67
CTIT June 24, 2009 Amsterdam The Netherlands Editors: Christian Hein Tom Ritter Michael Wagner Second European Workshop on Model Driven Tool and Process Integration (MDTPI) Second European Workshop on Model Driven Tool and Process Integration (MDTPI) CTIT Workshop Proceedings Secretariat CTIT: University of Twente CTIT P.O. Box 217 7500 AE Enschede The Netherlands Phone +31 53 489 3994 ISSN 0929-0672 CTIT proceedings WP09-05 173738-os-CTIT.qxd 03-06-2009 15:39 Pagina 1

Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Proceedings of the firstTwente Data ManagementWorkshop on XML Databases& Information Retrieval

21 June 2004EnschedeThe Netherlands

Editors:Vojkan MihajlovicDjoerd Hiemstra

Secretariat CTIT:University of TwenteCTITP.O. Box 2177500 AE EnschedeThe NetherlandsPhone +31 53 489 80 31ISSN 1574-0846

CTITWorkshop Proceedings

TDM 2004

Secretariat CTIT:University of TwenteCTITP.O. Box 2177500 AE EnschedeThe NetherlandsPhone +31 53 489 80 31ISSN 1574-0846

June 24, 2009AmsterdamThe Netherlands

Editors:Christian HeinTom RitterMichael Wagner

SecondEuropean

Workshop

onM

odelDrivenTooland

ProcessIntegration

(MDTPI)

Second European Workshop onModel Driven Tool and ProcessIntegration (MDTPI)

CTIT Workshop Proceedings

Secretariat CTIT:University of TwenteCTITP.O. Box 2177500 AE EnschedeThe NetherlandsPhone +31 53 489 3994

ISSN 0929-0672CTIT proceedings WP09-05

173738-os-CTIT.qxd 03-06-2009 15:39 Pagina 1

Page 2: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Christian Hein Tom Ritter Michael Wagner (Eds.)

Model Driven Tool and Process Integration

Second European Workshop on Model Driven Tool and Process Integration (MDTPI), Enschede, the Netherlands, June 24, 2009 Proceedings

Enschede, the Netherlands, 2009 CTIT Workshop Proceedings Series WP09-05 ISSN 0929-0672

Fraunhofer Institute for Open Communication Systems

Page 3: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that
Page 4: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Preface

This volume contains the proceedings of the 2nd European Workshop on Model Driven Tool and Process Integration held on 24 June 2009 in Enschede, the Netherlands, in conjunction with the European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA 2009). The 1st workshop held in 2008 has shown that the research area of tool and process integration in a model-driven development environment is emerging and draws more and more attention in particular from industry. The interesting talks and discussions of last year’s event have encouraged us to organize a second edition of the workshop.

The papers included in this year’s edition of the workshop show that there are a variety of relevant topics in this field. The synchronization is obviously an important and multi-dimensional problem, which needs to be addressed adequately. The efficient computation of model-differences is one major task to be accomplished in order to synchronize the work results coming from different developers. The usage of model repositories is closely linked to that task. The working results need to be made durable and accessible for all persons which are part of a development team. Another focal point covered by the papers is the technical integration of tools in order to build tool couplings contributing to the creation of tool chains, which eventually get certified. Finally, the project planning and the processes acting on the tool chains are considered as well.

We would like to take this opportunity to thank the people who have contributed to the MDTPI workshop. We wish to thank all authors and reviewers for their valuable contributions, and we wish them a successful continuation of their work in this area. Finally, we thank the organization of the ECMDA-FA 2009 conference in which this workshop has been embedded.

June 2009 Christian Hein

Tom Ritter Michael Wagner

Page 5: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Organisation

Workshop Chairs

Christian Hein Fraunhofer FOKUS, Germany Tom Ritter Fraunhofer FOKUS, Germany Michael Wagner Fraunhofer FOKUS, Germany

Programme Committee

Terry Bailey Vicinay Cadenas, Spain Maria Agustina Cibran Thales, Belgium Andreas Keis EADS IW, UK Nikola Milanovic Technical University Berlin, Germany Thomas Peikenkamp OFFIS, Germany Andrey Sadovykh Softeam, France

Supporting Projects

Project full title: MODELling solution for comPLEX software systems Contract no 034081

Project full title: Cost-efficient methods and processes for safety relevant embedded systems

Page 6: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Table of Contents

Difference-based Model Synchronization in an Industrial MDD Process ................. 1 Patrick Könemann, Ekkart Kindler, and Ludger Unland

Integration of Microsoft Visio and Eclipse Modeling Framework Using M3-Level-Based Bridges ......................................................................................... 13

Heiko Kern and Stefan Kühne

Mining of Model Repositories for Decision Support in Model Versioning.............. 25 Petra Brosch, Martina Seidl, and Manuel Wimmer

Model-based Integration, Execution and Certification of Development Tool-chains ........................................................................................ 35

B.Polgár, I.Ráth, Z.Szatmári, Á.Horváth, and I.Majzik

Integration by Model-driven Virtual Tool ............................................................... 47 Frédéric Jouault and Thierry Guéguen

MDE Project Execution Support via SPEM Process Enactment ............................. 53 Andrey Sadovykh and Antonin Abherve

Page 7: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that
Page 8: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Difference-based Model Synchronizationin an Industrial MDD Process�

Patrick Konemann1, Ekkart Kindler1, and Ludger Unland2

1 Informatics and Mathematical Modelling, Technical University of Denmark,2800 Kgs. Lyngby, Denmark

[pk|eki]@imm.dtu.dk2 Software Design & Management, Dusseldorf, Germany

[email protected]

Abstract. Models play a central role in model-driven software engineer-ing. There are different kinds of models during the development process,which are related to each other and change over time. Therefore, it is dif-ficult to keep the different models consistent with each other. Consistencyof different models is maintained manually in many cases today. This pa-per presents an approach for automated model differencing, so that thedifferences between two model versions can be extracted and stored. Itcan then be re-used independently of the models it was created from tointeractively merge different model versions, and for synchronizing othertypes of models. The main concern is to apply our concepts to an indus-trial process, in particular keeping usability and performance in mind.

Keywords. Model differencing, Model merging, Model synchronization.

1 Introduction

Models play an increasingly important role in software development. Differenttypes of models are used, which are produced in different phases of the soft-ware development process, with different objectives, and on different levels ofabstraction. A well-known approach is the model-driven architecture (MDA),which distinguishes between platform independent (PIM) and platform specificmodels (PSM). The PSM can then be used to automatically generate parts of thecode for the final software. Many industrial development processes distinguishbetween analysis (mostly PIM) and design (mostly PSM) models; the paperrefers to such a process of sd&m [2].

We discuss the differencing, merging, and synchronizing of models in theanalysis and the design phase of an industrial software development process.Figure 1 gives a brief overview of these scenarios. In step 1 the delta between twomodel versions, of the analysis model in this case, is extracted for documentationpurposes and later reuse. Step 2.a uses this delta to merge version 2 with anotherbranch of version 1. Furthermore, step 2.b uses the same delta to transfer the

� Major part of this work was done at the University of Paderborn, Germany, [1].

1

Page 9: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Analysis Model(version 1)

Analysis Model(version 2)

Deltav1-2

compare

Analysis Model(branch of version 1)

Deltav1-2

Analysis Model(branches merged)

merge with version 2

Design Model(of Analysis version 1)

Deltav1-2

Design Model(of Analysis version 2)

sync withAnalysisversion 2

1. Compare two model versions 2.b. Sync Design model2.a. Merge branches

Fig. 1. Diff and merge to synchronize models

delta to another model type, a design model in this case. These steps are oftenperformed manually today. One goal of this paper is to automate them.

Our contribution consists of the following parts: First, we describe how adelta between two model versions can be computed automatically and stored asa change list independently of the model versions it was created from. Second,we deal with the visualization of change lists. Third, a delta or parts of it canbe transferred semi-automatically to another model version or another modeltype to synchronize them; however, this step can not be fully automated sinceconflicts may occur during a merge. Our main concern is to apply these conceptsto a real project with big models. So we finally report on the experiences we madeconnecting different technologies.

Terms. This section introduces some important terms. Fortsch et al. [5] intro-duce some categories for diff and merge based approaches and compare someof them. The most important categories are symmetric vs. directed delta andunique identifiers. Furthermore, we distinguish between model-dependent andmodel-independent deltas.

A symmetric delta between two model versions contains all differences be-tween them such that it can be used to construct either version out of the deltaand the other version. In contrast, a directed delta can only be used to constructone version from the other and not the other way round. A model-independentdelta can be applied to another model without having the models available fromwhich it was created, and to view and even modify it independently of a model.If unique identifiers are used, each model element has a unique id, which doesnot change over the life-time of the element. Non-id-based approaches exploitsimilarities in the structure of a model to guess which elements of two differentversions actually are the same. This has a big influence on the algorithms fordifference calculation, since heuristics are less efficient than matching elementsby their ids. In contrast, algorithms which use identifiers are called exact. Ourapproach is id-based and uses a model-independent symmetric delta.

2

Page 10: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

«entity,entity »K_Addressbook

K_Contact

+ «P0» name: T_String

K_Group

+ size: T_Integer

+ getSummary() : T_String

«pstr»K_Person

+ birthday: T_Date+ fax: T_String+ «P1» first_name: T_String+ phone_private: T_String

T_String

«pstr»K_Address

+ city: T_String+ country: T_String+ «K0.2» street: T_String+ «K0.1» zip: T_String

T_Integer T_Date

business

0..1

private

0..1

+group 0..1

+subcontacts

0..*

+contacts

0..*1

Fig. 2. The analysis model for the example address book application

2 The development process

Our ideas will be integrated into the process described in this section which isused in the company sd&m [2]. It uses UML class diagrams for two types ofmodels: the analysis model shows the application and its underlying conceptsfrom the customer’s point of view; the design model is closer to the implemen-tation and used by a proprietary code generator. Our concepts are based on butnot limited to this process.

2.1 The models

The example used in this paper is artificial to keep it small and simple. However,the characteristics and modeling techniques of the real project are adopted inour simplified example. Figure 2 shows the analysis model for a simple addressbook application. It shows contacts, which can either be persons or groups; aperson may have two addresses, a private and a business address. The prefix Kdescribes a class in the analysis phase, the prefix T a data type. Except for someextra information, which will be discussed below, this is a standard UML classdiagram.

Figure 3 is a design delta that shows how the design model extends the anal-ysis model. The design classes are named without a K or T prefix. Their relationto analysis classes is indicated by a UML dependency with the stereotype A2D,which stands for analysis to design. It expresses that design classes have all theattributes and associations of the corresponding analysis classes, unless statedotherwise. However, design classes can add or refine attributes or associations.

The main reason for sd&m to make the design model an extension of theanalysis model rather than having two separate models is that there is lessredundancy in these models since every concept is, in principle, stored onlyonce. This way, it is easier to maintain the relation between the analysis and thedesign model. This presentation makes it easy to keep them consistent manually.But this choice has also some disadvantages: the design delta in Fig. 3 has almosttwice as many classes as the explicit design model would have. Moreover, softwareengineers need to build the actual design model from the delta in their mind. Towork on the design, it would be much easier to have an explicit diagram of the

3

Page 11: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

«entity,entity »Addressbook::K_Addressbook

«pstr»Addressbook::K_Address

+ city: T_String+ country: T_String+ «K0.2» street: T_String+ «K0.1» zip: T_String

Addressbook::K_Group

+ size: T_Integer

+ getSummary() : T_String

Addressbook::K_Contact

+ «P0» name: T_String

«pstr»Addressbook::K_Person

+ birthday: T_Date+ fax: T_String+ «P1» first_name: T_String+ phone_private: T_String

PDAConnector

- ip: int- user: String

Address

- code: int

Person

- uid: int

Group

- gid: int

Addressbook

+addressbook 1

+pdaConnections 0..*

«A2D»

«A2D»«A2D»«A2D»

business

0..1

private

0..1

+group0..1

+subcontacts0..*

+contacts

0..*1

Fig. 3. The design model for the example the address book application

design. As we will see in Sect. 2.3, we can split up the analysis and the designmodel without loosing the advantages of the current approach.

2.2 Scenarios: Working with the models

Next, we will briefly discuss the way these different models are used during thedevelopment process and identify some typical synchronization scenarios. Theprocess is incremental and iterative, which means that individual features ofthe application are developed more or less independently of each other. Featurescorrespond to use cases (UC) that are specified in requirement documents earlierin the process. Please keep in mind that we deal with industrial models whichmay be very big, which can easily have more than 1000 classes.

Figure 4 shows an excerpt of the real development process for some features,called UC3, UC4, and UC6. At the beginning (top in the diagram), the analysisand the design correspond to each other, i.e. they are synchronized. Then twoteams start working on the analysis model independently of each other to developUC3 and UC4 respectively. This gives rise to a branch of the analysis model (weindicate the covered use cases of a model version in the lower part of a box).Later a team works on UC6 integrating it into the analysis model covering UC3.After UC4 was integrated into the analysis model, the process also requires itsrealization in the design. Many of the changes that are made in the design werealready made in the analysis (i.e. extensions and modifications). The realizationin the design needs to be done for all use cases.

In the end, there are two different versions of the analysis model, one coveringUC3 and UC6, the other covering UC4 only. The final software must cover alluse cases, so both version have to be merged. A similar common scenario is thecreation of a release that covers only parts of the final application. A reasonmight be that the customer explicitly requested such a release while some otheruse cases (e.g. UC6) are not yet realized. In order to create a release, an analysisand a design model are needed that cover the requested use cases, UC3 and UC4in our example.

4

Page 12: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

ReleaseAnalysis�model

UC3,�UC4Design�model

UC3,�UC4

Analysis�model

Analysis�modelUC3

Design�model

Analysis�modelUC3,�UC6

Analysis�modelUC3,�UC4,�UC6

Analysis�modelUC4

UC3

UC6

UC4

Design�modelUC4

UC4

UC3UC3

merge�UC4

Legend:use case realization

merge

consistencyanalysis/design

redundantoperation

Fig. 4. Exemplary development process

Many of the previously described operations were already performed in thesame or a slightly different way and may be automated—so they are markedwith a ‘smiley’ in Fig. 4. These redundant operations within the analysis seemto be straightforward, but conflicts need to considered similar to commonlyknown text-based merges. The redundant operations on the design model aremore complicated because the structure of the design slightly differs. All theseoperations were performed manually by the developers until now. The modelsare of course stored without much redundancy, as we have seen in Sect. 2.1. Nev-ertheless the design has to be updated for each change. Since all these operationsare performed and documented by hand they are error-prone.

2.3 Improvements

After explaining how the scenarios in Fig. 4 can be improved, this section sum-marizes some problems with the process, and show how we improve the situationby using model synchronization.

The following steps are schematically shown in Fig. 1; the key for our ap-proach are change lists. In step 1 we compare two model versions and storethe differences fully automatically in a change list; e.g. a change list is createdthat contains all (and only) changes made for UC4. Then we use that changelist later to merge UC4 into the analysis version UC3,UC6 (step 2.a). This stepcan not always be automated completely because conflicts may occur and needto be resolved. Furthermore, we can use the same change list to transfer thechanges to the design in order to synchronize it with the analysis (step 2.b); e.g.the design model including UC4 can semi-automatically be produced. The samesteps enables us to produce the requested Release containing UC3 and UC4. Achange list for UC3 can be produced from the original analysis model versionand the one containing UC3. That list can then be used to replace the redundant

