3.2. From Object Event Graphs to Activity Networks
An activity is a composite event that is composed of, and temporally framed by, a pair of start and end events.
In addition to its performer, an activity may involve further resources and allocating the required resources from resource pools during the course of a business process is essential for keeping it going.
Activity Networks (ANs) extend Object Event Graphs by adding activity nodes (in the form of rectangles with rounded corners) and Resource-Dependent Activity Scheduling (RDAS) arrows. Consequently, an AN consists of two kinds of nodes (event nodes and activity nodes) and two kinds of edges (event scheduling arrows and RDAS arrows).
ANs represents higher-level process models compared to Event Graph process models. In an AN, an event node may be connected to an activity node either via a conditional event scheduling arrow, as shown in Figure 3-3, or via an RDAS arrow, as shown in Figure 3-4. Using RDAS arrows allows higher-level modeling resulting in more concise diagrams.
As an example of an AN process we consider a manufacturing process with a workstation (as an organizational agent) and three types of events: PartArrival events, Processing-ActivityStart events and Processing-ActivityEnd events. Again, for obtaining a short process duration, the recurrence of PartArrival events is limited to three events.
The example process is described by the following list of events: PartArrival@1, Processing-ActivityStart@1.01, PartArrival@5.4, PartArrival@6.5, Processing-ActivityEnd@8.47, Processing-ActivityStart@8.48, Processing-ActivityEnd@11.95, Processing-ActivityStart@11.96, Processing-ActivityEnd@17.48, where an expression E@t represents an event of type E occurring at time t.
How this process unfolds in time is illustrated by the following process log:
| Step | Time | Current Events | System State | Future Events |
|---|---|---|---|---|
| 0 | 0 | WorkStation-1{ status: 1} | av.workStations: ws1 | PartArrival@1 | |
| 1 | 1 | PartArrival | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityStart{ ws1 }@1.01, PartArrival@18.83 |
| 2 | 1.01 | Processing-ActivityStart | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityEnd{ ws1 }@8.08, PartArrival@18.83 |
| 3 | 8.08 | Processing-ActivityEnd | WorkStation-1{ status: 1} | av.workstations: ws1 | PartArrival@18.83 |
| 4 | 18.83 | PartArrival | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityStart{ ws1 }@18.84, PartArrival@25.61 |
| 5 | 18.84 | Processing-ActivityStart | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityEnd{ ws1 }@23.9, PartArrival@25.61 |
| 6 | 23.9 | Processing-ActivityEnd | WorkStation-1{ status: 1} | av.workstations: ws1 | PartArrival@25.61 |
| 7 | 25.61 | PartArrival | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityStart{ ws1 }@25.62 |
| 8 | 25.62 | Processing-ActivityStart | WorkStation-1{ status: 2} | av.workstations: | Processing-ActivityEnd{ ws1 }@32.03 |
| 9 | 32.03 | Processing-ActivityEnd | WorkStation-1{ status: 1} | av.workstations: ws1 |
Notice that, as opposed to the process log shown in Table 3-1,
- the workstation with ID 1 is a (performer) resource for Processing activities having either the status 1 (being available) or 2 (being busy), and
- there is a pool of available resources ("av.workstations"), which contains only one resource (ws1), initially.
Typically, a business process is an instance of a business process type defined by an organization (or organizational unit), which is the owner of the business process type, in the form of a business process model. The above example business process is an instance of the following model:
An AN specifies a set of chained event rules with typed object, event and activity variables, based on an underlying OE class model defining object, event and activity types. By convention, activity classes have a duration function that is invoked for getting the duration of newly created instances of the activity class. In a simulation design model, these functions typically define random variate sampling functions (like the service time concept in queuing theory).
The AN shown in Figure 3-3 defines the following event rules:
- On each PartArrival event, if the associated WorkStation object's status attribute has the value AVAILABLE, then it is set to BUSY and the rule variable wsAllocated is set to true; otherwise the inputBufferLength attribute of the associated WorkStation object is incremented. If wsAllocated holds, then a new Processing activity is scheduled to start immediately with a duration provided by invoking the duration function defined in the Processing activity class.
- When a Processing activity ends, if the inputBufferLength attribute of the associated WorkStation object has the value 0, then the WorkStation object's status attribute is set to AVAILABLE; otherwise the rule variable wsAllocated is set to true and the WorkStation object's inputBufferLength attribute is decremented. If wsAllocated holds, then a new Processing activity is scheduled to start immediately with a duration provided by invoking the duration function defined in the Processing activity class.
Since the resource management logic concerning the workstation as a resource for Processing activities follows a general pattern, a new modeling language element can be introduced for capturing this pattern. Using resource-dependent activity scheduling arrows, we can express the process model of Figure 3-3 more simply as in the following diagram:
Notice that in this model, we have expressed that we no longer have to take care of setting the status of the workstation as a resource, nor do we have to update the queue/buffer length. This is now expressed implicitly by the semantics of the RDAS arrow and has to be handled in a generic way by a simulator supporting DPMN-A models.
The following diagram shows a model containing both event scheduling arrows and RDAS arrows:
In this model, activities are initiated (1) by an RDAS arrow when they may have to wait for the availability of required resources, or (2) by an event scheduling arrow when no other resources are required. For instance, a new Load activity can only be started, when a wheel loader (as a performer) is available, while a Haul activity can be started immediately after the completion of a Load activity because it's performed by the loaded truck, and no other resources are required.
The most widely used language for defining ANs is the Business Process Modeling Notation (BPMN). However, in BPMN there is only one type of arrow, called "Sequence Flow", which is semantically overloaded with both meanings: it can represent an event flow arrow or an RDAS arrow.
The concept of ANs includes business system processes, where many business actors perform activities for handling many business cases in parallel. Consequently, it is more general than the common concept of a business process as a case-handling process that is restricted to one case.
Normally all activity nodes of an AN have a queue of planned activities ("tasks") waiting for the availability of required resources (including their performer). Only if a successor activity node does not require additional or different resources, it does not have a (resource allocation) queue and can be started right away whenever a predecessor activity has completed, as indicated by an event flow arrow.
When all activity nodes of an AN only have a single resource (the performer of the activity), and each of them has a different performer, then the AN corresponds to a Queuing Network in the sense of Operations Research.
A DPMN process design model (like the one shown in Figure 3-6) essentially defines the admissible sequences of events and activities together with their dependencies and effects on objects, while its underlying OE class design model (like the one shown in Figure 3-8 below) defines the types of objects, events and activities, together with the participation of objects in events and activities, including the resource roles of activities, as well as resource multiplicity constraints, parallel participation constraints, alternative resources, and task priorities.
It is an option, though, to enrich a DPMN process design model by displaying more computational details, especially the recurrence of exogenous events, the duration of activities and the most important resource management features defined in the underlying OE class design model, such as resource roles (in particular, performer roles can be displayed in the form of Lanes), resource multiplicity constraints, alternative resources, and task priorities. The following model shows an enriched version of Figure 3-6:
Such an enriched DPMN process design model includes all computational details needed for an implementation without a separate explicit OE class design model. In fact, such a process model implicitly defines a corresponding class model. For instance, the enriched DPMN model of Figure 3-7 above implicitly defines the following OE class model:
