GReAT

1
GReAT

• Vamshi Raghu
• 7th April 2005

2
Outline

• What is GReAT ?
• Context
• Origin.
• Motivation / Need for GReAT.
• GReAT Design Goals.
• The GReAT Language
• Pattern Specification Language
• Graph Transformation Language
• Control flow language
• Implementation using the GME framework.
• Typical GReAT Usage
• Relevance to my research.
• References

3
What is GReAT ?

• Graph Rewriting And Transformation.
• A model compiler compiler (right now, a model
  compiler interpreter).
• A language and a tool chain.
• A UML-friendly graph-based language for
  expressing model to model transformations.
• A suite of tools that support the use of this
  language to generate model to model transformers
  from visual specifications.

4
Origin

• Developed at the Institute for Software
  Integrated Systems (ISIS), Vanderbilt
  University, as part of the Model-Based Synthesis
  of Generators for Embedded Systems project,
  which is a part of the DARPA Model Based
  Integration of Embedded Systems (MoBIES)
  project.
• The goal of the project is to build reusable
  technology for .. model interpreters for embedded
  systems.

5
Origin (.. Continued)

• Model Integrated Computing was envisioned at the
  ISIS as a way of specifying computation in
  general as model transformation (interpretation).
  
• The solutions for a majority of the MoBIES
  projects are, therefore, built around a common
  core meta-modeling technology called the Generic
  Modeling Environment (GME) (implemented only on
  Windows!)

6
Motivation (in relation to GME)

• While GME provides for the definition of a
  modeling language and the domain specific design
  environment (DSDE) using UML Class diagrams, the
  interpretation of these models still involves
  mapping onto another model (eventually a model of
  computation).
• Model interpreters (needed for this step) used to
  be realized using GME in a traditional
  programming language, that traversed the model
  graph via a meta-model and programming-language
  specific (object-model-specific) API generated by
  GME.
• GReAT has its roots in the effort to use GME
  itself to automate the building of interpreters
  for domain-specific visual languages
  (paradigms) defined using the GME suite.

7
Motivation (extending the state of the art)

• Design of a useful model-driven pattern-based
  graph-language for describing a generator is non
  trivial as the source and target domains maybe
  arbitrarily different, and the transformation may
  involve an arbitrarily complex computation.
• Existing transformation techniques (node
  replacement grammars, hyperedge replacement
  grammars, algebraic approaches, programmed graph
  replacement) either work only for graphs of the
  same domain, or do not provide for a way to
  specify structural constraints on graphs, or are
  not UML-friendly.

8
GReAT Design Goals

• The language should provide for a way to specify
  the input and output domains.
• The language should provide for a way to model
  all the intermediate objects created during the
  transformation (model the steps).
• The language must be Turing complete.
• The language should have efficient
  implementations of its programming constructs.
  (constant factor slow down from hand written
  code).
• The language must make generator writers more
  productive.

9
The role of GReAT in the DSDE generation process

• The GReAT language defines the syntax and
  semantics of a graph transformation language
  which encodes the pattern matching and
  transformation idioms that are repeated in manual
  interpreter writing.
• The GReAT interpreter realizes the semantics of
  the transformation language by making it
  executable.

Diagram source MODEL-BASED SYNTHESIS OF
GENERATORS FOR EMBEDDED SYSTEMS, Gabor Karsai,
ISIS, Vanderbilt University.
10
The GReAT Language - components

• Has 3 Major Parts
• The Pattern Specification language is the
  primary expressivity-enhancing mechanism.
  Consists of
• Simple patterns
• Patterns with a fixed cardinality.
• Patterns with a variable cardinality.
• The Rewriting and Transformation language is
  the structural-integrity-enforcement mechanism.
• The High Level Control Flow language
  Reincorporates some ideas from traditional
  textual languages. Supports the following control
  structures
• Sequencing
• Non-determinism
• Hierarchy
• Recursion
• Test-Case

11
Pattern Specification Language

• Review of Graph concepts as used here
• A graph G is pair (GV, GE), Where GV is a set of
  vertices in the graph and GE is the set of edges
  and ?e (etype, src, dst) ? GE,
• (src ? GV) (dst ? GV)
• A match M is a pair (MVB, MEB), where MVB is a
  set of vertex bindings and MEB is a set of edge
  bindings.
• A vertex binding VB is a pair (PV, HV) where PV
  is a pattern vertex and HV is a host vertex.
• An edge binding EB is a pair (PE, HE) where PE is
  a pattern edge and HV is a host edge.
