3.2.3. The Allocate-Release Modeling Pattern

The conceptual process model shown in Figure 3-14 and the process design model shown in Figure 3-25 exhibit a general pattern for modeling a sequence of two resource-constrained activities of types A1 and A2 shown in Figure 3-26. For describing this pattern, we assume that

  1. the process owner maintains queues for planned activities: q1 for for planned activities of type A1, and q2 for planned activities of type A2, both defined as queue-valued (i.e., ordered multi-valued) reference properties of the process owner in the underlying information model;
  2. the underlying information model specifies the sets of resources R1 and R2 required by A1 and A2,
  3. the set of resources required by A2 but not by A1 is denoted by R2R1;
  4. the set of resources required by A1 and by A2 is denoted by R1R2.
Figure 3-26. A conceptual modeling pattern for a sequence of resource-constrained activities
???

We can describe the algorithm of the Allocate-Release Modeling Pattern for the case of a sequence of two resource-constrained activities in the following way:

  1. ON start event:
    1. If the resources R1 required by A1 are available, they are allocated; otherwise, a planned A1 activity is added to the queue q1.
    2. If the resources R1 have been allocated, a new activity of type A1 is started.
  2. WHEN an activity of type A1 completes:
    1. The resources R2R1 are allocated, if they are available; otherwise, a planned A2 activity with reserved resources R1R2 is added to q2.
    2. If R2R1 have been allocated, a new activity of type A2 is started. In addition, an immediate release request for R1R2 is caused/scheduled.
  3. ON release request for R1R2:
    1. If q1 is not empty and the resources R1R2 required by both A1 and A2 are available, they are allocated and R1R2 are re-allocated to head( q1); otherwise, R1R2 are released.
    2. If the resources R1R2 have been re-allocated, a new activity of type A1 is started.
  4. WHEN an activity of type A2 completes:
    1. There is no state change.
    2. An immediate release request for R2 is caused/scheduled.
  5. ON release request for R2:
    1. If R1R2 is nonempty: if q1 is not empty and the resources R1R2 required by A1, but not yet allocated, are available, they are allocated and R1R2 are re-allocated to head( q1); otherwise, R1R2 are released. If q2 is not empty, then re-allocate R2R1 to head( q2); otherwise, R2R1 are released.
    2. If R1R2 have been re-allocated, a new activity of type A1 is started. If R2R1 have been re-allocated, a new activity of type A2 is started.

New modeling elements for expressing the Allocate-Release Modeling Pattern

Since the Allocate-Release Modeling Pattern defines a generic algorithm for allocating and releasing resources, its (pseudo-)code does not have to be included in a DPMN Process Diagram, but can be delegated to an OE simulator supporting the resource-dependent scheduling of resource-constrained activities according to this pattern. This approach allows introducing new DPMN modeling elements for expressing the Allocate-Release Modeling Pattern in a concise way, either leaving allocate-release steps completely implicit, as in the DPMN Process Diagram of Figure 3-27, or explicitly expressing them, as in Figure 3-28.

The most important new DPMN modeling element introduced are resource-dependent causation (resp., activity start) arrows pointing to resource-constrained activities, as in Figure 3-27. These arrows are high-level modeling elements representing the implicit allocate-release logic exhibited in Figure 3-26. Thus, the meaning of the model of Figure 3-27 is provided by the model of Figure 3-26.

Figure 3-27. Using resource-dependent activity start arrows in a conceptual process model.
???

It is an option to display the implicit allocate-release steps with Allocate and Release rectangles together with simple control flow arrows, as between the start event circle and the Allocate R1 rectangle in Figure 3-28.

Figure 3-28. Displaying the implicit allocate-release steps.
???

The meaning of the model of Figure 3-28 is the same as that of Figure 3-27, which is provided by the model of Figure 3-26. The fact that, using resource-dependent activity start arrows, the allocate-release logic of resource-constrained activities does not have to be explicitly modeled and displayed in an OEM process model shows the power of founding a process model on an information model, since the entire resource management logic can be expressed in terms of resource roles, constraints and pools in an OEM information model. This is in contrast to the common approach of industrial simulation tools, such as Simio and AnyLogic, which require defining resource roles, constraints and pools as well as explicit allocate-release steps in the process model, in a similar way as shown in Figure 3-28.

Using resource-dependent activity start arrows in a process model implies using their standard allocate-release logic according to which required resources that have not been allocated before are allocated immediately before an activity requiring them is started and released immediately after this activity is completed if they are not required by the next activity. Whenever another (non-standard) resource allocation logic is needed, it has to be expressed explicitly using ordinary event scheduling arrows.

Simplifying the workstation process model

We can now simplify the workstation model using the resource type category for WorkStation in the OEM class model and a resource-dependent activity start arrow from the arrival event to the processing activity in the DPMN process model. The resulting class model is shown in Figure 3-31.

Figure 3-29. Modeling WorkStation as a resource type
???

The simplification of the process model of Figure 3-5 results in the model of Figure 3-30.

Figure 3-30. A simplified version of the workstation process model using a resource-dependent activity start arrow.
???

Simplifying the medical department process model

We can now simplify the medical department model using the resource type category for Doctor, Room and Nurse in the OEM class model and resource-dependent activity start arrows in the DPMN process model. The resulting class model is shown in Figure 3-31.

Figure 3-31. A simplified version of the medical department information model with Doctor and Room as resource types
???

The simplification of the rather complex process model of Figure 3-25 by using resource-dependent activity start arrows results in the model of Figure 3-32.

Figure 3-32. A simplified version of the medical department process model using resource-dependent activity start arrows.
???