A Modeldriven Approach to Refactoring Tiago Massoni Software

A Model-driven Approach to Refactoring Tiago Massoni Software Productivity Group UFPE

Software Evolution n Need to evolve ¡ ¡ n Synchronism with ever-changing business Adaptive, perfective and corrective evolution But, in general, evolution degenerates structure! ¡ The more you change, the harder to change again A Model-driven Approach to Refactoring 2

Improving Evolution n Program refactoring ¡ ¡ ¡ n Model refactoring ¡ ¡ ¡ n Clean-up before further changes Improves O. O. programs keeping observable behavior Tool support Abstraction Cheaper design exploration Model-driven development Automated traceability is needed ¡ But hard to achieve in practice A Model-driven Approach to Refactoring 3

Round-trip Engineering: refactoring programs n n Rather concrete models Business rules from programs get lost Program Refactoring P 1 A Model-driven Approach to Refactoring P 2 4

Round-trip Engineering: refactoring models Model Refactoring n User-edited source code and regeneration are problematic MDA tools have similar problems P 1 A Model-driven Approach to Refactoring P 2 5

Contributions n Structural model-based approach to refactorings ¡ n Basis: primitive laws for Alloy (on-going work) Definition of an analogous program transformation for each Alloy law ¡ Sequence of law applications in ROOL ¡ Given ROOL programs in conformance to an Alloy model n n Alloy law’s conditions are sufficient to reason about the analogous transformation on ROOL Result: reasoning of joint refactoring by considering only model refactorings A Model-driven Approach to Refactoring 6

Contributions n Make the results from our work available to UMLers ¡ Semantics for UML class diagrams n n ¡ Translational semantics based on Alloy Denotational semantics, using the same semantic model as Alloy Benefits: Automatic analysis, laws, formal refactoring, model-based program refactoring A Model-driven Approach to Refactoring 7

Content n Laws ¡ ¡ n n Alloy ROOL Our approach to model-based refactoring UML Semantics A Model-driven Approach to Refactoring 8

Algebraic Laws n Define a notion of equivalence between language constructs ¡ ¡ n n n Programs Models Define two semantics-preserving transformations (proven) Restructuring and stepwise development Clarify language constructs ¡ Axiomatic semantics A Model-driven Approach to Refactoring 9

Laws for Alloy n Alloy Modeling language ¡ ¡ n Laws for Alloy ¡ ¡ n Signatures (sets), relations and predicate logic Automatic analysis Composed to form coarse-grained laws Refactorings Based on an equivalence notion for object models ¡ Alphabet (Σ) and view (v) A Model-driven Approach to Refactoring 10

Example Applying the Pull Up Relation Law no (Account-Ch. Acc). x Ch. Book Account =Σ, v Ch. Book r * x * Account Ch. Acc Σ = {Account, Ch. Acc, Ch. Book, r} v = {r → x} A Model-driven Approach to Refactoring 11

Laws of Programming n n n Formally define program transformations Laws for imperative programming: Hoare et al. , Morgan Laws for object-oriented programming: ROOL A Model-driven Approach to Refactoring 12

ROOL n n Refinement Object-Oriented Language Formal object-oriented programming language ¡ n Similar to Java, although sequential with a copy semantics A comprehensive set of primitive laws ¡ ¡ ¡ Laws for commands and classes Relative completeness: normal form Proven to be behavior-preserving A Model-driven Approach to Refactoring 13

Laws for ROOL n Class Refinement ¡ ¡ Based on traditional data refinement Refinement by internal representation change n ¡ n Coupling invariant relate representations Extended to consider refinement of class hierarchies Laws composed to prove formal refactorings A Model-driven Approach to Refactoring 14

Conformance of Programs to Alloy n We delimit our notion of conformance ¡ ¡ Structures (signatures and relations) are implemented in the program Constraints from the model are satisfied at certain points during program’s execution n Model define invariants on how the heap of the object-oriented program will be organized at these points A Model-driven Approach to Refactoring 15

Combining Laws: Push Down Relation checks Account Ch. Book * Sav. Acc no (Account – Ch. Acc). checks Ch. Acc //Any other class abstract class Account Chbook cb: = new Ch. Book; pub checks: Ch. Book; Account acc: =. . . ; . . . if acc is Ch. Acc -> acc. checks: = cb; meth m = (pds • . . . a: = self. checks; . . . class Sav. Acc extends Account new= self. checks: = null; . . . A Model-driven Approach to Refactoring class Ch. Acc extends Account new= self. checks: = new Ch. Book; . . . 16

