Your SlideShare is downloading. ×
Chapter 4 "Process Orchestrations"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Chapter 4 "Process Orchestrations"

278
views

Published on

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
278
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
57
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 3/26/2013 CHAPTER OUTLINE • Section 4.1 introduces control flow patterns, a Business Process Methodology yardstick in process control flow structures. The patterns will be described both textually and more Chapter 4- Process Orchestrations formally using the event-based approach introduced in the previous chapter. • Section 4.2 provides a compact introduction to Petri nets. Different Petri net classes are introduced, Prepared by: including condition event nets, predicate transition Rao Majid Shamshad nets and, colored Petri nets. University of Education, Lahore • An informal perspective on business process modelling email: majidrao111@yahoo.com http://www.bpm-ue.blogspot.com is taken in Section 4.3, where event-driven process chains are discussed. This approach is widely used in the business domain to model business processes from a pragmatic, application-oriented point of view. 4.1 CONTROL FLOW PATTERNS • Basic control flow patterns include:• Control flow patterns provide a yardstick for – sequence, expressing process orchestrations. Control – and split, flow patterns are independent of concrete – and join, process languages, so that each pattern can – exclusive or split be expressed in different process languages. – exclusive or join. Control flow patterns can also be used to • These control flow patterns are supported by compare the expressiveness of process virtually any process meta-model. Control flow languages. patterns are defined at the process model level. Their execution semantics, however, applies to process instances. 4 1
  • 2. 3/26/2013• Activity models are denoted by capital letters, SEQUENCE A,B,C, . . ., • The sequence pattern defines that an activity• while the associated activity instances are instance b in a process instance p is enabled denoted by small letters, i.e. a, b, c, . . .. after the completion of activity instance a in p,• Gateways are typically denoted by G, and g is with process model an instance of a gateway • P = (N,E, type) containing activity models A, B,• Let P be a process model and p a process and a gateway model G such that A,B Є NA, instance based on this model with an event G Є NG, E Ͻ {(A,G), (G,B)}, and set Ɛᵨ. type(G)=Sequence 5 6• The application of the sequence pattern in A→B induces an event ordering between the termination event of a (and the activity instance of activity model A) and b, such that b can only be enabled after a has terminated. This approach relates the control flow patterns directly to the state transitions of activity instances.• In particular, the state transition from init to enabled of an activity instance b can only be done after the state transition from running of a to terminated of a has occurred. 7 8 2
  • 3. 3/26/2013 And Split • An and split or parallel split is a point in a process model where a single thread of control splits into multiple threads of control which are executed concurrently. • An and split determines that for each termination of an activity instance a there are enable events of activity instances b and c, and these events occur after the termination event of a. 9 10 And Join • An and join is a point in a process model where multiple concurrent threads converge into one single thread of control. It is an assumption of this pattern that each incoming branch is executed exactly once. • For each enable event of an activity instance d, there are termination events of activity instances b and c, such that the termination events occur before the enable event.11 12 3
  • 4. 3/26/2013 Xor Split • An Xor split or exclusive or split is a point in a process model where one of several branches is chosen. • The execution semantics of an exclusive or split determines that for each termination of an activity instance a associated with activity model A there is either an enable event of activity instance b or an enable event of an activity instance c, but not both:13 14 Xor Join • An xor join or exclusive or join is a point in a process model where two or more alternative threads come together without synchronization. It is an assumption of this pattern that exactly one of the alternative branches is executed. • For each termination event of an activity instance b or c there is one and only one enable event of an activity instance d. • While it is an assumption of this pattern that the branches are alternative and none of them are ever executed in parallel, the branches can be part of a loop. But even in this case, for each iteration of a loop, the branches are alternative and have exclusive or semantics.15 16 4
  • 5. 3/26/2013 Or Split • An or split is a point in a process model where a number of branches are chosen. Selection of any nonempty subset of branches is a proper behavior of an or split. • An or split restricts the events of related activity instances as follows: for each termination event of a there is a subset of enable events of b and c. In general, for each termination event of a there can be enable events for any subset of activity instances on the outgoing branches of the split.17 18 Or Join • An or join is a point in a process model where multiple threads of control converge into one single thread. It is an assumption of this pattern that a branch that has already been activated cannot be activated again while the merge is still waiting for other branches to complete. • The or join is a problematic control flow pattern. The problem is that the join cannot locally decide how long to wait for its activation.19 20 5
  • 6. 3/26/2013• Even from the simple process model fragment shown in Figure 4.9, this problem can be explained: once one incoming branch is triggered, for instance, by termination of b, how should the or join react? There are two options: – Wait: The or join waits before the activity instance d is triggered, because the other incoming path—which completes in activity instance c—can still be executed. – Trigger : The or join triggers d immediately after the termination of b.• The problem is that we cannot decide which of these alternatives the correct one is. After the first incoming branch has terminated, how long should the or join wait for the other branch to complete? If no additional knowledge is available, there is no way of deciding whether c will eventually terminate for the particular process instance. Since there is 21 22 Multiple Merge• A multiple merge or multi-merge is a point in a process model where two or more concurrent threads join without synchronization. The activity following the merge is started for every activation of every incoming branch.• The multi-merge is functionally equivalent with the exclusive or join; the only difference is that the latter assumes that only one of its incoming branches gets activated. This assumption is not in place for the multi-merge pattern. 23 24 6
  • 7. 3/26/2013• The multiple merge pattern spawns off new threads of control. These threads need to be identified so that future joins can be realized properly. These aspects are illustrated in an example shown in Figure 4.11, where a process model with an and split followed by a multi- merge is shown. As a result, any of the threads induced by the and split will survive the multiple merge and spawn a new instance for activity model D and of the activity models following D in the process model.• Each of the threads of control spawned off by the multi-merge is subject to the and split/and join shown in the process model. The and join requires information on the identity of the threads that come in; otherwise, situations could arise in which activity instances that belong to different threads of control are synchronized. These issues can be illustrated by the event diagram 25 26 Discriminator• The discriminator is a point in a process model that waits for one of the incoming branches to complete before activating the subsequent activity. From that moment on it waits for all remaining branches to complete and “ignores” them. Once all incoming branches have been triggered, it resets itself so that it can be triggered again. This allows a discriminator to be used in the context of a loop. 27 28 7
  • 8. 3/26/2013 These activity instances are b2 and c2. What is remarkable in this example is that there are two instances of activity model C active concurrently, assuming c1 has not yet terminated. Even if c2 terminates before c1, the semantics of the discriminator makes sure that it can only fire and enable d2 after the first iteration has completed, i.e., only after the remaining activity instance c1 has terminated. If• An example involving the discriminator pattern is this I the case, the discriminator can fire a second time, to shown in Figure 4.14. The process starts with enable d2. The event diagram of this process instance is activity instance a before an and split occurs that shown in Figur 4.15. spawns activity instances b1 and c1. Assuming b1 terminates first, the discriminator fires and enables d1. When d1 terminates, assuming a new iteration of the loop is required, new activity instances based on B and C are created. 29 30 Arbitrary Cycles A more complex example of a cycle involving the multi- merge pattern I shown in Figure 4.18. The problem in• An arbitrary cycle is a point in a process model where one or more activities can be executed this example is that the cycle enter one of two repeatedly. concurrent branches of an and split whose branches• An arbitrary cycle is graphically depicted in Figure are joined b a multi-merge 4.17. In this example, a sequence consisting of activity models A, B, and C is iterated. The iteration is represented by an exclusive or split that decides whether to iterate the cycle or whether to leave it and continue with activity instance d, associated with activity model D. In case the loop is iterated, the exclusive or join triggers another instance associated with activity model A. 31 32 8
  • 9. 3/26/2013 Deferred Choice • Deferred choice is a state-based pattern. State-based patterns capture the implicit behaviour of processes that is based not on the current case but rather on the environment or other parts of the process. Some of the following patterns require the existence of an external process that represents the environment. This process is used as a source for external events. 33 34• A deferred choice is a point in a process model where one of several branches is chosen. In contrast to the exclusive or split, the choice is not made explicitly—for example, based on data values or a user decision—but several alternatives are offered to the environment.• The environment activates one of the alternatives, and the other branches are then withdrawn. Because the choice is delayed until one of the alternative branches has actually been started, the moment of choice is deferred to a point in time that is as late as possible 35 36 9
  • 10. 3/26/20134.7 BUSINESS PROCESS MODELING NOTATION 37 38 39 40 10
  • 11. 3/26/201341 4243 44 11