design paradigms

38
30Sep2002 30Sep2002 UVA CS851 - Forensic Software Engin UVA CS851 - Forensic Software Engin eering eering Design Paradigms Design Paradigms Petroski Intro – ch2 Petroski Intro – ch2 J. P. Gunderson J. P. Gunderson

Upload: tilly

Post on 21-Feb-2016

61 views

Category:

Documents


1 download

DESCRIPTION

Design Paradigms. Petroski Intro – ch2 J. P. Gunderson. Approach. Not gonna read you the book You should have already read it Look at ramifications Pull in some of his references What does a bridge have in common with my software application, anyway? Map his conclusions onto Software - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Design ParadigmsDesign Paradigms

Petroski Intro – ch2Petroski Intro – ch2J. P. GundersonJ. P. Gunderson

Page 2: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

ApproachApproachNot gonna read you the bookNot gonna read you the book

You should have already read itYou should have already read itLook at ramificationsLook at ramifications

Pull in some of his referencesPull in some of his referencesWhat does a bridge have in common with What does a bridge have in common with

my software application, anyway?my software application, anyway?Map his conclusions onto SoftwareMap his conclusions onto Software

Link back to Perrow’s Normal AccidentsLink back to Perrow’s Normal Accidents

Page 3: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

PerspectivePerspective Building machinesBuilding machines

Building machines to build machinesBuilding machines to build machines Three roles in building a machineThree roles in building a machine

DesignerDesignerEngineerEngineer ImplementerImplementer

Two Aspects of SoftwareTwo Aspects of SoftwareSoftware as a machineSoftware as a machineSoftware development as a machineSoftware development as a machine

Page 4: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Chapter 3 - Scale MattersChapter 3 - Scale MattersGalileo and the cube lawGalileo and the cube lawVitruviusVitruvius

The auger exampleThe auger exampleDiognetus and the craneDiognetus and the crane

Page 5: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Cube LawCube LawTwice the length -> Four times the surface area -> Eight times the mass

Human Femur Elephant Femur Hadrosaur Femur

Page 6: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Addressing Scale changesAddressing Scale changesGalileo pointed out that you can’t just Galileo pointed out that you can’t just

scale upscale upVitruvius adds that this also applies to Vitruvius adds that this also applies to

force – double the size of the auger, force – double the size of the auger, quadruple the power needed to turn itquadruple the power needed to turn it

Diognetus’s crane shows that sometimes Diognetus’s crane shows that sometimes you have to make qualitative changes to you have to make qualitative changes to overcome scale effectsovercome scale effects

Page 7: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Petroski has great citesPetroski has great cites ““And even in the late 20And even in the late 20thth century, failures of century, failures of

heavy steel sections( see, e.g., Fisher, 1984) heavy steel sections( see, e.g., Fisher, 1984) and large missiles (e.g., and large missiles (e.g., Rosenthal, 1989Rosenthal, 1989) have ) have been attributed to design errors in overlooking or been attributed to design errors in overlooking or underestimating the effects of size in scaling up underestimating the effects of size in scaling up successful designs.”successful designs.”

Rosenthal, 1988 – Trident 2 missilesRosenthal, 1988 – Trident 2 missiles Take a fully functional model, and simply scale it upTake a fully functional model, and simply scale it up What could go wrong?What could go wrong?

Page 8: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The GoodThe Good

Page 9: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Trident 2Trident 2Designed by Lockheed to replace the Designed by Lockheed to replace the

Trident 1Trident 1Let’s make it biggerLet’s make it bigger

44 feet long, twice as heavy as the Trident 144 feet long, twice as heavy as the Trident 1Subsequent analysis suggested that Subsequent analysis suggested that

several problems occurred when the several problems occurred when the design was ‘scaled up’design was ‘scaled up’Original report NY Times 17Aug1989Original report NY Times 17Aug1989Risks (9)12Risks (9)12

Page 10: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 11: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 12: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 13: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 14: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 15: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 16: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 17: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad

Page 18: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The BadThe Bad In the third test, ... instead of spinning end-In the third test, ... instead of spinning end-

over-end, (the missile) began flying on over-end, (the missile) began flying on what at first seemed to be a normal what at first seemed to be a normal trajectory ... "Then it appeared to be losing trajectory ... "Then it appeared to be losing some thrust control and it self-destructed." some thrust control and it self-destructed." Admiral Malley said he had not yet studied Admiral Malley said he had not yet studied the full body of data from the test. the full body of data from the test. But he But he said it appeared that the aft-end pressure said it appeared that the aft-end pressure had severed electrical connectionshad severed electrical connections... ...

Page 19: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

The Kind of PrettyThe Kind of Pretty(in a sick way)(in a sick way)

