Formal tool support for software evolution

Transcription

1 Service de Génie Logiciel Formal tool support for software evolution Tom Mens staff.umh.ac.be/mens.tom/ Université de Mons-Hainaut

2 Problem statement More and better tool support needed for software evolution 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 2

3 Formal support for consistency maintenance to ensure that a design model remains consistent when parts of it evolve based on description logics formalism in collaboration with Ragnhild Van Der Straeten Vrije Universiteit Brussel for refactoring to ensure that the refactored software preserves the behaviour of the original version based on graph rewriting formalism in collaboration with Serge Demeyer & Dirk Janssens Universiteit Antwerpen 3

4 Service de Génie Logiciel Formal Support for Consistency Maintenance Université de Mons-Hainaut

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 dealing with this problem 5

6 Maintaining consistency of design models Requires 3 kinds of traceability 6

7 Maintaining consistency of design models Extension (profile) of UML metamodel 7

8 Classification of inconsistencies Behavioural Structural 8 Specification specification conflicts Specification - instance conflicts Instance - instance conflicts Invocation inheritance inconsistency Observation inheritance inconsistency Incompatible definition Invocation inheritance inconsistency Observation inheritance inconsistency Incompatible behaviour inconsistency Dangling type reference Inherited association inconsistency Role specification missing Instance specification missing Disconnected model

9 Motivating example Incompatible behaviour inconsistency Sequence of messages in sequence diagram is inconsistent with specification of behaviour represented by protocol state machine it is not possible to find a path in the state machine that corresponds to the order established by the sequence diagram Invocation inheritance consistency any sequence of operations invocable on the superclass can also be invoked on the subclass (Liskov's substitutability principle) 9

10 Motivating example 10

11 Motivating example 11

12 Motivating example Incompatible behaviour inconsistency 12

13 Motivating example Invocation inheritance inconsistency ATM PrintingATM 13

14 Description Logics Formalism 14 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

15 Construct Description Logics Dialects Tradeoff expressiveness/performance Syntax Language concept A S FL role name (atomic or transitive) R conjunction value restriction existential quantification top bottom negation disjunction existential restriction (E) number restrictions collection of individuals C D R.C R T A C C D R.C ( n R) ( n R) { a1... an } N O AL* role hierarchy R S H 15 inverse role qualified number restriction R ( n R.C) ( n R.C) I Q

16 Description Logics Dialects Tradeoff expressiveness/performance Language FL, AL ALE, ALR, ALER ALC, ALCO, ALCOU, S, ALCOUE, SI SHIN, SHIQ with atomic roles SHIQ with transitive roles Complexity P NP PSpace ExpTime NExpTime 16

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 ModelElement Versioned)) 17

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

19 Description Logics Formalism 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)))))

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

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 CHECKIFCASHAVAILABLE Current operation: I DISPENSECASH Current operation: I EJECTCARD Inconsistency at state: I GIVECASH NIL Need to improve usability integrate in UML tool OCL front-end 21

22 Description Logics Formalism Current work : model refactoring Claim : 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 SD1 inheritance consistency evolution C SD1 evolution consistency 22 D SD2

23 Service de Génie Logiciel Formal support for Software Refactoring Université de Mons-Hainaut

24 Software Refactoring Definition Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure [Fowler 1999] Goals Improve the design of software Increase program understanding Detect existing bugs Avoid introducing new bugs Increase productivity Increase maintainability 26

25 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 27

26 Refactoring through graph transformation LAN case: Java source code 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 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 Packet { public String contents; public Node originator; public Node addressee; } 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("no destination"); else super.accept(p); } }

27 Refactoring through graph transformation LAN case: Program structure Directed, labelled, typed graph 31

28 Refactoring through graph transformation LAN case: Program Behaviour Behaviour of class Node use a kind of "extended" abstract syntax tree {System.out.println( name+"sends to"+nextnode.name); nextnode.accept(p);} {this.send(p);} 32

29 Refactoring through graph transformation well-formedness constraints: Type graph graph metamodel cf. UML metamodel a,u c V M P t t,p l m C l p a,u VD m MD e E i e 33

