metamodel evolution in the context of a mof-based … · 2013. 7. 16. · modeling infrastructure...

Diplomarbeit

Metamodel Evolution in the Context of a MOF-Based

Metamodeling Infrastructure

eingereicht am 30.09.2008beim Institut für Theoretische Informatik

der Universität Karlsruhe (TH)

Dozent: Prof. Dr. P. H. Schmitt

Betreuer: Dipl.-Ing. Boris Gruschko, SAP AG

Erik BurgerIm Bauernbrunnen 874821 MosbachMatrikelnummer: 1146018E-Mail: [email protected]

Versicherung der selbständigen Erarbeitung

Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und weder ganz oder inTeilen als Prüfungsleistung vorgelegt und keine anderen als die angegebenen Hilfsmittel benutzt habe.Sämtliche Stellen der Arbeit, die benutzten Werken im Wortlaut oder dem Sinn nach entnommen sind,habe ich durch Quellenangaben kenntlich gemacht. Dies gilt auch für Zeichnungen, Skizzen, bildlicheDarstellungen und dergleichen sowie für Quellen aus dem Internet.

Ort, Datum:

Unterschrift:

Zuletzt geändert am 27.9.2008

CONTENTS i

Contents

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Background 2

2.1 Model-Driven Architecture (MDA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Meta-Object Facility (MOF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 JMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 MOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Changes in MOF-Based Metamodels 8

3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Determination of Overall Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 MOIN-Specific Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Query Visibility of Changes 21

4.1 Changes Without Effects on Queries and Result Sets . . . . . . . . . . . . . . . . . . . . . 214.2 Changes Affecting the Result Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Changes Making the Query Invalid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 JMI Interfaces 24

5.1 JMI Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 JMI Transformation Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3 Changes in JMI Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Assignment of MOF Changes to JMI Changes . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 Example 38

6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2 Severities regarding M1 instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.3 Severities regarding Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.4 Transformation into JMI model instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.5 Severities regarding JMI interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Related Work 44

7.1 MOF repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.2 Metamodel Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8 Conclusion 46

Bibliography 47

Glossary 49

Appendices

A Change Severities Overview 50

CONTENTS ii

B OCL Constraints 53

B.1 Change Metamodel Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.2 Severity Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.3 JMI Metamodel Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59B.4 Helper Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

LIST OF FIGURES iii

List of Figures

1 The MOF abstraction layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 The MOF metamodel, simplified view (from [Het06]) . . . . . . . . . . . . . . . . . . . . . 33 Generated Java inheritance patterns (from [JMI02]) . . . . . . . . . . . . . . . . . . . . . 54 The MOF change metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Example: Deletion of a class makes M1 data invalid . . . . . . . . . . . . . . . . . . . . . 106 Example: Association cardinality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Example: Composition cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Example: Containment change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Example: Deletion of generalization leads to invalid M1 data . . . . . . . . . . . . . . . . 1610 Example: Type change on an association end . . . . . . . . . . . . . . . . . . . . . . . . . 1711 Example: Change in type hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812 Example: Inversion of type hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913 Query visibility: Adding generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2114 Query visibility: Deleting generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2215 Query visibility: Deleting generalization with association . . . . . . . . . . . . . . . . . . . 2316 The JMI metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2617 The JMI primitive type package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2718 The JMI reflective package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719 MOF to JMI transformation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2820 The transformation metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3221 Example metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3822 Change steps as Change Metamodel instances . . . . . . . . . . . . . . . . . . . . . . . . . 3823 Example metamodel, Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4124 Example metamodel, Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4225 JMI interfaces of example metamodel, Version 2 . . . . . . . . . . . . . . . . . . . . . . . 43

Abstract

The evolution of software systems can produce incompatibilities with existing data and appli-cations. For this reason, changes have to be well-planned, and developers should know the impactof changes on a software system. This also affects the branch of model-driven development, wherechanges occur as modification of the metamodels that the system is based on. Models that areinstantiated from an earlier metamodel version may not be valid instances if the new version of ametamodel. Also, changes in the interface definition may require adaptations to the modeling tools.

In this thesis, the impact of meta-model changes is evaluated for the modeling standards MetaObject Facility (MOF) and the interface definition Java Metadata Interface (JMI), based on theModeling Infrastructure (MOIN) project at SAP, which includes a MOF- based repository and im-plements the JMI standard.

For the formalisation of changes to MOF-bases metamodels, a Change Metamodel is introducedto describe the transformation of one version of a metamodel to another by the means of modelingitself. The changes are then classifed by their impact on the compatibility of existing model data andthe generated JMI interfaces.

The description techniques and change classifications presented in this thesis can be used toimplement a mechanism that allows metamodel editors to estimate the impact of metamodel changeswith the help of modeling tools that can adapt existing data semi-automatically.

Zusammenfassung

Die Weiterentwicklung von Software-Systemen kann zu Inkompatibilitäten mit bestehenden Datenund Anwendungen führen. Daher sollten die dabei vollzogenen Änderungen gründlich geplant werden,und Entwickler sollten sich der Folgen von Änderungen an einem Software-System bewusst sein. Diesbetrifft auch modellgetriebene Entwicklung, bei der Änderungen in Form von Modifikationen an denzugrundeliegenden Metamodellen auftreten. Bestehende Modelldaten, die aus einer früheren Versiondes Metamodells heraus instanziiert wurden, sind nicht zwingend gültige Instanzen einer weiterentwi-ckelten Version. Weiterhin können Änderungen in der Schnittstellen-Spezifikation es erfordern, dassvorhandene Modellierungswerkzeuge angepasst werden.

In dieser Arbeit werden die Auswirkungen von Änderungen an Metamodellen für die Model-lierungsstandards Meta Object Facility (MOF) und Java Metadata Interface (JMI) untersucht. Diesgeschieht anhand des SAP-Projektes Modeling Infrastructure (MOIN), welches ein MOF-basiertesMetadaten-Repository enthält und den JMI-Standard implementiert.

Für die formale Definiton von Änderung an MOF-basierten Metamodellen wird zuerst ein Ände-rungs-Metamodell (Change Metamodel) vorgestellt, mithilfe dessen die Transformation einer Metamo-dell-Version zur nächsten unter Verwendung von Modellierungstechniken beschrieben werden kann.Diese Änderungen werden dann anhand ihrer Auswirkung auf die Kompatibilität zu bestehendenModelldaten und Schnittstellen klassifiziert.

Die Beschreibungstechniken und die Klassifizierung, die in dieser Arbeit vorgestellt werden, könnenfür eine Implementierung genutzt werden, die es Metamodell-Entwicklern erlaubt, die Folgen vonÄnderungen an Metamodellen für bestehende Daten und Anwendungen einzuschätzen und diese mithalbautomatischer Unterstützung anzupassen.

1 INTRODUCTION 1

1 Introduction

One of the challenges in software development is the handling of evolutionary changes in a softwaresystem. If a system evolves, the functionality and the interfaces may be changed in a way that existingapplications that are built on top of this system cannot continue working without adaptation to the newcircumstances. For this reason, changes to a system have to be well-planned, and the impact on existingdata and application must be described so that existing applications can be adapted. In order to keep thiseffort as small as possible, it is preferable if the effect of changes on existing installations is predictible,so that the modification of a system can be performed with knowledge of the impact it may have.

In the field of model-driven development, systems are described by modeling languages such as theMeta Object Facility (MOF). Together with the graphical notation of the Unified Modeling Language(UML), domain-specific metamodels are created that reflect the properties of a certain business domain.These metamodels are afterwards instantiated as actual models by customers for the description of theirdata.

1.1 Problem Statement

Like every kind of software component, metamodels are also subject to evolutionary changes, for exampleif a new version of the piece of software that includes the metamodel is released. If customers of thissoftware have built models with the previous version, they rely on the availability of migration rulesto adapt their model content to the new version. On the side of the software developer, the editor ofthe metamodel should be aware of the way in which changes to the metamodel layout will affect thecompatibility to existing data in terms of metamodel compliance and interface compatibility, so that thetools that the modeling software offers can still be used by customers of the previous versions. Thisproblem does not only affect the relationship of the software vendor to a customer. Since the roles of themetamodel editor and the software engineer who implements the modeling tools can be taken by differentpersons, the knowledge of the impact of changes to the metamodel is also relevant for the internal softwaredevelopment process.

Furthermore, the MOF specification does not offer a standard for the description of evolution ofmetamodels, so a formalisation for metamodel changes has to be found in order to describe the possibleimpacts in a structured way.

1.2 Structure

In this thesis, the problem of metamodel evolution will be evaluated for an actual implementation ofa MOF-based repository within the MOIN project at SAP1. The general problem description is solelybased on MOF, but specific problems for the MOIN implementation are also regarded.

The structure of this thesis is as follows: Firstly, the technologies that are used in the course ofthis thesis are introduced and described briefly. For the description of possible changes to MOF-basedmetamodels, a change metamodel will be introduced, which is itself described by the means of MOF.Furthermore, change severities are defined by which the single metamodel change types will then beclassified with respect to their impact on systems with existing model data. Furthermore, the problemof the determination of change severities for sequences of changes is discussed, and OCL constraints arepresented for common combinations of metamodel changes. In the next section, the impact on the queryinfrastructure of MOIN is described. Subsequently, the same is done for the Java interfaces in Section 5,and the results of these investigations are presented in an overview table in Appendix A. This thesisfinishes with an example demonstrating metamodel evolution case, references to related works and anoutlook at future work based on the results of this work.

1SAP is a trademark or registered trademark of SAP AG in Germany and in several other countries.

2 BACKGROUND 2

2 Background

2.1 Model-Driven Architecture (MDA)

The notion Model-Driven Architecture (MDA) denotes a software development approach that was launchedby the Object Management Group (OMG) in 2001. It focuses on integration and inter-operability insoftware development, covering all phases from specification and design through implementation andlifecycle management. Several technologies were standardized by the OMG, such as CORBA, UML, MOFand XMI. The UML standard is a widely adopted modelling language for object-oriented software design,as well as XMI for the interchange of model data. The MOF standard is described below.

The MDA approach [MDA03] defines a number of concepts, which are described in brief here:Model A model is the description or specification of a system and its environment. This description

can be graphical, in formal or natural language.Model-Driven MDA is a system development approach that makes use of models for understanding,

designing, and modificating systems.Architecture The architecture is the specification of the parts and connectors of a system and the

rules for the interaction of these parts.Platform A platform contains the technological and engineering details that are not relevant to the

functionality of a system. It offers interfaces and specified usage patterns to allow usage of the systemwithout knowledge of the internal technical structure.

2.2 Meta-Object Facility (MOF)

The Meta Object Facility specification [MOF02] defines a formal language and framework for the descrip-tion of metamodels. MOF is a standard that was developed by the Object Management Group (OMG). Itwas created as a language for the description of a metamodel for the Unified Modeling Language (UML).MOF also specifies an Interface Description Language (IDL) for the access and manipulation of metadata.A good introduction into MOF can be found in the introductory chapters of the specification of the JavaMetadata Interface (JMI) [JMI02]. The current version of the standard is MOF 2.0; however, the subjectof this thesis is based on MOF 1.4.

M3 Layer

M2 Layer

M1 Layer

M0 Layer

MOF model

metamodels (e.g. UML metamodel)

models (e.g. UML models)

actual objects (data)

inst

antiat

ion

Figure 1: The MOF abstraction layers

2 BACKGROUND 3

2.2.1 Design

When speaking about metadata (which is often described as “data about data”), one could theoreticallycreate an arbitrary number of meta-layers, since every kind of data can be described by a correspondingset of meta-data. (And thus the meta-data itself, and the meta-meta-data etc.) MOF is organized ina four-layered architecture in which the layers represent different levels of abstraction. The four layersare named M0 to M3, with M3 being the highest level. The separation of layers is strict, meaning thatelements of a layer can only reference elements of the same layer and can only be instances of the elementsin the layer above. The only exception to this rule is the MOF model itself (see below).

M3 Layer

The M3 layer contains the MOF metamodel (also called MOF model). The MOF model is used toinstantiate metamodels, which are then part of the M2 layer. The MOF model, however, is an instance ofitself. This means, for example, that the element Class in the MOF metamodel is its own meta-object.For this reason, MOF can be called a closed metamodelling architecture.

M2 Layer

The M2 layer contains metamodels, which are instances of the MOF model. For example, the UMLmetamodel is part of the M2 layer.

M1 LayerIn the M1 layer (also called model layer) describes the format and semantics of data. It contains

models. For example, UML models are part of the M1 layer.

M0 LayerThe M0 layer or information layer contains the actual objects or instances and thus, the data. For our

considerations, the M0 layer is not of interest.

ModelElement

Package Classifier Feature

DataType Class Attribute Reference

Association AssociationEnd

1 *contains

1

*

type

0..1

1

references

1 2

Figure 2: The MOF metamodel, simplified view (from [Het06])

2 BACKGROUND 4

2.2.2 Internal Structure

MOF was originally derived from a subset of UML and shares many common modeling elements withUML: The main elements are called classes, which are connected by associations, which have each twoassociation ends. The instances of associations are called links. For the convenient access of associations,classes can contain references, which like association ends and attributes have a type, which is modeledas the association IsOfType. In the MOF metamodel, the concept of inheritance is called generalization,which is represented by the Generalizes association.

Figure 2 shows an excerpt of the MOF model. The self-containedness property of MOF can be seenhere: The MOF model is described in itself, using principles like classes, inheritance and associations ina diagram.2

The complete model is too complex to be depicted or described in its entireness here; this is why wechose to include only the simplified view here. For the understanding of the following chapters, and fordetails of the standard, the MOF specification document [MOF02] should be regarded.

2.2.3 OCL

The Object Constraint Language (OCL) is a declarative, strongly typed, side-effect free language that wasoriginally created as a constraint language for UML. In its current version, it can be used with anyMOF-compliant metamodel in order to express additional constraints that cannot be expressed by themeans of graphical notation. OCL is now part of the MOF 2.0 standard. Its specification can be foundin [OCL06].

2.3 JMI

In order to access metadata in Java, the Java Metadata Interface (JMI) standard offers an API to discover,retrieve and manipulate metadata elements. The standard is being developed in the Java CommunityProcess as Java Specification Request (JSR) 040; the current version is 1.0 of 2002. The JMI standard isbased on MOF 1.4 in its current version; a language binding for MOF 2.0 does not exist yet.

2.3.1 Design

As a metadata API, JMI defines the Java representation of models. In Figure 3, an example model canbe seen on the left side. The generated Java interfaces for these elements are on the bottom right. JMIoffers two ways to access metadata: The reflective interfaces and the generated, tailored interfaces. Thereflective operations are defined in the classes whose names start in “Ref” and can be seen on the topright. The generated interfaces inherit from these reflective interfaces.

As it can be seen in Figure 3, the classes on the MOF side (C1, C2) each have two representations onthe Java side: An instance interface that extends RefObject (C1, C2), and a class proxy interface (C1Class,C2Class) that extends RefClass. This is caused by the fact that unlike package instances or links (whichare association instances), class instances have real object identity. While the package objects are merelya collection of the objects that they contain, and association objects contain the collection of links, whichhave no properties except the information of their existence, class instances have more complex featuresand are thus represented as Java instances. The class proxy instances are used for the creation of classinstances, and they also hold the classifier-scoped3 features of a class.

Furthermore, the reflective interface allows the discovery of an element’s features4 and allows a pro-gram to use them without prior knowledge. For example, if a class has a property attr1, then there aregenerated (tailored) operations to access this property, called getAttr1() and setAttr1(). If it is notknown whether an object has this property, it is not possible to use these operations because the Javatype check would fail, since getAttr1() is not defined for RefObject. Using the reflective interface, theproperty could be accessed by refGetValue("attr1"), which would throw an exception at runtime ifthe property does not exist. Using refMetaObject(), the existence of the property could also be checkedbefore.

2To make the issue even more confusing, UML is the language for the graphical notation of MOF and its metamodels.3Equivalent to static in Java4Like the reflective package in Java

2 BACKGROUND 5

It is also possible to navigate between the model layers using the refMetaObject() operation. In theexample of Figure 3, the M2 level is represented on the Java side as the interfaces C1, C2 and so on. IfM1 data is created, it is represented as instances of these classes. If refMetaObject() is now invoked onsuch instances, it returns an instance of MofClass5 with the attribute name set to C1. The metaobjectof this element is an instance of MofClass with the name Class, which is then its own metaobject.

P1 P2

Package P1

C1

C2

RefBaseObject

RefPackage RefAssociation RefFeatured

RefObject RefClass

P1 A

P2

C1Class C2Class

C1

C2

Metamodel Definition Inheritance in Generated Interfaces

A

Figure 3: Generated Java inheritance patterns (from [JMI02])

2.3.2 Special Tags Relevant for JMI

packagePrefix

For the generated Java classes and packages, it may be necessary to define a prefix for the Java packagenames. (e.g. java.lang.reflect) Since this prefix is only relevant for the generation of JMI interfaces,it is not used in the names of every element, but instead saved in a tag which is attached to the packagein which the elements are contained.

methodPrefix

The method prefix is similar to the above mentioned package prefix. If a method prefix is specified,the string is applied to all names of generated operations of that package.

substituteNameNot all names that can be used for model elements can also be used in the Java interfaces because

there are certain keywords (like e.g. Class) that cannot be used as an identifier. For this purpose, JMI

5This Java class represents the MOF model element Class; but since this is a reserved keyword in Java, the nameMofClass was chosen as the substitute name for the JMI interface.

2 BACKGROUND 6

specifies a tag with which a substitute name for interface generation can be provided. This is relevantfor the impact of metamodel changes on the JMI interfaces, which is described in Subsection 5.3.

2.4 MOIN

The Modeling Infrastructure (MOIN) at SAP provides a MOF-based repository and several metadataservices that can be used as the base for metamodeling tools. In the MOF specification, the purposeof a metadata repository is seen in “storing the computer representations of models and a collection ofassociated tools” [MOF02, section 5.2]. The models that are persisted and managed by the repositoryrepresent the M1 layer, while the metamodels that they are based on (M2 layer) are usually fixed.

In the case of MOIN, tools can connect via JMI, or they can use the Query Infrastructure using theMOIN Query Language (MQL). An OCL parser and evaluator is also provided that checks metamodelconstraints. Metadata can be persisted in the file system as well as on a database. For creation andediting of metamodels, a graphical model editor can be used within the Eclipse-based SAP NetweaverDeveloperStudio.

2.4.1 Special Tags

2.4.1.1 StorageWhen a link on M1 level is to be persisted, there are three possible ways of storing the information:

On either one side of the link or on both sides. In MOIN, there is a special tag that defines the storage ofa link. Currently, MOIN uses one-sided storage, meaning that if a link is created between two elementson M1 level, the information on this link is only stored in one of the elements.6 In the metamodel, theStorage tag is attached to the AssociationEnd on the side of the association where it is to be stored.

The metamodel author should decide about link storage for every Association created. If no storagetag is present, MOIN sets it automatically, depending mainly on the existence of references in the classesat the association ends.

2.4.1.2 Attribute Initializer

MOIN uses a special constraint to express an initializer value for primitive type attributes. This initialvalue is used when new M1 instances are created. The use of this initializer is optional. It could also beused when an attribute is added to the metamodel and existing M1 data has to be updated to the newmetamodel.

2.4.2 Query Infrastructure

Besides JMI, MOIN offers a query infrastructure that can be used as an entry point into the repository.It allows the retrieval of model data based on the MOIN Query Language (MQL).

MQL provides an SQL-like syntax to query the repository. An MQL query is specified against aM2 metamodel and queries M1 data. The MOIN Query Language (MQL) is strongly typed against theMOF metamodel. MQL queries return a result set which consists of multiple result records that containreferences to the elements of the type that was specified in the query.

6In the actual implementation, this means that the M1 object at the “storage” end will contain a field that points tothe other, linked element. In persisted state, it means that the link will be stored in the same partition as the respectiveelement at the stored end.

ModelElementChange

/severity:SeverityKind

«enumeration»ChangeKind

ADD

DELETE

«enumeration»SeverityKind

NON_BREAKING

BREAKING_RESOLVABLE

BREAKING_NOT_RESOLVABLE

ChangeSequence/severity:SeverityKind

ExistenceChangekind:ChangeKind

affectedElement:ModelElement

PropertyChange

affectedElement:ModelElement

LinkChange

kind:ChangeKind

ConstrainsChangeconstrainedElement:ModelElement

constraint:Constraint

RefersToChangereferrer:Reference

exposedEnd:AssociationEnd

CanRaiseChangeexcept:Exception

operation:Operation

position:Integer

AliasesChangeimporter:Import

imported:Namespace

MultiplicityTypeChangelower:Integer

upper:Integer

isOrdered:Boolean

isUnique:Boolean

PrimitiveTypeChange

propertyName:String

IsOfTypeChangetypedElement:TypedElement

type:Classifier

ContainsChangecontainer:Namespace

containedElement:ModelElement

position:Integer

GeneralizesChangesuperElement:GeneralizableElement

subElement:GeneralizableElement

position:Integer

AttachesToChangemodelElement:ModelElement

tag:Tag

position:Integer

StringChangenewValue:String

MultiValuedStringChangekind:ChangeKind

value:String

position:Integer

BooleanChangenewValue:Boolean

EnumerationTypeChange

DirectionKindChangedirection:DirectionKind

ScopeKindChangescope:ScopeKind

AggregationKindChangeaggregation:AggregationKind

EvaluationPolicyChangeevaluationPolicy:EvaluationKind

VisibilityKindChangevisibility:VisibilityKind

1 {ordered} 1..*

changeschangeSequence

Figure 4: The MOF change metamodel

3 CHANGES IN MOF-BASED METAMODELS 8

3 Changes in MOF-Based Metamodels

In this section, the types of changes that can applied to M2 metamodels will be described and classifieddepending on their impact on existing M1 data. First, a formal definition of metamodel changes will bepresented, then, the single change types will be described and classified.

3.1 Definition

For the description of metamodel changes, we introduce a Change Metamodel (see Figure 4). Instances ofthis metamodel describe an actual change to a metamodel as a sequence of single change steps, containedin a ChangeSequence element. As described in [AP03], all changes in a metamodel can be expressed as asequence of either additions or deletions of elements and links, or modifications of a property. The ChangeMetamodel is also based on this assumption; the three base classes of the change metamodel cover theaddition or deletion of elements (ExistenceChange), the modification of properties7 (PropertyChange) andthe deletion or addition of links (LinkChange). These single change types will be described and classifiedin the following subsections.

For the non-trivial cases, the classification of a change is expressed as an OCL constraint. These andother consistency constraints that are attached to the change metamodel are listed in Appendix B.1.

3.1.1 ExistenceChange

This class describes the addition or deletion of an element, such as a class, an attribute, an association, etc.If an element is to be deleted, the attribute affectedElement references the element in the metamodel.In the case of an addition, it references a new element.

3.1.2 PropertyChange

A property of a metamodel element represents an attribute in the MOF class of which the element is aninstance.8 Since in the MOF model, the attributes of the classes are only typed with DataTypes (and notwith classes), we can specify an actual class in our metamodel for every property type. Furthermore, thepropertyName field is only needed for the PrimitiveTypeChange. With multiplicity or enumeration types,there is only one attribute of the respective type in each MOF class, and so the change is unambiguous.

3.1.3 LinkChange

This class represents all changes in features that are associations in the MOF model. This includescontainment, inheritance (generalization) and typing, some of which are features that are not representedas a (visible) association in a model diagram.

For associations that are ordered, the field position describes the position of a newly added element.For deletions, this value is ignored.

3.2 Prerequisites

3.2.1 Difference of Metamodels

In general, there are two ways of determining the difference of two (meta-)models: Either the tracing ofsingle changes or direct comparison. Both approaches have their advantages and drawbacks.

7When we talk about “properties”, we mean attributes of MOF model classes. However, since the notion “attribute”could be misinterpreted in some cases, we refer to them as properties.

8This can be somewhat confusing, since metamodel classes can have attributes themselves; however, these class attributesdo not have values in the M2 level, but only in the M1 instances.


Single changes to a metamodel can only be traced if the infrastructure which is used to edit themetamodel supports the recording of changes. This generates a sequence of atomic changesteps, which isat the same time the advantage and the disadvantage of this approach. On the one hand, single steps areoften needed for a formal description of a larger change. With tracing, they do not have to be determinedby an algorithm, as it is the case for the direct comparison; on the other hand, it is possible that someof these steps revert each other, for example a consequent addition and deletion of the same element. Inother words, the set of changes is not necessarily minimal when using this method.

If two metamodels are compared directly, an algorithm has to be found that determines a sequenceof changes that describes the conversion of one metamodel version to another. The advantage of thisapproach is that the sequence of changes will be minimal if a proper algorithm is used, e.g. the onedescribed in [CRGMW96]. However, it is more difficult to determine the atomicity of changes. Forexample, moving an attribute from a class to a superclass can be seen as a delete/add operation oftwo attributes with the same name, multiplicity and type, but also as a change of containment for theattribute. Of course, the latter makes it easier to make statements about the impact on M1 data.

3.2.2 Validation of M1 Model Data

Instance data on the M1 level is always connected to a M2 metamodel, and in general, it cannot be usedwithout knowledge about the metamodel.9 If there are changes in the metamodel, existing M1 data canbecome invalid.

There are different ways of validating the conformance of M1 data to a metamodel. A general definitionof model inconsistencies for UML is given in [MvdSD06]. The easiest way to do this is on interface level,e.g. the generated JMI interfaces. However, this definition is very strict and does not even allow minimalchanges such as a change in the order of attributes.10 Furthermore, this definition of compatibilitydepends on the language used for the interfaces, which is Java for the JMI case.

In MOIN, model data is stored in partitions, from where it is loaded and validated against the deployedmetamodels. If M1 data refers to M2 elements that do not exist, these references are ignored and anerror message is traced. Nevertheless, the M1 data can be read.

3.3 Classification

In this subsection, the changes types are sorted by the classes of the change metamodel. In the singlesections, the description of the impact of changes is then split up by the affected MOF classes.11 Here,we use the non-abstract MOF classes. Some changes are not applicable to MOIN because of unsupportedtypes or because attributes are set to a certain value by standard. It is noted in the respective section ifa feature is not supported by MOIN.

We classifiy the changes into the three severities that are defined in [BGGK07]:

non-breaking < breaking and resolvable < breaking and not resolvable

• A non-breaking change does not require any adaptation of existing M1 data, which is mostly truefor additive changes to the metamodel.

• For breaking and resolvable changes, an algorithm can be defined to migrate existing instances tothe new metamodel version.

• If a breaking and not resolvable change occurs, manual interaction is required to make existing dataconformant with the new metamodel, if at all possible.

For certain M1 models, a change can have no effect although it is classified as breaking. In the followingsections, we will always describe the worst case at first, and then mention the special cases where M1 data

9However, there are methods to determine metamodel information from M1 data, depending on the format in whichthey are stored. This problem is similar to the extraction of schema information from existing XML instances, as describedin [MAC03].

10See Section 5 for details.11For changes in the metamodel, we regard neither the MOF-conformance nor the integrity of the metamodel — we

suppose that the editor of a metamodel ensures these. Our interest lies in the M1 models and the changes that arenecessary in order to make them conformant to the new M2 metamodel.


is not affected by that change. However, there are generic cases that can be applied to all metamodeltypes: If an M2 element is modified, and no M1 instances exist for that element12, the change is non-breaking.


This section is divided into the M2 classes of which affectedElement is an instance.

3.3.1.1 Class

add The addition of Class elements is non-breaking.delete If classes are deleted, the corresponding M1 instances must also be deleted. This change can

be breaking and not resolvable if a situation similar to Figure 5 occurs: The instance of Type2 has a linkto an instance of Subtype1. If Subtype1 is deleted, the association still exists in the metamodel, since itis connected to the superclass Type1 of the deleted class. As a consequence of the deletion of Subtype1,all its instances and the links to these instances are also deleted, leaving only the instance of Type2.Now the model data is invalid, since there is no link to an instance of Type1, which is required by theminimum cardinality of 1 in the metamodel. This case is described by the severity constraint [SC-1]. Inother situations, this change is breaking and resolvable.

Type1 Type2

Subtype1

:SubType1 :Type2

M2

M1

Type1 Type2

:Type2

1..* 0..1 1..* 0..1

Figure 5: Example: Deletion of a class makes M1 data invalid

3.3.1.2 Attribute

add The effect of the addition of an attribute to an element depends on the minimum cardinality13

of that attribute. If the minimal cardinality is 0, then the change is non-breaking. If it is greater than 0,which means that attribute values have to exist, the change is breaking and not resolvable, as describedin severity constraint [SC-2]. This is caused by the fact that MOF 1.4 does not support initializers fortyped elements. Otherwise, the initial value could be set for non-initialized attributes. If an initial valuefor the attribute is specified elsewhere in the metamodel, the change is breaking and resolvable.14 If thecontaining element for the attribute has been added in the course of the change sequence, the addition ofmandatory attributes is non-breaking since there are no M1 instances of this element.15 This is describedin severity constraint [SC-2].

delete All attribute values have to be deleted. This change is breaking and resolvable.

3.3.1.3 Associationadd For associations, the same is true as for attributes: If the minimum cardinalities of the associ-

ation’s ends are equal 0, then the change is non-breaking. If the minimum is greater than 0, the existing

12For classes, this also means that instances of any subtype must not exist either.13I.e. the field lower in the attribute multiplicity.14In MOIN, there is a special constraint for attribute initializers. (See Paragraph 2.4.1.2)15In case the newly added element is declared as a superclass of existing classes with possible M1 instances, these instances

can become invalid; this fact is described in severity constraint [SC-6] of GeneralizesChange.


M1 data may not conform to the new metamodel, and the change is breaking and not resolvable. If thereare no instances of the element at the other end of the association, this change is non-breaking.16

In the example of Figure 6, several cases can occur when Assoc1x2 is added to the metamodel: If thereare no instances of neither Type1 nor Type2, the change is trivially non-breaking. If there are instances ofType1, the change is still non-breaking, since the minimum cardinality of assoc1x2EndB is 0. If instancesof Type2 exist, the change is breaking and not resolvable, since the minimum cardinality of assoc1x2EndAis 1, but there are no links for this association, as it has been newly added to the metamodel.

delete The links in the M1 model have to be deleted. This change is breaking and resolvable. Thisis described in severity constraint [SC-3].

Type1 Type21..* 0..1Assoc1x2

assoc1x2EndA assoc1x2EndB

Figure 6: Example: Association cardinality

3.3.1.4 AssociationEnd

Since an AssociationEnd is always contained in an Association17 , the effects for add/delete are thesame as for an Association element.

3.3.1.5 Reference

A Reference has no instances; it is to be understood as a convenient way to access links (which canbe seen as instances of an Association). If references are added or deleted, the only change is in theinterface definition of an element, which is on the M2 level. Thus, these changes are non-breaking.

3.3.1.6 Package

add The addition of a Package is non-breaking.delete If a package is deleted, the impact on M1 data depends on how the contents of this package

can be resolved. If the elements which were contained in the package can be resolved, the change isbreaking and resolvable, otherwise ist is breaking and not resolvable.

3.3.1.7 Import

add The addition of an Import is non-breaking.delete If all the elements which were imported by this Import can be resolved, this change is breaking

and resolvable. Otherwise, it is breaking and not resolvable.

3.3.1.8 TagThe semantics of a Tag are not specified by MOF. This is why it is not possible to make a statement

about the impact of a generic tag. However, there are tags which are relevant for JMI generation, seeParagraph 5.4.2.5, and there are special tags in MOIN, see Subsection 3.5.

3.3.1.9 Constraintadd In general, the addition of a constraint is breaking and not resolvable. Constraints can be

arbitrarily complex, so necessary changes in M1 data cannot be easily resolved. Also, constraints in aM2 model can be in different languages (MOF uses OCL in its own constraints), so a possible “impactanalysis” of constraint changes would have to be language-specific. Even if we only regarded OCL, theanalysis would exceed the scope of this work.

However, there is one (trivial) special case; if there are no instances of the element affected by thenew constraint (i.e., its context), the change is non-breaking.

delete The deletion of a constraint is always non-breaking, since the restrictions for M1 data arereduced by this operation.

16Here, the same is true as for Attribute: If the classes at the association’s end are newly added, there can be no newinstances; also, in the case of existing subclasses, the severity is described in severity constraint [SC-6].

17This is described in MOF constraint [C-33].


3.3.1.10 Constantadd This change is non-breaking.delete If the constant is referenced somewhere in the M1 data, the change is breaking and not

resolvable; otherwise, it is non-breaking.

3.3.1.11 OperationAn Operation is specified on M2 level and does not have a representation on M1 level. Since it is a

BehavioralFeature, it does not have instances, and its behaviour is only dependent on the state of aninstance; if two instances are in the same state, i.e. all attribute values are the same in both instances,the operation behaviour will be identical. The addition or deletion of an operation does not have aneffect on the M1 data; thus, this change is non-breaking.

3.3.1.12 ExceptionExceptions, like operations, are specified on M2 level. A change of an Exception definition does not

influence the persistence of M1 data; it is non-breaking.

3.3.1.13 Parameter

Since a Parameter is always part of an Operation or Exception, a change is non-breaking.

3.3.1.14 DataType

The DataType class is abstract in the MOF model; however, since the approach is the same for allsubclasses of DataType, we will only describe it once here.

add This change is non-breaking.delete If a DataType is deleted, all TypedElements of this type (in the M2 model) have to get another

type or be deleted. However, this is an additional action18 which ensures metamodel consistency, andthe changes made for this action have effects of their own. (See Paragraph 3.3.3.3) If the deletion ofa Datatype does not cause changes in the M2 model, it is also non-breaking for the M1 data, since aDataType does not have M1 instances.

3.3.1.15 CollectionTypeCollectionType is not supported by MOIN.

3.3.1.16 AliasTypeAliasType is not supported by MOIN.

3.3.1.17 StructureFieldFor a StructureField, the same is true as for DataType.


In this section, we analyse the changes in properties of MOF classes. Derived attributes are not regardedsince they cannot be directly changed.

3.3.2.1 ModelElement

name Elements can be resolved after a name change since every element has a unique identifier,the MOFid. If the infrastructure accesses the metamodel elements via the MOFid primarily,19 a namechange which preserves the MOFid is non-breaking. Nevertheless, a refactoring must be performed on theM1 instances to guarantee the consistency with the metamodel. Thus, the overall change is breaking andresolvable.

18Namely, an IsOfTypeChange.19This is the way it is done in MOIN.


annotation An annotation is only used for descriptive purposes20, so changes in this attribute arealways non-breaking.

3.3.2.2 GeneralizableElementisRoot/isLeaf These properties can be seen as constraints which are only important for the consis-

tency of the metamodel itself; thus, the M1 data is not affected by a change of these flags, the change isnon-breaking.

isAbstract If an abstract element is marked non-abstract, the change is non-breaking. If a non-abstract element is changed to abstract, its direct instances will have to be deleted. This change isbreaking and resolvable.

visibility If the visibility of an element is increased, the change is non-breaking ; if it is decreased, thechange is breaking and not resolvable.

The visibility is always set to public_vis in MOIN.

3.3.2.3 AssociationisDerived If a non-derived association is set to derived, the links in the M1 data may become invalid

if they do not conform with the derivation rule, which can be defined in an arbitrary way. So this changeis breaking and not resolvable. If a derived association is set to non-derived, the change is non-breaking.21

This feature is always set to false in MOIN.

3.3.2.4 ClassisSingleton If a singleton class is changed to non-singleton, this change is non-breaking. In M1

models, there can be at most one single element of this class, which is still valid after the class loses itssingleton property. In the other direction, the change is only non-breaking if there is exactly one instanceof the class. Otherwise, it is breaking and not resolvable, since there is no way to determine which instanceshould be the new singleton instance and which instances should be deleted.

This feature is always set to false in MOIN.

3.3.2.5 TagThe effect of changes of a tag property cannot be universally described. See Paragraph 3.3.1.8.

3.3.2.6 Constraint

expression Again, the semantics of a constraint can be arbitrarily complex, so general statementson the effect on M1 data cannot be made easily. The special case is the same as in Paragraph 3.3.1.9: Ifthere are no M1 instances of the constrained element, the change is always non-breaking.

language A change of this feature does not make sense without changing the expression itself. Seeabove.

evaluationPolicy The EvaluationPolicy determines the point of time when a constraint should bechecked. This does not influence the compliance of static M1 data with the constraint; hence, a changeof this property is non-breaking.

A change of the evaluation policy does not have an effect in MOIN.

3.3.2.7 Featurescope If the scope is set from instance_level to classifier_level, it has to be assured that all

instances of that element have the same value. If different values are existent, it is not clear which oneshould be chosen. So this change is breaking and not resolvable.

In the other direction, if the scope is set from classifier_level to instance_level, the change isnon-breaking.

visibility See GeneralizableElement (Paragraph 3.3.2.2).This feature is always set to public_vis in MOIN.

20[MOF02], chapter 7.4.121In order to preserve as much data as possible, it would be a good idea to persist the links the way they were last

calculated.


3.3.2.8 StructuralFeaturemultiplicity If the range of the multiplicity is widened, the change is non-breaking ; if it is narrowed,

the change is breaking and not resolvable.isChangeable This feature is always set to true in MOIN.

3.3.2.9 AttributeisDerived See Association. (Paragraph 3.3.2.3).This feature is always set to false in MOIN.

3.3.2.10 OperationisQuery Since Operation is a M2 feature, a change of this feature is non-breaking.

3.3.2.11 Constantvalue Since Constant is a M2 feature, a change of this feature is non-breaking.

3.3.2.12 ParameterA Parameter can only be part of an Operation or an Exception, which are both M2 features.

3.3.2.13 AssociationEndisNavigable A change in navigability does not have any effects on the M1 data. Therefore, this

change is non-breaking.This feature is always set to true in MOIN.aggregation If an aggregation is changed from composite to none, this change is non-breaking. In

the other direction, there are two cases: If a composition cycle is created, the change is breaking and notresolvable, since there could be links between instances which violate the composite closure rule: On theM1 level, an element must not be in the closure of a composite relation to itself; furthermore, an elementcan have at most one composite parent.22 If the metamodel does not contain a composition cycle afterthe change or if no links exist which will violate the composition closure rule, the change is non-breaking.This is described in detail in severity constraint [SC-4]. In Figure 7, an example of a composition cyclecan be seen.

Type1 Type2

Type3

Type1 Type2

Type3

:Type1 :Type2

:Type3

:Type1 :Type2

:Type3

M2

M1

Valid in both versions Invalid in the new version

Figure 7: Example: Composition cycle

multiplicity If the range of the multiplicity is widened, the change is non-breaking ; if it is narrowed,the change is breaking and not resolvable.

22See [MOF02], chapter 8.11.2


isChangeable This property describes the dynamic behaviour of a model. Static M1 data will stillbe valid if this property is changed, so the change is non-breaking.

This feature is always set to true in MOIN.

3.3.2.14 EnumerationTypelabels The adding of labels constitutes a non-breaking change. If labels are removed or renamed, the

change is generally breaking and not resolvable; however, if there are no fields in the M1 data with theaffected enumeration label, the change is also non-breaking.

3.3.3 LinkChange

This class describes the changes of links between elements in the metamodel. Since there is only a finitenumber of associations specified in MOF, we can describe all kinds of changes with the classes mentionedin the change metamodel.

A link change can be the addition or the deletion of a link. This means that the change of a linkis represented as delete and add. Since in many cases, a single delete does not make sense because theassociation must have an instance23, the description in the following paragraphs covers changes ratherthan single deletions or additions. (See Figure 4)

3.3.3.1 ContainsChange

If the containment of an element is changed,24 several cases have to be regarded:

• If the new container is not a supertype, the element cannot be resolved, so the change is equal tothe deletion of the element. The severity is equal to an ExistenceChange with the delete kind ofthe respective element type, which is breaking and not resolvable in the standard case.• If the new container is a supertype of the former container, the element will still be accessible for all

M1 instances which reference it. However, if mandatory features (i.e. features with a multiplicity,where the minimum cardinality is greater than 0) are moved to a supertype, there is a possibility forM1 data to become invalid, which makes the change breaking and not resolvable. Of course, this doesnot apply to cases where all instances have values for that feature, e.g. because a new superclasswas introduced and existing features are moved there. Then, the change is non-breaking, since allexisting instances are still valid, and for the superclass, no instances exist, since it was newly createdin the course of the metamodel change. This is described in detail by severity constraint [SC-5] andcan also be seen in the example in Section 6.

In the example of Figure 8, an attribute is moved to a superclass. After this change, all instancesof Type2 will still be valid, but instances of Type1 will become invalid since there are no values forattribute1.

3.3.3.2 GeneralizesChangeadd If a new supertype is added to an element, there are two possible cases. Firstly, if the new

supertype or one of its supertypes contain mandatory features or there are mandatory association endswhich point to these types, the change will be breaking and not resolvable, since the existing instances ofthe type will not have any values for these features. If the new supertype hierarchy does not contain suchfeatures, the change is non-breaking.

The addition of a subtype is always non-breaking from the standpoint of the “super” element; thus, ageneralization change should be observed from the subtypes’ view.

delete If instances of the subtype are used as values for features which are typed with one of itsdirect or indirect supertypes, a deletion of the generalization association between those types will causeM1 data to become invalid if there are instances of these features, as seen for an association in Figure 9.

23For example, a TypedElement must have a type; all elements except instances of Package must have a container (MOFconstraint [C-1]), etc.

24Technically, a change in containment consists of two single changes: one delete and one add change. Since all elementsexcept Packages must be contained (MOF constraint [C-1]), it does not make sense to investigate the effects of singlechanges. The changes described here also define severities for the cases which were not regarded in Subsection 3.3.1.


Type1

Type2

attribute1:Integer

Type1

attribute1:Integer

Type2

attribute1 hasmultiplicity 1..*

:Type1 :Type2

attribute1 = 42

M2

M1

Figure 8: Example: Containment change

If the features are not mandatory, this problem can be resolved by removing the link between theinstances, or in case of object-values attributes by a deletion of the attribute instance. This makes thechange breaking and resolvable. If the features are mandatory, the change is breaking and not resolvable25.

If the supertype contains structural features, the values of these features have to be deleted in theM1 instances and the change is breaking and resolvable; if the supertype does not contain any structuralfeatures, the change is non-breaking.

The overall severity of the change is the highest severity of the two criteria mentioned. An exactspecification can be found in severity constraint [SC-6].

In MOIN, there is no inheritance for packages.

Type1 Type2

Subtype1

:SubType1 :Type2

M2

M1

Type1 Type2

Subtype1

invalid

Figure 9: Example: Deletion of generalization leads to invalid M1 data

3.3.3.3 IsOfTypeChange

The deletion of an IsOfType link always coincides with the creation of a new one, since the associ-ation end type has the multiplicity 1. There are two cases of a type change which are relevant here:AssociationEnd and Attribute elements.26

If the new type is a supertype of the old type, the change can be non-breaking, since all instanceswill still be valid. However, there is a speciality for AssocEnd. If the situation is similar to Figure 10,existing M1 data will become invalid: In the example, EndB is moved to a supertype. In the M1 data,the instances of Type1 and SubType2 will still be valid after the change, since the association still exists.Only the instance of Type2 is invalid since there is no association to an instance of Type1 despite theminimum cardinality 1 of EndA. This makes the change breaking and not resolvable.

25This case is equal to the situation in Figure 5 on page 10.26The other instances of TypedElement are either not relevant for M1 data (Parameter, Constant) or are implicitely covered

by these cases (Reference).


If the new type is a subtype of the old type, the severity depends on the existent links and attribuevalues in the M1 data. If they are all type compatible with the change, i.e. that all instances are of thenew type or one of its subtypes, the change is non-breaking. If there are instances of the old type whichserve as a link end or attribute value, the change is breaking and not resolvable.

If the new type is no sub- or supertype, the change is breaking and not resolvable. An exact specificationcan be found in severity constraint [SC-7].

Type1 Type2

SubType2

:Type1 :Type2:SubType2

M2

M1

Type1 Type2

SubType2

1..*

0..1

EndA

EndB

1..* 0..1

EndA EndB

Figure 10: Example: Type change on an association end

3.3.3.4 AttachesToChangeA Tag does not have semantics which are specified in MOF, so the effects of a tag re-attachment

cannot be described in general. See Paragraph 3.3.1.8.

3.3.3.5 ConstrainsChange

This feature is ignored since we do not regard constraints. Anyway, a constraint is not only connectedto an element via the Constrains association: In MOIN, the constraint language is OCL, and thusevery constraint has an explicit context keyword. If an OCL constraint has a different context than theelement to which it is connected via the Constrains association, MOIN will recognize this as an error.

3.3.3.6 RefersToChange

Changing the ReferencedEnd for a Reference constitutes a non-breaking change.27

3.3.3.7 CanRaiseChange

Since Operation and Exception are M2 elements, the change of this association is non-breaking.

3.4 Determination of Overall Severity

3.4.1 Problem Description

Observing changes on an atomic level, like with the proposed change metamodel, has a fundamentaldisadvantage: There are certain kinds of changes which have a different effect on the metamodel if theyare applied in combination. Normally, the overall severity of a change is the maximum of the severitiesof the single changes. But this is not always true. Think, for example, of the deletion of an element andthe creation of another element with the same type and the same name. If a metamodel is modified thisway, the only change is in the unique identifier of the affected element, everything else will be the same,which especially means that existing models will not become invalid in the new version of the metamodel.

Another aspect of this matter is that there are kinds of changes in MOF which can be describedas a single modification with the change metamodel, such as name changes or type changes for Typed

27Note that the new end has to be compatible in terms of multiplicity, changeability and type (MOF constraints [C-21],[C-23] and [C-24]). If the new referenced end is not compatible with this, further changes in the metamodel will have to beperformed to ensure consistency of the metamodel.


Element28, but others, like changes in generalization or containment, cannot be described as a singlechange.29 This has to be regarded when describing the severities for metamodel changes.

3.4.2 Solution

Since metamodel changes are part of a ChangeSequence, it does not make much sense to analyse theeffects of a single change operation. Furthermore, many operations cannot be applied as a single change,because they would lead to an inconsistent metamodel state. For example, if a Class is removed fromits container, there has to be another change which adds it to a new container, because otherwise MOFconstraint [C-1] would be violated.

This is why the analysis of a change always has to regard the new metamodel version after allchanges, which means that the new type and containment hierarchy must be known as well as theoriginal hierarchies. If, like in our case, a metamodel change is described by the original metamodeland an instance of the change metamodel, the new metamodel has to be constructed first. We choseto describe the severities as OCL constraints which can be found in Appendix B.2. There, the helperfunctions [M-1] to [M-9] are used to calculate the new containment and type hierarchy. Based on thesefunctions, the derived attribute severity of each ModelElementChange element can be determined.

Since the severity of every ModelElementChange element depends on the other changes which areperformed in the same ChangeSequence, the overall severity of such a sequence can be determined easilyby finding the maximum severity. If a change sequence only consists of one change, this is still true, sincethe constraints are written in a way so that the result will still be correct if there are no other changesexcept one.

Type1

Type2

Type3

Type4

Type5

M2

M1

Type1

Type2

Type3

Type4

Type5

i3a:Type3 i4:Type4

i3b:Type3 i5:Type5

invalid after change 1;becomes valid again after change 2

invalid after each change

1.

2.+

Figure 11: Example: Change in type hierarchy

3.4.3 Examples

In this section, we will describe cases where a change sequence containing changes which would be breakingif performed as a single change becomes non-breaking in total.

3.4.3.1 Example for Hierarchy ChangeIn the case of Figure 11, the class Type3 moves up one level in the type hierarchy: instead of being

an indirect subtype of Type1, it becomes a direct subtype. If this change is described as two operations,deletion (1.) and creation (2.) of the generalization, the severity of the first operation is breaking,

28The latter also covers the rerouting of an Association to another element in the metamodel.29This is caused by the fact that Generalization is an association on M3 level, and thus a link on M2 level. The

associations in the metamodel are actually instances of the M3 classes Association and AssociationEnd. This can be a bitconfusing since both are represented as a connector in the M2 class diagrams.


according to Figure 9. This is also true as an overall severity for the instances i3b and i5, but not forthe instances i3a and i4. Since Type3 becomes a subtype of Type1 again, the association between Type3

and Type4 conforms to the metamodel, and so the change is non-breaking for these two instances. If allM1 instances are valid after the change, the overall change is also non-breaking.

3.4.3.2 Example: Inverting Generalization

Figure 12 shows a case where two changes are applied: The type of the association end EndB is changedfrom Type2 to Type3, and the direction of the generalization is inverted.30 The interesting aspect of thisconfiguration is the fact that each one of these changes would be breaking, but the combination of all ofthem is non-breaking.

Type1 Type2

Type3M2

M1

Type1 Type2

Type3

i1a:Type1 i2:Type2

i1b:Type1 i3:Type3

EndA EndB

EndA

EndB

Figure 12: Example: Inversion of type hierarchy

3.4.3.3 Containment Change

Changes in containment of element often occur as pairs, since all types of elements except pack-ages must be contained in another element. The movement of an element to a different container isdescribed as a delete operation and an add operation. They can be identified as a pair by the identicalcontainedElement. The severity of containment changes is described in Paragraph 3.3.3.1.

3.4.3.4 Delete and Add of Similar Elements

A rather trivial case of severity weakening are operations which revert each other. Not all of thesecombinations can occur if the difference between two metamodels is determined by direct comparison.

Addition and Deletion of an Element This change is always non-breaking and will not occur withdirect comparison of metamodels since the versions are identical before and after the change.

Deletion and Addition of an Element If an element is deleted, it cannot be exactly re-created,since a newly created element will get a different MOFid than the one which was deleted. However, itis possible to create an element with the same type and properties such as name, attributes etc. If thename is identical, the element will still be found if the infrastructure resolves elements by name when theMOFid is not found, as it is done in MOIN.

3.5 MOIN-Specific Changes

3.5.1 Storage

The choice of the storage side has great effects on the layout of the persisted M1 data. If the storageside is changed to the other side of an Association in the metamodel, all existing M1 data will becomeinvalid. This change is implementation-specific to MOIN and constitutes a breaking and resolvable change.

30These steps actually each consist of two operations: deleting and adding of the generalization and of the IsOfType link.


3.5.2 Attribute Initializer

The attribute initializer constraint is used as the attribute value if new instances of an element arecreated. If this initial value is changed, existing M1 data cannot become invalid. The only problems arethe semantics of this value: If existing data with this value is present, in can be mistaken for an initialvalue, and existing initial values can be mistaken for individually set values.

4 QUERY VISIBILITY OF CHANGES 21

4 Query Visibility of Changes

If metamodels are modified, it is possible that not only existing M1 data is affected by these changes, butalso the result sets of existing MQL queries. As the query functionality of MOIN serves as an entry pointfor the access of M1 data, there may also be queries with an expected result set for existing M1 data.

The changes to the metamodel can have two kinds of effects on the queries:

• The result set can be different from the desired set.• The query itself can become invalid if it does not conform to the type system of the new version.

In this section, we will investigate changes to the metamodel under the condition that the M1 dataremains the same during the change. This means that the result set for an existing query and unmodifiedM1 data can only differ for a new metamodel if changes in the type hierarchy are part of the metamodelchange. In all other cases, the result set will be the same or the query itself will become invalid.

In general, additive changes to the metamodel cannot make a query invalid. If there are no M1 valuesfor element features, the query engine will not return an entry in the result set for this element. On theother hand, changes which include the deletion of elements will make a query invalid only if the deletedelement is part of the query, e.g. a class, an attribute or an association.

4.1 Changes Without Effects on Queries and Result Sets

In general, all changes which are non-breaking according to the classifiations in Subsection 3.3 will nothave an effect on query result sets. The only exception to this are changes to the generalization hierarchy,which are described in the next section.

4.2 Changes Affecting the Result Set

Since the M1 data is not modified for the new metamodel, there can only be few cases which actuallyhave an effect on the result set of a query. All of these cases are related to a change in type hierarchy.This is caused by the fact that queries normally operate on a type and all its subtypes. Only if thekeyword withoutsubtypes is added to the from-clause, subtypes are not regarded.

But when new types are added to the metamodel, there can be no instances for these types in theM1 data, since the types did not exist at the time the data was created. However, it is possible to addgeneralization between already existing classes, which adds the instances of the classes which are nowsubclasses to the result set.

Type1

Type2 Type3

i1:Type1

i2:Type2

i3:Type3

Query: select t1 from Type1 as t1

Result set before change: {i1, i2}

Result set after change: {i1, i2, i3}

M2 M1

+

Figure 13: Query visibility: Adding generalization


4.2.1 Adding Generalization Between Existing Types

result set As seen in Figure 13, the addition of generalization between two existing classes mayincrease the size of the result set of a query if there are instances of the class which becomes the newsubclass.

query modification If the result set is intended to be the same after the metamodel change, thequery of Figure 13 must be modified in a way so that all classes of the type hierarchy in the older versionare mentioned explicitely. In this case, these are the types Type1 and Type2. So the result is the unionof the result sets of the following queries:

select t1 from Type1 as t1 withoutsubtypes ∪

select t2 from Type2 as t2 withoutsubtypes

Listing 1: Query result set after generalization change

4.2.2 Deleting Generalization Between Existing Types

result set In the other way, if a generalization is deleted, the size of the result set of a query maybe reduced if there are instances of the subclass while the query operates over the superclass, as seen inFigure 14. A more complicated case where association are involved is shown in the next section.

query modification In order to obtain the same result set with the new metamodel, the solution isagain to include all classes explicitely in the from-clause. The result set is constructed analogously toFigure 13.

Type1

Type2 Type3

i1:Type1

i2:Type2

i3:Type3

Query: select t1 from Type1 as t1

Result set before change: {i1, i2, i3}

Result set after change: {i1, i2}

M2 M1

Figure 14: Query visibility: Deleting generalization



select t3 from Type3 as t3 withoutsubtypes

Listing 2: Query preserving result set after generalization delete

4.3 Changes Making the Query Invalid

The MOIN Query Language is strongly typed against M2 metamodels. This means that changes in thetype system of a metamodel can make a query invalid. The validity of a query is checked in a preparationstep before the actual query execution, and if it fails, the operation is aborted.31

31The validity of a query is independent from the existence of actual M1 data, since the type check is performed againstthe metamodel.



If elements which occur in the query are deleted from the metamodel, the query becomes invalid. Thischange is not resolvable. This applies to the following kinds of elements: Class, Attribute, Association(and the AssociationEnd elements contained in it) and DataType (for comparisons). The deletion of aReference element is only breaking if the name of the reference differs from the name of the correspondingAssociationEnd. Otherwise, the link can be resolved via the association.

4.3.2 IsOfTypeChange

If the type of a TypedElement is changed to a type which is not a supertype of the former type, thequery becomes invalid. This cannot be resolved automatically since the semantics of a type changeare sometimes ambiguous. For example, a TypeChange on an AssociationEnd element would cause achange in the from-clause of a query which includes a navigation over this association. However, it is notpossible to determine which the new type of the from-clause should be, since it could be the type of theAssociationEnd itself or one of its subtypes, and for each of these, subtypes could be included or not.

4.3.3 ContainsChange

For containment, the same is true as described in Subsection 3.3: The query will only become invalid ifthe affected element cannot be resolved after a containment change. If the element is still resolvable, thequery can be executed normally.

4.3.4 GeneralizationChange

The change of generalization can lead to queries becoming invalid if associations or features are accesedin the course of the query. If generalization between two classes is removed, a selection of elements of asubclass of the association end’s type will no longer be valid in the new metamodel version. This is thesituation of Figure 9 on page 16, for which a critical query can be seen in Figure 15 below. The removalof the generalization makes the query invalid because the type SubType1 does not have a reference orassociation end called endB. The same is the case for attributes that are inherited from a superclass: Ifthe generalization is removed, the query will become invalid if it accesses the attribute.

Type1

SubType1

Type2Query:select s1 from SubType1 as s1, Type2 as t2

where s1.EndB = t2

M2

Assoc1x2

endA endB

Figure 15: Query visibility: Deleting generalization with association

5 JMI INTERFACES 24

5 JMI Interfaces

The primary means for access and manipulation model data in MOIN is the Java Metadata Interface(JMI). If changes are applied to underlying metamodels, the structure of these interfaces is also changed,possibly causing incompatibilities with existing tools using these interfaces. The compatibility for thoseinterfaces is determined by Java type compatibility.32

Thus, we will investigate the impact of the change types defined in Section 3 on the Java typecompatibility of the generated interfaces.

The generation of interfaces from metamodels is a process which is currently implemented as a JMIGenerator within MOIN. The generation logic lies in the actual Java implementation of the generatorservice, which makes it difficult to describe the impact of metamodel evolution on the generated interfaces.

In this section, an alternative approach of JMI generation is presented: In order to describe the struc-ture of generated JMI interfaces, a JMI metamodel is introduced (see Figure 16). Using this metamodel,the generation of JMI interfaces can be described as a model transformation from MOF to the JMImetamodel, using a Transformation Metamodel (see Figure 20). The actual generation of Java classes canthen be performed in a relatively simple process which is more or less a serialization of the JMI modelinstances.

For the description of the change impact on JMI interface, we will first describe the severities of changesin JMI metamodel instances; then, a description of the effect of metamodel changes on JMI metamodelinstances will follow. The combination of these two mappings delivers the impact of metamodel changeson the interfaces; this is presented as an overview table in Appendix A.

5.1 JMI Metamodel

5.1.1 Structure

The JMI metamodel contains main classes which resemble the reflective interfaces of the JMI specification.These classes are:

• JmiBaseObject

• JmiObject

• JmiClass

• JmiPackage

• JmiAssociation

• JmiStruct

• JmiEnum

Each class represents a reflective interface: JmiObject represents RefObject, JmiClass represents RefClass and so on.33 Instances of these “core” classes of the JMI metamodel are converted into actual Javaclasses in a generation step. All other instances of JMI metamodel classes are converted to methods,fields, comments or import statements, which are contained in the Java classes and are not classes oftheir own.

32When talking about Java type compatibility in this thesis, we refer to source compatibility, not binary compatibility.33As a consequence of the self-descriptive nature of MOF, the reflective classes are themselves used as the single supertype

if no other supertypes are specified for a JmiObject or JmiPackage element. In a pure modeling approach, this would be ajump between two modeling layers, which, on the other hand, is the idea behind reflection in Java. To represent this aspectof JMI design, the JMI Reflective Package is introduced in the next subsection.

5 JMI INTERFACES 25

5.1.2 Design Decisions

5.1.2.1 LinksThe JMI metamodel itself does not contain links to the original MOF classes to which the JMI

objects correspond; this connection is established by the Transformation Metamodel (see next section).Also, classes which belong together semantically do not necessarily have a link in the metamodel, e.g.JmiObject and JmiClass. This is due to the fact that the Java interfaces, in this example, do not havea direct connection; nevertheless, the corresponding RefClass can be obtained for any RefObject viathe reflective interface of JMI. The idea behind this JMI metamodel is to represent the structure of thegenerated interfaces rather than their semantical behaviour. In order to discover the semantics of theinterfaces, the original metamodel classes can be accessed by the links of the Transformation Metamodel.

5.1.2.2 InheritanceThe inheritance structure for the generated interfaces was only modeled in the points where the struc-

ture is dependant from the metamodel layout. This is why there are classes that model the inheritance ofinstance interfaces and packages (ExtendsObjectStatement and ExtendsPackageStatement), but nonefor the class proxy and association interfaces. The reason for this can be seen in Figure 3 on page 5: Thegeneralization structure of metamodels is only created for classes and packages on the Java side, but notfor associations and class proxies; these interfaces always have the implicit supertypes RefAssociation

and RefClass respectively.

5.1.2.3 ExceptionsExceptions are only modeled if they are part of the source metamodel. Most standard JMI operations

throw a javax.jmi.reflect.JmiException. However, this was not modeled since it is a static propertyof every generated interface class, and as such, it can be included in the actual serialization process.

5JM

IIN

TE

RFA

CE

S26

JmiBaseObject

packageName:String

className:String

JmiObject JmiClass

JmiAssociation JmiPackage

JmiEnum

labels:StringJmiStruct

JmiExceptionname:String

JmiPrimitiveType

JmiOperationname:String ExceptionConstructor

ParameterAccessor

JmiReference

JmiAnnotation

text:String

JmiConstant

name:String

values:String

ReferenceAccessor

ReferenceMutator

JmiAttribute

AttributeAccessor

AttributeMutator

ModeledOperation

ElementCreator

DefaultCreator

SpecificCreator

StructCreator

LinkExists

LinkAdd

LinkRemove

End1Accessor

End2Accessor

NestedImportedAccessor

AssociationAccessor

ClassProxyAccessor

ExtendsPackageStatement

ExtendsObjectStatement

«enumeration»ParameterMultiplicitySINGLE

SET

LIST

JmiParameter

«reference» type:JmiBaseObject

name:String

multiplicity:ParameterMultiplicity

1..*

1 *

extendsStatement1..*

1object

*

type

1

type

throwsinput*

{ordered}

return0..1

11

*

Figure 16: The JMI metamodel

5 JMI INTERFACES 27

5.1.3 JMI Primitive Types Package

The MOF specification defines six primitive types: Boolean, String, Integer, Double, Float and Long.These types are mapped to the Java types of the same name. In order to be able to express this relationshipin the terms of the JMI metamodel, these Java types are modeled as instances of JmiPrimitiveType

here. They can be used by any instance of the JMI metamodel by importing the primitive types package.

Boolean(from PrimitiveTypes)

String(from PrimitiveTypes)

Integer(from PrimitiveTypes)

Double(from PrimitiveTypes)

Float(from PrimitiveTypes)

Long(from PrimitiveTypes)

JmiBoolean :JmiPrimitiveType

JmiString :JmiPrimitiveType

JmiInteger :JmiPrimitiveType

JmiDouble :JmiPrimitiveType

JmiFloat :JmiPrimitiveType

JmiLong :JmiPrimitiveType

:PrimitiveTypeTransformation






MOF primitive types Transformation JMI primitive types

source

source

source

source

source

source

target

target

target

target

target

target

Figure 17: The JMI primitive type package

5.1.4 JMI Reflective Package

The purpose of the reflective interfaces in the JMI specification is twofold: On the one hand, the reflectiveinterfaces are direct or indirect supertypes of each generated JMI interface, with the topmost type Ref

BaseObject (See Figure 3 on page 5). Secondly, the reflective interfaces hold methods which allow thegaining of meta-information on the JMI objects, such as an object representation of an elements meta-object, its MOFid or for the verification of model constraints. These reflective interfaces are representedas the elements of the reflective package in the JMI metamodel, as seen in Figure 18.

RefObject :JmiObject

RefClass :JmiClass

RefPackage :JmiPackage

Figure 18: The JMI reflective package

5 JMI INTERFACES 28

MOF-basedmetamodel

Transformationmetamodel instance

JMI metamodelinstance

GeneratedJava code

Type1

Type2

:ClassTransformation

:ClassTransformation

:JmiObjectname="Type1"

:ExtendsObjectStatement

:JmiObjectname="Type2"

public interface Type1extends RefObject {...}

public interface Type2extends Type1 {...}

Figure 19: MOF to JMI transformation process

5.2 JMI Transformation Metamodel

5.2.1 Design

The transformation from metamodels to instances of the JMI metamodel is described by an algorithmwhich contains the single steps of the transformation. In order to be able to associate the generated JMImodel elements with the metamodel elements from which they were created, a Transformation Metamodelis used, which can be seen in Figure 20. The metamodel itself is quite simple and does not have a complexstructure; it is merely used to model the 1:1 associations34 between the different MOF and JMI elements.

The consistency requirements for the MOF-to-JMI transformation are described in Appendix B.3.2.These constraints describe much of the transformation semantics originating from the JMI specification[JMI02] itself; hence, they are not repeated here.

For the generation of a JMI metamodel instance, a certain order of generation should be kept; other-wise, the elements could not be generated completely in one step, since references to elements which donot exist yet would not be instantiated. This is why the transformations should be performed in the waywhich is described in the next section.

5.2.2 Transformation process

The transformation of a MOF-based metamodel into a JMI metamodel instance is the critical step in theMOF-to-JMI transformation described in this section. All logic of the generation lies in this step, andthe second transformation step seen in Figure 19 should be understood as a serialization of instances ofthe JMI metamodel.

The process is written in a pseudocode notation here; for a formal definition, OCL constraints arelisted in the appendix. In the pseudocode notation, a phrase like “Element e1 in Element e2” meansthat the elements are linked by an instance of the Contains association. The transformation process isdescribed as a procedure which takes the outermost package of the elements to be converted as an inputparameter.

34With one exception: Class maps to two interfaces, namely the instance interface JmiObject and the class proxy interfaceJmiClass.

5 JMI INTERFACES 29

procedure ConvertMofToJmi(Package p)create JmiPackage pjmi

create PackageTransformation tPackage

tPackage.source← p

tPackage.target← pjmi

for all Class c in p do . create classes and proxiescreate JmiObject ojmi

create JmiClass cjmi

set ojmi.name according to [JMI02], section 4.7.2cjmi.name← ojmi.name + "Class"create ClassTransformation tClass

tClass.source← c

tClass.target← ojmi

tClass.classProxyTarget← cjmi

for all Enumeration e in p do . create enumeration typescreate JmiEnum ejmi

ejmi.name← e.name

ejmi.labels← e.labels

create EnumTransformation tEnum

tEnum.source← e

tEnum.target← ejmi

for all StructureType s in p do . create structure typescreate JmiStruct sjmi

create StructTransformation tStruct

tStruct.source← s

tStruct.target← sjmi

create StructCreator cStruct and parameterscStruct.container← s.container.transformation.target

for all Class c in p do . create generalization hierarchyif c.supertype is empty then

create ExtendsObjectStatement s

c.extendsStatement.add(s)s.object← JmiReflectivePackage::RefObject

elsefor all Class csuper in c.supertype do

create ExtendsObjectStatement s

c.extendsStatement.add(s)s.object← csuper

create DefaultCreator d . create class constructord.container← c.transformation.classProxyTarget

create input and output parameterscreate ClassProxyAccessor and parameters in psub

for all Reference r in c do . create referencescreate JmiReference rjmi

create ReferenceAccessor accReference and parameters . respect multiplicity, isOrderedif r.multiplicity.upper = 1 and r is changeable then

create ReferenceMutator and parameters

rjmi.container← r.container.transformation.target

for all Attribute a in p do . create attributescreate JmiAttribute ajmi

create AttributeAccessor acc

set name according to [JMI02], section 4.8.5 . booleans with is, others with get

acc.container← a.container.transformation.target

create return parameterif a.isChangeable then

5 JMI INTERFACES 30

create AttributeMutator mAttr

mAttr.container← a.container.transformation.target

create input parameters

for all Operation o in p do . create modeled operationscreate ModeledOperation m

create output parameterfor all parameter pin of o with direction = in_dir do

create input parameters

create OperationTransformation tOperation

tOperation.source← o

tOperation.target← m

for all Association a in p do . create associationsif ignoreLifeCycle = false then

create JmiAssociation ajmi

create LinkExists and parametersif End1 of a is navigable then

create End1Accessor and parameters in ajmi . respect multiplicity, isOrdered

if End2 of a is navigable thencreate End2Accessor and parameters in ajmi

if End1 and End2 are changeable thencreate LinkAdd and parameters in ajmi

create LinkRemove and parameters in ajmi

create AssociationTransformation tAssoc

tAssoc.source← a

tAssoc.target← ajmi

create AssociationAccessor and parameters in pjmi

for all Package psub in p do . package operationsConvertMofToJmi(psub)create NestedImportedAccessor and parameters in pjmi

if p.supertype is empty then . create package hierarchycreate ExtendsObjectStatement s

c.extendsStatement.add(s)s.package← JmiReflectivePackage::RefPackage

elsefor all Class psuper in p.supertype do

create ExtendsPackageStatement s

p.extendsStatement.add(s)s.package← psuper

for all element e in p do . create annotationsif e.annotation not empty then

create JmiAnnotation ajmi

ajmi.text← e.annotation

ajmi.container← a.container.transformation.target

5 JMI INTERFACES 31

5.3 Changes in JMI Interfaces

In this subsection, the changes in the interfaces are described, using the JMI metamodel. For thedescription of the changes to JMI interfaces, the severities from Subsection 3.3 are used.


The deletion of an element semantically corresponds to the deletion of a Java interface or parts of it, suchas variables, methods or method parameters. In general, the deletion of an element is breaking and notresolvable, since existing tools which access the interface may rely on these elements. If they are missingafter a change to the metamodel, code will break and cannot be resolved without knowledge about thesemantics of the change.

The severity of an addition of an element depends on the type of the element. It is described in detailin the following paragraphs.

5.3.1.1 JmiBaseObject

add Adding a JmiBaseObject also results in the addition of a new Java interface class. This doesnot make any of the existing method calls invalid, so the change is non-breaking.

delete If an element is deleted, existing code that refers to this element become invalid. This changeis breaking and not resolvable.

5.3.1.2 JmiParameter

If a parameter is added to or deleted from an operation, the calls to the resulting Java methods willbe invalid because of the different numbers of parameters. However, this can be resolved automaticallyby changing these method calls in a way that all new parameters are set to the null value. Thus, thechange is breaking and resolvable.

5.3.1.3 ExtendsObjectStatement

add The addition of a superclass is additive if seen from the perspective of the generated interfaces.So the change is non-breaking.

delete If an extends statement is deleted, which is semantically the removing of a superclass, theinterface loses features, e.g. methods which are inherited from the superclass. If existing calls to theinterface access these features, they will be invalid with the new version of the interface. Thus, thechange is breaking and not resolvable.


5.3.2.1 nameA name change leads to a refactoring process in the interfaces, which can be performed automatically

using a transformation model instance which connects to the metamodel. From there, the original nameof the element can be retrieved from a change metamodel instance and refactoring can be performed, sothe change is breaking and resolvable.

5.3.2.2 typeIf the type of a parameter is changed, there are two cases which have to be distinguished:

• If the parameter is an input parameter, the severity is only non-breaking if the new type is asupertype of the old type. For all other cases, the change is breaking and not resolvable.• For a return parameter, the case is similar, but for the opposite direction in the type hierarchy: If

the new type is a subtype of the old type, the change is non-breaking, in all other cases, it is breakingand not resolvable.

5.3.2.3 multiplicity

If the multiplicity of a parameter is changed, the severity depends on the parameter direction and thekind of the change:

5 JMI INTERFACES 32

Class(from Model)

ClassTransformation

JmiObject(from JmiMetamodel)

JmiClass(from JmiMetamodel)

Package(from Model)

PackageTransformation

JmiPackage(from JmiMetamodel)

Association(from Model)

AssociationTransformation

JmiAssociation(from JmiMetamodel)

Enumeration(from Model)

EnumTransformation

JmiEnum(from JmiMetamodel)

StructureType(from Model)

StructTransformation

JmiStruct(from JmiMetamodel)

Attribute(from Model)

AttributeTransformation

JmiAttribute(from JmiMetamodel)

Reference(from Model)

ReferenceTransformation

JmiReference(from JmiMetamodel)

Operation(from Model)

OperationTransformation

JmiOperation(from JmiMetamodel)

Constant(from Model)

ConstantTransformation

JmiConstant(from JmiMetamodel)

PrimitiveType(from Model)

PrimitiveTypeTransformation

JmiPrimitiveType(from JmiMetamodel)

Exception(from Model)

ExceptionTransformation

JmiException(from JmiMetamodel)

source transformation

1..1 1..1

transformation

target1..1

1..1

transformation classProxyTarget

1..1 1..1


1..1 1..1

transformation target

1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1


1..1 1..1

Figure 20: The transformation metamodel

5 JMI INTERFACES 33

For all kinds of parameters, change from SINGLE to SET or LIST is breaking and resolvable, since theJava type of the interface will change from a singular object type to collection type and vice versa; this canbe resolved by adapting the code of the tool which is using the interface. For changes between unordered(SET) an ordered collections (LIST), the direction of the parameter has to be taken into account:

If the multiplicity on an input parameter is changed from LIST to SET, the change is non-breaking,since the Java type java.util.List is a subtype of java.util.Collection. In the other direction, thechange is breaking and resolvable.

With a return parameter, the case is dual to the above mentioned: change from SET to LIST isnon-breaking, change from LIST to SET is breaking and resolvable.

5.3.2.4 label

If the labels of a JmiEnum interface are changed35, existing code which tries to access these labels willbreak, so this change is breaking and not resolvable.

5.3.3 LinkChange

5.3.3.1 ContainsIn this paragraph, the possible link changes are sorted by the type of the contained element.JmiOperation If an operation is moved to another container, the position of the new container in the

supertype hierarchy of the old container is the only relevant criterion: If the new container is a supertypeof the old container, the change is non-breaking. Otherwise, calls to this operation will become invalid,which makes the change breaking and not resolvable, unless a similar operation, i.e. with same name andcompatible signature,36 is created and added to the old container.

JmiAttribute/JmiReference/JmiConstant The severity for these elements is identical with JmiOp

eration.JmiAnnotation Annotations are represented as comments in the Java code and are such not relevant

for compatibility, so these changes are always non-breaking.

5.3.3.2 Throws

If an operation is altered in the number of kind of exceptions it throws, the change is breaking and notresolvable since existing code could try to handle exactly the kind of exceptions specified. If a modeledoperation does not contain modeled exceptions, the type javax.jmi.reflect.JmiException is addedto the throws statement to the interface, which is incompatible with the common supertype of modeledexceptions, javax.jmi.reflect.RefException.

5.4 Assignment of MOF Changes to JMI Changes

In this subsection, the changes in MOF-based metamodels are assigned to changes in the JMI metamodel,for which the severities have been described above. Using this assignment, the impact of metamodelchanges on the generated JMI interfaces can be determined. An overview of the metamodel changes antheir impact can be seen in Appendix A.


5.4.1.1 Class

add A new JmiObject an a new JmiClass element is created. The JmiObject instance is linkedto RefObject via a newly created ExtendsObjectStatement. Two ElementCreators are created in theJmiClass element. A ClassProxyAccessor is created in the containing JmiPackage element.

delete The above mentioned elements are deleted.35Which would be described in the change metamodel as a MultivaluedStringChange on the property labels of an

JmiEnum36I.e. the same number of parameters, of which every single parameter is of the same type or a supertype as the parameter

at the this position in the old operation.

5 JMI INTERFACES 34

5.4.1.2 Attributeadd A new JmiAttribute element is created, with the adjacent AttributeAccessor and Attribute

Mutator elements. For the containing JmiObject element, the corresponding ElementCreator is modifiedin a way that it is assigned a new input parameter, i.e. a new JmiParameter element is created, with thetype equal to the new attribute’s type’s JMI representation.

delete The JmiAttribute, AttributeAccessor and AttributeMutator elements and the JmiPa

rameter element are deleted.

5.4.1.3 Associationadd A new JmiAssociation element is created with its contained operations, depending on the

properties of the original Association element: For each of the two AssociationEnd elements, theelements End1Accessor and End2Accessor are created if the isNavigable property is set to true. Thetypes and multiplicities of these elements must match those of the original MOF elements. If for bothends, the isChangeable property is true, the LinkAdd and LinkRemove operations are created. A newAssociationAccessor element is created in the respective JmiPackage.

delete The above mentioned elements are deleted.

5.4.1.4 AssociationEndSince an association end cannot exist without an association in which it is contained, the effects of

addition and deletion are those described in the paragraph above.

5.4.1.5 Reference

add A new JmiReference object and a ReferenceAccessor element are created. If the Reference

element has the property isChangeable and is single-valued, a ReferenceMutator element is also created.delete The above mentioned elements are deleted.

5.4.1.6 Packageadd A JmiPackage element is created. If it is nested in another package, a NestedImportedAccessor

element is created.delete The above mentioned elements are deleted.

5.4.1.7 Importadd A NestedImportedAccessor is created and added to the corresponding container package ele-

ment.delete The above mentioned element is deleted.

5.4.1.8 Tag

For the special tags javax.jmi.packagePrefix, javax.jmi.methodPrefix andjavax.jmi.substituteName, changes to several elements occur. If the package prefix changes, all ele-ments whose transformation source lies in the affected package are changed in the property packageName.If the substitute name is changed, the element which was transformed from the element which containsthe tag will be changed in the property className. The method prefix affects the className of elementsof the type ModeledOperation which lie in the containment of the package that contains the tag.

5.4.1.9 Constraint

Changes in constraints do not have an effect on the generated interfaces.

5.4.1.10 Operation

add A new ModeledOperation element is created.delete The above mentioned element is deleted.

5 JMI INTERFACES 35

5.4.1.11 Exceptionadd A new JmiException element is created with the contained ExceptionConstructor and Pa

rameterAccessor elements.delete The above mentioned elements are deleted.

5.4.1.12 Parameteradd A new JmiParameter element is created. Its type property is set to the transformation target

of the original Parameter element’s type.delete The above mentioned element is deleted.

5.4.1.13 DataType

add For EnumerationType, StructureType or PrimitiveType, a new JmiEnum, JmiStruct or JmiPrimitiveType element is created. In the case of JmiStruct, AttributeAccessor elements are created forevery field of the structure type.

delete The above mentioned elements are deleted.

5.4.1.14 StructureField

add A new AttributeAccessor element is added to the containing JmiStruct element.delete The AttributeAccessor element is removed from the containing JmiStruct and is deleted.


5.4.2.1 ModelElement

name If no javax.jmi.substituteName tag is specified, the element’s className will change.annotation The property text of the contained JmiAnnotation element is changed.

5.4.2.2 GeneralizableElementisRoot/isLeaf A change in this property does not have an effect on the JMI interfaces.isAbstract If this property is set to true, no ElementCreator is generated in the proxy class Jmi

Class of the element. So a change from true to false causes the creation of the ElementCreator

operation, a change from false to true causes the deletion of that element.visibility The JMI interface classes are only created for elements with visibility public_vis. This

means that a change to public visibility causes the creation of the respective classes, so the impact isequal to an additive ExistenceChange. If the visibility is changed from public to protected or private,the impact on the interfaces is equal to the deletion of the element.

5.4.2.3 Association

isDerived A change in this property does not have an effect on the JMI interfaces. See [JMI02,Chapter 4.2.5].

5.4.2.4 ClassisSingleton The singleton semantics of a class only have an impact on the runtime behaviour of the

generated JMI objects and do not influence the layout of the interfaces.

5.4.2.5 TagIf the field tagID is one of the the following:

• javax.jmi.packagePrefix

• javax.jmi.methodPrefix

• javax.jmi.substituteName

a change in the property values has the same effect as the addition or deletion of these tags.

5 JMI INTERFACES 36

5.4.2.6 ConstraintA change of properties of this type does not have an effect on the JMI interfaces.

5.4.2.7 Featurescope The accessors and mutators for features for the instance interfaces are generated in every case,

so there is no change if the scope is changed. However, for the class proxies, the accessors and mutatorsare only created if the value is classifier_level. If this is changed to instance_level, the effect is thedeletion of the accessors and mutators contained in the JmiClass objects; if an instance-scoped featureis changed to classifier-scoped, the effect is the creation of these elements.

visibility As with GeneralizableElement, only elements with visibility level public_vis are gen-erated, so the effects of changing a public feature to non-public are the same as for the deletion of thatfeature; if a non-public feature is made public, the effects are the same as for the creation of that element.

5.4.2.8 StructuralFeature

multiplicity The impact on interfaces only depends on the field upper and the isOrdered property.If upper is changed from >1 to 1 or vice versa, the property multiplicity in the corresponding Jmi

Parameter element will change between SINGLE, SET or LIST. If the isOrdered property is changed, themultiplicity will change between SET and LIST.

isChangeable This parameter controls the generation of mutator methods in the interfaces. If it isset to false, no mutators are generated. So a change from true to false causes the deletion of themutators, a change from false to true causes their creation.

5.4.2.9 OperationisQuery A change in this property does not have an effect on the JMI interfaces.

5.4.2.10 Constraintvalue A change in this property does not have an effect on the JMI interfaces.

5.4.2.11 Parameter

direction If the direction of a parameter is changed, the link between JmiParameter to JmiOperationis changed between return and input.

multiplicity This change alters the feature multiplicity of a JmiParameter in the same way asdescribed for StructuralFeature.

5.4.2.12 AssociationEndisNavigable This parameter defines whether the accessors for a JmiAssociation are created. So a

change in this value leads to the creation or deletion of End1Accessor or End2Accessor elements.aggregation The aggregation semantics of model only have an impact on the runtime behaviour of

the generated JMI objects and do not influence the layout of the interfaces.multiplicity This change alters the feature multiplicity of the association end accessors in the

same way as described for StructuralFeature.isChangeable The creation of LinkAdd and LinkRemove elements is controlled by this parameter.

5.4.2.13 EnumerationTypelabel This change alters the attribute labels of the corresponding JmiEnum element.

5.4.3 LinkChange

5.4.3.1 Contains

A change in containment in a MOF model is reflected in various ways in a JMI model. The singlecases are mentioned below, sorted by the type of the contained elements.

Class Changes the containment of ClassProxyAccessor elements.Package Changes the containment of NestedImportedAccessor operations.

5 JMI INTERFACES 37

Association Changes the containment of AssociationAccessor operations.Feature Changes the containment of ReferenceAccessor, ReferenceMutator, AttributeAccessor

and AttributeMutator operations.Operation Changes the containment of ModeledOperation elements.Constant Changes the containment of JmiConstant elements.Parameter affects the links between JmiParameter and JmiOperation.Constraints A change in the containment of constraints does not have an effect on the JMI interfaces.Tags A change in the containment of tags depends on the nature of the tag; see Paragraph 5.4.2.5.

5.4.3.2 Generalizes

Class A change in the generalization hierarchy of classes alters the links between the ExtendsOb

jectStatement elements an the JmiObject elements involved.Package The case is the same as described above, for ExtendsPackageObject and JmiPackage

elements.

5.4.3.3 IsOfType

This change alters the type links between JmiParameter elements and the elements used as the type.

5.4.3.4 RefersTo

A change in this association does have a direct effect on the generated interfaces; however, the changecan cause further modifications to the MOF model instance to ensure the metamodel consistency, whichmay also have an impact on the generated interfaces.

5.4.3.5 CanRaiseThis change alters the throws links between JmiOperation and JmiException elements.

6 EXAMPLE 38

6 Example

In this section, the process of metamodel evolution is shown for a small example metamodel. Firstly, thechange to the metamotel is described, then, the severities for existing M1 data are determined, includinga detailed explanation of the determination process. The generation of a JMI metamodel instance andthe Java interfaces is shown an overview diagram on the following pages.

6.1 Description

The example used here is similar to the example in Figure 8 on page 16. It consist of a single class Type1with a single Integer typed attribute attr1. The modification includes the addition of a new class, Type2,and the relocation of the attribute to this new class.37

Package1

Type1

attr1:int [1..1]

Package1

Type2

attr1:int [1..1]

Type1

Version 1 Version 2

Figure 21: Example metamodel

This change is described using instances of the change metamodel, as seen below. Change1 describesthe addition of Type2, and Change2 represents the addition of the generalization link. The “relocation”of attr1 is described as a removal from its container in Change3 and an addition to the new containerin Change4.

Change1 : ExistenceChange

kind=ADD

affectedElement=Type2

Change3 : ContainsChange

kind=DELETE

container=Type1

containedElement=attr1

Change2 : GeneralizesChange

kind=ADD

superElement=Type2

subElement=Type1

Change4 : ContainsChange

kind=ADD

container=Type2

containedElement=attr1

Figure 22: Change steps as Change Metamodel instances

37The containment of an Attribute element in a Class element is technically represented as an instance of the MOFmodel association Contains. In the UML diagram, it is not depicted as a new frame with a line connection, but as a textfield in the frame representing the Class element.

6 EXAMPLE 39

6.2 Severities regarding M1 instances

6.2.1 Single Changes

Change1 The addition of a Class element is non-breaking according to severity constraint [SC-1] onpage 55.

Change2 The determination of the severity of this change is a bit more complex. If we look at severityconstraint [SC-6] on page 57, we see that for an additive change, we have to check for mandatory featuresin the supertypes, meaning attributes or references which have a lower multiplicity greater than zero. Inour example, the only supertype is Type2, and a check for mandatory features yields attr1.38 So theaddition of the generalization link would be breaking and not resolvable since for instances of the subtypeType1, the attribute attr1 may not be set. But in Version 1, the subtype of the new generalization linkcontains an attribute which is similar to attr1 (which means that it is at least identical in name, typeand multiplicity; in this case, it is even the identical element), so the change is non-breaking.

Change3 The severity of a containment change is described in severity constraint [SC-5] on page 56:Since the element which is removed from its container is added to a new container which is a supertypein the new generalization hierarchy, all instances of Type1 will still be valid as far as attr1 is regarded,and so the severity of this change is non-breaking.

Change4 The same constraint specifies that the addition of a mandatory feature is non-breaking ifthe new container has been added in the course of the change sequence, since then there can be noinstances of this element which could become invalid because of a missing attribute value. If the newcontainer had been existant before, the change would have been breaking and not resolvable.

6.2.2 Overall

The overall severity of this change can now be easily determined by calculating the maximum of all singleseverities, since the determination of single severites is based on all changes which occur within the changesequence. So the overall severity of this change sequence is also non-breaking.

6.3 Severities regarding Queries

Since the overall severity for M1 data is non-breaking, all queries will still be valid after the change to thenew version. Since the example is quite minimal, there are not many possible kinds of queries. The onlypossible query that includes an attribute would look like the following statement:

select t1.attr1 from Type1 as t1

The result of this query is unchanged after a change in the metamodel, since no subclasses are addedto classes that already exist in Version 1 of the metamodel.

6.4 Transformation into JMI model instance

The example metamodel is transformed according to the transformation process described in Subsec-tion 5.2.2. The generated instance of the JMI metamodel is connected to the example metamodel via aninstance of the transformation metamodel, in our example, instances of the classes PackageTransformation and ClassTransformation. The transformed model and the generated code can be seen in 6.5.2and Figure 6.5.2.

According to Subsection 5.4, the single changes have the following effects on the generated JMI model:

• Change1 causes the creation of a JmiObject and a JmiClass element, in this case Type2 andType2Class, and also the ExtendsObjectStatement element with a link to RefObject.

• Change2 causes the alteration of the object link of the ExtendsObjectStatement of Type1, whichis changed from RefObject to Type2.

38The constraint requires us to check for features which exist after all changes of the sequence which the current changeis part of.

6 EXAMPLE 40

• Change3 causes the deletion of the containment link between the JmiObject interface of Type1 andthe JmiAttribute element representing attr1.

• Change4 causes the creation of a containment link between the JmiObject interface of Type2 andthe JmiAttribute element representing attr1.

The resulting JMI model has to fulfill the transformation constraints from Appendix B.3.2.

6.5 Severities regarding JMI interfaces

6.5.1 Single Changes

In this subsection, the changes in the JMI interfaces of the example are assigned to the change severitiesaccording to Subsection 5.3.

Change1 This change is purely additive, so the severity is non-breaking.Change2 The rerouting of the containment link augments the set of superclasses: The former su-

pertype RefObject is still included since the new superclass Type2 is also a subclass of RefObject. Sothe change is additive and non-breaking.

Change3 This change in containment would be breaking if it happened in isolation from otherchanges. But since the removed element is added to an element which is a superclass of the formercontainer, the change is non-breaking.

Change4 As an additive operation, this change is non-breaking.

6.5.2 Overall

The overall severity is determined as the maximum of all single changes, which results in the severity typenon-breaking for this example. This means that all applications which use the generated JMI interfaceswill still be compatible in terms of Java source compatibility after the changes of this example.

6 EXAMPLE 41

MetamodelPackage1

Type1attr1:int [1..1]

javax.jmi.packagePrefix="mof.test"

:PackageTransformation :ClassTransformationTransformation Model

JMI Model

:JmiPackagepackageName="mof.test.package1"

className="Package1Package"

:JmiClasspackageName="mof.test.package1"

className="Type1Class"

:JmiObjectpackageName="mof.test.package1"

className="Type1"

:ExtendsPackageStatement

RefPackage(from JmiReflectPackage)

:ClassProxyAccessorname="getType1Class"

:JmiParametermultiplicity=SINGLE

:SpecificCreatorname="createType1"


:JmiParametername="attr1"

multiplicity=SINGLE

:DefaultCreatorname="createType1"


JmiInteger(from JmiPrimitivePackage)


RefObject(from JmiReflectPackage)

:JmiAttribute

:AttributeAccessorname="getAttr1"

:AttributeMutatorname="setAttr1"


:JmiParametername="newValue"

multiplicitiy=SINGLE

transformation

source

transformation

source

transformation

target

transformation

classProxyTarget

transformation

target

extendsStatement

package

return

type

return

type

return

type

input

type

extendsStatement

object

type

type

return

input

package mof.test.package1

public interface Package1Package extends javax.jmi.reflect.RefPackage {

public Type1Class getType1Class();

}


public interface Type1Class extends javax.jmi.reflect.RefClass {

public Type1 createType1();

public Type1 createType1(int attr1);

}


public interface Type1 extends javax.jmi.reflect.RefObject {

public int getAttr1();

public void setAttr1(int newValue);

}

Figure 23: Example metamodel, Version 1

6 EXAMPLE 42

Metamodel

Package1

Type2attr1:int [1..1]

Type1

javax.jmi.packagePrefix="mof.test"

:PackageTransformation :ClassTransformation :ClassTransformationTransformation Model

JMI Model

:JmiPackagepackageName="mof.test.package1"

className="Package1Package"




className="Type1"

:ExtendsPackageStatement

RefPackage(from JmiReflectPackage)






multiplicity=SINGLE





className="Type2"










RefObject(from JmiReflectPackage)


multiplicity=SINGLE

:JmiAttribute

:AttributeAccessorname="getAttr1"

:AttributeMutatorname="setAttr1"


:JmiParametername="newValue"

multiplicitiy=SINGLE

JmiInteger(from JmiPrimitivePackage)

transformation

source

transformation

source

transformation

source

transformation

target

transformation

classProxyTarget

transformation

target

extendsStatement

package

return

type

return

type

return

input

type

type

input

type

extendsStatement

object

type

type

return

input

object

extendsStatement

transformation

classProxyTarget

transformation

target

return

type

return

type

return

type

Figure 24: Example metamodel, Version 2

6 EXAMPLE 43


public interface Package1Package extends javax.jmi.reflect.RefPackage {



}





}





}


