Chap 05 Data Flow Diagram.pptx

Chapter 5 Data Flow Diagram

Outline

• Introduction• Data flow diagrams

– Reading DFD– Elements of DFD– Using DFD to define business processes

• Creating data flow diagrams– Creating the context diagram– Creating DFD fragments– Creating the level 0 DFD– Creating Level 1 DFD (and bellow)– Validating DFD

• What is a process model? What is a data flow model? Are the two related? If so, how?

• • Process models are used to document and organize

the information obtained during the analysis phase of a systems development project. Data flow diagramming is a popular technique that is used in process modeling today. Data flow diagrams document the business processes and the data that passes among them.

• Distinguish between logical process models and physical process models.

• • Logical process models describe processes

without suggesting how they are constructed. Physical process models provide information that is needed to ultimately build the system.

• Define what is meant by a process in a process model. How should the process be named? What information about a process should be stored in the CASE repository?

• • A process represents actions that are performed for some specific business

reason. A process should be named using a verb phrase; information regarding a process to be stored in the CASE repository includes:

• • Label (name)• Type (process)• Description (what it is)• Process Number• Process Description (Structured English)• Notes

• Define what is meant by a data flow in a process model. How should the data flow be named? What information about a data flow should be stored in the CASE repository?

• • A data flow represents a single piece of data or a set of logically-related data items

that move to or from processes. A data flow should be named using a noun; information regarding a data flow to be stored in the CASE repository includes:

• • Label (name)• Type (flow)• Description • Alias• Composition (description of data elements)• Notes

• Define what is meant by a data store in a process model. How should the data store be named? What information about a data store should be stored in the CASE repository?

• • A data store represents a set of data that is stored together - the data store

holds the data. A data store should be named using a noun; information regarding a data store to be stored in the CASE repository includes:

• • Label (name)• Type (store)• Description • Alias• Composition (description of data elements)• Notes

• Define what is meant by an external entity in a process model. How should the external entity be named? What information about an external entity should be stored in the CASE repository?

• • An external entity is something that is outside the scope of our system, but

interacts with it. An external entity may be a person, organization, or another system that supplies information to the system and/or receives information from the system. An external entity should be named using a noun; information regarding an external entity to be stored in the CASE repository includes:

• • Label (name)• Type (entity)• Description • Alias• Notes

• Why is a process model typically composed of a set of DFDs? What is meant by decomposition of a business process?

• • Most business processes are too complex to depict using

one diagram. Consequently, business processes are typically depicted with a set of DFDs, with the first diagram (Context Level) showing a summary of the system, and subsequent DFDs showing processes within that system. Decomposition is a method for breaking down a business process into smaller, logical processes.

• Explain the relationship between a DFD context diagram and the DFD level 0 diagram.

• • A context level diagram is a high-level view of the entire system

represented as one process symbol. Data flows going into and out of the system and the external entities that interact with the system are the only other element of the system shown on this type of diagram. A level 0 diagram is the first view of the internal processes of the business system. These processes are shown from fairly high level, with subsequent diagrams depicting increasing levels of detail. The level 0 diagram shows the same data flows and entities as the context, as well as data stores associated with the system.

• Explain the relationship between a DFD level 0 diagram and a DFD level 1 diagram(s).

• • The DFD level 0 diagram depicts only the major high-

level processes in the system. Each process is then decomposed into a more detailed DFD level 1 diagram. Typically a set of DFD diagrams for a system will include at least one DFD level 1 diagram for each process shown on the context level diagram.

•

• Discuss how the analyst knows how to stop decomposing the process model into more and more levels of detail.

• • The complexity of an overall system or business process that is being

modeled sets the boundary conditions for knowing what is the “ideal” level of decomposition for any specific system or process. Processes are typically decomposed into lower-level DFDs when the additional decomposition helps to explain the complexity of the process; experts suggest that each DFD page have at least three, but not more than seven to nine, processes. A good rule of thumb is to consider a process decomposition complete when the process in question can be explained on one sheet of paper (e.g., structured English, Pseudocode), or with one process description model (decision table/tree).

