Decision Models: One Way to Guide Reuse and Enable System Generation

Dirk Muthig

(muthig@iese.fhg.de)
Fraunhofer Institute for Experimental Software Engineering (IESE)
Sauerwiesen 6,  67661 Kaiserslautern, Germany
Generative and component-based software engineering are approaches to reuse. The problems that often arise  within a reuse environment are the identification and evaluation of assets concerning a given problem, as well as the composition of assets that are developed within different contexts (i. e., the compatability of assumptions made about the environment by the different assets).We argue that these problems can be avoided by creating all assets in the same context (i. e., in the scope of a product line) and constructing a decision model that guides the developer  through the identification, the adaption, and the composition of reusable assets.

Here, we will focus on the first step of the software life-cycle, the requirements elicitation. Domain analysis methods determine the common and varying requirements for a product line instead for one single system. The scope of the product line is the common context in which all assets will be developed. It is the bases for the potential improvements promised by domain engineering methods.  Our domain analysis approach is the Customizable Domain Analysis (CDA) method, which will be presented at GCSE '99 [1], in the context of PuLSE (Product-Line Software Engineering). The output of CDA are two workproducts: a domain model and a decision model.

The domain model, a set of workproducts, captures the requirements for all systems of a product line. There are two types of requirements: requirements that are common to all systems of the product line, commonalities, and requirements that vary from system to system, variabilities. Commonalities are not different from requirements for a particular single system except that they hold for all members of a product family. Variabilities are requirements that may differ between members of the product family.

We haved used PuLSE-CDA in several industrial projects, where we identified the need for CDA to be customizable to different environments and to minimize the necessary changes while introducing the product line approach. From a domain model point of view, this means that the workproducts to document requirements for the product line should be as similar as possible to the already established workproducts that have been used for documenting requirements for single systems.

Because there is no significant difference between commonalities and specific system requirements, the notations for documenting the latter can be adopted to document commonalities. But most of the notations used in practice do not consider variabilities. Hence, notations of generic workproducts (i. e., instantiatable workproducts that capture variant requirements) must be extended in a natural way. This is done by introducing meta elements that indicate points of variation and enable the instantiation of the workproducts. These meta elements connect the variabilities with decisions that, when completely resolved, specify (via instantiating the domain model) a particular system, a member of the product line. The decisions are at different levels of abstraction and are hierarchically structured based on constraints among them. This decision hierarchy is the domain decision model.

The structure of the decision model and its usage during application engineering will be presented in more detail. Examples gained from our projects will be used to visualize the theoretical framework of our  decision model and to prove its usability and relevance in industrial environments.

[1]  J. Bayer, D. Muthig, and T. Widen, Customizable Domain Analysis, accepted by GCSE '99.


Back to the GCSE Young Researchers Workshop Abstracts Overview.

Dirk Mutig
Last modified: Wed Sep 15 17:53:49 MEST 1999