1

ITEC 3010Analysis - Data Flow Diagrams

2

Chapter 6 (Traditional Approach to Requirements) -- Data Flow Diagrams (DFD)

• Data Flow Diagram (DFD)– A graphical system model that shows all of the main

requirements for an information system: inputs, outputs, processes and data storage

– Everyone working on the project (and end users) can see all the aspects of the project in the diagram with minimal training (simple – only 5 symbols)

3

4

Example of a Data Flow Diagram – fig. 6-3

• The square is an external agent– A person or organization, outside the boundary of a

system that provides data inputs or accepts data outputs

• The rectangle with rounded edges is a process– A symbol that represents an algorithm or procedure by

which data inputs are tranformed into data outputs

• The lines are data flows – Represents movement of data

• The flat three-sided rectangle are data stores (a file or part of a database)– A place where data is held

• Fig. 3-6 corresponds to event “Customer wants to check item available” (see last lecture)

5

6

Data Flow Diagrams and Levels of Abstraction

• Levels of abstraction– Particular to any modeling technique that breaks the

system into a hierarchical set of increasingly more detailed models

– Example above – a DFD fragment – showing one process in response to one event

– Other diagrams show the processing at a higher level (more general) or lower level (a more detailed view of one process)

– Higher level processes in a DFD can be decomposed into separate lower level DFD (or some other diagram)

7

Context Diagrams

• Context Diagram: A DFD that summarizes all processing activity within the system in single process symbol– Describes highest level view of a system

– All external agents and all data flows into and out of a system are shown in the diagram

– The whole system is represented as one process

• Example – fig. 6-5 shows a context diagram for a university course registration system that interacts with 3 agents: academic dept., student, and faculty member

8

9

Notes on Context Diagram

• Useful for showing system boundaries• External agents are outside the software scope

(which is represented by the single process). But not from System Analysis

• Data stores are not shown in the context diagram since they are considered to be in the software scope (i.e. the single process)

• It is the highest level DFD• Context diagram does not show any details of

what takes place within the system (i.e. that single process)

10

11

DFD Fragments

• DFD fragment: A DFD that represents the system response to one event within a single process symbol– A fragment is created for each event in the event list –

it is a self-contained model showing how the system responds to a single event

– Created one at a time– Fig. 6-7 shows 3 DFD fragments for a course

registration system– Each fragment represents all processing for an event

within a single process symbols– The data stores in the DFD fragment represent entities

in the ERD (Entity Relationship Diagram – see last lecture) – Not Necessarily !

12

13

14

15

The Event-Partitioned System Model

• Event-partitioned system model: a DFD that models requirements using a single process for each event– The entire set of DFD fragments can be combined into this

single DFD called the event-partitioned system model or diagram 0

– Diagram 0 shows the entire system on a single DFD

• Figure 6-10 (next slide) shows a set of four related DFDs– The top diagram shows the Context diagram for course

registration (same as fig. 6-5 above)– The diagram below that (Diagram 0) is the decomposition of

the one process in the context diagram AND consists of the a combined version of the 3 DFD fragments in fig. 6-7 above (in fig. 6-10, DFD fragment 1 is shown below diagram 0)

– Finally, Diagram 1 is a decomposition of the process in DFD fragment 1

16

17

Dividing the system into subsystems

• The RMO customer support system involves 20 events, therefore the event-partitioned system model (diagram 0) would contain 20 processes– This can get to be a crowded diagram!

– Solution is to divide the system into subsystems

– Events are grouped into related subsystems based on similar:

• Interactions with external agents

• Interactions with data stores

• Required processing

• In the RMO example, we can break up the support system into 4 subsystems (see next slide)

18

19

• Next Step: After the subsystems are defined:– A DFD is created to represent the division of

the system into subsystems – the subsystem DFD

– This subsystem DFD shows how the four RMO subsystems are connected (i.e. how they are related to all the outside sources and destinations of data)

• Note that there is a process in the diagram for each of the four subsystems that were defined for RMO

– See figure 6-13 for an example based on the 4 subsystems in the RMO example

– Note - even with only 4 subsystems (rather than one process for each of the 20 events) the diagram gets cluttered

20

21

• Next Step: can decompose a subsystem DFD into event-partitioned models - one for each subsystem:– In the RMO example can expand the subsystem

in fig. 6-13 called “Order entry subsystem” into an event-partitioned model

• this model has 5 processes within it – see next slide

– The analyst would also create an event-partitioned model for the other 3 subsystems in the RMO example

22

23

Summary - Relationship of all these diagrams

• Figure 6-12 shows the relationship among DFD abstraction levels when subsystems are defined

• The figure starts off with the context diagram, which breaks down to the subsystem diagram (one for each subsystem)

• The subsystem diagram is turn broken down into the event-partitioned subsystem diagrams

• ETC.

24

Layers of DFD Abstraction

25

Decomposing Processes to see Details of One Activity

• Using this same principle of breaking down the model to more detailed level, we can take a DFD fragment (e.g. create new order fragment from the RMO example) and decompose it into sub-processes

• In figure 6-15 this is shown– Since fragment “create new order” was the second

