GReAT: Graph Rewriting And Transformation

1
GReAT Graph Rewriting And Transformation

• Presenter Yuehua Lin
• 2/17/04, Tuesday
• Slides help from Aditya Agrawal
• aditya.agrawal_at_vanderbilt.edu

2
Domain-Specific MDA
3
Metamodel and Models
Model
Metamodel a graph grammar of models
4
Model manipulation and transformation

• Models are graphs
• The most common operations are
• Traversal and matching
• Creation of secondary data structure
• Text generation (e.g. code/config )

3
2
1
5
Research Hypothesis of GReAT

• Model transformations can be specified using
  graph transformations on metamodels. Using this
  approach we aim to achieve a significant increase
  in productivity in the development of such
  transformations.

• Goals
• Easyto-use language for system developers
• Increase productivity (order of 2 to 10)
• Efficient execution (not more that 2 times slower
  than hand code)

6
Overview
Transformation Modeling
Refers to
Refers to
Describes
Describes
Transformation Execution
Input
Output
7
Graph Rewriting Transformation (GReAT)

• Pattern specification
• Patterns with cardinality
• Graph transformation and rewrite
• Create New Objects
• Delete Objects
• Modify Attributes
• High-level control flow
• Hierarchy
• Sequencing
• Recursion
• Branching

8
Pattern Specification Language

• Single cardinality

Pattern Graph
Host Graph
Cardinality n a pattern vertex must match n host
graph vertices.
9
Pattern Specification Language (contd)

• Fixed cardinality

Pattern Graph
Host Graph
10
Graph transformation language
Bind
Delete
New
A transformation rule example with pattern, guard
and attribute mapping
11
Control Flow Language

• Sequencing of rules required
• For efficiency
• Understanding of the transformation
• Intuitive for programmers
• Control Constructs
• Sequencing
• Branch (Test/Case)
• Hierarchy
• Recursion

Sequencing
Hierarchy
12
Transformation Engine A Virtual Machine
13
Steps to Use GReAT Tools

• Build Transformation model (provided by user)
• meta models
• transformation rules
• configuration model
• Run Transformation model
• Run Master Interpreter to convert the above
  models to the required formats
• Run GR engine/GRD engine to perform the
  transformation
• Run Code Generator to generate C code if
  necessary

14
GReAT Demo Description

• Demo Example House2Order
• This example converts a house model into a
  purchase order of door required to build the
  house.
• Begin demo

15
Demo 2 C-SAW

• C-SAW is an aspect weaver that can weave
  crosscutting constraints/modifications in domain
  models automatically for rapid model
  transformation.
• http//www.gray-area.org/Research/C-SAW

16
Framework of Aspect Model Weaver
Input Models
Specification aspects
Strategies
weaving engine
Output Models
17
Three Key Components

• Specification aspects for specifying a set of
  locations in the domain models, e.g. a collection
  of models that have the same type
• Strategies for describing the crosscutting
  behavior and its associated model transformation,
  e.g. add new atoms to the specified models
• A weaving engine for performing the described
  transformations via interacting with the modeling
  environment.
• All aspects and strategies are specified in
  Embedded Constraint Language (ECL).

18
C-SAW Demo Description

• Embedded System Modeling Language (ESML) is a
  domain-specific graphical modeling language
  developed for modeling real-time mission
  computing embedded avionics applications.
• We have over 20 ESML component models that
  communicate with each other via a real-time
  event-channel mechanism.
• Tasks
• 1) Insert Log atoms to the ESML component
  models that have data atoms and create
  connections between the Data atom and the Log
  atom.
• 2) Insert two Concurrency atoms of different
  attributes to the component models that have at
  least one data atom.

19
Play C-SAW Demo Video

• http//www.gray-area.org/Research/C-SAW/

20
Example The Aspect Specification And Strategy
21
Effect of Model Transformation
Before Weaving
After Weaving
22
ESML Models (1/4)

• The Embedded Systems Modeling Language (ESML) is
  a domain-specific graphical modeling language
  developed for modeling real-time mission
  computing embedded avionics applications.
• The Model of Computation (MoC) used for ESML
  leverages elements from the CORBA Component Model
  8 and the Boeing Bold Stroke architecture,
  which also uses a real-time event channel

23
ESML Models (2/4)

• In this model, components are complex, ported
  objects (typically consisting of multiple
  instances of different classes), which interact
  with each other through two mechanisms
• procedure invocation via component Receptacles
  (clients expressed dependencies on other
  components interfaces) to Facets (public server
  component interfaces),
• event propagation through a publish/subscribe
  mechanism.

24
ESML Models (3/4)

• The above two mechanisms are typically combined
  in a push-directed-pull interaction pattern.
