Download pdf - EclipseCon2010 - Painless Metamodel Evolution

Painless (?) Metamodel EvolutionA pragmatic approach

© 2002 IBM Corporation

Confidential | Date | Other Information, if necessary

A pragmatic approach

Eclipse Con 2010

Christian Saad (University of Augsburg, DE)Etienne Juliot (Obeo, FR)Marc Dutoo (Open Wide, FR)

About the speakers

� Christian Saad - University of Augsburg• Research assistant at the University of Augsburg

• Topics of interest: Model analysis, business processmanagement

� Etienne Juliot - founder of Obeo, FR• Contributes to several Eclipse projects (SCA Tools,

Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 2

• Contributes to several Eclipse projects (SCA Tools, Acceleo, ATL, EEF, ...) and OpenSource communities

� Marc Dutoo - SOA, BPM, ECM architect• Head of R&D Dept. at Open Wide, a French Open

Source software integrator

� With the support of• Stéphane Drapeau, Obeo, FR• The Java Workflow Tooling (JWT) and SCA projects

Overview

� Metamodel evolution is painful !

� JWT (migration)� use case - practices - technologies - automating it

� SCA (extensions)


� SCA (extensions)� use case - analysis - solution

� Further

� Conclusion

Metamodels do evolve !

along with� The business domain

• Driven by new requirements or standards

• Concepts or attributes may be added or become obsolete

� Internal features


� Internal features

� Driven by features of the modeling tool itself

� Ex: layout information

� External features

• Driven by model usage

• Ex: runtime information (logging, transactions) in workflows

Metamodel changes are...

� (too?!) easy to design (EMF & co)

� painful to cope with – for devs and users alike• old models must be migrated (tedious and boring)

• or their legacy metamodels maintained (defeats the purpose)...


the purpose)...

• …if there's actually someone caring enough

� and metamodel evolutions never stopthey just pile up !

... everyone who has really used modeling / MDA has experienced it !

Introducing the JWT use case

� we experienced it at our project• Java Workflow Tooling (JWT)

• An extensible Workflow tool suite in the SOA TLP

� all the more because it aims at• an extensible model (through aspect-like extensions)

that allows to support different runtimes


that allows to support different runtimes

• different GEF-based views on top of it

• compatibility with other workflow standards (through transformations)

1. Alleviating the pain - diagnostic

� Know where you are• store a version number in the model

• version-specific namespace: pros and cons

• Use it if your technology allows it – see next

Manage evolutions


� Manage evolutions• talk about them! (Wiki, release notes, warning dialogs)

• write howtos on evolving legacy models in bugzillas

• ex. "all nodes with a X=Y property now are of type Z"

� But• The user still has to do everything, so it hurts !

1. Alleviating the pain – practices

� Modeling practices: “eager” changes• Adding new nodes breaks nothing

• However Deleting/Refactoring does

Provide abstract nodes with generic semantics


� Write unit tests which load sample models!

� But� Beware of being restricted in metamodel evolutions that won't

break "too much" legacy models

− Default behaviours are inherited

− Ex: Subclassing JWT ExecutableNode

2. Scalpels - using technologies

� Been there, done that : • you've migrated two models by hand, and don't want to do it

again. So code the evolution rules that you documented!

• Ex.: Java EMF - lighter : scripting (groovy)

� BUT source and target metamodels are different:• load both: But still has to code the copy of the part of the


• load both: But still has to code the copy of the part of the original model that didn't change (most of it actually)

� A simple, content-oriented solution : XSL

� … and provide these to model users!• extend the EMF editor actions (yours or the original one), up

to...

• breaking free from java, code, EMF (for best… and worse)

� An EMF solution : ATL• EMF based model to model transformations

3. Healing - automating evolution

� Make the evolution transparent• When evolving (meta)models , most of the work is

the same

• Check version, if not the same as your tool's, find and apply required transformation

� JWT’s ATL model converter


� JWT’s ATL model converter• Lightweight ATL-based framework

• Developers only need to slightly adapt the ATL transformation

• Ask users whether they are OK with automatic transformation before manipulating files!

Introducing the SCA Tools project

� Service Component Architecture (SCA) aims to provide

� A model for the creation of service components in a wide range of languages and

� A model for assembling service components into a business solution


business solution

� SCA Tools project is a set of tools for developers of SCA applications

� The project was created under the SOA Tools Platform (STP) TLP

� The project is moving to the new SOA TLP (move review planned April 7)

SOA Top Level Project

