Overview

• Introduction

• Design principles

• Design methods

• Conclusion
 Purpose of Design
• Design is where customer requirements, business needs,
and technical considerations all come together in the
formulation of a product or system
• The design model provides detail about the software
data structures, architecture, interfaces, and
components
• The design model can be assessed for quality and be
improved before code is generated and tests are
conducted.
– Does the design contain errors, inconsistencies, or omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints,
schedule, and cost that have been established?
(More on next slide) 2
 Purpose of Design (continued)
• A designer must practice diversification and convergence
– The designer selects from design components, component solutions,
and knowledge available through catalogs, textbooks, and experience
– The designer then chooses the elements from this collection that
meet the requirements defined by requirements engineering and
analysis model
– Convergence occurs as alternatives are considered and rejected until
one particular configuration of components is chosen
• Software design is an iterative process through which
requirements are translated into a blueprint for constructing
the software
– Design begins at a high level of abstraction that can be directly traced
back to the data, functional, and behavioral requirements
– As design iteration occurs, subsequent refinement leads to design
representations at much lower levels of abstraction
3
 Software Design Methods
• Software Design is perhaps the most critical factor affecting
the quality of the system; it has a major impact on later phases
particularly maintenance

• Design methods provide guidelines on the choices to be made

during the design process

• Structured Methods, Formal Methods and Object-Oriented

Methods.
– Formal methods make extensive use of mathematical notations for
the object transformations and for checking consistencies (not
included here).
 Why Methods Don’t Work Miracles?

• Design methods provide guidance and advice

• By focusing on a particular domain of problems e.g.,
data-processing, real time systems, it is possible to
provide tighter guidance.
• Cooking recipe analogy – designing a software is like
writing a cooking recipe
• Most methods are applied to different domains to
optimize their use that results from familiarity with
method
 Design methods
• Structured Methods:
– Functional decomposition
– Data Flow Design (SA/SD)
– Design based on Data Structures (JSD/JSP)

• Object-Oriented Design (OOD)

 Functional decomposition

bottom-up top-down
 Functional decomposition (cont’d)
• Extremes: bottom-up and top-down
• Not used as such; design is not purely rational:
– clients do not know what they want
– changes influence earlier decisions
– people make errors
– projects do not start from scratch
• Rather, design has a yo-yo character
• Examples:
– bottom-up design
– top-down design
– Stepwise Refinement
 Top-down Design
In principle, top-down design involves starting at
the uppermost components in the hierarchy
and working down the hierarchy level by level.
In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience
(and sometimes components) during the
design process.
Top-down and bottom-up design
• Bottom-up design
– Make decisions about reusable low-level utilities.
– Then decide how these will be put together to create high-
level constructs.

• A mix of top-down and bottom-up approaches are

normally used:
– Top-down design is almost always needed to give the
system a good structure.
– Bottom-up design is normally useful so that reusable
components can be created.
 Stepwise Refinement
• The simplest realistic design method, widely used in
practice.
• Not appropriate for large-scale, distributed systems:
mainly applicable to the design of methods.
• Basic idea is:
– Start with a high-level spec of what a method is to achieve;
– Break this down into a small number of problems (usually
no more than 10)
– For each of these problems do the same;
– Repeat until the sub-problems may be solved immediately.
 Structured Analysis and Design
• Two-step process:
– Structured Analysis (SA), resulting in a logical
design, drawn as a set of data flow diagrams
– Structured Design (SD) transforming the logical
design into a program structure and data structure
drawn as sets of structure charts and ERDs
 Entities in a data flow diagram
• Many different symbols exist for each entity
• external entities

• processes

• data flows

• data stores D1 Data Stores

 Some Rules for External Entities
• External people, systems and data
stores
• Reside outside the system, but
interact with system
• Either a) receive info from system,
b) trigger system into motion, or c) External
provide new information to system Entities

• e.g. Customers, managers

• Not clerks or other staff who simply
move data
 Some Rules for Data Stores
• Internal to the system
• Data at rest
• Include in system if the system
processes transform the data
– Store, Add, Delete, Update D1 Data Stores
• Every data store on DFD should
correspond to an entity on an ERD
• Data stores can come in many
forms:
– Hanging file folders
– Computer-based files
– Notebooks
 Some Rules for Data Flows

• Data in motion, moving from

one place to another in the
system Data Flow
– From external entity (source) to
system
– From system to external entity
(sink)
– From internal symbol to internal
symbol, but always either start
or end at a process
Data Flow Diagrams
Tips

• Direct flows of information between two data stores are

evidently not possible

M1 Purchase Orders

P.O. Copy

M2 Stock
 Some Rules for Processes
• Always internal to system
• Law of conservation of data: 0.

#1: Data stays at rest unless Processes

