=Paper=
{{Paper
|id=None
|storemode=property
|title=Supporting Blended Workflows
|pdfUrl=https://ceur-ws.org/Vol-940/paper5.pdf
|volume=Vol-940
|dblpUrl=https://dblp.org/rec/conf/bpm/PassinhasAPCSH12
}}
==Supporting Blended Workflows==
https://ceur-ws.org/Vol-940/paper5.pdf
Supporting Blended Workflows
Davide Passinhas1 , Michael Adams2 , Bernardo Oliveira Pinto1 , Ricardo
Costa1 , António Rito Silva1 , and Arthur H.M. ter Hofstede2,3
1
INESC-ID/IST/Technical University of Lisbon, Av. Prof. Dr. Cavaco Silva,
2744-016 Porto Salvo, Portugal
{davide.passinhas,bernardo.pinto,ricardo.antunes.costa,rito.silva}@ist.
utl.pt
2
Queensland University of Technology, Brisbane, Australia
{mj.adams,a.terhofstede}@qut.edu.au
3
Eindhoven University of Technology, Eindhoven, The Netherlands
Abstract. Despite advances in the field of workflow flexibility, there
is still insufficient support for dealing with unforeseen exceptions. In
particular, it is challenging to find a solution which preserves the intent
of the process as much as possible when such exceptions are encountered.
This challenge can be alleviated by making the connection between a
process and its objectives more explicit. This paper presents a demo
illustrating the blended workflow approach where two specifications are
fused together, a “classic” process model and a goal model. End users are
guided by the process model but may deviate from this model whenever
unexpected situations are encountered. The two models involved provide
views on the process and the demo shows how one can switch between
these views and how they are kept consistent by the blended workflow
engine. A simple example involving the making of a doctor’s appointment
illustrates the potential advantages of the proposed approach to both
researchers and developers.
1 The Blended Workflow Approach
The blended workflow engine supports a novel approach [1] to workflow man-
agement systems that provides end users with two views of the same workflow
instance, a “classical” workflow view based on an explicit process model and a
view which shows objectives and their relationships. By executing the workflow
instance according to the former view, end users’ work is guided by a defini-
tion of what is the standard behaviour, specified by explicit organisational rules,
whereas the latter view empowers end users to use their tacit domain knowledge
to handle unexpected situations.
The two views are supported by two different specifications, one activity-
based and the other goal-based. Both specifications share a common data model.
As a workflow instance progresses toward its completion via consecutive instan-
tiations of its data model, the two specifications describe a prescriptive and a
descriptive way of instantiating the data model.
2 Passinhas et al.
The two specifications are consistent from a semantic point of view: any
workflow instance that is executing according to one of the specifications can
continue executing according to the other. Therefore each view can present the
current state of the workflow instance to end users, who can switch between the
two views without having to redo any of the work they have done while using
the other view. However, it is possible to produce more information using the
goal-based specification, so that additional knowledge that may be useful when
dealing with unexpected situations can be acquired. Additionally, it is possible
to relax some restrictions when executing according to the goal view or to skip
the execution of activities in the activity view.
episodes medicalPrescription
Patient 1 Episode 1 0..1 Medical
*
String name (key) patient Int number (key) episode Prescription
Int age (key) Date reserveDate (key) String description
Bool heartProblems Bool checkin 1 medicalPrescription
episode Bool checkout (key)
(key) 1 1 episode (key)
1 patientData prescriptionMedication
1 medicalReport *
Patient Data Medical Report Prescription
Int height String description Medication
Int weight Int number (key)
int bloodPressure String name
String physicalCondition Int quantity
bool heartImpact
Fig. 1. Doctor Appointment Example - Data Model
Figure 1 presents the data model for a Doctor Appointment workflow spec-
ification. The creation of a workflow instance corresponds to the creation of an
Episode instance and its association to an existing Patient instance. The work-
flow instance progresses by creating instances of the other entities. Eventually a
Medical Report will be written and the patient checks out.
Figure 2 presents the activity-based specification of the Doctor Appointment
example. The specification follows a typical BPMN4 -like activity-based speci-
fication enriched with pre- and post-conditions, denoted respectively by PRE
and POS. For each activity, its pre- and post-conditions describe what should
be the data model state immediately before and after the execution of the ac-
tivity, respectively. An activity-based specification can execute in an activity
engine in isolation, ignoring its set of pre- and post-conditions, but pre- and
post-conditions are necessary for the blended workflow to keep both views syn-
chronized, as we shall show in the demo.
The specification shows that the Booking activity creates an instance of
Episode and sets its reserveDate attribute. Note that the creation of an Episode
instance requires a Patient instance and a value for the number attribute, which
4
http://www.bpmn.org/
Supporting Blended Workflows 3
PRE: episode is DEF
POS: (patientData.height is DEF) AND
(patientData.weight is DEF))
Collect Physical
patient data medical report episode
Data
patient list episode
episode
Doctor
Booking CheckIn Checkout
Appointment
POS: (episode is DEF) AND PRE: episode.reserveDate == TODAY PRE: (episode is DEF) AND PRE: (episode is DEF) AND
(episode.reserveDate is DEF) POS: (episode.checkin is DEF) (patientData.bloodPressure is DEF) (medicalReport.description is DEF)
POS: (medicalReport.description is DEF) POS: (episode.checkout is DEF)
Collect Medical
Data
PRE: episode is DEF
POS: (patientData.bloddPressure is DEF) ANF
(patientData.physicalCondition is DEF))
Fig. 2. Doctor Appointment Example - Activity Specification
constitute the key attributes of Episode. As another example, note that the ex-
ecution of Collect Medical Data only requires an instance of Episode. This
relaxed restriction occurs because the blended workflow allows activities to be
skipped. In this case it would be possible to skip the Booking and Checkin activ-
ities, but to execute Collect Medical Data if an Episode instance is created.
CT: Prescription Medication
MC: (heartImpact == FALSE) OR
CT: Episode (medicalPrescription.episode.patient.heartProblems == FALSE)
Process Heart
Medical Medication
CT: Episode Appointment Restriction
SC: reserved = today Checkout
Patient
Book
CT: Episode
Patient
AC: checkin
SC: checkout is DEF
Checkin
Patient Write
CT: Episode Medical Write
AC: today == reserved Report Medical
Obtain
SC: checkin = TRUE Prescription
Patient
Data CT: Medical Report CT: Medical Prescription
CT: Patient Data AC: (episode is DEF) AND AC: episode.checkin
AC: episode.checkin (episode.patientData.bloodPressure is DEF) SC: description is DEF
SC: description is DEF
Obtain Obtain Add
Physical Medical Prescription
Data Data Medication
CT: Patient Data
CT: Patient Data SC:physicalCondition is DEF
SC: (height is DEF) AND (weight is DEF) CT: Prescription Medication
AC: medicalPrescription is DEF
Measure CT: Patient Data SC: (prescriptionMedication is COMPLETELY DEF)
Blood SC: bloodPressure is DEF
Pressure
Fig. 3. Doctor Appointment Example - Goals Specification
Figure 3 presents the goal-based specification that adapts from [2] two kinds
of goals: achievement and maintain. Achievement goals are specified in a tree
and have activation conditions (AC), which should hold true to allow the goal to
4 Passinhas et al.
become active, and success conditions (SC), which define when a goal is achieved.
To achieve a goal it is also necessary that all its sub-goals have succeeded. Addi-
tionally, a goal has a context (CT) that represents the data model entity which
is the root of its condition’s evaluation. A maintain goal describes a data model
invariant.
The achievement goal Write Medical Report has the Medical Report en-
tity as context, and requires both an Episode instance and a value for the
patient’s blood pressure to become active. Upon the goal achievement, the
description attribute is defined. The maintain goal Heart Medication Re-
striction states that it is not possible to prescribe drugs that may adversely
impact the hearts of patients with heart problems.
When executing a workflow instance in the activity view end users can: (1)
execute an activity; or (2) skip the execution of an activity. In both situations
the process instance progresses according to the control-flow definition. If an
activity’s pre-condition does not hold when it is enabled according to the control-
flow specification, the end user can execute a pre-activity to satisfy the pre-
condition.
When executing a workflow instance in the goal view end users can: (1)
activate a goal; (2) achieve a goal; (3) skip a goal; (4) redo a goal; (5) disable a
goal’s activation condition; (6) disable a maintain goal; or (7) create a new goal.
When a goal becomes active, its sub-goals also become active. If a goal’s success
condition holds when it is activated, then it is immediately achieved. When a
goal is achieved, the activity view evaluates whether any of the enabled activities
can complete. The redo of a goal preserves the state: the same set of conditions
continue to hold.
2 Demo Script
In this section we describe the demo script and its objectives. For a screen-cast
please visit URL: http://www.youtube.com/watch?v=Anb4kuXtBgc. The tool
does not include a worklist manager that assigns workitems to users based on
their roles because it is not relevant for the blended workflow proof of concept.
Therefore in the demo the doctor is able to execute any workitem, either goal
or activity.
Second Opinion case
1. Start a Doctor Appointment process for Patient Davide Passinhas;
2. In the activity view, execute all activities until Doctor Appointment activity
is enabled;
3. An unexpected situation occurs: during the Doctor Appointment activity
the patient’s condition deteriorates, and the doctor decides to measure his
blood pressure again: (1) the doctor switches to the goal view, activates goal
Measure Blood Pressure and redoes it;
Supporting Blended Workflows 5
4. Due to this situation the doctor decides to seek a second opinion from a
colleague, so in the goal view she: (1) creates a new entity, Second Opinion,
defines a relationship with entity Medical Report, and then creates a new
goal, Second Opinion, which has a success condition requiring a Second
Opinion’s description attribute to be defined; (2) activates goal Write
Medical Report, which also activates goal Second Opinion; (3) goal Second
Opinion is enabled by the blended workflow engine; (4) goal Second Opinion
is achieved by the user; (5) goal Write Medical Report is enabled by the
blended workflow engine; and (6) goal Write Medical Report is achieved
by the user;
5. The doctor switches to the activity view and verifies that the Doctor Ap-
pointment activity is completed, and the Checkout activity is enabled for
execution;
6. The doctor decides to prescribe a medication. She switches again to the goal
view: (1) activates goals Write Medical Prescription and Add Prescrip-
tion Medication, with the latter being enabled by the blended workflow
engine; (2) achieves goal Add Prescription Medication; (3) activates new
goal Add Prescription Medication, and prescribes a medication that may
adversely impact on the heart; (4) tries to achieve goal Add Prescription
Medication with the prescribed medication, but receives an error message
because the maintain goal Heart Medication Restriction is violated; (5)
the doctor decides to take the responsibility to prescribe the drug anyway,
and so disables the maintain goal Heart Medication Restriction; and (6)
executes goal Add Prescription Medication;
7. The doctor switches to the activity view and executes the Checkout activity,
finishing the process.
Urgency case
1. Start a Doctor Appointment process for Patient David Martinho;
2. The Booking activity is executed and the reservedDate is set for 10 days
later;
3. Due to urgency of the patient’s condition, the patient requires an examina-
tion by the doctor before the reserveDate but the Checkin activity is not
enabled for execution;
4. The doctor switches to the goal view, activates the Checkin Patient goal
and overrides the goal’s activate condition, ’today == reserveDate’, so that
the goal can become enabled;
5. The doctor executes the Checkin Patient goal. The blended workflow en-
gine automatically completes the Checkin activity and enables activities
Collect Physical Data and Collect Medical Data;
6. In the activity view Collect Physical Data and Collect Medical Data
activities are skipped by the doctor, due to the urgency;
7. The doctor executes the pre-activity in the Doctor Appointment activity to
fill in the missing data, the blood pressure data, and continues execution.
6 Passinhas et al.
The current version of the tool is a second prototype that extends a first
prototype [3] implemented one year ago. It was implemented in JAVA using the
FénixFramework5 for the domain specification and persistency, Vaadin6 for the
user interfaces, and the YAWL [4] engine to execute the activity specification.
The code is publicly available in a GitHub repository7 .
3 Acknowledgement
The research was partially supported by the Portuguese Foundation for Science
and Technology, FCT-MCTES (INESC-ID multiannual funding) through the
PIDDAC Program funds.
References
1. Silva, A.R.: A blended workflow approach. In Daniel, F., Barkaoui, K., Dustdar, S.,
Aalst, W., Mylopoulos, J., Rosemann, M., Shaw, M.J., Szyperski, C., eds.: Business
Process Management Workshops. Volume 99 of Lecture Notes in Business Informa-
tion Processing., Springer (2012) 25–36
2. Van Lamsweerde, A.: Goal-oriented requirements engineering: A guided tour. In:
Proceedings of the Fifth IEEE International Symposium on Requirements Engineer-
ing. RE ’01, Washington, DC, USA, IEEE Computer Society (2001) 249–262
3. Pinto, B.O., Silva, A.R.: An architecture for a blended workflow engine. In Daniel,
F., Barkaoui, K., Dustdar, S., van der Aalst, W., Mylopoulos, J., Rosemann, M.,
Shaw, M.J., Szyperski, C., eds.: Business Process Management Workshops. Volume
100 of Lecture Notes in Business Information Processing., Springer (2012) 382–393
4. ter Hofstede, A.H.M., van der Aalst, W.M.P., Adams, M., Russell, N., eds.: Modern
Business Process Automation: YAWL and its Support Environment. Springer (2010)
5
https://fenix-ashes.ist.utl.pt/trac/fenix-framework
6
https://vaadin.com/home
7
https://github.com/socialsoftware/blended-workflow