PhD in Software Design: Research Ideas

In this page you will find several possible research directions that can be pursued within a PhD (or even an MSc) programme. By no means this is intended to be a comprehensive list! You are invited to contact me to discuss these or your own ideas.

Ideas in this page:

Tool support in object-oriented design
Formal specification of object-oriented design
LePUS3 in UML
Abstraction classes in software design
Measuring software flexibility

Tool support in object-oriented design

Key terms: Object-oriented programming, CASE tools, software visualization

Primary skills: Programming in Java

Tool support in object-oriented design (OOD) aims to provide means for capturing abstractions in object-oriented applications and class libraries. Activities which such a tool can support or automate include the following:

Modelling: Using a well-defined visual notation (unlike UML) would help the programmer understand the principles upon which the system is designed by.
Specification (forward engineering): Write how the system should be designed.
Visualization: Write specifications in a visual language
Verification: Ensure that the specifications are followed by the implementation.
Recognition (reverse engineering): Extract the 'design' of the program from the source code.

The two-tier programming project is an ongoing effort to build tool support for these activities. Possible research directions include:

Verification of software design: Pick a software development project and claims about it's design and use the TTP toolkit to prove or refute these claims.
Pattern recognition: Use the TTP toolkit to search for patterns in code.
C++ application: extend the TTP toolkit to C++.

Formal specification of object-oriented design

Key terms: Mathematical logic, design patterns, object-oriented programming, software visualization

Primary skills: Abstraction, object-oriented programming

The objective of formal specification is to deliver precise and concise method of expressing object-oriented design decisions. Objects of specification include design patterns, class libraries, and application frameworks. Our ongoing research in formal specification of OOD has lead us to formulate LePUS3 and Class-Z, a small subset of the Z specification language designed to support both visual and symbolic specifications:

LePUS3 is a visual specification language which provides a well-defined alternative to UML Class Diagrams.
Class-Z Schemas are Z schemas-like specifications.

LePUS3 and Class-Z have well-defined semantics and it is axiomatized in the first order predicate calculus. Possible research directions include:

Model in LePUS3 or in Class-Z: Java Foundation classes, Java Swing, Smalltalk-80, Enterprise JavaBeans, .NET, or your favourite application.
How can we model the Java blueprints (pick your favourite design pattern here) in LePUS3?

For more details please see: lepus.org.uk

LePUS3 in UML

Primary skills: Object-oriented design and modelling

Key terms: Unified Modeling Language (UML), LanguagE for Patterns Uniform Specification (LePUS), version 3 (under development.)

LePUS is a formal and visual language for specifying object-oriented design. The objective of this project is to re-define LePUS3 in UML 2.0.

Abstraction classes in software design

Key terms: Software design theory, software architecture

Related terms: Mathematical logic

Primary skills: Abstraction, broad familiarity with software design

What are the primary categories of software design? We observe three categories that divide the spectrum of software design statements:

Strategic statements ('architectural design') include architectural styles, programming principles, component-based software engineering standards, and design principles.
Tactical statements ('detailed design') include design patterns, programming idioms and refactorings.
Implementation statements include UML class and collaboration diagrams, and program documentation.

According to the Intension/Locality hypothesis, these categories can be distinguished formally using the Locality criterion and the Intension criterion as follows:

Strategic statements are non-local
Tactical statements are local and intensional
Implementation statements are extensional

Possible research directions include:

Determine the abstraction class of a .NET (Pick your favourite software design description here.)

Measuring software flexibility

What does it mean for software to be flexible? A theory on measuring software flexibility I developed with Tom Mens attempts to answer this question. Given the design pattern, architectural style, or any other well-formed expression of the software's 'design', the notion of evolution complexity can help us assess the complexity of specific evolution steps.

Possible research directions include:

Select your favourite software package and measure its flexibility towards a particular class of changes; conclude in which ways the software is flexible and in which way it is not.
Suggest ways to expand the theory towards a combination of changes and offer an absolute flexibility metric.

Related material:

Amnon H. Eden, Tom Mens. “Measuring Software Flexibility.” IEE Software, Vol. 153, No. 3 (Jun. 2006), pp. 113–126. London, UK: The Institution of Engineering and Technology.