1. Katholieke Universiteit Leuven112 April 2000 Research Topics in Software Evolution Dr. Tom Mens FWO Postdoctoral Fellow Programming Technology Lab Vrije Universiteit Brussel

2. 2 Long-Term Research Goal Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

3. 3 Long-Term Research Goal  Anticipating evolution (= before)  how can we improve the quality of the software?  how can we identify unstable parts in the software?  which parts are badly designed / need restructuring?  Supporting evolution (= during)  e.g. support for upgrading, restructuring, merging, …  documenting evolution  Analysing evolution (= after)  does the evolution have the desired effect?  has the software quality improved? Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

4. 4 Long-Term Research Goal Wide range of evolution support tools is needed  Upgrading software, frameworks and components  involves version control, collaborative development, software merging  Improving software quality, restructuring  Assessing software quality, determining need for evolution  Empirical and experimental research  Management aspects  Better understanding of the software evolution process itself  Co-evolution, consistency maintenance, compliance checking  Change propagation, impact analysis, effort estimation Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

5. 5 Long-Term Research Goal  Scalability of the technique is essential  must remain applicable for large-sized software systems and for large software development teams  “A major challenge for the research community is to develop a good theoretical understanding and underpinning for maintenance and evolution, which scales to industrial applications.” K. H. Bennett, V.T. Rajlich, Software Maintenance and Evolution: A Roadmap, The Future of Software Engineering, ACM Press, 2000  Need for lightweight approaches Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

6. 6 Long-Term Research Goal  Formal techniques enable domain-independence  independent of the considered (OO) programming language  e.g., Smalltalk, Eiffel, Java, C++, …  independent of the phase in the software life-cycle  e.g., analysis, software architecture, design, implementation  Emphasis on following formalisms  Graphs and graph rewriting  Declarative reasoning techniques on top of OO language  Software metrics Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

7. 7 Current research E V O L U T I O N Better support for software merging Manage evolution of design patterns Assess need for evolution F O R M A L I S M S Graph rewriting Declarative reasoning Software metrics

8. 8 Current research E V O L U T I O N Better support for software merging Manage evolution of design patterns Assess need for evolution F O R M A L I S M S Graph rewriting Declarative reasoning Software metrics

9. 9 Better support for software merging  Based on idea of reuse contracts  Provide formalism based on graph rewriting  Represent software by graphs  Represent software evolution by graph rewriting  Provide formal characterisation of merge conflicts  Domain-independent approach  Independent of the target language  Independent of the phase in the life-cycle

10. 10 Better support for software merging +intersects(c: Circle) -radius Circle +distanceTo(p: Point) -x -y PointTriangle +area() +circumference() Shape center vertices3  Example: UML class diagram

11. 11 Better support for software merging  Use graphs to represent software 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» n Node types: u «class» u «attribute» u «operation» u «interface» n Edge types: u «assoc» u «aggregation» u «inherits» u «implements» u «accesses» u «updates» u «invokes»

12. 12 Better support for software merging implements nested operation attribute interface class assoc, aggregation, inherits inherits updates, accesses invokes nested  Use type graph to specify domain-specific constraints Specify other constraints declaratively

13. 13  Use restricted set of primitive graph productions with application preconditions to specify software evolution  AddNode  DropNode  AddEdge  DropEdge  RetypeNode  RetypeEdge  RelabelNode  RelabelEdge Better support for software merging 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

14. 14 AddEdge 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» Better support for software merging  Use single-pushout approach to apply graph production to a given initial graph G

15. 15 Better support for software merging  Detect syntactic merge conflicts as breaches of application preconditions  corresponds to notion of parallel dependence  can be implemented efficiently with a conflict table or merge matrix P1P1 P 2 = DropNode(area,«operation») P 1 = AddEdge(area,radius,«accesses») P2P2 P1P1 P2P2 Undefined source conflict 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»

16. 16  Detect semantic merge conflicts using the formal notion of pushouts and pullbacks  More fine-grained conflict characterisation by detecting occurrence of graph patterns in result graph Better support for software merging « class » « inherits » {added by developer 2} {added by developer 1} cyclic inheritance

17. 17 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»

18. 18 Current research E V O L U T I O N Better support for software merging Manage evolution of design patterns Assess need for evolution F O R M A L I S M S Graph rewriting Declarative reasoning Software metrics

