A Formalism for Transformational Software Evolution Programming Technology Lab Vrije Universiteit Brussel, Belgium Tom Mens

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

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 ...

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

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

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

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

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:

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

March 2001, Lisbon© Mens Tom, Programming Technology Lab 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

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

March 2001, Lisbon© Mens Tom, Programming Technology Lab 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:

March 2001, Lisbon© Mens Tom, Programming Technology Lab 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

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

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»

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

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

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

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»

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»

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

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

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»

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

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

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

March 2001, Lisbon© Mens Tom, Programming Technology Lab 27 Example ctd. L Bank Account Loan handles   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    4 postconditions

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

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

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

March 2001, Lisbon© Mens Tom, Programming Technology Lab 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

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

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

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 x NDR DR WDR 0.1 VTM TV2 WDR 1.0 WDR 2.0

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

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