Chapter 8 : Structuring System Requirements (Process Modeling)

Objectives
  1. Understanding the logical modeling of processes through studying examples of data flow diagrams.
  2. Draw data flow diagrams following specific rules and guidelines that lead to accurate and well-structured process models.
  3. Decompose data flow diagrams into low-level data flow diagrams.
  4. Balancing higher-level and lower-level data flow diagrams.
  5. Explain the differences among four types of DFDs: current physical, current logical, new physical, and new logical.
  6. Use data flow diagrams as a tool to support the analysis of information systems.


Chapter Overview
The purpose of this chapter is to show students one particular method for modeling business processes, data flow diagrams (DFDs). Although there are several methods and techniques available for process modeling, we have chosen to focus on DFDs because they have been popular for many years, especially in the structured analysis and design literature. Many CASE tools, such as the Visible Analyst Workbench�, IEF�, and others, have incorporated DFDs into their sets of system development tools and techniques.

The chapter is divided into several distinct sections, each of which builds on what has come before. After a brief introduction to process modeling, data flow diagramming techniques are introduced in a section called "Data Flow Diagramming Mechanics." This section demonstrates the basic DFD symbols, definitions, and rules. We use the Gane and Sarson symbol set throughout the book, and these symbols are explained in this section. There is also an example from Hoosier Burger, the food ordering system first shown in Chapter 2. This section also includes explanations of decomposition and balancing.

The second major section of Chapter 8 introduces the concept of four different types of DFDs:
(1) current physical,
(2) current logical,
(3) new logical, and
(4) new physical.

We use another example from Hoosier Burger, its inventory control system (which is manual), to illustrate the first three types of DFDs. We point out that current practice in using DFDs indicates that very little time should be spent on the current physical DFD.

The third major section in this chapter, "Using Data Flow Diagramming in the Analysis Process," is novel for an introductory systems analysis and design text. In this section, guidelines for drawing and using DFDs in analysis are introduced. This is different from the mechanical rules presented earlier. Topics include completeness, consistency, timing, iterative development, primitive DFDs, and analyzing DFDs for system inefficiencies and discrepancies among DFDs that are supposed to be modeling the same system. We use another Hoosier Burger example and output from Oracle's Designer/2000 CASE tool to illustrate some of these concepts.

  1. Process Modeling.

  2. Data Flow Diagramming Mechanics.

  3. Four Different Types of DFDs.

  4. Using Data Flow Diagramming in the Analysis Process.

  5. Examples



Return

Process Modeling:
Process modeling involves graphically representing the functions, or processes, which capture, manipulate, store, and disribute data between a system and its environment and between components within a system. A common form of a process modeling is a dtat flow diagram.
Data flow diagramming is one of several notations that called structured analysis techniques.

Data Flow Diagram:A picture of the movement of data between external entities and processes and data stores within a system.

Modeling a system's Process
You and other team members must organize the information into a meaningful representation of the information systemthat exists and of the requirements desired in a replacement system.

Why logical & physical DFD (Tradeoffs)
Physical data flow diagrams help you better understand the people and/or computer systems that are used in the overall system's processing. Logical data flow diagrams help you better understand the essence of the system, the data and the processes that transform them, regardless of actual physical form. Further, the new logical data flow diagrams can then show any additional functionality necessary in the new system, to indicate which, if any, obsolete components have been eliminated, and any changes in the logical flow of data between system components, including different data stores. The data flow diagrams for the new physical system can then be constructed with the data flow diagrams for the new logical system as a guide. As discussed in the chapter, experts used to recommend that all four levels of data flow diagrams (current physical, new physical, current logical, and new logical) be constructed because:
(1) analysts knew little about the business of the user and needed to develop a detailed current physical data flow diagram in order to understand the business,
(2) users were not able to work with a new logical data flow diagram right away, and
(3) there is not much work in turning current logical data flow diagrams into new logical data flow diagrams.

Sources and sinks
(The origin and/or destination of data, sometimes referred to as external entities) Sources and sinks are always outside of the system being considered. They are of interest to the system being considered only because they represent sources of data coming into the system and destinations for data leaving the system. If any data processing occurs inside a source or sink, it should be of no interest to the system being modeled. If the processing is of interest, however, or if the identified source/sink has several inputs and outputs to and from the rest of the system, it may be better considered as an internal process.
fig8-2




fig8-3a




fig8-3b



The highest level DFD is called a context diagram. It represents the system as a single process, with all the related entities and the data flows in and out of the system. The next level diagram, called a level-0, decomposes the one process from the context diagram into two to nine high-level processes. Each process in a level-0 diagram can be decomposed if necessary. Each resulting diagram is called a level-1. Should processes in a level-1 diagram be decomposed, each resulting diagram would be called a level-2 diagram. Each one of these processes would be decomposed on a level-3 diagram, and so on.

Context diagrams have only one process that represents the entire system being modeled and show only the data flows into and out of the system. The diagram also includes sources and sinks, which represent the system's environmental boundaries. There are usually no data stores in a context diagram
fig8-4