19. 19 Manage Evolution of Design Patterns  Using declarative metaprogramming  symbiosis between declarative metalanguage (e.g. Prolog) and OO base language (e.g. Smalltalk)  allows declarative programs to reason about, or even generate, object-oriented code  can be used to  detect design patterns instances in the source code  specify design patterns (and their instances) declaratively  generate design patterns in the code  explore the use of different variants of a design pattern  manage evolution of design pattern instances  Example  Use declarative transformations to resolve merge conflicts between parallel evolutions of same design pattern instance

20. 20 Manage Evolution of Design Patterns  Example: Abstract Factory design pattern

21. 21 Manage Evolution of Design Patterns  Abstract Factory evolution 1: addConcreteFactory(LinuxLook)

22. 22 Manage Evolution of Design Patterns  Declarative transformation: rule addConcreteFactory(abstractFactory,?I,[?CF]) if addRole(?I,concreteFactory,?CF),  ?AP such that role(?I,abstractProduct,?AP): input(' Name of concrete ?AP created by concrete ?CF factory ',[?AP,?CF],?CP), addRole(?I,concreteProduct,[?CP,?AP]), addRole(?I,concreteRelation,[?CF,?CP]),  ?Method such that role(?I,abstractFactoryMethod,[?Method,_]): addRole(?I,concreteFactoryMethod,[?Method,?CF]) query addConcreteFactory(abstractFactory,AF,[LinuxLook]) User input: Name of concrete Window created by concrete LinuxLook factory: LinuxWindow Name of concrete Button created by concrete LinuxLook factory: LinuxButton

23. 23 Manage Evolution of Design Patterns  Abstract Factory evolution 2: addAbstractProduct(Menu)

24. 24 Manage Evolution of Design Patterns  When both Abstract Factory evolutions are performed manually by different developers, we get a merge conflict:  the Menu class does not contain a LinuxMenu subclass  the LinuxLook class does not contain a newMenu factory method  Solution:  specify the evolutions as explicit declarative design pattern transformations  apply these transformations sequentially

25. 25 Manage Evolution of Design Patterns  End result after having applied both transformations:

26. 26 Current research E V O L U T I O N Better support for software merging Manage evolution of design patterns Assess need for evolution F O R M A L I S M S Graph rewriting Declarative reasoning Software metrics

27. 27 Assess need for evolution  Use declarative metaprogramming and software metrics to  analyse need for software evolution (= before)  by identifying unstable parts, weak spots, bad design Example 1: automatically detect different uses of inheritance  interface/implementation inheritance  extension/cancellation inheritance  abstraction/concretisation inheritance detect “bad practices”  e.g. mixture of interface and implementation inheritance  heavy use of cancellation and abstraction inheritance Example 2: identify opportunities for refactoring  classes with common behaviour but no common superclass (and vice versa) => introduce (resp. remove) abstract superclass

28. 28 Software Metrics  Use graphs to provide a generic framework for (object- oriented) software metrics  automatically generate metrics suite for particular language  In collaboration with Michele Lanza, University of Berne Hierarchy Nesting Level Number of (public/instance/...) attributes of a class Number of (abstract/public/instance/...) methods in a class Number of invocations in a method Number of method lines/statements Number of (immediate/transitive) parents/children of a class Number of accessors of a given attribute Method/Attribute Inheritance Factor Method/Attribute Hiding Factor SyClMe At Ca St Li Co Ac Co In Ov,Ex In PathLength NodeCount EdgeCount Ratio Sum Average

29. 29 International Contacts  Co-founder, coordinator and secretary of FWO Wetenschappelijke OnderzoeksGemeenschap Fundamenten van Software-Evolutie  January 2001 - December 2005  4 Flemish research institutes: KUL, RUG, UA, VUB  5 European research institutes: Bern, Vienna, Munich, Paderborn, Lisboa  Co-organiser of Workshop on Formal Foundations of Software Evolution  Lisboa, March 2001, co-located with CSMR 2001  together with Prof. Michel Wermelinger, Universidade Nova de Lisboa  Co-organiser of Workshop on Object-Oriented Architectural Evolution  Budapest, June 2001, co-located with ECOOP 2001  together with Prof. Galal H. Galal, University of Middlesex London  Co-organiser of Workshop on Graph-Based Tools  October 2002, co-located with ICGT 2002  together with Andy Schurr and Gaby Taentzer