Multiple Domain Model Approach

It is not always easy to build a stable feature model for a given domain. Some reasons have been discussed in the previous section. One other reason is the complexity of models for larger domains with a high number of features ( >100 ). Such domains often exhibit complex relations between features as well.

Such models are hard to develop, hard to maintain and hard to reuse. The problems sketched above are not unique to feature models but occur wherever complex scenarios are to be represented. The most common software engineering approach to handle those problems is decomposition into smaller problems that are easier to handle. Themulti domain model approach of CONSUL allows just that for feature models, unlike other approaches like FODA, FORM or FeatuRSEB that use only a single feature model.

CONSUL supports two different decomposition approaches based on multiple feature mod-els.

5.3.8.1 Domain Decomposition

Closer examination of a problem domain will always reveal that it is in fact composed of a number of smaller subdomains with a specialized focus. Of course, different decomposi-tions are possible, because some features may belong to more than one domain.

Looking at the HTML viewer component family example already introduced (Figure 5.10), a sample decomposition is given in Figure 5.13. Most features of the model belong to more general problem domains. Four domains have been identified here. The File Access,Document Rendering,Document RepresentationandScripting Languagesdomains contribute to the HTML viewer domain. The HTML viewer domain is an intersection of these domains. However, the relations between features within the in-tersected domains remain the same or are more restricted. For example in the general model a feature HTTP is probably an option or part of an or-feature group. In the HTML viewer component it is mandatory. But HTTPS is a sub-feature of HTTP in both models. Addition-ally more domain models may contain more features (shown with different color in Figure 5.13), since they covers different problems not relevant in the HTML viewer case.

5.3 Feature-Based Problem Analysis

rendering document representation

scripting languages file access

HTMLView

Transport ScriptEngines HTML

HTTP FTP NFS SMB ECMAScript PHP Perl RenderMode

Text Graphic Voice

Braille Format

MS Word

Dialect

HTML3.2 HTML4 XHTML

JavaScript VBScript HTTPS

Figure 5.13: Decomposition of a domain: HTML viewer component family domain feature(’ScriptingLanguages.JavaScript’) implies

conflicts(feature(’DocumentRepresentation.HTML3_2’))

Figure 5.14: Sample cross model feature relation for decomposed HTML viewer domains

Such a decomposition seems to have not much use in the first place, but the benefits become obvious when a similar problem is to be solved and therefore to be modeled. For a word processor a similar model could be used based on the same four domains but with a different intersection result. For example a different document representation would be probably used, but the rendering domain would remain the same.

As long as those models are independent from each other, their handling is easy. Often, there will be some kind of relationships between these models, although it is advisable to minimize these relations. CONSUL supports the connection of different models via their feature relations and model mapping expressions.

Instead of referring to features local to the model, it is also possible to include features from other models in the relation expression. For this, to each model a unique name is assigned that is used as prefix for its feature names. Figure 5.14 shows an exemplary rule for the domain based on the decomposition given in Figure 5.13. The left-hand side, before the colon, shows the name of the feature to which the relation expression is attached, the right-hand side shows the actual relation. In this example, the featureJavaScriptof the ScriptingLanguagesfeature model conflicts with the featureHTML3_2in the model DocumentRepresentation, that means that they cannot selected for the same feature set.

has(feature(’HTMLViewer.Text’)

implies feature(’DocRendering.Text’) has(feature(’HTMLViewer.Graphic’))

implies feature(’DocRendering.Graphic’) has(feature(’HTMLViewer.HTML3_2’))

implies feature(’DocRepresentation.HTML3_2’) ...

Figure 5.15: Mapping the HTML viewer domain 5.3.8.2 Domain Composition

Decomposing the domain of interest into a number of smaller domains makes it more main-tainable, easier to change and also easier to reuse, but on the flip-side is the loss of clarity for the family deployer. With just a single model, it is easier to visualize the most impor-tant relations between features as a parent/child relation. Between independent models no such relation exists. Additionally, when models are reused, the vocabulary (feature) used in one or more of the models may not be the desired one. There could be many features in a domain, for example, that have no relevance to the specific case. There are two options: the use of a modified feature model, or the hiding of the problems.

Depending on the situation, one approach has to be chosen. The use of a new model needs no further explanation and also no special support by CONSUL.

CONSUL supports the later approach byfeature mapping.

The example in Figure 5.15 shows some mapping functions of the original HTML viewer domain to the two other domain models.

5.3.8.3 Hierarchical Domain Models

The combination of the multi domain modeling with CONSUL’s three levels of software family domains presented in Section 5.1.1, leads to a hierarchal domain model structure.

The starting point is a domain model for the application family that may be mapped to other, reusable domain models on the application family level. These models are in turn mapped to the models that describe the component families used to implement the application fam-ilies. On the lowest level, the component family models are mapped to component specific models.

Figure 5.16 shows the previously introduced HTML browser application family with its feature model hierarchies. In this example, only the component family HTML Viewer

5.3 Feature-Based Problem Analysis

Figure 5.16: Structure of hierarchical domain models

uses multiple models. The features selected in the HTML Browser are mapped to the viewer model that in turn is mapped to the four sub-models (mapping expressions (Figure 5.17)). The mapping expressions for the sub-model mapping use some special expressions.

The expressionhas(f eature(⁰M odel1 :∗⁰))is expanded to match several expressions, one for each feature in the model. Thef eature(⁰M odel2.%⁰)is the counterpart and references the matched feature on the left-hand side. Thus, if both parts are combined, the expression maps each feature of the first model to the same feature of the second model.

This top-down view on the model structures is only possible after the completion of the application family development. In reality, the development of an application family from reusable component families is composed of two different, complementary processes: The top-down process that analyzes the application domain and builds/reuses models for it, and the bottom-up process of matching existing reusable component families against the appli-cation domain requirements. The same applies to the component family/component levels.

The result of these parallel processes is the completed, hierarchical model structure.

Compared to approaches that rely on a single model, the hierarchical model approach of CONSUL allows easier integration of existing software families into new families. Using a single model for each application family would force the developers of component families to maintain the features relevant to their component family in all application domain models.

With feature model mapping, only the links between the models have to be maintained.