Model-Driven Development – From Frontend to Code

Model-Driven Development -
From Frontend to Code

Sven Efftinge Bernd Kolb Markus Völter

sven@efftinge.de bernd@kolbware.de voelter@acm.org
www.efftinge.de www.kolbware.de www.voelter.de

© 2006 Völter, Efftinge, Kolb -1- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Model Driven Development

• Model Driven Development is about making software

development more domain-related as opposed to
computing related. It is also about making software
development in a certain domain more efficient.

Domain Concepts Domain Concepts

mental work
of developers

Software Technology Software Technology

Concepts Concepts

© 2006 Völter, Efftinge, Kolb -2- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

MDSD Core Concepts

several

Metametamodel
target
subdomains
software
design architecture
bounded area of
expertise partial
composable knowlege/interest

knowledge multiple
multi-step transform viewpoint
Domain
single-step compile Model semantics
Ontology
interpret
no precise/
roundtrip Domain
executable
Specific
Language

graphical
Metamodel
textual

© 2006 Völter, Efftinge, Kolb -3- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

How does MDSD work?

• Developer develops model(s) Model

Model
Model Metamodel
based on certain
metamodel(s).
• Using code generation

optional, can be repeated

Tranformation
templates, the model is
Transformer
Rules

transformed to executable
code.
• Optionally, the generated Model Metamodel

code is merged with

manually written code.
•
Code
One or more model-to- Transformer Generation
Templates
model transformation steps
may precede code generation.
Manually
Generated
Written
Code
Code
optional

© 2006 Völter, Efftinge, Kolb -4- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Goals & Challenges

• Goals:
• We need an end-to-end tool chain that allows us to
build models, verify them and generate various artefacts
from them.
• All of this should happen in a homogeneous environment,
namely Eclipse.

• Challenges:
• Good Editors for your models
• Verifying the models as you build them
• Transforming/Modifying models
• Generating Code
• Integrating generated and non-generated code

© 2006 Völter, Efftinge, Kolb -5- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Roadmap for the two Sessions

• We will start by defining a metamodel for state 15‘
machines, based on the UML metamodel
Session 1

• We will then build a graphical editor for state

30’
machines using the well-known UML-based
notations.
• We will then add additional constraints (e.g. 15‘
That states must have different names)

• Next up will be a code generator that creates

a switch-based implementation of state 20‘

machines in Java.
• Recipes help developers with the imple-
Session 2

10‘
mentation of the actions associated with states.

• We will then cover model-to-model 20‘

transformations and model modifications.

• Finally, we will built a textual editor for 15‘

rendering the state machines textually.
© 2006 Völter, Efftinge, Kolb -6- w w w .openarchitectureware.org
 Model-Driven Development – From Frontend to Code

Defining the Metamodel

• A statemachine consists of a number of states.

• States can be start states, stop states and “normal”
states.
• A transition connects two states. States know their
outgoing and incoming transitions.
• We also support composite states that themselves
contain sub state machines.
• A state machine is itself a composite state.
• A state has actions. Actions can either be entry or
exit actions.

• The metamodel is defined using EMF, the Eclipse

Modelling Framework.

© 2006 Völter, Efftinge, Kolb -7- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Defining the Metamodel II

© 2006 Völter, Efftinge, Kolb -8- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Defining the Metamodel III

• The metamodel
is defined using
EMF.
• EMF provides
tree-based
editors to define
the metamodel.
• The metamodel
has its own
project called
oaw4.demo.gmf.
statemachine2

© 2006 Völter, Efftinge, Kolb -9- w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Defining the Metamodel IV

• Note that we have to create the genmodel as well

as the .edit and .editor projects from the ecore
model.
• This is necessary for the graphical editor to work.
© 2006 Völter, Efftinge, Kolb - 10 - w w w .openarchitectureware.org
 Model-Driven Development – From Frontend to Code

Building the graphical Editor

• The editor is based on the metamodel defined

before.
• A number of additional models has to be defined:
• A model defining the graphical notation
• A model for the editor’s pallette and other tooling
• A mapping model that binds these two models to
the domain metamodel
• A generator generates the concrete editor based on
these models.

