Transcript Slides

Lecture 8:
Designing for
Indestructability
CS201j: Engineering Software
University of Virginia
Computer Science
David Evans
http://www.cs.virginia.edu/~evans
Menu
• Design
– Why it matters?
– What makes a good design?
• Modular Dependency Diagrams
– Documenting Designs
• How to Design Systems
– How to Design Programs
24 September 2002
CS 201J Fall 2002
2
Why Does
Design Matter?
"How is a taste in this beautiful art to be formed in our countrymen,
unless we avail ourselves of every occasion when public buildings are
to be erected, of presenting to them models for their study and
imitation?...You see, I am an enthusiast on the subject of the arts. But
it is an enthusiasm of which I am not ashamed, as its object is to
improve the taste of my countrymen, to increase their reputation, to
reconcile them to the rest of the world, and procure them its praise."
Thomas Jefferson (letter to James Madison, 1785)
24 September 2002
CS 201J Fall 2002
3
Software Design Matters
• Cost/Time to Implement
– Some of you learned this the hard way for PS3!
• Independence of Modules
– Decoupled modules can be developed and
tested independently
• Ability to Change
– Requirements for software change, poorly
designed software is hard/impossible to change
24 September 2002
CS 201J Fall 2002
4
The Browser Wars
• 1996:
– Netscape Navigator: 73%
– Microsoft IE: ~20%
• August 2002:
– Microsoft IE: 96%
– Netscape: ~1%
24 September 2002
CS 201J Fall 2002
5
Browser History
• NCSA Mosaic (first widely used browser) –
no design, quick and dirty implementation
• Dec 1994: developed into Netscape
Navigator, V 1.0 (100K lines of code)
• Oct 1994: Microsoft starts developing IE
• 1995-1997: both browsers grew
uncontrollably
– Communicator 4.0: 120 developer, 3M lines of
code
Based on Daniel Jackson’s Notes
24 September 2002
CS 201J Fall 2002
6
Microsoft Componentizes
• IE 3.0: Microsoft does complete
restructuring (Jan-Aug 96)
• Designed around clear modules
• Team of 3-4 people designed component
architecture
– Modules: URL (high-level services), low-level
services, MSHTML (HTML rendering), shell
document, security services, etc.
– Easy to customize browser by replacing
components
24 September 2002
CS 201J Fall 2002
7
What went wrong for Netscape?
• 1997: Communicator is impossible to
develop
– Without clear interfaces and modules, can’t
divide work
– All 120 developers had to work together
“Most of the code is self-contained spaghetti…The core
functionality works, but it’s the little squeaks everywhere
that break.”
Aleks Totic, Netscape, July 1997
“We’re in a really bad situation with our current code base…we’re
paying the price for going fast. And when you go fast, you don’t
architect...”
Michael Toy, Netscape, July 1997
24 September 2002
CS 201J Fall 2002
8
Netscape’s Downfall
• Netscape tries for 2 months to re-architect
browser, but failed
• Tried starting from scratch for
Communicator 6.0 (never completed)
• Eventually, give up and release it as open
source Mozilla
– Nobody can understand the code, so no one
develops anything interesting for it
Based on Daniel Jackson’s Notes
24 September 2002
CS 201J Fall 2002
9
Microsoft v. Netscape
• Microsoft knew design mattered
– Designed IE 3.0 around clear modules
– Easy to add new features, fix problems
– Won AOL deal because they could customize
appearance of browser
• Netscape grew a quick-and-dirty
implementation without clear modules and
interfaces until it was impossible to develop
• Netscape sold to AOL, IE is the only
browser that matters today
24 September 2002
CS 201J Fall 2002
10
How should we describe designs?
24 September 2002
CS 201J Fall 2002
11
Modular Dependency Diagrams
• Show the component modules
– How is the program organized?
• Show the dependencies between them
– How do modules depend on each other?
• Why do we want to know?
24 September 2002
CS 201J Fall 2002
12
Using MDDs
• Design Time
– Consider different designs
– If the MDD has lots of cycles, crossings, etc. the
design is not decoupled enough
• Implementation
– Organize the implementation
• Testing
– Where do you look when a test fails?
• Maintenance
– What modules must be considered when specification
of one changes?
24 September 2002
CS 201J Fall 2002
13
MDD Notation
StringTable
24 September 2002
Module
Usually a Java class
CS 201J Fall 2002
14
MDD Notation
StringTable
Module
Usually a Java class
depends on the specification of
TableEntry
24 September 2002
CS 201J Fall 2002
15
Code  MDD
A
• If A calls a method of B, then A
depends on the specification of B
B
– If the specification of B changes, we need
to reconsider A
A
• If A mentions the class B, but doesn’t
call any methods or access fields, then
A weakly depends on B
B
– If the specification of B changes, we don’t
need to reconsider A.
24 September 2002
CS 201J Fall 2002
16
PS2 Module Dependencies
NameTrends
StringTable
StringIterator
TableEntry
If the specification of StringTable changes,
do we have to reconsider NameTrends?
Yes, dependencies reveal dependencies.
24 September 2002
CS 201J Fall 2002
17
PS2 Module Dependencies
NameTrends
StringTable
StringIterator
TableEntry
If the specification of TableEntry changes,
do we have to reconsider NameTrends?
No, we only have to consider StringTable.
24 September 2002
CS 201J Fall 2002
18
PS2 Module Dependencies
NameTrends
StringTable
StringIterator
TableEntry
24 September 2002
If the implementation of StringIterator changes,
what classes must be reconsidered?
None! Trick question – if specification contract
is followed, we only care when spec changes.
CS 201J Fall 2002
19
PS1 Module Dependency Diagram
CellAutomata
GridDisplay
Grid
Cell
CellState
is a subtype of
(extends)
ConwayLifeCell
What’s bad about this design?
24 September 2002
CS 201J Fall 2002
20
Evaluating Designs
Cell
Grid
24 September 2002
Circular Dependency:
Grid depends on Cell
Cell depends on Grid
CS 201J Fall 2002
21
Why are circular dependencies bad?
• Need to finish both modules before you can
test them (can use stub versions for testing)
• If a test fails, may be hard to figure out which
module is at fault
• If spec of one changes, need to reconsider
other module, but what if its spec changes
as a result?
• But…sometimes unavoidable
– Challenge: come up with a better design for PS1
(with 100 bonus points!)
24 September 2002
CS 201J Fall 2002
22
Evaluating Designs
• Conflicting demands:
Dependencies are bad, but reuse is good
NameTrends
StringTable
StringIterator
24 September 2002
CS 201J Fall 2002
23
Evaluating Designs
• Too many modules: lots of dependencies,
overall design too complex to understand
• Too few modules: hard to divide, each
module may be too big to implement
• Guideline: humans can only understand
about 7 things at once – if you have more
than 7 modules, make the modules bigger
(could then subdivide them)
24 September 2002
CS 201J Fall 2002
24
Evaluating Designs
• No absolute rules
• Important thing is that you can justify your
design by explaining why it is better than
alternatives
• A good design will make implementation
(relatively) easy, a bad design will make
implementation impossible
24 September 2002
CS 201J Fall 2002
25
Charge
• PS4: Design Document
– Due Thursday
• Wednesday, 8pm: AC’s will hold recitation
on useful programming techniques
– Not intended to help with design for PS4
– But, will be helpful for coding for PS4 and
beyond…
24 September 2002
CS 201J Fall 2002
26