Assembling the Proofs of Ordered Model Transformations - arXiv

Assembling the Proofs of Ordered Model Transformations Maribel Fernández

Jeffrey Terrell

Department of Informatics, King’s College London, Strand, London WC2R 2LS, UK [email protected]

In model-driven development, an ordered model transformation is a nested set of transformations between source and target classes, in which each transformation is governed by its own pre and postconditions, but structurally dependent on its parent. Following the proofs-as-model-transformations approach, in this paper we consider a formalisation in Constructive Type Theory of the concepts of model and model transformation, and show how the correctness proofs of potentially large ordered model transformations can be systematically assembled from the proofs of the specifications of their parts, making them easier to derive.

1

Introduction

In this paper, we outline a mechanism to assemble correctness proofs of model transformations in the context of Model Driven Development (MDD). Although MDD is in widespread use, it is essentially an informal approach to software development which does not guarantee the correctness of model transformations. High-trust solutions are essential if MDD is to be used in safety critical systems and beyond. The problem of establishing the correctness of a model transformation is well established, and work has been done towards formalising the process using for instance rewriting languages (e.g. Maude [4]) or typed multigraphs [24]. However, these approaches are first-order and do not reflect the higher-order nature of the UML-based techniques. The aim of our research is to lay the foundations on which a range of certified model transformations might be built, following a line of work that started in [17], where the use of constructive type theory to implement model transformations was first discussed. The notion of an ordered model transformation was introduced in [18], to describe how a complex transformation between models, built from a potentially large number of interrelated classes, might be derived from the specification of a series of mappings between classes, via a partially ordered traversal of the source and target models. This paper represents a significant advance on that work in that it a) formally defines the specification of an ordered model transformation in type theory, and b) provides a mechanism for assembling the proofs of ordered model transformations from their constituent parts. In this paper, a model is a Unified Modelling Language (UML) [7] class model, and a model transformation is a function which maps the artefacts of a source model (classes, attributes and relationships) onto the artefacts of a target model [11, 12]. UML is a graphical language for specifying the structure and behaviour of object oriented systems. It is also a pillar of the Object Management Group’s (OMG) Model Driven Architecture (MDA) [6] (a particular brand of MDD), along with the transformation language Query/View/Transform (QVT) [8] . Consider a transformation between two models (see Fig. 1) in which each object of X is transformed into an object of Y , via a precondition at X and a postcondition at Y . In general, the postcondition at Y is composed of three components: Data asserts a relation between the attributes of X and Y ; Link asserts a relation between Y and the class that contains it; and Nest defines the specification (in context) of the B. Buhnova, L. Happe, J. Kofroˇn: Formal Engineering Approaches to Software Components and Architectures 2013 (FESCA’13) EPTCS 108, 2013, pp. 63–77, doi:10.4204/EPTCS.108.5

c M. Fernández & J. Terrell

This work is licensed under the Creative Commons Attribution License.

64

Ordered Model Transformations

R

PreX

∗

X

PostY

S

∗

/Y S0

R0 ∗

∗

Figure 1: A transformation between classes X and Y , which is subject to a precondition on X and a postcondition on X and Y .

transformation between the classes that X and Y contain (clearly, if Y were a root class, the postcondition would not have a Link component, and if Y were a leaf class, the postcondition would not have a Nest component). While Data components vary significantly between transformations (there is no reason why they should be the same), the Link and Nest components are generally quite similar. In fact the only assertion that a Link component can make is that Y participates in a relationship with the class that contains it; and all that a Nest component can do is pass control of the specification to the classes that X and Y contain. This opens up the prospect of removing from users the tedious task of proving Link components by hand.1 Of course, this prospect only presents itself by virtue of the ordered nature of the models and transformations under consideration, where order is defined by containment. However, such transformations are sufficiently common in practice (see, for instance, [11] for examples) to make this a worthwhile pursuit. In this paper, we focus on a particular but nonetheless ubiquitous kind of model transformation, in which the source and target models are either partially or totally ordered.2 In particular, based on the definitions of model and model transformation given in [17], we show that the proofs of the specifications of large ordered model transformations can be systematically assembled from their parts, making them easier to derive. Our main contribution is a method to derive correctness proofs for ordered model transformations by assembling the proofs of their parts, within constructive type theory. We illustrate the method with examples. The proofs in this paper have all been implemented in the Coq Proof Assistant [1], see the Coq scripts at http://www.inf.kcl.ac.uk/pg/terrellj. The paper is organised as follows: In Section 2, we give a brief introduction to MDA and type theory, to try to make the paper self contained. In Section 3, we show how to formalise a model transformation (the specification and its correctness proof) in constructive type theory, including the key notion of a parametric proof (a proof with a hole over which it is possible to quantify and hence parametrise). We then use this idea to formally specify ordered model transformations in general in Section 4. In Section 5, there is a concrete example of an assembled proof. Finally, in Section 6, we sum up and discuss future developments.

1 The

proof of an assertion involving a many-valued relationship requires a proof by list induction, and the proof of a chain of many-valued relationships, which is not uncommon, requires a nested set of proofs by list induction. 2 Hierarchical models are the rule rather than the exception in industry (the UML metamodel is fundamentally hierarchical), where transformations are notable for their size rather than their complexity.

M. Fernández & J. Terrell

2

65

Preliminaries

We recall the basic notions of Model Driven Architecture (MDA) and Constructive Type Theory (CTT) that are used in the paper. We refer the reader to [11] and [13] for more details on MDA and CTT, respectively.

2.1

Model Driven Architecture

The movement away from the machine to a higher level of abstraction began in earnest in the early 1990s, with the advent of a number of object-oriented analysis and design methodologies. The most influential, in the authors’ view, was the one proposed by Shlaer and Mellor in [21, 22], for it played a huge part in shaping the MDA a decade later. The aims of the MDA are two-fold: first, that software systems should be developed independently of the platforms on which they will eventually run, and second, that they should be translated into specific implementations using standard parts, namely model to text and model to model transformations. In its simplest form, a model transformation takes as input a model, written in a source modelling language (IL), and outputs a new model, written in a possibly different target modelling language (OL). The transformation should be applicable to any model written in IL, therefore it can be seen as a mapping from elements of IL to elements of OL. In MDA, both the input and output languages are defined as metamodels within the Meta-Object Facility (MOF) [15]. Metamodelling in the MOF is usually done according to a four level hierarchy [14]. The levels are related by an object-oriented style class/object instantiation relationship: classes at level Mi+1 provide descriptions of objects at level Mi . Roughly speaking, we can think of entities at the M0 level as objects representing instances of an M1 UML class. The M2 level is where metamodels are defined. Metamodels are collections of instances of the M3 level classes (meta-meta-classes). The M3 level of the MOF model is used to classify the elements that make up an M2 level metamodel. Following [17, 18], in this paper we will consider model transformations as higher-order functional programs satisfying certain pre and post conditions.

