INSTITUTO DE COMPUTAÇÃO
Sheila Katherine Venero Ferro
DW-SAAArch: A reference architecture for dynamic
self-adaptation in workflows
DW-SAAArch: Uma arquitetura de referência para a
autoadaptação dinâmica em workflows
CAMPINAS
2015
DW-SAAArch: A reference architecture for dynamic
self-adaptation in workflows
DW-SAAArch: Uma arquitetura de referência para a
autoadaptação dinâmica em workflows
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestra em Ciência da Computação.
Thesis presented to the Institute of Computing of the University of Campinas in partial fulfillment of the requirements for the degree of Master in Computer Science.
Supervisor/Orientadora: Profa. Dra. Cecília Mary Fischer Rubira
Este exemplar corresponde à versão final da Dissertação defendida por Sheila Katherine Venero Ferro e orientada pela Profa. Dra. Cecília Mary Fischer Rubira.
CAMPINAS
2015
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Venero Ferro, Sheila Katherine,
V555d VenDW-SAAArch : a reference architecture for dynamic self-adaptation in workflows / Sheila Katherine Venero Ferro. – Campinas, SP : [s.n.], 2015.
VenOrientador: Cecília Mary Fischer Rubira.
VenDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.
Ven1. Arquitetura de software. 2. Arquitetura de referência. 3. Sistemas de gestão de fluxo de trabalho. 4. Fluxo de trabalho. 5. Engenharia de software. I. Rubira, Cecília Mary Fischer,1964-. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.
Informações para Biblioteca Digital
Título em outro idioma: Dw-SAAArch : uma arquitetura de referencia para autoadaptação
dinâmica em workflows
Palavras-chave em inglês:
Software architecture Reference architecture
Workflow management systems Workflow
Software engineering
Área de concentração: Ciência da Computação Titulação: Mestra em Ciência da Computação Banca examinadora:
Cecília Mary Fischer Rubira [Orientador] Marco Aurélio Gerosa
Ariadne Maria Brito Rizzoni Carvalho
Data de defesa: 09-11-2015
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Sheila Katherine Venero Ferro
DW-SAAArch: A reference architecture for dynamic
self-adaptation in workflows
DW-SAAArch: Uma arquitetura de referência para a
autoadaptação dinâmica em workflows
Banca Examinadora:
• Profa. Dra. Cecília Mary Fischer Rubira IC/UNICAMP
• Prof. Dr. Marco Aurélio Gerosa IME/USP
• Profa. Dra.Ariadne Maria Brito Rizzoni Carvalho IC/UNICAMP
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
First, I would like to thank God for giving me the strength to complete this stage of my life and for all graces and blessings.
I could never have done any of this, particularly the research and writing that went into this dissertation, without the support and encouragement of a lot of people whose names may not all be enumerated. Their contributions are sincerely appreciated and gratefully acknowledged. However, I would like to express my deep appreciation particularly to the following people:
To my supervisor, Prof. Cecilia Mary Fischer Rubira, whose expertise, understanding, generous guidance and support made possible this work.
To the jury members of my dissertation, Prof. Marco Aurelio Gerosa and Prof. Ari-adne Maria Brito Rizzoni Carvalho for the constructive suggestions and useful critiques that helped me to improve this dissertation.
To my family, especially to my parents, for their unconditional love and support at all times.
To Eduardo, for the long talks, his patient guidance, the enthusiastic encouragement and his countless love.
To all my friends who in one way or another helped me in this stage of my life. I would also like to thank the CNPq for the financial support during this research.
Atualmente muitas organizações usam diferentes tipos de sistemas de informação orienta-dos por processos (Process-Aware Information System-PAIS) para suportar seus processos. Um exemplo típico de tais sistemas são os Sistemas de Gerenciamento de Workflows (work-flow management systems-WFMSs), que automatizam parcial ou totalmente os processos de negócios. Sistemas tradicionais de gerenciamento de workflows geralmente trabalham com processos bem estruturados e, normalmente, com atividades previsíveis e repetitivas. No entanto, os processos de negócios atuais, devido à sua alta complexidade e à cons-tante mudança do seu meio ambiente ou contexto, são obrigados a serem flexíveis com o objetivo de reagir as mudanças previsíveis ou mesmo imprevisíveis. Um dos maiores inconvenientes dessas plataformas de workflows é que elas geralmente não podem adaptar dinamicamente os processos de negócio de acordo com situações novas ou inesperadas.
Portanto, existe uma necessidade de expandir o comportamento dinâmico dessas so-luções computacionais. Para resolver o problema, uma arquitetura de referência para sistemas de gerenciamento workflows chamada “DW-SAAArch” foi desenvolvida. A ar-quitetura permite a auto-adaptação em workflows em nível da lógica de negócios que visa tratar o comportamento excepcional causado pelo resultado de uma violação de uma regra de negócio, por um problema relacionado com o conteúdo dos dados ou por um comportamento inesperado no processo de negócio. DW-SAAArch fornece suficiente fle-xibilidade para adaptar dinamicamente os fluxos de trabalho em tempo de execução. A fim de validar nossa proposta, uma prova de conceito foi realizada no domínio da enferma-gem, selecionamos um cenário real de enfermagem para mostrar a aplicabilidade prática da arquitetura de referência proposta e os resultados mostraram que a arquitetura de referência suporta com sucesso adaptações lógicas de negócio em workflows.
Today several organizations use many kinds of Process-Aware Information Systems to support their processes. A typical example of such systems is the workflow management systems (WFMSs). Business processes are partially or totally automated by these tech-nologies. Traditional WFMSs usually work with well-structured processes and typically for predictable and repetitive activities. However current business processes, due to their complexity and the continuous changes in the environment are often required to be flexi-ble in order to reflect foreseeaflexi-ble or unforeseeaflexi-ble changes in the environment. One of the drawbacks of these workflow platforms is that they usually cannot adapt their processes dynamically according to new or unexpected situations.
There is a need to expand the dynamic behavior of these computational solutions. To address the problem, a reference architecture for workflow management systems called “DW-SAAArch” was developed. The reference architecture allows self-adaptation in work-flows at the business logic level treating exceptional behavior caused by the result of a break of a business rule, a constraint violation, a data issue, or an unexpected business behavior. DW-SAAArch provides enough means of flexibility to dynamically adapt the workflows during runtime. In order to validate our solution, a proof of concept was con-ducted in the nursing domain. We selected a real nursing scenario to show the practical applicability of the proposed reference architecture. The results show that the reference architecture successfully supports business logical adaptations in workflows.
1.1 Research Methodology . . . 15
2.1 Relationships between the basic terminology of WFMS . . . 18
2.2 Workflows System Characteristics . . . 19
2.3 Generic Workflow Product Structure . . . 20
2.4 Workflow Reference Model - Components & Interfaces . . . 22
2.5 Transition scheme for process instances . . . 23
2.6 Types of flexibility in processes . . . 24
2.7 Hierarchy of self-* properties . . . 28
2.8 Constituent parts of a self-adaptive software system . . . 28
2.9 Activities of a Control Loop . . . 29
2.10 IBM’s MAPE-K reference model . . . 30
3.1 PRISMA Diagram . . . 37
3.2 Simplified conceptual map . . . 40
4.1 DW-SAAArch: Reference Architecture . . . 51
4.2 Main phases of the dynamic workflow adaptation . . . 52
4.3 Sequence Diagram for workflow adaptation . . . 57
5.1 Nursing processes by Wanda Horta. . . 60
5.2 Business Process of the Nursing Processes . . . 61
5.3 Systematic way for the Health Status Research . . . 62
5.4 Activity Diagram for the Nursing Processes . . . 66
5.5 Activity Diagram for researching the health status . . . 67
5.6 Activity Diagram for the Diagnosing the health status . . . 68
5.7 DW-SAAArch for the Nursing Domain . . . 69
5.8 Sequence Diagram for the Nursing Process . . . 72
3.1 Search query for “Workflow” as a main concept in IEEE database. . . 36
3.2 Search query for “Business Process” as a main concept in IEEE database. . 36
3.3 Complete query for the research in IEEE database. . . 36
3.4 Synthesis of the literature review . . . 38
5.1 Nursing Diagnosis, Intervention and Evaluation -1st Iteration . . . 75
5.2 Nursing Diagnosis, Intervention and Evaluation -2nd Iteration . . . 78
5.3 Nursing Diagnosis, Intervention and Evaluation -3rd Iteration . . . 81
1 Introduction 13
1.1 Motivation . . . 13
1.2 Context and Problem Statement . . . 13
1.3 Proposed solution . . . 14
1.4 Research methodology . . . 15
1.5 Organization . . . 15
2 Background 17 2.1 Processes, Business Processes, and Workflows . . . 17
2.2 Workflow Management Systems . . . 18
2.2.1 General Implementation Model . . . 20
2.2.2 Reference Model for Workflow Management Systems . . . 21
2.3 Process-Aware Information System (PAIS) . . . 23
2.3.1 Flexibility in Processes . . . 24
2.3.2 Processes Adaptation . . . 26
2.4 Self-Adaptive systems . . . 27
2.4.1 Components of a self-adaptive system . . . 27
2.4.2 Control loops . . . 28
2.4.3 MAPE-K . . . 29
2.5 Reference Architecture . . . 30
2.6 Intelligent Agents . . . 31
2.7 Computational Reflection and Meta-level Architectures . . . 32
2.8 Architectural Patterns . . . 32
3 State of the Art 34 3.1 Systematic literature review . . . 34
3.2 PRISMA . . . 35
3.3 Adaptation Approaches . . . 38
3.3.1 Managing uncertainty . . . 41
3.3.2 Analyzing the necessity to adapt . . . 42
3.3.3 Workflow reconfiguration . . . 43
3.3.4 User Demand . . . 44
3.3.5 Monitoring Exceptions and allocation of resources . . . 45
3.4 Conclusions of the Literature Review . . . 46
4 DW-SAAArch: Reference Architecture 48 4.1 Architectural Requirement Establishment . . . 48
4.2 Decisions for the Architectural Design . . . 49
4.4.2 The Adaptation layer . . . 54
4.4.3 Instance Manager Layer . . . 56
4.4.4 Acquisition and Implementation Layer . . . 56
4.5 Sequence for workflow adaptation . . . 56
5 Proof of Concept: The Nursing Process 58 5.1 Methodology Approach . . . 58
5.2 Description of the evaluation plan . . . 58
5.3 Motivation . . . 59
5.4 The Nursing Process . . . 60
5.4.1 Nursing Data Collection or Nursing History (Step1) . . . 62
5.4.2 Nursing Diagnosis (Step 2) . . . 64
5.4.3 Nursing Planning (Step 3) . . . 65
5.4.4 Implementation (Step 4) . . . 65
5.4.5 Nursing Evaluation (Step 5) . . . 65
5.5 Evaluation of the Architecture . . . 66
5.5.1 Simulation of a Real-life Medical Scenario . . . 73
5.5.2 Threats of validity . . . 85
5.6 Results and Discussions . . . 86
6 Conclusions 88 6.1 Research Summary . . . 88 6.2 Contributions . . . 89 6.3 Limitations . . . 90 6.4 Future perspectives . . . 90 Bibliography 91
Introduction
This chapter describes the motivation of this research, explains the context and the prob-lem, briefly describes our solution and research methodology and, finally, presents the organization of the dissertation.
1.1
Motivation
As it is known, the business process is one of the most important instruments of an enterprise, it realizes the business goal. A business process consists of a set of activities that are performed in coordination of an organizational and technical environment [77]. Normally, this set of activities is modeled based on their outputs so that the activities are partially or completely ordered. However, what happens if during the process execution something in the environment changes or a task fails and its execution produces not well-defined results? The process cannot continue to run until it is modified. Thus, there is a necessity of adapting the process so it can handle these new situations and exceptional conditions.
This problem is a big challenge when we talk about process automation. Modeling all the possible situations at design time becomes an extremely difficult or almost impossible task. Business analysts model “normal” circumstances, common deviations or situations likely to happen, but it is impossible to think in every potential scenario or predict unforeseen events. According to Bidder [11], it is possible to predict at most 90% of the circumstances that may happen.
On the other hand, the process adaptation is not an easy task; it requires experience and knowledge,and, therefore, the presence of a business expert becomes essential. Only a business expert is capable of making changes in the process instance to handle these particular situations.
1.2
Context and Problem Statement
Nowadays, the organizations in public administration, business, education, science and engineering work with several computer applications. These institutions monitor and control their processes through different information technologies which provide not only
automation, but also help them with the organizational structure, especially on coordi-nating human activities and data management [62].
Various types of Process-Aware Information Systems are used by the organizations to support their processes. Workflow management systems (WFMSs) are typical examples of such systems [1]. These systems are designed to support business processes that consist in a number of activities that can be executed automatically, manually, or a combination of both; they automate business processes partially or totally. WFMSs define, create, and manage the execution of workflows through software, executing one or more workflow engines that allow process definition, user interaction, and provide means to invoke IT tools and other applications [76].
Traditional workflows management systems usually work with well-structured cesses and typically for predictable and repetitive activities [22]. However, modern pro-cesses often are required to be flexible in order to reflect foreseeable or even unforeseeable changes in the environment. Thus, WFMSs face some limitations in terms of flexibility: they do not support to adapt workflows dynamically or sometimes support them in a rigid manner [1].
Lately adaptability in workflow technology is one of the hot topics in the academic world [69]. Nevertheless, just a few approaches treat adaptation at the business logic level. Most of the approaches deal adaptation at the technological or performance level, treating exceptional behavior caused by errors in the application or errors in the infrastructure or middleware components on which the process runs. This research is focused on dynamic adaptation in workflows at the business logic level, treating exceptional behavior caused by the result of a breach of a business rule, a constraint violation, a data issue, or an unexpected business behavior.
Solving the limitation of flexibility of the workflow management systems, it would be possible to adapt the execution of a process, so it could cope with unexpected situations and conditions. This research proposes a reference architecture to provide flexibility to workflow management systems. This study aims to answer two research questions: (i) Does the architecture provide means to adapt the workflow under new circumstances or unexpected behaviors during the workflow execution? (ii) What kind of changes does the architecture support?
1.3
Proposed solution
To overcome the limitation of workflow management systems discussed earlier, we propose with this research a reference architecture for workflow management systems that will provide means of flexibility to adapt processes at the business logic level, to dynamically reconfigure workflows at runtime aiming to support foreseen and unforeseen changes or exceptional behavior. This research is focused on the adaptation layer.
The reference architecture, called “DW-SAAArch”, is based on self-adaptive systems. Our knowledge-based approach uses the concept of intelligent agents and follows the autonomic MAPE-K loop for making decisions at runtime aiming to solve business logical adaptations.
This reference architecture facilitates and guides the design of concrete architectures for supporting self-adaptation in workflow management systems. It provides a powerful tool to deal with uncertainty in the processes due to the continuously changing environ-ment because, it will help business experts during the decision-making process to cope with new situations. We hope with this work to cause an impact in the way that enter-prises manage their processes, and to help them in maintaining their leadership in the business world.
1.4
Research methodology
It is a qualitative research that uses a proof of concept. In this research, the proof of concept was developed as a case study but with data of the literature. Figure 1.1 shows the major phases of the research.
Figure 1.1: Research Methodology
The first stage was the definition of the problem; secondly a literature review was conducted in order to find out the state of the art, the current approaches that deal with process adaptation at the business logic level. After the analysis of the existing approaches, we have designed of the novel architecture for dynamic self-adaptation of workflows. Finally, a proof of concept was conducted in order to evaluate the feasibility of the proposed architecture in the nursing domain.
1.5
Organization
This dissertation is organized as follows: Chapter 2 introduces the basic concepts used in the remaining chapters. Chapter 3 shows the state of the art and presents the literature review. Chapter 4 shows the proposed reference architecture and its features. Chapter 5 describes the evaluation of the proposed solution by means of a proof of concept in the
nursing domain. And finally, Chapter 6 concludes the dissertation by evaluating what has been achieved and making some proposals for future work.
Background
In this chapter, we present and discuss topics that provide the foundation to this work. The four first sections will help us to understand the basic concepts related to processes, business processes, workflows, workflows management systems, process-aware information systems, flexibility and adaptation in processes and self-adaptive systems. The next sections present the concept of a reference architecture and the concepts used in the design of our reference architecture such as intelligent agents, computational reflection and some architectural patterns.
2.1
Processes, Business Processes, and Workflows
The ISO 9000 2015 defines a process as “a set of activities that are interrelated or that interact with one another. Processes use resources to transform inputs into outputs. Processes are interconnected because the output from one process often becomes the input for another process. [...] Sometimes inputs become outputs without transformation”.
According to Davenport [21], “a process is simply a structured, measured set of ac-tivities designed to produce a specified output for a particular customer or market [...] a specific ordering of work activities across time and space, with a beginning, an end, and clearly identified inputs and outputs: a structure for action”.
Thus, a process is a set of interrelated activities that interact together in order to achieve some outcome. There are processes everywhere and in every aspect of life. Pro-cesses can be governmental, administrative, industrial, agricultural, medical, physical, chemical, computational, mechanical, electrical, and so on.
According to Hammer and Champy [28], “A business process is a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer. A business process has a goal and is affected by events occurring in the external world or in other processes”. According to Weske [77], “A business process consists of a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal. Each business process is enacted by a single organization, but it may interact with business processes performed by other organizations”.
So, a business process is a sequence of related processes or activities which collectively
realize a business objective, normally within a specific organizational context but can also be affected by events in the external world. Business process activities can be performed manually or by information systems [77].
According to Hollingssworth [32], “A workflow is a computerized facilitation or au-tomation of a business process, in whole or part”. Weske [77] says that “Workflow is the automation of a business process, in whole or in part, during which documents, informa-tion, or tasks are passed from one participant to another for acinforma-tion, according to a set of procedural rules”. So, the automation of a Business Process is a workflow.
2.2
Workflow Management Systems
Workflow Management means to deliver the right data to the adequate person with the right tool at the right time. So, a Workflow Management System (WFMS) is a software system that completely defines, manages and executes workflows in a specific order of execution according to the business logic [32].
Workflow technology supports business processes within a given application system or between a set of application systems in which humans are actively involved. It improves the collaboration among the knowledge workers.
Figure 2.1: Relationships between the basic terminologies of WFMS [79].
Weske [77] defines “A workflow management system is a software system that defines, creates, and manages the execution of workflows through the use of software, running
on one or more workflow engines, which is able to interpret the process definition, in-teract with workflow participants, and, where required, invoke the use of IT tools and applications”.
Figure 2.1 shows the relationships between the basic terminologies of WFMS. A WFMS should provide support for the following functions [32]:
• Build-time functions, to define and model the business process and its activities translating them from the real world into a formal computerized representation. There exist many languages for process definition.
• Run-time control functions, to manage the workflow processes in an active environ-ment.
• Run-time interactions with users and IT application tools for processing the activi-ties
Figure 2.2 illustrates the basic characteristics of WFMS and the relationships between those main functions.
2.2.1
General Implementation Model
To construct a model for a workflow system, it is necessary to identify its main functional components. Figure 2.3 shows the major functional components of a generic workflow system [32]:
• Software Components for providing support to the functions within the workflow system (shown in dark fill)
• System definition and control data used by one or more software components (shown unfilled)
• External applications and Application Databases that may be invoked(shown in light fill)
Figure 2.3: Generic Workflow Product Structure [32]
The roles of the major functional components in a workflow system are described as follows [32]:
• The process Definition Tool: it is used to create the process description in a computer processable form.
• Process Definition: it contains all necessary information about how to execute the process in the workflow enactment software. It includes starting and completion conditions, constituent activities and rules, user tasks to be assumed, references to applications which may be invoked, definition of any workflow relevant data which may need to be referenced, etc.
• The workflow enactment software: it interprets the process description and controls the instantiation of processes and sequencing of activities, adding work items to the user work lists and invoking application tools when necessary. The workflow enactment service maintains internal control data either centralized or distributed across a set of workflow engines.
• Workflow Relevant Data and Application Data: data generated or updated by workflow application programs, it is also known as case data. This data is accessible to the workflow engine, and it is manipulated directly (and only) by the invoked applications.
• Worklists: a queue where the user interactions needed in the process execution are placed. They may be invisible or visible for users.
• Worklist Handler & User Interface: the worklist handler is a software compo-nent which manages the interaction between workflow participants and the workflow enactment service. Workflow engines also support other interactions with client ap-plications, including sign-on and -off of workflow participants, requesting the com-mencement of an instance of particular process types, requesting work items queued for particular participants, etc.
• Supervisory Operations: These operations allow supervisors to modify work allocation rules, identify participants for specific roles, track alerts or trace the historic of a particular process instance, etc. For distributed workflow engines, some specific commands to transfer such control operations may be needed.
• Exposed and Embedded Interface: there is a need of interfaces that allow interoperability with other workflow systems.
2.2.2
Reference Model for Workflow Management Systems
In the last years, the Workflow Management Coalition (WfMC) has defined a standard to identify the main characteristics, functions, and interfaces of workflow management systems.
Figure 2.4 shows the proposed Reference Model which specifies five APIs that sur-round a workflow engine. These APIs provide standard means of communication between workflow engines and a workflow clients (other workflow components, such as process definition and monitoring tools).
Figure 2.4: Workflow Reference Model - Components & Interfaces [32]
In this model, there is a logical separation between the process and the activity control logic which is responsible of the workflow enactment service, and the applications and end user tasks for processing those activities.
The workflow enactment service provides a runtime environment in which one or more workflow management engines create, manage and execute workflow instances and interact with external resources by means of workflow application programming interface.
Several functions can be handled by the workflow engine, including interpretation of the process definition, control of process instances, navigation between process activities, sign-on and sign-off of specific participants, identification of work items for user attention and an interface to support user interactions, maintenance of workflow control data and workflow relevant data, passing workflow relevant data to/from applications or users, an interface to invoke external applications and link any workflow relevant data, supervisory actions for control, administration and audit purposes.
The workflow enactment service may be considered as a state transition machine, where an individual process or activity instances change states in response to external events. Figure 2.5 shows a transition scheme for process instances.
The Workflow Enactment Service interacts with the external resources by the following interfaces:
• Workflow Definition Interchange (Interface 1), the interface between the mod-eling and definition tools and the runtime workflow management software is called the process definition importexport interface.
Figure 2.5: Transition scheme for process instances [32]
Workflow engine interacts with the Worklist handler, responsible for organizing the user interaction with the instanced process. It is the responsibility of the Worklist handler to choose and advance each element of the worklist.
• Invoked Application Interface (Interface 3), which allows the Workflow engine to activate a tool to perform a particular activity. This interface may be based on a server; there is no interaction with the user.
• Interoperability Functions (Interface 4) provides communication between het-erogeneous workflow systems.
• Administration & monitoring Interface (Interface 5) provides operations such as user management, role management, audit management, resource control, process supervisory functions, etc.
2.3
Process-Aware Information System (PAIS)
A Process-Aware Information System is a software system that manages and executes operational processes involving people, applications, and/or information sources on the basis of process models [24].
PAIS separates the processing logic from the application code. Thus, at design time the processing logic has to be explicitly defined by a meta-model. At runtime, PAIS orchestrates the process and coordinates process applications and other resources [74]. It provides generic services for process modeling, process execution, process monitoring, and user interaction.
Examples of PAISs include workflow management systems, case handling tools, and service orchestration engines. A workflow management system can be seen as a particular kind of PAISs with an emphasis on process automation rather than redesign and analysis [1].
One of the biggest challenges of PAIS is the adaptability. Today WFMS and other PAIS do not have means to provide sufficient flexibility, so they cannot support dynamic changes in business processes [1].
2.3.1
Flexibility in Processes
Regev and Wegmann [55] define flexibility as the ability to yield to change without disap-pearing, without losing identity. In Processes, flexibility is defined as the ability to deal with both foreseen and unforeseen changes, adapting or varying the affected parts of the business process and maintaining the essential form of the parts not impacted [60].
In the literature, it can be identified different concepts and types of flexibility in pro-cesses, it is with regard to the types of changes it enables. Figure 2.6 shows the taxonomy proposed by Regev, Soffer and Schmidt [54], it includes three orthogonal dimensions: the abstraction level of the change, the subject of change, and the properties of the change.
• By the abstraction level of change. It is divided in two: type and instances. Process Type evolution refers to the process model, a change in the process type should be reflected in all instances. Process instance change is referred to deviations of one or more instances because exceptional situations.
• By the subjects of change. It can be differentiated five basic perspectives: The functional perspective describes what the process has to do, define the goal. The operational perspective describes what activities have to be executed during the process. The behavioral perspective defines, when and under which preconditions activities are performed. The informational perspective defines which information shall exchange between activities. The organizational perspective defines who par-ticipates as well as the roles they take in the process. Additional perspectives might be added for business processes in special environments.
• four properties of change are considered: the extent, the duration, the swiftness and the anticipation of change
Kumar and Narasipuram [37] distinct two types of business process flexibility: Pre-Designed Flexibility and Just-in-Time Responsive Flexibility. The Pre-Design flexibility is made at the design time by the process designer and the Just-in-Time Responsive Flexibility is created on the fly by the process manager at runtime who requires some kind of intelligence to deal with the change. These two types of flexibilities depend on the nature of the variability of the environment, the underlying reason or stimulus for flexibility.
According to the type of stimulus, [37] defines four types of flexibility:
• Constant refers to a constant stimulus with no variations and a fixed response. • Uncertain but crisply predefined refers to pre-identified changes with a certain
probability of occurrences, so possible paths are defined at design time.
• Ambiguous refers to the difficulty of identifying the stimulus from a finite set of fuzzy stimuli after it is identified by an expert, it is chosen a respective path for the stimulus.
• Surprise refers to an unforeseen stimulus at design time, a new response path must be added by an expert.
According to Schonenberg et al. [60] the flexibility types can be classified as follows: • Flexibility by Design, design alternative execution paths within a process model
at design time. The selection of the most appropriate path is made at runtime for each process instance.
• Flexibility by Deviation, a process instance might temporarily deviate at runtime from the execution path prescribed in order to deal with changes in the environment, without altering the process model.
• Flexibility by Underspecification, the ability to execute an incomplete process model at run-time. Because of the insufficient information about an instance at design time, it cannot be known what the specific contents or tasks that should be performed, so the process cannot be complete. At runtime, more execution paths will be incorporated within the existing process model. The Placeholders (variable points marked as underspecified) should be defined a priori. Ex. Late binding, late modeling.
• Flexibility by Change, the ability to modify a process model at run-time. This means to migrate all current process instances to the new process model. Some events cannot be addressed by temporary deviations and require the addition or removal of tasks in the process model on a permanent basis.
We can conclude that flexibility in processes is the capability to adapt processes to foreseen or unforeseen variations or changes in order to meet its primary goal, without replacing it completely. As we can see there are various ways to classify flexibility accord-ing to different perspectives.We want to point out the followaccord-ing types of flexibility as the more significant:
• Flexibility in the process model or in the instances (temporal or evolutionary); • Flexibility at design time or at runtime (foreseen changes by selection within a set
of paths or unforeseen changes by modeling new paths with an expert); • Flexibility according to the subject.
The concept of flexibility leads to the concept of process adaptation.
2.3.2
Processes Adaptation
Weber, Sadiq and Reichert [74] define adaptation as the ability of the implemented pro-cesses to cope with exceptional circumstances, for anticipated and unanticipated excep-tions which usually are addressed through structural changes of single process instances.It is the ability to adapt the process and its structure to cope with an emerging event.
An exception is an event that deviate a process from its normal course. An exception can happen because of a business fault or a technological fault [25]. A business fault is a fault that occurs within the business process, caused by the result of a breach of a business rule, a constraint violation, a data issue, or an unexpected business behavior. On the contrary, a technological fault is caused by errors in the application or errors in the infrastructure or middleware components on which the process runs.
Process adaptation can occur at design time or at runtime. At design time, the process is created as a template by the process manager who is responsible for creating different paths to be chosen at runtime; this kind of adaptation is explicit because changes are anticipated before execution. At runtime, a large number of process instances are created from the predefined process template, during their execution exceptional or unplanned situations could happen because of the highly dynamic and complex environment.
Adaptation in processes can be either reactive or predictive. Reactive adaptation refers to the need of adaptation for a task that is about to be executed after experiencing a variation. Predictive adaptation refers to an anticipation of a variation or changes, it analyzes the executing workflow further down and adapts the affected part of workflow in advance [47].
2.4
Self-Adaptive systems
A self-adaptive system adjusts its artifacts or attributes in response to changes. To accom-plish its goal, it should monitor the software system (self) and its environment (context) to detect changes, make decisions, and act appropriately. The basis of self-adaptive software is the adaptation of dynamic/runtime changes [59]. This kind of software tries to fulfill its requirements at runtime in response to changes [36]. These systems make decisions on their own, using high-level rules and policies. They constantly check and optimize their status and automatically adapt themselves to changing conditions, keeping the system’s complexity invisible to the user and operators.
According to Kephart and Chess [36], to contemplate the systems goals they should have some features known as self-* properties:
• Self-configuration, it is the ability for automatic configuration of components according to high-level goals.
• Self-optimization, it is the ability for automatic monitoring and control of re-sources to ensure the optimal functioning. The system may decide to initiate a change into the system proactively in an attempt to improve performance or quality of service.
• Self-healing, it is the ability of automatic detection, diagnosis, correction, and recovery of faults.
• Self-protection, it is the ability to identify and protect from malicious attacks but also from end-users who inadvertently make software changes.
Salehie and Tahvildari [59] discuss these properties along with some others and pro-vides a unified hierarchical set, Figure 2.7 describes a hierarchy of self-* properties in three levels. In this hierarchy, self-adaptiveness is in the general level, which is decom-posed into major and primitive properties at two different levels. The primitive properties are Self-awareness and Context-Awareness. Self-awareness means aware of its self-states and behaviors according to [30] and context-awareness means aware of its context its operational environment according to [52].
2.4.1
Components of a self-adaptive system
According to Weyns et al. [78] a self-adaptive system is constituted of a managed subsys-tem and managing subsyssubsys-tem, as it can be seen in Figure 2.8. The managed subsyssubsys-tem
Figure 2.7: Hierarchy of self-* properties [59]
comprises the application logic that provides the system’s domain functionality. The managing subsystem comprises the adaptation logic that deals with one or more concerns in its operating environment. In others words, the managing subsystem manages the managed subsystem. Other higher layers can be added to the system; consequently, a managing subsystem can be managed by another managing system.
Figure 2.8: Constituent parts of a self-adaptive software system [78]
2.4.2
Control loops
Control loops are crucial elements to realize the adaptation of software systems. A control loop typically involves four key activities, as it can be seen in Figure 2.9: collect, analyze,
Figure 2.9: Activities of a Control Loop [23]
decide, and act [23]. The data about the current state is collected from the executing system and its context. These data is analyzed in order to decide how to adapt the system to reach a desirable state. This feedback helps to reduce the effects of uncertainty which appear in different forms as disturbances or noise in variables or imperfections in the models of the environment [17].
In this context, the major contribution of feedback loops cames from IBM‘s autonomic computing initiative [23]. They proposed the notion of an autonomic element as a building block for self-managing systems, using MAPE-K (monitor-analyze-plan-execute over a knowledge base)[34].
2.4.3
MAPE-K
MAPE-K is a reference model for autonomic control loops suggested by IBM [34]. It is a logical architecture that defines the main architectural blocks for building an autonomic manager either in a monolithic or distributed approach. See Figure 2.10.
The MAPE-K has its name from the main tasks in the feedback control loop of self-adaptive systems, described as follows [34]:
• Monitor, it collects information from the managed resources. The monitor function aggregates, correlates and filters the information until it determines a symptom that needs to be analyzed.
• Analyze, it performs complex data analysis and reasoning on the symptoms pro-vided by the monitor function. This analysis is made with stored knowledge data. If there is a need for changes, the request is logically passed to the plan function. • Plan, it structures the actions needed to achieve goals and objectives. The plan
Figure 2.10: IBM’s MAPE-K (Monitor, Analyse, Plan, Execute, Knowledge) reference model for autonomic control loop [34]
function creates or selects a procedure to enact a desired alteration in the managed resource to cope with the new situation.
• Execute, it carries out the adaptation, changes the behavior of the managed re-source using effectors based on the actions recommended by the plan function. • Knowledge, standard data shared among the monitor, analyze, plan and execute
functions. The shared knowledge includes data such as topology information, his-torical logs, metrics, symptoms, and policies. Knowledge is created by the monitor part, and execute part might update the knowledge.
An autonomic manager administrates itself changing its internal rules in order to stop or remedy an unsatisfactory situation. In the MAPE-K autonomic loop, the managed element represents any software or hardware resource.
2.5
Reference Architecture
According to Bass et al. [9], a reference architecture is a reference model mapped onto soft-ware elements and the data flows between them. These softsoft-ware elements work together in order to implement the functionality of the reference model. A reference architecture is a generic architecture that provides the foundation to design future concrete architectures [7].
[49] states a reference architecture facilitate and guide: • The design of concrete architectures for new systems • The extensions of systems of neighbor domains
• The evolution of derived systems
• The improvement in the standardization and interoperability among different sys-tems.
A reference architecture reuse and share the knowledge about software development in a specific domain, in particular with regard to architectural design. It must address the business rules, architectural styles, best practices of software development and the software elements that support the development of systems for that domain [48].
Our reference architecture uses Intelligent agents to construct the major components of the architecture and the following architectural patterns to design its structure.
2.6
Intelligent Agents
Shoham [63] claims that an agent is an entity that possesses attribute states, called mental states. The usual mental states are beliefs, decisions, skills, goals, intentions, commitments and expectations, concepts analogous or similar to humans. Thus, any hardware or software component can be considered an agent if it can be analyzed and controlled in terms of these mental states.
Jennings [35] define an agent as a persistent software entity dedicated to a specific purpose that can simulate a human behavior.
According to Wooldridge, there is not a universally accepted definition of the term agent. Part of the difficulty in defining the term is because different application domains attribute different levels of importance to the agent. For instance, some application domains give great importance to the learning ability but for others this ability may not only unimportant but also undesirable. Nevertheless, he states that there is a general consensus that autonomy is the central idea of the notion of an agent [75].
In this research, we assume that an agent is an autonomous software entity situated in some environment where it takes autonomous actions to achieve its goals. It is capable of making decisions to proactively or reactively respond changes in its environment in real-time [81].
According to Wooldridge and Jennings [82], agents are:
• Autonomous, because they operate without direct human intervention and control their internal states.
• Social, because they interact with human and other agents
• Reactive, because they perceive changes in the environment and respond to it in a timely fashion
• Proactive, because they take the initiative to satisfy its goals, and have a goal-directed behavior.
2.7
Computational Reflection and Meta-level
Architec-tures
In this research, we use the Computational reflection which is the ability of a system to watch its own computation and possibly change the way it performs [40]. Reflection consists of two causally connected layers: the base-level layer that deals with the functional aspect of the system, and the meta-level layer that deals with the non-functional aspect [15].
The base-level agent perceives and modifies a given environment. Base-level actions achieve the goal of the system.The meta-level agent operates in an enlarged environment that includes the base-level agent. It observes the base-level agent, decides the ideal actions to achieve its goals, and finally it modifies the base-level agent so that it performs those actions [27].
The Meta-Level Architecture is a knowledge engineering approach that tries to specify control in a software system. The central idea in the meta-level architecture is to use a declarative language for describing the system behavior.
2.8
Architectural Patterns
The architectural patterns provide reusable solutions to software design problems. They express structural organization schemas for software systems and provide a set of prede-fined subsystems, specifying their responsibilities, rules and guidelines for organizing the relationships between them [14].
There are various architectural patterns, we just mention those patterns used in the creation of the reference architecture.
• Layered Pattern is the most common architecture pattern in which components are organized into horizontal layers. Each layer has a specific role and responsibility within the application. Every layer is encapsulated and can evolve independently [14]. The maintainability is the main benefit of this pattern; other benefits can be easier reuse, dependencies between layers can be reduced, a layer can easily be swapped with other implementations of that layer, etc.
• Shared Repository pattern consists of maintaining all data in a central reposi-tory shared by all functional components of the data-driven application. This data triggers and coordinates the control flow of the application logic, so other compo-nents can react if this data changes. If a component creates new data, or if the application receives new data from its environment, it is also stored in the shared repository. This data must be synchronized [14]. One of the major benefits of this pattern is that there are no direct interactions with the components of the system which facilitates the change and the revision of the repository without affecting other parts of the system.
• Reflection Pattern supports a high degree of runtime flexibility in a software architecture. It specifies properties, application’s structure, behavior, and status
into a set of meta-objects. The meta-objects are separated from the core application logic through two-layer architecture: a meta level contains the meta-objects, a base level the application logic. It provides a meta level with a meta-object protocol, which is a specialized interface to dynamically configure and modify all meta-objects under the supervising control of the application. The base-level objects first consult an appropriate meta-object before they execute behavior or access state that can vary potentially [14].
State of the Art
This section describes the current state of dynamic adaptation in the context of processes. In order to discover consistent bibliographic information of the topic of interest, it was made a Systematic Review.
3.1
Systematic literature review
The objective of performing a literature review is to analyze and discuss published papers in a specific scientific area to identify how the different approaches deal with this specific issue.
Moher et al. [44] define that a systematic review is a review that uses systematic and explicit methods to identify, evaluate, select and synthesize high-quality information about a research question of a specific topic.
Petticrew and Roberts [41] define systematic review as a set of scientific methods that try to limit the systematic error in order to identify, analyze, and synthesize better all relevant studies of a given subject or a particular issue. Also, systematic reviews are particularly valuable for analyzing all the evidence of a particular issue, when there is uncertainty about the answer. If it is unclear whether a particular intervention is effective, then, a systematic review of available evidence can help to solve the problem.
The methodology used to perform the systematic review in this research is based on strategies of the framework PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) [44]. The main objective of PRISMA is to help researchers to improve the reporting of systematic reviews and meta-analyses. This process has four main stages: identification, screening, eligibility, and included [44].
Although systematic literature reviews are executed in practice by more than one person in order to minimize subjectivity, the fact that it is performed by a single person does not invalidate the method; because besides offering a good sense of directions about how to search and find papers, it guarantees a search without bias with respect to the question asked.
3.2
PRISMA
The main topic of this research is “dynamic adaptation in workflows/business processes”. In our research, we define “dynamic adaptation” as the ability of workflows to change or react according to its environment or context. Thus, our research question will be “How the adaptation in workflows/business processes is performed?” to cover the major quantity of papers that deal with this problem.
In order to find relevant information to thoroughly understand the research topic, it was combined using boolean operators the keywords “workflows” or “business process” with the related concepts of “adaptation” and “dynamic”, in addition to “workflow system”. The search strategy was predetermined so that the main concepts such as “workflow” or “business process” will be contained in the title field and the concepts related to “adap-tation”, such as adapt*, reschedul*, reconfigur*, “dynamic adap“adap-tation”, “context-aware”, “readjusting workflows”, “readjusting business processes”, “agent”, “knowledge based pro-cess management”, “workflow management software”, “auto adaptation”, “auto manage-ment”, “self-adaptive workflow”, “self-adaptive business process” will be contained in the abstract field and will be combined with the boolean operator “OR”. We also added some other words that we consider might improve our search.
This search strategy was repeated in major databases of the area of computer science: IEEE, ACM and Science Direct. As PRISMA suggests, Tables 3.1, 3.2 show the detailed search strategy for the IEEE database showing a meaningful difference related to the amount of the found papers between the concepts of “workflow” and “business processes”. Table 3.3 shows the total amount of papers with both concepts.
In a previous conducted research, it was possible to identify two predominant kinds of adaptations in workflows: the performance type and the logical type. The Per-formance type is the adaptation at the perPer-formance level or system/software level; it is related to problems like resource allocation, service composition, service binding, failures in the system, etc. On the other hand, business logical adaptations treat structural aspects such reconfiguring the sequence of the workflow according to some knowledge, adding or removing new activities in order to cope with new situations, all of it in a higher level. The focus of this research is to study logical adaptations, so it is the major inclusion criterion.
Another criterion was to find whether studies handle adaptation at running time, this characteristic is very important because of the dynamism of the business processes. Also, it was analyzed if there is a need of an expert, the approaches should try to make decisions by their own or proportionate solutions; it means that the adaptation should be automatic or, at least, semi-automatic. The last inclusion criterion was that the studies must show a consistent architecture since we are trying to design an architec-ture.
The inclusion and exclusion criteria were important elements in our literature review, since they enabled the inclusion of relevant studies to answer our research question and the exclusion of studies that do not contribute to our study.
Table 3.1: Search query for “Workflow” as a main concept in IEEE database. Main concept: Workflow
((“Document Title”:workflow) AND (“Abstract”:adapt* OR “Ab-stract”:reschedul* OR “Abstract”:reconfigur* OR “Abstract”:“self-adaptive workflow” OR “Abstract”:“dynamic adaptation” OR “Abstract”:“context-aware” OR “Abstract”:“workflow systems” OR “Abstract”:“agent” OR “Abstract”:“workflow architecture” OR “Ab-stract”:“auto adaptation” OR “Abstract”:“auto management” OR “Abstract”:“readjusting workflows” OR “Abstract”:“knowledge based process management” OR “Abstract”:“workflow management software”) Results: 712 papers
Table 3.2: Search query for “Business Process” as a main concept in IEEE database. Main concept: Business Process
((“Document Title”:“business process”) AND (“Abstract”:adapt* OR “Abstract”:reschedul* OR “Abstract”:reconfigur* OR “Abstract”:“self-adaptive business process” OR “Abstract”:“dynamic adaptation” OR “Abstract”:“context-aware” OR “Abstract”:“business process systems” OR “Abstract”:“agent” OR “Abstract”:“business process architecture” OR “Abstract”:“auto adaptation” OR “Abstract”:“auto management” OR “Ab-stract”:“readjusting business process” OR “Abstract”:“knowledge based process management” OR “Abstract”:“business process management soft-ware”))
Results: 112 papers
Table 3.3: Complete query for the research in IEEE database. Complete search
(((“Document Title”:workflow) OR (“Document Title”:“business process”)) AND (“Abstract”:adapt* OR “Abstract”:reschedul* OR “Abstract”:reconfigur* OR “Abstract”:“self-adaptive workflow” OR “Abstract”:“self-adaptive business process” OR “Abstract”:“dynamic adaptation” OR “Abstract”:“context-aware” OR “Abstract”:“workflow sys-tems” OR “Abstract”:“business process syssys-tems” OR “Abstract”:“agent” OR “Abstract”:“workflow architecture” OR “Abstract”:“business process architecture” OR “Abstract”:“auto adaptation” OR “Abstract”:“auto management” OR “Abstract”:“readjusting workflows” OR “Ab-stract”:“readjusting business process” OR “Abstract”:“knowledge based process management” OR “Abstract”:“workflow management software” OR “Abstract”:“business process management software”)))
The number of papers found in the three databases was 1229 from this result, we delimited the search date from January 2003 to May 2014 with 1040 papers remaining. After eliminating by title, 349 papers remained. Then 138 articles were eliminated after reading their summaries, remaining 211 papers. For the next phase, “by thematic focus” 183 papers were eliminated. Finally, applying the four phases of The PRISMA framework, the search resulted in 28 papers.
Figure 3.1 summarizes the four phases of PRISMA.
3.3
Adaptation Approaches
Table 3.4 summarizes the literature review. It shows us the concepts classification related to the problem, method, solution, objective, and strategy it also lets us know whether the proposition was already implemented or not.
Table 3.4: Synthesis of the literature review
Authors Year Problem Method Solution Objective Strategies Implemented?
Deng, et al. 2004 Managing
uncertainty Case Study ECA rules Personalizing Reactive YES Müller,
Greiner and Rahm
2004 Workflow
reconfiguration Case Study ECA rules Personalizing
Reactive and predictive
YES
Wang, Wang
and Xu 2005 User demand
Approach proposition ECA rules and intelligent agents
Optimization Reactive YES
Dai and Wang 2006 Workflow reconfiguration Approach proposition ECA rules and intelligent agents Optimization Reactive NO Wang and Wang 2006 Analyzing the necessity to adapt Case Study Goal oriented, rule based and intelligent agents Optimzation and Correction Reactive and predictive YES Han, Thiery and Song 2006 Workflow reconfiguration and Analyzing the necessity to adapt Documentary analysis Literature review Optimzation, Personalizing and Correction Reactive and predictive NO
Qu, Sheng and
Jiao 2006 User demand
Model Proposition
Intelligent
agents Personalizing Reactive YES
Ardissono, et al. 2006 Monitoring exceptions and allocation of resources Model
Proposition Guide line
Optimization and Personalizing Reactive YES Chakravarty and Singh 2007 Workflow reconfiguration Archtecture propositon Agent based with rules and policies Correction Reactive NO Lee, et al. 2007 Monitoring exceptions and allocation of resources Documentary analysis MAPE Autonomic Loop - - NO
Cho, Choi and
Choi 2007 User demand Case Study
Rule based and context
subtrees
Personalizing Reactive YES
Duo, et al. 2008 Workflow reconfiguration Archtecture propositon Intelligent agents Optimzation and Correction Reactive NO Smanchat, Ling and Indrawan 2008 Monitoring exceptions and allocation of resources Documentary analysis Literature review Optimzation, Personalizing and Correction Reactive and predictive NO Russello, Dong and Dulay 2008 Monitoring exceptions and allocation of resources Approach
proposition ECA rules Personalizing Reactive YES
Du, Jiang and
Diao 2008 Workflow reconfiguration Model Proposition Petri nets and clinical pathways
Personalizing Reactive YES
Table 3.4 Synthesis of the literature review – Continued from previous page
Authors Year Problem Method Solution Objective Strategies Implemented?
Dang, et al. 2008 Monitoring exceptions and allocation of resources Model Proposition Ontologies Optimization and Personalizing Reactive YES Sell and Springer 2009 Managing uncertainty Model Proposition Black box of the context Optimzation and Correction Reactive NO Wang, Chen, Fan and Fu 2009 Workflow reconfiguration Model Proposition Autonomic objects and CAS Correction Reactive NO Abbasi and Shaikh 2009 Managing uncertainty Model Proposition Ontologies Optimzation and Correction Reactive NO Mounira and Mahmoud 2010 Analyzing the necessity to adapt Create a
system Data mining
Optimization and Personalizing
Reactive YES
Bernal, et al. 2010 Workflow reconfiguration
Approach
proposition ECA rules
Optimzation and Correction Reactive NO Romeikat, et al. 2010 Workflow reconfiguration Approach
proposition ECA rules
Optimzation and Correction Reactive YES Agrawal 2011 Workflow reconfiguration Approach
proposition ECA rules
Optimzation and Correction
Reactive NO
Mitsch, et al. 2011 Workflow reconfiguration Model Proposition Ontologies Optimzation and Correction Reactive YES Marrella, Mecella, and Russo 2011 Managing uncertainty Approach proposition Rule based and CBR based Correction Reactive NO
Moon and Kim 2013
Analyzing the necessity to
adapt
Archtecture
propositon Rule based
Optimization and Personalizing Reactive NO Hofmann, Sackmann and Betke 2013 Managing uncertainty Documentary analysis DRWMFS - - NO Stavenko, Kazantsev and Gromoff 2013 Managing uncertainty Documentary analysis Adaptive case management - - NO
In the method column, 65% of the articles did not use a scientific method or was not possible to identify it by only reading the articles. However, as Wainer [70] stated, it is very common in the area of computer science, authors propose architectures, approaches or build models, programs and do not worry about the way to assess what has been proposed, a requirement that increasingly becomes necessary. Although the proposition of a model, architecture or approach is not a valid scientific method, in this work it was chosen to put it as a method used.
The solution column shows the techniques and the elements used to achieve logical adaptation in each approach.
In the objective column, it was analyzed the main adaptation objective of each ap-proach based on of the categorization of Smanchat, Ling and Indrawan [64]. The objective can be divided into personalization, optimization or correction. Personalization refers to adapt the workflows according to new user’s needs or conditions. It means performing new tasks, replacing others, changing the sequence of the activities among others, in order to cope with new requirements or contexts. Optimization refers to adapt the workflows
in order to improve the quality or performance of the system, in extra-functional level, for example the completion time or solve bottlenecks, etc. Correction refers to adapt the workflow when some fault happens during execution, for example some error during the procedures or a not expected input. In this situation, the workflow must be adapted to compensate the failure [64]. But, most of the studied approaches want to optimize their processes and achieve adaptation for personalize or correct processes.
In the strategy column, it was analyzed another important adaptation feature, the used strategies. The strategies used in order to achieve adaptation were: reactive and predictive, categorization based on Müller, Greiner and Rahm [47]. The reactive adapta-tion starts responding exactly at the moment when a new condiadapta-tion or situaadapta-tion happens. On the other hand, the predictive adaptation supervises and analyzes the workflow by anticipating possible changes.
Finally, the last column shows whether the authors implement their proposition. Figure 3.2 shows a simplified conceptual map pointing out the problem and solution of each paper.
3.3.1
Managing uncertainty
One of the major and more difficult problems is handling uncertainty which means deal-ing with unknown circumstances. This problem will carry out with activities such as: identify possible problems or risks, assess the probability of each them, analyze response alternatives, etc. As we could see, this process requires high level of knowledge and experience.
Deng et al. [22] tried to solve this problem modeling workflows at design time, they proposed an innovative way to manage the uncertainty, they divide the activities into two groups the general activities which are known and repeatable activities and the flexible activities, the “black box”, which groups unknown activities or sub-processes. To han-dle better these sub-processes they associated some attributes (pool activities, selection constraint, and composition constraint) to them. Their rule-based model allows to select activities manually and automatically composed them at running time. They made study case general medical treatment.
On the other hand, Marrella, Mecella, and Russo [42] proposed a modeling approach that monitors two realities (expected and physical reality) when one of them is different from the other it converts the physical reality into the initial state and the expected reality into the goal and builds a corresponding recovering plan. They define preconditions and postconditions of tasks that are partially ordered, as per an initial state and final state (goal). This approach incorporates execution feedback directly into the plan, without blocking execution of the main processes which result in a reduction of the overall response time.
Sell and Springer [61] and Abbasi and Shaikh [2] proposed models that separate context from the WFMS. Sell and Springer [61] proposed an adaptation layer that interacts with a context service, the adaptation layer will read information from a context service, verify if there is a need for adaptation and automatically it will calculate its position and it will execute it. To calculate its position, it will evaluate the current workflow state and the interdependencies of the activities. This approach allows a simple management and a better reusability of the adaptation layer. At the same time, Abbasi and Shaikh [2] proposed a model in which a context manager/reasoner monitors the static context information and dynamic physical world information. The context manager selects at running time an appropriate activity from the pool of activities by using the context information and some adaptation logic. They propose the usage of an ontology as a knowledge base.
Disasters are almost impossible to predict and are non-routine, so how to deal with this kind of emergency? what have to be done during the disaster? Managing during the disaster, also known as DRM, is the uncertain problem that this paper want to solve. WFMS and BPM are concepts not widely used in the area of Disaster Response Man-agement (DRM), that is why Hofmann, Sackmann and Betke [31] analyze the advantages of using WFMS and BPM in Disaster Response Management (DRM). To do so, they describe some requirements for DRM and mapped them with some WFMS approaches. They compare the DRM and BPM and came to the conclusion that both domains share the main objective which is managing people, resources and (response) activities. Finally,
they analyze approaches in order to prove the feasibility of BPM tools in DRM.
Stavenko, Kazantsev and Gromoff [65] proposed a modern way to model business pro-cesses in order to deal with the uncertainty of propro-cesses. They plan to use an adaptive case approach because it not rigorously model and emphasizes creative work. This ap-proach aims to support decision makers in performing creative, knowledge-intensive work and provide means of flexibility to the workflow.
3.3.2
Analyzing the necessity to adapt
Another problem that workflows have to deal with is monitoring and analyzing the context to verify the necessity of adaptation to accomplish the final goal, besides of following the correct steps and analyzing possible exceptions, there is pressing need to analyze the environment, variables, and other information to find problems that require adaptation. Discover this kind of problem is very difficult as it requires high analytical skills, which means hard knowledge work.
In order to deal with this problem Mounira and Mahmoud [46] proposed a framework that uses mining process techniques for discovering context information from execution environment. They analyze the event log, and if there is a problem, the context reasoner would make the decision to adapt the workflow or not, after that some rules are adapted or created.
Also, Han, Thiery and Song [29] in the survey “Managing exceptions in the medical workflow systems” said that knowledge-based approaches are the best for analyzing the need of adaptation, and data mining methods will improve this process.
Moon and Kim [45] in their paper “Context-Aware Business Process Management for Personalized Healthcare Services”, also try to address this problem, they proposed an integrated architecture of context-aware business process management system based on ubiquitous computing and web services technologies. They propose the usage of ubiq-uitous technologies such as RFID (radio frequency identifications) and smart sensors. After, the gathered information and the electronic medical records (EMR) are analyzed and processed in order to generate personalized healthcare process.
Conjointly, Wang and Wang [72] proposed a cognitive approach based on situational awareness and real-time decisions. The approach perceives and understands the workflow environment, watches over it and exercises timely and decision-based control of the exe-cution of the process. It would reason and evaluate the situation according the business logic and business rules. This approach not only provides real-time reaction but proactive goal-oriented behavior. It also makes a prediction of the future state of the environment which help to define a workflow for unstructured problems or without a routine. Their study case involves exception management in securities trading. The system has a trade status monitoring agent, a trade details monitoring agent, a diagnostic agent and resolu-tion agent. The system was built by Web Services Development Package (WSDP) and Java Expert System Shell (JESS).
