1. McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic

2. 5-2 Learning Objectives Understand the basic concepts of logical process modeling Draw DFDs using specific rules and components to depict logical process models Understand the hierarchy of DFDs using the concept of functional decomposition

3. 5-3 Learning Objectives Understand the differences between DFDs and flowcharts. Understand the four basic logic modeling techniques of structured English, decision tables, decision trees, and state-transition diagrams and be able to select the appropriate tool for the conditions

4. 5-4 Logical Process Modeling The “What” versus the “How” –Logical Model versus Physical Model Physical model: what the system and exactly how it does it Logical Model: What a system is or does without any of the constraints of how that might be accomplished

5. 5-5 Benefits of Logical Model Reduces the risk of overlooking important business requirement due to the analyst becoming preoccupied with the technical elements Reduces the biases associated with the way the current system is implemented Analysts can communicate with users easily

6. 5-6 Data Flow Diagram A graphical tool that depicts the sequence of processes and functions contained within a specific system boundary and the flow of data through that system

7. 5-7 DFD Symbols Four basic symbols –Process –Data Flow –Data Store –External Entity Two popular symbol sets –Gane and Sarson –DeMarco and Yourson

8. 5-8 Figure 5-1. Comparison of DFD Symbols

9. 5-9 DFD Components Data Flow –Represented by a line with arrowhead indicating direction of flow –Data in motion –Use noun to name the data content

10. 5-10 DFD Components Data Store –Represents a repository for data recorded within the system –Data at rest

11. 5-11 DFD Components Process –Transform data into another form –Process inputs to create a set of output data flows –Using the input as output in its same basic form –Reorganize the inputs

12. 5-12 External agent –Someone or something interacts with the system but resides outside the system boundary Source: serve as the origin of data flowing into the system Sink: represents a destination for data flowing out from the system DFD Components

13. 5-13 Figure 5-2. Data Flow Diagram for Logical Apple-Peeling Process

14. 5-14 DFD Hierarchy System is composed of a decomposable set of subsystems By creating a top-down decomposed hierarchy of diagrams, each with a greater degree of detail than the last, we can understand the complexity of the system

15. 5-15 Figure 5-3. Numbering Convention for DFD Decomposition

16. 5-16 Context Level Diagram Shows the system boundary Contain only one process, labeled with the name of the system, assigned a zero as its identifier Data flow connects the process to its source and sink entities

17. 5-17 Figure 5-4. Context-Level Diagram for Employee Payroll System

18. 5-18 Level-0 DFD More detail than the context diagram –Major processes within the system –Sequence of those processes –Data stores accessed by those processes –Source and sink entities that interact with the system

19. 5-19 Figure 5-5. Level-0 Data Flow Diagram for Employee Payroll System

20. 5-20 Level-1 through Level-n DFD Level-0 is decomposed to a required level of detail for all processes All data flows entering or leaving a parent process must also be shown as entering or leaving the set of child processes No more than seven levels should be developed When a process has been fully decomposed to the desired level of detail, it is referred to as a functional primitive

21. 5-21 Figure 5-6. Level-1 Data Flow Diagram for Employee Payroll System

22. 5-22 Figure 5-7. Excerpt from Fully Decomposed DFD fro Employee Payroll System

23. 5-23 DFDs versus Flowcharts Flow chart –a diagram that specifies all programs, inputs, outputs, and data store accesses and retrievals –depicts the specific flow of control through an IS

24. 5-24 Figure 5-8. ANSI System Flowchart Symbology

25. 5-25 Figure 5-9. System Flowchart Example

26. 5-26 DFD Guidelines Establish system boundary. Label processes and data flows with sufficient information. Think WHAT and not HOW. Think data FLOW, not control.

27. 5-27 Analyzing and Using the DFD Constant verification is the key to an accurate set of DFDs. DFD should be carefully reviewed with end users. DFD should be checked against the stated system objectives.

28. 5-28 Modeling Process Logic A technique used to model the sequential or temporal logic contained within the processes –Structured English –Decision tables –Decision Trees –State-Transition Diagram

29. 5-29 Structured English Use three logic constructs –Repetition –Decision –Sequential Each process must have only one entrance and only one exit

30. 5-30 Table 5-2. Structured English representation of Common Procedural Structures

31. 5-31 Table 5-2. Structure English representation of common Procedural Structures

32. 5-32 Table 5-3. Structure English Examples for process 4.0

33. 5-33 Figure 5-10. Functional-Primitive Decomposition for the Process 4.0

34. 5-34 Decision Tables A diagram of all the logic and possible outcomes associated with a particular process –Process rules –Condition stubs –Action stubs

35. 5-35 Decision Tables Process rule and condition stubs – represent the specific rule when making a decision Action stubs –represent all possible courses of action associated with a given set of conditions and rules

36. 5-36 Table 5-4. Structured English logic for Insurance Rating System

37. 5-37 Table 5-5. Decision Table for Insurance Rating System

38. 5-38 Table 5-6. Procedure for Constructing Decision Tables

39. 5-39 Decision Trees Graphical representation of logic in a “tree trunk and branches” shape Decision Points (nodes) –the sequence in which the decision are made Actions –description of action to be taken are connected to a node by an arrow

40. 5-40 Figure 5-11. The basic Structure of a NonProbabilistic Decision Tree

41. 5-41 Figure 5-12. Decision Tree for Insurance Rating System

42. 5-42 State Transition Diagram Models how two or more processes are related to each other in time Illustrates the various states a system component can take in relation to the events or conditions that cause a change from one state to another

43. 5-43 State Transition Diagram State: a condition of existence that can be taken by a system component When an event occurs, a transition triggered, and the system component assumes a different state, thus causing an action to occur

44. 5-44 Figure 5-13. State-Transition Diagram for generic Three-State Event

45. 5-45 State Transition Diagram State Transition Diagram steps 1.Identify the initial state. 2.Represent that state by drawing a rectangle on the diagram. 3.Connect that state with an arrow to show its first transition. 4.Each state should lead to at least one other state.

46. 5-46 State Transition Diagram State Transition Diagram steps (cont.) 5.Label the arrow with a descriptive event name. 6.List the appropriate actions to be taken adjacent to each state rectangle. 7.Consider system actions to unexpected events. 8.Repeat the process until all possible states are accounted for.

47. 5-47 Figure 5-14 (a). State transition Diagram for Elevator Floor Request Logic

48. 5-48 Figure 5-14 (b). State transition Diagram for Door Control Request Logic

49. 5-49 Criteria for Determining Appropriate Logic Modeling Technique Table 5-7. Criteria For Determining Appropriate Logic Modeling Technique

50. 5-50 Chapter Summary By reducing a complex system into a set of logical models, the analyst can easily view the system in a holistic sense. Using the various modeling tools, the analyst must be able to analyze complex logic sequences and organize them into a set of instructions.

51. McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 End of Chapter