Page 20: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Scale EffectsScale Effects The first time the missile was tested at sea, The first time the missile was tested at sea,

Admiral Malley said, Admiral Malley said, the unexpectedly strong the unexpectedly strong pounding from the water jet caused the pounding from the water jet caused the (missile's rocket) nozzles to malfunction(missile's rocket) nozzles to malfunction as soon as soon as they fired above the water's surface. The as they fired above the water's surface. The missile began spinning in a spectacular missile began spinning in a spectacular cartwheel until it self destructed. ... cartwheel until it self destructed. ...

After reviewing the tests of the Trident 1, the After reviewing the tests of the Trident 1, the Navy said, Navy said, such jets were present, but had gone such jets were present, but had gone unnoticed because they had not affected the unnoticed because they had not affected the smaller missile's flightsmaller missile's flight. .

Page 21: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Scale Effects in SoftwareScale Effects in Software Is an algorithm scalable?Is an algorithm scalable?

Is this the same scale?Is this the same scale? When does it pay to switch algorithms?When does it pay to switch algorithms?

Is the software design process scalable?Is the software design process scalable? Functional decompositionFunctional decomposition Waterfall modelWaterfall model Object oriented XObject oriented X Aspect oriented XAspect oriented X

Are design flaws being masked by ignorance Are design flaws being masked by ignorance factors?factors?

Page 22: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Page 23: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

IntroductionIntroductionPeople learn by failingPeople learn by failingEngineers are peopleEngineers are people ““Imagination and fear are among the best Imagination and fear are among the best

engineering tools for preventing tragedy.” engineering tools for preventing tragedy.” Spector and Gifford, Communications of Spector and Gifford, Communications of

the ACM, April 1986the ACM, April 1986A Computer Science Perspective of Bridge A Computer Science Perspective of Bridge

DesignDesign

Page 24: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

What do bridges have to do with What do bridges have to do with my software?my software?

Bridges (despite Petroski’s several books Bridges (despite Petroski’s several books of failure analysis) are remarkably reliableof failure analysis) are remarkably reliable

This is an interview that looks at the bridge This is an interview that looks at the bridge design and implementation process.design and implementation process.Software development as a machineSoftware development as a machine

There are some interesting contrasts There are some interesting contrasts between the way bridges are engineered between the way bridges are engineered and the way software is hacked togetherand the way software is hacked together

Page 25: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Bridges start to finishBridges start to finishPreliminary Design PhasePreliminary Design Phase

Select the type and locationSelect the type and locationMain Design PhaseMain Design Phase

Produce all the design documentsProduce all the design documentsDown to every bolt hole, and wire thicknessDown to every bolt hole, and wire thickness

ConstructionConstructionSchedule the constructionSchedule the constructionDesign the construction processDesign the construction processManage the constructionManage the construction

Page 26: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Preliminary DesignPreliminary Design Done by a consulting engineering companyDone by a consulting engineering company Starts with the requirementsStarts with the requirements Explore several alternative designs Explore several alternative designs Produces a document that details the optionsProduces a document that details the options

Costs, locations, special constructionCosts, locations, special construction Maybe 100 pagesMaybe 100 pages

Make a recommendationMake a recommendation Approved by the stakeholders, before detail Approved by the stakeholders, before detail

design starts (client, municipality, public)design starts (client, municipality, public)

Page 27: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Main DesignMain DesignResource analysis, schedulingResource analysis, schedulingModel the bridge Model the bridge Produce 50 – 200 drawingsProduce 50 – 200 drawings

Define components, interfaces, design in Define components, interfaces, design in parallelparallel

Few standard components Few standard components Specifications:Specifications:

Special materials neededSpecial materials neededSpecific construction methodsSpecific construction methods

Page 28: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Model the bridgeModel the bridgeCAD, finite elementCAD, finite elementPossible prototype, if unusual Possible prototype, if unusual

requirements requirements Define major sub-componentsDefine major sub-components

FunctionsFunctions Interfaces with other componentsInterfaces with other components

Model forces, static and dynamic loadsModel forces, static and dynamic loads Interface with existing systemsInterface with existing systems

Roads, waterwaysRoads, waterways

Page 29: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

DesignDesign Small design teamSmall design team

Lead designerLead designer Special teams (piers, foundations, deck)Special teams (piers, foundations, deck) Limited ParallelismLimited Parallelism

Verification: every calculation, part, material Verification: every calculation, part, material checked by a second engineer, final design re-checked by a second engineer, final design re-checked by senior engineer.checked by senior engineer. If computer used, hand check hardcopy of inputs and If computer used, hand check hardcopy of inputs and

outputs to remove transcription errorsoutputs to remove transcription errors