5

Page 13: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Correspondencemodel EA meta model Change list

model

Correspondenceinstance

EA model(analysis/design model)

Change list instance

references

conformsconforms conforms

references

references

references

Fig. 5. The meta levels for change lists and correspondences

operations in Fig. 4 creating analysis and design model versions covering UC3and UC4.

To sum it up, instead of documenting all changes manually, our tool is ableto identify all changes between two models fully automatically and compile thesechanges into a change list. So changes between two versions can be documentedfully automatically. Furthermore, that list is independent from the versions it wascreated from – i.e. it can be reused without having the original model versionsavailable. It can then be applied to other models semi-automatically, where thedegree of necessary interaction depends on the scenario.

Moreover, we will make the analysis and the design model explicit, instead ofworking with the design delta only. This, of course, can easily result in inconsis-tencies between the two models. But we use a correspondence graph to transferchanges to the other model to keep them consistent.

3 Concepts

This section explains the concepts of change lists and their usage for modelsynchronization. sd&m uses the modelling tool Enterprise Architect (EA) in theprocess. Fig. 5 gives an overview of how a change list relates to EA models. Themiddle column shows the EA meta model and instances, the actual EA models.Since change lists (instances) refer to EA models, the model for change listsrefers to the EA meta model. The relation between correspondences and EAmodels is similar and will be discussed later in Sect. 3.4.

Every element within the EA has a Global Unique IDentifier (GUID) [9]which does not change over the lifetime of the element, so we can exploit thisGUID for our technique: we use it to identify changes of an element as well asto maintain the relation between the analysis and the design model.

3.1 Change lists

As already indicated in Sect. 2.3, the change list is at the core of our approachand exactly describes all changes between two models. It should be possible toreproduce the changed model from the original model and the change list, andvice versa. It should also be used for documentation and visualization of changes.

6

Page 14: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Change

+ author: String+ date: datetime+ name: String+ note: String

CompositeChange

AtomicChange

+ feature: String+ type: ChangeType

ChangeList

+ source: String+ target: String

ChangeValue

+ value: Object

«enumeration»ChangeType

«enum» add «enum» change «enum» move «enum» remove

«interface»ReferenceToEA

+ guid: String

EA::EANamedElement

+ guid: String+ name: String

+dependants*

+dependsOn*

+eaElement 0..1

0..1

+targetValue

0..1

0..1

+sourceValue

0..1

+subChanges *

+container0..1

+changes

*

+list

0..1

Fig. 6. A model for change lists

Figure 6 shows the model for change lists. In order to structure changes, themodel distinguishes between CompositeChanges and AtomicChanges. Further-more, each Change has a name, an author, a date, and a note.

In the context of this paper, the most interesting issue are the atomic changes.There are four types of atomic changes: add, change, move, remove, which aredefined in the ChangeType. The attribute feature refers to the element thatwas changed, the sourceValue and the targetValue define the values before resp.after the change, if applicable for the type of change. We also need dependenciesbetween changes to selectively transfer changes to other models (see Sect. 3.3 fordetails). They are represented using the association dependsOn - dependencies.

To be model-independent, atomic changes as well as the ChangeValues actu-ally use ReferenceToEA to refer to an element of the EA model. This referenceis symbolic, i.e. it refers to a GUID only. The reason for that is, that we do notwant to attach a change list to a concrete EA model since it should be possibleto use the change list on different models and different versions of a model. Forthe very same reason, the reference to the source and the target of the completeChangeList is symbolic only.

3.2 Creating a change list

Next, we present the algorithm for creating a change list from a source and atarget model (a changed version of the source model). The algorithm is id-based,exact, and it creates a model-independent and symmetric delta.

It first iterates over all elements of the source and the target model versionsto determine all removed and added elements respectively. Second, all elementsoccurring in both versions are checked for changes and movements. Third, de-pendencies between all changes are calculated (see Tab. 1 for details).

This simple algorithm identifies and stores all differences between two modelversions. The left part of Fig. 7 shows the most important columns of a changelist, the type, the changed feature, a description, and the old and new value (ifthey exist). A change of type add, for instance, does not contain a String as anew value; instead it contains a copy of the newly created element (cf. reference

7

Page 15: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Fig. 7. Left: excerpt of a change list; right: validation result

Change type Change depends on elements

change none (besides the changed element)

add The parent of the added element

remove The parent of the removed element

move The old and the new parent of the moved elementTable 1. Description of the dependent elements against change types

eaElement in Fig. 6), which is not visible in the table view. The right part ofthe figure is discussed in the next section.

The dependencies are important because they are later used for validationand change application order. A dependency between two changes is defined asfollows (see Tab. 1): Change CA depends on change CB if CA depends on anelement that is changed by CB and CB is of type add or remove. Figure 7 showsan example ([1] gives examples for all cases): A new package ’Datatypes’ wasadded (row 4), and some classes are moved to that package (rows 7–9). So allthese changes of type move depend on the change in row 4. For validation lateron, if (for any reason) the change describing the new package is invalid, thenthe changes describing the moved classes are also invalid. When the changes areapplied to another model, the order of application is important—of course, theclasses cannot be moved until the package is created.

3.3 Applying a change list to another model version

In this section, we describe the way change lists can be used to merge changes intoanother version, e.g. for merging two branches (cf. Fig. 4). Conflicts are handledthe following way: (1) All changes are validated against the target model version.(2) Suggestions are made how to handle each change and presented to the user.(3) Users may either accept the suggestions and apply the changes, in case noconflicts occurred. But if the users wants to change the suggestions or if conflictsoccurred, they have to change some status flags and continue with step (1).

We use the flag Valid to express whether a conflict exists or not. The flagApply expresses the suggestions and may be modified by the user.

We consider two causes for conflicts: Either elements on which some changeswere made according to the change list might not exist any more, or these el-

8

Page 16: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Analysismodel

Designmodel

«A2D»

«A2D»

«A2D»

Analysismodel Correspondences Design

model

Generated with Triple Graph Grammars

Fig. 8. Old relation (left) and correspondences (right) between analysis and design

ements might have changed differently. In the first case, the change cannot beapplied at all and must be ignored. In the second case, the conflict must eitherbe resolved explicitly or the change must be ignored. The validation (conflictdetection and suggestion making) is described in more detail in [10]:

Users have different choices to solve a conflict: Either they decide to ignorethe change (and possibly modify the resulting model manually afterwards) or tomake some modifications on the model or the change list first so that the changecan be applied. A change list can be applied only if all conflicts are resolved, i.e.all changes are either valid or ignored.

Disregarding technical details, applying valid changes is straightforward.

3.4 Applying a change list to a design model

As discussed in Sect. 2.3, the development process requires that changes madein an analysis model must also be transferred to a corresponding design model.The actual transfer is very similar to a merge of two versions of the analysismodel, once it is clear how the elements of the analysis model correspond to theelements of the design model. In the previous section, elements were matchedusing their GUIDs—that works because a different version of the same model isused. The design model is another model with new GUIDs1, so we need anotherstrategy to match design elements to the corresponding analysis elements.

Correspondences. Until now, the relation between the analysis and the de-sign was maintained with stereotyped UML dependencies, as indicated in theleft-hand side of Fig. 8. From now on, the design model is independent from theanalysis model; the relation between both models will be maintained in a sepa-rate data structure: in correspondences. We use Triple Graph Grammars [11, 8]to build correspondences and the new design model. This model transformationand its rules are described in [1].

There are three types of correspondences which express the relation betweenelements from the analysis and the design: the first one describes a relationbetween elements from both models (as it is shown in the right-hand side ofFig. 8); the second and the third ones point only to an element from the analysis1 EA creates its own read-only GUIDs for all elements, they cannot be changed.

9

Page 17: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

respectively design model meaning that there is no corresponding element in theother model. Thus, correspondences store whether an element does or does nothave a corresponding element in the other model. Referencing works symbolicallyvia the respective GUIDs.

Applying the change list. The algorithm for applying a change list is verysimilar to the one in Sect. 3.3. But instead of using GUIDs stored in the changelist to match elements in the design model, we need correspondences to lookup the design elements. In addition to the conflicts that are already describedin Sect. 3.3, the correspondences need to be considered as well, so we use yetanother flag here. We omit the details here, which are given in detail in [10].

3.5 Summary

We have seen how two model versions can be compared, and how differences areidentified and represented in a change list. This change list can then be used tovisualize and to transfer changes to other models—even without having the twomodels available from which the change list was created. Furthermore, a changelist in combination with a correspondence model can be used to synchronize withanother kind of model, a design model in our case. The key to this flexible modelsynchronization are the different status flags and, for practice, the flexible toolfor viewing and manipulating change lists and their validation results.

4 Summary and Conclusion

The contribution of this paper is a model synchronization concept using changelists, and experiences with industrial sized models. The development process hasdifferent scenarios that are time-consuming and error-prone due to redundantmanual work, as discussed in Sect. 2.2. So we introduced change lists for differ-ence representing between two model versions. They are created automaticallyand can then be used for branch merging and model synchronization. A changelist is model-independent, i.e. it can be used without having the models avail-able it was created from. Next, we briefly outline the implementation, evaluateperformance, compare our approach to related work, and discuss future work.

Implementation. The presented process uses the EA for creating and main-taining the models; the transformation engine we used is based on the EclipseModeling Framework (EMF). Thus, we developed an adapter to access modelsfrom the EA from within EMF2. Limitations, however, are that the approachis currently only working with the EA, and it ignores diagrams; however, alldiagrams are still readable and must be refreshed after change list applications.More details and information about the adapter and the GUI, including changelist visualization and conflict resolution, can be found in [10].2 The adapter can also be used for other purposes since it provides a generic access tomodels from the EA.

10

Page 18: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Performance. We integrated most of our concepts into the process with ac-ceptable delays, for instance by regularly scheduled time-consuming change listcreations. The experiments with industrial models show that there is need for im-proving efficiency. The bottleneck is the Automation Interface of the EA, whichmakes model access easy at the cost of performance. For example, applying achange list with 1521 differences to a model with roughly 11.000 elements takesaround 30min. But almost 80% of the time is just used for transmitting the datafrom the EA to EMF, the actual model changes are performed much faster.

Comparison to other approaches. None of other known approaches fitsour needs to store the delta symmetric and model-independent, and are able towork with EA models. Especially the transfer of changes to another model typeis unique, although [4] has a similar approach.

EMF Compare3 has a sophisticated framework for comparison, differencepresentation, and conflict resolution. It works with and without unique identi-fiers, so in combination with our adapter, the difference calculation also workswith EA models. However, the differences always refer to the originating mod-els, i.e. it is not model-independent and hence not applicable to the presenteddevelopment process.

The IBM Rational Software Architect4 operates on UML models with uniqueidentifiers and provides difference visualization and conflict resolution. But sim-ilar to EMF Compare, it also create model-dependent differences.

[6] distinguishes three different change types: add, remove and change. Amoved element will be represented as by a delete and created command. But asa set of commands, this format is not feasible for the use with change lists.

The meta model of [7] for representing differences between models is similarto our approach, unfortunately it works on code and not on models. Experimentswith a lot of code showed a bad performance (e.g. creating a change list for anexample model with about 800 classes took—depending on the differences—between 30 and 50 minutes).

Indeed, [4] covers most of our criteria, but unlike our approach, it cannottransfer changes selectively. The reason is that they do not maintain dependen-cies between changes. Furthermore, the visualization of changes is not clearlyarranged for big models and does not support filtering.

Future work. We achieved most of our goals for the examined process, ex-cept for the following. Change lists cannot be concatenated easily, because thedependencies between changes are consistent within one change list only. Forconcatenations, the conflicts must be re-calculated.

Our work gives also rise to interesting conceptual questions: The tool allowsus to identify differences between an analysis and a design model in an MDDprocess. Conceptually, these changes are—or at least document—the design de-cisions taken in the project. These changes are currently maintained on a very3 http://www.eclipse.org/emft/projects/compare/4 http://www.ibm.com/software/awdtools/architect/swarchitect/

11

Page 19: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

low technical level so that they are not of much help for documenting the de-sign decisions. But we believe that from this low-level information, the designdecisions on a higher level can be generated automatically, and presented to thedeveloper5.

Acknowledgement. We would like to thank sd&m for the insight into their processes

and the support we got from them. Many thanks to Johannes Jakob and Alexander

Konigs for their Enterprise Architect meta model [3].

References

1. Konemann, P.: Verbesserung eines modellbasierten Softwareentwicklungsprozessesmit Hilfe von Modellsynchronisation. University of Paderborn, Software Engineer-ing Group, Germany, Master thesis (2007)

2. Unland, L., George, T.: MDA richtig einsetzen: Klassische und innovative Rezepte.OBJEKTspektrum 6 (2005) 41–44

3. Amelunxen, C., Konigs, A., Rotschke, T., Schurr, A.: MOFLON: A Standard-Compliant Metamodeling Framework with Graph Transformations. In Rensink,A., Warmer, J., eds.: Model Driven Architecture – Foundations and Applications:Second European Conference. LNCS 4066, Springer, (2006) 361–375

4. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: A Metamodel Independent Approachto Difference Representation. Journal of Object Technology 6 (2007) 165–185

5. Fortsch, S., Westfechtel, B.: Differencing and Merging of Software Diagrams –State of the Art and Challenges. In Filipe, J., Helfert, M., Shishkov, B., eds.:International Conference on Software and Data Technologies (ICSOFT), Setubal(Portugal). Volume 2., Institute for Systems and Technologies for Information,Control and Communication (2007)

6. Alanen, M., Porres, I.: Difference and Union of Models. In Stevens, P., Whittle,J., Booch, G., eds.: UML 2003 – The Unified Modeling Language. LNCS 2863,Springer (2003) 1–17

7. Xing, Z., Stroulia, E.: UMLDiff: An algorithm for object-oriented design differenc-ing. In Redmiles, D.F., Ellman, T., Zisman, A., eds.: 20th IEEE/ACM Interna-tional Conference on Automated Software Engineering (ASE 2005), Long Beach,CA, USA, ACM (2005) 54–65

8. Schurr, A.: Specification of Graph Translators with Triple Graph Grammars. InTinhofer, G., ed.: WG’94 20th Int. Workshop on Graph-Theoretic Concepts inComputer Science. LNCS 903, Springer (1994) 151–163

9. Sparx Systems Pty Ltd Victoria, Australia: EA User Guide. (2008) Version 7.5.10. Kindler, E., Konemann, P., Unland, L.: Diff-based Model Synchronization in an

Industrial MDD Process. IMM-Technical Report-2008-07, Technical University ofDenmark (2008)

11. Greenyer, J., Kindler, E.: Reconciling TGGs with QVT. In Engels, G., Opdyke,B., Schmidt, D.C., Weil, F., eds.: Model Driven Engineering Languages and Sys-tems, 10th International Conference, MoDELS 2007, Nashville, USA. LNCS 4735,Springer (2007) 16–30

5 The project Model-synchronization Technology for Model-Based Software Engineer-ing at the Technical University of Denmark is currently doing research in this area.

12

Page 20: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Integration of Microsoft Visio and EclipseModeling Framework UsingM3-Level-Based Bridges

Heiko Kern and Stefan Kuhne

Business Information Systems, University of LeipzigJohannisgasse 26, 04103 Leipzig, Germany{kern|kuehne}@informatik.uni-leipzig.de

