Chapter 5

McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter 5

Modeling the Processes

and Logic

Modeling the Processes

and Logic

5-2

Learning ObjectivesLearning ObjectivesLearning ObjectivesLearning 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

5-3

Learning ObjectivesLearning ObjectivesLearning ObjectivesLearning 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

5-4

Logical Process ModelingLogical Process ModelingLogical Process ModelingLogical 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

Benefits of Logical ModelBenefits of Logical ModelBenefits of Logical ModelBenefits 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

5-6

Data Flow DiagramData Flow DiagramData Flow DiagramData 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

5-7

DFD SymbolsDFD SymbolsDFD SymbolsDFD Symbols

• Four basic symbols– Process– Data Flow– Data Store– External Entity

• Two popular symbol sets– Gane and Sarson– DeMarco and Yourson

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

5-9

DFD ComponentsDFD ComponentsDFD ComponentsDFD Components

• Data Flow– Represented by a line with arrowhead

indicating direction of flow– Data in motion– Use noun to name the data content

5-10


• Data Store– Represents a repository for data recorded

within the system– Data at rest

5-11


• 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

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


5-13

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

5-14

DFD HierarchyDFD HierarchyDFD HierarchyDFD 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

5-15

Figure 5-3. Numbering Convention for DFD Decomposition

5-16

Context Level DiagramContext Level DiagramContext Level DiagramContext 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

5-17

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

5-18

Level-0 DFDLevel-0 DFDLevel-0 DFDLevel-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

5-19

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

5-20

Level-1 through Level-n DFDLevel-1 through Level-n DFDLevel-1 through Level-n DFDLevel-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

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

5-22

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

5-23

DFDs versus FlowchartsDFDs versus FlowchartsDFDs versus FlowchartsDFDs 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

5-24

Figure 5-8. ANSI System Flowchart Symbology

5-25

Figure 5-9. System Flowchart Example

5-26

DFD GuidelinesDFD GuidelinesDFD GuidelinesDFD Guidelines

• Establish system boundary.

• Label processes and data flows with sufficient information.

• Think WHAT and not HOW.

• Think data FLOW, not control.

5-27

Analyzing and Using the DFDAnalyzing and Using the DFDAnalyzing and Using the DFDAnalyzing 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.

5-28

Modeling Process LogicModeling Process LogicModeling Process LogicModeling 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

5-29

Structured EnglishStructured EnglishStructured EnglishStructured English

• Use three logic constructs– Repetition– Decision– Sequential

• Each process must have only one entrance and only one exit

5-30

Procedural Structure Structured English Model

Non-conditional Sequence – perform an action sequence without conditions.

[action 1], [action 2], [action 3],…[action n]

Simple Conditional Sequence – perform an action sequence based on a condition with two possible values. If condition is true, then perform action sequence 1, otherwise perform action sequence 2.

IF [condition] THEN [action sequence] ELSE [action sequence]

Complex Conditional Sequence – perform an action sequence based on a condition with more than two possible values. If condition is true, then perform action sequence 1, otherwise test each condition until true and perform associated action sequence.

DO BASED ON [condition]: IF [condition] = [value] THEN [action sequence] IF [condition] = [value] THEN [action sequence] … IF [condition] = [value] THEN [action sequence]

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

5-31

Procedural Structure Structured English Model Combinatorial Condition Sequence – test values for multiple conditions and perform correct action sequence based on those values. A Decision table is often used in lieu of nested if-then-else conditionals.

Decision Table

Rule 1

Rule 2

Rule 3

Rule n

[condition 1] value value value value

[condition 2] value value value value

[condition n] value value value value

[action] X X

[action] X

[action] X

Zero-to-Many Iteration – repeat the action sequence until the condition is false. Used when the action sequence is based upon the initial value of the condition.

REPEAT UNTIL [condition]: [action sequence]

One-to-Many Iteration – repeat the action sequence until the condition is false. Used when the action sequence must be performed at least once regardless of the initial value of the condition.

DO WHILE [condition]: [action sequence]

- OR - FOR [condition]: [action sequence]

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

5-32

Process ID

Structured English

4.1.1

Multiply GROSS_PAY by FED_TAX_RATE and store in EMP_TAX_DEDUCT.