Page 30: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

DrawingsDrawings50 to 200 drawings capture the details of 50 to 200 drawings capture the details of

the bridge designthe bridge designSpecifications capture any special needsSpecifications capture any special needsThese are reviewed and approved by the These are reviewed and approved by the

stakeholdersstakeholdersWhile this captures most of the needed While this captures most of the needed

information for construction, the designers information for construction, the designers are on tap during construction phase.are on tap during construction phase.

Page 31: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

ConstructionConstructionUsually a different organizationUsually a different organizationWork with designers to make sure the right Work with designers to make sure the right

bridge is being builtbridge is being builtVery different skill set from design, Very different skill set from design,

different trainingdifferent trainingConstant oversightConstant oversight

InspectionsInspectionsMaterials tests, etc.Materials tests, etc.

Page 32: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Bridge buildingBridge building

Page 33: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Resources and SchedulingResources and Scheduling1.5 years to design a medium sized bridge1.5 years to design a medium sized bridgeConstruction 3 to 4 yearsConstruction 3 to 4 yearsDesign costs represent 6% of total costDesign costs represent 6% of total costResources:Resources:

Small bridge 1-5 person yearsSmall bridge 1-5 person yearsMedium bridge 10-30 person years Medium bridge 10-30 person years

6 to 20 person team6 to 20 person teamLarge bridge up to 150 person yearsLarge bridge up to 150 person years

Page 34: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Contrast with softwareContrast with software Bridges are designed and built using the Bridges are designed and built using the

waterfall model.waterfall model. Could be 5 years from start to finishCould be 5 years from start to finish

Technology changes more slowly, model T’s still can Technology changes more slowly, model T’s still can cross bridgescross bridges

Rate of usage increase quicklyRate of usage increase quickly Some new bridges are undersized before they are Some new bridges are undersized before they are

completedcompleted But bridges don’t fall down as often as software But bridges don’t fall down as often as software

crashes.crashes.

Page 35: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Normal AccidentsNormal Accidents Interactions:Interactions:

Can you modify part A Can you modify part A without messing up without messing up part Bpart B

CouplingCoupling Is it interruptible?Is it interruptible? Is it a process or a Is it a process or a

series of stepsseries of steps Bridge design: Where Bridge design: Where

does it fit?does it fit?

Interactions

Linear Complex

Cou

plin

g

Loos

eTi

ght

1 23 4

Dams*

Rail Transport*

Aircraft *

Nuclear Plant *

*Mining R & D Firms

*

Universities*

*Junior College

*Most Manufacturing

Page 36: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

BridgesBridges InteractionsInteractions

Naturally decomposesNaturally decomposes But replacing a But replacing a

foundation would be foundation would be hardhard

CouplingCoupling Broken into Broken into

interruptible phasesinterruptible phases Each independent, Each independent,

input – process – input – process – output modeloutput model

Interactions

Linear Complex

Cou

plin

g

Loos

eTi

ght

1 23 4

Dams*

Rail Transport*

Aircraft *

Nuclear Plant *

*Mining R & D Firms

*

Universities*

*Junior College

*Most Manufacturing

Bridge Design *

Page 37: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Where does Software Development Where does Software Development fit?fit?

Waterfall model is out of favorWaterfall model is out of favor Spiral models, eXtreme programming, etc.Spiral models, eXtreme programming, etc. Lack of separation between concept, design and Lack of separation between concept, design and

constructionconstruction Often a lack of interface specifications, in spite of ParnasOften a lack of interface specifications, in spite of Parnas When is the last time you had a complete specification When is the last time you had a complete specification

(down to every variable type) before you started coding?(down to every variable type) before you started coding? Who does your design review before it gets coded?Who does your design review before it gets coded? Who does the line by line code inspection before it shipsWho does the line by line code inspection before it ships Tight coupling, high complexityTight coupling, high complexity

Page 38: Design Paradigms

30Sep200230Sep2002 UVA CS851 - Forensic Software EngineeringUVA CS851 - Forensic Software Engineering

Normal AccidentsNormal Accidents Supported by actual Supported by actual

‘accident’ rates?‘accident’ rates? What causes failures What causes failures

in the development of in the development of software?software? Mars Polar OrbiterMars Polar Orbiter

Those who don’t learn Those who don’t learn from history…from history… How many buffer over-How many buffer over-

run patches in the last run patches in the last six months?six months?

Interactions

Linear Complex

Cou

plin

g

Loos

eTi

ght

1 23 4

Dams*

Rail Transport*

Aircraft *

Nuclear Plant *

*Mining R & D Firms

*

Universities*

*Junior College

*Most Manufacturing

Bridge Design *

*Software Design