Requirements Variability Support through MDD and Graph Transformation

One of the most important factors of success in the development of a software product line is the elicitation, management, and representation of variability. Feature models, are used as a key artifact to express requirements variability and are the basis for the domain architecture design. In this context, this article explores the possible advantages of Model Driven Development (MDD) and shows an automated transformation from the feature model to the architecture model. This transformation is understood as a graph transformation process because it offers a natural way to represent model transformations. The transformation is applied by the definition of a simple context-free graph grammar where production rules are obtained from metamodels of both feature and architecture models. Presented at GraMoT 2005 (http://program-transformation.org/Gpce05/GraphModelTransformations).

Transcript

1. International Workshop on Graph and Model Transformation Generative Programming and Component Engineering (GPCE'05) Requirements variability support through MDDTM and graph transformation F. Javier Pérez García Miguel A. Laguna Yania Crespo Bruno González-Baixauli
2. September 05 Page 2 Index Introduction: Product Lines MDDTM and Product Lines A Transformation example Support through graph transformations Conclusions
3. September 05 Page 3 Introduction: Product Lines
4. September 05 Page 4 Product Lines (PL) PL issues: Successful reuse approach Coarse-grained components Top-down systematic approach High effort & complex Lack of process definition Two Processes: Product Line Engineering Process Product Product Engineering Process
5. September 05 Page 5 Product Line Process (1) Goal: reduce investment and present results earlier Enabling PLs for small enterprises Features: Defined with SPEM Using best practices Two different process Iterative
6. September 05 Page 6 Product Line Process (2) Product Line Engineering Process Asset management (Reuse library) Product Engineering Process Inicio Elaboración Construcción Transición Inicio Elaboración Construcción Transición Inception Elaboration Construction Transition Assets Requirement Engineering Reference Architecture definition Component Implementation Domain definition Assets Assets
7. September 05 Page 7 PL Engineering Process Three phases: PL inception PL elaboration PL construction Six disciplines: Domain definition PL Requirement engineering Reference architecture definition Component implementation Other (Test & Change management)
8. September 05 Page 8 PL Requirements Engineering Initial: features & use-cases [solution oriented] Add Goals: Intentional viewpoint – explicit Problem oriented NFR dealing Analyze alternatives
9. September 05 Page 9 Goal Model Examples D D D Persona Discapacitada Comunicar Receptor Mensaje D Facilidad de Uso Movilidad D D D D Comunicador Aumentativo Y Alternativo (CAA) D Entregar Mensaje D Facilidad de Uso D D D D Mensaje Obtener Mensaje D D ALCANZAR Comunicación AND ALCANZAR Mensaje Introducido ALCANZAR Mensaje Reproducido OR OR Mediante Texto Mediante SPC Usando Texto Usando Voz ACTOR Leyenda HARDGOAL SOFTGOAL RECURSO TASK
10. September 05 Page 10 PL Models Goal Model Goal Model Feature Model Feature SubModel Product Line Model Application Model Soft-goal Model Application <<refine>> <<refine>> <<refine>> <<refine>> << instanceOf >> << instanceOf >> <<instanceOf>>
11. September 05 Page 11 MDD and Product Lines
12. September 05 Page 12 MDD & MDA Model Driven Development Generalization of Model Driven Architecture (MDATM) Introduced by OMG Based in models: Platform Independent Model (PIM) Platform Specific Model (PSM) Model Transformations Can be applied to our process?
13. September 05 Page 13 MDA & Product Lines Several model types: Goal & Softgoal Feature Architecture (class) Different scope: All PL (variability & communality) Application specific PIM models PIM to PIM transformations (MDE)
14. September 05 Page 14 PL Architecture (OO Framework) Application Feature Sub-Model Application Model Application EJB PIM to PSM transformations Application .NET PIM to PIM Transformations? Application Goal/soft-goal Model Instantiation Selection Goal/soft-goal Model Configuration Feature Model Rationale Definition PL Architecture (OO Framework) Application Feature Sub-Model Application Model Application EJB PIM to PSM transformations Application .NET PIM to PIM Transformations? Application Goal/soft-goal Model Instantiation Selection Selection Goal/soft-goal Model Configuration Configuration Feature Model Rationale Definition Transformations
15. September 05 Page 15 PL Architecture (OO Framework) Application Feature Sub-Model Application Model Application EJB PIM to PSM transformations Application .NET PIM to PIM Transformations? Application Goal/soft-goal Model Instantiation Selection Goal/soft-goal Model Configuration Feature Model Rationale Definition PL Architecture (OO Framework) Application Feature Sub-Model Application Model Application EJB PIM to PSM transformations Application .NET PIM to PIM Transformations? Application Goal/soft-goal Model Instantiation Selection Selection Goal/soft-goal Model Configuration Configuration Feature Model Rationale Definition Horizontal Transformations Selection: Domain engineer Configuration: Trazability Application from PL: Trazability
16. September 05 Page 16 Vertical Transformations Application EJB Application .NET Application EJB Application .NET Application : PIM to PSM (MDA)
17. September 05 Page 17 A Transformation Example
18. September 05 Page 18 Application EJB Application .NET Application EJB Application .NET Transformation
19. September 05 Page 19 From the Feature Model …
20. September 05 Page 20 … to the Architecture Model
21. September 05 Page 21 Features to Architecture Transformation Metamodel mapping approach: Compatibility? – MOF Simplicity Architecture metamodel - UML Feature metamodel Several Czarnecky – cardinality Describe transformations with OMG QVT
22. September 05 Page 22 Feature Metamodel (Czarnecki)
23. September 05 Page 23 Partial UML Class Metamodel
24. September 05 Page 24 Features to Architecture Transformation Ordered Context Sensitive Transformations Rules: Feature model -> Package: FeatureModelToNamespace Root feature -> Class: RootFeatureToClass Recursively (linked features): SolitaryFeatures & FeatureGroups to classes and associated to parent: SolitaryFeatureToClass & FeatureGroupToClass GroupedFeatures to classes and associated (generalization) to parent feature group: FeatureModeltoNamespace Associations multiplicity = Feature cardinality
25. September 05 Page 25 FeatureModelToNamespace m:FeatureModel <<domain>> name=fm n:Namespace name=fm <<domain>> uml, e fm, c FeatureModel to Namespace Feature Model is transformed in a Package
26. September 05 Page 26 when FeatureModelToNamespace(m,n) RootFeatureToClass f:RootFeature <<domain>> name=fn m:FeatureModel c:Class name=fn <<domain>> uml, e fm, c where SolitaryFeatureToClass(f,c) FeatureGroupToClass(f,c) n:Namespace RootFeature to Class The RootFeature is transformed to the first class
27. September 05 Page 27 where SolitaryFeatureToClass(sf,sc); FeatureGroupToClass(sf,sc); SolitaryFeatureToClass f:Feature <<domain>> sf:SolitaryFeature c:Class <<domain>> uml, e fm, c a:Association name=sn featureCardinality=fc sc:Class name=sn ae2:AssociationEnd multiplicity=fc ae1:AssociationEnd multiplicity=“1..1” SolitaryFeature to Class SolitaryFeatures are transformed into classes and associated to the owner feature with multiplicity featureCardinality
28. September 05 Page 28 where GroupedFeatureToClass(fg,cg); FeatureGroupToClass f:Feature <<domain>> fg:FeatureGroup uml, e fm, c name=gn groupCardinality=gc c:Class <<domain>> a:Association ae2:AssociationEnd multiplicity=gc ae1:AssociationEnd multiplicity=“1..1” cg:Class name=gn FeatureGroup to Class FeatureGroups are transformed to classes and associated of owned GroupedFeatures with multiplicity groupCardinality
29. September 05 Page 29 where SolitaryFeatureToClass(f,c) FeatureGroupToClass(f,c) GroupedFeatureToClass fg:FeatureGroup <<domain>> f:GroupedFeature gc:Class <<domain>> uml, e fm, c name=fn c:Class name=fn g:Generalization parent child GroupedFeature to Class GroupedFeatures are transformed to sub- classes of owner
30. September 05 Page 30 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 Element Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 ElemType
31. September 05 Page 31 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 Element Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 RootFeatureToClass ElemType
32. September 05 Page 32 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 Element Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 SingleFeatureToClass ElemType
33. September 05 Page 33 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 ElemType Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 FeatureGroupToClass Element
34. September 05 Page 34 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 Element Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 GroupedFeatureToClass ElemType
35. September 05 Page 35 Transformation Example Input Buttons Element Mechanism Grouped Lists Phrase Voice Character 1..1 1..1 0..1 1..1 1..1 Element Button List Character Phrase Voice Input Grouped MecType Mechanism 0..1 SingleFeatureToClass ElemType
36. September 05 Page 36 Support through Graph Transformations
37. September 05 Page 37 Support Specification independent of implementation. Support based on: Models representation Transformation implementation Two approaches: XML + XSLT / Java Graph Grammars + AGG
38. September 05 Page 38 Graph Transformations Models = Graphs Model Transformations = Graph Transformations Metamodel = Type Graph Models = Typed Graphs + Attributes Rule ordering: Layered Graph Grammars AGG: State of the art graph transformation tool Context + Layers + Attributes
39. September 05 Page 39 Graph Transformation Rules QVT rule translates into a set of GG rules: Create classes Classes in the target model matching features in the source model Move children Link Features in the source model to the transformed parent class Delete Feature Node Transformed Feature node has no children and can be deleted
40. September 05 Page 40 Rule Ordering Layers L0: FeatureModelToNamespace L1: RootFeatureToClass L2: SolitaryFeatureToClass L3: FeatureGroupToClass L4: GroupedFeatureToClass Dangling edges restriction Loop over layers
41. September 05 Page 41 RootFeature To Class Rules
42. September 05 Page 42 Initial Feature Model
43. September 05 Page 43 Resulting Architecture Model
44. September 05 Page 44 Conclusions
45. September 05 Page 45 Conclusions Exploration MDATM to PL own process Transformation: Feature -> Architecture Support through Graph Transformations GT Tool: AGG Integration within other tools (Eclipse) Further work Trazability mechanism Goals to Feature transformation
46. International Workshop on Graph and Model Transformation Generative Programming and Component Engineering (GPCE'05) Requirements variability support through MDDTM and graph transformation F. Javier Pérez García Miguel A. Laguna Yania Crespo Bruno González-Baixauli
47. September 05 Page 47 XML + XSLT Under Eclipse Feature Model -> Xfeature plugin: XML Customizability of meta-model Architecture Model UML Class diagram XMI
48. September 05 Page 48 XFeature
49. September 05 Page 49 Resulting Model
50. September 05 Page 50 Eclipse Integration