2.2

Constructive Type Theory

The type theory below is based on the one proposed by Martin-Löf [13]. A type is defined by prescribing how its inhabitants are formed. For example, if S is the successor function, then the inhabitants of the type Nat are given by n : Nat . 0 : Nat (S n) : Nat If A and B are types, then A ∧ B, A ∨ B and A → B are defined to be types too, where A ∧ B is inhabited by a pair of inhabitants of A and B, A ∨ B is inhabited by an inhabitant of A or B, together with an indication as to whether it is an inhabitant of A (on the left) or B (on the right), and A → B is inhabited by a function from A to B, i.e.

a: A b: B ha, bi : A ∧ B

a: A inl a : A ∨ B

b: B inr b : A ∨ B

[a : A] .. .. b: B . λa: A.b: A → B

66


If a is an inhabitant of A, and B(a) is a type whose inhabitants depend on a, then ∀a : A . B(a) and ∃a : A . B(a) are defined to be types, where ∀a : A . B(a) is inhabited by a function that takes A to B(a), and ∃a : A . B(a) is inhabited by a pair of inhabitants of A and B(a), i.e. [a : A] .. .. b : B(a) λ a : A . b : ∀a : A . B(a)

a : A b : B(a) . ha, bi : ∃a : A . B(a)

One particular type that we shall meet often in this paper is ∀a : A . P(a) → ∃b : B . Q(a, b) , which defines the specification of a transformation that takes a source class A to a target class B, subject to precondition P(a) and postcondition Q(a, b). Note that types A ∧ B and A → B are special cases of types ∀a : A . B(a) and ∃a : A . B(a) where B is independent of a. A term λ a : A.b of type A → B represents a function from A to B. Application is written simply as juxtaposition: t : ∀a : A.B(a) s : A . (t s) : B(s) Further, the reduction relation is generated by the β -rule: (λ a : A.t)s → t{a 7→ s} The reflexive and transitive closure of the one-step reduction relation → is denoted by . We shall also add to our language a predicate =, which we can use to build dependent types like x = 0, where x : Nat. When 0 is substituted for x, the type becomes 0 = 0, which is inhabited by r(0) (see [25] for more details); when 1 is substituted for x, the type becomes 1 = 0, which is uninhabited. Lastly, we shall add the type [E] of lists of elements of type E to our language, and two distinguished types Set and Prop, which will be used to classify types.

3

Type Theory for Model Transformations

In this section, we formalise UML classes and objects using constructive type theory. Definition 1. A UML class C is encoded as a type, that is, an inhabitant of type Set; and a UML object of C is encoded as an inhabitant of type C. Furthermore, a base attribute of C is encoded as an inhabitant of type C → τ1 , where τ1 is a ground type, e.g. Nat; and a referential attribute of C is encoded as an inhabitant of type C → τ2 , where τ2 is the type of some other UML class or class list. We shall assume that every UML class C has a single base attribute IdC of type Nat, and as many referential attributes as it needs to encode the relationships in which it participates. For example, if C is linked by a one-valued relationship to UML class D, and a many-valued relationship to UML class E, then the rule for constructing the inhabitants of C is as follows, where @C denotes an anonymous constructor of C. n : Nat d : D l : [ E ] . @C n d l : C


67 A

PreA

PostP

/P

Figure 2: A transformation between A and P. The judgement a : A admits several different readings: a is an inhabitant of type A (as above), a is a program whose specification is A (which may be that of a model transformation), and a is a proof of proposition A (which may be that of a precondition). In the last reading, A is defined to be an inhabitant of type Prop, where A is considered to be true if and only if it is inhabited. The relationship between propositions and types, which was first discovered by Curry [5] and later extended by Howard [9], is known as the Curry-Howard isomorphism. In this paper, we describe a technique to derive proofs of potentially large ordered model transformations. To illustrate the ideas underlying this technique, we consider first a simple model transformation, where each object of class A (see Fig. 2) is transformed into an object of class P, subject to a precondition PreA of type A → Prop and a postcondition PostP of type A → P → Prop. 3 The specification of the transformation is formalised as a type, i.e. ∀a : A . PreA a → ∃p : P . PostP a p ,

(1)

and its proof is given by [a : A] 1

[h : Pre a] 2 .. .. Hole u : Post a p (∃ I) hp, ui : ∃p : P . Post a p (→ I) 2 λ h . hp, ui : Pre a → ∃p : P . Post a p (∀I)1 , λ a . λ h . hp, ui : ∀a : A . Pre a → ∃p : P . Post a p

(2)

i.e. a function that takes an object a of A and a proof h of PreA a, and returns as a pair the corresponding object p of P and a proof u of PostP a p. There is a hole in the proof above because the transformation is under specified. However, given suitable definitions of A, P, PreA and PostP , the hole could be filled and the proof completed. Furthermore, given a second transformation with a different set of definitions of A, P, PreA and PostP , we could apply the same procedure. However, the proofs would be so similar, at least in outline, that it should be possible to capture them all in a parametrised proof, by quantifying over all source and target classes, pre and postconditions, and proofs of holes, in the specification of the transformation. Based on this idea, we define the following correctness condition. Definition 2 (Correct Model Transformation). A correct model transformation from X to Y should ensure that for each x in X that satisfies the precondition there is a y in Y that satisfies the postcondition. This is formalised using the following type: ∀X : Set . ∀Y : Set . ∀Pre : X → Prop . ∀Post : X → Y → Prop . ∀ f : X → Y . ∀Hole : (∀x : X . Pre x → Post x ( f x)) . ∀x : X . Pre x → ∃y : Y . Post x y .

(3)

3 Preconditions serve several purposes. First, to allow a choice of rules in different cases, e.g. by checking that a class is a root class, if root classes are transformed by a different rule to non-root classes. Second, to ensure that a postcondition is well-defined, e.g. by insisting that x ≥ 0 if the postcondition takes the square root of x. Third, to ensure that only certain source elements are transformed, e.g. by checking that a class is persistent, if only persistent classes are mapped to database tables. In the first and second cases, we might expect the precondition to contribute to the proof of the postcondition.

68