Abstract. Nowadays there are powerful tools for Model-Driven De-velopment. An ongoing problem is the insufficient tool interoperabilitywhich complicates the development of complete tool chains or the reuseof existing metamodels, models, and model operations. In this paper wepresent the approach of M3-Level-Based Bridges and apply this approachto enable the interoperability between two selected tools. The first tool isMicrosoft Visio with strengths in modelling and information visualizationand the second tool is the Eclipse Modeling Framework with advantagesin model processing by transformation and generation tools.

1 Introduction

The approach of Model-Driven Development (MDD) [1] has gained in relevanceduring the last decade. The consequent use of models, modelling languages andmodel operations as central concepts in this approach leads to several advantages:a better handling of complexity, more efficient development processes, and im-proved software quality, to name a few. Today powerful tools are available for thesupport of typical MDD tasks such as language definition, modelling or modelprocessing. But an ongoing problem is the insufficient tool interoperability [2,3]. This lack of interoperability complicates the development of complete toolchains or the reuse of existing metamodels, models, and model operations in adevelopment process.

In this article, we present the approach of M3-Level-Based Bridges (M3B)to achieve tool interoperability between different MDD tools. We apply this ap-proach to realise the interchange of metamodels and models between two selectedtools: Microsoft Visio [4] and Eclipse Modeling Framework (EMF) [5]. MicrosoftVisio is a widely used commercial tool that is mainly suitable for modelling andvisualising information. Visio provides the definition of modelling languages byusing stencils. The tool is part of the Microsoft Office Suite that enables theintegration into other Microsoft products. In addition, there are many tools andadd-ons (ViFlow1, SemTalk2, etc.) that provide the modelling in specific do-mains, for instance, in business process management. The second tool or, more1 http://www.viflow.com2 http://www.semtalk.com

13

Page 21: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

precisely, framework is given by the Eclipse Modeling Framework and by tools(Epsilon3, openArchitectureWare4, etc.) based on this framework. EMF allowsthe definition of domain-specific metamodels and provides basic functionalities,such as a serialization function, a generator language, and an API to access(meta)models. In summary, the motivation to build an M3B between Visio andEMF is that both tool spaces can benefit from the created interoperability be-cause Visio has advantages in modelling and EMF provides a wide range ofmodel processing tools.

The paper is structured as follows: in the following section, we will give aconceptual overview of M3B. As the bridge is based on the mapping betweenmetametamodels, we will explore the metamodel hierarchy of Visio and EMFin section 3. Then, we will present the development of the bridge and show anexample in section 4. Lastly, we will give an overview of related works in section 5and will present our conclusions in section 6.

2 M3-Level-Based Bridges

The M3B approach is well-established and has been successfully applied in build-ing bridges between different tool spaces. M3Bs are, for instance, the ARIS5-to-EMF bridge [6], MetaEdit6-to-EMF bridge [7], or XML-to-EMF [5] bridge.Although the implementation of such bridges can differ in technical terms, theconceptual approach is the same.

A basic prerequisite to construct M3Bs is the existence of a metamodel hi-erarchy [8] consisting of three levels. At the lowest level (M1-level) are modelswhich describe a software system. The structure of these models and the availableconcepts that can be instantiated in these models are defined by a metamodelat M2-level. Finally, the structure and the available concepts of the metamod-els are defined by a metametamodel at M3-level. Models, metamodels and themetametamodel are connected by a linguistic instance relationship [8] that canalso be denoted as conform-to relationship [9].

Based on the existence of such hierarchies, the basic step to build an M3Bis the mapping between the metametamodels. The mapping consists of differentmapping rules that specifiy the relation between semantically equivalent con-cepts. Semantic equivalence means, for instance, that the concepts at M3-levelwhich express relationships at M2-level are mapped onto each other. Furthersemantic concepts are described in [7] and include, for instance, object type,attribute type or data type. Based on the mapping specification, the transfor-mation of metamodels and models can be derived. To create the transformations,it is necessary to know how the conform-to relationship is realised between eachlevel. The M2-level transformation maps metamodels between hierarchies. The

3 http://www.eclipse.org/gmt/epsilon/4 http://www.openarchitectureware.org5 http://www.ids-scheer.com6 http://www.metacase.com

14

Page 22: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

M1 M2 M3 M4

MM1

MMM

MM2

M1' M2' M3' M4'

MM1'

MMM’

MM2'

M1

M2

M3Mapping

Transformation

Transformation

conform to

conform to conform to

conform to

Fig. 1. Pattern of M3-Level-Based Bridges

metamodels in both hierarchies are isomorphic. Analogous to the M2-level trans-formation, the M1-level transformation enables the mapping of models. Thesemodels are also isomorphic. Figure 1 shows the concept of M3B.

The use of the transformation taxonomy from Mens et al. [10] characterisethe transformations as follows. The M2-level transformation is horizontal andexogenous because the abstraction level stays the same and the metametamodelsare different. The M1-level transformation is horizontal and endogenous becausethe abstraction level also stays the same and the metamodels are equal.

3 Modelling with Visio and EMF

3.1 Model Structure in Visio

A linguistic metamodel hierarchy consisting of three levels occurs in Visio: V3model at M3-level, stencils at M2-level, and Visio models at M1-level. In thissection we present the data structure for Visio models at M1-level in order todescribe the M1-level transformation later.

To analyse the data structure we have used mainly the Visio object model7

(Visio’s programming interface) and the user interface. A snippet of the modelstructure is shown in Figure 2. Visio models are stored in documents that areusually files with a name. A document consists of pages. A page has also a nameand is a canvas that contains shape elements. A shape is a model element and isan instance of a master from a stencil. Hence, a shape has a reference attributeto a master. A shape can have its own data properties (defined only at M1-level) and data properties defined in a master (defined at M2-level). A page canlikewise have data properties. Data properties store values with a specified datatype. Visio supports data types such as text, numbers, time, date, currency andlist. Furthermore, a shape can contain other shapes and can be connected withother shapes.

7 http://msdn.microsoft.com/en-us/library/aa342179.aspx

15

Page 23: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

name : string

Document

name : string

Page

1 *

pages

text : stringmaster : master

Shape

*

1shapes data type : visioDataType

value : datatype

Data Property

*1 properties

*

*

connects

1 *

properties

**

contains

Fig. 2. Data Structure of Visio Models

3.2 Metamodelling in Visio

Visio offers the functionality for building Domain-Specific Languages (DSL) [11].The (concrete and abstract) syntax of a DSL can be defined by stencils. Anal-ogous to the analysis of the model structure, we have studied the object modeland the user interface. The result of the analysis is a metametamodel that ex-plicates the language definition concepts. This metametamodel is here denotedas V3 model (see Fig. 3).

Contrary to other metametamodels, the V3 model is relatively simple. It con-sists of Stencil, Master, and Data Property. A stencil (instance of Stencil)is a set of masters (instances of Master). A master describes a class of modelelements (in Visio denoted as shape – see previous subsection) which can existon their own. Masters can occur in two forms: a simple shape and a connectionshape. In the context of a graph, a simple shape and a connection shape canbe regarded as a node and an edge, respectively. A further metamodelling con-cept is to define properties (instances of Data Property). Each data propertyis assigned to a master, has a data type, and can have a default value.

In addition to defining an abstract syntax, Visio provides the description ofa concrete syntax. Each master owns a graphical form which can be any kindof graphical construct (e.g. rectangle, circle, line, icon, star, polygon, ellipse,a combination of these figures, etc.). Data properties can also be displayed astextual annotation.

name : string

Stencilname : stringisConnection : bool

Master*1

masters Data type : visioDataTypevalue : data type

Data Property*1

properties

Fig. 3. Definition of Visio Stencils

16

Page 24: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

3.3 Metamodels and Models in EMF

Contrary to Visio, developed especially for modelling and information visual-ization, EMF is designed to support the development of (Eclipse) applications.Models describing EMF applications can be regarded as metamodels and in-stances of these metamodels can be regarded as models. All metamodels areinstances of the metametamodel Ecore which is implemented in EMF.

A simplified subset of Ecore is shown in Figure 4. The main elements of Ecoreare EPackage, EClass, EReference and EAttribute. An EPackage is identifiedby an Uniform Resource Identifier and contains a set of EClassifiers. An EClassi-fier can be an EClass or an EDataType. An EClass defines an EMF metamodelelement that represents a set of similar model entities. EClasses can have ERef-erences which express unidirectional relationships between two EClasses. AnEClass can additionally have EAttributes to express properties of this EClass.The range of the attribute values are specified by an EDataType such as EInt,EString or EDate. A further metamodelling concept is the inheritance betweenEClasses.

Apart from considering the structure of Visio models (see Section 3.1), weneed to know the structure of EMF models in order to build the M1-level trans-formation. Every model element in EMF is an EObject specified by a Javainterface. The EObject interface provides different methods which enable thenavigation in models and allow the query of metatype information. For instance,the EObject.eGet(EStructuralFeature) method returns either all EObjects, ref-erenced by a certain EReference, or values of the EAttributes. Further, the EOb-ject.eClass() method returns the EClass of a model element.

EClass

EReference

EDataTypeEAttribute

eReferenceType

eAttributeType

EStructuralFeatureeStructuralFeatures

eSuperTypes

EPackageeClassifiers

EClassifier

Fig. 4. Subset of Ecore

17

Page 25: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

4 Microsoft Visio to EMF Bridge

4.1 Overview

Microsoft Visio and Eclipse EMF can be divided into three levels: M3 (V3 andEcore), M2 (Visio stencils and EMF metamodels), and M1 (Visio models andEMF models). Based on this level structure, we apply the approach of M3-Level-Based Bridge (see Fig. 5). The M3-level mapping specifies an unidirectionalmapping from V3 to Ecore. Using this mapping, we can derive the transformationrules at M2-level which export stencils to EMF. Several transformation rules mapdifferent Visio concepts onto one Ecore concept. To distinguish the different Visioconcepts in Ecore, we introduce an abstract EMF metamodel that approximatesthe data model structure of Visio (see Fig. 6). All exported metamodel elementsare inherited from a corresponding abstract metamodel element. For our purpose,the export of stencils is sufficient and we will therefore ignore the import of EMFmetamodels to Visio. The consideration of this import would be possible on thecondition that all metamodel elements are inherited from an abstract metamodelelement. Based on the M3-level mapping and M2-level transformation, we canderive the M1-level transformation which enables the export and re-import ofVisio models.

Eclipse EMF

Ecore

conforms to

conforms to

Model

conforms to

M3

M2

M1

Microsoft Visio

V3

conforms to

Datamodel

Stencil

Metamodel

generalization

M2-leveltransformation

M1-leveltransformation

M3-level mapping

based on

Model

Stencil

Data model EObject

determinates determinates

instance of instance of

basedon

Fig. 5. Overview of the Visio-to-EMF Bridge

18

Page 26: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

4.2 M3-Level Mapping

We propose the following mappings:

Stencil �→ EPackage: In Visio a stencil contains a set of modelling conceptsin terms of masters. A similar concept in Ecore is the EPackage concept.EPackage can also group modelling concepts. Therefore, we map Stencilonto EPackage. The name of Stencil maps onto the name of EPackage andthe association masters maps onto the reference eClassifiers from EPack-age.

Master �→ EClass: In Visio a master can define a set of model elements. Thecorresponding concept in Ecore is the EClass concept which can also definea set of model elements. Hence, we map Master onto EClass. The stencilof a master is equivalent to the EPackage of the corresponding EClass. Thename of Master maps onto the name of EClass.

Data Property �→ EAttribute: A data property in Visio and an EAttribute inEcore can be used to describe properties of a set of modelling elements. Thus,we map Data Property onto EAttribute. The name of a data propertyis equal to a name of an EAttribute. Visio supports data types such as:string, number, list, boolean, currency, date and time. We map these typesas follows {Visio data type �→ EMF data type}: {string, currency, date, andtime �→ EString}, {number �→ EInt}, {booelan �→ EBoolean}, {list �→ multi-value EAttribute}.

4.3 M2-Level Transformation

The M2-level transformation consists of transformation statements which arederived from the M3-level mapping specification. The mapping rule Stencil �→EPackage transforms all stencils in EPackages. The rule Master �→ EClasstransforms all masters in EClasses. If the masters are a simple shape, thenthe corresponding EClasses are inherited from the abstract EClass “Shape” (seeFig. 6). If the masters are a connection shape, then the corresponding EClassesare inherited from the abstract EClass “Connection” (see Fig. 6). The last ruleData Property �→ EAttribute transforms all data properties to EAttributeswith the equivalent data type and optional with a default value.

4.4 M1-Level Transformation

The M1-level transformation contains transformation statements which are alsoderived from the M3-level mapping specification. The mapping rule Master �→EClass transforms all shapes (instances of a certain master) to EObjects (in-stances of the EClass corresponding to the master). The rule Data Property �→EAttribute causes the transformation of all property values of a shape intovalues of an EAttribute which corresponds to the shape’s EClass. The ruleStencil �→ EPackage has no effect at the M1-level. In addition to the derivedtransformation rules, graphical model data such as symbol position or symbol

19

Page 27: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Document Page

Shape

Connection

Attribute

1 *

pages

*

1shapes

*

*

contains

1*

properties

*1 properties

*

*

connects

Fig. 6. Abstract Visio Data Model in EMF

size is transformed into EMF model data. Furthermore, all data properties de-fined at M1-level are transformed into instances of the EClass “Attribute” takenfrom the abstract metamodel.

4.5 Implementation

We have prototypically realised the Visio-to-EMF bridge as an Eclipse plug-in. The bridge consists mainly of three parts. The first part is the M2-leveltransformation which creates EMF metamodels from stencils. We have writtena C# program that exports stencil data as an XML document. This document isread by a stencil reader that is implemented in Java. The model is transformedafterwards, according to the M2-level rules. The transformation builds an in-memory object model and serialises the objects as an XMI file in Ecore format.

The second part of the bridge is the M1-level transformation with Visiomodels as input and EMF models as output. Analogous to the stencil export,a C# program creates an XML document containing the Visio model data.Furthermore, we have implemented a model reader and the transformation rulesin Java. The reader navigates through the Visio model and creates EMF modelelements. The EMF model is also created in a dynamic way (i.e. in-memory)and is serialised as an XMI file.

The third part of the bridge is the M1-level transformation with EMF mod-els as input and Visio models as output. The transformation creates an XMLdocument from the EObject model with XPand8. The document contains theVisio model data which is parsed by a C# program. This program creates theVisio model by using the Visio programming interface.

4.6 Use Case

A concrete example should illustrate the Visio-to-EMF bridge. In this case wewant to export Event-Driven Process Chains (EPC) [12] from Visio to EMF in8 XPand is a part of openArchitecureWare.

20

Page 28: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

order to reuse a validation approach for business processes [13] that we havealready implemented with EMF-based tools.

EPC is a graphical modelling language to describe business processes. EPCmodels consist of nodes and arcs. Nodes can be functions, events, or connectors.Arcs between these elements represent the control flow. Connectors are usedto model parallel (AND-connectors) and alternative (XOR-connector and OR-connector) executions.

Figure 7 shows at the left-hand side the metamodel hierarchy with the V3model, EPC stencil and EPC model that is to be transformed into EMF. The re-sults of the transformations are the EMF metamodel and the EMF model at theright-hand side. Afterwards, we need to transform the exported EMF-Visio mod-els into EMF models conforming to an EPC metamodel used by the validationrules. This transformation is easy to realise by a model-to-model transformationwith EMF-based transformation tools. Thereafter, we can apply the validationrules to check the models. In this case the model contains no errors.

