Systems analysis and design methods 7th whitten and benley chapter 15

Software DesignStructured Design  Structure chart modules are depicted by named rectangles.. Software DesignStructured Design  Data Flow Diagrams of Programs drawn for the program.. So

Software Design

Introduction

 The chapter will address the following questions:

 How do you factor a program into manageable program modules that can be easily modified and maintained?

 How do you recognize a popular structured design tool for depicting the modular design?

 How do you revise a data flow diagram to reflect necessary program detail prior to program design?

 What are two strategies for developing structure charts by examining data flow diagrams?

 How do you design programs into modules that exhibit loose

coupling and high cohesive characteristics?

 How do you package program design specifications for

communicating program requirements for implementation

 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

 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

FOCUS ON SYSTEM INTERFACES

Software (and Hardware) Technology

Interface Technology

FOCUS ON SYSTEM GEOGRAPHY

Check credit Validate Validate

Release order

Customers

Orders Products order customer number valid order order without valid customer

credit order with valid products approved order

quantity

in stock approved order rejected order

prices picking ticket

Orde r Proce ss ing Program Proces s Initiati on Routine Shutdown

Routine Get an

Order Validate

an Orde r File an Order Chec k

Custo mer

Cr edit Check Produc t

D ata Check

C redit Data Releas e

an Orde r Cus tomers Products O rde rs

Software Design

Structured Design

 The primary tool used in structured design is the structure chart

 Structure charts are used to graphically depict a modular

design of a program

smaller more manageable modules, the hierarchy and organization

of those modules, and the communication interfaces between modules

performed by the module or the internal data used by the module

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

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

Software Design

MODULE B

MODULE A

LIBRARY MODULE A

MODULE G

MODULE F

MODULE E

MODULE D

MODULE

C

SYSTEM MODULE

1

2 3

Software Design

Structured Design

 Data Flow Diagrams of Programs

drawn for the program

modules on a structure chart

used by programmers

maintenance

processes, and processes to implement internal controls.

Software Design

BOUNDARY

A

BOUNDARY B

BOUNDARY B BOUNDARY

A

P

NEW PROCESS B

P NEW PROCESS A

P

PROCESS A (DO NOT EXPAND)

P PROCESS WITH MANY INPUTS &

SCREENED DATA B

FINAL TOTALS

OF DATA A & C

RELEASED DATA D

REVISED XYZ STATUS

REVISED XYZ STATUS RELEASED DATA D

FINAL TOTALS

OF DATA A & C

SCREENED DATA B

SUM OF DATA A AND DATA C DATA C

DATA A

Software Design

P PROCESS X

P PROCESS X

P DELET E

D DETAILS

P READ

A DETAILS

P UPDAT E

A DETAILS

DELETED D DETAILS UPDAT ED C DETAILS NEW B DETAILS

A DETAILS

Software Design

Structured Design

 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

is called the afferent.

transformations of data is called the central transform

efferent

Software Design

P

OUTPUT FUNCT ION C

P INPUT FUNCT ION B

P INPUT FUNCTION D

P OUTPUT FUNCT ION A

P INPUT FUNCT ION C

P OUTPUT FUNCT ION B P

TRANSFORM FUNCT ION A

P TRANSFORM FUNCT ION B

P INPUT FUNCT ION A

BOUNDARY B

Efferent

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

 The steps are as follows:

through the sequence until it reaches a process that does processing (transformation of data) or an output function.

flow is traced backwards through connected processes until a transformation processes is reached (or a data flow is encountered that first represents output)

central transform!

Software Design

P

OUTPUT FUNCTION C

P TRANSFORM FUNCTION A

P TRANSFORM FUNCTION B

P INPUT FUNCTION B

P INPUT FUNCTION D

P OUTPUT FUNCTION A

P INPUT FUNCTION C

P OUTPUT FUNCTION B

P INPUT FUNCTION A

BOUNDARY B

FINISH POINT FOR TRACING INPUT D

Software Design

Structured Design

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

are included on the structure chart

FUNCTION

B

INPUT FUNCTION C

BOSS

G F

E

C

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

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

Software Design

TRANSFORM FUNCTION A

TRANSFORM FUNCTION B

INPUT

FUNCTION

A

INPUT FUNCTION D

INPUT

FUNCTION

B

INPUT FUNCTION C

BOSS

CENTRAL TRANSFORM CONTROLLER

C

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

appear as a module beneath it on the structure chart

Software Design

TRANSFORM FUNCTION A

TRANSFORM FUNCTION B

INPUT

FUNCTION

A

INPUT FUNCTION D