• The editor is build with the Eclipse GMF, the

Graphical Modelling Framework.

© 2006 Völter, Efftinge, Kolb - 11 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor II

© 2006 Völter, Efftinge, Kolb - 12 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor III

• We use another project for the GMF models from

which we’ll create the editor:
oaw4.demo.gmf.statemachine2.gmf
• This project contains all the additional models we
talked about before:

© 2006 Völter, Efftinge, Kolb - 13 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor IV

• The gmftool model contains the definition of the

palette that will be used in the editor.

• We have creation tools for all the relevant

metamodel elements.
• Each of these tools has a nice icon associated.

© 2006 Völter, Efftinge, Kolb - 14 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor V

• The Figure Gallery

contains the figures (as well
as their associated labels)
• Shapes
• Line Style
• Colors
• Decorations
• Diagram Nodes represent
the vertices in the graph
that is being edited.
• Compartments can be
defined as parts of Nodes.
• Connections play the role
of the edges in the graph.

© 2006 Völter, Efftinge, Kolb - 15 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor VI

• We map nodes and

links.
• We include all the
other models so
they can be
referenced.
• Better editors will
become available
by GMF final.
• From that, we
generate the editor
plugins:

© 2006 Völter, Efftinge, Kolb - 16 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Building the graphical Editor VII

• Here is the editor, started in the runtime

workbench, with our CD Player example.

Overview
Pane

Tool
Palette

These rectangles
are to demo
decorations ☺ Model
Element
Properties

© 2006 Völter, Efftinge, Kolb - 17 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Constraints

• Constraints are rules that models must conform to in

order to be valid. These are in addition to the structures
that 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 in
the editor
... and we don’t want to implement constraints twice
to have them available in both places!

• Functional languages are often used here.

• UML’s OCL (Object Constraint Language) is a good
example,
• We use oAW’s check language, which is alike OCL

© 2006 Völter, Efftinge, Kolb - 18 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Constraints II

• Constraints are put

into the statemachine2
project, the same as
the metamodel.
• StatemachineBatchErrors
are used in batch validation
mode (automatically evalu-
ated every 2 seconds in the
editor)
• StatemachineLiveErrors prevent erratic modellings
in the first place.

© 2006 Völter, Efftinge, Kolb - 19 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Constraints III

• Here are some examples written in oAW’s Checks

language. For which elements
is the constraint is
applicable

Error message
in case
Expression is
Constraint false
ERROR or Expression

•
WARNING
Note the code completion and error highlighting ☺

© 2006 Völter, Efftinge, Kolb - 20 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Constraints IV

• To make the GMF generated editors evaluate our

constraints, we needed to tweak things a little bit;
most of this is in oaw4.demo.gmf.statemachine2.etc
• We wrote our own ConstraintEvaluators and
plugged in the oAW CheckFacade.
• We used AspectJ to weave in Adapters into the EMF
Factory
• We wrote a watchdog that does the batch
evaluations whenever the model does not change for
two seconds.
• Also, you have to
make two important
adjustments in the
gmfgen model

© 2006 Völter, Efftinge, Kolb - 21 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Constraints V

• In this model there

are two errors
• There are two
states with the
same name (Off)
• The start state has
more than one out-
Transition
• The validation is
executed automatically
• Clicking the error
message selects
the respective
“broken” model
element in the dia-
gram.

© 2006 Völter, Efftinge, Kolb - 22 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Code Generation

• Code Generation is used to generate executable

code from models.
• Code Generation is based on the metamodel
and uses templates to attach to-be-generated
source code.
• In openArchitectureWare,
we use a template
language called xPand.
• It provides a number of
advanced features such as
polymorphism, AO support
and a powerful integrated
expression language.
• Templates can access
metamodel properties
seamlessly

© 2006 Völter, Efftinge, Kolb - 23 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Code Generation II

• What kind of code will be generated? How do you