Ordered Model Transformations The proof of (3) is little more than two eliminations and a sequence of introductions, i.e. [X : Set] 1 [Y : Set] 2 [Pre : X → Prop] 3 [Post : X → Y → Prop] 4 [ f : X → Y ]5 .. .. [Hole : (∀x : X . Pre x → Post x ( f x))] 6 [x : X] 7 (∀E) Pre x → Post x ( f x) [h : Pre x] 8 (→ E) Post x ( f x) (∃ I) ∃y : Y . Post x y (→ I) 8 Pre x → ∃y : Y . Post x y (∀I)7 ∀x : X . Pre x → ∃y : Y . Post x y (∀I)6 ∀Hole : (∀x : X . Pre x → Post x ( f x)) . ∀x : X . . . . (∀I)5 ∀ f : X → Y . ∀Hole : (∀x : X . Pre x → Post x ( f x)) . . . . (∀I)4 ∀Post : X → Y → Prop . ∀ f : X → Y . . . . (∀I)3 ∀Pre : X → Prop . ∀Post : X → Y → Prop . . . . (∀I)2 ∀Y : Set . ∀Pre : X → Prop . . . . (∀I)1 . ∀X : Set . ∀Y : Set . . . .

(4)

The fixed outline shape of the proof is captured by rules (∃ I) to (∀I)7 , and the variable proof of the hole is captured by assumption 6. Furthermore, the function K defined below can easily be shown to inhabit (3). K =d f λ X . λY . λ Pre . λ Post . λ f . λ Hole . λ x . λ h . h( f x), ui . (5) Note that the arguments X and Y are arbitrary source and target classes; Pre and Post are arbitrary pre and postconditions; f is a function that maps source objects to target objects; Hole is a proof of the hole (see (2)); x is a source object; and h is a proof that the precondition holds on the source object. K returns a target object ( f x), and a proof u that the postcondition holds on the source and target objects. We shall now apply K to a particular transformation, i.e. the one between A and P. Let PreA be a predicate that holds on all objects of A, and let PostP be a predicate that holds on all objects of A and P which have the same base attribute values. Formally, let PreA =d f λ a . > PostP =d f λ a . λ p . (IdA a = IdP p) . Now, if fA =d f λ a . @P (IdA a) , then the proof of the hole is [a : A] 1

[h : >] 2 .. .. pIdA : A → Natq [a : A] 1 (→ E) IdA a : Nat (II) r(IdA a) : IdA a = IdA a (→ I) 2 λ h . r(IdA a) : > → IdA a = IdA a (∀I)1 λ a . λ h . r(IdA a) : ∀a : A . > → IdA a = IdA a ( =d f ) . λ a . λ h . r(IdA a) : ∀a : A . PreA a → PostP a ( fA a)


69 A

PreA

PostP

/P

PostQ

R1

PreB

B

S1

/Q

Figure 3: A two-runged transformation Furthermore, if HoleA =d f λ a . λ h . r(IdA a) , then K A P PreA PostP fA HoleA (@A 1) Triv h(@P 1), r(IdA (@A 1))i . Therefore, @P 1 is the transform of @A 1, and r(IdA (@A 1)) is the term that proves it. In the next sections we generalise these ideas to families of ordered model transformations.

4


In the previous section, we showed how the specification of a small transformation could be abstracted into the specification of a family of transformations, by quantifying over all possible source and target classes, pre and postconditions and holes. The proof that resulted contained a fixed part, common to all members of the family, and a variable part, specific to a particular member. In this section, we extend these ideas to ordered model transformations in general. There are two kinds of ordered transformations: totally and partially ordered. Informally, a totally ordered set of transformations is one that has the shape of a ladder, in which the source and target models are the verticals, and the transformations are the rungs. A partially ordered set of transformations has the shape of a tree of ladders, in which the branches between nodes are totally ordered transformations. We give examples before presenting the formal definitions. Consider the two-runged transformation in Fig. 3, in which A is transformed to P subject to conditions PreA and PostP , and B is transformed to Q subject to conditions PreB and PostQ . If an object a of A is transformed to an object p of P, then the object R1 a of B is transformed to the object S1 p of Q. In other words, the transformation of B to Q is nested within the transformation of A to P. As before, we shall define the specification of the transformation as a type, outline its proof, and abstract over classes, conditions and holes. The transformation along each rung is similar to the one between A and P earlier. However, the transformation between the verticals (relationships) is new. The specification of the transformation that is depicted in Figure 3 is formalised as a type as follows (for ease of readability, we write one rung per line). ∀a : A . PreA a → ∃p : P . (PostP a p ∧ ∀b : B . PreB b ∧ (R1 a) = b → ∃q : Q . PostQ b q ∧ (S1 p) = q) .

(6)

The transformation along the second rung is nested within the first rung, and has stronger pre and postconditions in virtue of the connectivity constraints placed on objects of B and Q. Note that a third or fourth rung would have the same shape as the second rung.

70

Ordered Model Transformations f

x

R

Rx

Com f0

/ fx

S

/ S ( f x) = f 0 (R x)

Figure 4: The commutative square Com. In outline, the proof of (6) is [a : A] [a : A] [b : B] [b : B] [PreB b ∧ R1 a = b] [PreB b ∧ R1 a = b] (∧ E1 ) (∧ E2 ) pPre.B bq pR1 a. = bq .. Hole .. Com B A . . PostQ b q S1 p = q [a : A] (∧ I) (PostQ b q ∧ S1 p = q) [q/q] [PreA a] .. .. .. Fixed .. HoleA PostP a p (∀b : B . PreB b ∧ R1 a = b → . . .) [p/p] (∧ I) (PostP a p ∧ ∀b : B . PreB b ∧ R1 a = b → . . .) [p/p] .. .. Fixed ∀a : A . PreA a → ∃p : P . PostP a p ∧ . . . The fixed parts of the proof exist in virtue of the structure of the specification, whereas the variable parts exist in virtue of its under-specification. The variable parts are either of the Hole kind, i.e. proofs that postconditions are derived from preconditions, or the Com kind, i.e. proofs that adjacent rungs are linked. Quantifying over all variables in (6), including proofs of variable parts, and changing the names of bound variables where appropriate, we obtain the specification of an arbitrary two-runged transformation. Definition 3 (Two-Runged Model Transformation). An arbitrary two-runged model transformation is formalised in constructive type theory by the following type: ∀X : Set . ∀Y : Set . ∀Pre : X → Prop . ∀Post : X → Y → Prop . ∀ f : X → Y . ∀Hole : (∀x : X . Pre x → Post x ( f x)) . 0

∀X : Set . ∀Y 0 : Set . ∀Pre0 : X 0 → Prop . ∀Post 0 : X 0 → Y 0 → Prop . ∀ f 0 : X 0 → Y 0 . ∀Hole0 : (∀x0 : X 0 . Pre x0 → Post x0 ( f 0 x0 )) . ∀R : X → X 0 . ∀S : Y → Y 0 . ∀Com : (∀x : X . S ( f x) = f 0 (R x)) . ∀x : X . Pre x → ∃y : Y . Post x y ∧ 0

0

0 0

∀x : X . Pre x ∧ R x = x0 → ∃y0 : Y 0 . Post 0 x0 y0 ∧ S y = y0 .

(7)

