Reverse Engineering and Design Recovery

1. Reverse Engineering and Design Recovery Informatics 122 Alex Baker

2. Definitions • Reverse Engineering: Analyzing a system to: • Identify its components and their relationships • Create representations in another form • Usually refers to redocumentation • Design Recovery • A subset of reverse engineering • A higher level understanding (Chikofsky and Cross, 1990)

3. Also like a double-waterfall… • General model for recovery (Byrne, 1992) Alteration Reverse Engineering Abstraction Con- ceptual re-think Con- ceptual Forward Engineering Refinement re-specify Requirements Requirements re-design Design Design re-build Implementation Implementation Existing System Target System

4. What is the Design? • The basics • Beast and Superbeast classes • AI classes • Data structure • Engine structure

5. What is the Design? We want a game based on Beast We want it to be expandable We must be able to add more monsters To enact this we want to use interfaces A lot of this is enacted through pushable Pushable is used by the engine to…

6. What if we want to… Change the double-beast-push behavior Add a new monster type Let the player climb on top of blocks Simplify the design

7. What is the Design? • The basics • Beast and Superbeast classes • AI classes • Data structure • Engine structure

8. What is the Design? We want a game based on Beast We want it to be expandable We must be able to add more monsters To enact this we want to use interfaces A lot of this is enacted through pushable Pushable is used by the engine to…

9. What do we use? • Reverse engineering recreates design abstractions from • Code • Existing design documentation (if available) • Personal experience / general knowledge about problem and application domains • Talking to people (Biggerstaff, 1989)

10. What do we Create? • Recovered abstractions need: • Formal specifications • Module breakdowns • Data abstractions • Dataflows • Informal knowledge • All information required to understand • What • How • Why (Biggerstaff, 1989)

11. Why do we have to do this?

12. Why do we have to do this? • Working with others’ code… • Debugging • Maintenance • Modification • Reuse • Working with your own code • You will work with code in the absence of a design

13. Motivation: No design • Lost design • Build-and-fixed • Agile methodologies • Incomprehensible design

14. Motivation: Design Drift

15. Motivation: Design Drift • Design not followed

16. Motivation: Design Drift • Design deviations

17. Motivation: Design Drift • Design deviations

18. Motivation: Design Drift • Design deviations ?

19. Motivation: Design Drift • Design deviations

20. Motivation: Design Drift • Design deviations ??? ???

21. Motivation: Design Drift • Design deviations ??? ???

22. Motivation: Design Drift • Design deviations ??? ???

23. Motivation: Design Drift • Design deviations ??? ???

24. Motivation: Design Drift • You’re often recovering, in some sense

25. Deviations happen Sometimes you’re formally making a spec Sometimes you’re just trying to figure out what the heck someone was thinking…

26. What are the Goals of RE Cope with complexity Generate alternate views Recover lost information Detect side effects Synthesize higher abstractions Facilitate Reuse (Chikofsky and Cross, 1990)

27. What are the Goals of RE Redocumentation Design Recovery Cope with complexity Generate alternate views Recover lost information Detect side effects Synthesize higher abstractions Facilitate Reuse

28. All this code What does it mean?

29. So lets start with the basics • Recreating the structure (redocumentation) Alteration Reverse Engineering Abstraction Con- ceptual re-think Con- ceptual Forward Engineering Refinement re-specify Requirements Requirements re-design Design Design re-build Implementation Implementation Existing System Target System

30. Object Orientation • Something of an advantage • Class names, function names • Established relationships (inheritance, members, etc.) • Cohesion

31. The Ideal Program (again) vs. …

32. Finding the structure • Entities • Classes • Methods • Variables • Relationships • Inheritance • Member Objects • Method calls

33. Approaches • Reverse engineering tools • E.g. Omondo • Reading documentation • Reading class names • Code reading • Talking to people

34. Also, remember • Existing artifacts, but also • Personal experience • General knowledge about problem • General knowledge about solution

35. In terms of our process model knowledge knowledge goals goals them you representations (languages) Ideas (languages) Ideas (languages) if(condition) functionCall(X); else functionCall(Y);

36. An example: Jetris http://jetris.sourceforge.net/

37. Reverse Engineering Jetris • Multiple “passes” • Run the game • Reading names • What is HTMLLink? PublishHiScore? • What is Figures.java? FigureFactory? • TetrisGrid (wait, what’s with those arrays?) • AddFigure, dropNext, addFigureToGrid… • Actual loop? (nextMove) • UI

38. Goals and Knowledge • Of Tetris • Based on other artifacts (running program) • Of tendencies? • Patterns?

39. Lets get philosophical again!

40. Design Recovery in our Models Design Space Outcome Space Feasible Desirable Conceivable

41. Design Recovery (Product) Design Space Outcome Space Feasible Desirable Conceivable

42. Design Recovery (Product) Design Space Outcome Space Feasible Desirable Conceivable

43. Design Recovery (Product) Design Space Outcome Space Feasible Desirable Conceivable

44. Not Just the UML What principles were applied? What were their priorities? What patterns emerged? What actual patterns were used? What would developers making changes need to consider? • This will save you a lot of trouble

45. Another (Small) Example addAllPixels(Image image){ for(int i = 0; i < image.getWidth(); i++){ for(int j = 0; j < image.getHeight(); j++){ Color c = image.getColor(i, j); addPixel(new Pixel(i, j, c)); addToColumn(i, new Pixel(i, j, c)); updateColorTotals(c); }}}

46. We might be able to guess that: • Need for a pixel class • Different instances for • addPixel • addToColumn • Concerned about speed • Not so much about space • Concerned about changability? • Or just following convention

47. Could have just been addAllValues(ImageNumber n){ for(int i = 0; i < image.height; i++){ for(int j = 0; j < image.height; j++){ colorArray[n][i][j] = image.colorAt(i, j); }}}

48. The other side of the coin… • How easy is your program to understand? • The dual nature of code • How is your: • Documentation • Naming • Code • Metaphor • Principles

49. Finally: What’s Actually Created? • It depends: • How difficult? • Who else? • The future… • Getting philosophical one last time

50. Design Recovery (Process) if(condition) functionCall(X); else functionCall(Y); representations (languages) activities activities Ideas (languages) Ideas (languages)