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