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

2. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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-oriented software evolution

3. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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. March 2001, Lisbon© Mens Tom, Programming Technology Lab 5 Our Approach: Reuse Contracts Use graph rewriting to provide a formal foundation for software evolution based on reuse contracts http://prog.vub.ac.be/poolresearch/rcs/

6. March 2001, Lisbon© Mens Tom, Programming Technology Lab 6 Reuse Contracts Overview  Benefits of reuse contracts (illustrated with a simple example) 1.Document reuse and evolution 2.Deal with upgrade problems 3.Provide support for software merging 4.Provide support for framework refactoring  Generalising reuse contracts (using formalism of graph rewriting) 1.Apply reuse contracts to different domains  analysis, architecture, design, implementation 2.Scale up reuse contracts to high-level transformations

7. March 2001, Lisbon© Mens Tom, Programming Technology Lab 7 1. Documenting Reuse DesktopFolder position contents move: add: addMany: SizedFolder add: item size reuse Extension(size, attribute) Refinement(add, size, updates) size =+ item.size

8. March 2001, Lisbon© Mens Tom, Programming Technology Lab 8 DesktopFolder position contents move: add: addMany: 1. Documenting Evolution evolution Coarsening(addMany, add, invokes) DesktopFolder position contents move: add: addMany:

9. March 2001, Lisbon© Mens Tom, Programming Technology Lab 9 2. Dealing with Upgrade Problems DesktopFolder position contents move: add: addMany: evolution DesktopFolder position contents move: add: addMany: reuse size not updated when adding many items SizedFolder add: item size size =+ item.size SizedFolder add: item size size =+ item.size

10. March 2001, Lisbon© Mens Tom, Programming Technology Lab 10 2. Dealing with Upgrade Problems DesktopFolder position contents move: add: addMany: evolution DesktopFolder position contents move: add: addMany: SizedFolder add: size reuse Coarsening(addMany, add, invokes) Extension(size, attribute) Refinement(add, size, updates) inconsistent operation conflict

11. March 2001, Lisbon© Mens Tom, Programming Technology Lab 11 Conflict Table 2. Dealing with Upgrade Problems extension refinement coarsening extensionrefinementcoarsening no conflicts inconsistent operations interface conflicts operation capture, unanticipated recursion operation capture, inconsistent operations no conflicts operation capture, inconsistent operations  extension/cancellation: adding/removing an operation or attribute  refinement/coarsening: adding/removing invocation or attribute access  abstraction/concretisation: making an operation abstract/concrete

12. March 2001, Lisbon© Mens Tom, Programming Technology Lab 12 3. Support for Software Merging DesktopFolder position contents move: add: addMany: evolution DesktopFolder v1 contents add: addMany: evolution Extension(position, attribute) Extension(move:, method) Coarsening(addMany, add, invokes) Extension(size, attribute) Refinement(add, size, updates) inconsistent operation conflict DesktopFolder v2a contents size add: addMany:

13. March 2001, Lisbon© Mens Tom, Programming Technology Lab 13 4. Support for FW Refactoring Refactoring conflict ! Bank Account Loan handles Company SplitClass (Bank,[Bank,Agency]) Agency Account Loan handles BankCompany represents AddClass(Safe) AddAssociation(Bank,Safe) Bank Account Loan handles Company Safe  Need for higher-level evolution transformations  Need for user-defined conflict resolution

14. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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. March 2001, Lisbon© Mens Tom, Programming Technology Lab 15 Graphs G Triangle «class» Circle «class» «inherits» intersects «operation» «assoc» center radius «attribute» «aggregation» vertices {3} Point «class»Shape «class» area «operation» circumference «operation» x «attribute» distanceTo «operation» y «attribute» «inherits»  Internal Graph Representation +intersects(c: Circle) -radius Circle +distanceTo(p: Point) -x -y Point Triangle +area() +circumfere() Shape center vertices3  Example: UML class diagram  Node types:  «class»  «attribute»  «operation»  «interface»  Edge types:  «assoc»  «aggregation»  «inherits»  «implements»  «accesses»  «updates»  «invokes»

16. March 2001, Lisbon© Mens Tom, Programming Technology Lab 16 Type Graph v e node type edge type implements nested operation attribute interface class assoc, aggregation, inherits inherits updates, accesses invokes nested  Used to specify domain-specific constraints Specify extra constraints declaratively

17. March 2001, Lisbon© Mens Tom, Programming Technology Lab 17 P m R area «operation» radius «attribute» «accesses» G Circle «class» area «operation» «accesses» circumference «operation» radius «attribute» H Circle «class» area «operation» «accesses» circumference «operation» radius «attribute» «accesses» L area «operation» radius «attribute» Graph Rewriting  Used to specify software evolution

18. March 2001, Lisbon© Mens Tom, Programming Technology Lab 18  Use restricted set of graph productions  AddNode  DropNode  AddEdge  DropEdge  RetypeNode  RetypeEdge  RelabelNode  RelabelEdge Primitive Graph Productions AddEdge (area,radius,«accesses») R area «operation» radius «attribute» «accesses» L area «operation» radius «attribute» DropNode (Triangle.area,«operation») R Triangle L «operation» area Triangle