fig8-5



Decomposition:
Decomposition is the iterative process by which a system description is broken down into finer and finer detail, creating a set of diagrams in which one process on a given diagram is explained in greater detail on a lower-level diagram. Balancing is the conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level. You can determine if a set of DFDs are balanced or not by observing whether or not a process which appears in a level-n diagram has the same inputs and outputs when decomposed for a lower-level diagram.

You stop decomposing a DFD when the following six conditions are satisfied.
  • Each process is a single decision or calculation or a single database operation, such as retrieve, update, create, delete, or read.
  • Each data store represents data about a single entity, such as a customer, employee, product, or order.
  • 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.
  • Every data flow does not need to be split further to show that different data are handled in different ways.
  • You believe that you have shown each business form or transaction, computer screen, and report as a single data flow.
  • You believe there is a separate process for each choice on all lowest-level menu options for the system.

fig8-7




fig8-8




fig8-9





Return

Four Different Types of DFDs
Current physical DFDs often show the people and technology used within a system, showing who does what and the media on which data are stored. Current logical DFDs attempt to show the essence of the system without regard to the actual physical implementation.

Detailed DFDs for the current physical system tend to take a great deal of time and then tend to be tossed aside as the focus shifts from the current to the new system. By not drawing current physical DFDs, or by drawing only cursory ones, analysts can save themselves effort and focus from the beginning on what is really important, the new system


fig8-13a




fig8-13b




fig8-15




fig8-16





Return

Using Data Flow Diagramming in the Analysis Process
DFDs can be used as analysis tools to help determine the completeness of a system model and a model's internal consistency, as a way to focus on when system events occur through analyzing timeliness, and, through iterative use, to develop and check models. Analysts can study DFDs to find excessive information handling, thus identifying areas for possible efficiencies.
fig8-17





For data flow diagrams to be complete, all the necessary components of a data flow diagram should be included in the diagram and fully described in a project repository. As described in the chapter, with most CASE tools, the CASE tool's repository, is linked to the diagram. Whenever you define (or redefine) a process, data flow, source/sink, or data store on a data flow diagram, an entry is automatically created (or updated) in the repository for that element. Figure 8-18 shows a sample report of the contents of a CASE repository entry. It is this tight linkage between diagrams and the CASE repository that creates much of the value of a CASE tool. Further, you cannot have an entry in the repository that is not on some diagram. The repository is also helpful for enforcing DFD rules; for example, during decomposition, the repository remembers what were all of the inflows and outflows of an exploded process. The repository also keeps track of any split or joined data flows.
fig8-18




fig8-19




fig8-20








Return

Examples:
1- Problem 2:
Context

Level-0 Diagram

2- Problem 3:
Context

Level-0 Diagram

3- Problem 5:
You should continue the process of decomposition until they have reached the point where no sub-process can logically be broken down further (i.e., each process meets the definition of a primitive process). See the level-1 data flow diagram for this exercise, which shows a sample decomposition of the process titled Finalize Order from the level-0 data flow diagram provided for Problem and Exercise 3.
Level-1 Diagram

4- Problem 6:
Some errors and peculiarities in these diagrams include:
  • Different names and numbers are used for apparently the same data store on the two diagrams.
  • In the level-0 diagram, the data store, Class Roster, does not have the data flow, Scheduled Classes, flowing into it, rather this data flow connects processes 2 and 3, thus these DFDs are not balanced.
  • Process 1 appears to accomplish nothing since its inflow and outflow are identical; such processes are uninteresting and probably unnecessary; it is possible that this process will become interesting when it is decomposed, where validation and error handling processes might appear.
  • Process 2 does not appear to need Course Request as input in order to perform its function, as implied by its name.
  • Some students may also wonder if process 3 has input sufficient to produce its output; for example, where are prior class registrations kept so that process 3 can determine when a course is full?

5- Problem 10:
Three major errors in Figure 8-22 are:
  • Process 1.0 (P2) has only inputs, making it a "black hole."
  • Data flow DF5 should not move directly from source E1 to data store DS1 without first going through a process.
  • Data flow DF1 should not move directly from source E1 to sink E2 without first going through a process.
  • Other peculiarities (such as Process 1.0 has label P2 and the data store has only a label, not a number) are only that, not errors.

6- Problem 11:
There is a general formatting issue with these DFDs since there are no numbers on processes and data stores, but the student should be able to find logical errors as well. These diagrams show the decomposition of process P1 on the level-0 diagram. Three particular logical errors in Figure 8-23 are:
  • The data store DS1, not DS2, should be represented on the level?1 diagram.
  • Data flow DF3 should be an outflow on the level-1 diagram, and data flow DF6 should not be on the Level-1 diagram.
  • Process P1.4.2 has no inputs and is thus a "miracle."

7- Problem 12:
Context

Level-0 Diagram

Hosted by www.Geocities.ws

1