ccsb223/sad/chapter131 chapter 13 designing the system internals

CCSB223/SAD/CHAPTER13 1

Chapter 13

Designing the System Internals


Learning Objectives Understand the concepts of

structured and modular systems design

Learn the principles and guidelines associated with good systems design practices


Learning Objectives Explain the concepts of factoring,

module size, coupling, and cohesion

Learn to identify and correct for the various types of undesirable cohesion and module coupling


Learning Objectives Understand the concepts behind

the hierarchical structure diagram Derive a structure diagram from a

DFD using either a transform or a transaction analysis approach


Modular Design Decomposes a large, complex

software application into smaller, interrelated components call modules


Modular Design Module

A group of executable instructions with a single point of entry and a single point of exit

Designed to perform its functions independently from all other modules

Should be designed to perform a single function

Minimize the dependency among modules


Principles of Good Internal Design

To create a system Easy to read and understand Easy to code and revise Easy to maintain


Design Guideline

Explanation

Factor The system should be factored, or decomposed, into small modules which conform to both the size and cohesion guidelines of good design.

Span of Control

No parent module should be given control over more than 5 to 7 child, or subordinate, modules.

Coupling The extent to which modules are dependent on each other should be minimized such that the amount of communication between dependent modules is also minimized. Ideally, module communication should occur only via passed data elements and informational flags.

Size A reasonable size for a single module is considered to be between 50 and 100 lines of executable code.

Cohesion The instructions contained within a module should pertain only to that function. This suggests that a well-factored module should be describable in a few simple words with no “and” or “or” in the module name.

Shared Use Wherever possible, a child module should be called by multiple parent modules.

Table 13-1. Guidelines for Good System Design


System Factoring Bottom-up Approach

Identifies the processes that need to be a part of the system

Codes each identified process as a module that interface with all other process modules


System Factoring Top-down Approach

The system is first viewed in the broadest possible sense

Then the system is decomposed into subsystems that work together to efficiently and effectively reach the stated objectives for the overall system


Module Span A single module does not have

control over more than five to seven subordinate modules

Low fan-out design


Figure 13-1. Example of Excess and Hierarchical Span of Control

CEO

VPFinance

Finance Dept.

VP Marketing

Marketing Dept.

VPAcctg

Acctg Dept.

CEO

VPIS

Plant Operations

VPMfg.

Excess Span of Control

VPFinance

Finance Dept.

VPAcctg

Marketing Dept.

VPMarketing

Acctg Dept.

ISDirector

Plant Operations

VPMfg.

CFO CIO COO

ISDept.

Hierarchical Span of Control


Figure 13-2. Example of High and Low Fan-Out Module Structures

1.0Payroll

Program

1.4Calculate

Deductions

1.0Payroll

Program

1.2.1Calculate Gross Pay

1.4Update Payroll

Record

1.5CalculateNet Pay

1.6Generate Paycheck

1.7Update Payroll

Record

1.3Calculate Gross Pay

1.2Edit Payroll

Record

1.1Get Payroll

Record

1.2.2Calculate

Taxes

1.2.3Calculate

Deductions

1.2.4CalculateNet Pay

1.4.1Print

Payroll Report

1.4.2Append

Payroll File

1.1.1Edit Payroll

Record

1.3GeneratePaycheck

1.2Calculate

Employee Pay

1.1Get Payroll

Record

High Fan-Out

Low Fan-Out


Module Cohesion A measure of completeness Every statement in a module

should relate to the identified function of that module


Types of Cohesion Functional Cohesion

Modules accomplish a single, well-defined task or function


Types of Cohesion Sequential Cohesion

The relationship between one instruction and the next in a given module

The result or output of one instruction becomes the input for the next instruction


Types of Cohesion Communicational Cohesion

Two or more tasks within the same module use the same piece of data

Sequence of those tasks is not critical


Types of Cohesion Procedural Cohesion

Instruction set in a module performs multiple functions that have a specific sequence in which they must be performed


Types of Cohesion Temporal Cohesion

Instructions were grouped together because of some common relationship based on time

They all need to be executed at about the same point in time


Types of Cohesion Logical Cohesion

Instructions are grouped together only because they appear to fall into the same logical class of functions


Types of Cohesion Coincidental Cohesion

Instructions within the module have little or no relationship


Module Coupling The extent of to which two or more

program modules are interdependent

The goal is to create modules that are completely independent or that display loose coupling


Types of Coupling Data Couple

The dependency between the two modules is limited to the fact they pass data between each other

Control Coupling One module passes control

information or flag to another module


Types of Coupling Stamp Couple

Data are passed between modules in the form of data structure or entire record

Any change to the data structure of file sequence could also have an adverse effect on module execution


Types of Coupling Common Coupled

Two modules both refer to the same global data area

Content Coupling One module actually modifies the

procedural content of another module


Hierarchical Structure Diagram Also called Structure Chart Illustrates the relationship of the

modules to each other Displays the flow and processing of

data between and within the various modules of the system in hierarchical form


DFDs versus Structure Charts The intended audience for the DFD

is composed of business managers and end users

The audience for the structure chart is entirely made up of application programmers


Element Name Element Characteristics Element Symbol Module

Depicts a logical piece of program

Name ID Number Can be superordinate or

subordinate

Library Module

Depicts a logical piece of program that may be repeated within the chart

Name ID Number

