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?