Model-Driven and Software Product Line Engineering

Jean-Claude Royer, Hugo Arboleda

• Publisher: Wiley-ISTE
• Year: 2013
• ISBN:
  9781118569733
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

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.

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 m...

Table of contents

• Cover
• Title Page
• Copyright
• Chapter 1. Introduction
• Chapter 2. Software Product Line Engineering Basics
• Chapter 3. Model-Driven Engineering
• Chapter 4. Model-Driven and Software Product Line Engineering
• Chapter 5. The FieSta Framework: Fine-Grained Derivation and Configuration
• Chapter 6. Tools Support
• Chapter 7. A Second Comprehensive Application Example
• Chapter 8. Further Reading
• Chapter 9. Conclusion
• Bibliography
• Index