A Model-driven Approach to Formal Refactoring

1. A Model-driven Approach to Formal Refactoring Conformity Notion Tiago Massoni Software Productivity Group

2. Model-driven program refactoring • We investigate an approach for relating transformations in object models and O.O. programs • Approach: primitive transformations at both levels (Alloy, ROOL) • Transform models, apply analogous changes to source code • What is analogous? • We must relate programs and models somehow

3. Implementation of an object model • If P implements M • The invariant from M (InvM) must be valid for any heap in P’s traces • There must be a way to relate objects in P to sets, relations in M, in order to evalute Inv • A morphism (mapping)! M ↕ P

4. Possible morphisms • Morphism 1 (strict) • based on participant names • Every set is bound to objects in a class with the same name (same for relations and fields) • Morphism 2 • Morphism 1 + Content-based sets • set S is bound to objects whose fields presents a certain value • Morphism 3 • Morphism 2 + Collection-based relations • relation R is bound to pairs of objects (container,contained) within a collection

5. Formal definitions Name (M): all Set, Relation names in model M Name (P): all Class, Field names in program P Name (M) = NameS(M) U NameR (M) Name (P) = NameC(P) U NameF(P) Heap (a record) objects: NameC(P) -> set Object field: Object x NameF(P) -> set Object (WF Heap: all c: NameC(P), f: NameF(P), o: objects(c) | field(o,f) ≠ { } => c possui f )

6. Formal definitions For a program P, all heaps in P’s traces H(P): set Heap Morphisms ΦS : NameS(M) x Heap -> set Object ΦR : NameR (M) x Heap -> set ?? Object x Object

7. Implementation notion • A program P implements M if all heaps in P’s traces make InvM valid, as long as there exists a morphism from each heap to M names • Formalizing M imp P <=> some ΦS, ΦR| all h:H(P), ns:NameS(M), nr:NameR(M) | InvM[ns◄ΦS(ns,h) , nr◄ΦR(nr,h)] Binding value to names in the invariant formula

8. ac C A * B heap Conformity notion • Invariants must be valid, but • morphism is strict • same names for sets and relations • Syntactic conditions on relation and field declarations • Well fit to structural transformations • refactoring class A { ac: set C;... }... class B extends X {...} ↕ all a:A | one a.ac

9. Our morphism for sets and classes • This morphism defines the objects, which are instances of a class n, as the binding for the set ns αS(n: NameS(M), h: H(P)) = {o: Object| n ЄNameC(P) ^ o Єh.objects (n)}

10. Our morphism for relations and fields • This morphism defines the pairs of objects, linked by edges named n, as the binding for the relation nr αR(n: NameR(M), h: H(P)) = {o1,o2:Object| n ЄNameF(P) ^ o2 ∈h.field(o1,n)}

11. Relationship conformity  implementation Additional constraints (stronger) M conf P = M imp P[αS,αR/ ΦS, ΦR] ^ NameS(M) in NameC(P) ^all nr: NameR(M), nf: NameF(P) | mult (nr,nf) where mult(nr: NameR(M),nf: NameF(P)) = decl(nr) = set => decl(nf) = set ^ !(decl (nr) = set) => decl(nf) = var

12. Theorem all M,P | M conf P => M imp P

13. Proof M conf P => M imp P = by definition M imp P[αS,αR/ ΦS, ΦR] ^ NameS(M) in NameC(P) ^all nr: NameR(M), nf: NameF(P) | mult (nr,nf) => M imp P =substitution, one-point rule …

14. A Model-driven Approach to Formal Refactoring Conformity Notion Tiago Massoni Software Productivity Group