This formalisation is similar to the one in (3) except that it also quantifies over Com, i.e. a proof that starting from every object x of X (X being the source end of the first rung) and navigating to some object y0 of Y 0 (Y 0 being the target end of the second rung), first via f and S, and then via R and f 0 , the same y0 is obtained. The commutative square, after which Com is named, is shown in


71

Fig. 4. Furthermore, given a proof of Com, it is a trivial matter to prove that the rungs are linked, i.e. [x : X] [Com : ∀x : X . S ( f x) = f 0 (R x)] (∀E) S ( f x) = f 0 (R x) pR x = x0 q (IE) . S ( f x) = f 0 x0 Property 1. The function that inhabits (7) is λ X Y Pre Post f Hole X 0 Y 0 Pre0 Post 0 f 0 Hole0 R SCom x h.h( f x), ui Proof. Direct, using the typing rules given in Section 2. Note that the first element of the output pair is the result of applying the root function f to an arbitrary root object x, reflecting the fact that an ordered transformation is essentially a transformation between root classes. We are now ready to formalise the notion of ordered model transformation. First we consider totally ordered transformations, and later we extend the results to partially ordered transformations.

4.1

Totally Ordered Transformations

In order to formalise totally ordered model transformations, we will define a dependent type T X Y f , where T is the type name, and X, Y and f are the parameters on which it depends, i.e. root source class, root target class and root function respectively. A totally ordered transformation is an inhabitant of this dependent type. The inhabitants of T are defined inductively, in much the same way as Nat, by means of a base rule and a step rule. Definition 4. (Type T X Y f ) The type T is defined inductively, with a rule defining the base case and a rule defining the inductive step, as follows: X : Set Y : Set f : X → Y X 0 : Set Y 0 : Set f 0 : X 0 → Y 0 Pre0 : X 0 → Prop Post 0 : X 0 → Y 0 → Prop Hole0 : ∀x0 : X 0 . Pre0 x0 → Post 0 x0 ( f 0 x0 ) R : X → X 0 S : Y → Y 0 Com : ∀x : X . f 0 (R x) = S ( f x) TBase X Y f X 0 Y 0 f 0 Pre0 Post 0 Hole0 R SCom : T X Y f X : Set Y : Set f : X → Y X 0 : Set Y 0 : Set f 0 : X 0 → Y 0 Pre0 : X 0 → Prop Post 0 : X 0 → Y 0 → Prop Hole0 : ∀x0 : X 0 . Pre0 x0 → Post 0 x0 ( f 0 x0 ) R : X → X 0 S : Y → Y 0 Com : ∀x : X . f 0 (R x) = S ( f x) t0 : T X 0 Y 0 f 0 TStep X Y f X 0 Y 0 f 0 Pre0 Post 0 Hole0 R SCom t 0 : T X Y f

(T I1 )

(T I2 )

The base rule constructs a transformation of the kind shown in Fig. 5 (left). Note that the root hole and root pre and postconditions (to clarify, the root is at the top) are not part of the construction. The step rule constructs the successor of a transformation t 0 , of the kind shown in Fig. 5 (middle). Again, the root hole and root pre and postconditions are not part of the construction.

72

Ordered Model Transformations f

X f

X

/Y

R

Com

Pre0 X0

f0

Hole0

Post 0/

R

Com

Pre0 X0

f0

t0 :

S

Y0

X 00

Hole0 T

X0 Y 0

/Y

fa

A S

R1

Com1

/P S1

Y0

PreB fb PostQ /Q B

Y 00

PreC fc PostR /R C

Post 0/ f0

HoleB

R2

Com2

S2

HoleC

Figure 5: From left to right: representations of the base and step rules of type T , followed by an inhabitant of type T A P fa , namely tAP . To construct an inhabitant of T , we first apply the base rule and then repeatedly apply the step rule. For example, the transformation tAP in Fig. 5 (right) is constructed as follows: tBQ =d f TBase B Q fb C R fc PreC PostR HoleC R2 S2 Com2 , tAP =d f TStep A P fa B Q fb PreB PostQ HoleB R1 S1 Com1 tBQ . By extension of (6), it would be easy to write down the specification of tAP , including the root transformation we have so assiduously excluded. However, much more useful would be to write down a function that could compute it, not only for tAP but also for every other inhabitant of T X Y f as well. Such a function is given below. Definition 5. (Spec) Spec : ∀X : Set . ∀Y : Set . ∀ f : X → Y . T X Y f → (X → Y → Prop) Spec X Y f (TBase X Y f X 0 Y 0 f 0 Pre0 Post 0 Hole0 R SCom) =d f λ x : X . λ y : Y . ∀x0 : X 0 . Pre0 x0 ∧ x0 = R x → ∃y0 : Y 0 . Post 0 x0 y0 ∧ y0 = S y Spec X Y f (TStep X Y f X 0 Y 0 f 0 Pre0 Post 0 Hole0 R SCom t 0 ) =d f λ x : X . λ y : Y . ∀x0 : X 0 . Pre0 x0 ∧ x0 = R x → ∃y0 : Y 0 . Post 0 x0 y0 ∧ y0 = S y ∧ Spec X 0 Y 0 f 0 t 0 x0 y0 .

(8)

Now, the specification of a transformation is an inhabitant of Prop. However, Spec returns an inhabitant of type X → Y → Prop. Why? To allow it to be integrated with the root objects of type X and Y , passed down to it by the root transformation. In its general form, an ordered model transformation is formalised as follows. Definition 6. (Ordered Model Transformation) An ordered model transformation is an inhabitant of type ∀X : Set . ∀Y : Set . ∀ f : X → Y . ∀t : T X Y f . ∀Pre : X → Prop . ∀Post : X → Y → Prop . ∀Hole : ∀x : X . Pre x → Post x ( f x) . ∀x : X . Pre x → ∃y : Y . Post x y ∧ Spec X Y f t x y .

(9)


73

X X0

f

/Y

t1

t2

Y0

X 00

Y 00

Figure 6: A representation of the join rule of type T . A proof of (9) (an inhabitant of the type) has the form: λ X . λY . λ f . λt . λ Pre . λ Post . λ Hole . λ x . λ h . h( f x), ui ,

(10)

where u is a proof of Post x ( f x) ∧ Spec X Y f t x ( f x) . According to (10), if we could construct an inhabitant of type T from suitable values of Hole (a proof of the root hole), X and Y (the root classes), f (the root function), and Pre and Post (the root conditions), then we could justifiable claim that h( f x), ui is a certified implementation of the transformation, for an arbitrary source object x. In other words, constructing a suitable value of t is tantamount to proving the specification.

4.2

Partially Ordered Transformations

