1. 1 A Graph Rewriting Formalism for Object-Oriented Software Evolution Tom Mens tom.mens@vub.ac.be FWO Postdoctoral Fellow Programming Technology Lab Vrije Universiteit Brussel Belgium

2. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 2 Thesis Statement A formal foundation (of reuse contracts) allows us to deal with (object-oriented) software evolution in a domain- independent and scalable way.

3. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 3 Overview  Formal techniques enable domain-independence  independent of the considered (OO) programming language  e.g., Smalltalk, Java, C++, …  independent of the phase in the software life-cycle  e.g., analysis, software architecture, design, implementation  Provide formalism based on graph rewriting  Represent software by graphs  Represent software evolution by graph rewriting  Use formalism to support software merging and upgrading  Provide formal characterisation of merge conflicts  Facilitate detection (and resolution) of conflicts

4. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 4 workstation 1 fileserver 1 workstation 2 printer 1 workstation 3 1. originate(p) 2. send(p) 3. accept(p) 4. send(p) 5. accept(p) 6. send(p) 7. accept(p) 8.print(p) Running example: LAN simulation

5. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 5 Example: UML class diagram accept(p:Packet) originate(p:Packet) Workstation contents Packet accept(p:Packet) send(p:Packet) Node originator name accept(p:Packet) print(p:Packet) PrintServer accept(p:Packet) save(p:Packet) FileServer addressee nextNode

6. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 6 Example: graph representation «assoc» originator Packet «class»Node «class» accept «operation» send «operation» «inherit» Vertex types: «class» «attribute» «operation»... Edge types: «assoc» «inherit» «invoke» «access» «update»... «assoc» addressee name «attribute» contents «attribute» Workstation «class» accept «operation» originate «operation» Transcript «class» println «operation» nextNode «attribute» «access» «invoke»

7. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 7 Example: type graph nested operation attributeclass assoc, inherit update access invoke nested  Use type graph to specify domain-specific constraints

8. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 8  Use restricted set of primitive graph productions with application preconditions to specify software evolution AddVertex DropVertex AddEdge DropEdge RetypeVertex RetypeEdge RedirectSource RedirectTarget RelabelVertex RelabelEdge Evolution by graph productions AddEdge (invoke,send,getName) getName «operation» send «operation» «invoke» getName «operation» send «operation» «invoke» RedirectSource (access,send,name,getName) send «operation» name «attribute» «access» getName «operation» «access»  send «operation» name «attribute» getName «operation» «access» 

9. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 9 Example: software evolution  P 1 : Add accessor operation getName for attribute name Node «class» accept «operation» send «operation» name «attribute» nextNode «attribute» «access» «invoke» Node «class» accept «operation» send «operation» name «attribute» nextNode «attribute» «access» «invoke» getName «operation» «invoke» «access» AddVertex(operation,getName) RedirectSource(access,send,name,getName) AddEdge(invoke,send,getName) send «operation» name «attribute» «access» getName «operation» name «attribute» «access» send «operation» «invoke» P1P1

10. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 10 Example: software evolution  P 2 : Factor out logging behaviour Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» log «operation» «invoke» «access» AddVertex(operation,log) AddEdge(invoke,send,log) RedirectSource(invoke,send,println,log) RedirectSource(access,send,name,log) send «operation» name «attribute» «access» println «operation» «invoke» send «operation» name «attribute» «access» println «operation» «invoke» log «operation» «invoke» P2P2

11. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 11 Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» log «operation» «invoke» «access» Node «class» accept «operation» send «operation» name «attribute» nextNode «attribute» «access» «invoke» getName «operation» «invoke» «access» send «operation» name «attribute» «access» getName «operation» name «attribute» «access» send «operation» «invoke» send «operation» name «attribute» println «operation» «access» «invoke» send «operation» name «attribute» println «operation» «access» «invoke» log «operation» «invoke» send «operation» name «attribute» «access» Example: Software Merging Use pullback to detect potential merge conflicts P2P2 P1P1

12. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 12 Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» Node «class» accept «operation» send «operation» name «attribute» Transcript «class» println «operation» nextNode «attribute» «access» «invoke» log «operation» «invoke» «access» Node «class» accept «operation» send «operation» name «attribute» nextNode «attribute» «access» «invoke» getName «operation» «invoke» «access» Example: Software Merging AddVertex(operation,log) AddEdge(invoke,send,log) RedirectSource(invoke,send,println,log) RedirectSource(access,send,name,log) AddVertex(operation,getName) RedirectSource(access,send,name,getName) AddEdge(invoke,send,getName) Conflict if productions are parallel dependent Detect by violations of application preconditions syntactic conflict !

13. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 13 Example: Software Merging RedirectSource (access,send,name,log) send «operation» name «attribute» log «operation» «access»  getName «operation» send «operation» name «attribute» log «operation» «access»  getName «operation» send «operation» name «attribute» log «operation»  getName «operation» «access» RedirectSource (access,send,name,getName) precondition  edge (access,send,name) not satisfied ! precondition  edge (access,send,name) not satisfied ! merge conflict Can be implemented efficiently using conflict table

14. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 14 Addressing scalability  Normalisation algorithm  Removes redundant productions in a sequence  Reorders the remaining productions into a canonical form  Predefine composite productions as sequences of productions SplitMethod(m 1,m 2,OutEdges) = AddVertex(operation,m 1 ),AddEdge(invoke,m 1,m 2 ), RedirectSource(type,m 1,target,m 2 )forall (type,target) in OutEdges P 1 = SplitMethod(send,log,{(invoke,println),(access,name)})  Use high-level information about the evolution transformations to detect and resolve evolution conflicts  Formalisation of object-oriented refactorings  Detect their applicability; ensure their behaviour-preservation; analyse their complexity  Evolution of design pattern instances “A Declarative Evolution Framework for Object-Oriented Design Patterns”. Tom Mens, Tom Tourwe, ICSM 2001

15. ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel 15 Conclusion  Conditional graph rewriting is a feasible and useful formalism to address the problem of software merging in a domain-independent way.  Further work needed  practical validation in industrial setting  integrate ideas in CASE tools of IDEs  address scalability better  deal with conflict resolution