CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals.
-
Upload
joanna-copeland -
Category
Documents
-
view
220 -
download
2
Transcript of CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals.
CCSB223/SAD/CHAPTER13 1
Chapter 13
Designing the System Internals
CCSB223/SAD/CHAPTER13 2
Learning Objectives Understand the concepts of
structured and modular systems design
Learn the principles and guidelines associated with good systems design practices
CCSB223/SAD/CHAPTER13 3
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
CCSB223/SAD/CHAPTER13 4
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
CCSB223/SAD/CHAPTER13 5
Modular Design Decomposes a large, complex
software application into smaller, interrelated components call modules
CCSB223/SAD/CHAPTER13 6
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
CCSB223/SAD/CHAPTER13 7
Principles of Good Internal Design
To create a system Easy to read and understand Easy to code and revise Easy to maintain
CCSB223/SAD/CHAPTER13 8
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
CCSB223/SAD/CHAPTER13 9
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
CCSB223/SAD/CHAPTER13 10
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
CCSB223/SAD/CHAPTER13 11
Module Span A single module does not have
control over more than five to seven subordinate modules
Low fan-out design
CCSB223/SAD/CHAPTER13 12
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
CCSB223/SAD/CHAPTER13 13
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
CCSB223/SAD/CHAPTER13 14
Module Cohesion A measure of completeness Every statement in a module
should relate to the identified function of that module
CCSB223/SAD/CHAPTER13 15
Types of Cohesion Functional Cohesion
Modules accomplish a single, well-defined task or function
CCSB223/SAD/CHAPTER13 16
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
CCSB223/SAD/CHAPTER13 17
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
CCSB223/SAD/CHAPTER13 18
Types of Cohesion Procedural Cohesion
Instruction set in a module performs multiple functions that have a specific sequence in which they must be performed
CCSB223/SAD/CHAPTER13 19
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
CCSB223/SAD/CHAPTER13 20
Types of Cohesion Logical Cohesion
Instructions are grouped together only because they appear to fall into the same logical class of functions
CCSB223/SAD/CHAPTER13 21
Types of Cohesion Coincidental Cohesion
Instructions within the module have little or no relationship
CCSB223/SAD/CHAPTER13 22
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
CCSB223/SAD/CHAPTER13 23
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
CCSB223/SAD/CHAPTER13 24
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
CCSB223/SAD/CHAPTER13 25
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
CCSB223/SAD/CHAPTER13 26
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
CCSB223/SAD/CHAPTER13 27
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
CCSB223/SAD/CHAPTER13 28
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
CCSB223/SAD/CHAPTER13 29
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
CCSB223/SAD/CHAPTER13 30
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
CCSB223/SAD/CHAPTER13 31
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
CCSB223/SAD/CHAPTER13 32
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
CCSB223/SAD/CHAPTER13 33
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
CCSB223/SAD/CHAPTER13 34
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
CCSB223/SAD/CHAPTER13 35
DFD Conversion Strategies Transform Analysis Transaction Analysis
CCSB223/SAD/CHAPTER13 36
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
CCSB223/SAD/CHAPTER13 37
Transform Analysis DFDs are partitioned into three
categories Afferent processes Efferent processes Central transform
CCSB223/SAD/CHAPTER13 38
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
CCSB223/SAD/CHAPTER13 39
Figure 13-7. First Draft Structure Diagram From a Simple DFD
CCSB223/SAD/CHAPTER13 40
Figure 13-8. Detailed Structure Diagram
CCSB223/SAD/CHAPTER13 41
Transaction Analysis Examines the DFD for the purpose
of identifying processes that represent transaction centers
CCSB223/SAD/CHAPTER13 42
Figure 13-9. Transaction Analysis Approach to Deriving a Structure Diagram
CCSB223/SAD/CHAPTER13 43
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
CCSB223/SAD/CHAPTER13 44
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
CCSB223/SAD/CHAPTER13 45
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 -
CCSB223/SAD/CHAPTER13 46
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.
CCSB223/SAD/CHAPTER13 47
Chapter 13
End of Chapter