What Is Software Design?: Modular Design Is The Decomposition of A Program Into

Software Design
What is 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
point of entry and a single point of exit.

 Packaging is the assembly of data, process, interface, and
geography design specifications for each module.
Copyright Irwin/McGraw-Hill 1998

1
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
by breaking up a the program into a hierarchy of modules that

result in a computer program that is easier to implement and
maintain.

2
Software Design
INFO RM ATIO N SYSTEM S FRAM EW O RK
F OCU S ON FO CU S ON FO CUS ON FO CUS ON

SYS T EM SYST EM SYST E M SYST E M
DA T A PR OCE SSE S INT E RFA CES GEO GRA PH Y
SYS T E M
OW NER S
(scope )
B usiness P rocesses
r eject ed or der
cr edit Check
Cust om er s
cr edit
S cust om er
SYS T E M num ber or der wit h
appr oved or der
Y valid pr oduct s
US ERS
S or der Validat e
cust om er
valid or der Validat e
pr oduct s O r der s
T appr oved
(requ irem e nts) or der wit hout pr ices or der
E valid
cust om er
picking
M Pr oduct s
quant it y
in st ock
Release
or der
t icket
A C hapters 5, 7
N
A
L Application Schem a
Y O r der
S
Pr oc es si ng
Pr ogr a m
T I ni t i a t i on Pr oc es s Shut dow n
S SYS T E M Rout i ne an O r de r Rout i ne
DES IGNE RS G et a n Va l i da t e Fi l e a n
O r der an O r de r O r de r
(facilitation ) (specifica tion) Che ck

Cust om e r
Cr edi t
Chec k
Pr oduc t
Dat a
Chec k
Cr edi t
Da t a
Re l e as e
an
O r der
Cust om e r s O r der s
Pr oduc t s
Chapters 11, 16
SYS T E M
BU ILDE RS
(com ponen ts)
Interface
Softw are Technology
(and H ardw are)
Technology

3
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.

4
Software Design
Structured Design
 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.

5
Software Design
Structured Design
 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.

6
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
5 DATA A DATA B DATA C

6 DATA B
DATA D
AND C/D
MODULE MODULE MODULE MODULE MODULE

C D E F G
DATA B
7
LIBRARY
MODULE
A

7
Software Design
Structured Design
 Data Flow Diagrams of Programs

 Structured design requires that data flow diagrams (DFDs) first be
drawn for the program.
 Processes appearing on the logical, elementary DFDs may
represent modules on a structure chart.
 Logical DFDs need to be revised to show more detail in order to
be used by programmers
 The following revisions may be necessary:
 Processes appearing on the DFD should do one function.
 Processes need to be added to handle data access and
maintenance.
 DFDs must be revised to include editing and error handling
processes, and processes to implement internal controls.

8
Software Design
D DATA STORE A DATA A P
FINAL TOTALS BOUNDARY
PROCESS A OF DATA A & C B
P SUM OF DATA A
(DO NOT
BOUNDARY AND DATA C
PROCESS EXPAND)
A DATA C WITH MANY
INPUTS &
OUTPUTS
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)
D DATA STORE A DATA A
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

9
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
BOUNDARY B DETAILS DELETED D DETAILS D DATA STORE D

A
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
C DETAILS TO UPDATE UPDATED C DETAILS D DATA STORE C

P C DETAILS
D DATA STORE A BE UPDATED
A DETAILS FOR
PROCESSING PROCESS X
P
BOUNDARY B DETAILS
A DELETE DELETED D DETAILS D DATA STORE D
D DETAILS D DETAILS
TO BE DELETED

10
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.

11
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 TRANSFOR M J
FUNCTION FUNCTION
D DATA STORE E
C A
H
M
D DATA STORE D
P
P P
D G I OUTPUT
INPUT TRANSFOR M
FUNCTION FUNCTION B FUNCTION
D C

12
Software Design
Structured Design
 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.
 A sequence of processing for a given input may actually split to
follow different paths.

13
Software Design
Structured Design
 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!

14
Software Design
P P
BOUNDARY
A A BOUNDARY
OUTPUT L
INPUT B
FUNCTION FUNCTION
A A
START FOR
TRACING
INPUT A K
P
C
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
D INPUT G TRANSFORM I OUTPUT

FUNCTION FUNCTION B FUNCTION
D C
START FOR FINISH POINT
TRACING FOR TRACING
INPUT D INPUT D

15
Software Design
Structured Design
 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
chief” of all other modules.

• This module manages or coordinates the execution of the other
program modules.
 Step 2 - The last process encountered in a path that identifies
afferent processes becomes a second-level module on the
structure charts.
 Step 3 - Beneath that module should be a module that
corresponds to its preceding process on the DFD.

 This would continue until all afferent processes in the sequence
path are included on the structure chart.

16
Software Design
BOSS
F G
INPUT INPUT INPUT

