me 2010 preliminary proceedings

8/8/2019 Me 2010 Preliminary Proceedings

1/113

Program ChairsDirk DeridderVrije Universiteit Brussel, BelgiumBernhard Schtzfortiss GmbH, GermanyDalila TamzalitLINA, University of Nantes, FranceAlfonso PierantonioUniversit degli Studi dell'Aquila, Italy

Steering CommitteeDirk DeridderVrije Universiteit Brussel, BelgiumHubert DuboisCEA LIST, FranceJeff GrayUniversity of Alabama, USATom MensUniversit de Mons, BelgiumAlfonso PierantonioUniversit degli Studi dell'Aquila, ItalyBernhard Schtzfortiss GmbH, GermanyPierre-Yves Schobbens

University of Namur, BelgiumDalila TamzalitLINA, University of Nantes, FranceStefan WagnerTU Mnchen, Germany

Program CommitteeArnaud AlbinetContinental Automotive, FranceBenoit BaudryIRISA, University of Rennes, FranceMireille Blay-FornarinoUniversit de Nice-Sophia Antipolis, France

Jean-Michel BruelUniversity of Toulouse, FranceJordi CabotEMN Nantes, FranceRubby CasallasUniversity of Los Andes, ColombiaAntonio CicchettiMlardalen University, SwedenDavide Di RuscioUniversit degli Studi dell'Aquila, ItalyAnne EtienINRIA Futurs, FranceJean-Marie FavreOneTree Technologies, Luxembourg

Mehdi JazayriUniversity of Lugano, SwitzerlandGerti KappelTU Wien, AustriaUdo KelterUniversitt Siegen, GermanyOlivier Le GoaerLINA, University of Nantes, FranceRichard PaigeUniversity of York, United KingdomAntonio VallecilloUniversidad de Malaga, SpainRagnhild Van Der Straeten

Vrije Universiteit, BelgiumHans VangheluweUniversiteit Antwerpen, BelgiumD i W l

International Workshop on

Models and Evolution

ME 2010

ACM/IEEE 13th International

Conference on Model Driven

Engineering Languages and

Systems

Oslo, Norway - October 3-8, 2010

http://www.modse.fr

Preliminary Proceedings


2/113

Long papers


3/113

Merging Model Refactorings

- An Empirical Study -

Maximilian Koegel, Markus Herrmannsdoerfer, Otto von Wesendonk,Jonas Helming, and Bernd Bruegge

Institut fur Informatik, Technische Universitat MunchenBoltzmannstrasse 3, 87548 Garching, Germany

{koegel, herrmama, wesendon, helming, bruegge}@in.tum.de

Abstract. Model-driven development promotes models as abstractionsof a system from which the system code can be generated. As a conse-

quence, many development activities such as refactoring have moved fromthe code- to the model-level. A model refactoring is a composite changeconsisting of a series of model changesthat improves the model qualitybut does not change the system behavior. Version Control (VC) systemsare applied to control change on models and to facilitate collaboration.Many of them are limited in their ability to detect composite changesand to use them for merging. To overcome these limitations, operation-based VC systems directly track the composite changes. In this paper,we present an empirical study to answer the following research questions:(1) Do developers produce a better merge result when merging with in-formation about composite changes? (2) Do developers favor to discusscomplex merges instead of being forced to solve them immediately? Weshow that merging can be improved significantly by information aboutcomposite changes, and that developers like to discuss merges when they

reject changes from the repository.

1 Introduction

Models are an essential artifact throughout the entire life cycle in software en-gineering projects. These models include UML and SysML models as well asproject management models like release plans. Model-driven software develop-ment is putting even more emphasis on models, since they are not only anabstraction of the system under development, but the system is generated fromits models. As a result, many development activities that have originally beenperformed on code are now performed on models. One of these activities is

refactoring. Model refactorings are model transformations that restructure themodels in order to improve certain quality attributes of the models, but preservethe behavior [19]. They are the model-level equivalent of source code refactor-ings [7]. Refactoring is a maintenance activity. According to Lehman [13], anevolving system erodes due to increasing complexity without refactoring. Modelrefactorings are complex changes on a model and are usually comprised of sev-eral atomic model changes. For example, an extract superclass refactoring on


4/113

2 Merging Model Refactorings - An Empirical Study

a UML class diagram creates a new superclass for a number of existing classesand moves shared attributes and associations from the subclasses to the new

superclass. This refactoring results in many atomic changes.Version Control (VC) systemsalso known as Software Configuration Man-

agement systemsare widely used to control change on models and to facilitatecollaboration. Most of them employ optimistic concurrency control to allow forparallel and offline work on their configuration items which may be models. Asa consequence, conflicts can occur between the changes that are performed con-currently by different parties on the configuration items. Model merging is theactivity of resolving these conflicts. Traditional VC systems such as CVS or Sub-version support merging for textual artifacts such as source code on a textuallevel. However, many researchers recognized that these systems are very limitedwhen applied on models, especially in the use case of merging [1, 5, 10, 11, 1618].Nguyen et al. describe this problem as the impedance mismatch between the flattextual data models of traditional VC systems and graph-based software models[16]. Different approaches have been proposed to cope with the shortcomings ofexisting methods and techniques to better support change tracking and merg-ing of graph-based models. They can be categorized into three different classes:state-based, change-based and operation-based approaches [4].

State-based approaches only store states of a model and thus need to de-rive differences by comparing two statese.g., a version and its successorafter the changes occurred. This activity is often referred to as differencingand is required for merging to detect conflicting changes.

Change-based approaches record the changes, while they occur, and storethem in a repository. There is no need for differencing, since the changes arerecorded and stored, and thus do not need to be derived later on.

Operation-based approaches are a special class of change-based approa-ches which represent the changes as transformation operations on a state.The recorded operations can be applied to a state to transform it into thesuccessor state. Merging is performed based on the recorded operations.

From a versioning point of view, refactorings are complex changes and aremore difficult to cope with than simple changes, such as changing an attributeor creating an element. Refactorings should be considered as atomic changesfor versioning, since they should not be applied partially. However, most of thestate-based approaches are not able to detect refactorings, since they have toderive the changes by differencing. It is impossible to detect a refactoring withcertainty, since it looks exactly like a set of simple changes. Nevertheless, thereare approaches that try to heuristically recover the refactorings from a state-based difference [2, 3, 8]. In contrast, operation-based VC systems can directlyrecord refactorings as composite operations.

Independent of the approach how the information about composite changeswas derived, it is considered to be helpful for conflict detection and merging [14,15]. However, to our best knowledge, there is no empirical evidence about thebenefits of information about composite changes for model merging. To provide


5/113

Merging Model Refactorings 3

this evidence, we have performed an empirical study. We have developed a ques-tionnaire consisting of 8 merging scenarios and distributed it to 46 developers.

As a result, we received 778 merge decisions and statistically analyzed them. Inthis paper, we present the design and results of the empirical study.

Outline. Section 2 provides an introduction to composite changes on models andto the merge problem considering these changes. Section 3 presents the designof the empirical study, its results and an interpretation of the results. Section 4concludes the paper with a short summary. Related work is not aggregated in aseparate section but is provided inline.

2 Merging Complex Changes

Models are abstractions of the system under development or of the developmentproject itself. Models are essentially graphs with attributed nodes. Many of thepossible changes on a model can be described by simple graph changes, such asadding edges and nodes or changing attributes of nodes. However, some modelsare also subject to more complex changes. For example, a UML class diagramcan be refactored. Within one command from a usere.g., performing an extractsuperclass refactoringmany nodes and edges might be created, removed orchanged. From a technical point of view, these changes consist of a number ofsimple changes. This implies that changes occur on different levels of abstraction;we refer to these levels as change granularity.

While traditional VC systems treat change on the representational level, ap-proaches exist on top of them to treat changes on the level of a graph representingthe model [6]. If the respective approach is not independent of a certain meta-

model, it may also treat changes on the metamodel level, e.g., on the level ofa UML class diagram. To capture refactorings on models the system must alsobe able to capture complex changes as composite changes consisting of severalchanges on the metamodel level of change. Furthermore, many of these complexchanges are performed atomically. So they only reflect the developers intention,if all the included changes on the model are applied as an atomic unit. Other-wise, the intention of the developersuch as preserving the behavior in case ofrefactoringis only partially reflected in the model and hence might not makesense. To illustrate a conflict on a complex change and a merge result with a par-tially applied complex change, we provide a detailed example from the domainof UML class diagrams. The complex change is an extract superclass refactoring.This refactoring creates a common super class for a number of existing classes.All common attributes and associations of the existing classes are pulled up intothe newly created superclass. The ancestor model as well as all other versionsare shown in Figure 1.

