Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs)

Transcription

1 Introduction Data Process Modeling: Context Diagrams & Data Flow Diagrams (DFDs) MIS 374 When designing/building an information system for an organization, you should consider the following questions regarding the information processed by the system: Who (i.e. which stakeholder(s)) needs this information? What information is needed? Where is that information stored? How is the information transformed as it enters the system, flows through it, and is outputted? As a systems analyst, programming analyst, or IT auditor you are likely to need a graphical technique to help investigate and document how data is inputted into the system either manually or automatically. You ll also need to see how data flows through the system, is changed, and stored. Lastly you should consider what the output is and how data is retrieved from the system (e.g. reports, exports to external systems). Graphics that are data focused will greatly assist you in your ERD creation and overall database design. Since the database is a foundation of your system, it s important to model it thoroughly. Graphics also simplify complex components of a system. By creating a simpler depiction of the system we can better communicate with our non-technical client or future users how the system works. The Story-Telling Power of DFDs DFDs tell stories. They do not capture the business process (i.e. how you do your job function), but instead focus on where the data comes from, where it goes, and how it changes. DFDs help depict the data flowing through a system in a visual way that enables you to better communicate with other IT professionals and stakeholders. Therefore, another trained person (i.e.: a 374 classmate, the TAs, and the professors) should be able to read your DFDs without ever reading the supporting case materials. Your DFDs should be self-explanatory and thoroughly explain the system s data transformation processes. Description A data flow diagram (DFD) is a drawing that shows how a system's environmental entities, processes, and data are interconnected. Developers or users can depict their current system processes or desired system process using the four simple symbols shown in Table A below. Table A. Data Flow Diagram Symbols Environmental Entity (EE) a source of, or destination for, data outside the system. Data flow each data flow must have a unique identifier or label describing the data. Process bubble a process that changes data. Process bubbles should be numbered in the top section of the bubble. The Process Label should be in a verb object format, and placed in the middle section of the bubble. The bottom section of the bubble should identify the actor or system component performing the process Data store where the data is stored (e.g. database, file, file cabinet). Page 1 of 7

2 DFD Symbols and Rules As stated on page 1, DFDs consist of four basic symbols that represent (1) environmental entities, (2) data flows, (3) processes, and (4) data stores. External Entity (EE) Symbols. Systems interface with persons, organizations, locations, and other systems. Each of these entities in the environment is represented by a square and includes the name of the entity. Sometimes drawings become cluttered if data flow arrows are needed from several different processes to the same EE. In this case, consider repeating an EE square, and remember to include the EEn label to make sure that it s clear that two EE squares with the same names are identical and not different entities. Process Symbols. A process is a transformation of data. Data flows into a process, is transformed, and then flows out. In order for something to be a process, the output must be different from the input in some way. Process symbols are labeled with a verb and object, such as Verify User Name and Edit Date. The context diagram is an exception: the central oval is labeled with the system name, and is not a particular process. Data Flow Symbols. A good way to think of a data flow is "data on the move. The data moves from an environmental entity to a process, from one process to another, from a data store to a process, and so on. In most cases the data flow is a single line going in one direction; two-headed (or forked) arrows can be used to show the same data flows from one process, data store, or entity to more than one destination. Each data flow in a DFD is labeled with a unique name in the same diagram. However, when the same flow appears on more than one level the same name is used for each appearance. Data Store Symbols. Whereas data flows represent data on the move, data stores represent data that is maintained in fixed locations. Think of a data store as "data at rest." Examples of data stores are master files, such as inventory and personnel data that are kept current, and history files that are held in archival storage. Data stores are depicted with open-ended rectangles and have a unique label, such as D1, D2, etc. Rules for Creating DFDs Be sure to adhere to the following rules when creating your DFDs. This will ensure consistency across your diagrams, and help you clearly communicate the story to your reader: 1. Input to a process should be different than the output 2. Processes must have both and input and an output 3. Objects (e.g. environmental entities, data stores) should have unique names a. Remember, you may repeat an object in order to unclutter your diagram 4. Each diagram should have 7 or fewer processes 5. Each process should have a verb phrase label to describe the process 6. Data flows labels should be noun phrases 7. Data only flows in one direction at a time 8. Data must be transformed by a process (i.e. it cannot move directly between environmental entities or data stores) 9. Data store labels should be noun phrases 10. It may be okay if Figure 0 has no actors on a process The Context Diagram DFDs exist in a hierarchy, beginning with the simplest, highest, system level diagram, called the context diagram. This system level diagram illustrates the context, that is, the circumstances of the system environment. This diagram contains only a single, unnumbered process bubble in the shape of a circle to Eleanor Jordan All rights reserved. (Update 2015 by Clint Tuttle) Page 2 of 7