public interface Type1 extends mof.test.package1.Type2 {

}


public interface Type2 extends javax.jmi.reflect.RefObject {

public int getAttr1();

public void setAttr1(int newValue);

}

Figure 25: JMI interfaces of example metamodel, Version 2

7 RELATED WORK 44

7 Related Work

Software evolution is a topic which has been researched intensely. The fields of this research include theevolution of programs, database schemas and models. However, the MOF standard does not include aspecification for versioning, and thus the description of evolution of metamodels. In the MOF standard,it is suggested that this be included in an eventual implementation of a MOF repository.

7.1 MOF repositories

Besides the MOIN project at SAP, there are also other implementations of a MOF repository, mostlyin the academic field. The most popular commercial implementation is the Metadata Repository Project(MDR), which is part of Sun’s NetBeans platform. MDR offers features that ease the integration into thedevelopment envirionment, but it can also be used independently from the NetBeans IDE. It implementsMOF 1.4, JMI and XMI and has a persistence layer which supports SQL databases, file persistence andtransient memory persistence. It also features a graphical tool to explore the contents of the metadatarepository. MDR is being developed as open source software.

At Humboldt University in Berlin, a repository has been developped in the course of the A MOFproject [Sch05]. It is based on MOF 2.0 and implements the sub-model CMOF. A MOF also includesa Java API of its own, rather than using JMI, and concentrates on easy development using meta-datarather than the storage of meta-data. Therefore, it only supports non-persistent model storage, which,together with the lack of JMI, distinguishes it from the repositories mentioned beforehand. However, AMOF supports the XMI standard for interchange with other modeling environments.

