Designing Large Software
Systems
User Interface
Phrasing
MP3s
Prediction
Rules Db
WAVs
Phrase Completion
Presentation
Audio
Construction
Stored Menus
Output
Phrase
Synthesis Engine
Menu PresentationGraphics, Text
User Feedback
Choice
Logging,
Monitoring, &
Annunciation
Build and Release
Edit / Undo/ ReDo
Block Diagram - shows module relationships
MAIN
State of
Each Joint
Get Desired
for X
X
Position
X
Velocity
Joint X
Get Actual
for X
X
Position
X
Velocity
Adjust
Adjust
Adjust
Shoulder Adjust
Adjust
Drive
Adjust
Waist
Grasp
Drive
Elbow
Drive
Wrist Turn
Drive
Wrist Bend
Drive
Grasp
Drive
Structure Chart - shows levels of supervision
1
Data Flow Diagram - shows movement, conversion, and storage of data
Operator(s)
User IO
Sensors
SensorData
CAPE
Measurement Results
Result
Database
SensorConfig
Flight Guidance
Data
Aircraft
Cloud Chart - (pre UML) object relationships
Generation 2 Configuration Control Detail
= Internal
Communication
TCP/IP Stack
(HTTP, SNMP,
Telnet)
Socket Input
File System
Serial
Terminal
File Input
Serial Input
Command
Processor
Serial Input
Design Approach
OO, or Structured. or Information Flow
Structured – strictly “called” levels of
supervision. One mediator, calling one
“helper” routine at a time.
OO – concurrent, selectively persistent
tasks
Info Flow – a database manager, with
queries, sorting, and reporting.
2
Design Approach
Any answer of Yes to the following
questions:
• Is it algorithm based? – Structured
• Can it be accomplished using singlecontext switching? – Structured
• Is there a Real Time OS? – Object
Oriented is a candidate
Design Approach
• Is the system defined by the data it holds
and 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 used
extensively? – use what they used (COTS
= commercial off the shelf)
• Event driven? – Object Oriented (including
Visual Basic)
• Can the system be modeled clearly –
Object Oriented
3
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 and
Objects)
• Object Oriented – use UML (Unified
Modeling Language)
"Module"
• Programming - code, class, object,
function, procedure, snippet, subroutine,
routine, level, subprogram, many many
names.
• With a boundary - a distinction from
another "module"
• Traversing the boundary - call, invoke,
jump, goto, rendezvous, many many
names.
4
In Practical Terms…
• A module must do its job
• What does it need to do its job?
• What other modules does it depend on to
do its job?
• "DeCoupled" - needs only data from other
modules.
Reasons NOT to design a
module
• LOC or Size Limit
• Redundant code consolidation - ignores
the bigger picture of functional isolation
• For the sake of modularization
Reasons TO design a module
•
•
•
•
Clarity
Independence of function
Hiding and Protection
Reducing Complexity
5
Coupling
• The strength of module inter-connection
• One module's dependence on another
• any method call reflects at least some
coupling
Data Coupling
• A module is self-contained
• Defers to other modules only to get
necessary, 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
fileNumber
String
Write_String_To_File
6
Control Coupling
• A module has all necessary data, but waits
until a command comes to tell it what to do
• Flags passed between modules
• Example?
• Look at DbMgr
e.g. Db Mgr
request (operation type)
Edit, Add, or
Delete a Record
request
Get
Request
Database
Manager
Add
Delete
Edit
7
Control Coupling 2
• Module calls another for assistance, and
then it receives back an error message
• Inversion of Authority
Output
Error
Write to
Device
Output
Status?
Device
Driver
Error Packet
Error
Handling
Who "oversees"
the error?
Common Coupling
• A global variable is shared
• What if - you attempt to fix one module by
changing the global variable type?
8
Stamp Coupling
• A record is shared
• Same "what if?"
• The invisible danger of untraceable
associations
• Change one, change the record… what
happens to all the other modules that
depend on it?
Pathological (or Content)
Coupling
• The worst use of a go-to
• Jump into, and out-of, a routine outside of
the 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, optimize
through solid design rather than bit-tuning,
get a faster CPU instead of writing
assembler, pay for the extra memory, buy
code if it’s available.
9
“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 other
design decisions. A go-to, in particular, is a powerful
tool when used as a direct, no-nonsense jump under
well-stated conditions, and can very closely follow
problem-space behavior if used with some planning
and forethought (Ada, a language designed from
scratch by smart French people, contains a goto
keyword). On the other hand, the indirection of a
pointer tends to be a computer-space construct, that is
often confusing and - if honesty should prevail unnecessary (Java, the latest geek programming
language, 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, optimize
through solid design rather than bit-tuning,
get a faster CPU instead of writing
assembler, pay for the extra memory, buy
code if it’s available.
Cohesion
• The tendency of one module, to do one,
well-defined, independent job
• The question always is… Should these
behaviors be placed in a single module,
or split up?
• Signs of trouble…
– can't think of a descriptive name
– weak verb
– multiple verbs
10
Example
• An output module - should it handle output
to file, screen, and printer, and just take in
a flag telling it what to do?
• Or should you write three modules, and
call 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 because
the happen at the same time
• Init routines - order is not important, they
just all need to be done together.
11
Sequential Cohesion
• Behaviors are grouped together because
they usually happen in order, the output of
one behavior being the input to the next
e.g. Individual bit-processing in byte
construction, individual character
processing in word processing, etc.
Procedural
• Sequential, but data is not passed
between behaviors within the same
routine
e.g. Bringing up a system through a step-bystep process (watch your PC boot: disk,
ports, network, display, the order is
important)
Communicational
• Behaviors are grouped because they act
on the same data
12
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 bad
coupling
• We want…
– Strong Cohesion
– Weak Coupling
13
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 of
behaviors / unrelated within the module
The thermostat in your home….
Desired Temperature
Furnace
Control
(test, raise, lower)
14
well partitioned….
Furnace
Controller
Get
Desired
Get
Actual
Raise
Temp
Lower
Temp
why?
Design an air traffic control
system - at the top level
• Plane images and detailed information
comes 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
UA417
28.2
Velocity size and direction of
arrow
Altitude - 28200
Type - Symbol
Label - UA417
15
Block Diagram
Radar
Db Mgr
Operator Display
Gas Pump
Application:
MAIN
Gas Readout
Start
Switch
Dollar Readout
Nozzle
Handle
Gas Type
Flow
Meter
Gas Pump
Motor
Gas Metering
Calculation
Algoritm
Gas Pump Design
A Gasoline Pump at a service station is an
aggregate of the following class instances:
Input Class: Provides services, gives status of
real 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 gas
dispensed.
16
Display Output Class: Provide userreadable display output services.
Display Output Objects:
Gas Readout - how many gallons have
been pumped?
Dollar Readout - how much money is
owed?
Control Output Class: Provide services for
controlling machinery.
Control Output Objects:
Gas Pump Motor - when activated, pumps
gas out of the nozzle.
Algorithm Class: solves mathematical
functions.
Algorithm Object:
Gas Metering Calculation - something like
$ = Amount * Cost as a function of grade.
17
Application Class: provides program start,
stop, scheduling, or program control
services.
Application Object:
simple Main().
Some terms
• Program “Flow” - Objects exist concurrently to provide
services. Objects are created and then “messaged” or
activated by inputs or other objects.
• Object Creation - “instantiation”, comes into being,
processes, provides services.
• Object Activation - receives a message, either from the
environment (in the case of input classes), or from
another object.
• To Activate - send another object a message.
• Propagation - an object instantiating or activating
another.
Application C
C
C
Start Switch
Grade Button
A
A
C
C
C
Gas Readout
Dollar Readout
Nozzle Handle
C
A
C
A
C
Gas Pump
C
A
C
A
C
A
Flow Meter
C
A
ON CREATION
CREATES
ON ACTIVATION
A
ACTIVATES
S
STATUS PATH
S
A
C
Metering
Algorithm
S
S
A
18
Gas Pump Program “Flow”:
1. Application object is constructed:
2. On creation - Creates StartSwitch and
GradeButton objects.
3. Assures that only one each of
StartSwitch and GradeButton objects can
be created (an important point!).
StartSwitch object:
On creation - nothing.
On activation - creates GasReadout(0),
DollarReadout(0), and NozzleHandle
objects.
On deactivation - destroys NozzleHandle,
GasPump, FlowMeter,
MeteringCalculation objects.
GradeButton object:
On creation - nothing.
On activation – provides status to Metering
Algorithm
On deactivation - nothing
19
NozzleHandle object:
On creation - creates GasPumpMotor
object.
On activation - activates GasPumpMotor.
On deactivation - deactivates
GasPumpMotor.
GasPumpMotor object:
On creation - creates FlowMeter object.
On activation - activates FlowMeter.
On deactivation - deactivates FlowMeter.
FlowMeter object:
On creation - creates MeteringCalculation
object.
On activation - activates and provides
“gallon count” to MeteringCalculation.
On deactivation - stops “gallon count” to
MeteringCalculation.
20
MeteringAlgorithm object:
On creation - nothing.
On activation - reads GradeButton status
and “gallon count” (from FlowMeter
object), provides
messages to DollarReadout and
GasReadout display objects.
On deactivation - freezes displays.
GasPumpMotor object (the following
constitute 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 is
first squeezed to the time the StartSwitch is
deactivated.
Assignment: construct contracts for the remaining
objects.
Add the following capabilities to
the Gas Pump:
Pay with credit card at the pump.
Safety lock that prevents gas flow after
$25.00.
21
Do a structured design of the
Gas Pump
• List the separate modules that need
to be designed and programmed.
• Draw a Structure Chart
Project Planning
• List the Software Development tasks that need
to be accomplished in implementing the gas
pump tasks. Include Requirements, Design,
Reviews, Coding, Reviews, Integration, Test,
Documentation
• List them in time order of which can be
accomplished, then derive parallel paths – List
tasks in columns, each column being a
separate development path.
Project Planning
• Decide which tasks are 1, 2, or 3-person
tasks.
• 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?
22