Conditional

Indicates that subordinate modules are invoked by the superordinate module based on some condition

Loop

Indicates that one or more modules are repeated

Symbol is drawn around the lines associated with the repeating modules

2.9

CALCULATE CREDIT HOURS

3.2

CALCULATE REORDER

POINT

Table 13-2. Elements of a Hierarchical Structure Diagram


Element Name Element Characteristics Element Symbol

Control Couple

Indicates the passing of a message or system flag being passed from one module to another

Identified by the filled in circle at its beginning

Names the message or flag being passed

Data Couple

Indicates the passing of a data being passed from one module to another

Identified by the empty circle at its beginning

Names the data type being passed

On-Page Connector

Indicates that certain parts of the diagram are continued on another page

Off-Page Connector

Indicates that certain parts of the diagram are continued in another location on the same page of the diagram

Print Reorder Report

Print Reorder Report

Table 13-2. Elements of a Hierarchical Structure Diagram


Figure 13-3. Example of a Generalized DFD and Its Associated Hierarchical Structure Diagram

READINPUTDATA

1.0

EDITINPUTDATA

2.0

PROCESSDATA

3.0

FORMATOUTPUT

4.0

DISPLAYOUTPUT

5.0

INPUT STREAM OUTPUT STREAM

CENTRAL TRANSFORM

(a)

(b)

THESYSTEM

GENERATEOUTPUT

PROCESSDATA

GETINPUTDATA

DISPLAYOUTPUT

FORMATOUTPUT

EDITINPUTDATA

READINPUTDATA

RAW DATA

EDIT FLAG

INPUT OUTPUT

OUTPUT

FORMATTED OUTPUT

FORMATTED OUTPUT

RAW DATA

INPUT OUTPUT

INPUT STREAM

OUTPUT STREAM


Deriving the Hierarchical Structure Diagram

Preparing the DFDs Insure all processes on the DFD

perform only one function Mono-functionality Each new process has either a single

input with multiple outputs or a single output from multiple inputs


Deriving the Hierarchical Structure Diagram

Preparing the DFDs Add those processes that are

associated with reading, modifying, and deleting data from the various data stores on the DFD

Add processes focused on exceptions, error trapping, and internal control issues


Figure 13-4. Expanding Multi-Function Processes on a DFD for Conversion to a Structure Diagram

1.0

PROCESSA

2.0

PROCESSB

3.0

PROCESSC

1.0

PROCESSA

2.0

PROCESSB

3.0

PROCESSC

4.0

PROCESSD

SOURCE

B DATA STORE

A DATA STORE

B DATA STORE

C DATA STORE

A DATA STORE

C DATA STORE

(a)

(b)

SINK

SOURCE

SINK


Figure 13-5. Example of Adding Data Access and Maintenance Processes to a DFD

1.0

PROCESS

1.0

READDATA

2.0

PROCESS

4.0

DELETEDATA

5.0

UPDATEDATA

SOURCE

B DATA STORE

A DATA STORE

B DATA STORE

C DATA STORE

A DATA STORE

C DATA STORE

(a)

(b)

SOURCE

D DATA STORE

New Data

Deleted Data

Updated Data

3.0

ADDNEW DATA

DC DATA STORE


DFD Conversion Strategies Transform Analysis Transaction Analysis


Transform Analysis The various processes are divided

into three categories:1. Those that perform either input or

input editing function2. Those that perform calculations or

process data3. Those that serve to create or finalize

system output


Transform Analysis DFDs are partitioned into three

categories Afferent processes Efferent processes Central transform


Figure 13-6. The Categorization into Afferent, Transform, and Efferent Processes -Implies a Hierarchical Control Structure

1.0

PROCESS

MAIN CONTROL

3.0

PROCESS

2.0

PROCESS

4.0

PROCESS

5.0

PROCESS

6.0

PROCESS

7.0

PROCESS

9.0

PROCESS

8.0

PROCESS

10.0

PROCESS

Afferent EfferentTransform

AFFERENT TRANSFORM EFFERENT

1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0


Figure 13-7. First Draft Structure Diagram From a Simple DFD


Figure 13-8. Detailed Structure Diagram


Transaction Analysis Examines the DFD for the purpose

of identifying processes that represent transaction centers


Figure 13-9. Transaction Analysis Approach to Deriving a Structure Diagram


Advantages of Structure Chart

1. It allows the evolution of the actual program code to occur in the same logical step-by-step manner that was employed in constructing the logical DFD

2. By arranging the program into a hierarchical set of modules, the program structure becomes both well-organized and easily manageable


Advantages of Structure Chart

3. Allows for a detailed quality analysis of the various modules within the system with regard to appropriate coupling and cohesion

• Any error or future upgrades are localized and easier to maintain


Disadvantages of Structure Chart

1. The development of a good structure chart requires a great deal of effort

2. Most modern CASE tools do not yet completely facilitate the conversion of a leveled set of DFDs into a finished structure diagram

- End -


Chapter Summary The conversion of the logical DFDs

into a usable set of structure charts has transformed our system from a logical sequence of processes and data flows into a well-structured set of modules that are related in both an effective and efficient manner.


Chapter 13

End of Chapter

ccsb223/sad/chapter131 chapter 13 designing the system internals

Documents

module size

child module

module communication

system easy

wellfactored module

system factoringbottom

approachthe system

system codes