Mdd Open Source Tooling

8/8/2019 Mdd Open Source Tooling

1/50

w w w.openarchitectureware.org- 1 -

Model-Driven Development with Open Source Tool ing

2006 Markus Vlter

Markus [email protected]

Model-Driven Development

With Open Source Tooling


2/50



2006 Markus Vlter



Part 1:Tools Overview

Part 2:Demonstration w ith

openArchitectureWare


3/50



2006 Markus Vlter

Tool Overview

Theres a huge number of small tools available. See www.planetmde.org, as well as www.codegeneration.net

These are often specific to (and come from thecommunities of) a modelling tool a target architecture (such as J2EE, Embedded)

a research environment

There are several major general purpose tools in usetoday.

Eclipse.org stuff

Eclipse GMT Eclipse GMT openArchitectureWare androMDA GME


4/50



2006 Markus Vlter

Tool Overview: Eclipse.org

EMF (Eclipse Modelling Framework)mostly a meta-meta model (Ecore)

JET (Java Emitter Templates)Very basic code generation tools

EMFT (EMF Technologies)Queries, OCL, Transactions

GMF (Graphical Modelling Framework)Build your own graphical editors

UML2UML2 metamodel implementation based on EMF

GMT (Generative Modelling Tools) -> see next slide

MDDi (MDD integration)integration bus for MDD tools

All of these (plus others) will soon be part of the EclipseModelling Project


5/50



2006 Markus Vlter

Tool Overview: Eclipse GMT

GMT is an Eclipse Technology project and plays the role ofthe research incubator for Eclipse-based MDSD tools.

openArchitectureWare -> see part two of talk

ATL (Atlas Transformation Language) QVT-like M2Mtransformation language by INRIA

AM3 (Atlas Mega Model Management)

AMW (Atlas Model Weaver)

Fuut-je (Generator Tool)

MOFScript (Model-To-Text Transformation) UMLX (M2M Transformation)

VIATRA2 (M2M Transformation)


6/50



2006 Markus Vlter

Tool Overview: androMDA

androMDA is an MDA tool that

comes with a lot ofpre-built cartridges for JavaEnterprise contexts (JEE, Hibernate, Spring)

is based on JMI and Velocity

is not too well suited for building your own generators,most people just use the cartridges that it includes

Has a large user community, mostly because it addressesmainstream use cases


7/50



2006 Markus Vlter

Tool Overview: GME

GME is the Generic Modelling Environment built byVanderbilt Universitys ISIS

There are a lot of transformation/simulation/verification

tools built around it

It is used quite a bit in the US defense/avionics industriesas well as in industrial automation


8/50



2006 Markus Vlter







9/50


10/50



2006 Markus Vlter

Roadmap for the two Sessions

We will start by defining a metamodel for statemachines, based on the UML metamodel

We will then build a graphical editor for statemachines using the well-known UML-basednotations.

We will then add additional constraints (e.g.That states must have different names)

Next up will be a code generator that creates

a switch-based implementation of statemachines in Java.

Recipes help developers with the imple-mentation of the actions associated with states.

We will then cover model-to-modeltransformations and model modifications.

Finally, we will built a textual editor for

rendering the state machines textually.


11/50



2006 Markus Vlter

Defining the Metamodel

A statemachine consists of a number ofstates. States can be start states, stop states and normal

states.

A transition connects two states. States know theiroutgoing and incoming transitions.

We also support composite states that themselvescontain sub state machines.

A state machine is itself a composite state. A state has actions. Actions can either be entry orexit actions.

The metamodel is defined using EMF, the EclipseModelling Framework.


12/50



2006 Markus Vlter

Defining the Metamodel II


13/50



2006 Markus Vlter

Defining the Metamodel II I

The metamodelis defined usingEMF.

EMF providestree-basededitors to definethe metamodel.

The metamodelhas its ownproject calledoaw4.demo.gmf.statemachine2


14/50



2006 Markus Vlter