19. March 2001, Lisbon© Mens Tom, Programming Technology Lab 19 Primitive Graph Productions evolution reuse DropEdge(addMany, add, «invokes») AddNode(size, «attribute») AddEdge(add, size, «updates») inconsistent operation conflict SizedFolder «class» size «attribute» add: «operation» DesktopFolder «class» position «attribute» contents «attribute» move: «operation» add: «operation» addMany: «operation» DesktopFolder «class» position «attribute» contents «attribute» move: «operation» add: «operation» addMany: «operation» «invokes» «updates»

20. March 2001, Lisbon© Mens Tom, Programming Technology Lab 20 Syntactic Conflicts P1P1 P 2 = DropNode(area,«operation») P 1 = AddEdge(area,radius,«accesses») P2P2 P1P1 P2P2 Undefined source conflict Syntactic conflict if P 1 and P 2 are not parallel independent G Circle «class» area «operation» circumfere «operation» radius «attribute» «accesses» > G2G2 Circle «class» circumfere «operation» radius «attribute» «accesses» G1G1 Circle «class» area «operation» circumfere «operation» radius «attribute» «accesses»

21. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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. March 2001, Lisbon© Mens Tom, Programming Technology Lab 22 Syntactic Conflicts -i+isource (e,v) target (e,v) label (i,L) type (i,T) -source (e,v) -target (e,v) -j  if i=j  if j=e  if j=v  if j=e  if j=v  if i=j  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=jC5 if i=jC6 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

23. March 2001, Lisbon© Mens Tom, Programming Technology Lab 23 Semantic Conflicts L1L1 area «operation» radius «attribute» R1R1 area «operation» radius «attribute» «accesses» G Circle «class» area «operation» circumfer «operation» radius «attribute» «accesses» G1G1 Circle «class» area «operation» circumfer «operation» radius «attribute» «accesses» m1m1 AddEdge ( ,area,radius,«accesses») H Circle «class» area «operation» circumfer «operation» radius «attribute» «accesses» «invokes» Pushout construction L2L2 area «operation» circumfer «operation» R2R2 area «operation» circumfer «operation» «invokes» G2G2 Circle «class» area «operation» «accesses» circumfer «operation» radius «attribute» «invokes» Refinement ( ,area,circumference,«uses») m2m2 L area «operation» Pullback construction area «operation»

24. March 2001, Lisbon© Mens Tom, Programming Technology Lab 24  Based on the formal notion of  pushouts and pullbacks  Fine-grained conflict characterisation  By detecting occurrence of graph patterns in result graph Semantic Conflicts addManyaddsize « updates » « invokes » {added during reuse} {removed during evolution} inconsistent method conflict « class » ? « class » ? « inherits » {added by developer 2} {added by developer 1} cyclic inheritance

25. March 2001, Lisbon© Mens Tom, Programming Technology Lab 25 Structural Conflicts Refactoring conflict ! Bank Account Loan handles Company SplitClass (Bank,[Bank,Agency]) Agency Account Loan handles BankCompany represents AddClass(Safe) AddAssociation(Bank,Safe) Bank Account Loan handles Company Safe More difficult to detect in a general way  Customise conflict table with user-defined and domain-specific conflict resolution rules

26. March 2001, Lisbon© Mens Tom, Programming Technology Lab 26 Addressing Scalability  Use assertions to describe productions  preconditions, postconditions, invariants  Use dependencies to address scalability 1.Defining “atomic” composite productions from a production sequence 2.Reordering productions in a sequence 3.Removing redundancy in a production sequence 4.Factoring out commonalities from parallel production sequences 5.Parallellising subsequences

27. March 2001, Lisbon© Mens Tom, Programming Technology Lab 27 Example ctd. L Bank Account Loan handles 1 2 3   P source( ,3)source( ,3)  +( ,3,4,represents,assoc) +(4,Agency,class) +1, +2, +3, + , +  -4 target( ,1), target( ,1) source( ,4)source( ,4) preconditions invariants R Agency Account Loan handles Bank represents 1 2 3    4 postconditions

28. March 2001, Lisbon© Mens Tom, Programming Technology Lab 28 Using dependencies  Dependencies can be defined between productions  based on relations between assertions

29. March 2001, Lisbon© Mens Tom, Programming Technology Lab 29 1. Composite productions (a) Calculate dependencies between productions in the sequence (b) Calculate pre/postconditions of composite in terms of this information

30. March 2001, Lisbon© Mens Tom, Programming Technology Lab 30 2. Reordering productions

31. March 2001, Lisbon© Mens Tom, Programming Technology Lab 31 3. Removing redundancy  Simplify a production sequence AddN(4) AddN(3)AddN(4)RelabelN(1,2) AddE( ,3,4) RetypeN(2) DropE( ,3,4) DropN(3) AddN(3)AddN(4)DropN(3) AddN(3)AddN(4)DropN(3) redundant pair reorder redundant pair

32. March 2001, Lisbon© Mens Tom, Programming Technology Lab 32 3. Removing Redundancy

33. March 2001, Lisbon© Mens Tom, Programming Technology Lab 33 4. Factoring out commonalities  Find commonalities in two parallel sequences, and factor out  facilitates merging and conflict detection

34. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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 7.4 10.x 11 12 NDR DR WDR 0.1 VTM TV2 WDR 1.0 WDR 2.0

35. March 2001, Lisbon© Mens Tom, Programming Technology Lab 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. March 2001, Lisbon© Mens Tom, Programming Technology Lab 36 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 refinement abstract layer concrete layer consistent??? evolution