David Evans cs.virginia/evans

1. Lecture 8: Designing for Indestructability David Evans http://www.cs.virginia.edu/evans CS201j: Engineering Software University of Virginia Computer Science

2. Menu • Design • Why it matters? • What makes a good design? • Modular Dependency Diagrams • Documenting Designs • How to Design Systems • How to Design Programs CS 201J Fall 2003

3. Announcements • Schedule changes (including Exam 1) on notes today • Bring today’s notes to section tomorrow • Read through the problem before section • PS4 out tomorrow • You will be assigned into teams of 3 • If you turned in a PS3 CS 201J Fall 2003

4. 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) CS 201J Fall 2003

5. 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 CS 201J Fall 2003

6. The Browser Wars • 1996: • Netscape Navigator: 73% • Microsoft IE: ~20% • August 2002: • Microsoft IE: 96% • Netscape: ~1% CS 201J Fall 2003

7. 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 developers, 3M lines of code Based on Daniel Jackson’s Notes CS 201J Fall 2003

8. 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 CS 201J Fall 2003

9. 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 CS 201J Fall 2003

10. 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 CS 201J Fall 2003

11. 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 CS 201J Fall 2003

12. How should we describe designs? CS 201J Fall 2003

13. 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? CS 201J Fall 2003

14. 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? CS 201J Fall 2003

15. MDD Notation Module Usually a Java class StringTable CS 201J Fall 2003

16. MDD Notation Module Usually a Java class StringTable depends on the specification of TableEntry CS 201J Fall 2003

17. Code  MDD • If A calls a method of B, then A depends on the specification of B • If the specification of B changes, we need to reconsider A • If A mentions the class B, but doesn’t call any methods or access fields, then A weakly depends on B • If the specification of B changes, we don’t need to reconsider A. A B A B CS 201J Fall 2003

18. PS2 Module Dependencies NameTrends StringTable StringIterator If the specification of StringTable changes, do we have to reconsider NameTrends? TableEntry Yes, dependencies reveal dependencies. CS 201J Fall 2003

19. PS2 Module Dependencies NameTrends StringTable StringIterator If the specification of TableEntry changes, do we have to reconsider NameTrends? TableEntry No, we only have to consider StringTable. CS 201J Fall 2003

20. PS2 Module Dependencies NameTrends StringTable StringIterator If the implementation of StringIterator changes, what classes must be reconsidered? TableEntry None! Trick question – if specification contract is followed, we only care when spec changes. CS 201J Fall 2003

21. GridDisplay Cell PS1 Module Dependency Diagram CellAutomata is a subtype of (extends) Grid ConwayLifeCell CellState What’s bad about this design? CS 201J Fall 2003

22. Cell Evaluating Designs Circular Dependency: Grid depends on Cell Cell depends on Grid Grid CS 201J Fall 2003

23. 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 (worth 100 bonus points!) CS 201J Fall 2003

24. Evaluating Designs • Conflicting demands: Dependencies are bad, but reuse is good NameTrends StringTable StringIterator CS 201J Fall 2003

25. 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) CS 201J Fall 2003

26. 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 CS 201J Fall 2003

27. Charge • PS4: Out Tomorrow • I will assign you into teams of 3 • Only people who turned in PS3 will be assigned to teams – if you didn’t turn in PS3 today, but are in the class you need to let me know CS 201J Fall 2003