INPUT

FUNCTION

B

OUTPUT FUNCTION A

INPUT FUNCTION C

OUTPUT FUNCTION C

BOSS

CENTRAL TRANSFORM CONTROLLER

OUTPUT FUNCTION B

C

Software Design

P

READ PRODUCT CONTAINED

P

WRITE REPORT ACTIVITY DETAILS

P

READ MEMBER ORDER

P

GET ORDER DETAILS

P FORMAT MEMBER ACTIVITY DETAILS

FORMATED ACTIVITY DETAILS

UNFORMATTED ACTIVITY DETAILS

MEMBER ORDER DETAILS

CUSTOMER AND ORDER DETAILS

PRODUCT

ON AN ORDER DETAILS MEMBER DETAILS

Software Design

MAINTAIN MEMBER

GET

ORDER

DETAILS

CALCULATE ORDER VOLUMES

FORMAT MEMBER ACTIVITY DETAILS

WRITE REPORT ACTIVITY DETAILS

READ

MEMBER

READ MEMBER ORDER

READ PRODUCT CONTAINED

ON ORDER

CUSTOMER AND ORDER DETAILS

CUSTOMER AND ORDER DETAILS

UNFORMATED ACTIVITY DETAILS UNFORMATED ACTIVITY DETAILS

FORMATED ACTIVITY DETAILS

FORMATED ACTIVITY DETAILS

NUMBER

MEMBER ORDER DETAILS

 Transaction analysis is the examination of the DFD to identify

processes that represent transaction centers

transformation upon the incoming data (data flow); rather, it serves

to route the data to two or more processes

directs traffic flow

because they usually appear as a process containing a single incoming data flow to two or more other processes.

T RANSACTION CENT ER A

P

PROCESS TRANSACTION TYPE A

BOUNDARY

A

P

PROCESS TRANSACTION TYPE C

P

DISPLAY RESULT

BOUNDARY B

RESULT TRANSACTION

VALID

T RANSACTION

T YPE C RESULT

TYPE B RESULT

T YPE A RESULT

TRANSACTION

T YPE C

T RANSACTION TYPE B TRANSACT ION

T YPE A

Software Design

TRANSACTION CENTER

PROCESS TRANSACTION TYPE C

PROCESS TRANSACTION TYPE B

PROCESS

TRANSACTION

TYPE A

DISPLAY RESULT

TRANSACTION

TYPE A, B, OR

C RESULT

TYPE A RESULT

TRANSACTION

TYPE A

TYPE B RESULT

TYPE A, B, OR

C RESULT

TRANSACTION TYPE C

TYPE C RESULT

TRANSACTION TYPE B

 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

Software Design

Structured Design

 Structure Chart Quality Assurance Checks

 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

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.

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

Software Design

Structured Design

(from most desirable to least desirable)

• Functional cohesion — are modules whose instruction are related

because they collectively work together to accomplish a single define function

well-• 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

• 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

Software Design

Packaging Program Specifications

 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

Application Schema

Chapters 11, 16

FOCUS ON SYSTEM PROCESSES

Interface Schema

Chapters 11, 13, 14, 15

FOCUS ON SYSTEM INTERFACES

Network Schema

Chapter 11

FOCUS ON SYSTEM GEOGRAPHY

Order Form Help +

Customer Form

Product Lookup

Logon New Customer New Order Order Accepted Change

of Address First Order Request Order Help Order Help Complete Request Lookup Request Product Lookup Help Product Lookup Help Complete

CUSTOMER customer_no [Alpha (10)] INDEX customer_name [Alpha(32)]

customer_rating [Alpha(1)] INDEX balance_due [Real(5,2)]

PRODUCT product_no [Alpha(10)] INDEX product_name [Alpha(32)]

unit_of_measure [Alpha(2)]

unit_price [Real(3,2)]

quantity_available [Integer(4)]

ORDER order_no [Alpha(12)] INDEX order_date [Date(mmddyyyy) CUSTOMER.customer_no

ORDER_PRODUCT ORDER.order_no PRODUCT.product_no quantity_ordered [Integer(2)

Or de r Proce s s in g Program Proce ss

an Or de r Initia tion Routine

Sh utdown Rou tin e

Ge t an

Or de r Validat e File an

Orde r Che ck

Cus t ome r

Cr ed it Check Prod uct Data

St Louis Mainframe

Indy AIX Server

NT Server LA

NT Server NY Communications Controller PBX

Enternet LAN AIX/Lan Manager Ethernet LAN/NT

Ethernet LAN/NT Client P C Client PC

Client PC Client PC