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

Software Design Introduction  The chapter will address the following questions:       How you factor a program into manageable program modules that can be easily modified and maintained? How you recognize a popular structured design tool for depicting the modular design? How 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 you design programs into modules that exhibit loose coupling and high cohesive characteristics? How you package program design specifications for communicating program requirements for implementation Software Design What is Software Design?  Introduction  Software design consists of two components, modular design and packaging  Modular design is the decomposition of a program into modules  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 Software Design Structured Design  Introduction  Structured design was developed by Ed Yourdon and Larry Constantine  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 Software Design INFORMATION SYSTEMS FRAMEWORK FOCUS ON SYSTEM DATA FOCUS ON SYSTEM PROCESSES FOCUS ON SYSTEM INTERFACES SYSTEM OWNERS (scope) Business Processes reject ed order Customers S Y S T E M A N A L Y S T S (facilitation) SYSTEM USERS credit Check credit cust omer number order (requirements) Val idate customer order wit h valid product s valid order order wit hout valid customer approved order Validat e product s Orders approved order prices Products quantit y in st ock Release order picking ticket Chapters 5, Application Schema Orde r Proce ss ing Program SYSTEM DESIGNERS (specification) Initiati on Routine Proces s an Orde r Get an Order Validate an Orde r Chec k Custo mer Cr edit Check Produc t D ata Cus tomers Products Shutdown Routine File an Order Check C redit Data Releas e an Orde r O rde rs Chapters 11, 16 SYSTEM BUILDERS (components) Software (and Hardware) Technology Interface Technology FOCUS ON SYSTEM GEOGRAPHY Software Design Structured Design  Structure Charts  The primary tool used in structured design is the structure chart  Structure charts are used to graphically depict a modular design of a program • Specifically, they show how the program has been partitioned into smaller more manageable modules, the hierarchy and organization of those modules, and the communication interfaces between modules • Structure charts, however, not show the internal procedures performed by the module or the internal data used by the module Software Design Structured Design  Structure Charts      Structure chart modules are depicted by named rectangles Structure chart modules are presumed to execute in a top-tobottom, 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  Structure Charts   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 DATA A SYST EM MODULE DATA B MODULE A FLAG A DATA A MODULE B 4 FLAG B DATA B MODULE C DATA C MODULE D MODULE E DATA B LIBRARY MODULE A DATA D FLAG B MODULE F DATA B AND C/D MODULE G Software Design Structured Design  Data Flow Diagrams of Programs     Structured design requires that data flow diagrams (DFDs) first be drawn for the program Processes appearing on the logical, elementary DFDs may represent modules on a structure chart Logical DFDs need to be revised to show more detail in order to be used by programmers The following revisions may be necessary:  Processes appearing on the DFD should one function  Processes need to be added to handle data access and maintenance  DFDs must be revised to include editing and error handling processes, and processes to implement internal controls Software Design D DATA STORE A DATA A P P BOUNDARY A DATA C PROCESS WITH MANY INPUTS & OUTPUT S SUM OF DATA A AND DATA C PROCESS A (DO NOT EXPAND) BOUNDARY B FINAL TOTALS OF DATA A & C P D DATA STORE B SCREENED DATA B DATA B RELEASED DATA D PROCESS B (DO NOT EXPAND) REVISED XYZ STATUS D DATA STORE C EXPANDED (OR REPLACED BY) D DATA STORE A DATA A P P BOUNDARY A DATA C NEW PROCESS A SUM OF DATA A AND DATA C P D DATA STORE B DATA B NEW PROCESS B PROCESS A P SCREENED DATA B BOUNDARY B FINAL TOTALS OF DATA A & C RELEASED DATA D PROCESS B REVISED XYZ STAT US D 10 DATA STORE C Software Design D P MEMBER ORDER DETAILS MEMBER READ MEMBER ORDER MEMBER DETAILS D MEMBER ORDER ACTIVITY P D MEMBER ORDER MEMBER ORDER DETAILS READ MEMBER WRITE REPORT ACTIVITY DETAILS P MEMBER DETAILS D PRODUCT ON AN ORDER PRODUCT ON AN ORDER DETAILS P P FORMATED ACTIVITY DETAILS GET ORDER DETAILS PRODUCT ON AN ORDER DETAILS P CUSTOMER AND ORDER DETAILS READ PRODUCT CONTAINED ON ORDER P CALCULATE ORDER VOLUMES 23 UNFORMATTED ACTIVITY DETAILS FORMAT MEMBER ACTIVITY DETAILS ACTIVITY REPORT FILE Software Design MAINTAIN MEMBER CUSTOMER AND ORDER DETAILS CUSTOMER AND ORDER DETAILS GET ORDER DETAILS UNFORMATED ACTIVITY DETAILS UNFORMATED ACTIVITY DETAILS MEMBER DETAILS MEMBER NUMBER READ MEMBER READ MEMBER ORDER ORDER NUMBER FORMATED ACTIVITY DETAILS FORMAT MEMBER ACTIVITY DETAILS CALCULATE ORDER VOLUMES MEMBER ORDER DETAILS FORMATED ACTIVITY DETAILS PRODUCT ON AN ORDER DETAILS READ PRODUCT CONTAINED ON ORDER 24 WRITE REPORT ACTIVITY DETAILS Software Design Structured Design  Transaction Analysis  An alternative structured design strategy for developing structure charts is called transaction analysis  Transaction analysis is the examination of the DFD to identify processes that represent transaction centers • A transaction center is a process that does not actual transformation upon the incoming data (data flow); rather, it serves to route the data to two or more processes – You can think of a transaction center as a traffic cop that directs traffic flow – Such processes are usually easy to recognize on a DFD, because they usually appear as a process containing a single incoming data flow to two or more other processes 25 Software Design BOUNDARY A T RANSACT ION BOUNDARY B P P INPUT FUNCT ION A PROCESS T RANSACT ION T YPE A VALID T RANSACT ION T RANSACT ION T YPE A T YPE A RESULT P P T RANSACT ION T YPE B PROCESS T RANSACT ION T YPE B P T YPE B RESULT T RANSACT ION CENT ER A T RANSACT ION T YPE C P PROCESS T RANSACT ION T YPE C 26 RESULT T YPE C RESULT DISPLAY RESULT Software Design BOSS T RANSACT ION T YPE A, B, OR C RESULT INPUT FUNCT ION A T YPE A, B, OR C RESULT VALID T RANSACTION T RANSACT ION CENT ER T YPE A RESULT T RANSACT ION T YPE A PROCESS T RANSACTION T YPE A DISPLAY RESULT T YPE C RESULT T RANSACTION T YPE B T YPE B RESULT PROCESS T RANSACT ION T YPE B 27 T RANSACT ION T YPE C PROCESS T RANSACTION T YPE C Software Design Structured Design  Transaction Analysis  The primary difference between transaction analysis and transform analysis is that transaction analysis recognizes that modules can be organized around the transaction center rather than a transform center 28 Software Design Structured Design  Structure Chart Quality Assurance Checks  Coupling:  In structured design, the decomposition of a program in manageable modules should be done in such a way that the modules are independent as possible from one another  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 29 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 30 Software Design Structured Design  Structure Chart Quality Assurance Checks  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 31 Software Design Structured Design  Structure Chart Quality Assurance Checks  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 32 Software Design Structured Design  Structure Chart Quality Assurance Checks  Cohesion:  There are seven types or levels of cohesion and they are as follows: (from most desirable to least desirable) • Functional cohesion — are modules whose instruction are related because they collectively work together to accomplish a single welldefine function • 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 33 Software Design Structured Design  Structure Chart Quality Assurance Checks  Cohesion:  There are seven types or levels of cohesion and they are as follows: (continued) • 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 34 Software Design Packaging Program Specifications  Introduction  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 35 Software Design INFORMATION SYSTEMS FRAMEWORK FOCUS ON SYSTEM DATA FOCUS ON SYSTEM PROCESSES FOCUS ON SYSTEM INTERFACES Database Scehma Application Schema FOCUS ON SYSTEM GEOGRAPHY SYSTEM OWNERS (scope) S Y S T E M A N A L Y S T S (facilitation) SYSTEM USERS (requirements) SYSTEM DESIGNERS (specification) Interface Schema Or de r Proce s s in g Program PRODUCT CUSTOMER product_no [Alpha(10)] INDEX customer_no [Alpha (10)] INDEXproduct_name [Alpha(32)] customer_name [Alpha(32)] unit_of_measure [Alpha(2)] customer_rating [Alpha(1)] INDEX unit_price [Real(3,2)] balance_due [Real(5,2)] quantity_available [Integer(4)] Proce ss an Or de r Sh utdown Rou tin e Ge t an Or de r Validat e an Or de r File an Orde r Order Accepted Change of Address New Order Chapter 12 Communicat ions Cont roller St Louis Mainframe NT Server LA Order Help Complete Order Form Request Order Help ORDER_PRODUCT ORDER ORDER.order_no order_no [Alpha(12)] INDEX order_date [Date(mmddyyyy) PRODUCT.product_no quantity_ordered [Integer(2) CUSTOMER.customer_no Network Schema Customer Form New Customer Logon Initia tion Routine Che ck Cus t ome r Cr ed it Check Prod uct Data C hec k Cr edit D ata Re le ase an Orde r Help + First O rder Request Product Lookup PBX NT Server NY Et hernet LAN/NT Et hernet LAN/NT Request Product Lookup Help Indy AIX Server Cus tome rs Products Or de rs Chapters 11, 16 SYSTEM BUILDERS (components) 36 Product Lookup Help Complete Product Lookup Chapters 11, 13, 14, 15 Client P C Client PC Client PC Ent ernet LAN AIX/Lan Manager Chapter 11 Client PC Software Design Summary    Introduction What is Software Design? Structured Design 37 ... RANSACTION T YPE C Software Design Structured Design  Transaction Analysis  The primary difference between transaction analysis and transform analysis is that transaction analysis recognizes that... to be added to handle data access and maintenance  DFDs must be revised to include editing and error handling processes, and processes to implement internal controls Software Design D DATA STORE... DETAILS Software Design Structured Design  Transaction Analysis  An alternative structured design strategy for developing structure charts is called transaction analysis  Transaction analysis is