[competencies] Research:
The Design Space Technique
Competencies HomepagePublicationsActivitiesWhat else?
overviewprojectspastprojectsresearchawardspaperslecturescv
Generic ComponentsSystem DevelopmentDesign SpacesUsing Design Spaces
 
 

Design spaces provide a uniform, semi-formal way for describing and classifying both requirements for and properties of software artefacts. Design Spaces are equally suited to capture functional as well as non-functional properties such as architectural issues or time and memory complexity.
 

A wealth of design choices...

During the development of an application, many different design decisions have to be taken. The Design Space for a specific application domain is intended to describe the entirety of these design choices along with the possible alternatives. The Design Space is spanned by dimensions corresponding to relevant criteria for classifying systems belonging to the chosen domain. Each dimension describes the possible variation in one system characteristic. A dimension may either enumerate the set of possible alternatives or categories, or the possible values may be represented using continuous data types like Integer or Float.

Existing systems can be characterized by specifying at most one category from each dimension. Reusable, generic software artefacts where exact properties -- e.g. concerning their timing behaviour -- will be determined only at the time of their deployment in a concrete application, can be described by using compound data types like sets and intervals on the simple data types.

Those dimensions referring to requirements or properties concerning a software artefact's observable behaviour or functionality span the so-called requirements subspace (originally referred to as the functional subspace) of the overall Design Space. The remaining dimensions describe architectural or structural properties, i.e., how the system achieves its task. The subspace spanned by these dimensions is therefore called the structural Design Space. It represents the architectural choices and decisions to be made during system design.
 

How to capture design expertise?

The dimensions in a Design Space are typically not independent from each other. Relationships exist between categories of different dimensions; these relations are expressed via so-called correlations. Correlations can be used to describe how design alternatives will fit together, i.e., to express favorable or unfavorable combinations of choices. Each side of a correlation may be a boolean expression over the values of specific dimensions. We distinguish between two qualitatively different kinds of correlations: strong correlations express either complete incompatibility or strict dependence of categories. Weak correlations, on the other side, describe the fact that the combined selection of some categories is advantageous or disadvantageous. For weak correlations, we deploy a quantification on a scale ranging from -1 to +1. A value of +1 indicates that the respective categories can favorably be used together, while a value of -1 expresses that the categories should not be combined in one system.

Correlations may either be symmetrical or asymmetrical. The latter kind of correlations describes relationships of the type "if the characterized system has property A, then it should also have property B". Symmetrical correlations, on the other side, describe a type of equivalence: The existence of a symmetrical correlation of 1.0 between two categories A and B expresses that it is highly probable that a system has either both properties or none of them.

Correlations between categories in the functional Design Space and categories in the structural Design Space map requirements to structural design aspects. They can be considered as design rules helping the designer to choose adequate designs for a given set of requirements. Correlations within the structural design space represent design consistency constraints. They can be used to prevent bad design choices by explicitly describing the advantages and disadvantages of different structural combinations. Correlations between dimensions in the functional Design Space represent interdependencies between requirements (e.g., trade-offs between contradictory goals) that can be used to denote consistency constraints for the requirements specification.
 

Introducing structure

In order to structure Design Space descriptions, it is possible to define groups of Design Space dimensions referring to some distinct part of the overall system functionality, e.g. fault tolerance or scalability aspects. This allows to emphasize that certain classification criteria are closely related, and thus facilitates understanding of the Design Space by the application developers.

A concept of hierarchical dependencies allows to state that certain dimensions are only applicable to a subset of all systems belonging to the respective domain, as expressed by a specific category in one specific dimension. Besides this, it is possible to define an order on the Design Space dimensions, indicating in which sequence they should be applied. This allows domain experts to record their experience that classifying an application according to dimension A is easier than classifying it according to dimension B. The subsequent selection of a category in dimension B may then be facilitated by correlations narrowing the set of available alternatives, e.g. because some design choices should not be used in conjunction with those properties already selected.
 

Incremental refinement

A Design Space for a specific application domain can be validated by classifying a set of systems from this domain. The hints obtained from evaluating the correlations between the Design Space dimensions can be compared to the characteristics of the existing systems. Mismatches are indications for inadequacies or mistakes in the Design Space description. Either some correlations are actually wrong and need to be corrected, or the Design Space misses to consider relevant characteristics of the scrutinized systems that have to be investigated in more detail. This approach can be further generalized to a methodology for iterating and refining Design Spaces. In such a way, experiences from past software projects can be reused during realization of new applications.
 

Deployment of Design Spaces

The concept of Design Spaces is useful for a variety of purposes. First, the dimensions in the requirements Design Space can be considered as a catalogue enumerating important criteria for the requirements specification, providing hints concerning the relevant criteria that have to be taken into account. By reusing this catalogue, the activity of requirements specification is considerably facilitated. Another effect is that the requirements specifications of different systems belonging to the same application domain become comparable.

The correlations between dimensions in the requirements Design Space can be interpreted as consistency constraints for the requirements specification; their consideration can contribute to an improvement of the quality of the design documents. Similarly, the correlations between dimensions in the structural Design Space indicate consistency constraints for design aspects. By evaluating them, unfavorable or inconsistent combinations of design decisions can be detected.

Moreover, the Design Space concept provides a facility for capturing experience of developers, especially with respect to architectural aspects. Design rules -- correlations between dimensions in the requirements and dimensions in the structural Design Space -- can be used as guidelines for the high-level design of applications belonging to the respective application domain. Based on the characterization of the application in the requirements Design Space, the design rules indicate favorable combinations of design alternatives in the structural subspace. Even without considering design rules, the enumeration of "assorted" design alternatives already forms an important asset for the development of new applications, comparable to a pattern catalogue.
 

 
Homepage | Competencies | Publications | Activities | What else
Nov-2004