We assume that a developer A now performs an extract superclass refactor-ing on the classes Bus and Car, resulting in the model state shown in Figure 1.The refactoring effectively pulls up the composition to Engine from Car andBus to the new superclass P oweredV ehicle. Another developer B also starts


6/113


with the same ancestor model but decides to perform a different change, result-ing in the model state shown in Figure 1. The developer changes the multiplicity

of the composition from Bus to Engine on the side of Engine to unboundedto reflect the fact that buses might have more than one Engine. Under theassumption that developer A has already committed his changes to the reposi-tory, an attempt to commit from the second developer B will result in a mergesituation. The two design choices and hence the two intentions of the develop-ers are conflicting. Either the composition from Car to Engine has a differentmultiplicity than the composition from Bus to Engine, or they have the sameand the refactoring can be fully applied. If a system is not aware of intentionalchanges, it will look at this conflict from a metamodel level point of view. De-veloper A wants to delete the composition from Bus to Engine (as part of therefactoring), while developer B wants to change the multiplicity of the sameassociation on one end. This can also be identified as a conflict however, itis not only displayed differently to the user, but it is also treated differentlyin a merge. In case developer B decides to keep his or her change, the refac-toring of developer A will only be partly reflected. The composition from Busto Engine is still required to exist to be able to keep the change of developerB. However, Bus now additionally shares another composition with Engine in-herited from its new superclass P oweredV ehicle. The resulting model with thepartially reflected refactoring is shown in Figure 1. In the following, we referto these partially applied refactorings as partial refactorings. Partial refactoringshall be avoided, because refactorings represent an atomic set of changes andshall not be applied partially.

*11

Vehicle

Bus CarBike

Engine1 1

Vehicle

Bus CarBike

Engine* 1

Ancestor Version After Changes of Developer B

Vehicle

Bus Car

Bike EnginePoweredVehicle

Vehicle

Bus Car

Bike EnginePoweredVehicle

After MergeAfter Changes of Developer A

Fig. 1. Example of a partially applied Refactoring after the Merge

3 Empirical Study

In this section, we present the empirical study to show the benefits of informationabout composite changes for model merging. We describe the research questions,the design of the study, the results, their statistical evaluation and interpretation.


7/113


3.1 Research Questions

We conducted the empirical study to answer the following research questions:

1. Do developers produce a better merge result when merging withinformation about composite changes?

When developers merge models with complex changes such as refactorings,do they profit from information about composite changes? And if they do,how much do they profit? Is the merge result better in comparison to a mergeresult without this additional knowledge?

2. Would developers favor to discuss complex merges instead of beingforced to solve them immediately?

When developers merge models, they are normally forced to complete themerge, before they can commit their changes to the repository. Would devel-opers favor to postpone a merge decision and first discuss the conflict with

the involved developer?

3.2 Study Design

We designed a questionnaire consisting of 8 different merging scenarios. In everyscenario, the developer is presented a description of the current model state andof the changes that he or she has performed including a rationale for the changes.The developer is then confronted with a merge situation due to conflicts withnew incoming changes from the repository.

The model is a simple UML class model in slight variations, see Figure 1for an example. The conflicting changes always contain at least one refactoringoperation as a representative for a complex change. We selected the refactorings

by frequency of occurrence in a case study on the evolution of the metamodelsfrom the Graphical Modeling Framework (GMF) that are specified in Ecore [9]:Extract/Inline Class, Extract/Inline Superclass, Partition/Join Association andPull-up/Push-down Attribute/Association. Figure 2 shows an example for eachrefactoring.

make: StringhorsePower:int

Vehiclemake: String

VehiclehorsePower:int

Engine

1Bus Car

Engine1 1

Bus Car

Engine1

Vehicle

Extract/Inline Class Extract/Inline Superclass

ElectricEngine

PetrolEngine

Engine

Vehicle ElectricEngine

PetrolEngine

Engine

Vehicle

Partition/Join Class

horsePower:intCar

Vehicle

horsePower:intBus Car

horsePower:intVehicle

Bus

Pull-up/Push-down Attribute

Fig. 2. Refactoring Examples


8/113


The same scenario is once presented without the composite changes and oncewith the composite changes taken into consideration. In other words, the merge

is once performed on the intentional level of change, and once on the metamodellevel of change. Since the time for questions per interviewee is limited, we can notpresent models and also commits with realistic sizes. To simulate reasonably largecommit sizes, we just presented the conflicting changes, but gave the developersthe choice to look at the other, non conflicting changes which might help tounderstand the intention of the other developer. Therefore, the developers hadthe following choices: (1) Accept Mine: Accept my change and reject the changefrom the repository, (2) Accept Theirs: Accept the change from the repositoryand reject my change, and (3) Take More Time: Take more time to look atall incoming changes.

For each merge result, we measure whether it implies a partial refactoringas introduced in Section 2. Please note that for questions that take compositechanges into account, it is impossible to perform a partial refactoring. If a con-flicting change as part of a composite change is rejected, the whole compositewill be rejected. Additionally, we offer the developer for every merge question thepossibility to discuss his or her choice with the respective opponent developer.The merge scenarios and questions were not represented in a tool to avoid anyrepresentational or usability-related influences on the result. The questionnaireis available online at [12].

3.3 Study Result

We have interviewed 46 developers by means of an electronic questionnaire. 48%of the developers are professionals and 52% students. 67% of the professionals

are software engineers, 29% researchers and 4% other developers. 58% of thestudents are Bachelor students and 42% Master students, and they all have aComputer Science related major. Figure 3 depicts the experience of developersin years grouped by three areas: Object-Oriented Programming, Source CodeRepositories and Unified Modeling Language and the frequency of use of refac-torings on code and on UML class diagrams.

Fig. 3. Developer Experience and Refactoring Usage

The 46 developers have answered 778 merge questions in total. 368 of thosewere questions with information about composite changes and 410 without. For


9/113


the latter, 49% of the merges resulted in partial refactorings. Conservatively, weassumed that a developer selecting to take more time to look at all incoming

changes would come up with a merge without partial refactorings. As notedearlier, there are no partial refactorings with the information about compositechanges, which was also reflected in the data. Figure 4 shows the distribution ofthe choices for the merge scenarios for questions with and without informationabout composite changes. The developers also indicated whether they would liketo discuss a decision with the developer that committed the conflicting change.The full results of the study in terms of raw data are available on [12].

Fig. 4. Merging and Discussion Choices

3.4 Statistical Evaluation

We have performed a number of statistical tests on the data to test the validityof different hypotheses in terms of the gathered data. All the tests we performedare on binary random variables. We assume that the decisions for different mergequestions are independent. Therefore, the binary random variables can be as-

sumed to have a binomial distribution. Binomial distributions are characterizedby a probability p for a single experiment to succeed. For all tests we have twosample groups. For example, we have the groups of merge decisions with andwithout information about composite changes, and the binary variable whetherthe merge produced a partial refactoring or not. For the two samples, we calcu-late a 99% or 95% confidence interval for the binomial distributions probabilityp. In other words, given the sample the parameter p of the distribution is with99% or 95% probability in this interval. We calculate the interval based on thefollowing formula by using the arithmetical average as a maximum likelihoodestimate for p, where k is the number of instances of the sample where the vari-able is true and a is the constant for the respective significance level (1.96 for95% and 2.3264 for 99%):

kn p a

(p (1 p))

n

Once we have derived the interval for both samples, we check if they overlap.If they do overlap, we cannot derive any significant statement for the hypothesis.If they do not overlap, however, we can accept the hypothesis on a 99% or 95%


10/113


significance level. In the following, we will describe different hypothesis and theirresults:

Partial Refactorings vs. Composite Changes. Our hypothesis is thatpartial refactorings are significantly less frequent in merges with informationabout composite changes. We have two samples: all merge decisions without andwith information about composite changes. The binary random variable is true ifthere is no partial refactoring. The 99% confidence interval for the group withoutcomposites is [0.4506, 0.5708], while the other group results in the interval [1, 1].Clearly, they are not overlapping, so we can accept the hypothesis on a 99%significance level.

Merge Choice vs. Composite Changes. Our hypothesis is that the dis-tribution of the merge choices (Accept My, Accept Theirs, Take More Time)was different for merge decisions without and with information about compositechanges. More specifically, we expected more choices to Accept Mine for deci-sions without information about composite changes. However, the intervals areoverlapping, so we can not accept the hypothesis on a 95% significance level.

Discussion vs. Merge Choice. We expected that developers would dis-cuss decisions more often, if they reject a change from the repository or if theyrequest more time. This leads to three hypotheses on this correlation. Our firsthypothesis is that merge decisions with the choice Take More Time requireda discussion more often than decisions with the choice Accept Theirs. Our sec-ond hypothesis is that merge decisions with the choice Accept Mine requireda discussion more often than decisions with the choice Accept Theirs. Finally,our third hypothesis is that merge decisions with the choice Accept Theirs re-quired a discussion less often than both other decisions. We have two samples foreach hypothesis: all merge decisions with the respective choice and all decisionswith another choice. The binary random variable is true if there is a discussion

