1 / 24

Lecture 3: Introducing Data Flow Diagrams (DFDs)

Lecture 3: Introducing Data Flow Diagrams (DFDs). Section 1 - The Concept of Diagrams Why use Diagrams? Diagrams as Working Documents Systems Analysis Modelling Techniques. Why Use Diagrams?. To help overcome the communication problem between users and developers.

clio
Download Presentation

Lecture 3: Introducing Data Flow Diagrams (DFDs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lecture 3:Introducing Data Flow Diagrams (DFDs) Section 1 - The Concept of Diagrams • Why use Diagrams? • Diagrams as Working Documents • Systems Analysis Modelling Techniques

  2. Why Use Diagrams? • To help overcome the communication problem between users and developers. • Use of natural language, written or spoken open to • misinterpretation • ambiguities • omissions • Diagrams • help communication • help understanding • are unambiguous

  3. Why Use Diagrams (Cont’d) DEVELOPERS (have discussions with users etc)  CREATE DIAGRAMS (to record understanding)  AMEND DIAGRAMS (with further information)  USE DIAGRAMS as the  BASE OF SYSTEM STRUCTURE

  4. Diagrams as Working Documents • Diagrams are working documents: • changes will occur (for correctness) • changes must be documented and tracked • Change is integral to the development process.

  5. Systems Analysis - Modelling Techniques (Examples) • Data Flow Diagrams • Entity Relationship Diagrams • Normalisation • Entity-Life Histories

  6. Lecture 3:Introducing Data Flow Diagrams (DFDs) Section 2 - Data Flow Diagrams (DFDs) • Data Flow Diagramming • DFD Notation • DFD Levelling • Guidelines for Drawing DFDs • Connectivity & Validation

  7. Data Flow Diagramming • Business users normally define their business operation in terms of the processes of that operation. A process may be defined as an action or series of actions which produce a change or development. • The process view of a system may be modelled by a Data Flow Diagram (DFD).

  8. Data Flow Diagramming (Cont’d) • DFDs concentrate upon the data needed to support the information requirements of a system: • what data is needed • the processes that convert it. • Data flow diagrams provide: • the notion of structure • static pieces of documentation • communication tool • DFDs are one of the most powerful and useful techniques available to the systems analyst.

  9. DFD Notation A DFD has four key components. External Entity Process Data Store Data Flows

  10. Processes • Processes are the individual tasks which when completed in a certain sequence fulfil the overall goal of the system of which they are a part. 2 Sales Clerk Validate Customer Order Processes transform input into output.

  11. Data Flows • Data Flows depict the fact that some data in the form of documents, phone calls etc is moving. • From an external entity to a process (or vice versa). • From one process to another. • From a process to a store (or vice versa). invoice address

  12. Data Flows (Cont’d) Write data to a file Take data from a file

  13. Customer order 1 Sales Clerk Validate Order new_order part_number D1 Orders D2 Stock Data Flows (cont’d) • Data flow names should be different if the form of their data elements changes on entry to and exit from a process.

  14. Data Stores D1 Stock • Data Stores contain data which is needed by a process in order for it to be completed. • These show data ‘at rest’ within the system. • They carry a description and are numbered D1, D2, D3 etc (computer data) or M1, M2, M3 etc (manual files).

  15. External Entity Customer • External entities exist in the system’s environment and either provide data to the system (sources) or receive data from the system (sinks). • They are usually people, places, departments, organisations etc.

  16. DFD Levelling • DFDs allow the analyst to look at the system at different levels of detail. • A business operation may contain many processes. • The inclusion of all processes on a single diagram can: • make it look cluttered • make it difficult to see exactly what a process does • To overcome this it is usual to ‘break down’ the diagram, a process known as levelling.

  17. DFD Levelling (See Lejk & Deeks p67) Context Level 1 Level 2 1 2.1 External Entity Sub-process Process 2 2.2 Overall Process Sub-process Process 3 2.3 External Entity Sub-process Process

  18. Context Diagrams (Overview or Level 0) • Represent the system at a high level of detail. Comprised of: • One single process box for the entire system. • External entities. • The data flows that pass between the external entities and the system.

  19. Context Diagrams (cont’d) Purpose: • to identify and examine the interfaces between the external entities and the system.

  20. Example Context Diagram Customer order Simple Order System invoice delivery_details Customer

  21. Level 1 Diagrams Show: • the system in more detail • how data enters the system • how these data items are transformed by the processes • how they leave the system • A Level 1 diagram must have the same number of inputs and outputs as its context diagram. • The flows are connected to and from the actual processes which create, receive or change them. • Processes are numbered 1, 2, 3 etc on a Level 1 diagram.

  22. Guidelines for Drawing a Context Diagram • Read the case study a number of times. • Try to list potential external entities. • Establish what flows are sent to the system from the external entities. • Establish what flows are sent from the system to the external entities. • Draw the Context diagram.

  23. Guidelines for Drawing a Level 1 Diagram • Taking one sentence at a time try to identify potential processes (look for verbs). • Identify and list the data flows. • Identify and list the data stores. • Draw the Level one diagram (using the correct notation).

  24. ‘Connectivity & Validation’ • Make sure the Level 1 diagram is fully connected. • That is, a process must receive inputs from other processes or from data stores to be triggered. • Check the Level 1 diagram against the context diagram for consistency: • flows across the boundaries must be the same • names must be the same

More Related