The above example is very specific but, it is also possible to use other stencilsand Visio models. Furthermore, the usage of other bridges from EMF to othermetamodel hierarchies enables the usage of further tools. For instance, the ARIS-to-EMF bridge enables the application of ARIS tools.

Order received

Check order

Order validOrder invalid

Fulfil orderRefuseorder

Order processed

XOR

Stencil Master*1 masters

XOR

EPC:Stencil XOR:Master

Event:Master

Function:Master

Connection:Master

masters

masters

masters

masters

XOR

M1

M2

M3 EPackage EClass*1 eClass

EPC:EPackage XOR:EClass

Event:EClass

Function:EClass

Connection:EClass

eClass

eClass

eClass

eClass

Microsoft Visio Eclipse EMF

Fig. 7. Export of Visio-EPC models to EMF-EPC models

21

Page 29: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

5 Related Work

As already mentioned in section 2, the M3B approach occurs in many casessuch as ARIS-to-EMF [6], MetaEdit-to-EMF [7], EMF-to-XML [5] or XML-to-Relational Database [14]. All these bridges apply the same pattern to integratedifferent metamodel hierarchies. They define a mapping on the M3-level and usethe instance-of relationship between the underlying level to transform metamod-els at M2-level and models at M1-level.

In the context of tool integration, the existing approaches are manifold. Re-garding the level of transformation, the M3B approach is based upon a mappingonto the M3-level. Other approaches [15, 2] work on M2-level, that is, the in-tegration is based on a transformation between metamodels correlating to thedata models of the tools.

Furthermore, there are generic data formats such as the XML Metadata In-terchange [16] or the Graph eXchange Language (GXL) [17]. GXL, for instance,offers support for exchanging instance graphs together with their appropriateschema information in an uniform format. GXL is based on typed, attributed,ordered directed graphs, which are extended by concepts to support the repre-sentation of hypergraphs and hierarchical graphs. Theoretically, GXL could beused in order to realise the exchange of the data between each level. For this,each model has to be transformed into this graph format.

6 Summary and Conclusion

In this paper, we have developed an interface for the exchange of metamodels andmodels between Microsoft Visio and Eclipse EMF by applying the concept of M3-Level-Based Bridges. For this purpose, we explored the Visio stencil definitionconcepts and the underlying data structure of models. Furthermore, we describedthe metametamodel Ecore and the generic model storage structure of EMF.Based on this information, we specified an M3-level mapping and derived an M2-level and M1-level transformation. Based on the transformation specification,we have implemented the bridge as an Eclipse plug-in. Furthermore, we havedemonstrated the bridge by an example of EPC export. M3-Level-Based Bridgeshave already been used repeatedly to achieve (meta)model interchange betweendifferent tools based on metamodel hierarchies. As a result of the developmentand the study of this bridge and other bridges, we can say that this approach isuseful to build tool chains and to reuse models and model operations. In a nextstep, we want to describe the concept in a more formal way than presented inthis paper.

22

Page 30: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

References

1. Stahl, T., Volter, M.: Model-Driven Software Development – Technology, Engi-neering, Management. John Wiley & Sons Inc. (2006)

2. Bezivin, J., Bruneliere, H., Jouault, F., Kurtev, I.: Model Engineering Supportfor Tool Interoperability. Proceedings of the 4th Workshop in Software ModelEngineering (WiSME) (2005)

3. Karsai, G., Lang, A., Neema, S.: Tool Integration Patterns. Workshop on ToolIntegration in System Development (TIS) (2003)

4. Biafore, B.: Visio 2007 Bible. John Wiley & Sons Inc. (2007)5. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: Eclipse Modeling Frame-work. The Eclipse Series. Addison-Wesley Longman (2009)

6. Kern, H., Kuhne, S.: Model Interchange between ARIS and Eclipse EMF. InTolvanen, J.P., Gray, J., Rossi, M., Sprinkle, J., eds.: 7th OOPSLA Workshop onDomain-Specific Modeling at OOPSLA 2007. (2007)

7. Kern, H.: The Interchange of (Meta)Models between MetaEdit+ and Eclipse EMFUsing M3-Level-Based Bridges. In Tolvanen, J.P., Gray, J., Rossi, M., Sprinkle,J., eds.: 8th OOPSLA Workshop on Domain-Specific Modeling at OOPSLA 2008.(2008)

8. Kuhne, T.: Matters of (Meta-) Modeling. Software and Systems Modeling 5(4)(2006) 369–385

9. Bezivin, J.: On the Unification Power of Models. Software and System Modeling4(2) (2005) 171–188

10. Mens, T., Czarnecki, K., Gorp, P.V.: A Taxonomy of Model Transformations[online]. In Bezivin, J., Heckel, R., eds.: Language Engineering for Model-DrivenSoftware Development. Number 04101 in Dagstuhl Seminar Proceedings, Interna-tionales Begegnungs- und Forschungszentrum (IBFI), Schloss Dagstuhl, Germany(2005)

11. Kelly, S., Tolvanen, J.P.: Domain-Specific Modeling – Enabling Full Code Gener-ation. John Wiley & Son, Inc. (2008)

12. Keller, G., Nuttgens, M., Scheer, A.W.: Semantische Prozeßmodellierung auf derGrundlage Ereignisgesteuerter Prozeßketten (EPK) (in German). Technical Re-port Heft 89, Institut fur Wirtschaftsinformatik, Universitat des Saarlandes, Saar-brucken (1992)

13. Kuhne, S., Kern, H., Gruhn, V., Laue, R.: Business Process Modelling with Con-tinuous Validation. In Pautasso, C., Kohler, J., eds.: 1st International Workshopon Model-Driven Engineering for Business Process Management. (2008)

14. Balmin, A., Papakonstantinou, Y.: Storing and querying XML data using denor-malized relational databases. The VLDB Journal–The International Journal onVery Large Data Bases 14(1) (2005) 30–49

15. Amelunxen, C., Klar, F., Konigs, A., Rotschke, T., Schurr, A.: Metamodel-basedTool Integration with MOFLON. Proceedings of the 30th International Conferenceon Software Engineering (2008) 807–810

16. Object Management Group: MOF 2.0/XMI Mapping, Version 2.1.1. Technicalreport (2007)

17. Winter, A., Kullbach, B., Riediger, V.: An Overview of the GXL Graph ExchangeLanguage. Volume LNCS 2269., Springer (2002) 324–336

23

Page 31: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

24

Page 32: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Mining of Model Repositories for DecisionSupport in Model Versioning�

Petra Brosch��, Martina Seidl, and Manuel Wimmer

Institute of Software Technology and Interactive SystemsVienna University of Technology, Austria

{lastname}@big.tuwien.ac.at

Abstract. State-of-the-art software repositories support optimistic ver-sioning and hence the concurrent editing of one artifact by multiple devel-opers is possible. The drawback of this method is the time-consuming,manual merge process when conflicting changes occur. This is even abigger problem when the artifacts are models. Although similar kindsof conflicts frequently reoccur, current systems hardly provide any reso-lution support. To tackle this problem, this paper introduces enhancedresolution support based on past resolution decisions. In order to keepthe necessary information to learn recommendations for improved con-flict resolution, a generic extension to current repository technology isproposed.

1 Introduction

Consider the scenario shown in Figure 1: Harry and Sally check out the sameartifact from a central repository and perform different changes. When Sally isfinished, she loads the new version back to the repository. Later Harry also in-tends to submit his new version to the repository, but unfortunately his changesare conflicting with the changes of Sally. So he has to resolve these conflicts beforehe is allowed to store his new version into the repository. The described situa-tion typically occurs when optimistic versioning systems, where—in contrast topessimistic versioning following the lock-modify-unlock paradigm—the parallelediting of artifacts is possible, are applied for the coordination and managementof concurrent team work. If the artifacts under version control are linear likesource code, merging parallel changes of multiple developers is a well-developedtask [10]. When common version control systems (VCSs) are used for the textualrepresentation of non-linear information, such as analysis and design models, themerge process often becomes time-consuming. The standard line-oriented com-parison tools are not suited for the rich-structured models. Since the user supportis very limited and consequently most actions are performed by hand, the conflictresolution is often error-prone and cumbersome as well [3].� This work has been partly funded by the Austrian Federal Ministry of Transport,Innovation and Technology (BMVIT) and FFG under grant FIT-IT-819584.

�� Funding for this research was provided by the fFORTE WIT - Women in TechnologyProgram of the Vienna University of Technology, and the Austrian Federal Ministryof Science and Research.

25

Page 33: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Fig. 1. Check-In Process

To leverage conflict resolution multiple approaches have been proposed [7],but all of them ignore one important factor: the user decisions of the past. As thesame kind of conflicts frequently reoccur, the same steps for resolving have to betaken again and again. If it would be possible to infer general resolution strategiesfrom accumulated historical data, the time spent for the conflict resolution couldbe reduced and errors occurring in human intervention could be minimized.The information available in the repository has been successfully used to makepredictions about software evolution by applying mining techniques [11]. Weintend to follow similar approaches for deriving general resolution strategies,but for this purpose we need data which is not yet kept in standard repositories.Coming back to our previous example, it is impossible to reconstruct the userdecisions as, except for explicit branching [9], neither the version of the secondcheck-in of Harry nor the actual conflicts are stored. Therefore we propose anextension for VCSs in order to collect the local working copy of the secondmodeler, conflicting parts of the model, and former user decisions in order toresolve those conflicts. This allows us an in depth analysis and mining of generalresolution patterns for the realization of a resolution recommender system.

2 Model Versioning By-Example

For further stressing the need for advanced versioning mechanisms, we presentthree concrete model versioning examples illustrating different kinds of conflictsoccurring during the check-in phase.

2.1 Example 1: 4 Merge Strategies—4 Problems

In the example illustrated in Figure 2, two modelers check out the actual versionof a UML class diagram (cf. V0 in Figure 2) as their local working copies. Both

26

Page 34: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Person

name

Passport

idV0

namedateOfBirthsex

idphotofingerprint

Person

V0‘ V0‘‘

Person

namedateOfBirthsex

Passport

idphotofingerprint

1 1

namedateOfBirthsexpassportID

hphotofingerprint

Person

name

Person

namePassport

Naive�Merge Syntax�aware Merge Semantic�aware Merge

dateOfBirthsexpassportIDphotofingerprint

1 1dateOfBirthsexpassportIDphotofingerprint

1 1

Passport

idphotofingerprint

V0‘‘V0‘

V1a

fingerprint fingerprint

V1b V1c V1d

Fig. 2. Example Scenario 1: 4 Ways to Merge Conflicting Changes

perform changes to their copies in order to relate persons with passports. There-fore, the first modeler introduces an association between the classes (cf. V0’),whereas the second modeler shifts all attributes from class Passport into classPerson and afterwards the class Passport is deleted (cf. V0”). Based on the con-flict detection mechanisms and reasoning power of VCSs [7], the following fourmerge results (cf. V1a–V1d in Figure 2) are possible.

Naive merge. Employing a naive merge, changes from both modelers areintegrated in the merged version without taking care of syntactical or semanticalconcerns (cf. V1a). The merge incorporates first the added elements into V1a, i.e.,the association introduced in V0’ and the additional attributes of class Personfrom V0”. Subsequently, the deletions are propagated, i.e., the class Passportis no longer available in V1a. The result is a model which is not conform tothe metamodel, i.e., the syntax definition of the modeling language, due to adangling reference problem.

Syntax-aware merge. A more sophisticated merge approach also takes thesyntax of the modeling language into account. In our example, the merge maydetect that the deletion of the class Passport has a dangling reference as conse-quence. Therefore, the class Passport is kept in the resulting model V1b. Notethat several other strategies are possible for ensuring syntactic correctness. Al-though the dangling reference problem is avoided, this model version is also notsuitable, because of several redundant attributes.

27

Page 35: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Semantic-aware merge. For detecting semantic problems such as the redun-dant attributes, further information is needed for the merge process. A semantic-aware merge may employ heuristics or an ID-based conflict detection to makeout that the second modeler has applied a move refactoring for the Passportattributes, followed by a rename refactoring for the attribute ID, and finally, adelete operation on the class Passport. With this input, a merge may concludethat redundant attributes exist when an automatic merge is achieved. Thus,an interactive merge process is started to let the user decide, which of the twoversions (V1c or V1d) is more appropriate for the further development process.Unfortunatly, simply using one version completely ignores model refinements ofthe second modeler. For more complex examples, also a mix of the two ver-sions or additional modifications are necessary to establish a correct integratedversion.Learning Potential. For this example, manual configuration of the VCSs

may be possible by providing dedicated rules for conflict detection and resolutionas is done in [8]. But in general, it is not feasible to provide a complete list of allpossible conflicts and resolutions in advance. Therefore, the VCS should recog-nize conflicting model structures and switch to an interactive merge approach,if no automatic conflict resolution is possible. Then the modeler has to inspectand correct the merge result, and the system tracks the user’s conflict resolutionstrategies for self-adaptation.

2.2 Example 2: Refactorings on Models

Changes cause not only local conflicts occurring due to concurrent changes of thesame model element. In fact, the consequences of the modification of one elementmay be noticeable over the whole model. Such global conflicts often occur whenfor example refactoring operations are performed.

Consider the following example. One modeler changes class A to singleton,i.e., only one instance of this class is created per runtime which is accessed bya public and static method named getInstance(). At the same time, a secondmodeler performs some changes in another class and adds an instance of class Aby calling the constructor. These changes are conflicting because in the mergedversion, the constructor is not visible to this class.Learning Potential. A VCS which detects the changes of converting a

class to singleton as refactoring pattern, may apply an appropriate conflict reso-lution pattern: accept both changes, but change calling the constructor to callinggetInstance().

2.3 Example 3: Modeling with Different Intensions

The conflict in our third example (see Figure 3) occurs because of different butpartly overlapping intensions of the modelers.

After checking out the actual version of the origin model V0 consisting of theclasses Car and Engine and the association has, Sally replaces the association

28

Page 36: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Car Engine

V0

Car Engine Car EngineV0' V0''1 1 1*

V11 1 1*

Car Engine EngineType1

Fig. 3. Example Scenario 3: Different Modeling Intensions

with a composition in her working copy V0’. Hence, she defines an Engine in-stance as part of one Car instance. In parallel, Harry increases the multiplicitiesin his working copy in a different way (cf. Figure 3) to unbound in order to de-clare that more than one car may use the same type of an engine (e.g., an engineof the type Diesel). Both versions express different understandings of the classEngine. A naive merge including both variants would result in a semanticallyincorrect model as the upper bound for the multiplicity of the composition isrestricted to one. This leads to a merged model covering both aspects by intro-ducing a third class named EngineType and consequently result in a model ofhigher semantics and quality.Learning Potential. From this specific conflict and its corresponding res-

olution, a resolution pattern is mined. In cases where an association is markedas composition and at the same time the multiplicity is set to unbound, anadditional class should be introduced. This pattern may be reused for similarexamples, such as the following. Consider a model consisting of a class Library, aclass Book and an association between those classes, and concurrently the samemodifications as in our running example occur. One modeler defines that thebook is contained in one library, actually meaning with book a concrete bookcopy, whereas the other defines that a book is offered in several libraries. Byapplying the previously explored resolution pattern, an additional class Book-Copy—the name has to be inserted by the modelers—is introduced in order toresolve the contradicting association definition.

