Entity-relationship diagrams are used to define the information in a system. Making such diagrams is called information modeling, and was the focus of the last chapter. In this chapter, the focus is on what happens and at whose instigation. This is called process modeling. Since the process diagrams indicate the flow of data, they are also called data flow diagrams.
You can elaborate on process models to use for the design stage. As an alternative, this chapter will explain storyboard diagrams. Storyboard diagrams specify implementation details, mainly the files (scripts) for the application. The ER, process, and storyboard diagrams are complementary ways to document your application. This documentation is especially useful when it comes time to change the application, either to fix a problem or address a new opportunity.
The goal of logical design is to specify the functions of the application. What does it do? Process diagramming is a tool for doing this.
Process diagrams focuses on three things, the three symbol types in a process diagram.
Agents can refer to the people, described by their roles in the business, that invoke particular tasks in the application. An agent can be the system itself. This is appropriate for something like a time-based operation when “the system” initiates action such as sending out bills or purging old records. Processes refer to tasks, or, rather, the parts of the application that implement tasks. The term data store is intended to be a technology-independent term referring to information required by the application. A data store might turn out to be a table in a database, but it might be more or less complex. It could be a card file on someone’s desk, or a set of form letters on someone’s computer, or a set of charts mounted on the wall.
Process diagrams make use of distinct symbols for agents, processes, and data stores, with arrows indicating the flow of data. In this text, rectangles that are close to being squares stand for agents, rectangles with rounded corners stand for processes, and long rectangles with a double bar on one side stand for data stores. Arrows will be one- or two-headed.
Developing a process diagram requires you, the systems designer, to think about your users; in particular, to give the users meaningful names. You need to determine what tasks are invoked by what people in what situations. For the simple mail-order business described in the last chapter, we can assume that the following agents use the application involving the database:
An order-taker enters the information on (new) customers and orders.
A clerk in the product department adds, edits, and removes the product records in the catalog table.
A shipping clerk uses the information in the database to pack up the orders and ship them out using the shipping method of choice.
An agent to be called “the system” because the process it invokes is automated; namely, a process that purges all completed orders over a year old from the system invoked according to a preset time schedule. The process might generate a report on noncompleted orders more than 90 days old over to be handled by a special (manual) process.
Creating a process design is an iterative process in which a process at one level can be expanded to be multiple processes at another level. Consider the process diagram shown in Figure 6.1.
Figure 6.1: Process diagram for ordering system.
Notice that this diagram is to convey the logic of the application. It is done prior to building the application. As such, it shows one data store called orders. As you probably recall from the last chapter, it might turn out that the normalization conditions and the requirements for most database products require the use of two tables. The ship methods data store probably will turn out to refer to a piece of paper posted by the shipping clerks’ desks indicating the schedule for UPS and FedEx. The ship methods data store is not connected to a process that creates or modifies the data.
The methodology of process diagrams requires that agents are connected to process symbols, and process symbols have connections to data stores. An agent symbol is never connected directly to a data store because the methodology requires that you specify what process does the task. The direction of the arrows indicates reading or writing. Double-headed arrows indicate read and write action. If there is a data store that is never read, but only written, then the system as presented is lacking a function to make the data store meaningful. That might be okay, since all of the system might not be defined, but it is a signal to review what you intended. A data store that is written to but never read is called a black hole. A data store that is read, but not written to, is called a miracle.
Going over the connections is a way of checking out for yourself, and for the systems owners, if you have specified the functions desired. For example, an order taker invokes the order entry process. This process uses information from the catalog and uses and makes changes in the form of additions to the customer and the order data store. The double-headed arrows concerning the ship order process and the orders data store indicate that this operation does change the orders. This is correct because the act of shipping an order requires the status field to be changed.
Notice that a systems designer could have defined another process: adding or changing the customer data store. The diagram in Figure 6.1 assumes that is part of order entry.
The process diagram gives you a graphical prop for an analysis of the system requirements. You can use it by yourself or as part of a discussion with colleagues.
As indicated previously, another name for process diagrams is data flow diagrams. The arrows indicate the flow of information. Some of the information is generated by the process; other information comes from the agents or the data store with little modification from the process. Information flows from agents to processes, which, in turn, store the information “as-is” into data stores or make calculations and store the resulting information into data stores. Going the other way, processes extract information from data stores and present it to agents.
One thing the process/data flow diagram does not do is indicate the flow of goods. Even though this application is intended to support a mail-order business, there is no arrow representing the flow of goods from a warehouse to a customer. This flow of goods can be considered a side effect of the information processing system and not what the diagram is intended to represent.
In many situations, you will be designing an application that makes use of databases in existence already in the organization. For the cases when the databases do not exist, you will use entity-relationship diagrams to design them. Although some professionals insist on always starting with the ER diagrams for information modeling, and others insist on starting with the process modeling (and still others on object modeling), a balanced approach, fit to the problem, is what is recommended here. You will go back and forth. You will even (gasp!) occasionally find it necessary to go back and change the logical diagrams because of something that occurs to you during programming or testing. You can continue to use process diagrams, expanding the ones you already have made by dividing processes into smaller tasks. Alternatively, you can turn to other techniques such as storyboards.
The last diagramming technique is called storyboard and belongs to the building stages and not the analysis and planning stages. A storyboard contains rectangle symbols for files, also called scripts, and arrows representing the situations of a file calling a file. An arrow that represents one file invoking another file to handle a form will be a thick arrow. An arrow indicating a hyperlink in one file to another file will be a thin arrow. This format is inspired by the use of storyboards for multimedia applications, which borrowed storyboards from film and animation. However, the different form of arrows is our own. You can use this format or use your own design for your application.
The storyboards for multimedia applications would contain descriptions of any audio, screen shots of video, and clips of graphics. That type of information is not that critical to the applications here. However, you should enhance the simple storyboard techniques shown here to include what is important to you. For example, you might indicate situations when what the person sees at the client computer is the display of a customized HTML file with images specified by filenames from a database.
The diagram in Figure 6.2 is a storyboard for the state capital quiz application described in the previous chapter.
Figure 6.2: Storyboard for state capital quiz.
The storyboard visually provides the following facts about this application: there are two scripts. These two scripts contain three forms, indicated by three form action arrows. Each of the two scripts contains directives specifying themselves as the action for forms. The miniquizask script specifies the miniquizcheck script as the form handler for a third form. The miniquizcheck has a link to miniquizask to start the process over again. This visual story “told” by the diagram is a critical benefit of creating storyboards. You will use them before, during, and after the programming stage of your projects. We will return to this example and make an addition in the next section.