1. johnb DFDs and Design John Bell The DeMarco notation

2. 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

3. 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

4. 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

5. 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.

6. 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

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

8. 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

9. johnb 4 DFD Objects o 4. Process »a transform that processes incoming data flows into changed outgoing data flows 1.2 Validate Sale sale detailsvalid sale details

10. johnb 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 compute price process data

11. johnb 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. johnb 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”) 2.1 validate customer order customer order invalid customer order valid customer order

13. johnb DFD Objects Data 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 generate invoices sales generate shipping slips valid sales order invoice shipping slip

14. johnb DFD Objects Data Flows data flows can converge when several packets of data join together to form an aggregate packet of data 2.1 produce sales order valid customer details valid order item details valid sales order details sales order

15. johnb 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. johnb 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 produce sales order 2.1 produce sales order 3.2 validate applications 3.1 register applications 3.3 assess applications application registered application valid application approved application reject

17. johnb 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 produce weekly sales totals 2.1 check sales order Sales Orders sales order checked sales order weekly sales totals

18. johnb DFD Objects Data Stores each data store may correspond to 1 or more entities in the logical data model Sales Orders Sales Order Item

19. johnb 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. johnb 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 Customer Tax Office Supplier Order inventory system sales order invoice payment sales tax details purchase order delivery invoice

21. johnb Drawing DFDs Levelling DFDs 1 3 2 3.1 3.2 Context Diagram Level 1 Diagram Diagram 3 at Level 2

22. johnb 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. johnb Drawing DFDs Creating Logical DFDs eliminate implementation details: Naming 2.1 Bill checks form 2.1 Validate sales order AZ104 sales order valid sales order valid AZ104

24. johnb Drawing DFDs Physical DFDs example of a physical DFD for an order processing system – NB …. DFDs should NOT be drawn this way 2.1 Reception clerk x4 order formchecked x4 form 2.2 Sort into areas 2.3 send to production section sorted x4 forms. 2.4 production section despatched orders A66-production request form

25. johnb Drawing DFDs Creating Logical DFDs logical DFD of the same processing 2.1 check customer order customer order checked customer order 2.2 Check production feasibility 2.3 commit resources accepted order order resources schedule order details resources used