3.1 Process Behavior

This video belongs to the openHPI course Business Processes: Modeling, Simulation, Execution. Do you want to see more?

Enroll yourself for free

3.1 Process Behavior

Time effort: approx. 17 minutes

An error occurred while loading the video player, or it takes a long time to initialize. You can try clearing your browser cache. Please try again later and contact the helpdesk if the problem persists.

Scroll to current position

00:00Ladies and gentlemen I'd like to welcome you to the third week
00:03of our course on business process modeling and analysis. In
00:07this week we will analyze process behavior.
00:11The week is organized as follows - we have seven video clips all together.
00:17Three of them are bonus material and I will say a few words
00:22in a minute about these bonus material.
00:24It's about process behavior and how to analyze process behavior.
00:28This in itself is a little bit on the formal side, a little
00:32bit on the theoretical side but I'll try to
00:35explain the concepts as informally and as practically as I can.
00:41So in video one 3.1 we define process behavior. What
00:45actually is the behavior of the business process?
00:49In the video 3.2 we look at structural soundness
00:54or structural soundness is a prerequisite for soundness as which is
00:59the criterion that we will look at in this week.
01:03So video 3.3 looks at soundness and explains in an
01:08informal way how soundness what soundness is what soundness can
01:12be applied to processes.
01:14In video 3.4 we look at simulating business processes
01:19before we start the bonus material, and the bonus material is
01:23still on the informal side but again a bit more formal than
01:27what we discussed earlier in this week.
01:31So 3.5 looks at an informal petri net primer, presents
01:36petri nets which is a formal foundation of behavioral analysis of processes,
01:42explains petri net in a very informal brief way also.
01:47Afterwards in 3.6 we map BPMN process models to petri nets
01:53and in 3.7 we use petri nets to check soundness. To check soundness
01:58of the BPMN process model, so that we know that's the
02:02BPMN process model is correct.
02:06In the bonus homeworks you can own additional points. So it's
02:10not only that we have the bonus videos but there will also
02:12be a bonus homework and these go on top of the normal points.
02:18So you can own additional points, so that you can improve your
02:22overall score that you achieve in this course.
02:30In week two we looked at the syntax and all, this
02:34is the semantics of modeling languages in particular process modeling languages.
02:39And we define syntax as well syntactic correctness
02:45makes sure that the elements of the model are organized in a way
02:49that matches the abstract syntax of the modeling language . And
02:53as an example I have again this claim insurance claim process
02:58model that we discussed earlier already.
03:01So here we can track whether it's syntactically correct. So
03:04what we do we need to check their well we can take a look at
03:08the start event. The start event does not have any incoming
03:13edges that would be syntactically incorrect. Start events do not have
03:17incoming a flow edges and the end events do not have any outgoing
03:22flow edges, also that is correct.
03:25We have a number of activities
03:28and we have one gateway and these are connected by sequence
03:32flow and also the sequence flow each sequence flow edge
03:36is connecting exactly two nodes so that this process
03:40more we can say is technically correct even if we look at the
03:44at the role here insurance company that is we would say that is a
03:48syntactically correct process model expressed in the BPMN.
03:52So it complies to the abstract syntax of the BPMN.
03:58So how about semantics?
04:00Well the semantics of a process model
04:05defines the meaning of syntactically correct process models.
04:08We only need to have a meaning for a syntactically correct process model.
04:12The meaning is the behavior defined by the process model which is
04:17the order of performed activities.
04:20So in this example again we see simple simple process
04:25simple behavior so we have an event that occurs that is
04:28the claim received event, the event that occurs in the beginning.
04:39Alright here we go. So that is the first event that occurs
04:45and after that event occurs register claim is executed decide
04:50on claim coverage and then there is a decision. Either we go to
04:52the upper branch or we go the lower branch either of the two for each
04:57for each process instance either the upper branch is taken
05:01or the lower branch is taken. And that's basically the semantics
05:04of this process.
05:07We were discussing syntactical correctness and now we
05:10turn to semantic correctness.
05:13Semantic correctness needs to ensure that the process behaves
05:17correctly and terminates properly.
05:20So and this example shows that we can build
05:25process models that are syntactically correct but they have semantic
05:31they are semantically incorrect, they have a flaw. That is
05:35let's say undesirable in process models so we need to be able to detect
05:40these kinds of flaws and this is exactly what we aim at in this week.
05:46Alright so semantic correctness ensures that a process behaves
05:50correctly and terminates properly.
05:53And to analyze in semantic correctness the process model
05:57needs to be checked for the absence of behavioral anomalies we call it.
06:02So let's take a look at this process model. It's a variant of an order process
06:09in which first we analyze the order,
06:13we receive the order which is modelled as an activity here,
06:18then we have concurrent branches. So we can
06:23package the product and ship or issue the shipment concurrently
06:26to sending the invoice and receiving the payment only after
06:30these two and there is the AND split.
06:32Only after these two branches have completed we have
06:36the synchronizing behavior of the AND joins or the AND join
06:40here. And only if these two branches terminate then the
06:45next activity can be started which is checking the payment.
06:50In this process model is represented that the check payment
06:53has two outcomes, two possible outcomes. One is if the amount
06:58is invalid. So here we have
07:01our condition attached here invalid amount.
07:04If the amount is invalid, we need to send an updated invoice
07:09to make sure that we receive
07:13all the outstanding funds.
07:15Although the remaining funds that have not been paid so far.
07:21Alright so let's assume we go the lower way so the cheque payment activity resulted
07:27an invalid amount to be true. So the amount was not valid. We
07:31send an updated invoice and then so
07:35and then we go to this and XOR join again
07:42and what we do is we wait for receiving the payment. Assume the payment comes,
07:47we receive the payment. So we are at this position exactly and we have
07:50completed the receive payment activity. So what happens in this process?
07:54Well it should continue
07:59but this is not what happens. Actually this AND join
08:04AND join here waits for both incoming edges to be signalled. And
08:08here in this case only one incoming edge is signalled namely the
08:12one from the receive payment activity. Therefore the process gets stuck
08:16so it's a perfectly correct process model from
08:20a syntactic point of view but it has this semantic error semantic flaw
08:25that it gets stuck it might get stuck.
08:28If the other branch would be chosen in the first
08:32after the first cheque payment activity than the process would
08:35would terminate properly. But there are cases in which the process does not
08:40complete properly and this is a semantic incorrectness that we
08:44should be able to detect.
08:47So this week we explain correct process behavior in an informal way.
08:53And as mentioned before as bonus material we also introduce
08:56petri nets and a mapping from BPMN process models to petri nets
09:00for a more formal investigation of correctness.
09:06Process behavior was specified so far also informally.
09:11So this activity is executed and the other activity has been executed.
09:15Here we will make it a bit more precise. So the behavior
09:19of a process model can be characterized by the set of all execution
09:24sequences that are possible in this model.
09:28Therefore we look at the traces
09:31of the process model resulting from events that occur and activities that are performed.
09:36So we look at activities that are performed and events that occur.
09:41And we build we build sequences of these
09:46events and activity in the available traces or so to speak traces
09:52of the process and the resulting semantics. Therefore they are called
09:55trace semantics. So the trace are the steps that are taken during
09:59execution of the process.
10:02Ok so this another example again. What are the traces? And
10:08each trace begins with a claim received. So there's a
10:13trace claim received, register claim, decide on claim coverage,
10:17prepare a letter of approval and claim approved. That's one trace
10:21one possible execution of the process. So we see that not all
10:25activities need to be present in all traces. Of course we have the decision here.
10:32But there's another trace and another trace starts like
10:38like the first one. So receiving the claim, registering the claim
10:41decide on claim coverage. But then prepare letter of rejection is
10:46executed and the claim is rejected. So there are two traces
10:50this process more or less exactly two traces.
10:55So this is shown here again,o traces in the example
11:01traces in the example are exactly the two traces we we can see here.
11:07So yeah first the first one goes until
11:14approval takes the upper branch and the second one takes the
11:17lower branch. So there are exactly these two traces for this
11:19process model.
11:23In behavioral analysis we abstract from the actual running states
11:28of an activity and so we said this activity happens that this
11:32activity is executed this activity is executed. So we are not
11:35really interested in the running phase itself and this is appropriate
11:39since we're interested in the logical ordering of the activities
11:42and not in the activity executions themselves. So just interested
11:47in the behavioral analysis looking for behavioral flaws.
11:51So what do we actually do when we analyze the semantics using the trace semantics?
11:56An activity goes directly from the ready state
12:00to the terminated state.
12:02So there is a bypass so to speak of the running state because
12:06activity that is ready then in one step is terminated.
12:11We might even see that a bit more clear in this example that exhibits concurrency.
12:16So concurrency results in traces with an arbitrary ordering of concurrent
12:21activities. So in this abstract example
12:24we have different races. So each trace starts with with
12:28the event I, so we start we label the start event I
12:34last event O. Reasons will be discussed in a minute,
12:39or later this week I should say.
12:42So the first activity that happens here is A.
12:47Ok let's highlight that, that's the A.
12:50And then we have concurrency and in concurrency we learn that the execution paths
12:56are independent from each others. So B and D can be executed
13:01independently. So either B can start
13:04B can be executed start can be executed
13:08and then after B has been executed C or D can be executed.
13:15And so let's assume D is executed or D
13:19happens I should say. Afterwards E might happen or C might
13:24happen. And only but only if all of these five
13:28activities have been have occurred have happened we
13:33need to perform F. So F happens and then the final event
13:37the output event happens.
13:40Alright so here we have not just
13:44two traces as we have a number of traces and we have here
13:49i've shown here the traces. The first one
13:53that is a sorry I need to
13:56use the highlighter again.
13:59The first one is I, so I A
14:07D, no sorry.
14:12So let's erase all that to make it a bit more clear.
14:18So we now investigate the first the first trace here. The first
14:22trace starts with I, then we have the A, then we have the B,
14:28then we have the D,
14:31then we have the C and the E, finally the F and the O. So that's one
14:36one way of executing this. So the first trace.
14:40The second trace we have a different ordering of the concurrent
14:42activities. So we first have B and C and then D and E.
14:47In the last one we also have a different ordering of the concurrent activities. We have
14:52we start with D and E and then have B and C.
14:56So you see if there's concurrently if there's concurrence in
14:59a process model we have a larger state space, more states can be
15:05process can be in more states and that makes it far more
15:09complex than just having sequential execution like we've seen in
15:12the first example.
15:15Right in general all traces are allowed in which I A
15:19is followed by any ordering of B C D and E where B occurs before C and D
15:24occurs before E followed by F and the O.
15:31Ok we now need to look at loops and here in this example
15:35we have a loop from well see it after executing the first part
15:41of the process we can step back to A
15:43which it is used as a join node.
15:48And here we can have loops of arbitrary length depending
15:52on the number of iterations the number of iteration is not
15:55fixed. So they can be
15:57it can be loops of arbitrary lengths and one example is here I
16:01would not discuss that. I think it's quite clear. After the first iteration
16:05of these activities I can jump back one loop iteration one possible loop iteration
16:11a trace is shown here.
16:16Also I did that once for two loop iteration but you can of
16:19course expand that to any number of loop iterations which
16:23increases the length of the trace of course.
16:26Alright that concludes video clip 3.1 in which we
16:30introduced process behavior, we looked at syntactic correctness
16:34but also semantic correctness which means the behavior of a process model.
16:39We looked at an example where we have a behavioral anomaly
16:43and we introduced traces as a means to characterize behavior.

About this video

<p>Business processes that do not violate any syntax rules may, nevertheless, be subject to behavioral anomalies, e.g., deadlocks. The analysis of the behavior of a business process can disclose such anomalies and provide insights towards their resolution.</p>