service de génie logiciel -...

Université de Mons-Hainaut

Service de Génie Logiciel

Formal tool support forsoftware evolution

Tom Mens

staff.umh.ac.be/Mens.Tom/www.umh.ac.be/~genlog

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

2

Problem statement

More and better tool support needed for softwareevolution

– traceability management– version control– impact analysis– change propagation– consistency maintenance– refactoring– co-evolution between architecture, design and

implementation

Formal support can be helpful for some of these

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

3

Formal support

for consistencymaintenance

– to ensure that a designmodel remains consistentwhen parts of it evolve

– based on descriptionlogics formalism

– in collaboration withRagnhild Van Der StraetenVrije Universiteit Brussel

for refactoring

– to ensure that therefactored softwarepreserves the behaviourof the original version

– based on graph rewritingformalism

– in collaboration withSerge Demeyer &Dirk JanssensUniversiteit Antwerpen



Formal Support

for Consistency Maintenance

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

5

Maintaining consistency of design models

Problem statement– UML models represent different views of the

system design• class diagrams, sequence diagrams, state diagrams

– Inconsistencies can be introduced due to• evolution• parallel changes made by different persons involved in

the design process• refinement

– UML tools provide poor mechanisms for dealingwith this problem

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

6


Requires 3 kinds of traceability

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

7


Extension (profile) of UML metamodel

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

8

Classification of inconsistencies

Disconnected modelInvocation inheritanceinconsistencyObservation inheritanceinconsistencyIncompatible behaviourinconsistency

Instance -instanceconflicts

Instance specificationmissing

Incompatible definitionSpecification- instanceconflicts

Dangling type referenceInherited associationinconsistencyRole specification missing

Invocation inheritanceinconsistencyObservation inheritanceinconsistency

Specification–

specificationconflicts

StructuralBehavioural

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

9

Motivating example

Incompatible behaviour inconsistency– Sequence of messages in sequence diagram is

inconsistent with specification of behaviourrepresented by protocol state machine

• it is not possible to find a path in the state machine thatcorresponds to the order established by the sequencediagram

Invocation inheritance consistency– any sequence of operations invocable on the

superclass can also be invoked on the subclass(Liskov's substitutability principle)

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

10

Motivating example

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

11

Motivating example

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

12

Motivating example

Incompatible behaviour inconsistency

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

13

ATM

PrintingATM

Motivating example

Invocation inheritance inconsistency

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

14

Description Logics Formalism

a decidable formalism (to detect inconsistencies)– detecting inconsistencies requires answering logic queries in

a finite time– two-variable fragment of first-order predicate logic– used to represent information about

• individuals (i.e., the model): Tbox• classes of individuals (i.e., the metamodel): Abox• consistency between metamodel and models comes for free

– staightforward correspondence between UML and DL• classes → concepts• associations → roles• attributes → roles or concrete domain attribute (primitive

types)• inheritance → subsumption mechanism and transitive closure

tool support– Classic, Loom, Racer, ...– inconsistencies can be resolved using logic language

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

15

Description Logics DialectsTradeoff expressiveness/performance

IR—inverse role

HR ⊆ Srole hierarchy

AL*

O{ a1 ... an }collection of individuals

(≥ n R.C) (≤ n R.C)

(≥ n R) (≤ n R)

∃ R.C

C ∪ D

¬A ¬C

⊥

T

∃ R

∀ R.C

C ∩ D

R

A

Syntax

Q

N

S

Language

FL

value restriction

existential restriction (E)

number restrictions

concept

Construct

role name (atomic or transitive)

conjunction

existential quantification

top

bottom

negation

qualified number restriction

disjunction

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

16

Description Logics DialectsTradeoff expressiveness/performance

NExpTime

ExpTime

PSpace

NP

P

Complexity

ALC, ALCO, ALCOU, S, ALCOUE, SI

FL, AL

Language

ALE, ALR, ALER

SHIN, SHIQ with atomic roles

SHIQ with transitive roles

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

17


manual translation of UML metamodel– use Tbox to express terminological knowledge (i.e., UML

metamodel entities)

(LOOM:defrelation namespace :domain ModelElement:range Model :characteristics :single-valued)

(LOOM:defrelation ownedElement :is (:inverse namespace))

(LOOM:defconcept Versioned :is Stereotype (:roles(version)))

(LOOM:defconcept VersionedElement :is (:and ModelElementVersioned))

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

18


automatic translation of UML models– use ABox to express assertional knowledge (i.e., UML model

entities)

(create 'ATM class)

(tellm (:about ATM (name ATM) (Has-feature getPin) (Has-feature getAmountEntry) ... (Is-parent-of PrintingATM) (IsAbstract false) (In-namespace Class-Diagram)))

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

19


Use logic rules to reason about the knowledge base– < Tbox, Abox >

E.g. rules for incompatible behaviour inconsistency– Collect operations in sequence diagram

(retrieve (?stimulus ?callaction ?operation)(:and(Receiver-of ?object ?stimulus)(Initiates ?stimulus ?callaction)(CallAction-operation ?callaction ?operation)))))

