design recovery 1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Design Recovery 1 PowerPoint Presentation
Download Presentation
Design Recovery 1

Loading in 2 Seconds...

play fullscreen
1 / 47

Design Recovery 1 - PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Design Recovery 1' - lotte


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
design recovery 1

Design Recovery 1

Informatics 122

Alex Baker

what is design recovery
What is Design Recovery?
  • Sort of like reverse engineering
what is design recovery1
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)

what is design recovery2
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)

also like a double waterfall
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

why do we need to know this
Why do we need to know this?
  • Working with others’ code…
    • Debugging
    • Maintenance
    • Reuse
  • Working with your own code
motivation no design
Motivation: No design
  • Lost design
  • Build-and-fixed
  • Agile methodologies
  • Incomprehensible design
motivation design drift1
Motivation: Design Drift
  • Design not followed
motivation design drift2
Motivation: Design Drift
  • Design deviations
motivation design drift3
Motivation: Design Drift
  • Design deviations
motivation design drift4
Motivation: Design Drift
  • Design deviations

?

motivation design drift5
Motivation: Design Drift
  • Design deviations
motivation design drift6
Motivation: Design Drift
  • Design deviations

???

???

motivation design drift7
Motivation: Design Drift
  • Design deviations

???

???

motivation design drift8
Motivation: Design Drift
  • Design deviations

???

???

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

???

design recovery in our models
Design Recovery in our Models

Design Space

Outcome Space

Feasible

Desirable

Conceivable

design recovery product
Design Recovery (Product)

Design Space

Outcome Space

Feasible

Desirable

Conceivable

design recovery product1
Design Recovery (Product)

Design Space

Outcome Space

Feasible

Desirable

Conceivable

design recovery product2
Design Recovery (Product)

Design Space

Outcome Space

Feasible

Desirable

Conceivable

design recovery in our models1

activities

Design Recovery in Our Models

goals (languages)

knowledge (languages)

tools

ideas (languages)

representations (languages)

design recovery process
Design Recovery (Process)

if(condition)

functionCall(X);

else

functionCall(Y);

representations (languages)

activities

activities

representations (languages)

Ideas (languages)

Ideas (languages)

design recovery process1
Design Recovery (Process)

if(condition)

functionCall(X);

else

functionCall(Y);

representations (languages)

activities

activities

representations (languages)

Ideas (languages)

Ideas (languages)

design recovery process2
Design Recovery (Process)

if(condition)

functionCall(X);

else

functionCall(Y);

representations (languages)

activities

activities

representations (languages)

Ideas (languages)

Ideas (languages)

design recovery process3
Design Recovery (Process)

knowledge

if(condition)

functionCall(X);

else

functionCall(Y);

goals

representations (languages)

activities

activities

representations (languages)

Ideas (languages)

Ideas (languages)

design recovery process4

activities

Design Recovery (Process)

goals (languages)

knowledge (languages)

tools

ideas (languages)

representations (languages)

also remember
Also, remember
  • Design recovery recreates design abstractions from
    • Code
    • Existing design documentation (if available)
    • Personal experience
    • General knowledge about problem and application domains
isn t this reverse engineering
Isn’t this Reverse Engineering?
  • Not just recreating the UML diagram…
    • Program flows
    • Rationale
    • Metaphor
object orientation
Object Orientation
  • Something of an advantage
    • Class names, function names
    • Established relationships (inheritance, members, etc.)
  • Important details can be subtle
also like a double waterfall1
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

finding the structure not the same as the design
Finding the structure(not the same as the design)
  • Entities
    • Classes
    • Methods
    • Variables
  • Relationships
    • Inheritance
    • Member Objects
    • Method calls
approaches
Approaches
  • Reverse engineering tools
    • E.g. Omondo
  • Reading documentation
  • Code reading
  • Reading class names
  • Talking to people
but where s the design
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
an example jetris
An example: Jetris

http://jetris.sourceforge.net/

jetris design recovery
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
goals and knowledge
Goals and Knowledge
  • Of Tetris
  • Based on other artifacts (running program)
  • Of tendencies?
  • Patterns?
what will you actually create
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
the other side of the coin
The other side of the coin…
  • How easy is your program to understand?
  • How is your:
    • Documentation
    • Naming
    • Code
assignment 3 design recovery
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/

assignment 3 design recovery1
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
suggestions for group work
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
further tips
Further tips
  • Use representations of classes to organize
  • Rote completeness is not the answer, will need to be elegant
team assignments
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