+ All Categories
Home > Documents > GReAT: Graph Rewriting And Transformation Presenter: Yuehua Lin 2/17/04, Tuesday Slides help from...

GReAT: Graph Rewriting And Transformation Presenter: Yuehua Lin 2/17/04, Tuesday Slides help from...

Date post: 25-Dec-2015
Category:
Upload: mabel-peters
View: 216 times
Download: 2 times
Share this document with a friend
Popular Tags:
41
GReAT: Graph Rewriting And Transformation Presenter: Yuehua Lin 2/17/04, Tuesday Slides help from Aditya Agrawal [email protected]
Transcript

GReAT: Graph Rewriting And Transformation

Presenter: Yuehua Lin

2/17/04, Tuesday

Slides help from Aditya Agrawal

[email protected]

Domain-Specific MDA

Tool Integration

Metamodeling

Analysis

Execution

Metamodels

Domainmodels

Translation

Synthesis & Generation

Model-ModelTransformations

Domain-specific modeling

Metamodel and Models

Metamodel

Model

Metamodel: a graph grammar of models

Model manipulation and transformation

Models are graphs The most common operations are

1. Traversal and matching2. Creation of secondary data structure3. Text generation (e.g. code/config …)

Output Graph

A

B

C

D

E

Text File

24

3 6

51

Input Graph

4

3 6

51

Input Graph

321

Research Hypothesis of GReAT

Model transformations can be specified using Model transformations can be specified using graph transformationsgraph transformations on metamodels. on metamodels.

Using this approach we aim to achieve a Using this approach we aim to achieve a significant increase in productivity in the significant increase in productivity in the

development of such transformations.development of such transformations.

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

Metamodel of Source

Metamodel of Target

DS-PI ModelDS-PI Model

Source Models

DS-PS ModelDS-PS Model

Target Model

Model Transformation Specification

Input Output

Describes Describes

Refers to

Refers to

Transformation Modeling

Transformation Execution

Transformation

Mod

el A

PI

MetaMeta

Virtual Machine

Mod

el A

PI

Overview

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

Pattern Specification Language

Single cardinality

Pattern Graph Host Graph

Cardinality n: a pattern vertex must match n host graph vertices.

Pattern Specification Language (cont’d)

Fixed cardinality

Pattern Graph

Host Graph

Graph transformation language

Delete

New

Bind

A transformation rule example with pattern, guard and attribute mapping

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

Transformation Engine A Virtual Machine

13/17

Steps to Use GReAT Tools Build Transformation model (provided

by user):1. meta models2. transformation rules3. configuration model

Run Transformation model1. Run Master Interpreter to convert the

above models to the required formats2. Run GR engine/GRD engine to perform the

transformation3. Run Code Generator to generate C++ code

if necessary

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

Framework of Aspect Model Weaver

StrategiesSpecification aspects

Input Models

Output Models

weaving engine

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/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/17

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

W/

20/17

Example: The Aspect Specification And Strategydefines 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/17

Before Weaving After Weaving

Effect of Model Transformation

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/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/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/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/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/17

Extra Slides (2)Let’s look at the meta models first, Meta Model of Input model: HouseModel Meta Model of Output model: OrderModelThen 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/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 modelSo the quantity of the generated order is 5.

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/17

A Domain Driven Development Framework

Conclusion

GReAT is--Pattern specification language--Graph transformation language--High-level control flow language

Graph grammars and transformations

Node replacement grammars Hyper edge replacement grammars

Algebraic approaches Sequencing

Programmed graph replacement systems. Sequencing Textual control flow

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)

Sequencing

For Block

Test Case

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

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

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

24

3 6

51

Output GraphInput Graph

A

B

C

D

E

Text File

4

3 6

51

Input Graph

Reference Between Metamodels OUT

association

association

41/17

Pattern Specification Language (cont’d)

Variable cardinality

Pattern Graph Host Graph


Recommended