The University of Darmstadt also runs a MOF 2.0 repository project, called MOFLON [AKRS06].It is equipped with a graphical editor for metamodelling and also supports JMI and XMI. MOFLONsupports OCL via the Dresden OCL compiler and also features the specification of integration patternsvia a declarative QVT notation. The behaviour and transformation of models can be specified in thegraphical editor with UML diagrams, from which Java code is generated automatically.

7.2 Metamodel Evolution

The general process of Model Transformation targets the conversion of model data which is based on acertain metamodel into a model which is based on another metamodel. If two versions of a metamodelare used as these source and target metamodels, metamodels can be described by means of model trans-formation. For MOF, a transformation description language is defined in the Query/View/Transformation(QVT) standard [QVT07]. However, the QVT standard has not been widely adopted; furthermore, it isbased on MOF 2.0, while this thesis is based on version 1.4. Since QVT and MOF 2.0 are not supportedin MOIN, QVT was not used to describe the transformation steps in the evolution process and JMIconversion in this thesis.

For the concurring metamodeling standard Eclipse Modeling Framework (EMF), a change meta-modelis defined that follows a different concept than the one presented in this thesis. The EMF changemetamodel is far smaller in size, and much more general. It basically describes one single element whichrespresents changes to all kinds of elements from the Ecore metamodel. Since EMF lacks a comprehensivespecification document, more information about the EMF change metamodel can best be obtained bydownloading the model definition sources on the Eclipse homepage.39

