Upload
palmer
View
74
Download
0
Tags:
Embed Size (px)
DESCRIPTION
GReAT. Vamshi Raghu 7 th April 2005. 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. - PowerPoint PPT Presentation
Citation preview
7th April 2005 Vamshi Raghu 1
GReAT
Vamshi Raghu
7th April 2005
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 4
Origin
Developed at the Institute for Software Integrated Systemsrsquo (ISIS) Vanderbilt University as part of the ldquoModel-Based Synthesis of Generators for Embedded Systemsrdquo project which is a part of the DARPA ldquoModel Based Integration of Embedded Systemsrdquo (MoBIES) project
The goal of the project is to ldquobuild reusable technology for model interpreters for embedded systemsrdquo
7th April 2005 Vamshi Raghu 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)
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 4
Origin
Developed at the Institute for Software Integrated Systemsrsquo (ISIS) Vanderbilt University as part of the ldquoModel-Based Synthesis of Generators for Embedded Systemsrdquo project which is a part of the DARPA ldquoModel Based Integration of Embedded Systemsrdquo (MoBIES) project
The goal of the project is to ldquobuild reusable technology for model interpreters for embedded systemsrdquo
7th April 2005 Vamshi Raghu 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)
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 4
Origin
Developed at the Institute for Software Integrated Systemsrsquo (ISIS) Vanderbilt University as part of the ldquoModel-Based Synthesis of Generators for Embedded Systemsrdquo project which is a part of the DARPA ldquoModel Based Integration of Embedded Systemsrdquo (MoBIES) project
The goal of the project is to ldquobuild reusable technology for model interpreters for embedded systemsrdquo
7th April 2005 Vamshi Raghu 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)
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 4
Origin
Developed at the Institute for Software Integrated Systemsrsquo (ISIS) Vanderbilt University as part of the ldquoModel-Based Synthesis of Generators for Embedded Systemsrdquo project which is a part of the DARPA ldquoModel Based Integration of Embedded Systemsrdquo (MoBIES) project
The goal of the project is to ldquobuild reusable technology for model interpreters for embedded systemsrdquo
7th April 2005 Vamshi Raghu 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)
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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)
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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 itrsquos roots in the effort to use GME itself to automate the building of interpreters for domain-specific visual languages (ldquoparadigmsrdquo) defined using the GME suite
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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 itrsquos programming constructs (constant factor slow down from hand written code)
The language must make generator writers more productive
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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
SoftwarePlatform
Output ModelMapping ModelInput Model
Generator Models
Meta-Generator
Domain-SpecificModels
Platform-SpecificCodeData
DomainPlatform-Specific
Generator
Domain Generation System Generation Process
Meta- Generation Generator Generation Process
Describes Describes
Executes
Diagram source ldquoMODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMSrdquo Gabor Karsai ISIS Vanderbilt University
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 10
The GReAT Language - components Has 3 Major Parts
The Pattern Specification language ndash 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 ndash is the structural-integrity-enforcement mechanism
The High Level Control Flow language ndash Reincorporates some ideas from traditional textual languages Supports the following control structures Sequencing Non-determinism Hierarchy Recursion Test-Case
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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 foralle = (etype src dst) GEisin
(src GV) ^ (isin dst GV)isin 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 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 12
Pattern Specification Language
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)
Simple patterns
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 13
Pattern Specification Language ndash resolving ambiguity
The above pattern can match with both (P1T1) (P2T3) (P3T2) and (P1T3) (P2T5) (P3T4)
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
Simple patterns
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 14
Pattern Specification Language ndash resolving ambiguity
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
Simple patterns
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 15
Pattern Specification Language
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 (P1T1) (P2T2 T3 T4 T5 T6)
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 16
Pattern Specification Language ndash ambiguity resolution
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 ldquoset semanticsrdquo 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
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 17
Pattern Specification Language ndash ambiguity resolution
The alternate is an interpretation as shown in the RHS above also referred to as ldquotree semanticsrdquo
The semantics is ldquoweakrdquoer in the sense that it returns multiple conflicting matches
Fixed cardinality patterns
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 18
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 19
Pattern Specification Language ndash ambiguity resolution
Also inspired by regular expressions [ s3(xy) = sxyxyxy example ]
Introduces the notion of a ldquogrouprdquo with a cardinality n that will match n sub graphs
Solution Extended Set Semantics
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 20
Pattern Specification Language
Variable cardinality patterns can be used to represent a family of graphs
(Completes the regular expression metaphor)
Variable Cardinality Patterns
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 21
Graph RewritingTransformation 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 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 22
Graph RewritingTransformation 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 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 23
Graph RewritingTransformation 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 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 24
Graph RewritingTransformation 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 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 25
Graph RewritingTransformation 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
vertexedge 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 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 26
Graph RewritingTransformation 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 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 27
Control Flow Language UML Model of the control flow language
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 28
Control Flow Language Components of the Control
Flow language and their functions ndash Ports ndash pass the bindings
(ldquopacketsrdquo) that establish the context for a given rule
Sequencing ndash establishes a meaningful order to rule firing as determined by the generator programmer
Non-determinism ndash provides for expression of concurrent execution
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 29
Control Flow Language
Hierarchy - Rules can contain rules within them
Recursion - A high level rule can call itself
Test-Case ndash facilitates conditional branching
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 30
Control Flow LanguageSequencing of rules ndash example (2 rule sequence)
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 31
Control Flow Language
Nesting of rules ndash example
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 32
Control Flow LanguageNesting of rules ndash semantics of a block
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 33
Control Flow LanguageNesting of rules ndash semantics of a for block
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 34
Control Flow LanguageRealizing conditional flow with TestCase
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 35
Control Flow Language
Detail Execution of a single Case
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
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
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 38
Control Flow Language
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 39
Control Flow Language
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 39
Control Flow Language
Concurrency Nondeterminism
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 40
Control Flow Language
Termination
bull A sequence of rules is said to have terminated if eitherbull a rule has no output interface or bull a rule having an output interface does not
produce any output packets
bull 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 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 41
Implementation of GReAT
bull GReAT is implemented using the GME framework
bull 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 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 42
Implementation of GReAT
bull 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 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 43
Implementation of GReAT
bull The implementation consists of 2 major componentsbull The Sequencerbull The Rule Extractor which
in turn is composed of bull The Pattern Matcher andbull The Effector (OP
Generator)
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 44
Typical GReAT Usage Build Transformation model 1048707
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 (GRDexe) 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 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 45
Relevance to my researchproject
For 762 Model one or more of the following patterns in monophonic audio at multiple levels of abstraction At the level of conceptualization of melodyeffect
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 authoringmanagement
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004
7th April 2005 Vamshi Raghu 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 AGReAT 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 Userrsquos Manual March 2004