• Suppose a process on a DFD is numbered 4.3.2. What level diagram contains this process? What is the process’s parent process?

• • Level 2 diagram contains the process numbered 4.3.2• Parent process is 4.3• • Explain the use of structured English in process descriptions.• • Structured English is one method of describing a process.

Typically, short sentences are used to describe the elements or steps in the process.

• Why would one use a decision tree and/or a decision table in a process description?

• • Alternate methods of describing a process are a

decision tree and a decision table. A decision tree is useful in that it aids in understanding decision logic pertaining to nodes (questions) and branches (answers). A decision table aids in understanding the actions (business policies) that based on a condition or a set of conditions.

• Explain the process of balancing a set of DFDs.• • Balancing involves assuring that all the

information from a higher-level diagram is appropriately represented on the next level, or ‘child’ diagram. The child diagram shows more detail, but must show all the inflows and outflows to and from the parent process on the higher level diagram.

• How are mutually exclusive data flows (i.e., alternative routes thorough a process) depicted in DFDs?

• • Mutually exclusive data flows (alternatives) are all

shown on the data flow diagram. Nothing is shown on the diagram to indicate these are alternatives. The information in the written process description will document the fact that the data flows are mutually exclusive.

•

• Discuss various ways to verify the correctness of a process model.

• • Model correctness can be verified by having the

users validate it in a walkthrough, or through role-playing. Analysts should also check that the decomposition of diagrams goes to the same level of detail (not necessarily the same number of levels). Analysts should also check for consistency in terminology throughout the model.

• What is meant by a DFD semantic error? Provide an example.• • A semantics error is an error of meaning in the data flow

diagram, in which the model does not accurately represent the business process being modeled. One example of a semantic error is one in which the data inputs to a process do not correspond to the type of information in the output data flow (see following DFD excerpt).

• Creating use cases when working with users is a recent development in system analysis practice. Why is the trend today to employ use cases in user interviews or JAD sessions?

• • Users may be confused or intimidated by the

symbols used in drawing DFDs. Most users can verbalize the content of a use case more easily than they can grasp drawing DFDs. Use cases are easier to start with than DFDs for most users.

• How can you make a DFD easier to understand? (Think first about how to make one difficult to understand).

• • Try to ensure that the processes are clearly named and

that each process on a diagram is of about the same scale. It is confusing if some processes on a diagram are significantly more complex than others on the same diagram. Try to structure the flow through the processes from top to bottom, left to right, since that is the natural way most people read diagrams.

• Suppose your goal is to create a set of DFDs. How would you begin an interview with a knowledgeable user? How would you begin a JAD session?

• • Although my goal is to create a set of DFDs, it is best to begin

by creating a set of use cases. Therefore, I would begin my interviews or the JAD session by working with the users to identify the major events that are handled by the system and to complete the use cases for those events. After I had a complete and verified set of use cases, then I could work on structuring the information from them into a set of DFDs for the system.

Introduction

• In this chapter – how the requirements definition and use case are further refined into a process model.

• Process model – is a formal way of representing how a business system operates.– Illustrates the processes and activities that are

performed and how data move among them.– Can be used to document the current system (as-is)

or the new system (to be) being developed, whether computerized or not.

Introduction

• There are many different process modeling techniques, but we use one of the most commonly used techniques: DFD

• Data flow diagramming – is a technique that diagrams the business processes and the data that pass among them.– Focus is mainly on the processes or activities that

are performed.

Introduction

• In this chapter, we focus on logical process model.• Logical process model – are models that describe processes,

without suggesting how they are conducted.– Focus on how the business should run, without being distracted by

implementing details.• Physical models (chapter 10) – provide information that is

needed to ultimately build the system. The physical details are defined during the design phase, such as:– Be able to tell whether a process is computerized or manual– Whether a piece of information is collected by paper form or via the

Web– Whether information is placed in a filing cabinet or a large database

This Chapter

• Explain how to read DFDs• Describe the DFDs basic syntax• Describe the process used to build DFDs

– that draws information from the use cases and from the additional requirements information gathered from the users

DATA FLOW DIAGRAMS (DFD)

PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 26

