AMW Use Case - Variability Management in a Model-Driven Software Product Line

AMW Logo

This use case illustrates an approach to manage variability during the SPLs construction process, using a MD-SPL approach. The approach was developed by the Software Construction Group of The University of Los Andes (Colombia).

Overview

Software industry have been evolving from hand-craft process to semi-automatic process to improve productivity and quality. An approach to achieve this goal is the reuse. Software Product Line (SPL) is an approach to develop software products by reusing sets of components called core assets. On the other hand, Model Driven Architecture (MDA) [1] is an approach of generative reusability. Results of recent investigations have shown how the mixture of MDA and SPLs (MD-SPL) is an approach that makes possible the definition of a SPLs creation process [2, 3]. In [4], we present a proposal to manage variability during the SPLs construction process, using a MD-SPL approach. For this, we separated the concepts related to a product line in different domains: (1) the business logic domain, (2) the architecture domain, and (3) the technological platform domain. We created metamodels, feature models, weaving models, and transformation rules as core assets. This scheme enables us to transform one initial source model into different (variable) target models for obtaining variable SPL members. In order to generate variable target models, we created three types of transformation rules: (1) base rules, (2) control rules, and (3) specific rules. We exemplify this proposal with a SPL for the Cupi2 project [5]. For the construction process we used GMF [6] like modelling environment, AMW [7] to make weaving models, ATL [8] to transform model-to-model and Acceleo [9] to transform model-to-code. This use case illustrates our proposal. First, we introduce an application context. Later, we summarizes our approach to manage variability using MD-SPL.

Application context

We created a SPL for the Cupi2 project [5]. Cupi2 is part of a series of efforts from the Software Construction Group of The University of Los Andes (Colombia) to find new ways to teach/learn computer programming. In Cupi2, complete examples and exercises are used to illustrate different topics. Each example/exercise includes a graphical interface, a set of requirements, a set of unit tests, java code, and documentation. There are 18 levels in total. Each level adds new concepts to the previous ones. We build a SPL which generates examples for level 7. In this level, among other topics, we deal with ordering and searching algorithms in collections. Cupi2 examples share commonality and variability. All Cupi2 examples are stand-alone applications without complex non-functional requirements; they are developed using the same technological platform, in this case Java. All the examples are structured by two components: the kernel and the user interface. The kernel component implements the concepts of business logic. The user interface component implements information visualization and interaction between users and kernel components. Structures of aggregation can represent the kernel concepts and their relationships. In an aggregation structure, there is always a main element that groups the other elements of the kernel. For example, in the Music Store application, a MusicStore assembles a set of Discs and each Disc assembles a set of Songs. To build a graphical user interface (GUI), Cupi2 applications employ a set of elements like panels, lists, labels, images, and radio buttons, among others. The GUI elements can be grouped in views of different types (main view, extension view, set view, search view, information view, and aggregation view). In Figure 1, we present a possible GUI configuration with four different types of views.



Figure 1. Cupi2 example GUI

The Variability Management Approach

Now we present briefly our approach using the application context. We separate concepts related to a SPL in domains to manage variability. These domains are the business logic, the architecture domain, and the technological platform domain. Our strategy follows the MDA approach and it is based on the automatic transformation of models until obtaining executable applications. We start from a business logic model, we transform it into an architectural model, after that we transform it into a technological platform model and finally we generate source code from it. Before each transformation is done, the user selects the features that he wants. To achieve this, we build (1) metamodels for each domain, (2) feature models for each target domain, (3) weaving models and transformations.

Metamodels

We define three different metamodels as core assets for Cupi2 applications: business logic, architecture, and technological platform metamodel. Business logic metamodel includes the essential concepts of the problem; architecture metamodel the concepts related to the graphic user interface; finally, the technological platform metamodel includes Java concepts. For the last one, we created a simplified Java metamodel.

Feature model

Feature models are a standard de facto used to represent common and different characteristics of members from a product line [10]. The features can be mandatory, optional, or alternative. In our approach, feature models describe common and different characteristics of applications in target domains. Cupi2 SPL has two target domains: architecture and technological domain. We develop a feature model for each of them. Figure 2 presents a subset of features for the architecture and technological domain. For instance, Architecture feature model describes MainView is mandatory feature and InformationView, SetView and AddView are optional. Java feature model describes items are grouped using JCombobox or JList.



Figure 2. Cupi2 feature models

Weaving models and transformations

User selects the features that he wants before the execution of each transformation. He makes the selection by associating (source) model elements and (target) features. We use a weaving model to create the associations. Figure 3 shows links between business model elements and architecture features. For instance, one link associates Disc element and SetView feature. It generates a SetView which groups discs by using a list. Another link associates MusicStore element and Serialization feature.



Figure 3. Weaving model between business model and architecture features

After the weaving process, a transformation is executed. A transformation has two inputs (source model and weaving model) and one output (target model). Transformation applies base, control, or specific rules. We create base rules for the metamodel concepts that have to be always transformed into the same target feature. We create control and specific rules for the metamodel concepts that can be transformed into different (variable) target features. We implement the base rules using declarative programming, and the specific rules using imperative programming. The control rules are implemented in a mixed way, it means, they have a declarative section and an imperative one. Listing 1 presents an example for each type of rule. The mainView is a base rule. The setView, in line 7, is a control rule. The declarative section is in the lines 8 to 13 and the imperative section is in the lines 14-16. The setView rule searches in the weaving model the elements that have the feature SetView associated (line 9). For those elements, a View is created (line 13) and the addComponent imperative rule is called (line 15). The addComponent rule creates concepts associated to the created View giving the characteristics needed for a SetView.



Listing 1. Base, control, and specific transformation rules

Then all model-to-model transformations are executed. We apply a model-to-code transformation to obtain the source code. Finally, we manually complete the applications.

Download and examples

Publication

The publication titled "Variability Management in a Model-Driven Software Product Line" presents our approach in more details.

Example

This example is the complete scenario to generate Cupi2 examples.

Example User Guide

This document explains how to generate a specific Cupi2 example.

References

[1] J. Mukerji, and J. Miller, "MDA Guide," 2003.
[2] J. Estublier, and G. Vega, "Reuse and variability in large software applications" in 13th ACM SIGSOFT Lisbon, Portugal 2005.
[3] A. L. Santos, A. Lopes, and K. Koskimies, "An MDA Approach to Variability Management in Product-Line Engineering ".
[4] K. Garcés, C. Parra, H. Arboleda, A. Yie, and R. Casallas, "Variability Management in a Model-Driven Software Product Line" in Proceedings of the Congreso Colombiano de Computación, Bogotá, Colombia 2007.
[5] "Proyecto CUPI2" Access 2007; [Online]. Available: http://cupi2.uniandes.edu.co.
[6] "Graphical Modeling Framework " Access 2006; [Online]. Available: http://www.eclipse.org/gmf/.
[7] "AMW Home Page" Access 2006; [Online]. Available: http://www.eclipse.org/gmt/amw/.
[8] "ATL Home Page" Access 2006; [Online]. Available: http://www.eclipse.org/gmt/atl/.
[9] "Acceleo" Access 2006; [Online]. Available: http://www.acceleo.org.
[10] K. Kang, S. Cohen, J. Hess et al., Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Estados Unidos 1990.

General Information