johnb
Uses of DFDs
o used to represent the processing which occurs within systems
o 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
johnb
Uses of DFDs
o 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
o 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
johnb
Uses of DFDs
o Physical DFDs may be used to assist with understanding of existing processing and as an aid to deriving the logical DFD
o DFDs:» do not include any procedural, control or
timing aspects of processing. Initialisation, termination or control are not modelled
johnb
DFDs
o a useful analysis tool that: » uses models and standard, expressive notation: to
aid understanding of complexity and to assist scoping and specification of systems
o Partitioning:» entire system is first represented as a single,
unlevelled process in the Context Diagram. This defines the system’s boundary in terms of its data and information interfaces with its environment.
johnb
DFDs
o 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
johnb
4 DFD Objects
o 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
johnb
4 DFD Objects
o 2. Data Flow» represents a ‘packet‘ of data moving
between objects
o 3. Data Store» represents data either temporarily or
permanently at rest
cash sale details Transactions
data flow data store
johnb
4 DFD Objects
o 4. Process» a transform that processes incoming data
flows into changed outgoing data flows
1.2 Validate Salesale details valid sale details
johnb
DFD Objects
ProcessesProcesses
• 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
compute price
process data
johnb
DFD Objects
ProcessesProcesses
• 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
johnb
DFD Objects
Data FlowsData 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”)
2.1
validate customer order
customer order
invalid customerorder
valid customer order
johnb
DFD Objects
Data FlowsData Flows
• data flows can diverge when duplicate packets of data are sent to different parts of the system
2.1
2.2
2.3
validate sales orders
generateinvoices sales
generate shipping slips
valid salesorder
invoice
shipping slip
johnb
DFD Objects
Data FlowsData Flows
• data flows can converge when several packets of data join together to form an aggregate packet of data
2.1produce sales order
valid customer details
valid order item details
valid sales order details
sales order
johnb
DFD Objects
Data FlowsData 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
johnb
DFD Objects
Data FlowsData 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
produce sales order
2.1
produce sales order
3.2 validateapplications
3.1 registerapplications
3.3
assess applications
application
registeredapplication
validapplication
approvedapplication
reject
johnb
DFD Objects
Data StoresData 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.2produceweekly sales totals
2.1checksalesorder
Sales Orders
salesorder
checked salesorder
weekly salestotals
johnb
DFD Objects
Data StoresData Stores
• each data store may correspond to 1 or more entities in the logical data model
Sales Orders
Sales Order
Item
johnb
DFD Objects
External AgentsExternal Agents
• represent external objects with which the system communicates and which are outside the scope of the system
eg. outside organisation or individualgovernment agencyanother departmentanother system
• data flows connecting the external agents to processes within the system represent the interface between the system and its environment
johnb
Drawing DFDs
Context DiagramsContext Diagrams
• the highest level DFD that shows the interaction with the system and its environment (data flows) and defines the system boundary
Customer
TaxOffice
Supplier Orderinventory system
sales order
invoice
payment
sales tax details
purchase order
delivery
invoice
johnb
Drawing DFDs
Levelling DFDsLevelling DFDs
1
3
2
3.1
3.2
ContextDiagram
Level 1Diagram
Diagram 3 atLevel 2
johnb
Drawing DFDs
Levelling rulesLevelling 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
johnb
Drawing DFDs
Creating Logical DFDsCreating Logical DFDs
• eliminate implementation details: Naming
2.1Billchecks form
2.1Validate sales order
AZ104
sales ordervalid sales order
valid AZ104
johnb
Drawing DFDs
Physical DFDsPhysical DFDs• example of a physical DFD for an order processing system – NB …. DFDs should NOT be drawn this way
2.1
Receptionclerk
x4 order form checked x4 form2.2
Sort intoareas
2.3send toproductionsection
sorted x4forms.
2.4
productionsection
despatchedorders
A66-productionrequest form