Data Flow Diagrams

• Reading DFD• Elements of DFD• Using DFD to define business processes

fig_05_06 Reading a DFD

The relation between use cases and data flow diagrams is use cases are developed first and then data flow diagrams ensue (to take place afterward ).

Names of use cases become processesInputs and outputs become data flows

Integrating Scenario Descriptions

• DFDs start with the use cases and requirements definition

• Generally, the DFDs integrate the use cases– Names of use cases become processes– Inputs and outputs become data flows– “Small” data inputs and outputs are combined

into a single flow


6 - 29

The relationship between use cases and data flow diagrams

• Use cases tend to be developed with users– to make sure the analyst has fully captured the

processes and relationships; • DFD’s are built upon the use cases

– to more fully formally understand the processes involved

Elements of a DFD

• Process• Data flows• Data stores• External entities

• There are two commonly used style of symbols:1) Chris Gane and Trish Sarson2) Tom De Marco and Ed Yourdon

• Neither is better than the other.• We will use Gane and Sarson style.PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 31

Elements of a DFD

• Process– An activity or function performed for a specific

business reason– Its name is verb phrase.– Manual or computerized


6 - 32

Elements of a DFD

• Data flow– A single piece of data or a logical collection of

data– Its name is noun.– Always starts or ends at a process– Each process must create at least one output data

flow– no output, the process does not do anything

– Each process has at lest one input data flow– It is difficult or impossible to produce an output with no

inputPowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 33

DFD Elements

• Data Store– A collection of data that is stored in some way– Its name is noun.– Data flowing out is retrieved from the data store– Data flowing in updates or is added to the data

store• External entity

– A person, organization, or system that is external to the system but interacts with it.

– Its name is noun.PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 34

Naming and Drawing DFD Elements


6 - 35

Process

Data flow

Data store

Externalentity

rectangle

Rounded boxes

arrow

Rectangle that are open on the right

endq

Using a DFD to Define Business Processes

• Business processes are too complex to be shown on a single DFD.– The first DFD - provides a summary of the overall system,

with additional DFDs providing more and more detail about each part of the overall business process.

• Decomposition is the process of representing the system in a hierarchy of DFD diagrams– Child diagrams show a portion of the parent diagram in

greater detail– A series of DFDs, each representing a lower level of

detail…from context diagram to level 2 diagramPowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 36

Key Definition


6 - 37

• Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

Relationship among Levels of DFDs


6 - 38

Context diagram

Level 0 diagram

Level 1 diagram

Level 2 diagram

Context Diagram


6 - 39

• First DFD in every business process• Shows the overall business process as just

one process (process 0)• Shows all the external entities that receive

information from or contribute information to the system

• No data stores• Use Number 0

Level 0 Diagram


6 - 40

• Shows all the major processes that comprise the overall system – the internal components of process 0

• Shows how the major high-level processes are interrelated by data flows

• Shows external entities and the major processes with which they interact

• Adds data stores• Use numbers 1, 2, 3..etc.

Level 1 Diagrams


6 - 41

• Generally, one level 1 diagram is created for every major process on the level 0 diagram

• Shows all the internal processes that comprise a single process on the level 0 diagram

• Shows how information moves from and to each of these processes

• If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process

• Use numbers 1.1, 1.2,…etc. – called children of level 0 (1,2,..etc.)

Level 2 Diagrams


6 - 42

• Shows all processes that comprise a single process on the level 1 diagram

• Shows how information moves from and to each of these processes

• Level 2 diagrams may not be needed for all level 1 processes

• Correctly numbering each process helps the user understand where the process fits into the overall system

Summary of DFDs

Context Level 0 Level 1 Level 2

Process overall business process as just one process

major processes that comprise the overall system

all the internal processes that comprise a single process on the level 0 diagram

all processes that comprise a single process on the level 1 diagram

Number 0 1, 2, 3… 1.1, 1.2.. 1.1.1, 1.1.2

Data store w/o DS With DS DS DS

Alternative Data Flows


6 - 44

• Suppose that a process produces 2 different data flows under different circumstances. How do we show these alternative paths in the DFD?– show both data flows and use the process description to

