ENMA 6010: Data Flow Diagrams1 ENMA 6010: Data Flow Diagrams Modeling System Functions Primary...

ENMA 6010: Data Flow Diagrams 1

ENMA 6010:

Data Flow Diagrams

Modeling System Functions

Primary Reference: Wikipedia – Data Flow Diagrams

©2010 – Mark PolczynskiAll rights reserved

http://www.yourdon.com/strucanalysis/chapters/ch9.html


We will be studying four modeling approaches:

• Data flow diagram – system function

• State transition diagrams – time dependent behavior

• Entity relationship diagram – stored data/material

• Process flow diagrams – actions and decisions

Det

ail

To understand the rationale behind this modeling tool,

We need to review the reasons for modeling,

And the characteristics of good model.


Goals of System Modeling:

1.To focus on important system features while downplaying less important features,

2.To discuss changes and corrections to the user’s requirements at low cost and with minimal risk,

3.To verify that we understand the user’s environment,

4.To verify that we have documented our understanding in a way that would allow others to construct/maintain the system.

Data flow diagrams are a good tool for modeling system functions.

Additional tools are typically required to meet this complete set of goals.


Characteristics of Good Models

1.Graphical, with support for detailed text descriptions: Picture is worth a thousand words picture links to a thousand words.

2.Top-down partitionable: Globe Continents Countries

3.Minimally redundant: Make changes in just one place in the model.

4.Transparent: Requires no expertise inmodel building to understand the model.


Data Flow Diagrams

Data flow diagrams focus on:

1. Processes within a system that

a) Transform data/materialinputs to outputs

b) Store data/materials

2. Flows

a) Within the system between the processes and stores,

b) To/from entities outside of the system.

Low-hangingapple

Picked apple

Picked apples

Pick apple


Origins and Uses

• Data flow diagrams began to be widely used in the 1970’s.

• They are a key tool in software engineering.

• They are associated with the general field of structured analysis.

• So, they are good for modeling business systems.

• They focus on data (information), but in a general sense, they can represent any type of flow, e.g., money flow, material flow.

• Thus, they are a good tool for modeling inventory flow and storage in a manufacturing system.

• But in their basic form they are primarily qualitative vs. quantitative.

• That being said, they can be an excellent high-level representation for streamlining systems and reducing inventory.


Data, Materials, and Objects

•Because DFDs came out of software engineering, the focus was on data.

•But as we see, the modeling approach accommodates any kind of flow, including data, materials, money (which is now data, not materials like silver and gold), etc.

•So here, we will just use the generic term “object” for whatever is flowing.

•As it turns out, this term will show up in other modeling tools.


ProcessProcess (or function) which transforms data or material (objects) inputs to outputs. Black box - does not indicate how or when the transform is done. Shorthand = “bubble”.

Data Flow Diagram Symbols

Flow Directed pathways between processes, stores, and terminators. Use a different flow for each type of object.

Store Place where objects come to rest. You only store object that the system needs to “memorize”.

External Terminator

Entities outside the system. Where flows start and end. Outside the scope of the model.


Example Data Flow Diagram: Book Shipping and Receiving System

Alternate shape

From Yourdon –Some inconsistencies!


Naming Data Flow Diagram Elements

Constructing and understanding data flow diagrams can be enhanced by sticking to some simple naming conventions:

ProcessVerb-object phrase: “Calculate sales tax”. Don’t use the name of the person/computer/etc. Rather, describe the function (keep it general).

External Terminator

This is typically some physically distinct entity – person, computer, company, agency, another system.

Flow Noun: Name of the object flowing, e.g. “Apple”. If it is “Apple, Pear, Banana”, and you process them all the same way call it “Fruit”.

Store Typically, plural of the object being stored: “Apples”


Some Implementation Notes:

• If you are struggling with defining meaningful names for diagram elements (e.g. “valid tax return” vs. “input”), then you probably don’t understand the system.

• To increase clarity, you can show terminators and stores more than one time in a diagram (see BODS example), but each process bubble can appear only once.

• Terminators are outside the system being modeled. If you start drawing flows between terminators, then you are, in essence, expanding the boundaries of the system you are modeling.

• You can’t have processes or stores with inputs but no outputs (sinks), or outputs but no inputs (sources).

• Only terminators can be sources or sinks of objects.


Implementation Note on Terminators:

• Usually, your customer defines the scope of the system that you will be modeling.

• This defines the terminators for the DFD.

• Terminators are outside of the system, and, by definition, the modeler cannot change the contents, organization, or internal procedures of terminators.

• Therefore, the DFD is an essential document for customer interaction and model scope definition.

• It is essential to controlling customer expectations.


Further Information on Implementation

The Yourdon text has detailed guidelines on do’s and dont’s of drawing DFDs.

We will not cover this detail here, but it is highly recommended that someone on your team reads through this and does a thorough check of your project DFD.

That being said, there are some key issues we still need to touch on:

• Logical model vs. physical model,

• Top-down modeling,

• Bottom-up modeling,

• Data dictionary

• Extensions for real-time control.


