Great
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

GReAT PowerPoint PPT Presentation


  • 166 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Great

GReAT

Vamshi Raghu

7th April 2005

Vamshi Raghu


Outline

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


What is great

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


Origin

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


Origin continued

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


Motivation in relation to gme

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


Motivation extending the state of the art

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


Great design goals

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


The role of great in the dsde generation process

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


The great language components

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


Pattern specification language

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


Pattern specification language1

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


Pattern specification language resolving ambiguity

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


Pattern specification language resolving ambiguity1

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


Pattern specification language2

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


Pattern specification language ambiguity resolution

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


Pattern specification language ambiguity resolution1

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


Pattern specification language ambiguity resolution2

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


Pattern specification language ambiguity resolution3

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


Pattern specification language3

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


Graph rewriting transformation language

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


Graph rewriting transformation language1

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


Graph rewriting transformation language2

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


Graph rewriting transformation language3

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


Graph rewriting transformation language4

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


Graph rewriting transformation language5

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


Control flow language

Control Flow Language

  • UML Model of the control flow language

Vamshi Raghu


Control flow language1

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


Control flow language2

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


Control flow language3

Control Flow Language

Sequencing of rules – example (2 rule sequence)

Vamshi Raghu


Control flow language4

Control Flow Language

Nesting of rules – example

Vamshi Raghu


Control flow language5

Control Flow Language

Nesting of rules – semantics of a block

Vamshi Raghu


Control flow language6

Control Flow Language

Nesting of rules – semantics of a for block

Vamshi Raghu


Control flow language7

Control Flow Language

Realizing conditional flow with Test/Case

Vamshi Raghu


Control flow language8

Control Flow Language

Detail: Execution of a single Case

Vamshi Raghu


Control flow language9

Control Flow Language

Concurrency / Nondeterminism

Vamshi Raghu


Control flow language10

Control Flow Language

Concurrency / Nondeterminism

Vamshi Raghu


Control flow language11

Control Flow Language

Concurrency / Nondeterminism

Vamshi Raghu


Control flow language12

Control Flow Language

Concurrency / Nondeterminism

Vamshi Raghu


Control flow language13

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


Implementation of great

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


Implementation of great1

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


Implementation of great2

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


Typical great usage

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


Relevance to my research project

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


References

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


  • Login