explain why they are alternatives– DFD does not show that the data flows are mutually

exclusive.

• Tip -- alternative data flows often accompany processes with IF statements

Process Descriptions


6 - 45

• To explain what the process does and provide additional information that the DFD does not provide.– Text-based process descriptions provide more information

about the process than the DFD alone

• If the logic underlying the process is quite complex, more detail may be needed in the form of– Structured English– Decision trees– Decision tables

Lesson 2 of Chapter 5CREATING DATA FLOW DIAGRAMS


6 - 47

Creating Data Flow Diagrams

• Creating the context diagram• Creating DFD fragments• Creating the level 0 DFD• Creating Level 1 DFD (and below)• Validating DFD

Review

• Interviewing and/or JAD sessions; creating use cases; creating data flow.

• DFDs are usually created by the project team and reviewed by users for correctness

• Decomposing a DFD• means breaking complex processes into a structured set

of detailed diagrams.• Balancing a DFD

• means making sure that all information presented at one level is accurately represented in the next level.

± PROCESS

± DATA FLOW

E.g. Result of a query to a database, contents of a printed report : data that moves together to common destinations

Actions performed on data so that they are transformed, stored or distributed. This can be a computerised or manual transformation

SYMBOLS USED IN A DFD

± DATA STORE

A physical location to hold data e.g. a file folder or notebook, database, table, etc.

± SOURCE/SINK

Origin and/or destination of the data. Often referred to as external entities as they are outside the system. We are only interested in how data flows in to or from the system to them.

SYMBOLS USED IN A DFD

Do’s and Don’ts when constructing a Data Flow Diagram

Miracle error - A process has no input data flows

Black hole error - A process has no output data flows

Do’s and Don’ts when constructing a Data Flow Diagram

An unbalanced set of data flow diagrams

SOURCE SINK

(a) Context diagram

(b) Level-0 diagram

SOURCE 1

SINK

0

SOURCE 2

1.0

2.0

A B

A

C

B

In context diagram, we have one input to the system, A and one output, B

Level-0 diagram has one additional data flow, CThese DFDs are not balanced – called SYNTAX

ERROR

Balancing DFDs:Example of data flow splitting

x.0Payment & coupon

x.1Payment

x.2Coupon

Composite data flow

Disaggregated data flow

We can split a data flow into separate data flows on a lower level diagram.

Rules for Using DFD Symbols

• Data Flow That Connects YES NO

A process to another process

A process to an external entity

A process to a data store

An external entity to another external entity

An external entity to a data store

A data store to another data store

Steps in Building DFDs

• Build the context diagram• Create DFD fragments for each use case• Organize DFD fragments into level 0 diagram• Decompose level 0 processes into level 1 diagrams as

needed; decompose level 1 processes into level 2 diagrams as needed; etc.

• Validate DFDs with user to ensure completeness and correctness


6 - 57

Creating the Context Diagram• The “big picture” of the system with external

entities and only one process• Draw one process representing the entire

system (process 0)• Find all inputs and outputs listed at the top of

the use cases that come from or go to external entities; draw as data flows

• Draw in external entities as the source or destination of the data flowsPowerPoint Presentation for

Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 58

A Context Diagram Example


6 - 59

Creating DFD Fragments

• Each use case is converted into one DFD fragment

• Number the process the same as the use case number

• Change process name into verb phrase

• Design the processes from the viewpoint of the organization running the systemPowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 60

Creating DFD Fragments• Add data flows to show

use of data stores as sources and destinations of data

• Layouts typically place– processes in the center– inputs from the left– outputs to the right– stores beneath the

processesPowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved.

6 - 61

fig_05_06

fig_05_06

Creating the Level 0 Diagram

• Combine the set of DFD fragments into one diagram

• Generally move from top to bottom, left to right

• Minimize crossed lines• Iterate as needed

– DFDs are often drawn many times before being finished, even with very experienced systems analysts


6 - 63

A Level 0 DFD Example


6 - 64

A process “Maintain Patient Info” gets data from that data store, updates it in the process, and writes it back out.

