Development methodology

We developed a development methodology with BPMN-PLAN, named Business Process Management Software Development Methodology (BPMSDM), as shown in figure 4_1. The topmost block is the requirement specification phase. The requirements are specified according to the five models in BPMN-PLAN, which are process behavior, reference data instance, e-form, role, and resource specifications.

The process behavior specifications are specified with BPMN*.

After the requirements are specified, they are analyzed in the specification analysis phase to ensure the completeness and the consistency. Completeness means that all requirements are covered by the specifications, and consistency indicates that there is no conflict between the specifications. If there is no problem, the specifications are used as the input of next phase. In case a problem occurs, the specifications are modified accordingly.

In the system design phase, the Process Behavior model is defined first. It is a more detailed definition of the process behavior specification, which is obtained in requirement specification phase. For instance, the artifact association, activity per-condition and post-condition assignment, etc. In Process Behavior model, where a business process is defined in terms of business component objects and their interactions. To obtain an executable model, i.e. CA-PLAN definition, the Process Behavior model is transferred to the Activity model of CA-PLAN, and the rest sub-models are specified according to requirement specifications. The transferring process also creates the design templates of the four other sub-models. These

~ 26 ~ 

templates are used to help to build the sub-model definitions with the editing tools in Agentflow system, based on the corresponding requirement specifications obtained in first phase. For example, role templates are created from the participant information defined in Process Behavior model, and they are used to construct one or more Role models with the role specifications.

After all the sub-models of CA-PLAN are designed, they are analyzed to ensure the business process is executable, which indicates structural correctness [16] and satisfaction of resource constraints [17]. If there is any conflict in the CA-PLAN definition, the development is rolled back to system design or requirement specification phase.

The development ends up with a complete business process definition in CA-PLAN, which is executable on an Agentflow platform. The definition is then taken into testing phase, execution phase, and so forth, which are out of the scope of this thesis and are not discussed.

Requirement specification

Activity model Artifact model Form model Role model Resource model Transferring

~ 28 ~ 

4.2. Transferring algorithm

In this section, we present an algorithm for transferring a BPMN* definition to a PTD definition of CA-PLAN.

As the comparison in the table below, BPMN* has richer notations than PTD.

The objects they have in common are compose-able processes (BP Activities), conditional transitions (BP Sequence Flows), start and end point (start event, end event).

Table 4_1 BPMN* versus PTD

BPMN* object PTD object

BPD Project Multiple start and end events

(with triggers or results)

Single start and end point (without triggers and results) Intermediate event Events are embedded in processes

BP Activity Process

BP Gateway None

(each transition is independent from others)

BP Sequence Flow (with condition) Transitions

(represented by pre-condition and post-condition of connected processes)

BP Message Flow None

BP Association None

BP Pool, BP Lane None

BP Artifact None

The transferring algorithm 4_1 works in three phases. First, in line A01, it recomposes the inter-organization processes into intra-organization processes. In line A02, it transform specific components in the BPD. After these two phases, we shall have a "compressed" BPD whose components are ready for the one-to-one mapping to PTD at the last phase in line A03. The details including the input and the output of each phase will be put in the following subsections.

~ 29 ~ 

Algorithm Mapping BPMN* (B);

Input: B (BPD of BPMN*) Output: B (PTD of CA-PLAN)

A00 begin

A01 Recompose collaboration process (B);

A02 Transform Process (B.process);

A03 One-to-one Mapping (B);

A04 end

Algorithm 4_1 Transferring BPMN*

4.2.1. Phase 1 : Recompose collaboration process

Since the collaborations in CA-PLAN are depicted in a service-oriented approach, we presume that the inter-organization process in BPMN* is defined in the format of call and return with BP Message Flows. A caller is a process which requests a remote service by sending a segment of message, and a waiter is a process which waits for the remote service to be done and accepts the reply. For clarity, we define that a caller is the source of the call message flow, and a waiter is the target of the return message flow. Both processes own the parent process in common according to

~ 30 ~ 

process composition.

The inessential remote information is removed, that is because the internal details of a remote service are not concerned within RCP mechanism, and all of them are regarded as "black box" services.

In algorithm 4_2, we find each pair of BP Message Flows (call and return) and their local contact processes, i.e. caller and waiter. If both the caller and waiter are the same process (e.g. the lower part of figure 3_6), it is identified as a pair of communication annotations and bypassed. Otherwise, a pair of synchronous flows (e.g. the upper part of figure 3_6), and the caller and waiter is replaced with a virtual process named "independent process" in line 05. Pre-condition and post-condition of the independent process are same as the remote process. After we are done with the pair of BP Message Flows, they are removed from the BPD in line 07.