DFD Logical Model vs. Physical Model• The logical model contains only the diagram elements absolutely needed

to make a system meet the customer requirements.

• This is sometimes termed the essential model.

• The physical model contains process, store, and flow elements that are added by the designer to make implementation easier.

• This may be called the environmental model.

• The logical model is implementation independent…

…The physical model is implementation dependent.


Great! What Does That Mean?!

This is a very critical distinction…and an essential part of building good models.

Let’s start with a simple example: Making a PBJ sandwich…


Processes and Flow

Here is the logical model for preparing your sandwich.

The model contains all the essential processes and flows.

But what if you were preparing the sandwich in the morning,and it is supposed to be your lunch?


Process, Flow, and Storage

Here, the sandwich is constructed and storedfor later consumption.

Thus, the storage element is required toimplement this system,

But it is not required to make a PBJ sandwich.


This is an example of a physical model containingan implementation-dependent data store.

Logical Model:Ideally, orders are processed immediately.

Physical Model:In this implementation of the ideal system, orders are processed in batches, so they need to be stored before processing.Un-Lean


Here is an example of a necessary data store in an order entry system…

Here, it is absolutely necessary to keep a long-term record of Ordersfor government accounting regulations, warrantee coverage, etc…

So this should be included in the logical model.


Using Logical and Physical Models

Typically, you develop the logical model first to understand the system,

Then build the physical model to use as a design spec showing actual implementation.

The physical model represents compromises that add cost to the system.

In the physical model, the diagram elements turn into the names of:

• People,

• Physical pieces of hardware,

• Software packages,

• File or databases,

• Inventory locations,

• Etc…


Buffers and Work-In-Process

• In practice, a primary difference between logical and physical models lies in the stores.

• In logical models, only the objects that needs to be stored for future use (“memorized” for data) appear in the model.

• The added data stores in physical models represent buffers needed for real-world systems to level out flow between processes.

• Since data flow and data store can also represent material flow and material store, data stores represent inventory or work-in-process.

• Comparison of logical and physical models is an excellent way ofidentifying and reducing work-in-process.

Goal is to make physical model look like logical model.


Logical vs. Physical Model

In a sense, the logical model represents an ideal future state of a system.

Thus, the logical represents a “to-be” model that our kaizen efforts should be directed toward.

It is important to build the logical model first, since we really need a description of the to-be state.

Now, whether you are designing a new system or analyzing an old system, you must always ask:

• Why do I need this storage element in the physical model?

• How could I eliminate the need for this physical element?


Top-Down Modeling

• Obviously, a system with many processes, flows, and stores can result in a data flow diagram that is impossible to understand, maintain, and improve.

• The field of structured analysis allows top-down design, modeling, and documentation, where processes are decomposed into multiple sub-levels.

• Data flow diagrams support this approach.

Let’s see how this works…


Returning to the Book Order and Delivery System, we see a bunch of process blocks, storage blocks, terminator blocks, and flows.

So we can easily find the system boundaries right away…

Process

Flow

Store

External Terminator


Context Diagram

By observing system boundaries, we can draw a Context Diagram which shows the system we are analyzing (target system), and the systems that our system interacts with.

Target system for analysis

Note: Drawing the Context Diagram resolved some inconsistencies in Yourdon’s original example!


Context Diagram

The Context Diagram is the top level in our top-down model.

Once we settle on what is inside and outside the system we will model,

And how our system interacts with the outside world,

We can focus our attention on modeling the target system.

Target system for modeling


Level 0

Returning to Yourdon’s example, Level 0 shows the major functions and stores inside the Context Diagram target system.

Note the numbering on the functions

ENMA 6010: Data Flow Diagrams28

Context Diagram

System

Level 0

1

23

Level 1

3.33.1

3.2

Top-Down Modeling – Process Decomposition

Next, you draw data flow diagrams for what is happening inside each Level 0 function, etc….

Note the numbering convention on the processes.

Level 2


Top-Down Decomposition Implementation Notes:

•Try to limit each DFD level to about 6 processes and stores (1 .ppt slide).

•If you have more than 6 processes, try to group them, and then create sub-level showing detail.

•You will rarely go beyond Level 2.

Remember!

DFD just shows:

• WHAT processes (transforms, functions) are performed on data/materials.

•Not HOW the processes are performed.

•We’ll use other tools to show the HOWs.

Top-Down Modeling for System Design

The top-down approach works well when designing a new system.

Since you don’t know details, you can start by identifying the main object transformations.

Then figure out later (or delegate) how each major transformation will be done.This generates the lower levels of the diagram.

Note: As you do this, you may choose to change the boundaries of upper layers, e.g., move Process 3.3 inside of Process 2.


Level 0

1

32

Level 1

3.1

3.2

3.3


DFD Modeling Process: Bottom-Up ModelingWe saw how to build a top-down for a new process, but it is also possible to

draw DFDs using a bottom-up approach.

Bottom-up works OK for existing systems, but kind of difficult for systems that don’t exist yet. Here’s how you do it:

1. Start by just writing down “events” (things that happen in your system) on post-it notes. These events represent the process elements (bubbles).

