6 Process Modeling

Introduction

A process model is a formal way of representing how a business system operates. It illustrates the processes or activities that are performed and how data moves among them.

There are many different process modeling techniques in use today; we focus on data flow diagrams (DFDs) in this chapter. Here we focus on logical flow models, which are models that describe processes without suggesting how they are conducted. By focusing on these logical models, we explore how business should run without being distracted by implementation details (the physical model).

Data Flow Diagrams

Elements of Data Flow Diagrams

Processes

A process is an activity or a function that is performed for some specific business reason. In general, each process performs only one activity.

Every process has:

• A (unique) number
• A name (verb phrase)
• A description
• One or more output data flows
• Usually one or more input data flows

all of which are noted in the CASE repository.

Processes are represented as rounded rectangles in the Gane and Sarson DFD style.

Data Flows

A data flow is a single piece of data (e.g. patient's name) (sometimes called a data element), or a logical collection of several pieces of information (e.g. patient's information).

Data flows are the glue that holds the processes together: one end of every data flow will always come from or go to a process, with the arrow showing the direction. Data flows show which inputs go into each process and what output each process produces.

Every data flow has:

• A name (noun)
• A description
• One or more connections to a process

all of which are noted in the CASE repository.

Data flows are represented as arrows in the Gane and Sarson DFD style.

Data Stores

A data store is a collection of data that is stored in some way (which is determined later when creating the physical model).

Data stores form the starting point for the data model (discussed in Ch7) and are the principal link between the process model and the data model. Data flows coming out of a data store indicate that information is retrieved from the data store, and data flows going into a data store indicates that information is added to the data store or that information in the data store is changed.

Every data store has:

• A (unique) number
• A name (noun)
• A description
• One or more output data flows
• Usually one or more input data flows

all of which are noted in the CASE repository.

Data stores are represented as long, open-ended rectangles in the Gane and Sarson DFD style.

External Entities

An external entity is a person, organization, or system that is external to the system but interacts with it (e.g., patient, doctor, government, accounting system). Note: An external entity is external to the system but may or may not be part of the organization.

• External Entity: People who use the information from the system to perform other processes or who decide what information goes into the system (e.g. managers, staff)
• Not External Entity: People who perform a process (data-entry clerk, order taker) are a part of the process. They are usually included in the process description, but are not represented in the DFD itself.

Every external entity has:

• A name (noun)
• A description

all of which are noted in the CASE repository.

Data flows are represented as rectangles in the Gane and Sarson DFD style.

Using DFDs to Define Business Processes

One key principle in process modeling with DFDs is the decomposition of the business processes into a series of DFDs, each representing a lower level of detail.

Context Diagram

The first DFD in every business process is the context diagram, which shows the context into which the business process fits, i.e. the overall business process as just one process--the system itself. All process models have one context diagram.

Level 0 Diagram

The next DFD is called the level 0 diagram or level 0 DFD. The level 0 diagram shows all the processes at the first level of numbering (i.e. the processes numbered 1 through 9), the data stores, external entities, and data flows among them. All process models have one and only one level 0 DFD.

A second key principle in creating sets of DFDs is balancing--which means ensuring that all information presented in a DFD at one level is accurately represented in the next level DFD.

Level 1 Diagrams

Each process on the level 0 DFD can be decomposed into a more explicit DFD--the level 1 diagram or level 1 DFD. In general, all process models have as many level 1 diagrams as there are processes on the level 0 diagram; every process in the level 0 DFD is decomposed into its own level 1 DFD.

Level 2 Diagrams

Level 2 DFDs further decompose Level 1 DFDs...

Data Flow Splits and Joins

Some data flows are actually made up of many different data elements (such as patient name, patient address, appointment time, and doctor). A split could be used to document that part of the data (e.g. patient name and patient address) that is used for one process and another part (doctor and appointment) that is used by another process. Unlike the decomposition of processes, there is no requirement that the data flows in a split be mutually exclusive or include all of the parent data flow.

In the case of a join, separate parts of a data flow join together to form the data flow. For example, patient information (name, address) and appointment information (appointment time, doctor) might be data flows produced by different processes at a low-level DFD but might join to become one "Appointment Information" data flow in higher-level DFDs.

Alternative Data Flows

A process may produce different data flows under different circumstances (a credit card authorization request could produce an "approved" or "rejected" result). We show both data flows and use the process description (see next heading) to explain that they are alternatives. (Nothing in the DFD itself shows that the data flows are mutually exclusive.)

Process Descriptions

The purpose of the process description is to explain what the process does and provide additional information that the DFD does not provide. As we move through the SDLC, we generally move from general text descriptions of requirements to increasingly precise descriptions that are eventually translated into very precise programming languages. Three techniques are commonly used to describe more complex processing logic: structured English, decision trees, and decision tables.

Structured English

Structured English is a a formal way of writing instructions that describe the steps of a process.

• Action statements are simple statements that perform some action
• If statements control actions that are performed under different conditions
• For (or While) statements perform some actions until a condition is reached
• Case statements are an advanced form of an If statement that have several mutually exclusive branches

Decision Trees

Decision trees are a graphical way of describing the logic contained in the structured English If statements; hence, they are only helpful when there is a large number of nested If statements.

Decision trees are composed of circles that represent decision points that present a question (an If statement). The decision point has a set of outcomes that branch off in different directions that lead to other decision points.

