DFDs and Design

1
DFDs and Design
The DeMarco notation

• John Bell

2
Uses of DFDs

• used to represent the processing which occurs
  within systems
• most systems are too complex to be represented by
  just 1 DFD - so the system is partitioned into a
  hierarchy of manageable components, each
  consisting of related processes

3
Uses of DFDs

• a DFD can be viewed as either a physical or a
  logical DFD depending on the extent to which it
  does or does not model a technology-specific
  implementation
• desirable to produce logical DFDs which represent
  what the processing is required to accomplish,
  rather than physical DFDs which represent how the
  processing requirements are met

4
Uses of DFDs

• Physical DFDs may be used to assist with
  understanding of existing processing and as an
  aid to deriving the logical DFD
• DFDs
• do not include any procedural, control or timing
  aspects of processing. Initialisation,
  termination or control are not modelled

5
DFDs

• a useful analysis tool that
• uses models and standard, expressive notation
  to aid understanding of complexity and to assist
  scoping and specification of systems
• Partitioning
• entire system is first represented as a single,
  unlevelled process in the Context Diagram. This
  defines the systems boundary in terms of its
  data and information interfaces with its
  environment.

6
DFDs

• Partitioning (cont)
• the diagram at the next level - the Level one
  diagram - represents the highest level
  partitioning of the system. Each process in this
  diagram
• represents a major business activity.
• can be exploded to a further level of detail as
  a DFD in its own right. This can be continued as
  far as required until primitive processes are
  reached

7
4 DFD Objects

• 1. External Entity
• represents any person, thing or system external
  to the processing in the diagram and which either
  supplies data to the processing (a Source) or
  receives data output from the processing (a
  Sink)

Customer
8
4 DFD Objects

• 2. Data Flow
• represents a packet of data moving between
  objects
• 3. Data Store
• represents data either temporarily or permanently
  at rest

cash sale details
Transactions
data flow
data store
9
4 DFD Objects

• 4. Process
• a transform that processes incoming data flows
  into changed outgoing data flows

sale details
valid sale details
1.2 Validate Sale
10
DFD Objects
Processes

• each process should have a unique number and a
  name that
• describes clearly what the process does
• should use a verb and a noun phrase (eg. compute
  price,
• validate customer data, accept supplier
  delivery) and avoid
• vague names (eg. process data)

2.1
process data
compute price
11
DFD Objects
Processes

• a process MUST have at least 1 data flow
  entering in and
• at least 1 data flow flowing out of it and
  there must be a
• change in the contents of data flows

12
DFD Objects
Data Flows

• represent data packets moving through the
  system
• the name should describe the contents of the
  data
• packet - use a noun phrase - and imply the
  contents of the
• the data flow as clearly as possible (eg
  customer payment
• rather than just payment)

invalid customer order
2.1
customer order
validate customer order
valid customer order
13
DFD Objects
Data Flows

• data flows can diverge when duplicate packets
  of data are
• sent to different parts of the system

2.2
generate invoices sales
invoice
valid sales order
2.1
validate sales orders
2.3
generate shipping slips
shipping slip
14
DFD Objects
Data Flows

• data flows can converge when several packets of
  data join
• together to form an aggregate packet of data

valid customer details
2.1
sales order
produce sales order
valid order item details
valid sales order details
15
DFD Objects
Data Flows

• data flows are permitted
• between 2 processes
• from a data store to a process
• from a process to a data store
• from a source to a process
• from a process to a sink

16
DFD Objects
Data Flows

• omit any processing required to handle trivial
  rejects -
• ie. rejects where no work needs to be undone
• show the possibility of trivial rejects by using
  a data flow
• labelled reject. It is allowable for such
  flows to have no
• destination indicated

2.1
2.1
valid application
3.1
3.3
3.2
produce sales order
produce sales order
register applications
validate applications
assess applications
registered application
reject
application
approved application
17
DFD Objects
Data Stores

• represent a collection of data packets at
  rest
• each data store has a unique name - a plural
  noun that
• clearly signifies the contents of the data
  store
• data flows to or from a data store may remain
  unlabelled
• if all attributes in the store are moving -
  ie. if an entire packet
• (or packets) is going into or out of the data
  store

2.2
checked sales order
2.1
sales order
produce weekly sales totals
check sales order
weekly sales totals
Sales Orders
18
DFD Objects
Data Stores

• each data store may correspond to 1 or more
  entities
• in the logical data model

Sales Order
Sales Orders
Item
19
DFD Objects
External Agents

• represent external objects with which the system
  
• communicates and which are outside the scope of
• the system
• eg. outside organisation or individual
• government agency
• another department
• another system
• data flows connecting the external agents to
• processes within the system represent the
  interface
• between the system and its environment

20
Drawing DFDs
Context Diagrams

• the highest level DFD that shows the interaction
  with
• the system and its environment (data flows) and
• defines the system boundary

invoice
purchase order
sales order
Customer
Order inventory system
delivery
Supplier
payment
invoice
Tax Office
sales tax details
21
Drawing DFDs
Levelling DFDs
Context Diagram
Level 1 Diagram
Diagram 3 at Level 2
1
3.1
3
3.2
2
22
Drawing DFDs
Levelling rules

• the data that flows into and out of a parent
  process must
• match the data that flows into and out of the
  related child
• diagram
• diagrams should have approximately no more than
  7
• processes
• levelling should continue until bottom level or
  primitive
• processes are reached
• not all parts of the system need to be
  decomposed to the
• same level

23
Drawing DFDs
Creating Logical DFDs

• eliminate implementation details Naming

2.1
AZ104
valid AZ104
Bill checks form
2.1
valid sales order
Validate sales order
sales order
24
Drawing DFDs
Physical DFDs

• example of a physical DFD for an order
  processing system
• NB . DFDs should NOT be drawn this way

2.1
2.2
x4 order form
checked x4 form
Reception clerk
Sort into areas
A66-production request form
sorted x4 forms
despatched orders
2.3
2.4
.
send to production section
production section
25
Drawing DFDs
Creating Logical DFDs

• logical DFD of the same processing

2.1
checked customer order
2.2
check customer order
customer order
Check production feasibility
accepted order
order details
2.3
order
commit resources
resources used
resources schedule