Systems Analysis I Data Flow Diagrams

1. Systems Analysis IData Flow Diagrams ISYS 200 Glenn Booker Week #4

2. Data Flow Diagrams • Data Flow Diagrams (DFDs) are the primary tool for summarizing the processes a system can perform • They are useful both for capturing the existing system’s capabilities, and then are revised to show the new system’s processes • A DFD shows processes, entities, and data stores, connected by data flow lines Week #4

3. Data Flow Diagrams • Processes are the functions some user can perform using the system • Users indicate the kind of user who is allowed to perform each process (clerk, sales manager, etc.) • The data stores on a logical DFD are a high level description of the types of data storage needed to perform each process Week #4

4. Data Flow Diagrams • DFDs can show either the logical structure of processes, or the physical structure • Logical structure shows all possible processes, regardless of where they occur in the system • Physical structure indicates what physical parts of the system (e.g. type of servers) perform each kind of process • Unless specified, assume we imply a logical DFD Week #4

5. DFD Notation • Here are Visio examples of the entity, process, and data store shapes, with data flow lines connecting them • If your shapes differ from the text’s, provide a legend Note that in Visio, these shapes are under the Flowchart family, not Database Week #4

6. DFD Scope • A DFD does not show any kind of business rules for processes – just all possible paths • No decisions, or conditions (if) • A logical DFD does not show the subsystems involved in a process • We might show a Customer data store, but don’t specify how or where is it implemented • Processes may be manual or automated – there is no distinction on a logical DFD Week #4

7. DFD Notation – Entities • More formally, the ‘kind of user’ is called an entity in the text – an unfortunate choice when we get to the ERD* • An entity can be a type of user, or some kind of external system with which your system interacts • External systems might include other information systems within or outside of your organization • Like a legacy system used for processing invoices * An entity in a DFD could be more general than an entity in an ERD Week #4

8. DFD Notation – Processes • Processes are the business functions performed using the system • We prefer a “verb (adjective) noun” naming convention for processes • Prepare shipping invoice • Enter new customer • Remove backorder • Update reorder parameters • Number processes for later reference Week #4

9. DFD Notation – Data Stores • A data store is a kind of data needed to perform processes • Temporary data isn’t shown on a logical DFD • Data stores can be manual or automated • A data store is labeled with the type of data • Sales • Customer • Put a reference number in front of each data store name, e.g. D1, D2, D3, etc. Week #4

10. Creating a Logical DFD • Data flow diagrams can be done on multiple levels of detail, as your understanding of the system evolves • Start by listing the processes and activities associated with your system, and look for entities, processes, and data stores • Create a context diagram (the simplest DFD) • Create the diagram 0 data flow diagram, showing entities, general processes and data stores • Include data flow names Week #4

11. Creating a Logical DFD • Pick significant processes, and expand them into more detailed DFDs if needed • The numbering of processes reflects the level of detail shown • The system is process ‘0’ in a context diagram • In a diagram 0 DFD, the processes are numbered 1, 2, 3, etc. (parent diagram) • To expand on process 3, Diagram 3 would show processes 3.1, 3.2, 3.3, etc. (child diagram) Week #4

12. Creating a Logical DFD • Watch the zeros! Process ‘0’ does NOT appear on the Diagram 0 DFD! • Diagram ‘x’ means it is a DFD which expands on the contents of the process numbered ‘x’ • So Diagram 3.2 would contain processes 3.2.1, 3.2.2, 3.2.3, etc. • Page 200 has a good Diagram 0 DFD • This is the lowest level of DFD detail we’ll use Week #4

13. Levels of DFD Week #4

14. Rules for Data Flow Diagrams • Entities never connect directly to a data store • They must use some process to access or modify the data • Hence a user or external system can only connect to one or more processes • All kinds of entities which appear on the context diagram must appear somewhere on the DFD • Otherwise they don’t do anything! Week #4

