Process Modeling Interface

One of the main targets of this work is to separate process modeling from domain modeling. Nonetheless, the nature of CPNs and their execution in CPN Tools requires the process models and the domain model to be present in the same CPN model. Thus, both model types must be present in the same input file of CPN Tools. As we will see in Sections 3.4 and 5.4.2, the process models as the dynamic part of BPR projects will be developed in the SMPL language which is derived from UML ADs. The SMPL process models are transformed into CPN process models and interwoven with the CPN domain model of the preceding Section 3.2 in a single model file. Interweaving the models requires the domain model file to act as a template where the process models can be inserted easily. This is best supported if the domain model and the process models are kept separate and well defined insertion points are available in the template file. To keep the CPN domain model separate from the CPN process models as well as to establish well defined insertion points, an interface of the two was defined. The basic idea is to create a copy of the subpage MobileWork (see Figure 3.15) of the CPN domain model for every activity and to link these copies such that they form mobile business processes. As already introduced in Section 3.2, the subpage MobileWork contains all elements necessary to represent a mobile task.

To handle mobile business processes both the physical flow of the workers and the virtual control flow of the process have to be facilitated. For these reasons, the subpage MobileWork is equipped with two interfaces. The physical flow of the workers occurs through the places Waiting as input and WorkFinished as output. It is worth noting that these two places are fusion places which means that they are singletons. As a result, all waiting workers are present in one and the same place Waiting, regardless of the process and activity

3.3. COMPOSITION OF BUSINESS PROCESSES 61 andalso (not (W_interrupted(w,lw))) andalso (#2 paid) = W_ActID(w)]

input(w);output (wn);

action(W_adjustWorkingTime(w));

startWork

[((#cid f) = (#cid (hd (#t (#sched w))))) andalso (not (W_interrupted(w,lw))) andalso (#2 paid) = W_ActID(w)]

input(w);output(wn);

Figure 3.15: Interfaces of model part MobileWork

they are working on. The same applies for the workers present in the place WorkFinished.

The process control flow occurs through the places FlowIn as input and FlowOutas output. These places are of the type Flow. The third place of the process control interface is the place TaskName. This place contains exactly one token of the type PAID with the ID of the process and the ID of the activity this copy of MobileWork represents. This token is thus a unique identifier for the activity mapped to this subpage copy. The marking of the place TaskName is created at the creation time of the process model. Since the place builds loops with the transitions startWork and finishWork, its marking remains constant for the whole simulation run. In contrast to the worker interface, the process flow interface is built of ports instead of fusion places. Figure 3.15 gives an overview of the interfaces.

Structuring the interfaces as described above allows to integrate independent processes into the simulation as long as every process and every activity have a unique name which is represented by their respective attributes ID of type

62 CHAPTER 3. SIMULATION OF MOBILITY STRING. The guard of the transition startWork of the worker interface en-sures that a Worker token is always directed into the correct copy of the subpage MobileWork. This decision is taken based on a comparison of the name of the activity stored in both the schedule of the worker and the token paid. The process flow interface ensures that a worker cannot enter the sub-page MobileWork until the respective activity is executable in the semantics of the business process. This is achieved by the input place FlowIn and the guard of startWork which blocks until a token is present in the place FlowIn.

Waiting

Figure 3.16: Process modeling interface instantiated

Figure 3.16 illustrates how the MobileWork interfaces are instantiated for enabling the transition startWork. The example in Figure 3.16 refers to the example processes introduced in Section 2.1 on page 13. Note that for the sake of lucidity Figure 3.16 is incomplete, since it shows only four activities instead of all ten activities of both processes.

Figure 3.16 shows a view of the interfaces that is internal to the sub-page MobileWork. Since the business processes are created out of copies of MobileWorkand utilize the interfaces, there is an external view to the inter-faces too. The external view of the worker interface was already discussed in Section 3.2.6 in-depth.

The external view of the process flow interface is part of the actual business process descriptions. Since the CPN model of every activity is a copy of the subpage MobileWork, every activity needs a copy of the process flow interface, too. Figure 3.17 shows the CPN model substitution of an activity with its process flow interface. Note that in opposition to the internal view, the edge between the place id and the subpage MobileWork is unidirectional since the place TaskName is an input port.

The corresponding place names of the process flow interface are given in Table 3.1. Since all places must have a unique name, a unique positive integer

3.3. COMPOSITION OF BUSINESS PROCESSES 63

in1 Flow

id1 PAID

1`("Process", "Activity1")

Activity1

MobileWork

out1 Flow

Figure 3.17: CPN substitution of a mobile activity

is appended to the names of the external interface places. For one and the same activity, the same unique number is appended.

Internal place External place FlowIn in<number>

TaskName id<number>

FlowOut out<number>

Table 3.1: Corresponding places of the process flow interface

The Flow tokens will initially be created by the Scheduler as soon as the first task of a process is assigned to a worker’s schedule. The tokens are created for all tasks with precedence 1. For tasks with higher precedence (in the power line extension example the activities “Work @L3”, “On @L1”,

“On @L2”) these tokens are produced as a result of the execution of the predecessor tasks of the same process—i.e., they represent the current state of the process. This happens on the edge from the transition finishWork to the place FlowOut after the execution of the task is finished. In the next sections it will be demonstrated how to build business processes out of the activity substition depicted in Figure 3.17.