Introduction

As discussed in the Chapters 1 and 2, for embedded software development it is important to produce both reliable software and resource efficient software in a fast and cost effec-tive process. So the main goal of this chapter is to evaluate approaches for family-based software development with respect to their usability in embedded software development.

Therefore, it is relevant which parts of the software development process are covered by a methodology, how it helps to produce the implementation(s) and that these implementa-tions use the memory and processing time effectively. This requires not only to look at the technical aspects of the methodologies alone. It is also necessary to take the typical skills and education of embedded software developers into account.

The promoters of software families and software product lines generally claim that these are an efficient way to produce reliable software (and are able to prove this). The question of resource efficiency does rarely get so much attention, however.

This chapter starts with a general introduction to software families and product lines. The following detailed discussion of the state of the art in this area covers general methodolo-gies, which are more focused on processes, as well as realizations techniques that can be used to actually implement software families or product lines. The concluding section dis-cusses how the different methodologies can be combined and summarizes the main issues of this chapter.

3.2 Family-Based Software Development and Product-Line Engineering

In the sixties and seventies of the last century a phenomena called “software crisis” ap-peared. Faster computers made previously unthinkable applications (theoretically) possi-ble. But while the creation of better and faster hardware even today follows Moore’s Law [Moo75], which predicts a doubling of computing speed per 18 month, the growing com-plexity of software development started to cause problems. More complex software results

in more lines of code, more interaction between program parts, more possible errors in pro-grams, and more time to get software produced. Therefore development of new programs could not be done at the same pace hardware evolved.

One of the reasons was that, compared to other areas of business, reuse of software artifacts in these days was limited. The emerging software engineering discipline started to think about how a system could be built from reusable parts. Parnas with his work aboutprogram familiespioneered in an area that is one of the hottest topics in software engineering today.

The termprogram families was coined by Parnas in 1976 when he discovered that many problems of software development and deployment are related to the fact that software development activities are often focused on solving only a single problem. He recognized that it may pay off to look not only at one problem at a time but to consider similar problems simultaneously.

His definition for program families, as given in [Par76], is

We consider a set of programs to constitute afamily, whenever it is worthwhile to study programs from the set by first studying the common properties and thendetermining the special properties of the individual family members.

While this definition can also be applied to already existing programs (or any set of related software artifacts), Parnas already saw the main application of the program family concept in the creation of new software. In [Par79] he described the application of the program family concept to support reuse in the area of operating system design.

The term product lineappeared much later in the software engineering community. The focus of product-line engineering is quite different, yet the main ideas are the same for program families and product lines.

The definition for a product line, as given in Griss [Gri00], is quite close to the definition of Parnas:

Aproduct lineis a set of products that share a common set of requirements, but also exhibit significant variability in requirements. This commonality can be exploited by treating the set of products as a family and decomposing the design and implementation into a set of shared components that separate concerns.

But this definition requires that asignificantamount of variability has to be present, whereas Parnas focuses more on commonality between family members.

Another definition, given by Lopez-Herrejon et al. [LHB01], states that “Aproduct lineis a family of related software products . . . Different family members (product-line applications) are represented by different combinations of components”. This definition states even more

3.2 Family-Based Software Development and Product-Line Engineering

clearly that while there have to be relations between the products in a product line, it does not have to be a very strong relation.

Both definitions focus on different aspects of product lines. The first definition emphasizes on the origin of a program family based on a set of requirements, whereas the second defini-tion gives a hint on how product-lines are implemented. Both use the termfamilyto describe the set of members of a product line and both fit into Parnas definition of a program fam-ily ifprogramis replaced by product. Product lines are by definition not necessarily pure software products but may be any kind of product. The main difference between program families and product-lines is the view on commonalities and variabilities: A product line is defined by the needs of the customers of the product line, which is an external view, a program family is defined by its internal view on the programs.

Although the product-line term is the more popular term today, this dissertation focuses on software family development rather than product-line development for two reasons:

• The term software family¹ focuses on the aspect of producing software, which is an inside view, a product-line approach takes an outside view, focusing on the final results (the products). Products are not always just software, often, especially in the embedded systems area, they are a combination of hard- and software.

• Although it is possible (and sometimes even the optimal way) to implement software for product lines without using software families, software families are in general the appropriate solution.

The goal of family-based software development is to benefit from producing the common parts of a family only once and reuse them to create different family members by combining common parts and member-specific parts. Admittedly, the extraction and realization of the common parts of a set of applications may initially cost more than the creation of a small number of separate applications, but once the number of applications grows, the family-based development finally costs less, as is shown for example in [CHW98].

The Figure 3.1 shows that under though simplified yet reasonably accurate assumptions, there is a point where the high initial investment for a family starts to pay off, because the cost for creating a family member is lower than the cost for producing a new single system solution from scratch.

1Although Parnas used the termprogram family,the term software familyseems to be more appropriate, because a software family is not necessarily a set of complete programs, but may be any kind of software artifact like a library or component.

Systems Number of Initial Cost

of Family

Total Investment

1 2 3 4 5 6

Software Family Single Systems

1 3 5

2 4 6 7 8 9

Figure 3.1: Benefits of software families versus single application development