We generalise the construction to take into account the case where transformations are partially ordered. Without loss of generality, we assume that a partially ordered transformation can be constructed from two ordered transformations, as shown in Fig. 6. Thus, we extend the definition of T X Y f in Definition 4 with a join rule, i.e. t1 : T X Y f t2 : T X Y f (T I3 ) , TJoin t1 t2 : T X Y f and extend the definition of Spec (Definition 5) with a case for TJoin , which returns the conjunction of the specifications of t1 and t2 , i.e. Spec X Y f (TJoin t1 t2 ) =d f λ x : X . λ y : Y . Spec X Y f t1 x y ∧ Spec X Y f t2 x y . See Fig. 7 for an example.

5

Concrete Example

Consider a transformation between the UML and SQL models in Fig. 8, in which • each model m is mapped to a schema s of the same name; • each class c in m is mapped to a table t in s of the same name, and a primary key column in t of the same name; • each attribute in c is mapped to a non-primary key column in t of the same name; • the mappings are unconditional, i.e. the preconditions always hold.

74


A

fa

/P

t7

/Q

B

t6

C

/S

E

t5

t4

D

/R t1

G

/T

F /U

t3

t2

H

/V

J

/W

I Figure 7: An example of a partially ordered transformation, in which A, B, . . . , J are the source classes, P, Q, . . . ,W are the target classes, and A is transformed to P, B to Q and so on. The transformation (minus the root artefacts) is given by t7 , where t1 =d f TBase . . ., t2 =d f TBase . . ., t3 =d f TBase . . ., t123 =d f TJoin (TJoin t1 t2 ) t3 , t4 =d f TStep . . . t123 , t5 =d f TBase . . ., t6 =d f TStep . . . t4 , t56 =d f TJoin t5 t6 , and t7 =d f TStep . . . t56 . The specification of the transformation is given by Spec A P fa t7 . The specification of the transformation is given by ∀m : Model . PreModel m → ∃s : Schema . PostSchema m s ∧ Spec Model Schema fModel tModel−Schema m s , where tModel−Schema : T Model Schema fModel−Schema . If m1 =d f @Model 1 [ c1 , c2 , c3 ] c1 =d f @Class 2 [ @Attribute 5, @Attribute 6, @Attribute 7 ] c1 =d f @Class 3 [ @Attribute 8 ] c3 =d f @Class 4 [ ] , i.e. a model with 3 classes and 4 attributes, then K Model Schema fModel PreModel PostSchema HoleModel m1 Triv reduces to hs1 , pi, where s1 is given by s1 =d f @Schema 1 [t1 ,t2 ,t3 ] t1 =d f @Table 2 [ @Column 2 true, @Column 5 f alse, @Column 6 f alse, @Column 7 f alse, ] t1 =d f @Table 3 [ @Column 3 true, @Column 8 f alse ] t3 =d f @Table 4 [ @Column 4 true ] ,


75

Model model_name: string classes : list Class

Schema schema_name: string tables : list Table

* tables * classes

Class class_name: string attributes : list Attribute

Table table_name: string columns: list Column

* columns * attributes

Attribute attribute_name: string

Column column_name: string is_primary_key: bool

Figure 8: The UML and SQL models. i.e. a schema with 3 tables and 7 columns (3 of which are primary keys), and p is an unspecified proof (through lack of space) that s1 is indeed the transform of m1 .

6

Related Work and Conclusions

A number of authors have attempted to provide a formal understanding of metamodelling and model transformations. Ruscio et al. have made some progress towards formalizing the KM3 metamodelling language using Abstract State Machines [20]; and Rivera and Vallecillo have exploited the class-based nature of the Maude specification language to formalize metamodels written in KM3 [19]. Further, a related algebraic approach is given by Boronat and Meseguer in [2]. More recently, Calegari et al. [3] proposed a framework for encoding models and metamodels in the Calculus of Inductive Constructions (CIC) [23, 1], and in doing so showed how parts of the ATL model transformation language [10] could be expressed in the CIC, including matched rules, helpers and expressions based on the Object Constraint Language (OCL) [16]. In this paper, we have shown how to assemble the proof of a potentially large ordered model transformation, by decomposing it into a number of smaller proofs which are easier to derive. 4 We focused on a particular kind of transformation with uniform characteristics, which we hope to extend to other kinds of transformations in the future, although we have already incorporated a number of additional variants into the scheme outlined above, including support for many-valued relationships, unmapped source classes (of which C is an example in Fig. 7) and multiple target classes. In future work, we will extend the techniques to a larger class of model transformations, by abstracting over the non-hierarchical parts of models too. One way of achieving this would be to quantify over arbitrary propositions in each postcondition so that users could include a non-hierarchical proof fragment where necessary. To a certain extent, this is already supported because the Data component of a postcondition is user-defined and therefore arbitrary. However, another option would be to add a separate conjunct to the postcondition. 4

The reader should note that this approach could never be fully automatised in virtue of the unlimited scope of pre and postconditions. However, once the smaller proofs are available, the process of assembling them into a proof of the whole could indeed be automatised.

76


Clearly, we do not exclude the possibility of an ordered model being embedded within a larger model, like an ordered core with an unordered covering (for example, see Fig. 9). In fact, our experience suggests that the majority of industrial models (which are characterised by their size rather than their complexity) are like this, and that the algorithms which transform them invariably perform preorder traversals of the ordered cores of the source models. That is not say that every model transformation fits this mould. However, it is reasonable to suppose that the lessons learnt from this study may also be applicable to other kinds of model transformations. has assignment dynamics modelled by

Assigner State Model {no=52, kl=ASM}

0..1

R60

attributes

analysis area id [ID] (R60) class key letter [ID] (R60) status attribute name

{no=28, kl=EIS}

Existing Instance State attributes

analysis area id [ID] (R132) state number [ID] (R132) class key letter [ID] (R132) state name method is creation is terminal description

Nonexistent State

Executable UML v31

{no=120, kl=NS} attri butes

analysis area id [ID] (R132) state number [ID] (R132) class key letter [ID] (R132)

Version 3.1.0 CCG_XUML for iCCG XUML for iUML API

is a state of 1

is used by 1

R54

attributes

causes entry to

analysis area id [ID] (R54) class key letter [ID] (R54) state number [ID] state name is start state method description

0..*

0..1

Instance State

R133

{no=119, kl=IS} R193

1..*

attributes

analysis area id [ID] (R135,R135) class key letter [ID] (R135) target class key letter [ID] (R135) signal number [ID] (R135)

R145

1..* is responded to in

responds to

0..*

analysis area id [ID] (R133) class key letter [ID] (R133) state number [ID]

{no=9, kl=FA}

R29

attri butes

Derived Association

analysis area id [ID] (R7) relationship number [ID] (R7) location of formalisation

1

{no=10, kl=DA} attributes

belongs to

Not supported by the API

Instance State Model

analysis area id [ID] (R7) relationship number [ID] (R7)

references an identifier at the A end of

attributes

R8 is derived from

0..*

