- Software Reuse
- Software Product Lines
- Modeling Requirements Variability in Software Product Lines: Feature Modeling
- Modeling Design Variability in Software Product Lines
- Reusable Design Patterns
- Modeling Single Systems with UML
- COMET: A UML-Based Software Design Method for Single Systems
- Modeling Software Product Lines with UML
- UML as a Standard
- Related Texts
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Modeling Design Variability in Software Product Lines
Techniques for modeling variability in design include modeling variability using parameterization, modeling variability using information hiding, and modeling variability using inheritance (Gomaa and Webber 2004). The relative merits of each technique depend on the amount of flexibility needed in the product line. These approaches are described briefly in Sections 1.4.1 through 1.4.3.
1.4.1 Modeling Variability Using Parameterization
Parameters can be used to introduce variability into a software product line. The values of parameters defined in the product line components are where the variation comes in. Different members of the product line would have different values assigned to the parameters.
Parameterization approaches use four different types of parameters:
-
Compilation parameters. Values are set at compile time. This approach is sometimes used to conditionally compile code depending on the parameter setting.
-
Configuration parameters. Values are set at system configuration time, which is sometimes referred to as system generation (sysgen) time or system installation time.
-
Runtime initialization parameters. Values are set at system initialization time. The component could provide operations that are called at system initialization to initialize or change the values of parameterized attributes.
-
Table-driven parameters. Some reusable applications are configured with parameters that are stored in tables. This can be an effective way of allowing users to configure the application.
Several product line analysis methods use parameterization. The FODA method developed at the Software Engineering Institute (SEI) uses features to characterize the domain (Kang et al. 1990). In FODA, one kind of feature is the parameter. In the Domain-Specific Software Architecture (DSSA) program, generic components were parameterized to simplify customization for particular applications (Hayes-Roth 1995). The FAST product line method (Weiss and Lai 1999), which emphasizes analyzing commonality and variability in a product line, uses parameterization extensively as one of the approaches to achieve variability. The EDLC model for software product lines uses parameterization at configuration time to define the values of component parameters (Gomaa and Farrukh 1999).
A well-documented case study of a product line that used parameterization is CelsiusTech (Bass et al. 2003). CelsiusTech's Ship System 2000 (SS2000) is a product line for command and control of naval systems. The SS2000 consisted of parameterized components for which the application engineers supplied the parameter values. The SS2000 features 3,000 to 5,000 parameters that must be individually set for each member system of the product line. Managing such a large number of parameters could be a problem because little or no guidance is given on how to ensure that parameters are not in conflict with each other.
1.4.2 Modeling Variability Using Information Hiding
Information hiding can also be used to introduce variability into a software product line. Different versions of a component have the same interface but different implementations for different members of the product line. Thus the variability is hidden inside each version of the component. In this case the variants are the different versions of the same component but must adhere to the same interface. This approach works well as long as changes can be limited to individual components and no changes to the interface or assumptions about how the interface will be used are required. From a reuse perspective, the application engineer selects a component from a limited set of choices and uses it in the application.
Most product line methods use information hiding. In addition to parameterization, the FODA, DSSA, FAST, and EDLC methods already described all use information hiding.
1.4.3 Modeling Variability Using Inheritance
A third way of introducing variability into a software product line is to use inheritance. In this case, different versions of a class use inheritance to inherit operations from a superclass, and then operations specified in the superclass interface are redefined and/or the interface is extended by the addition of new operations. For a given member of the product line, the application engineer selects the version of the component.
With the widespread use of object-oriented techniques, variability using inheritance has become increasingly common in software product lines. The KobrA approach (Atkinson et al. 2002), which is an object-oriented customization of the Product Line Software Engineering (PuLSE) method (Bayer et al., 1999; DeBaud and Schmid 1999), uses inheritance to model component variability. In the EDLC product line method (Gomaa and Farrukh 1999), inheritance is used to model different variant subclasses of an abstract class, such that the variants are used by different members of the product line.
1.4.4 Comparison of Approaches for Modeling Design Variability
Modeling variability using parameterization allows application engineers to define the values of product line attributes, which are maintained by various product line components. If all the variability in a product line can be defined in terms of parameters, then this can be a simple way to provide variability. However, the variability is limited in that no functionality can change. In some product lines parameterization is used to select among functionality alternatives, although it is a complicated and error-prone approach and needs to be used with care.
Modeling variability using information hiding allows application engineers to choose variants from a limited set of choices in which the interface is common but the implementations are variable. Information hiding allows a higher degree of variability than parameterization does because both functionality and parameters can be varied.
Modeling variability using inheritance allows application engineers to choose variants whose functionality can vary. Because of the nature of inheritance, this approach also allows a wider range of variants by extending the superclass interface in variant subclasses.
In most product lines, a combination of all three approaches is needed. The object-oriented approach to software development helps by supporting all three of these approaches to modeling variability. However, other approaches are also needed, as explained next.