Detecting and repairing modeling errors
Many process models created using traditional methods contain modeling
errors. When dragging and dropping single graphical model elements on
a canvas, users often lose sight of the control flow that they design
when connecting the single model elements and adding gateways to their
process model. When creating a process model using the accelerators,
notably the patterns, you cannot introduce modeling errors into your
model. However, on traditionally created models, the accelerators help
you to easily detect, locate, and correct errors in those models.
Copy the Evaluate Candidate-Faulty Version process from the Hiring
process catalog to the Exercise process catalog and open it in the
editor. The Evaluate Candidate process describes the evaluation and
interview process for an applicant applying for a student internship
or researcher position. This process is used by the research team
co-authoring this article. It was modeled in the traditional way
without using any patterns, refactorings, or transformations.
Unfortunately, it contains two control-flow errors.
The initial part of this process is shown in Figure 40. The first task
in the process is Receive Application, which captures the arrival of
an application folder. The task is followed by the Check CV task to
examine the curriculum vitae of the applicant. Then, a fork gateway
follows that opens three parallel branches. The upper branch contains
the Review Selected Publications task where available publications of
the candidate are examined and some are selected for further review.
The middle branch contains the Examine Qualification Profile task to
check whether the skill profile of the candidate matches the skills
needed by the team. The lower branch contains the Check Grades
& Certificates task that looks at the formal documents
included in the application. The three branches are closed by a merge
gateway.
Figure 40. Initial part of
the Evaluate Candidate process
The final part of the Evaluate Candidate process contains three
decision gateways. If the candidate looks promising after the initial
reviews, an exercise is sent to the candidate to test technical and
collaboration skills. If the candidate scores well on the exercise, an
interview is scheduled. If the interview is successful, the candidate
is usually accepted. In all other cases, the candidate is rejected
— that is, the three No branches of the decision enter the
Reject task at the end of the process model.
Figure 41. The final part
of the Evaluate Candidate process
Each part of this process contains a very typical modeling error that
usually happens when models are created in the traditional way. Click
right on the Evaluate Candidate process in the project tree and invoke
the Control-Flow Analysis from the menu. Alternatively, click
right on the white space of the drawing canvas and invoke
Control-Flow Analysis from the menu that is associated with
the drawing canvas. A new view containing error messages is added at
the bottom of Business Modeler (Figure 42).
Figure 42. Errors detected
by the control-flow analysis
Click the plus sign (+) in front of the error message to view further
details. More detailed error descriptions inform you about the type of
error (lack of synchronization or deadlock) and the location of the
error in some fragment of the process.
Figure 43. The detailed
error description
Our example process contains a lack of synchronization error in the
initial part. The error is caused by the fork and detected on the
merge. The final part of this process contains a deadlock that is
detected on the Reject task. By double-clicking on an error message
the fragment containing the error is highlighted in red (see Figures
44 and 45 in the following section).
A lack of synchronization
modeling error
A lack of synchronization is an error where two or more parallel
branches are not correctly synchronized in the process model. Because
of this, all tasks following the insufficient synchronization are
executed more often than intended.
In our example, the fork gateway opens three parallel branches that are
synchronized by a merge gateway. The merge waits for one branch to
finish and then continues to route the flow to the final part of the
process. This means that, for each branch entering the merge, the
final part of the process will be executed once (three times in
total). Of course, this is not the intended process behavior.
Figure 44. A lack of
synchronization error in the Evaluate Candidate process
model
A deadlock modeling
error
A deadlock is a modeling error that causes the control flow to stop at
some task or gateway in the process model because the task or gateway
waits for some input that can never arrive. In our example, the Reject
task waits for three control inputs from each of its incoming
connections. However, only one of the three required control flow
inputs is activated in any execution of the process, because the three
decision gateways always activate exactly one of their output
branches. The control flow will therefore stop at the input of the
Reject task, which can never execute.
Each decision in our example process opens two exclusive branches.
Either the Yes or the No branch is taken. For example, if the first
decision activates the No branch, the other two decisions are no
longer taken as the control directly proceeds to the Reject task. It
is therefore impossible for the Reject task to receive all three No
inputs at the same time.
Figure 45. A deadlock
error in the Evaluate Candidate process model
You can observe the problematic behavior caused by these two types of
errors by simulating your process model with Business Modeler. To read
more about modeling errors, see the articles in
Resources.
Recall that the control-flow analysis detected two errors in the
Evaluate Candidate process:
- A lack of synchronization caused by pairing a fork gateway with a
merge gateway.
- A deadlock caused by a task that expects three inputs coming from
alternative branches.
To identify the gateway causing the lack of synchronization, examine
the affected process fragment. The fork is correct, because we want to
execute all three tasks in parallel. Consequently, the merge must be
replaced by a join that correctly matches the fork.
Figure 46. Examining the
lack of synchronization error
To correct the lack of synchronization error, select the merge and
invoke Transform > Toggle Gateways or click on the  icon in the palette. The merge will be replaced by a join.
Save the process model and then run the Control-Flow Analysis again
— the error is no longer reported (Figure 47).
Figure 47. Applying the
Toggle Gateways transformation corrects the lack of
synchronization error
Select either the fork or the join and run the Toggle Gateways
transformation again. It will now toggle both gateways simultaneously
— that is, the fork is changed to a decision and the join is
changed to a merge. The reason for this behavior: when you toggle a
gateway that is part of a process fragment that contains an error,
only the selected gateway is toggled. When you select a gateway that
is paired with one or more correctly matching gateway(s), the set of
matching gateways is always toggled together to ensure that you do not
introduce a modeling error into your model when toggling gateways. In
a nutshell, the Toggle Gateways transformation allows you to correct
errors caused by gateways, but it will always ensure that you do not
transform a correct model into an incorrect one. See part 3 of this
series for details.
To correct the deadlock error, first make the error more explicit.
Select the Reject task and invoke Refactor > Activity to
Gateway Form or click on the  icon in the palette (Figure 48).
Figure 48. Applying the
Activity to Gateway Form refactoring
The three connections that lead directly to the Reject task are
converted to a join with three incoming connections and a single
outgoing connection that leads to the task. The Activity to Gateway
Form refactoring provides you with a correct translation of the input
and output logic of a task into the corresponding gateways. See part 4
of this series for details.
You can now see that the outgoing flow of the three decisions is
incorrectly matching the join gateway.
Figure 49. The join
gateway that incorrectly merges the decision gateways
Select the join and invoke Transform > Toggle Gateways
again to toggle the join into a merge. Save the corrected model and
run the control-flow analysis again. No error is reported!
| 