3 represent the entire system and ending with the lowest level diagrams that contain the most detailed data transformation processes. Figure A illustrates the context diagram for the existing Latinitas system with a single process bubble in the middle. The five environmental entities are represented by squares surrounding the single system process bubble. The system is connected to its environmental entities by arrows that represent data flows. Notice how many data flows surfaced in the team s discussions with Angie about her work with Latinitas donors, volunteers, and interns. When Angie posted her request for an MIS 374 Volunteer Database, she had not thought through her real needs. White-boarding with her MIS 374 development team was a learning experience for Angie as well as the team. Figure A - Context Diagram for Existing Latinitas System The Figure 0 Diagram The next level in the DFD hierarchy is referred to as the Figure 0 Diagram. This diagram provides the first level of detail of the high-level processes contained in the system bubble of the context diagram. Each process of the Figure 0 diagram is numbered from left to right and then top to bottom. In order to prevent a DFD from becoming cluttered, the general rule is to keep the number of processes depicted in a diagram to seven or less. This rule applies to the Figure 0 diagram as well as DFDs on lower levels as well. Figure B shows the Figure 0 diagram of the existing Latinitas system. The system contains four highlevel (or main) processes: Manage Interns, Manage Volunteers, Organize Fund Raising Events, and Determine Needs for Funds. Page 3 of 7

4 Figure B - Level 0 (Figure 0) DFD for the Latinitas System MIS 374 Because the Figure 0 diagram contains more detail than the context diagram, it is important to ensure that the data flows to and from each environmental entity must match between each level. In the Figure 0 diagram above, the same five environmental entities and their labeled data flows from the context diagram are included and now connect to more specific processes in the Latinitas system. are included. For example, the Fundraising Donor at the bottom right of Figure 0 above has exactly two data flows with the same names as the two data flows for the Fundraising Donor in the Context Diagram. Also note that the Job Duties dataflow splits from Process 3 when flowing into Process 1 and 2. Since some processes can create data that is then used by multiple subsequent processes, you re allowed to do this when it makes sense. This will reduce duplicate dataflows and over-crowding in your model. Figure n Diagrams In the next level of the hierarchy, the individual processes identified in the Figure 0 diagram are detailed in their own diagrams, called Level 1 diagrams. For example, you would create a Figure 1 diagram to provide detail about the first process (Manage Interns in the above example). You would create a Figure 2 diagram to provide detail about the second process (Manage Volunteers in the above example). We refer to these DFDs as Figure n diagrams. Figure C below illustrates a Level 1 diagram for Process 3 of the Latinitas system Organize Fundraising Event. This Figure 3 DFD consists of five detailed processes numbered 3.1, 3.2, etc. Process 3.1 is the initial process of obtaining and processing donations needed to hold an event. The second detailed process of Figure 3 is process 3.2, the determination of when to hold fundraising events. Page 4 of 7

5 Figure C Level 1 (Figure 3) DFD for Organizing Fundraising Events If additional detail is needed for any of the processes in a Level 1 diagram, you would create a Level 2 diagram. The logic for creating a Level 2 diagram is similar to creating a Level 1 diagram: You should have 7 or fewer detailed processes The data flows to and from each relevant environmental entity should match the data flows in the Level 1 diagram for that environmental entity. The numbering of each process should follow the numbering of the process in the Level 1 diagram. For example, to provide more detail about process 3.1 from the Figure 3 diagram, each process would be numbered 3.1.n. Please see below for an example. Page 5 of 7

