1. GReAT: Graph Rewriting And Transformation Presenter: Yuehua Lin 2/17/04, Tuesday Slides help from Aditya Agrawal aditya.agrawal@vanderbilt.edu

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

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

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

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 1.Easy–to-use language for system developers 2.Increase productivity (order of 2 to 10) 3.Efficient execution (not more that 2 times slower than hand code)

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

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 Pattern GraphHost Graph Cardinality n: a pattern vertex must match n host graph vertices.

9. Pattern Specification Language (cont’d)  Fixed cardinality Pattern Graph Host Graph

10. Graph transformation language Delete New Bind 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. 13/17 Steps to Use GReAT Tools  Build Transformation model (provided by user): 1.meta models 2.transformation rules 3.configuration model  Run Transformation model 1.Run Master Interpreter to convert the above models to the required formats 2.Run GR engine/GRD engine to perform the transformation 3.Run Code Generator to generate C++ code if necessary

14. 14/17 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. 15/17 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 Strategies Specification aspects Input Models Output Models weaving engine

17. 17/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. 18/17 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. 19/17 Play C-SAW Demo Video  http://www.gray-area.org/Research/C-SAW/ http://www.gray-area.org/Research/C-SAW/

20. 20/17 Example: The Aspect Specification And Strategy defines Start, FindData1, AddLog; strategy FindData1( ) { atoms()->select(a | a.name() == "Data1")->AddLog(); } strategy AddLog( ) { declare parentModel : model; declare dataAtom, logAtom : atom; dataAtom := self(); parentModel := parent(); logAtom := parentModel.addAtom("Log", "LogOnWrite"); logAtom.setAttribute("Kind", "OnWrite"); logAtom.connectedTo(dataAtom); } aspect Start( ) { rootFolder( ).findFolder("ComponentTypes").models()->FindData1(); }

21. 21/17 Before WeavingAfter Weaving Effect of Model Transformation

22. 22/17 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. 23/17 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. 24/17 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. 25/17 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. 26/17 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. 27/17 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. 28/17 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. 29/17 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. 30/17 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. 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 2 4 3 6 5 1 Output GraphInput Graph A B C D E Text File 4 3 6 5 1 Input Graph

40. Reference Between Metamodels OUT association

41. 41/17 Pattern Specification Language (cont’d)  Variable cardinality Pattern Graph Host Graph