Metamodel evolution is prevalent in Model-Driven Engineering, necessitating the co-evolution of dependent artifacts like models and transformations. Whereas model co-evolution has been extensively studied, the co-evolution of transformations and especially its substantial ingredient in terms of OCL expressions has received little attention up to now. Thus, the goal of this paper is a systematic analysis of potential impacts of metamodel evolution on OCL expressions in model transformations. For this, a complete and minimal set of atomic metamodel changes has been derived from Ecore, which is analyzed with respect to its effects on structural complexity and information capacity. This analysis builds the basis for investigating the impacts concerning syntactical conformance and scope of affected OCL expressions. Finally, we report on lessons learned gained from establishing the set of changes and examining the impacts thereof.
Model-Driven Engineering (MDE) proposes the use of models to conduct software
development on a higher level of abstraction [
While the automated co-evolution of models has been subject to extensive research
in the past (cf., [
To tackle this limitation, this paper focuses on the co-evolution of OCL
expressions in model transformations by first proposing acomplete and minimal set of atomic
changes focusing on structure, which has been systematically derived from the Ecore4
meta-MM, enabling the definition of arbitrary evolutions of Ecore-based MMs. All
changes of this set are subsequently analyzed concerning their effects on the MM with
respect to structural complexity, i.e., the number of instantiable MM elements, and
information capacity, i.e., the potential number of instances of the MM, since these two
criteria are significant for the impacts on OCL expressions which will be revealed in the
remainder of this paper. Second, the potential impacts of these changes on OCL
expressions are investigated by systematically analyzing the impacts of each of these changes
concerning affected OCL expressions, revealing non-breaking and breaking impacts [
Outline: Section 2 systematically analyzes the impacts of MM evolution on OCL expressions. While lessons learned are presented in Section 3, related work is surveyed in Section 4. Finally, Section 5 concludes the paper with an outlook to future work. 2
In this section, role and importance of OCL in model transformations are highlighted, before the complete and minimal set of changes as well as the investigation of impacts of each change on OCL expressions are presented. Although OCL might also be used in other contexts, e.g., to specify MM constraints restricting the instantiability of the MM, we focus on the co-evolution of OCL in model transformations. Nevertheless, this work might also be applied to other application contexts. A detailed investigation of impacts on OCL constraints in MMs is, however, left to future work. 2.1
In order to illustrate the role and importance of OCL, Figure 1 shows an excerpt of the
well-known Class2Relational transformation5, serving as a running example
throughout the paper. From the example one might see that OCL expressions are used in two
indispensable roles [
Element 1 id:String Metamodel
Evolution 2[3ouaprnbadaiscqettkturrraeeagdcC]e,tl::aBS*stosroinletgyaApntetr:Sibtruitneg4 3214 CCRDreheenaleaanCttmgeeheeaAAOnttAttgrrtrdeitibbresiuurbettueedte ΔΔ+
1 naEmleem:Setnritng
Class 2 package:String abstract:Boolean [o3rdaetrterd=fal*se, type:SAtrtintrgibute
unique] multivalued:Boolean 4 Source Metamodel impacts
In general, model transformations depend on three distinct MMs, being (i) the
source MM, (ii) the target MM, and (iii) the transformation MM (cf. Fig. 1). Thereby,
OCL expressions depend on the source MM by means of a so-called “domain conforms
to”-relationship [
Example. Before proposing the systematic set of atomic changes, four exemplary atomic changes (cf. Fig. 1) with their effects on structural complexity and information capacity of the MM are discussed. First, the attribute Element.id has been renamed to name (cf. 1 in Fig. 1), being updative, i.e., a state change, by nature. Although this causes neither a change in structure nor a change in information capacity, OCL expressions are affected. Second, the attribute Class.package has been deleted (cf. 2 in Fig. 1), being destructive by nature, thus, decreasing structural complexity and information capacity, which impacts OCL expressions significantly, since the deleted element ENamedElement Δ Update Name name:String -+DCereleatteeEEPPaacckkaaggee Δ Update ePackage uornEdiTqeyurpeede:b:dboEooloelelmeaanennt ΔPeaUScupkpdaeagrte-e eSu..pE.ePrPaacckkaaggee ePackage ..E.Classifier lowerBound:int Δ Update Ordered + Create EClass upperBound:int Δ Update Unique - Delete EClass
BoΔuUnpdd/UatpepLeorbwoeurn-d +- CDreeleattee EERReerreeffeerreennccee EStructurΔaUlFpedaatteureeContainingClass eContainingClass ... must not be accessed anymore. Third, the reference Class.attr has been changed from ordered to unordered (cf. 3 in Fig. 1), being again updative by nature, leaving structural complexity and information unaffected, but, however, affecting OCL expressions. Finally, the attribute Attribute.multivalued of type Boolean has been created (cf. 4 in Fig. 1), being constructive by nature, therefore increasing both, structural complexity and information capacity, since this attribute might now be instantiated with true or false, without, however, affecting OCL expressions.
Systematic Set of Changes. Going beyond these four exemplary changes, Figure 2 shows the relevant excerpt of Ecore, including all elements for definingstructure, while disregarding (i) properties for code generation (e.g., volatile), (ii) derived properties (e.g., required), since they may be led back from other properties (e.g., lowerBound), and (iii) operations (e.g., EOperation), since the focus is on MMs defining structure and not behavior. For deriving all constructive and destructive changes, one has to resort to all concrete meta-classes, e.g., EClass. For receiving all updative changes, i.e., state changes of features, one has to refer to all meta-features, e.g., EClass.abstract. The resulting set of atomic changes is shown in Figure 2 as well as in Table 2.
Criteria. Before analyzing the impacts of the changes on OCL expressions, their
effects with respect to (i) structural complexity and (ii) information capacity are analyzed,
being increasing, neutral, or decreasing. Changes affecting structural complexity
indicate impacts in accessing MM elements in OCL expressions and might be evaluated by
counting the number of instantiable MM elements [
Evaluation. In the following, the set of changes is evaluated (cf. Table 2).
Constructive/Destructive Changes: All constructive changes have an increasing effect on both, structural complexity and information capacity, since they increase the number of instantiable MM elements and by this also the potential number of valid instances. In contrast, all destructive changes have the exact opposite effect.
Updative Changes: Whereas all constructive as well as destructive changes behave equally with respect to our criteria, updative changes do not and might be further subdivided into four groups according to their behavior.
Group 1 Renaming Updates: The first group includes updates on ENamedElement.name and EEnumLiteral.value, i.e., renames, being neutral with respect to both, structural complexity and information capacity.
Group 2 Moving Updates: This group regards updates on containment references, i.e., EPackage.eSuperPackage, EClassifier.ePackage , EStructuralFeature.eContainingClass, as well as EEnumLiteral.eEnum, which enable the movement of a feature from one container to another one. Such updates increase structural capacity in the target container, but decrease structural complexity in the source container. Since the features are still available in the MM, yet at another position, the effect on the information capacity is neutral, i.e., not affecting the number of valid instances.
Group 3 Restricting/Relaxing Updates: The third group considers updates on restricting or relaxing the instantiability of MM elements, comprising the features abstract of EClass, upperBound, lowerBound, and unique of ETypedElement as well as all features of EAttribute and EReference. Their effect on structural complexity is neutral, but their effect on information capacity is either increasing or decreasing, depending on the concrete state change. For instance, in case of an increase of feature lowerBound, the number of valid instances decreases, since more values are required. In contrast, a decrease of lowerBound has the opposite effect. Furthermore, type specialization has decreasing effect on information capacity, since the set of valid instances decreases. In contrast, type generalization has increasing effect on information capacity. Please note that feature ETypedElement.ordered has neutral effect on both, structural complexity and information capacity, but impacts the underlying OCL datatype (cf. Sect. 2.3).
Group 4 Constructive/Destructive Updates: Finally, this group considers updates on types, i.e., EClasses themselves, or the datatypes of EStructuralFeatures. This group may be further subdivided into two categories according to their effects. First, the addition of eSuperTypes and pulling up of EStructuralFeatures have increasing effect on information capacity, while their effect on structural complexity is increasing for the addition of eSuperTypes and both, increasing and decreasing for EStructuralFeatures, analogously to moving updates. Second, the deletion of eSuperTypes and pushing down of EStructuralFeatures has decreasing effect on information capacity, while their effect on structural complexity is decreasing for the removal of eSuperTypes and again both, increasing and decreasing for EStructuralFeatures.
In the following, impacts of MM evolution on OCL expressions are exemplified and on basis of this, dedicated criteria are derived, which are finally evaluated with respect to the complete and minimal set of changes.
Example. To reveal impacts of MM evolution on OCL expressions, the running example is utilized again: first, the renaming of the attributeElement.id (cf. 1 in Fig. 1) has no effect with respect to structural complexity and information capacity, but breaking impact on the syntax of all OCL expressions accessing the element either directly or indirectly via inherited versions thereof, i.e., the impact scatters. Second, the deletion of the attribute Class.package (cf. 2 in Fig. 1) naturally has breaking impact on all OCL expressions accessing this element, since the structure has been changed in a destructive way, and since belonging to a leaf class, the impact does not scatter. Third, the
Ecore Meta-Feature lowerBound upperBound = 1 unique/ordered not applicable
unique = true and ordered = true upperBound > 1 unique = true and ordered = false unique = false and ordered = true unique = false and ordered = false
OCL Type Scalar Collection Type Bag Sequence Set OrderedSet
no impact on OCL type
change of the reference Class.attr from ordered to unordered, i.e., ordered=false (cf. 3 in Fig. 1), has breaking impact, although the structural complexity is unaffected, i.e., the feature is still accessible. However, it causes a change of the internally employed OCL collection type from OrderedSet to Set and by this, invalidates the usage of now undefined operations such asfirst() . In this context, Table 1 shows the possible Ecore settings related to collections and the resulting OCL collection type. Finally, the creation of the attribute Attribute.multivalued (cf. 4 in Fig. 1) naturally has no impact.
Criteria. As one might see from the exemplary discussion above, changes may have potential impact on the syntax of OCL expressions being either non-breaking or breaking. Moreover, a change exhibits a certain scope, i.e., the scattering of the impact, being local, i.e., OCL expressions using the MM element itself, or global, i.e., on OCL expressions using inherited versions thereof.
Evaluation. In the following, all changes are systematically evaluated with respect to these criteria. Please note that the evaluation assumes that changed MM elements have been used by at least one OCL expression and the worst case scenario is considered, i.e., changes are evaluated as breaking, if there exists at least one case that breaks the OCL expression. Since the vast majority of changes have local impact regarding the scope as long as they concern elements in leaf classes, this criterion is discussed for exceptional cases, only. The detailed results of the evaluation may be found in Table 2.
Constructive/Destructive Changes: Constructive changes do not have any impact on OCL expressions, since newly created elements can not have been referred to. In contrast, destructive changes always have breaking impact on OCL expressions, since having a destructive effect on the structure.
Updative Changes: Updative changes are evaluated on basis of the groups introduced in Section 2.2, in the following.
Group 1 Renaming Updates: Although renames do neither affect structural complexity nor information capacity, their impact is nevertheless breaking, since renamed elements are no longer accessible under their original name.
Group 2 Moving Updates: Since moves change the structure of instances by changing the position of elements, the impact on OCL is always breaking.
Group 3 Restricting/Relaxing Updates: Although these updates leave the structural complexity unaffected, they impact information capacity, which may also break the syntax of OCL expressions. This is since different settings of features such as ETypedElement.ordered result in different OCL datatypes (cf. Table 1). For example, changing the feature ordered from true to false implies a change from the OCL collection type OrderedSet to Set, thereby invalidating, e.g., the usage of the operation first() .
Group 4 Constructive/Destructive Updates: This group is divided into two categories concerning their effect with respect to information capacity as already mentioned EPackage eEClass itvEAttribute c ruEReference t snEDataType o CEEnum EEnumLiteral EPackage eEClass ivEAttribute t cuEReference trseEDataType DEEnum EEnumLiteral ENamedElement (inherited by: EClass, EPackage, EAttribute, EReference, EDataType, EEnum EEnumLiteral) EPackage EClassifier (inherited by: EClass, EDataType, EEnum) EClass
Change on Ecore-based Metamodel Ecore Meta-Class
Name of Atomic
Change
Meta-Feature
State Change of
Meta-Feature Create EPackage n.a.
Create EClass n.a.
Create EAttribute n.a.
Create EReference n.a.
Create EDataType n.a.
Create EEnum n.a.
Create EEnumLiteral n.a.
Delete EPackage n.a.
Delete EClass n.a.
Delete EAttribute n.a.
Delete EReference n.a.
Delete EDataType n.a.
Delete EEnum n.a.
Delete EEnumLiteral n.a.
Update Name name n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. n.a. oldName → newName and oldName <> newName Update ESuperPackage Update EPackage eSuperPackage oldeSuperPackage →
neweSuperPackage ePackage oldePackage →
newePackage
Effect on Structural InformaComplex- tion
ity Capacity p rouG Ireesacn ltreauN receseaD Irecasen ltreauN reeasceD i-rekabnong irkeangB lcaLo 1 llaobG
N Impact on
OCL
Syntax Scope + + + na.. + + + + no impact possible x x x x x x x x x x x x x x x x x x x x
Abst Syn g n i k a e r b n o N x x x x x x x x x x x x x x x x x x above. First, updates increasing information capacity are comparable to constructive changes and thus, non-breaking. Second, updates decreasing information capacity are comparable to destructive changes and are thus, breaking. The scope of these updates is local, unless eSuperTypes are removed, affecting inheriting elements and therefore, having global impact. 3
This section discusses lessons learned gained from (i) establishing the complete and minimal set of changes as well as from (ii) investigating impacts.
cused on one specific meta-MM, i.e., Ecore, the approach of deriving constructive and destructive changes from concrete meta-classes as well as updative changes from all meta-features is universally applicable since it might be applied to any meta-metamodel.
change set is minimal comprising atomic changes, only, it allows for non-redundant impact analysis. In contrast, a set of composite changes might include overlaps, e.g., “Extract Class” and “Extract Superclass” both include the change “Create EClass”. Composite changes, however, might held more information to be exploited for co-evolution.
changes of meta-features have been broken down into several cases, explicating different state changes. This has been necessary, since different state changes entail different effects on structural complexity and information capacity and, consequently, impact OCL expressions differently, e.g., the state change of upperBound from 1 to > 1 has breaking impact, whereas the state change from > 1 to another number > 1 has not.
tive changes as well as updates with constructive effects (cf. part of group 4 ) that increase structural complexity never break OCL expressions. This is in contrast to model co-evolution where the introduction of required elements has breaking impact on models, since models rely on a different kind of relationship to their MM, i.e., “conforms to”, while transformations “domain conform to” their source and target MMs.
revealed that changes not affecting structural complexity, e.g., updates of group 3 , may nevertheless induce a syntactical breakage of OCL expressions in certain cases as explicated above. This is, since changes of group 3 may induce implicit type changes of the underlying OCL datatypes and by this, change the set of valid operations. 4
Subsequently, related work is evaluated with respect to its focus, supported changes, impact analysis on OCL, and support by a prototypical implementation (cf. Table 3).
Regarding the focus of co-evolution in a specific technical space, two groups of
approaches exist. Most closely related, the first group of approaches targets the
coevolution of transformations employing OCL expressions [
Focus of Work Co-Evolution of Technical Classes of
Space SCuhpapnogretesd
Supported Changes Approach iLnCOM frrsaonm
T
~ (ATL)
(ATL)
(ATL)
by one of them [
Considering the supported changes, six approaches [
Regarding the impact on OCL, four approaches [
In summary, one might see that the work presented in this paper is unique with respect to the complete and minimal set of changes and a systematic in-depth investigation of impacts. This is in contrast to related approaches, which rather concentrate on fully supporting co-evolution for smaller sets of selected composite changes. 5
This paper provided a systematic investigation of impacts of MM evolution on OCL
expressions in model transformations. Basing thereupon, several lines of future work
remain open. First, resolution actions to resolve violations caused by MM evolution
have to be identified. Their goal will be to perform local repairing by establishing a
view simulating the old MM version, e.g., in case of decreasing the upperBound from
> 1 to 1, the now single-valued feature will be wrapped into a collection. In case that
multiple changes have been performed on a single MM-element, the resolution actions
should be chained analogous to the idea presented in [