moved by a process.
#2: Processes cannot consume or create data BY
THEMSELVES
– Must have at least 1 input data flow (to avoid miracles)
– Must have at least 1 output data flow (to avoid black
holes)
Data Flow Diagrams
Tips

• For a process to be complete, it needs to have both an input and

an output (shown by data flows going into and coming out of it)

2 Goods Receiving
Check T2 Matched P.O.’s
Delivery Matched P.O.

2 Goods Receiving
b
Supplier Check
Delivery Note Delivery

2 Goods Receiving
b
Supplier Check T2 Matched P.O.’s
Delivery Note Delivery Matched P.O.
Data Flow Diagrams
Tips

• As with processes, data stores should both receive

information for storing and provide it for further
processing
• If a data store exists without a flow from a process
coming into it or a flow towards a process coming out
of it then the analyst should further investigate the
system (by asking the user such questions as “how
does the information get here in the first place?” and
“who uses this information after it gets here?”)
Data Flow Diagrams
Tips

f
Someone M2 A data store
Something

WHY?

2
f
Someone Do something M2 A data store
Something with it Same something
 Processes
• Logical process models omit any processes that do
nothing more than move or route data, thus leaving the
data unchanged. Valid processes include those that:
– Perform computations (e.g., calculate grade point average)
– Make decisions (determine availability of ordered products)
– Sort, filter or otherwise summarize data (identify overdue
invoices)
– Organize data into useful information (e.g., generate a report or
answer a question)
– Trigger other processes (e.g., turn on the furnace or instruct a
robot)
– Use stored data (create, read, update or delete a record)
 Types of Diagrams
• Context Diagram
– A data flow diagram (DFD) of the scope of an
organizational system that shows the system boundaries,
external entities that interact with the system and the
major information flows between the entities and the
system
• Level-O Diagram
– A data flow diagram (DFD) that represents a system’s
major processes, data flows and data stores at a high level
of detail
 Figure 1
Context diagram of a Food ordering system
 Figure 2
Level-0 DFD of a food ordering system
 Creating Data Flow Diagrams
Creating DFDs is a highly iterative process of gradual
refinement.
General steps:
1. Create a preliminary Context Diagram
2. Identify Use Cases, i.e. the ways in which users
most commonly use the system
3. Create DFD fragments for each use case
4. Create a Level 0 diagram from fragments
5. Decompose to Level 1,2,…
6. Go to step 1 and revise as necessary
7. Validate DFDs with users.
 Data Flow Diagrams
Starting from the Context Diagram

• To develop a Context Diagram we carry out the

following tasks:
(i) Identify all sources and recipients of data from the
system, i.e. external entities
(ii) Identify the major data flows to and from the external
entities
(iii)Convert each source or recipient into an external entity
symbol
(iv)Add the data flows between each external entity and a
single box representing the entire system
Top-level DFD: context diagram

direction request
library
management client
system
report ack’ment
 DFD Rules—General
• Basic rules that apply to all DFDs
– Inputs to a process are always different than
outputs
– Objects always have a unique name
• In order to keep the diagram uncluttered, you can
repeat data stores and sources/sinks on a diagram
 DFD Rules—Symbols
• Data Store
Process
– Data cannot be moved
– No process can havedirectly from one (a
only outputs store to another
miracle)
– Data cannot move directly from an outside source to a data store
– No process can have only inputs (black hole)
– Data cannot move directly from a data store to a data sink
–
– A process
Data hasa noun
store has a verb phrase
phrase labellabel
 DFD Rules—Symbols
• Data Flow
Source/Sink
–
– AData
datacannot
flow hasmove
only one direction of flow between
directly from a source tosymbols
a sink
– A fork means that exactly the same data goes from a common location
–A to source/sink has a noun
two or more processes, dataphrase
stores orlabel
sources/sinks
 DFD Rules—Symbols
• Data Flow (Continued)
– A join means that exactly the same data comes from any
two or more different processes, data stores or
sources/sinks to a common location
– A data flow cannot go directly back to the same process it
leaves
– A data flow to a data store means update
– A data flow from a data store means retrieve or use
– A data flow has a noun phrase label
 DFD Rules—Context Diagram
• One process, numbered 0.
• Sources and sinks (external entities) as
squares
• Main data flows depicted
• No internal data stores are shown
– They are inside the system
– External data stores are shown as external entities
– How do you tell the difference between an
internal and external data store?
 Decomposition of DFDs
• Functional decomposition
– Act of going from one single system to many component
processes
– This is a repetitive procedure allowing us to provide more
and more detail as necessary
– The lowest level is called a primitive DFD
• Level-N Diagrams
– A DFD that is the result of n nested decompositions of a
series of subprocesses from a process on a level-0 diagram
 DFD Rules—Balancing DFDs
