Domain Engineering

Systems Number of Initial Cost

of Family

Total Investment

1 2 3 4 5 6

Software Family Single Systems

1 3 5

2 4 6 7 8 9

Figure 3.1: Benefits of software families versus single application development

3.4 Domain Engineering

Customer Needs

Domain Engineering

Application Engineering Domain

Analysis Domain

Design

Product Configuration

Domain Implementation

Additional Requirements Domain

Knowledge

Requirements Analysis

Custom Development

Integration and Test Model

Domain Family

Architecture

Product Configuration Additional

Requirements

Product Features

Design Custom

Figure 3.2: Relation between domain and application engineering (based on [SEI97]) reusing these assets (i.e. retrieval, qualification, dissemination, adaptation, assembly, and so on) when building new systems” [CE00].

The domain engineering itself can be further divided intodomain analysis,domain design anddomain implementation. Each of these parts has a strong relation to its corresponding counterparts in application engineering. The relations are depicted in Figure 3.2. It is im-portant to point out the feedback path from the application engineering back to the domain engineering. During application engineering additional requirements that have to be con-sidered in the domain engineering may be found. These requirements may influence the domain analysis, design or implementation.

The gathering of domain knowledge is not only an activity where external information is processed just once. Knowledge gathered during the other parts of the process may also change the view on the domain. The same holds true for all parts. Even a custom devel-opment may eventually lead to the inclusion of parts of that develdevel-opment into the domain design or implementation.

3.4.1 Domain Analysis

The domain analysis (DA) is the most important and probably also the most difficult step in developing of family-based software. It is mainly concerned with defining theproblem domain. The term “problem domain” is used, because it describes the different problems the family members have to solve. The goal of DA is to model the problem domain in a way that can be used to produce a software family for it.

In order to be able to produce a model for a domain, everyone must agree on what the domain actually is. Therefore, the first activity in DA is to define thescope of the domain, that is, to find a measure to decide which problems belong into the domain and should be supported by family members and which do not.

DA requires an in-depth understanding of the (possible) problems of the domain to give a precise and clear definition of the domain scope. The domain experts are responsible for the scope definition. They have to create the definition in cooperation with all potential stakeholdersof the domain, like end users, domain designers and implementors, application analysts and designers, and even the developing organization management.

The scoping activity, like all other activity in domain analysis, usually does not produce final results immediately. Results of the following activities during the domain analysis and also during the other parts of domain and application engineering may lead to a changed view on the domain and could eventually result in a changed and improved domain scope definition.

The next activity is to find out what differentiates the problems in the domain and what is common to all problems or subsets of them. The results of this variability and commonality (VC) analysis already give a measure to evaluate the scope definition with respect to the range of problems included.

If the number of commonalities is high and only a very limited number of variabilities exists, the scope might be too small to justify the development of a family. If the number of potentially useful family members is too small, the additional effort for creating a family could be wasted.

It is also possible that the VC analysis shows a low number of commonalities. This could indicate that the scope is too wide, there could be too many systems in the domain that have not enough in common to be effectively producible from the same set of reusable abstractions. However, since all these indicators are very soft, it is not possible to give general advice on how to interpret the results of the VC analysis. Experience from previous, comparable projects is necessary to decide this matter.

The scope and representation of the results of a VC analysis differs for different methodolo-gies. Most methodologies use a graph-like structure to represent commonalities, variabili-ties and their relations. Some methods additionally include case diagrams, state diagrams and other means to represent the problems covered by the domain.

To enable discussion during the analysis and to communicate its results, it is necessary for all persons involved to understand each other. Often, different terms have the same meaning to different persons or, even worse, the same term is interpreted differently by different persons. To solve this problem most methodologies propose the creation and use of a domain dictionary. Such a dictionary holds the definitions for all special terms relevant

3.4 Domain Engineering

in the domain. The domain dictionary is created at the beginning of the domain analysis phase, and extended later, if required.

The scope definition, the results of the VC analysis and the domain terminology dictio-nary together form a model of the domain that is then used in the subsequent development activities.

The main problem of domain analysis is that it relies mostly on soft factors like knowledge about the domain, the appropriate choice of the domain scope, commonalities and variabil-ities. Even small changes may result in completely different results that may fit better or worse. In general, it is not possible to decide whether a better domain representation exists.

3.4.2 Domain Design

The domain design activity translates the results of the domain analysis (the domain model) into a software design that allows to create the different family members from it. For a given domain model there might be many different designs that could be used. The choice of the design is influenced, for instance, by the skills of the designers and the available tools.

One of the most important influences is the nature of the domain itself. If, for instance, a high degree of variability must not cause avoidable overhead, the chosen design has to ensure this.

The methodologies vary extremely in the way they support the domain design activity. A number of methodologies only define the process of how to create a domain design but do not prescribe a specific design methodology (for example FAST [WL99], ODM [SCK⁺96]).

While this permits the use of these methodologies in a wide range of domains, the price to be paid is that external domain design methodologies have to be integrated. Some other methodologies define a specific way how the results of the domain analysis can be translated into a design more or less directly (for example GenVoca [BO92] or DEMRAL [Cza98]).

Usually, these methodologies fit only for a smaller range of domains, but are easier to use and produce results in shorter time.

3.4.3 Domain Implementation

The implementation of a software family from a domain model is the last step in the creation of a software family. Though the design has a strong influence on the implementation, there is still a high degree of freedom for an implementation. Object-oriented designs can be realized with a number of different programming languages. As with the domain design, the domain implementation depends on factors like developer skills, resource constraint etc.

To implement families and especially the variability within families, it is possible to use different techniques depending on the design and other criteria like the binding time of a

variability (configuration time, compile time, link time or run time). These techniques are discussed in more detail in Section 4.