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
Université de Mons-Hainaut
Service de Génie Logiciel
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
Maintaining consistency of design models
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
Maintaining consistency of design models
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
Description Logics Formalism
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
Description Logics Formalism
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
Description Logics Formalism
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
Description Logics Formalism
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
Description Logics Formalism
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
Description Logics Formalism
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
Université de Mons-Hainaut
Service de Génie Logiciel
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); } }
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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!
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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
Refactoring through graph transformation
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, …