PBr

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.

Software process analysis and modeling

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

Motivation: Software processes range from simple and ad-hoc to complex and over-specified. The development has its patterns and rules, but they are very often not known or violated in practice; the symptoms of problems that this causes 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.

Efficient software component representation, verification and matching

(lang:cz Reprezentace, ověřování a porovnávání softwarových komponent s ohledem na efektivitu)

Motivation: Compilers and strongly typed languages give us basic level of assurance that a (monolithic) system will not encounter run-time failures due to mismatches on syntactical contract level. This is however not the case in dynamically composed modular systems, and reliability assurance is a challenge for safe assembly and updates in near future component/service-based mobile applications (cf. EZdroid) and/or highly dynamic re-configurable systems (SOA). QoS representation is missing on API level, with estimation or values based on service implementation, for use in service matching (needs good SOTA analysis, may have been mostly done already, potential motivation: industrially usable method (not obscure academic one ;-) ).

How can we design and improve component representation (meta-data), methods for its extraction from specification, documentation and/or implementation and use for architectural consistency assurance? Can we devise methods for matching components (using these representations) within an application as well as with user requirements, which are computationally efficient for e.g. resource-constrained and dynamic scenarios?

Concrete example topics:

  • Controlled partial upgrades of evolving service-based systems.

Architecture and Methodologies for Adaptive Software with Safety Requirements

(lang:cz Architektury a metodiky pro adaptivní software s požadovanou úrovní bezpečnosti)

Motivation: Current automotive, railway and similar systems are increasingly software-driven, composed of a mix ranging from safety-critical to infotainment elements. New versions of software parts need to be installed, and its architecture needs to enable adaptation to changing circumstances. Software systems tend to grow in size and complexity, and this trend has hit the safety-critical world as well — a modern high-end car now hides more LOC under its hood than a most popular desktop operating system did a decade ago.

This blend poses many challenges from the technological and methodological point of view: we would like to have a pleasant user experience yet we must not compromise system (and therefore user) safety while we have difficulties comprehending the system’s complexity. How should we design, develop, and maintain such systems? Where are methods which are sufficiently simple for everyday use yet profound in their foundations (so we can firmly rely on them)?

Concrete example topics:

  • Architecture and Methodology for Adaptive AUTOSAR Middleware and Applications. (Sangita De, since 2017)
  • Designing Metrics for Modular Software with high Relevance for Quality Properties

(Previous Topics)

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).

Further topics of interest

(Read: if you are really interested in any of these, I’m open to discussion):

Component or module substitution/matching with margins of correctness

  • motivation = even though a 1-to-1 substitution (e.g. version upgrade) of a component may not be viable (would be type unsafe, behaviourally inconsistent, etc.), it may be granted when the capabilities available in the context and/or the scope of differences support it and/or when the substitution is done for a set of related components and/or if we consider “degrees of similarity” rather than strict black-and-white compatibility (e.g. via ability to generate adapters at deployment/binding time); this is a continuation of current research
  • goal = methods, models and algorithms to measure the degree of incompatibility, determine the alternatives of resulting architectures and their suitability, analyse and support substitution of a set of components
  • scope = measures will cover extent and quality of differences on component or set-of-components interface, methods will consider both 1:1 and M:N substitution

Software development process patterns

  • motivation = sw development has its patterns and rules, but they are very often not known or violated; the symptoms of problems that this causes are not recognized early enough.
  • goal = use existing project data from bugtracking / ALM tools to detect and describe potential good/bad practices and the consequent benefits/risks. build a repository of process/practice patterns as they manifest in the tools, e.g. in burndown charts, to serve as a guide for project managers etc.