has instance dynamics modelled by

UML Association {no=4, kl=UMLA} attri butes

is at A 0..* end of

is at 0..* B end of

R2

R3

has an A end of

has a B end of

1

is used by 0..*

R135

0..1

0..*

0..1

Assigner SPC

models the assignment dynamics of is signal role of 1 {no=7, kl=AC}

1

{no=139, kl=ASPC}

analysis area id [ID] (R157,R169) class key letter [ID] (R157,R169) spc type [ID] (R157)

has role 1

R61

models the instance dynamic behaviour of

1

1

R128 contains 0..*

{no=2, kl=C}

R224 performs signal role for 1 R168 represents specific counterparts generically to

Signal Transmission

is located at branch with

belongs to

1

is at branch which is the location of 0..*

0..1

Subclass Participation

{no=14, kl=RI} is formalised by

attri butes

R220

R244

{no=16, kl=SP}

formalises

1

attributes

0..1

R12

R13

analysis area id [ID] (R13,R13,R220) relationship number [ID] (R13,R220) subclass class key letter [ID] (R13) relationship end (R220)

is pointed at by

defers implementation to 1..*

attri butes

is route for deferral of

analysis area id [ID] (R244,R240,R245) operation id [ID] (R244,R240) subclass class key letter [ID] (R245) parent class key letter (R244)

1..*

0..*

attributes

{no=15, kl=GEN} is further deferred down

analysis area id [ID] (R12) relationship number [ID] superclass class key letter (R12)


0..* is route for further deferral of

is superclass in 0..*

is subclass in 0..*

R9

Generalisation

contains

R20 points to 1

1..* is characterised by {no=5, kl=A}

Attribute

1..*

0..*

attributes

attri butes

analysis area id [ID] (R10) referential attribute name [ID] (R10) referencing class key letter [ID] (R10)

is referenced by

R23

refers to

Non Referential Attribute

R16

contains

analysis area id [ID] (R9,R71) class key letter [ID] (R9) attribute name [ID] description data type name (R71) default value

{no=17, kl=I}

Identifier

is input for

attri butes

analysis area id [ID] (R14) identifier number [ID] class key letter [ID] (R14) preferred

contains

0..*

Supplementary Signal Parameter Carried By UML Signal

{no=136, kl=NCTERM} attri butes

{no=147, kl=SSPCBS} attributes

Domain Operation

0..*

has role 1

has output

0..*

R199

0..*

{no=140, kl=ISPC}

attributes is carried by analysis area id [ID] (R157,R168,R199) all signals of class key letter [ID] (R157,R168,R199) 0..1 spc type [ID] (R157) identifier number (R199)

contains 0..* has input

*

Instance SPC

R237

{no=155, kl=OPP}

Operation Parameter attri butes

has name and or type linked to

provides name and or type for

R203

0..*

0..1

operation id [ID] (R201,R202) analysis area id [ID] (R203,R207,R201,R202) name [ID] is a set position data type mode linked attribute name (R203) data type name (R207) linked class key letter (R203)

receives

carries supplementary 0..*

0..*

attri butes

is type of


analysis area id [ID] (R192,R191,R190) provides name and or type for owning spc key letter [ID] (R190) spc type [ID] (R190) 0..* parameter name [ID] data type mode is a set data type name (R191) linked attribute name (R192) linked class key letter (R192)

R192

0..*

0..1 specifies the domain of

R207

0..*

R223 R222

R71 has its domain specified by R185

defines type of

{no=81, kl=SIGP}

Signal Parameter

0..1

0..*

R151

contains

*

is always identifed by 1

analysis area id [ID] (R151,R151) target spc key letter [ID] (R151,R151) target spc type [ID] (R151,R151) signal number [ID] (R151) parameter name [ID] (R151) position

R190

R238

R202

is part of

attributes


R184

0..1

Non Counterpart Terminator analysis area id [ID] (R157,R223) terminator key letter [ID] (R157) name description spc type (R157) is foreign

1

{no=163, kl=DOMOP}


provides name and or type for

is 0..1 output for

is provided by R218

0..*

attri butes

analysis area id [ID] (R16,R16) identifier number [ID] (R16) class key letter [ID] (R16,R16) attribute name [ID] (R16)

R10

{no=149, kl=DSMEM} attri butes

is carried by 1..*

is {no=158, kl=STERM} provided attri butes analysis area id [ID] (R211) by terminator key letter [ID] 1 name description class key letter (R211)

R217

provides

provides

{no=162, kl=NCTOP}

operation id [ID] (R215) analysis area id [ID] (R222,R215)

{no=20, kl=AII}

{no=13, kl=NRA}

1

0..*

Non Counterpart Terminator Operation operation id [ID] (R215) analysis area id [ID] (R218,R215) terminator key letter (R218)

0..*

attri butes

Data Structure Member

analysis area id [ID] (R184,R189,R185) data structure type name [ID] (R189) structure member name [ID] is a set position in structure data type mode member type name (R185) linked class key letter (R184) linked attribute name (R184)

0..1

R201

0..*

R215

attributes

Attribute in Identifier

analysis area id [ID] (R10) attribute name [ID] (R10) class key letter [ID] (R10)

*

operation id [ID] (R215) analysis area id [ID] (R217,R215) terminator key letter (R217)

attri butes

R166

analysis area id [ID] (R210) terminator key letter [ID] name description class key letter (R210)

Specialisation Terminator

{no=161, kl=STOP} attributes

{no=151, kl=OP}

Operation

operation id [ID] analysis area id [ID] (R238) operation number name description is externally visible method operation subclass

0..*

0..*

Specialisation Terminator Operation

is deferred 1 down

*

is identified by 1..*

1

1

{no=157, kl=ATERM}

R216

provides

1

{no=22, kl=AR}

is target of

is directed at

is scoped to

attri butes

is provided by

{no=160, kl=ATOP} attributes

operation id [ID] (R215) analysis area id [ID] (R216,R215) terminator key letter (R216)

owns

R14

{no=12, kl=RA}

{no=135, kl=SPC}

Association Terminator

sees specific counterparts via

attributes

1..*

produces signal to be consumed by

0..*

0..*

communicates to counterparts via

0..*

Association Terminator Operation

R242

R243

analysis area id [ID] (R28,R23,R23) referencing class key letter [ID] (R23) referencing attribute name [ID] (R23) referenced class key letter [ID] (R23) referenced attribute name [ID] (R23) relationship number (R28) relationship end (R28)

contains

consumes signal produced by

Signal Producer Consumer attributes

R28

1

R170

0..*

analysis area id [ID] (R237) key letter [ID] R157 spc type [ID]

{no=159, kl=COP}

{no=6, kl=DEFOPI} attri butes

analysis area id [ID] (R241) operation id [ID] (R241) subclass class key letter [ID] (R241) method description

