1. Object-Oriented Reengineering Oscar Nierstrasz Software Composition Group University of Bern

2. Slide 2 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Roadmap 1. Legacy OO systems What are they? Why do they exist? Why should we care? 2. The Reengineering lifecycle

3. Slide 3 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. What is a Legacy System? legacy A sum of money, or a specified article, given to another by will; anything handed down by an ancestor or predecessor. — OED A legacy system is a piece of software that: you have inherited, and is valuable to you.

4. Slide 4 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Lehman’s Laws A classic study by Lehman and Belady (1985) identified several “laws” of system change. Continuing change A program that is used in a real-world environment must change, or become progressively less useful in that environment. Increasing complexity As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure.

5. Slide 5 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. OO Legacy Object-oriented legacy systems: = successful OO systems whose architecture and design no longer respond to changing requirements Compared to traditional legacy systems: The symptoms and the source of the problems are the same The technical details and solutions may differ

6. Slide 6 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Problems with Legacy Systems Typical problems are: original developers no longer available outdated development methods used extensive patches and modifications have been made missing or outdated documentation so, further evolution and development may be prohibitively expensive

7. Slide 7 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Architectural Drift With time, all legacy systems tend to drift from their original design. Insufficient documentation most legacy systems suffer from inexistent or inconsistent documentation Duplicated functionality “cut, paste and edit” is quick and easy, but leads to maintenance nightmares Lack of modularity strong coupling between modules hampers evolution Improper layering missing or improper layering hampers portability and adaptability

8. Slide 8 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Design Drift Legacy systems suffer from both high-level architectural and low-level design drift. Misuse of inheritance aggregation, code reuse... Missing inheritance duplicated code... Misplaced operations high coupling, low cohesion... Violation of encapsulation public instance variables, friends, global variables...

9. Slide 9 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Roadmap 1. Legacy OO systems 2. The Reengineering lifecycle Patterns, tools and techniques

10. Slide 10 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. The Reengineering Lifecycle Requirements Designs Code (0) requirement analysis (1) model capture (2) problem detection (3) problem resolution (4) program transformation

11. Slide 11 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Reverse and Reengineering Patterns Reverse engineering patterns encode expertise and trade-offs in extracting design from source code, running systems and people. –Even if design documents exist, they are typically out of sync with reality. Reengineering patterns encode expertise and trade- offs in transforming legacy code to resolve problems that have emerged. –These problems are typically not apparent in original design but are due to architectural drift as requirements evolve

12. Slide 12 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Setting Direction Agree on Maxims Appoint a Navigator Speak to the Round Table Most Valuable First Fix Problems, Not Symptoms If It Ain't Broke Don't Fix It Keep it Simple Set direction Maintain direction Coordinate direction Where to start What not to do What to do How to do it Principles & Guidelines for Software project management especially relevant for reengineering projects

13. Slide 13 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. First Contact System experts Chat with the Maintainers Interview during Demo Talk with developers Talk with end users Software System Read All the Code in One Hour Do a Mock Installation Read itCompile it Skim the Documentation Talk about it Verify what you hear feasibility assessment (one week time) Read about it

14. Slide 14 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Initial Understanding Top down Speculate about Design Recover design Analyze the Persistent Data Study the Exceptional Entities Read it Compile it understand  higher-level model Bottom up

15. Slide 15 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. CodeCrawler: Visualizing Metrics

16. Slide 16 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Detailed Model Capture Tie Code and Questions Refactor to Understand Keep track of your understanding Expose design Expose the design & make sure it remains exposed Step through the Execution Look for the Contracts Learn from the Past Use Your Tools Look for Key Methods Look for Constructor Calls Look for Template/Hook Methods Look for Super Calls Expose collaborations Expose contracts Expose evolution Write Tests to Understand

17. Slide 17 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Tests: Your Life Insurance Write Tests to Enable Evolution Grow Your Test Base Incrementally Managing tests Use a Testing Framework Test the Interface, Not the Implementation Record Business Rules as Tests Designing tests Write Tests to Understand Test Fuzzy features Test Old Bugs Retest Persistent Problems Regression Test after Every Change Migration Strategies

18. Slide 18 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Migration Migrate Systems Incrementally Conserve Familiarity How Use Profiler before Optimizing Build Confidence Involve the Users How Why Prototype the Target Solution Always Have a Running Version Regression Test after Every Change Present the Right Interface Distinguish Public from Published Interfaces Deprecate Obsolete Interfaces Make a Bridge to the New Town How Tests, your Life-Insurance Where to

19. Slide 19 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Detecting Duplicated Code Compare Code Mechanically Visualize Code as Dotplots Redistribute Responsibilities Transform Conditionals to Polymorphism Detect Understand

20. Slide 20 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Duploc: Detecting Duplicated Code Compare, visualize and navigate multiple source files

21. Slide 21 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Dotplot Visualization Sample Dot Configurations:

22. Slide 22 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Redistribute Responsibilities Eliminate Navigation Code Data containers Monster client of data containers Split Up God Class Move Behaviour Close to Data Chains of data containers

23. Slide 23 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Transform Conditionals to Polymorphism Transform Self Type Checks Test provider type Test self type Test external attribute Transform Client Type Checks Transform Conditionals into Registration Test null values Introduce Null Object Factor Out Strategy Factor Out State Test object state

24. Slide 24 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Conclusion Yes, there are object-oriented legacy systems too! –… actually, that's a sign of health Reverse engineering and reengineering are essential activities in the lifecycle of any successful software system. –… consequently, do not consider it second class work There is a large set of lightweight tools and techniques to help you with reengineering. –… check our book, but remember the list is growing Nevertheless, people must do the job! –… so pick them carefully and reward them appropriately!

25. Slide 25 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. The end For more information, please visit: www.iam.unibe.ch/~scg/ Buy the book!

26. Slide 26 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz.

27. Slide 27 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Roadmap 1. Legacy OO systems 2. The Reengineering lifecycle 3. Odds and ends

28. Slide 28 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. FAMOOS Case Studies Goal: Reengineering object-oriented legacy systems towards component frameworks. Emphasis: Lightweight tools and techniques applied to industrial case studies. DomainLOCReengineering Goal pipeline planning55,000extract design user interface60,000increase flexibility embedded switching180,000improve modularity mail sorting350,000portability and scalability network management2,000,000unbundle application space mission2,500,000identify components

29. Slide 29 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Moose A language-independent reengineering platform based on FAMIX repository –querying –metrics computation –navigational operators built-in language parsers (Smalltalk,...) CDIF and XMI file exchange –external parsers and tools

30. Slide 30 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. FAMIX A simple, UML-like meta-model designed for reengineering operations and information exchange –language-independent meta-model models source code, not designs explicit language mappings for C++, Java, Ada (Smalltalk in the works...) –models method invocations and variables accesses for dependency analysis reverse engineering refactoring –interchange for reengineering tools CDIF and XMI

31. Slide 31 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. FAMIX Core Model The full model also includes Functions, Formal Parameters... Additional information is stored for every entity (the name of a Class, the visibility of a Method,...)

32. Slide 32 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Duploc: Visualizing Software Evolution

33. Slide 33 of 25Software Composition Group University of Berne (Switzerland) 2002 © Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz. Interactive Visualization Anomalous software entities are usually the “interesting” ones.