To address such problems, we present an extension for current VCSs in orderto provide enhanced versioning support with a focus on how to provide resolutionsuggestions.

3 The Conflict Resolution Reasoner

In order to provide decision support for conflict resolution in model versioning,we extend conventional VCSs like Subversion1 by a learning component, the Con-1 http://subversion.tigris.org/

29

Page 37: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Check Out

Pattern Mineranalyze

VCS

ModelRepositoryConflict

Detector

Check InWC

Conflict Resolution Reasoner

ool customize

VCS

Modeler

adaptDetector

Merger

ResolutionAction

Storage

V0

V1

V2

ConflictResolver

ResolutionPatternStorage

[ ]

[else]Mode

ling

To Editor

VCSSupervisorConflict Resolution

Pattern Editor customize

Merger

Legend

Conflict

R l ti St t

Action Recorder

Resolution AdvisorResolution Strategy

V0 Artifact (Model)

Edited Artifact

Fig. 4. Architecture of the Extended Model Repository

flict Resolution Reasoner. Furthermore we describe how conventional VCSs maybe enhanced to collect additional information for the analysis of past resolutiondecisions. For the user of the VCS only one thing changes. The system providesrecommendations for the resolution which automatically remove the conflicts, ifselected. The overall architecture of the extended model repository is depictedin Figure 4.

The main part of the extension is located at the repository server, whereresolution actions of all team members are collected. At the client side, only thediff-tool used for manual conflict resolution and merging has to be replaced.

The workflow is as follows. The client checks out the latest revision of therepository and starts editing. For this step the developer’s preferred modelingenvironment may be used. After editing, the locally modified working copy iscommitted into the VCS. When a modeler checks in the changes of the workingcopy, the Conflict Detector compares the working copy with the latest version ofthe repository—or performs a three-way comparison if the latest version is neweras the original version of the working copy—and decides whether the user hasto remodel the working copy, or the merge can be performed without conflicts.In conventional VCSs remodeling is performed completely manually, visualizingtextual representations of the user’s working copy on the left hand side and of thelatest version of the repository on the right hand side. In our approach, the clientside Conflict Resolver is not only used for graphical difference visualization andremodeling in order to resolve conflicts, but also for the visualization of resolutionrecommendations which support the user in deciding a resolution strategy. Forproviding this decision support, the Resolution Advisor annotates the conflictreport produced by the Conflict Detector with appropriate resolution strategiesfound in the Resolution Pattern Storage.

The Action Recorder collects all user operations performed during the conflictresolution transaction and persists them in the Resolution Action Storage.

The Pattern Miner analyzes the Resolution Action Storage and adapts theResolution Pattern Storage. In order to find useful patterns the huge amount of

30

Page 38: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

data in the Resolution Action Storage has to be preprocessed, meaning that thedetailed information about the resolution of concrete conflicts is broken downto more common facts, like it is done in by-example approaches [4]. These factsconsist of a set of types of conflicting elements, the context within the model,the type of conflict (e.g., DeleteChange), and a resolution.

The data mining techniques used by the Pattern Miner may be customizedby the VCS Supervisor. Starting with computing association rules based on theApriori algorithm [1] for finding resolution strategies with high confidence forgiven conflict situations, in future work we plan to use cluster analysis for findingresolution hints in similar situations as well [5, 6].

Resolution patterns found by the Pattern Miner are stored in the ResolutionPattern Storage which acts as the knowledge base for the Resolution Advisor.Already stored patterns may be customized by the VCS Supervisor using theConflict Resolution Pattern Editor. For example, this may be necessary if an au-tomatically derived pattern is too restrictive in defining the conflict situation inrespect of the involved element types.

4 Challenges

We plan to integrate the Conflict Resolution Reasoner in our model versioningsystem AMOR [2] for offering advanced support in the conflict resolution phase.We are aware of the multiple challenges we have to face for the realization of ourvision of building a system which relieves the users of a versioning system froma heavy burden. In the following we discuss some of these challenges and sketchour solution strategies.Applicability. The benefits of applying the Conflict Resolution Reasoner

show up not until the completion of a training phase where user decisions arecollected for further analysis. At the beginning, our model versioning system actslike a standard VCS, but it will improve over time. For training purposes, theprojects must have a reasonable size. However, for similar projects, i.e., projectsusing the same modeling language, it is possible to share the discovered knowl-edge.Quality of the Resolution Strategies. The resolution of a conflict is a

highly sophisticated task which demands human intuition, expert knowledge,and experience. It will probably never be possible to implement a completelyautomatic conflict resolution tool. Therefore it is crucial to provide guidanceand support to the user in the form of a recommender system which proposesmultiple resolution strategies from which the user chooses one. The Conflict Res-olution Reasoner automatically infers those strategies according to user behaviorand user decisions. Naturally, it could happen that useless or even problematicstrategies are learnt. Therefore the system is supervised by the VCS Supervisorwho may intervene if, for example, the Conflict Resolution Reasoner becomes lessreliable by newly learnt strategies. Furthermore the VCS Supervisor may defineconflict patterns and resolution strategies manually. The Resolution Advisor com-

31

Page 39: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

ponent will rank the strategies considered as suitable according to metrics basedon usage statistics.Performance. We expect a huge amount of data resulting from logging

the additional information stored in the Resolution Action Storage. As alreadyexplained before, the content of a standard repository does not suffice to recon-struct the occurred conflicts and the accompanying user decisions for resolutions.For the sake of flexibility we decided to use an extra repository with a suitabledata structure to store the necessary information for the data mining process.This physical separation has the further advantage that the performance of thepart of the backend accessed by the user is not impaired if expensive data pro-cessing and complex analysis are performed.User Acceptance. Since the Conflict Resolution Reasoner is only an addi-

tional feature to well-established version control systems and directly integratedin the user’s preferred modeling environment almost no familiarization with thetool as well as with the versioning workflow is necessary. Furthermore, if theConflict Resolution Reasoner does not work—due to whatsoever reason—the useris not hindered at his work because “traditional versioning” is still possible.Evaluation. When we have implemented our versioning system, we con-

duct case studies to evaluate the applicability of our approach. Before such acase study, it is almost impossible to test components like the Pattern Miner as(1) there exist no model repositories because models are usually versioned pes-simistically and (2) if there was a repository, it would not contain the necessaryinformation anyway. In the context of AMOR, we will evaluate the approachon the one hand with students of a university course and on the other handin a real-world testbed supported by Sparx Systems2, the vendor of EnterpriseArchitectTM.

References

1. R. Agrawal and R. Srikant. Fast Algorithms for Mining Association Rules in LargeDatabases. In Proceedings of the 20th International Conference on Very Large DataBases (VLDB’94), pages 487–499, 1994.

2. K. Altmanninger, G. Kappel, A. Kusel, W. Retschitzegger, M. Seidl, W. Schwinger,and M. Wimmer. AMOR - Towards Adaptable Model Versioning. In 1stInternational Workshop on Model Co-Evolution and Consistency Management(MCCM’08), Workshop at MODELS’08, 2008.

3. S. Barrett, P. Chalin, and G. Butler. Model Merging Falls Short of Software En-gineering Needs. In 2nd Workshop on Model-Driven Software Evolution (MoDSE2008), Workshop at CSMR’08, 2008.

4. P. Brosch, P. Langer, M. Seidl, and M. Wimmer. Towards End-User Adapt-able Model Versioning: The By-Example Operation Recorder. In Proceedings ofthe International Workshop on Comparison and Versioning of Software Models(CVSM09), Workshop at ICSE’09, 2009.

5. D. J. Cook and L. B. Holder. Graph-Based Data Mining. IEEE Intelligent Systems,15(2):32–41, 2000.

2 http://www.sparxsystems.at/

32

Page 40: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

6. U. Fayyad, G. Piatetsky-Shapiro, and P. Smyth. From Data Mining to KnowledgeDiscovery in Databases. AI Magazine, 17:37–54, 1996.

7. T. Mens. A State-of-the-Art Survey on Software Merging. IEEE Transactions onSoftware Engineering, 28(5):449–462, 2002.

8. T. Mens, R. Van Der Straeten, and M. D’Hondt. Detecting and Resolving ModelInconsistencies Using Transformation Dependency Analysis. Model Driven Engi-neering Languages and Systems, 4199:200–214, 2006.

9. L. Murta, C. Correa, J. G. Prudencio, and C. Werner. Towards Odyssey-VCS2: Improvements over a UML-based Version Control System. In Proceedings ofthe International Workshop on Comparison and Versioning of Software Models(CVSM08), Workshop at ICSE’08, pages 25–30, 2008.

10. D. E. Perry, H. P. Siy, and L. G. Votta. Parallel Changes in Large-Scale Soft-ware Development: an Observational Case Study. ACM Transactions on SoftwareEngineering and Methodology (TOSEM), 10(3):308–337, 2001.

11. T. Zimmermann, P. Weissgerber, S. Diehl, and A. Zeller. Mining Version His-tories to Guide Software Changes. IEEE Transaction on Software Engineering,31(6):429–445, 2005.

33

Page 41: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

34

Page 42: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Model-based Integration, Execution andCertification of Development Tool-chains �

B. Polgar, I. Rath, Z. Szatmari, A. Horvath, and I. Majzik

Department of Measurement and Information Systems,Budapest University of Technology and EconomicsMagyar Tudosok krt. 2, Budapest, Hungary, H-1117

{polgar,rath,szatmari,majzik}@mit.bme.hu

Abstract. Software development processes are typically supported bya set of different tools that assist the designer in various phases of de-velopment like modeling, verification, source code generation, testing.Tool-chains can be formed by the integration of tools that are related tothe subsequent steps of the process. In this paper, we present a tool inte-gration framework which applies metamodel-driven and process-centricdesign patterns. Motivated by our research activities in various projects,our framework is based on standard process models, which allows there-use of tool integration patterns as well as automated checking of theconformance of tool-chains to development standards. We make use ofthe state-of-the-art Rational Jazz platform as a technological basis.

1 Introduction

Motivation. During system development – especially in the development ofsafety-critical systems, e.g., in the field of automotive, avionics or railway –several tools are used for the different aspects, i.e., for modeling, transforma-tion, verification, testing, analysis and code generation. We faced the challengein several of our projects to integrate these tools.

For instance, the DIANA project [1] aims at the implementation of an en-hanced avionics platform, named AIDA (Architecture for Independent DistributedAvionics, [2]). Along with this objective, a primary research goal is to developa tool chain to be used for AIDA, which incorporates standard modeling toolsfor SysML, OCL, JML and various other domain-specific languages. Within theframework of this project, our efforts are concentrated on designing and imple-menting the integrated end-to-end design tools with transparent transformationswhich are used to automatically map the design and specification models to anal-ysis and validation domains for a thorough verification and validation process.

The goal of the MOGENTES project [3] is to significantly enhance test-ing and verification of dependable embedded systems by means of automatedgeneration of efficient test cases from engineering models. In the project the� This work was partially supported by the European Union as part of the FP7-STREPMOGENTES (216679).

35

Page 43: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

newly developed test generation technologies should be integrated with existingmodeling tools and with the test environment of the industrial partners. The in-tegration should be realized in a seamless way, i.e., domain experts with limitedknowledge and experience in usage of formal methods (that will be used for testgeneration) should also be able to use them with minimal learning effort.

Related Work. Tool integration has been a hot research topic over the past years.There have been a number of early attempts (such as [4]) at integrating devel-opment tools within the context of a well-defined process. With a tendency touse non-standard technologies for various critical components, they were rathersuited for a particular type of application rather than being generally usable.

However, the experience from these approaches has been collected and syn-thesized into design patterns [5] which are common to most tool integrationapproaches of today. An important class is metamodel-driven tool integration[6], which is based on the idea of a model bus, a data repository which cap-tures semantic information on the data that is exchanged between the tools andprovides uniform persistence support. Recent initiatives ([7, 8]) target advancedfeatures such as model difference computation and model merging, but theirscalability to industrial model sizes (a few million model elements) is yet to beevaluated.

The workflow-based approach [9] has been (partially) implemented in a num-ber of tools. The SENSORIA Development Environment [10] offers Eclipse-basedintegration interfaces and a simple orchestration language in which small toolintegration processes can be described. jETI [11], a similar tool integration frame-work, is targeted at remote invocations for Eclipse-based tools using Web Ser-vices technology.

With the increasing emphasis on organized collaborative work in softwaredevelopment, high-level team management tools such as Rational Jazz [12] areemerging, driven by precise process models exported from modeling environ-ments like the Rational Method Composer or its open source variant, the EclipseProcess Framework Composer [13].

Goals. In our solution we did not want to develop a completely new frameworkrather to achieve our goals by reusing and combining existing technologies andextending them if necessary. Thus, our approach is targeted as a complementarycontribution to high-level collaboration integration environments. We apply boththe metamodel-driven and the process-driven tool integration patterns with aspecial focus on certifiability, and integrate low-level tool integration workflowswith high-level process descriptions. With our solution we address the followingproperties:

– Definition of a flexible framework. In the architecture key componentsare identified independently of the underlying technology. For the imple-mentation of the components high level, modern technologies having strongindustrial support are used if possible. Between the components well-definedinterfaces are defined in order to be able to change the implementation tech-nology.

36

Page 44: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

– Model-based construction and execution of tool-chains. The integra-tion of tools required for a given activity is specified using a process modelthat includes the tasks, the supporting tools, and the input/output artefacts.The process models will directly form the basis of executing the correspond-ing tool-chains, this way the domain expert is able to focus on the semanticsof the tool-chain without dealing with specific lower level notations and con-figuration options of the process execution engine.The process model is mapped automatically to the input language of a pro-cess execution engine that invokes the tools specified in the process modeland ensures the proper handling of the related artefacts.

– Data integration. The artefacts processed and generated by a tool-chainare stored in a persistent data repository, where meta-information can beassigned that supports version control, traceability and other related tasks.

– Certification of Processes. To reduce the risks of software design fail-ures, the software development processes are more and more subject to reg-ulations fixed in (domain-specific) standards that define criteria for the se-lection of techniques and measures. An automatic assessment process fordevelopment tool-chains is proposed based on logic-based description of re-quirements stated in the standards. The standards for safety-critical systemsdefine safety integrity levels (SIL) for development processes and describemethods that can be applied to the tool-chains. An ontology based repre-sentation of these requirements and the development process is constructedand the certification using a reasoner tool is performed.

The paper is organized as follows: the architecture with key components aredescribed in the next section. Section 3 discusses in more details the approachesfor process modeling and process certification, while Sec. 4 demonstrates theconcepts in a case study that contains details about a prototype implementation.Finally we conclude our recent work and sketch the future work.

2 Architecture

Based on our research and development experience and on the related works inthe field we have identified the key components that are needed to fulfil the goalsdescribed in the introduction. The architecture composed of these componentscan be seen in Fig. 1.

Process Modeling. The basis of the framework is the Process Model createdand edited by the Process Editor: it contains the information about who doeswhat, on which artefact, with which tool. This model describes (i) tasks, i.e., themodeling, analysis, verification and other steps of the development process, (ii)tools that are used to create, modify, test, generate, verify, transform, etc. someof the handled artefacts, (iii) artefacts that can be models, files or anything thatcontain information handled during the process, and (iv) roles of acting persons.

Process modeling can be performed on different levels with different ProcessEditors; this is discussed in more details in Sec. 3.1.

37

Page 45: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Fig. 1. Framework architecture