• In this combined mode of operation, a publisher
  component notifies subscriber components about
  the availability of data, and the subscribers,
  when triggered, call back through their
  receptacles to the facet of the supplier to
  retrieve that data.

25
ESML Models (4/4)

• The ESML provides the following modeling
  categories to allow representation of an embedded
  system a) Components, b) Component Interactions,
  and c) Component Configurations.
• The embedded systems built using ESML are
  typically multi-threaded.
• Thread types with their rates and priorities can
  be declared inside processors. By design, threads
  are related to subscribe ports when the
  component receives a notification via the
  subscribe port, an associated thread wakes up and
  executes the components code.

26
Extra slides (1)

• House2Order
• HouseModel - Input Meta-model in UML class
  diagram format
• Order -Output Meta-model in UML class diagram
  format
• zt_House2Order - Folder containing the
  transformations
• zz_Config - Folder containing configuration
  information

27
Extra Slides (2)

• Lets look at the meta models first,
• Meta Model of Input model HouseModel
• Meta Model of Output model OrderModel
• Then lets look at the configuration model,
• Configuration file meta information, start rule
  (is MakeOrder3) and the input and output file
  types which define the meta name, root folder and
  file mode of the participating files.
• The start rule will be invoked first.
• MakeOrder3 Transformation rule
• is a compositive rule that excutes CreateOrder,
  MakeOrder and AddToOrder sequencially.
• Finally, lets look at the transformation rules
• The CreateOrder transformation rule
• Match/bind the in and out ports and a house
  model instance and rootfolders for input model
  and output model. When matching, then create a
  new order model instance (see the attribute
  action of purchase order) and a composition
  connection (see the blue edge) to its rootfolder.
• As the first rule, its input models/files are
  given by the configuration information.

28
Extra Slides (3)

• The MakeOrder transformation rule
• Create an OrderItem instance when there is a
  matching between the input model and the pattern.
  Using guard to determine when this creation occur
  (when AdjacentTo.hasDoor returns true). Using the
  AttributeMappings ExpressionString (see its
  ExpressionString attributes) to set the initial
  attributes of the created OrderItem instance.
• The AddToOrder transformation rule
• When a set of matching between the input model
  and the pattern happens (for example, there are 5
  matches), the quantity of the OrderItem instance
  will be accumulated to 5 via the
  AttributeMappings ExpressionString
  specification.
• MyHouse1 Input model
• It has 7 adjacentTo relationship between these
  rooms. However, only 5 of them have door.
• MyOrder1 Output model
• So the quantity of the generated order is 5.

29
Extra Slides (4)

• Run the master interpreter to create the required
  meta information file, transformation file and
  configuration file.
• Invoke the GR Engine to perform the
  transformation.
• You need to specify the input model and its
  path
• You also need to specify the output model and
  its path.
• The output model is then generated.
• Run code generator to create C codes.
• MyOrder1 Output model
• So the quantity of the generated order is 5.

30
A Domain Driven Development Framework
31
Conclusion

• GReAT is
• --Pattern specification language
• --Graph transformation language
• --High-level control flow language

32
Graph grammars and transformations

• Node replacement grammars
• Hyper edge replacement grammars
• Algebraic approaches
• Sequencing
• Programmed graph replacement systems.
• Sequencing
• Textual control flow

33
Pattern Matching

• Simple Fixed Cardinality
• Exponential in the number of pattern vertices and
  edges
• Optimization is to start with at least one known
  vertex
• Recursive algorithm developed
• Variable cardinality
• Based on dynamic programming
• Time complexity not known (may be NP complete)

34
Sequencing
35
For Block
36
Test Case
37
Domain Specific Languages

• Domain Specific Languages can increase
  productivity.
• Historically DSLs haven't had a wide impact.
• What is the reason?
• High development cost
• Lack of standardization
• Lack of vendor support
• Lack of robustness

38
DSL Development Framework

• A formal approach towards the specification and
  implementation of DSLs
• A formal approach lends itself to standardization
  (OMG MDA QVT)
• Formal Specification of DSL can lead to Correct
  by construction languages
• Framework to support the formal approach
• Reduce development cost.
• Standard protocol can lead to vendor confidence

39
State of the Art Unique Requirement

• Graph grammars and transformations
• Over 20 years of research, Node Hyper edge
  replacement, Algebraic approaches and Programmed
  graph replacement systems. Prominent PROGRES,
  AGG
• Transformations where domain and range belong to
  different type systems.
• Algorithmic nature of transformations
• Specification of traversal schemes
• Efficiency of transformation code
• More intuitive and easy to understand
  specification

40
Reference Between Metamodels OUT
41
Pattern Specification Language (contd)

• Variable cardinality

Pattern Graph
Host Graph