Refer to the following figure which contains drafts of a context and level-0 DFD for a University class CHAPTER 7 STRUCTURING SYSTEM PR TABLE 7-2 Rules Governing Data Flow Diagramming Process: A. No process can have only outputs. It would be making data from nothing (a miracle). If an object has only outputs, then it must be a source B. No process can have only inputs (a black hole). If an object has only inputs, then it must be a sink C. A process has a verb phrase label. Data Store: D. Data cannot move directly from one data store to another data store. Data must be moved by a process. E. Data cannot move directly from an outside source to a data store. Data must be moved by a process that receives data from the source and places the data into the data store F. Data cannot move directly to an outside sink from a data store. Data must be moved by a process. G. A data store has a noun phrase label. Source/Sink: H. Data cannot move directly from a source to a sink. It must be moved by a process if the data are of any concern to our system. Otherwise, the data flow is not shown on the DFD 1. A source/sink has a noun phrase label. Data Flow: J. A data flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store to show a read before an update. The latter is usually indicated, however, by two separate arrows because these happen at different times. K. A fork in a data flow means that exactly the same data goes from a common location to two or more different processes, data stores, or sources/sinks (this usually indicates different copies of the same data going to different locations). L. A join in a data flow means that exactly the same data come from any of two or more different processes, data stores, or sources/sinks to a common location. M. A data flow cannot go directly back to the same process it leaves. There must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process. N. A data flow to a data store means update (delete or change). 0. A data flow from a data store means retrieve or use. P. A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together as one package. (Source: Based on Celko, 1987.) Guidelines for Drawing DFDs In this section, we will consider additional guidelines for drawing DFDs that extend berond the simple mechanics of drawing diagrams and making sure that the rules listed in Tables 7-2 and 7-3 are followed. These guidelines include (1) completeness, (2) consistency, (3) timing considerations, (4) the iterative nature of drawing DFDs, and (5) primitive DFDs. Completeness The concept of DFD completeness refers to whether you have included in your DFDs all of the components necessary for the system you are modeling. If your DFD contains data flows that do not lead anywhere or data stores, processes, or external entities that are not connected to anything else, your DFD is not complete. Not only must all necessary elements of a DFD be present, each of the components must be fully described in the project dictionary. Different descriptive information can be kept about each of the four types of elements on a DFD, and each project dictionary standard an organization adopts has different entry information. Data flow repository entries typically include the following: - The label or name for the data flow as entered on the DFDs (Note. Case and punctuation of the label matter, but if exactly the same label is used on multiple DFDs, whether nested or not, then the same repository entry applies to each reference.) - A short description defining the data flow - A list of other repository objects grouped into categories by type of object - The composition or list of data elements contained in the data flow - Notes supplementing the limited space for the description that go beyond defining the data flow to explaining the context and nature of this repository object - A list of locations (the names of the DFDs) on which this data flow appears and the names of the sources and destinations on each of these DFDs for the data flow Consistency The concept of DFD consistency refers to whether or not the depiction of the system shown at one level of a nested. A gross violation of consige with the depictions of the system show no level-0 diagram. Another example of incon. tency would be a level- thingrann wiils noters on a higher-level DFD but not on lower levels (also a violation of balancing). Yet another example of inconsistency is a datata flow attached to one object on a lower-level diagram but also attached to another object at a higher level; for example, a data flow named Payment, which serves as input to Process 1 on a level- 0 DFD, appears as inpul to P Process 2. Timing lou may have noticed in some of the DFD examples we have presented that DFDs do not do a very good job of representing time. On a given DFD, there is no indication of whether a data flow occurs constantly in real time, once per week, or once per year: There is also no indication of when a system would run. For example, many large, transaction-based systems may run several large, computing-intensive jobs in batch mode at night, when demands on the computer system are lighter. A DFD has no way of indicating such overnight batch processing. When you draw DFDs, then, draw them as if the system you are modeling has never started and will never stop. Iterative Development The first DFD you draw will rarely capture perfectly the system you are modeling. You should count on drawing the same diagram over and over again, in an iterative fashion. With each attempt, you will come closer to a good approximation of the system or aspect of the system you are modeling. Iterative DFD development recognizes that requirements determination and requirements structuring are interacting, not sequential, subphases of the analysis phase of the SDLC. Primitive DFDs One of the more difficult decisions you need to make when drawing DFDs is when to stop decomposing processes. One rule is to stop drawing when you have reached the lowest logical level; however, it is not always easy to know what the lowest logical level is. Other, more concrete rules for when to stop decomposing include the following: - When you have reduced each process to a single decision or calculation or to a single database operation, such as retrieve, update, create, delete, or read - When each data store represents data about a single entity, such as a customer, employee, product, or order - When the system user does not care to see any more detail or when you and other analysts have documented sufficient detail to do subsequent systems development tasks - When every data flow does not need to be split further to show that different data are handled in different ways - When you believe that you have shown each business form or transaction, computer online display, and report as a single data flow (this often means, for example, that each system display and report title corresponds to the name of an individual data flow) - When you believe there is a separate process for each choice on all lowest-level menu options for the system Obviously, the iteration guideline discussed earlier and the various feedback loops in the SDLC (see Figure 7-1) suggest that when you think you have met the rules for stopping, you may later discover nuances to the system that require you to further decompose a set of DFDs. By the time you stop decomposing a DFD, it may be quite detailed. Seemingly simple actions, such as generating an invoice, may pull information from several entities and may also return different results depending on the specific situation. For example, the final form of an invoice may be based on the type of customer (which Identify and explain potential violations of rules and guidelines on these diagrams (refer to pg. 187 for rules and pg.|195-196 for guidelines)