Get documents about "GReAT
Document Sample
GReAT
Vamshi Raghu
7th April 2005
7th April 2005 Vamshi Raghu 1
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
7th April 2005 Vamshi Raghu 2
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.
7th April 2005 Vamshi Raghu 3
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”.
7th April 2005 Vamshi Raghu 4
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!)
7th April 2005 Vamshi Raghu 5
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 it’s 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.
7th April 2005 Vamshi Raghu 6
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.
7th April 2005 Vamshi Raghu 7
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 it’s programming constructs. (constant factor slow
down from hand written code).
The language must make generator writers more
productive.
7th April 2005 Vamshi Raghu 8
The role of GReAT in the DSDE
generation process
Meta-Generation: Generator Generation Process
Generator Models
Input Model Mapping Model Output Model The GReAT language
defines the syntax and
Describes
Meta-Generator Describes semantics of a graph
transformation language
which encodes the pattern
Domain-Specific Domain/Platform-Specific
Platform-Specific
matching and
Models Generator Code/Data transformation idioms that
Domain Generation: System Generation Process
Executes
are repeated in manual
interpreter writing.
Software
Platform The GReAT interpreter
realizes the semantics of
Diagram source: “MODEL- the transformation language
BASED SYNTHESIS OF
GENERATORS FOR by making it executable.
EMBEDDED SYSTEMS”, Gabor
Karsai, ISIS, Vanderbilt
University.
7th April 2005 Vamshi Raghu 9
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
7th April 2005 Vamshi Raghu 10
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).
7th April 2005 Vamshi Raghu 11
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).
7th April 2005 Vamshi Raghu 12
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.
7th April 2005 Vamshi Raghu 13
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.
7th April 2005 Vamshi Raghu 14
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})}.
7th April 2005 Vamshi Raghu 15
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.
7th April 2005 Vamshi Raghu 16
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 “weak”er in the sense that it
returns multiple conflicting matches.
7th April 2005 Vamshi Raghu 17
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.
7th April 2005 Vamshi Raghu 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.
7th April 2005 Vamshi Raghu 19
Pattern Specification Language
Variable Cardinality Patterns
Variable cardinality patterns can be used to represent a
family of graphs.
(Completes the regular expression metaphor).
7th April 2005 Vamshi Raghu 20
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
7th April 2005 Vamshi Raghu 21
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.
7th April 2005 Vamshi Raghu 22
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.
7th April 2005 Vamshi Raghu 23
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.
7th April 2005 Vamshi Raghu 24
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.
7th April 2005 Vamshi Raghu 25
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.
7th April 2005 Vamshi Raghu 26
Control Flow Language
UML Model of the control flow language
7th April 2005 Vamshi Raghu 27
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.
7th April 2005 Vamshi Raghu 28
Control Flow Language
Hierarchy - Rules can
contain rules within
them.
Recursion - A high level
rule can call itself.
Test-Case – facilitates
conditional branching
7th April 2005 Vamshi Raghu 29
Control Flow Language
Sequencing of rules – example (2 rule sequence)
7th April 2005 Vamshi Raghu 30
Control Flow Language
Nesting of rules – example
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules – semantics of a block
7th April 2005 Vamshi Raghu 32
Control Flow Language
Nesting of rules – semantics of a for block
7th April 2005 Vamshi Raghu 33
Control Flow Language
Realizing conditional flow with Test/Case
7th April 2005 Vamshi Raghu 34
Control Flow Language
Detail: Execution of a single Case
7th April 2005 Vamshi Raghu 35
Control Flow Language
Concurrency / Nondeterminism
7th April 2005 Vamshi Raghu 36
Control Flow Language
Concurrency / Nondeterminism
7th April 2005 Vamshi Raghu 37
Control Flow Language
Concurrency / Nondeterminism
7th April 2005 Vamshi Raghu 38
Control Flow Language
Concurrency / Nondeterminism
7th April 2005 Vamshi Raghu 39
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.
7th April 2005 Vamshi Raghu 40
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.
7th April 2005 Vamshi Raghu 41
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
7th April 2005 Vamshi Raghu 42
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)
7th April 2005 Vamshi Raghu 43
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.
7th April 2005 Vamshi Raghu 44
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.
7th April 2005 Vamshi Raghu 45
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 User’s Manual, March 2004.
7th April 2005 Vamshi Raghu 46
Related docs
Other docs by ewghwehws
Control system for dynamoelectric machines with differentially excited fields
Views: 0 | Downloads: 0