request for the decision. The 99% confidence intervals for the first groups are[0.6080, 0.7369], [0.6157, 0.7426] and [0.1517, 0.2350], respectively. The intervalsfor the second groups are [0.1199, 0.2351], [0.2091, 0.3353] and [0.5653, 0.6927].The two corresponding intervals for all three hypotheses do not overlap, and wecan thus accept the three hypothesis on a 99% significance level.

3.5 Result Interpretation

In this section, we interpret the results in terms of the research questions posedin Section 3.1, taking into consideration the statistical results from the previoussection.

The results show that developers produce a fairly large percentage (about

50%) of partial refactorings in their merge results, if they do not have informationabout composite changes. They decided in favor of them, even though theyhad the choice of taking more time to look at all incoming changes. We claimthat this is a realistic simulation of the merge case, where possibly hundreds orthousands of changes are incoming that might help to understand the conflicts.In these situations, developers are forced to either spend time to look at manychanges or to make a decision only by looking at the conflicting changes. Also,


11/113


we claim that partial refactorings are a suboptimal merge result, and that itis favorable to apply a refactoring completely to preserve its intention. The

statistical test provides evidence that partial refactorings are less frequent inmerges with information about composite changes on a significance level of 99%.More specifically, the difference in the probability of partial refactorings is atleast 0.43 with a significance of 99%.

In 70% of these complex merge situations, developers would have liked todiscuss their choice. The request for discussion is dependent on the choice thedevelopers made in the merge. If they choose to accept their changes or takemore time for a decision, they tend to discuss the choice more often. A selectionto accept the incoming change is less often selected for discussion. Both claimshave been shown on a 99% significance level by the statistical tests. This seemsreasonable and we expected this, since a developer only favors an incomingchange over his or her change, if he or she understands and approves the incomingchange. These decisions less often require a discussion. If a developer selects hisor her own change and thus discards another change, it seems reasonable todiscuss this choice with the other developer more often. Finally, if a developerchooses to take more time, the decision seems to be difficult and therefore isprobably more often suited for a discussion.

4 Conclusion

We investigated the problem of merging complex changes with and without infor-mation about composite changes. We assessed both approaches in an empiricalstudy. During the study, 46 professional and student developers made 778 deci-sions on merges including refactorings. The results clearly show that information

about composite changes significantly improves the merge result. We can con-clude on a 99% significance level that the probability for a consistent mergeresult on complex changes is at least 75% better with information about com-posite changes than without it. Also we can show that developers favor to discusscomplex merges when they reject changes from the repository. A solution basedon operation-based change tracking to capture change on the intentional levelwas already presented in [10, 11]. The results of this study imply that applyingoperation-based merging can improve merge results.

References

1. C. Bartelt. Consistence preserving model merge in collaborative development pro-

cesses. In CVSM 08: Proceedings of the 2008 international workshop on Compar-ison and versioning of software models, pages 1318, New York, NY, USA, 2008.ACM.

2. P. Brosch, M. Seidl, K. Wieland, M. Wimmer, and P. Langer. The operationrecorder: specifying model refactorings by-example. In Proceeding of the 24thACM SIGPLAN conference companion on Object oriented programming systemslanguages and applications, pages 791792, Orlando, Florida, USA, 2009. ACM.


12/113


3. A. Cicchetti, D. D. Ruscio, R. Eramo, and A. Pierantonio. Automating co-evolutionin model-driven engineering. In Enterprise Distributed Object Computing Confer-

ence. IEEE Computer Society Conference Publishing Services (CPS), 2008.4. R. Conradi and B. Westfechtel. Version models for software configuration man-agement. ACM Comput. Surv., 30(2):232282, 1998.

5. D. Dig, K. Manzoor, R. Johnson, and T. N. Nguyen. Refactoring-aware configu-ration management for object-oriented programs. In ICSE 07: Proceedings of the29th international conference on Software Engineering, pages 427436, Washing-ton, DC, USA, 2007. IEEE Computer Society.

6. Eclipse. EMF Compare. http://wiki.eclipse.org/EMF_Compare.7. M. Fowler. Refactoring: Improving the Design of Existing Programs. Addison-

Wesley, 1999.8. K. Garces, F. Jouault, P. Cointe, and J. Bezivin. Managing model adaptation by

precise detection of metamodel changes. In ECMDA-FA, pages 3449, 2009.9. M. Herrmannsdoerfer, D. Ratiu, and G. Wachsmuth. Language evolution in prac-

tice: The history of GMF. In 2nd Intl. Conference on Software Language Engi-

neering (SLE09), 2010.10. M. Koegel. Towards software configuration management for unified models. In

CVSM 08: Proceedings of the 2008 international workshop on Comparison andversioning of software models, pages 1924, New York, NY, USA, 2008. ACM.

11. M. Koegel, J. Helming, and S. Seyboth. Operation-based conflict detection andresolution. In CVSM 09: Proceedings of the 2009 ICSE Workshop on Comparisonand Versioning of Software Models, pages 4348, Washington, DC, USA, 2009.IEEE Computer Society.

12. M. Koegel and O. von Wesendonk. Empirical Study Companion Webpage. http://www1.in.tum.de/static/shared/studies/merge/.

13. M. M. Lehman, J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski. Metricsand laws of software evolution - the nineties view. In METRICS 97: Proceedingsof the 4th International Symposium on Software Metrics, page 20, Washington,

DC, USA, 1997. IEEE Computer Society.14. A. Lie, R. Conradi, T. M. Didriksen, and E.-A. Karlsson. Change oriented ver-sioning in a software engineering database. In Proceedings of the 2nd InternationalWorkshop on Software configuration management, pages 5665, New York, NY,USA, 1989. ACM.

15. T. Mens. A state-of-the-art survey on software merging. IEEE Trans. Softw. Eng.,28(5):449462, 2002.

16. T. N. Nguyen, E. V. Munson, J. T. Boyland, and C. Thao. An infrastructure fordevelopment of object-oriented, multi-level configuration management services. InICSE 05: Proceedings of the 27th international conference on Software engineering,pages 215224, New York, NY, USA, 2005. ACM.

17. D. Ohst. A fine-grained version and configuration model in analysis and design. InICSM 02: Proceedings of the International Conference on Software Maintenance(ICSM02), page 521, Washington, DC, USA, 2002. IEEE Computer Society.

18. J. Rho and C. Wu. An efficient version model of software diagrams. In APSEC98: Proceedings of the Fifth Asia Pacific Software Engineering Conference , page236, Washington, DC, USA, 1998. IEEE Computer Society.

19. R. V. D. Straeten and M. DHondt. Model refactorings through rule-based in-consistency resolution. In Proceedings of the 2006 ACM symposium on Appliedcomputing, pages 12101217, Dijon, France, 2006. ACM.


13/113

Documenting Stepwise Model Refinement using

Executable Design Decisions

Matthias Biehl

Embedded Control SystemsRoyal Institute of Technology

Stockholm, [email protected]

Abstract. During model refinement a wealth of knowledge about themodel under development is accumulated that is only partly represented

by the model itself. Design decisions and the considered modeling alter-natives are neither represented by the model nor are they documented.During later lifecycle stages this information is often not available anymore, which reduces the understandability of the model and potentiallyleads to inconsistencies and erosion of the model. We propose an ap-proach to capture and store the design decisions in model-driven de-velopment. We represent design decisions as model transformations andpropose tool support that applies this representation to capture designdecision with low effort. The captured design decisions provide a recordof the model evolution and the rationale of the evolution.

Key words: Design Decision, Evolution, Model Transformation, Re-finement

1 Introduction

During the early stages of architectural design a number of alternative architec-tural models are created, evaluated and refined. During this exploration phasea lot of knowledge about the system is acquired, which is important duringlater lifecycle phases such as detailed design and maintenance. However, thisknowledge consisting of design decisions and their justification is usually notdocumented due to the associated time and cost overhead.

Capturing and documenting design decisions is expensive and is often seen asan additional obligation not providing any immediate value in the design process.

In fact, the value of design decision documentation will usually surface muchlater in the lifecycle, for example during maintenance activities. By the timethe knowledge is needed, it is usually not readily available any longer. Decisionsthat seemed to be self-evident at the time they were made can often not bereconstructed or understood later in the development process. This problem isknown as knowledge vaporization [3], which results in further problems such asinconsistencies, design erosion, aging and architectural drift [20, 16, 17].


14/113

2 Matthias Biehl

The design method of stepwise refinement of programs was first exploredby Dijkstra [6] and by Wirth [22]. Wirth states that program development is

a series of refinement steps, further he links refinements with the design de-cisions. Refinement can have slightly different meanings. In the strict sense, arefinement describes adding detail to something that already exists. In a morerelaxed sense, refinement can also include adding new functionality. An exampleof a development method based on architectural refinement is Attribute DrivenDesign (ADD) [23]. ADD prescribes a top-down decomposition process that sub-sequently attacks all quality attributes in their order of importance.

In this work we assume a model-driven development process, where modelsare developed iteratively by refining a baseline model. Iterative refinement startswith an initial model, which is the first baseline model and may be empty. Ineach refinement step the baseline model is changed, yielding a new model thatserves as baseline for the consecutive refinement step.

One refinement step entails a small change in the model and cannot be un-derstood without considering related refinement steps made immediately beforeand after. It makes sense to bundle refinement steps into logical entities thatcomprise several refinement steps. A design decision is such a logical entity thatcomprises several related refinement steps.

When a model is refined, a number of design decisions are made and appliedon an initial model. As a result a modified model incorporating the changesinduced by the design decisions is created. Thus the model refinement can bedocumented by a sequence of design decisions.

Architects have long recognized the importance of documenting design deci-sions, as Tang et al. found in their survey on architecture design rationale [18].Practitioners use documented design rationale to reason about the architecture.While some representations and tool support are available, the capturing of de-

sign decisions and their rationale still creates additional overhead, making designdecision documentation a double edged sword [10].

This paper is structured as follows. In section 2 we introduce related work.In section 3 we introduce our representation for design decisions. In section 4we show how this representation can be used to capture design decisions withlow effort. In section 5 we present a case study in which we apply our approachon a model of an automotive embedded architecture. We conclude this work insection 6.

2 Related Work

In this section we review related work in the area of design decision represen-tation. Kruchten [9] specifies an ontology of architectural design decisions. Anumber of different approaches for representing design decisions have been pro-posed in academia. Informal representations document design decisions in theform of free text and use-cases. Template-based approaches provide a guidelinefor textual descriptions of design decisions such as the template by Tyree andAkermann [21]. Structural approaches explicitly represent the design delibera-


15/113

Documenting Stepwise Model Refinement using Executable Design Decisions 3

tion process, including alternatives and arguments. Examples are IBIS [11], PHI[15], DRL [12] and QOC [14]. Approaches for representing design decisions that

were developed in recent years focus on linking design decisions with the archi-tectural model. The SEURAT approach links rationale to specific lines in thesource code [4]. AREL is a UML profile that can be used to annotate architec-tural models with design decisions and rationale [19]. The Archium [7] approachassociates design decisions with modifications of the architecture. These modelsprovide descriptions, traceability and linking to other modeling elements.

3 Representation of Design Decisions

In this section we introduce our representation for design decisions, which istailored for model-driven development. There are several objectives for our rep-resentation of design decisions for model-driven development:

Objective 1: Design decisions should be represented explicitly.

Objective 2: The design decision representation should reduce the captureoverhead.

Objective 3: Design decisions should be represented independently of acertain modeling language.

Objective 4: The documentation of design decisions should be consistentwith the architectural model.

Objective 5: The documentation of design decisions should be linked tothe model elements affected by the decision.

3.1 Executable Design Decision

Our representation for a design decision consists of the following parts: a modeltransformation and a textual description (objective 1). The representation iscalled executable design decision [1], as a model transformation engine can ex-ecute it automatically (objective 2). The core of the executable design decisionis a model transformation, which describes both the context in which the designdecision can be made and the effect that the design decision will have on the ar-chitecture (objective 5). Since we use model transformations to represent designdecisions, we can execute the design decision and inspect the effect the design de-

cision has on the model. As a consequence of this automation, the model and thedesign decision are consistent (objective 4). Model transformations can be spec-ified for any metamodel without needing to change the metamodel (objective 3).Different model transformation technologies can be used for expressing designdecisions, as long as the model transformation engine fulfills certain require-ments, such as support for model-to-model transformations that are endogenousand in-place.


16/113

4 Matthias Biehl

3.2 Formalization of Design Decisions

In the previous section we introduced our representation of design decisions.Design decisions are interpreted as change functions and represented as modeltransformations. When a design decision is made for a given model, the resultis a new model incorporating the changes induced by the design decision. Ifwe interpret the design decision as a function, the input of the function is theprevious model, the output is a new model.

This can be formalized as follows: A design decision d : M M made ona given architectural model A0 M yields a new architectural model A1 M,where M is the set of possible architectures described according to a commonmetamodel. The design decision can be interpreted as a function over architec-tural models, where an execution of the design decision creates a new architectureincorporating the changes induced by the design decision d, in short A1 = d(A0).Several design decisions d1...dn are made during architectural refinement, for-

malized as a composition of functions An = (dn dn1 ... d1)(A0). As a resultwe can describe the design process explicitly as dndn1...d1, i.e. the sequenceof steps by which the architecture is refined, instead of the outcome An of thedesign process.

4 Capturing Design Decisions

In stepwise model refinement the capturing of design decisions comprises foursteps:

1. Performing an update of the model, so it reflects the new design decision2. Documenting where in the model the change applies and what is changed3. Documenting the rationale of the change4. Linking the documentation to the model elements affected by the change

The overhead of these steps is one of the main reasons why design decisions arenot documented [10]. Tools can help to reduce the overhead for the architect,by exploiting the intrinsic relation between steps (1), (2) and (4). A modeltransformation has a precondition and a postcondition that can be used fordocumenting where in the model the change applies and what is changed (2).When the model transformation is executed on the initial model, the outcomeis the updated model (1). The precondition of the model transformation linksthe design decision to the model before the change and the postcondition linksthe design decision to the model after the change (4). A model transformationis capable of capturing steps (1), (2) and (4) by a single representation.

The architect does not need to create the model transformation manually,instead it can be created algorithmically from different snapshots of the model.We can create this model transformation based on a snapshot of the model takenbefore the change and a snapshot taken after the change. We use a triple graphgrammar (TGG) rule to describe the design decision dn of section 3.2. A TGGrule consists of three graphs, a left-hand side graph, a right-hand side graph anda mapping graph. We calculate these three components in the following way:


17/113


Left-hand Side (LHS) The model An1 corresponds to the context of theapplied decision, i.e. the snapshot of the model before the change.

Right-hand Side (RHS) The model An corresponds to the outcome ofthe applied decision, i.e. the snapshot of the model after the change.

Mapping The mapping graph establishes identity links between elementsin the LHS and RHS. Given the LHS and RHS, the mapping graph can becomputed e.g. by comparing the values of the model elements in LHS withthe model elements in RHS.

5 Case Study

To validate our proposal of using model transformations to represent designdecisions we perform a case study on design decisions in a model of an automotive

brake-by-wire system. In this case study we explore modeling a design decisionusing different model transformation languages, ATL and Tiger EMF. ATL isa representative from the class of hybrid (declarative and imperative) modeltransformation languages and Tiger EMF as a representative from the classof model transformations based on triple graph grammars. The intention is toexplore the feasibility and usability of different classes of model transformationapproaches for representing design decisions.

5.1 Brake-By-Wire Architecture

In modern cars the traditional mechanics and hydraulic connection between userinterface and actuators are increasingly replaced by electronics and software

[13]. In this case study we will look at a subsystem of the automotive softwarearchitecture, a brake-by-wire system.

We use EAST-ADL2 [5] as a representation for the architecture of the brake-by-wire system. EAST-ADL2 is an architecture description language for thedomain of automotive embedded systems. It can be used to describe high-levelabstract functions and both the hardware and the software architecture of anembedded system.

Figure 1 shows an initial architecture of the brake-by-wire system modeledwith EAST-ADL2. We use it as an initial model that is subsequently refined.In a brake-by-wire system the brake pedal is a component that reads the usersinput and sends this information over a network to the brake controllers atevery wheel. At each wheel a brake controller receives both information aboutthe wheel speed and the requested braking from the pedal. The brake controlleractuates the mechanical brake in order to achieve a good braking performance,e.g. to avoid skidding.

Safety and reliability are important qualities of a brake-by-wire system. Thusthe design decisions made during the development of the brake-by-wire systemneed to address safety. Common design decisions in safety-critical embeddedsystems are decisions about the replication of components with the intent to


18/113

6 Matthias Biehl

Fig. 1. Simplified brake-by-wire system modeled with EAST-ADL2

enhance the reliability of the system. These decisions have a major impact onboth the safety and the cost of the complete system as we will see in this example.

Option B in Fig. 2 shows a refined architecture of the brake-by-wire system.Here we intended to increase the reliability and safety of the system and decidedto use triple redundancy with a voter for the pedal sensor. An alternative design

option uses dual redundancy instead, depicted as option A in Fig. 2. The secondsensor serves as a standby, running in parallel with the primary sensor, so thatat least one of the components delivers a signal, should the other one fail. Dualredundancy improves reliability compared to the initial model and does not havethe high cost of triple redundancy.