implement a state machine?
• There are many ways of implementing a state
machine:
• GoF’s State pattern
• If/Switch-based
• Decision Tables
• Pointers/Indexed Arrays
• We will use the switch-based alternative. It is
neither the most efficient nor the most elegante
alternative, but it’s simple.
• For more discussion of this topic, see
Practical State Charts in C/C++ by Miro Samek

© 2006 Völter, Efftinge, Kolb - 24 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

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 switches over all states to find out the
current state
• Check whether there’s a transition for the
event 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 ☺
© 2006 Völter, Efftinge, Kolb - 25 - w w w .openarchitectureware.org
 Model-Driven Development – From Frontend to Code

Code Generation IV

• The generator is located

in the oaw4.demo.gmf.
statemachine2.generator
project.
• There are a number of
code generation
templates.
• Extensions are also
defined.
• There are also workflow
files (.oaw) that control
the workflow of a generator run.
• Different workflow files contain different “parts” of
the overall generator run and call each other.
• Workflow files are in some small way like ant files.

© 2006 Völter, Efftinge, Kolb - 26 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Code Generation V
Namespace and
Extension Import • The blue text is
generated into
the target file.
Opens a
File
Name is a property
of the State-
Machine class
• The capitalized
words are
xPand keywords

Calls another
• Black text are
Iterates
over all template metamodel
the states
of the
properties
•
State-
Machine DEFINE...END-
Extension Call
DEFINE blocks
are called
Template
name Like methods in OO, templates.
templates are
associated with a
(meta)class • The whole thing
is called a
template file.

© 2006 Völter, Efftinge, Kolb - 27 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Code Generation VI

• One can add behaviour to existing

metaclasses using oAW’s Xtend language.
Imports a
namespace

Extensions are
typically defined
for a metaclass

Extensions can also

have more than one
parameter

• Extensions can be called using member-style

syntax: myAction.methodName()
• Extensions can be used in Xpand templates,
Check files as well as in other Extension files.
• They are imported into template files using the
EXTENSION keyword

© 2006 Völter, Efftinge, Kolb - 28 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Code Generation VII

• Workflow loads the model, checks it (same

constraints as in Editor!) and then generates
code.
A component is a
„step“ in the
workflow

A number of
parameters are
passed in

We invoke the
same check file as
in the editor

This starts the

first, „top level“
template

Code is
automatically
beautified

© 2006 Völter, Efftinge, Kolb - 29 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Recipes I

• There are various ways of integrating generated

code with non-generated code:

a)

b)

c) d) e)
generated code non-generated code

© 2006 Völter, Efftinge, Kolb - 30 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Recipes II

• To help developers to “do the right thing” after

the generator has created base classes and the
like, you can use a recipe framework.
• It provides a task-based approach to
“completing” the generated code with manual
parts.
• This works the following way:
• As part of the generator run, you instantiate
checks that you write to a file
• After the generator finishes, the IDE (here:
Eclipse) loads these checks and verifies them
against the complete code base (i.e. Generated +
manual)
• If things don’t conform to the rules, messages
are output helping the developer to fix things.

• For example, in the state machine case, actions

must be implemented in subclasses.

© 2006 Völter, Efftinge, Kolb - 31 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Recipes III

• Here’s an error that suggests that I extend my

manually written class from the generated base
class:

Recipes can be
arranged
hierarchically

„Green“ ones
This is a can also be
failed check hidden Here you can see
additional
information about
the selected recipe

© 2006 Völter, Efftinge, Kolb - 32 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Recipes IV

• I now add the respective extends clause, and

the message goes away – automatically.

Adding the extends

clause makes all of
them green

© 2006 Völter, Efftinge, Kolb - 33 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Recipes V

• Now I get a number of compile errors because I have

to implement the abstract methods defined in the
super class:

• I finally implement them sensibly, and everything is

ok.
• The Recipe Framework and the Compiler have guided
me through the manual implementation steps.
• If I didn’t like the compiler errors, we could also add
recipe tasks for the individual operations.
• oAW comes with a number of predefined recipe
checks for Java. But you can also define your own
checks, e.g. to verify C++ code.
© 2006 Völter, Efftinge, Kolb - 34 - w w w .openarchitectureware.org
 Model-Driven Development – From Frontend to Code

