All of the methodologies and tools introduced throughout this book rely on the evaluation of appropriate case studies. This chapter introduces three industrial-strength case studies serving as a foundation for all subsequent chapters in this book.

The Sales Scenario case study demonstrates business application engineering in the domain of enterprise software, a rather large domain encompassing, for example, enterprise resource planning (ERP), product life cycle management (PLM) and supply chain management (SCM). Such solutions must be adapted and customised to the particular company where the activities are employed. This is not a trivial task because of highly different needs of the respective stakeholders. For this reason business applications often have thousands of configuration settings. To reduce the complexity for the sake of conciseness, the Sales Scenario case study is focused on one specific sub-domain – customer relationship management (CRM) – combined with some parts of the aforementioned solutions.

Introduction

The previous chapters of this book have presented a number of different techniques that are useful for developing software product lines (SPLs). These techniques can be combined in a variety of ways for different SPLs; each SPL is likely to require its own combination of techniques. To provide some guidance for SPL engineers, this and the next chapter discuss different scenarios for product line development and explain the ways in which the techniques previously presented can be used in these scenarios.

This chapter focuses on product-driven SPL engineering. We begin by explaining what we mean by this term, followed by an identification of requirements for this SPL scenario and a description of an approach for systematically developing such SPLs. The chapter closes by discussing the approach and how it meets the initial requirements as well as the challenges discussed in Chapter 1.

Introduction

The implementation of a product line consists of a set of reusable components, called core assets, which are composed and configured in different ways to build different concrete products. The goal of a product line to support multiple products introduces additional complexity both to its assets and to the development process. The assets are more complicated because they must deal with variations of the concrete products. The development process is more complicated because it must deal not only with evolution of the common assets, but also with independent evolution of products and instantiation of new products.

In order to reduce the complexity of the implementation of a product line and to facilitate independent evolution, it is desirable to modularise the core features of a product line and the specific features of individual products. Considering features as units of variation in a product line, our goal is to support feature-oriented decomposition of software, in which each feature is implemented in a separate module.

Introduction to traceability in SPL

Traceability is a quality attribute in software engineering that establishes the ability to describe and follow the life of a requirement in both the forward and backward directions (i.e. from its origins throughout its specification, implementation, deployment, use and maintenance, and vice-versa). The IEEE Standard Glossary of Software Engineering Terminology defines traceability as ‘the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another’ (IEEE, 1999).

According to (Palmer, 1997) ‘traceability gives essential assistance in understanding the relationships that exist within and across software requirements, design, and implementation’. Thus, trace relationships help in identifying the origin and rationale for artefacts generated during development lifecycle and the links between these artefacts. Identification of sources helps understanding requirements evolution and validating implementation of stakeholders’ requirements. The main advantages of traceability are: (i) to relate software artefacts and design decisions taken during the software development cycle; (ii) to give feedback to architects and designers about the current state of the development, allowing them to reconsider alternative design decisions, and to track and understand bugs; and (iii) to ease communication between stakeholders.

Introduction

Variability management is a key challenge in software product line engineering (SPLE), as reflected in challenge 2 (identifying commonalities) introduced in Chapter 1. A software product line (SPL) is all about identifying, modelling, realising and managing the variability between different products in the SPL.

Variability management has two major parts: modelling the variability an SPL should encompass; and designing how this variability is to be realised in individual products. For the former part, different kinds of variability models can be employed: a typical approach is to use feature models (Kang et al., 1990) (or cardinality-based feature models, see Czarnecki et al. (2005b), in some cases), but domain-specific languages (DSLs) have also been used with some success. The latter part – modelling how variability is realised – is less well understood. Some approaches have been defined and will be discussed in Section 4.2, including their limitations. In this chapter, we therefore focus on DSLs for variability management and present a novel approach developed in the AMPLE project that aims at overcoming these limitations.

As the size and complexity of software systems grows, so does the need for effective modularity, abstraction and composition mechanisms to improve the reuse of software development assets during software systems engineering. This need for reusability is dictated by pressures to minimise costs and shorten the time to market. However, such reusability is only possible if these assets are variable enough to be usable in different products. Variability support has thus become an important attribute of modern software development practices. This is reflected by the increasing interest in mechanisms such as software product lines (Clements & Northrop, 2001) and generative programming (Czarnecki & Eisenecker 2000). Such mechanisms allow the automation of software development as opposed to the creation of custom ‘one of a kind’ software from scratch. By utilising variability techniques, highly reusable code libraries and components can be created, thus cutting costs and reducing the time to market.

A software product line is 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. Core assets are produced and reused in a number of products that form a family. These core assets may be documents, models, etc., comprising product portfolios, requirements, project plans, architecture, design models and, of course, software components.

Introduction