An approach for the classification of metamodel evolution cases based on EMF has been described byBecker et al. in [BGGK07]. The basic concept of the three change severities used in this thesis is definedthere. Although based on EMF and Ecore, Becker et al. reject the EMF change metamodel for beingtoo general for their purposes and propose its refinement. Since such a refinement is not presented in

39http://www.eclipse.org/emf

http://www.eclipse.org/emf

7 RELATED WORK 45

the work, the focus lies on the procedural model for the migration of model data and a classification ofchanges based on the Ecore metamodel.

Finding the difference of two models is a well-known problem; an algorithm for the determina-tion of deltas for any kind of hierarchically structured information is described by Chawathe et al.in [CRGMW96]. The authors use graphs for the representation of data and use graph transformationrules for the description of changes to the structure. Four basic editing operations are defined which arecomparable to the base classes of the change metamodel used in this thesis. Additionally, a cost functionand a matching algorithm for similar data is specified.

In [AP03], a definition of metamodel changes is given for UML models in the form of editing oper-ations which are usable in both directions via a dual counterpart. Besides an algorithm that representsmetamodel differences as applications of the editing operations mentioned beforehand, Alanen and Por-res also describe an algorithm for the minimization of change sequences. Furthermore, a version controlmechanism for metamodels is proposed that targets the lack of versioning in the UML standard.

