designing large software systems
TRANSCRIPT
1
Designing Large SoftwareSystems
Edit / Undo/ ReDo
User Interface Phrasing
Menu Presentation-Graphics, Text
Prediction
Phrase Completion
Build and Release
Rules Db
AudioConstruction
Synthesis Engine
MP3s
WAVsPresentation
Output
User Feedback
Logging,Monitoring, &Annunciation
Stored Menus
Phrase
Choice
Block Diagram - shows module relationships
Joint X
Get Desiredfor X
Get Actualfor X
Adjust
XPosition
XVelocity
XPosition
XVelocity
ShoulderDrive
Adjust
WaistDrive
Adjust
ElbowDrive
Adjust
Wrist TurnDrive
Adjust
Wrist BendDrive
AdjustGrasp
GraspDrive
MAIN
State ofEach Joint
Structure Chart - shows levels of supervision
2
CAPESensors
Operator(s)
ResultDatabase
Aircraft
Flight GuidanceData
Measurement ResultsMeasurement ResultsSensorData
SensorConfig
User IO
Data Flow Diagram - shows movement, conversion, and storage of data
TCP/IP Stack(HTTP, SNMP,
Telnet)
Generation 2 Configuration Control Detail= Internal
Communication
Socket Input
File System
Serial Input
SerialTerminal
File Input Serial Input
CommandProcessor
Cloud Chart - (pre UML) object relationships
Design ApproachOO, or Structured. or Information FlowStructured – strictly “called” levels of
supervision. One mediator, calling one“helper” routine at a time.
OO – concurrent, selectively persistenttasks
Info Flow – a database manager, withqueries, sorting, and reporting.
3
Design Approach
Any answer of Yes to the followingquestions:
• Is it algorithm based? – Structured
• Can it be accomplished using single-context switching? – Structured
• Is there a Real Time OS? – ObjectOriented is a candidate
Design Approach
• Is the system defined by the data it holdsand moves? – Info Flow
• Multi-tasking? – Object Oriented• Persistence, concurrency, and garbage
collection an issue? – Object Oriented• Is the Language specified? –
– Java – OO– C – Structured– C++ - either Structured or OO
Design Approach
• Third-party software to be usedextensively? – use what they used (COTS= commercial off the shelf)
• Event driven? – Object Oriented (includingVisual Basic)
• Can the system be modeled clearly –Object Oriented
4
Major Modules / Objects
• Find a clean cohesion and decoupling
• Establish the top level of supervision– OO, that might mean a background task
– Structured, it is the Main
– Info Flow, it is the Db Manager
• Data should flow between major modules,not control
• Low-level drivers – close to the HW
Illustrate your design
• Structured – use Structure Charts
• Info Flow – use Data Flow Diagrams
• Object Oriented – use Cloud Charts(Booch representation of Classes andObjects)
• Object Oriented – use UML (UnifiedModeling Language)
"Module"
• Programming - code, class, object,function, procedure, snippet, subroutine,routine, level, subprogram, many manynames.
• With a boundary - a distinction fromanother "module"
• Traversing the boundary - call, invoke,jump, goto, rendezvous, many manynames.
5
In Practical Terms…
• A module must do its job
• What does it need to do its job?
• What other modules does it depend on todo its job?
• "DeCoupled" - needs only data from othermodules.
Reasons NOT to design amodule
• LOC or Size Limit
• Redundant code consolidation - ignoresthe bigger picture of functional isolation
• For the sake of modularization
Reasons TO design a module
• Clarity
• Independence of function
• Hiding and Protection
• Reducing Complexity
6
Coupling
• The strength of module inter-connection
• One module's dependence on another
• any method call reflects at least somecoupling
Data Coupling
• A module is self-contained
• Defers to other modules only to getnecessary, pre-processed data
• Example?
• Write_String_To_File( FileNumber,"Hello");– what's coupled? Just called and calling
routines, through easily-understood data.
• in "structure chart" form:
main
Write_String_To_File
fileNumber
String
7
Control Coupling
• A module has all necessary data, but waitsuntil a command comes to tell it what to do
• Flags passed between modules
• Example?
• Look at DbMgr
e.g. Db Mgr
Edit, Add, or Delete a Record
request (operation type)
DatabaseManager
Get Request
Add Delete Edit
request
8
Control Coupling 2
• Module calls another for assistance, andthen it receives back an error message
• Inversion of Authority
Write to Device
Output
Error
Output
Device Driver
Error Handling
Error Packet
Status?
Who "oversees"the error?
Common Coupling
• A global variable is shared
• What if - you attempt to fix one module bychanging the global variable type?
9
Stamp Coupling
• A record is shared
• Same "what if?"
• The invisible danger of untraceableassociations
• Change one, change the record… whathappens to all the other modules thatdepend on it?
Pathological (or Content)Coupling
• The worst use of a go-to
• Jump into, and out-of, a routine outside ofthe normal call procedure
• A method you do not return from…
OK... what’s wrong with a go-to?
Other clarity-based suggestions:
Use case statements instead of nested ifs,use arrays instead of linked lists, optimizethrough solid design rather than bit-tuning,get a faster CPU instead of writingassembler, pay for the extra memory, buycode if it’s available.
10
“Go-tos are not to be “avoided at all costs”. It is,instead, serpentine code that needs to be avoided.Simplicity and clarity should override most otherdesign decisions. A go-to, in particular, is a powerfultool when used as a direct, no-nonsense jump underwell-stated conditions, and can very closely followproblem-space behavior if used with some planningand forethought (Ada, a language designed fromscratch by smart French people, contains a gotokeyword). On the other hand, the indirection of apointer tends to be a computer-space construct, that isoften confusing and - if honesty should prevail -unnecessary (Java, the latest geek programminglanguage, does not allow the use of pointers).”
... local company coding standards, 1995
Other clarity-based suggestions:
Use case statements instead of nested ifs,use arrays instead of linked lists, optimizethrough solid design rather than bit-tuning,get a faster CPU instead of writingassembler, pay for the extra memory, buycode if it’s available.
Cohesion
• The tendency of one module, to do one,well-defined, independent job
• The question always is… Should thesebehaviors be placed in a single module,or split up?
• Signs of trouble…– can't think of a descriptive name
– weak verb
– multiple verbs
11
Example
• An output module - should it handle outputto file, screen, and printer, and just take ina flag telling it what to do?
• Or should you write three modules, andcall the correct one?
• Consider coupling at the same time
Functional cohesion
• One function, one job
• Gets only the data it needs
• Produces an output in its simplest form
Temporal Cohesion
• Behaviors are grouped together becausethe happen at the same time
• Init routines - order is not important, theyjust all need to be done together.
12
Sequential Cohesion
• Behaviors are grouped together becausethey usually happen in order, the output ofone behavior being the input to the next
e.g. Individual bit-processing in byteconstruction, individual characterprocessing in word processing, etc.
Procedural
• Sequential, but data is not passedbetween behaviors within the sameroutine
e.g. Bringing up a system through a step-by-step process (watch your PC boot: disk,ports, network, display, the order isimportant)
Communicational
• Behaviors are grouped because they acton the same data
13
Logical
• Only a loose association
• A furnace module: raise temp, lower temp,test temp
Coincidental
• No association
Spaghetti
• Information takes a circuitous route
• Usually the result of bad cohesion and badcoupling
• We want…– Strong Cohesion
– Weak Coupling
14
Order the types of Coupling
• Data - good / weak / exposed
• Control Down, Control Up
• Stamp, Common
• Pathological - bad / strong / hidden
Order the types of Cohesion
• Functional - good / strong / independent
• Sequential, Communicational, Procedural,Temporal
• Logical
• Coincidental - bad / weak association ofbehaviors / unrelated within the module
The thermostat in your home….
Furnace Control
(test, raise, lower)
Desired Temperature
15
well partitioned….
FurnaceController
Get Desired
Get Actual
RaiseTemp
Lower Temp
why?
Design an air traffic controlsystem - at the top level
• Plane images and detailed informationcomes from a radar - plane ID, direction,altitude
• Radar inputs are periodic (sweeps =1/sec)
• Plane list is a database
• Display is "exception driven"
Position - lat/long as x,y
Velocity - size and direction of arrow
Altitude - 28200
Type - Symbol
Label - UA417
28.2
UA417
16
Block Diagram
Radar Db Mgr Operator Display
NozzleHandle
Gas Type
StartSwitch
FlowMeter
Gas Readout
Dollar Readout
Gas PumpMotor
Gas MeteringCalculation
Algoritm
Gas PumpApplication:
MAIN
Gas Pump Design
A Gasoline Pump at a service station is anaggregate of the following class instances:
Input Class: Provides services, gives status ofreal world devices.
Input Objects:Start Switch - user pulls switch to begin session.Gas Type (or “Grade”) Push Buttons - regular,premium, etc.Nozzle Handle - begins flow of gas.Flow Meter - calculates gallons of gasdispensed.
17
Display Output Class: Provide user-readable display output services.
Display Output Objects:
Gas Readout - how many gallons havebeen pumped?
Dollar Readout - how much money isowed?
Control Output Class: Provide services forcontrolling machinery.
Control Output Objects:
Gas Pump Motor - when activated, pumpsgas out of the nozzle.
Algorithm Class: solves mathematicalfunctions.
Algorithm Object:
Gas Metering Calculation - something like$ = Amount * Cost as a function of grade.
18
Application Class: provides program start,stop, scheduling, or program controlservices.
Application Object:
simple Main().
Some terms
• Program “Flow” - Objects exist concurrently to provideservices. Objects are created and then “messaged” oractivated by inputs or other objects.
• Object Creation - “instantiation”, comes into being,processes, provides services.
• Object Activation - receives a message, either from theenvironment (in the case of input classes), or fromanother object.
• To Activate - send another object a message.• Propagation - an object instantiating or activating
another.
Application
Start Switch Grade Button
Gas Readout Dollar Readout Nozzle Handle
C
A
C
Gas Pump
CC
C C
C
C
A
A
Flow Meter
C
C
A
A
MeteringAlgorithm
C
C
A
A
C
CREATESC
ON CREATION
A
ACTIVATESA
ON ACTIVATION
S STATUS PATH
S
S
A
A
S
19
Gas Pump Program “Flow”:
1. Application object is constructed:
2. On creation - Creates StartSwitch andGradeButton objects.
3. Assures that only one each ofStartSwitch and GradeButton objects canbe created (an important point!).
StartSwitch object:
On creation - nothing.
On activation - creates GasReadout(0),DollarReadout(0), and NozzleHandleobjects.
On deactivation - destroys NozzleHandle,GasPump, FlowMeter,MeteringCalculation objects.
GradeButton object:
On creation - nothing.
On activation – provides status to MeteringAlgorithm
On deactivation - nothing
20
NozzleHandle object:
On creation - creates GasPumpMotorobject.
On activation - activates GasPumpMotor.
On deactivation - deactivatesGasPumpMotor.
GasPumpMotor object:
On creation - creates FlowMeter object.
On activation - activates FlowMeter.
On deactivation - deactivates FlowMeter.
FlowMeter object:
On creation - creates MeteringCalculationobject.
On activation - activates and provides“gallon count” to MeteringCalculation.
On deactivation - stops “gallon count” toMeteringCalculation.
21
MeteringAlgorithm object:
On creation - nothing.
On activation - reads GradeButton statusand “gallon count” (from FlowMeterobject), provides
messages to DollarReadout andGasReadout display objects.
On deactivation - freezes displays.
GasPumpMotor object (the followingconstitute an object’s contract):
Instantiated: by NozzleHandle constructor.
Constructor: creates FlowMeter object.
States: Active, Inactive.
Destructor: destroyed by StartSwitch destructor.
Persistence - from the time the NozzleHandle isfirst squeezed to the time the StartSwitch isdeactivated.
Assignment: construct contracts for the remainingobjects.
Add the following capabilities tothe Gas Pump:
Pay with credit card at the pump.
Safety lock that prevents gas flow after$25.00.
22
• List the separate modules that needto be designed and programmed.
• Draw a Structure Chart
Do a structured design of theGas Pump
Project Planning
• List the Software Development tasks that needto be accomplished in implementing the gaspump tasks. Include Requirements, Design,Reviews, Coding, Reviews, Integration, Test,Documentation
• List them in time order of which can beaccomplished, then derive parallel paths – Listtasks in columns, each column being aseparate development path.
Project Planning
• Decide which tasks are 1, 2, or 3-persontasks.
• Assign person-hours to each task.• Charge $85 / hr.• Do for both OO and Structured• What are the job costs?• What is the schedule in calendar-time?