1 / 47

Design Recovery 1

Design Recovery 1. Informatics 122 Alex Baker. What is Design Recovery?. Sort of like reverse engineering. What is Design Recovery?. Design recovery recreates design abstractions from Code Existing design documentation (if available)

lotte
Download Presentation

Design Recovery 1

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. Design Recovery 1 Informatics 122 Alex Baker

  2. What is Design Recovery? • Sort of like reverse engineering

  3. What is Design Recovery? • Design recovery recreates design abstractions from • Code • Existing design documentation (if available) • Personal experience / general knowledge about problem and application domains • Talking to people (Biggerstaff, 1989)

  4. What is Design Recovery? • Recovered abstractions need: • Formal specifications • Module breakdowns • Data abstractions • Dataflows • Informal knowledge • All information required to understand • What • How • Why (Biggerstaff, 1989)

  5. 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

  6. Why do we need to know this? • Working with others’ code… • Debugging • Maintenance • Reuse • Working with your own code

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

  8. Motivation: Design Drift

  9. Motivation: Design Drift • Design not followed

  10. Motivation: Design Drift • Design deviations

  11. Motivation: Design Drift • Design deviations

  12. Motivation: Design Drift • Design deviations ?

  13. Motivation: Design Drift • Design deviations

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

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

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

  17. Motivation: Design Drift ???

  18. Motivation: Design Drift ???

  19. Could even be your own code • You’re often recovering, in some sense ???

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

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

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

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

  24. activities Design Recovery in Our Models goals (languages) knowledge (languages) tools ideas (languages) representations (languages)

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

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

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

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

  29. activities Design Recovery (Process) goals (languages) knowledge (languages) tools ideas (languages) representations (languages)

  30. Also, remember • Design recovery recreates design abstractions from • Code • Existing design documentation (if available) • Personal experience • General knowledge about problem and application domains

  31. Isn’t this Reverse Engineering? • Not just recreating the UML diagram… • Program flows • Rationale • Metaphor

  32. Object Orientation • Something of an advantage • Class names, function names • Established relationships (inheritance, members, etc.) • Important details can be subtle

  33. The Ideal Program (again!) vs. …

  34. 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

  35. Finding the structure(not the same as the design) • Entities • Classes • Methods • Variables • Relationships • Inheritance • Member Objects • Method calls

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

  37. But where’s the design? 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

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

  39. Jetris Design Recovery • Run the game • Reading names • What is HTMLLink? • What is Figures.java? FigureFactory? • TetrisGrid (wait, what’s with those arrays?) • AddFigure, dropNext, addFigureToGrid… • Actual loop? (nextMove) • UI

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

  41. What will you actually create? • It depends: • How difficult? • Who else? • The future… • We could make • UML • UI map • Program flow • Depiction of array metaphors • …

  42. The other side of the coin… • How easy is your program to understand? • How is your: • Documentation • Naming • Code

  43. Assignment 3 – Design Recovery • Recover the design of VBoard • Sketching program developed for software engineering research • You may use any tools you like • Get the VBoard code from the subversion repository, detailed instructions are here: http://vboard.bhnet.us/download/VBoard/

  44. Assignment 3 – Design Recovery • Each group must turn in: • A Complete UML (-ish) Diagram • At least 1 additional diagram of your choice (might be informal) • A document describing the design of VBoard (at least 4 pages) • Your audience is someone unfamiliar with VBoard who needs to make very significant changes to it • Graded on completeness, clarity, accuracy • Each person also needs to submit a team evaluation (forms available on class webpage) • Paper copy due Tuesday, Oct. 29th, at start of class

  45. Suggestions for Group Work • Everyone start by taking their own look at the whole system • Multiple perspectives will be very useful • Work out the high level architecture • Understand program flows • Look out for subtle details

  46. Further tips • Use representations of classes to organize • Rote completeness is not the answer, will need to be elegant

  47. Team Assignments Team 1 • BAMBAEEROW, CAMERON • DAUZ, JONATHAN • JONAS, NICHOLAS • LAVAVESHKUL, MICHAEL • SHI, LINDA Team 2 • DEMPSEY, MITCHELL • KOLLA, SUBODH • LAM, CYNTHIA • LEE, RICK • STEWART, DAVID Team 3 • BEDFORD, AURORA • CHIU, ARTHUR • DYKZEUL, BRADLEY • IGNACIO, JAN • YEGANYAN, MICHAEL Team 4 • BAUTISTA, JEREMIAH • BOSCH, CHRISTOPHER • ESQUENAZI, NATHAN • PURPURA, DAVID Team 5 • CHISLOM, ALTON • HIRANO, SEN • KWOK, MATHEW • SAM, VINH Team 6 • HUANG, ALLEN • KNOBEL, JACOB • LIU, ZHE • SHAFER, THOMAS

More Related