Professional Documents
Culture Documents
Chapter 15
Chapter 15
Introduction
1
Software Design
Introduction
Software design consists of two components, modular design and
packaging.
Modular design is the decomposition of a program into
modules.
A module is a group of executable instructions with a single
2
Software Design
Structured Design
Introduction
Structured design was developed by Ed Yourdon and Larry
Constantine.
This technique deals with the size and complexity of a program
3
Software Design
INFORMATION SYSTEMS FRAMEWORK
SYSTEM
OWNERS
(scope)
Business Processes
rejected order
credit Check
Customers
credit
S customer
SYSTEM number order with
approved order
Y valid products
USERS
S order Validate
customer
valid order Validate
products Orders
T approved
(requirements) order without prices order
E valid
customer
picking
M Products
quantity
in stock
Release
order
ticket
A Chapters 5, 7
N
A
L Application Schema
Y Order
S
Processing
Program
Customers Orders
Products
Chapters 11, 16
SYSTEM
BUILDERS
(components)
Interface
Software Technology
(and Hardware)
Technology
4
Software Design
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.
5
Software Design
Structured Design
Structure Charts
Structure chart modules are depicted by named rectangles.
Structure chart modules are presumed to execute in a top-to-
bottom, left-to-right sequence.
An arc shaped arrow located across a line (representing a module
call) means that the module makes iterative calls.
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.
Program modules communicate with each other through passing of
data.
6
Software Design
Structured Design
Structure Charts
Programs may also communicate with each other through passing
of messages or control parameters, called flags.
Library modules are depicted on a structure chart as a rectangle
containing an vertical line on each side.
7
Software Design
1 SYSTEM
MODULE
DATA A
2
3 DATA B
5
MODULE MODULE
A B
6 FLAG A 4
4 FLAG B
FLAG B
DATA B
7
LIBRARY
MODULE
A
8
Software Design
Structured Design
maintenance.
DFDs must be revised to include editing and error handling
P
RELEASED DATA D
SCREENED
D DATA STORE B DATA B PROCESS B
DATA B (DO NOT REVISED XYZ STATUS
EXPAND)
D DATA STORE C
EXPANDED (OR
REPLACED BY)
P
P FINAL TOTALS BOUNDARY
SUM OF DATA A PROCESS A OF DATA A & C B
NEW
PROCESS AND DATA C
BOUNDARY DATA C
A A
P P RELEASED DATA D
SCREENED
DATA B
NEW PROCESS B
PROCESS
REVISED XYZ STATUS
DATA B B
D DATA STORE B
D DATA STORE C
10
Software Design
D DATA STORE A
A DETAILS P
NEW B DETAILS D DATA STORE B
PROCESS X
UPDATED C DETAILS D DATA STORE C
NEW B DETAILS P
TO BE ADDED
ADD NEW B DETAILS D DATA STORE B
P NEW B
A DETAILS DETAILS
READ
A DETAILS
P
P
BOUNDARY B DETAILS
A DELETE DELETED D DETAILS D DATA STORE D
D DETAILS D DETAILS
TO BE DELETED
11
Software Design
Structured Design
Transform Analysis
One approach used to derive a program structure chart from
program DFD is transform analysis.
Transform analysis is an examination of the DFD to divide
the processes into those that perform input and editing, those
that do processing or data transformation (e.g., calculations),
and those that do output.
• The portion consisting of processes that perform input and editing
is called the afferent.
• The portion consisting of processes that do actual processing or
transformations of data is called the central transform.
• The portion consisting of processes that do output is called the
efferent.
12
Software Design
Central
BOUNDARY
A A
P Transform P
L BOUNDARY
INPUT OUTPUT B
FUNCTION FUNCTION
A A
Afferent C
P
K
D DATA STORE B
INPUT
FUNCTION
E
P Efferent
B OUTPUT
FUNCTION
B
P P
B INPUT F J
TRANSFORM
FUNCTION FUNCTION
D DATA STORE E
C A
H
M
D DATA STORE D
P
P P
D G I OUTPUT
INPUT TRANSFORM
FUNCTION FUNCTION B FUNCTION
D C
13
Software Design
Structured Design
Transform Analysis
The strategy for identifying the afferent, central transform, and
efferent portions of a begins by first tracing the sequence of
processing for each input.
There may be several sequences of processing.
14
Software Design
Structured Design
Transform Analysis
Once sequence paths have been identified, each sequence path is
examined to identify process along that path that are afferent
processes.
The steps are as follows:
• Step 1 - Beginning with the input data flow, the data flow is traced
through the sequence until it reaches a process that does
processing (transformation of data) or an output function.
• Step 2 - Beginning with an output data flow from a path, the data
flow is traced backwards through connected processes until a
transformation processes is reached (or a data flow is encountered
that first represents output).
• Step 3 - All other processes are then considered to be part of the
central transform!
15
Software Design
BOUNDARY P P
A A BOUNDARY
INPUT OUTPUT L
B
FUNCTION FUNCTION
A A
START FOR
TRACING
INPUT A K
C P
INPUT E
FUNCTION P
D DATA STORE B OUTPUT FINISH POINTS
B
FUNCTION FOR TRACING
B
INPUTS A & B
P P
B INPUT F TRANSFORM J
FUNCTION FUNCTION
START FOR C A D DATA STORE E
TRACING
INPUT B
H
M
D DATA STORE D
P P P
16
Software Design
Structured Design
Transform Analysis
Once the DFD has been partitioned, a structure chart can be created
that communicates the modular design of the program.
Step 1 - Create a process that will serve as a “commander and
17
Software Design
BOSS
F G
INPUT
FUNCTION
A
18
Software Design
Structured Design
Transform Analysis
Step 4 - If there is only one transformation process, it should
appear as a single module directly beneath the boss module.
• Otherwise, a coordinating module for the transformation processes
should be created and located directly above the transformation
process..
Step 5 - A module per transformation process on the DFD
should be located directly beneath the controller module.
19
Software Design
BOSS
F G
E, F, & G
J&I
C E&F
J I
G&H
20
Software Design
Structured Design
Transform Analysis
Step 6 - The last process encountered in a path that identifies
efferent processes becomes a second-level module on the
structure chart.
Step 7 - Beneath the module (in step 6) should be a module
21
Software Design
BOSS
E
J
F G
E, F, & G
J&I I
C E&F K
J I
G&H
22
Software Design
MEMBER P
D MEMBER ORDER
DETAILS READ D ACTIVITY REPORT FILE
MEMBER MEMBER
DETAILS ORDER
MEMBER
ORDER
ACTIVITY
P
D MEMBER ORDER MEMBER
ORDER P
READ
MEMBER DETAILS
WRITE
REPORT
ACTIVITY
DETAILS
P
MEMBER DETAILS
GET FORMATED
PRODUCT ORDER ACTIVITY
D PRODUCT ON AN DETAILS
ON AN DETAILS
ORDER
ORDER
P DETAILS
PRODUCT P
CUSTOMER
ON AN ORDER FORMAT
AND ORDER
DETAILS READ MEMBER
DETAILS
PRODUCT ACTIVITY
CONTAINED DETAILS
ON ORDER P UNFORMATTED
ACTIVITY
CALCULATE DETAILS
ORDER
VOLUMES
23
Software Design
MAINTAIN
MEMBER
CUSTOMER
AND ORDER
DETAILS UNFORMATED FORMATED
ACTIVITY ACTIVITY
DETAILS DETAILS
CUSTOMER
AND ORDER FORMATED
DETAILS UNFORMATED ACTIVITY
ACTIVITY DETAILS
DETAILS
FORMAT WRITE
GET CALCULATE
MEMBER REPORT
ORDER ORDER
ACTIVITY ACTIVITY
DETAILS VOLUMES
DETAILS DETAILS
MEMBER
DETAILS
PRODUCT
MEMBER ON AN
MEMBER ORDER ORDER
NUMBER DETAILS ORDER
DETAILS
NUMBER
READ
READ
READ PRODUCT
MEMBER
MEMBER CONTAINED
ORDER
ON ORDER
24
Software Design
Structured Design
Transaction Analysis
An alternative structured design strategy for developing structure
charts is called transaction analysis.
Transaction analysis is the examination of the DFD to
25
Software Design
BOUNDARY
A
TRANSACTION BOUNDARY
B
P P
INPUT PROCESS
FUNCTION TRANSACTION
A TYPE A TYPE A
RESULT
TRANSACTION RESULT
VALID
TRANSACTION TYPE A
P P
TYPE B
TRANSACTION PROCESS RESULT DISPLAY
P
TYPE B TRANSACTION RESULT
TYPE B
TRANSACTION
CENTER
A
TYPE C
TRANSACTION RESULT
TYPE C P
PROCESS
TRANSACTION
TYPE C
26
Software Design
BOSS
TRANSACTION
TYPE A, B, OR TYPE A, B, OR
VALID
C RESULT C RESULT
TRANSACTION
TYPE A TYPE C
RESULT RESULT
27
Software Design
Structured Design
Transaction Analysis
The primary difference between transaction analysis and transform
analysis is that transaction analysis recognizes that modules can be
organized around the transaction center rather than a transform
center.
28
Software Design
Structured Design
modules.
Loosely coupled modules are less likely to be dependent on
one another.
29
Software Design
Structured Design
30
Software Design
Structured Design
31
Software Design
Structured Design
cohesiveness.
Programs that are implemented with highly cohesive modules
32
Software Design
Structured Design
33
Software Design
Structured Design
follows: (continued)
• Temporal cohesion — are modules whose instructions appear to
have been grouped together into a module because of “time”.
• Logical cohesion — are modules that contain instructions that
appear to be related because they fall into the same logical class of
functions.
• Coincidental cohesion — are modules that contain instructions
that have little or no relationship to one another.
34
Software Design
Packaging Program Specifications
Introduction
As an systems analyst, you are responsible for packaging that set
of design documentation into a format suitable for the
programmer.
This package is called a technical design statement.
35
Software Design
INFORMATION SYSTEMS FRAMEWORK
SYSTEM
OWNERS
(scope)
S
SYSTEM
Y
USERS
S
T
(requirements)
E
M
A
N
A
L Database Scehma Application Schema Interface Schema Network Schema
Y Order Customer
New Custom er
S
Processing For m
Program
PRO DUCT
CUST O MER p ro d u ct_n o [Al p h a(10)] I NDEX
Logon Or der Accepted
CUST O MER. cu sto mer_n o q u an ti ty_o rd ered [I n teg er(2) Client P C Client P C
Pr oduct E nter net LAN AIX /Lan
Customers Products
Orders Pr oduct Lookup Help Com plete
Lookup Manager
SYSTEM
BUILDERS
(components)
36
Software Design
Summary
Introduction
What is Software Design?
Structured Design
37