Software Engineering Oct-01 #12: Design Phil Gross

2 Administrivia Due date for Design? – Tue or Thurs? – Two extra days for design, or implementation? ACM talk on C++ for Java Programmers – Thursday 6-8pm – Location TBD

3 Requirements Tweaking Posted to webboard Some things had accidently been dropped Attacked is back, so is SendMap Deltas start immediately, Go is when youre ready to play

4 A Note on Iterations It would be better if we had a few A living demonstration on why straight-through plans are bad

5 A Note on Good Design Adjustments are easy Result of good design Or using a well-designed frameworks Frameworks are just about the hardest thing to architect

6 A Note on Optimization Knuths laws of Optimization First Law: Dont! Second Law (for experts only): Not Yet! Try to get the thing working before you do any optimization

7 Case Study: Denver Airport Approved in 1989, with intended opening in 1993 Mind-bogglingly huge: 53 square miles Budgeted for $2.5 billion Fully automated baggage handling system

8 Denver Airport Baggage System budgeted at $193 million Approx 20 miles of track Barcoded luggage scanned by lasers 4000 telecars carry it to destination Tracked by photocells Run by 300 computers

9 Timeline: Mayors Humiliation March 2, 1993 – Denver Mayor Wellington Webb announces the first airport opening delay. The October 31, 1993 opening date is changed to December 19, 1993 to allow for a seven week debugging of hundreds of systems. October 25, 1993 – Mayor Webb announces the second airport opening delay. The December 19, 1993 opening date is changed to March 9, 1994 to accommodate changes made by the airlines, allow more time to test critical airport systems, train airline ticket agents and other workers, and complete installation of fire and security systems. March 1, 1994 – Mayor Webb announces the third airport opening delay. The March 9, 1994 opening date is changed to May 15, 1994 to accommodate problems of troubleshooting the airport's complex baggage system. Mayor Webb further asserts that the airport will open on May 15th "come hell or high water." May 2, 1994 – Mayor Webb announces the fourth airport opening delay. The May 15, 1994 opening date is delayed indefinitely to resolve more problems encountered while testing the baggage system.

10 Timeline Part II June 20, 1994 – The Webb administration announces that four steps are required in completion before a new opening date will be announced. BAE must submit a master schedule. Logplan and the city must evaluate the BAE master schedule and conduct several tests to see how realistic it is. Denver must consult with the airlines on their recommendations. The BAE's baggage system must operate for an unspecified period of time at an acceptable level. August 4, 1994 – Mayor Webb announces that the city will spend an extra $50 million to build a conventional airport-wide luggage system using traditional tugs and carts. August 22, 1994 – Webb announces that Denver International Airport will open on February 28, 1995.

11 Timeline Part III September 7, 1994 – Denver and BAE sign an agreement that allows BAE to work directly with United Airlines to simplify the baggage system so it can be ready for a February opening. September 21, 1994 – Denver and BAE begin mediation over who is to blame for the cost overruns and problems with the baggage system. February 28, 1995 – Concourse A's opening is postponed indefinitely, owing to litigation between Denver and Continental Airlines, which has cancelled its lease of 30 gates, and its operation of using Denver as a major hub. Concourse C, carrying 12 airlines, opens with a traditional tug and cart baggage system. Concourse B, housing all of United's gates, opens using the BAE automated baggage handling system only on outbound, Denver-originated flights.

12 Why? GAO Says… The baggage system continued to unload bags even though they were jammed on the conveyor belt. This problem occurred because the photo eye at this location could not detect the pile of bags on the belt and hence could not signal the system to stop. The baggage system loaded bags into telecarts that were already full. Hence, some bags fell onto the tracks, again causing the telecarts to jam. This problem occurred because the system had lost track of which telecarts were loaded or unloaded during a previous jam. When the system came back on-line, it failed to show that the telecarts were loaded.

13 And More… The timing between the conveyor belts and the moving telecarts was not properly synchronized, causing bags to fall between the conveyor belt and the telecarts. The bags became wedged under the telecarts. This occurred because telecarts were bumping into each other near the load point. An observer reports: Videos of the failing system under test are great fun to watch. Bags being flung at carts that aren't where they're supposed to be, carts flying off tracks, bags flying through the air smashing into the ground, and so on. Quite a show.

14 Aftermath Conventional baggage system built at cost of $51m Airport opened two years late and $2 billion over budget Airport ridiculed for a variety of reasons, but baggage handling is the most memorable A few sites use this a successful case study?!

15 Two Phases of Design Architectural – Modular decomposition Detailed design – Each module is worked out in detail Weve already snuck in a bit of architectural design – Feel free to abandon or alter Code if you feel it will reduce risk

16 Action vs. Data vs. OO With classical design, you need to do two separate analyses – Action-oriented, based on interactions, data flow, etc. – Data-oriented, based on data structures OO Combines the two – Because objects do

17 Cohesion and Coupling Cohesion: degree of interaction within a module Coupling: degree of interaction between two models Think about Informational Cohesion – Items are in the same module because they act on the same data structure Broad Goal: High Cohesion, Low Coupling

18 Action: Highest Abstraction Start out with raw data Convert into high-level format for processing Convert back to some low-level format Good idea to modularize at the points of maximum abstraction – i.e. when input data has been converted into final form, and before data had been converted into output form – With modern languages, often the stream border

19 OOD Lots of books about this Schachs approach: 1. Construct interaction diagrams for each use case 2. Construct the detailed class diagram 3. Design in terms of clients of objects 4. Proceed to detailed design

20 Elevator Use Case

21 Elevator Seq

22 Collab.

23 Detail

24 Figure Out Clients Determine flow of messages to classes Determine which classes will have to be started by main Add new initialization hooks if necessary

25 Detailed Design Work out implementation of each method Easy, right?