Design Recovery 1

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
Con- ceptual
Con- ceptual
re-think
Reverse Engineering Abstraction
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

• Youre 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
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
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
Isnt 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
Con- ceptual
Con- ceptual
re-think
Reverse Engineering Abstraction
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 wheres 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, whats 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

• 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