6 Figure D - Level 2 (Figure 3.1) DFD for Obtaining Donations Now that the diagrams have reached a sufficient level of detail, the data store symbol has been introduced in Figure 3.2 above. In this example, Donor Information is a manila folder that Angie keeps; the Donor Database and Donations Per Event are spreadsheets. All data store symbols should have identifiers, such as D1, D2 and D3, depending on how many data stores are used in the system being modeled. NOTE: You may introduce data stores in any diagram (except for the context diagram) you can include them in Figure 0, Level 1 diagrams, Level 2s, etc The same top-down decomposition of the system processes can be continued for more detailed levels. However, it is not necessary to document the same level of detail for all processes. Some processes can be adequately documented at a higher level in the hierarchy. The top-down process of documenting a system with DFDs continues until you reach a level of detail where the focus is on individual data flows that are important to determining functional requirements for the scope of a project. Tip when Creating DFDs Page 6 of 7

7 Our example figures for Latinitas are the result of considerable time spent by the team with Angie, their client. A good way to start is to create the simple context diagram with an in the middle to represent the entire system. Then ask your client about what data the system must produce and what data is required for the system s functionality. If you do your work on a white-board, photograph the board at the end of your discussion. If you think your initial work is fairly accurate, then create an electronic version of the context diagram in Visio or LucidCharts that will allow you to add Environmental Entities and data flows as you talk with stakeholders to learn more details and create lower level DFDs. Few clients will be able to provide all of the necessary answers, so you will need to talk with key stakeholders that understand the existing system to analyze the processes for an existing system. Individuals are likely to be able to only describe processes they perform. You will likely perform several iterations, collecting information from several stakeholders, and then analyzing the data you collected to consolidate into the DFDs to accurately describe the existing system FAQs Q1: How do I make my DFDs pretty? All the lines are crisscrossed. Answer: Try to organize your external entities (EEs) around the outside edges of the document. Then, put your process bubbles between these entities. If any process uses multiple EEs, try to put the EEs close to each other. Also try to use right-angle connectors; they make the diagrams more legible, as well as, help you group in-bound and out-bound data flows together. Q2: How do I even begin to make my DFDs? I m totally stuck. Answer: The Group Project case lists steps for major processes. Start with each process separately using the interview data. The Group Project 1 specification requires you to collect these (or roll up these details) into a summary level DFD (Figure 0) to just show major processes at the summary level. The instructions only require that you turn in a few Level 1 DFDs so you only have to create a few clean Level 1 DFDs that follow all the rules (e.g. a Figure 1, Figure 2, Figure 3). Before creating a Figure 0 diagram, make a list of all the data flows that go to and from the external entities in your Level 1 diagrams, so you know what needs to show up on the Figure 0 diagram and Context diagram. Some analysts find it easier to work on paper or whiteboard before using Visio or Lucidcharts. For your client project you may want to white board processes and then take photos to use for Visio or Lucidcharts graphics. Q3: What are some general hints when making DFDs? Answer: Label your external entities (ex: EE1 and EE2). If you use the same external entity multiple times, make sure each has the same EE number. Also, make sure external entities don t talk with each other. That is, don t draw data flows between external entities instead, these data flows must be connected through some process bubble in the System. Remember that every process must transform data. Printing doesn t transform data. A data flow arrow, not a process bubble, shows sending or delivering data. Use the Gane-Sarson process symbols if you are using Visio. This stencil has all the symbols you need for DFDs but you can also just find symbols that match the ones list above. Just make them consistent to the symbols above so we don t have to interpret your DFD. NOTE: Gane-Sarson process symbols are the process bubbles above with three parts process ID # on top, verb object process label in the middle, and who/what performs the process on the bottom. Page 7 of 7