30 Refactoring through graph transformation Well-formedness constraints = forbidden subgraphs WF-1: a class cannot define the same method twice WF-2: a method cannot refer to variables in descendant classes WF-3: a method cannot refer to parameters of other methods C m m MD MD l l m M C V m l m i* a u MD E e* MD 1 2 p P a u MD E e* 34 WF-1 WF-2 WF-3

31 Refactoring through graph transformation 36 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 in inheritance chain 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 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); } }

32 Refactoring through graph transformation Graph transformation EncapsulateField EncapsulateField(var,getter,setter) Parameterised transformation Embedding mechanism incoming edges var V 1 P 1 outgoing edges (t,1) (t,1), (p,2), (t,3) var V 1 setter M 2 getter M 3 37

33 Refactoring through graph transformation Graph transformation EncapsulateField EncapsulateField(var,getter,setter) Parameterised transformation Embedding mechanism incoming edges (a,1) (c,3) P 2 (u,1) (c,2) outgoing edges (m,0) (m,0), (m,4), (m,5) 38

34 Refactoring through graph transformation Graph transformation EncapsulateField Controlled (programmed) graph rewriting Control the application order of productions Use application preconditions preconditions for EncapsulateField succeed fail P 1 repeat P 2 39

35 Refactoring through graph transformation Graph transformation EncapsulateField Use preconditions To satisfy wf-constraints to satisfy more specific constraints e.g. EncapsulateField should not introduce accessor method names that exist in inheritance chain Express negative preconditions as forbidden graph expressions var V var V m m VD VD l l C C i* i* C C m m MD MD l l getter M getter M 40

36 Refactoring through graph transformation Graph Transformation EncapsulateField Apply transformation to LAN graph EncapsulateField(name,getName,setName) m 41

37 Refactoring through graph transformation Behaviour preservation Access preservation each method body (transitively) accesses at least the same variables 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 same method calls as it did before the refactoring 42

38 Refactoring through graph transformation Graph invariant for access preservation MD?*a V EncapsulateField preserves behaviour access preserving: variables remain accessible via transitive closure a e* MD E var V 1 MD e* l VD c l e a E getter M MD 3 5 E 8 var V 1 43

39 Refactoring through graph transformation Graph invariant for update preservation EncapsulateField preserves behaviour update preserving: variables remain updatable via transitive closure MD e* E u var V 1 MD?*u MD e* V l VD c l e u E setter MD MD 2 4 E 7 var V 1 44

40 Refactoring through graph transformation Graph invariant for call preservation MD?*c M MD Trivially fulfilled for EncapsulateField all existing calles are preserved But: new calls are introduced for each variable access/update! l 45

41 Refactoring through graph transformation Graph transformation PullUpMethod PullUpMethod(parent,child,name) affects all subclasses requires controlled graph rewriting parent C 1 child C 2 MD 3 i m l name M 4 P 1 parent C 1 child C 2 MD 3 i l name M 4 m i parent C 1 i C MD 5 m MD 3 3 MD P 2 l 6 l name M 4 i l parent C 1 i C 5 name M 4 46

42 Refactoring through graph transformation Behaviour preservation of PullUpMethod preserves calls, accesses, updates Only if we assume isomorphism between pulled up method definitions in subclasses C MD m l parent C i name M c c a a u u l m C MD 48

43 Refactoring through graph transformation Behaviour preservation of PullUpMethod preserves calls, accesses, updates Requires tracking function to express method equivalence i parent C 1 C 5 i m MD MD P MD 6 l l name M 4 i l name M 4 parent C 1 i C 5 49

44 Refactoring through graph transformation Tool support Specified refactorings in Fujaba Java source code refactor Fujaba Refactoring transfos Check preservation 50

45 Refactoring through graph transformation 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 Graph Transformation type graph, graph expressions graph invariants negative application conditions parameterised and controlled graph transformation with embedding mechanism Refactoring wf-constraints behaviour preservavtion preconditions transformation

46 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 requirements How is refactoring related to other techniques? design patterns, application frameworks, aspect-oriented programming, generative programming, 52