Part II Product Lines for Digital Information Products
8.2 Application Design
rationale behind this approach is that on the one hand individualization is limited to a certain degree, but on the other hand, synergy effects can be realized which increase quality (because common components make updates easier and less error-prone) and reduce production costs. If negotiations with customers can only satisfy few of their requirements or if negotiations fail entirely, e.g., because there are no adequate configurations or core assets, this feedback is given to domain engineering for possible changes.
Example 8.1
Based on the example for domain requirements in Sect. 7.1.2, a special e-learning course on “Information Systems” can have the following content requirements (ne-gotiated with a customer group):
Content requirements:
1. The course on “Information Systems” has a general introduction “Introduction to IS”.
2. The course needs the domain “databases” with “database modeling”.
3. The database domain has an introduction “Introduction to DB”.
4. The domain “database modeling” has the “ER model” and the “relational model”.
5. The course needs the domain “workflow”, and the domain “workflow modeling”
with “Petri nets”.
6. The domain “workflow” has an introduction “Introduction to WF”.
8.2 Application Design
Using the requirements specified in application analysis, the objective of ap-plication design is to create a product-specific model and a product map, based on the conceptual product line model and core asset version graphs de-veloped in domain engineering. The affected models and the tailoring process are explained next.
8.2.1 Deriving a Product Model
The product model determines a specific content configuration that is se-lected for one particular information product. In a general sense, the product model defines the “architecture” of the specific information product. Using the requirements from application design, the specific product configuration is derived from the conceptual product line model.
The product model can be regarded as an instance of the conceptual prod-uct line model. The rules that are presented in the sequel are used to derive an instance, and thus, a content configuration that is valid according to the product line constraints. From a general point of view, these represent the semantics of the grammar introduced in Fig. 7.1. There are also conceptual similarities between these rules and those presented in Def. 4.4 for software products in software product lines. The rules also unveil how synergy effects are achieved through the usage of common features or common domains.
1. A product model P M is a subtree of the conceptual product line model CP LM.
2. By definition, the root domain of CP LM is included into P M .
3. A domain or feature of type common has to be included into P M if its immediate predecessor was included, i.e., for any included common do-main or common feature, all immediate successors of type common have to be included in P M .
4. An optional domain or optional feature may be included into P M if its immediate predecessor is included.
5. If the immediate predecessor of an alternative domain (which has at-tributes min, max) was included in P M , then, the particular alternative domain must also be included. Furthermore, if an alternative domain con-tains only alternative features (see grammar in Fig. 7.1), at least min and at most max of these features must be chosen; if an alternative domain contains only other alternative domains, then at least min and at most maxof these domains must be included.
6. A crosscutting feature (which has no type) has to be included in P M if its immediate predecessor was included.
Example 8.2
The application of the aforementioned rules is illustrated in this example which uses the conceptual product line model introduced in Fig. 7.2. A product model (for a product variant) should be derived that satisfies the specific content requirements of the example in Sect. 8.1.1.
As shown in Fig. 8.1, we can proceed in a top-down manner to include the appropriate domains and features from the conceptual product line model into one concrete product model; included features or domains are checked off. By rule 2, the root domain is included. Then, “Introduction to IS” is included (rule 3), “Layout-General” (rule 6), and “Databases” (rule 3). As a consequence, “Introduction to DB”, “DB Modeling”, “ER Model”, and “Relational Model” are included (rule 3).
By rule 4, “Workflow” is included. As a consequence, “Introduction to WF” must be included (rule 3), and “Petri Nets” is chosen from “WF Modeling” (rule 5).
The resulting product model is depicted on the right side of the figure, and it has a valid configuration. The crosscutting feature “Layout-General” will be weaved into all atomic features of the domain where it is located, and all subdomains (see Sect.
8.2 Application Design 141
Information Systems
Petri Nets
<<alternative>>
Event-oriented Process Chains
<<alternative>>
WF Implementation
<<optional>>
WF Modeling
<<alternative>> (1,2) Workflow
<<optional>>
Databases
<<common>>
Introduction to DB
<<common>>
DB Modeling
<<common>>
ER Model
<<common>>
Relational Model
<<common>>
DB Theory
<<optional>>
Normalization
<<optional>>
DB Implementation
<<optional>>
SQL
<<optional>>
WFMS Architecture
<<optional>>
Introduction to WF
<<common>>
Layout-General Introduction to IS
<<common>>
Information Systems
Petri Nets
<<alternative>>
WF Modeling
<<alternative>> (1,2) Workflow
<<optional>>
Databases
<<common>>
Introduction to DB
<<common>>
DB Modeling
<<common>>
ER Model
<<common>>
Relational Model
<<common>>
Introduction to WF
<<common>>
Layout-General Introduction to IS
<<common>>
Conceptual Product Line Model Product Model
Product-specific Features
Introduction to IS Introduction to DB
ER Model
Relational Model Introduction to WF Petri Nets
all with layout ‘‘Layout-General’’
Fig. 8.1. Example of a derivation of a product model from the conceptual product line model of Fig. 7.2.
7.2). Looking at the product model, it becomes also clear which atomic features are to be realized in this particular information product (lower left side of the figure), and that their order is not yet important at this stage.
This example also clarifies that not every content configuration is allowed by the product line specifications. For example, it is not allowed to select only “SQL”
and “WFMS Architecture”. The conceptual product line model imposes that if these features are selected, then we must also select at least “Introduction to IS”,
“Layout-General”, “Databases” with “Introduction to DB”, and “Workflow” with
“Introduction to WF”. This way, a certain reuse context is guaranteed, and a con-tent developer is aware of the possible configurations in which a certain concon-tent
component is reused.
8.2.2 Creating a Product Map
The product model specifies so far only which domains or features have been chosen for a specific information product. At this point, additional configura-tion details are added: each product feature is assigned a predefined version of its corresponding core asset version graph.
Essentially, the product map template that was prepared in domain design (see Fig. 7.4) is now used to do this assignment. After the data for the
partic-ular product has been completed in the product map template, it is referred to as the product map (of the particular product). The principle of how to assign a version to a feature is shown conceptually in Fig. 8.2.
Domain Subdomain1 Subdomain2 Feature Digital
Information Product:
Course 1 Layout-General v. 1.0 Introduction to IS C v. 1.2a
Databases C Introduction to DB C v. 1.1
DB Modeling C ER Model C v. 2.0 Relational Model C v. 1.3 DB Theory O Normalization O DB
Implementation
O SQL O
Workflow O Introduction to WF C v. 1.0
Modeling A (1,2)
Petri Nets A v. 2.1
Event-oriented Process Chains Information Systems A
WF Implementation
O WFMS Architecture
O
V1.0 V1.1a V1.2a
change 1 change 2
V1.1b change 4 V1.2b
change 3
Introduction to IS Core Asset Version Graphs
Package1
Package2
Package3
Fig. 8.2. Example of a product map for a specific product.
For each feature (atomic or crosscutting) that is contained in the product model, exactly one version from its associated core asset version graph must be chosen, which is written at the intersection of the row of the respective feature and the column of the product. This assignment means that a feature has be to realized by that particular version. This assignment is similar to the built-from-relation discussed in Def. 4.4 for software product lines. Further-more, it is indicated in the Figure how the atomic features will be grouped into delivery packages, according to the packaging requirements captured in do-main engineering. Technically, the data of the aforementioned assignments is added to the product map database that was prepared in domain engineering (Fig. 7.5).