Part II Product Lines for Digital Information Products
5.4 Overview of PLANT
5.4.2 A Process Model with Three Sub-Processes
The process model complements the strategy and provides more concrete guidance during the creation of product lines for digital information products.
The process model of the PLANT approach is depicted in Fig. 5.1. It is derived from the insights gained with software product lines (Sect. 4.2) and has three different, interrelated sub-processes: family engineering, domain engineering, and application engineering. The sequence of the respective activities in the sub-processes does not have to be strictly waterfall-like, and iterations are possible. An overview of the sub-processes is shown next in Tab. 5.1–5.4.
More details will follow in Chapters 6–8, and details on the interrelation of the sub-processes will be explained as well.
Family engineering (1) has the view on the product line as such and pro-vides an organizational roof for the PLANT approach. It is assumed that the activities of family engineering (cf. Tab. 5.1) are executed when a product line is initiated, and thereafter for controlling purposes at specified time intervals or after the completion of one pass of domain or application engineering. The main purpose of family engineering is to complement the purely technical view
5.4 Overview of PLANT 81
Repository of Core Assets
1) Family Engineering
2) Domain Engineering 3) Application Engineering Domain Req.
Documents
Models
Construction Artifacts
Domain Test Artifacts Process
1) Domain Analysis
2) Domain Design
3) Domain Realization
4) Domain
Testing Product Repository
Process 5) Evaluation/Controlling
Repository 1) Feasibility/Risk Assessment
2) Economic/Evolution/Lifecycle
3) Configuration Management Documents
2) Application Design
3) Application Realization
4) Application Testing 1) Application
Analysis 4) Organization
Digital Information Product 1 Digital Information Product n Design
Digital Artifacts
Test Artifacts Requirements
Documents
Fig. 5.1. The process model of the PLANT approach with the most important activities and connections.
of domain and application engineering by management issues. More details are presented in Chapter 6.
Domain engineering (2) is a sub-process that focuses on all digital in-formation products in one product line in one specific domain. Most of the overall effort is invested here to plan and prepare reuse. All artifacts created in domain engineering are called core assets, and are stored in a core asset repository on which activities in other phases can draw upon. The core assets represent the building blocks that can be used later to build a concrete digital information product. There are various types of core assets in PLANT which are shown in Tab. 5.2. The typical inputs, outputs, and activities of domain engineering are depicted in Tab. 5.3.
Domain engineering makes preparations for application engineering and among these, defines exactly one conceptual product line model for one prod-uct line. This model specifies before reuse which content configurations are allowed for digital information products. Later, in application engineering, one concrete digital information product can only have a content configura-tion that can be derived from the conceptual product line model; a prede-fined product map template is used to capture in application engineering the product-specific configurations.
It has already been mentioned that digital information products can con-sist of a mixture of content and software (Sect. 2.2.5), and this becomes ob-vious in PLANT since especially the construction artifacts can be content, or a mixture of both content and software; thus, the phases in the domain
Table 5.1. Overview of family engineering in PLANT. A detailed description is given in Chapter 6
1.1 Feasibility/Risk Assessment
Inputs: results of interviews/surveys, information about legal regulations, best practices in the field, competitors, current state of market, available resources and constraints
Activities: assess technical and organizational feasibility of product line; assess risk Outputs: family engineering overview document; if necessary: other documents
(surveys, etc.)
1.2 Economic/Evolution/Lifecycle Aspects Inputs: overview document
Activities: estimate effort in person months with/without PLANT; plan update cycles for content during lifecycle of information products
Outputs: updated overview document; if necessary: other documents with details 1.3 Configuration Management
Inputs:
overview document; if available: feedback from domain analysis (2.1) with configuration data from market-based view, feedback from appli-cation realization (3.3) with configurations from product-based view Activities: if data is available: compare and assess if configurations from
market-based view and product-market-based view match sufficiently Outputs: updated overview document
1.4 Organization Inputs: overview document
Activities:choose appropriate organization structure for employees or check whether existing one is still suitable; define who is responsible for fam-ily, domain, or application engineering
Outputs: updated overview document
1.5 Evaluation/Controlling Inputs: overview document
Activities: check is defined indicators in 1.1–1.4 are within expected ranges; make decisions
Outputs: updated overview document with next date for evaluation
engineering process are not only concerned with content development, but also in parallel with software development. Content components are construc-tion artifacts that contain a predefined piece of content. Other artifacts such as applets (e.g., used within a Web page) or helper programs, are software.
Helper programs are used to create information products by composition out of content components, or to accomplish other tasks; they are procured or created in domain engineering.
A version graph model is defined uniformly for all core assets, but it is em-ployed only if an asset needs to be versioned. For example, a version graph can be used to track the evolution of content components and ease the simultane-ous usage of different component versions in different information products.
5.4 Overview of PLANT 83 Table 5.2. Types of core assets for one product line in PLANT. Details are presented in Chapter 7.
1. domain requirements documents 2. models1
a) 1 product line metamodel
b) 1 conceptual product line model (derived from product line metamodel) c) 1 product map template
d) 1 component model for content components e) 1 uniform versioning scheme for core assets f) 1 construction specification
g) 0 . . . ∗ reusable workflow modules
h) 0 . . . ∗ models for software artifacts (e.g., for helper programs, etc.) 3. construction artifacts
a) content components
b) other artifacts (such as layout description files, helper programs, programs that are part of the content)
4. test artifacts
Furthermore, a uniform component model is specified for all content com-ponents in one product line, which guarantees that all content comcom-ponents have for example the same structure and the same underlying assumptions for reuse. Therefore, the assembly of content components becomes less prob-lematic than with components found in public repositories which were built according to different requirements.
The construction specification defines in fact a construction workflow model that creates all information products in one product line, using con-struction artifacts. Reusable workflow modules, which represent prefabricated pieces of a workflow model, can be prepared to speed up the creation of a con-struction specification. The actual execution of the workflow model is done in application engineering. Additional details on domain engineering of PLANT are presented in Chapter 7.
Application engineering (3) focuses on the construction of one single digital information product (see Tab. 5.4 for an overview of inputs, outputs, and activities). However, it is not allowed to realize every conceivable product, but only one that can be derived from the specifications made in domain engineering. If some specific core assets are needed for a product which are not already there, then application engineering must be stopped and domain engineering is repeated with adequate feedback. The term “application” seems suitable in this context, since (as already argued) the content inside a digital information product may consist of a mixture of content and software.
1“1” means “exactly one”; “*” means arbitrary many.
Table 5.3. Overview of domain engineering in PLANT. A detailed description is given in Chapter 7
2.1 Domain Analysis
Inputs: results of interviews/surveys; if available: external domain requirements documents (e.g., legal regulations) or other available artifacts; if avail-able: feedback from domain testing (2.4) or application analysis (3.4)
Activities:
define scope of the product line; define content & packaging require-ments valid for all information products in the product line; define requirements for additionally employed software artifacts (e.g., helper programs); communicate market-based view of configurations to (1.3) Outputs: domain requirements documents
2.2 Domain Design
Inputs: domain requirements documents from domain analysis (2.1); if avail-able: feedback from application design (3.2)
Activities:derive product line models (see Tab. 5.2, 2a-2g) from product line re-quirements; if necessary: create models for additional software artifacts (e.g., helper programs; see Tab. 5.2, 2h)
Outputs: models
2.3 Domain Realization
Inputs: models from domain design (2.2), if available: feedback from application realization (3.3)
Activities:
realization of construction artifacts for digital information products (Tab. 5.2 3a-3b), i.e., content components (by forward engineering or re-engineering from existing material), realization of other artifacts (e.g., layout descriptions; helper programs for construction, packaging, de-livery; programs for test case generation; programs that are part of content), realization of product map database and construction work-flow model
Outputs: construction artifacts
2.4 Domain Testing
Inputs: construction artifacts (from 2.3), domain requirements documents (from 2.1), if available: feedback from application testing (3.4)
Activities:
create reusable domain test cases; test construction artifacts (e.g., syn-tax checking, content validation, test of helper programs), verify that construction workflow model can generate only products with desired configurations, integration testing of content components
Outputs: tested construction artifacts; reusable domain test cases; if necessary:
feedback to domain analysis (2.1)
Due to the preparatory work of domain engineering (e.g., content creation or programming), the focus of application engineering is shifted towards a derivation of a content configuration, and assembly of appropriate core assets.
The product map template records the configuration special to one product.
The configuration data is stored in a relational database. In a well-designed product line the effort of application engineering should be less than in
tradi-5.4 Overview of PLANT 85 Table 5.4. Overview of application engineering in PLANT. A detailed description is given in Chapter 8
3.1 Application Analysis
Inputs:
domain requirements documents (from 2.1); if needed: domain design models (from 2.2) for assessing application-specific requirements; re-sults of application-specific interviews/surveys; if available: feedback from application testing (3.4)
Activities:
define particular requirements for one digital information product; con-sider requirements/constraints defined in domain engineering (2.1 and 2.2)
Outputs: application requirements documents for one digital information prod-uct; if needed: feedback to domain analysis (2.1)
3.2 Application Design
Inputs: application requirements documents from application analysis (3.1), models from domain design (2.2)
Activities: derive the models and the specific configuration for one specific digital information product
Outputs: application-specific models; if necessary: feedback to domain design (2.2)
3.3 Application Realization
Inputs: models from application design (3.2), construction artifacts prepared in domain realization (2.3)
Activities:configuration and assembly of one digital information product; commu-nication of created configuration (product-based view) to family engi-neering (1.3)
Outputs: one digital information product with its specific digital artifacts; if nec-essary: feedback to domain realization (2.3)
3.4 Application Testing Inputs:
the digital information product (from 3.3), domain requirements docu-ments (from 2.1), application requiredocu-ments docudocu-ments (from 3.1), do-main test artifacts (from 2.4)
Activities: test and validate digital information product
Outputs: tested and validated digital information product; if necessary: feedback to application analysis (3.1), domain testing (2.4)
tional single-product development – the payback of the investment in domain engineering.
After a product is created, it is allowed to make some manual adaptations to make it suit better to product-specific requirements, but only if they do not contradict the overall product line constraints, and if the effort of the modifi-cations is low compared to the overall effort needed for application engineering (e.g., adding some cross-references, etc.). However, in a well-designed product line such adaptations should be rare. For major modifications (e.g., of new
core assets), PLANT requires a new pass of domain engineering. More details on application engineering are discussed in Chapter 8.
An overview of the models used in PLANT in domain and application engi-neering is shown in Fig. 5.2, along with a categorization into conceptual, logi-cal and physilogi-cal design (i.e., from a general to a more specific, implementation-dependent view). The models are on different abstraction layers and allow a delay of design and configuration decisions for a concrete variant up to the latest possible point. At the most general level, the conceptual product line model, which is built according to the product line metamodel, specifies which content configurations are possible for information products. The con-tent component model specifies the general characteristics of reusable concon-tent components, which are a special category of core assets of a product line. Core assets can be versioned according to the core asset version graph model. A product map derives a product model based on the conceptual product line model; the product model records a special feature configuration, as well as the versions of the core assets implementing those features. In a general sense, the product model can be regarded as the architecture description of a prod-uct. The data of the product map is stored in a relational database, which is queried during the construction of a product. The construction specification is a workflow model that specifies how to create each information product in the product line. Reusable workflow modules are prefabricated model pieces that can be employed to speed up the design of the construction specifica-tion model. Addispecifica-tional details on the presented models will be provided in Chapters 7– 8.
How PLANT is initiated
The interconnections between domain, application, and family engineering for digital information products pose the question of where to start when the PLANT approach is initiated. In brief, the initial pass is sketched in Fig. 5.3;
PLANT starts in family engineering. If there is a decision in favor of one product line, the process can move on to the first pass of domain engineering.
Thereafter, a base of core assets is available for one product line. Individual in-formation products can then be derived in application engineering. After each pass of domain or application engineering, the product line is re-evaluated in family engineering which can use updated data, for example data from domain analysis, or product configuration data recorded in application realization.