- 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.2 Software Product Lines
The most promising approach for architecture reuse is to develop a product line architecture, which explicitly captures the commonality and variability in the family of systems that constitutes the product line. Various terms are used to refer to a software product line. A software product line is also referred to as a software product family, a family of systems, or an application domain. The terms used most often in the early days of this field were domain analysis (Prieto-Diaz 1987) and domain modeling. The architectures developed for application domains were referred to as domain models or domain-specific software architectures (Gomaa 1995).
Parnas referred to a collection of systems that share common characteristics as a family of systems (Parnas 1979). According to Parnas, it is worth considering the development of a family of systems when there is more to be gained by analyzing the systems collectively rather than separately—that is, when the systems have more features in common than features that distinguish them. A family of systems is now referred to as a software product line or a software product family. Some approaches attempt to differentiate between these two terms. This book, in common with other approaches, does not differentiate between the terms software product line and software product family, assuming that they both refer to a family of systems.
The architecture for a software product line is the architecture for a family of products. Some product line development approaches provide a generic architecture, or reference model, for the product line, which depicts the commonality of the product line but ignores all the variability. Each application starts with the generic architecture and adapts it manually as required. Although this approach provides a better starting point in comparison to developing a system without any reuse, it fails to capture any knowledge about the variability in the product family.
A more desirable approach is to explicitly model both what is common and what is different in the product family. A software product line architecture should therefore describe both the commonality and variability in the family. Depending on the development approach used (functional or object-oriented), the product line commonality is described in terms of common modules, classes, or components, and the product line variability is described in terms of optional or variant modules, classes, or components.
The term application engineering refers to the process of tailoring and configuring the product family architecture and components to create a specific application, which is a member of the product family.
1.2.1 Modeling Variability in Software Product Lines
Modeling commonality and variability is an important activity in developing software product lines. Early advocates of product line development included proponents of the FAST (Family-Oriented Abstraction, Specification, and Translation) approach and its predecessors (Coplien et al. 1998; Weiss and Lai 1999), work at the Software Engineering Institute (Clements and Northrop 2002; Cohen and Northrop 1998; Kang et al. 1990), work at the Software Productivity Consortium (Pyster 1990), and the EDLC (Evolutionary Domain Life Cycle) approach (Gomaa 1995; Gomaa and Farrukh 1999; Gomaa and O'Hara 1998; Gomaa, Kerschberg, et al. 1996). Jacobson et al. (1997) introduced the concept of variation points as a way to model variability in use cases and UML.
Variability in a software product line can be modeled at the software requirements level and at the software design level. The most widely used approach for modeling variability in requirements is through feature modeling, as described next.