Recipes VI

• Here’s the implementation of the Recipes. This

workflow component must be added to the workflow.
You extend one of a
number of suitable
base classes…

…and override a
suitable template
method

You can then create

any number of
checks.

This one checks

that a class extends
another one

And return the

checks to the
framework

© 2006 Völter, Efftinge, Kolb - 35 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Model Transformations I

• Model Transformations create one or more new

models from one or more input models. The input
models are left unchanged.
• Often used for stepwise refinement of models and
modularizing generators
• Input/Output Metamodels are different
• Model Modifications are used to alter or
complete an existing model
• For both kinds, we use the xTend language, an
extension of the openArchitectureWare expression
language.
• Alternative languages are available such as
Wombat, ATL, MTF or Tefkat (soon: various QVT
implementations)

© 2006 Völter, Efftinge, Kolb - 36 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Model Transformation II

• The model modification shows how to add an

additional state and some transitions to an existing
state machine (emergency shutdown)
Extensions can
import other
extensions
The main function

„create extensions“
guarantee that for
each set of
parameters the
identical result will
be returned.

Therefore
createShutDown()
will always return
the same element.

© 2006 Völter, Efftinge, Kolb - 37 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Model Transformation III

• The generator is based on an implementation-

specific metamodel without the concept of
composite states.

• This makes the templates simple, because we

don‘t 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 transforms

models described with our GMF editor into models
expected by the generator.

© 2006 Völter, Efftinge, Kolb - 38 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Model Transformation IV

• We want to transform from the editor’s

metamodel ‘statemachine2’ to the
generator’s metamodel ‘simpleSM’

• We need to ‘normalize’
composite states.

• States inherit outgoing

transitions from their
parent states

• For those transitions the

exit actions are inherited,
too

• Unify action and event

elements with the same
name

© 2006 Völter, Efftinge, Kolb - 39 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Textual Editor I

• A graphical notation is not always the best syntax

for DSLs.
• So, while GMF provides a means to generate
editors for graphical notations, we also need to be
able to come up with editors for textual
syntaxes.
• These editors need to include at least
• Syntax hightlighting
• Syntax error checking
• Semantic constraint checking

© 2006 Völter, Efftinge, Kolb - 40 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Textual Editor II

• We use oAW’s textual DSL generator framework

xText
• 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 Check
file, as always oAW

© 2006 Völter, Efftinge, Kolb - 41 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Textual Editor III

• The grammar (shown in • The generated eCore

the boostrapped editor) AST model
A The first rule
literal describes the
root element
of the AST

Rule names
will
Rule become the
name AST classes

States contain
a number of
entry actions,
transitions and
exit actions

Assigns an These variables

indentifier to will become
a variable attributes of
(here: state) the AST class

© 2006 Völter, Efftinge, Kolb - 42 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Textual Editor IV

• You can define additioal constraints that should be

validated in the generated editor.
• This is based on oAW’s Check language
• i.e. These are constraints like all the others you’ve
already come across

© 2006 Völter, Efftinge, Kolb - 43 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Textual Editor V
• The generated editor and it’s outline view
Literals
have
become
keywords

Constraints
are
evaluated
in real time

© 2006 Völter, Efftinge, Kolb - 44 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Tooling Versions

Eclipse 3.1 or Eclipse 3.2, suitable EMF version

Eclipse >= 3.2M6, GMF >= 1.0M6

Eclipse >= 3.1, oAW >= 4.0

Eclipse >= 3.1, oAW >= 4.0

Eclipse >= 3.1, oAW >= 4.0

Eclipse 3.2, oAW >= 4.1

Eclipse 3.2, oAW >= 4.1

© 2006 Völter, Efftinge, Kolb - 45 - w w w .openarchitectureware.org

 Model-Driven Development – From Frontend to Code

Summary

• The tool chain we’ve 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

• THANK YOU.

© 2006 Völter, Efftinge, Kolb - 46 - w w w .openarchitectureware.org