Defining the Metamodel IV

Note that we have to create the genmodel as wellas the .edit and .editor projects from the ecoremodel.

This is necessary for the graphical editor to work.


15/50



2006 Markus Vlter

Building the graphical Editor

The editor is based on the metamodel definedbefore. A number of additional models has to be defined:

A model defining the graphical notation

A model for the editors pallette and other tooling

A mapping model that binds these two models tothe domain metamodel

A generator generates the concrete editor based onthese models.

The editor is build with the Eclipse GMF, theGraphical Modelling Framework.


16/50



2006 Markus Vlter

Building the graphical Editor II


17/50



2006 Markus Vlter

Building the graphical Editor III

We use another project for the GMF models fromwhich well create the editor:oaw4.demo.gmf.statemachine2.gmf

This project contains all the additional models we

talked about before:


18/50



2006 Markus Vlter

Building the graphical Editor IV

The gmftool model contains the definition of thepalette that will be used in the editor.

We have creation tools for all the relevantmetamodel elements.

Each of these tools has a nice icon associated.


19/50



2006 Markus Vlter

Building the graphical Editor V

The Figure Gallerycontains the figures (as well

as their associated labels) Shapes Line Style Colors

Decorations

Diagram Nodes representthe vertices in the graphthat is being edited.

Compartments can bedefined as parts of Nodes.

Connections play the roleof the edges in the graph.


20/50



2006 Markus Vlter

Building the graphical Editor VI

We map nodes andlinks.

We include all theother models so

they can bereferenced.

Better editors willbecome available

by GMF final. From that, we

generate the editorplugins:


21/50



2006 Markus Vlter

Building the graphical Editor VII

Here is the editor, started in the runtimeworkbench, with our CD Player example.

These rectanglesare to demo

decorations

Tool

Palette

OverviewPane

Model

ElementProperties


22/50



2006 Markus Vlter

Constraints

Constraints are rules that models must conform to inorder to be valid. These are in addition to the structuresthat the metamodel defines.

Formally, constraints are part of the metamodel.

A constraint is a boolean expression (a.k.a predicate)that must be true for a model to conform to a metamodel.

Constraint Evaluation should be available in batch mode (when processing the model)

as well as interactively, during the modelling phase inthe editor

... and we dont want to implement constraints twiceto have them available in both places!

Functional languages are often used here. UMLs OCL (Object Constraint Language) is a good

example,

We use oAWs check language, which is alike OCL


23/50



2006 Markus Vlter

Constraints II

Constraints are putinto the statemachine2project, the same asthe metamodel.

StatemachineBatchErrorsare used in batch validationmode (automatically evalu-ated every 2 seconds in theeditor)

StatemachineLiveErrors prevent erratic modellingsin the first place.

M d l D i D l t ith O S T li


24/50



2006 Markus Vlter

Constraints II I

Here are some examples written in oAWs Checkslanguage.

Note the code completion and error highlighting

For which elementsis the constraint is

applicable

ConstraintExpression

Error messagein case

Expression isfalse

ERROR orWARNING

Model Driven Development with Open Source Tool ing


25/50



2006 Markus Vlter

Constraints IV

To make the GMF generated editors evaluate ourconstraints, we needed to tweak things a little bit;most of this is in oaw4.demo.gmf.statemachine2.etc

We wrote our own ConstraintEvaluators andplugged in the oAW CheckFacade.

We used AspectJ to weave in Adapters into the EMFFactory

We wrote a watchdog that does the batch

evaluations whenever the model does not change fortwo seconds.

Also, you have tomake two importantadjustments in thegmfgen model



26/50



2006 Markus Vlter

Constraints V

In this model thereare two errors There are two

states with thesame name (Off)

The start state hasmore than one out-Transition

The validation isexecuted automatically Clicking the error

message selects

the respectivebrokenmodelelement in the dia-gram.



27/50



2006 Markus Vlter

Code Generation

Code Generation is used to generate executablecode from models. Code Generation is based on the metamodel