15. Rules for Data Flow Diagrams • Each process will connect to at least one user or external system, and one data store • Each process may send data to one or more data stores, and/or get data from one or more data stores • Processes rarely connect to other processes • Each process needs data flowing in and out of it • Fix processes which have logically incomplete inputs and outputs Week #4

16. Rules for Data Flow Diagrams • Leave in processes which calculate something, make decisions, manipulate data, or organize data • Data flows into and out of parent and child diagrams should be consistent • Data flows pointing away from an entity imply they provide input to the system • Data flows pointing to an entity imply they receive an output from the system Week #4

17. Rules for Data Flow Diagrams • Every data store needs data flowing both in and out somewhere on the diagram • Otherwise you have a data black hole = inputs but no output, or • A miracle = outputs without input • Data stores do not connect directly to each other • A process is needed to take data from one data store, and write it to another one Week #4

18. DFD Evolution • Typically three steps are used with DFDs • The first DFD captures the processes used by the existing system • The second DFD describes the processes to be used by the new system • A third DFD is a physical description of the new system • The first two DFDs are logical DFDs • Now we’ll mention the physical DFD Week #4

19. Physical DFDs • A physical DFD shows how processes will be implemented • Entities are still entities • Data stores are now files, and may include temporary files • Processes are now specific programs or manual procedures • See example on page 202 Week #4

20. Partitioning a DFD • A Physical DFD can be partitioned to help determine the structure of the application • Partitioning groups processes by similarity • Group manual processes vs. automated ones • Group processes by the type of user • Group processes by their time sequence • Group processes which perform similar tasks • Group processes which use similar resources Week #4

21. Partitioning • Group processes to ensure consistent data • Group processes for security protection • Partitioning can also be done at the user interface level (e.g. a web site) for the same kinds of reasons Week #4

22. CRUD Matrix • A CRUD matrix maps data and processes to verify that all data is used correctly throughout the system • CRUD refers to the possible activities • Create new data • Read existing data • Update or change or modify existing data • Delete existing data Week #4

23. CRUD Matrix • The CRUD matrix shows process names in each row, and data stores in each column (p. 203) • For each process and data store, enter C, R, U, and/or D to indicate the possible data activities • A blank indicates that process does not affect that data store • For further clarity, use the process and data store numbers from the DFD Week #4

24. CRUD Matrix • At a minimum, make sure each data store is Created and Read by at least one process • Update and Delete may be optional Week #4

25. Event Response Table • Further documentation of processes is encouraged • One form is the event response table (p. 204) • This provides a summary of each process • Event – is the process name • Source – is the entity who starts the process • Trigger – is the data or stimulus which is needed from the source Week #4

26. Event Response Table • Activity – is a brief description of the process • Response – is typically an interface screen (for a human Destination) or type of data (for an external system Destination) which conveys the results of the process • Destination – is the entity which received the output from the process (whether human or an external system) Week #4

27. Other DFD Documentation • Another approach for documenting a DFD is to outline the contents of the DFD before making the drawing • Identify the entities and processes • Make a table to show • Process Name, Description, Entities, Inputs, Outputs, and Data Sources Week #4

28. Other DFD Documentation • Except Description, these all correspond directly to stuff which appears on the DFD: • Process Name – the label inside the process shape (later add the numbering) • Description – a brief description of the process • Entities – are the entities which participate in the process • Inputs – are data flow(s) leading into the process • Outputs – are data flow(s) leading out of the process Week #4

29. Other DFD Documentation • Data Sources – are the data stores connected to the process (later add the numbering) • Notice that the Inputs and Outputs are the data flow labels, which could be coming from or to entities or data stores • Use the table to help arrange the processes • For example, sort the processes by Entity to help see which processes should be grouped together on the DFD Week #4

30. Other DFD Documentation • Duplication of entities and data stores is permitted on a DFD for clarity • Flag or footnote them to indicate a deliberate duplicate is being used • In addition to the description of processes, provide a brief description of the data stores and entities • Note any assumptions about the scope or responsibilities of anything in the DFD which affected your modeling decisions Week #4