Process Modeling

Last month, I presented a case study that described the needs of a fictitious publishing company based on the information in the Pubs database (see "Data Modeling," April 2000). This month, to show you how the business system works, I'll introduce process modeling, which shows the structure of the company's activities and how the data flows through the company's processes. To build a database that is both extensible and expandable, you need to understand what your company does and how it does it. Process modeling is a proven technique for this discovery activity.

The Decomposition Diagram

Process modeling is a way to organize and document the flow of data through a business system's processes. One of the graphics you can create as part of the process modeling procedure is a decomposition diagram. A decomposition diagram shows a top-down functional decomposition of a system and exposes the system's structure. This diagram is a simple hierarchy chart, like the one in Figure 1, which shows the breakdown of the fictitious publishing company's functions and activities.

I read the decomposition diagram from the top down. The topmost (root) node represents the entire system, the Publishing House (level 0). The next level contains the main functions or subsystems, based on what I've discovered during the client interviews. I've arbitrarily numbered each function; Manage Authors & Royalties is function 1, Manage Production is function 2, and so on. Beneath the function level, you can see the activities that make up each function; here, the numbering identifies the relationship. For instance, beneath the Manage Authors & Royalties function are three activities: Create Contracts (1.1), Pay Royalties or Retainers (1.2), and Oversee Author Writings (1.3).

Where did these activities come from? The case study I developed last month stated that the company wants to track sales, keep track of its employees, optimize the work assignments, and manage authors and royalties. When you read the case study (or interview the customer), look for the big pieces of the picture. The big pieces (major functions) that I found are tracking sales, managing employees, managing production (of the publications), and managing authors and royalties.

The decomposition diagram is a logical model, abstracted from the real world. The model shows the activities that need to be performed, but not how they'll be performed. Each activity maps to one or more tasks. These activities and tasks can be performed by people, by software, or even by machinery. But they need to be performed, or the system is at risk of failure.

The Data-Flow Diagram

Figure 2 illustrates a data-flow diagram (DFD), another graphic you can create during process modeling. A DFD shows the flow of the data through a system, and the work or processing performed on the data as it moves through the system. The DFD—sometimes called a bubble chart, a transformation graph, or a process model—is easy to read when you know how.

Each round node is a process that is related to the decomposition diagram through the numbering and naming scheme. DFD process node 1.1 maps to activity 1.1 on the decomposition diagram. The yellow rectangles are external agents or entities—people, systems, or things that lie outside the scope of the system you're developing but that interact with the system. The horizontally barred objects (open-ended boxes) are data stores; these are repositories of data that result from the process. These data stores eventually map to database tables.

You read the DFD by following the activity flow. For instance, starting at the external agent Publishing House, follow the curved arrow (engages in) to the process node Publishing Activities, then follow the arrow (that use) to the data store Articles. Follow the next arrow (are used to) to the process node Compile Publication, and then to the process node Ship Publication, which is received by the external agent Store. The Store tries to Sell Publication, which results in the data store Sales Data.

Figure 2 is a top-level DFD. It shows as complete a picture of the process flow as I can map at this time (based on my current understanding of the processes) and exposes an understanding of the data and how the data is processed. Typically, when you undertake a complete requirements analysis, you start with this high-level DFD, then drill down through each process node to the tasks that make up the process, and map them in similar fashion. When you finish, you have multiple levels of detail for each process and a detailed understanding of the system, the functions and processes of that system, and the tasks necessary to make each function and process work. Armed with this knowledge, you're ready to begin the next step in planning the new solution—developing the conceptual model, as represented by an entity relationship diagram (ERD). I'll tackle this model in next month's column.

If you're interested in pursuing systems design and process modeling and want a more in-depth discussion of these topics, I recommend Jeffrey L. Whitten and Lonnie D. Bentley, Systems Analysis and Design Methods, Fourth Edition (Irwin Professional Publish-ing 1998). Also, you can obtain more details on differing methodologies used in systems design and analysis from the online Help your CASE tool provides. I used Visio Professional 2000 to construct all the models for this series.

Process modeling is essential for finding out how a system works. Knowing how the system works will help you build a reliable, well-functioning, and long-lasting database. Process modeling is a compilation of several types of logical, graphical models that work together to describe how a system works (or will work). The decomposition diagram and the data-flow diagram are two popular and useful process models.