Fig. 2. Simplified brake-by-wire system with (A) double redundancy and (B) tripleredundancy

5.2 Representation of Design Decisions with Tiger EMF

Tiger EMF [2] is a model transformation framework that is based on triplegraph grammars. It supports in-place transformations. A transformation rule isspecified using a pattern to be matched in the source model (left-hand side),and a pattern to be created in the target model (right-hand side). Between ele-ments from the left-hand side and elements from the right-hand side a mapping-relation, the third graph, can be specified, which is expressed with correspondingnumbers in the left-hand side and right-hand side.

The context of the design decision corresponds to the left-hand side of themodel transformation, depicted in Fig. 3.


19/113


Fig. 3. Left-hand side of the design decision for double and triple redundancy

The outcome of the design decision corresponds to the right-hand side, de-picted in Fig. 4. The negative application condition specifies that the transforma-tion is applied at most once, and due to space constraints it is not included here.The transformation creates an architecture with triple redundancy as depictedin Fig. 2 B.

Fig. 4. Right-hand side of the design decision for triple redundancy

We can use existing tools for reliability and cost analysis on this architec-ture. Even though the reliability of the system is improved, the component costsfor triple redundancy with voter are high. We might want to explore an alter-native design decision for double redundancy. Based on the initial architecture(see Fig. 1) and the alternative design decision, we can generate an alternativearchitecture.

We create an alternative design decision using a new model transformation.The right-hand side of the new model transformation is depicted in Fig. 5, theleft-hand side is the same as for the previous model transformation, as the deci-sion is applied in the same context. After executing the model transformation,an architecture with double redundancy is created (see Fig. 2 A).


20/113

8 Matthias Biehl

Fig. 5. Right-hand side of the design decision for double redundancy

As we have seen in this example, the design space can be explored withoutmuch effort by reusing the design decisions and modifying them slightly. Designdecisions solving the same issue differently, i.e. alternative design decisions (ormodel transformations), have the same context (or left-hand side) and a differentoutcome.

Moreover, we can change the design decisions to be applicable in a differentcontext. The design decision for double redundancy (Fig. 5) can be applied tothe WheelSpeedSensor instead, by changing the string PedalSensor to Wheel-SpeedSensor in the corresponding left-hand side (Fig. 3). This can be generalizedby introducing parameters into the transformation.

5.3 Representation of Design Decisions with ATL

To show that design decision can be represented with different model transfor-mation languages, we created a second example of the design decision for tripleredundancy and implemented it in ATL. The ATLAS Transformation Language(ATL) [8] is a hybrid model transformation language, supporting both declara-tive and imperative programming styles. An ATL transformation is composed ofrules that describe how to create and initialize the elements of the target mod-els. To support in-place transformations, ATL has to be configured to run ina special execution mode, the refining mode. Several practical limitation of thecurrent ATL refining mode exist, such as missing foreach-loops and lazy rules.Due to space constraints we have not included the transformation source code.

6 Conclusion

We proposed model transformation as a representation for design decisions ful-filling the identified objectives for design decisions in model driven development.We call this representation executable design decisions, since an engine can auto-matically create the changed model based on this design decision representation.


21/113


Design decisions can be captured based on two snapshots of the model: (1)the model before the change and (2) the model after the change. The model

transformation representing the design decision can be computed. The architectdoes not have to code the transformation manually.

In a case study we have shown that it is feasible to represent executabledesign decisions using different model transformation languages. We noticed dif-ferences between the languages. Creating the model transformation graphically,such as in Tiger EMF, resembles modeling the architecture directly. Textualmodel transformation descriptions such as those by ATL are verbose and possi-bly harder to understand.

The sequence of design decisions captures the evolution of the model. Anyintermediate version of the model can be reconstructed by replaying the designdecision up to that point. This allows the designer to try out several alternativedecisions and inspect the produced architecture. At the same time the designdecisions are documented and linked to the model.

6.1 Future Work

There is a need for a large industrial case study. Such a case study can beused to find out if design decisions provide an appropriate granularity for modelevolution in practice and with more complex refinements.

The proposed representation for design decisions does not presuppose thatthe documented decision is actually realized. However, we would need to providean additional infrastructure for storing design decisions that were rejected.

When the design decision is captured explicitly and to some degree of for-mality, the decision itself can become the subject of analysis. For example therelation between different design decisions, such as dependency relations, can

be calculated automatically. The model transformation provides a precondition(the left-hand side) and a postcondition (the right-hand side) that can be usedfor deducing dependencies.

Acknowledgements

This work has been partially funded by the ARTEMIS projects CESAR andiFEST.

References

1. Matthias Biehl and Martin Torngren. An executable design decision representa-

tion using model transformations. In 36th EUROMICRO Conference on SoftwareEngineering and Advanced Applications (SEAA 2010), September 2010.

2. E. Biermann, K. Ehrig, C. Kohler, G. Kuhns, G. Taentzer, and E. Weiss. Graph-ical definition of in-place transformations in the Eclipse Modeling Framework. InMODELS 2006, volume 4199, pages 425439, 2006.

3. Jan Bosch. Software architecture: The next step. Software Architecture, 3047:194199199, 2004.


22/113

10 Matthias Biehl

4. J. E. Burge and D. C. Brown. An integrated approach for software design checkingusing rationale. In Proc. Design Computing and Cognition Conference, Cambridge,

MA, 2004.5. Philippe Cuenot, Patrik Frey, Rolf Johansson, Henrik Lonn, Yiannis Papadopoulos,Mark-Oliver Reiser, Anders Sandberg, David Servat, Ramin T. Kolagari, MartinTorngren, and Matthias Weber. The east-adl architecture description language forautomotive embedded software. Model-Based Engineering of Embedded Real-TimeSystems, 2010.

6. Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, October 1976.7. Anton Jansen, Jan van der Ven, Paris Avgeriou, and Dieter K. Hammer. Tool

support for architectural decisions. Software Architecture, Working IEEE/IFIPConference on, 0:4+, 2007.

8. F. Jouault, F. Allilaire, J. Bezivin, and I. Kurtev. ATL: a model transformationtool. Science of Computer Programming, 72:3139, June 2008.

9. Philippe Kruchten. An ontology of architectural design decisions in software in-tensive systems. In 2nd Groningen Workshop Software Variability, pages 5461,

October 2004.10. Philippe Kruchten, Rafael Capilla, and Juan C. Duenas. The decision views role

in software architecture practice. IEEE Softw., 26(2):3642, 2009.11. W. Kunz and H. W. J. Rittel. Issues as elements of information systems. Technical

report, Univ. Calif. at Berkeley, 1970.12. Jintae Lee. Decision representation language (DRL) and its support environment.

Technical report, MIT Artificial Intelligence Laboratory, August 1989.13. Peter Liggesmeyer and Mario Trapp. Trends in embedded software engineering.

Software, IEEE, 26(3):1925, April 2009.14. Allan MacLean, Richard M. Young, Victoria M. E. Bellotti, and Thomas P.

Moran. Questions, options, and criteria: elements of design space analysis. Human-Computer Interaction, 6(3):53105, 1996.

15. R. McCall. Phi: a conceptual foundation for design hypermedia. Design Studies,

12(1):3041, January 1991.16. David L. Parnas. Software aging. In ICSE, pages 279287, 1994.17. D. Perry and A. Wolf. Foundations for the study of software architecture. ACM

SIGSOFT Software Engineering Notes, 17(4):4052, October 1992.18. Antony Tang, Muhammad A. Babar, Ian Gorton, and Jun Han. A survey of

architecture design rationale. J. Syst. Softw., 79(12):17921804, December 2006.19. Antony Tang, Yan Jin, and Jun Han. A rationale-based architecture model for

design traceability and reasoning. Journal of Systems and Software, 80(6):918934, June 2007.

20. John B. Tran, Michael W. Godfrey, Eric H. S. Lee, and Richard C. Holt. Architec-tural repair of open source software. In In Proceedings of International Workshopon Program Comprehension, pages 4859, 2000.

21. Jeff Tyree and Art Akerman. Architecture decisions: Demystifying architecture.IEEE Software, 22(2):1927, 2005.

22. Niklaus Wirth. Program development by stepwise refinement. Communications ofthe ACM, 14(4):221227, April 1971.

23. Rob Wojcik, Felix Bachmann, Len Bass, Paul C. Clements, Paulo Merson, RobertNord, and William G. Wood. Attribute-driven design (add), version 2.0. Technicalreport, Software Engineering Institute, November 2006.


23/113

Decoupling Operation-Based Merging from

Model Change Recording

Stephen C. Barrett, Patrice Chalin, and Greg Butler

Concordia University, Montreal, Quebec, Canada{ste barr,chalin,gregb}@encs.concordia.ca