Combining Laws n Source code in conformance with the structural model n Law application on the model is OK n But several program constructs prevent program refactoring ¡ Usual pre-conditions are not fullfilled Satisfies heap invariants //Any other class. . . Account acc: = new Ch. Acc; class Account { acc. checks: = new Ch. Book; pub checks: Ch. Book; . . . end meth m = (pds • . . . a: = self. checks; class Sav. Acc extends new = self. checks: = null; . . . class Ch. Acc extends Account { end new = Account { self. checks: = new Ch. Book; . . . end A Model-driven Approach to Refactoring 17

Example: Push Down Relation Account checks Ch. Book Account * Sav. Acc Ch. Book checks Sav. Acc * Ch. Acc no (Account – Ch. Acc). checks A Model-driven Approach to Refactoring 18

Our Approach n Define a sequence of transformations that are analogous to the modeling law ¡ ¡ n Fixing the fragments ¡ ¡ n Fixing those red fragments Then pushing down the attribute Transfer the model invariant to the program Use ROOL laws to rewrite those code fragments Defining an analogous transformation ¡ ¡ Tactics language Step-by-step guiding the rewritings in a formal way A Model-driven Approach to Refactoring 19

Our Approach class Sav. Acc extends Account new= self. checks: = null; n Assumption ¡ [self<=Account and !(self<=Ch. Acc)=> self. checks = null] {self. checks=null} self. checks: = null; Simple specification ¡ n {self is Sav. Acc} self. checks: = null; Applying model invariant ¡ n . . . self. checks: [self. checks=null, self. checks=null]; Trivially ¡ skip; A Model-driven Approach to Refactoring 20

Our Approach //Any other class Chbook cb: = new Ch. Book; Account acc: =. . . ; if acc is Ch. Acc -> acc. checks: = cb; . . . n Assumption (law [is test true]) ¡ n if acc is Ch. Acc -> {acc is Ch. Acc} acc. checks: = cb; Introduce cast ¡ if acc is Ch. Acc -> ((Ch. Acc)acc). checks: = cb; A Model-driven Approach to Refactoring 21