8 CONCLUSION 46

8 Conclusion

In this section, the work presented is summarized, followed by a description of the achievements in thisthesis. Finally, an outlook to the future work, which may be based on this thesis, is given.

8.1 Summary

After a description of the metamodeling technologies used, the problem of calculating the difference of twometamodels was discussed, presenting two fundamental techniques for the comparison of two metamodelversions. Independently from these techniques, a formalisation of changes to MOF-based metamodels waspresented in the form of a change metamodel. Using this metamodel, the types of metamodel changeswere evaluated regarding the severity of single and combined changes in terms of compatibility of existingmodel instances as well as interface compatibility. With regard to the SAP modeling infrastructure projectMOIN, effects to the MOIN query infrastructure and to JMI interfaces were described, whereas the lattertechnology is a common standard which is also used by other MOF-based repositories.

8.2 Achievements

The change metamodel allows a description of the metamodel evolution process using the means ofmodeling itself. Based on this, the severity of changes to a metamodel can be determined for singlechanges, and, more importantly, for complex change sequences using the change severity classification.This classification is implementation-independent and is only based on the MOF standard. It can beused to make statements about the compatibility of existing model instances to new versions of themetamodel on which they are based. The severity classification has been noted formally using OCL,so that the results of an automatic or manual classification can be checked by the respective modelinginfrastructure. This makes it possible to use the results of the change classifications presented here ina platform-independent way. For manual evaluation of change severities, an overview table has beencreated.

