Part II Product Lines for Digital Information Products
7.3 Domain Realization
Composition
Final Construction Workflow for the Product Line
Repository of Core Assets Domain Req.
Documents
Models
Construction Artifacts
Domain Test Artifacts
Workflow Warehouse
Fig. 7.8. Reuse of workflow modules kept in a workflow warehouse.
a warehouse), non-volatile (i.e., the existing workflow modules in a warehouse are not changed), and time-variant (i.e., modules are stored for a longer pe-riod of time). In this respect, there are similarities with data warehouses (see [Inm96, PS05a]).
The combination of places and transitions of copies of workflow modules with those of the edited workflow can be described in a formal way with join operators as defined in [PS05a]. Other details on the workflow warehouse and the usage of workflow modules are given in Sect. 9.2.3.
7.3 Domain Realization 127 manner. Starting with the requirements for a specific content component and the uniform content component model, the content component (which con-tains the actual information) is created, and the finished component is stored in the repository of core assets.
Example 7.4
Some examples for content components (based on different content component models):
• A Powerpoint file of a lecture on ER Models
• A Web page for a lecture on ER Models
• An XML file of a lecture on ER Models
• A PDF file of a lecture on ER Models
• A video file of a lecture on ER Models
Reengineering from Existing Material
The reengineering approach combines a bottom-up and a top-down approach for the creation of content components. In some cases digital material is al-ready available which could be used to create content components for a prod-uct line. However, there are obstacles in practice which sometimes impede an easy transfer, such as different file formats that possibly do not allow easy modification of content, or diverging layouts and content structures. In such cases, an adaptation of existing content to create content components that satisfy the product line requirements can be as tedious as a creation from scratch.
Reengineering can help in this context by automating some of the well-structured tasks. The principle of reengineering involves, similar to reengineer-ing of software [CI90], the phases reverse engineerreengineer-ing (bottom-up) and forward engineering (top-down), and is depicted in general for content artifacts in Fig.
7.9. At first, reverse engineering analyzes a given digital artifact, such as a file containing some content, and extracts some data whose representation is on a higher level of abstraction which allows for modifications. Thereafter, forward engineering creates a content component according to the content component model, which fits into the product line context, and the level of abstraction is reduced. The difference between forward engineering alone as described at the beginning of this section and reengineering, is that reengi-neering has additionally the phase of reverse engireengi-neering that extracts some useful data from existing artifacts, followed thereafter by forward engineering which makes adaptations.
A more detailed process model for reengineering digital artifacts, which can be used with the creation of content components, is shown in Fig. 7.10. The
Digital Artifact Digital
Artifact Reverse Engineering
Forward Engineering
Abstraction Level
Fig. 7.9. Principle of re-engineering of existing content (see also [PSV05]).
process model assumes that from existing artifacts, some kind of components can be extracted, which can be for example, text, audio and video files, flash animations, or layout specifications. The automated component identification phase (which does reverse engineering) is performed automatically, and is followed by the semi-automatic component qualification phase for forward engineering.
Automated Component Identification (Reverse Engineering)
Context Parsing (Using Data Model)
Abstract Representation
Component Analysis (Using Extraction Model)
Identified Components
Component Extraction (Using Extraction Model) Define Reusability Models
Semi-Automatic Component Qualification (Forward Engineering)
Domain Engineer
Component Spec./Test (Apply Reusability Metrics)
Component Classification (Apply Taxonomy Model)
Packaging
Storage
Candidate Repository
Core Assets Repository Candidates
Qualified, Reusable Components
Categorized Components
Packaged Components
PDF Text
HTML XML
Java Applets
other
Existing Sources
-Data Model -Extraction Model -Reusability Specs.
-Taxonomy Model
Transformation
Adapted Components 1)
2)
3)
4)
5)
6)
7)
8)
9)
Fig. 7.10. A reengineering process model for content components (cf. [PV05]).
At the beginning of the process, a domain engineer has to define the reusability models that are used for automation (phase 1), such as the data
7.3 Domain Realization 129 model of the file which contains the data to be extracted (e.g., an XML DTD), the extraction model that specifies what to extract (e.g., an XQUERY defi-nition), reusability specifications to compute how well a piece was extracted (e.g., syntax conformity, etc.). An optional taxonomy model can be defined to help to categorize extracted candidates more easily when many candidates are there. In phase 2, the data model is used to parse existing files and gain a more abstract representation, such as an abstract syntax tree [ALSU07].
This representation is used in component analysis (phase 3) which applies the extraction model to identify the parts of interest; these represent candidate components which are stored in phase 4 into a temporary candidate repos-itory. In practice, it is possible that the aforementioned conceptual reverse engineering phases are not directly distinguishable when they are embedded inside reverse engineering tools (e.g., [Cif94]).
The semi-automatic work that needs interaction with the domain engineer begins in phase 5. At first, extracted candidates are automatically examined with the available reusability specifications. In addition, the domain engineer manually inspects and tests the extracted results to see if the components are useful and, if not, go back to earlier phases. When a large number of com-ponents need to be extracted and a taxonomy model was defined earlier, the appropriate categorization of components can be done in phase 6 to simplify their handling. In phase 7, extracted content components can be additionally transformed to fit within the product line context, i.e., the content, layout, structure, or granularity may be modified manually or with appropriate tools to satisfy the requirements of the content component model. In phase 8, a finished content component can be “packaged”, i.e., additional metadata can be added if necessary, or the delivery format can be changed (e.g., to a com-pressed file format to save space). Finally, the packaged content component is stored in the core assets repository.
Reengineering is especially attractive when an organization has lost the original source files of content components, which are only available in a binary format that does not allow simple modifications, or when creation from scratch is too expensive or not possible. Reverse engineering, however, can have many intricate legal implications which can differ in various countries and license agreements; these aspects are discussed in [Sam90, Hoe06]. Additional details on the process model and its activities can be found in [PV05].
7.3.2 Realization of other Construction Artifacts
Other artifacts are possibly needed within a product line in order to be able to create products. Depending on the chosen content component model, lay-out specifications may be separately defined. If possible, such a separation should be always be done, because it makes the individualization and the maintenance of content easier. For example, Powerpoint layout specifications can be separately saved in a master file; for HTML-based content one can
create separate CSS files, for XML one can create formatting guidelines with XSL-FO.
In many cases, programs need to be integrated within textual content. Such programs are also created in domain realization. For example, programs that are often embedded into content are Flash animations or Java applets (e.g., simulations, etc.).
Additional helper programs are created if the combination of content com-ponents and other construction artifacts cannot be performed with available tools, and especially if it is not possible to integrate the tools into an auto-mated workflow. Helper programs need to be designed in such a way that the construction of digital information products can be made by calling these pro-grams with certain parameters. Helper propro-grams can be for example format converters or wrappers that provide for the workflow a standardized interface for calling different programs. Helper programs are a critical part of the au-tomation of the construction workflow model for digital information products.
Depending on the application domain, the testing of construction artifacts may become tedious and inefficient when many different cases have to be tested. If such cases can be derived in an algorithmic way, test case generators can be created to simplify this task. Such generators are also reusable in application testing.
Example 7.5
Some examples of other construction artifacts:
• Layout-specifications: A Powerpoint master file “master.pot”
• Helper programs:
– pptappend.exe: appends the slides of a Powerpoint file after the last slide of another Powerpoint file; accepts 3 parameters: source file 1 and 2; 3) the output file.
– pptapplytemplate.exe: applies a layout file to a Powerpoint file; accepts 2 parameters: 1) a Powerpoint file; 2) a Powerpoint master file
– pptextracttemplate.exe: for reengineering purposes, this program extracts a layout specification from an existing Powerpoint file; accepts 2 parameters:
1) a Powerpoint file; 2) the file name in which the extracted master is to be stored.
7.3.3 Realization of the Product Map Database
The product map template (see Fig. 7.5) is implemented as a relational database. In addition, the data available from domain engineering is initially entered into the appropriate tables (i.e., relations): the domains, features, core asset version graphs for the construction artifacts, package data.
7.4 Domain Testing 131