Article Preview
Top1. Introduction
Designing, developing and maintaining a good software system is a challenging task still in this 21st century. The approach of reusing existing good solutions for developing any new application is now one of the central focuses of software engineers. Building software systems from previously developed components saves cost and time of redundant work, and improves the system and its maintainability. A new software development paradigm, software product line (Clements & Northrop, 2001), is emerging to produce multiple systems by reusing the common assets across the systems in the product line. However, the idea of product line is not new. In 1976 Parnas (Parnas, 2001) proposed modularization criteria and information hiding for handling product line.
A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (Clements & Northrop, 2001). Core assets are the basis for software product line. The core assets often include the architecture, reusable software components, domain models, requirements statements, documentation and specifications, performance model, etc. Different product line members may differ in functional and non-functional requirements, design decisions, run-time architecture and interoperability (component structure, component invocation, synchronization, and data communication), platform, etc. The product line approach integrates two basic processes: the abstraction of the commonalities and variabilities of the products considered (development for reuse) and the derivation of product variants from these abstractions (development with reuse) (Hein, Schlick, & Vinga-Martins, 2000).
The main idea of software product line is to explicitly identify all the requirements which are common to all members of the family as well as those that are different, and then arrange them in a model. This implies a huge model which will help the stakeholders to be able to trace any design choices and variability decisions as well. Finally, the derivation of the product is done by selecting the required variants from the model and configuring them according to product requirements.
Common requirements among all family members are easy to handle as they simply can be integrated into the family architecture and are part of every family member. But problem arises from the variant requirements among family members. Variants are usually modeled using feature diagram, inheritance, templates and other techniques. In comparison to analysis of a single system, modeling variants adds an extra level of complexity to the domain analysis. In any product line model, the same variant has occurrences in different domain model views. Different variants have dependencies on each other. Tracing multiple occurrences in different model views of any variant and understanding the mutual dependencies among variants are major challenges during domain modeling. While each step in modeling variant may be simple but problem arises when the volume of information grows. As a result, the impact of variant becomes ineffective on domain model. Therefore, product customization from the product line model becomes unclear and it undermines the very purpose of domain model.
The objective of this chapter is to provide an approach to modeling variants in the domain model of a product line. This model carries all the variant related information like specifications, interdependencies, origins of variants, etc. In developing product line, the variants are to be managed in domain engineering phase, which scopes the product line and develops the means to rapidly produce the members of the family. It serves two distinct but related purposes; firstly, it can record decisions about the product as a whole including identifying the variants for each member, and secondly, it can support application engineering by providing proper information and mechanism for the required variants during product generation (Fig. 1).
Figure 1. Product derivation using variability model