– Traverse state diagram(defun traverse-statediagram (?from-state ?from-name ?op-list)... ;starting from a certain ?state ;retrieve ?operation set corresponding to events on ?transition (do-retrieve (?transition ?operation ?callevent ?state) (:and (Is-source-of ?from-state ?transition) (Triggered-by ?transition ?callevent) (Is-occurence-of ?callevent ?operation) (Is-target-of ?state ?transition) ) (if (equalp ?operation ?current) (traverse-statediagram ?state (get-value ?state 'name) (cdr ?op- list)) (format t "Incompatible behaviour found at state: ~S~%"?from-name)))))

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

20


UML models are– developed in a CASE tool (Poseidon)– exported in XMI format– translated into description logics format by an

XSLT tool (Saxon)– imported in, and analysed with, a logic reasoning

engine (Loom, Racer)

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

21


Output results

UML(49): (traverse-sm (fi VerifyAccountBalance-SM-1.0) "VerifyAccountBalance" (generate-received-operations (fi anATM-1.0)))

Current operation: |I|CHECKIFCASHAVAILABLECurrent operation: |I|DISPENSECASHCurrent operation: |I|EJECTCARDInconsistency at state: |I|GIVECASHNIL

Need to improve usability– integrate in UML tool– OCL front-end

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

22


Current work : model refactoringClaim :– There is an equivalence between "inheritance consistency"

and "evolution consistency"• behaviour inheritance consistency between diagrams within

the same model• preservation of behavioural properties between diagrams in

successive model versions

C

D

SD1

SD2

- - - - - - -

- - - - - - -

C’ - - - - - - - SD1’

evolution

inheritance consistency evolution consistency



Formal support for

Software Refactoring

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

26

Software Refactoring

Definition– Refactoring is the process of changing a software

system in such a way that it does not alter theexternal behavior of the code, yet improves itsinternal structure [Fowler 1999]

Goals– Improve the design of software– Increase program understanding– Detect existing bugs– Avoid introducing new bugs– Increase productivity– Increase maintainability

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

27

Refactoring through graph transformation

Feasibility study of formalism based on– graphs

• Expressive representation of program structure and behaviour

– graph transformation• Intuitive representation of software transformation• Theoretical results can help during analysis

to specify/apply refactorings– in a language-independent manner– while guaranteeing behaviour preservation

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

30

public class Node { public String name; public Node nextNode; public void accept(Packet p) { this.send(p); } protected void send(Packet p) { System.out.println( name + "sends to" + nextNode.name); nextNode.accept(p); } }

public class Packet { public String contents; public Node originator; public Node addressee; }

public class Printserver extends Node{ public void print(Packet p) { System.out.println(p.contents); } public void accept(Packet p) { if(p.addressee == this) this.print(p); else super.accept(p); } }

public class Workstation extends Node{ public void originate(Packet p) { p.originator = this; this.send(p); } public void accept(Packet p) { if(p.originator == this) System.err.println("nodestination"); else super.accept(p); } }


LAN case: Java source code

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

31


LAN case: Program structure– Directed, labelled, typed graph

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

32


LAN case: Program Behaviour– Behaviour of class Node

• use a kind of "extended" abstract syntax tree

{this.send(p);}

{System.out.println( name+"sends to"+nextNode.name); nextNode.accept(p);}

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

33


well-formedness constraints: Type graph– graph metamodel

• cf. UML metamodel

C

M MD

V VDl

lm

m

EP

ea,u

a,u

t,p

t

p

i

ec

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

34


Well-formedness constraints = forbiddensubgraphs

– WF-1: a class cannot define the same methodtwice

– WF-2: a method cannot refer to variables indescendant classes

– WF-3: a method cannot refer to parameters ofother methods

C MDm

V

l m i*a | u

e*

E

MD MD

P

pa | u

e*

E

1 2m MC

MDm

MDm l

l

WF-1 WF-2 WF-3

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

36


public class Node { private String name; private Node nextNode; public String getName() { return this.name; } public void setName(String s) { this.name = s; } public Node getNextNode() { return this.nextNode; } public void setNextNode(Node n) { this.nextNode = n; } public void accept(Packet p) { this.send(p); } protected void send(Packet p) { System.out.println( this.getName() + "sends to" + this.getNextNode().getName()); this.getNextNode().accept(p); } }

public class Node { public String name; public Node nextNode; public void accept(Packet p) { this.send(p); } protected void send(Packet p) { System.out.println( name + "sends to" + nextNode.name); nextNode.accept(p); } }

Refactoring EncapsulateField– Encapsulates public variables and provides accessor methods

EncapsulateField(name,String getName(),setName(String))EncapsulateField(nextNode,Node,getNextNode(),setNextNode(Node))

– Precondition: Accessor methods should not be defined ininheritance chain

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

37

(t,1) (t,1), (p,2), (t,3)outgoing edgesincoming edges


Graph transformation EncapsulateFieldEncapsulateField(var,getter,setter)

• Parameterised transformation• Embedding mechanism

var V1

P1

var V1

setter M2

getter M3

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

38

(m,0) (m,0), (m,4), (m,5)(a,1) (c,3) (u,1) (c,2)outgoing edgesincoming edges


Graph transformation EncapsulateFieldEncapsulateField(var,getter,setter)

• Parameterised transformation• Embedding mechanism

P2

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

39

preconditionsfor

EncapsulateFieldP2

repeat

succeed

fail

P1


Graph transformation EncapsulateField– Controlled (programmed) graph rewriting

• Control the application order of productions• Use application preconditions

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

40


Graph transformation EncapsulateField– Use preconditions

• To satisfy wf-constraints• to satisfy more specific constraints

– e.g. EncapsulateField should not introduce accessormethod names that exist in inheritance chain

– Express negative preconditions as forbidden graphexpressions

m lgetter M

i*MDCCvar V

mVD

l

m lgetter M

i*MDCCvar V

mVD

l

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

41

m


Graph Transformation EncapsulateField– Apply transformation to LAN graph

• EncapsulateField(name,getName,setName)

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

42


Behaviour preservation– Access preservation

• each method body (transitively) accesses at least the samevariables as it did before the refactoring

– Update preservation• each method body (transitively) performs at least the same

variable updates as it did before the refactoring– Call preservation

• each method body (transitively) performs at least the samemethod calls as it did before the refactoring

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

43

Graph invariant for access preservation

EncapsulateField preserves behaviour– access preserving: variables remain accessible via

transitive closure


MD V?*a

var VEE getter M MD1

c l aevar V

a

853MD

e*EMD

e*

1

VDl

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

44

Graph invariant for update preservation

EncapsulateField preserves behaviour– update preserving: variables remain updatable via

transitive closure


var VEE setter MD MD1

c l uevar V

1

u

MD V?*u

742MD

e*EMD

e*

VDl

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

45

Graph invariant for call preservation

Trivially fulfilled for EncapsulateField– all existing calles are preserved– But: new calls are introduced for each variable

access/update!


MD M?*c

MDl

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

46

Graph transformation PullUpMethod– PullUpMethod(parent,child,name)

• affects all subclasses• requires controlled graph rewriting

name M4

child C

MDm

parent C1

2

3 l

i

P1

name M4

child C

MDm

parent C1

2

3 l

i


P2

name M4

C

MDm

parent C1

5

6 l

i

name M4

C

parent C1

5

i

MD

l

i

MD

l

i

3 3

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

48

C

name MMD

m

parent C

l

iC

MD

m l

c c a a

u u


Behaviour preservation of PullUpMethod– preserves calls, accesses, updates

• Only if we assume isomorphism between pulled up methoddefinitions in subclasses

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

49

Behaviour preservation of PullUpMethod– preserves calls, accesses, updates– Requires tracking function to express method equivalence


P2

name M4

C

MD

m

parent C1

5

6 l

i

name M4

C

parent C1

5

i

MD

l

i

MD

l

i

3 3

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

50

Refactoring through graph transformationTool support

Specified refactorings in FujabaJava

sourcecode

Fujaba Refactoringtransfos

Checkpreservation

refactor

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

51


Conclusion– Graph transformation useful for specifying refactorings

• Language independent• Visual, flexible, precise representation• Verifying different kinds of preservation

But– need to manipulate complex graph structures

• deep copy (push down method), deep move (move method)– current-day tools are immature and not scalable

RefactoringGraph Transformation

wf-constraintstype graph, graph expressions

transformationparameterised and controlled graphtransformation with embedding mechanism

preconditionsnegative application conditions

behaviour preservavtiongraph invariants

© T

om M

ens,

UM

H, M

ay 2

004

Form

al T

ool S

uppo

rt f

or S

oftw

are

Evol

utio

n

52

Open Research Questions

Support for model refactoring (designs / architectures) Other formalisms for refactoring support How to (de)compose refactorings ? How to determine where and why to refactor ? What is (preservation of) behaviour ?

– real-time systems (time); embedded systems (power & memory);safety critical systems (liveness, …)

– What are good program invariants ? How to express them ? What's the effect of refactoring on software quality ?

– complexity, evolvability, performance, ... Co-evolution: How to guarantee consistency ?

– code ⇔ design ⇔ architecture ⇔ requirementsHow is refactoring related to other techniques ?

– design patterns, application frameworks, aspect-orientedprogramming, generative programming, …

service de génie logiciel -...

Documents