Abstract. Two general approaches to the merging of models exist:state-based, and operation or history-based. Naturally, using one overthe other involves trade-offs. Up to now, a major drawback of the latterapproach has been overly tight coupling between the tool performing themerge, and the recorder tracking the changes made to the models.

We break this coupling through the use of an abstraction layer, anda tool-independent means of representing model changes: conceivablyallowing even cross-tool models to be successfully merged. Further, thedesign does not preclude the application of state-based methods. Thedecoupling architecture and techniques are described in the context oftheir implementation in our model merging tool, Mirador.

Keywords: change recorder decoupling, change metamodel, operation-based merging, state-based merging, model merging, MDD, Mirador

1 Introduction

The importance of model merging to model-driven development (MDD) can

be gauged by the literature, which points to a great need for research into, anddevelopment of tools that synchronize and merge models [1]. And by the numberof conferences and workshops dedicated to the closely related topics of softwareversioning, model comparison, model differencing, model evolution, and the like.Though accepting of its importance, the community is divided over how to bestaccomplish model merging. Where one camp maintains that an approach basedon model state will be most effective, the other insists that correctness requiresmaking use of change operations recorded over the course of a modeling session.

As with many dichotomies, the approaches are less contradictory than firstappears. This was brought sharply into focus for us during redesign of our modelmerging tool Mirador. Mirador features the use of multiple comparison strategiesfor establishing model element correspondence, and table-directed merging on alocal level. And Mirador is operation-based. Recently, we turned out attention

to what is the most frequently cited objection to operation-based merging: thetight coupling between change recording mechanism and merging tool.

In Mirador we have successfully decoupled the two by: (1) abstracting awaydifferences between change recorder outputs; (2) reconstructing modified modelsfrom the change logs; and (3) incorporating change history into the models


24/113


25/113

merging: has information that can resolve the add-delete problem and someconflicts, and requires tight coupling with the modeling tool/change recorder.

2.2 Representing Model Differences

Cicchetti, et al. [3] have proposed capturing the differences between models asa first class artifact through the use of a difference metamodel (MMD) thatextends some given metamodel (MM). The MMD (left side of Fig. 2) stipulatesthe derivation of three new types for each model element type of the MM. Withthis extended metamodel in place, modifying a model conforming to MM resultsin a new version conforming to MM and MMD that represents the initial andfinal states of the model undergoing modification. The Ecore model fragment onthe right side of Fig. 2 illustrates its usage. The appearance of MMD elementsin the fragment indicate that the model has changed, specifically: class c4 andattribute a1 have been added, a unidirectional relationship r2 inserted between

c3 and c4, and the association r1 between c1 (now c3) and c2 removed.

Added

Deleted

Changed

ModelElement

DifferenceMetamodel

(MMD)

updated.

induces

.

c4: AddedEClassname = HtmlDocElem

is_abstract = true

c2: EClassname = HtmlList

c3: EClassname = HtmlDoc

r2: AddedEReferencename = elements

is_compostion = true

r1: DeletedEReferencename = elements

is_compostion = true

a1: AddedEAttributename = type

attributes.

updated.

c1: ChangedEClassname = HtmlDoc

eReferences.

eReferences.

eReferenceType.

eReferenceType

Fig. 2. Difference metamodel and a difference model fragment.

The initial model consists of all the Changed and Deleted MMD elements(c1, r1 ), and any MM elements that have not been updated ( c2). While thefinal model consists of all MM elements (c2, c3), plus the Added MMD ele-ments (c4, r2, a1 ). Everything in the final model is reachable from the modelsroot node (not shown). The direction of the links between MM and MMD el-ements however, make portions of the initial model unreachable, necessitatingthat references to them be maintained elsewhere. Thus tools that are unawareof the MMD see only the final model, while MMD aware tools, provided theyare supplied with this reference list, see both.

We note that since the difference metamodel only captures the end states of

a modeling session, it cannot by itself support operation-based merging. Also,the difference representation reveals what has changed, but not in precisely whatway. This information must be extracted from the model by performing a diffbetween the final version of an element and its initial version. Other things tonote are that: adding a new element X inserts a subclassed AddedX object


26/113

into the final model; deleting an element Y removes it from the final model, butleaves a ghost DeletedY in the initial model; adding, deleting, or altering acontained element changes its container (e.g., c1 due to a1 ); and meta-objectnames are for human use, being assigned as new objects are created.

3 The Mirador Model Merger

Mirador is an operation-based merging tool being developed at Concordia Uni-versity. Written in Java, it can run stand-alone, or as a Fujaba plug-in [4]. It usesEcore to represent changes that have been made to the models to be merged.

3.1 User Interface

Users interact with the tool through three panels. The first panel parses the

model change logs. A file containing model element pairings established in aearlier merge session may also be read in. The second panel is concerned withmatching the elements of one model with those of the other, either interactivelyor automatically. Merging based on these pairings, takes place in the last panel.

Conflict identification and merging require a mapping of an element in onemodel to its corresponding entity in the other. In contrast to most tools whichexploit only one matching approach, Mirador makes use of similarity measuresobtained from multiple strategies, as well as an overall score computed with aweighted distance function [5]. Up to eight strategieswhich may be externallysuppliedcan be selectively loaded at start-up time. A partial screenshot of theElement Matching Panel is shown in Fig. 3. Seen running across the top of theGUI are fields for altering the weights assigned to each of the loaded evaluators.

Fig. 3. Mirador displaying similarity measures after comparing model elements.


27/113

Trees are used to display the left and right versions of the model. This em-phasizes element ownership and containment, and has the virtue of simplicity.It also does not conflate changes to the model with changes to its view. A com-mon condition that poses several traps for the unwary [6]. A nodes details aregiven in the table beneath its tree. Shown here are candidate matches for theselected item, that is, all elements of the same kind found in the other model,ranked by similarity. Grayed out elements have been paired. A pair can be brokenup with the Unmatch button. Likewise, available elements can be paired withMatch. Elements can be automatically matched by similarity, with the Thres-hold field specifying the minimum similarity score: Any elements not alreadymatched when the user advances to the Model Merge Panel will be paired withtheir highest ranked and available candidate that is at, or above the threshold.

3.2 Tool Architecture

Miradors components and inter-process data flow are informally documented in

the diagram of Fig. 4. There are three subsystems, each corresponding roughlyto a page of the Mirador wizard. Input in the form of raw model change logscomes from the tracking recorders at the far left. This input stream along withthe abstraction layer (MAL) constitute the input subsystem. The comparisonsubsystem is composed of a comparison unit and an assortment of similarityevaluators. It uses a visualization component which will eventually incorporatethe graphic facilities of EMF Compare [7]. The merge subsystem uses planes oflocal change operations to analyze the merge, and decision tables to drive it.

Eclipse /Recorder

MiradorAbstraction

Layerleftright

merged

MiradorComparison

Unit

MiradorMerging

Unit

Mirador

Visualizationmatch

candidates_

conflicts/

resolution_

matches

merged.model

l

Fujaba /Coobra

left.ctr

right.ctr

merged.ctr

NameEvaluator

SimilarityEvaluatorleft.model

right.model

left.model

right.model

measures

ECLEvaluator

IdEvaluator

ChangePlane

* DecisionTable

*

Fig. 4. Mirador architecture.

4 Change Record Isolation

There are two related, but slightly different aspects to decoupling Mirador fromthe change tracking mechanism, to be take up in this and the next section. Thefirst has to do with deciphering the recorder-specific change logs, and the secondwith how model changes are represented to downstream processes.


28/113

4.1 Common Change Record Objects

At present, Mirador is limited to working with Fujaba models. Because it is inreality a historical trace of changes, a Fujaba model possesses the characteristicscommon to other traces, and as such can serve as an exemplar: Typically, changesare logged in a flat file as single-line records, each made up of fields delimited bya special character, with records grouped into transactions. Change logs differprimarily in their change record formats and transaction layouts. To neutralizethese differences Mirador adopts a common change record structure.

The raw change records of a particular change recorder are converted intoobjects of this common structure in passing through that recorders dedicatedMAL interface. The recorder-specific Fujaba class hierarchy can be seen in Fig. 5alongside the recorder-neutral Mirador hierarchy, with ellipses alluding to similarhierarchies needed to support other change recorders. Providing tool-specifichierarchies makes for greater modularity, and simplifies debugging.

FujabaTransactionRecord

FujabaChangeRecord

ChangeRecord

ChangeTransaction

changes

FujabaRecordFactory

RecordFactory

ChangeRepository

record-

MiradorRecordFactory

FujabaRecord

MiradorRecord

FujabaTransaction

MiradorTransaction

MiradorRepository

MiradorCreateRecord

MiradorTransactionRecord

lf_tx_actions

rt_tx_actions

FujabaRepository

FujabaHeaderRecord