For the case of Java interfaces using JMI technology, a classification has also been presented whichdescribes interface compatibility after metamodel changes. The process of the generation of JMI interfaceshas been described as a model-to-model transformation by the means of a JMI metamodel.

8.3 Future Work

In a metamodeling infrastructure which allows the comparison of different versions of the same metamodel,the classification presented in this thesis could be used to automatically determine the impact of a changeto a certain metamodel on existing model data based on that metamodel. This would require an automaticcalculation of a change metamodel instance from either two versions of a metamodel or from the currentediting process of a persisted metamodel. The model editing tool could then determine the severity of thechanges, which would enable the metamodel editor to decide about changes to the metamodel regardingthe projected impact on existing data as well as interface compatibility of the generated software.

The formal description of the JMI generation process could be used to create a generator tool whichtransforms metamodels into instances of the JMI metamodel. From these instances, the generation ofactual Java files could be described as a serialization process of model instances. This would make itpossible to evaluate the changes to JMI interfaces even if the transformation process is changed, sincethe change severities are calculated from the modeled description of the interfaces.

The classification of metamodel changes then would enable metamodel editors and tool developers toestimate the effects of changes to existing metamodels, based on an automatic analysis. For users of themodeling tools, the formal description of metamodel evolution changes would ease the migration of theirexisting model data to new versions of that software.

BIBLIOGRAPHY 47

Bibliography

[AKRS06] C. Amelunxen, A. Königs, T. Rötschke, and A. Schürr, MOFLON: A Standard-CompliantMetamodeling Framework with Graph Transformations, Model Driven Architecture - Foun-dations and Applications: Second European Conference (Heidelberg) (A. Rensink andJ. Warmer, eds.), Lecture Notes in Computer Science (LNCS), vol. 4066, Springer Verlag,2006, pp. 361–375.

[AP03] Marcus Alanen and Ivan Porres, Difference and Union of Models, “UML 2003” – The UnifiedModeling Language, Modeling Languages and Applications 6th International Conference,San Francisco, CA, USA, October 20–24, 2003, Proceedings (Berlin/Heidelberg) (PerditaStevens, Jon Whittle, and Grady Booch, eds.), Lecture Notes in Computer Science, vol.2863, Springer Verlag, 2003, pp. 2–17.

[BGGK07] Steffen Becker, Thomas Goldschmidt, Boris Gruschko, and Heiko Koziolek, A Process Modeland Classification Scheme for Semi-Automatic Meta-Model Evolution, Proc. 1st Workshop“MDD, SOA und IT-Management” (MSI’07), GiTO-Verlag, April 2007, pp. 35–46.

[CRGMW96] Sudarshan S. Chawathe, Anand Rajaraman, Hector Garcia-Molina, and Jennifer Widom,Change Detection in Hierarchically Structured Information, Proceedings of the 1996 ACMSIGMOD International Conference on Management of Data, Montreal, Quebec, Canada,June 4-6, 1996 (H. V. Jagadish and Inderpal Singh Mumick, eds.), ACM Press, 1996,pp. 493–504.

[Het06] Thomas Hettel, Impact Analysis of OCL Expressions, Master’s thesis, Institut für Ange-wandte Informatik und Formale Beschreibungsverfahren der Universität Karlsruhe, 2006.

[HKV94] C. Huemer, G. Kappel, and S. Vieweg, Management of Data Model Evolution in Object-Oriented Database Systems, Proceedings of the International Symposium on AdvancedDatabase Technologies and their Integration (ADTI’94) (Nara, Japan), October 1994.

[HLR06] David Hearnden, Michael Lawley, and Kerry Raymond, Incremental Model Transformationfor the Evolution of Model-Driven Systems, in Nierstrasz et al. [NWHR06], pp. 321–335.

[JMI02] Java Community Process, JavaTM Metadata Interface (JMI) Specification, Version 1.0, June2002, http://jcp.org/aboutJava/communityprocess/final/jsr040/index.html.

[MAC03] Jun-Ki Min, Jae-Yong Ahn, and Chin-Wan Chung, Efficient extraction of schemas for XMLdocuments, Inf. Process. Lett. 85 (2003), no. 1, 7–12.

[Mat03] Martin Matula, NetBeans Metadata Repository, Sun Microsystems, March 2003, http://mdr.netbeans.org/MDRwhitepaper.pdf.

[MDA03] Object Management Group, MDA Guide Version 1.0.1, June 2003, http://www.omg.org/docs/omg/030601.pdf.

[MOF02] Object Management Group, Meta Object Facility (MOF) Specification, Version 1.4, April2002, http://www.omg.org/docs/formal/050505.pdf.

[Mon93] Simon Monk, A Model for Schema Evolution in Object-Oriented Database Systems, February1993.

[MvdSD06] Tom Mens, Ragnhild van der Straeten, and Maja D’Hondt, Detecting and Resolving ModelInconsistencies Using Transformation Dependency Analysis, in Nierstrasz et al. [NWHR06],pp. 200–214.

http://jcp.org/aboutJava/communityprocess/final/jsr040/index.html

http://mdr.netbeans.org/MDR-whitepaper.pdf

http://mdr.netbeans.org/MDR-whitepaper.pdf

http://www.omg.org/docs/omg/03-06-01.pdf

http://www.omg.org/docs/omg/03-06-01.pdf

http://www.omg.org/docs/formal/05-05-05.pdf

BIBLIOGRAPHY 48

[NR88] Gia-Toan Nguyen and Dominique Rieu, Schema Evolution in Object-Oriented Database Sys-tems, Tech. Report 947, INRIA & IMAG, Laboratoire de Génie Informatique, Grenoble,France, December 1988.

[NWHR06] Oscar Nierstrasz, Jon Whittle, David Harel, and Gianna Reggio (eds.), Model Driven En-gineering Languages and Systems, 9th International Conference, MoDELS 2006, Genova, Italy,October 1-6, 2006, Proceedings, Lecture Notes in Computer Science, vol. 4199, Berlin/Hei-delberg, Springer Verlag, 2006.

[OCL06] Object Management Group, OCL 2.0 Specification, Version 2.0, May 2006, http://www.omg.org/docs/formal/060501.pdf.

[PK97] Anne Pons and Rudolf K. Keller, Schema Evolution in Object Databases by Catalogs, IDEAS’97: Proceedings of the 1997 International Symposium on Database Engineering & Appli-cations (Washington, DC, USA), IEEE Computer Society, 1997, p. 368.

[Pla08] Hasso Plattner, Trends and Concepts in the Software Industry I, Lecture Notes,Universität Potsdam, 2008, http://epic.hpi.unipotsdam.de/pub/Home/

TrendsAndConceptsI2008/TuK2008_CompleteScript.pdf.

[PÖ97] Randel J. Peters and M. Tamer Özsu, An Axiomatic Model of Dynamic Schema Evolution inObjectbase Systems, ACM Transactions on Database Systems 22 (1997), no. 1, 75–114.

[QVT07] Object Management Group, Meta Object Facility (MOF) 2.0 Query/View/TransformationSpecification, July 2007, http://www.omg.org/docs/formal/080403.pdf.

[Sch05] Markus Scheidgen, On Implementing MOF 2.0 – New Features for Modelling Language Ab-stractions, 2005.

[Spr03] Jonathan Mark Sprinkle, Metamodel Driven Model Migration, Ph.D. thesis, Vanderbilt Uni-versity, Nashville, Tennessee, USA, August 2003.



http://epic.hpi.uni-potsdam.de/pub/Home/TrendsAndConceptsI2008/TuK2008_CompleteScript.pdf

http://epic.hpi.uni-potsdam.de/pub/Home/TrendsAndConceptsI2008/TuK2008_CompleteScript.pdf


GLOSSARY 49

Glossary

Application Programming Interface (API) The interface provided by a system, library or applicationin order to exchange data or provide services.

Eclipse Modeling Framework (EMF) A modeling framework based on the Eclipse platform.

Java Metadata Interface (JMI) A mapping between Java and MOF. It provides a standard interfacefor access, manipulation and exchange of MOF-based metadata in Java.

Meta Object Facility (MOF) Formal language and framework for specifying metamodels definded bythe OMG. MOF is used to define how meta data is organized.

Model-Driven Architecture (MDA) A software engineering approach defined by the OMG, using platform-independent models and domain specific languages.

Modeling Infrastructure (MOIN) SAP technology which provides a MOF-based meta-model repositoryand OCL integration.

MOF identifier (MOFid) Permanent, unique identifier that every MOF element posesses. This identi-fier is generated and bound to the object when it is created and cannot be changed for thelifetime of the object.

MOIN Query Language (MQL) The API of MOIN’s query infrastructure, which describes the syntaxof the query language supported by MOIN.

Object Constraint Language (OCL) Formal, side effect free language to describe constraints on MOF-based models. These constraints can be invariants, pre- and post conditions and also queryresult definitions.

Object Management Group (OMG) A consortium that defines standards for modeling of programs,systems and business processes. Most prominent OMG standards are CORBA, UML andMOF.

Query/View/Transformation (QVT) A standard for the description of model transformation definedby the OMG, based on MOF 2.0 and OCL 2.0.

Unified Modeling Language (UML) A widely used graphical language for object modeling and speci-fication. OMG standard.

XML Metadata Interchange (XMI) XML-based interface for serialization of metadata, mainly usedfor import and export of metamodels.

AP

PE

ND

IXA

CH

AN

GE

SE

VE

RIT

IES

OV

ERV

IEW

50

Appendix A Change Severities Overview

M1 severity JMI severityMOF change type nb br bn comments nb br bn affected JMI elements/comments

ExistenceChangeClass add X additive X JmiClass

delete X special case, see constraint [SC-1] X

X other cases X

Attribute add X minimum cardinality > 0, no initializer X JmiAttribute, ElementCreator

X minimum cardinality > 0, initializer exists X

X minimum cardinality = 0 X

delete X X

Association add X minimum cardinality > 0 X AssociationAccessor

X minimum cardinality > 0, no instances X

X minimum cardinality = 0 X

delete X X

AssociationEnd same as for Association

Reference add X X JmiReference

delete X X

Package add X X JmiPackage,

delete X contents resolvable X NestedImportedAccessor

X contents not resolvable X

Import add X X NestedImportedAccessor

delete X elements resolvable otherwise X

X elements not resolvable X

Tag add X (X) dependent from tag IDdelete X (X) see section 5.4.2.5

Constraint add X in general X all elementsX no constrained elements X

delete X less limitations for M1 data X

Operation add X X ModeledOperation

AP

PE

ND

IXA

CH

AN

GE

SE

VE

RIT

IES

OV

ERV

IEW

51

delete X X

Exception add X X JmiException

delete X X

Parameter add X X ModeledOperation,

delete X X JmiParameter

DataType add X X JmiEnum, JmiStruct

delete X X

StructureField add X X JmiStruct

delete X X

PropertyChangeModelElement name X refactoring, unique ids X all elements

annotation X X

GeneralizableElement isRoot X X JmiObject,

isLeaf X X JmiClass

isAbstract X true → false X JmiPackage

X false → true X

visibility X increase (always public_vis in MOIN) X

X decrease X

Association isDerived X true → false X

X false → true X

Class isSingleton X true → false X JmiClass, JmiObject

X false → true X

Constraint expression X X all elementslanguage X X

evaluationPolicy X no effect in MOIN X

Feature scope X instance_level → classifier_level X Attribute/ReferenceAccessor,

X classifier_level → instance_level X Attribute/ReferenceMutator,

visibility X increase (always public_vis in MOIN) X ModeledOperation

X decrease X

StructuralFeature multiplicity X widening (X) (X) see section 5.3.2.3X narrowing (X) (X)

isChangeable X always true in MOIN X Attribute/ReferenceMutator

Attribute isDerived X true → false X JmiAttribute

X false → true X

Operation isQuery X X

Constant value X X

Parameter direction X X ModeledOperation

multiplicity X (X) (X) see section 5.3.2.3AssociationEnd isNavigable X always true in MOIN X true → false

AP

PE

ND

IXA

CH

AN

GE

SE

VE

RIT

IES

OV

ERV

IEW

52

X false → true

aggregation X composite → none X

X none → composite, composition closurerule violated

X

X closure rule not violated X

multiplicity X widening (X) (X) see section 5.3.2.3X narrowing (X) (X)

isChangeable X X true → false

X false → true

EnumerationType labels X addition X JmiEnum

X delete; general case X

X delete; no M1 data with this value X

LinkChangeContains X not mandatory; to supertype X various

(see [SC-5]) X not mandatory; to other type X

X mandatory; to supertype X

X mandatory; to new or abstract supertype X

X mandatory; to other type X

Generalizes add X supertype contains mandatory features orassociations

X

(see [SC-6]) X supertype contains non-mandatory fea-tures or associations

X

X supertype contains no features or associa-tions

X

delete X no associations to supertype or type com-patible; new features in supertype

X

X no associations to supertype or type com-patible; no new features in supertype

X

X supertype has adjacent mandatory associ-ation ends; change not type compatible

X

X supertype has adjacent non-mandatory as-sociation ends; change not type compatible

X

IsOfType X new type is supertype; general case depends on kind of element(see [SC-7]) X new type is supertype see section 5.3.2.2

X new type is subtype and instances are typecompatible

X new type is no sub- or supertypeRefersTo X X

CanRaise X X JmiException

APPENDIX B OCL CONSTRAINTS 53

Appendix B OCL Constraints

B.1 Change Metamodel Constraints

[CM-1] MultiplicityChangeApplicabilityA MultiplicityChange can only be applied to elements of the type StructuralFeature, AssociationEnd,

Parameter and CollectionType.

context MultiplicityChange