{no=118, kl=UMLS}

analysis area id [ID] (R166) target spc key letter [ID] (R166) target spc type [ID] (R166) signal number [ID] signal name description

is transmission of

R171

0..*

R210

has 0..*

attributes

Referential Attribute

R219

operation id [ID] (R215) analysis area id [ID] (R215,R17,R242) class key letter (R17) deferring relationship number (R242)

attri butes

Deferred Operation Implementation

{no=18, kl=FOPD} attri butes

1..*

is transmitted by

attributes

operation id [ID] (R215) analysis area id [ID] (R219,R215) is instance based class key letter (R219)

R241

0..1

Further Operation Deferral analysis area id [ID] (R241,R243) operation id [ID] (R241) subclass class key letter [ID] (R241) child relationship number (R243)

{no=21, kl=RAIRI}

Attribute Reference

UML Signal

attri butes

analysis area id [ID] (R170,R170,R171) target spc key letter (R171) producing spc key letter [ID] (R170) producing spc type [ID] (R170) consuming spc key letter [ID] (R170) consuming spc type [ID] (R170) signal number (R171) target spc type (R171)

R211

represents counterparts to

Polymorphic Operation

Class Operation implements

belongs to

Referential Attribute In Referential Identifier analysis area id [ID] (R19,R19) referential attribute name [ID] (R19) referencing class key letter [ID] (R19) relationship number [ID] (R19) relationship end [ID] (R19)

1

{no=19, kl=POLOP}

R240

0..*

1

forms part of

1

has 0..*

implements 0..1

{no=3, kl=DEFOP}

Deferred Operation

further defers implementation to

belongs to

1 R17

R245

1

1..*

{no=138, kl=STR}

attri butes

1 has superclass

has subclass

1

analysis area id [ID] (R22,R21,R20) relationship number [ID] (R22,R21) relationship end [ID] referenced identifier number (R20) referenced identifier class key letter (R20)

attributes

R5

1

identifies

{no=54, kl=ASSIG}

Assigner Signal analysis area id [ID] (R128,R200) target assigner key letter [ID] (R128,R200) signal number [ID] (R128) target spc type (R128)

attri butes

analysis area id [ID] (R5,R29) class key letter [ID] (R5) association multiplicity relationship number (R29)

analysis area id [ID] (R224) class key letter [ID] class number class name description is foreign

characterises

R19

is affected by

0..*

1..*

{no=144, kl=TSIG}

attributes

analysis area id [ID] (R128) target terminator key letter [ID] (R128) signal number [ID] (R128) method target spc type (R128)

attri butes

R169

Association Class

{no=8, kl=NAC} attri butes

attri butes

1

Terminator Signal

attri butes

analysis area id [ID] (R128) target class key letter [ID] (R128) signal number [ID] (R128) target spc type (R128)

R225

is formalised in

Non Association Class

Class defines the type for references to instances of R188

Referential Identifier

analysis area id [ID] (R53,R195,R53) target assigner key letter [ID] (R53,R53,R195) state number [ID] (R53) signal number [ID] (R53) destination state number (R195) effect type

R53

uses

{no=51, kl=SIG}

Signal

uses

contains 0..*

analysis area id [ID] (R5) class key letter [ID] (R5)

1..*

{no=55, kl=AE}

attributes

is entered 0..* via

{no=61, kl=ISM} analysis area id [ID] (R61) class key letter [ID] (R61) status attribute name

{no=11, kl=DE}

Derivation Element

analysis area id [ID] (R8,R8) derived relationship number [ID] (R8) element relationship number [ID] (R8)

analysis area id [ID] (R225,R2,R3) relationship number [ID] description A end conditionality B end conditionality A end multiplicity B end multiplicity A end role name B end role name A end class key letter (R2) B end class key letter (R3) is foreign

is formalised by having an A identifier referenced by

0..*

Assigner Effect

attri butes

is used to derive 0..*

R7

0..1

is entered as a result of

{no=134, kl=SES} attri butes

analysis area id [ID] (R156,R156) class key letter [ID] (R156) state number [ID] (R156) target class key letter [ID] (R156) signal number [ID] (R156)

R156

{no=34, kl=EF}

analysis area id [ID] (R193,R145,R196,R193) state number [ID] (R193) class key letter [ID] (R193,R145,R196,R193) creation state number (R145) destination state number (R196) effect type target class key letter [ID] (R193) signal number [ID] (R193)

carries formalisation for 1

Formalised Association

0..1 0..1

is formalised by having a B identifier refereced by

Signal Entering State

is entered as a 0..* result of

attri butes

references an identifier at the B end of

R21

causes entry 0..1

affects

R195

0..1

is entered as a result of

Effect

R22

R200

R196

attri butes

{no=121, kl=SU}

Signal Usage

The classes marked with an * in their top-left corner are the only classes that will be populated for a 'Package Container Domain Version'. (See iCCG User Guide for further details)

{no=53, kl=AST}

Assigner State causes entry to

contains 1..*

(c) Kennedy Carter Ltd. 2007

0..*

consists of

results in creation in 0..1

R132

has type

0..*

0..1

has type 0..1

1

*

{no=26, kl=DAT} has type

Data Type attri butes

defines type of 0..*

R191

0..1

analysis area id [ID] (R221) data type name [ID]

contains 0..*

contains

0..* R221

*

*

Provided Data Type

{no=75, kl=UDDT}

*

{no=148, kl=DST}

*Constrained

is derived of

*

Constrained Real Type

*

{no=69, kl=CTT}

attributes

{no=73, kl=CTODT}

Enumeration Type

attri butes

analysis area id [ID] (R74) data type name [ID] (R74)

attributes


is defined in

1

1

is defined in

attributes



is defined in

is defined in 1

1 is defined in

1

is defined in

{no=165, kl=SEG} is defined in

R233

contains

1

is defined in 1 R228

0..*

Test Method

contains 0..*

{no=168, kl=TM}

* is listed within

attri butes

analysis area id [ID] (R227) number [ID] name method

contains

R226

0..*

0..*

0..1 is current selection of R229 has currently selected 0..1

Test Method Set {no=169, kl=TMS} attri butes

analysis area id [ID] (R228,R229) name [ID]

is defined in 1

*

0..*

Test Method Set Component

0..*

analysis area id [ID] (R233) number [ID] name method

0..1 is current selection of

R230 contains

references

1

R235

R232 has currently selected

Initialisation Sequence

is referenced by

0..*

0..1 is a component of {no=166, kl=ISEQ}

1

attri butes

analysis area id [ID] (R230,R232) sequence name [ID]

consists of R234

is first component in 0..1

*

Initialisation Segment attri butes

attri butes

1 R227

contains *

{no=68, kl=ET}

*

{no=164, kl=AA}

Analysis Area

is defined in 1..*