4.1.2

IF EMP_NONTAX_DEDUCT > 0 THEN append EMP_NONTAX_DEDUCT to employee data.

4.1.3

Multiply GROSS_PAY by .01 and store in EMP_RETIRE.

4.1.4

Multiply CURR_EMP_VACATION by EMP_DAY_RATE and store in EMP_VACATION_PAY.

Table 5-3. Structure English Examples for process 4.0

5-33

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

5-34

Decision TablesDecision TablesDecision TablesDecision Tables

• A diagram of all the logic and possible outcomes associated with a particular process– Process rules– Condition stubs– Action stubs

5-35

Decision TablesDecision TablesDecision TablesDecision 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

5-36

Structured English Process Description IF Driver_Age < 25 THEN IF Accident_Free = “N” THEN Surcharge = 0.20 ENDIF ELSE IF Driver_Gender = “F” THEN Surcharge = 0.10 ENDIF ELSE IF Driver_Educ = “N” THEN Surcharge = 0.15 ENDIF ELSE IF College = “N” THEN Surcharge = 0.12 ENDIF ELSE IF HS_GPA < 3.25 THEN Surcharge = 0.10 ENDIF ELSE IF HS_GPA >= 3.25 THEN Surcharge = 0.07 ENDIF ELSE IF Accident_Free = “Y” THEN Surcharge = 0.00 ENDIF ELSE IF Accident_Free = “N” THEN Surcharge = 0.07 ENDIF ENDIF

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

5-37

Driver Age 25 yrs +

25 yrs +

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

< 25 yrs

Accident Free Y N N Y Y Y Y Y

Driver Gender - - - Female Male Male Male Male

Driver’s Education

- - - - N Y Y Y

College (attending /completed)

- - - - - N Y Y

High School GPA

- - - - - - < 3.25 3.25+

20% surcharge

X

15% surcharge

X

12% surcharge

X

10% surcharge

X X

7% surcharge

X X

No surcharge

X

Table 5-5. Decision Table for Insurance Rating System

5-38

Rule Description Determine all conditions and the values they can assume.

Conditions are the “IF” portion of a Structured English statement. In most cases, possible values for a condition will be binary (i.e. “yes” or “no”), in other cases values can have many values (i.e. hair or eye color).

Determine all possible actions that need to be taken.

Actions are the “THEN” portion of a Structured English statement. Actions should be clearly defined so as to avoid any ambiguity.

Calculate and list an exhaustive set of rules.

Multiply the number of possible values for each condition by the number of possible values for all other conditions. For example, 3 conditions with 2 possible values each would yield 8 rules in the exhaustive set — 2 x 2 x 2 = 8.

Associate actions with rules.

Each action, as previously determined, should be associated with at least one rule and each rule should have at least one action.

Simplify the rule set in the decision table.

Remove all redundant or nonsensical rules from the exhaustive set to create a smaller and less complex decision table.

Table 5-6. Procedure for Constructing Decision Tables

5-39

Decision TreesDecision TreesDecision TreesDecision 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

5-40

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

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

5-42

State Transition DiagramState Transition DiagramState Transition DiagramState 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

5-43


• 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

5-44

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

5-45


State Transition Diagram steps1. 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.

5-46


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.

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

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

5-49

Criteria for Determining Appropriate Logic Criteria for Determining Appropriate Logic Modeling TechniqueModeling TechniqueCriteria for Determining Appropriate Logic Criteria for Determining Appropriate Logic Modeling TechniqueModeling Technique

Primary Criteria 1=Best 2=Better 3= Good

Structured English

Decision Table

Decision Tree

State-Transition

Transformation of conditions or actions into specific sequence.

1 3 1 -

Portraying complex logic sequences.

3 1 2 -

Portraying simple logic sequences.

2 2 1 -

Making basic decisions. 3 2 1 -

Determining conditions or actions.

2 3 1 -

Checking logic consistency and completeness.

3 1 1 -

Ease of Manipulation. 3 1 2 -

Compactness 3 1 2 -

Portraying temporal logic sequences

- - - 1

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

5-50

Chapter SummaryChapter SummaryChapter SummaryChapter 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.

Chapter 5

Documents

Transcript of Chapter 5