FUNCTION FUNCTION FUNCTION
B C D
INPUT
FUNCTION
A

17
Software Design
Structured Design
 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.

18
Software Design
BOSS
F G
E, F, & G
J&I
INPUT INPUT INPUT CENTRAL

FUNCTION FUNCTION FUNCTION TRANSFORM
B C D CONTROLLER
C E&F
J I
G&H
INPUT TRANSFORM TRANSFORM

FUNCTION FUNCTION FUNCTION
A A B

19
Software Design
Structured Design
 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
that corresponds to the succeeding process appearing on the

sequence path.
• Likewise any process immediately following that process would
appear as a module beneath it on the structure chart.

20
Software Design
BOSS
E
J
F G
E, F, & G
J&I I
INPUT INPUT INPUT CENTRAL OUTPUT OUTPUT

FUNCTION FUNCTION FUNCTION TRANSFORM FUNCTION FUNCTION
B C D CONTROLLER C B
C E&F K
J I
G&H
INPUT TRANSFORM TRANSFORM OUTPUT

FUNCTION FUNCTION FUNCTION FUNCTION
A A B A

21
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

22
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

23
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
identify processes that represent transaction centers.

• A transaction center is a process that does not do actual
transformation upon the incoming data (data flow); rather, it serves
to route the data to two or more processes.
– You can think of a transaction center as a traffic cop that
directs traffic flow.
– Such processes are usually easy to recognize on a DFD,
because they usually appear as a process containing a single
incoming data flow to two or more other processes.

24
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

25
Software Design
BOSS
TRANSACTION
TYPE A, B, OR TYPE A, B, OR
VALID
C RESULT C RESULT
TRANSACTION
INPUT TRANSACTION DISPLAY

FUNCTION CENTER RESULT
A
TYPE A TYPE C
RESULT RESULT
TRANSACTION TRANSACTION TYPE B TRANSACTION

TYPE A TYPE B RESULT
TYPE C
PROCESS PROCESS PROCESS

TRANSACTION TRANSACTION TRANSACTION
TYPE A TYPE B TYPE C

26
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.

27
Software Design
Structured Design
 Structure Chart Quality Assurance Checks

 Coupling:
 In structured design, the decomposition of a program in
manageable modules should be done in such a way that the

modules are independent as possible from one another.
 In structured design programs appearing on a structure chart
are evaluated relative to their degree coupling.

 Coupling refers to the level of dependency that exists between
modules.
 Loosely coupled modules are less likely to be dependent on
one another.

28
Software Design
Structured Design

 Coupling:
 Types of coupling: (from best to worst)
• Data coupling — two modules are said to be data coupled if their

dependency is based on the fact that they communicate by passing
of data.
• Stamp coupling — two modules are said to be stamp coupled if
their communication of data is in the form of an entire data
structure or record.
• Control coupling — two modules are said to be control coupled if
their dependency is based on the fact that they communicate by
passing of control information or flags.
• Common coupling — modules are said to be common coupled if
they refer to the same global data area.

29
Software Design
Structured Design

 Coupling:
 Types of coupling: (continued)
• Content coupling — two modules are said to be content coupled

(also referred to as hybrid coupled) when one module actually
modifies the procedural contents of another module.

30
Software Design
Structured Design

 Cohesion:
 Cohesion refers to the degree to which a module's instructions
are functionally related.

 Highly cohesive modules contain instructions that collectively
work together to solve a specific task.

 The goal is to ensure that modules exhibit a high degree of
cohesiveness.
 Programs that are implemented with highly cohesive modules
tend to be easier to understand, modify, and maintain.

31
Software Design
Structured Design

 Cohesion:
 There are seven types or levels of cohesion and they are as
follows: (from most desirable to least desirable)

• Functional cohesion — are modules whose instruction are related
because they collectively work together to accomplish a single
well-define function.
• Sequential cohesion — are modules whose instructions are related
because the output data from one instruction is used as input data
to the next instruction.
• Communicational cohesion — are modules whose instructions
accomplish tasks that utilize the same piece(s) of data.
• Procedural cohesion — are modules whose instructions
accomplish different tasks, yet have been combined because there
is a specific order in which the tasks are to be completed.
32
Software Design
Structured Design

 Cohesion:
 There are seven types or levels of cohesion and they are as
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.

33
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.
 The technical design statement should include all data, process,
interface, and geography building block specifications

developed by the designer.

34
Software Design
INFO RM ATIO N SYSTEM S FRAM EW O RK
FOCUS ON FOCUS ON FOCUS ON FO CUS ON

