139,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Many approaches to creating Software Product Lines have emerged that are based on Model-Driven Engineering. This book introduces both Software Product Lines and Model-Driven Engineering, which have separate success stories in industry, and focuses on the practical combination of them. It describes the challenges and benefits of merging these two software development trends and provides the reader with a novel approach and practical mechanisms to improve software development productivity.
The book is aimed at engineers and students who wish to understand and apply software product lines and model-driven engineering in their activities today. The concepts and methods are illustrated with two product line examples: the classic smart-home systems and a collection manager information system.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 325
Veröffentlichungsjahr: 2013
Ähnliche
Table of Contents
Chapter 1. Introduction
1.1. Software product line engineering
1.2. Model-driven engineering
1.3. Merging model-driven and software product line engineering
1.4. The FieSta framework
1.5. Book structure
Chapter 2. Software Product Line Engineering Basics
2.1. Introduction to product line engineering
2.2. Brief history
2.3. Application example: Smart-Home systems
2.4. Software product line engineering
2.5. Domain engineering
2.6. Variability management
2.7. Application engineering
2.8. Benefits and drawbacks
2.9. Issues in product line
2.10. Summary
Chapter 3. Model-Driven Engineering
3.1. Introduction
3.2. Models and metamodels
3.3. UML class diagrams and OCL
3.4. Model transformations
3.5. Modeling framework
3.6. Model transformation languages
3.7. Benefits and challenges for SPLE
3.8. Summary
Chapter 4. Model-Driven and Software Product Line Engineering
4.1. Introduction
4.2. Problem space issues
4.3. Solution space issues
4.4. Developing core assets
4.5. Variability expression and product configuration
4.6. Core asset development and product derivation
4.7. Summary
Chapter 5. The FieSta Framework: Fine-Grained Derivation and Configuration
5.1. Introduction
5.2. Binding models and constraint models
5.3.Deriving products based on constraint models and binding models
5.4. Identified limitations
5.5. Summary
Chapter 6. Tools Support
6.1. Introduction
6.2. The FieSta process
6.3. The SPL of Smart-Home systems
6.4. Variability expression and product configuration
6.5. Completing and running the product derivation
6.6. Summary
Chapter 7. A Second Comprehensive Application Example
7.1. Domain of the collection manager system
7.2. Requirements of the application example
7.3. The overall process
7.4. Variability expression and product configuration
7.5. Core assets development and product derivation
7.6. Summary
Chapter 8. Further Reading
8.1. Northop and Clements’ book
8.2. Pohl, Böckle and Van der Linden’s book
8.3. Gomaa’s book
8.4. Van der Linden, Schmid, and Rommes’ book
8.5. Stahl, Voelter, and Czarnecki book
8.6. AMPLE book
8.7. Feature modeling notations
8.8. Decision models
8.9. Model-driven software product lines
8.10. Dynamic variability
8.11. Domain specific languages
8.12. Additional references
8.13. Summary
Chapter 9. Conclusion
9.1. Book summary
9.2. MD-SPL engineering
Bibliography
Index
First published 2012 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:
ISTE Ltd27-37 St George’s RoadLondon SW19 4EUUK
John Wiley & Sons, Inc.111 River StreetHoboken, NJ 07030USA
www.iste.co.uk
www.wiley.com
© ISTE Ltd 2012
The rights of Hugo Arboleda and Jean-Claude Royer to be identified as the author of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.
Library of Congress Cataloging-in-Publication Data
Arboleda, Hugo.
Model-driven and software product line engineering / Hugo Arboleda, Jean-Claude Royer.
pages cm
Includes bibliographical references and index.
ISBN 978-1-84821-427-9
1. Software product line engineering. 2. Model-driven software architecture. I. Royer, Jean-Claude. II. Title.
QA76.76.D47A7323 2012
005.1--dc23
2012028382
British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library
ISBN: 978-1-84821-427-9
Chapter 1
Introduction
For more than 10 years, two independent approaches in software engineering have been emerging: software product line engineering (SPLE) and model-driven engineering (MDE). Software product line engineering is a software process, which puts emphasis on “re-use” organized through a common software architecture [GOM 04]. This process relies on a domain analysis and scoping activity to characterize the products to be delivered. The realization of a concrete application is based on a production plan, and the configuration of the application of the engineering step. Model-driven engineering emphasizes the creation of models that represent the system under consideration at a high level of abstraction. These models are the base on which to implement the application automatically. These two approaches have in common the following concerns: improving productivity, increasing the quality of software and automating, as much as possible, the construction of software assets. They are also complementary: model-driven engineering seems a promising trend to automate the production chain needed for product creation in product lines. It also seems suited for modeling the various concerns and artifacts of a product line. In software engineering, traceability is the ability to track the information flow of software artifacts. Traceability is also a crucial issue in product line engineering. MDE can help in managing artifacts and tracing links.
The main focus of this book is to propose a practical approach to engineering a software product line based on MDE. This book presents the basic concepts of both engineering approaches and the main challenges in defining a modeldriven tool. The book is concerned with the technical aspects of modeling variability, defining a reference architecture, and constructing tool support. This book can be useful for graduate students as well as software engineers who wish to learn about product lines and concepts of model-driven engineering. Two application examples illustrate the concepts and the processes: a product line of Smart-Homes and a product line of Collection Managers. It is also appropriate for researchers in the area of MDE and SPLE since it addresses some complex issues such as fine-grained configuration and fine-grained variation.
1.1. Software product line engineering
Software engineering aims at speeding up software development and maintenance processes, decreasing costs, and improving productivity and quality. By addressing these objectives, software product line engineering seeks to develop software products through the re-use of artifacts. Thus, the products should be quickly developed, and their quality should be as good as the quality of the artifacts used for their construction. A software product line (SPL) is defined as a set of similar products created from re-usable artifacts in the context of a specific application domain. In SPLE, product designers configure and derive products by re-using the available artifacts created by the product line architects. The description of the set of products that are part of an SPL is called the scope of the product line. To capture and express the scope of SPLs, product line architects first determine the commonalities, i.e. the characteristics shared by all products in the scope, and then they study their variability. The architects build a feature model or, more generally, a variability model. This model is a structured set of variation points associated with their variants, which can be either requirements, code, architectures, testing plans, or any other elements of a full software development process. Variation points are relevant characteristics that can have different values, the so-called “variants”, according to the variability of a product line. The set of re-usable artifacts occurring in the products defines the product line platform. In this book, it shall be referred to as the core asset.
The development of the product and core asset are fairly complex processes, often presented with two phases: domain engineering and application engineering. The former process analyzes the domain, the commonalities, and the variability; it elaborates a production plan for the product line development and generates the assets to be re-used. The latter process is in charge of building each product from its characteristics, the core assets and the plan defined during the first phase. This second phase can be a complete software lifecycle: the most important activities are the product configuration and the product derivation. The product configuration is a representation of the product to be built expressed in terms of the variability model. It is from such configuration, core assets, and production plan that the effective product can be generated.
1.2. Model-driven engineering
Model-driven engineering refers to a range of development approaches based on the use of software modeling as primary documents. These documents comprise requirements or other artifacts such as feature models, use cases, Unified Modeling Language (UML) diagrams, and architectures, among others. Code is written by hand or generated in part or in whole from the models. Whenever possible, code generation ranges from system “stubs” or “skeletons” to deployable products. Several steps are required to iteratively integrate various concerns and to transform models until the source code is obtained. Models are less sensitive to computing technology and to evolutionary changes of that technology. We can have general models describing the problem space and deriving other distinct models representing some solutions. Platformspecific aspects, such as the characteristics of languages, can be integrated in subsequent steps and then performance issues or deployment aspects can be further added. In this way, abstraction and separation of concerns can be used in a uniform and tool-assisted process. The need for such facilities is increasing as the semantic gap between modeling languages and implementation codes becomes wider-and-wider.
MDE originated in the late 1990s out of the need for more abstract software description, and to increase software productivity and quality. It emerged from the adoption of UML as a standard and from research on data representation, CASE tools, and interchange format. MDE emphasizes such concerns as abstraction, early verification, model transformation, and automatic code generation. MDE provides a unified formalism with models and transformations to represent artifacts and processes of software engineering. The ability to build readable models is important for stakeholders to collaborate efficiently. Models only capture single points of view and focus on some domain concepts that are known to be easier to specify, understand, and maintain.
Software engineering needs automation. This is a fact learned from the history of engineering. Automation is by far the most effective technological means for boosting productivity and reliability. MDE provides automation at every step of development and facilitates a progressive integration of knowledge and platform details. The techniques and tools for using MDE successfully have now reached a degree of maturity that renders them practical even in large-scale industrial applications.
MDE appears as a promising technique for SPLE since it provides uniformity and abstraction for software artifacts and processes. SPLE is a paradigm that focuses on artifact re-use and variability management. It introduces a complex software process and artifacts that are more numerous, heterogeneous, and complex than in traditional software engineering. MDE can help in representing the artifacts in a uniform and abstract way. SPLE also requires some specific tasks such as product configuration and should place more emphasis on traceability management. MDE has the ability to build complex transformations, which is promising in the automation of domain and application engineering.
1.3. Merging model-driven and software product line engineering
SPLE and MDE have common concerns: improving productivity, making software development cost-effective, empowering domain experts in software development, enforcing architecture, capturing domain and technological knowledge in separate artifacts, increasing software quality, and automating the construction of software products as much as possible. They are also complementary. Model-driven engineering seems a promising trend in automating the production chain needed for the creation of product lines. It is also suited to model the various concerns and artifacts of a product line. SPLE proposes a global view and process for product line engineering with a strong focus on the rational re-use of artifacts.
Many approaches to create SPLs based on MDE have emerged e.g. [VÖL 07b, WAG 05]. These are called MDE-based SPL approaches or MD-SPL approaches. MDE conceives the whole software development cycle as a process of creation, iterative refinement, and the integration of models. We define an MD-SPL as a set of products developed from application domain models, and derived from a set of re-usable model transformation rules. There is a general agreement on the fact that model transformations may require several stages, e.g. [VÖL 07b, ARB 09b, ARB 09a]. At each stage, application domain models are automatically transformed to include more implementation details. Models with only problem space concerns are incrementally transformed to include the solution space, i.e. concerns of software design and/or technological platforms, as well as performance issues. At the end of a staged model transformation process, models including all the implementation details are transformed into source code of software systems.
Most of the current MD-SPL approaches [VÖL 07b, WAG 05, LOU 08, SAN 08] create application domain metamodels and variability models to capture and express variability separately. For configuring a particular product, the product designers create configurations that consist of (1) application domain models and (2) instances of variability models. An instance of a variability model includes a selection of variants from the variability model. The MD-SPL approaches using multi-staged model transformations also facilitate the configuration of products by creating specific instances of variability models. For example, product designers can select software architectural details before executing model transformations in charge of adding architectural information. Therefore, the staged transformation of an application domain model may derive products with different software architectures or products to run on different technological platforms.
During the product derivation process, the instances of variability models are used to decide what transformation rules must apply. Thus, from different instances of variability models, different products can be derived from the same application domain model.
Figure 1.1 sketches the process of creating an MD-SPL example. Each product line member manages its data by means of a relational database schema. In this example, product line architects have chosen to use the UML Class Metamodel to capture and express the variability related to problem space concerns. Thus, product designers are able to start the configuration process of products by creating diverse class models. To capture variability in the context of relational database schemas, product line architects create a variability model that includes one variation point, a Primary Key Structure with two alternative variants: With Primary Key and Without Primary Key. Additionally, the architects relate a different model transformation rule to each variant. Rule One is related to the variant With Primary Key
Figure 1.1.Example of a MD-SPL creation process
and Rule Two is related to the variant Without Primary Key. Product designers complete the configuration process of products by creating instances of the variability model. If the variant With Primary Key is selected in an instance of the variability model, using Rule One, all the class elements in a Source Class Model are transformed into table elements with one primary key. If the variant Without Primary Key is selected in another instance of the variability model, using Rule Two, all the class elements in a Source Class Model are transformed into table elements without a primary key.
1.4. The FieSta framework
This book covers most of the creation lifecycle of MDSPL. The activities have been organized in a framework that incorporates the principles of MD and SPL engineering. We have named this framework FieSta for fine-grained scope definition, configuration, and derivation of model-driven and software product lines. FieSta focuses on two major processes. Firstly, the process of capturing and expressing variability in MD-SPL, which impacts, consequently, on the process of configuring product line members. Secondly, the process of deriving products by re-using and composing model transformations based on product configurations.
FieSta provides model-based mechanisms to extend the expressive power of variability involved in current MD-SPL approaches in such a way that more detailed products can be configured according to the fine-grained variability principle. FieSta includes a mechanism that allows product designers to create fine-grained configurations that represent valid products. We define a valid product as an assembly that meets the requirements that product designers specify by means of configurations. FieSta also includes a mechanism to control the valid fine-grained variations. FieSta resolves problems in application domains where (1) model elements must be configured individually and (2) products must be configured in multiple stages, sometimes by designers with different domain knowledge.
During the process of product derivation, model transformation rules must be composed to derive products from their configuration. The composition is done according to each configuration. FieSta maintains uncoupled the information of relationships between variants and their related transformation rules. This facilitates the maintenance, re-use, and evolution of transformation rules and/or variability models. Additionally, FieSta proposes a high-level mechanism to compose model transformation rules and to adapt their execution ordering (or execution scheduling) to create finegrained configurations and derive products based on them.
FieSta (1) provides mechanisms to extend the power of variability of MD-SPL by using metamodeling and feature modeling conjointly, and (2) integrates a product derivation process, which uses the decision model and Aspect-Oriented Programming (AOP) facilitating the re-use, adaptation, and composition of model transformation rules. Figure 1.2 presents an activity diagram summarizing the processes involved in FieSta.
During the domain-engineering process, product line architects create model transformations consisting of sets of transformation rules. Each transformation rule is responsible for producing a part of a final product. Model transformation rules implement algorithms to transform application domain models into refined models (or source code) including concerns from a different level of abstraction. Product line architects also create decision models. Decision models are the basis of our mechanism to derive products including variability. They capture the execution ordering of transformation rules to be performed by the model transformation engine to derive configured products. We use AOP to build the scheduling of the transformation rules, i.e. the order in which transformation
Figure 1.2.The FieSta general process
rules are going to process model elements to accomplish the required derivation.
During the domain engineering process, product line architects create application domain metamodels, feature models, and constraint models to capture the variability and commonalities of MD-SPL. We introduce constraint models that make it possible for product line architects to capture and express the valid fine-grained variations among product line members using the concepts of constraint, cardinality property, and structural dependency property.
To configure a product during the application engineering process, product designers create (1) application domain models that conform to application domain metamodels and (2) binding models, which are sets of bindings between model elements and features. After a binding model is created, it is validated against a set of object constraint language (OCL) statements derived from its respective constraint model.
To derive a complete product according to a binding model, we dynamically adapt the parameters of model transformation executions, which we achieve by using model transformation rules that are selected from the binding model and the precreated decision models.
Along with FieSta, we present model-based tool support, the FieSta toolkit, which implements facilities to (1) capture finegrained variations between product line members, (2) configure detailed products, and (3) derive fine-grained configured products. We illustrate the FieSta approach through two application examples: a product line of Smart-Homes and a product line of Collection Managers.
1.5. Book structure
Figure 1.3 presents the structure of this book, which is organized in four parts: an introduction, a presentation of the state-of-the-art, our proposal (the FieSta framework), and the conclusions.
Figure 1.3.Structure of the document
Following this chapter, the reader shall find a chapter on software product line engineering, a chapter on model-driven engineering, and a chapter considering the state-of-the-art in model driven and software product line engineering. These chapters provide the foundation for our framework. Part three discusses the FieSta approach. It includes one chapter on the principles of FieSta for fine-grained variation, configuration, and derivation. Following this discussion, we describe the tools for supporting the MD-SPL engineering mechanisms we previously introduced. The concepts and tools are illustrated on a Smart-Home case study. Chapter 7 is devoted to a second application example. The final part is composed of two chapters; the first one presents further readings and the second concludes this book, including a discussion and an outlook for future work.
Chapter 2: Software product line engineering basics. This chapter introduces software product line (SPL) engineering. The major stages in SPL development are discussed: (1) the domain engineering process and (2) the application engineering process. Feature modeling is introduced as a mechanism for expressing product line variability and for configuring products. Decision models are included as artifacts used to relate re-usable core assets and variants from product lines, and support the product derivation process based on product configurations.
Chapter 3: Using model-driven engineering. This chapter introduces the main concepts of MDE: models, metamodels, and model transformations. Regarding models, we introduce some definitions and we explain the concept of separation of concerns of a system in different models. We also discuss the concept of level of abstraction of models, and we classify the levels of abstraction as a particular case of separation of concerns. We explain the general concepts of metamodeling: domain specific modeling (DSM), the relation of conformity, and the four-layer metamodeling framework. We summarize UML and OCL notations to help readers understand the models presented in this book. We also introduce the eclipse modeling framework (EMF), which is a metamodeling and modeling framework. Finally, we define the concept of model transformations and we classify them into four major categories: model-to-model, model-to-text, horizontal, and vertical transformations. We introduce the Xpand and the Xtend model transformation languages, which are languages included in the OAW framework.
Chapter 4: Model-driven and software product line engineering. We give an overall view of the process, the challenges of merging these two engineering approaches, and the impact in the problem and solution dimensions. We discuss in depth the variability expression, the multi-stage process, the core asset development, the product configuration, and the product derivation process.
Chapter 5: The FieSta framework. The previous chapters present the background for this chapter in which FieSta, our approach to create SPL based on MDE, is introduced. This chapter makes use of the application example introduced throughout the previous chapters to illustrate the different axes of our framework. Constraint models, which are re-usable artifacts we build to capture the scope of MD-SPLs, are presented and their use is illustrated within the context of the Smart-Home example. Binding models, which serve to configure products and are sets of bindings between model elements and features that satisfy the constraint models, are explained and also illustrated with our application example. We then show how to derive products based on the binding models and the decision models, which are sets of aspects we use to adapt model transformations required to derive configured products. Finally, we present the limitations of FieSta for deriving products based on decision models.
Chapter 6: Tools support. This chapter validates FieSta, our MD-SPL approach, by presenting examples of products that we are able to derive using our MD-SPL mechanisms. It presents the results of configuring and deriving products of the Smart- Home product line. The implementation strategy of FieSta is sketched. It defines the general process for the implementation of our MD-SPL engineering mechanisms for creating product lines. The implementation strategy includes (1) the required activities for the creation of products, and (2) the tools we create to support these activities. The tool support for expressing variability and configuring products, as well as the tool support for deriving configured products are described.
Chapter 7: A Second comprehensive application example. In addition to our Smart-Home systems’ MD-SPL, we have also created a product line of stand-alone applications to manage data collections. We call a member of this product line a collection manager system. For example, a collection manager system manages the students of a school and their personal information: name, address, e-mail, etc. Another product manages records in a music store and their related information: name, artist, price, etc. At the architecture level, products are structured in two tiers: the kernel and the Graphical User Interface (GUI). The kernel tier implements functional requirements to add elements into the collection and to order the collection. The GUI tier implements visualization and interaction with the final users and the kernel component.
Chapter 8: Further reading. The purpose of this chapter is to provide the main references related to product line engineering and to discuss some open or more advanced issues. This chapter reviews some of the previous books related to product lines and to model-driven approaches. For historical and pedagogical reasons, we comment on Northrop’s and Pohl’s books. Gomaa’s book promotes a rather UML-like approach for SPLE, while the book is aligned with new technologies such as MDE and AOP. The book from van der Linden et al. addresses a survey of product line practices as well as various application examples, being a valuable reference for practitioners who want to launch a product line. A section of this chapter is dedicated to featuring modeling notations, which are of prime importance in SPLE. The problem of mixing product line engineering and model-driven engineering has been already addressed in several works. A specific section is devoted to these approaches, a detailed discussion, and a comparison table are presented. An advanced topic, not yet discussed in the current book, is the management of dynamic information in such an engineering process. Domain Specific Languages (DSL) are nowadays, techniques which are completely relevant in our context. We present some facts concerning the relations between DSL and model-driven engineering. A final section collects several important references to provide readers with a more comprehensive view of this domain.
Chapter 9: Conclusion. This chapter concludes this book presenting (1) a summary of our framework, (2) a reflection taking into account the contributions we propose to the field of model-driven software product line engineering, and (3) future outlooks for research.
Chapter 2
Software Product Line Engineering Basics
Software product line engineering is a recent trend in software development. It can bring benefits in terms of costs and productivity; however, it also involves a complex software development process. This chapter introduces the basics for product line engineering and addresses the main technical aspects. The management of product line engineering processes is an important issue; however, it is not dealt within this book. Interested readers can refer to [NOR 02, POH 05a, CAC 06].
2.1. Introduction to product line engineering
Software systems are complex and their development is time-consuming and error-prone. Many software companies are building applications that share more commonalities than differences. They often repeatedly add new features and build new variants or releases of their applications. Most often, software development consists of creating variations from existing software. The strategy of re-using software artifacts has been seen as a means to alleviate the problems associated with software development. Re-using software artifacts facilitates the composition of products from a set of artifacts already developed and tested, instead of building the products from scratch. Software product line engineering is a paradigm that provides a means to incorporate the re-use strategy as a central part of software development [CLE 01, BOS 02]. A software product line (SPL) is a set of software products that share many common properties to be built from a common set of assets [CZA 00]. The ultimate objective of product line engineering is to improve productivity, i.e. save time, reduce costs, and increase the quality of products. In this chapter, we first introduce the basis of SPL engineering (SPLE), including the main processes involved in the creation of SPLs: domain engineering process, section 2.5, and application engineering process, section 2.7. These two processes are also often called “development for re-use” and “development with re-use”, placing strong emphasis on re-usability.
The principle of SPLE is to develop several products sharing some common concerns in a development cycle.
DEFINITION 2.1. – A software product line is a set of software applications that shares concerns, features, requirements, or market specificity and that are built in a rational and planned way from a set of re-usable assets.
Mainly used in Europe, the term product family can be considered as a synonym. The term software factory is a related and older concept, but it is not equivalent and covers various meanings. It was used earlier to denote product lines and it is still used, specifically in the Microsoft context. Often, a software factory denotes a new generation framework trying to automate the application engineering as much as possible. This concept emerges from model-driven engineering and some new generative approaches making the definition of complex and automated tool chains possible. A software factory can be a part of an SPL, namely in the latest generation where application engineering is strongly automated. However, product line is a broader concept that includes variability management and domain analysis, which are not considered in a software factory.
The first thing to note about SPLE is that the development cycle produces several products or applications, while most of the traditional development cycles focus on one application at a time. The second point is that the products share some concerns; usually, one can say that they belong to the same domain. For instance, we can have several configurations for Smart-Home that are more or less secure, autonomous, interconnected with the Web and so on. The common parts define what is called the commonalities. All Smart-Homes should have at least rooms, doors, windows, and a heating system. However, these products are different, thus, they have some specific parts. The set of these differences is called the variability. For instance, we can define a basic home with a security system, another one with automatic windows, and a third one with both features. One important task in SPLE is to define precisely the domain of interest, to express the commonalities and the variability of the products, and to structure this information.
A simple and abstract view of the main processes involved in SPLE is depicted in Figure 2.1. It involves three interacting and iterative processes. The management process is under the control of the business plan which decides the production of applications. It acts as a supervisor for the two other processes. It looks at the quality of the core assets and the final products. The core assets development is responsible for developing individual elements (e.g. requirements, codes, tests, documentations) and to make them re-usable. It also defines the product line scope and elaborates a production plan. The former describes the set of products while the latter shows how to build the products. The products development is responsible for the building of products following the production plan. It starts from a configuration of the product, which is a description of its included features, and it then builds the expected product application using the core assets but also suggesting new assets if needed. These three processes are orchestrated by the management process but they are all strongly interacting.
Figure 2.1.The three processes view
Here, we concentrate on technical engineering activities rather than on project management. Effective technical engineering is presented in two phases: domain engineering and application engineering. The first engineering step analyzes the domain, the commonalities, and the variability. It elaborates a global and common production plan and generates the assets to be re-used. The second engineering step is responsible for building one product from its characteristics, the core assets, and the plan defined during the first step. The plan can be an informal document describing how to build the products. The future trend in SPLE is to automate the production plan, and one successful technique is to use MDE to define an executable tool chain. These steps will be described in more detail in the rest of the book. Another point to bear in mind is the difference between the problem space and the solution space traditionally used in software engineering. The problem space is the set of requirements, the need for some applications, regardless of the precise structure and shape of this information. Its goal is to describe the functionality of the system, but often non-functional requirements are also added, such as performance or even marketing requirements. The solution space is concerned with the description of one solution to the problem using various notations ranging from message sequences, architecture, class diagrams, or source codes. The interplay between the two engineering steps, problem and solution space, and core assets is depicted in Figure 2.2. In this picture, we simplify the development process during engineering when all the steps of a classic lifecycle are relevant. Thus, we should add tests, maintenance, documentation, versioning, etc.
In this diagram, the core assets form a central repository to store and mine assets. These assets can be produced by all the steps; they are referenced in the production plan and effectively used in application engineering to build products.
Figure 2.2.Domain and application engineering
2.2. Brief history
The notion of the product line is rather old;Wikipedia argues that the oldest assembly line is “The Terracotta Army” around the year 215 BC before Christian era. (http://en.wikipedia.org/wiki/Assembly_line#Overview:_a_culmination_of_many_efforts). The most famous and more recent assembly line was introduced by the car manufacturer H. Ford around 1913 as the result of the efforts of several engineers over seven years. The assembly line decreased car production costs mainly by reducing the assembly time. It paved the way for mass production but also influenced the industry considerably. The history of software product lines started 30 years ago. There are some differences between classic manufactured products and software systems. For instance, making an exact copy of a type of software is easy and there are often many possible variations. Software engineering is not the straight application of industry engineering to software. This engineering is still exploring new approaches and product lines are a normal evolution of software engineering. The advent of SPLE is comparatively recent and the first Software Product Line Conference, organized by the Software Engineering Institute, was held in 2000. [SUG 06] introduces a special issue of CACM dedicated to software product lines.
This history has three foundations: Artifact re-use, program families, and domain analysis. The paper from Mc Ilroy [McI 68] is the main source for re-usability and software component concepts. The idea was to build software applications like hardware systems, by assembling pre-defined components. Parnas [PAR 76] introduced the notion of program families in the middle of the 1970s. It can be viewed as a forerunner of the software product family concept but dealing only with the design step. The notion of domain analysis was introduced in the middle of the 1980s by Neighbors [NEI 89]. He introduced the Draco approach to the construction of software systems from re-usable components. “The basic idea captures the frustrating feeling that most of the system you are currently building is the same as the last few systems you have built; but once again you are building everything from scratch”. This work exposes the three major stakeholders in domain analysis: the application domain analyst, the modeling domain analyst, and the domain designer.
The first industrial project was the Toshiba Software Factory in 1977; it concerns the development of a family of power generators. One useful reference about the activity in this domain is the SEI site (http://www.sei.cmu.edu/productlines/), which contains information about case studies, tools, and methods as well as a catalog of software product line projects. Northrop, in [NOR 02], was the first author to propose a comprehensive view of SPLE with all the related technical and organizational activities. The SEI group was also at the origin of the patterns for categorizing SPL practices. At the beginning of 1980s, the European community sponsored several important projects in this domain such as ESAPS, CAFE, FAMILIES and more recently AMPLE (www.ampleprojet.net). Another sign of the activity in this domain was the launching of conferences: the two main ones are Software Product Line and Product Family Engineering conferences that were merged in 2005. More details on these past events can be found on the SPLC website (http://www.splc.net/history.html).
The SPL success story of product line engineering includes HP printers, Nokia smart phones, and many others. HP developed a line of firmware for a number of printers and multifunction (printer/copier/scanner/fax) devices. These products have been created with a quarter of the team, in a third of the time, and with 1/25th the number of bugs in earlier products. Nokia Mobile Phones produces a wide range of mobile phones, more than 30 models, with a wide variety of functional features, different user interfaces, and using several platforms. Nokia is a leader in mobile phone manufacture, and software product line engineering has helped them reach that position. MARKET MAKER provides software in Europe for the stock market. The company decided to plan the Internet versions as a software product line. Due to its systematic product line approach, the company was able to set up products in a few days. The time to market is 2-4 days and after five products, there is a reduction of 60% in maintenance costs. More details can be found in the hall of fame (http://www.splc.net/fame.html) on the SPLC website.
2.3. Application example: Smart-Home systems
To better explain the basis of MDE and SPLE, and to demonstrate the feasibility and economies of our approach, we consider two examples from two different domains. In this chapter, we introduce the first one. This is a home automation system, which is rather a classic application of product lines. The second one is introduced and developed in Chapter 7. It has more characteristics of information system applications where we need to manage, present, and store several pieces of information of a business domain.
The Smart-Home illustrative example is taken from the domain of home automation. “A smart home is a building for living equipped with a set of electrical and electronic sensors and actuators in order to allow for an intelligent sensing and controlling of the building’s devices: windows, heaters, lights, etc.” [ELS 08]. This application example was also exploited in several other projects, for instance in the AMPLE project [RAS 11] and in Pohl’s book [POH 05b].
2.3.1. Smart-Home system’s domain
Smart-Homes are equipped with a wide range of electronic and electrical devices, such as light arrays, temperature sensors, thermostats, electrically steered blinds and windows, door sensors, door openers, etc. A Smart-Home software system coordinates and controls such devices enabling inhabitants to manage them from a common user interface. A Smart-Home system offers high-level functionality where several sensors and actuators work together. The sensors are physical devices that measure values of the environment and make them available to the Smart-Home system. The actuators activate the devices whose state can be monitored and changed. All installed devices, including sensors and actuators, are a part of the Smart-Home network. The status of devices can be changed by inhabitants through the user interface, remotely by using an Internet connection or by the system using predefined policies. These policies let the system act autonomously in case of certain events. For example, in case of low indoor temperature, the windows close automatically; in case of fire, the fire brigade is automatically called, and so on.
The architectural structure of buildings (e.g. the number of floors, rooms, or windows), the sensors and actuators as well as other devices, their location inside the buildings, and the policies, are specific for each Smart-Home system and must be defined by the designers of the Smart-Home systems. Thus, Smart-Home systems can be created with the necessary software components to respond to the particular requirements of each Smart-Home owner. At runtime, the Smart-Home system is then ready to respond to external or internal stimuli depending on the defined structure of the building, its devices, and the chosen policies.
In our example, Smart-Home systems must provide the following functions:
– Climate control system. Climate control devices must be orchestrated to keep the preferred temperature in the rooms of the house.
– Security system
