Computer Systems & Architecture Lesson Software Product Lines

Objectives Describe why we need to reuse an existing architecture Explain that what makes software product lines work List the three things should be consider the architecture for product lines

10.1 Overview A software architecture represents a significant investment of time and effort, usually by senior talent. So it is natural to want to maximize the return on this investment by re-using an architecture across multiple systems. Architecturally mature organizations tend to treat their architectures as valuable intellectual property and look for ways in which that property can be leveraged to produce additional revenue and reduce costs.

When an organization is producing multiple similar systems and re-using the same architecture, it enjoys substantial benefits that include reduced cost of construction and reduced time to market.

This is the lure of the software product line, defined 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.

10.2 What makes software product lines work? The essence o a software product line is the disciplined, strategic re-use of assets in producing a family of products. What makes product lines succeed to spectacularly from the vendor or developer’s point of view is that the commonalities shared by the products can be exploited through re-use to achieve production economics. The potential for re-use is broad and far-ranging, including: –Requirements

–Architectural design –Elements –Modeling and analysis –Testing –Project planning –Process, methods and tools –People –Exemplar systems –Defect elimination

10.3 Scoping The scope of the product line defines what systems are in it, and what systems are out. Put less bluntly, a product line’s scope is a statement about what systems an organization is willing to build as part of its line and what systems it is not willing to build.

Of all of the assets in a core asset repository, the software architecture plays the most central role. The essence of building a successful software product line is discriminating between what is expected to remain constant across all family members and what is expected to vary. Products in a software product line exist simultaneously and may vary in terms of their behavior, quality attributes, platform, network, physical configuration, middleware, scale factors and so on Architectures for product lines

A product line architect needs to consider three things: Identifying variation points Supporting variation points Evaluating the architecture for product line suitability

Identifying variation is an ongoing activity. Because of the many ways a product can vary, variants can be identified at virtually any time during the development process. Some variations are identified during product line requirements elicitation; others, during architecture design; and still others, during implementation. Variations may also be identified during implementation of the second products as well. Identifying variation points

In a conventional architecture, the mechanism for achieving different instances almost always comes down to modifying the code. But in a software product line, architectural support for variation can take many forms: Inclusion or omission of elements. Inclusion of a different number of replicated elements. Selection of versions of elements that have the same interface but different behavioral or quality attribute characteristics. Supporting variation points

These mechanisms produce wholesale changes at the architectural level. Other mechanisms can be introduced that change aspects of a particular element. More sophisticated techniques include the following: –In object-oriented systems, specializing or generalizing particular classes can achieve variation. –Building extension points into element’s implementation. –Variation can be accomplished by introducing build- time parameters to an element, a subsystem, or a collection of subsystems, whereby a product is configured by setting a collection of values.

- Reflection is the ability of a program to manipulate data on itself or its execution environment or state. -overloading is a means of re-using a named functionality to operate on different types.

Like any other, the architecture for a software product line should be evaluated for fitness of purpose. In fact, given the number of systems that will rely on it, evaluation takes on an even more important role for a product line architecture. Evaluating a product line architecture

-What and how to evaluate. The evaluation will have to focus on the variation points to make sure they are appropriate, that they offer sufficient flexibility to cover the product line’s intended scope. -When to evaluate. An evaluation should be performed on an instance or variation of the architecture that will be used to build one or more products in the product line.

10.5 What makes software product lines difficult? It takes a certain maturity in the developing organization to successfully field a product line. Technology is not the only barrier to this; organization, process and business issues are equally vital to master to fully reap the benefits of the software product line approach. The Software Engineering Institute has identified twenty-nine issues or ‘practice areas’ that affect an organization’s success in fielding a software product line.

Most of these practice areas are applied during single-system development as well, but take on a new dimension in a product line context. Two examples are architecture definition and configuration management. Architecture definition needs to emphasize variation points in a software product line. Configuration management is each product is the result of binding a large number of variations.

Getting an organization to adopt the product line approach is in many regards like any other technology insertion problem. How to solve it depends on the organization’s culture and context. Top-down adoption comes when a manager decrees that the organization will use the approach. Adoption strategies

Bottom-up adoption happens when designers and developers working at the product level realize that they are needlessly duplicating each other’s work and begin to share resources and develop generic core assets. Orthogonal to the issue of in which direction the technology will grow is the question of how the product line itself grows. Here there are two primary models. Proactive model Reactive model

Creating products and evolving a product line An organization that has a product line will have an architecture and a collection of elements associated with it. From time to time, the organization will create a new number of the product line that will have features both in common with and different from those of other members. One problem associated with a product line is managing its evolution.

As time passes, the product line-or, in particular, the set of core assets from which products are built – must evolve. That evolution will be driven by both sources which are: –External sources –Internal sources

Organizational structure An asset base on which products depend, but which has its own evolutionary path, requires an organization to decide how to manage both it and product development. Jan Bosch has studied product line organizational models and has identified four types: 1.Development department 2.Business units 3.Domain engineering unit 4.Hierarchical domain engineering units.