(When we have more than two outcomes at the decision points, we might have a candidate for a Case structure).

Decision Tables

Decision tables are used for very complex processes that have multiple decision rules. Usually, the top left portion of the table shows the conditions to be tested, while the bottom left shows the actions. The conditions and actions are linked by rules.

Creating DFDs

• Data flow diagrams (DFDs) start with the information in the use cases and the requirements definition
• generally speaking, the set of DFDs that make up the process model simply integrate the individual use cases (and add in any process in the requirements definition not selected as use cases)
• i.e. we (the project team) take the use cases and rewrite them as DFDs:
  • the name of the use cases become processes, and
  • the inputs and outputs become data flows
• Building a process model that has many levels of DFDs usually entails five (5) steps:
  1. building the context diagram that shows all the external entities and the data flows into and out of the system from them
  2. creating a DFD fragment for each use case that shows how the use case exchanges data flows with the external entities and data stores
  3. organizing these DFD fragments into a level 0 DFD
  4. developing level 1 DFDs bases on the steps within each use case, to better explain how they operate. (in some cases, these level 1 DFDs are further decomposed into level 2 DFDs, level 3 DFDs, level 4 DFDs, and so on
  5. validating the set of DFDs to ensure completeness and correctness

Creating the Context Diagram

• The context diagram defines how the business process or computer system interacts with its environment, primarily the external entities
• to create the context diagram, we draw one process symbol for the business process or system being modeled (numbered 0 and named for the process).
• reading through the use cases, we add the inputs and outputs listed at the top of the form, as well as their sources and destinations; usually all the inputs and outputs will come from or go to external entities (such as a person, organization, or information system), but sometimes they will connect directly to data stores in an external system...
• none of the data stores inside the process/system that are created by the process or system itself are included in the context diagram...
• we may combine related (smaller) data flows (customer name, address, etc.) into larger data flows (customer information)

Creating DFD Fragments

• A DFD fragment is one part of a DFD that will eventually be combined with other DFD fragments to form a DFD diagram.
• in this step, each use case is converted into one DFD fragment
• in converting use cases into DFDs, it is important to have a consistent view-point when naming processes
• most analysts put the process in the middle of the DFD fragment, with the major inputs starting from the left side or top entering the process and outputs leaving from the right of the bottom; data stores are often written below the process.

Creating the Level 0 DFD

• our set of DFD fragments (one for each use case) are combined into one DFD drawing that becomes the level 0 DFD
• Iteration is the cornerstone of good DFD design: a DFD is usually drawn several times before it is completed.

Creating Level 1 DFDs (and Lower)

• we now create lower-level DFDs for each process in the level 0 DFD that needs a level 1 DFD
• each one of the use cases is turned into its own DFD
• usually, each step in the use case becomes a process on the level 1 DFD, with inputs and outputs becoming input and output data flows
• (of course, there will be modifications during this transformation from use cases to DFDs)
• we are advised to include external entities in level 1 and lower DFDs in order to simplify the readability of DFDs
• though most systems will go only to level 2 at most, there is no requirement that all parts of the system must be decomposed to the same level of DFDs. Some parts of the system may be very complex and require many levels, whereas other parts of the system may be simpler and require fewer.

Validating the DFDs

• two fundamental problems that can occur with DFDs:
  • syntax errors--which refer to the structure of DFDs and whether the DFDs follow the rules of the DFD language (e.g. the rule that processes must have a name; rules can also be specified for consistent view point, decomposition, and balance.)

    An important syntax error in creating DFDs result from violating the Law of Conservation of Data (developed by Prof. Dale Goodhue, U of Georgia), the first part of which says:

Data at rest stays at rest until moved by a process.

That is, data cannot go to or come from a data store or an external entity without having a process to push it or pull it. The second part of the law states that:

Processes cannot consume or create data.

That is, data only enters or leaves the system by way of the external entities. A process cannot destroy data; all processes must have outputs (violation of this tenet results in what is called a black hole error). Similarly, a process cannot create data (though it can transform data from one form to another); all processes must have inputs (violation of this tenet results in what is called a miracle error). There is one exception to the second tenet of the second rule though).

• semantic errors--which refer to "grammatical errors" made when creating DFDs; they refer to the meaning of the DFDs and whether they accurately describe the business process being modeled and can be thought of as misunderstandings by the analyst in collecting, analyzing, and reporting information about the system. There are three useful checks to help ensure that models are semantically correct:
  1. ensure that the model is an appropriate representation by asking the user to validate the model in a walk-through; users can be asked to role-play the DFD the same way in which they role-played the use case (one of the most subtle forms of semantic errors occurs when a process creates an output but has insufficient inputs to create it; the outputs of a process can only be combinations and transformations of its inputs)
  2. ensure consistent decomposition, which can be tested by examining the lowest-level processes in the DFDs; in most circumstances, all processes should be decomposed to the same level of detail--which is not the same as saying the same number of levels; it is usually best to ensure that all processes at the very bottom of the model provide the same consistent level of detail
  3. ensure that the terminology is consistent throughout the model; resolving differences in terminology and definition before the model is finalized is important in ensuring that everyone who reads the model or who uses the information system built from the model has a shared understanding.

---

Exception to the Second Tenet of the Second Law of Conservation of Data: A temporal process that issues a trigger output based on an internal time clock. Whenever some predetermined time period elapses, the process produces an output. The time-keeping process has no inputs because the clock is internal to the process. [Go Back.]