1 / 70

Reverse Engineering and Design Recovery

Reverse Engineering and Design Recovery. Informatics 122 Alex Baker. Definitions. Reverse Engineering: Analyzing a system to: Identify its components and their relationships Create representations in another form Usually refers to redocumentation Design Recovery

gigi
Download Presentation

Reverse Engineering and Design Recovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

More Related