Tool Management. A Tool represents an executable program that performs oneor more tasks during the development. Tools are independent of the frameworkand can be implemented in different languages (e.g., in Java or in C) and accord-ing to different technologies (e.g., as standalone program or as web service). Theonly requirement is to be programmatically invocable, i.e., have the businessfunctionality exposed to a well-defined interface which is externally accessible(ranging from command line interfaces to library functions).

Connectors are the components that provide uniform interface of the toolsfor the framework. These invoke the tools, where the invocation can be anything:function invocation, remote procedure call, command line execution, web serviceinvocation, etc. These may provide multiple interfaces — and thus multiple func-tionalities — of single tools. Upon invocation the connector retrieves the inputartefacts needed by the tool from the Data Repository, and uploads the outputartefacts provided by the tool to there (both through the Artefact Manager). Itmay also derive traceability information from the input and output artefacts.

The Tool Manager manages the tools through the connectors. This way theheterogeneity of the tools are handled by the connectors and the Tool Man-ager needs to handle only components (the connectors) that have uniform ’ap-pearance’. The instances of these uniform components are stored in the ToolRepository. The Tool Manager shall provide a mechanism for the registrationof connectors and it is responsible also for the initialization and finalization ofthem.

Data Management. Models and other data files (i.e., artefacts) that are handledduring the development process (especially in the tool-chains) are described inthe Process Model. These are input and output data of the tools and the purposeof data management is to handle these in a uniform way and storing thesein a central repository (or in distributed repositories) extended with version,traceability and other information (e.g., type, related dates, creator).

The Artefact Manager is the component that provides data handling andtraceability related services to the other components of the framework (to the

38

Page 46: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Connectors and to the Process Execution User Interface). The handled informa-tion is stored in the Data Repository component.

Process Execution. The purpose of the process execution is to manage and tracethe execution of workflows (tool-chains) defined in the platform-specific processmodel that comprises tools contained by the Tool Repository and references datacontained in the Data Repository. The execution can be initiated and supervisedon the Process Execution User Interface and it is performed by the ProcessExecution Engine.

The Process Execution User Interface provides a control panel for the userswhere (i) execution of tasks defined in the platform-specific process model canbe initiated, (ii) state of execution can be traced, and (iii) versions of artefactinstances and their related metadata can be managed and traced.

The Process Execution Engine is responsible for the execution of the stepsdefined in the Process Model. When execution is initiated tool instances (con-nectors) associated to steps in the Process Model are retrieved from the ToolRepository through the Tool Manager and their services are invoked. When in-voking services, references to the input data are provided to the connectors,which then retrieve these from the Data Repository and invoke the externaltools with them. After the execution has finished the engine feeds back the sta-tus information to the supervisory interface (Process Execution User Interface).

3 Modeling and Certification of Processes

3.1 Process Modeling

In our work those steps of the development process are of special interest thatrefer to the execution of tools and even those parts where these steps form asequence — hence the related tools form a tool-chain — and this can be executed(semi-)automatically. Thus the aim of the process modeling can be conceived asto have a description of the tool-chains that have to be executed at given pointsin the development process.

Based on this model we have the following goals: (i) derive deployment modelsas automatically as possible (ii) enable the certification of processes by provingits correspondence to the requirements of development standards.

The Process Model is constructed according to the MDA concepts: it has aplatform-independent version, which is a logical model where tools appear onlyon abstract level (e.g. as an abstract tool or defined in a task by referring theexecution of a given tool) and it has a platform-specific version, which is aninstrumented model where all execution related information about the tools arepresent.

The creation of the platform-independent process model can be supportedby design patterns in the editor, which patterns shall be constructed on the basisof standards, related domain requirements or best practices.

39

Page 47: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

The platform-specific model is created from the platform-independent one:this step consists of the binding of concrete tools contained by the Tool Reposi-tory to the abstract tools.

Two types of deployment models are generated from the platform-specificmodel: (i) the Workflow Model contains the description of the tool-chain to beexecuted in the format that can be executed by the Process Execution Engine,(ii) the Storage Model is the description of the data structure in a format thatis needed to configure the Data Repository.

These components and their relations are depicted in Fig. 2 extended withsome implementation related information that is discussed in Sec. 4.

Fig. 2. Models and their relations used in process modeling and execution

3.2 Process Certification

The certification process necessitates the following tasks:

– Formalization of the requirements (criteria) in standards that concern theselection of methods and tools.

– Definition (or adaptation) of modeling techniques to describe the relation ofmethods, the capabilities of tools, and the construction of (domain-specific)development processes.

– Elaboration of techniques that check the compliance of concrete developmentprocesses (constructed by process designers) to the requirements.

In the standards the methods are refined hierarchically, i.e., several high levelmethods are decomposed into alternative combinations of lower level ones, andsufficient conditions for every SIL are formulated using various combinations ofthe applied methods. A formal representation of the hierarchical structure ofmethods is provided by defining an ontology [14]. Here concepts refer to thedevelopment methods and their relations include the refinement.

The next step of the formalization process is the categorization of the toolsin the tool repository. Each available tool in the tool repository is classified onthe basis of the concepts defined in the ontology, according to the supportedmethods. Finally, the (domain-specific) development process model is mappedautomatically to an ontological representation, in order to support the logicalreasoning.

According to the approach described above, all of the tasks, the tools andthus the development processes are characterized using the concepts represented

40

Page 48: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

in the ontology. Using these concepts, the necessary and sufficient conditions forthe selection of methods and the dependency on the safety integrity level arerepresented using ontology queries [15]. This way the standard conformance ofthe selection of methods and their supporting tools in the development processcan be checked using an ontology reasoner. In our research we used the Protege[16] ontology modeling tool and the Racer Semantic Web Reasoning System [17].

Fig. 3. The certification process

In Fig. 3 the assessment process is depicted. Based on the domain specificstandard the Methods Ontology and the Requirements can be constructed. Thedevelopment process can be modeled using the process model of OMG (SPEM– Software Process Engineering Metamodel) and this Process Model should betransformed into an ontology model. Finally, the standard conformance of thedevelopment process can be checked using the reasoner tool.

4 Case Study

Prototype Implementation. To support the goals outlined in Sec. 1, we have de-signed and implemented a prototype framework. Our prototype implementationis composed of the following software systems:

1. Platform-independent Process modeling is carried out with the Eclipse Pro-cess Framework Composer [18] (ver. 1.5) (which is essentially the same asRational Method Composer 7.5) that is based on the SPEM metamodel.Platform-specific process models are designed with a domain-specific lan-guage and editor developed with the ViatraDSM tool [19].

2. Model transformations between platform-independent and platform-specificprocess models, as well as storage and executable process models are imple-mented as VIATRA2 [20] transformation plugins.

3. Tool management is performed by the Rational Jazz Platform (ver. 0.6).Tool connectors are implemented as Jazz service plugins. For data manage-ment, we use the Jazz’s data repository [21]. Artefact management servicesare provided by Jazz Services working on EMF-based storage models, andthe Apache Derby relational database management system is used as theunderlying Data Repository.

41

Page 49: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

4. Finally, we integrated the JBoss jBPM workflow engine as a Jazz service [22](ver 3.2) to be used for process execution and monitoring. To allow the jBPMengine to invoke tools through connector interfaces, we implemented light-weight action adaptors which serve as plug-ins to the jBPM environment.

Description of the example. The example is taken from the MOGENTES project[3], where the goal is the model-based generation of efficient test cases. Let’sconsider a usual development process where the system is modeled in UML usingstate charts for defining the behavior of objects. During structural testing, thetest goal is to have full state and transition coverage with a possibly minimalnumber of tests. For this reason, the state chart model is transformed to thelanguage of the SAL model checker [23] and test sequences are generated withthe SAL-ATG tool [24].

(a) (b)

Fig. 4. Views of the Process Model in EPF Composer a) Activity Diagram b) DetailedActivity Diagram

Originally, this process is captured as an iterative procedure, where the testcases are executed until all test requirements are fulfilled (the results from test-ing are used as feedback for the modification of the models). For the sake ofsimplicity, we use a simplified version of this process where no iteration cyclesare involved. Thus, the test generation workflow appears in the process modelwith two tasks: it is composed of a transformation task and a test generationtask. Both are realized as the execution of a tool, thus it forms a small tool-chainwhich is executed by the test engineer.

In the following, we demonstrate how the goals formulated in the introductionare fulfilled by the framework described above.

4.1 Process Modeling

Platform-independent process model. The first step is the construction of thetool-chain as a high level EPF process model. We may start with high level

42

Page 50: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

design patterns but the goal is to create a detailed process model where allnecessary tasks are concretized (with associated roles, tools and work items);see Fig. 4.

Platform-specific process model. The platform-specific process model can be de-rived from the high level EPF model by an automated model transformation inVIATRA2. The model is augmented with platform-specific information (such astool IDs, tool interface function invocation parameter mappings, and work itemmetadata) in a domain-specific editor, implemented in ViatraDSM (Fig. 5(a)).

(a) Platform-specific process model (b) jPDL workflowmodel

(c) Storage model for the IBM Rational Jazz Platform

Fig. 5. Platform-specific models

4.2 Process execution

Workflow deployment model. We use the platform-specific models to derive de-ployment models for process execution and data management. For process ex-ecution, we use an annotated JPDL model which can be directly interpretedby the JBoss jBPM engine (Fig. 5(b)). The JPDL description includes invoca-tion information and parameter passing mapped to process variables, which areused by our process plug-ins at run-time to facilitate the execution of tools withproper data.

Data deployment model. For data management, we use the Data Repositorycomponent of the Rational Jazz Platform. It uses an EMF-driven metadata-based object repository, where the “schema” is specified by a storage model(defined as an annotated EMF model, Fig. 5(c)). This model is automatically

43

Page 51: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

created from the platform-specific models and contains information about therelationships between various artefact types (such as containment, cross refer-ences) and metadata attributes. The actual data items that are used in the work-flow are stored as BLOB attributes in the storage model, with metamodel-basedversioning management support (elements derived from the Auditable type areautomatically versioned by Jazz).

Execution. The data management system and all tool connectors are imple-mented as Jazz Services, which can be invoked through Java function calls (lo-cally) and Java RPC (remotely)1. Tools along with connectors are deployed onthe tool integration server, which is accessible to clients (workstations). In theexample scenario, the system consists of the following Jazz services:

– tool services: the UML2SAL model transformation, and the SAL-ATG testgenerator are deployed as stand-alone services on the Jazz server;

– the data access service is generated for the storage metamodel (supportingspecific queries) and deployed on the Jazz server;

– the integration workflow service makes use of the workflow execution infras-tructure service (the JBoss jBPM executor in the prototype) and exposes aseparate Jazz service for the invocation of the entire workflow.

For instance, if a test engineer wishes to execute the test generation process,she may connect to the Jazz server from within her Eclipse workbench, createthe UML statechart models, upload the models to the repository, invoke theintegration workflow service (with proper parameter passing) and retrieve theresulting test cases from the repository.

4.3 Certification

The assessment of the process can be executed on the basis of a required stan-dard. In this example we refer to the EN50128 standard [25]. In Fig. 6 thehierarchy of the methods described in the Verification and Testing step of thisstandard is presented. For every method the recommendation level is indicated(mandatory (M), highly recommended (HR), recommended (R) and not recom-mended (NR)) and the combination of the required methods is expressed as alogical condition.

Based on the hierarchy of methods an ontology is constructed as mentionedin Sec. 3.2. Both the tools and tasks described in the tool level and task levelprocess model are categorized using the concepts of the ontology and tool-chainpatterns are proposed in order to support high level methods in the developmentprocess.

For example, Structure-Based Testing (which is a Dynamic Analysis andTesting method) can be supported by the following tool-chain:

1 While Jazz supports remote calls through RESTful web services, at this implemen-tation stage we have not used that functionality.

44

Page 52: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

Fig. 6. Methods hierarchy in the Verification and Testing step

1. Model transformation from UML2 statechart model to the input format ofthe SAL model checker.

2. Test generation for a given coverage criteria using the SAL-ATG [24] tool.3. Mapping abstract test cases to executable test cases.4. Execution of test cases and measuring coverage by Rational RealTime.

The process model that includes this tool-chain can be validated using theontology reasoner according to the hierarchy of methods presented in Fig. 6.It turns out that in order to satisfy the requirements for SIL3 and SIL4, othermethods (and supporting tools) are also necessary.

5 Conclusions

The tool integration framework presented in this paper supports the goals tar-geted in the introduction: (i) the different tasks arising during tool integration— namely process modeling, process execution, tool management and data man-agement — are supported by the framework, (ii) these tasks are separated oncomponent level, (iii) for the implementation of these components widely sup-ported technologies are used, e.g., Jazz, EPF Composer, Apache Derby, jBPM,domain specific modeling, (iv) construction of process models that conforms todevelopment standards are supported by the application of process design pat-terns, (v) certification of development processes is supported by an automatedapproach that check the conformance of the processes to standards using ontolo-gies.

The feasibility of our approach was demonstrated by a prototype implemen-tation and was illustrated on a case study.

References

1. The DIANA Project Consortium: DIANA (Distributed, equipment Independentenvironment for Advanced avioNic Application) EU FP6 Research Project http://dianaproject.com.

2. Skysoft, Inc.: The AIDA System (DIANA Project White Paper). Technical report,The DIANA Project, EU FP6 (2008) http://diana.skysoft.pt.

3. The MOGENTES Project : MOGENTES (Model-based Generation of Tests forDependable Embedded Systems) EU FP7 Research Project http://mogentes.eu.

45

Page 53: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

4. Einar W. Karlsen: The UniForM WorkBench: A Higher Order Tool IntegrationFramework. Lecture Notes In Computer Science 1641/1999 (1999) 266–280 DOI10.1007/3-540-48257-1 17.

5. Gabor Karsai, Andras Lang, Sandeep Neema: Design patterns for open tool inte-gration. Software and Systems Modeling 4(2) (2004) 157–170 DOI 10.1007/s10270-004-0073-y.

6. Carsten Amelunxen, Felix Klar, Alexander Konigs, Tobias Rotschke, Andy Schurr:Metamodel-based Tool Integration with MOFLON. In: International Conferenceon Software Engineering, ACM (2008) 807–810 DOI 10.1145/1368088.1368206.

7. Rick Salay et al.: An Eclipse-based Tool Framework for Software Model Man-agement. In: OOPSLA Workshop on Eclipse Technology eXchange, ACM (2007)55–59 DOI 10.1145/1328279.1328291.

8. Elisabeth Kapsammer et al.: On Models and Ontologies - A Layered Approachfor Model-based Tool Integration. In: in Proceedings of the Modellierung 2006(MOD2006). (2006) 11–27

9. Flavio Corradini, Leonardo Mariani, Emanuela Merelli: An agent-based approachfor tool integration. International Journal on Software Tools for Technology Trans-fer 6(3) (2004) 231–244 DOI 10.1007/s10009-004-0158-5.

10. Howard Foster, Philip Mayer: Leveraging Integrated Tools for Model-Based Anal-ysis of Service Compositions. In: 3rd International Conference on Internet andWeb Applications and Services. (2008) DOI 10.1109/ICIW.2008.103.

11. Tiziana Margaria, Ralf Nagel, Bernhard Steffen: jETI: A Tool for Remote ToolIntegration. Lecture Notes in Computer Science 2440/2005 (2005) 557–562 DOI10.1007/b107194.

12. IBM Rational: Jazz Community Site http://jazz.net/.13. Peter Haumer: Increasing Development Knowledge with Eclipse Process Frame-

