A Formalism for Transformational Software Evolution

1. A Formalism forTransformational Software Evolution Programming Technology Lab Vrije Universiteit Brussel, Belgium Tom Mens tommens@vub.ac.be http://prog.vub.ac.be/~tommens

2. Need better tool support for • version control • e.g. upgrading application frameworks • collaborative software development • software merging • change management • change propagation • change impact analysis & effort estimation • ripple effect • ... • evolution at a high level of abstraction • evolution of design patterns, refactorings • architectural evolution • ... object-orientedsoftwareevolution

3. Need better tool support for • co-evolution between different phases • maintaining consistency • checking compliance between architecture and design, design and implementation, ... • re-engineering of legacy systems • program comprehension • reverse engineering • migration • ... • empirical research on software evolution • based on change metrics • predictive models • ...

4. Tool support must be • scalable • applicable to large-scale software systems • “A major challenge for the research community is to develop a good theoretical understanding an underpinning for maintenance and evolution, which scales to industrial applications.” [Bennett&Rajlich 2000] • domain-independent • independent of the programming or modelling language • generally applicable in all phases of the software life-cycle

5. Our Approach:Reuse Contracts Usegraph rewritingto provide aformal foundationforsoftware evolution based onreuse contracts http://prog.vub.ac.be/poolresearch/rcs/

6. Reuse Contracts Overview • Benefits of reuse contracts (illustrated with a simple example) • Document reuse and evolution • Deal with upgrade problems • Provide support for software merging • Provide support for framework refactoring • Generalising reuse contracts (using formalism of graph rewriting) • Apply reuse contracts to different domains • analysis, architecture, design, implementation • Scale up reuse contracts to high-level transformations

7. DesktopFolder position contents move: add: addMany: Extension(size, attribute) Refinement(add, size, updates) SizedFolder size add: item 1.Documenting Reuse reuse size =+ item.size

8. DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: Coarsening(addMany, add, invokes) 1.Documenting Evolution evolution

9. DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: SizedFolder SizedFolder size =+ item.size size =+ item.size size size add: item add: item size not updated when adding many items 2.Dealing with Upgrade Problems evolution reuse

10. DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: SizedFolder size add: 2. Dealing with Upgrade Problems evolution reuse Coarsening(addMany, add, invokes) inconsistent operation conflict Extension(size, attribute) Refinement(add, size, updates)

11. 2. Dealing with Upgrade Problems • extension/cancellation: adding/removing an operation or attribute • refinement/coarsening: adding/removing invocation or attribute access • abstraction/concretisation: making an operation abstract/concrete Conflict Table extension refinement coarsening interface conflicts extension refinement coarsening no conflicts no conflicts operation capture, unanticipated recursion operation capture, inconsistent operations no conflicts operation capture, inconsistent operations inconsistent operations no conflicts

12. DesktopFolder v1 DesktopFolder position contents move: add: addMany: contents add: addMany: 3.Support for Software Merging evolution evolution Extension(position, attribute) Extension(move:, method)Coarsening(addMany, add, invokes) inconsistent operation conflict DesktopFolder v2a contents size add: addMany: Extension(size, attribute) Refinement(add, size, updates)

13. Account Bank Company handles Bank Company Account SplitClass(Bank,[Bank,Agency]) Loan represents Loan Agency handles AddClass(Safe) AddAssociation(Bank,Safe) Account Refactoring conflict ! handles Loan Bank Company Safe 4. Support for FW Refactoring • Need for higher-level evolution transformations • Need for user-defined conflict resolution

14. Reuse Contract Formalism • Domain-independent formalism • Independent of the target language • Independent of the phase in the life-cycle • Lightweight formalism to facilitate tool support • Represent software artifacts by graphs • Represent software evolution by graph rewriting • Formal characterisation of evolution conflicts

15. Example: UML class diagram • Internal Graph Representation G Shape«class» Point «class» area «operation» «assoc» x«attribute» Shape center center circumference«operation» y«attribute» Point +area() -x +circumfere() distanceTo«operation» -y vertices 3 «inherits» «inherits» +distanceTo(p: Point) «aggregation» {3} Circle «class» Triangle «class» radius «attribute» vertices Circle intersects«operation» -radius +intersects(c: Circle) Triangle Graphs • Node types: • «class» • «attribute» • «operation» • «interface» • Edge types: • «assoc» • «aggregation» • «inherits» • «implements» • «accesses» • «updates» • «invokes»

16. v node type e edge type Type Graph • Used to specifydomain-specific constraints assoc, aggregation, inherits nested class attribute updates, accesses nested implements interface operation invokes nested inherits Specify extra constraints declaratively

17. R area «operation» «accesses» P radius «attribute» L m area «operation» G H radius «attribute» Circle «class» Circle «class» area «operation» area «operation» «accesses» radius «attribute» radius «attribute» «accesses» «accesses» circumference«operation» circumference«operation» Graph Rewriting • Used to specify software evolution

18. R R L Triangle area «operation» area «operation» AddEdge (area,radius,«accesses») «accesses» «accesses» radius «attribute» radius «attribute» L Triangle DropNode (Triangle.area,«operation») «operation» area Primitive Graph Productions • Use restricted set of graph productions • AddNode • DropNode • AddEdge • DropEdge • RetypeNode • RetypeEdge • RelabelNode • RelabelEdge