The rest non-pair BP Message Flows are considered as communication annotations and are removed in line 09. At the last of the procedure, all remote BP Pools and their associated processes are removed in line 10.

~ 31 ~ 

Algorithm Recompose collaboration process (B);

Input: B (BPD of BPMN*)

Output: B (BPD without BP Swimlanes, BP Message Flows)

00 begin

09 remove non-pair BP Message Flows

10 remove remote domains information from B 11 end

Algorithm 4_2 Procedure Recompose collaboration process

4.2.2. Phase 2 : Transform process

As prior addressed, there are several notations in BPMN* which has no correspondent in PTD. In this phase, components of these notations are transformed into other BPMN* components which have correspondents in PTD. For example, there is no corresponding PTD notation for the halt event, and thus the halt events in BPD are transformed into the listen tasks.

Therefore, the process is transformed step by step into a "compressed" process whose components are one-to-one corresponding to PTD.

~ 32 ~ 

Algorithm Transform Process (pc);

Input: P (process or sub-process) Output: P (“compressed” process)

00 begin

01 for each embedded Sub-Process ESP in P do {

02 Transform Process (P.ESP);

03 }

04 Remove ignorable commentaries (P);

05 Join start and end events (P);

06 Expand interrupted routines (P);

07 Expand gateways (P);

08 Transform halt events (P);

09 Arrange sequence flow conditions (P);

10 Duplicate references (P);

11 end

Algorithm 4_3 Procedure Transform Process

Lines 01-03 Recursively proceed embedded sub-processes

At the beginning of the procedure, each embedded sub-process of current process is proceeded in advance. Thereby the algorithm recursively works from the bottom to the top level of process composition.

Line 04: Remove ignorable commentaries

The commentaries such as BP Associations and BP Artifacts are redundant. They are removed after validation.

Line 05: Join start and end events

In BPMN*, a start event in BPMN* is corresponding to a start point in PTD, and

an end event is corresponding to an end point. There might be more than one start or end event in a process, while they are not supported in CA-PLAN. To solve the incompatibility, in each process diagram, a start event with no trigger named as initiate event is added to represent the single start point, and an end event with no result named as complete event is added to represent the single end point. Additional BP Sequence Flows are also added to link together begin event and start events, or end events and complete event.

~ 33 ~ 

initiate event

start events end events

complete event

Added

Figure 4_2 Join start and end events

After inserting the begin event, all the start events need to be transformed into halt events with corresponding triggers to obey the BPMN* semantics while preserving the "expecting" behavior. Table 4_2 indicates the transformations of start events. This transformation is only considered as a transit, the forbidden syntax of intermediate events in BPMN (e.g. a halt event with "multiple" trigger) are ignored here.

Table 4_2 Start events transformation

Start event Action

None (no trigger) It is omitted.

With trigger: BP Message, Timer, Rule, Link, or Multiple

It is transformed into a halt event with the corresponding trigger.

For example, in figure 4_3, there are two routines A and B. The A routine starts with a no trigger start event, while B routine starts with a link start event. After the initiate event is added, the start events are transformed into halt events.

Figure 4_3 Example of start event transformation

The end events are transformed into the tasks, which perform the corresponding actions. T

Table 4_3 End events transformation

End event Action

able 4_3 indicates the transformations of end events. The post-condition of each transformed task is set to the completion of the action.

~ 34 ~ 

None (no trigger) It is omitted.

Message trigger It is transformed into a send task.

With trigger: Error, Cancel, es

Compensation, or Link

It is transformed into a (inter-process message) send task.

Terminate trigger It is transformed into a task with system

call that terminates current process.

Multiple trigger It is transformed into an embedded sub-process with corresponding tasks only.

In figure 4_4, two routines B and C end with results "message" and "none"

accordingly. After the complete event is added, the end event with message result is transformed into a task that sends message, while the end event with no result is omitted.

Figure 4_4 Example of end event transformation

Line 06: Expand interrupted routines

An interruptible activity is a BP Activity attached with at least one interrupt event. A complete routine is the subsequent routine of normal completion of the interruptible activity, and interrupt events and their subsequent routines are grouped as interrupt handling routines. For example, the gray area of figure 4_5 is an interrupt handling routine that is designated to be triggered by a cancel event.

