Chapter 14. Processing Network Design Models
For accommodating PN modeling, OEM-A is extended by adding pre-defined types for processing objects, entry node objects, arrival events, processing node objects, processing activities, exit objects and departure events, resulting in OEM-PN. These "built-in" types, as described in Figure 14-1, allow making PN models based on them simply by making a process model with DPMN without the need of making an OEM class model as its foundation, as shown in Figure 14-2.
Notice that the range of the properties arrivalRecurrence, successorNodes and
duration of the built-in object types EntryNode and ProcessingNode is Function
, which means that the value of such
a property for a specific node is a specific function. While the standard UML semantics does not support such an extension of the semantics of
properties in the spirit of the Functional Programming paradigm, its implementation in a functional OO programming language like
JavaScript, where objects can have instance-level functions/methods, is straightforward.
The property successorNodes allows to express a function that provides, for any given entry or processing node, a (possibly singleton) set of processing nodes or exit nodes. Such a function can express several cases of routing a processing object from a node to one or more successor nodes:
- a fixed unique successor node for modeling a series of processing nodes connected by (possibly conditional) object flow arrows, as in Figure 14-4;
- a conditional unique successor node for modeling an Exclusive (XOR) Gateway leading to one of several possible successor nodes;
- a variable subset of a set of potential successor nodes for modeling an Inclusive (OR) Gateway;
- a fixed set of successor nodes for modeling a Parallel (AND) Gateway;
In a DPMN diagram, the set of successor nodes of a node is defined by Flow Arrows, possibly in combination with Gateways.
PN example 1: a single workstation
Part arrivals are modeled with an «entry node» element (with name “partEntry”), the workstation is modeled with a «processing node» element, and the departure of parts is modeled with an «exit node» element (with name “partExit”).
DPMN is extended by adding the new modeling elements of PN Node rectangles, representing node objects with associated event types, and PN Flow arrows, representing combined object-event flows. PN Node rectangles take the form of stereotyped UML object rectangles, while PN Flow arrows have a special arrow head, as shown in Figure 14-2.
PN example 2: a workstation may have to rework parts
Parts that turn out to be defective after being processed need to be reworked. This can be modeled by adding an attribute percentDefective to the object type Workstation and suitable logic to the Processing activity end event rule such that in percentDefective % of all cases a processed part cannot depart the system (i.e., is not removed from the input buffer), but is being reworked by another Processing activity.
PN example 3: Department of Motor Vehicles
A Department of Motor Vehicles (DMV) has two consecutive service desks: a reception desk and a case handling desk. When a customer arrives at the DMV, she first has to queue up at the reception desk where data for her case is recorded. The customer then goes to the waiting area and waits for being called by the case handling desk where her case will be processed. After completing the case handling, the customer leaves the DMV via the exit.
Customer arrivals are modeled with an «entry node» element (with name “dmvEntry”), the two consecutive service desks are modeled with two «processing node» elements, and the departure of customers is modeled with an «exit node» element (with name “dmvExit”).