Docstoc

GReAT

Document Sample
GReAT Powered By Docstoc
					                    GReAT

                 Vamshi Raghu
                 7th April 2005



7th April 2005           Vamshi Raghu   1
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   2
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     3
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”.
           7th April 2005   Vamshi Raghu   4
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   5
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.




              7th April 2005   Vamshi Raghu           6
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     7
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.

            7th April 2005   Vamshi Raghu   8
The role of GReAT in the DSDE
generation process
Meta-Generation: Generator Generation Process
                     Generator Models
      Input Model        Mapping Model           Output Model                  The GReAT language
                                                                                defines the syntax and
Describes
                      Meta-Generator                    Describes               semantics of a graph
                                                                                transformation language
                                                                                which encodes the pattern
  Domain-Specific   Domain/Platform-Specific
                                                Platform-Specific
                                                                                matching and
     Models               Generator                Code/Data                    transformation idioms that
Domain Generation: System Generation Process
                                                  Executes
                                                                                are repeated in manual
                                                                                interpreter writing.
                                                   Software
                                                   Platform                    The GReAT interpreter
                                                                                realizes the semantics of
   Diagram source: “MODEL-                                                      the transformation language
   BASED SYNTHESIS OF
   GENERATORS FOR                                                               by making it executable.
   EMBEDDED SYSTEMS”, Gabor
   Karsai, ISIS, Vanderbilt
   University.

                       7th April 2005                        Vamshi Raghu                  9
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




                  7th April 2005         Vamshi Raghu            10
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).


                7th April 2005     Vamshi Raghu    11
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).

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

              7th April 2005   Vamshi Raghu         13
    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.

                     7th April 2005     Vamshi Raghu               14
    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})}.
                 7th April 2005      Vamshi Raghu               15
    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.

                7th April 2005     Vamshi Raghu              16
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.
             7th April 2005   Vamshi Raghu   17
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.

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

               7th April 2005   Vamshi Raghu            19
Pattern Specification Language
   Variable Cardinality Patterns




   Variable cardinality patterns can be used to represent a
    family of graphs.
   (Completes the regular expression metaphor).


              7th April 2005   Vamshi Raghu          20
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




              7th April 2005   Vamshi Raghu          21
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.




             7th April 2005   Vamshi Raghu           22
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.

              7th April 2005    Vamshi Raghu            23
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.



             7th April 2005   Vamshi Raghu          24
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.
              7th April 2005    Vamshi Raghu             25
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.


              7th April 2005    Vamshi Raghu            26
Control Flow Language
   UML Model of the control flow language




            7th April 2005   Vamshi Raghu    27
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.


     7th April 2005   Vamshi Raghu                     28
Control Flow Language

                                        Hierarchy - Rules can
                                         contain rules within
                                         them.
                                        Recursion - A high level
                                         rule can call itself.
                                        Test-Case – facilitates
                                         conditional branching




     7th April 2005   Vamshi Raghu                  29
Control Flow Language
Sequencing of rules – example (2 rule sequence)




           7th April 2005   Vamshi Raghu          30
Control Flow Language
Nesting of rules – example




        7th April 2005   Vamshi Raghu   31
Control Flow Language
Nesting of rules – semantics of a block




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




            7th April 2005   Vamshi Raghu     33
Control Flow Language
Realizing conditional flow with Test/Case




         7th April 2005   Vamshi Raghu      34
Control Flow Language
Detail: Execution of a single Case




        7th April 2005   Vamshi Raghu   35
Control Flow Language
Concurrency / Nondeterminism




       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
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.


             7th April 2005   Vamshi Raghu           40
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.

     7th April 2005   Vamshi Raghu             41
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


     7th April 2005   Vamshi Raghu               42
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)




     7th April 2005   Vamshi Raghu                    43
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.

                 7th April 2005    Vamshi Raghu              44
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.
               7th April 2005   Vamshi Raghu            45
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.

             7th April 2005   Vamshi Raghu          46

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:8/18/2012
language:
pages:46