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) Existing SystemTarget System Implementation Design Requirements Con- ceptual Con- ceptual Design Implementation re-think re-specify re-design re-build Alteration Reverse Engineering Abstraction Forward Engineering Refinement

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. 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 Feasible Desirable Conceivable Outcome Space Design Space

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

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

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

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

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

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

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

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

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

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) Existing SystemTarget System Implementation Design Requirements Con- ceptual Con- ceptual Design Implementation re-think re-specify re-design re-build Alteration Reverse Engineering Abstraction Forward Engineering Refinement

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. 29 th, 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