One of the reasons for using variability in the software product line (SPL) approach (see Apel et al., 2006; Figueiredo et al., 2008; Kastner et al., 2007; Mezini & Ostermann, 2004) is to delay a design decision (Svahnberg et al., 2005). Instead of deciding on what system to develop in advance, with the SPL approach a set of components and a reference architecture are specified and implemented (during domain engineering, see Czarnecki & Eisenecker, 2000) out of which individual systems are composed at a later stage (during application engineering, see Czarnecki & Eisenecker, 2000). By postponing the design decisions in such a manner, it is possible to better fit the resultant system in its intended environment, for instance, to allow selection of the system interaction mode to be made after the customers have purchased particular hardware, such as a PDA vs. a laptop. Such variability is expressed through variation points which are locations in a software-based system where choices are available for defining a specific instance of a system (Svahnberg et al., 2005). Until recently it had sufficed to postpone committing to a specific system instance till before the system runtime. However, in the recent years the use and expectations of software systems in human society has undergone significant changes.

Today's software systems need to be always available, highly interactive, and able to continuously adapt according to the varying environment conditions, user characteristics and characteristics of other systems that interact with them. Such systems, called adaptive systems, are expected to be long-lived and able to undertake adaptations with little or no human intervention (Cheng et al., 2009). Therefore, the variability now needs to be present also at system runtime, which leads to the emergence of a new type of system: adaptive systems with dynamic variability.

Introduction

Empirical evaluation has for many years been utilised to validate theories in other science disciplines. One of the first well-known reported examples of empirical evaluation occurred when Galileo wanted to prove that the rate of descent of objects was independent of their mass. This would disprove a theory put forward by Aristotle that the rate of descent is directly proportional to their weight. To prove his theory Galileo dropped two balls made from the same material but different masses from the top of the Tower of Pisa. When the experiment was performed Galileo's theory was proved correct through the empirical evidence collected. What this story demonstrates is the importance of empirical validation to verify or disprove theories and hypotheses. The purpose of this chapter is to emphasise the importance and difficulties of empirical evaluation in the domain of SPLE.

In addition to physics, experimentation plays a vital role in other disciplines. For example, medicine as a discipline did not really exist before experimentation was applied to this area (Basili, 1996). Instead, remedies and cures to illnesses were passed around based on hearsay, or from generation to generation. When experimentation was applied to medicine real progress was observed, with extra resources diverted to areas showing promise. Applying experimentation can speed up the progress of a discipline by quickly eliminating futile approaches and incorrect theories. Furthermore, experimentation can potentially open up new areas of research by uncovering unexpected results.

Introduction

In software development, we have to make choices and take decisions, and these depend on obtaining answers for critical questions, such as the following:

• How should an important decision be made when conflicting strategic goals and stakeholders’ desires or quality attributes must be considered?

• How can stakeholders be assured that the decision has been made in a sound, rational and fair process that withstands the rigour of an aspect-oriented analysis and design, or a software product line, for example?

In software product line (SPL) development, the answers to these questions are critical, because they require dealing with modelling and implementation of common and variable requirements that can be composed and interact in different ways. Furthermore, they also require decisions that can impact several products at the same time. For example, we may simply want to know which requirements are in conflict and which features are negatively affected – considering different configurations of the software product lines – to choose the best architecture to design and implement the product line and to be able to decide which mandatory or optional features should have implementation priority. Therefore, help is required to support software engineers in making better, informed decisions, by offering them a systematic process for ranking a set of alternatives based on a set of criteria. In requirements engineering, for instance, it is useful to identify conflicting requirements with respect to which negotiations must be carried out and to which trade-offs need to be established (Rashid et al., 2003). A concrete typical use is to offer a ranking of non-functional requirements (NFRs) based on stakeholders’ wishes. This helps to establish early trade-offs between requirements, hence providing support for negotiation and subsequent decision-making among stakeholders. As discussed in Moreira et al. (2005a), having performed a trade-off analysis on the requirements, we are better informed with respect to each important quality attribute the system should satisfy, before making any architectural choices.

Requirements engineering in software product line engineering

Software product line engineering (SPLE) (Clements & Northrop, 2001) has been recognised as one of the foremost techniques for developing reusable and maintainable software within system families (Parnas, 2001a, 2001b). We focus on a feature-oriented form of SPLE, in which the key concern is to break the problem domain down into features, which are system properties, or functionalities, which are relevant to some stakeholders.

Domain and application engineering

Feature-oriented SPLE can be usefully broken down into two core activities: domain engineering and application engineering. The key task of domain engineering is to model the domain itself in order to lay the foundation for deriving individual products, which is the remit of application engineering. The work presented in this chapter belongs to the realm of domain engineering; we seek to aid the requirements engineer in analysing, understanding and modelling the domain by providing a framework for the automated construction of feature models from natural language requirements documents.