inv: self.affectedElement.oclIsKindOf(StructuralFeature) or

self.affectedElement.oclIsTypeOf(AssociationEnd) or

self.affectedElement.oclIsTypeOf(Parameter) or

self.affectedElement.oclIsTypeOf(CollectionType)

[CM-2] DirectionChangeApplicabilityA DirectionChange can only be applied to elements of the type Parameter.

context DirectionChange

inv: self.affectedElement.oclIsTypeOf(Parameter)

[CM-3] AggregationChangeApplicabilityAn AggregationChange can only be applied to elements of the type AssociationEnd.

context AggregationChange

inv: self.affectedElement.oclIsTypeOf(AssociationEnd)

[CM-4] ScopeChangeApplicabilityA ScopeChange can only be applied to elements of the type Feature.

context ScopeChange

inv: self.affectedElement.oclIsKindOf(Feature)

[CM-5] EvaluationPolicyChangeApplicabilityAn EvaluationPolicyChange can only be applied to elements of the type Constraint.

context EvaluationPolicyChange

inv: self.affectedElement.oclIsTypeOf(Constraint)

[CM-6] VisibilityChangeApplicabilityA VisibilityChange can only be applied to elements of the type GeneralizableElement, Import and

Feature.

context VisibilityChange

inv: self.affectedElement.oclIsKindOf(GeneralizableElement) or

self.affectedElement.oclIsTypeOf(Import) or

self.affectedElement.oclIsKindOf(Feature)


[CM-7] StringChangeValidNamesOnly String properties that exist in MOF can be changed.

context StringChange

inv: let ae = self.affectedElement in

Set{"name", "annotation"} > includes(self.propertyName) or

(ae.oclIsTypeOf(Tag) and

self.propertyName = "tagID") or

(ae.oclIsTypeOf(Constraint) and

Set{"expression", "language"} > includes(self.propertyName)) or

(ae.oclIsTypeOf(Constant) and

self.propertyName = "value") or

(ae.oclIsTypeOf(EnumerationType) and

self.propertyName = "labels")

[CM-8] MultivaluedStringChangeValidNamesOnly multivalued String properties that exist in MOF can be changed.

context MultivaluedStringChange

inv: (self.affectedElement.isTypeOf(Tag) and

self.propertyName = "values") or

(self.affectedElement.isTypeOf(EnumerationType) and

self.propertyName = "labels")

[CM-9] BooleanChangeValidNamesOnly Boolean properties that exist in MOF can be changed.

context BooleanChange


(ae.oclIsTypeOf(Import) and

self.propertyName = "isClustered") or

(ae.oclIsKindOf(GeneralizableElement) and

Set{"isRoot", "isLeaf", "isAbstract"} > includes(self.propertyName)) or

((ae.oclIsKindOf(StructuralFeature) or ae.oclIsTypeOf(AssociationEnd)) and

self.propertyName = "isChangeable") or

((ae.oclIsTypeOf(Association) or ae.oclIsTypeOf(Attribute)) and

self.propertyName = "isDerived") or

(ae.oclIsTypeOf(AssociationEnd) and

self.propertyName = "isNavigable") or

(ae.oclIsTypeOf(Operation) and

self.propertyName = "isQuery") or

(ae.oclIsTypeOf(Class) and

self.propertyName = "isSingleton")


B.2 Severity Constraints

Note: This section makes heavy use of the helper functions defined in Appendix B.4.[SC-1] ExistenceChange: Class

context ExistenceChange

inv: (self.affectedElement.oclIsTypeOf(Class)) implies

if (self.kind=ADD)

then self.severity=NON_BREAKING

else (self.kind=DELETE)

if (self.newAssocEnds(self.affectedElement) > exists(end|

end.multiplicity.lower > 0 and

self.affectedElement.allSupertypes() > exists(t|

t=self.changeSequence.newType(end))))

then self.severity = BREAKING_NOT_RESOLVABLE

else self.severity = BREAKING_RESOLVABLE

endif

endif

[SC-2] ExistenceChange: Attribute


inv: (self.affectedElement.oclIsTypeOf(Attribute)) implies

if (self.kind=ADD) then

if (self.affectedElement.multiplicity.lower = 0)

then self.severity = NON_BREAKING

else check if containing element has been newly added

if (self.changeSequence.changes > exists(c|

c.oclIsTypeOf(ExistenceChange) and c.kind = ADD and

c.newContains(c.affectedElement) >

contains(self.affectedElement)))


else self.severity = BREAKING_NOT_RESOLVABLE

endif

endif

else (self.kind=DELETE)

self.severity = BREAKING_RESOLVABLE

endif

[SC-3] ExistenceChange: Association


inv: (self.affectedElement.oclIsTypeOf(Association) and self.kind=ADD) implies

if (self.affectedElement.contents > select(e|e.oclIsTypeOf(AssociationEnd)) >

forAll(a|a.multiplicity.lower = 0))


else check if the types on the other sides have been newly added

if (self.affectedElement.contents > select(e|

e.oclIsTypeOf(AssociationEnd) and e.multiplicity.lower > 0) >

forAll(a|self.changeSequence.isNewElement(a.otherEnd().type)))



endif

endif


[SC-4] AggregationKindChange

context AggregationKindChange


ae.oclIsTypeOf(AssociationEnd) implies

if (ae.aggregation=none and self.aggregation=composite)

then check for composition cycles

if (ae.otherEnd().type.allCompositeChildren() > contains(ae))


else self.severity = NON_BREAKING

endif


endif

[SC-5] ContainsChange

context ContainsChange

inv: (self.container.oclIsTypeOf(Class) and

self.containedElement.oclIsKindOf(StructuralFeature))

implies

if (self.kind=DELETE)

then

if self.changeSequence.changes > exists(c|

c.oclIsTypeOf(ContainsChange) and c.kind = ADD and

(c.containedElement = self.containedElement or

c.containedElement.similar(self.containedElement)) and

self.newSupertypesExtended(self.container) > contains(c.container))

feature moved to supertype


feature deleted or moved elsewhere


endif

else (self.kind=ADD)

if (self.containedElement.multiplicity.lower > 0)

then mandatory feature

if (self.changeSequence.isNewElement(self.container))

then containing class has been newly added

if (self.newSubtypes(self.container) >

select(s|not self.changeSequence.isNewElement(s)) > forall(s|

s.containedElement > select(e|e.oclIsKindOf(StructuralFeature) >

exists(f|f.similar(self.containedElement)))) or

self.newSubtypes(self.container) > isEmpty())

element is in all preexistent subclasses


preexistent subclasses without this feature


endif

mandatory feature added to a preexistent class

else self.severity= BREAKING_NOT_RESOLVABLE

endif

nonmandatory feature


endif

endif


[SC-6] GeneralizesChange

context GeneralizesChange

inv:

the "super" element of the change plus all its supertypes in the old metamodel

let selfAndOldSuper = self.superElement.allSupertypes() > including(self.superElement) in

the "super" element of the change plus all its supertypes after all other changes

let selfAndNewSuper = self.newSupertypesExtended(self.superElement) >

including(self.superElement) in

all the contained structural features in selfAndNewSuper after all changes

let newSuperFeatures = selfAndNewSuper > iterate(i:GeneralizableElement;

y:Set(ModelElement) = Set{} | y > including(self.newContains(i))) >

select(e|e.oclIsOfType(StructuralFeature)) in

all association ends in the supertypes of superElement that exist after all changes

let newSuperAssocEnds = (selfAndNewSuper >

iterate(i:GeneralizableElement; y:Set(AssociationEnd) = Set{} |

y > including(self.newAssocEnds(i))) in

association ends on the old supertypes

let oldSuperAssocEnds = self.changeSequence.oldAssocs() > collect(containedElement) > select(e|

e.oclIsTypeOf(AssociationEnd) and selfAndOldSuper > includes e.type)

association ends on new supertypes; regard only ends already existing in the old version

let newExistingSuperAssocEnds = self.newAssocEnds(selfAndNewSuper) >

intersection(self.changeSequence.oldAssocs() > collect(containedElement))

if (self.kind = ADD)

then check for mandatory features in supertypes

if (newSuperFeatures > exists(f|f.multiplicity.lower > 0 and

not self.subElement.containedElement > exists(e|e.similar(f))) or

check for mandatory associations in supertypes

newSuperAssocEnds > exists(end|end.otherEnd().multiplicity.lower > 0 and

not self.oldAssocs() > collect(containedElement) > includes(end)))


else check for nonmandatory features in supertypes

if (newSuperFeatures > exists(f|f.multiplicity.lower = 0 and

not self.subElement.containedElement > exists(e|e.similar(f))) or

check for nonmandatory associations in supertypes

newSuperAssocEnds > exists(end|end.otherEnd().multiplicity.lower = 0 and

not self.oldAssocs() > collect(containedElement) > includes(end)))

then self.severity = BREAKING_RESOLVABLE


endif

endif

else (self.kind = DELETE)

if oldSuperAssocEnds>isEmpty() or newExistingSuperAssocEnds.includesAll(oldSuperAssocEnds)

then no associations in the new supertype hierarchy or type compatible

if (not superFeatures > isEmpty() and superFeatures.includesAll(

self.superElement > collect(containedElement) >

select(e|e.oclIsTypeOf(StructuralFeature))))

then self.severity = BREAKING_RESOLVABLE


endif

else association to supertypes exists; change not type compatible

if AssociationEnds.allInstances() > excluding(a|self.isNewElement(a)) > exists(e|

selfAndOldSuper > excluding(self.newSuperTypes(subElement))

> exists(t|t.type = e) and e.multiplicity.lower>0)



endif

endif


[SC-7] IsOfTypeChange

context IsOfTypeChange

inv:

if (self.typedElement.oclIsTypeOf(Attribute))

then

if (self.newSupertypes(self.typedElement)) > includes(self.type)


else self.severity=BREAKING_NOT_RESOLVABLE

endif

else if (self.typedElement.oclIsTypeOf(AssociationEnd))

then

if (self.newSupertypes(self.typedElement)) > includes(self.type)

then

if (self.typedElement.otherEnd().multiplicity.lower>0)

then self.severity=BREAKING_NOT_RESOLVABLE

else self.severity=NON_BREAKING

endif

else self.severity=BREAKING_NOT_RESOLVABLE

endif

endif

endif

[SC-8] MultiplicityChange

context MultiplicityChange

inv: if (affectedElement.multiplicity.lower >= self.lower and

affectedElement.multiplicity.upper <= self.upper)


else self.severity=BREAKING_NOT_RESOVABLE

endif


B.3 JMI Metamodel Constraints

B.3.1 Model Constraints

[JM-1] ClassProxyAccessorReturnType

context ClassProxyAccessor

inv: self.return.type.oclIsTypeOf(JmiClass)

[JM-2] AssociationAccessorReturnType

context AssociationAccessor

inv: self.return.type.oclIsTypeOf(JmiAssociation)

[JM-3] NestedImportedAccessorReturnType

context NestedImportedAccessor

inv: self.return.type.oclIsTypeOf(JmiPackage)

[JM-4] LinkExists

context LinkExists

inv: self.name = "exists" and self.return.type = JmiPrimitiveTypes::Boolean

[JM-5] LinkAdd

context LinkAdd

inv: self.name = "add" and self.return.type = JmiPrimitiveTypes::Boolean

[JM-6] LinkRemove

context LinkRemove

inv: self.name = "remove" and self.return.type = JmiPrimitiveTypes::Boolean

[JM-7] AttributeMutatorInputParameter

contect AttributeMutator

inf: self.input.size < 2 and self.input.at(1).name = "newValue"

B.3.2 Transformation Constraints

[TM-1] ClassTransformationInstanceNaming conventions for JmiObject elements.

context ClassTransformation

inv: self.target.packageName = self.source.packageName() and helper function [M15]

self.target.className = self.source.substitutedName() helper function [M16]

[TM-2] ClassTransformationInstanceAttributeAccessorFor every instance-scoped public attribute, an AttributeAccessor element must be created in the

containment of the corresponding JmiObject element


inv: self.source.contents.select(e|e.oclIsKindOf(Attribute)) > forAll(attr|

(attr.visibility=PUBLIC_VIS and attr.scope=INSTANCE_SCOPED) =

self.target.contents > exists(ja|

ja.oclIsKindOf(JmiAttribute) and ja.contents > exists(acc|

acc.oclIsKindOf(AttributeAccessor) and

acc.return.type = attr.type.transformation.target and

acc.return.multiplicity = attr.multiplicity.toParameterMultiplicity() and

acc.name = attr.accessorName() helper function [M13]

)

)

)


[TM-3] ClassTransformationInstanceAttributeMutatorFor every non-derived, instance-scoped, changeable and single-valued attribute, an AttributeMutator

element must be generated in the containment of the corresponding JmiObject element and namedaccording to the JMI naming conventions.



(attr.visibility=PUBLIC_VIS and attr.scope=INSTANCE_SCOPED and

attr.isChangeable and attr.multiplicity.upper = 1) =


ja.oclIsKindOf(JmiAttribute) and ja.contents > exists(mut|

mut.oclIsKindOf(AttributeMutator) and

mut.input > at(1).type = attr.type.transformation.target and

mut.input > at(1).multiplicity = attr.multiplicity.toParameterMult() and

mut.name = attr.mutatorName() helper function [M14]

)

)

[TM-4] ClassTransformationProxyNaming conventions for JmiClass elements.


inv: self.classProxyTarget.packageName = self.target.packageName and

self.classProxyTarget.className = self.target.className + "Class"

[TM-5] ClassTransformationProxyAttributeAccessorFor every classifier-scoped public attribute, an AttributeAccessor element must be created in the

containment of the corresponding JmiClass element


inv: self.source.allSuperTypes > including(self.source) > collect(contents) >

select(e|e.oclIsKindOf(Attribute)) > forAll(attr|

(attr.visibility=PUBLIC_VIS and attr.scope=CLASSIFIER_SCOPED) =

self.classProxyTarget.contents > exists(ja|

ja.oclIsKindOf(JmiAttribute) and ja.contents > exists(acc|

acc.oclIsKindOf(AttributeAccessor) and

acc.return.type = attr.type.transformation.target and

acc.return.multiplicity = attr.multiplicity.toParameterMultiplicity() and

acc.name = attr.accessorName() helper function [M13]

)

)

)

[TM-6] ClassTransformationProxyAttributeMutatorFor every non-derived, classifier-scoped, changeable and single-valued attribute, an AttributeMuta

tor element must be generated in the containment of the corresponding JmiClass element and namedaccording to the JMI naming conventions.



(attr.visibility=PUBLIC_VIS and attr.scope=CLASSIFIER_SCOPED and

attr.isChangeable and attr.multiplicity.upper = 1) =

self.classProxyTarget.contents > exists(ja|

ja.oclIsKindOf(JmiAttribute) and ja.contents > exists(mut|

mut.oclIsKindOf(AttributeMutator) and

mut.input>at(1).type = attr.type.transformation.target and

mut.input>at(1).multiplicity = attr.multiplicity.toParameterMult() and

mut.name = attr.mutatorName() helper function [M14]

)

)

)


[TM-7] ClassTransformationElementCreatorEvery class proxy element must contain a default element creator and a specific element creator that

contains all attributes of the class as input parameters.


inv: self.classProxyTarget.contents > exists(dc| default creator

dc.oclIsTypeOf(DefaultCreator) and

dc.name = "create" + self.target.name and

dc.return.type = self.target)

and self.classProxyTarget.contents > exists(sc| specific creator

sc.oclIsTypeOf(SpecificCreator) and

sc.name = "create" + self.target.name and

sc.return.type = self.target and

self.source.allSuperTypes() > including(self.source) > collect(contents)

> select(a|a.oclIsTypeOf(Attribute) and input parameters

not a.isDerived and a.scope = INSTANCE_LEVEL) > forAll(attr|

sc.input > exists(p|p.type = a.type.transformation.target and

p.name = a.transformation.target.className)

)

)

[TM-8] ClassTransformationStructCreatorFor every structure type, a creator element must exist.


let cPrefix = "create" in

inv: self.source.contents > select(s|s.oclIsTypeOf(StructureType)) > forAll(st|

self.classProxyTarget.contents > exists(sc|

sc.name = cPrefix.concat(st.transformation.target.name) and

sc.return.type = st.transformation.target and

st.contents > select(sf|sf.oclIsTypeOf(StructureField)) > forall(f|

sc.input > exists(p|

p.name = f.substitutedName() and

p.type = f.type.transformation.target)

)

)

)

[TM-9] ClassTransformationExtendsFor JmiObject elements, extends statement must exist for every supertype of the original class; if it

has no supertypes, the transformed element has to extend RefObject.


inv: if (self.source.supertypes.size() = 0) then

self.target.extendsStatement.size() = 1 and

self.target.extendsStatement > collect(object) >

contains(JmiReflectPackage::RefObject)

else

self.source.supertypes > forAll(s|

self.target.extendsStatement > exists(e|

e.object = s.transformation.target)

)

endif

[TM-10] PackageTransformationNaming conventions for packages

context PackageTransformation

inv: self.target.packageName = self.source.packageName() and helper function [M15]

self.target.className = self.source.substitutedName().concat("Package") [M16]


[TM-11] PackageTransformationExtendsFor JmiPackage elements, extends statement must exist for every supertype of the original package;

if it has no supertypes, the transformed element has to extend RefPackage.


inv: if (self.source.supertypes.size() = 0) then

self.target.extendsStatement.size() = 1 and

self.target.extendsStatement > collect(package) >

contains(JmiReflectPackage::RefPackage)

else

self.source.supertypes > forAll(s|

self.target.extendsStatement > exists(e|

e.package = s.transformation.target))

endif

[TM-12] AssociationTransformationLinkExistsType, name and multiplicity of a LinkExists operation must match association end.

context AssociationTransformation

let end1 = self.source.contents > select(e|e.oclIsTypeOf(AssociationEnd)) > at(1) in


inv: self.contents.exists(le|le.oclIsTypeOf(LinkExists) and

le.input.at(1).name = end1.substitutedName() and

le.input.at(1).type = end1.type.transformation.target and

le.input.at(1).multiplicity = end1.multiplicity.toParameterMultiplicity() and

le.input.at(2).name = end2.substitutedName() and

le.input.at(2).type = end2.type.transformation.target and

le.input.at(2).multiplicity = end2.multiplicity.toParameterMultiplicity())

[TM-13] AssociationTransformationLinkAddType, name and multiplicity of a LinkAdd operation must match association end. Operation only

exists if both ends are changeable.




