Embed Size (px)
Citation preview
Blended Workflow: Organizational Perspective
Guilherme Filipe Pereira Querido Ramos
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisor: Prof. Antonio Manuel Ferreira Rito da Silva
Examination Committee
Chairperson: Prof. Jose Luıs Brinquete BorbinhaSupervisor: Prof. Antonio Manuel Ferreira Rito da Silva
Members of the Committee: Prof. Maria Dulce Pedroso Domingos
October 2018
Acknowledgments
I want start by thanking Professor Antonio Rito Silva for all of the guidance through the work on this
thesis and for having the patience to help me develop as a person and as a software engineer.
I want to thank my family, and in particular to my parents, that always made what was possible and
impossible to give me the opportunities and tools to help me pursue my dreams.
I would like to thank Lucia for always supporting me during my most difficult times during the times,
and to motivate me to make the best I could make. I would also like to thank my friends, for all of the
great times passed together and for all of the challenges that we passed together.
Abstract
Workflow systems allow the execution of a process specification with the intent of improving the process
efficiency. With the addition of a resource perspective to a workflow system, it is possible to customize
the workflow engine to the person that is executing the business process. In this dissertation, I enrich the
Blended Workflow with a resource perspective that allows the design and execution of activity and goal
specifications that comply to several resource assignments. Blended Workflow is a workflow system
that combines executions of both activity and goal specifications that are generated from a data model.
It is proposed a set of resource management languages for the Blended Workflow system which has
high expressiveness and preserves the consistency between the Blended Workflow models. It is also
shown how these languages are implemented and how does the execution engine supports the resource
perspective.
Keywords
Workflow system; Model generation; Resource management; Work assignment
iii
Resumo
Os sistemas de fluxo de trabalho permitem a execucao de especificacoes de processos de negocio,
com a intencao de melhorar a eficiencia destes processos. Com a adicao de uma perspectiva de
recursos a um sistema de fluxo de trabalho, e possıvel personalizar o sistema para cada pessoa que
execute o processo de negocio. Nesta dissertacao, eu vou enriquecer o sistema Blended Workflow com
uma perspetiva de recursos que permita o desenho e execucao de especificacoes de actividades e de
objectivos e que cumpra com as variadas atribuicoes de recursos. Blended Workflow e um sistema
de fluxo de trabalho que combina a execucao de modelos, de actividades e de objectivos, modelos
estes gerados a partir de um modelo de dados. E proposto um conjunto de linguagens de gestao de
recursos para o sistema do Blended Workflow que sao expressivas e que permitam a conservacao da
consistencia dos modelos do Blended Workflow. E tambem demonstrado de que maneira e que estas
linguagens sao implementadas e de que maneira e que o motor de execucao suporta a perspectiva de
recursos.
Palavras Chave
Sistema de fluxo de trabalho; Geracao de modelos; Gestao de recursos; Atribuicao de trabalho;
v
Contents
1 Introduction 1
1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Blended Workflow 3
2.1 Design time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Runtime execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Activity model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Goal model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Running example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 State of the Art 9
3.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Resource model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Work lists and Assignment of tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Allocation of tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Process’s involvement based assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Resource Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Specification and representation of resource management . . . . . . . . . . . . . . . . . . 16
3.7.1 BPEL4People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7.2 BPMN 2.0 - Resource extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7.3 RAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Proposed Approach 21
4.1 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Resource model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Resource Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Generation of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
vii
4.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Running example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Implementation 37
5.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Specification parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.2 Storing the resource perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Specification generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.4 Mutating the models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.1 Enabling a resource-enhanced execution . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.2 User authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.3 ExecutionResourceInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.4 Pending work item set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.5 Execute a work item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.6 History of work items executed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 Dashboard UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Proof of concept 63
7 Conclusion 65
7.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A Running Example 69
A.1 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Data Model: Resource assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.3 Resource Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.4 Resource Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B Spefication languages 79
B.1 Resources’ meta-model language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 RAL language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.3 BW language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
viii
C Xtext Grammars 87
C.1 Resources’ meta-model language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.2 Resources Rules language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ix
x
List of Figures
2.1 Relation between activity and goal views to the data repository . . . . . . . . . . . . . . . 4
2.2 Generation of Blended Workflow models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Doctor Appointment Example - Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Example of a RACI matrix that activities with organizational positions. Source: Wikipedia 14
4.1 Organizational model proposed by RAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Flow diagram between Blended Workflow models and operations that are available for
each model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Example of the initial generation of enriched activity and goal models . . . . . . . . . . . . 29
4.4 Doctor Appointment Example - Organizational structure . . . . . . . . . . . . . . . . . . . 33
4.5 Doctor Appointment Example - Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 Blended Workflow’s component-connector diagram . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Blended Workflow’s module diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Blended Workflow’s module uses diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Blended Workflow’s module diagram after the addition of the resource perspective . . . . 40
5.5 Sequence diagram for the save operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6 The different blocks present in the resource enhanced DSL . . . . . . . . . . . . . . . . . 44
5.7 Relationships between RALExpression and BW-Core classes . . . . . . . . . . . . . . . . 45
5.8 UML diagram for the Entity is Person relation . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9 Example of objects that fill the Entity Is Person relation . . . . . . . . . . . . . . . . . . . . 48
5.10 Activity diagram for a specification that contains an add sequence operaiton . . . . . . . . 50
5.11 SetOfRequiredResources UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.12 Pipe-and-filter pattern present in execution modules . . . . . . . . . . . . . . . . . . . . . 53
5.13 Authentication UI module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.14 Dashboard UI view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
xi
5.15 Goal view for the Doctor appointment specification. On the left, the view before the re-
source perspective, on the right the view after . . . . . . . . . . . . . . . . . . . . . . . . . 62
xii
List of Tables
3.1 Comparison between different specification languages regarding their features . . . . . . 20
4.1 Roles of each position in the Doctor Appointment’s resource model . . . . . . . . . . . . . 34
5.1 API’s endpoints to design the resource perspective . . . . . . . . . . . . . . . . . . . . . . 46
A.1 Assignments for each of the data fields in the doctor appointments running example . . . 72
xiii
xiv
Listings
4.1 Some examples of RAL expressions to be used in assignments . . . . . . . . . . . . . . . 24
4.2 RAL History-based expressions BNF Grammar . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Example of history-based assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 RAL Commonality-based expressions BNF Grammar . . . . . . . . . . . . . . . . . . . . 26
4.5 Example of commonality-based assignments . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Grammar rules for the assignment of RAL Expressions to data elements . . . . . . . . . . 27
4.7 Example of the resource rules block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Data entities has resource model persons . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Resource module - Spring application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Delete function for RALExpression class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Resource module - Spring application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.1 Doctor Appointment’s Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Doctor Appointment’s Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.3 Doctor Appointment’s Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.1 Resource Model BNF Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 RAL Expressions BNF Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.3 BW BNF Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
C.1 Resource Model xText notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.2 Resource Rules xText notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
xv
xvi
Acronyms
API Application Program Interface
AST Abstract-Syntax Tree
BW Blended Workflow
BPMN Business Process Modeling Notation
DSL Domain Specific Languagess
DTO Domain Transfer Object
JWT JSON Web Tokens
RAL Resource Allocation Language
WES Workflow Enactment Service
xvii
xviii
1Introduction
Nowadays, many business processes are translated into an activity workflow in order to improve
it’s efficiency and interoperability with other processes. However, as time passes by and processes
become more complex, they also require more flexibility and swiftness in responding to deviations from
the standardized process. This means that we can no longer fully represent a business process in an
activity model.
To solve this problem, the Blended Workflow system was presented. This system provides end
users with a workflow engine that allows the execution of workflow models. It is possible to execute
a workflow using two views, activity and goal-based. It allows them to execute either according to the
standard behavior, provided by the activity model, or to deviate from it, depending of the variations on the
execution context, provided by the goal model. The system consistently manages both views, enabling
the user to switch the view they are executing accordingly while the work already done is preserved.
The generation of these views is based on an initial data model provided to the system, from which the
activity and goal models are generated.
During this thesis, I intend to enrich the Blended Workflow system with a resource management
perspective that allows the specification of execution constraints based on the organizational structure
1
of the process. The final result should be a design and an execution environments for the Blended
Workflow which consistently deals with the resource management aspect, and where can, eventually,
be efficiency gains during execution, due to the additional information that is contained in the enriched
model.
1.1 Objectives
The objective is to enrich the Blended Workflow with rich resource assignments in order to better
represent a real business process that delegates each of it’s parts to the resources involved. Firstly, it is
necessary to enable the specification of a resource model. The resource model represents the organi-
zational structure of an organization. The Blended Workflow data models must then contain information
about the resource assignments in design time. The Blended Workflow (BW) engine must then enforce
this assignments upon the generated activity and goal model, and guarantee the operations made in the
activity and goal model maintain the resource assignments consistency.
1.2 Document Structure
This thesis is is organized as follows: Chapter 1 introduces the general problematic and the main
objectives that are ought to be achieved during the thesis. Chapter 2 provides a short description of the
Blended Workflow and introduces the running example that will be used thought the thesis to introduce
the concepts presented. In Chapter 3 presents the related work regarding resource management and
how workflow systems usually tackle the problem. Chapter 4 proposes an approach to implement the
concepts presented in the related work in the BW system. Chapter 5 walks though the implementation
that was made in order to implement the solution proposed in Chapter 4. Chapter 6 evaluates the current
system according to the parameters defined in the thesis project. Finally, the Chapter 7 concludes the
thesis and proposes the following areas of research.
2
2Blended Workflow
In this chapter I present what the Blended Workflow is, how it is organised, and what is the function-
ality that it provides. I also explain in detail the different data, activity and goal models that allow the
system to provide it’s functionality. Finally, I present an example that will be used throughout the thesis
to better explain the concepts introduced in this thesis.
Blended Workflow is a workflow system that allows the execution of business processes using two
different views, activity-based and goal-based views, both based on the same data model. This system
aims to empower end users actions by allowing them to choose which view of the process they will follow
at a given moment based on the circumstances of the execution. This allows them to better respond to
unexpected situations that are not explicitly defined.
The two views that the system provides are based on two equivalent specifications for the business
process that are derived from a data model provided to the system. [1] Both views represent the user’s
current state of the workflow and allow the users to switch between them, while maintaining the state of
the workflow instance. The activity specification follows a Business Process Modeling Notation (BPMN)-
like specification but enriched with PRE and POST conditions. These conditions define what the data
model state be immediately before and after the execution of an activity. The goals specification is
3
organized in a tree that represents each goal’s dependencies. A goal is achieved when all of its sub-
goals are achieved together with its success condition. Goals have an activation condition, ACT, that
needs to be true before the goal can be achieved, an invariant condition, INV, that represents a condition
that must hold in order for the goal to be achieved and a success condition, SUC, that represents the
state changes produced by the goal. [1] Figure 2.1 shows how these models are related to the data
model.
Figure 2.1: Relation between activity and goal views to the data repository
The transformation of the data model into the two specifications that support activity and goal views
is done through a set of semi-automatic steps. Some are fully automatic, while other are human trig-
gered. Nevertheless, all steps preserve the models consistency. There is a Condition Model [1] that is
automatically generated and mediates between the data model and the final specifications. This model
describes the conditions that need to hold when the data model contains all the required data. This
model is used to understand what conditions the specifications must maintain in order to keep the in-
tegrity between the two models, and it is actually used as the basis of two automatic transformations
that generate the activity and goal models. After the models are generated, the designers can apply
transformations both in the activity and goal model, by composing and decomposing elements of the
model. This is an important feature because it helps the designers adjust the models to the desirable
kind of interaction.
Enabling the switch between the two different views means that the activity and goal views need to
be consistent in the initial state and during the execution of the workflow.
4
The system also contains a model verifier, implemented in Alloy, which is intended to prove the
correctness of the models generated by the the Blended Workflow and study some of its properties.
2.1 Design time
Throughout the thesis there will be two phases of the Blended Workflow execution that will be ref-
erenced. The first of them is the design time phase. It is in this phase that the Blended Workflow is
prepared for the execution of a workflow. It starts with the creation of a data model that holds all of
the information that is used and necessary thought the workflow. The data model, written in a Blended
Workflow Domain Specific Languagess (DSL), is then parsed and stored in the system. It then generates
a condition model, and the respectively activity and goal models. (Figure 2.2)
Figure 2.2: Generation of Blended Workflow models
After each model is generated and stored, the system also allows transformations to be made to
each model in order to refine each specification. This flexibility provided by the system may hinder the
consistency of the two models. Therefore, it is necessary to do a semantical check for these operations
in order to guarantee that even after the transformations, the activity and goal views remain consistent
regarding the data model.
2.2 Runtime execution
The BW engine provides a runtime execution environment in which we can execute instances of a
specification. For each specification, we are allow to create multiple workflow instances. Each workflow
instance represents an execution of a specification. In the context of a workflow instance the execution
can occur through the activity and goal views. The system allows the user to switch between the two dif-
ferent views during the execution of a workflow. This is possible because, at all times, both specifications
are synchronized regarding which data fields have been executed.
It is also during this phase, that we execute activities and goals that will fulfill the data model, and by
the end, represent a successful business process execution regardless of which view was used.
5
2.3 Data model
The data model is the base of a specification. It describes how the information is structured and
how it relates to the rest of the process. The model is similar to a Entity-Association model. The main
components are the Entity, the Attribute and the Association. An Entity represents a ”thing” which can
be distinctly identified [2], such as a car, a person, a phone, etc. An Attribute is a characteristic of a
entity. A car can have as attributes a name, a color, a type of engine, for example. An Association is a
relationship between two entities, such as Car to a owner (Person).
Since this is the model that contains all of the data of a specification, it is the base for the activity and
goal models and is the reason why the activity specification can be synchronized with the goal specifica-
tion. Each activity and goal from each model is mapped to a number of data products (entities, attributes
and associations). During execution, both models consult the data model to see which data products
have been fulfilled, and consider the respective activities and goal to execute in order to produce the
data necessary to finish the business process.
2.4 Activity model
As specified earlier, the activity model is described using the BPMN-like notation enriched PRE
and POST conditions. [1] The PRE condition represents the data that is required by an activity to be
executed. The POST condition represents the state of the data after the activity’s execution. [3] In
the activity view end users can execute activities. An activity is available to execution when its PRE
conditions are valid within the current workflow instance. [4]
There are five operations that are allowed to be made on the activity model during design phase
and they are: (i) Rename activity, (ii) merge activity, (iii) split activity, (iv) add sequence and (iv) remove
sequence. Rename activity changes the name of the activity. Merge activity merges two activities. Split
activity allows the user to split an activity into two activities by splitting it post condition. Add sequence
adds a new restriction to the workflow control flow that enforces a sequencing between activities that did
nor existed before.. Remove sequence allows the user to remove a restriction that has been added by
the add sequence operation. These operations, to occur, have to preserve the model consistency.
2.5 Goal model
Goals represent what the end user attempts to accomplish with the process and they are represented
in a tree of dependencies. Each goal contains: (i) a success achieve condition, SUC, which is the
product of the goal; (ii) an activation condition, ACT, which must be true in order to execute the goal; (iii)
6
an invariant condition, INV, which represents a condition that must remain true before, while and after
the execution of the goal.
There are two types of goals: produce and association. Produce goals are the goals that create
entities or attribute. Association goals are the ones that make the different associations present in the
data model between activities.
Similarly to the activity model, there are 3 operations that can be made to the goal model during
design time and they are: (i) Rename goal, (ii) merge goal and (iii) split goal. Rename goal changes the
goal’s name. Merge goal merges two goals into a single one if the constraints given by the data model
remain valid. Split goal splits a goal that has been previously been merged by the merge goal operation
while verifying the consistency of the resulting model.
2.6 Running example
During this thesis, I will base my explanations using a Use Case to better explain the Blended Work-
flow concepts and how the resource management improvements are implemented. The Use Case
describes a typical doctor appointment process and is described in more detail in [4]. To support the
resource management I had to add the Doctor entity that represents the doctor that handles the patient’s
appointment.
Figure 2.3: Doctor Appointment Example - Data Model
The Figure 2.3 contains the Data Model that represents the information needed in a doctor’s appoint-
ment and is the base of the whole example. This data model is translated into the BW DSL for the data
7
model in Appendix A.1.
This use case was chosen mainly for two reasons: the first is that it is a business process that can
require and benefit from the deviation of a standard specification, hence it’s usage on other Blended
Workflow papers; the second reason is that it is a process that rely heavily of an organizational struc-
ture, therefore being a good example on to experiment the resource management concepts that will be
presented shortly.
The Blended Workflow will, for this example, generate a simplified activity and goal model, i.e, a
model that contain an activity or goal for each of the entity and attribute present in the data model.
8
3State of the Art
Before I start describing how the Blended Workflow system will be altered in order to enable a
organizational perspective, I will first explore what is resource management in general and how it is
connected to workflow models. I will also describe how current workflow systems integrate resource
management and formal languages that allow the specification of these models.
Muehlen, Russel et al., Cabanillas et al. work on this area were very important to the definition of this
section. Muehlen’s research allowed me to have a global understanding of how a resource perspective
is structured and how it is implemented in workflow systems. Russel et al. work was very important to
define objectives that a resource perspective should achieve in order to successfully represent business
processes. Finally, Cabanillas et al. research was the base of all of the concepts introduced to the
Blended Workflow resource perspective.
3.1 Basic Concepts
In resource management, there are several concepts that are important to understand before we start
diving into the underlying architectures that usually take place in workflow systems. These concepts,
9
based on Muehlen’s work [5], will also be used through out the thesis to describe the solution to the
Blended Workflow.
Resource - (or process participant) is an entity that contributes to the execution of business goals and
activities, usually having activities assigned to it.
Internal resource - resource that belongs to the organization and that the workflow system has access
to.
External resource - resource that although takes part in activities of the organizations activities/goals
it does not belong to it. (Outsourcing etc)
Resource Model - models the resources that contribute to the execution of the workflow model.
Process Model - is a formal description of what a process is, what it produces and how it behaves and
relates with other processes.
Enterprise Architecture is an architectural description of the enterprise as a whole regarding its re-
sources, business processes and goals, hardware, communications etc. It helps the enterprise to
analyze, design, plan and implement all of its structure regarding efficiency and effectiveness.
Workflow - (or workflow model) is a detailed specification of a process model that is able to be executed
by a workflow management system. It is composed by several tasks that are connected in a graph
that represent its dependencies. [6]
Workflow Management System - provides a infrastructure for the set-up, execution and analysis of the
performance of a workflow.
Enterprise-driven resource modeling is the technique in which we model the Resource Model con-
forming to the Enterprise architecture. In spite of the fact that usually a Enterprise architecture
is not directly translatable to a Activity workflow, a mapping between the two models is usually
performed.
Workflow-driven resource modeling - is the method in which we model the resource model around
our workflow definition, i.e, it is our activities and how they are organized, that we determine how
resources should be organized.
Role - link between the resource model and the process model. From the point of view of the resource
model, a role represents both the capabilities and privileges that a resource has. From the process
model, a role represents the capabilities and privileges necessary in order to execute a certain
activity.
10
Capability - propriety of the resource that describe actions that the resource can do regardless of its
position. For example, John has a capability that is speaking 5 different languages. This capability
is not dependent of its organization position neither is it granted by the organization.
Privilege - propriety of the organizational position that is trickled down to the resources that belong
to it. All of the resources from a organization position inherit it’s privileges. Resources only hold
privileges for as long as they belong to a certain position. For example, John is an Accountant in
company A. Every Accountant has the permission (a.k.a privilege) to deposit or withdraw money
from the company’s A bank account. Therefore, John also has the privilege to manage company’s
A bank account. However, if John moves to another position, he will lose this privilege. (but be
granted another)
Task duty - type of involvement from a resource to an activity. Usually, task duty represents the different
roles in a RASCI table.
Organizational Position - function that a employee has within a organization. It gives the employee
some roles and demands the responsibility of achieving the positions goals by the employee.
Organizational Unit - aggregate of multiple organization positions in a logical way as in a practical
way in order to improve communication and efficiency between positions. Organizational Unit
members work together towards a common goal of the various positions. They are permanent
groups of human resources
Organization Team - similar to Organizational Unit, differing only in its duration, i.e, they are temporary
and have a limited existence.
3.2 Resource model
The resource model is a fundamental part of any workflow system that integrates resource manage-
ment. It is where the information about resources, their roles, responsibilities, how they are structured
and related with each other is stored.
A resource can be classified into 2 groups: human or non-human. [6] It is important to make a
distinction between the two groups because the different relations that each type of resource has to the
business and to a process model. Human resources take work items from the activities where non-
human resources may only be a restriction for the execution of an activity, e.g., the activity ’Operate the
patient’ needs a room in order to be executed. Resources also have a schedule and a history associated
with them. A schedule is a list of work items that a resource is planned on doing at some point in the
future. A history is a list of work items that the resource has successfully completed. [6]
11
A human resource is typically a member of the organization and has a specific position which gives
him roles. They can be a member of one or more organizational units, or one or more organizational
teams. Human resources also have relationships with other resources, that represent the organizational
hierarchy. A direct report is the resource to which the resource reports. A subordinate are resources of
which the resource is responsible for and to whom they report. [6] They can also have capabilities which
are useful upon the optimization of assignments of tasks to them.
Non-human resources can be of two types: (i) durable or (ii) consumable. [6] Durable resources can
take any amount of work without affecting the amount of work that the resource can take. On the other
hand, a consumable resource is a resource that is partially of fully consumed upon the completion of a
work item. They also have associated with them a rate of consumption or capacity that indicates how
much work they can make before they are consumed.
It is also important that the resource model is flexible and mutable due to the changing nature of
how a organization is structured in terms of positions and units and to the change in roles of the em-
ployees. [5] Therefore, if this feature has to be supported, the must be an engine should be responsible
to communicate with the resource model (usually the workflow enactment service) to trigger operations
to mutate the resource model. Operations like add or remove employees, changing a employee po-
sition (promote, demote, transfer), update capabilities from employees, add or remove privileges from
organization positions, create or remove organizational units/positions are mandatory for a system that
proposes to manage the organization resources.
An interesting question that is often asked when integrating a resource model into a workflow system
is: Should we use a single model for both workflow data as well as resource data? Muehlen [5] suggests
that both views should remain separate and be evolved on their own, since each of the models evolves
at their own pace. It also enables the designers to model both models independent of changes from
each other, resulting in a model that is more robust. [5]
3.3 Work lists and Assignment of tasks
Nowadays, we see more and more the usage of todo-lists as tool used by the employees to organize
themselves in which tasks they have to do and when. We also see tools that integrate this concept of a
todo-list to a shared environment like Asana, Trello or GetFlow.
Having resource management integrated with a workflow system enables the possibility to elevate
this concept one step further. Due to having information about what our resources are, what activities the
workflow has, and which resource is assigned to which activity, we can automatically extract information
about an employee work list, generate shared work lists for groups of employees that need to handle
activities together.
12
The assignment of tasks is made at design-time and define the conditions that the resources must
fulfill in order to become candidates to perform a work item. Therefore, this specification at design-
time must be integrated with the specification of the business process. Various alternatives for this
specification are presented in section 3.7.
3.4 Allocation of tasks
The allocation of tasks differs from the assignment of tasks regarding when they are made. The
assignment of tasks is a choice that is made at design-time in which a resource or group of resources
are given the responsibility for a particular workflow task. In the allocation of tasks it is chosen what
particular resource is going to be responsible for a particular workflow task during run-time. In other
words, during the assignment of tasks, we say which resources can be select to be responsible for
a task, whereas in the allocation of tasks we effectively select which particular resource executes a
particular work item.
Depending on what information the system has, it may be also possible to automatically allocate
tasks to employees depending on their experience (how many activities of that type the employee has
done), on their work list (give tasks to employees that have less work items allocated) and on their
capabilities. It may be also possible to coordinate tasks so that information from activity to activity flows
smoothly and a resource does not have to stop its work because it is waiting for information from another
resource.
There are several ways to approach the allocation of work items. This is usually done by the Workflow
Enactment Service (WES) at run-time and work items are either pushed, pulled or allocated using a
combined strategy. [5] Using the push strategy, the resources signal their availability to the WES which
then chooses a resource from a list of resources available to perform a certain activity. Alternatively, in
the pull strategy the resource chooses which task he should execute next. It is also possible to have a
combined strategy, where the WES pushes multiple tasks to the employee but the order at when they
are executed is left to the resource.
3.5 Process’s involvement based assignments
It is also possible to have different degrees of involvement to a process’s task. RACI matrices (Figure
3.1) allows the specification of different responsibilities in a process for the various members of an
organization. [7] They provide a way to plan, organize and coordinate work between resources, while
giving resources different degrees of responsibilities in a task.
RACI matrices associate tasks with resources. This association can vary in scope and tasks can
13
Figure 3.1: Example of a RACI matrix that activities with organizational positions. Source: Wikipedia
either be associated with persons, roles, organizational positions or organizational units. Each cell of
the table contains zero or more RACI initials. There are four different functions that a resource can have
on a task in RACI tables:
Responsible (R) is the person who must perform the work. He is responsible for the activity until the
work is finished. His work is approved by an accountable.
Accountable (A) is the person who must approve the work made by a person responsible for a given
task. This person takes responsibility of the task’s work after it’s approval.
Consulted (C) is a person whose opinion is requested by the person responsible for the task.
Informed (I) is a person who is kept up-to-date about the progress of a task.
There are also variants of RACI tables where more functions are added. In particular, RASCI tables
are particularly interesting to IT organizations, because they provide the function Support (S). People
with the function S are people that may assist in the completion of the given task.
3.6 Resource Patterns
Russell et al identified in their paper [6] several resource patterns that usually appear on commercial
workflow systems. These patterns are divided into 7 categories: (i) Creation, (ii) Push, (iii) Pull, (iv)
Detour, (v) Auto-start, (vi) Visibility and (vii) Multiple resource patterns. Creation patterns focus on the
restrictions that happen at design time that restrict how a work item can be executed. Push patterns
describe situations where work items are proactively offered or allocated to resources. On the other
14
hand, Pull patterns specify the situations where the resource commits himself to the execution of a work
item after there has been a offer by the system. Detour patterns refer to situations where the normal
execution of a work item is interrupted by the system or by a resource. Auto-start patterns focus on
situations where the execution of a work item is triggered by an event of the system. Visibility patterns
describe the restrictions that resources are subject to when viewing work items. Lastly, Multiple resource
patterns focus on many-to-many relations between work items and resources.
Only the creation patterns are considered because the focus of the thesis is to define a resource
management language to be integrated in the Blended workflow Specifications. The creation patterns
are:
Direct Distribution - The allocation to individual resources is made at design-time.
Role-Based Distribution - Allocation of a work item to a specific role. This work item will then be made
available to every individual resource that has that role.
Deferred Distribution - Design-time specification that the resource assignment will be made at run-
time as part of the workflow.
Authorization - Specify the range of privileges that a resource must have to be allocated to a task.
Separation of Duties - Two tasks cannot be executed by the same resource in a given workflow in-
stance.
Case handling - allocation of various work items to the same resource in a given workflow instance.
Retain familiar - Allocation of the work item to a resource that previously executed another work item
of the same workflow instance.
Capability-based distribution - Allocation of a work item to a capability. This work item will then be
made available to every individual resource that has that capability.
History-based distribution - Allocation of the work item is based on the previous work performed by
the resources.
Organizational distribution - Allocation of a work item to a organizational position. This work item will
then be made available to every individual resource that has that position.
Automatic Execution - the work item is able to be executed with the intervention of a resource.
15
3.7 Specification and representation of resource management
An important piece of the architecture of workflow systems that offers resource managements is the
specification of resource assignments. I will present three languages that enable this specification and
make a comparison between them with the objective of choosing the best language to be used in the BW.
This comparison will evaluate whether the language supports each specific workflow pattern [6]. Each
pattern will be evaluated with not supported (-), semi-supported (+/-) or fully supported (+). Features
are the resource patterns [6] that are supported by the language. I will also divide this comparison in
two parts: the first, (i) resource model, in which I will evaluate the language regarding the specification
of the resource model and in the second part, (ii) assignment of tasks, where I will evaluate the mapping
between the resource model and the process model. (Table 3.1)
3.7.1 BPEL4People
BPEL4People is a BPEL extension that adds a resource perspective upon the BPEL language. BPEL
was one of the first standards adopted by the industry as a language and framework to execute business
processes based on web services. Two major omissions had been made upon the specification of
BPEL: (1) hierarchical form of business processes and (ii) human involvement in business processes.
[8] Two extensions were proposed to solve the problem that arose from the second omission: WS-
HumanTask and BPEL4People. They attempt to integrate a resource perspective into WS-BPEL 2.0,
which is an extension to BPEL that solves the lack of a hierarchical organizational structure. WS-
HumanTask was designed with the intent to provide a notation, an Application Program Interface (API),
a state diagram and a coordination protocol for the execution of human tasks. BPEL4People was an
increment to this proposal and its intent was to support many scenarios of business processes execution
that involved human interaction. WS-HumanTask provides: (i) various implementations of a task; (ii)
deadline management for tasks (each task can have a startDeadline and a completeDeadline); (iii) a
notification framework that informs various resources of the progress and events related to a task; (iv)
roles that are associated with a task, and are the requirements for the execution of that task; (v) data
fields in task instances.
Resources are identified in the scope of a BPEL process and can be assigned to a task either by
direct reference to its name or to the results of a query. For example, a task can be assigned to the
result of the query every resource with the role Administrate. Using these queries it is possible to
enable the Retain familiar and Separation of Duties resource patterns in our workflow system. [8] Due
to the resource model in BPEL4People being simplistic, it is not possible to reference Organizational
positions or units, neither have relationships between resources as delegates to or reports to. Is is
also not possible to have capabilities related to resources. This makes it difficult to have assignments
16
based on organizational structure and it is impossible based on resource’s capabilities. History-based
assignments are also difficult because it is only possible the reference the history of the work performed
by a resource within the scope of a process instance. The list of resource patterns that BPEL4People is
able to provide is summarized in Table 3.1 based on the work by Nick Russel [8].
The formal notation of this extension is specified using XML Schema 1.0 for the Data model schema
and XPath 1.0 for the queries to the resource model. It also uses WSDL 1.1 for the web service interface
definitions. [9]
3.7.2 BPMN 2.0 - Resource extension
BPMN 2.0 - Resource extension is an BPMN extension module that is aimed at supporting a resource
perspective into BPMN processes. The extension considers three important aspects related to resource
management that are defined for a process model: (i) resource structure, (ii) work distribution and (iii)
authorization. The resource structure focus on the specification and classification of our resources
towards building a resource model. The classification is divided into functional classification (e.g: roles)
and organizational classification (e.g: organizational positions, units). The work distribution aspect is
the work assigned to a specific resource for its execution. This is based on the assignment of roles to
resources that are later defined as a set of privileges that are needed for an execution of an activity.
The Authorization aspect defines the privileges the resources have regarding the execution of activities.
Privileges depend on the resource structure and grant resources the ability to execute a set o work items
provided by activities. The resource patterns that the extension implements are depicted in Table 3.1.
The WorkDistribution extension extends the BPMN element UserTask to represent a single unit of
work that is performed by the person when executing an activity. This aspect also involves the re-
sourceResolution extension, which describes the information that is needed the engine during the alo-
cation of activities to resources, the resolutionConstraint extension, which limits the size of the set of
resources that results from the resourceResolution extension, the distributionAgent extension, that indi-
cates how is the work distributed, the role extension, which assigns roles to resources, and finally the
taskPrivilege extension that expresses the concepts of the authorization aspect.
This BPMN 2.0 extension also provides a graphical notation for the resource perspective. It both
offers a notation for the resource model itself and a modification to the graphical notation of a business
process provided by BPMN, including the WorkDistribution extension.
3.7.3 RAL
Resource Allocation Language (RAL) [10] is a language designed to formally specify the resource
assignments in a process model while offering a graphical notation (RALph). RAL was designed from
17
the beginning to integrate the specification of a workflow model and a resource model. It allows us to
connect these 2 models in an expressive and independent way, enabling the specification and automatic
verification of resource assignments. [11] It is a modular language divided into 4 modules each one sup-
porting a specific type of assignments. RAL is a language that is used as link between the Organization
Model and the Business process, and comprises RAL Core, a common set of RAL constructs that is
responsible for this connection. This module was designed to cover a subset of the Workflow Resource
Patterns [6] and comprises of the following expressions:
ANYONE - selects any person.
IS PersonConstraint - selects people that meet the PersonConstraint criteria. Example: Jack is re-
sponsible to insert water into the coffee machine - IS Jack.
NOT (Expr) - negates the expression. Example: Everyone but Jack is responsible to buy coffee - NOT
(IS Jack).
(Expr) OR (Expr) | (Expr) AND (Expr) - combines multiple expressions using the login in AND and OR
operators. Example: Either Jack or Lisa must clean the coffee machine every morning - (IS Jack)
OR (IS Lisa).
RAL Org is an extension to RAL Core with expressions and constraints that allow for the representa-
tion of allocations based on organizational structures.
HAS (PositionConstraint | UnitConstraint | RoleConstraint [IN UnitConstraint]) - selects any per-
son that complies to the position’s,unit’s or role constraints. Optionally, the role can be constrained
to a Unit. Example: An Office Clerk in the Marketing unit is responsible for all the printed material
- HAS OfficeClerk IN Marketing.
HAS CAPABILITY CapabilityConstraint - selects resources based on their capabilities.
[DIRECTLY] REPORTS TO PositionRef | IS [DIRECTLY] REPORTED BY PositionRef - selects re-
source based on their hierarchical dependencies. Example - Everyone that reports to a Manager
make a daily report about their work - DIRECTLY REPORTS TO Manager.
CAN DELEGATE WORK TO PositionRef |CAN HAVE WORK DELEGATED BY PositionRef - selects
resources based of the relationship DelegatesWorkTo
SHARES Amount (POSITION | UNIT | ROLE [IN UnitConstraint]) WITH PersonConstraint - selects
resources that share some organizational relation with another resource. Example: Everyone that
shares the same unit with Jack drink coffee everyday - SHARES ONE UNIT WITH Jack.
18
Finally, the module RAL AC (Access-Control) extends RAL Core in order to specify run-time con-
straints, therefore providing support to the following WRP patterns: Binding of Duties, Case Handling
and Retain Familiar. RAL AC also provides a solution to the specification of a task duty through the
following rule:
TaskDuty := responsible for | accountable for | providing support for | consultant of | informed about
The definition of what is a task duty is open to the organization. In this case, it was defined in order
to represent RASCI matrices. PersonConstraint is also extended with the following condition so that it is
possible to express that the person assigned must be the same related to another activity:
ANY PERSON TaskDuty ACTIVITY activityID - selects any person with a given task duty for the
given activityID. Example: The person responsible to buy coffee is also responsible to check if there is
any coffee left - IS ANY PERSON responsible for ACTIVITY BuyCoffee.
In terms of RALph, Resources are expressed as entities, and assignments are expressed via con-
nectors linking activities to resources. Activities can be connected to resources either by the resource
assignment connector or the hierarchy connector and to other activities using the history connector. A
resource can be of type: (i) person, (ii) role, (iii) organization position and (iv) organizational unit. There
is also a capability entity that refers to a particular skill that a person has.
The resource assignment connector specifies the responsibilities of resources (or capabilities) by
connecting them to activities. The hierarchy connector assign an activity to a supervisor or a subordinate
of a given organizational position, allowing for a hierarchical structure of the assignments. Finally there is
the history connector which assigns an activity to an actor (actors) that has taken part in another activity.
There are four kinds of history connectors: the activity referenced represents an activity instance (i) in the
context of the same process instance, (ii) the same or any previous process instance, (iii) any previous
process instance, or (iv) any process instance that was executed in a specified period of time. [11]
3.8 Comparison
All the languages presented above were either designed or analyzed [8] based on the work on
workflow resource patterns [6], which allows us to make a direct comparison between them on whether
they support a specific pattern or not.
The fundamental difference that exists between BPEL4People and BPMN 2.0 Resource Extension
to RAL is that RAL was designed from scratch whereas the other two are extensions on an already
existing workflow language, WS-BPEL and BPMN 2.0 respectively. This means that the textual and
graphical notations of BPEL4People and BPMN 2.0 Resource Extension have to comply with the rules
19
Table 3.1: Comparison between different specification languages regarding their features
BPEL4People BPMN 2.0 Extension RALDirect Distribution + + +Role-Based Distribution + + +Deferred Distribution + + +Authorization + / - + -Separation of Duties + + +Case handling - - +Retain familiar + + +Capability-based distribution - + +History-based distribution + / - - -Organizational distribution + / - + +
that each language has in order to be considered a native extension to language, leading into difficulties
when integrating said extensions into other workflow systems. The textual notation of BPEL4People is
made using XML Schema due to compliance with the language that it extends. BPMN 2.0 Resource
extension shares the same problem. RAL presents a much simpler notation because it is not tied to
a specific workflow language and allows itself to be integrated with any workflow language with ease.
Graphical notations are rich in every language with each one taking use of the graphical capabilities
of their ”parents”. RAL uses RALph [11] which is a new notation based on RAL with the intent to be
integrated with other notations like BPMN adding the resource perspective.
In terms of resource patterns supported, BPMN 2.0 Extension and RAL perform equally with both of
them supporting 8 patterns. BPEL4People fully supports 5 patterns and provides a soft implementation
for 3 patterns. Each creation pattern is compared to each language in Table 3.1 and each pattern is
explained in detail in section 3.6.
Both BPEL4People and BPMN 2.0 - Resource Extension offer a formal notation for the resource
model to be used in the assignments. This is possible because they already have a language, from their
parent languages, in which they can formally specify the model. On the other hand, RAL only provides
a description of a meta model for the resource model, and doesn’t delve into a formal notation.
20
4Proposed Approach
In this chapter I explain how I intent to implement the concepts of resource management presented
in Chapter 3 of this thesis. It is divided into 4 sections that represent the different phases of the Blended
Workflow: Section 3.7 explains the specification of models and section 4.2 shows how the models are
generated after it’s specification. Section 4.3 explores how the operations that are made to the models
need to change and section 4.4 details the new execution model for the Blended Workflow. Finally, the
section 4.5 expands the running example in order to contain a resource perspective.
Most of the concepts presented in the related work are applied to an activity-based workflow. How-
ever, in the context of the Blended Workflow, it is necessary to apply these concepts to the various
models. Firstly to the data model, which is used to generate the activity-based and goal-based specifi-
cations. Secondly to the condition model, which is an intermediate model where all the model constraints
are explicitly represented to serve as a common basis to the activity and goal models. Finally, to the
activity-based and goal-based specifications, which are the final models of the system.
All through this transformation process it is necessary to control the semantics that each model
contains. Lets first consider the Blended Workflow without resource management. For that, we have
that S(DM) is the set of instances that the BW can generate according to a particular model DM . For
21
the first models created by the BW engine, we have that S(DM)D = S(DM)A = S(DM)G. This is the
basic premise of the Blended Workflow: generation of equivalent activity and goal models from a data
model.
With the integration of resource management, we now have the cooperation of the data model and
the resource model to generate a set of BW instances. Let us name that set of instances S(DM +RM),
which represent not only the instances that where created, but also who create them. These instances
are equal to S(DM) with added resource assignments, meaning the instances in S(DM + RM) when
ignoring the resource management part, i.e., a projection to the initial BW model, are equivalent to
S(DM). Additionally, the objective is that we have instances that S(DM +RM)D = S(DM +RM)A =
S(DM + RM)G to maintain the basic premise of BW, which means that the same actors can create
the same instances in any of the models. However, there could be operations to the activity and goal
models that relax or restrict these models comparing to the data model. This creates situations where
S(DM + RM)A ⊆ S(DM + RM)D, or similarly, S(DM + RM)G ⊆ S(DM + RM)D if the operations
restricted the models. There could also be operations that relaxed both models. This would created
situations where S(DM + RM)A ⊇ S(DM + RM)D, or similarly, S(DM + RM)G ⊇ S(DM + RM)D.
I then need to understand the feasibility of operations that could restrict or relax the model. I must also
understand how does the current operations that the BlendedWorkflow supports affect the models, i.e,
if the operations generate an equivalent, relaxed or restricted model.
4.1 Specification
The first problem that surfaces while implementing the concepts presented in chapter 3 to the
Blended Workflow is the specification of the models. This is an integral part of the problem, because
it is with the specification of the data model that the BW models are generated. Therefore, the choice
of how to integrate the specification of the resource model and the resource assignments into the data
model is of major importance.
RAL was chosen to both to specify the resource model and for the resource assignments. I chose
RAL due to a number of reasons: (i) expressiveness - it is possible to represent most of the resource
creation patterns using the constructs provided by the language; (ii) independence - it is independent
from a workflow language and thus it can be integrated with the Blended Workflow Specification.
In spite of RAL being designed to be applied to activities, since the assignments and the concepts
presented in the RAL work [10] are loosely coupled to activities, they can be applied to other concepts.
In this work, it will be extended to the other models of the Blended Workflow, being applied to entities,
attributes, and relations from the data model, and to goals from the goal model.
RAL was designed to support most of the workflow resource patterns [6], although, the Case Han-
22
dling pattern is not supported by the Blended Workflow, because the concept of a case is not present in
the system. All the other workflow patterns are present in the BW and will be supported with this work’s
implementation of a resource management perspective.
4.1.1 Resource model
The resource model proposed for the BW Engine is based on the meta-model proposed by RAL (Fig.
4.1) and plays a integral part in the system. All of BW models are enriched with resource assignments
that will reference to the resource model. This resource model is specified by the designer and contains
all the information about the organizational structure and its entities that will later be used by the resource
assignments.
Figure 4.1: Organizational model proposed by RAL
There are five entities in this meta-model and are related to the concepts presented in section 3.1:
Person, Position, Role, Capability and OrganizationalUnit.
As stated in the section 3.7.3, RAL does not provide a formal specification language for the resource
meta-model. The language that allows this specification is proposed in this thesis and complies with the
meta-model used by RAL. (Fig. 4.1) The language is defined in BNF and its definition can be found in
Appendix B.1. The syntax follows a similar approach to the syntax used to describe BW’s data model.
4.1.2 Resource Assignments
The connection between each of the BW models and the resource model is made through the use
of RAL itself. The connection is made in the form of resource assignments using the RAL expression
23
language. In the data model, we have data elements that are assigned to the resources present in the
resource model. The situation is similar when we analyze the activity model and goal model. An activity
and a goal can also be assigned to a resource that complies with their respective data elements.
Since we ought to apply RAL to 3 different models, some adaptations have been made to the lan-
guage in order to remove the usage of activity as a language construct. Since the data model is the base
for both activity and goal models, the expressions now reference data elements rather than activities.
There are also some adaptations to RAL AC module that is responsible for the description of assign-
ments based on process involvement. Taking inspiration in RACI tables, I restricted the RAL AC module
to two types of assignments. A resource can either be responsible for or informed about a data element.
This distinction of assignment is important to express the different business functions resources can
take. A data element can have one resource responsible for it and multiple resources informed about
it. The resource that is responsible for the data element is the one that defines it. A resource that is
informed about the data element is notified upon the completion of it.
Listing 4.1: Some examples of RAL expressions to be used in assignments
1 IS John
2 HAS POSITION Receptionist
3 HAS ROLE CleanTrash IN UNIT ITDepartment
4 IS PERSON IN DATA FIELD Review.leader
5 IS ANY PERSON RESPONSIBLE FOR Report
The grammar that allows the specification of RAL is present in Appendix B.2 and it is written in
BNF. This grammar allows the specification of every RAL Module presented in section 3.7.3, as well as,
a new module created to support history-based assignments. This module adds three new grammar
rules, in listing 4.2, HistoryExpr, HistoryConstraint and Quantifier. HistoryExpr is a new RALExpression
and represents the syntax that enables history-based assignments. HistoryConstraint is the rule that
contains all the possible history-based constraints to assignments that are supported. Quantifier is a
simple rule that allow the quantification of constraints by LEAST or MOST.
24
Listing 4.2: RAL History-based expressions BNF Grammar
〈historyExpr〉 ::= ‘WITH’ 〈quantifier〉 ‘HISTORY ON’ 〈historyConstraint〉 ‘IN’ 〈dataObjId〉
〈historyConstraint〉 ::= ‘EXECUTION’ | ‘BEING INFORMED’
〈quantifier〉 ::= ‘LEAST’ | ‘MOST’
The following sentences are examples of how RAL Expressions would be written taking into consid-
eration the history expressions syntax:
Listing 4.3: Example of history-based assignments
1 ANYONE WITH LEAST HISTORY ON BEING INFORMED IN Report.description
2 ANYONE WITH MOST HISTORY ON EXECUTION IN Episode.height
3 ANYONE WITH MOST HISTORY ON BEING INFORMED IN Episode.doctor.person
4 ANYONE WITH LEAST HISTORY ON EXECUTION IN Prescription
The history-based constraints chosen to be implemented were execution and being informed. Ex-
ecution includes the definition of atributes and entities, as well as its associations. Being informed
represents a resource being informed of the execution of a given task, that a resource has the Informed
responsibility in the RACI table.
There is also a new type of assignment that is supported by RAL that is not stated in section 3.6
and it is based on commonality. This assignment takes a resource selected by a PersonConstraint and
selects another one based on some similarity to him, either by positions, roles or units. This similarity is
quantifiable by SOME similar resources or by ALL similar resources. The grammar rules that allow this
assignment pattern are the following:
25
Listing 4.4: RAL Commonality-based expressions BNF Grammar
〈commonalityExpr〉 ::= ‘SHARES’ 〈amount〉 〈commonRoleConst〉 ‘WITH’ 〈personConstraint〉
| ‘SHARES’ 〈amount〉 ‘ROLE’ [〈unitOptional〉] ‘WITH’ 〈personConstraint〉
〈commonRoleConst〉 ::= ‘POSITION’ | ‘UNIT’
〈amount〉 ::= ‘SOME’ | ‘ALL’
The following sentences are examples of how RAL Expressions would be written taking into consid-
eration the commonality expressions syntax:
Listing 4.5: Example of commonality-based assignments
1 ANYONE SHARES SOME POSITION WITH Jorge
2 ANYONE SHARES ALL ROLE WITH ANY PERSON RESPONSIBLE FOR Data.weight
The final step in the integration of resource management concepts to the specification of BW mod-
els is to specify how is the RAL language connected to the data model. There are two parts for the
increment that was made to the language. The first part are the rules that allows the expression of
the process involvement related to a RAL expression. For that, three new rules that were added to the
BW Specification Language (Appendix B.3) and they are ralConstraint, ralResponsible and ralInformed.
Both ralResponsible and ralInformed contain the language constructs that allow the specification of the
responsible for and informed about responsibilities, respectively. ralConstraint is the rule that contains all
of the supported RACI responsibilities. Note, although we have only considered two of the RACI respon-
sibilities, the language is open to other responsibilities because the rules that specify each responsibility
are separated in modules. The rules are presented in the listing 4.6.
The second part of the increment to the language addresses how it is applied to the Blended Work-
flow models. In order to build the resource assignments on top of the Blended Workflow models, I
decided to place the resource assignments in a separate block of a data model. All of the resource
rules are added in the ResourceRules block. This approach provides modularity to the specification of a
BW model as it separates the data specification from the resource assignments. To represent this new
language block, the following rules (listing 4.6) were added:
26
Listing 4.6: Grammar rules for the assignment of RAL Expressions to data elements
〈resourceRules〉 ::= 〈resourceRule〉 | 〈resourceRule〉 〈resourceRules〉
〈resourceRule〉 ::= 〈resourceAssign〉 | 〈entityIsPerson〉
〈entityIsPerson〉 ::= 〈identifier〉 ‘IS PERSON’
〈resourceAssign〉 ::= 〈identifier〉 〈ralConstraint〉
〈ralConstraint〉 ::= 〈ralResponsible〉 | 〈ralInformed〉
〈ralResponsible〉 ::= ‘has responsible’ 〈RALExpression〉
〈ralInformed〉 ::= ‘informs’ 〈RALExpression〉
As a short example, for the running example, the resource assignments for the creation of the Data
entity would be described as follows:
Listing 4.7: Example of the resource rules block
1 ResourceRules {
2 Data has responsible HAS ROLE ScreeningOfPatients IN UNIT OrthopedicUnit
3 Data.bloodPressure informs IS PERSON IN DATA FIELD Data.episode.doctor
4 }
Although not enforced by the grammar, it is only allowed to have both one rule of the types responsi-
ble and inform for each data element. This restriction will be placed in the semantical check that is done
to the data model by the engine. This decision was made in order to reduce the probability to errors
when writing the resource rules and improve its readability.
I also added a new type of resource rule beside resource assignment. The rule entityIsPerson allows
the association between the data model entities and resource model persons, i.e, entities that are both
data model entities and resource model persons. This is particular useful because, in many cases, there
are entities in the data model that represent a person and that same person is present in the resource
model. If we enable the connection through the data model and the resource model, we are able to make
assignments to tasks that depend on a person that is chosen at runtime. Consider an example that the
data model has two entities, TeamLeader and Employee, both representing persons in the resource
model. The connection between the data model and resource model can be described as follows in the
27
ResourceRules block:
Listing 4.8: Data entities has resource model persons
1 TeamLeader IS PERSON
2 Employee IS PERSON
4.2 Generation of models
The Blended Workflow models go through several stages of transformation during their lives. The
flow diagram between models is presented in Figure 4.2 and summarizes the transformation process
of the models. The first step (1) is to individually develop the data model and the resource model. It
is important to keep the development of these models separate in order to ensure the premise that the
data model works regardless of the resource model. [5] After the two models have been developed it is
necessary to join them together (2) to create a data model that is enriched with resource assignments
to resources in the resource model.
Figure 4.2: Flow diagram between Blended Workflow models and operations that are available for each model
The third step is the transformation of this model into the condition model that represents the work-
flow constraints that the data model implies. This generation is the same as it previously was done with
the BW without resource management. However, some resource assignments imply some workflow
constraints that must be taken care of. If we have a responsible for or informed about assignment of the
type deferred, it means that the assignment depends on another data element. An implicit dependsOn
28
constraint exists between these two data elements. The condition model generation must take into ac-
count the resource assignments for these types of constraints and add a dependsOn constraint between
them. The rest of the condition model generation proceeds normally as the other expressions do not
impact the workflow sequence.
With the condition model generated, it is now possible to generate both the activity model (4) and
the goal model (5) with the workflow constraints required by the data model. This generation must also
be updated to include the resource assignments and to preserve their constraints in both generated
models. This generation is nothing more that trickling down of the resource assignments that each data
element has to the respective activity and goal.
Figure 4.3: Example of the initial generation of enriched activity and goal models
We can consider this as a two-phased generation: the first phase is to generate the activity and goal
models regarding the workflow constraints; the second phase is to take each activity and goal and apply
to them the resource assignments that their work products (data elements that an activity or goal fulfills)
have. Since the BW Engine makes a one-to-one generation of data elements to activities and goals, i.e,
for each data element there is an equivalent activity or goal that only fulfills that data element. Because
of this, we guarantee that when we reapply to data element’s restrictions to the generated activities and
goals, we are preserving the semantics imposed by the data model. In Figure 4.3 you have an example
29
that illustrates the initial generation of activities and goals from the data models and the enrichment of
these models with the resource assignments.
Finally, the operations that are supported on both the activity model (6) and goal model (7) also
have new constraints that must be taken into account due to the addition of the resource assignments.
The generation of both the activity model (4) and the goal model (5) preserve the assignments in the
original data model. However, the operations to the generated models, can have a different effect on the
assignments: maintain, relax or restrict the models.
4.3 Operations
An important part of the solution are the operations that are made on goals and activities, on the goal
model and activity model, respectively. These operations allow the mutation of the workflow and must
be analyzed regarding the resource management. With the new resource assignments, it is necessary
to define what are the intended semantics of the operations, i.e, preserve, relax or strict the model.
To preserve the semantics, it is necessary that the model produced after the operation generates
the same instances that could be generated by the model before the operation. The relaxed semantic
tells us that the model produced by the operation generates a set of instances that is a superset of the
instances that the model before the operation could produce. Finally, the restricted semantic means that
the produced model generates a set of instance that is a subset of the instances the were previously
possible.
As a short example, consider the operation Merge Activity between two activities, Activity A1 and
Activity A2, that respectively require a resource with the role ManagePatientInformation and a resource
with the position Receptionist. If we merge these two activities, the resource assignment in the resulting
activity could be as follows: (i) it is not allowed since the activities have different resource assignments;
(ii) the resulting activity would allow either resource assignments to be true resulting in a relaxed model;
(iii) the resulting activity would require the resource to oblige to both assignments at the same time,
resulting in a restricted model.
There 8 different operations across all models that can be made. Two of them, rename activity and
rename goal, are neither workflow or resource related. Merge and split operations in either activity
and goal models are workflow related but impact the resource assignments, therefore having a different
behavior with the addition of the resource perspective. The remaining add/remove sequence operations,
only present in the Activity model, only impact the workflow model with the exception of the resource
assignments based on the task duty or the assignment deferral. For example, if the have an activity
named abc and the resource responsible for it’s execution is the one that is responsible for the activity
named ghi. Although the two activities might not directly connected, it is exists a dependency between
30
activity abc to activity ghi, i.e, activity abc cannot execute before activity ghi. Since these assignments
impact the workflow model, therefore the sequence’s operations must take these types of assignments
into account.
To the merge activity and goal operations, we must implement all of the semantics present above, i.e,
we allow the user to specify which policy we wants for a given merge operation. For the split operations,
a simplification is made. Since we can only split activities/goals that have been previously merged by
the merge operation, we can infer that the semantic we want to enforce is the same that was used in the
the merge operation. Therefore, this operation copies the assignments from the merged activity/goal to
the split activity/goal, enforcing the previously selected policy.
4.4 Execution
After each model has been successfully generated, the Blended Workflow engine provides an ex-
ecution interface in which it is possible to execute activities or goals for a given workflow instance.
Previously, this execution interface allowed the execution of every single item by anyone that had access
to the interface. With the addition of a resource perspective, two improvements must be made to the
interface and execution model: (i) User identification and (ii) Control access on activities and goals.
The user identification is the identification of the different users that use the execution interface. It
is necessary to identify each user because we will need to enforce each resource assignment constraint
to the respective activity and goal. There must be an entity in BW that represents an user and this
entity must be associated with the resource model. This entity is the User entity and it is an entity that
is related to the global scope of the BW. Each User is mapped to a person from the resource model.
The generation of Users is made upon designing a new specification: when a new person is created
for a given specification, it is also created a related user entity that is global to the BW engine. If two
specifications have two persons with the same name, then these persons share the same User entity
upon identification. This allows a User to be associated with multiple specifications and manage his
enrollment with each one using one unique User entity.
The control access on activities and goals is the semantical check that is made at runtime that
enforces the resource assignment constraints, that each activity and goal has, upon the user that is
identified and only allows the resources that make the RAL expression valid to execute the work item.
To help the evaluation of expressions, I define to functions that can be made to each RAL Expression:
1. ‘Get Eligible Resources’ tells us, for a given RAL expression, and for a given workflow history,
which persons in the resource model have the characteristics that validate the expression.
2. ‘Person is eligible’ evaluates if, for a given person and for a given workflow history, the person has
the characteristics that validate the RAL expression, therefore being eligible for the execution a
31
work item. This operations uses the ‘Get Eligible Resources’ to get all of the resources that are
eligible to execute and checks if the given person is one of them.
Using this two functions, the access control for executing an activity/goal goes as following: (i) a
user attempts to execute an activity/goal; (ii) the engine queries the expression if the person (related to
the User that is executing the engine) is eligible to execute; (iii) the expression gets the list of eligible
resources and sees if the person is one of them; (iv) if the expression validates the user, then the engine
proceeds with the execution of the activity/goal.
Another important piece of the execution of a specification, is how the user gets the activities and
goals to execute. As stated in section 3, there are several workflow patterns for this interaction that are
presented in Russell’s work [6]. In this thesis however, we don’t focus on implementing new ways for the
BW engine to distribute work, but rather enhance the current system’s distribution taking into account the
resource assignments. The BW engine distributes work using the pull strategy (section 3.4) by providing
a list of all the activities or goals, depending on the view, that can be executed by any resource. With
the addition of resource assignments, it no longer makes sense to present every single activity/goal that
is possible to be executed, but only the list of activities/goals that the resource is eligible to execute.
Therefore, the interface that provides the list of items to be executed must filter the items based on the
User that is querying the interface.
Finally, there is a new interaction in the execution interface that emerges with the addition of resource
management: informing a group of resources that a particular activity or goal has been executing. This
interactions intend to implement the ‘informed about’ responsibility presented previously. To support it,
the engine must only allow resources with this type of responsibility to have access to the history log of
work items executed in a workflow.
4.5 Running example
To better explain how the Blended Workflow will behave with the addition of resource management,
I extend the running example presented in section 2.6.
In this example, we only consider the organizational entities that are related to a doctor appointment.
There are Nurses and Doctors who directly report to the Unit Director. There is also the Administrative
Manager that is responsible to the Units administrative subdivision and reports to the Unit Director. The
Scheduling Administrative and the Receptionists report to the Administrative Manager. Finally, there
is the Unit Manager which is the person responsible for the whole unit. This organisational model is
represented in Figure 4.4.
Each position has one or more roles attributed to them. In this example, each position’s roles are
described in Table 4.1. The Unit Director and Administrative Manager have intersecting Roles, both
32
Figure 4.4: Doctor Appointment Example - Organizational structure
managing the work loads of their subordinates and reporting the current situation of their sub-units. The
Administrative Manager is also responsible for the management of unit patient’s information. Doctors
have roles that indicate their primary functions. Although not being their main roles, they can perform
the screening of patients as well as provide first aids to patients. Their primary role is to treat patients
and perform medical examinations. On the other hand, Nurses perform the Screening of patients and
the first aid as their primary activity in the organization. The only role of a Scheduling Administrative
is to Schedule Appointments for all of the patients of the hospital. The receptionist main role is to
welcome patients on the waiting room and receive the payments of the doctor appointments. They can
also schedule further appointments for the patient. Similarly to Administrative Manager, they can also
manage patient’s information.
Regarding the data model, I base the example’s data model, Figure 4.5, in the data model present
in the original example [4] for Blended Workflow. However, this new model is already enriched with a
resource management perspective. There is a new special type of entity, the Person type. This type
of entity was added to connect entities from the data model to the various persons that are present in
the resource model. In the example, both Patient and Doctor entities are of the type Person. This is
necessary in order to express the assignments that require the selection of entities that are determined
during runtime. The data model also has been enriched with resource assignments, as depicted in Table
A.1 on Appendix A.2. The assignments are divided into two categories: responsible for and informed
about. Responsible for are the resources that are allowed to execute the data element and informed
33
Table 4.1: Roles of each position in the Doctor Appointment’s resource model
Position Roles
Unit Director WorkLoadScheduler; UnitReporter
Administrative Manager WorkLoadScheduler; UnitAdministrativesReporter; ManagePati-entInformation
Doctor ScreeningOfPatients; FirstAids; TreatPatients; MedicalExamina-tor
Nurse ScreeningOfPatients; FirstAids
Scheduling Administrative ScheduleAppointments
Receptionist ScheduleAppointments; WelcomePatients; ManagePatientInfor-mation
about are the resources that are notified upon the execution of that data element.
The entity Patient has 3 attributes name, age and heart problems. The definition of attributes name
and age require the resources to have role ManagePatientInformation and being in the Orthopedic
Unit in order to be responsible for it. The attribute heartProblems demands a resource with the role
ScreeningOfPatients as well as being in the Orthopedic Unit. The creation of the entity Patient must be
made by a person with the position Administrative Manager.
The entity Doctor has e attributes, name and age. The definition of the entity as well as its attributes
require the position of Unit Director. It also informs every resource with the position Administrative
Manager of its creation.
The entity Episode, can be created by any resource that has the role ScheduleAppointments and
belongs to the Orthopedic Unit, has 4 attributes, number, reserveDate, checkIn, checkOut. It also has
the association ‘doctor’ with the entity Doctor. The attributes number and reserved must be executed
by any resource that has the role ScheduleAppointments and that belong to the Orthopedic Unit. The
attribute checkIn requires a resource that belongs to the position Receptionist. The execution of of the
attribute checkIn also informs all of the resources that have the role ScheduleAppointments and is in
the orthopedic unit. The attribute checkOut must also be performed by a resource that belongs to the
position Receptionist. The resources that have the position administrative Manager or that have the role
schedule appointments and are in the orthopedic unit are informed about the definition of the attribute.
The association doctor represents the doctor that is assigned to the patient by a Administrative Manager.
In each Episode there is an Entity associated named Data. Each of the fields as well as the cre-
ation of the Data entity require a resource with the role ScreeningOfPatients and that belongs to the
34
Figure 4.5: Doctor Appointment Example - Data Model
orthopedic unit in order to be executed. The doctor that was determined in the data element Re-
port.episode.doctor.person is informed about the execution of the data elements.
Each Episode also has a Report entity with a single attribute named description. Both of them,
must be created by the same person that belongs to the position Doctor. The doctor must be the
resource that was determined in association Episode.doctor.person. The resources that have the role
WorkLoadScheduler and belong to the orthopedic unit must be informed about the execution of both data
elements. The patient of the Episode that was determined in the association Episode.patient.person
must also be informed about the description of the Report.
Finally, an Episode can have a Prescription attached to it. This entity, as well as its attribute, must
be created by a resource that has the position Doctor as well as have the capability BelongsToDoctor-
sAssociation. The creation of the attribute description also informs all the resources that less frequently
created this entity and have the organizational position doctors. A Prescription is composed of several
Medication entities, that must be created by the same person that created its Prescription entity.
The example’s organization is composed of 10 people. John, George and Anna that have the Recep-
tionist organizational position. Angela is the Scheduling Administrative and Magnus is the Administrative
Manager. William and Luke are both Doctors. Luke also has the capability of belonging to the doctor’s
association. Carol and Mary are nurses and Helen is the unit directory of orthopedic unit.
35
Using this running example, we can apply the language to define the resource model of the hospital
organizational structure. The resource model is in Appendix A.3 and it is written in the language defined
in Appendix B.1.
To complete the specification of the running example’s model, in Appendix A.4, you can find the
ResourceRules language construct that implements the resource assignments proposed in the running
example.
With this specification, we are able to generate a workflow environment that represents both the
workflow of a doctor appointment as well as it’s resource assignments.
36
5Implementation
In the following chapter I present the implementation of the resource perspective in the Blended
Workflow. Firstly, in Section 5.1, I will describe the architecture of the system and list the changes that
need to be made in order to implement the resource perspective. In Section 5.2 are described the
changes made in the designer module of the system that allowed for the specification of the resource
model and rules. Section 5.3 describes the new module within the engine that provides an enhanced
engine for the design and execution of models. Finally in Section 5.4 I explain how all these changes
are presented to the user and what is the new flow of execution within the user interface.
5.1 Architecture
The system’s architecture, depicted in Figure 5.1, has the following structure: (i) designer component
- an Xtext project that parses the data model and calls the APIs on the BW engine to generate the
specification; (ii) engine component - a backend server that includes the verification of the correctness
of the specifications sent by the designer module and allows for the execution of Blended Workflow
instances. This engine is implemented in Java Spring and provides an API interface to design, access
37
and operate the models; (iii) frontend component - a Web Application made in React that implements
the human interface to access the BW Engine. This application accesses the BW Engine API in order
to display its information in HTML and CSS and performs operations on the models.
Figure 5.1: Blended Workflow’s component-connector diagram
We can also organize the Blended Workflow into a module architecture, as depicted in figure 5.2. This
view of the system gives us a notion of functional modules that exist despite its component organization.
It is composed of two parts: the engine and the designer. The engine modules contain the functionality
responsible for the allows the execution of the workflow. It includes an execution manager that keeps
track of specification instance’s data and its execution and a Engine UI module that implements the
execution of the models in the user interface. The designer module is responsible for the design of
specifications and includes the DSL Parser, the Design UI Module and the Models Manager. The DSL
Parser is responsible for parsing the BW DSL and interacts with the Models Manager module. The
Models Manager stores and enables operations on BW specifications. Finally, the Design UI Module is
the part of the user interface that allows the user access to the design operations that are allowed to be
made on the models.
Figure 5.2: Blended Workflow’s module diagram
The modules use each other in order to provide the Blended Workflow system (Figure 5.3). The
two fundamental modules are the Execution Manager and the Models Managers that provide the core
functionality of the system. All modules use the Models Manager since it provides the data about
38
the models in which the BW operates. The Engine UI Module also uses the Execution Manager that
provides the execution functionality to the interface.
Figure 5.3: Blended Workflow’s module uses diagram
To implement the resource perspective, the module architecture must be changed as follows: (i) the
DSL Parser should support the proposed resource language and RAL language as well as the resource
rules language constructs that provide the connection between the data model and the resource model;
(ii) Both Execution Manager and Models Manager must support resource management during the design
and execution of Blended Workflows respectively; (iii) update the user interface modules to provide
resource management in a meaningful way to the process workflow. With theses changes in mind, the
modules diagrams takes the structure presented in figure 5.4.
There are two new modules, Resource-enabled executor and Resource Models, that are responsible
for the execution of the models with the resource assignment’s restrictions and with the storage of the
resource models, respectively.
The Engine UI Module was separated in two modules that represent two ways of executing a work-
flow: (i) the Workflow UI Executor that provides the standard way of execution the workflow that is
implemented by the core project; (ii) the Dashboard UI Executor, that provides a view that is costumized
to the user executing the system and that shows every work item that the person has permission to
execute.
The DSL Parser module was separated into two different modules: the Core parser, which provides
the parsing for the data model DSL, and the Resource Parser, which implements the languages de-
scribed in the previous chapter, that enable the specification of a resource model and the resource
assignments.
Finally, there is the Authentication Manager module. This is a new module that provides the user
39
identification that is needed during the execution of the engine.
Figure 5.4: Blended Workflow’s module diagram after the addition of the resource perspective
Since this thesis is aimed at enriching the Blended Workflow with an optional resource perspective,
the first problem that was tackled was how to design an architecture in that each of the core modules, i.e,
the modules that handle the core functionality of the BW system, can be independent of the enrichment
done in the thesis.
With this in mind, the implementation of the resource perspective for the engine module depends on
the core module but it does not require the original module to depend on the new extension. Therefore,
the previous version is isolated in a spring project named bw-core that contains the core modules of
the system on top of which new extensions can be developed. The new extension is built on a new
spring project, bw-resources, that extends the bw-core. This means that the new spring app uses all of
the controllers and domain from the bw-core, which allowed me to add the resource perspective on a
separate module without losing or having to reprogram any of the functionality that has been previously
implemented. This is possible due to the @Import annotation that Spring-Framework provides, that
imports a Configuration class. Since we are importing the application class of the core module, it imports
every controller and class that the module contains.
Listing 5.1: Resource module - Spring application
1 @PropertySource({ "classpath:resources.properties" })
2 @Import(CoreApplication.class)
3 @SpringBootApplication
4 public class ResourcesApplication extends SpringBootServletInitializer {
5 @Override
6 protected SpringApplicationBuilder configure(SpringApplicationBuilder
40
application) {
7 return application.sources(ResourcesApplication.class);
8 }
9
10 public static void main(String[] args) {
11 SpringApplication.run(ResourcesApplication.class, args);
12 }
13
14 @Bean
15 public BCryptPasswordEncoder bCryptPasswordEncoder() {
16 return new BCryptPasswordEncoder(11);
17 }
18
19 @Bean
20 public ResourcesFactory modulesFactory() {
21 return new ResourcesFactory();
22 }
23 }
There are two classes, DesignInterface and ExecutionInterface, that are the interface to the Modules
Manager and Execution Manager modules, respectively. The Spring Controllers use these classes to
gain access to the domain and to perform the business logic. Since the bw-resources project imports
all of the controllers from the bw-core spring project, the only way to change the behaviour of controllers
that are implemented in the core module, is to change the Interface class. To reuse the controllers from
the bw-core project, a crucial change was made in the bw-core project: the instance creation of the
DesignInterface and ExecutionInterface classes is made through a factory instead of direct instiancia-
tion. The factory, ModulesFactory, allows the instantiation of the DesignInterface and ExecutionInterface
classes.
The ModulesFactory is a Spring Bean so that the instantiation of the factory is dependent of the
Spring project that is running. For the bw-core project, the Bean function modulesFactory() instantiates
a ModulesFactory class. For the bw-resources project, the Bean function modulesFactory() instantiates
the ResourcesFactory class, which is a subclass of ModulesFactory that instantiates the new Design-
ResourcesInterface and ExecutionResourcesInterface classes. Since DesignResourcesInterface and
ExecutionResourcesInterface are sub-classes of DesignInterface and ExecutionInterface respectively,
polymorphism is applied and the core controllers use the new interfaces instead of the old ones. The
new classes implement the new resource models manager and change the behaviour of the execution
manager.
41
In the Xtext project the choice was to maintain both the core functionality and the resource perspec-
tive in the same project. This decision was made in order to facilitate the writing of specifications, since
the Xtext Eclipse Plugin would be able to auto-suggest entities and attributes from the data model. Oth-
erwise, the writing of the specifications would have to be done in three different stages (data model,
resource model and resource assignments) instead of one. In spite of this, it is possible to execute the
designer without using the resource perspective.
5.2 Designer
The designer module comprises the Xtext project, the models manager and the designer UI module.
The Xtext project allows the design and specification of the data model language. Xtext is an Eclipse
GMT project that allows for the creation of textual DSL. [12] Based on an EBNF-like notation, Xtext is able
to provide an syntax-highlighted editor for the language and generate an Abstract-Syntax Tree (AST).
The models manager is the part of the design module that is responsible to take the information
provided by the parser, evaluate it and store it in the database. It is also responsible for the generation of
models and all of the operations that can be made on the models. These modules execute in the Spring
Engine component.
The UI module is responsible for the access to the operations that can be made to each model. It is
part of the unified interface that is built using React.Js.
The BW languages are denoted in the EBNF-like notation, and each specification is written using the
editor provided by Xtext. Upon each save operation in the specification file, the module uses the AST
to parse the specification, construct the respective Domain Transfer Object (DTO)s that represent the
data model and send the DTOs to the designer to store the specification. The designer API takes the
requests, evaluates them, and store them in the database. Upon request by the parser, it also generates
the condition, activity and goal models associated with the provided data model. When the engine is
executing, the UI module supports the operations that modify the goal and activity models, e.g., merge
operations.
Only two parts of the designer module were changed to support the resource perspective. The first
is the parsing of the specification, in which I had to enrich the BW language to include the languages
described in Appendix B.1 and Appendix B.2. The models manager was also updated so that it now
provides an API to persist resource entities as well as the generation of models. The operations were
also updated to take into account the resource assignments. The UI module remained unchanged
because it already provided access to the operations that were implemented on the generated model,
only throwing new error messages in case they are not allowed.
42
5.2.1 Specification parsing
As stated before, the first part of the designer module that had to be changed was the specification
parsing, in order to include the languages proposed in Chapter 4 and depicted in Appendix B.1 and
Appendix B.2.
These languages were translated to the EBNF-like notation supported by Xtext. In terms of grammar
structure, some changes were made in order to ease the AST parsing. The language, however, is typed
exactly as before. Although the languages are separated into parts, this separation was not translated
into different Xtext projects in order to simplify the Xtext component.
In listing C.1, from appendix C, we have the grammar rules that allow the specification of the Re-
sourceSpecification in general, which is an aggregate of several resource model entities and the re-
source model, and the specification of the resource model entities. In listing C.2, from appendix C we
have the grammar rules that allow the specification of the resource rules block, in which the designer
specifies the resource assignments for each data element.
Figure 5.5: Sequence diagram for the save operation
Figure 5.5 presents us the interaction that occurs between classes when a new specification is saved.
When the user saves the specification in the eclipse editor, it triggers the parsing of the AST and the
designer module starts to store the specification into the engine using the designer API. WriteBlended-
WorkflowService is the class responsible for writing a specification on the engine. The class is invoked
43
by the BlendedWorkflowValidator xtend class, which is the class that is triggered upon each save op-
eration. The WriteBlendedWorkflowService writes the specification in four phases. Firstly, it writes the
Data Model by sending each entity to the engine, thought the designer models manager API. Then, if
the parser finds an instance for the ResourceSpecification rule in the AST, it proceeds to write the re-
source model. Following the writing of the entities and resources present in the specification, the module
proceeds to prompt the models manager to check if the data model is consistent, as it has previously
done, and finally proceeds to generate the remaining models from the data model. The semantic check
for the data model as well as the generation of the activity and goal models did not suffered any change
since the addition of resource management didn’t add any changes to their algorithms. The final step
is to enrich the generated activity and goal models with the resource assignments present in the data
model. One key decision that was made was to separate the generation of the workflow models from the
resource models as much as possible. Due to this, the generation of the resource model is separated
from the generation of the data model and instead of changing the generation algorithms for the activity
and goal models, we apply a transformation to the successfully generated models.
Figure 5.6: The different blocks present in the resource enhanced DSL
The writing of the resource model consists in taking each entity parsed by Xtext, converting it into the
respective DTO and sending it into the engine’s designer API. The entities present in the resource model,
i.e, capabilities, roles, units, positions and persons, as well as each resource assignment are converted
to DTOs. Each resource assignment is written through a ResourceRuleDTO that contains: the data
elements that we are assigning, the task duty, and a RALExpressionDTO that contains the constraint of
the assignment. In order to better represent the RALExpressions, to better differentiate them, each type
44
of expression is a DTO that will ultimately have as super class the base RALExpressionDTO.
One important aspect to mention is that the same project works both for the standard workflow
generation and the resource perpective enhanced workflow. If the user wants to generate a standard
workflow, he must type a data model as he has previously done. If he wants a resource enhanced
workflow, all he must do is add the resource model specification as well as the resource assignments to
the language instance, and the parser automatically differentiates between the workflows. (Figure 5.6)
5.2.2 Storing the resource perspective
The models manager is responsible for storing all the resource perspective information, i.e, the
resource model, the resource assignments and the enhanced activity and goal models, into a persistent
source. This module executes in the engine component that is build using Spring and has as a persistent
source a database. The access to the database is made through the Fenix framework [13].
The module was changed in order to support the design of resource-perpective related entities. It
was added a total of 11 endpoints to it’s API, present in Table 5.1. Endpoints 1 and 2 create and clean
a resource model for a specification. This endpoints are called every time the parsed detects a new
version of a specification, and therefore needs to clean both the data model and resource model to
create new ones for the new version. Endpoints 3,4,5,6 and 8 create the entities and it’s attributes that
belong to the resource model.
To store the entities, it was necessary to create a new fenix framework DML that extends the previous
version and add entities for each of the elements of the resource model. It was also necessary to
represent the RAL Expression and the hierarchy that was used in the DTOs.
Figure 5.7: Relationships between RALExpression and BW-Core classes
45
Table 5.1: API’s endpoints to design the resource perspective
Method Endpoint Description
GET specs/{specId}/resourcemodel/clean 1 - Clean the specification’s resourcemodel
POST specs/{specId}/resourcemodel/ 2 - Create a new resource model
POST specs/{specId}/resourcemodel/capabilities 3 - Create a new capability in thespecification’s resource model
POST specs/{specId}/resourcemodel/roles 4 - Create a new role in the specifica-tion’s resource model
POST specs/{specId}/resourcemodel/units 5 - Create a new unit in the specifica-tion’s resource model
POST specs/{specId}/resourcemodel/positions 6 - Create a new position in the speci-fication’s resource model
POST specs/{specId}/resourcemodel/positions/init 7 - Initialize a position’s attributes
POST specs/{specId}/resourcemodel/persons 8 - Create a new person in the speci-fication’s resource model
POST specs/{specId}/resourcemodel/generate 9 - Generate the activity and goal en-riched models
POST specs/{specId}/resourcemodel/relations 10 - Add a new entity IS PERSON re-lation
POST specs/{specId}/resourcemodel/rules 11 - Add a new resource assignment
Having two separate DML specifications brought challenges when trying to add behaviour to classes
that belonged to the core module. For that, the approach used was to have all of the additional relations
and the behaviour that was associated with them in the resource model. For example, the first problem
that surfaced when I added the relations was when trying to delete a specification. Due to the fact that
the Fenix Framework requires you to clean every relationship of a class before you can delete it, and the
code that did this to core entities was already developed in the core module, the resource model had
to clean the relationships between the Resource Module and the Core Module before the core module
could clean it’s entities. One example of this interaction, expressed in listing 5.2, is the delete function
of the RALExpression class, on which we clean the relationships between the RALExpression and the
entities of the Core module.
46
Listing 5.2: Delete function for RALExpression class
1
2 public abstract class RALExpression extends RALExpression Base {
3 public void delete() {
4 getActivityInformsSet().stream().forEach(p -> removeActivityInforms(p));
5 getActivityResponsibleForSet().stream().forEach(p ->
removeActivityResponsibleFor(p));
6 getGoalInformsSet().stream().forEach(p -> removeGoalInforms(p));
7 getGoalResponsibleForSet().stream().forEach(p -> removeGoalResponsibleFor
(p));
8 setRalExprNot(null);
9 setRalExprAndLeft(null);
10 setRalExprAndRight(null);
11 setRalExprOrLeft(null);
12 setRalExprOrRight(null);
13 setProductResponsibleFor(null);
14 setProductInforms(null);
15 setResourceModel(null);
16 deleteDomainObject();
17 }
18 }
The UML diagram for RALExpression present in Figure 5.7 gives an example of a relationship be-
tween the core and resource modules. This class is fundamental to enable the resource perspective
behaviour. However, to keep the core module low coupled, the classes Product, Activity and Goal have
no information of their relation to the class RALExpression. All of the logic for creating, managing, us-
age and cleaning these relationships is in the Resource module. These relations make the resource
assignments possible because they associate each of the entity that are used in a workflow execution
to a RALExpression. In section 5.3 we explore how these relationships are used in order to restrict the
workflow execution to the resource’s that are assigned.
Another interesting problem to solve, that emerged with the separation of core and resource modules,
was how to store the new relationship between Entity and Persons in which is it possible to have a data
domain entity be considered as a Person from the Resource Model. Since we cannot add a new attribute
to the class Entity, the solution was for the Resource Model class to store a list of every Entity that is
declared in the assignments to be of the type Is Person. Therefore, any checks that are made to an entity
to check if it is of type Is Person are made through the Resource Model class. To enable the execution
of work items with this type of entities as its execution, a new relation was added, in the resource model,
47
Figure 5.8: UML diagram for the Entity is Person relation
between the class EntityInstance and Person. The Resource-enabled executor presented in section
5.3 communicates with the Resource Model Manager in order to handle activities/goals whose post
conditions include the definition of a IsPerson relations. Figure 5.8 models the Entity Is Person relation.
Figure 5.9: Example of objects that fill the Entity Is Person relation
In Figure 5.9 we find a set of objects that illustrate how the Entity Is Person relationship is translated
into the domain. We have a data model entity, in this case Doctor, that is of type IsPerson. Therefore, this
class has a relationship with the ResourceModel stating that it belongs to the set of entities that are of
this type. Later, during workflow execution, the Doctor entity is associated with a set of entity instances,
in case of the example Doctor123. Since the Doctor entity is of type IsPerson, its entity instances must
be associated with a Person at the time of its creation. In the case of the example, the entity instance
Doctor123 is associated with the resource model person John.
5.2.3 Specification generation
As previously stated in section 4.2, the generation is made in two steps. The first step in which we
generate the models accordingly to workflow restrictions is already implemented and remain unchanged.
The second step is new and implemented in the resource engine. The class DesignResourcesInterface
48
separates the generation of the enriched models between the activity model and the goal model. For
the activity model, it takes all the entities and attributes present in the data model and for each one,
get the activities that have as its post condition the entity in question, and applies to the activity the
assignment contained in the entity/attribute. The same is made for the attributes. For the goal model,
the methodology is the same with the exception that it will look for goals in which the success condition
contains the entity in question. Note that this generation is possible because the generation of the
core model is minimal. Each entity and each attribute is assigned to a single activity/goal, such that
the enrichment of the activity and goal core models with resource management does not introduce
inconsistencies in relation to the enriched data model.
To support this generation in the database, some relations were added in the DML. These relate
the activity and goal entity to a RALExpression in a relationship named ‘responsible for’ and to another
RALExpression in a relationship named ‘informs’. The generation creates these relations, that will later
be used by the execution engine to determine whether or not a resource is capable of executing an
activity/goal.
5.2.4 Mutating the models
The final part of the designer module that required changes in order to support a resource perspective
was the operations that can be made to either the activity or goal model. These operations were already
implemented in the core module manager. However, with the addition of resource assignments, these
operations have a different behaviour.
To implement the behaviour intended and explained in section 4.3, there were several concerns that
must be taken into account: (i) the ability to express which kind of policy we want for a given operation; (ii)
ensure that add/remove sequence operations do not break the workflow requirements made by resource
assignments; (iii) original resource assignments and the ones resulting from merge operations should
be dealt alike; (iv) the merge of resource assignments do not lead into inconsistencies such as (NOT
HAS POSITION pos1) AND (HAS POSITION pos1).
Both Rename activity and rename goal remained unchanged since they neither affect the workflow
model or the resource model.
The resource perspective does not affect the add/remove sequence operations with the exception
of two cases: when one of the activities either has an assignment of types IsPersonInDataObject and
IsPersonInTaskDuty that dependes on the other activity. To illustrate these cases, in figure 5.10 we have
an example that contains the IsPersonInTaskDuty assignment. In yellow, we have the sequence that the
operation is trying to add, i.e, the Activity 1 executing after the execution of Activity 2. However, Activity
2 contains the resource assignment ‘has responsible IS ANY RESPONSIBLE FOR Activity 1’. This
implicitly means that the Activity 1 must execute before the Activity 2 in order to be able to evaluate the
49
RAL expression upon it’s execution. We we allow the operation to be made, a circularity in the activity
model is introduce, leading to an inconsistency in the specification.
Figure 5.10: Activity diagram for a specification that contains an add sequence operaiton
Suppose, that the example contains an entity named Ent and this entity is a person. In case the
Activity 2 had the expression ‘Activity 2 has responsible IS PERSON IN DATA FIELD Ent’, and the
Activity 1 had as a post condition the definition of the entity Ent as well as the definition of the IsPerson
relation. This means that for the Activity 2 to have persons that can be responsible for it, the Activity 1
must be executed first. Therefore, the same implicit relationship exists between the two activities.
Since the models manager in the core project checks for any circularities that may be introduced
with the operation, the solution to solve this inconsistency was to add a dependency between the data
objects of both activities in order to objectively represent the implicit dependence represented in green
in the figure 5.10. This dependence is added by the DSL Parser module and is added each time
either a IsPersonInDataObject or IsPersonInTaskDuty expressions are parsed. With the addition of
this dependence, the core module can now check if the operation will lead to circularities taking into
account the resource assignments but without actually using them.
The merge and split operations, for both activity and goal models, had their semantics changed with
the addition of a resource perspective. These operations follow the same algorithm for both activity and
goal models The merge operation is described as follows:
1. The Resource models manager receives a ResourcesMergeOperationDto. This class is an ex-
tension of the class MergeOperationDto that was previously used, and adds the information about
which type of policy it is supposed to be used in operation.
2. We then extract both activities/goals that are to be merged and get each assignment for the re-
sponsible for and informed about process responsibilities.
3. The designer then proceeds to merge the activity/goal as he has previously done. The philosophy
50
is that we check for incoherences in the merged activity/goal and if any is found, the operation is
aborted.
4. The algorithm then tries to create a new RALExpression for the two responsibilities that joins both
expressions using the selected policy:
(a) For the relaxed policy, it is created a RALExprOr that combines both expressions;
(b) For the restricted policy, it is created a RALExprAnd expression;
5. After the expression is merged, the designer checks if the merged expression has any inconsis-
tency. If it is consistent, the designer assigns the expression to the merged activity/goal.
The merge policy that exactly preserved the models was not implemented since it was a subset of
the restricted policy, i.e, that policy could be achieved using the restricted policy. Although the engine
provides both policies for the user, the default merge policy is the restricted policy since it guarantees
the consistency between the two models. However, it is also possible to apply the relaxed policy if the
user so desires.
Figure 5.11: SetOfRequiredResources UML
To check if the merged expression is consistent we use the SetOfRequiredResources structure. This
structure contains all of the dependencies that the expression has in terms of concrete entities in the
resource model. For example, the expression (HAS POSITION p) AND (NOT (HAS ROLE r)) would
generate a SetOfRequiredResources that expresses that expression needs the position p and the role
r. The generation of this structure is made in each expression. For expressions that contain other
expressions, it first fetches the structure of the expressions it contains and then generates a structure
containing all of the dependencies. This guarantees us that the structure give us all of the resource
information for chains of expressions that compose with other expressions. The structure, depicted
51
in figure 5.11, contains two sets for: each of the entities of the resource model (positions, persons,
capabilities, roles and units); data elements in the form of task duties, in data element and history
assignments. One set tells what resource is needed and the other tells what resources we must not
have.
The algorithm that checks the consistency of a expression get the SetOfRequiredResources for the
expression and traverse the sets in search for negation inconsistencies, i.e, if a resource is in both sets
for the category of entity. The expression (HAS ROLE r) AND (NOT (HAS ROLE r)) would generate a
SetOfRequiredResources structure that would have the role r in the set roles and in the set notRoles.
Since a role is found in both the roles and notRoles sets, the expression is considered inconsistent.
The algorithm also checks if the work item products of the merged activity/goal are present in the
set that forbids data elements, for example, the work item that has as product the entity e1, and it’s RAL
expression tells us the person responsible is not in the data element e1.
5.3 Engine
The Engine module is responsible for the execution of Blended Workflow models. It comprises the
Engine UI Module and the Execution Manager. The Execution Manager is the model that interacts with
the Models Manager to enable the execution of the workflow models. The Engine UI Module comprises
all of the UI that is dedicated to executing specifications.
To enable the resource perspective, a new module, the Resource-Enabled Executor module, was
added. This module is a sub-module of Execution Manager and provides the same functionality as the
Core Executor only with a different behaviour that is resource based.
5.3.1 Enabling a resource-enhanced execution
A resource-enhanced execution is a standard execution that obeys the resource assignments that
are made to each data element, either though the task duty responsible for or informed about. Instead
of allowing everyone to execute and view every work item in both activity and goal views, a resource-
enhanced execution filters work items to the correct persons and provides views that are more useful to
each person responsibilities.
Compared to the core execution, a resource-enhanced execution translates into three differences: (i)
having pending work item list that only shows the work items that the person executing the system can
be responsible for; (ii) restricting the execution of work items to the persons that validate the work item’s
responsible for RALExpression; (iii) the history log of executed work items only shows work items that
the person could be responsible for.
52
Enabling this type of execution requires one important system feature that was not present until
this point: the identification of the person that is executing the system. It is fundamental to be able
to determine objectively which person is executing the views, and restrict his operations based on his
responsibilities. It is the authentication of users that enables the resource assignment verification.
While implementing this execution, there was a focus on keeping the logic for the resource perspec-
tive separate from the workflow logic as much as possible, following the philosophy used in the Designer
module. Therefore, the resource-enhanced execution had to be implemented without changing any
behaviour present in the Core Executor.
Since the resource-enhanced execution is a subset of the core execution and only filters some ex-
ecutions of the core executor, a pipe-and-filter pattern can be applied to the core execution in order to
add the new execution: we filter instances of the core execution that do not comply with the resource
assignments present in the activity/goal work items.
The Core Executor uses the ExecutionInterface class to enable the execution of models. This class
is used by the Spring Controllers that provide access the the Core Executor API. It implements the logic
that is necessary for the fetching of pending work items, their execution and obtaining a history log of
which work items have been executed. This is the class that needed to be changed in order to add the
resource-enhanced execution.
Figure 5.12: Pipe-and-filter pattern present in execution modules
To keep this logic separate from the core behaviour, the class ExecutionResourcesInterface was
created in the bw-resources project. It extends the ExecutionInterface class from the Core Executor
module and is instantiated in the bw-resources project using the ResourcesFactory class. This is the
class that applies the pipe-and-filter pattern (Figure 5.12) to the core execution and is explained in more
detail in section 5.3.3.
5.3.2 User authentication
One fundamental feature that was added to the Engine module was the identification of the person
that is executing the system. This identification is necessary in order to validate if the person executing
53
the system has permissions to view/execute work items. The identification of persons is made though a
user authentication.
The method chosen to implement the user authentication was through the JSON Web Tokens (JWT)
protocol. This protocol was developed to be used for authentications in API applications and works by
assigning and passing around an encrypted token in each request that is made to the server. This token
helps to identify the logged in user, instead of storing the user in a session on the server and creating a
cookie. The protocol defines two operations that enable an authentication:
Authentication - A first contact between the user and the server is made, when the user tells the server
his credentials (username and password). If the server validates the login, it returns a valid JWT.
Authorization - After the login is made, the user sends the received JWT in the header of each request
to the server. The server then validates the JWT sent in each request and, if valid, authorizes the
request.
A JWT is string composed of there parts, each one separated by a dot: (i) the header, which contains
the type of token (JWT) and the hashing algorithm used. The header is a JSON object that is Base64Url
encoded to become a part of the string; (ii) the payload, that contains the claims of the token, i.e, the
statements about an entity like the username and password. It can be of type registered, public and
private. The claim is structured as a JSON object that is encoded to become a part of the string; (iii)
the signature, which is used to verify if the message has not been tampered with. To generate one, we
take the encoded header and payload, a secret that is only known by the server, and hash it using the
hashing algorithm present in the header.
To implement this protocol in the engine, the Spring Security was used. Spring Security provides a
structure that sits in the Spring filters pipeline and that allows the authorization of requests to be made
without changing any of the controllers. All of the JWT logic is implemented in the filters that activate
before the request reaches the controllers. The class that configures Spring Security is BlendedWebSe-
curityConfigurerAdapter. It is here that permissions for each different URLs are configured and the new
JWTAuthenticationFilter and JWTAuthorizationFilter filters are added to the chain.
The JWTAuthenticationFilter implements the attempt of authentication, i.e, the interpretation of the
UserDto passed in the request body to the /login controller and uses the class AuthenticationManager
from Spring to authenticate the credentials. It also implements the action that is taken when a successful
authentication is made in which a JWT token is created with the usage of JWTS Java library. This filter
is only called when a authentication is made through the /login controller using the POST method. All
of this logic is implemented in the Spring UsernamePasswordAuthenticationFilter class that is a super
class of our filter.
The JWTAuthorizationFilter is a standard filter that acts in every requests and implements the check
54
for the authorization token. The filter first checks if the token prefix (BEARER) is present in the header.
If it is, it validates the token and extracts the username and sores it in the SecurityContextHolder. It is
through the SecurityContextHolder that the logged in user is obtained in controllers and domain classes.
5.3.3 ExecutionResourceInterface
The ExecutionResourceInterface class provides the functionality for the Resource-enhanced execu-
tor module. This is a subclass of the ExecutionInterface class, which is the class that implements the
Core executor. This class applies the pipe-and-filter pattern to the Execution module through the usage
of inheritance. To add more filters to this pipeline, it would be necessary to extend the ExecutionResour-
ceInterface to be applied after this executor.
The idea for applying a pipe-and-filter pattern to the execution was mainly to keep the different exe-
cutions’ logic separate from each other. This was possible because the resource-enhanced execution
doesn’t alter any on the workflow execution logic but only filters some types of execution.
One benefit of using inheritance for implementing the pipe-and-filter pattern was that no controllers
for the Executor Manager module had to be changed. This was possible because the instantiation of the
ExecutionInterface class in the controllers is made through the Resource Factory. Since the Resource
factory is a Spring Bean that changes upon the project that is executing, it is possible to make the
controllers instantiate the new Executors without changing their code.
To provide the pipe-and-filter functionality in this inheritance implementation, it is always required
that the overridden method, i.e, the method that is being filtered, calls upon it’s super method and then
applies the filtered intended.
5.3.4 Pending work item set
The first step in executing a workflow instance is to obtain the current list of pending work items. This
is where the work item DTOs are obtained to be later passed to the execution of work items. They are
obtained using the methods getPendingActivityWorkItemSet and getPendingGoalWorkItemSet, from the
ExecutionInterface class, and they return a set of work items for the activity and goal model respectively.
They return ActivityWorkItemDto’s and GoalWorkItemDto’s that are sub classes of WorkItemDto. These
DTOs contain all of the information about a work item as well as it’s entity context that is used for
execution. These two methods transform a work item domain object into the correct DTO. They use
two protected methods that contain the logic for fetching the work item list and are named respectively
getPendingActivitySet and getPendingGoalSet.
To the standard behaviour of obtaining the pending list of work items, it is important to filter the work
items in which only the work items that the logged in user can execute are obtain. This is important to
55
be done in order to present a more simple and useful view for the user executing the system.
It is in both getPendingActivitySet and getPendingGoalSet that the filtering of activities and goals
for execution is made. The logic in each method is very similar, only justifying being separated into two
different methods because of the methods that are specific for goals and activities. These methods are
overridden in the new ExecutionResourceInterface and apply the pipe-and-filter pattern. The filtering of
activities and goals is made as follows:
1. The method calls its version in the super class and obtain the standard list of activities and goals.
2. The current logged in user is obtained
3. For each activity or goal in the standard pending list, if its responsible for expression does not have
as eligible person the current logged in user, the it is removed from the list
After we obtain the list of activities and goals to execute, it is necessary to transform them into DTOs.
Due to the addition of the entity is person relation, a new type of activity and goal emerged in which this
relation is filled. To implement the possibility of the execution of these activities and goals, two new types
of work item DTOs were created, the ResourceActivityWorkItemDto and ResourceGoalWorkItemDto.
These DTOs extend their previous iteration, in order to have all the previous logic for the workflow
execution function, with the difference that they have two new properties: the EntityIsPersonDto set and
the executionUser. The executionUser is a property that is used for the history of work items executed
and is explored in section 5.3.6.
The EntityIsPersonDto is a new DTO that contains the information about an entity is person relation
that must be filled in an activity or goal. It contains: the entity that is of type person; the entity instance
in which we will be associating a person; a set of persons that can be chosen for the relation; and the
person chosen to be used in the relation. The person chosen is used in the execution of these types of
DTOs. The other attributes are necessary in order to be presented in the User Interface, allowing the
selection of a person.
5.3.5 Execute a work item
The execution of work items is implemented by the functions executeActivityWorkItem and execute-
GoalWorkItem. They take as parameter the work item DTOs that are obtained through the get pending
list of work items operation. The implementation of the execution of work items is implemented in the
Core executor module, in ExecutionInterface class.
Implementing the resource-enhanced version of the execution of a work item means that only the
person that is logged to the system has permissions to execute it. A person has permission to execute
a work item when the work item’s responsible for expression has as eligible the logged in person.
56
To implement it, the pipe-and-filter pattern is used:
1. The method calls its version in the super class and execute the work item accordingly to the core
executor module.
2. The current logged in person is obtained
3. For the work item executed, the activity/goal is fetched
4. If the person does not belong the set of persons that are eligible for the activity/goal’s responsible
for expression, then an exception is thrown, and the transaction is aborted
5. If the person belongs to the set, then the person that is logged is assigned as the work item’s
execution user
The resource-enhanced execution of work items must also take into account the execution of activi-
ties or goals that contain the creation of the entity is person relation. In the previous section, I explained
how these work items are differentiated from the normal work items. To execute one of these work items,
the rule is that every EntityIsPersonDto has the personChosen attribute assigned to a person belonging
to the personContext set. If the personChosen is not set, then a new Person is created in the resource
model.
The logic for executing these types of work items is present in the respective ResourceActivity-
WorkItemDto and ResourceGoalWorkItemDto classes:
Listing 5.3: Resource module - Spring application
1 @Override
2 public ActivityWorkItem executeActivity(WorkflowInstance workflowInstance,
Activity activity) {
3 ActivityWorkItem activityWorkItem = super.executeActivity(workflowInstance,
activity);
4
5 for (EntityIsPersonDto entityIsPersonDto : getEntityIsPersonDTOSet()) {
6 activityWorkItem.getPostConditionSet().stream()
7 .map(PostWorkItemArgument::getProductInstanceSet)
8 .flatMap(Collection::stream)
9 .filter(productInstance -> productInstance instanceof EntityInstance)
10 .filter(productInstance -> entityIsPersonDto.getEntity().getName().
equals(productInstance.getEntity().getName()))
57
11 .filter(productInstance -> productInstance.getEntity().
getResourceModel().checkEntityIsPerson(productInstance.getProduct
()))
12 .map(productInstance -> (EntityInstance) productInstance)
13 .forEach(entityInstance -> {
14 if (entityIsPersonDto.getPersonChosen() != null) {
15 Person person = entityInstance.getEntity().getResourceModel()
.getPerson(entityIsPersonDto.getPersonChosen().getName())
;
16 entityInstance.setPerson(person);
17 } else {
18 entityInstance.setPerson(new Person(
19 entityInstance.getEntity().getResourceModel(),
20 entityInstance.getExternalId(),
21 entityInstance.getExternalId()
22 ));
23 }
24 });
25 }
26
27 return activityWorkItem;
28 }
5.3.6 History of work items executed
The last functionality that the Execution Manager module provides is the history of activities/goals
that have been executed. The function that implement it in the ExecutionInterface class is getLog-
WorkItemList.
A resource-enhanced version of this function is different in two ways: firstly, instead of returning every
single work item executed, only the work items that the logged in user have permission to be informed
about it are obtained; secondly, the work items return are of types ResourceActivityWorkItemDto and
ResourceGoalWorkItemDto, with the property executionUser set correctly.
Following the same pipe-and-filter pattern as before, the functionality is implemented as follows:
1. The method calls its version in the super class and list of work items executed accordingly to the
core executor module.
2. The current logged in person is obtained
58
3. For each work item in the history list, if its informs expression does not have as eligible person the
current logged in user, it is removed from the list
4. For the remaining work items, a ResourceActivityWorkItemDto or ResourceGoalWorkItemDto is
constructed with the attribute executionUser set
5.4 User interface
The final component of the resource perspective is the user interface. This component is divided
into two modules: the Engine UI Module and the Design UI Module. The Engine UI Module implements
the user interface that allows the execution of workflow instances. The Design UI Module provides
the access in the user interface to the graphical representation of the several models, and allows the
execution of operations in these models.
The interface is built in ReactJs. ReactJs is an open-source Javascript library that is aimed at building
UIs and provides declarative an component-based views and allow web designers to build interfaces that
are modular and easy to mantain.
The addition of the resource perspective added a new UI module, the Dashboard UI Executor, which
is a sub-module of the Engine UI module. This module adds a new view for executing workflow instances
that are customized for the specific user.. In the Dashboard view, the logged in user can find all of the
work items that he can executed, organized by specifications and workflow instances. This view was
only possible, because of the assignment of work items to persons, that allows the system to provide a
view that has meaning for the user currently logged.
The Design UI module remains unchanged due to the fact that no new operations were added to
the Models Manager, and the changes that were made to the current operations, due to the resources
management models, were implemented in the engine, making the UI exactly the same.
The Workflow UI Executor, the module that represents the previous execution UI, also remained
largely unchanged due to the fact that the new rules are applied in the Execution Manager module.
However, to be able to communicate with the new Resource-enabled executor module, it has to contain
an authentication of the person executing, in order to be able to make the requests.
5.4.1 Authentication
The main functionality that needed to be added to the Workflow UI Executor was the authentication
of users. This was necessary due to the fact that the resource-enabled executor required that each
request included the Authentication header.
Due to the fact that system is not intended to be put into production at this point of time, the log in
59
process was simplified (Figure 5.13). To enable the authentication of users, a new navigation item was
added to the application header, named users, in which all of users present in the system are display.
To log in to a user, you select one of the users from the list, and that user is authenticated. This was
possible because the password of the users is the same as the user name, so a real authentication
process occurs, implemented using JWT.
Figure 5.13: Authentication UI module
After the user logs in a request is made, a JwtAuthenticationResponseDto object is returned from
the server, that contains the bearer token that is used to authorize the subsequent requests from the
UI Executor to the Execution Manager module. This token is then stored in the redux on the property
user in the format of a LoggedUser object. This object contains information about the user name of the
logged in user and the bearer token that confirms the authentication.
Each request to server must now contain the bearer token that identified the user authentication.
For that, in the React project, the RepositoryService class now receives a LoggedUser object in the
constructor. This LoggedUser object is used to obtain the Bearer token and pass it in each request. It is
passed in each request through the Axios constructor, that sets the base configuration for each request
made by the RepositoryService. Axios is a Javascript library that provides a HTTP Client that supports
the ES6 Promise API.
5.4.2 Dashboard UI
The Dashboard UI View is a new view of work items, that allow the logged in user to have a global
perspective of every work item that he can execute. This global perspective organizes work items by
specification, workflow instance and type of view, either activity or goal based.
The motivation behind this view is to offer a simple presentation of all the work items assigned to the
user organized by specification and instance. Afterwards, the user can load a chosen instance into the
standard executor and start the execution of that instance from there. Previously, a person would have
60
to check every activity/goal view of a workflow instance to know which and how many work items he
could execute.
Figure 5.14: Dashboard UI view
This new view, presented in Figure 5.14, besides providing a global view of which work items the
person can execute, it also provides a direct link to the instance executor, that allows the execution of
the work items either by activity or goal models.
To implement this view, the Resource-enabled Executor Module API is used. It contains a endpoint,
‘/users/dashboard’, that constructs a DashboardDto object for the authenticated user. This DTO contains
two sets, one that contains every activity work item that the authenticated user is able to executed, and
other that contains every goal work item. Each work item contains information about the specification
and workflow instance that it belongs.
The Dashboard React component, after fetching the DashboardDto for the authenticated user, pro-
ceeds to sort the work items into a map, firstly by specification name, then by workflow instance name,
61
and finally by the type of view, activity or goal view, that the work item belongs.
Finally, the button that allows the person to go to the execution view, were implemented by filling the
redux with the correct information about the specification and workflow instance name, and redirects the
page to the instance execution view.
Although the interface in both activity and goal view did not have its implementation changed, the in-
teraction with it is very different. Instead of displaying all of the work items that are opened for execution,
now only the work items that the logged in user can be responsible for are displayed.
Figure 5.15: Goal view for the Doctor appointment specification. On the left, the view before the resource perspec-tive, on the right the view after
In figure 5.15, you can find the Goal view for the Doctor appointments specification, that has been
used as a running example. Consider the person executing the system is Anna. Anna occupies the
position Receptionist. Because of that, in the begging of a instance, she only is responsible for executing
the Episode data element. If the older version of the system is running, view of the left, then Anna has
access to every work item that is possible to be executed in the workflow instance, even though she is not
supposed to execute them. On the right, we are executing the version of the system that is enriched with
the resource assignments. Because of that, Anna only sees the work items that she has responsibility
to execute, and therefore, the UI only shows the goal ‘Episode’.
62
6Proof of concept
In this chapter I analyze and present a proof of concept that aims at showing the capabilities of
system. I also summarize of the capabilities that the system provides.
To evaluate if the system meets the expectations and achieves the objective of successfully imple-
menting resource management in the Blended Workflow system it is necessary to measure how many
workflow resource patterns does the system support.
For that, I will provide an example for each resource pattern and how it is supported by the system.
As a base for the assignments’ examples, I will use the running example that has been used through
the thesis. The specification data model and resource model are present in appendix A.1 and appendix
A.3. A list describing each of the resource patterns can be found in section 3.6.
Direct Distribution :
Patient has responsible IS PERSON William
Role-Based Distribution :
Patient.name has responsible HAS ROLE ManagePatientInformation IN UNIT OrthopedicUnit
Deferred Distribution :
63
Data.bloodPressure informs IS PERSON IN DATA FIELD Data.episode.doctor
Authorization - This resource pattern is not supported;
Separation of Duties :
Episode has responsible (NOT (IS ANY PERSON RESPONSIBLE FOR Episode.patient))
Case handling - This resource pattern is not supported;
Retain familiar :
Medication has responsible IS ANY PERSON RESPONSIBLE FOR Medication.prescription
Capability-based distribution :
Prescription has responsible HAS CAPABILITY BelongsToDoctorsAssociation
History-based distribution :
Prescription.desc informs WITH LEAST HISTORY ON EXECUTION IN Prescription
Organizational distribution :
Episode.checkout has responsible HAS POSITION Receptionist
Automatic Execution : This resource pattern is not supported;
From the previous list we can infer that the resource perspective added to the Blended Workflow
support 8 out of 11 resource patterns that have been identified in previous work.
The system provides the execution of workflow instances that respect the resource assignments
written in the resource rules, restricting the access to the log of executed work items to the persons that
have permission to validate the informs responsibility.
The system also handles the consistency of operations in both activity and goal models, ensuring
that the old operations do not break any of the resource assignments.
Finally, with the addition of the dashboard view, the UI provides a personalized view for the au-
thenticated person that takes into account the work items that are to be executed and the resource
permissions that the person has.
64
7Conclusion
Business processes are usually translated into an activity or goal based workflow specification. Al-
though this improves the process efficiency and interoperability, it is also not sufficient to fully represent
a business process. This is due to the fact that these specifications do not take into account the impact
that the resources that execute the business process have on them.
For this reason, the research in this dissertation for a resource perspective in the Blended Workflow
was conducted. The objective was to add a resource perspective that allowed the workflow designers
to represent a process resource model as well as making resource assignments between the already
implemented workflow models and the resource model. The main difficulty that was faced during this
dissertation was how to apply concepts from the resource assignments to three different types of BW
elements: data elements, activities and goals. The problem emerged from the fact that all of the concepts
presented in the state of the art are usually related to activities gather that the BW elements. The
Blended Workflow system is now able to provide both features to workflow designers while adapting all
of the concepts presented in the state of the art to the Blended Workflow elements.
Besides providing a platform to specify these enriched activity and goal models, the system also
provides an application to execute these models accordingly to the restrictions imposed by the resource
65
assignments. This means that the Blended Workflow engine now provides a control-access to the
execution of activities and goals that is very useful for organisations.
The system also provides a new execution view, named dashboard view, that presents a more or-
ganised view of all of the work items that the person is able to execute.
7.1 Future work
With the addition of the resource perspective in the Blended Workflow, multiple research topics on
the Blended Workflow have opened. A list of these topics follows:
• Have additional allocation methods. The Blended Workflow only supports the pull allocation of
work items. The system would benefit if other types of allocation as presented in Russell’s work [6].
• Use dynamic allocation of work items. Have a type of dynamic allocation that takes into account
the resource assignments and determines a optimized path of work items execution between dif-
ferent people.
• Gamification. Apply a gamification philosophy to the execution engine, that could serve as a
performance assessment of the users of the process.
• Operations in the resource model. Add operations that can be made to the resource model that
allow the designers of the processes to represent the mutations that occur in the resource model
as time passes by.
• Support activities/goals that are executed by multiple resources. Many business processes
contain activities/goals that are executed by several people, i.e, the operation of a patient. Sup-
porting these types of activities/goals would allow the designers to represent a process with more
accuracy.
• Enable a graphical representation of the resource model and assignments. Provide a graph-
ical view for the resource model that is associated with a specificiation as well as integrate the
resource assignments into the graphical representations of the activity and goal models.
66
Bibliography
[1] A. R. Silva and V. Garcıa-Dıaz, “Integrating activity- and goal-based workflows: A data model based
design method,” in Lecture Notes in Business Information Processing, vol. 256, 2016, pp. 352–363.
[2] P. P.-S. Chen, “The entity-relationship model—toward a unified view of data,” ACM Transactions on
Database Systems (TODS), vol. 1, no. 1, pp. 9–36, 1976.
[3] A. Rito Silva, “A blended workflow approach,” in Lecture Notes in Business Information Processing,
vol. 99 LNBIP, no. PART 1, 2012, pp. 25–36.
[4] D. Passinhas, M. Adams, B. O. Pinto, R. Costa, A. R. Silva, and A. H. Hofstede, “Supporting blended
workflows,” in CEUR Workshop Proceedings, vol. 936, 2012, pp. 23–28.
[5] M. Zur Muehlen, “Organizational Management in Workflow Applications – Issues and Perspectives,”
Information Technology and Management, vol. 5, no. 3/4, pp. 3–4, 2004.
[6] N. Russell, A. H. M. Hofstede, and D. Edmond, “Workflow resource patterns,” Business, vol. 3520,
no. 5446, p. 13–17, 2004.
[7] C. Cabanillas, M. Resinas, and A. Ruiz-cort, “Automated resource assignment in bpmn models
using raci matrices,” pp. 56–73, 2012.
[8] N. Russell and W. M. Van Der Aalst, “Work distribution and resource management in BPEL4People:
Capabilities and opportunities,” in Lecture Notes in Computer Science (including subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), vol. 5074 LNCS, 2008, pp.
94–108.
[9] O. W.-b. Extension and B. T. Committee, “WS-BPEL Extension for People ( BPEL4People ) Speci-
fication Version 1 . 1,” Review Literature And Arts Of The Americas, no. November, pp. 1–58, 2009.
[10] C. Cabanillas, M. Resinas, A. Del-Rıo-Ortega, and A. Ruiz-Cortes, “Specification and automated
design-time analysis of the business process human resource perspective,” Information Systems,
vol. 52, pp. 55–82, 2015.
67
[11] C. Cabanillas, D. Knuplesch, M. Resinas, M. Reichert, J. Mendling, and A. Ruiz-Cortes, “RALph: A
graphical notation for resource assignments in business processes,” in Lecture Notes in Computer
Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinfor-
matics), vol. 9097, 2015, pp. 53–68.
[12] S. Efftinge and M. Volter, “oaw xtext: A framework for textual dsls,” in Workshop on Modeling
Symposium at Eclipse Summit, vol. 32, 2006, p. 118.
[13] J. a. Cachopo and A. Rito-Silva, “Combining software transactional memory with a domain
modeling language to simplify web application development,” in Proceedings of the 6th
International Conference on Web Engineering, ser. ICWE ’06. New York, NY, USA: ACM, 2006,
pp. 297–304. [Online]. Available: http://doi.acm.org/10.1145/1145581.1145640
68
ARunning Example
A.1 Data Model
The following data model is written in the DSL defined by the Blended Workflow and represents all
of the information contained within the doctor appointments example.
Listing A.1: Doctor Appointment’s Data Model
1 Specification: "Doctor Appointment"
2
3 Entity Patient {
4 name : String
5 age : Number
6 heartProblems : Boolean
7 }
8
9 Entity Doctor {
69
10 name : String
11 age : Number
12 }
13
14 Entity Episode mandatory {
15 reserveDate : Date
16 checkin : Boolean
17 checkout : Boolean
18 number: Number
19 }
20
21 Entity Prescription {
22 desc : String dependsOn Prescription.episode.report.desc
23 }
24
25 Entity Report dependsOn Report.episode.data.bloodPressure {
26 desc : String mandatory
27 }
28
29 Entity Data {
30 height : Number
31 weight : Number
32 bloodPressure : Number
33 physicalCondition : String
34
35 Constraint Data : Data.bloodPressure == Data.episode.prescription.medication.
quantity
36 }
37
38 Entity Medication dependsOn Medication.prescription.desc {
39 name : String
40 quantity : Number
41 heartImpact : Boolean
42
43 Constraint HeartAttackContraint: NOT (Medication.heartImpact)
44 OR NOT (Medication.prescription.episode.patient.heartProblems)
45 OR (Medication.quantity <= Medication.prescription.episode.data.bloodPressure
)
70
46
47 }
48
49 Association EpisodeHasDoctor {
50 Episode with episode (0..*)
51 Doctor with doctor (1)
52 }
53
54 Association PatientHasEpisode {
55 Patient with patient (1)
56 Episode with episode (0..*)
57 }
58
59 Association EpisodeHasPrescription{
60 Episode with episode (1)
61 Prescription with prescription (0..1)
62 }
63
64 Association EpisodeHasData {
65 Episode with episode (1)
66 Data with data (1)
67 }
68
69 Association EpisodehasReport {
70 Episode with episode (1)
71 Report with report (1)
72 }
73
74 Association PrescriptionHasMedication {
75 Prescription with prescription (1)
76 Medication with medication (1..*)
77 }
A.2 Data Model: Resource assignments
71
Table A.1: Assignments for each of the data fields in the doctor appointments running example
Data field Responsible for Informed aboutPatient Position: AdministrativeManagerPatient.name Role: ManagePatientInformation
AND Unit: OrthopedicUnitPatient.age Role: ManagePatientInformation
AND Unit: OrthopedicUnitPatient.heartProblems Role: ScreeningOfPatients AND
Unit: OrthopedicUnitDoctor Position: Unit Director Position: Administrative ManagerDoctor.name Position: Unit Director Position: Administrative ManagerDoctor.age Position: Unit Director Position: Administrative ManagerEpisode SeparationOfDuties:
Episode.patient AND Role: Sched-uleAppointments AND Unit: Ortho-pedicUnit
Episode.number Role: ScheduleAppointments ANDUnit: OrthopedicUnit
Episode.reserveDate Role: ScheduleAppointments ANDUnit: OrthopedicUnit
Episode.checkIn Position: Receptionist Role: ScheduleAppointments AND Unit:OrthopedicUnit
Episode.doctor Position: Administrative ManagerEpisode.checkOut Position: Receptionist Position: Administrative Manager OR
(Role: ScheduleAppointments AND Unit:OrthopedicUnit)
Data Role: ScreeningOfPatients ANDUnit: OrthopedicUnit
Deferred: Episode.doctor
Data.height Role: ScreeningOfPatients ANDUnit: OrthopedicUnit
Deferred: Episode.doctor
Data.weight Role: ScreeningOfPatients ANDUnit: OrthopedicUnit
Deferred: Episode.doctor
Data.bloodPressure Role: ScreeningOfPatients ANDUnit: OrthopedicUnit
Deferred: Episode.doctor
Data.physicalCondition Role: ScreeningOfPatients ANDUnit: OrthopedicUnit
Deferred: Episode.doctor
Report Position: Doctor AND Deferred:Episode.doctor
Role: WorkLoadScheduler AND Unit: Or-thopedicUnit
Report.description Position: Doctor AND Deferred:Episode.doctor
Deferred: Episode.patient
Prescription Position: Doctor AND Capability:BelongsToDoctorsAssociation
Prescription.description Position: Doctor AND Capability:BelongsToDoctorsAssociation
Commonality in Deferred: Episode.doctor
Medication RetainFamiliar: Prescription Position: Doctor AND History: Most exe-cutions in Prescription
Medication.number RetainFamiliar: PrescriptionMedication.name RetainFamiliar: PrescriptionMedication.quantity RetainFamiliar: Prescription
Continued on next page
72
Table A.1 – Continued from previous pageData field Responsible for Informed aboutMedication.heartImpact RetainFamiliar: Prescription
A.3 Resource Model
The following resource model is written in the DSL defined in this thesis and represents all of the
resources present within the doctor appointment example.
Listing A.2: Doctor Appointment’s Data Model
1 Capability BelongsToDoctorsAssociation {
2 description: "Represents the enrolment of a resource in the country's doctor'
s association"
3 }
4
5 Role WorkLoadScheduler {
6 description: "Schedule work items to his/hers subordinates"
7 }
8
9 Role Scheduler
10
11 Role UnitReporter
12
13 Role UnitAdministrativesReporter
14
15 Role ManagePatientInformation
16
17 Role ScreeningOfPatients
18
19 Role FirstAids
20
21 Role TreatPatients
22
23 Role MedicalExaminator
24
25 Role WelcomePatients
26
27 Unit OrthopedicUnit
73
28
29 Position UnitDirector {
30 isMemberOf: OrthopedicUnit
31 participatesIn: {WorkLoadScheduler, UnitReporter}
32 canDelegateWorkTo: {AdministrativeManager}
33 description: "Person is charge for the whole orthopedic unit"
34 }
35
36 Position AdministrativeManager {
37 isMemberOf: OrthopedicUnit
38 participatesIn: {WorkLoadScheduler, UnitAdministrativesReporter,
ManagePatientInformation}
39 canDelegateWorkTo: {SchedulingAdministrative, Receptionist}
40 reportsTo: UnitDirector
41 }
42
43 Position Doctor {
44 isMemberOf: OrthopedicUnit
45 participatesIn: {ScreeningOfPatients, FirstAids, TreatPatients,
MedicalExaminator}
46 canDelegateWorkTo: {Nurse}
47 reportsTo: UnitDirector
48 }
49
50 Position Nurse {
51 isMemberOf: OrthopedicUnit
52 participatesIn: {ScreeningOfPatients, FirstAids}
53 reportsTo: UnitDirector
54 }
55
56 Position SchedulingAdministrative {
57 isMemberOf: OrthopedicUnit
58 participatesIn: {Scheduler}
59 reportsTo: AdministrativeManager
60 }
61
62 Position Receptionist {
63 isMemberOf: OrthopedicUnit
74
64 participatesIn: {Scheduler, WelcomePatients, ManagePatientInformation}
65 reportsTo: AdministrativeManager
66 }
67
68 Person John {
69 occupies: {Receptionist}
70 }
71
72 Person George {
73 occupies: {Receptionist}
74 }
75
76 Person Anna {
77 occupies: {Receptionist}
78 }
79
80 Person Angela {
81 occupies: {SchedulingAdministrative}
82 }
83
84 Person Magnus {
85 occupies: {AdministrativeManager}
86 }
87
88 Person William {
89 occupies: {Doctor}
90 }
91
92 Person Luke {
93 hasCapability: {BelongsToDoctorsAssociation}
94 occupies: {Doctor}
95 }
96
97 Person Carol {
98 occupies: {Nurse}
99 }
100
101 Person Mary {
75
102 occupies: {Nurse}
103 }
104
105 Person Helen {
106 occupies: {UnitDirector}
107 }
A.4 Resource Rules
The following resource rules are written in the DSL defined in this thesis and represents all of the
resource assignments from each resource in appendix A.3 to the data model in appendix A.1 contained
within the doctor appointments example.
Listing A.3: Doctor Appointment’s Data Model
1 ResourceRules {
2 Patient IS PERSON
3 Doctor IS PERSON
4 Patient has responsible HAS POSITION AdministrativeManager
5 Patient.name has responsible HAS ROLE ManagePatientInformation IN UNIT
OrthopedicUnit
6 Patient.age has responsible HAS ROLE ManagePatientInformation IN UNIT
OrthopedicUnit
7 Patient.heartProblems has responsible HAS ROLE ScreeningOfPatients IN UNIT
OrthopedicUnit
8 Doctor has responsible HAS POSITION UnitDirector
9 Doctor informs HAS POSITION AdministrativeManager
10 Doctor.name has responsible HAS POSITION UnitDirector
11 Doctor.name informs HAS POSITION AdministrativeManager
12 Doctor.age has responsible HAS POSITION UnitDirector
13 Doctor.age informs HAS POSITION AdministrativeManager
14 Episode has responsible (NOT (IS ANY PERSON RESPONSIBLE FOR Episode.patient))
AND (HAS ROLE Scheduler IN UNIT OrthopedicUnit)
15 Episode.number has responsible HAS ROLE Scheduler IN UNIT OrthopedicUnit
16 Episode.reserveDate has responsible HAS ROLE Scheduler IN UNIT OrthopedicUnit
17 Episode.checkin has responsible HAS POSITION Receptionist
18 Episode.checkin informs HAS ROLE Scheduler IN UNIT OrthopedicUnit
76
19 Episode.doctor has responsible HAS POSITION AdministrativeManager
20 Episode.checkout has responsible HAS POSITION Receptionist
21 Episode.checkout informs (HAS POSITION AdministrativeManager) OR (HAS ROLE
Scheduler IN UNIT OrthopedicUnit)
22 Data has responsible HAS ROLE ScreeningOfPatients IN UNIT OrthopedicUnit
23 Data informs IS PERSON IN DATA FIELD Data.episode.doctor
24 Data.height has responsible HAS ROLE ScreeningOfPatients IN UNIT
OrthopedicUnit
25 Data.height informs IS PERSON IN DATA FIELD Data.episode.doctor
26 Data.weight has responsible HAS ROLE ScreeningOfPatients IN UNIT
OrthopedicUnit
27 Data.weight informs IS PERSON IN DATA FIELD Data.episode.doctor
28 Data.bloodPressure has responsible HAS ROLE ScreeningOfPatients IN UNIT
OrthopedicUnit
29 Data.bloodPressure informs IS PERSON IN DATA FIELD Data.episode.doctor
30 Data.physicalCondition has responsible HAS ROLE ScreeningOfPatients IN UNIT
OrthopedicUnit
31 Data.physicalCondition informs IS PERSON IN DATA FIELD Data.episode.doctor
32 Report has responsible (HAS POSITION Doctor) AND (IS PERSON IN DATA FIELD
Report.episode.doctor)
33 Report informs IS PERSON IN DATA FIELD Report.episode.patient
34 Report.desc has responsible (HAS POSITION Doctor) AND (IS PERSON IN DATA
FIELD Report.episode.doctor)
35 Report.desc informs IS PERSON IN DATA FIELD Report.episode.patient
36 Prescription has responsible (HAS POSITION Doctor) AND (HAS CAPABILITY
BelongsToDoctorsAssociation)
37 Prescription.desc has responsible (HAS POSITION Doctor) AND (HAS CAPABILITY
BelongsToDoctorsAssociation)
38 Prescription.desc informs (HAS POSITION Doctor) AND (WITH LEAST HISTORY ON
EXECUTION IN Prescription)
39 Medication has responsible IS ANY PERSON RESPONSIBLE FOR Medication.
prescription
40 Medication.name has responsible IS ANY PERSON RESPONSIBLE FOR Medication.
prescription
41 Medication.quantity has responsible IS ANY PERSON RESPONSIBLE FOR Medication.
prescription
42 }
77
78
BSpefication languages
B.1 Resources’ meta-model language
Listing B.1: Resource Model BNF Grammar
〈program〉 ::= [〈capabilities〉] [〈roles〉] [〈units〉] [〈positions〉] [〈persons〉]
〈capabilities〉 ::= 〈capability〉 | 〈capability〉 〈capabilities〉
〈capability〉 ::= Capability 〈identifier〉 [〈capabilityBody〉]
〈capabilityBody〉 ::= { 〈description〉 }
〈roles〉 ::= 〈role〉 | 〈role〉 〈roles〉
〈role〉 ::= Role 〈identifier〉 [〈roleBody〉]
〈roleBody〉 ::= { 〈description〉 }
79
〈units〉 ::= 〈unit〉 | 〈unit〉 〈units〉
〈unit〉 ::= Unit 〈identifier〉 [〈unitBody〉]
〈unitBody〉 ::= { 〈description〉 }
〈positions〉 ::= 〈position〉 | 〈position〉 〈positions〉
〈position〉 ::= Position 〈identifier〉 〈positionBody〉
〈positionBody〉 ::= { [〈description〉] 〈unitAttr〉 [〈participateAttr〉] [〈delegateAttr〉] [〈reportsAttr〉] }
〈unitAttr〉 ::= isMemberOf: 〈identifier〉
〈participateAttr〉 ::= participatesIn: { 〈participateAsgmt〉 }
〈participateAsgmt〉 ::= 〈identifier〉 | 〈identifier〉 , 〈participateAsgmt〉
〈delegateAttr〉 ::= canDelegateWorkTo: { 〈delegateAsgmt〉 }
〈delegateAsgmt〉 ::= 〈identifier〉 | 〈identifier〉 , 〈delegateAsgmt〉
〈reportsAttr〉 ::= reportsTo: 〈identifier〉
〈persons〉 ::= 〈person〉 | 〈person〉 〈persons〉
〈person〉 ::= Person 〈identifier〉 [〈personBody〉]
〈personBody〉 ::= { [〈description〉] [〈capabilityAttr〉] [〈occupiesAttr〉] }
〈capabilityAttr〉 ::= hasCapability: { 〈capabilityAsgmt〉 }
〈capabilityAsgmt〉 ::= 〈identifier〉 | 〈identifier〉 , 〈capabilityAsgmt〉
〈occupiesAttr〉 ::= occupies: { 〈occupiesAsgmt〉 }
〈occupiesAsgmt〉 ::= 〈identifier〉 | 〈identifier〉 , 〈occupiesAsgmt〉
〈description〉 ::= description: 〈string〉
80
〈letter〉 ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y |
Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x |
y | z
〈digit〉 ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
〈qualifiedChar〉 ::= 〈letter〉 | 〈digit〉 | _
〈identifierText〉 ::= | 〈qualifiedChar〉 〈identifierText〉
〈identifier〉 ::= 〈letter〉 〈identifierText〉
〈character〉 ::= 〈letter〉 | 〈digit〉 | _ | . | - | , | : | \ | | | ? | ’ | + | * | !
〈text〉 ::= ´’ | 〈character〉 〈text〉
〈string〉 ::= ‘"’ 〈text〉 ‘"’
B.2 RAL language
Listing B.2: RAL Expressions BNF Grammar
〈RALExpression〉 ::= ‘ANYONE’ | 〈personExpr〉 | 〈hierarchyExpr〉 | 〈grpResourceExpr〉 | 〈denyExpr〉
〈commonalityExpr〉 | 〈compoundExpr〉 | 〈capExpr〉 | 〈historyExpr〉
〈personExpr〉 ::= ‘IS’ 〈personConstraint〉
〈grpResourceExpr〉 ::= ‘HAS’ 〈grpOrgConstraint〉 | ‘HAS’ 〈roleConstraint〉 [〈unitOptional〉]
〈grpOrgConstraint〉 ::= 〈posConstraint〉 | 〈unitConstraint〉
〈commonalityExpr〉 ::= ‘SHARES’ 〈amount〉 〈commonRoleConst〉 ‘WITH’ 〈personConstraint〉
| ‘SHARES’ 〈amount〉 ‘ROLE’ [〈unitOptional〉] ‘WITH’ 〈personConstraint〉
〈commonRoleConst〉 ::= ‘POSITION’ | ‘UNIT’
〈unitOptional〉 ::= ‘IN’ 〈unitConstraint〉
〈capExpr〉 ::= ‘HAS CAPABILITY’ 〈identifier〉
81
〈hierarchyExpr〉 ::= 〈reportExpr〉 | 〈delegateExpr〉
〈reportExpr〉 ::= 〈reportsExpr〉 | 〈reportedExpr〉
〈reportsExpr〉 ::= [〈depth〉] ‘REPORTS TO’ 〈positionRef 〉
〈reportedExpr〉 ::= ‘IS’ [〈depth〉] ‘REPORTED BY’ 〈positionRef 〉
〈delegateExpr〉 ::= 〈delegatesExpr〉 | 〈delegatedExpr〉
〈delegatesExpr〉 ::= ‘CAN DELEGATE WORK TO’ 〈positionRef 〉
〈delegatedExpr〉 ::= ‘CAN HAVE WORK DELEGATED BY’ 〈positionRef 〉
〈denyExpr〉 ::= ‘NOT’ ‘(’ 〈deniableExpr〉 ‘)’
〈compoundExpr〉 ::= 〈andExpr〉 | 〈orExpr〉
〈andExpr〉 ::= ‘(’ 〈RALExpression〉 ‘)’ ‘AND’ ‘(’ 〈RALExpression〉 ‘)’
〈orExpr〉 ::= ‘(’ 〈RALExpression〉 ‘)’ ‘OR’ ‘(’ 〈RALExpression〉 ‘)’
〈deniableExpr〉 ::= 〈personExpr〉
| 〈grpResourceExpr〉
| 〈commonalityExpr〉
| 〈capExpr〉
〈personConstraint〉 ::= 〈identifier〉
| ‘PERSON’ 〈dataObjIdExpr〉
| ‘ANY PERSON’ 〈taskDuty〉 〈dataObjId〉
〈posConstraint〉 ::= ‘POSITION’ 〈identifiers〉
〈identifiers〉 ::= 〈identifier〉 | 〈dataObjIdExpr〉
〈roleConstraint〉 ::= ‘ROLE’ 〈identifiers〉
〈unitConstraint〉 ::= ‘UNIT’ 〈identifiers〉
82
〈positionRef 〉 ::= ‘POSITION OF’ 〈personConstraint〉
| 〈posConstraint〉
〈dataObjIdExpr〉 ::= ‘IN DATA FIELD’ 〈dataObjId〉 ‘.’ 〈dataObjId〉
〈dataObjId〉 ::= 〈identifier〉 | 〈identifier〉 ‘.’ 〈dataObjId〉
〈amount〉 ::= ‘SOME’ | ‘ALL’
〈depth〉 ::= ‘DIRECTLY’
〈taskDuty〉 ::= ‘RESPONSIBLE FOR’
| ‘INFORMED ABOUT’
〈historyExpr〉 ::= ‘WITH’ 〈quantifier〉 ‘HISTORY ON’ 〈historyConstraint〉 ‘IN’ 〈dataObjId〉
〈historyConstraint〉 ::= ‘EXECUTION’ | ‘BEING INFORMED’
〈quantifier〉 ::= ‘LEAST’ | ‘MOST’
B.3 BW language
Listing B.3: BW BNF Grammar
〈BWSpecification〉 ::= 〈specification〉 [〈entities〉] [〈associations〉] [〈resourceAsgmt〉]
〈entities〉 ::= 〈entity〉 | 〈entity〉 〈entities〉
〈associations〉 ::= 〈association〉 | 〈association〉 〈associations〉
〈specification〉 ::= Specification: 〈string〉
〈entity〉 ::= Entity 〈identifier〉 [〈existsConstraint〉] [〈dependsConstraint〉] { [〈attributes〉]
[〈constraints〉] }
〈existsConstraint〉 ::= exists
〈dependsConstraint〉 ::= depends on 〈MultipleDOIds〉
83
〈multipleDOIds〉 ::= 〈dataObjId〉 | 〈dataObjId〉 , 〈multipleDOIds〉
〈attributes〉 ::= 〈attribute〉 | 〈attribute〉 〈attributes〉
〈attribute〉 ::= 〈dataObjId〉 : 〈identifier〉 [〈mandConstraint〉] [〈dependsConstraint〉]
〈mandConstraint〉 ::= mandatory
〈association〉 ::= Association 〈identifier〉 { 〈dataObjId〉 with 〈identifier〉 ( 〈cardinality〉 )
〈dataObjId〉 with 〈identifier〉 ( 〈cardinality〉 ) }
〈cardinality〉 ::= INT | INT .. INT | INT .. * | INT .. +
〈constraints〉 ::= 〈constraint〉 | 〈constraint〉 〈constraints〉
〈constraint〉 ::= Constraint 〈identifier〉 : 〈expression〉
〈expression〉 ::= 〈or〉 | 〈and〉 | 〈Equality〉 | 〈comparison〉 | 〈plusOrMinus〉 | 〈mulOrDiv〉 |
〈primary〉 | 〈atomic〉
〈or〉 ::= 〈and〉 OR 〈and〉
〈and〉 ::= 〈comparison〉 AND 〈comparison〉
〈comparison〉 ::= 〈plusOrMinus〉 〈compSymbol〉 〈plusOrMinus〉
〈compSymbol〉 ::= >= | > | <= | <
〈plusOrMinus〉 ::= 〈mulOrDiv〉 〈plusOrMinusSym〉 〈mulOrDiv〉
〈plusOrMinusSym〉 ::= + | -
〈mulOrDiv〉 ::= 〈primary〉 〈mulOrDivSym〉 〈primary〉
〈mulOrDivSym〉 ::= * | /
〈primary〉 ::= ( 〈expression〉 ) | NOT 〈primary〉 | 〈atomic〉
〈atomic〉 ::= 〈dataObjId〉 | INT | 〈string〉 | true | false
〈resourceAsgmt〉 ::= ResourceRules { 〈resourceRules〉 }
84
〈resourceRules〉 ::= 〈resourceRule〉 | 〈resourceRule〉 〈resourceRules〉
〈resourceRule〉 ::= 〈resourceAssign〉 | 〈entityIsPerson〉
〈entityIsPerson〉 ::= 〈identifier〉 IS PERSON
〈resourceAssign〉 ::= 〈identifier〉 〈ralConstraint〉
〈ralConstraint〉 ::= 〈ralResponsible〉 | 〈ralInformed〉
〈ralResponsible〉 ::= has responsible 〈RALExpression〉
〈ralInformed〉 ::= informs 〈RALExpression〉
85
86
CXtext Grammars
C.1 Resources’ meta-model language
Listing C.1: Resource Model xText notation
1
2 ResourceSpecification:
3 capabilities += Capability*
4 roles += Role*
5 units += Unit*
6 positions += Position*
7 persons += Person*
8 resourceRules = ResourceRules
9 ;
10
11 Capability:
87
12 'Capability' name = ID ('{' 'description' ':' description = STRING '}')?
13 ;
14
15 Role:
16 'Role' name = ID ('{' 'description' ':' description = STRING '}')?
17 ;
18
19 Unit:
20 'Unit' name = ID ('{' 'description' ':' description = STRING '}')?
21 ;
22
23 Position:
24 'Position' name = ID '{'
25 (('isMemberOf' ':' unit = [Unit]) &
26 ('description' ':' description = STRING)? &
27 ('participatesIn' ':' '{' roles += [Role] (',' roles += [Role])* '}')? &
28 ('canDelegateWorkTo' ':' '{' delegateTo += [Position] (',' delegateTo +=
[Position])* '}')? &
29 ('reportsTo' ':' reportsTo = [Position] )?)
30 '}'
31 ;
32
33 Person:
34 'Person' name = ID ('{'
35 (('description' ':' description = STRING)? &
36 ('hasCapability' ':' '{' capabilities += [Capability] (',' capabilities
+= [Capability])* '}')? &
37 ('occupies' ':' '{'occupies += [Position] (',' occupies += [Position])* '
}')?)
38 '}')?
39 ;
C.2 Resources Rules language
Listing C.2: Resource Rules xText notation
88
1 ResourceRules:
2 {ResourceRules}
3 'ResourceRules' '{'
4 relations += EntityIsPerson*
5 rules += ResourceRule*
6 '}'
7 ;
8
9 EntityIsPerson:
10 entity = [Entity] 'IS' 'PERSON' ('{'
11 persons += DataPerson (',' persons += DataPerson)*
12 '}'
13 )?
14 ;
15
16 DataPerson:
17 name = ID '[' assignments += DataAssignment (',' assignments +=
DataAssignment)* ']'
18 ;
19
20 DataAssignment:
21 field = ID '=' value = STRING
22 ;
23
24 ResourceRule:
25 datafield = QualifiedName
26 taskDuty = ResourceTaskDuty
27 expression = RALExpression
28 ;
29
30 ResourceTaskDuty:
31 ('has' 'responsible') | 'informs'
32 ;
33
34 /**
35 * RAL Expressions Grammar
36 */
37 RALExpression:
89
38 AnyoneExpr |
39 PersonExpr |
40 OrganizationalExpr |
41 HierarchyExpr |
42 NotExpr |
43 CompoundExpr |
44 CapabilityExpr |
45 HistoryExpr |
46 CommonalityExpr
47 ;
48
49 AnyoneExpr:
50 {AnyoneExpr}
51 'ANYONE'
52 ;
53
54 PersonExpr:
55 'IS' PersonConstraint
56 ;
57
58 PersonConstraint:
59 IsPersonID | IsPersonDataObject | IsPersonInDuty
60 ;
61
62 IsPersonID:
63 person = ID
64 ;
65
66 IsPersonDataObject:
67 'PERSON' 'IN' 'DATA' 'FIELD' dataField = QualifiedName
68 ;
69
70 IsPersonInDuty:
71 'ANY' 'PERSON' taskDuty = TaskDuty dataField = QualifiedName
72 ;
73
74 TaskDuty:
75 'RESPONSIBLE' 'FOR' |
90
76 'INFORMED' 'ABOUT'
77 ;
78
79 OrganizationalExpr:
80 HasPositionExpr | HasUnitExpr | HasRoleExpr
81 ;
82
83 HasPositionExpr:
84 'HAS' 'POSITION' position = [Position]
85 ;
86
87 HasUnitExpr:
88 'HAS' 'UNIT' unit = [Unit]
89 ;
90
91 HasRoleExpr:
92 'HAS' 'ROLE' role = [Role] ('IN' 'UNIT' unit = [Unit])?
93 ;
94
95
96 HierarchyExpr:
97 ReportsToPersonPositionExpr |
98 ReportsToPositionExpr |
99 ReportedByPersonPositionExpr |
100 ReportedByPositionExpr |
101 DelegatesToPersonPositionExpr |
102 DelegatesToPositionExpr |
103 DelegatedByPersonPositionExpr |
104 DelegatedByPositionExpr
105 ;
106
107 ReportsToPersonPositionExpr:
108 (directly ?= 'DIRECTLY')? 'REPORTS' 'TO' 'POSITION' 'OF' personExpr =
PersonConstraint
109 ;
110
111
112 ReportsToPositionExpr:
91
113 (directly ?= 'DIRECTLY')? 'REPORTS' 'TO' 'POSITION' position = [Position]
114 ;
115
116 ReportedByPersonPositionExpr:
117 'IS' (directly ?= 'DIRECTLY')? 'REPORTED' 'BY' 'POSITION' 'OF' personExpr =
PersonConstraint
118 ;
119
120 ReportedByPositionExpr:
121 'IS' (directly ?= 'DIRECTLY')? 'REPORTED' 'BY' 'POSITION' position = [
Position]
122 ;
123
124 DelegatesToPersonPositionExpr:
125 'CAN' 'DELEGATE' 'WORK' 'TO' 'POSITION' 'OF' personExpr = PersonConstraint
126 ;
127
128 DelegatesToPositionExpr:
129 'CAN' 'DELEGATE' 'WORK' 'TO' 'POSITION' position = [Position]
130 ;
131
132 DelegatedByPersonPositionExpr:
133 'CAN' 'HAVE' 'WORK' 'DELEGATED' 'BY' 'POSITION' 'OF' personExpr =
PersonConstraint
134 ;
135
136 DelegatedByPositionExpr:
137 'CAN' 'HAVE' 'WORK' 'DELEGATED' 'BY' 'POSITION' position = [Position]
138 ;
139
140 NotExpr:
141 'NOT' '(' expr = DeniableExpr ')'
142 ;
143
144 DeniableExpr returns RALExpression:
145 PersonExpr | OrganizationalExpr | CommonalityExpr | CapabilityExpr
146 ;
147
92
148 CompoundExpr:
149 '(' leftExpr = RALExpression ')' rightExpr = CompoundType
150 ;
151
152 CompoundType:
153 AndExpr | OrExpr
154 ;
155
156 AndExpr:
157 'AND' '(' expr = RALExpression ')'
158 ;
159
160 OrExpr:
161 'OR' '(' expr = RALExpression ')'
162 ;
163
164 CapabilityExpr:
165 'HAS' 'CAPABILITY' capability = [Capability]
166 ;
167
168 HistoryExpr:
169 HistoryExecutingExpr | HistoryInformedExpr
170 ;
171
172 HistoryExecutingExpr:
173 'WITH' quantifier = HistoryQuantifier 'HISTORY' 'ON' 'EXECUTION' 'IN'
dataField = QualifiedName
174 ;
175
176 HistoryInformedExpr:
177 'WITH' quantifier = HistoryQuantifier 'HISTORY' 'ON' 'BEING' 'INFORMED' 'IN'
dataField = QualifiedName
178 ;
179
180 HistoryQuantifier:
181 'LEAST' | 'MOST'
182 ;
183
93
184 CommonalityExpr:
185 SharesPositionExpr | SharesUnitExpr | SharesRoleExpr
186 ;
187
188 SharesPositionExpr:
189 'SHARES' amount = Amount 'POSITION' 'WITH' person = PersonConstraint
190 ;
191
192 SharesUnitExpr:
193 'SHARES' amount = Amount 'UNIT' 'WITH' person = PersonConstraint
194 ;
195
196 SharesRoleExpr:
197 'SHARES' amount = Amount 'ROLE' ('IN' 'UNIT' unit = [Unit])? 'WITH' person =
PersonConstraint
198 ;
199
200 Amount:
201 'SOME' | 'ALL'
202 ;
94
