Developing Software Lines: Why Bother?
- 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
A software product line consists of a family of software systems that have some common functionality and some variable functionality. To take advantage of the common functionality, reusable assets (such as requirements, designs, components, and so on) are developed, which can be reused by different members of the family. Clements and Northrop (2002) define a software product line as "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" (p. 5).
The interest in software product lines emerged from the field of software reuse when developers realized that they could obtain much greater reuse benefits by reusing software architectures instead of reusing individual software components. The software industry is increasingly recognizing the strategic importance of software product lines (Clements and Northrop 2002).
The idea of a product line is not new. There are examples of product lines in ancient history; the pyramids of Egypt (Figure 1.1) might have been the first product line! A modern example of product lines comes from the airline industry, with the European Airbus A-318, A-319, A-320, and A-321 airplanes, which share common product features, including jet engines, navigation equipment, and communication equipment (Clements and Northrop 2002).
)
Figure 1.1 A product line from ancient history: the pyramids of Egypt
The traditional mode of software development is to develop single systems—that is, to develop each system individually. For software product lines, the development approach is broadened to consider a family of software systems. This approach involves analyzing what features (functional requirements) of the software family are common, what features are optional, and what features are alternatives. After the feature analysis, the goal is to design a software architecture for the product line, which has common components (required by all members of the family), optional components (required by only some members of the family), and variant components (different versions of which are required by different members of the family). To model and design families of systems, the analysis and design concepts for single-product systems need to be extended to support software product lines.
This chapter presents an overview of software reuse and software product lines. It also gives an overview of using the Unified Modeling Language (UML) to develop component-based software product lines.
1.1 Software Reuse
Software reuse has been a goal in software engineering since 1968, when the term software engineering was first coined. This section briefly surveys different approaches to software reuse, starting with the most common form of software reuse (using reuse libraries) and leading up to software product lines.
1.1.1 Software Reuse Libraries
In traditional software reuse, a library of reusable code components is developed. This approach requires the establishment of a library of reusable components and of an approach for indexing, locating, and distinguishing between similar components (Prieto-Diaz and Freeman 1987). Problems with this approach include managing the large number of components that such a reuse library is likely to contain and distinguishing among similar though not identical components.
The reusable library components are the building blocks used in constructing the new system. Components are considered to be largely atomic and ideally unchanged when reused, although some adaptation may be required. Depending on the development approach, the library could contain functional or object-oriented components. This reuse approach has been used with both functional and object-oriented systems.
When a new design is being developed, the designer is responsible for designing the software architecture—that is, the overall structure of the program and the overall flow of control. Having located and selected a reusable component from the library, the designer must then determine how this component fits into the new architecture.
An example of this traditional reuse is a subroutine library, which consists of a collection of reusable subroutines in a given application area—for example, a statistical subroutine library. Another example is an object-oriented toolkit, which consists of a set of related and reusable classes designed to provide useful, general-purpose functionality. These reuse libraries and toolkits emphasize code reuse.
Apart from certain specific domains, such as mathematical libraries, the benefits of the traditional software reuse approach have been limited in general. With this approach, overall reuse is relatively low, and the emphasis is on code reuse.
1.1.2 Software Architecture and Design Reuse
Instead of reusing an individual component, it is much more advantageous to reuse a whole design or subsystem, consisting of the components and their interconnections. This means reuse of the control structure of the application. Architecture reuse has much greater potential than component reuse because it is large-grained reuse, which focuses on reuse of requirements and design.