1 / 47

Chapter 13

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.

camilla-farren
Download Presentation

Chapter 13

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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. CEO VP Finance VP Marketing VP Acctg VP Mfg. VP IS Acctg Dept. Plant Operations Finance Dept. Marketing Dept. Excess Span of Control CEO COO CFO CIO IS Director VP Finance VP Acctg VP Marketing VP Mfg. IS Dept. Finance Dept. Acctg Dept. Marketing Dept. Plant Operations Hierarchical Span of Control Figure 13-1. Example of Excess and Hierarchical Span of Control CCSB223/SAD/CHAPTER13

  13. 1.0 Payroll Program 1.1Get Payroll Record 1.2 Edit Payroll Record 1.3 Calculate Gross Pay 1.4 Calculate Deductions 1.5 Calculate Net Pay 1.6 Generate Paycheck 1.7 Update Payroll Record High Fan-Out 1.0 Payroll Program 1.1 Get Payroll Record 1.2 Calculate Employee Pay 1.3 Generate Paycheck 1.4 Update Payroll Record 1.1.1 Edit Payroll Record 1.4.1 Print Payroll Report 1.4.2 Append Payroll File 1.2.1 Calculate Gross Pay 1.2.2 Calculate Taxes 1.2.3 Calculate Deductions 1.2.4 Calculate Net Pay Low Fan-Out Figure 13-2. Example of High and Low Fan-Out Module Structures 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. Table 13-2. Elements of a Hierarchical Structure Diagram CCSB223/SAD/CHAPTER13

  29. Table 13-2. Elements of a Hierarchical Structure Diagram CCSB223/SAD/CHAPTER13

  30. 5.0 4.0 1.0 3.0 2.0 PROCESS DATA EDIT INPUT DATA READ INPUT DATA DISPLAY OUTPUT FORMAT OUTPUT (a) CENTRAL TRANSFORM INPUT STREAM OUTPUT STREAM (b) THE SYSTEM INPUT STREAM OUTPUT STREAM INPUT OUTPUT INPUT OUTPUT GET INPUT DATA PROCESS DATA GENERATE OUTPUT OUTPUT FORMATTED OUTPUT EDIT FLAG RAW DATA RAW DATA FORMATTED OUTPUT FORMAT OUTPUT DISPLAY OUTPUT READ INPUT DATA EDIT INPUT DATA Figure 13-3. Example of a Generalized DFD and Its Associated Hierarchical Structure Diagram 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. (a) SINK 3.0 2.0 1.0 3.0 4.0 2.0 1.0 PROCESS C PROCESS A PROCESS A PROCESS B PROCESS C PROCESS B PROCESS D SOURCE B A B C A C DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE (b) SINK SOURCE Figure 13-4. Expanding Multi-Function Processes on a DFD for Conversion to a Structure Diagram CCSB223/SAD/CHAPTER13

  34. (a) New Data Deleted Data Updated Data SOURCE (b) 4.0 5.0 2.0 1.0 1.0 3.0 SOURCE ADD NEW DATA PROCESS PROCESS UPDATEDATA DELETEDATA READ DATA B A B C D C A DC DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE DATA STORE Figure 13-5. Example of Adding Data Access and Maintenance Processes to a DFD 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: • Those that perform either input or input editing function • Those that perform calculations or process data • 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. 8.0 3.0 4.0 2.0 10.0 1.0 6.0 7.0 9.0 5.0 PROCESS PROCESS PROCESS 9.0 PROCESS PROCESS PROCESS PROCESS PROCESS 10.0 PROCESS 5.0 3.0 6.0 2.0 4.0 1.0 PROCESS 8.0 7.0 Afferent Transform Efferent MAIN CONTROL AFFERENT TRANSFORM EFFERENT Figure 13-6. The Categorization into Afferent, Transform, and Efferent Processes -Implies a Hierarchical Control Structure 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 • 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 • 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 • 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 • The development of a good structure chart requires a great deal of effort • 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 CCSB223/SAD/CHAPTER13

More Related