CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals

CCSB223/SAD/CHAPTER132 Learning Objectives Understand the concepts of structured and modular systems design Learn the principles and guidelines associated with good systems design practices

CCSB223/SAD/CHAPTER133 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/CHAPTER134 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/CHAPTER135 Modular Design Decomposes a large, complex software application into smaller, interrelated components call modules

CCSB223/SAD/CHAPTER136 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/CHAPTER137 Principles of Good Internal Design To create a system Easy to read and understand Easy to code and revise Easy to maintain

CCSB223/SAD/CHAPTER138 Table Guidelines for Good System Design

CCSB223/SAD/CHAPTER139 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/CHAPTER1310 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/CHAPTER1311 Module Span A single module does not have control over more than five to seven subordinate modules Low fan-out design

CCSB223/SAD/CHAPTER1312 Figure Example of Excess and Hierarchical Span of Control CEO VP Finance Finance Dept. VP Marketing Marketing Dept. VP Acctg Acctg Dept. CEO VP IS Plant Operations VP Mfg. Excess Span of Control VP Finance Finance Dept. VP Acctg Marketing Dept. VP Marketing Acctg Dept. IS Director Plant Operations VP Mfg. CFOCIO COO IS Dept. Hierarchical Span of Control

CCSB223/SAD/CHAPTER1313 Figure Example of High and Low Fan-Out Module Structures 1.0 Payroll Program 1.4 Calculate Deductions 1.0 Payroll Program Calculate Gross Pay 1.4 Update Payroll Record 1.5 Calculate Net Pay 1.6 Generate Paycheck 1.7 Update Payroll Record 1.3 Calculate Gross Pay 1.2 Edit Payroll Record 1.1 Get Payroll Record Calculate Taxes Calculate Deductions Calculate Net Pay Print Payroll Report Append Payroll File Edit Payroll Record 1.3 Generate Paycheck 1.2 Calculate Employee Pay 1.1 Get Payroll Record High Fan-Out Low Fan-Out

CCSB223/SAD/CHAPTER1314 Module Cohesion A measure of completeness Every statement in a module should relate to the identified function of that module

CCSB223/SAD/CHAPTER1315 Types of Cohesion Functional Cohesion Modules accomplish a single, well-defined task or function

CCSB223/SAD/CHAPTER1316 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/CHAPTER1317 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/CHAPTER1318 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/CHAPTER1319 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/CHAPTER1320 Types of Cohesion Logical Cohesion Instructions are grouped together only because they appear to fall into the same logical class of functions

CCSB223/SAD/CHAPTER1321 Types of Cohesion Coincidental Cohesion Instructions within the module have little or no relationship

CCSB223/SAD/CHAPTER1322 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/CHAPTER1323 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/CHAPTER1324 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/CHAPTER1325 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/CHAPTER1326 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/CHAPTER1327 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/CHAPTER1328 Table Elements of a Hierarchical Structure Diagram

CCSB223/SAD/CHAPTER1329 Table Elements of a Hierarchical Structure Diagram

CCSB223/SAD/CHAPTER1330 Figure Example of a Generalized DFD and Its Associated Hierarchical Structure Diagram READ INPUT DATA 1.0 EDIT INPUT DATA 2.0 PROCESS DATA 3.0 FORMAT OUTPUT 4.0 DISPLAY OUTPUT 5.0 INPUT STREAMOUTPUT STREAM CENTRAL TRANSFORM (a) (b) THE SYSTEM GENERATE OUTPUT PROCESS DATA GET INPUT DATA DISPLAY OUTPUT FORMAT OUTPUT EDIT INPUT DATA READ INPUT DATA RAW DATA EDIT FLAG INPUTOUTPUT FORMATTED OUTPUT RAW DATA INPUT OUTPUT INPUT STREAM OUTPUT STREAM

CCSB223/SAD/CHAPTER1331 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/CHAPTER1332 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/CHAPTER1333 Figure Expanding Multi-Function Processes on a DFD for Conversion to a Structure Diagram 1.0 PROCESS A 2.0 PROCESS B 3.0 PROCESS C 1.0 PROCESS A 2.0 PROCESS B 3.0 PROCESS C 4.0 PROCESS D SOURCE B DATA STORE A B C A C (a) (b) SINK SOURCE SINK

CCSB223/SAD/CHAPTER1334 Figure Example of Adding Data Access and Maintenance Processes to a DFD 1.0 PROCESS 1.0 READ DATA 2.0 PROCESS 4.0 DELETE DATA 5.0 UPDATE DATA SOURCE B DATA STORE A B C A C (a) (b) SOURCE D DATA STORE New Data Deleted Data Updated Data 3.0 ADD NEW DATA DC DATA STORE

CCSB223/SAD/CHAPTER1335 DFD Conversion Strategies Transform Analysis Transaction Analysis

CCSB223/SAD/CHAPTER1336 Transform Analysis The various processes are divided into three categories: 1. Those that perform either input or input editing function 2. Those that perform calculations or process data 3. Those that serve to create or finalize system output

CCSB223/SAD/CHAPTER1337 Transform Analysis DFDs are partitioned into three categories Afferent processes Efferent processes Central transform

CCSB223/SAD/CHAPTER1338 Figure 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 AfferentEfferent Transform AFFERENT TRANSFORMEFFERENT

CCSB223/SAD/CHAPTER1339 Figure First Draft Structure Diagram From a Simple DFD

CCSB223/SAD/CHAPTER1340 Figure Detailed Structure Diagram

CCSB223/SAD/CHAPTER1341 Transaction Analysis Examines the DFD for the purpose of identifying processes that represent transaction centers

CCSB223/SAD/CHAPTER1342 Figure Transaction Analysis Approach to Deriving a Structure Diagram

CCSB223/SAD/CHAPTER1343 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/CHAPTER1344 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/CHAPTER1345 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/CHAPTER1346 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/CHAPTER1347 Chapter 13 End of Chapter