Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Requirements Variability Support through MDD and Graph Transformation

Javier Pérez
September 28, 2005

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

Javier Pérez

September 28, 2005
Tweet

More Decks by Javier Pérez

Other Decks in Research

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 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
  4. 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
  5. 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
  6. 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)
  7. September 05 Page 8 PL Requirements Engineering Initial: features &

    use-cases [solution oriented] Add Goals: Intentional viewpoint – explicit Problem oriented NFR dealing Analyze alternatives
  8. 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
  9. 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>>
  10. 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?
  11. 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)
  12. 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
  13. 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
  14. September 05 Page 16 Vertical Transformations Application EJB Application .NET

    Application EJB Application .NET Application : PIM to PSM (MDA)
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. September 05 Page 37 Support Specification independent of implementation. Support

    based on: Models representation Transformation implementation Two approaches: XML + XSLT / Java Graph Grammars + AGG
  29. 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
  30. 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
  31. September 05 Page 40 Rule Ordering Layers L0: FeatureModelToNamespace L1:

    RootFeatureToClass L2: SolitaryFeatureToClass L3: FeatureGroupToClass L4: GroupedFeatureToClass Dangling edges restriction Loop over layers
  32. 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
  33. 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
  34. September 05 Page 47 XML + XSLT Under Eclipse Feature

    Model -> Xfeature plugin: XML Customizability of meta-model Architecture Model UML Class diagram XMI