Data outflow from data store: Current Patient InformationData inflow into the data store: Updated Patient Information

A Level 1 DFD Example


6 - 65

In creating the level 1 diagram where you retrieve data from that data store you may give the data flow as ‘Patient Details’ instead of listing all data items like patient name, address, phone number, health insurance, HIPAA identifier, and more.

Creating Level 1 Diagrams (and Below)

• Each use case is turned into its own DFD• Take the steps listed on the use case and depict each

as a process on the level 1 DFD• Inputs and outputs listed on use case become data

flows on DFD• Include sources and destinations of data flows to

processes and stores within the DFD• May also include external entities for clarity


6 - 66

Creating Level 1 Diagrams (and Below)

• When to stop decomposing DFDs?– Ideally, a DFD has at least three processes and no

more than seven to nine.– It is not necessary to break down farther on Level

1 and Level 2 diagrams


6 - 67

CD SELECTIONS


5 - 68

CD SELECTIONS


5 - 69

CD SELECTIONS


5 - 70

CD SELECTIONS


5 - 71

Context Diagram for CD Selections Internet Sales System


6 - 72

Level 0 DFD for CD Selections Internet System


6 - 73

Level 1 DFD for CD Selections Process 1: Take Requests


6 - 74

use case step generally is the same as a PROCESS on the Level 1 DFD.

Level 1 DFD for CD Selections Process 1: Take Requests


6 - 75

Use case step generally is the same as a PROCESS on the Level 1 DFD.

Validating the DFD

• Check for quality• Most common errors:• Syntax errors – grammatical errors made by the analyst

when he creates the DFD.– Syntax refers to the structure of the DFDs and whether the

DFDs follow the rules of the DFD language.• Semantic errors – misunderstandings by process being

modeled.– Semantics refers to the meaning of the DFDs and whether

they accurately describe the business process being modeled.

Validating the DFD

• The most common syntax error:• 1. data at rest stays at rest until moved by a

process – Data cannot move without a process.

• 2. processes cannot consume or create data– Data only enters or leaves the system by way of

the external entities– A process cannot destroy input data; all processes

must have outputs.

fig_05_12

fig_05_12

Validating the DFD

• Syntax errors – diagram follows the rules– Assure correct DFD structure


6 - 79

For each DFD: Check each process for: A unique name: action verb phrase; number; description

At least one input data flowAt least one output data flowOutput data flow names usually different thaninput data flow namesBetween 3 and 7 processes per DFD

Validating the DFDFor each DFD:

Check each data flow for:A unique name: noun; descriptionConnects to at least one processShown in only one direction (no two-headed arrows)A minimum number of crossed lines

Check each data store for:A unique name: noun; descriptionAt least one input data flowAt least one output data flow

Check each external entity for:A unique name: noun; descriptionAt least one input or output data flow


6 - 80

Validating the DFDAcross DFDs:

Context Diagram:Every set of DFDs must have one Context Diagram

Viewpoint:There is a consistent viewpoint for the entire set of DFDs

Decomposition:Every process is wholly and complete described by the

processes on its children DFDs

Balance:Every data flow, data store, and external entity on a higher level

DFD is shown on the lower level DFD that decomposes it No data stores or data flows appear on lower-lever DFDs that do not appear on their parent DFD


6 - 81

Validating the DFD

• Semantics errors – diagram conveys correct meaning– Assure accuracy of DFD relative to actual/desired

business processes• To verify correct representation, use

– User walkthroughs– Role-play processes

• Examine lowest level DFDs to ensure consistent decomposition

• Examine names carefully to ensure consistent use of terms


6 - 82

Summary

• The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes.

• Use cases record the input, transformation, and output of business processes and are the basis for process models.

• Eliciting use cases and modeling business processes are critically important skills for the systems analyst to master.


6 - 83

fig_05_06

fig_05_06

fig_05_07a

fig_05_07a

fig_05_07b

fig_05_07b

fig_05_08

fig_05_08

fig_05_09

fig_05_09

fig_05_10

fig_05_10

Chap 05 Data Flow Diagram.pptx

Documents

Transcript of Chap 05 Data Flow Diagram.pptx