1 / 46

GReAT

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.

palmer
Télécharger la présentation

GReAT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GReAT Vamshi Raghu 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 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. Vamshi Raghu

  4. Origin • Developed at the Institute for Software Integrated Systems’ (ISIS), Vanderbilt University, as part of the “Model-Based Synthesis of Generators for Embedded Systems” project, which is a part of the DARPA “Model Based Integration of Embedded Systems” (MoBIES) project. • The goal of the project is to “build reusable technology for .. model interpreters for embedded systems”. 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!) 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 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. 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. 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 it’s programming constructs. (constant factor slow down from hand written code). • The language must make generator writers more productive. 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. Diagram source: “MODEL-BASED SYNTHESIS OF GENERATORS FOR EMBEDDED SYSTEMS”, Gabor Karsai, ISIS, Vanderbilt University. Vamshi Raghu

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

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

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

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

  15. Pattern Specification Language • Fixed cardinality patterns • Inspired by regular expression like syntax [ s5o = sooooo example ]. • This is realized by altering • The pattern vertex definition to a pair (class, cardinality), where cardinality is an integer. • The vertex binding definition to a pair (PV, HVS), where PV is a pattern vertex and HVS is a set of host vertices. • The above match is thus {(P1,T1), (P2,{T2, T3, T4, T5, T6})}. Vamshi Raghu

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

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

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

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

  20. Pattern Specification Language • Variable Cardinality Patterns • Variable cardinality patterns can be used to represent a family of graphs. • (Completes the regular expression metaphor). Vamshi Raghu

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

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

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

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

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

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

  27. Control Flow Language • UML Model of the control flow language Vamshi Raghu

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

  29. Control Flow Language • Hierarchy - Rules can contain rules within them. • Recursion - A high level rule can call itself. • Test-Case – facilitates conditional branching Vamshi Raghu

  30. Control Flow Language Sequencing of rules – example (2 rule sequence) Vamshi Raghu

  31. Control Flow Language Nesting of rules – example Vamshi Raghu

  32. Control Flow Language Nesting of rules – semantics of a block Vamshi Raghu

  33. Control Flow Language Nesting of rules – semantics of a for block Vamshi Raghu

  34. Control Flow Language Realizing conditional flow with Test/Case Vamshi Raghu

  35. Control Flow Language Detail: Execution of a single Case Vamshi Raghu

  36. Control Flow Language Concurrency / Nondeterminism Vamshi Raghu

  37. Control Flow Language Concurrency / Nondeterminism Vamshi Raghu

  38. Control Flow Language Concurrency / Nondeterminism Vamshi Raghu

  39. Control Flow Language Concurrency / Nondeterminism Vamshi Raghu

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

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

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

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

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

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

More Related