System Decomposition Overview

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, 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