• Partial matches are allowed (no restriction on M
  that specifies that each pattern object must be
  bound).

12
Pattern Specification Language

• Simple patterns

• A simple pattern is one in which the pattern
  represents the exact sub-graph.
• The catch lies in ensuring the determinism of the
  match (the same match must be returned for each
  invocation of the pattern matcher on the same
  graph and pattern).

13
Pattern Specification Language resolving
ambiguity

• Simple patterns

• The above pattern can match with both (P1,T1),
  (P2,T3), (P3,T2) and (P1,T3), (P2,T5),
  (P3,T4).
• One solution is to return the set of all matches.
• This is expensive - O(hp) where h is the number
  of host vertices and p is the number pattern
  vertices.

14
Pattern Specification Language resolving
ambiguity

• Simple patterns

• The approach taken in GReAT is to limit the set
  of valid matches by assigning an initial binding
  that establishes a context.
• The initial binding reduces the search complexity
  in two ways,
• The exponential is reduced to only the unmatched
  pattern vertices and
• Only host graph elements within a distance d from
  the bound vertex are used for the search, where d
  is the longest pattern path from the bound
  pattern vertex.

15
Pattern Specification Language

• Fixed cardinality patterns

• Inspired by regular expression like syntax s5o
  sooooo example .
• This is realized by altering
• The pattern vertex definition to a pair (class,
  cardinality), where cardinality is an integer.
• The vertex binding definition to a pair (PV,
  HVS), where PV is a pattern vertex and HVS is a
  set of host vertices.
• The above match is thus (P1,T1), (P2,T2, T3,
  T4, T5, T6).

16
Pattern Specification Language ambiguity
resolution

• Fixed cardinality patterns

• It is not entirely intuitively obvious what
  semantics to assign a fixed cardinality pattern
  such as the one in the LHS above.
• One possible interpretation is what is referred
  to as set semantics. Treat each pattern vertex
  as representing a set of vertices in the host
  graph. This results in the match as shown on the
  RHS.
• While this is a simple and unambiguous
  interpretation, it is difficult to express some
  patterns with this semantics.

17
Pattern Specification Language ambiguity
resolution

• Fixed cardinality patterns

• The alternate is an interpretation as shown in
  the RHS above, also referred to as tree
  semantics.
• The semantics is weaker in the sense that it
  returns multiple conflicting matches.

18
Pattern Specification Language ambiguity
resolution

• Solution Extended Set Semantics

• Also inspired by regular expressions s3(xy)
  sxyxyxy example
• Introduces the notion of a group with a
  cardinality n, that will match n sub graphs.

19
Pattern Specification Language ambiguity
resolution

• Solution Extended Set Semantics

• Also inspired by regular expressions s3(xy)
  sxyxyxy example
• Introduces the notion of a group with a
  cardinality n, that will match n sub graphs.

20
Pattern Specification Language

• Variable Cardinality Patterns

• Variable cardinality patterns can be used to
  represent a family of graphs.
• (Completes the regular expression metaphor).

21
Graph Rewriting/Transformation Language

• A UML language for describing graph
  transformations.
• Partly declarative, partly imperative. The
  imperative part is partitioned into the control
  flow language.
• The declarative part is the input to the pattern
  matcher, it is composed of a hierarchical
  sequential structure of productions.
• The basic transformation description entity is
  the production.
• A production contains a pattern graph which
  confirms to the combined metamodel of the source,
  target and temporary objects

22
Graph Rewriting/Transformation Language

• Each object in the pattern graph belongs to a
  type.
• Additionally, each object is associated with a
  role that specifies the role it plays in the
  transformation.

23
Graph Rewriting/Transformation Language

• There are three different roles that a pattern
  object can play. They are
• bind The object is used to match objects in the
  graph.
• delete The object is used to match objects, but
  once the match is computed, the objects are
  deleted.
• new After the match is computed, new objects are
  created.

24
Graph Rewriting/Transformation Language

• The conditions for the match that are not
  captured by the pattern objects alone, can be
  additionally defined as constraints on attributes
  using OCL.
• If the mapping involves transformation of
  attributes, that is specified using attribute
  mapping objects.

25
Graph Rewriting/Transformation Language

• The formal definition of a production is as
  follows. A production P is a triple
• (pattern graph, guard, attribute mapping), where
• Pattern graph is a graph
• Pattern Role is a mapping for each pattern
  vertex/edge to an element of role bind,
  delete, new.
