Markus Völter voelter@acm voelter.de

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w . v o e l t e r . d e © 2 0 0 5 M a rk u s V ö l t e r. - 1 -

Model-Driven Software Development and Eclipse

Markus Vö[email protected]

Model-Driven Software Development and

Eclipse



Markus Vö[email protected]

www.voelter.de

• Independent Consultant

• Based out of Heidenheim, Germany

• Focus on• Software Architecture• Middleware• Model-Driven Software

Development

About me



C O N T E N T S

• What is MDSD?• MDSD Infrastructure• Related Eclipse Projects

• Meta-metamodelling• Editor Construction• Model Transformation• Code Generation• Infrastructure



C O N T E N T S





What is MDSD?

• Domain 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.

Software TechnologyConcepts

Domain Concepts

Software TechnologyConcepts

Domain Concepts

mental workof developers



What is MDSD? II

• Model-Driven Software Development is about making models first class development artifacts as opposed to “just pictures”.

• Various aspects of a system are not programmed manually; rather they are specified using a suitable modelling language.

• The language for expressing these models is specific to the domain for which the models are relevant. The modelling languages used to describe such models are called domain-specific languages (DSL).

• Models have to be translated into executable code for a specific platform.

• Such a translation is implemented using model transformations.



What is MDSD? III

Model

DomainSpecific

Language

Metamodeltextual

graphical

Domain

Ontology

bounded area ofknowlege/interest

semantics

precise/executable

multiple

partial

viewpoint

subdomains

composable

Metametamodeltarget

softwarearchitecture

softwarearchitecture

transform

compile

interpret

multi-step

single-step

noroundtrip

knowledge

several

designexpertise

• Related Approaches (Specializations):MDA, SF, DSM, GP, …



How does MDSD work?

• Developer develops model(s)based on certain metamodel(s).

• Using code generation templates, the model is transformed to executable code.

• Optionally, the generated code is merged with manually written code.

• One or more model-to-model transformation steps may precede code generation.

ModelModelModel

Transformer TranformationRules

Model

TransformerCode

GenerationTemplates

Generated CodeManuallyWrittenCode

optional

Metamodel

Metamodel

optio

nal,

can

be

repe

ated



C O N T E N T S





MDSD Tooling

• Meta-Metamodels incl. Editors to define Metamodels• Editors to build and (real-time) verify models• Transformers that build models from other models• Code generators that generate code from models

Editor Model A

Metamodel 1

<<instanceof>>

Meta-Metamodel

<<instanceof>>

Meta-Editorbuilds

builds

knows

knows

Transformerreads

Model B

Metamodel 2

builds

<<instanceof>>

<<instanceof>>

Generatorreads

Codecreates