FujabaCommentRecord

MiradorDestroyRecord

MiradorAlter

Record

Fig. 5. Tool-specific change record hierarchy shadowed by a neutral hierarchy.

Each set of tool-specific leaves of the ChangeRecord sub-hierarchy is re-placed by a set of Mirador classes that represent only those features of interestfor merging. The ChangeRepository class for a tool reads the logs of its changerecorder, delegates record creation to its factory, and gathers changes into leftand right transactions. A ChangeTransaction serves to bundle the changerecords together at the model element level; the common version doing so in arecorder-independent fashion.

During record gathering, the repository will eliminate any redundant oper-ations it recognizes. For instance, upon creation, an element may be given atemporary name only to be replaced by a user supplied name at a later point

in the same transaction. The temporary operation can be safely discarded. Thecommon repository also acts as a container for the Ecore models that will beeventually reconstructed from the change operations.

Thus two steps have been taken towards decoupling: the first isolates thetextual nature of change log records, and the second removes dependencies on


29/113

recorder-specific objects. Though adequate for internal use, having to accommo-date the Mirador replacement objects places a burden on external actors. Still,this is a great improvement over having to deal with multiple recorder formats.

4.2 Reconstruction of Changed Model Versions

To be truly independent of recorder idiosyncrasies, we need to work with modelsrather than the object-oriented stand-ins for recorded changes described above.In this spirit Mirador reconstructs Ecore versions of the left and right modelsby executing the operations of the respective change logs.

The changes of a log are executed navely, with little attention paid to under-lying semantics. Mirador navigates the changes from the models root on down,creating and cobbling elements together as it goes, employing the Ecore API ina fairly straight forward manner. The ease with which existing elements may bemanipulated and nested is the main reason behind our selection of Ecore overUML2. The result is an Ecore model structured in terms of containment, thatis to say, as parents and children.

At the time of this writing, Mirador knows of packages, classes, operations,attributes, and bidirectional associations. Of these, only associations raise anydifficulties. Many modeling tools considers associations to be first class entities,and use a classifier each for the association and its ends. Ecore on the otherhand, models a bidirectional association and its roles with two references. Theappearance of an association in the model then, requires a translation of threemetamodel objects and their properties into two. This is the bidirectional case;a unidirectional association is translated into a single reference.

Having full reconstructions of the left and right models enables downstreamprocesses to perform state-based analyses and manipulations. Any operation-based work undertaken at this point however, would involve using the change

operation objects as saved in the MiradorRepository. To achieve total decou-pling, these change operations must be somehow hung off the elements of themodels that they change. The next section proposes a means for doing just that.

5 Capturing Model Evolution

The two Ecore models outputted from the abstraction layer are sufficient for thecomparison subsystem to accomplish its goal, but may not satisfy all similarityevaluators. For example, the by history evaluator scans the change operationsfor clues that could aid with matching, and the by ECL evaluator runs arbi-trary scripts of the Epsilon Comparison Language [8] which could conceivablyattempt to examine the change history.

While model comparison in Mirador has a kind ofsoft dependency on change

history, its merging has a hard dependency. These needs can be fulfilled in a toolindependent manner by making the changes part of the models to be merged.We use the metamodel of Cicchetti, et al. [3] for this purpose, but as their workis intended to model differences (see Section 2.2) and not change sequences, wehave extended it as explained in the next subsection.


30/113

5.1 The Changed Metaclass

When reconstructing the models from their change logs, Mirador wraps each

Ecore element it creates in an EcoreWrapper. The wrappers provide conve-niences like element ID and ancestor details that we would rather not pollutethe model with. They act as scaffolding; to be removed once the models havebeen merged. They also make it possible to extend Ecore with the MMD withouthaving to modify Ecore itself, and to maintain links to all MMD elements.

The iconified model at the top right of Fig. 6aan abstract class ATypecontained in package root pkgis represented by the wrapped Ecore metaclassesbeside it. The icons of 6b show this model evolving through two changes: theclass being renamed to LType, and then being made concrete. In the originaldifference metamodel these changes result in one ChangedEClass object beingcreated with an updated reference to the modified object w2. In our extension ofthe MMD there are two ChangedEClass objects, one for each change, alongwith linkage in the opposite direction by which they can be reached from w2.

a)

root_pkg

AType

parent

children

updated

updated

changes {ordered}-

root_pkg

AType

root_pkg

LType

root_pkg

LType

cc1 : ChangedEClass

captured : EClassImpl

name = "AType"abstract = true

cc2 : ChangedEClass

captured : EClassImpl

name = "LType"abstract = true

b)

w1 : EcoreWrapper

element_id = "#1"

class_name = "EPackage"

element : EPackageImpl

name = "root_pkg"

parent

children

w1 : EcoreWrapper

element_id = "#1"

class_name = "EPackage"

element : EPackageImpl

name = "root_pkg"

w2 : EcoreWrapper

element_id = "#2"

class_name = "EClass"

element : EClassImpl

name = "AType"

abstract = true

w2 : EcoreWrapper

element_id = "#2"

class_name = "EClass"

element : EClassImpl

name = "LType"

abstract = false

Fig. 6. Representation of a model initially (a), and after two changes (b).

Rather than store the original state of the updated element in the Changedmetaclass directly, we save it as a nested captured object. Admittedly, not asclean as the original design that replicated the MM element with an added up-dated reference. It is simply a concession to implementation, where to transcribean Ecore object into another is quite difficult, but to make a copy is easy.

At this point Mirador has been completely decoupled from change recorders.In fact, any change history dependent tool that can navigate an Ecore modelcould make use of the abstracted output to decouple itself in the same way.

6 Related Work

State-based merging relies on static models, and is exemplified by Unison [9] andRational Rose, where operation-based tools like IceCube [10] analyze dynamictraces of replica changes. Lippe and Oosterom [11] first put forth operation-based


31/113

merging for managing changes to object-oriented databases. They described amerge as a weave of primitives in a transformation grid, related non-commutatingoperations to conflicts, and proposed three algorithms for detection. In Miradorwe have reoriented their grid, and added a third dimension for matching strate-gies [12]. Renewed interest in the approach is typified by the works of Koegel,et al. [13], and Schmidt, et al. [14] who argue for transaction based merging.

Properly matching model elements is vital to successful merging, and ap-proaches to it have been varied. Lippe and Oosterom did not concern themselveswith entity matching. Others like Pottinger and Bernstein take it as a given [15],and many tools insist on unique identifiers to do any useful work [6]. More ro-bust and flexible ideas are offered by Xing and Stroulia [16] who match basedon name and structural similarity, or Kolovos [8] who furnishes a general com-parison language. Mirador draws from these and others, to offer an assortmentof strategies for comparing and matching. Treude, et al. [17] show how to reducethe inherent O(n2) complexity of model element comparison to O(n log n).

Cicchetti, Di Ruscio, and Pierantonio [3] describe a metamodel independentway of representing model differences suitable for state-based merging. In Mi-rador we have extended their difference metamodel to track model evolution,making it applicable to operation-based merging. Additionally, we have madedesign changes to facilitate constructing the difference model in Ecore.

7 Conclusion and Future Work

This paper has presented techniques for erasing the dependency that operation-based model merging has on the tools used for recording changes made to models.We also briefly presented our own merging tool Mirador, which incorporates thedescribed techniques, along with novel facilities for matching model elementsbased on multiple similarity measures.

Much work remains to be done on Mirador. Currently it assumes that thetraces passed in to it are complete; that the entire histories of the models inquestion are contained within the change operations of the logs. This assumptionneeds to be removed. As part of migrating Mirador to Eclipse, an interface toEclipse-Change Recorder logs is being added to the abstraction layer. This movewill make the visualization capabilities of EMF Compare available to us.

Our work has driven home an important observation worth pursuing: Stateis always available in an operation-based approach. A full trace contains theancestor model, the final model, and every model in between. Accordingly, theeither or question posed by the perceived dualism of state vs. operation basedshould be replaced with a question of more or less. That is, Is the state-basedapproach good enough for our needs? or Is it worth the extra space, computa-tional (and yes, programming) effort to follow an operation-based approach?

References

1. Schmidt, D.C.: Guest editors introduction: Model-driven engineering. IEEE Com-put. 39(2) (Feb 2006) 2531


32/113

2. Mens, T.: A state-of-the-art survey on software merging. IEEE Trans. on Softw.Eng. 28(5) (May 2002) 449462

3. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: A metamodel independent approach

to difference representation. Journal of Object Technology 6(9) (Oct 2007) 165185http://www.jot.fm/contents/issue_2007_10/paper9.html.

4. Fujaba. Website of the Fujaba Tool Suite project (Nov 2009) http://www.fujaba.de/home.html.

5. Barrett, S., Butler, G., Chalin, P.: Mirador: a synthesis of model matching strate-gies. In: IWMCP 10: Internat. Workshop on Model Comparison in Practice. (Jul2010)

