design recovery 1 informatics 122 alex baker. what is design recovery? sort of like reverse...

47
Design Recovery 1 Informatics 122 Alex Baker

Post on 21-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

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) Personal experience / general knowledge

about problem and application domains

Talking to people

(Biggerstaff, 1989)

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…

General model for recovery (Byrne, 1992)

Existing System Target System

Implementation

Design

Requirements Requirements

Con-ceptual

Con-ceptual

Design

Implementation

re-think

re-specify

re-design

re-build

Alteration

ReverseEngineeringAbstraction

ForwardEngineeringRefinement

Why do we need to know this? Working with others’ code…

Debugging

Maintenance

Reuse

Working with your own code

Motivation: No design

Lost design Build-and-fixed Agile methodologies

Incomprehensible design

Motivation: Design Drift

Motivation: Design Drift

Design not followed

Motivation: Design Drift

Design deviations

Motivation: Design Drift

Design deviations

Motivation: Design Drift

Design deviations

?

Motivation: Design Drift

Design deviations

???

Motivation: Design Drift

Design deviations

???

???

Motivation: Design Drift

Design deviations

???

???

Motivation: Design Drift

Design deviations

???

Motivation: Design Drift

???

Motivation: Design Drift

???

Could even be your own code

You’re often recovering, in some sense

???

Design Recovery in our Models

Feasible Desirable

Conceivable

Outcome Space

Design Space

Design Recovery (Product)

Feasible Desirable

Conceivable

Outcome Space

Design Space

Design Recovery (Product)

Feasible Desirable

Conceivable

Outcome Space

Design Space

Design Recovery (Product)

Feasible Desirable

Conceivable

Outcome Space

Design Space

Design Recovery in Our Models

activities

goals (languages) knowledge (languages)

ideas (languages) representations (languages)

tools

Design Recovery (Process)

activities

Ideas (languages) representations (languages)

activities

Ideas (languages)

representations (languages)

if(condition) functionCall(X);else functionCall(Y);

Design Recovery (Process)

activities

Ideas (languages) representations (languages)

activities

Ideas (languages)

representations (languages)

if(condition) functionCall(X);else functionCall(Y);

Design Recovery (Process)

activities

Ideas (languages) representations (languages)

activities

Ideas (languages)

representations (languages)

if(condition) functionCall(X);else functionCall(Y);

Design Recovery (Process)

activities

Ideas (languages) representations (languages)

activities

Ideas (languages)

representations (languages)

if(condition) functionCall(X);else functionCall(Y);

goals

knowledge

Design Recovery (Process)

activities

goals (languages) knowledge (languages)

ideas (languages) representations (languages)

tools

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?

Not just recreating the UML diagram… Program flows Rationale Metaphor

Object Orientation

Something of an advantageClass names, function namesEstablished relationships (inheritance,

members, etc.)

Important details can be subtle

The Ideal Program (again!)

vs.

Also like a double-waterfall…

General model for recovery (Byrne, 1992)

Existing System Target System

Implementation

Design

Requirements Requirements

Con-ceptual

Con-ceptual

Design

Implementation

re-think

re-specify

re-design

re-build

Alteration

ReverseEngineeringAbstraction

ForwardEngineeringRefinement

Finding the structure(not the same as the design) Entities

Classes Methods Variables

Relationships Inheritance Member Objects Method calls

Approaches

Reverse engineering toolsE.g. Omondo

Reading documentation Code reading Reading class names Talking to people

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

http://jetris.sourceforge.net/

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

Of Tetris

Based on other artifacts (running program)

Of tendencies?

Patterns?

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…

How easy is your program to understand?

How is your: Documentation Naming Code

Assignment 3 – Design Recovery

Recover the design of VBoardSketching program developed for software

engineering researchYou 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 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

Everyone start by taking their own look at the whole systemMultiple perspectives will be very useful

Work out the high level architecture Understand program flows Look out for subtle details

Further tips

Use representations of classes to organize

Rote completeness is not the answer, will need to be elegant

Team AssignmentsTeam 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