Infrastructure ("Model Bus)



C O N T E N T S





EMF for Metamodelling

• EMF stands for Eclipse Modelling Framework

• Its prime content is a metametamodel called Ecore • it is implemented in Java; i.e. metamodels are represented

using Java data structures• It is more or less a subset of MOF (the OMG

metametamodel that forms the basis for MDA)

• Metamodels built with EMF automatically feature• Event-based change notification• XMI serialization/deserialization• An API to modify instances of the metamodel (i.e. models)

• EMF also provides editor support – see later.



EMF for Metamodelling II

• EMF seems to become the basis for many MDSD-related tools, such as• Model-to-Model transformers,• Code generators, • Editors• And maybe even Code IDE‘s



openArchitectureWare for Metamodelling

• openArchitectureWare is a comprehensive open source tool suite for model-driven software development (see www.openarchitectureware.org).• It is not an Eclipse project – it’s hosted at sourceforge – but it

provides extensive integration into Eclipse.

• Metamodels are represented as Java classes (no metametamodel supported, except reflection, if you will)

• It‘s possible to model metamodels using an arbitrary UML modelling tool and then generate metaclasses including • Constraint checkes• Namespaces• Compostion• Event mechanisms



C O N T E N T S





GEF

• GEF stands for Graphical Editing Framework

• It can be used to build MVC-based graphical editors that are integrated into the Eclipse platform.

• It forms the basis for basically all editor generators… that’s why its mentioned here.

• At this time, there is no specific integration with EMF; it is non-trivial to build GEF editors for EMF models.

• Note that using GEF is far from trivial, therefore, several projects aim at generating GEF editors from higher level descriptions, ideally, annotated domain metamodels – see later.



GEF II – Example Editor



GEF III – How GEF works

Domain Model(Metamodel

Implementation)

Models(Adapts Domain Model

to GEF Framework)

Parts(contain policies and

commands)

Figures(represent the model

elements visually)

MVC

view

controllermodel

Adapteradaptee

adapter

Commands

modifiesPolicies

queries



EMF for Editor Generation

• Based on EMF metamodels, you can use EMF tools to generate Eclipse-based editors.• These are tree-based editors, • Coupled with properties that can be edited in the eclipse

property view

• Editors are specified using a so-called genmodel, it allows you to specify the editor-relevant information for the metamodel for which you want the editor generated.

• Note that the generated code is separated into two parts,• A generic editor infrastructure onto which any kind of

editors can be built (by you, manually!),• And then the tree editors themselves.



GEF & openArchitectureWare

• openArchitectureWare provides a generator to generate GEF editors from (annotated) domain metamodels.

• This makes editor development significantly easier and more efficient, especially if the domain metamodel (and thus, the associated editors) evolves over the course of a project.

• Can be used to generate any „box and line“ editors with arbitrary visualization, tool tips, smart buttons, decorators, etc.



GEF and openArchitectureWare sample editor



GEF & openArchitectureWare II

MetamodellGenerator

UML Metamodell in

Java impl.

Exportiertes UML – Modell (XML / XMI)

Domänen-metamodell in Java impl.

Domänen-Modell

Generator für Domäne

GENERATED

...

Untertitel

13.04.2005

Templates

GENERATED

GEF Editor Generator

Editor für einen Teil

der DomäneGENERATED

CREATES / EDITS

Editor Metamodell in Java impl.

Untertitel

13.04.2005

Templates

Modell des Editors (im Instantiator

erzeugt)

INSTANCE OF

INSTANCE OF

Hilfsklasse zur Beschreibung des

Modells eines Editors

GENERATED

USES

Untertitel

13.04.2005

Templates

INSTANCE OF

DEFINES TRANSFORMATION RULES FOR ANY CONCRETE

MODEL OF


MODEL OF


MODEL OF



GMF

• GMF stands for graphical modelling framework and is a project that aims at generating graphical (GEF-based) editors for EMF models.

• As of April 2005, the project is currently being initiated. I expect useful code end of 2005 earliest.• It seems like IBM will be contributing the framework (on

top of GEF) which will be used as the basis against which the code will be generated

• In principle, the approach will probably work the same way as “normal” EMF-generated editors:• You define an EMF metamodel• You build a genmodel from it, where you specify all the

editor-relevant properties of the metamodel.• From that, you generate an editor plugin.



GMF II - Principle



More…

• Merlin generates GEF editors that handle EMF models• GME is a metamodelling/modelling tool for building

DSLs. It is natively a COM tool. There is a Eclipse plugin that can at least show models…



C O N T E N T S





IBM MTF

• MTF is a (currently commercial/alphaworks) model-to-model transformation framework for EMF models.

• It is based on a textual transformation syntax • It can work with bijective transformations, i.e.

• You first define bijective mapping rules between two metamodels (relations),

• In a second step the framework can use these rules to:•Find out whether two models conform to the rules, or what

the differences are•Or modify one of the two models in order to make them

conforming to the mapping rules



IBM MTF II

import ecore http://www.eclipse.org/emf/2002/Ecoreimport emf http:///com/ibm/mtf/model/emf.ecoreimport ws http:///com/ibm/mtf/model/workspace.ecore

relate sample4(ws:IFile file1, ws:IFile file2) {mapPackages(over file1.resource.contents, over

file2.resource.contents)}

relate mapPackages(ecore:EPackage pkg1, ecore:EPackage pkg2 ) when equals(pkg1.name, pkg2.name ) {

mapPackages( over pkg1.eSubpackages, over pkg2.eSubpackages),

mapClasses( over pkg1.eClassifiers,over pkg2.eClassifiers ), mapDatatypes( over pkg1.eClassifiers, over pkg2.eClassifiers ), mapEnums( over pkg1.eClassifiers, over pkg2.eClassifiers )

}

relate mapClasses(ecore:EClass class1, ecore:EClass class2 ) when equals(class1.name, class2.name )

relate mapDatatypes…

relate mapEnums…

http://www.eclipse.org/emf/2002/Ecore



TefKat

• TefKat is a framework from DSTC that is also aimed at model-to-model transformations.

• It does not provide the bijective mapping feature• It provides a textual syntax to describe transformations

from a source metamodel to a target metamodel.• The syntax seems a bit more intuitive to use, mainly

because the rules are uni-directional



TefKat IITRANSFORMATION uml2rel : uml -> rel

IMPORT platform:/resource/transformation/models/simpleuml.ecoreIMPORT platform:/resource/transformation/models/relational.ecore

// Produces a Table and Key for each persistent UMLClass. RULE Class2Table(c, t, k) FORALL UMLClass c WHERE c.kind = "persistent“ MAKE Table t, Key k SET t.name = c.name, t.key = k, k.name = c.name;

// Produces Columns belonging to a Table for // each persistent UMLClass with storable Attributes. RULE Attr2Column(c, a, t, k, col) EXTENDS Class2Table(c, t, k) FORALL Attribute a WHERE hasAttr(c, a, n) MAKE Column col FROM c4a(c,a,n) SET col.name = n, col.owner = t;

// Immediate Attributes of a UMLClass that are primary have // their corresponding Column as part of the Table's Key. RULE KeyColumns(c, a, t, k, col) EXTENDS Attr2Column(c, a, t, k, col) WHERE a.kind = "primary" AND inhAttr(c, a) SET col.belongsTo = k;

PATTERN storable(A) …

PATTERN inhAttr(C, A) …

PATTERN hasAttr(C, A, N) …



openArchitectureWare for M2M

• Since openArchitectureWare is a comprehensive tool suite for MDSD there is also some support for model-to-model transformations.• Graphical model-to-model transformations are currently

being developed as a diploma thesis (well, maybe…).• As of now, you have to program model

transformations agains the very powerful metamodel-API.

• This is easy to understand and ok to use, however, it is procedural



openArchitectureWare for M2M IIpublic void modifyModel(MetaEnvironment metaEnv) { ElementSet allEntites = SCMEntityExtent.findAll(metaEnv); for (Iterator iter = allEntites.iterator(); iter.hasNext();) { SCMEntity e = (SCMEntity) iter.next(); createDAOComponent(e); }}

private void createDAOComponent(SCMEntity e) { SCMDAOComponent c = SCMDAOComponentExtent.newInstance(e, e.Name()+"DAO"); c.setEntity( e ); c.setPackage( e.Package() ); createOperation(e, c, "save"); createOperation(e, c, "delete"); createOperation(e, c, "update");}

private void createOperation(SCMEntity e, SCMDAOComponent c, String opName) { Operation op = OperationExtent.newInstance(e, opName); c.addOperation( op ); op.setReturnType( PrimitiveTypeExtent.findByName(e, ":java:lang:void") ); Parameter p = ParameterExtent.newInstance( e, "value" ); p.setType( e ); op.addParameter( p );}



C O N T E N T S





openArchitectureWare

• openArchitectureWare provides a specialized language for code generation that provides a very efficient way to represent templates.

• Advanced features that are essential for building larger generators are supports, such as • template polymorphism• template inheritance• and template advices are supported (AOP on template level)

• An explicit metamodel representation based on Java classes is supported – which is essential for representing non-trivial domains.

• Many frontends are provided – the code generator itself is independent from the concrete model syntax. They include• Many UML tools,• Visio• Feature-Modelling tools



openArchitectureWare II«DEFINE Root FOR SCMComponent» «EXPAND ImplBase» «IF needsDecoratorProxy» «EXPAND ComponentProxy::DecoratorProxy» «ENDIF» «EXPAND ContextInterface» «EXPAND Interface»«ENDDEFINE»

«DEFINE Interface FOR SCMComponent» «FILE InterfaceFilename» package «InterfacePackageName»; public interface «InterfaceName» { «EXPAND Operation::InterfaceImplementation FOREACH Operation» } «ENDFILE»«ENDDEFINE»

«DEFINE ImplBase FOR SCMComponent» «FILE ImplBaseFilename» package «ImplBasePackageName»; public abstract class «ImplBaseName» extends «BaseClassName» implements «FullyQualifiedInterfaceName» {

protected «FullyQualifiedContextInterfaceName» context() { return («FullyQualifiedContextInterfaceName»)getContextInternal(); } }´ «ENDFILE»«ENDDEFINE»



EMF for Code Generation

• EMF is not a dedicated code generator. • EMF uses code generation internally in order to generate

the metaclass implementations and the editors.• It provides template-based code generation based on the

the JET template engine. • JET uses a syntax that resembles JSP (i.e. it uses escaped

Java code for template control).• For big code generators, this syntax does not scale.

Advanced features (see next slide) are not supported.• Also, there is only a very limited number of frontends

that read models as input for code generation.



oAW/EMF: Best of Both Worlds

• A future release of oAW will be based on EMF.• It will be possible to generate code from EMF models,

even based on dynamic metamodels.• The proven XPAND language will be reused; it will

feature a couple of interesting extensions• among others, AOP for templates.

• A new component-based workflow engine will control the code generation process.• It will be possible to integrate other EMF based tools (such

as OCL checkers, model transformers) into this workflow.



C O N T E N T S





MDDi

• The MDD infrastructure project aims at building the necessary infrastructure for MDSD tool component compostion based on the Eclipse platform.

• The core component will be a model-bus that interconnects editors, transformers and generators in real time.

• As of April 2005, MDDi is still quite early in its development, I would expect useful code not before Q1/2006.

• MDDi is developed in close cooperation with the ModelWare project – a European-Union supported project for model-driven development.



GMT

• The Generative Model Transformer project was orginally intended at building a workflow engine for transformers and generators.

• It is now considered a “pool for collecting interesting research prototypes”. • The goal of producing a production-ready infrastructure

has been dropped if it ever was there• Maybe as a consequence of ModelWare and MDDi

• Currently, the following projects are hosted by GMT:• UMLX: Ed Willink’s M2M language• ATL: Another M2M tool from (french) INRIA• FUUT-je: a simple XML-based code generator developed

and maintained by Ghica van Emde Boas



OMELET

• OMELET is a framework for integrating arbitrary models, model transformations and model representations.

• Metamodels are considered types, models are instances of these types.

• OMELET is maily driven by E.D. Willink.• As far as I can tell, it will probably cooperate/merge with

MDDi.



Eclipse Platform

• Last but not least, the Eclipse platform, IDE and RCP frameworks can be used to integrate all the various tools into a coherent “MDSD-IDE”.

• openArchitectureWare provides a set of libraries and frameworks that help building MDSD IDEs based on Eclipse. This includes• Model Tree Views• An adapted spider view for models• A view that shows model validation messages,• Etc.



C O N T E N T S



THE END.



URLs

• EMF – www.eclipse.org/emf • oAW – www.openarchitectureware.org• GMF – http://eclipse.org/proposals/eclipse-gmf/• MDDi –

http://eclipse.org/proposals/eclipse-mddi/main.html• MTF –

http://zones.advisor.com/doc/15042 http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=910

• Tefkat – http://ww.dstc.edu.au/Research/Projects/Pegamento/tefkat/

• GMT – http://www.eclipse.org/gmt/ • OMELET - http://www.eclipse.org/omelet/



Some advertisement

• Völter, Stahl

• Modellgetriebene SoftwareentwicklungTechnik, Engineering, Management

• dPunkt 2005

• www.mdsd-buch.de

Markus Völter voelter@acm voelter.de

Documents

Transcript of Markus Völter voelter@acm voelter.de