and uses templates to attach to-be-generated

source code. In openArchitectureWare,

we use a templatelanguage called xPand.

It provides a number ofadvanced features such aspolymorphism, AO supportand a powerful integratedexpression language.

Templates can accessmetamodel propertiesseamlessly



28/50



2006 Markus Vlter

Code Generation II

What kind of code will be generated? How do youimplement a state machine? There are many ways of implementing a state

machine:

GoFs State pattern If/Switch-based

Decision Tables

Pointers/Indexed Arrays We will use the switch-based alternative. It isneither the most efficient nor the most elegantealternative, but its simple.

For more discussion of this topic, seePractical State Charts in C/C++ by Miro Samek



29/50


p p g

2006 Markus Vlter

Code Generation III: Pseudocode

Generate an enumeration for the states Generate an enumeration for the events Have a variable that remembers the state in

which the state machine is currently in.

Implement a function trigger(event) which First sw itches over all states to find out the

current state

Check whether theres a transition for theevent passed into the function

If so, execute exit action of current state,

Set current state to target of transition Execute entry action of this new current state

Return

And also handle nested states



30/50

w w w.openarchitectureware.org- 30 - 2006 Markus Vlter

Code Generation IV

The generator is locatedin the oaw4.demo.gmf.statemachine2.generatorproject.

There are a number ofcode generationtemplates.

Extensions are alsodefined.

There are also workflowfiles (.oaw) that controlthe workflow of a generator run.

Different workflow files contain different parts ofthe overall generator run and call each other.

Workflow files are in some small way like ant files.



31/50


Code Generation V

The blue text isgenerated intothe target file.

The capitalizedwords arexPand keywords

Black text aremetamodelproperties

DEFINE...END-DEFINE blocksare calledtemplates.

The whole thingis called atemplate file.

Opens aFile

Name is a propertyof the State-

Machine class

Like methods in OO,

templates areassociated with a

(meta)class

Iteratesover all

the states

of theState-Machine

Calls anothertemplate

Extension Call

Templatename

Namespace and

Extension Import



32/50


Code Generation VI

One can add behaviour to existingmetaclasses using oAWs Xtend language.

Extensions can be called using member-stylesyntax: myAction.methodName()

Extensions can be used in Xpand templates,Check f iles as well as in other Extension files.

They are imported into template files using theEXTENSION keyword

Imports anamespace

Extensions are

typically definedfor a metaclass

Extensions can alsohave more than one

parameter



33/50


Code Generation VI I

Workflow loads the model, checks it (sameconstraints as in Editor!) and then generatescode.

A component is astep in the

workflow

A number ofparameters are

passed in

We invoke thesame check f ile as

in the editor

This starts thefirst, top level

template

Code isautomatically

beautified



34/50


Recipes I

There are various ways of integrating generatedcode with non-generated code:

a)

b)

c) d) e)

generated code non-generated code



35/50


Recipes II

To help developers to do the right thingafterthe generator has created base classes and thelike, you can use a recipe framework.

It provides a task-based approach tocompleting the generated code with manual

parts. This works the following way:

As part of the generator run, you instantiatechecks that you write to a file

After the generator finishes, the IDE (here:Eclipse) loads these checks and verifies themagainst the complete code base (i.e. Generated +manual)

If things dont conform to the rules, messagesare output helping the developer to fix things.

For example, in the state machine case, actionsmust be implemented in subclasses.



36/50


Recipes III

Heres an error that suggests that I extend mymanually written class from the generated baseclass:

Rec ipes can bearranged

hierarchically

This is afai led check

Green onescan also be

hidden Here you can seeadditional

information aboutthe selected recipe


R i IV


37/50


Recipes IV

I now add the respectiveex t ends

clause, andthe message goes away automatically.

Adding the extendsclause makes all of

them green


R i V


38/50


Recipes V

Now I get a number of compile errors because I haveto implement the abstract methods defined in thesuper class:

