9.5.1. Resource Cardinality Constraints and Multitasking Constraints
Since activities require resources, and resources are allocated to planned activities, it is crucial to understand the relationship between activities and resources. An important part of its meaning are resource cardinality constraints and multitasking constraints.
Business process models do not only describe the possible sequences of events and activities, but they also describe the dependency of activities on resources. For instance, in a BPMN process diagram, a Lane L (such as the doctors lane in the BPMN process diagram below) may represent a resource type such that the diagram specifies for any Activity rectangle A in L (such as examinations) that an activity of type A is performed by a resource of type L.
While using a container shape, such as a BPMN Lane, for assigning elements, such as activities, to the element represented by the container shape (viz, a resource role) is a good way of visually expressing a many-to-one relationship between activity types and resource roles (all activity types within a Lane do have exactly one resource role), it does not allow expressing one-to-many or many-to-many relationships between activity types and resource roles.
Therefore, the BPMN Lane notation can only be used for specifying a performer resource role for activities that do not require resources of other types, and where we have a one-to-one association: (1) a resource can be allocated to at most one activity, and (2) an activity is performed by exactly one resource.
In general, though, the relationships between activities (of some type) and resources (of some type) can be best described by binary relationship types in an information model, such as by binary associations in a UML class diagram with multiplicity expressions at both ends. Figure 9-29 shows two one-to-one associations between the activity type examinations and the object types rooms and doctors associating a room as a (passive) resource and a doctor as a performer resource to an examination activity.
The association end at the side of the object type doctors is categorized as a resource role with the help of UML’s stereotype notation. The multiplicity expression at the resource role end is called resource multiplicity. In our example, the resource multiplicity at the doctors end is ”1” (an abbreviation of "1..1"), which means that exactly one doctor is required for performing an examination, defining a resource cardinality constraint that is a conjunction of a minimum resource cardinality constraint ("at least one") and a maximum resource cardinality constraint ("at most one").
In general, a multiplicity expression defines both a lower bound and an upper bound. When the lower bound of a resource multiplicity is greater than 0, it defines a minimum resource cardinality constraint. When the upper bound of a resource multiplicity is a natural number greater than 0, it defines a maximum resource cardinality constraint. The resource multiplicity 0..* (where * stands for unbounded), which does not define any resource cardinality constraint, is rather unusual since normally all activities require at least one resource (their performer).The multiplicity of the association end at the other side (of the activity type) represents a multitasking constraint, which defines if a resource is exclusively allocated to an activity, or to how many activities a resource can be allocated at the same time. In our example, the multiplicity 0..1 represents a multitasking constraint stating that, at any point in time, a doctor can be associated with, or perform, either no examination or at most one examination.
In an Object-Oriented (OO) programming approach, the computational meaning of a resource role is provided by a corresponding property in the class implementing the activity type. In the above example, the resource role association of "examinations" with "doctors" leads to a property doctor in the class Examination, as shown in Figure 9-30.
When activities admit using more resources than required, this means they can be started as soon as the required number of resources are available, but they can also be started with a greater number of resources, typically implying a faster performance.
While the model shown in Figure 9-29 is an example of a one-to-one association between an activity type and a resource object type, which is the only option in BPMN process models, we consider the cases of one-to-many, many-to-one and many-to-many associations in the following subsections.
One-to-Many Relationships
An example of a one-to-many relationship between activity types and resource object types is the association between ”load truck” activities and ”wheel loader” resources shown in Figure 9-31.
Notice that in this diagram, the «resource role» designation of the association end at the side of “wheel loaders” has been abbreviated by the keyword «rr». Its resource multiplicity of 1..2 specifies a minimum resource cardinality constraint of “at least one” and a maximum resource cardinality constraint of “at most two”, meaning that one wheel loader is required and a second one is admissible. When an activity does not require, but admits of, using more than one resource (of the same type), this typically means that the duration of the activity is the more decreasing the more resources are being used.
The one-to-many resource role association of ”load truck” with ”wheel loaders” leads to a property wheelLoaders in the activity class LoadTruck, as shown in Figure 9-32. Notice that this property has the multiplicity 1..2, which means that it is collection-valued and has either a singleton or a two-element collection value.
When activities admit using more resources than required, this means they can be started as soon as the required number of resources are available, but they can also be started with a greater number of resources, typically implying a shorter duration.
Many-to-One Relationships
An example of a many-to-one relationship between activity types and resource object types is the association between ”examination” activities and ”examination room” resources shown in Figure 9-33.
In this example, examination rooms (as resources) admit of up to three examinations being performed at the same time. Such a multitasking constraint can be implemented with the help of a (multitasking) capacity attribute of the class implementing the resource object type. If such a constraint applies to all instances of a resource object type, capacity would be a class-level (”static”) attribute, which is rendered underlined in a UML class diagram, as shown in the following model:
Alternatively, if different examination rooms have different capacities, then capacity would be an ordinary (instance-level) attribute of the class ExaminationRoom.
Many-to-Many Relationships
Examples of many-to-many relationships between activity types and resource object types are rare and typically involve activities going on with interruptions. An example is the association between ”teaching a course” activities and ”teacher” resources shown in Figure 9-34. In this example, the teaching of a course admits at most two teachers who may be involved in at most 7 course teaching activities at the same time.