• Guard is a boolean-valued expression that
  operates on the vertex and edge attributes. If
  the guard is false, then the production will not
  execute any operations.
• Attribute mapping is a set of assignment
  statements that specify values for attributes and
  can use values of other edge and vertex
  attributes.

26
Graph Rewriting/Transformation Language

• Firing of productions involves matching every
  pattern object marked either bind or delete.
• If
• the pattern matcher is successful in finding
  matches for the pattern
• then
• for each match the pattern objects marked delete
  are deleted, and pattern objects marked new are
  created.
• Conflicting deletes are rejected.
• Only those objects can be deleted that are bound
  exactly once across all the matches.

27
Control Flow Language

• UML Model of the control flow language

28
Control Flow Language

• Components of the Control Flow language and their
  functions
• Ports pass the bindings (packets) that
  establish the context for a given rule.
• Sequencing establishes a meaningful order to
  rule firing as determined by the generator
  programmer.
• Non-determinism provides for expression of
  concurrent execution.

29
Control Flow Language

• Hierarchy - Rules can contain rules within them.
• Recursion - A high level rule can call itself.
• Test-Case facilitates conditional branching

30
Control Flow Language

• Sequencing of rules example (2 rule sequence)

31
Control Flow Language

• Nesting of rules example

32
Control Flow Language

• Nesting of rules semantics of a block

33
Control Flow Language

• Nesting of rules semantics of a for block

34
Control Flow Language

• Realizing conditional flow with Test/Case

35
Control Flow Language

• Detail Execution of a single Case

36
Control Flow Language

• Concurrency / Nondeterminism

37
Control Flow Language

• Concurrency / Nondeterminism

38
Control Flow Language

• Concurrency / Nondeterminism

39
Control Flow Language

• Concurrency / Nondeterminism

40
Control Flow Language

• Termination

• A sequence of rules is said to have terminated if
  either
• a rule has no output interface, or,
• a rule having an output interface does not
  produce any output packets.
• Also, If the firing of a rule produces zero
  output packets then the rules following it will
  not be executed.

41
Implementation of GReAT

• GReAT is implemented using the GME framework.
• The UDM package is used to generate a meta-model
  specific C API that can be used to traverse the
  models.

42
Implementation of GReAT

• The interpreter consists of code in a
  conventional programming language (such as C)
  that is implemented at the user application level
  of the GME architecture

43
Implementation of GReAT

• The implementation consists of 2 major
  components,
• The Sequencer
• The Rule Extractor, which in turn is composed of
• The Pattern Matcher and
• The Effector (O/P Generator)

44
Typical GReAT Usage

• Build Transformation model ??
• Attach all UML class diagrams using either
  MetaGME2UMT or by attaching UML class diagrams as
  libraries.
• Build the transformation rules
• Build configuration model,
• Run Transformation model
• Phase I
• Invoke GReAT Master interpreter
• Phase II
• Run GR Engine to perform the transformation rules
  on input model.
• Run GR Debugger (GRD.exe) to locate bugs in a
  transformation rules.
• Phase III Run Code Generator to generate C
  code from the transformation rules.

45
Relevance to my research/project

• For 762 Model one or more of the following
  patterns in monophonic audio at multiple levels
  of abstraction
• At the level of conceptualization of
  melody/effect
• Artist specific patterns that define an artists
  style.
• Genre specific patterns that define a class of
  music.
• Instrument specific patterns that define the
  artifacts of the physical limitations of the
  instrument on the structure of the musical
  content.
• Using GME Manual Interpreter Implementation (no
  GReAT)
• For thesis A middleware architecture DSL for
  music content authoring/management.

46
References

• Agrawal A., Karsai G., Kalmar Z., Neema S., Shi
  F., Vizhanyo A. The Design of a Simple Language
  for Graph Transformations, Journal in Software
  and System Modeling, in review, 2005.
• Agrawal A. A Formal Graph-Transformation Based
  Language for Model-to-Model Transformations, PhD
  Dissertation, Vanderbilt University, Dept of
  EECS, August, 2004.
• Aditya A.GReAT A Metamodel Based Model
  Transformation Language Vanderbilt University
• Agrawal A., Karsai G., Shi F. Graph
  Transformations on Domain-Specific Models,
  ISIS-03-403, November, 2003.
• Aditya Agrawal Zsolt Kalmar Gabor Karsai Feng Shi
  Attila Vizhanyo, GReAT User Manual ISIS,
  Vanderbilt University November 2003
• Vanderbilt University, GME4 Users Manual, March
  2004.