Combining Generative and Graph Transformation Techniques for Model Transformation: An Effective Alli

1
Combining Generative and Graph Transformation
Techniques for Model Transformation An
Effective Alliance?

• Shane Sendall
• Software Modeling Verification Lab.
• Computer Science Department
• University of Geneva
• Switzerland

Shane.Sendall_at_cui.unige.ch
2
Overview

• Model Transformation
• Overview of Gmorph
• Graph Transformation/Generative Programming
• Closing Remarks

3
Model TransformationWhat

• A model transformation applies one or more rules
  according to the presence of certain patterns of
  elements in the set of source models, resulting
  in a set of target models.
• The application of a rule results in any number
  of the following
• the creation of a new model fragment
• the deletion of an existing model fragment
• the modification of an existing model fragment
• (where model fragment is any thing from a model
  to a model element)
• In the context of MDA, model transformation can
  be categorized as language translation and model
  evolution

4
Genermorphous (Gmorph)

• Gmorph is a language (still under development)
  for specifying and executing model
  transformations
• Goal
• push imperative approach toward some advantages
  of declarative approaches, such as, pattern
  matching, rule application, etc.
• Context
• an experimental language that is not fully
  featured it does not address all aspects that
  are useful for mainstream model transformation,
  e.g., reuse mechanisms, well-formedness checks,
  concurrent application of rules, etc.

5
Genermorphous (Gmorph)

• A hybrid approach that offers a (partially)
  visual transformation language, which address
  both model evolution and translation categories
• Rule Specification language (mixture of Graph
  Transformation Rules and Generative Programming
  Principles)
• Rule Composition language (small imperative
  language choice, sequence, iteration)
• Relation to QVT results from Gmorph could be fed
  back into a QVT language

6
Graph Transformation

• ? Graph Rewriting
• LHS (graph) left-hand side of rule pattern
• RHS (graph) right-hand side of rule pattern
• (Interface intersection of LHS RHS)
• Steps taken in applying a rule
• match, remove, glue, embed

RHS
LHS
7
GT relevance to Gmorph

• LHS and RHS
• Give a before and after view of rule
  application
• For model evolution transformations rule is a
  graph rewrite

8
Generative Programming

• A generative programming consists of three parts
  a problem space, a solution space, and the
  configuration knowledge.
• Problem space defines the appropriate
  domain-specific concepts and features.
• Solution space defines the target model elements
  that can be generated and all possible
  variations.
• Configuration knowledge specifies illegal feature
  combinations, default settings, default
  dependencies, construction rules, and
  optimization rules.

9
GP relevance to Gmorph

• Ability to handle variations in source model
  element matching and target model generation
  (language translation)
• Parameterization and open-world model of
  matching
• Default and configuration information are part of
  specification

10
Closing Remarks and Future Directions

• Issues
• Pattern matching at instance level
• Optional and multiple matches
• Transitive closure and sequence of matches
• Ability to easily define mappings between
  instances
• Current approach 1-to-1, 1-to-many, many-to-1 by
  traversal of LHS
• Interesting alternative an attribute
  grammar-like approach, which implicitly traverses
  LHS

11
Closing Remarks and Future Directions

• Issues
• Reversing transformations and model updating
  (round-tripping) gt (persistent) relations
• Separation between rule language and rule
  composition language gt to be fine-tuned with
  usage
• A concrete syntax that doesnt distort the
  concrete syntax of source model too much (work
  back from metamodel instance view)

12
(No Transcript)
13
Example using Gmorph

• Problem Transform a Java package and its
  contained abstract classes to a UML package and
  UML classes that correspond to these Java
  classes.

14
LHS of Gmorph Rule Spec
Metamodel JavaNB
javaPJavaPackage
/javaPackage
X, 0..
/classes
0..
/JCJavaClass
/declaredBy
/JFField
/features

• Additional Selection Conditions
• context JC ensure
• self.isInterface false and -- JC
  classes must not be interfaces
• self.modifier ModifierKindabstract
  -- JC classes must be abstract

15
RHS of Gmorph Rule Spec
Metamodel UML
umlPPackage
/ownedMember
A, 0..
0..
/owningPackage
/UCClass
/ATAttribute
/ownedAttribute
/class
16
RHS of Gmorph Rule Spec
Metamodel UML
ltumlPgt
ltUCgt A, 0..
ltATgt 0..
17
LHS/RHS of Gmorph Rule Spec
Metamodel JavaNB
Metamodel UML
umlPPackage
javaPJavaPackage
/javaPackage
/ownedMember
A, 0..
X, 0..
/classes
0..
0..
/owningPackage
/JCJavaClass
/UCClass
/ATAttribute
/declaredBy
/JFField
/ownedAttribute
/features
/class

• Additional Selection Conditions
• context JC ensure
• self.isInterface false and -- JC
  classes must not be interfaces
