System DecompositionOverview

Data Flow Diagrams

• Despite the name “Data Flow Diagrams”, DFD have a process, rather than a data, focus

• We represent all processes and all information stores, irrespective of whether or not they are computerized

Symbol Standards

• Activity or function – verb

• Collection of data – noun

• External entity – noun

• Logical “collection” of information in motion - noun

General Guidelines

• A process must actually do something (i.e. use (or be triggered by) data, and produce data)

• Only processes handle data, and interact with the “outside world”

• Sources and sinks are all external to the system, and are “black boxes”

• Data must be put in a data store (by a process), and must be used for something (by a process). Arrowheads show direction of flow (normally one-way)

Context DFD - Food Ordering System

Level 0 DFD

Level 0 Diagram

• ‘Decomposition’ of Context Diagram• Represents the major functions of a system• Answers question – “What does the system

fundamentally do”?• Highest level of detail• Each process is numbered ‘n’ or ‘n.0’• May show data stores

Continuing the Functional Decomposition

Continue the Functional Decomposition

• Further ‘Decompose’ each process:• Level 1 to Level 2• Level 2 to Level 3 etc

• Decompose Level 0 Process 1.0, number Level 1 Processes as 1.1, 1.2, 1.3, 1.4 etc.

• Decompose Level 1 Process 1.1, number Level 2 Processes as 1.1.1, 1.1.2, 1.1.3, 1.1.4 etc.

• No fixed number of processes at each level• Goal is to make the diagram readable and

meaningful

Balancing DFD

• Process inputs and outputs need to be equivalent on successive levels

• Note that this is the minimum (and inviolable) requirement. Preferable that they be the same (but “splitting” is permitted)

Completeness and Consistency

• Completeness – all necessary detail included (not just process and data flow names!)

• Consistency – between levels

Design Rules & Guidelines - Processes

• No process can have only inputs• No process can have only outputs• A process has a verb label -

What does the process ‘DO’• For any process, the data flows in should be

different from the data flows out – Indicates some form of data transformation

• Processes should be named uniquely *

Design Rules & Guidelines – Data Flows

• A data flow is usually shown with one direction only• A fork in a data flow means exactly the same data

flows to multiple destinations• A join in a data flow means exactly the same data flows

from multiple sources• A data flow cannot go directly back to the process it

left – something has to happen to it in the meantime!• A data flow to a data store means update, from a data

store means retrieve and use• Data flows have noun phrase labels, and should be

named uniquely *

Design Rules & Guidelines – Data Stores

• Data can’t move directly from one data store to another. Must be moved by a process

• Data can’t move directly from an outside source to a data store

• Data can’t move directly to an outside sink from a data store

• A data store has a noun label –This data is ‘ABOUT WHAT’?

• Data stores should be named uniquely *

Design Rules & Guidelines – Sources and Sinks

• Data can’t move directly from a source to a sink

• A Source / Sink has a noun label• ‘WHAT IS IT’ that the system is interacting

with?• Sources / Sinks should be named uniquely *

Old and New

• We may produce up to four sets of DFD• Current physical• Current logical• New logical• New physical