Software Engineering 3156

15-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 you’re

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

Knuth’s laws of Optimization First Law: Don’t! 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: Mayor’s 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

We’ve 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 Schach’s 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?