• When decomposing a DFD, you must conserve inputs
to and outputs from a process at the next level of
decomposition. This is called balancing.
• Example: Food ordering system
– In Figure 1, notice that there is one input to the system,
the customer order
– Three outputs:
• Customer receipt
• Food order
• Management reports
 DFD Rules—Balancing DFDs
• Example (Continued)
– Notice Figure 2. We have the same inputs and
outputs
– No new inputs or outputs have been introduced
– We can say that the context diagram and level-0
DFD are balanced
 DFD Rules—Balancing DFDs
• An unbalanced example, Figure 3
– In context diagram, we have one input to the
system, A and one output, B
– Level-0 diagram has one additional data flow, C
– These DFDs are not balanced
 Figure 3
An unbalanced set of data flow diagrams—why?
(a) Context diagram (b) Level-0 diagram
Data Flow Diagrams
Tips

• The drawing of DFDs is an iterative activity

• However clear a completed DFD looks, it should be

appreciated that to draw one, many passes have to be
made (with a lot of paper ending up in the waste-
paper basket!).
• A DFD starts taking its final shape when it is possible
to produce a clear list of data items (or attributes) for
each and every one of its data flows.
Top-level DFD: context diagram

direction request
library
management client
system
report ack’ment
 First-level decomposition

client management
request
report direction
log data
prelim. prelim.
doc doc
acknowledgement

return
borrow
request
request log data

borrow prelim. log file

title doc
title title

catalog adm.
 Second-level decomposition for
“preliminary processing”

data base log file

request client info log data

check OK
client process
data request
borrow return
not OK request request
From data flow diagrams to structure charts

• result of SA: logical model, consisting of a set

of DFD’s, augmented by minispecs, data
dictionary, etc.
• Structured Design = transition from DFD’s to
structure charts
• heuristics for this transition are based on
notions of coupling and cohesion
 Structured Design
• The concept of structured design is simple.
• Design a program as a top-down hierarchy of modules.
• The top-down structure of these modules is developed
according to various design rules and guidelines.
• The resulting hierarchy of modules can then be
evaluated according to certain quality acceptance
criteria to ensure the best modular design for the
program.
• Upon completion, the modules are to be implemented
using structured programming principles.
 Structured Design

• Structure Charts
– The primary tool used in structured design is the
structure chart.
– Structure charts are used to graphically depict a
modular design of a program.
• Specifically, they show how the program has been
partitioned into smaller more manageable modules,
the hierarchy and organization of those modules, and
the communication interfaces between modules.
• Structure charts, however, do not show the internal
procedures performed by the module or the internal
data used by the module.
 1 SYSTEM
MODULE

2
DATA A 3 DATA B
5
MODULE MODULE
A B

6 4
FLAG A
4
5 FLAG B 6 FLAG B

DATA A DATA B DATA C

DATA D DATA B
AND C/D

MODULE MODULE MODULE MODULE MODULE

C D E F G

DATA B 7

LIBRARY
MODULE
A
 Structure Charts
The figure above depicts the symbol set used for
structure charts.
– Structure chart modules are depicted by named
rectangles.
• Modules are factored, from the top down, into
submodules. The highest level module is referred to as
the system or root module. It serves to coordinate the
modules appearing directly beneath it. In turn, those
modules may serve to coordinate those modules
appearing immediately below them.
– Structure chart modules are presumed to execute
in a top-to-bottom, left-to-right sequence.
– The line connecting two modules represents a
normal call.
• For example, SYSTEM MODULE calls MODULE B.
 Structure Charts
– An arc shaped arrow located across a line (representing a module
call) means that the module makes iterative calls.
• Thus, SYSTEM MODULE calls MODULE A to be performed N number of
times, or until some condition is met.
– A diamond symbol located at the bottom of a module means that
the module calls one and only one of the other lower modules that
are connected to the diamond.
• Thus, MODULE A can call MODULE C or MODULE D. Notice however that
MODULE B can call MODULE G and it can call either MODULE E or
MODULE F.
– Program modules communicate with each other through passing of
data.
• Data being passed is represented by named arrows with a small circle on
one end. The direction of the arrow is significant. Note that DATA A is
being passed “up” from MODULE C to its parent, MODULE A. The
downward direction of the arrow for DATA B implies that SYSTEM MODULE
is passing it to MODULE B.
 Structure Charts
– Programs may also communicate with each other
through passing of messages or control parameters,
called flags.
• Control flags are depicted by an arrow with a darkened
circle on one end.
– Library modules are depicted on a structure chart as
a rectangle containing a vertical line on each side.
• Often times a systems designer recognizes the opportunity
to utilize a pre-defined or library module. For example,
perhaps one function of a program is to perform a special
sort routine that was previously developed and placed in
the program library for use by other developers for
applications that might reuse that function.
 Iteration and Decision on a
