AMW Use Case – Mapping Features To Models Technical report MST-9 3 April 2007 AMW Use Case – Mapping Features to Models Abstract Mapping features to models is a necessary step when developing software product lines of models. In such product lines, we need to relate objects from feature models (i.e. features) to objects from model templates. In this report we show an extension to the AMW framework to specify those relations through weaving models. Technical Report MST-9 3 April 2007 1 Orlando Avila-García Open Canarias, S.L. 38001 Santa Cruz de Tenerife Spain [email protected]Marcos Didonet Del Fabro ATLAS Group, INRIA & LINA University of Nantes, Nantes France [email protected]
Transcript
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
AMW Use Case – Mapping Features to Models
Abstract
Mapping features to models is a necessary step when developing software product lines of models. In such product lines, we need to relate objects from feature models (i.e. features) to objects from model templates. In this report we show an extension to the AMW framework to specify those relations through weaving models.
One of the possible synergies between software product lines and model driven engineering is the use of software product lines of models [1, 2]. In these product lines, family members are models, which are characterized by using features from a feature model.
The superimposed variants approach [1] is a technique to implement such product lines. It is based on the idea of creating a model template containing the family members in a superimposed way. The specialization of such a template gives rise to the different members and it is carried out by purging model template objects following the selection of features from a feature model, i.e. a feature configuration. This technique requires mechanisms to relate features from the feature model to model template objects. A first solution consists in annotating model template objects with presence conditions and meta-expressions referring to features [1].
However, the previous approach gives rise to several problems, such as the pollution of the model template with annotations [2]. An alternative approach is to use a domain-specific language to describe mappings between features and model template objects; that is the case of MTTL (Model Template Transformation Language) [2], a domain specific transformation language that specifies the specialization of model templates following feature configurations. In this report we present WMM_MTTL, an extension metamodel to AMW [4] that implements MTTL using the AMW framework.
2
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
2. The WMM_MTTL metamodel extension
Like MTTL, WMM_MTTL offers four mapping types: Clear, Remove, Select and Insert (see Section 4 – Appendix), each of them with its own semantics, specifying different manipulations of object relations within the model template. For example, a Remove mapping specifies the purge of a relation between two objects (source and target) within the template.
The collection attribute is used to identify the attribute of the source object that contains the relation. The attribute exist determines the existence condition that must be satisfied to execute the mapping during the template specialization.
Fragment of the WMM_MTTL metamodel extension
This initial implementation of WMM_MTTL makes use of URIs to identify both feature and model template objects. This differs from the initial MTTL metamodel [2], where objects were identified by their names and metaclasses. Time and experimentation shall tell us which approach is better.
-- @subsets end reference feature container : WovenElement;
-- @subsets end reference source container : WovenElement;
-- @subsets end reference target container : WovenElement;}
class Clear extends MappingLink {}
class Remove extends MappingLink { }
class Select extends MappingLink { }
class Insert extends MappingLink { }
class WovenElement extends WLinkEnd {}
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
3. WMM_MTTL Case Study
In this section we show a case study showing the usefulnes of WMM_MTTL to map features to model templates to specify template specialization operations.
3.1. Introduction.
Let's call Request Management Systems (RMS) those systems which, within the public administration domain, manage citizen's requests. In our experience, those systems share many commonalities; therefore, we can improve productivity by reusing software artifacts in their development. In this case study we propose to take advantage of our knowledge about commonalities and variabilities between UML use case models in the RMS domain. In this document we show a first step towards the development of a software product line for the maintenance of a family of use case models covering any variant of RMS. This product line of models will help us automate the analysis phase when developing such systems.
3.2. Domain Engineering
The infraestructure of a software product line is created during the domain engineering (or software product line engineering). In this case study, the first step is a domain analysis performed by the domain engineer through a commonality and variability analysis in order to set the scope of the product line, i.e. the number and characterization of family members. The result is a feature model. In this case study we are to use an implementation of the Cardinality-Based Feature Model (CBFM) metamodel [3].
Our second step is the domain design and implementation, where the domain engineer designs and implements reusable assets that will help in the development of every member of the model family. Following a superimposed variants approach, the domain engineer creates a model template containing all use case model variants in a superimposed form. At the same time, the domain engineer especifies how to transform or specialize such a template as to obtain every family member. In this case, we use WMM_MTTL, our implementation of MTTL [2] (see Section 2). Following a MDA (Model-Driven Architecture) approach, the domain engineer transforms instances of WMM_MTTL into any general-purpose transformation language (GPTL) for which we have already got a transformation engine, such as ATC [5], ATL [6] or QVT [7]. Figure 1 depicts a SPEM (Software Process Engineering Metamodel) [8] model describing this process.
3.3. Application Engineering
In this stage the application engineer (in this case a systems analyst) must create the UML use case model for a specific request management system (RMS). In our case study, the engineer makes use (execute) the software product line created in the domain engineering in order to generate the required use case model.
The application engineer will just have to identify the RMS he is to analyse by selecting optional and alternative features from the feature model of the software product line. The result is a feature configuration, which feeds the transformation of the software product line that automatically specializes the model template in order to generate the concrete use case model. Figure 2 depicts a SPEM model describing this process.
4
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
Figure 1. SPEM (Software Process Engineering Metamodel) 2.0model describing our domain engineering process. This process
delivers three output artifacts, assets of the software product line ofuse case models.
Figure 2. SPEM (Software Process Engineering Metamodel) 2.0model describing our application engineering process. This process
represents the production plan of a software product line for use casemodels. The input artifacts of such a process are the three reusable
assets created in the domain engineering phase.
5
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
3.4. First Stage
In a first stage of our case study, we will address an intentionally reduced scope for our software product line. In particular, only eight use case model variants will be taken into account during the domain analysis. We characterize them using a feature model with six mandatory, optional and alternative features (below, right). Cardinality [0..1] identifies optional features and cardinality [1..1] mandatory ones. There is only one feature group, with cardinality <1-1>, i.e. made of two alternative features where one and only one of them must be selected. By selecting alternative and optional features from this feature model we obtain eight different feature configurations, each of them corresponding to a member of the use case model family.
Taking a superimposed variants approach to model template creation, we include within the same use case model the eight use case model variants in a superimposed form. In other words, we include in the model template all objects belonging to any of the members of the model family. The use case model depicted below (left) represents such a model template, whose specialization gives rise to the different family members.
Use Case Model Template (UML2) Feature Model (CBFM)
6
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
Example of Use Case Model Family Members
In this section we show two of the family members or use case model variants generated by our product line in this first stage. On the right hand side of each use case model we find the feature configuration which characterizes it.
Example 1
Use Case Model (UML2) Feature Configuration (CBFM)
Example 2
Use Case Model (UML2) Feature Configuration (CBFM)
7
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
Artifacts Created During the Domain Engineering Phase
A. Feature Model (rms.cbfm). Instance of the Cardinality-Based Feature Model (CBFM) metamodel, edited with our EMF-based Eclipse plug-in.
8
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
B. Use Case Model Template (rmsUML_template.uml). Instance of UML 2.0, edited with UML2, a EMF-based Eclipse plug-in.
9
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
C. WMM_MTTL Transformation (rmsCBFM2UML.amw). Instance of our WMM_MTTL, edited with the AMW Tool.
This screenshot depicts a WMM_MTTL weaving model with six mappings between feature model (left) and model template (right). For example, the first mapping (highlighted) specifies the purge of the relation between objects Staff Member and Validate Request from the template when the feature Request Validation is not found in a feature configuration.
10
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
Example of Artifacts Created During the Application Engineering Phase
Example 1
We describe the artifacts created when we carry out the production plan (depicted in Figure 2) to obtain the first example of use case family member (page 4).
Use Case Model (UML2) Feature Configuration (CBFM)
11
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
A. Feature Configuration (rms_example1.cbfm). Instance of the Cardinality-Based Feature Model (CBFM) metamodel, edited with our EMF-based Eclipse plug-in. It is important to note that this model is a specialization of the Feature Model (page 5) characterizing the use case model family.
12
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
B. Use Case Model (rmsUML_example1.uml). Instance of UML 2.0, edited with UML2, a EMF-based Eclipse plug-in. It is important to note that this model is a specialization of the Use Case Model Template (page 6) describing the use case model family.
13
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
Example 2
We describe the artifacts created when we carry out the production plan (depicted in Figure 2) to obtain the second example of use case family member (page 4).
Use Case Model (UML2) Feature Configuration (CBFM)
14
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
A. Feature Configuration (rms_example2.cbfm). Instance of the Cardinality-Based Feature Model (CBFM) metamodel, edited with our EMF-based Eclipse plug-in. It is important to note that this model is a specialization of the Feature Model (page 5) characterizing the use case model family.
15
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
B. Use Case Model (rmsUML_example2.uml). Instance of UML 2.0, edited with UML2, a EMF-based Eclipse plug-in. It is important to note that this model is a specialization of the Use Case Model Template (page 6) describing the use case model family.
16
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
4. Appendix
Cardinality-Based Feature Model (CBFM) ecore metamodel [3]
Model Template Transformation Language (MTTL) ecore metamodel [2]
17
AMW Use Case – Mapping Features To Models
Technical report MST-9 3 April 2007
References
[1] K. Czarnecki and M. Antkiewicz: Mapping Features to Models: A Template Approach Based on Superimposed Variants. In GPCE'05: Proceedings of the Fourth International Conference on Generative Programming and Component Engineering. Springer-Verlag, LNCS 3676, pages 422-437. September 2005.
[2] O. Avila-García, A. Estévez García, E.V. Sánchez Rebull and J.L. Roda García: Using Software Product Lines to Manage Model Families in Model-Driven Engineering. In ACM SAC 2007: Proceedings of The 22nd Annual ACM Symposium on Applied Computing - Model Transformation Track. ACM Press, pages 1006-1011. March 2007.
[3] K. Czarnecki, S. Helsen, and U. Eisenecker. Staged Configuration Through Specialization and Multi-Level Configuration of Feature Models. Software Process Improvement and Practice, special issue on "Software Variability: Process and Management”, 10(2), 2005, pp. 143 – 169.
[4] Atlas Model Weaver (AMW) homepage. http://www.eclipse.org/gmt/amw/
[5] A. Estévez García, J. Padrón, E.V. Sánchez Rebull and J.L. Roda García: ATC: A Low-level model transformation language. In MDEIS 2006: Proceedings of the 2nd International Workshop onModel Driven Enterprise Information Systems. May 2006.
[6] Frederic Jouault and Ivan Kurtev: On the Architectural Alignment of ATL and QVT. In ACM SAC 2006: Proceedings of The 21st Annual ACM Symposium on Applied Computing. ACM Press. April 2006.
[7] OMG: MOF 2.0 Query/Views/Transformations. OMG Final Adopted Specification, number ptc/05-11-01.November 2005. Available at http://www.omg.org/docs/ptc/05-11-01.pdf.
[8] OMG: Software Process Engineering Meta-Model 2.0. OMG Draft Adopted Specification, numberad/06-04-05. April 2006. Available at http://www.omg.org/docs/ad/06-04-05.pdf.