Our Approach abstract class Account pub checks: Ch. Book; . . . meth m = (pds • . . . a: = self. checks; . . . n Considering two distinct cases ¡ n self is Ch. Acc or !(self is Ch. Acc) This leads to an if statement ¡ if (self is Ch. Acc) -> a: = ((Ch. Acc)self). checks; !(self is Ch. Acc)-> a: = null; A Model-driven Approach to Refactoring 22

Push Down Attribute Transformation Push Down Attribute (M 1: model, P 1: program, A: attribute) if P 1 not structured as M 1 id(P 1) else if A. modifier = pri apply <pri-pub> for each writing violation case 1(as in Sav. Acc): replace by skip case 2(as in other class): specialized casting. . . for each reading violation case 1(as in Account): replace by an if stat. . apply <move attribute to superclass(right-left)(A)> if old(A. modifier) = pri A Model-driven Approach to Refactoring 23 apply <self-encapsulate-field(A)> n

Example: Push Down Relation Account Ch. Book checks Sav. Acc * Ch. Acc //Any other class abstract class Account Chbook cb: = new Ch. Book; meth m = (pds • . . . Account acc: =. . . ; if (self is Ch. Acc)-> a: = ((Ch. Acc)self). checks; if acc is Ch. Acc -> ((Ch. Acc)acc). checks: = cb; !(self is Ch. Acc)-> a: = null; . . . class Sav. Acc extends Account class Ch. Acc extends Account new= skip; pub checks: Ch. Book; . . . new= self. checks: = new Ch. Book; A Model-driven Approach to Refactoring . . . 24

Benefits of our Solution n Application of refactoring to models ¡ ¡ ¡ n Automatic replication to source code No need for manual updates or round-trip Model constraints are maintained “Smart refactorings” ¡ Based on the model’s constraints A Model-driven Approach to Refactoring 25

Benefits of our Solution n Possible composition of laws ¡ ¡ n n Application of refactoring just as possible in models For each modeling law two correspondent program transformations Tool support May be used to horizontal consistency between views of a model ¡ Class diagrams driving changes to interaction diagrams A Model-driven Approach to Refactoring 26

Possible Limitations n We rely on conformance of source code ¡ n Identifying potential problems (red fragments) ¡ n Efficiently implementable? We have to change the program in “unexpected” ways ¡ n Hard to check automatically Renaming, self-encapsulate field Alloy’s references and ROOL’s copy semantics ¡ To be investigated A Model-driven Approach to Refactoring 27

Assumptions n Constrained conformance ¡ n Tactics language ¡ n Not sure if it’s the best representation Transfer the results to Java ¡ n How models are implemented (alphabet may help) Aliasing Fitting model-based refactoring into evolution process ¡ What about evolutionary changes that are not refactoring? A Model-driven Approach to Refactoring 28

UML Translational Semantics fact Bank. Properties { Account = Ch. Acc all a: Account|lone a. ~accs bk = ~accs } sig Bank { accs: set Account } sig Account{ bk: set Bank } sig Ch. Acc extends Account {} A Model-driven Approach to Refactoring 29

UML Translational Semantics n A set of translation rules ¡ ¡ n Representing class diagrams with OCL by using Alloy Tool support for translation Benefits ¡ ¡ Alloy’s automatic analysis to UML Leveraging work with Alloy n Laws and refactoring n Equivalence notion n Model-based refactoring A Model-driven Approach to Refactoring 30

UML Translational Semantics n Possible limitations ¡ Translational semantics may not work well n n ¡ Some UML concepts are not representable in Alloy Alternative: Provide a denotational semantics to class diagrams, using same semantic model as Alloy Dependency on UML standards and the Alloy Analyzer API A Model-driven Approach to Refactoring 31

Status n Three modeling laws have been addressed ¡ ¡ ¡ n Correspondent program transformations in tactics format Approaches to conformance have been investigated Aim: Investigate the whole set of modeling laws Translation rules from UML to Alloy have been defined in detail ¡ ¡ Currently developing tool support Analysis of limitations in order to assess the need for an alternative approach A Model-driven Approach to Refactoring 32

A Model-driven Approach to Refactoring Tiago Massoni Software Productivity Group UFPE

Another Example: Introduce Relation Customer Car Customer owned Car * owned = exp n Pre-conditions: ¡ ¡ To introduce owned as relevant (in Σ), it must depend on pre-defined relations (or be empty), as recorded in the view by owned = exp Customer itself or its family do not declare any relation named owned A Model-driven Approach to Refactoring 34

Applying transformation to program n We must not only introduce the attribute ¡ n We identified three basic ways to define a new relevant relation ¡ ¡ ¡ n We should also make the program conform to the invariant (owned=exp) exp = empty exp = another relation r exp = a composition of relations s. t (using an auxiliar signature) Solution: Apply class refinement ¡ coupling invariant: based on the invariant owned = exp A Model-driven Approach to Refactoring 35

Applying transformation to program n exp = empty ¡ Add new attribute to Customer n CI: self. owned = null; ¡ Augment constructor n self. owned: = null; n exp = t ¡ Add new attribute to Customer n CI: self. t = self. owned ¡ Maintain reads, guards and method calls to t ¡ For each write, augment assignment n self. t, self. owned: = a, a; A Model-driven Approach to Refactoring 36

Applying transformation to program Customer owned s Car t Aux n exp = s. t ¡ ¡ ¡ Add new attribute to Customer ¡ CI: !(self. s=null)=> self. owned=self. s. t, self. owned=null Maintain reads, guards and method calls to self. s, self. s. t For each write to self. s. t, augment assignment ¡ self. s. t, self. owned: = a, a; A Model-driven Approach to Refactoring 37

Applying transformation to program ¡ ¡ For each write to self. s, augment specialized assignment n if !(a=null)-> self. s, self. owned: = a, a. s; (a=null)-> self. s, self. owned: = a, null; Confinement is required (automatic from ROOL) Customer owned s Car t Instances of Aux created by Customer (s attribute) are confined to Customer Aux A Model-driven Approach to Refactoring 38

Thesis n Hypothesis ¡ ¡ ¡ For each relation Rm: M->M found a relation Rp: P->P There’s a conformance relation CONF: P->M Thesis (all m 1, m 2: M, p 1: P | (p 1, m 1) in CONF && (m 1, m 2) in Rm) => (some p 2: P | p 1 != p 2 && (p 1, p 2) in Rp && (p 2, m 2) in CONF) n A Model-driven Approach to Refactoring 39