6. Barrett, S., Chalin, P., Butler, G.: Model merging falls short of software engineeringneeds. In: MoDSE 08: Internat. Workshop on Model-Driven Software Evolution.(Apr 2008)

7. EMF Compare. Website of the EMF Compare subproject of the EclipseEMFT project (May 2010) http://www.eclipse.org/modeling/emft/?project=compare#compare.

8. Kolovos, D.S.: Establishing correspondences between models with the epsilon com-

parison language. In: ECMDA-FA 09: 5th European Conf. on Model Driven Ar-chitecture - Foundations and Applications, Berlin, Germany, Springer-Verlag (Jun2009) 146157

9. Pierce, B.C., Vouillon, J.: Whats in Unison? A formal specification and referenceimplementation of a file synchronizer. Technical Report MS-CIS-03-36, Universityof Pennsylvania, Philadelphia, PA, USA (Feb 2004) http://www.cis.upenn.edu/~bcpierce/papers/unisonspec.pdf.

10. Kermarrec, A.M., Rowstron, A., Shapiro, M., Druschel, P.: The IceCube approachto the reconciliation of divergent replicas. In: PODC 01: 20th Annual ACM Sym-pos. on Principles of Distributed Computing, New York, NY, USA, ACM (Aug2001) 210218

11. Lippe, E., van Oosterom, N.: Operation-based merging. ACM SIGSOFT Softw.Eng. Notes 17(5) (Dec 1992) 7887

12. Barrett, S., Chalin, P., Butler, G.: Towards automated model merging using anoperation-based metamodel. Technical Report DSRG-2009-02, Concordia Uni-versity, Montreal, QC, Canada (May 2009) http://users.encs.concordia.ca/~chalin/papers/BarrettEtAl09-TR-2009-02.pdf.

13. Koegel, M., Helming, J., Seyboth, S.: Operation-based conflict detection and res-olution. In: CVSM 09: Workshop on Comparison and Versioning of SoftwareModels, Los Alamitos, CA, USA, IEEE Computer Society (May 2009) 4348

14. Schmidt, M., Wenzel, S., Kehrer, T., Kelter, U.: History-based merging of models.In: CVSM 09: Internat. Workshop on Comparison and Versioning of SoftwareModels, Los Alamitos, CA, USA, IEEE Computer Society (May 2009) 1318

15. Pottinger, R.A., Bernstein, P.A.: Merging models based on given correspondences.In: VLDB 03: 29th Internat. Conf. on Very Large Data Bases. (Sep 2003) 862873

16. Xing, Z., Stroulia, E.: UMLDiff: an algorithm for object-oriented design differ-encing. In: ASE 05: 20th IEEE/ACM Internat. Conf. on Automated SoftwareEngineering, New York, NY, USA, ACM (Nov 2005) 5465

17. Treude, C., Berlik, S., Wenzel, S., Kelter, U.: Difference computation of largemodels. In: ESEC-FSE 07: 6th joint meeting of the European Software EngineeringConference and the ACM SIGSOFT Symposium on the Foundations of SoftwareEngineering, New York, NY, USA, ACM (Sep 2007) 295304


33/113

Towards Semantics-Preserving Model Migration

Markus Herrmannsdoerfer and Maximilian Koegel

Institut fur Informatik, Technische Universitat MunchenBoltzmannstr. 3, 85748 Garching b. Munchen, Germany

{herrmama, koegel}@in.tum.de

Abstract. Like other software artifacts, modeling languages and thustheir metamodels are subject to change. When a metamodel is changed,existing models may no longer conform to it. To avoid loss of information,the existing models need to be migrated. Manual migration is tedious anderror-prone, and thus model migration needs to be automated. However,

building an automated model migration is a difficult endeavor, as it needsto preserve the meaning of a possibly unknown number of models. In thispaper, we extend our operation-based approach to automate model mi-gration by a means to ensure semantics preservation. A coupled operationnot only adapts the metamodel and provides the appropriate model mi-gration, but also adapts the semantics definition. Semantics preservationis thus ensured constructively by defining appropriate couples of seman-tics adaptation and model migration. We showcase the approach usingthe well-known Petri net example evolution.

1 Introduction

Due to evolving requirements, modeling languages are subject to evolution [1].A modeling language is evolved by first adapting its metamodel to the evolvedrequirements. When the metamodel is adapted, dependent artifacts like e. g.editors and interpreters may need to be co-adapted. Most importantly, existingmodels may no longer conform to the adapted metamodel. To be able to use theexisting models with the evolved modeling language, they have to be migratedto conform to the adapted metamodel. Manual migration is tedious and error-prone, and thus model migration needs to be automated [2].

To automate model migration, we follow an operation-based approach [3]:When adapting the metamodel, the model migration is recorded as a sequence ofcoupled operations in an explicit history model [4]. A coupled operation encapsu-lates both the metamodel adaptation as well as the reconciling model migration.Model migration can be further automated by reusing recurring combinations of

metamodel adaptation and model migration. Through a number of case studies,we have shown that most of the model migration in practice can be coveredby reusable coupled operations [2, 3, 5]. The model migration needs to be de-fined manually only in case there is no appropriate reusable coupled operationavailable. We have implemented this operation-based approach for the Eclipse


34/113

Modeling Framework (EMF) [6] in a tool called COPE (COuPled Evolution ofmetamodels and models)1.

In addition to automating the model migration, it has to be ensured thatthe model migration preserves the meaning of the existing models. If the mean-ing is not preserved, important information may be lost during the automatedmodel migration. This problem is further aggravated by the fact that we needto migrate a possibly unknown number of models. Of course, we can only talkabout semantics preservation, in case the semantics of a modeling language isexplicitely defined. In practice, the semantics of a modeling language is usuallydefined by means of a simulator or code generator.

In this paper, we extend our operation-based approach by a means to en-sure semantics preservation. A reusable coupled operation not only adapts themetamodel and provides the appropriate model migration, but also adapts thesemantics definition. Semantics preservation is thus ensured constructively bydefining appropriate couples of semantics adaptation and model migration. We

showcase the approach using the well-known Petri net example evolution [7]. Forcustom coupled operations which require manual specification of the model mi-gration, the semantics definition also has to be adapted manually. Since customcoupled operations are rather rare in practice according to our case studies [2,3, 5], it is sufficient to manually prove semantics preservation in these cases.

The paper is structured as follows: Sec. 2 presents how we assume that boththe syntax and semantics of a modeling language are defined. Sec. 3 introducesour operation-based approach to build a semantics-preserving model migration.Sec. 4 demonstrates the approach using the well-known Petri net example evo-lution. Sec. 5 discusses related work, and Sec. 6 concludes the paper.

2 Definition of Modeling Languages

Modeling Languages. Before we can characterize the evolution of a modelinglanguage, we have to formally define our understanding of a modeling language.

Definition 1 (Modeling Language). A modeling language L = (A, S) is atuple of abstract syntaxA and semantics S.

Usually, modeling languages also define a concrete syntax to represent models ina human-readable manner. However, the concrete syntax which may also haveto be considered for modeling language evolution is out of this papers scope.Here, we assume that the abstract representation of a model contains all theinformation necessary to determine its semantics.

Definition 2 (Abstract Syntax). The abstract syntax defines the (possiblyinfinite) subset A = {m1, m2, . . .} M of the models that are syntacticallycorrect. M defines the set of all possible models which are essentially labeled andattributed graphs.

1 see COPE web site, http://cope.in.tum.de


35/113


36/113

Net.run(Interaction i):

reset()

ts = getActivatedTransitions()

while(!ts.isEmpty()) {if(ts.size() == 1) ts.get(0).fire()else i.choose(ts).fire()

ts = getActivatedTransitions()

}

Interaction.choose(List ts):

...

Net.reset():

places.each{p > p.reset()}

Net.getActivatedTransitions():

List

return transitions.collect{t >t.isActivated()}

Transition.isActivated(): boolean

return src.every{p > p.isActivated()}

Transition.fire():

src.each{p > p.decrement()}effect.execute()

dst.each{p > p.increment()}

Place.reset():

current = initial

Place.isActivated(): boolean

return current >= 1

Place.decrement():

current = current 1

Place.increment():

current = current + 1

Fig. 2. Semantics definition of the Petri net modeling language version 1.

Petri Nets consist of places and transitions. A Place has a number of to-kens (current) which are reset to the number ofinitial tokens when the netis started. A Transition transfers tokens from src to dst places. A transitionisActivated if every src place has at least one token. If multiple transitions areactivated at the same time, user Interaction is required to choose one. Whena transition fires, the tokens of the src places are decremented, its effectis executed and the tokens of the dst places are incremented. The semanticsdefinition thus map

me 2010 preliminary proceedings

Documents