The chapter jumps immediately to objective six in the introduction by discussing logical and physical models. The terms are a bit misleading, so a definition is required.
The text moves ahead to discuss two styles of data flow diagrams. The two styles are similar, with minor differences in the symbols they use for elements in the diagram. Follow the links below for a more formal discussion of each type of diagram.
The text only uses Gane-Sarson DFDs on the pages that follow.
The text discusses the meaning of each symbol. It remarks that a process symbol on a DFD may be called a black box because we are told on the diagram what it does, but not how it is done. This diagram is meant to show what happens, not how it happens. That makes this a logical diagram. A process must do something with the data it receives, or there is no need for the process to exist in the system. Typically, a process symbol represents code that a programmer must add to the system.
A data flow symbol shows how data flows into and out of processes. It must show direction, which is typically one way. If, however, a process pulls data from a data store, and writes back to it when done, there will be two data flow symbols between those objects, one flowing into the process, and one flowing into the data store. (See figure 5-7 on page 184.) This leads to the discussion on page 183 of commonly seen errors when DFDs are not done correctly. Consider the three errors in figure 5-6 on page 183:
A data store represents a file, folder, drive, or other means of storing information. It does no good if it is not connected to a process by a data flow. Multiple processes might access a data store, to read or write to it. If the system accesses data that changes only with versions of the program, such as tax rates, the data store holding that data may not have input data flows, and may only be connected to processes that read it.
An entity symbol typically represents users of a system, as shown in the examples on page 185. Note that entities may not connect directly to each other or to data stores. Entities should be connected to processes by data flows.
Review the information in figure 5-11, which shows three correct and three incorrect ways to show data flowing on a DFD. These are six rules that will keep you from making rookie mistakes on a DFD.
The text goes on for several pages, revealing that DFDs can be done at several levels, that they start at a very high level (called a context diagram), that each high level process can be broken down by lower level diagrams that show what happens inside it. Got that? Good, let's move on.
On page 197, the text brings up the idea of a data dictionary. A data dictionary is defining information about a database. This may be a system or a formal document that explains each data element in our system, including the kind of variable used to collect that element, the data type used to store it, and the length constraints on the element. With regard to a DFD, a data dictionary should also hold formal information about data flows, data stores, processes, and entities. Databases are typically stored and viewed as records, which are structures of data. A customer record, for example, might hold the customer's name, ID, credit card data, billing and shipping addresses, current account status, and order history.
On page 204, the text introduces the three classic structures of programming. It is good to know them if you are going to describe processes (programs).
When describing a business process for the data dictionary, or for the programmers that must follow it, the system analyst producing that description may need to use some form of English that describes the logic of the process. The text compares the structured English used by an analyst to the pseudocode used by a programmer. Both are only planning notations, not meant to be sufficient to carry out the tasks of the system without development.
Starting on page 206, the text discusses decision tables, which can be used to represent business rules. A programmer must be able to read tables like these and to translate them into code that processes in the system will use to make selection decisions. We will discuss some of these examples in class.
On page 210, the text shows us a decision tree, which is another way to display business rules. The choice to use decision tables or trees may rest with the project lead or may depend on the preferences of the audience. Whichever method is used, take care not to omit a possible combination of factors, else you will have a system that produces unexpected results or breaks.
The chapter ends with advice that it is a good idea to produce a logical model of both the current and new systems using the tools in this chapter, and to produce a physical model of the old and new systems when conducting the design phase of the project.
Turning to the last Toolkit chapter, this set of pages is most useful to students not familiar with searching for information on the Internet. Please browse through it, if you have not, and let's share any questions in class.