A Formalism for Transformational Software Evolution Programming Technology

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

Need better tool support for Ø version control Ø e. g. upgrading application frameworks Ø collaborative software development object-oriented software evolution Ø 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 Ø. . . March 2001, Lisbon © Mens Tom, Programming Technology Lab 2

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 3

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

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

Reuse Contracts Overview Ø Benefits of reuse contracts (illustrated with a simple example) 1. 2. 3. 4. 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) 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 6

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

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

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

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

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 interface conflicts refinement no conflicts operation capture, unanticipated recursion operation capture, inconsistent operations no conflicts operation capture, inconsistent operations coarsening March 2001, Lisbon refinement no conflicts © Mens Tom, Programming Technology Lab coarsening no conflicts 11

3. Support for Software Merging Desktop. Folder v 1 contents add: add. Many: evolution Desktop. Folder evolution position contents move: add. Many: Extension(position, attribute) Extension(move: , method) Desktop. Folder v 2 a Coarsening(add. Many, add, invokes) contents size add: add. Many: March 2001, Lisbon Extension(size, attribute) Refinement(add, size, updates) © Mens Tom, Programming Technology Lab inconsistent operation conflict 12

4. Support for FW Refactoring Account handles Bank Company Loan Split. Class (Bank, [Bank, Age ncy]) Bank Account Company represents Loan handles Agency Add. Class(Safe) Add. Association(Bank, Safe) Account Loan Refactoring conflict ! handles Safe March 2001, Lisbon Bank Company ØNeed for higher-level evolution transformations ØNeed for user-defined conflict resolution © Mens Tom, Programming Technology Lab 13

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 14

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

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

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

Primitive Graph Productions Ø Use restricted set of graph productions March 2001, Lisbon R L area «operation» radius «attribute» Add. Edge (area, radius, «accesses» ) area «operation» radius «attribute» L Triangle «operation» area «accesses» Add. Node Drop. Node Add. Edge Drop. Edge Retype. Node Retype. Edge Relabel. Node Relabel. Edge «accesses» Ø Ø Ø Ø R Drop. Node (Triangle. area, «operation» ) © Mens Tom, Programming Technology Lab Triangle 18

Primitive Graph Productions Desktop. Folder «class» position «attribute» contents «attribute» move: «operation» «invokes» add: «operation» add. Many: «operation» reuse size «attribute» add: «operation» March 2001, Lisbon «updates» Sized. Folder «class» evolution add: «operation» add. Many: «operation» Drop. Edge(add. Many, add, «invokes» ) Add. Node(size, «attribute» ) Add. Edge(add, size, «updates» ) © Mens Tom, Programming Technology Lab inconsistent operation conflict 19

Syntactic Conflicts Syntactic conflict if P 1 and P 2 are not parallel independent G G 1 Circle «class» P 1 area «operation» radius «attribute» «accesses» circumfere «operation» G 2 «accesses» radius «attribute» «accesses» circumfere «operation» P 1 = Add. Edge(area, radius, «accesses» ) <<uses>> Circle «class» «accesses» circumfere «operation» March 2001, Lisbon area «operation» P 2 radius «attribute» Circle «class» P 1 P 2 = Drop. Node(area, «operation» ) Undefined source conflict © Mens Tom, Programming Technology Lab 20

Syntactic Conflicts Ø Use a syntactic conflict table Ø Detect syntactic merge conflicts Ø in terms of transformation preconditions Ø compare breaches of application preconditions Ø Advantages J general Ø does not rely on predefined graph produtions J scalable Ø can be used directly for composite or domain-specific graph productions March 2001, Lisbon © Mens Tom, Programming Technology Lab 21

Syntactic Conflicts -j +j -i +i source (e, v) target (e, v) label (i, L) type (i, T) -source (e, v) -target (e, v) if i=j if j=e if j=v if i=j if j=v C 1 if i=j C 2 if e=j if v=j C 3 if e=j if v=j C 4 if i=j C 5 if i=j C 6 if j=v C 7 if j=e C 8 if j=v C 9 if j=e C 10 if (e, v)=(f, w) if v=w if (e, v)=(f, w) C 11 if (e, v)=(f, w) if v=w if (e, v)=(f, w) C 12 if i=j C 13 if i=j C 14 if e=f and v w source (f, w) target (f, w) label (j, L 2) type (j, T 2) -source (f, w) -target (f, w) March 2001, Lisbon C 15 if e=f and v w © Mens Tom, Programming Technology Lab 22

Semantic Conflicts L 1 L R 1 Add. Edge area «operation» (e, area, radius, «accesses» ) area «operation» «accesses» radius «attribute» ck on a llb ucti u P str n co L 2 G area «operation» circumfer «operation» m 1 G 1 Circle «class» area «operation» radius «attribute» «accesses» m 2 «accesses» circumfer «operation» co Pus ns ho tru u cti t on circumfer «operation» Refinement (e, area, circumference, «uses» ) G 2 R 2 Circle «class» «invokes» circumfer «operation» radius «attribute» Circle «class» area «operation» «invokes» «accesses» circumfer «operation» March 2001, Lisbon H area «operation» «invokes» area «operation» «accesses» © Mens Tom, Programming Technology Lab «accesses» radius «attribute» «accesses» circumfer «operation» 23

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

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

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 26

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

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

1. 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 29

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

3. Removing redundancy Ø Simplify a production sequence Relabel. N(1, 2) Retype. N(2) Add. N(3) Add. N(4) Add. E(g, 3, 4) Drop. E(g, 3, 4) redundant pair Add. N(3) Add. N(4) Drop. N(3) reorder Add. N(4) Add. N(3) Drop. N(3) redundant pair Add. N(4) March 2001, Lisbon © Mens Tom, Programming Technology Lab Drop. N(3) 31

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

4. 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 33

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 March 2001, Lisbon 7. 2 NDR 7. 4 DR VTM 10. x WDR 0. 1 WDR 1. 0 11 TV 2 12 WDR 2. 0 © Mens Tom, Programming Technology Lab 34

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 35

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 refinement evolution abstract layer consistent? ? ? concrete layer Ø Use triple graph grammars March 2001, Lisbon © Mens Tom, Programming Technology Lab 36