Process Modeling

A process model is a formal way of depicting the operation of a system showing both the activities performed and the movement of data within the system.

During the analysis stage we begin with logical models of the process, which ignore the implementation of the data and activities, and then in the design stage we begin to focus more on physical models, which try to incorporate and encapsulate implementation details.

Our main tool for modeling processes will be the data flow diagram, or DFD. A common approach to developing DFDs follows three basic stages:

  1. First create an intuitive, text-based, description of the process - such as our use cases and scenarios.

  2. Then provide a context diagram showing the relationship of the overall process to the outside world.

  3. Finally provide different levels of DFDs to precisely describe each of the subprocesses or activities in a "top-down" style.

The first step towards the use of DFDs is a discussion of syntax rules for the diagrams. We will begin with simple diagrams, and will gradually create more complex, multi-part, DFDs.

There are four basic components in a DFD: processes, data flows, data stores, and external entities. In the segment below, we discuss each of them in some detail.

Processes

Processes represent individual activities in the system, and are represented in DFDs using either an oblong or an oval.

For each process, we also record the following information on a second text form:

Note that every process in each DFD must have at least one input and at least one output.

Data flows

Data flows represent the generation and use of data items by activities in the system, and are represented in DFDs using arrows.

For each data flow, we also record the following information:

There are times when we will combine, or join two or more data flows together to form a more complex one (e.g. when two different activities each produce part of the necessary information)

There are also times when we will separate, or split, one data flow into two separate parts (e.g. where two different activities each need a different part of the produced data)

If data could be used in two or more different ways then both data flows are shown on the DFD, and the description field is used to indicate the alternative processing possibilities (e.g. under some conditions the data is sent to one activity, and under other conditions it is sent to a different activity)

Note that at least one end of every data flow must connect to a process (you cannot move data directly between data stores, or directly between a data store and an external entity).

Data stores

Data stores represent collections of data to be stored in some way (to be decided later, during the design phase and physical modeling), and are represented in DFDS using rectangles.

For each data store, we also record the following information:

External entities

External entities represent individuals or systems which interact with the system being modeled. This can include users and other systems. External entities are represented in DFDs using a rectangle.

To make external entities and data stores easilty identifiable from one another graphically, no numeric label is placed on the external entities, and the data stores are typically depicted with the right side of the rectangle "open".

For each external entity, we also record the following information:

Note on names/labels

The names/labels used on your DFD should make it easy and intuitive to distinguish between the different data items being moved, and the different data stores, processes, and external entities in use.

Levels of Diagrams

As mentioned earlier, we generally divide the system into a number of smaller activities in a heirarchical or top-down fashion, to make the process clearer to model and understand.

To achieve this, we generally show a context diagram - depicting the system in its business context (i.e. how the system as a whole interacts with the rest of the world) and then show the rest of the system in layers beneath that.

For the underlying layers:

As with any top-down strategy, our goal is to balance clarity against overhead: we want our individual DFD diagrams to be simple enough to be clear, but we don't want many trivial layers of DFDs to clutter the design.

Developing DFDs from Use Cases

Observe that, if we followed the use case construction ideas from our earlier notes, all the information we need to create our DFDs should be present in the collection of use case descriptions.

The task is then to collate all this information into a clear set of DFDs.

Example DFDs:

First, we consider the context diagram for a system that interacts with three external entities.

(Presumably we would have a more meaningful name for the central process than simply "Our System".)

NOTE: ALL THAT IS SHOWN HERE FOR THE CONTEXT DIAGRAM AND DFD0 ARE THE BASIC DIAGRAMS:
ALL THE SUPPORTING DESCRIPTION STILL NEEDS TO BE ADDED

Next, we look at the level 0 DFD which breaks our system up into three major processes.

(Again, presumably we would use much clearer, more descriptive, labels than Process X/Y/Z, or Data A/B/C/AB.

There is also a missing data flow in this diagram, a Report Request, which would go from the Auditor to 3 Process Z.)

We would then have a DFD1 describing process X, another DFD1 describing process Y, and another DFD1 describing process Z.

If processes X, Y, or Z were complex enough to warrant it, they would be further broken down, and those subprocesses would be described in level 2 DFDs.

Of course, here we have just shown the DFDs themselves. In fact, you would accompany each diagram with forms which contain all the additional information - particularly the descriptions.

For instance, for the diagrams shown above we would probably include an executive summary to go with the context diagram, outlining the system as a whole.

Furthermore, we would include another form for each data store, each data flow, each external entity, and each process, containing all the information outlined earlier in a clearly labelled, uniform, easily readibly format

Each description should be cross referenced to the appropriate other descriptions and diagrams, and there should be a table of contents and an index making it easy for readers to look up key information whereever it may be in the collection of DFD documents.

Thus the DFD becomes both a reference tool and a visual aid, providing a clear means of showing how the data and processes in a system interact.


Example Supporting Text:

We might use a standard template for the supporting text for DFDs. For instance, we might provide the text below to go along with the DFD 0 example above. (Note: the level of detail about both the processes and the data involved gets much more precise with each successive layer of DFDs. At DFD0 we're giving a fairly high-level overview, but by the time all the DFDs are complete there should be a precise description of both the processes and data items.)

DISCLAIMER: The labels used in the DFD0 were suboptimal at best - it would be preferable to pick labels that were far more descriptive of the processes, data flows, and data stores in question.

Our System: DFD 0

Overview

In this section we describe our overall system: identifying the key processes, external entities, data stores, and the flow of data between these items.

Our System handles the processing of sales requests from our clients, including the submission of requests directly from clients or through members of our sales team. It addresses the production of invoices, updates to our inventory system, and the production of monthly and annual audit reports for the auditing team.

Processes

There are three high-level processes in Our System, handling sales requests, invoicing and sales reporting, and auditing systems, respectively:

External Entities

There are three types of external entity that interact with Our System, the clients, members of the sales staff, and members of the auditing team:

Data Stores

We have a single high-level data store in use for Our System: the D1 Data Store. This stores both our client and our inventory information:

Data Flows

There are thirteen data flows represented at the high level in Our System (note that the diagram shows nine arcs, but three are bidirectional). The data flows represent the following:

Other Notes

A higher level view of this system is given in the Context Diagram (include page number or link). More detailed views of the processes are given in DFD's 1, 2, and 3 (again, include page numbers or links), while more detailed data descriptions are available in the ERD (link/page number again).

End of DFD0 Supporting Text Example
Note that this was just the supporting text for a single DFD. Most system models are going to include many DFDs, each of which will have its own accompanying supporting text, making for a substantial amount of information.