work Composer. Eclipse Review (2006)14. S. Bechhofer: OWL reference. W3C recommendation. (2004)15. Karvounarakis, G., Alexaki, S., Christophides, V., Plexousakis, D., Scholl, M.: Rql:

A declarative query language for rdf. In: Proceedings of the eleventh internationalconference on World Wide Web. (2002) 592–603

16. Protege: Protege ontology editor http://protege.stanford.edu/.17. Racer Systems Gmbh: Racer Semantic Web Reasoning System and Information

Repository http://www.racer-systems.com/.18. The EPF Project: website http://www.eclipse.org/epf/.19. Rath, I., Vago, D., Varro, D.: Design-time Simulation of Domain-specific Models

By Incremental Pattern Matching. In: 2008 IEEE Symposium on Visual Languagesand Human-Centric Computing (VL/HCC). (2008)

20. Varro, D., Balogh, A.: The model transformation language of the VIATRA2 frame-work. Science of Computer Programming 68(3) (October 2007) 214–234

21. R. Frost: Jazz and the Eclipse Way of Collaboration. IEEE Software 24(6) (2007)114–117 Digital Object Identifier: 10.1109/MS.2007.170.

22. John Koenig: JBoss jBPM White Paper. Technical report, The JBoss Group /Riseforth.com (2004) http://jbossgroup.com/pdf/jbpm\_whitepaper.pdf.

23. SAL: Symbolic Analysis Laboratory (web site) http://sal.csl.sri.com.24. Gregoire Hamon, Leonardo de Moura, John Rushby: Automated Test Generation

with SAL. Technical report, SRI International, Menlo Park CA 94025 USA (2005)http://www.csl.sri.com/users/rushby/papers/salatg.pdf.

25. CENELEC: EN 50128: Railway applications - Communication, signalling andprocessing systems - Software for railway control and protection systems. http://www.cenelec.eu.

46

Page 54: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

���������� � � ��� ����� ������� ��

�������� ����1 � ������� ���� 2

1 �������� ��� ����� ������� ������2 �������� ������ ������

��������� ������� ����� ��� ��������� �������� �� ������� � ������ �� !���" ����� # � ��� ����� �$��� ����� $��� ��� %��� �������� �� &��'�����$��# ($��� �� �$���)��� � ���� )�� ���� ����������� ���������# ����!����� �� �� ��� �����$ �� ��������� � ����� ��� �) �����# ��& ����� ��%��� � ������%��� ����� ����� �%������� ��� � ��*����� ����� �� ����� ���� �������� ��� �) �����#+� ������� $��� �$� ������ �) ���������� ���� � ���� �$�� ��������� ������� ���$������ �� ����� �� ������� �$��� ������� ��� ���� �$� ����!������� �) �������� �����# +� )���� �� �$�� ����� �� �$� ��,������ �) &$�����$ � ������� ���� ��� �� ��� ���,��������� �� &��� �� �� �$� ��,������ �)��� ���������� ��� ����#

� ����������

��� ��������� � �� ������� ������ ��� � �� �� �� � � ������ ������� � ��������� ����� ����� �������� ��� ����� � �������� ��� ������ � ����������� ������ �� �� � �� � ������ � ��������� �� ���� ��� ����������� � ���� ������!� � ������� ���" #�� ������� �$�� �� �� �����!� ������%&&'( )��� �������� ��� ����*�����+� ,���� -./ )��� ������� ������ �+�.��*0(���� $� 1���� )��� ��������������!� ������ �+� ���" ����� ������� � ����� �$� � �� ��� � ������ � ������ �� ������ ��������� *� ������� �� $� *����� ����� ������" ��� � �� ��� ���� �������� � �� *� �$� � �� ��� � *� *��� -./ �� ����� � (���� $ �����"

2������� ��� ���� �� �� ����� ������� �� ��� �� ���� � � �� ������ �� � $ ������� �� ��� �� ������� ��� � ����� �����" 3� �� ��������� ������� ��� ������ �� ��� ����� � ������ � ��� ��������� � �� ���� ������" .������������ � ������� ���� ��� �� *� ���� ��� ��� �������� ��� ������� ������ � ��� �� �����" ���� �� � ��� ��� � ������� ����� *� ��������� ����������*��"

3 ���� ������� ����� �� ����� � ��� ���� �� ���������� ���� � ���� ������ � ������� �� �*�� �� �� ����� �����" (�� ����� ���� �� ����� ��� 4+��� � ������ ����� ��� �� � �������� � ���� � 5+ �� � �� �$� ���� ���$��������" ��� !��� ��� �� � ������ � ���� ��� � �� ������� �� �� ��� ������ �� ����� ������ �� ������� ������� � ��� ������ �������� �� �������� �� ����� ���� ���" 6� ������� ����������� ������ ��� ��� ���� � ��� ��� ���*�� �� ����� � ������ � ��� �� !����� �� ��� ����� ����� � ��! � � ����� �������� ��� � ������� ��� �� ����� �� ��� �� ����� �����" ��� ���

47

Page 55: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

�������� ����� ��������� � ���� � �� ������� ����������� �� �������� ���� �

��� ������ ������� ��� ���������� �� �������� ���� ���� ����� �������������� �� ��� ������ ����� ���������� ��������� � ���� �� �� ��� ��� ������� ������ ���� � ��������� ��� �������� �� ��� ������ ���� � �� ������ � ��� ���������� ����� ����� ���� �� � ���� �� ������� ��� ������ ������ ������� �� ������� �������� ���� �

��� ���� � ������� ������ � ������� ���� ��� ������ �� ������ �������� ����������� �� ��� ���� � ��� ���� �� ������� ! ����� ������� " ���� � �� ��� ������ �������� #������ ��������� ����� �� ����� �� ������� $�

� ��� ����� � ���� �� ����

%� ��� ��� ��� ��� ���� � ����� �� ������� �� ��� ���� ��� ������� � ������� ��� ������� �� �� ������� ������ � ��� �� ���� ��� � ���� &�' ���� � (� �� � � �� ������ �� ������� ����� )����� *�' ������������ +,(- ��� ��� �� �� ����� �� ��� ������� ����� +��������������� ���� ������� �� �� ��������� (� ��� � � � �� �� � ���� �� �� � �������� �������� ��� �� �.������� � ������ ��� �� ���� ���� ���� ����������� ���� �� ��� ���� ���� ���� ����� ������ ��� ���� ������

��� ������� �� ������ ���� � ���� ���� ����� ����� /

� ���������� �� � ����� ���� ��� � ������ �� �������� ��� ��������� ���� �� ��������� � �� ����� ������ ���� �� ����������� �����0���� ������� ��� ������ ����� �� �������� ���� �� � � �� ������ ���� �� ��� ����������� �����

� ��������� �� ������� ����� ��� � � ��� � � �� ������� ���� ������ ��� ������� �� �������� ���� �.������ �� ��� ��������� �����)����� �0# ������� -� +��������� ��������� �� ������ ��� �������� ����� ������ ������ )����� ����������� ��������-�

� �������� �� ����� �������� (� ������� ��� ������� �� ��������� ���� ���� ����� �� ��� ������� ���� �� ��� ������� �� ����������� ���� �� �������� ��� ���� ������� ����� 1������� �� ����� ���� ������ �� ������ ������� � ��������� �� ������� ���������� +������ ������� ���� ���� ���� ������� �������� ���� ������� � ����� �� ����� ����� ��������

(� ������ ���� ��� ���������� �� ��� �������� ���� � ������� ���� ������������ � ������� ����������� ���������� ���� � ��������� � ������� �� �� ����� ������ ���� )�� �� �� ���� -� ��� ���� �� ��� ���� ��� ��������� �� ����� ���� �� ��� �� ��� � �� ����� ������ ���� � ��������� ������������ � ������� ���������� �� �������� �� ��� ������� ���� )������� �� ��� ���������� ����-�

48

Page 56: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

� ������� � �� �������

��� ������� �� � ��� �� ����� ���� � � ��� � ��� ���� � �� �� �� ��� �� � ����� �� � ��������� �� � ��� ���� ������� ��� �� ������� �� ��� ���������� � � ��� �� � �� �� � ���� ��� � ��� �� ����������� � ��������������� ���� � �� ������ ����� � ��� �� ���������� �������� ��� ������� ��� ��� ���� ���� ��� ����� ���� � ��� � �� � ������� ������ ��� ����� ����������� �� �� �� � ��������� �������� ��� � ��� ����� ������� � � ������� ������� ��� �� ������ ��� ���� �� ��� �� ��� ������

Tool Metamodel

CommonMetamodelDefinition

+usedBy

*

+uses

*

+weaves*

+weavingModel1

���� �� ������ �� � � ��� ���� ������� �� ��������� !��� ��"

��� ������� � ���� �� � �� # ����� ��� ��� ��������� �� � �� � ����� ������ ���� �� ������� � � ��� ���� �� ���� �� ������ �� ���� ��� ���� ��� ��������� � ���� � ��� ��������� ��� ������ ��� ��� � ��� ������������� ���� �� ��� ������ ��������� �� ��� � ��� ����� ��� ���������� �� �������� �� �� � �������� ��� ��� ���� ���� ���� �� �� �� ��� ����� �� � ��� �� ����� ���$ %&'� ��� � ��������� �� ())*+�

�� � ����� ����� �� �������� ���� ������� ���������� !����� ��� + �� �,��� ����� ����������"� �� � ��������� �� ��� ��� �� �� ��������� -��#.$ ������ �� �� �� ���� � �������� ������� ���� ������� �������� �������/�� �� ����� ��� �� �&0 -0. !�����&�� &���&���� &�����" ��� �� ���������� ������ � ��� ���� ������� ���

� ������� �������� �� �����

��� ��� �� ��� � ��� ��������� � �� ������ ������ ��� ������� ��� ����/������ �� ��� ������� ����� ��� � � � ��� � ��� ����� '�� � ���� �� ���������� �� �� ������ �� � ��� ���� !��� � �� #" ���� ��,�� �� �� �/���� ��� + �� �,� 1��� ���������� !�� ���� �� ������ ������ �� �� ����"�� �������� ��� ��� � ��� ���� ����� ��� ������ �� �������� �� � ��/����� ��� ���� ��� !����� ��������� ���� � ���" �� �� ����� ����� � �� �+ �� �, ����� ��� � �� � ��� � ��� ����� ������� � � ���� �������� �� �/���� �������� ��� ���� ���������� � ��� �� �� ����� ��� + �� �, ������

49

Page 57: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

DOORS : Tool Matlab : Tool Papyrus : Tool Autosar Builder : Tool

Autosar : MetamodelSimulink : MetamodelEAST ADL : Metamodel

virtual metamodel : CommonMetamodelDefinition

+usedBy

+uses

+usedBy

+uses+weaves

+weaves

+weavingModel

+weaves

���� �� ������� � � �� ��� ��� �������� ��� ����� ���� ����

���� ��� ������ � ����� ������ � � �� �� �� ������� �� ���� �� � ������ � �������������� ��� ��� ��� ���� ��� � ������� �������� �� ������ �� � �������!� ���� ������ ���" ��� �� !� ���� �������������� �� �������� �� #� �������� ������� ����� $���� ����� ��� ������� � �� �� ����� ������� ���� ������������� ������ �� �� �� ������� �����" �������� �������� ��� !� ������������������� � !� ���� ������������������ ��� �" #� ���� ��� �� ��%���� �� ��� #������ ��� ������� � �� ��� �� ������ ��� ��� �� ��� ����$���� ��� ������ &������ �����' ()"*+�

$���� ��� �� ���� ���#���� ���� �� � �� ������ �� ���� ����

,� ������� ����� -�� ��� �� ������ ����� �������� ��" ��� ������ � �� ��� ��� ���� ��� ���.

/� � ��� ����� -�� ��� �� ����� ����� �� #� ���� ������. ��� ��� ����"��� �� �� �� ���� �� ������� ���� �������� ��� � ���� ��������������

��� !� ����.

! ��� ���� ��� ����� #� � ����� ��� �� ������� �� � ��� #�� �������� ������� 0�� � �� #���� � � ��� �������� �� �� �� &������ �����' �������� �� �������� �� �� �� ����� ��������� �� �� ������ �� ������� -����� ��� �������� ��� ������ ���#�����

� ��� ����� � � ������� $�� ������ �� ������ ��� #����� ����� �� � ��� ���� �� ����� � ��� �� ������ � ������ �� �� �� ������� � �� ���� ���

� ������������ 1��� � �� ������ ����� �����" ��� !� ���� ��2 � !� ������2� �� ������ �� ������ ����� � #� ���������

� � � ������� ���� �� ��� ��� ����� � ��� ��� �� ��� �� �������� ����� � � ������� ! �� ����� ����� ������ ���� ���� � #� ������"����� ��� ����� ������� ��� �� � �����#�� �� ������ �� ����� $��� �� �� ���� ���� �� ���� ����� #������ � �� ��3� � �� �������

50

Page 58: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

51

Page 59: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

������� ������ �� � �� � ����� ���� ����� �� �������� � ��� �� ��� ����� ������� ���� ��� �� ��� �� � ����� ���� ��� ��� ��������

!�� �� � �� �� �� ������ �" � � ������� �� ����� ��� � ������� ������� #� �������" ���� ����� ��� �� �������� ����� $���"��� � �� � �����" � �� ���� � ����%� � ���" � ���� ������� �� ������ �� � �� �� ������� ����� �������� � ��� #� � �� �����" � ����������� ������� ��� � ��� ��� ����� � � ��&������� ���� � ����� � �� �� ������ � ����� ��� ��&������� �������� '���"�� ��� � ���� �� ��(��� ����� ������ �������� � � ���" �� ������� � �� �� ������ � ����� � � ��&������� $���" � �� ��� ����� � �� ���%�

������������

� ��� ������ �� � �� ���� �� ��������� ������� �� � )* !+ *�������,���

���������

�� ������� � �� ��� �� � ������� �� ��� ����������� �� ��� ����� !"�#$� ������ ������ ��� %����&'����� ����( �� '�����)*��� (��+���) �,�� ��� � #%#��������� �� �-.���&�������� ����� **��� �/���*� � ��� ��� �� ))��� &������ 012234

1� � �-��� %� �� ��� �� ������� �� %���� ������ * � ��*��� �� ��*)��5 �/���*���*)��*������ ��� * ������)�6� ������� ��� ����������� �� ��� �7�� ��� � �$$$������ ���� � #��������� �� 8��+���) �� $���������� �� #�*)���� � ��� �/���*�0$#�� 12294 :� % ��� & 3 )��� 1229 ���� �� ;������� ���� �� �$$$ #�*)����������/ 012294 1<<=19>

:� $���)������� �� �*�� %�� %���� % � ��� 0 %:4� ����������������� ���

��������

3� '������ '�� � -�� %� ������� � �� ��� �� ������ $� "���� � "�� *(� ������� *���� (� ���� ��� ����������� �� ��� �?�� ������ ��� �6���������� '������) � ��� %��?��� 0�'%274� 012274

7� '������ '�� � -�� %� ������� � �� ��� �� � ������� ��� ))�/��� �������*���� * � ��*��� �� � � * ))���� ��� ����������� �� ��� ������� � ��� ��'������ � ����� 0�' 274� 012274