~ 35 ~ 

Figure 4_5 Example of interrupted routines

In CA-PLAN, an atomic process is considered as a transaction which can be disrupted by messages (e.g. cancel an assigned work which is out of date). When an interruptible process is interrupted, an interrupt handling routine is executed and then the control is given back to the interruptible process. The problem is that PTD does not support the modeling of interrupt handling routines, and therefore it is necessary to expand the interruptible activities to fit in with PTD.

A halt event with link trigger is added to the compete routine to represent the normal completion of the interruptible activity. The interrupt handling routines are rearranged to become the outgoing flows of the interruptible activity. To decide the subsequent flow among them, a deferred choice pattern (event gateway) is applied after the completion of interrupted activity. Thereby the branch among complete routine and interrupt handling routines are decided according to the completion state of the interruptible activity, i.e. the first occurrence of event (e.g. normal completion or interrupted).

~ 36 ~ 

For example, the process diagram in figure 4_5 is expanded to the one in figure 4_6. If the interruptible activity completes normally, the complete routine is activated.

Otherwise, when timer or cancel event occurs first, the interrupted routine A or B will

be activated accordingly.

Figure 4_6 Example of interrupted routines expanding

Line 07: Expand BP Gateways

BP Gateways centrally control the convergence and divergence behaviors of connected BP Sequence Flows, which correspond to transitions in PTD. Since there is no corresponding concept in PTD, the BP Gateways are expanded.

The idea of expanding a BP Gateways is to scatter its constraints over the connected BP Sequence Flows. A dummy task which performs nothing is used to replace the BP Gateway, and the constraints of the BP Gateway are converted to its pre-condition or post-condition. In this way, the dummy task constrains the incoming or outgoing flows as BP Gateway does.

~ 37 ~ 

Figure 4_7 Example of inclusive gateway transformation

However, the event gateway used in branch function is unlike the others. It combines the behavior of halt event and exclusive gateway, that the decision of event gateway is delayed until the first of the designated BP Events is triggered. The event gateway is expanded to halt events with their triggers, and the exclusive constraint is associated with the outgoing flow condition of the halt events.

Figure 4_8 Example of event gateway transformation

The details of BP Gateways mapping is described in table 4_4 below.

Table 4_4 BP Gateways expanding

type\ function Split Join

Complex Replace gateway with a dummy teway with a dummy task, whose post-condition is

outgoing condition of the gateway.

Replace ga

task, whose pre-condition is incoming condition of the gateway.

Exclusive Replace gateway with a dummy y

task, whose post-condition is exclusive choice of the outgoing flows.

Replace gateway with a dumm task, whose pre-condition is exclusive adopting of the incoming flows.

~ 38 ~ 

~ 39 ~ 

Event Expand gateway to halt events,

and its exclusive constraint is associated with each outgoing flow of the halt events, e.g.

figure 4_8.

Inclusive Excluded from BPMN*.

Parallel

Replace gateway with a dummy task.

Replace gateway with a dummy task, whose pre-condition is set to wait for all the incoming flows.

Uncontrolled No action No action

Line 08: Transform halt events

The pause and recovery behaviors of halt events are implemented with the aid of inter-processes messaging. An expected trigger is expressed as a message, while listen (wait) and notify (trigger) processes are described by receive and send tasks accordingly. Halt events are therefore transformed into receive tasks, whose action is waiting for a trigger message. Note that the inter-processes messaging must be distinguished from the inter-organizational messaging, i.e. BP Message Flow in BPMN*.

Table 4_5 Halt events transformation

Halt event Action

None (with no trigger) It is omitted.

With trigger: Message, Error, Timer, Compensation, Rule, or Link

It is transformed into a corresponding receive task, whose post-condition is set to the completion of trigger.

Figure 4_9 Example of halt event transformation

Line 09: Arrange BP Sequence Flow Conditions

In CA-PLAN, we can use a transition to represent the combination of pre-condition and post-condition of processes. To transform a BP Sequence Flows into a transition of PTD, the conditional constraints of each BP Sequence Flow are associated with the pre-condition and post-condition attribute of each connected BP Activity.

Line 10: Duplicate references

~ 40 ~ 

The reference activity is used to reference another sub-process or task. All the references share exactly the same behaviors and properties with the referent. The reference activities have no corresponding notations in PTD and each of them is replaced with a copy of the referent (i.e. referenced activity).

~ 41 ~ 

4.2.3. One-to-one mapping