I finally implement them sensibly, and everything isok. The Recipe Framework and the Compiler have guided

me through the manual implementation steps.

If I didnt like the compiler errors, we could also addrecipe tasks for the individual operations.

oAW comes with a number ofpredefined recipechecks for Java. But you can also define your own

checks, e.g. to verify C++ code.


Recipes VI


39/50


Recipes VI

Heres the implementation of the Recipes. Thisworkflow component must be added to the workflow.

You extend one of anumber of suitable

base classes

and override asuitable template

method

You can then createany number o f

checks.

This one checks

that a class extendsanother one

And return thechecks to theframework


Model Transformations I


40/50


Model Transformations I

Model Transformations create one or more newmodels from one or more input models. The inputmodels are left unchanged.

Often used for stepwise refinement of models andmodularizing generators

Input/Output Metamodels are different

Model Modifications are used to alter orcomplete an existing model

For both kinds, we use the xTend language, anextension of the openArchitectureWare expressionlanguage.

Alternative languages are available such asWombat, ATL, MTF or Tefkat (soon: various QVTimplementations)


Model Transformation II


41/50


Model Transformation II

The model modification shows how to add anadditional state and some transitions to an existingstate machine (emergency shutdown)

Extensions canimport otherextensions

The main function

create extensions

guarantee that foreach set of

parameters thei den t ica l result wi ll

be returned.

ThereforecreateShutDown()will always returnthe same element.


Model Transformation III


42/50


Model Transformation III

The generator is based on an implementation-specific metamodel without the concept ofcomposite states.

This makes the templates simple, because we

dont have to bridge the whole abstraction gap(from model to code) in the templates.

Additionally, the generator is more reusable,because the abstractions are more general.

We will show a transformation which transformsmodels described with our GMF editor into modelsexpected by the generator.


Model Transformation IV


43/50


Model Transformation IV

We want to transform from the editorsmetamodel statemachine2 to thegenerators metamodel simpleSM

We need to normalizecomposite states.

States inherit outgoingtransitions from theirparent states

For those transitions theexit actions are inherited,too

Unify action and eventelements w ith the samename


Textual Editor I


44/50


Textual Editor I

A graphical notation is not always the best syntaxfor DSLs.

So, while GMF provides a means to generateeditors for graphical notations, we also need to beable to come up with editors for textualsyntaxes.

These editors need to include at least Syntax hightlighting

Syntax error checking Semantic constraint checking


Textual Editor II


45/50


Textual Editor II

We use oAWs textual DSL generator frameworkxText

Based on a BNF-like language it provides: An EMF-based metamodel (representing the

AST) An Antlr parser instantiating dynamic EMF-

models

An Eclipse text editor plugin providing

syntax highlighting

An outline view ,

syntax checking

as well as constraints checking based on a Checkfile, as always oAW


Textual Editor II I


46/50


Textual Editor II I

The grammar (shown inthe boostrapped editor)

The f irst ruledescribes theroot element

of the AST

The generated eCoreAST model

Aliteral

States containa number of

entry actions,transitions and

exit actions

Assigns anindentifier to

a variable(here: state)

These variablesw ill becomeattributes ofthe AST class

Rulename

Rule nameswill

become theAST classes


Textual Editor IV


47/50


You can define additioal constraints that should bevalidated in the generated editor.

This is based on oAWs Check language i.e. These are constraints like all the others youve

already come across


Textual Editor V


48/50


Literalshave

becomekeywords

The generated editor and its outline view

Constraintsare

evaluatedin real time


Summary


49/50


The tool chain weve just shown provides an end-to-end solution for MDSD,

Completely Open Source

Using standards wherever worthwhile,

And pragmatic solutions wherever necessary.

To get the tools, go to www.eclipse.org/emf

www.eclipse.org/gmf

www.openarchitectureware.org,www.eclipse.org/gmt/oaw



50/50







THANK YOU!

Documents

Mdd Open Source Tooling