>� $���)������� �� �*�� %���� 8� ��� 0 %84� ����������������� �����������<� $���)������� %8 ��� � ���� ����������������� �������������������9� �.@����� #�� ��� � A@������ %� ���� � '� #��� '� ������ �� �@�� B��% ))��� ��*����+ �� �*� �� ��� ������ �� �*-����� �/���*�� �������� ���� ���� ���� �� �� �����* ������ ��� ����������� �� ��� �%$C3 8��+���)� 3�� 8��+���) ���-.���&�������� %������� �� $*-����� C� �&A�*� �/���*�� 0122<4

52

Page 60: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

MDE Project Execution Support via SPEM Process Enactment

����������� ���������������������

�������������������������������

�!"�#�$��%��������&�����'%���� ���������'������()%�*��+'*��

Abstract.� ,�� ����-� .������ ������������ /�.�:� -���;%�-�� <��=���%� ���� �% %������������%�+��-%��-������'�'�%����-���%��>�� %��+����%'������%�>�������%��+<������ ���� ���� <��%����-� ����-���� %���-�� ��+�-�� ������ ���� *�--� �% ���*��+���������������*�����������<�����%%'�?�����-���������=��������+����@���<� /��@:� <��<�%�%� � *��+-� -������ *��� +���--���� %���������� %�*�>��������������� <����%%�%� A� $��'� ���� %������ + �%� %-�>-�� ��%� >�� ��� �����.�� >��-�� ��� %����-� +������-����%� ��� ��>� ��-�-�'� ,�� ���%� ����-�� >����%������ � +������ ��� %�<<���� �B���������*� ����<��=���� <-�%� *���$��;��*����+������-����%'� ���%� +������ ���-���%C� /�:� �������� �*� � <��=���� <-��� �'�'���%����������*��$��;��*�����+������-���D�/�:� -�� �����*� ����+������-�����������<��=����<-����*��+�����>�������+�������������%������D�/E:��+-�%%����������� �*� �B�����-�� F$�G� %���<�'� ���� +������ �+<-�+�������� �%� -%��<��%������ ��� ���%� ����-�� <��������� � ��+<�����%���� �--�%������� ��� ���<��%���������B+<-�'��

Keywords: $����F$�H��F$�G��<����%%�����+�������+������������%'

1 Introduction

��@� �*�>��� $����%%� ������������ ���+���-� /$��:� I�J� %<���*������� �%� �%������K���>��*�����<��%�������%�*�>���������������+������-����%'����%�-�������%� %-�>-�� ��<���� ��� �����K����%�� ���� ��� � %����%%� ��� ��%����� <��=���%�� �'�'���.�G$G�L� I�J�� ����M� IEJ�� ��$�� INJ'� ���%�� ����<��� ��%����� <��=���%���*����� �%�*�-� �.�� +������-����%� ��������� ��**������ ��+��%C� %�+�-����������*������� ��� ��%����� ��� ��.�G$G�L�� %�%��+%� +������K����� ��� ����M���.��*���%������������������%������$�'����%��+������-����%�������<<-�������--������ �*� <��=���%� ���-������ ���� -���� -%����� ���%'� ���� --� ���%� �*� <��=���%� ��� �%���O���������� ��������-����<��%����-���+�-�������%����� ��%��������%��������*������%����������<��=������������%����������<�����%%'����%��%������%����<�����������<��=����%�<<����%�%��+%'���������-����-%�����<��=���%�����<��=����>�� *-�>��B���������%������� <��%�%����� ��� � -���� <������ �*� ��+��� �'�'� >�� %�� +����%�� ���%'� M������-��� ����F�%���%%� $����%%� �B�������� G������ /F$�G:� I!J� ������%� ��� ���� �*� ���� +�%����++��-���%���>�%�*�����%������>�� *-�>��B��������<��%�%�����'��,�����%�����-��>��

53

Page 61: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

������'����� ����'���������

<��<�%�� � �����<�� *��� � +������ ��������� ��� ���%*��+����� �*� $��;��*�����+������-����%� ����B�����-��F$�G�>�����������-%� ���� >�� *-�>������-<%� �������������+������-������*��+����������+������*������%��������<��%����-'�,��������>���%������ <��=���� �B�������� �%� %�<<������ ��� ��%���%%� <����%%�� >����� �������%� >���� ����<��%����-�����%��������<�--�-'�����<��%�%�������%�+���������F$�G�������������%�%����-��*���-����-%�����<��=���%'��

���%�����-���%�%�����������������*�--�>����>�'�,��%���������>����%����������+�����������<�'� ,��%�������E�>��<�����������-%��*� ���� *�%���-���� %�������� �--�%�����>�������<��%���������B+<-�'�

2 Concept

���������<��*���$��;��;F$�G�>%�-�����<��%����������������%����I#J����I�J'�,������ <������%� >�� � ���� $��� ��������%� >���� ���%-���� ����� <����%%�%� ��� �����������������%� >��-�� <��%������� ���� ������-� *-�>'� ���� ��%�-���� F$�G� ��<��%������ ����$��� >�� *-�>� ������-� *-�>� ��-�'� ���� ��*��+����� *��+� ���� $��� +���-� >%��B����������%������ ���F$�G�����-�%'�������������� %���<�� ���-����������B�������>�������+��-�<�%�;<����%%���'������%��%�>�����������������+<-�������������%���������*�������� >���� ������������*� >��� %������� ���������%� ��� %%���%��*� ����-�%'� � � ,�����%���������>�� �>���+<���������������<��������������+ �����<�%%��-�����+���--���������B�����-�������%������%'��

����+�����**��������%�������������*�������+���������������+����%�������������� <��=���� ��%��������� <�%�'� ���%� %������� %����%� ���� ��*��+����� *��+� ����+������-�����������<��=����<-�����������%�������%�����������<��%����-�����-����������� <��=���'� ,�� ��������� ���� %������� %�����%� ���� ���-���%� ��� <������%� ��+�-������*������%'� � .������ ���� <��=���� ��%���������� ���� ��*��+����� *��+� ���� $���+������-�����������<��=����<-���%�%%���������%���������O��%�������������%����%��%��<������������������+���'�

54

Page 62: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

MDE Project Execution Support via SPEM Process Enactment�������

WorkflowSPEM model

Activity ManagementBPMN/BPEL model

WorkflowBPMN/BPEL model

Project Plan

Instantiation

GenerationIntegration

Generation

WorkflowBpel script

Activity ManagementBpel script

Generation

Communication

�Fig. 1.����%*��+������-�>�

�����������<���%��������%*��+�����*-�>���-�K����������+�����'�����$���+���-���*�������+������-���� �%��%��� ����������<��=����<-�'��������������<��%����-����%%����������+<-�+����������-�%���%��������������+������-���'�,�������%���+��������% %������������%����<'����+����%�<������*��������% �������*��+�����<��%����/��-�%��>�� �<������%������������%���<����%���% ���������������':��%�%%��������������������������+����%���������O��%�'�

������������������*����B�����-��F$�G�%���<�����+��<�%%��-������������B��%��<��F$�HPF$�G�+���-� �%� ��������� ��������� ���<��<�%���%��%��+�����%��+�K�� ���������%������'�,�������������������*�������%������%�������������%���������'�'�����-F�%�IQJ�+���--����%������%'�

���--�����B�����-�������%�������%���<���%���������'�

3 Implementation and Example

���� ����� <��%������ �����<�� >%� �+<-�+������ ��� ������� ��� ��<� �*� ��%���=���������� ���-� IRJ'� ,�� ���%� %�������� >�� <��%���� ���� �+<-�+�������� ��� �--�%�����>�������B+<-�'�

�%����>%�+�����������*�����������.�G$G�L�<��=������*������+������-����*���%�+�-����� ����*������� ��� ��%����� /��:'� ,�� ���� %������� ��-�>� >�� ���%����� � ��%���B��������<�%���*�������.�G$G�L����+������-���'��

55

Page 63: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

������'����� ����'���������

����������� �����������������������������������

����������� �������� ������

�����������������

�Fig. 2.���B���B��������*��+���.�G$G�L�����������-����

�����������<���%� ����>�� *-�>� *��� ������%���B��������%�<�����.�G$G�L�����������-���'�����Test Suites�A���%���%����%���<����%�����������<������%�<�%�%��*�����+������-����A�������%-����������B�����-�%�*����<�����-��<-�*��+'�������������%�� �B�������� ��� ��� %�����S�� >����� -��%� ��� ��%�-�%� ���� ��� ��-����� ��� ���� -����<�%�%� �*� ���� +������-���'� ���%� ���� >�� *-�>� ���-���%� �>�� ��������%� A� Test Translation ���Test Execution�A�����<����%�>����������>�� �<������%�A�Test Suites, Executable Test Suite� ��� Test Execution Results'� ,�� �������� ��� ���� +���-� ��*���%���-�%� ����-���� *��� *�-*�-+���� �*� ���%�� ��������%'� �--� �-�+���%� ��� ��� ��%������� �������-%������������������+�������'�

���+����%��B���<���*��������+������-�����<��=����<-����������%�������'�

56

Page 64: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

MDE Project Execution Support via SPEM Process Enactment�������

Fig. 3.�$��=����$-��,�%���������@T,�*���������%���B��������<�%��

������� E� %��>%� ���� ��<���-� �%��� �����*��� /@T,:� *��� <��=���� ��%��������'� ,��--�>%�%%��������������-�-����%�����%��������+������-������-�%��%������������% %��������� ��� ���� <��%����-� ��� ��� ����-���'� ,�� ��������� ���� �% � ��� ��� %%�������>���� � %������� �--� ���� >�--� �������� --� ��*��+����� ����� ���� �% C� ��%���<����%� �������+�������� ��*����� ��� ���� +������-����� �% � ��+���� ��� ��������� <��%����-�����-%���*������������<��=����<-�'�,���������������B+<-������Test Department��%�������%������ ��� ���� ��-�� >����� �%� ����-���� *��� ����� �% %� ��%��%%��� ����'� ���� �% ��������� �%� %��� ��� #"� ��%� *��� ����� �%�%'� ,�� ��������� ���� ��*��+����� *��+� ����+������-�����������<��=����<-���%� ���%*���������������+���������������+����%�������>�����>�--������%��%%���-���'�

���+�����<��=����<-���F$�HPF$�G�+���-���������������'�

� ������ �����

���������� �����

��� ��������

��� ��������������������

�Fig. 4.���%���B��������F$�H�����-�

�������N���<���%��F$�H����>��*��������������+���-'�,�����������������<��%������������-�*-�>�%<���*��������%��������B����������*��+������%���������+��%��*�F$�G���������'� ���� Test Translation ��� Test Execution� ��������%� ��� ���� �--%� ��� ������+���������������+����%������'�����+���-�-%��������%����������������*��+�����<��=����<-��A���%���<����%����*�������%������+��������� ��%�����%������-�%�� �% ��������%�������'����%��������%������<��������%�<<����*���<��=�����B�������'�

57

Page 65: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

������'����� ����'���������

��� ���%� %���� ���� F$�HPF$�G� +���-� ��� ��� �=�%���� *��� ���� ��������� ����%� A�%�+��%<���*���%��������--%��������������'�'�����--����MG�����*������������������+���-� ��<�%������ ��� ����-F�%'� ��>������ >�� >��-�� -� �� ��� �+<�%�K�� ����F$�GPF$�H� +���-� �������� >���� ���� ���%*��+����� �%� -����� �B�����-��� �'�'� ���B�����-��F$�G�%���<����������������'�

,�����������<��������������<��>���+<-�+����������*�--���������-������������+���������������+����%������'����%�%��������%��>��������*���<���������������O�������% ���*��+������������<��%����-'�

�Fig. 5.���%�����%-�����������������>�

����>��������*����*�������+���������������+����%��������%�%��>������������!'�����<��%����-����<��������>����������*��+��������������Test Translation��% C���%�%���������������������-�������-�%��>�� �<������%�������'�������%<��%��-��<��%�������������� ����%�%��+����<%%� ����������-� ��� ������B��Test Execution� �% �����-�� �����������Finish ������'� ,���������� ��� ����>��� �����*��� ���� %�����������*��%� ����<��%����-�>���������% �%���%�����-�����%������������% ����%'�

����>����%����+�%��*����������<��������-%�������*��������I�"J'��

58

Page 66: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that

MDE Project Execution Support via SPEM Process Enactment�������

5 Conclusions

,�� ���%� <<��� >�� <��%������ �� <<����� *��� ���� <��=���� �B�������� %�<<���� �%���� �<����%%������%��������B�������*��+��<��=����<-�'����%�>�� ��%���������������*������**���%� ��� $��� <����%%� ����+���� ��%����'� ���� ��������%���� *������ �*� ����<<����� �%� ����������� �*� ���� ��+�� ��������� ����+���� %������� ��� ���� <��=������%��������� %���'� ���� *���%� >%� <��� �� ���� %�+-�%%� ���������� �*� �� �B�����-��F$�G�%���<��>��-�� ��<����<�%%��-���������������B����-�%������%���'�'�����-F�%'�

���������<��<��%������ ��� ����<<���>%� �--�%������>����� ��<��%���������B+<-���B������� *��+� ���� ��.�G$G�L� ��� +������-���'� ���� ���� *�%���-���� %����� ���������<�� >%� �+<-�+������ ��� ��=���������� M��� ���-� ��� ��+�� �������������+����%�������>%�������'�

U�� ��-����� ���� �����<�� �%� <<-���-�� *��� -���� �������� �.�� <��=���%� ��� ���<������� � �-��-�� %������� ��� ������--���� ���� >�� *-�>� ��� ��*��+���� ����-����<��%����-'�,����������������������B��������%�<<����>�--��+<���������$�����<������������%���'��

6 Acknowledgements

���%� >�� � >%� ��;*������ ��� ���� ����<��� M�++�%%���� ��� ���� *�+�� �*���.�G$G�L�<��=���'�

References

I�J� ��@� �*�>��� $����%%� ������������ ���+���-�����<CPP>>>'�+�'���P������-���P����+���%P*��+-P%<�+'��+�

I�J���.�G$G�L�/�$#;�""!;,�;!:�<��=��������<CPP>>>'+���-<-�B'����IEJ�����M�/�$#;�""!;,�;!:�<��=��������<CPP>>>'+�+��%'����INJ���$��/�$�;,M�;�""�;�:�<��=��������<CPP>>>'%�<�;<��=���'���I!J�U;F$�G�%<���*��������>>>'�%�%;�<��'���P��++�����%P>%�<�-P�I#J� ?'� F�������� �'� ���� ��� �'� @����%� ��� L'� F-���� V�*�>��� $����%%� ����-���� ���

�B�������C�����T�GN$�����U;F$�G��<<����W��$���������%��*�,�����T?��,M?���""���<<'�E�N;E����,FH�";�#R!;�R��;��

I�J� �'� �-�K�-�� �'� F�-��� �'� H��-��%�� �'�� ���� ��� M'� ����� ��� �'� ?������� X����+��������-� .������ .���-�<+���� $����%%�%X�� �M�.�� �""Q� ;� ���-%� Y� $����%%� ,����������U�� %��<��F��-����Z�����""Q�

IQJ�$�>�����<- ���'�����-F�%� ;�����<������.�%����������������+���� *�������-�.�������������������$�'.���<��+�����""��

IRJ���=����������M������-�����<CPP>>>'��=���������'��+�I�"J�������[%�?Y.���<��+����>��;%��������<CPP��'%�*��+'��+�

59

Page 67: Proceedings of the first Twente Data Management Workshop ...extra information, which will be discussed below, this is a standard UML class diagram. Figure 3 is a design delta that