46
7th April 2005 Vamshi Raghu 1 GReAT Vamshi Raghu 7 th April 2005

GReAT

  • Upload
    palmer

  • View
    74

  • Download
    0

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

Page 1: GReAT

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

Page 2: GReAT

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

Page 3: GReAT

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

Page 4: GReAT

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

Page 5: GReAT

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

Page 6: GReAT

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

Page 7: GReAT

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

Page 8: GReAT

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

Page 9: GReAT

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

Page 10: GReAT

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

Page 11: GReAT

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

Page 12: GReAT

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

Page 13: GReAT

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

Page 14: GReAT

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

Page 15: GReAT

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

Page 16: GReAT

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

Page 17: GReAT

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

Page 18: GReAT

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

Page 19: GReAT

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

Page 20: GReAT

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

Page 21: GReAT

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

Page 22: GReAT

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

Page 23: GReAT

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

Page 24: GReAT

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

Page 25: GReAT

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

Page 26: GReAT

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

Page 27: GReAT

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

Page 28: GReAT

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

Page 29: GReAT

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

Page 30: GReAT

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

Page 31: GReAT

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

Page 32: GReAT

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

Page 33: GReAT

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

Page 34: GReAT

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

Page 35: GReAT

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

Page 36: GReAT

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

Page 37: GReAT

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

Page 38: GReAT

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

Page 39: GReAT

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

Page 40: GReAT

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

Page 41: GReAT

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

Page 42: GReAT

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

Page 43: GReAT

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

Page 44: GReAT

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

Page 45: GReAT

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

Page 46: GReAT

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