R75 is an element of 1

Constrained Text Type

{no=71, kl=CRT}

Type

attri butes

analysis area id [ID] (R74) data type name [ID] (R74) is referenced by instance handles of type

*

Time Of Day

analysis area id [ID] has population errors

analysis area id [ID] (R75) data type name [ID] (R75) enumeration name [ID] enumeration value enumeration value set

1 is part of

Data Structure Type

*

{no=80, kl=EE} attributes


R74

*

Enumeration Element

{no=74, kl=PDT} attri butes

analysis area id [ID] (R73) data type name [ID] (R73) description constraint data type subclass

1

is defined in 1

R73

User Defined Data Type attributes

R189

has first R239

*

Initialisation Sequence Component {no=167, kl=ISEQC}

0..*

0..1

attributes

analysis area id [ID] (R234,R235,R236,R239) sequence name [ID] (R234,R239,R236) position in sequence [ID] initialisation segment number (R235) next position in sequence (R236)

is preceded by

0..1

is followed by 0..1

{no=170, kl=TMSC}

1

attributes

Instance Handle Type {no=153, kl=IHT}

*

Constrained Date Type

attributes

analysis area id [ID] (R188,R74) data type name [ID] (R74) class key letter (R188)

*

Constrained Integer Type

{no=72, kl=CDT} attri butes


{no=70, kl=CIT} attri butes


*

Deferred Type attri butes

{no=67, kl=DT}


analysis area id [ID] (R226,R226) test method set name [ID] (R226) test method number [ID] (R226)

R236


Figure 9: An industrial strength model (of executable UML, courtesy of Abstract Solutions Ltd) comprising a strongly ordered core (admittedly, one defined by generalisation—an area for further study—as well as containment, and visually apparent only to a subject matter expert) surrounded by an unordered covering.

7

Acknowledgements

The authors would like to thank Iman Poernomo for his support in writing this paper.

References [1] Y. Bertot & P. Castéran (2004): Interactive Theorem Proving and Program Development. Coq’Art: The Calculus of Inductive Constructions. Texts in Theoretical Computer Science, Springer-Verlag, doi:10.1007/9783-662-07964-5. [2] A. Boronat & J. Mesegeur (2008): An Algebraic Semantics for the MOF. In J. Fiadeiro & P. Inverardi, editors: FASE 2008 Proceedings, LNCS 4961, Springer, pp. 377–391, doi:10.1007/978-3-540-78743-3 28. [3] Daniel Calegari, Carlos Luna, Nora Szasz & Alvaro Tasistro (2011): A Type-Theoretic Framework for Certified Model Transformations. In Jim Davies, Leila Silva & Adenilso da Silva Simão, editors: Formal Methods: Foundations and Applications - 13th Brazilian Symposium on Formal Methods, SBMF 2010, Natal, Brazil, November 8-11, 2010, Revised Selected Papers, Lecture Notes in Computer Science 6527, Springer, pp. 112–127, doi:10.1007/978-3-642-19829-8 8.


77

[4] M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer & C. Talcott (2003): The Maude 2.0 System. In: Rewriting Techniques and Applications (RTA 2003), Lecture Notes in Computer Science 2706, Springer-Verlag, pp. 76–87, doi:10.1007/3-540-44881-0 7. [5] H.B. Curry & R. Feys (1958): Combinatory Logic. 1, North Holland Publishing Company. [6] Object Management Group (2003): MDA Guide Version 1.0.1. [7] Object Management Group (2009): Unified Modelling Language, Version 2.2. Formal/09-02-02, formal/0902-04. [8] Object Management Group (2011): Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Formal/2011-01-01. [9] W.A. Howard (1980): The Formulae-as-Types Notion of Construction. In J.P. Seldin & J.R. Hindley, editors: To H.B. Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism, Academic Press Inc. [10] F. Jouault & I. Kurtev (2006): Transforming Models with ATL. LNCS 3844, MODELS 2005 Workshops, Springer-Verlag, pp. 128–138, doi:10.1007/11663430 14. [11] K. Lano (2009): Model-Driven Software Development with UML and JAVA. Cengage Learning EMEA. [12] K. Lano, editor (2009): UML 2 Semantics and Applications. Wiley, doi:10.1002/9780470522622. [13] P. Martin-Löf (1984): Intuitionistic Type Theory. Bibliopolis. [14] S.J. Mellor, K. Scott, A. Uhl & D. Weise (2004): MDA Distilled. Addison-Wesley. [15] Object Management Group (2006): Meta Object Facility (MOF) Core Specification. Formal/06-01-01. [16] Object Management Group (2012): Object Constraint Language (OCL), Version 2.3.1. Formal/2012-01-01. [17] I.H. Poernomo (2008): Proofs-as-Model-Transformations. In Antonio Vallecillo, Jeff Gray & Alfonso Pierantonio, editors: Theory and Practice of Model Transformations, First International Conference, ICMT 2008, Zürich, Switzerland, July 1-2, 2008, Proceedings, Lecture Notes in Computer Science 5063, Springer, pp. 214–228, doi:10.1007/978-3-540-69927-9 15. [18] I.H. Poernomo & J.W. Terrell (2010): Correct-by-Construction Model Transformations from Partially Ordered Specifications. In J.S. Dong & H. Zhu, editors: Formal Methods and Software Engineering, Lecture Notes in Computer Science 6447, 12th International Conference on Formal Engineering Methods, ICFEM 2010, Shanghai, China, November 17-19, Springer, doi:10.1007/978-3-642-16901-4 6. [19] J. Rivera & A. Vallecillo (2007): Adding Behavioural Semantics to Models. In: The 11th IEEE International EDOC Conference (EDOC 2007), IEEE Computer Society, Annapolis, Maryland, USA, pp. 169–180. [20] D. Ruscio, F. Jouault, I. Kurtev, J. Be´zivin & A. Pierantonio (2006): Extending AMMA for Supporting Dynamic Semantics Specifications of DSLs. Technical Report 06.02, Laboratoire d’Informatique de NantesAtlantique (LINA), Nantes, France. [21] S. Shlaer & S.J. Mellor (1988): Object-Oriented Systems Analysis – Modelling the World in Data. Yourdon Press, Prentice Hall. [22] S. Shlaer & S.J. Mellor (1991): Object Lifecycles – Modelling the World in States. Yourdon Press, Prentice Hall. [23] The Coq Development Team (2010): The Coq Proof Assistant, Reference Manual. Available at http: //coq.inria.fr/refman. [24] Xavier Thirioux, Benoˆıt Combemale, Xavier Crégut & Pierre-Lo¨ıc Garoche (2007): A Framework to Formalise the MDE Foundations. In: TOWERS, pp. 14–30. [25] S. Thompson (1999): Type Theory & Functional Programming. Computing Laboratory, University of Kent.