SCA "two-headed" metamodel and its extensions

� SCA was initiated by the Open SOA consortium

� → SCA specifications 1.0

� Currently, the OASIS Open Composite Services Architecture (CSA) Member Section is standardizing SCA


� Each runtime extends the SCA specifications with


� Each runtime extends the SCA specifications with additional Implementation, Interface and Binding types

SCA OSOASCA OASIS

Tuscany 1.x

FraSCAti 1.x

Tuscany 2.x

Runtime x Runtime y

SCA "two-headed" metamodel and its extensions

� SCA was initiated by the Open SOA consortium


� Currently, the OASIS Open Composite Services Architecture (CSA) Member Section is standardizing SCA


� Each runtime extends the SCA specifications with

Objective: to propose a set of tools(XML editors, GMF editors, launchers, ...) based on all these metamodels

The user must have the impression he is using the same tool when he defines an SCA-OSOA or an SCA-OASIS artefact!


� Each runtime extends the SCA specifications with additional Implementation, Interface and Binding types

SCA OSOASCA OASIS

Tuscany 1.x

FraSCAti 1.x

Tuscany 2.x

Runtime x Runtime y

SCA-OASIS artefact!

How we support the "two-headed" metamodel

� For each SCA specifications (OSOA and OASIS), we generated the metamodel and the GMF designer

� The same SCA runtimes extension mechanism is used

� The "two-headed"


� The "two-headed"metamodel and the extensions specific to the different SCA runtimes are transparent for the user

SCA-OASIS SCA-OSOA

How do we support the SCA runtimes extensions?

� A core metamodel: SCA-OSOA or SCA-OASIS� Extensions proposed by the SCA runtimes concern only the Implementation, Interface and Binding types

� Extension of the core metamodels is easy

� Use the "Child Creation Extenders" and "Extensible


� Use the "Child Creation Extenders" and "Extensible Provider Factory" options proposed in the .genmodel

� Extension of the GMF modeler is more difficult

� GMF does not take into account the extension options proposed by EMF

� → Specific code in the sca.diagram plugin

� → New plugin (sca.diagram.extension) to dynamically take into account the extensions

Create your own extension

� First step: extend the SCA metamodel

� Create a new metamodel

� Create a DocumentRoot that extends the DocumentRoot of the SCA metamodel

� Create your own elements that extendImplementation, Interface or Binding


� Generate the code

� Second step: extend the Composite Designer

� org.eclipse.gmf.runtime.emf.type.core.elementTypes

� org.eclipse.gmf.runtime.emf.type.core.elementTypeBindings

� …

� Third step: Extend existing ATL transformations and Acceleo generators

Further

COPE by TUM Munich University (http://cope.in.tum.de)

• Transformations

• by recording metamodel changes

• Mixes automatic and manually defined ones

High level transformation definition

• But


• But

• Developers must be “convinced” to follow this procedure

• Overhead when “trying out” new things in your models

• Changes in semantics only recorded in developer’s mind!

// 1. metamodel adaptation

Signature.inPort.eType = newClass("InPort", [Port])

Signature.outPort.eType = newClass("OutPort", [Port])

Port.’abstract’ = true

// 2. model migration

for(signature in Signature.instances) {

for(port in signature.inPort) port.migrate(InPort)

for(port in signature.outPort) port.migrate(OutPort)

}

Further

� Eclipse Edapt

• New project under EMFT

• Goals

• Migration of model instances, editors, transformations

• Attaching migration instructions to change history

• Approaches


• Approaches

• Recording changes (COPE)

• Extracting changes (EMF Compare)

� Semantic “tagging” of meta model elements

• Research topic

• Fit for every day use?

Conclusion

� From alleviating the pain, up to automated “healing”

� JWT use case

• ATL converter : robust and versatile

• Next: graphical UI help, help migrating models referred by other models, help migrating model transformations...


other models, help migrating model transformations...

� SCA "two-headed" metamodel use case• Simple at EMF model level, harder at GMF UI level, but at the end transparent for the user

• SCA metamodel can be used by others tools: ATL (module superimposition), Acceleo (dynamic templates), EEF

� What about your own experiences ?

Thanks for your attention !

A ny questions???

Contact us at [email protected] [email protected]

or [email protected]


We thank for his assistance:

� Stephane Drapeau, Obeo, FR – SCA project leader

or [email protected]

JWT website & wiki: http://www.eclipse.org/jwt

SCA website : http://wiki.eclipse.org/STP/SCA_Component