10.07.2015 Views

all FREECO11-workshop-papers.pdf - trese

all FREECO11-workshop-papers.pdf - trese

all FREECO11-workshop-papers.pdf - trese

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Ifis a well typed term, thenis provable. p : asType(∀x : T.∃y : U.P (x, y))∀x : T.P(x, fst(px))The theorem means that, given a proof of a formula ∀x : T.∃y :U.P (x, y), we can automatic<strong>all</strong>y extract a function f that, giveninput x : T , will produce an output fx that satisfies the constraintP (x, fx).Our notion of proofs-as-model-transformations essenti<strong>all</strong>y followsfrom this theorem. Given that we have the machinery to typethe structure of arbitrary metamodels, a model transformation betweentwo metamodels Source and Targetcan be thought of as afunctional programt : Source → TargetSuch a program can be specified as set of constraints over instancesof the input x : Source and output y : Target metamodels. Inthe simplest case, we can consider these constraints to be of a preconditionPre(x) that is assumed to hold over input metamodelinstances x : Source, and a postcondition relationship Post(x, y)that holds between x and required output metamodel instances y :Target.Given types Source and Targetto represent the source and targetmetamodels, and constraints as logical formulae over terms ofthe metamodels, we can then specify the transformation by a formula∀x : Source.Pre(x) →∃y : Target.Post(x, y)After that, we can attempt to find a certified transformation by identifyingan inhabiting term t oft : ∀x : Source.Pre(x) →∃y : Target.Post(x, y)If we look at the meaning of the types (rec<strong>all</strong> that ∀ corresponds toa dependent product Π and ∃ to a dependent sum Σ), we see thatt must be a function that takes in any input x of type Source andreturns a pairtx = w, pIn order to synthesize a provably correct model transformation, weapply the extraction mapping over t according to Theorem 2: thiswill give us the required model transformation fst(t) =w and acertification of the transformation’s correctness, a proof snd(t) =p.3. MODULARISING MODEL TRANSFOR-MATIONSThere has been considerable research interest in modularisingmodel transformations for some time already. The approaches proposedand studied so far, may be characterised by the granularity ofmodules that they provide: At a first level, we can distinguish internalcomposition of transformation rules from external compositionof entire model transformations [10]. We can further differentiateinternal composition into inter-rule composition, where entirerules are taken to be modules, and intra-rule composition, whererules themselves can be composed of finer-grained modules. In thefollowing, we will briefly discuss each of these compositions inturn.✷3.1 External CompositionExternal composition takes entire model transformations to bemodules that can be independently reused and composed. Early researchon external composition focused mainly on languages andtools for describing and executing such compositions of reusablemodel transformations. This has led to early work on MDA components[4], megamodelling [5], transformation chaining [3, 6, 17],and transformation configuration [19].As <strong>all</strong> of this work considers transformations as black-box componentsto be composed into larger components, the ‘signature’ or‘interface’ of a transformation becomes important. These termsrefer to the information that can be obtained about a transformationwithout inspecting its implementation. Initial work on externalcomposition [12, 18] defined transformation signatures by twosets of metamodels: one typing the models that the transformationconsumed and another typing the models produced by the transformation.Later research [6] found that this is not always sufficientinformation for safely composing transformations. In particular,endogenous transformations transform between models of thesame metamodel, but may well only address particular elementswithin this metamodel. Information about the metamodel thus becomesuseless when composing a set of endogenous transformations.In addition, some endogenous transformations may be intendedto be used with a fixpoint semantics (invoking them untilno more changes occur), which makes composing them even morecomplex. It was concluded in [6] that in addition to the metamodel,there needs to be information about the particular subset of modelelements that are used or affected by a transformation. In par<strong>all</strong>el tothis work, [17] also identified a need to include information aboutthe technical space of models (e.g., MOF or XML) into the transformationsignature. Alternatively, some of this information hasbeen encapsulated by wrapping models as components themselves,providing interfaces for accessing and manipulating the model in afashion independent of the technical representation [12].3.2 Internal CompositionInternal composition considers modules of a finer granularitythan entire model transformations. Inter-rule composition considersindividual rules to be modules, while intra-rule compositionconsiders even finer-grained modules, i.e. parts of rules.3.2.1 Inter-rule CompositionA number of transformation languages consider transformationrules to be the unit of modularity. A number of mechanisms areprovided for composing rules into transformations, including implicitand explicit rule invocation, and rule inheritance [3, 11]. Approachesinspired from graph transformation—for example, VMT[16]—even <strong>all</strong>ow for chaining of individual transformation rules.Module superimposition [20] applies the notion of superimpositionfrom feature-oriented software development [2] to the developmentof transformation modules, <strong>all</strong>owing individual rules to be overriddenby rules from superimposed modules.All of these techniques create some flexibility in <strong>all</strong>owing developersto exchange or independently evolve rules. However, they donot distinguish a rule’s interface from its implementation, whichmeans that rules and rule compositions cannot be verified or understoodmodularly without inspecting the complete implementationof each rule. Furthermore, some evaluations have shown that thereare scenarios where the modularisation capabilities available at thelevel of complete rules are not sufficient [7, 8, 11].3.2.2 Intra-rule CompositionTo improve modularisation capabilities, a number of mechanisms

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!