DFD fragment defined for the RMO example (see fig. 6-8) we will label processes inside of it as processes 2.1, 2.2, 2.3 etc.

– The diagram decomposes “create new order” into 4 sub-processes (see fig. 6-15) – labeled sub-processes 2.1-2.4

26

27

Evaluating DFD Quality

• A quality set of DFDs is– Readable

– Internally consistent

– Accurately represents system requirements

• Minimizing complexity– Want to avoid information overload

• Occurs when too much information is presented to a user at one time

• Two ways to avoid information overload use 7 + or – 2 rule (which limits the number of components) and interface minimization (which minimizes the number of interfaces and connections between components)

– A single DFD should have no more than 7 + or – 2 processes

– No more than 7 + or – 2 data flows into or out of a process

28

• Data Flow Consistency– Want consistency in DFDs– Common errors:

• Differences in data flow for a process and its decomposition (want to have balancing: equivalence of data content between data flows entering and leaving a process or its decomposition)

• Black hole– A process with data input that is never used to produce a

data output• Miracle

– A process with a data output that is created out of nothing (I.e. “miraculously appears”)

• Black hole and miracle problems apply to both processes and data stores

• Most CASE tools perform data flow consistency checking

29

30

31

Documenting Data Flow Diagram (DFD) Components

• Process Descriptions– Each process on a DFD needs to be defined

– Can keep breaking down DFD to more detailed DFD but at some point have to describe the process in structured English

• Uses instructions, repetition and if-then-else logic

• Note that this is not necessarily a computer program (its an algorithm that describes the process)

32

33

• Limitations of structured English– Good for representing processes such as those in

previous slide– Not so good for showing complex decision logic – as

shown in next slide– Not so good if there are few or no sequential steps

• Decision Table– A tabular representation of processing logic containing

decision variables, decision variable values and actions (or formulas)

• Decision Tree– A graphical description of process logic that uses lines

organized like branches of a tree

34

35

Making a Decision Table (from the logic on previous slide)

• Step 1– Identify the decision variables

• Year to date purchases (YTD)

• Number of items ordered

• Delivery date

• Step 2– Put variable with fewest possible value ranges in the

first row of the table• In this example could put either YTD or number of items

36

• Table so far is just one row:

YTD Purchases > $250 YES NO

• Step 3 – put variable with next fewest possible value ranges as next row in the table, to now get:

YTD Purchases > $250 YES NO

Number of Items (N) N <=3 N>=4 N<=3 N>=4

• Step 4 – keep inserting rows as in step 3 until all decision variables are included in the table

37

• Table now looks like:

YTD Purchases > $250 YES NO

Number of Items (N) N <=3 N>=4 N<=3 N>=4

Delivery Day Next 2nd 7th Next 2nd 7th Next 2nd 7th Next 2nd 7th

• Step 5 – Finally put as bottom row of the table the actions for each of the possible conditions – see next slide (fig. 6-22) from the text for the complete table

38

39

Decision Tree

• A graphical description of process logic that uses lines organized like branches of a tree

• Decision table is more compact but decision tree is easier to read

• Decision tree can be developed in essentially same way as a decision table (only difference is that it runs horizontally – i.e. Rows in a decision table are columns in the tree – just flip the table sideways and you get the tree)

40

41

• there may be several actions associated with a set of conditions in a Decision Table– Figure 6-24 shows a table where if the customer is new

and if an item is on backorder for >= 25 days then two things are done:

• (a) include detailed return instructions

• (b) expedite delivery

• See next slide for this example

42

43

Data Flow Definitions

• Data flow – a collection of data elements• Data flow definition – a textual description of a data

flow’s content and internal structure– Lists all the elements- eg. a “New Order” data flow consists of

• Customer –Name

• Customer-Address

• Credit-Card-Information

• Item-Number

• Quantity

– Most of these are stored and correspond to the attributes of data entities

– In addition to just listing elements can use algebraic notation• Data flow “equals” one element followed by another (repeating groups

can be shown in curly brackets)

44

45

46

47

48

Data Element Definitions

• Describe a data type– E.g. String, integer, floating point, or Boolean

– Lengths are usually defined for strings

– Numeric values usually have a minimum and maximum value (a valid range)

– Might define special codes (e.g. code A means ship immediately etc.)

49

+int

9(4)

+9(6).99

String[50]

50

Data Store Definitions

• Usually, a data store on the DFD represents a data entity on the ERD

• Should look at the ERD for details on this• If no ERD can define the data store as a collection

of elements (like did for data flows)

51

Workflow Modeling

• Workflow– The flow of control through a processing activity as it

moves among people, organizations, computer programs, and specific processing steps

– Encompasses• Trigger

• The processing steps that respond to a trigger

• Participants (or “actors”) – can be people and machines

• Flow of data

52

• Workflow models directly model the sequence of processing activities– Can develop and check with users to gain better

understanding of a system or organization

• Can also be developed during the transition between analysis and structured design

• Can be used to describe complex interactions• Can be used to describe alternative approaches• Uses some symbols from flow charts

– DFD are good at capturing flow of data within a workflow (but not control)

– Flow charts and activity charts can represent control flow but don’t represent data flow

53

54