2. For each process, identify what data or material is needed for the process function.

3. Find the process that provides the needed object and draw a flow line.

4. Create new processes where there is no source of the required object.

5. Add stores where they are absolutely required.

6. Processes which are read-only or write-only are terminators, or you haven’t analyzed the system correctly.


List all eventsthat occur in the system

For each event, identify the data/material in

For each data/material, identify stores as

needed

Put events, data/materials, stores

on self-stick notes

Attach data/material stores to flow

in and out

Attach flows in and out to events (processes)

Create diagram from flow/process/store sets

sets

Eliminate duplicate flow/process/store

elements

Walk through system operation using the

model

Model accurate?

Use themodel

Identify missing processes, flows, and

stores

Enter ExitGroup andOrganize

ProcessWalkthrough

Reviewand Revise

TestModel

Yes

No

Process Flow Diagram for Bottom-Up Data Flow Diagramming

For each event, identify data/material out


Data DictionaryYou can collect the names of all of the stored objects into a text document.

Then, you can describe the characteristics of that object.

This is the data dictionary…

It consists of what it is that we need to “remember” about each object.

Of course, you can treat materials just like data, which results in an inventory list vs. a data dictionary


Extensions for Real-Time Control

Consider our PBJ System.

Assumedly, we just don’t keep making and storing sandwiches,

Or just keep eating sandwiches all day long…

So, what turns the bubbleson and off?


Control function

Controlflow


Control Function

•The control function coordinates the activities of the other DFD functions.

•Control function inputs and outputs are 1-bit on/off yes/no signals.

•No data/materials flowing on control lines!

•These signals “wake up” other functions when the function needs to transform inputs to outputs.

•These could be expected or unexpected conditions.

•Typically there is no more than one control function for a particular data flow diagram.


What A Mess!!

Yes, these models can get pretty complicated and messy,

But whose fault is that?!

One way to help keep things under control is to put your DFDs in matrix format:

From

Func

tion

1

Func

tion

2

…

Term

inat

or 1

…

To Function 1 Flow AFunction 2 Store X

…Terminator 1 Flow B

…


OK, let’s convert Yourdon’s example to matrix form…

Start with functions:1.Receive order2.Ship books3.Collect payments

Then terminators:•Customers•Warehouse

Now build the matrix…


DFD Matrix – Step 1

Now let’s fill in the cells…

From

1. R

ecei

ve

orde

r

2. S

hip

book

s

3. C

olle

ct

paym

ents

Cust

omer

s

War

ehou

se

To1. Receive order

2. Ship books

3. Collect payments

Customers

Warehouse

From

1. R

ecei

ve

orde

r

2. S

hip

book

s

3. C

olle

ct

paym

ents

Cust

omer

s

War

ehou

se

To1. Receive order S: Customers F: Orders

2. Ship books S: Orders F: Books

3. Collect payments S: InvoicesF: Payments, inqiries

CustomersF: Invalid orders

F: Ship books F: Invoices

Warehouse


DFD Matrix – Step 2

F = FlowS = Store


From

1. R

ecei

ve

orde

r

2. S

hip

book

s

3. C

olle

ct

paym

ents

Cust

omer

s

War

ehou

se

To1. Receive order S: Customers F: Orders

2. Ship books S: Orders F: Books

3. Collect payments S: InvoicesF: Payments, inqiries

CustomersF: Invalid orders

F: Ship books F: Invoices

Warehouse

Why would you do this?

Well, for example, now it’s pretty easy to go to each empty cell and ask if there actually should be a data flow that we missed in our analysis.

Does Ship books send anything to warehouse?


Characteristics of Good Models

1.Graphical, with support for detailed text descriptions: Picture is worth a thousand words picture links to a thousand words.

2.Top-down partitionable: Globe Continents Countries

3.Minimally redundant: Make changes in just one place in the model.

4.Transparent: Requires no expertise in model building to understand the model.

Data flow diagrams have these characteristics.


Goals of System Modeling:

1.To focus on important system features while downplaying less important features,

2.To discuss changes and corrections to the user’s requirements at low cost and with minimal risk,

3.To verify that we understand the user’s environment,

4.To verify that we have documented our understanding in a way that would allow others to construct/maintain the system.

Data flow diagrams are a good tool for modeling system functions.

Additional tools are required to meet this complete set of goals.


We will be studying several modeling approaches, including:

• Data flow diagram – system function

• State transition diagrams – time dependent behavior

• Entity relationship diagram – stored data/material

• Process flow diagrams – actions and decisions

Det

ail

Can you be more specific?


State transition diagram

Entity relationship diagram

Process flow diagram

Preview of coming lectures…


Notes on using Visio to draw data flow diagrams…


My favorite shapes…

Forget it!

See next slide


Start with“Dynamic connector”…

Then select lineand right click…

Then choose“Curved Connector”

ENMA 6010: Data Flow Diagrams1 ENMA 6010: Data Flow Diagrams Modeling System Functions Primary...

Documents

Transcript of ENMA 6010: Data Flow Diagrams1 ENMA 6010: Data Flow Diagrams Modeling System Functions Primary...