• self.modifier ModifierKindabstract
  -- JC classes must be abstract

18
Gmorph Rule Script

• Transform Rule
• JavaNB-to-UML_PackageMapping (in javaP
  JavaNBPackage, out umlP UMLPackage)
• Instance Mapping
• javaP --gt umlP
• mapeach x in X onto a in A
• x.JC --gt a.UC
• mapeach srcField in x.JC.features onto tgtAttr
  in a.ownedAttribute
• srcField --gt tgtAttr
• Type Mapping
• UMLPackage lt-gt JavaNBPackage
• UMLClass lt-gt JavaNBJavaClass
• LHS.name lt-gt RHS.simpleName
• LHS.isRoot lt- RHS.superClassName.size() 0

19
Gmorph Rule Script (contd)

• -- Type Mapping (contd)
• UMLAttribute lt-gt JavaNBField
• LHS.name lt-gt RHS.name
• LHS.scope lt-gt RHS.scope
• LHS.visibility lt-gt RHS.visibility
• false -gt RHS.isVolatile
• LHS.isDerived lt- false
• UMLVisibilityKind lt-gt JavaNBVisibilityKind
• LHS.vk_public lt-gt RHS.public
• LHS.vk_protected lt-gt RHS.protected
• LHS.vk_private lt-gt RHS.private
• LHS.vk_package lt-gt RHS.package

20
Closing Remarks and Future Directions

• Advantages of Gmorph
• cognitive and practical advantages for concrete
  syntax approach (WYSIWYG) and explicit LHS and
  RHS (the before and after transformation view)
• Patterns described as object structures works
  well with imperative style traversal

21
Other Approaches

• IBM/DSTC QVT (logic language)
• Reversibility (due to unification)
• Usability, Performance?
• QVTP (relation-based approach)
• Nice expression of 1-to-1 language translation
• Awkward for complex model evolution trans.?
• Sun/Compuware QVT (logic language?)
• Reversibility, modularity
• Feasibility of using OCL to fully describe
  LHS/RHS?
• UMLX
• Graphical notation based on Graph Transformation
• Feasibility of encoding complex trans.
  graphically?
• Language translation transformations?

22
Matching Features

• Additional Features
• Optional matches for one or more p-elements
• p-element/group of p-elements are optionally
  matched (matching is mandatory by default)
• Maximum possible number of p-element matches are
  made
• Multiple matches for one or more p-elements
• Collection of tuples (tuple of p-elements scoped
  by matching container)
• Transitive closure matches for one or more
  p-elements
• Collection of tuples
• Fixpoint iteration
• Sequence of matches for one or more p-elements
• Sequence of tuples
• Ordered according to specified criteria

23
OMGs Model Driven Architecture Initiative

• Three levels
• Platform Independent Model(s)
• Platform Specific Model(s)
• Code Deployment/Configuration Information
• The big issues in automation support for MDA
• Consistency and synchronization between levels
  (vertical and horizontal)
• Support in construction tasks
• MOF 2.0 Query/View/Transformation Standardization

24
Model TransformationWhy

• Categories
• Model Translation
• inter-model mapping, synthesis, splitting, and
  updating
• Model Evolution
• source model is target model (same/copy)
• Examples in MDA
• Model Synchronization, Refinement, and Forward
  and Reverse Engineering

PIM
PSM
PSM
25
Model TransformationWhy

• Examples (contd)
• Synthesis of views
• E.g., bringing together the protocol view with
  the operation view to form the behavior model
• Generation of Views
• E.g., generating a scenario from a statemachine
• Application of Software Patterns and Refactoring
• E.g., applying the Singleton design pattern to a
  design model

ProtocolView
UML StateDiagram
UML SequenceDiagram
BehaviorModel
Operation View
26
Model TransformationHow

• Declarative approaches
• Logic languages
• Graph Rewriting languages
• Relation/Mapping languages
• Imperative, direct model manipulation approaches
• ltyour favorite mainstream languagegt API to
  model repository of tool
• XML-based approaches
• XSLT (and co.)/XMI.difference (XMI -gt XMI)
• Generative approaches
• Template/Frame languages
• Transformation generator languages
• Hybrid approaches
• Mix declarative and imperative styles

27
Graph Transformation

• ? Graph Rewriting
• LHS (graph) left-hand side of rule pattern
• RHS (graph) right-hand side of rule pattern
• (Interface intersection of LHS RHS)
• Steps taken in applying a rule
• match, remove, glue, embed

RHS
LHS
28
Graph Transformation

• Issues
• Dangling Edges
• Commutativity of rules
• Triggering Conditions
• Embedding rules
• Efficient algorithms for LHS matching
• Reversibility of rules (RHS ? LHS)

29
JavaNB Metamodel