1. 7th April 2005Vamshi Raghu1 GReAT Vamshi Raghu 7 th April 2005

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

3. 7th April 2005Vamshi Raghu3 What is GReAT ? Graph Rewriting And Transformation. A model compiler compiler (right now, a model compiler interpreter). A language and a tool chain. A UML-friendly graph-based language for expressing model to model transformations. A suite of tools that support the use of this language to generate model to model transformers from visual specifications.

4. 7th April 2005Vamshi Raghu4 Origin Developed at the Institute for Software Integrated Systems’ (ISIS), Vanderbilt University, as part of the “Model-Based Synthesis of Generators for Embedded Systems” project, which is a part of the DARPA “Model Based Integration of Embedded Systems” (MoBIES) project. The goal of the project is to “build reusable technology for.. model interpreters for embedded systems”.

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

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

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

8. 7th April 2005Vamshi Raghu8 GReAT Design Goals The language should provide for a way to specify the input and output domains. The language should provide for a way to model all the intermediate objects created during the transformation (model the steps). The language must be Turing complete. The language should have efficient implementations of it’s programming constructs. (constant factor slow down from hand written code). The language must make generator writers more productive.

9. 7th April 2005Vamshi Raghu9 The role of GReAT in the DSDE generation process The GReAT language defines the syntax and semantics of a graph transformation language which encodes the pattern matching and transformation idioms that are repeated in manual interpreter writing. The GReAT interpreter realizes the semantics of the transformation language by making it executable. Diagram source: “MODEL- BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMS”, Gabor Karsai, ISIS, Vanderbilt University.

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

11. 7th April 2005Vamshi Raghu11 Pattern Specification Language Review of Graph concepts as used here: A graph G is pair (GV, GE), Where GV is a set of vertices in the graph and GE is the set of edges and ∀ e = (etype, src, dst) ∈ GE,  (src ∈ GV) ^ (dst ∈ GV) A match M is a pair (MVB, MEB), where MVB is a set of vertex bindings and MEB is a set of edge bindings. A vertex binding VB is a pair (PV, HV) where PV is a pattern vertex and HV is a host vertex. An edge binding EB is a pair (PE, HE) where PE is a pattern edge and HV is a host edge. Partial matches are allowed (no restriction on M that specifies that each pattern object must be bound).

12. 7th April 2005Vamshi Raghu12 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

13. 7th April 2005Vamshi Raghu13 Pattern Specification Language – resolving ambiguity The above pattern can match with both {(P1,T1), (P2,T3), (P3,T2)} and {(P1,T3), (P2,T5), (P3,T4)}. One solution is to return the set of all matches. This is expensive - O(h p ) where h is the number of host vertices and p is the number pattern vertices. Simple patterns

14. 7th April 2005Vamshi Raghu14 Pattern Specification Language – 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

15. 7th April 2005Vamshi Raghu15 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 {(P1,T1), (P2,{T2, T3, T4, T5, T6})}. Fixed cardinality patterns

16. 7th April 2005Vamshi Raghu16 Pattern Specification Language – 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 “set semantics”. Treat each pattern vertex as representing a set of vertices in the host graph. This results in the match as shown on the RHS. While this is a simple and unambiguous interpretation, it is difficult to express some patterns with this semantics. Fixed cardinality patterns

17. 7th April 2005Vamshi Raghu17 Pattern Specification Language – ambiguity resolution The alternate is an interpretation as shown in the RHS above, also referred to as “tree semantics”. The semantics is “weak”er in the sense that it returns multiple conflicting matches. Fixed cardinality patterns

18. 7th April 2005Vamshi Raghu18 Pattern Specification Language – ambiguity resolution Also inspired by regular expressions [ s3(xy) = sxyxyxy example ] Introduces the notion of a “group” with a cardinality n, that will match n sub graphs. Solution: Extended Set Semantics

19. 7th April 2005Vamshi Raghu19 Pattern Specification Language – ambiguity resolution Also inspired by regular expressions [ s3(xy) = sxyxyxy example ] Introduces the notion of a “group” with a cardinality n, that will match n sub graphs. Solution: Extended Set Semantics

20. 7th April 2005Vamshi Raghu20 Pattern Specification Language Variable cardinality patterns can be used to represent a family of graphs. (Completes the regular expression metaphor). Variable Cardinality Patterns