19. DesktopFolder «class» DesktopFolder «class» position «attribute» position «attribute» contents «attribute» contents «attribute» move: «operation» move: «operation» add: «operation» add: «operation» «invokes» addMany: «operation» addMany: «operation» SizedFolder «class» size «attribute» add: «operation» Primitive Graph Productions evolution reuse DropEdge(addMany, add, «invokes») inconsistent operation conflict AddNode(size, «attribute») AddEdge(add, size, «updates») «updates»

20. G G1 Circle «class» Circle «class» area «operation» area «operation» «accesses» radius «attribute» radius «attribute» «accesses» «accesses» circumfere«operation» circumfere«operation» P2 G2 P1 = AddEdge(area,radius,«accesses») <<uses>> Circle «class» P1 P2 = DropNode(area,«operation») Undefined source conflict radius «attribute» «accesses» circumfere«operation» Syntactic Conflicts Syntactic conflict if P1 and P2 are not parallel independent P1 P2

21. Syntactic Conflicts • Use a syntactic conflict table • Detect syntactic merge conflicts • in terms of transformation preconditions • compare breaches of application preconditions • Advantages • general • does not rely on predefined graph produtions • scalable • can be used directly for composite or domain-specific graph productions

22. -i +i source (e,v) target (e,v) label (i,L) type (i,T) -source (e,v) -target (e,v) -j  if i=j  if i=j  if j=e  if j=v  if j=e  if j=v  if i=j  if i=j  if j=v  if j=v +j C1 if i=j C2 if e=j  if v=j C3 if e=j  if v=j C4 if i=j C5 if i=j C6 if j=v C7 if j=e C8 if j=v C9 if j=e source (f,w) C10 if (e,v)=(f,w)  if v=w     if (e,v)=(f,w)  target (f,w) C11 if (e,v)=(f,w)  if v=w     if (e,v)=(f,w) label (j,L2) C12 if i=j    type (j,T2) C13 if i=j   -source (f,w) C14 if e=f and vw  -target (f,w) C15 if e=f and vw Syntactic Conflicts

23. L1 R1 L AddEdge (e,area,radius,«accesses») area «operation» area «operation» area «operation» area «operation» area «operation» «accesses» radius «attribute» radius «attribute» Pullback construction m1 G G1 L2 Circle «class» Circle «class» area «operation» area «operation» area «operation» «accesses» radius «attribute» radius «attribute» circumfer«operation» m2 «accesses» «accesses» circumfer«operation» circumfer«operation» Pushout construction Refinement (e,area,circumference,«uses») H G2 R2 Circle «class» Circle «class» area «operation» area «operation» «invokes» area «operation» «accesses» «invokes» «invokes» radius «attribute» radius «attribute» circumfer«operation» «accesses» «accesses» circumfer«operation» circumfer«operation» Semantic Conflicts

24. {added by developer 2} «inherits» {added during reuse} «class»? «class» ? «updates» addMany add size «inherits» «invokes» {added by developer 1} {removed during evolution} Semantic Conflicts • Based on the formal notion of • pushouts and pullbacks • Fine-grained conflict characterisation • By detecting occurrence of graph patternsin result graph inconsistent method conflict cyclic inheritance

25. Account Bank Company handles Bank Company Account SplitClass(Bank,[Bank,Agency]) Loan represents Loan Agency handles AddClass(Safe) AddAssociation(Bank,Safe) Account Refactoring conflict ! handles Loan Bank Company Safe Structural Conflicts • More difficult to detect in a general way • Customise conflict table with user-defined and domain-specific conflict resolution rules

26. Addressing Scalability • Use assertions to describe productions • preconditions, postconditions, invariants • Use dependencies to address scalability • Defining “atomic” composite productions from a production sequence • Reordering productions in a sequence • Removing redundancy in a production sequence • Factoring out commonalities from parallel production sequences • Parallellising subsequences

27. L Account a 1 handles Bank preconditions Loan 3 b invariants 2 -4 -g source(a,3) source(b,3) +1, +2, +3, +a, +b P target(a,1), target(b,1) +(4,Agency,class) source(a,4) source(b,4) +(g,3,4,represents,assoc) R postconditions Bank a Account 3 g represents 1 b Loan Agency handles 4 2 Example ctd.

28. Using dependencies • Dependencies can be defined between productions • based on relations between assertions

29. 1. Composite productions (a) Calculate dependencies between productions in the sequence (b) Calculate pre/postconditions of composite in terms of this information

30. 2. Reordering productions

31. AddE(g,3,4) DropE(g,3,4) RelabelN(1,2) RetypeN(2) AddN(3) AddN(4) DropN(3) AddN(3) AddN(4) DropN(3) AddN(4) AddN(3) DropN(3) AddN(4) 3. Removing redundancy • Simplify a production sequence redundant pair reorder redundant pair

32. 3. Removing Redundancy

33. 4. Factoring out commonalities • Find commonalities in two parallel sequences, and factor out • facilitates merging and conflict detection

34. Validation of Reuse Contracts • Industrial case • One base release line • many customisations for  customer applications • Collaborative software development • parallel changes to base release and customisations • Provide support for • customisation, refactoring, upgrading, consolidation 7.2 NDR 7.4 DR VTM 10.x WDR 0.1 TV2 11 WDR 1.0 12 WDR 2.0

35. To Do • User-friendly tool support • Perform large-scale experiments • Validate scalability • Look at conflict resolution techniques • Look at structural conflicts (refactoring) • Address co-evolution

36. abstractlayer evolution consistent??? refinement concretelayer evolution Future Research: Co-Evolution • Underlying idea • Keep representation of same software artifact at different levels of abstraction (e.g. design and implementation) synchronised during evolution • Use triple graph grammars