The BP Activities are similar with processes in the CA-PLAN. They are mapped to corresponding processes of PTD in this step.

Table 4_6 indicates the relations between BPMN* BP Activities and PTD processes. In BPMN*, an independent sub-process can be used to represent invoking either a local process module or a remote service supported by data-mapping (e.g.

RCP); it is mapped to a corresponding process accordingly. In comparison with an independent sub-process, a service task is used to represent message-based services rather than RCP (e.g. a web service). Tasks are mapped to atomic processes in PTD with appropriate programming constructs, whose detailed behavior is adjusted latter.

The attributes associated with process are also used to generate design templates.

Table 4_6 BP Activities mapping

BP Activity Corresponding process in PTD Embedded sub-process Compound-process

Independent sub-process Call-process (local) or remote service (remote)

Reference sub-process, reference task None

(Transformed in procedure "Transform process", line 10)

Service task, receive tasks, send task, user task, script task, or manual task

Atomic processes

The rest of the BPMN* notations, i.e. initiate event, complete event, and BP

~ 42 ~ 

Sequence Flows, are mapped directly into corresponding notations of PTD. Table 4_7 indicates the relations among these notations.

Table 4_7 Miscellaneous notation mapping

BPMN* notation Corresponding object in PTD

Initiate event Start point

End event End point

BP Sequence Flow Transition

~ 43 ~ 

Chapter 5. Case study

In this section the development of a trading process is taken as example to demonstrate the methodology. This case concerns an on-line trading system that accepts customers’ orders, redeploys and delivers ordered goods, interacts with a banking system, and notifies customer when the trading process is complete. The banking system is a cooperative system that provides service for the trading system to confirm or rebate the customer payment.

5.1. Requirement specifications

We define the process specification from the perspective of trading system. The orders from customers are presumed to be handled by front-end systems, such as a web shopping system. Thereby the interactions between the trading system and its customers can be simplified as events.

The whole trading process begins with receiving the order from a customer, which has been validated by a front-end system. The trading system then consults the bank for confirming the payment. If the remittance is not confirmed, a failed notification is sent to the customer and the process is terminated; otherwise the system starts to redeploy the ordered goods. In case the order is canceled during redeployment, the payment is rebated to the customer. As soon as redeployment completes successfully, the goods are delivered and the invoices are filed. At last the reply of successful delivery notification is sent to customer.

z Process behaviors

The process behavior is specified as BPMN* diagram in figure 5_1.

Figure 5_1 Trading process

z Reference data instances

„ Customer information

z Deliver address, contact methods z Payment account, rebate account

„ Goods information

z Goods ids, quantity, price

~ 44 ~ 

„ Invoices

~ 45 ~ 

„ Process information

z Checking result (boolean) z E-Forms

„ Goods deployment form (GDF) z Roles

„ Customer

„ Trading system

„ Banking system

5.2. System design

• Process behavior modeling

Table 5_1 Process events

Event Trigger/ result

Incoming order (start event)

An order (message from the customer) is received.

Fail notification (end event)

The notification is sent.

Cancel interrupt (interrupt event)

The cancel notification is received during deployment.

Cancel notification (end event)

The notification is sent.

Success notification (end event)

The notification is sent.

~ 46 ~ 

Table 5_2 Process stages

Process stages Start condition End condition

Order checking The order is received. The order checking has been done.

Goods redeployment The order checking result is confirmed.

(checking result = T)

The goods have been deployed or the order has been canceled.

(deployment result=T or F) Order canceling The redeployment is

canceled.

The order has been canceled.

Rebating The order is canceled. The payment has been rebated.

Delivery The goods are deployed. The goods have been delivered.

Invoice making The goods are deployed. The invoices have been made.

• Transferring

For the first phase, the collaboration processes are recomposed. There are two remote processes defined for the trading in the banking system. One is the "remittance checking" process which interacts with the "order checking" process. This pair of BP Message Flows is considered as communication annotations and the "order checking"

process is considered as a service task. The other is the "rebating" process executed after order canceling process. It is synchronized with an implicit send and receive event, which are transformed into an independent process named "rebating request".

The result of this phase is showed in figure 5_2.

Note that if the process behavior is specified with BPMN, the modeler will likely be confused with the execution sequences of local and remote processes.

Note that if the process behavior is specified with BPMN, the modeler will likely be confused with the execution sequences of local and remote processes.

在文檔中 BPMN* 與工作流程管理系統之整合 (頁 33-0)