Subtyping Algorithm

Despite being a core concept, a definition of the term model type is not widely agreed by the MDE community yet. However, due to the similarities between the structures used in MDE (as defined by MOF) and in object-oriented paradigms, its reasonable to expect that theories developed for type systems of object-oriented languages will apply or adapt well for models.

In [116] and [117], Steel and J´ez´equel extended the notion of object subtyping to the realm of models, providing an algorithm for model subtyping (i.e., safe replaceability). This algo-rithm tries to be generic, and provides an elegant approach to address the problem of model type conformance, i.e., to check whether a required model type may be satisfied by a provided model type. In this thesis, we adapt their algorithm to the Ecore structure (see Figure 2.5), i.e., we consider a metamodel as a model type. We selected this choice for practical reasons: (a) a meta-model considers the MDE metalevel hierarchy; (b) there are many languages and operations defined for them that we can make use of; and (c) they are used in model transformation—the model operation par excellence—to describe the input and output parameters type.

5.1. MODELSUBTYPING 69

Definition. Given two model typesM and M^′(i.e., two metamodels), we say thatM^′is subtype ofM (M^′ ≤ M) whenever we can ensure that if we substitute M by M^′, the operations defined overM are also applicable to M^′, guaranteing type safety.

WhenM and M^′ are defined with the Ecore language (see Figure 2.5), this gives place to the following definitions:

• Metamodel M^′ is subtype of metamodelM (M^′ ≤ M) iff:

∀(EPackage)P ∈ M • ∃(EPackage)P^′ ∈ M^′• (P^′ ≤ P)

• EPackage P^′is subtype of EPackageP (P^′ ≤ P) iff:

isRelated(P^′.name, P.name)∧

∀ C ∈ P.eClassifiers • ∃ C^′ ∈ P^′.eClassifiers• (C^′ ≤ C)

• EClass C^′ is a subtype of EClassC (C^′ ≤ C) iff:

isRelated(C^′.name, C.name)∧ (C^′.abstract → C.abstract)∧

∀ SC ∈ C.eSuperTypes • ∃ SC^′ ∈ C^′.eSuperTypes• (SC^′ ≤ SC)∧

∀ SF ∈ C.eStructuralFeatures • ∃ SF^′ ∈ C^′.eStructuralFeatures• (SF^′ ≤ SF)

• EDataType D^′is a subtype of EDataTypeD (D^′ ≤ D) iff:

if (D.oclIsTypeOf (EEnum)∧ D^′.oclIsTypeOf (EEnum)) then (E.eLiterals⊆ E^′.eLiterals)

otherwise (not D.oclIsTypeOf (EEnum)∧ not D^′.oclIsTypeOf (EEnum))∧

((D^′ =D)∨ ((D^′.name = EDouble)∧ (D.name = EInt)))

• EAttribute A^′is subtype of EAttributeA (A^′ ≤ A) iff:

isRelated(A^′.name, A.name)∧ (A^′.eType ≤ A.eType) ∧ (A^′.unique = A.unique)∧

((A.upperBound = A^′.upperBound)∨ (2 ≤ A.upperBound ≤ A^′.upperBound))∧

(A.lowerBound ≤ A^′.lowerBound)∧ (A^′.ordered = A.ordered)

• EReference R^′ is a subtype of EReferenceR (R^′ ≤ R) iff:

isRelated(R^′.name, R.name)∧ (R^′.eType≤ R.eType) ∧ (R^′.unique = R.unique)∧

70 CHAPTER5. MODELMANAGEMENT

((R.upperBound = R^′.upperBound)∨ (2 ≤ R.upperBound ≤ R^′.upperBound))∧

(R.lowerBound≤ R^′.lowerBound)∧ (R^′.ordered = R.ordered)∧

(R^′.eOpposite≤ R.eOpposite)

The subtyping algorithm establishes the relationship that must exist between the elements of two different metamodels (M^′ and M) to ensure that the operations defined over M to be also applicable to M^′. We consider every metamodel element property reflected in the Ecore metamodel except those that refer to Java properties, which are not inherent to a model type description but specific to the EMF capability of generating Java code from the metamodel specification. Initially, we assume theisRelated operation defined as the equality relationship (see Section 5.1.2.1).

Let us illustrate the above definition with an example. We will retake the ATL transfor-mation presented in Section 2.1.4.4, and consider this model transfortransfor-mation as an example of model operation applied over the Author metamodel. Recall that, in this metamodel, authors have a single name and a single surname.

