1 / 41

GReAT: G raph Re writing A nd T ransformation

GReAT: G raph Re writing A nd T ransformation. Presenter: Yuehua Lin 2/17/04, Tuesday Slides help from Aditya Agrawal aditya.agrawal@vanderbilt.edu. Metamodeling. Tool Integration. Analysis. Metamodels. Domain models. Translation. Domain-specific modeling. Synthesis & Generation.

vachel
Download Presentation

GReAT: G raph Re writing A nd T ransformation

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: Graph Rewriting And Transformation Presenter: Yuehua Lin 2/17/04, Tuesday Slides help fromAditya Agrawal aditya.agrawal@vanderbilt.edu

  2. Metamodeling Tool Integration Analysis Metamodels Domain models Translation Domain-specific modeling Synthesis & Generation Model-Model Transformations Execution Domain-Specific MDA

  3. Metamodel Metamodel and Models Model Metamodel: a graph grammar of models

  4. B D 5 5 1 1 E C A 3 3 6 6 2 4 4 Input Graph Input Graph Output Graph Text File Model manipulation and transformation • Models are graphs • The most common operations are • Traversal and matching • Creation of secondary data structure • Text generation (e.g. code/config …) 1 2 3

  5. Research Hypothesis of GReAT Model transformations can be specified using graph transformations on metamodels. Using this approach we aim to achieve a significant increase in productivity in the development of such transformations. • Goals • Easy–to-use language for system developers • Increase productivity (order of 2 to 10) • Efficient execution (not more that 2 times slower than hand code)

  6. Source Models Model Transformation Specification Transformation Meta Meta Virtual Machine Target Model Model API Model API Metamodel of Source DS-PI Model DS-PI Model DS-PS Model DS-PS Model Metamodel of Target Overview Transformation Modeling Refers to Refers to Describes Describes Transformation Execution Input Output

  7. Graph Rewriting & Transformation (GReAT) • Pattern specification • Patterns with cardinality • Graph transformation and rewrite • Create New Objects • Delete Objects • Modify Attributes • High-level control flow • Hierarchy • Sequencing • Recursion • Branching

  8. Pattern Specification Language • Single cardinality PatternGraph HostGraph Cardinality n: a pattern vertex must match n host graph vertices.

  9. Pattern Specification Language (cont’d) • Fixed cardinality PatternGraph HostGraph

  10. Graph transformation language Bind Delete New A transformation rule example with pattern, guard and attribute mapping

  11. Control Flow Language • Sequencing of rules required • For efficiency • Understanding of the transformation • Intuitive for programmers • Control Constructs • Sequencing • Branch (Test/Case) • Hierarchy • Recursion Sequencing Hierarchy

  12. Transformation Engine A Virtual Machine

  13. Steps to Use GReAT Tools • Build Transformation model (provided by user): • meta models • transformation rules • configuration model • Run Transformation model • Run Master Interpreter to convert the above models to the required formats • Run GR engine/GRD engine to perform the transformation • Run Code Generator to generate C++ code if necessary

  14. GReAT Demo Description Demo Example: House2Order • This example converts a house model into a purchase order of door required to build the house. • Begin demo

  15. Demo 2: C-SAW • C-SAW is an aspect weaver that can weave crosscutting constraints/modifications in domain models automatically for rapid model transformation. http://www.gray-area.org/Research/C-SAW

  16. Framework of Aspect Model Weaver Input Models Specification aspects Strategies weaving engine Output Models

  17. Three Key Components • Specification aspects for specifying a set of locations in the domain models, e.g.a collection of models that have the same type; • Strategies for describing the crosscutting behavior and its associated model transformation, e.g.add new atoms to the specified models; • A weaving engine for performing the described transformations via interacting with the modeling environment. • All aspects and strategies are specified in Embedded Constraint Language (ECL).

  18. C-SAW Demo Description • Embedded System Modeling Language (ESML) is a domain-specific graphical modeling language developed for modeling real-time mission computing embedded avionics applications. • We have over 20 ESML component models that communicate with each other via a real-time event-channel mechanism. • Tasks: 1) Insert “Log” atoms to the ESML component models that have “data” atoms and create connections between the “Data” atom and the “Log” atom. 2) Insert two “Concurrency” atoms of different attributes to the component models that have at least one “data” atom.

  19. Play C-SAW Demo Video • http://www.gray-area.org/Research/C-SAW/

  20. Example: The Aspect Specification And Strategy

  21. Effect of Model Transformation Before Weaving After Weaving

  22. ESML Models (1/4) • The Embedded Systems Modeling Language (ESML) is a domain-specific graphical modeling language developed for modeling real-time mission computing embedded avionics applications. • The Model of Computation (MoC) used for ESML leverages elements from the CORBA Component Model [8] and the Boeing Bold Stroke architecture, which also uses a real-time event channel

  23. ESML Models (2/4) • In this model, components are complex, ported objects (typically consisting of multiple instances of different classes), which interact with each other through two mechanisms: • procedure invocation via component Receptacles (clients’ expressed dependencies on other component’s interfaces) to Facets (public server component interfaces), • event propagation through a publish/subscribe mechanism.

  24. ESML Models (3/4) • The above two mechanisms are typically combined in a “push-directed-pull” interaction pattern. • In this combined mode of operation, a publisher component notifies subscriber components about the availability of data, and the subscribers, when triggered, call “back” through their receptacles to the facet of the supplier to retrieve that data.

  25. ESML Models (4/4) • The ESML provides the following modeling categories to allow representation of an embedded system: a) Components, b) Component Interactions, and c) Component Configurations. • The embedded systems built using ESML are typically multi-threaded. • Thread types with their rates and priorities can be declared inside processors. By design, threads are related to subscribe ports: when the component receives a notification via the subscribe port, an associated thread wakes up and executes the component’s code.

  26. Extra slides (1) House2Order • HouseModel - Input Meta-model in UML class diagram format • Order -Output Meta-model in UML class diagram format • zt_House2Order - Folder containing the transformations • zz_Config - Folder containing configuration information

  27. Extra Slides (2) Let’s look at the meta models first, • Meta Model of Input model: HouseModel • Meta Model of Output model: OrderModel Then let’s look at the configuration model, • Configuration file: meta information, start rule (is MakeOrder3) and the input and output file types which define the meta name, root folder and file mode of the participating files. The start rule will be invoked first. MakeOrder3: Transformation rule is a compositive rule that excutes CreateOrder, MakeOrder and AddToOrder sequencially. Finally, let’s look at the transformation rules • The CreateOrder transformation rule Match/bind the in and out ports and a house model instance and rootfolders for input model and output model. When matching, then create a new order model instance (see the attribute ”action” of purchase order) and a composition connection (see the blue edge) to its rootfolder. As the first rule, its input models/files are given by the configuration information.

  28. Extra Slides (3) • The MakeOrder transformation rule Create an OrderItem instance when there is a matching between the input model and the pattern. Using guard to determine when this creation occur (when AdjacentTo.hasDoor returns true). Using the AttributeMapping’s ExpressionString (see its ExpressionString attributes) to set the initial attributes of the created OrderItem instance. • The AddToOrder transformation rule When a set of matching between the input model and the pattern happens (for example, there are 5 matches), the quantity of the OrderItem instance will be accumulated to 5 via the AttributeMapping’s ExpressionString specification. • MyHouse1: Input model It has 7 adjacentTo relationship between these rooms. However, only 5 of them have door. • MyOrder1: Output model So the quantity of the generated order is 5.

  29. Extra Slides (4) • Run the master interpreter to create the required meta information file, transformation file and configuration file. • Invoke the GR Engine to perform the transformation. You need to specify the input model and its path; You also need to specify the output model and its path. The output model is then generated. • Run code generator to create C++ codes. • MyOrder1: Output model So the quantity of the generated order is 5.

  30. A Domain Driven Development Framework

  31. Conclusion • GReAT is --Pattern specification language --Graph transformation language --High-level control flow language

  32. Graph grammars and transformations • Node replacement grammars • Hyper edge replacement grammars • Algebraic approaches • Sequencing • Programmed graph replacement systems. • Sequencing • Textual control flow

  33. Pattern Matching • Simple & Fixed Cardinality • Exponential in the number of pattern vertices and edges • Optimization is to start with at least one known vertex • Recursive algorithm developed • Variable cardinality • Based on dynamic programming • Time complexity not known (may be NP complete)

  34. Sequencing

  35. For Block

  36. Test Case

  37. Domain Specific Languages • Domain Specific Languages can increase productivity. • Historically DSL’s haven't had a wide impact. • What is the reason? • High development cost • Lack of standardization • Lack of vendor support • Lack of robustness

  38. DSL Development Framework • A formal approach towards the specification and implementation of DSLs • A formal approach lends itself to standardization(OMG MDA QVT) • Formal Specification of DSL can lead to “Correct by construction” languages • Framework to support the formal approach • Reduce development cost. • Standard protocol can lead to vendor confidence

  39. B D 5 5 1 1 E 3 3 C 6 6 A 2 4 4 Input Graph Input Graph Output Graph Text File State of the Art & Unique Requirement • Graph grammars and transformations • Over 20 years of research, Node & Hyper edge replacement, Algebraic approaches and Programmed graph replacement systems. Prominent: PROGRES, AGG • Transformations where domain and range belong to different type systems. • Algorithmic nature of transformations • Specification of traversal schemes • Efficiency of transformation code • More intuitive and easy to understand specification

  40. association association Reference Between Metamodels OUT

  41. Pattern Specification Language (cont’d) • Variable cardinality PatternGraph HostGraph

More Related