PBr

Areas and Topics offered for PhD supervision

Based on our research group areas, officially listed on faculty pages. The concrete topic is always negotiable — if the list does not fit exactly and you are interested in something related, just drop me a line.

Note: Whenever I use the term “component”, it primarily means a black-box reusable piece of software but can also denote a “module” as in modular programming (think C or Ada), “service” as in service-oriented architectures (think SOAP/WSDL or REST), or possibly even “agent” as in autonomous systems.

Area: Software Process Analysis and Modeling

(lang:cz Analýza a modelování softwarových procesů)

Motivation: Software processes range from simplistic and ad-hoc through simple and (mostly intentionally) under-specified to complex and (mostly un-intentionally) over-specified. Software development has its patterns and rules, but they are very often not known explicitly or are "silently" violated in practice; the symptoms of ensuing problems are not recognized early enough.

When you find yourself in the middle of a running project, how do you know which methodology the project actually uses (possibly versus which is the officially declared one), and how do you find out which possible discrepancies and methodology issues to tackle first? Could we use existing project data from bugtracking / ALM tools and empirical research methods to detect and describe potential good/bad practices and the consequent benefits/risks for a given project?

Concrete example topics:

  • Detect process-related anti-patterns in data extracted from a range of project- and application-lifecycle management tools. (Petr Picha, since 2014)
  • Discover actual methodology used by a given project, from its data.

Area: Effective Model-Based Verification of Modular Software

(lang:cz Modely řízené ověřování modulárního software s vysokou účinností)

Motivation: Compilers and strongly typed languages give us assurance of syntactical ("API") contract compliance for (monolithic) systems, and automated testing of all levels and types gives us reasonable trust that software systems will not encounter run-time failures in many circumstances. But achieving higher levels of reliability assurance (think corner cases and interaction/QoS contract levels), keeping strong traceability between models and implementations, and doing so efficiently (think shorter verification times and higher defect-detection rates), is a challenge.

How can we design and improve component/service representations (API and data/control-flow models), methods for their extraction from specification, documentation and/or implementation? Can we devise methods that use these models for matching components within an application? For testing their behaviour with high bug-detection rate and small test suites? The aim is industrially usable methods, not obscure academic ones ;-)

Concrete example topics:

  • Stochastic models (Markov and bayesian networks) for corner cases in functional safety software testing (Lukáš Černý, since 2020).

Area: Architectures for Adaptive Software with Safety Requirements

(lang:cz Architektury pro adaptivní software s požadavky na technickou bezpečnost)

Motivation: Current automotive, railway and similar systems are increasingly software-driven and more complex, composed of many components ranging from safety-critical to infotainment elements. New versions of these software parts need to be installed, and the system architecture needs to enable adaptation to changing circumstances, often without interrupting system operations. This blend poses many challenges from the technological and methodological point of view: we must not compromise system (and therefore user) safety while we have difficulties comprehending the system’s complexity.

What models, mechanisms and procedures can ensure that the evolved components do not disturb software and system functionality and quality? How do we update such systems "on the fly"? Can the relevant methods be sufficiently simple for everyday use yet profound in their foundations (so we can firmly rely on them)? Especially relevant for software assembly and updates in continuously running and/or highly dynamic re-configurable systems (e.g. control and self-adaptive).

Concrete example topics:

  • Architecture and Methodology for Adaptive AUTOSAR Middleware and Applications. (Sangita De, since 2017)
  • Consistency verification of modular flight software systems, enabling safe in-flight software updates.
  • Controlled partial upgrades of evolving service-based systems.

(Previous Topics - of historical relevance only)

Visualization of complex modular software systems (2013+)

(lang:cz Vizualizace komplexních modulárních softwarových systémů)

Motivation: Very little advances have been made in visual representations that would scale with the structural complexity and size of current applications (thousands of components in flat diagram); UML is vastly inadequate.

Goals:

  • Design or improve novel visual representations of software systems (notations, layouts) using unique approaches like interaction, mobile viewports, off-screen and 2.5D views.
  • Create suitable underlying models (meta-data) and algorithms (layout, clutter reduction) that would enable the description and visualization of software systems consisting of thousands of elements (components / modules / classes / …).

The topic mixes aspects of technological, information visualization and usability areas.

PhD students

  • Jaroslav Snajberk — thesis defended 2014
  • Lukas Holy — thesis defended 2016

Software component models for reliable composition (since ca 2010)

(lang:cz Komponentové modely pro spolehlivou kompozici software)

Motivation: Most current component models have “holes” or leaky abstractions – they don’t describe all features of the components on the interface level, e.g. events or configuration items. This leads to implementation (hidden) dependencies, in clear contradiction to the original purpose of black-box components = compositionality and substitutability.

Goals:

  • Investigate how the component/module black-box can be violated — hidden dependencies, leaked properties, stale references, illegal callbacks — and design measures to prevent it, e.g. in the form of a truly black-box component model.
  • Enhance standard lifecycle and binding of components to maintain architectural integrity/consistency throughout runtime evolution — prevent incompatible bindings, syntactically or semantically fragile component updates, creating hidden dependencies.

This is a basic research topic but requires validation of the concepts by real implementation to show they can be realized in a highly practical way.

Related research grant projects:

  • GACR 2011-2013 Development and verification of component-based applications using natural language specifications + GACR 2008-2010 Consistency verification of advanced component-based applications
  • Submitted: ABB research grant, FP7 EcSiTe, NTIS startup

and tools:

On the topic’s periphery are also these aspects:

  • dynamic languages like Groovy and JavaScript for use in components (e.g. JSR 292 and Da Vinci).
  • domain-specific components (e.g. for streaming applications, location-aware services, …) built on a common base of a generic component model, following core information hiding principles (obsessively black-box).