Markus Völter voelter@acm voelter.de

Model-Driven Software Development and Eclipse Markus Völtervoelter@acm.orgwww.voelter.de

About me Markus Völter voelter@acm.org www.voelter.de • Independent Consultant • Based out of Heidenheim, Germany • Focus on • Software Architecture • Middleware • Model-Driven SoftwareDevelopment

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

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.

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 several • Related Approaches (Specializations):MDA, SF, DSM, GP, … Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel textual

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.

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

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

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

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

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…

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…

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 II TRANSFORMATION 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 II public 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 ); }

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.

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 • What is MDSD? • MDSD Infrastructure • Related Eclipse Projects • Meta-metamodelling • Editor Construction • Model Transformation • Code Generation • Infrastructure 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