3.2. Resource-Constrained Activities

A Resource-Constrained Activity is an activity where one or more participants play a Resource Role (such as Performer). Typically, a resource-constrained activity is a component of a business process that happens in the context of an organization or organizational unit, which is associated with the activity as its Process Owner.

An activity of a certain type may require certain resources for being performable. At any point in time, a resource required for performing an activity may be available or not. A resource is not available, for instance, when it is is busy or when it is out of order.

Resources are objects of a certain type. The resource objects of an activity include its performer, as expressed in the diagram shown in Figure 3-6. While in a conceptual model, describing a real-world system, a performer is required for any activity, a simulation design model may abstract away from the performer of an activity.

For instance, a consultation activity may require a consultant and a room. Such resource cardinality constraints are defined at the type level. When defining the activity type Consultation, these resource cardinality constraints are defined in the form of two mandatory associations with the object types Consultant and Room such that both associations' ends have the multiplicity 1 ("exactly one"). Then, in a simulation run, a new Consultation activity can only be started, when both a Consultant object and a Room object are available.

For all types of resource-constrained activities, a simulator can automatically collect the following statistics:

  1. Throughput statistics: the numbers of enqueued and dequeued planned activities, and the numbers of started and completed activities.
  2. Queue length statistics (average, maximum, etc.) of its queue of planned activities.
  3. Cycle time statistics (average, maximum, etc.), where cycle time is the sum of the waiting time and the activity duration.
  4. Resource utilization statistics: the percentage of time each resource object involved is busy with an activity of that type.

In addition, a simulator can automatically collect the percentage of time each resource object involved is idle or out-of-order.

Figure 3-6. The resources required for performing an activity include the activity's performer.

For modeling resource-constrained activities, we need to define their types. As can be seen in Figure 3-7, a resource-constrained activity type is composed of

  1. a set of properties and a set of operations, as any entity type,
  2. a set of resource roles, each one having the form of a reference property with a name, an object type as range, and a multiplicity that may define a resource cardinality constraint like, e.g., "exactly one resource object of this type is required" or "at least two resource objects of this type are required".

The resource roles defined for an activity type may include the performer role.

Figure 3-7. Activity types may have special properties representing resource roles.

These considerations show that a simulation language for simulating activities needs to allow defining activity types with two kinds of properties: ordinary properties and resource roles. At least for the latter ones, it must be possible to define multiplicities for defining resource cardinality constraints. These requirements are fulfilled by OE Class Diagrams where resource roles are defined as stereotyped properties using the stereotype «resource role» or, shorter, «res».

The extension of basic OEM by adding the concepts needed for modeling resource-constrained activities (in particular, resource roles with constraints, resource pools, and resource-dependent activity start arrows) is called OEM-A.