A Model-driven Approach to Formal Refactoring

Tiago MassoniSoftware Productivity Group

Conformity Notion

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

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

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

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 Objectfield: Object x NameF(P) -> set Object

(WF Heap: all c: NameC(P), f: NameF(P), o: objects(c) | field(o,f) ≠ { } => c

possui f )

Formal definitions

For a program P, all heaps in P’s tracesH(P): set Heap

MorphismsΦS : NameS(M) x Heap -> set Object

ΦR : NameR (M) x Heap -> set ?? Object x Object

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

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

ac

B

*

A C

all a:A | one a.ac

↕

class A {

ac: set C;...

}...

class B extends X {...}heap

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)}

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)}

Relationship conformity implementation

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)

wheremult(nr: NameR(M),nf: NameF(P)) =

decl(nr) = set => decl(nf) = set^ !(decl (nr) = set) => decl(nf) = var

Additional constraints (stronger)

Theorem

all M,P | M conf P => M imp P

ProofM conf P => M imp P

= by definitionM 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…

A Model-driven Approach to Formal Refactoring

Tiago MassoniSoftware Productivity Group

Conformity Notion