SYST EM S YST EM SYST EM S YST E M
DAT A PROCESSES INT ERFACES GEOGRAP HY
S YST E M
OW NERS
(scope)
S
S YST E M
Y
US ERS
S
T
(requirem ents)
E
M
A
N
A
L Database Scehm a Application Schem a Interface Schem a Network S chem a
Y O r de r Cust om er
New Cust om er
S Form
Pr oce ss i ng
Pr ogr am
PRODUCT
CUST OMER p ro d u c t_ n o [Alp h a (1 0 )] INDEX
Logon O rder Accept ed
T c u s to m e r_ n o [Alp h a (1 0 )] INDEX p ro d u c t_ n a m e [Al p ha (3 2 )] I ni t i at i on Pr oc es s Shut dow n

Change
of
Com m uni cat i ons
Cont r ol l er
St . Loui s
M ai nf r am e
S S YST E M c u s to m e r_ n a m e [Al p h a (3 2 )] u n it_ o f_ m e a s u re [Alp h a (2 )]

c u s to m e r_ ra tin g [Al p h a (1 )] INDEX
u n it_ p ri c e [Re a l(3 ,2 )]
Rout i ne a n O r de r Rout i ne
New O r der Address
b a la n c e _ d u e [Re a l(5 ,2 )] NT Ser ver LA

DE SIGN ERS q u a n ti ty _ a v a i la b l e [I n te g e r(4 )]
G e t an Val i dat e Fi l e a n O rder Hel p Com pl et e O rder For m Fi r st O r der
O r de r a n O r de r O r der PBX NT Ser ver NY
Et her net LAN/ NT
Request
Request O rder Hel p
Pr oduct Et her net LAN/ NT
(facilitation) (specification) ORDER ORDER_ PRODUCT

Chec k
Cus t om er
Chec k
Pr oduct
Che ck
Cr e di t
Rel ea se
an
Lookup
ORDER.o rd e r_ n o Cr edi t Dat a Dat a O r der

Hel p +
o rd e r_ no [Al p h a (1 2 )] INDEX Request Pr oduct Lookup Hel p
o rd e r_ da te [Da te (m m d d y y y y )PRODUCT .p ro d u c t_ n o I ndyAI X Ser ver Cl i ent PC Cl i ent PC
CUST OMER. c u s to m e r_ n o q u a n ti ty _ o rd e re d [I nte g e r(2 ) Cl i ent PC Cl i ent PC

O r de r s Pr oduct Lookup Hel p Com pl et e Pr oduct Ent er net LANAI X/ Lan
Cus t om er s Pr oduct s Lookup M anager
Chapter 12 Chapters 11, 16 Chapters 11, 13, 14, 15 Chapter 11
S YST E M
B UILDE RS
(com ponents)

35

What Is Software Design?: Modular Design Is The Decomposition of A Program Into

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

What Is Software Design?: Modular Design Is The Decomposition of A Program Into

Загружено:

Авторское право:

Доступные форматы

Software Design

What is Software Design?

point of entry and a single point of exit.

geography design specifications for each module.

Copyright Irwin/McGraw-Hill 1998

by breaking up a the program into a hierarchy of modules that

Copyright Irwin/McGraw-Hill 1998

F OCU S ON FO CU S ON FO CUS ON FO CUS ON

S SYS T E M Rout i ne an O r de r Rout i ne

(facilitation ) (specifica tion) Che ck

(com ponen ts)

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

5 DATA A DATA B DATA C

MODULE MODULE MODULE MODULE MODULE

Copyright Irwin/McGraw-Hill 1998

 Data Flow Diagrams of Programs

 Processes need to be added to handle data access and

processes, and processes to implement internal controls.

Copyright Irwin/McGraw-Hill 1998

D DATA STORE A DATA A

Copyright Irwin/McGraw-Hill 1998

BOUNDARY B DETAILS DELETED D DETAILS D DATA STORE D

C DETAILS TO UPDATE UPDATED C DETAILS D DATA STORE C

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

 A sequence of processing for a given input may actually split to

follow different paths.

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

D INPUT G TRANSFORM I OUTPUT

Copyright Irwin/McGraw-Hill 1998

chief” of all other modules.

corresponds to its preceding process on the DFD.

path are included on the structure chart.

INPUT INPUT INPUT

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

INPUT INPUT INPUT CENTRAL

INPUT TRANSFORM TRANSFORM

Copyright Irwin/McGraw-Hill 1998

that corresponds to the succeeding process appearing on the

Copyright Irwin/McGraw-Hill 1998

INPUT INPUT INPUT CENTRAL OUTPUT OUTPUT

INPUT TRANSFORM TRANSFORM OUTPUT

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

identify processes that represent transaction centers.

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

INPUT TRANSACTION DISPLAY

TRANSACTION TRANSACTION TYPE B TRANSACTION

PROCESS PROCESS PROCESS

Copyright Irwin/McGraw-Hill 1998

Copyright Irwin/McGraw-Hill 1998

 Structure Chart Quality Assurance Checks

manageable modules should be done in such a way that the

are evaluated relative to their degree coupling.