21. 7th April 2005Vamshi Raghu21 Graph Rewriting/Transformation Language A UML language for describing graph transformations. Partly declarative, partly imperative. The imperative part is partitioned into the control flow language. The declarative part is the input to the pattern matcher, it is composed of a hierarchical + sequential structure of productions. The basic transformation description entity is the production. A production contains a pattern graph which confirms to the combined metamodel of the source, target and temporary objects

22. 7th April 2005Vamshi Raghu22 Graph Rewriting/Transformation Language Each object in the pattern graph belongs to a type. Additionally, each object is associated with a role that specifies the role it plays in the transformation.

23. 7th April 2005Vamshi Raghu23 Graph Rewriting/Transformation Language There are three different roles that a pattern object can play. They are: bind: The object is used to match objects in the graph. delete: The object is used to match objects, but once the match is computed, the objects are deleted. new: After the match is computed, new objects are created.

24. 7th April 2005Vamshi Raghu24 Graph Rewriting/Transformation Language The conditions for the match that are not captured by the pattern objects alone, can be additionally defined as constraints on attributes using OCL. If the mapping involves transformation of attributes, that is specified using attribute mapping objects.

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

26. 7th April 2005Vamshi Raghu26 Graph Rewriting/Transformation Language Firing of productions involves matching every pattern object marked either bind or delete. If the pattern matcher is successful in finding matches for the pattern then for each match the pattern objects marked delete are deleted, and pattern objects marked new are created. Conflicting deletes are rejected. Only those objects can be deleted that are bound exactly once across all the matches.

27. 7th April 2005Vamshi Raghu27 Control Flow Language UML Model of the control flow language

28. 7th April 2005Vamshi Raghu28 Control Flow Language Components of the Control Flow language and their functions – Ports – pass the bindings (“packets”) that establish the context for a given rule. Sequencing – establishes a meaningful order to rule firing as determined by the generator programmer. Non-determinism – provides for expression of concurrent execution.

29. 7th April 2005Vamshi Raghu29 Control Flow Language Hierarchy - Rules can contain rules within them. Recursion - A high level rule can call itself. Test-Case – facilitates conditional branching

30. 7th April 2005Vamshi Raghu30 Control Flow Language Sequencing of rules – example (2 rule sequence)

31. 7th April 2005Vamshi Raghu31 Control Flow Language Nesting of rules – example

32. 7th April 2005Vamshi Raghu32 Control Flow Language Nesting of rules – semantics of a block

33. 7th April 2005Vamshi Raghu33 Control Flow Language Nesting of rules – semantics of a for block

34. 7th April 2005Vamshi Raghu34 Control Flow Language Realizing conditional flow with Test/Case

35. 7th April 2005Vamshi Raghu35 Control Flow Language Detail: Execution of a single Case

36. 7th April 2005Vamshi Raghu36 Control Flow Language Concurrency / Nondeterminism

37. 7th April 2005Vamshi Raghu37 Control Flow Language Concurrency / Nondeterminism

38. 7th April 2005Vamshi Raghu38 Control Flow Language Concurrency / Nondeterminism

39. 7th April 2005Vamshi Raghu39 Control Flow Language Concurrency / Nondeterminism

40. 7th April 2005Vamshi Raghu40 Control Flow Language Termination A sequence of rules is said to have terminated if either: a rule has no output interface, or, a rule having an output interface does not produce any output packets. Also, If the firing of a rule produces zero output packets then the rules following it will not be executed.

41. 7th April 2005Vamshi Raghu41 Implementation of GReAT GReAT is implemented using the GME framework. The UDM package is used to generate a meta-model specific C++ API that can be used to traverse the models.

42. 7th April 2005Vamshi Raghu42 Implementation of GReAT The interpreter consists of code in a conventional programming language (such as C++) that is implemented at the user application level of the GME architecture

43. 7th April 2005Vamshi Raghu43 Implementation of GReAT The implementation consists of 2 major components, The Sequencer The Rule Extractor, which in turn is composed of The Pattern Matcher and The Effector (O/P Generator)

44. 7th April 2005Vamshi Raghu44 Typical GReAT Usage Build Transformation model: Attach all UML class diagrams using either MetaGME2UMT or by attaching UML class diagrams as libraries. Build the transformation rules; Build configuration model, Run Transformation model: Phase I: Invoke GReAT Master interpreter Phase II: Run GR Engine to perform the transformation rules on input model. Run GR Debugger (GRD.exe) to locate bugs in a transformation rules. Phase III: Run Code Generator to generate C++ code from the transformation rules.

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

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