Structure Chart
Symbol for showing
decisions Symbol for showing
Issue pay iteration
cheques
for all
employees

Calculate Pay Calculate Pay

Get Employee Print Pay
for Casual for Salaried
Pay Record Cheque
Worker Worker
Structure Chart for Entire Payroll Program
 Object-oriented development
• Object-oriented analysis, design and programming
are related but distinct.
• OOA is concerned with developing an object model
of the application domain.
• OOD is concerned with developing an object-
oriented system model to implement requirements.
• OOP is concerned with realising an OOD using an OO
programming language such as Java or C++.
 Characteristics of OOD
• Objects are abstractions of real-world or system
entities and manage themselves.
• Objects are independent and encapsulate state and
representation information.
• System functionality is expressed in terms of object
services.
• Shared data areas are eliminated. Objects
communicate by message passing.
• Objects may be distributed and may execute
sequentially or in parallel.
 Interacting objects

o1: C1 o3:C3 o4: C4

state o1 state o3 state o4
ops1() ops3 () ops4 ()

o2: C3 o6: C1 o5:C5

state o2 state o6 state o5
ops3 () ops1 () ops5 ()
 The Unified Modeling Language
• Several different notations for describing object-
oriented designs were proposed in the 1980s and
1990s.
• The Unified Modeling Language is an integration of
these notations.
• It describes notations for a number of different
models that may be produced during OO analysis and
design.
• It is now a de facto standard for OO modelling.
Employee object class (UML)
Employee

name: string
address: string
dateOfBir th: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. ..

join ()
leave ()
retire ()
changeDetails ()
 Object communication
• Conceptually, objects communicate by message
passing.
• Messages
– The name of the service requested by the calling object;
– Copies of the information required to execute the service
and the name of a holder for the result of the service.
• In practice, messages are often implemented by
procedure calls
– Name = procedure name;
– Information = parameter list.
 OOAD methods
• three major steps:

1 identify the objects

2 determine their attributes and services

3 determine the relationships between objects

 (Part of) problem statement
Design the software to support the operation of a
public library.
The system has a number of stations for customer
transactions. These stations are operated by library
employees.
When a book is borrowed, the identification card of
the client is read. Next, the station’s bar code reader
reads the book’s code.
When a book is returned, the identification card is not
needed and only the book’s code needs to be read.
 Candidate objects
• software
• library
• system
• station
• customer
• transaction
• book
• library employee
• identification card
• client
• bar code reader
• book’s code
 Carefully consider candidate list
• eliminate implementation constructs, such as “software”
• replace or eliminate vague terms: “system” 
“computer”
• equate synonymous terms: “customer” and “client” 
“client”
• eliminate operation names, if possible (such as
“transaction”)
• be careful in what you really mean: can a client be a
library employee? Is it “book copy” rather than “book”?
• eliminate individual objects (as opposed to classes).
“book’s code”  attribute of “book copy”
 Relationships
• From the problem statement:
– employee operates station
– station has bar code reader
– bar code reader reads book copy
– bar code reader reads identification card
• inferred knowledge:
– library owns computer
– library owns stations
– computer communicates with station
– library employs employee
– client is member of library
– client has identification card
Result: initial class diagram
Usage scenario  sequence diagram
 Structured Paradigm
• The structured paradigm had great successes
initially
– It started to fail with larger products (> 50,000 LOC)
• Maintenance problems (today, up to 80% of
effort)
• Reason: structured methods are
– Action oriented (finite state machines, data flow
diagrams); or
– Data oriented (entity-relationship diagrams,
Jackson’s method);
– But not both
 The Object-Oriented Paradigm

• Both data and actions are of equal importance

• Object:
– Software component that incorporates both data
and the actions that are performed on that data
• Example:
– Bank account
• Data: account balance
• Actions: deposit, withdraw, determine balance
 Structured versus Object-Oriented Paradigm

• Information hiding
• Impact on maintenance, development
 Transition From Analysis to Design

• Structured paradigm:
– Sharp transition between analysis (what) and design (how)
• Object-oriented paradigm:
– Objects enter from very beginning
 Analysis/Design “Hump”
• Systems analysis
– Determine what has to be done
• Design
– Determine how to do it
– Architectural design—determine modules
– Detailed design—design each module

CS540 Software Design Lecture 2 72

 Removing the “Hump”
• Object-oriented analysis
– Determine what has to be done
– Determine the objects
• Object-oriented design
– Determine how to do it
– Design the objects

CS540 Software Design Lecture 2 74

 In More Detail

• Objects enter here

 Conclusion
• Essence of the design process: decompose
system into parts
• Desirable properties of a decomposition:
coupling/cohesion, information hiding, (layers
of) abstraction
• Design methods: Structured methods
(functional decomposition, data flow design,
data structure design), formal methods,
object-oriented design