inv: (end1.isChangeable and end2.isChangeable) =

self.contents.exists(la|la.oclIsTypeOf(LinkAdd) and

la.input.at(1).name = end1.substitutedName() and

la.input.at(1).type = end1.type.transformation.target and

la.input.at(1).multiplicity = end1.multiplicity.toParameterMultiplicity() and

la.input.at(2).name = end2.substitutedName() and

la.input.at(2).type = end2.type.transformation.target and

la.input.at(2).multiplicity = end2.multiplicity.toParameterMultiplicity())

[TM-14] AssociationTransformationLinkRemoveType, name and multiplicity of a LinkRemove operation must match association end. Operation only

exists if both ends are changeable.




inv: (end1.isChangeable and end2.isChangeable) =

self.contents.exists(lr|lr.oclIsTypeOf(LinkRemove) and

lr.input.at(1).name = end1.substitutedName() and

lr.input.at(1).type = end1.type.transformation.target and

lr.input.at(1).multiplicity = end1.multiplicity.toParameterMultiplicity() and

lr.input.at(2).name = end2.substitutedName() and

lr.input.at(2).type = end2.type.transformation.target and

lr.input.at(2).multiplicity = end2.multiplicity.toParameterMultiplicity())


[TM-15] AssociationTransformationEnd1AccessorType, name and multiplicity of an End1Accessor operation must match association end. Operation

only exists if end is navigable.




inv: end1.isNavigable =

self.target.contents > select(a|a.oclIsTypeOf(End1Accessor)) > exists(acc|

acc.name = "get".concat(end1.name) and

acc.return.multiplicity = end1.multiplicity.toParameterMultiplicity() and

acc.return.type = end1.type.transformation.target and

acc.input.size() = 1 and

acc.input.contains(p|p.type = end2.type.transformation.target and

p.name = end2.type.transformation.target.className)

)

[TM-16] AssociationTransformationEnd2AccessorType, name and multiplicity of an End2Accessor operation must match association end. Operation

only exists if end is navigable.




inv: end2.isNavigable =

self.target.contents > select(a|a.oclIsTypeOf(End2Accessor)) > exists(acc|

acc.name = "get".concat(end2.name) and

acc.return.multiplicity = end1.multiplicity.toParameterMultiplicity() and

acc.return.type = end2.type.transformation.target and

acc.input.size() = 1 and

acc.input.contains(p|p.type = end1.type.transformation.target and

p.name = end1.type.transformation.target.className)

)

[TM-17] ConstantTransformationNaming conventions, typing and values for constants

context ConstantTransformation

inv: self.target.name = self.source.substitutedName() and

self.target.type = self.source.type.transformation.target and

self.target.values = self.source.values


[TM-18] PackageTransformationNestedImportedAccessorFor each imported or nested publicly visible package, an accessor must exist with matching name,

type and multiplicity.


inv: self.source.contents.select(i|i.oclIsTypeOf(Import) and

i.isClustered = true and i.visibility = PUBLIC_VIS and

i.importedNamespace.visibility = PUBLIC_VIS) > forAll(c|

self.target.contents.exists(a|

a.oclIsTypeOf(NestedImportedAccessor) and

a.name = "get".concat(c.substitutedName()) and

a.return.type = c.imported.transformation.target and

a.input.isEmpty()

)

)

and

self.source.contents.select(p|p.oclIsTypeOf(Package) and

p.visibility = PUBLIC_VIS > forAll(n|

self.target.contents.exists(a|

a.oclIsTypeOf(NestedImportedAccessor) and

a.name = "get".concat(n.name) and

a.return.type = n.transformation.target and

a.input.isEmpty()

)

)

[TM-19] PackageTransformationAssociationAccessorFor each publicly visible association, an accessor must exist with matching name, type and multiplicity.


inv: self.source.contents > select(a|a.oclIsKindOf(Association) and

a.visibility = PUBLIC_VIS) > forAll(p|

self.target.contents > exists(a|a.oclIsTypeOf(AssociationAccessor) and

a.name = "get".concat(p.transformation.target.name) and

a.return.type = p.transformation.target

)

)

[TM-20] PackageTransformationClassProxyAccessorFor each publicly visible class proxy, an accessor must exist with matching name, type and multiplicity.


inv: self.source.contents > select(c|c.oclIsKindOf(Class) and

c.visibility = PUBLIC_VIS) > forAll(p|

self.target.contents > exists(a|a.oclIsTypeOf(ClassProxyAccessor) and

a.name = "get".concat(p.transformation.target.name) and

a.return.type = p.transformation.classProxyTarget

)

)


[TM-21] PackageTransformationStructCreatorFor each publicly visible struct type, an accessor must exist with matching name, type and multiplicity.


inv: self.source.contents > select(s|s.oclIsKindOf(StructureType) and

s.visibility = PUBLIC_VIS) > forAll(st|

self.target.contents > exists(sc|sc.oclIsTypeOf(StructCreator) and

sc.name = "create".concat(p.transformation.target.name) and

sc.return.type = st.transformation.target and

st.contents > select(sf|sf.oclIsTypeOf(StructureField)) > forall(f|

sc.input > exists(p|

p.name = f.name and

p.type = f.type.transformation.target)

)

)

)

[TM-22] ClassTransformationInstanceReferenceAccessorFor every instance-scoped public attribute, an AttributeAccessor element must be created in the

containment of the corresponding JmiObject element


inv: self.source.contents.select(e|e.oclIsKindOf(Reference)) > forAll(ref|

(ref.visibility = PUBLIC_VIS) =

self.target.contents > exists(jr|

jr.oclIsKindOf(JmiReference) and jr.contents > exists(acc|

acc.oclIsKindOf(ReferenceAccessor) and

acc.return.type = ref.type.transformation.target and

acc.return.multiplicity = ref.multiplicity.toParameterMultiplicity() and

acc.name = "get".concat(ref.substitutedName())

)

)

)

[TM-23] ClassTransformationInstanceReferenceMutatorFor every non-derived, instance-scoped, changeable and single-valued attribute, an AttributeMutator

element must be generated in the containment of the corresponding JmiObject element and namedaccording to the JMI naming conventions.


inv: self.source.contents.select(e|e.oclIsKindOf(Reference)) > forAll(ref|

(ref.visibility = PUBLIC_VIS and ref.isChangeable and ref.multiplicity.upper = 1) =


ja.oclIsKindOf(JmiReference) and ja.contents > exists(mut|

mut.oclIsKindOf(ReferenceMutator) and

mut.input > at(1).type = ref.type.transformation.target and

mut.input > at(1).multiplicity = ref.multiplicity.toParameterMult() and

mut.name = "set".concat(ref.substitutedName())

)

)


[TM-24] ClassTransformationOperationName, type and multiplicity matching for modeled operations.


inv: self.source.contents > select(e|e.oclIsTypeOf(Operation)) > forAll(o|

(o.visibility = PUBLIC_VIS) =

self.target.contents > exists(mo|mo.oclIsTypeOf(ModeledOperation) and

o.contents > select(p|p.oclIsTypeOf(Parameter)) > forAll(par|

if (par.direction = IN_DIR) input parameters

then mo.input > exists(ip|

ip.type = par.type.transformation.target and

ip.name = par.substitutedName() and

ip.multiplicity = par.multiplicity.toParameterMultiplicity()

)

else mo.return > exists(op| output parameters

op.type = par.type.transformation.target and

op.multiplicity = par.multiplicity.toParameterMultiplicity()

)

endif

)

and o.contents > select(p|p.oclIsTypeOf(Exception)) > forAll(exc|

mo.throws.contains(exc.transformation.target)

)

)

)

[TM-25] ClassTransformationExceptionNaming convention for modeled exceptions.

context ExceptionTransformation

inv: if (self.source.name.endsWith("Exception"))

then self.target.name = self.source.substitutedName()

else self.target.name = self.source.substitutedName().concat("Exception")

endif

[TM-26] ClassTransformationExceptionConstructor


inv: self.source.contents > select(p|p.oclIsTypeOf(Parameter)) >

forAll(ep|self.target.contents > exists(c|

c.oclIsTypeOf(ExceptionConstructor) and

c.input > contains(jp|

jp.name = ep.substitutedName() and

jp.type = ep.type.transformation.target and

jp.multiplicity = ep.multiplicity.toParameterMultiplicity()

)

)

)

[TM-27] ClassTransformationExceptionParameterAccessor


inf: self.source.contents > select(p|p.oclIsTypeOf(Parameter)) >

forAll(ep|self.target.contents > exists(a|

a.oclIsTypeOf(ParameterAccessor) and

p.type = ep.type.transformation.target and

p.name = ep.accessorName()

)

)


B.4 Helper Functions

[M-1] AllCompositeChildrenDefinition for a method to recursively calculate all composite children of an element.

context ModelElementChange::allCompositeChildren(Classifier c)

post: result = AssociationEnd.allInstances() >

select(e|self.newType(e) = c and self.newAggregation(e) = composite) >

iterate(end:AssociationEnd; y:Set(AssociationEnd) = Set{} |

y > including(end.otherEnd())

) > collect(type) >

iterate(cl:Classifier; y:Set(Classifier) = Set{} |

y > including(self.allCompositeChildren(cl))

) > including(c)

[M-2] NewSuperTypesDetermines the set of supertypes for an element after a sequence of changes.

context ModelElementChange::newSupertypes(GeneralizableElement element) :

Set(GeneralizableElement)

post: result = element.supertypes > including(this.changeSequence.changes > select(ch|

ch.oclIsTypeOf(GeneralizesChange) and

ch.subtype = element and ch.kind = ADD) > collect(supertype)

)

> excluding(this.changeSequence.changes>select(ch|


ch.subtype = element and

ch.kind = DELETE) > collect(supertype)

)

[M-3] NewSubTypesDetermines the set of subtypes for an element after a sequence of changes.

context ModelElementChange::newSubtypes(GeneralizableElement element) : Set(GeneralizableElement)

post: result = element.suptypes > including(this.changeSequence.changes > select(ch|


ch.supertype = element and ch.kind = ADD) > collect(subtype)

)

> excluding(this.changeSequence.changes>select(ch|


ch.supertype = element and

ch.kind = DELETE) > collect(subtype)

)

[M-4] NewContainedElementsDetermines the set of contained elements after a sequence of changes.

context ModelElementChange::newContainedElements(ModelElement element) : Set(ModelElement)

post: result = element.containedElements > including(this.changeSequence.changes > select(ch|

ch.oclIsTypeOf(ContainsChange) and ch.container = element and

ch.kind = ADD) > collect(containedElement)) > excluding(this.changeSequence.changes >

select(ch|ch.oclIsTypeOf(ContainsChange) and ch.container= element and

ch.kind = DELETE) > collect(containedElement))


[M-5] NewAssocEndsDetermines the set of association ends which have the same type as the element after all changes. 40

context ModelElementChange::newAssocEnds(TypedElement element) : Set(AssociationEnd)

post: result = AssociationEnd.allInstances() > select(ae|ae.type = element) >

including( the association ends whose type is changed to element

self.changeSequence.changes > select(ch|ch.oclIsTypeOf(IsOfTypeChange) and

ch.type = element) > collect(typedElement) > select(t|

t.oclIsOfType(AssociationEnd))) >

excluding( the association ends whose type is change to another element

self.changeSequence.changes > select(ch|ch.oclIsTypeOf(IsOfTypeChange)

and not ch.type = element) > collect(typedElement) > select(t|

t.oclIsOfType(AssociationEnd) and t.type = element)) >

excluding( the deleted association ends

self.changeSequence.changes > select(ch|ch.oclIsTypeOf(ExistenceChange) and

ch.kind = DELETE and ch.affectedElement.type = element).collect(affectedElement))

[M-6] SimilarCompares two features if they are sufficiently similar to be recognized as the “same” feature.

context StructuralFeature::similar(StructuralFeature other) : Boolean

post: result = (self.name = other.name and

self.type = other.type and

self.scope = other.scope and

self.visibility = other.visibility and

self.multiplicity = other.multiplicity)

[M-7] OldAssocsDetermines the set of all associations present in the old version of the metamodel

context ChangeSequence::oldAssocs() : Set(Association)

post: result = Association.allInstances() > excluding(self.changes > select(c |

c.oclIsTypeOf(ExistenceChange) and c.kind = add and

c.affectedElement.oclIsTypeOf(Association)) > collect(affectedElement))

[M-8] IsNewElementChecks whether an element was newly added in the course of this change sequence

context ChangeSequence::isNewElement(ModelElement element) : Boolean

post: result = self.changes > exists(c |

c.oclIsTypeOf(ExistenceChange) and

c.kind = ADD and

c.affectedElement = element)

[M-9] NewTypeDetermines the new type of a typed element

context ChangeSequence::newType(TypedElement element) : Classifier

post: if (self.changes > exists(c | c.oclIsTypeOf(IsOfTypeChange) and

c.affectedElement = element))

then result = self.changes > select(c | c.oclIsTypeOf(IsOfTypeChange) and

c.affectedElement = element) > collect(type) > last()

else result = element.type

endif

40Note that the returned set of association ends actually contains the old association ends which still have their old types,and the newly created association ends with the new types. To determine the new type of an association end, use newType().


[M-10] ToUpper

context String::toUpper(character : String) : String

post: if (character.size() > 1) then result = ""

else if (Set{"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O",

"P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",} > contains(character))

then result = character

else if (character = "a") then result = "A"

else if (character = "b") then result = "B"

else if (character = "c") then result = "C"

else if (character = "d") then result = "D"

else if (character = "e") then result = "E"

else if (character = "f") then result = "F"

else if (character = "g") then result = "G"

else if (character = "h") then result = "H"

else if (character = "i") then result = "I"

else if (character = "j") then result = "J"

else if (character = "k") then result = "K"

else if (character = "l") then result = "L"

else if (character = "m") then result = "M"

else if (character = "n") then result = "N"

else if (character = "o") then result = "O"

else if (character = "p") then result = "P"

else if (character = "q") then result = "Q"

else if (character = "r") then result = "R"

else if (character = "s") then result = "S"

else if (character = "t") then result = "T"

else if (character = "u") then result = "U"

else if (character = "v") then result = "V"

else if (character = "w") then result = "W"

else if (character = "x") then result = "X"

else if (character = "y") then result = "Y"

else if (character = "z") then result = "Z"

else result = ""

[M-11] EndsWith

context String::endsWith(suffix : String) : boolean

post: let len = self.size() in

result =

(self.substring(self.size()suffix.size(),self.size()) = suffix)

[M-12] ToParameterMultiplicity

context Model::MultiplicityType::toParameterMultiplicity() : ParameterMultiplicity

post: if (self.upper < 2) then result = SINGLE

else if (self.isOrdered) then result = LIST

else result = SET

endif

endif

[M-13] AccessorNames

context Model::Attribute::accessorName() : String

let isPrefix = "is" in

let getPrefix = "get" in

let sname = self.substitutedName() in

post: for singlevalued boolean types, the accessor name starts with "is"

if (self.type = PrimitiveTypes::Boolean and self.multiplicity.upper = 1) then

if (self.name.substring(1,2) = isPrefix) then

result = sname

else

result = isPrefix.concat(sname.substring(1,1).toUpper()).concat(


sname.substring(2,sname.size()))

endif

else for others, the accessor name starts with "get"

result = getPrefix.concat(sname.substring(1,1).toUpper()).concat(


endif

[M-14] MutatorNames

context Model::Attribute::mutatorName() : String

let setPrefix = "set" in

let sname = self.substitutedName() in

post: if (self.type = PrimitiveTypes::Boolean and self.multilicity.upper = 1 and

sname.substring(1,2) = isPrefix) then

result = setPrefix.concat(sname.substring(3,3).toUpper()).concat(


else

result = setPrefix.concat(sname.substring(1,1).toUpper()).concat(


)

endif

[M-15] PackagePrefix

context Model::ModelElement::packageName() : String

post: result = self.contents.select(ppt| ppt.oclIsOfType(Tag)

and ppt.tagId = "javax.jmi.packagePrefix") > collect(values) > at(1).

concat(".").concat(self.outermostPackage().substitutedName())

[M-16] SubstituteName

Context Model::ModelElement::substitutedName() : String

let substName = (self.source.contents.select(t|t.oclIsKindOf(Tag) and

t.tagId = "javax.jmi.substituteName")) in

post: if (substName.isEmpty()) then result = self.name

else result = substName > at(1).values > at(1)

endif

[M-17] OutermostPackage

Context Model::ModelElement::outermostPackage() : Model::Namespace

post: if (self.container.isEmpty()) then

result = self

else

result = self.container.outermostPackage()

endif

[M-18] ParameterAccessorNames

context Model::Parameter::accessorName() : String

let isPrefix = "is" in

let getPrefix = "get" in

post: for singlevalued boolean types, the accessor name starts with "is"

if (self.type = PrimitiveTypes::Boolean and self.multiplicity.upper = 1) then

if (self.name.substring(1,2) = isPrefix) then

result = self.name

else

result = isPrefix.concat(self.name.substring(1,1).toUpper()).concat(

self.name.substring(2,self.name.size()))

endif

else for others, the accessor name starts with "get"

result = getPrefix.concat(self.name.substring(1,1).toUpper()).concat(

self.name.substring(2,self.name.size()))

endif


[M-19] NewSuperTypesExtended()

context ModelElementChange::newSupertypesExtended(GeneralizableElement element)

: Set(GeneralizableElement)

post: result = self.newSupertypes(element) >

iterate(i:GeneralizableElement; a:Set(GeneralizableElement) = Set{} |

a > including(i) > including(self.newSupertypesExtended(i)))

[M-20] NewSubTypesExtended()

context ModelElementChange::newSubtypesExtended(GeneralizableElement element)

: Set(GeneralizableElement)

post: result = self.newSubtypes(element) >

iterate(i:GeneralizableElement; a:Set(GeneralizableElement) = Set{} |

a > including(i) > including(self.newSubtypesExtended(i)))

[M-21] NewAggregation()

contect ModelElementChange::newAggregation(AssociationEnd end) : AggregationKind

post: if (self.changeSequence.changes.exists(ac|

ac.oclIsKindOf(AggregationKindChange) and ac.affectedElement=end))

then result = self.changeSequence.changes.select(ac|

ac.oclIsKindOf(AggregationKindChange) and ac.affectedElement=end) >

collect(aggregation) > last()

else result = end.aggregation

endif

metamodel evolution in the context of a mof-based … · 2013. 7. 16. · modeling infrastructure...

Documents