module Author2Person;

c r e a t e OUT : MMPerson from IN : MMAuthor ;

r u l e Author { from

a : MMAuthor ! Author t o

p : MMPerson ! Person ( name<− a . name ,

surname<− a . surname ) }

Now, suppose that we create a new metamodel Author2 on which we consider that an author can have two surnames, i.e., we set the upper bound value of the surname attribute to two. Would this model operation be applicable to the new metamodel? According to the above definition, the Author2 metamodel is not subtype of the Author metamodel, so we cannot ensure that the transformation will be applicable to the Author2 metamodel. In fact, if we define a model conforming to this new metamodel with an author whose name is Jose and whose surnames are Riveraand Cabaleiro, and we run the transformation, what we get is an ATL error, because we are trying to assign a collection of strings (a.surname) to a single string (p.surname).

Since a structural feature is usually accessed differently when its value is a single element and a collection of them, we include in our subtyping algorithm cardinality restrictions to

5.1. MODELSUBTYPING 71

distinguish both cases. For the same reason, we forceordered and unique properties to be equal (note that operations defined over sequences are not the same that those defined over sets, for instance). However, there are other properties, such ascontainment, that do not usually affect to the way an element is accessed in a model operation, and therefore we do not include any restriction about it in our algorithm.

Regarding data types, we consider the Ecore EString, EBoolean, EInt and EDouble data types. The operations defined over integer numbers (except the modulo operation) are also defined over the sortEDouble, and this is why we consider that EDouble ≤ EInt. Note that our context is replaceability or substitution in the application of operations, and therefore, the direction of our subtyping relationship≤ is opposite to the normal direction (EInt ≤ EDouble).

The presented subtyping algorithm is also useful in the context of metamodel evolution. It allows us to know what kind of metamodel modifications will invalidate (or not) the operations defined over a metamodel. For instance, we know that any element (package, class, reference, attribute, etc.) can be added to a metamodel and the operations defined over it will remain applicable. On the contrary, we cannot delete a metamodel element, since this action will usually invalidate the operation. Regarding modifications of elements, we have to perform them in such a way that the restrictions specified in the algorithm remain fulfilled.

5.1.2.1 Kinds of Subtyping

The above subtyping algorithm guarantees that, whenever a metamodel M^′ is subtype of an-other metamodel M, we can substitute M by M^′ and the operations defined over M will be directly applicable overM^′, i.e., we do not need to perform any modification to the operations to apply them over M^′. For this purpose, we assume the isRelated operation defined as the equality relationship, i.e., we force subtype elements to have the same name as their super-types. This kind of subtyping is called strict subtyping.

However, there are cases in which two elements may represent the same element but they have different names: think for instance on spelling mistakes, upper and lower cased differ-ences, or synonyms. Thus, we have also identified another kind of subtyping, subtyping with renaming, that implements theisRelated operation by means of a model that links words that are synonyms, or by defining an operation to compute the distance between two strings. Note that by forcing a relationship between the element names we promote class identity conserva-tion. Specifically, we have implemented the Levenshtein distance [76], a metric that represents the minimum number of operations needed to transform one string into the other, where an

op-72 CHAPTER5. MODELMANAGEMENT

eration is an insertion, deletion, or substitution of a single character. If the Levenshtein distance is lower than a fixed bound, two names can be considered to be related.

Another issue related to the subtyping algorithm is the metamodel package structure, which can be considered not relevant to what a model type refers to. In fact, Steel and J´ez´equel [116]

consider a model type as the set of object types for all the objects contained in a model, i.e., they basically consider as model type a metamodel without its package structure. To cover this case, we have identified two additional kinds of subtyping, namely flattened subtyping and flattened subtyping with renaming. These kinds of subtyping are unaware of the package structure, i.e., they do not consider metamodel packages in their calculations: they compare classifiers independently of the package they belong to. The latter, flattened subtyping with renaming, also allows related elements to have different names.

Finally, note that when the subtype relationship is relaxed by using one of the alternative types: subtyping with renaming, flattened subtyping or flattened subtyping with renaming, we will usually need to adapt the model operations to make them applicable to the new metamodel M^′. We believe that this adaptation can be automatically generated by means of a model transformation that renames the affected elements (in case of subtyping with renaming) or modifies the classifiers package if an ambiguity is possible (in case of flattened subtyping).