A Formal Representation for Context-Aware Business Processes

Computers in Industry 65 (2014) 1193–1214

A formal representation for context-aware business processes

Talita da Cunha Mattos a,1, Flavia Maria Santoro a,*, Kate Revoredo a,1,Vanessa Tavares Nunes b,2

a Programa de Pos-Graduacao em Informatica Departamento de Informatica Aplicada, Universidade Federal do Estado do Rio de Janeiro (UNIRIO),

22290-240 Rio de Janeiro, RJ, Brazilb COPPE, Universidade Federal do Rio de Janeiro (UFRJ), Rio de Janeiro, RJ, Brazil

A R T I C L E I N F O

Article history:

Received 23 July 2013

Received in revised form 19 April 2014

Accepted 9 July 2014

Available online 1 August 2014

Keywords:

Business process

Context

Situation

Business process adaptation

A B S T R A C T

A business process is a set of activities performed in a coordinated manner within an organizational and

technical environment that is aimed toward a business goal. The flexibility of a process is related to an

understanding of the unexpected events that occur when people, systems and resources interact and

require adjustments. Thus, business processes must be designed to respond to information about

different events and their specificity. This information defines what the literature calls ‘‘context’’. To

broaden the perception of context in the case of a business process, this work proposes an approach to

characterize the context of a business process activity in a given domain through conceptual models

structured in layers. A case study was conducted to evaluate the proposal, which provided evidence of

the applicability of the model.

� 2014 Elsevier B.V. All rights reserved.

Contents lists available at ScienceDirect

Computers in Industry

jo ur n al ho m epag e: ww w.els evier . c om / lo cat e/co mp in d

1. Introduction

A business process is a set of activities performed in acoordinated manner within an organizational and technicalenvironment to achieve a business goal [57]. Processes remain atop priority in a business setting; however, some aspects of theireffective implementation remain a challenge [21]. Deviations inworking routines are one of them. Thus, managing processeswithout dealing with these possible changes can lead to theinadequate performance of an organization [40].

The flexibility of a process is related to an understanding ofunexpected events, which occur when people, systems andresources interact and may require adjustments. Thus, businessprocesses must be designed to respond to different events andtheir specificity, as well as to unpredictable conditions in anenvironment. The literature has referred to such processes as

* Corresponding author at: Applied Informatics Department, Federal University

of the State of Rio de Janeiro, Avenida Pasteur, 458, Rio de Janeiro, CEP 22290-240,

Brazil. Tel.: +55 21 2530 8088; fax: +55 21 2530 8047.

E-mail addresses: [email protected] (T.d.C. Mattos),

[email protected] (F.M. Santoro), [email protected]

(K. Revoredo), [email protected] (V.T. Nunes).1 Applied Informatics Department, Federal University of the State of Rio de

Janeiro, Avenida Pasteur, 458, Rio de Janeiro, CEP 22290-240, Brazil.

Tel.: +55 21 2530 8088.2 COPPE, Federal University of Rio de Janeiro Cidade Universitaria da Ilha do

Fundao, Rio de Janeiro, CEP 21941-901, Brazil.

http://dx.doi.org/10.1016/j.compind.2014.07.005

0166-3615/� 2014 Elsevier B.V. All rights reserved.

context-aware processes [45,49,35]. Analysis of contextual infor-mation might indicate the need for modifications in processes,which facilitates learning from the past to support decisionmaking.

According to Bider [7], a great part of everyday life events can bepredicted but never a hundred percent of all events. Not allpossibilities of action are known in advance. Moreover, even if itwas possible to represent all possibilities in a process model, thiswould likely reduce the ability to understand the model due to thehigh degree of complexity required [7,28].

As an example, let us consider the following scenario: anAmerican company named ABC sells products through theInternet. A customer, John, living in Brazil, has a daughter wholives in the United States. He decides to send her an item from ABCas a gift. Thus, this item would have to be delivered in the UnitedStates. However, when he tries to make a purchase with hisinternational credit card, it is denied. Although the card is valid, theprocess expects the delivery country to be the same as that wherethe credit card invoice is received. In this case, the delivery addressis in the United States, whereas the billing address is in Brazil. Thefact that the country where the credit card bill is received isdifferent from the delivery country is not a predictable scenario,and so, the purchase is not authorized. Nonetheless, the situationundermines the primary purpose of the process, which is toachieve sales. This example illustrates the importance of develop-ing adequate approaches that can handle new situations, allowingfor the adaptation of a running process.

T.C. Mattos et al. / Computers in Industry 65 (2014) 1193–12141194

Hong et al. [27] performed an extensive literature reviewregarding context-aware information systems and classifiedstudies according to a framework based on the most commonarchitecture for such systems, which consists of five layers:concept and research, network, middleware, application and userinfrastructure. They also proposed a research agenda for this areaof study, identifying gaps in each layer. One particular conclusionreached by the authors supports our research, highlighting theneed for a formalization approach: ‘‘the integration of context-aware theory and concept studies may broaden our horizon on thissubject’’. Although there are several proposals that address theconcept of context associated with business processes (including[45,46,24,49,35,36]), to the best of our knowledge, none of themhave yet presented a generic and formal model to support therepresentation of such scenarios, exposing adaptation needs toenable organizations to achieve their goals. The problem addressedhere is the lack of formal models that associate process modelswith the contextual elements that might impact the execution ofthe process instances.

Therefore, this paper presents a formal description of how thecontext of a business process activity in a given domain can berepresented. The formalization is made through a metamodel. Ametamodel typically defines the language and/or the processesfrom which to form a model, i.e., a collection of concepts within acertain domain. While a model is an abstraction of phenomena inthe real world; a metamodel is yet another abstraction, highlight-ing properties of the model itself. The metamodel presented isstructured in three layers, that together, are able to support therepresentation of relevant contextual variables (associated toprocess model within its domain). When monitored, thosevariables might support a process instance to be dynamicallyadapted.

Our main contribution lies in extending the proposals reportedin the literature to build a broad and flexible model as a basis foradapting business processes based on context. The metamodel canbe applied to any organization domain and business process; sinceit is generic (i.e. it does not use a domain-specific metamodel). Theadvance provided by the layered approach is based on twoarguments. First, the establishment of explicit relationships amongthe elements of each layer (for example, a process model element,the external data billing address, is explicitly nominated as acontextual element). Second, the Situation, which is defined as partof the Context metamodel, integrates a set of contextual elementsthrough a formalism based on logic. This element is associatedwith Activity element in the Process layer. From this point on,contextual elements and the situations composed by them couldbe monitored as so by a process-aware information system.

The paper is organized as follows: Section 2 presents thetheoretical background; Section 3 presents our proposed meta-model; Section 4 discusses a case study to investigate theapplicability of the proposal; Section 5 describes related work incontext-aware business processes, highlighting the gaps in theliterature; and Section 6 provides conclusions and proposes futurestudies in this line of research.

2. Background knowledge

In this section, we review the elements that might compose abusiness process model (see Section 2.1) and different definitionsof context for general use (see Section 2.2). These concepts are thefoundation of our proposal.

2.1. Business process model

In a highly dynamic market, organizations are constantlyevolving to remain competitive. In this scenario, business

processes are the factors that sustain and improve the corecompetencies of organizations [51]. Moreover, a business processcan be represented through a business process model. The modelcreates an abstraction of a business process, providing anunderstanding of how various activities are conducted. The modelrepresents a set of orderly and structured activities with well-defined inputs and outputs and also indicates the actorsresponsible for performing tasks.

According to [44], process modeling is a practice used tovisualize and formally describe current (as-is) and redesigned (to-be) business processes. However, although traditional and well-established languages (and the metamodels behind them), such asBPMN, EPC, UML (Activity Diagram) are able to represent scenariosof a process, they do not include the concept of context explicitly.Besides, we argue that any attribute related to the activity of aprocess might be considered a contextual element. We notice thatthose metamodels (although they are extendable) do not comprisesome of these attributes, as for example, business rule, term, anddiscussion/interaction. Thus, we decided to use an ontologydeveloped before within our research group.

Nunes et al. [33] proposed a metamodel to support the creation,manipulation and reuse of contextual information related to theactivities of a business process based on an ontology. In [33], all ofthe elements of a process model were considered specializations ofa class called Context; thus, all of them were considered potentialcontextual elements (Fig. 1). The main subjects presented in thisontology are (i) information that exists during an activityrepresented by the classes Resources, Time, Glossary, BusinessRule, Process, Artifacts and External Data; and (ii) informationabout the individuals and the group as a whole that executes anactivity and the interactions that occur between them representedby the classes Actors, Person, Group, Role, Competence andInteraction. Therefore, the model was characterized as a businessprocess metamodel [34] that might support the creation ofbusiness process models; hence, it was chosen as the basis forour research.

2.2. Context representation

The concept of context has been defined in various ways in theliterature. Early in Software Engineering, for example, a ContextDiagram defines the boundary between a system, or part of asystem, and its environment, showing the entities that interactwith it [19]. Techniques for reactive systems design also mentionthe notion of environment as a kind of context in which a systemperforms, i.e., the interactions of a software system consist ofexchanges of occurrences (e.g. data items, events) with theenvironment [58]. Those definitions are similar to the one usedin this paper: context makes a distinction between a focus and itsenvironment.

An action is executed or an event occurs in a context. While anevent is a real-world occurrence that can be distinguished, contextcan be defined as a complex description of the knowledge sharedon physical, social, historical and other circumstances whereactions or events happen. All this knowledge is not a part of theaction or the event, but will constrain the execution of the action orthe interpretation of the event [12]. In a business process scenario,in which organizations must quickly detect and respond tochanges in their routines, context is the minimal set of variablesthat contains all relevant information impacting the design andimplementation of a business process [45]. Due to the relevance ofcontext in various knowledge domains or applications [3], someefforts have been made to create languages and metamodels thatare able to specify context.

Languages provide the appropriate syntax to represent theelements necessary for the construction of both metamodels and

Fig. 1. Context model based on ontology [33].

T.C. Mattos et al. / Computers in Industry 65 (2014) 1193–1214 1195

specific models resulting from them. Languages are usually datastructures used for the representation and exchange of contextualinformation [6]. We identified the following types of languages:key-value [47,50], markup schemes [25,18], graphics (UML activitydiagram extended – [4]; Contextual Graphs – [10,11]), object-oriented [26,17], languages based on logic [31,22] and languagesbased on ontology [23,15].

A metamodel of context provides structure at a generic levelthat is not tied to any specific system or approach, whereas acontext model specifies the relevant context for a particularcontext-aware service/system. Metamodels define context at anabstract level, establishing the basis for constructing contextmodels to support system designers in their decisions about whatcontext variables must be integrated into a system [5]. Moreover,the models are intended to enumerate the concepts that should beaddressed as context by a context-aware system.

Bauer [5] compared thirteen metamodels of context andcategorized them according to the degree to which they abstracteda given context from the real world. Thus, a metamodel with a highdegree of abstraction describes the world using generic categories.A metamodel with a low level of abstraction represents contextwith more specific categories. Among the works studied [59]proposed an ontology of context composed of three basic classes:extrinsic context, interface context and intrinsic context, which arerelated to the physical world and individual and technologicaldimensions, respectively.

Brezillon and Pomerol [13] proposed a theory that classifiescontext according to the focus of attention. To these authors,context cannot be isolated but must always relate to a focus. Thisfocus determines what can be considered relevant within a givencontext and is represented by a task, a step in problem solving ordecision making, or even the goal of a given process andorganization.

Vieira et al. [54] adopted the definition of context proposed byBrezillon and Pomerol [13] and distinguished between theconcepts of contextual element and context: (i) a contextual

element is any piece of data or information that allows an entity tobe characterized within a domain; and (ii) context is the set ofinstantiated contextual elements that are needed to support a taskperformed by an agent (human or software). Additionally, theelements that compose context have a relevant relationship withthe task that the agent is performing. Moreover, a contextualelement is stable and can be set at designated time, whereascontext is dynamic and must be constructed at runtime, when theinteraction occurs.

The context metamodel proposed by Vieira et al. [55] definesthe semantics of the core concepts used to build context modelsand is an extension of UML 2.0 [37]. The metamodel is divided intotwo main packages that organize concepts into two categories:context.metamodel.structure: describes concepts related to theconceptual and structural elements of a context-aware system, andcontext.metamodel.behavior: incorporates concepts related tobehavioral aspects of a context-aware system. The structure ofthe metamodel involves the following concepts: Contextual Entity,Contextual Element, Context Source, Focus and Rule:

� Contextual Entity represents the entities that should beconsidered for the manipulation of context. An entity is aconcrete representation of a real-world object that can bedistinctly identified and is relevant to describing a domain.� Contextual Element represents a property used to characterize a

Contextual Entity. This element is the basic information unit inthe context metamodel and can be identified from the set ofattributes and relationships associated with an entity. A contextwill consist of an aggregation of contextual elements.� Context Source provides information about how a contextual

element is acquired. The ways in which element contexts areacquired may differ depending on the nature of the contextualelement and the characteristics of the context source.� Focus is closely related to the running Task and is what allows for

the determination of which contextual elements must beinstantiated and used to compose the context. It is determined


by the Task together with the Agent who is running the Task. AnAgent can play different Roles during the execution of the Task.� Rule is a set of one or more conditions and a set of one or more

actions. Each condition is an expression, which results in a valueof true, false or null (unknown), when combined with theavailable data. An action indicates a procedure that should beperformed when the rule conditions are met.

The metamodel also supports concepts such as: Task, Agent,Role, Relevance and Acquisition. An important issue is thepossibility of associating the Focus with all contextual elementsthat are relevant to support it. The level of relevance of thisassociation is affected by the agent who is performing the task.

Once they were identified, we were able to divide the mainreference studies on context modeling into two groups. The firstgroup concerns the languages on which metamodels/models aredeveloped. The second group concerns more generic metamodelsthat describe the concepts of context. Our proposal fits within thesecond group because it aims to provide conceptual modelsstructured in layers for the representation of context.

We used the work of Vieira et al. [54] as the starting point forour proposal. However, it is important to note that despite the factthat Vieira et al. metamodel defines the concept of context, it is notspecifically suited for business processes; therefore, it does notmake explicit the relationships between the relevant concepts andthe domain of a business. Thus, describing how to use the conceptof context in business processes remains an important issue to beaddressed.

Furthermore, in order to use the metamodel in a real domain, itis necessary to extend the concept of contextual element to thespecific domain concepts. We argue that the domain model shouldbe built separately for the sake of modularity and to better expressthe three groups of concepts involved: context, process anddomain. The next section presents our proposal to establish aformal relationship between business processes and the concept ofcontext in a given domain, which will support the development ofcontext-aware process based systems.

3. A layered metamodel for context-aware business processes

The dynamic nature of a modern business environment makes abusiness process subject to a wide range of variations; thus,flexible approaches are needed to respond to such variations [48].Business process models tend to be rigid in format and are not ableto easily encompass either foreseen or unforeseen variations in theenvironment in which they operate. It is due to first, it is very hardto predict all the possible variations, and second, if the modelertries to include all the possible variations in the model, it wouldprobably turn to be very difficult to manage. So, the approach hereis to deal with relevant variations as ‘‘context’’ and address themadapting the process when they occur.

Each instance of a business process is subject to changes incontext, i.e., each iteration is a set of context-related information.Additionally, contextual knowledge can add relevant informationto support the execution of activities and describe artifacts orexplain why certain decisions were made.

We propose the representation of context in business processesbased on conceptual models. The fundamental concept adoptedhere is that context is the set of instantiated and combined(Situation) contextual elements that are necessary to support anactivity in a business process. A layered approach provides aconceptualization of the various aspects related to context. Thus, itis possible to isolate the elements belonging to each layer andthereby establish their relationships. Moreover, the modularcharacteristic of this proposal should facilitate the maintenanceand development of the model, as shown in Fig. 2.

The first layer is the Context Metamodel, which refers to theelements related to the manipulation of context, including theconcept of Situation [30], and their relationship. It is based on theproposal of Vieira et al. [54]. The second layer is the Business Process

Metamodel, which defines the elements that should be used todescribe a process, with the focus on the activity of the workprocess. It is based on the model of Nunes et al. [33]. Finally, thethird layer represents the Domain Metamodel, which is responsiblefor supporting the definition of the data structure, functions,relationships and constraints of the knowledge area considered.This layered approach provides different levels of abstraction andaims to support not only the representation of context but also theproperties necessary to deal with context in a business process.

An ontology formalism [53] was adopted to build theconceptual metamodels. According to Noy and McGuinness [32],ontologies are developed to facilitate the sharing and reuse ofinformation to describe concepts, properties, constraints andrelationships. In our case, to enable the use of this information, it isimportant to understand the underlying semantics and be able tomanipulate the information. The ontology was developed using thesoftware [41], and a graphic model was generated using the plugin[39]. Classes are represented by rectangles and relationships byarrows. The metamodels are described in detail in the followingsub-sections.

In the following sections the three Metamodels are described inmore details.

3.1. Context Metamodel layer

The Context Metamodel comprises the concepts related tocontext and their relationships. It was adapted from thecontext.metamodel.structure package of the context model pro-posed by Vieira et al. [54], where the main differences are asfollows: the classes Agent, Role and Task were excluded becausethey are related to the Business Process and therefore will berepresented in the second layer (see Section 3.2); the classSituation, which is characterized by a set of instantiated contextualelements, was included [30]; and finally, a new relationshipbetween the classes Acquisition and Context Source was estab-lished. Fig. 3 depicts the Context Metamodel. The classes andattributes are described in Table 1.

The goal of the Context Metamodel layer is to support theconstruction of specific context models, since it distinguishesthe classes and relationships necessary. The analyst responsiblefor building this context model should decide how to instantiatethe classes depending on the specific environment. Thecontext model, in turn, will be employed in each instance ofthe process, enabling the relationship between the layers to bedetermined.

3.2. Business Process Metamodel layer

In our formalism, we propose a layer to specifically defineconcepts of context and their relationships. Thus, to express theelements of a business model, we modified the ontology proposedby Nunes et al. [33] depicted in Section 2, excluding the classContext and establishing new relationships between the twolayers. Moreover, the formalism presented in this paper improvesthe original ontology by making all of the relevant concepts relatedto context explicit in a separate model (the first layer) andhighlighting in the second layer a process metamodel. Thismetamodel should be taken as a basis for building the processmodels, which is needed to identify and monitor the context. Fig. 4depicts the Business Process Metamodel. The main classes thatcompose this metamodel and their attributes are described inTable 2.

Fig. 2. Layered Metamodel for context-aware business processes.


Depending on the elements of the business process and of thedomain, only a subset of them will be considered relevant toactually be monitored as context. A process model element or adomain element becomes a contextual element if their corre-sponding classes are extensions of the Contextual Element class.For example, in a specific process, an artifact can be chosen asrelevant information to be monitored; thus, the Artifact class will

be an extension of the Contextual class for this domain. Therefore,there is a possible inheritance relationship between all elements inthe process layer and the Contextual Element in the context layer.

Fig. 5 illustrates examples of possible relations that occurbetween a context and process: (i) a relationship between the classContextual Element (in Context Metamodel) and Artifact (inBusiness Process Metamodel); (ii) a relationship between the

Fig. 3. Context Metamodel.


classes Activity (in Business Process Metamodel) and Focus (inContext Metamodel).

It is important to note that the Business Processes Metamodellayer, analogous to the context layer, aims to guide theconstruction of process models based on the concepts defined inthe layer.

Table 1Context Metamodel classes and attributes.

Class Description and attributes

Contextual Entity Represents entities (person, place, object, user, applicat

characterized by at least one contextual element

Attributes: name, type, description, is_characterized

Contextual Element Represents a property used to characterize a contextua

relationships associated to an entity.

Attributes: name, description, value

Context_Type Represents the contextual element’s categorization acco

element is related to a set of questions on their attribu

Attributes: value

Context_Source Represents ways in which contextual elements instance

desktops sensors, user-interface dialog, etc.).

Attributes: name, origin, type

Acquisition Represents ways of capturing contextual elements. It pa

Attributes: acquisition type, frequency of updating

Acquisition_Type Classifies the contextual element according to the way

Attributes: value

Updating_Type Classifies the contextual element according to the way

Attributes: value

Focus Allows for the determination of which contextual elem

Attributes: function, description, goal, is_active

Rule Logical statement that specifies the execution of one or

according to the value that one contextual element or a c

should be performed when a condition is met. Actions ca

element or assigning a new weight to the relevance be

Attributes: name, type, goal

Relevance Represents the level of importance of a contextual elemen

be low, medium or high

Attributes: description, weight

Situation Represents the set of instantiated contextual elements

Attributes: description, outcomes, is_characterized

3.3. Domain Metamodel layer

Any business is related to a specific domain. Thus, everythingthat influences a process (either internal or external variables)should be understood as part of this domain. A Domain Model is ahigh-level conceptual model that defines physical and abstract

ion) to be considered for the purpose of manipulating context information. It is

l entity. It is the basic unit of the model, identified by a set of attributes and

rding to the type of information that it provides. Indicates when a contextual

tes

s can be derived from heterogeneous and external sources (physical sensors,

rameterizes the relationship between a contextual element and a source context

it is acquired

it is acquired, in terms of the updating frequency

ents should be instantiated and used to compose a Situation.

more actions when pre-defined conditions are met. Conditions are characterized

ombination of contextual elements assumes. An action indicates a procedure that

n be, for example, triggering a system action, assigning a new value to a contextual

tween a focus and a contextual element

t in relation to the focus. It is characterized by a weight (Relevance_Type) that can

featuring an adaptation

Fig. 4. Business Process Metamodel.


objects in a knowledge area. It is frequently used to explain theterms of a domain by describing the main entities, their attributes,roles and relationships, as well as the constraints that rule thedomain. In a domain model, a class should represent a group ofobjects instead of a programming object. Domain models mayimprove accuracy and focus discussions among stakeholders,business teams or technical teams.

Table 2Business Process Metamodel classes and attributes.


Activity Set of actions aimed at reaching one or more objectives

execute it

Attributes: name, description, action, expected goal, ach

Actor Represents professionals involved in the execution of an

them. They are specialized in Individual, Group and No

Attributes: name, type

Role A function that is performed by one or more Actors and t

and require some Competence

Attributes: name, function

Artifact Concrete product resulting from the execution of an ac

Attributes: name, type, description

External Data Information external to the organization or work proce

Attributes: name, description, type

Resource Element related to computing platforms, hardware, ma

specific subclasses such as Environment (location within

the domain. . .

Attributes: name, function, type

Term Concept established by the domain and the application

Attributes: name, description, type.

Competence Skill required for a specific actor to perform an activity

Attributes: technological knowledge, leadership, busine

Business Rule Information that defines or constrains some aspect of the

specific domain. It aims to support the business structu

standards, or external constraints, such as laws and reg

Attributes: name, type

Procedure Norm or standard that is executed by Actors (according to

some action associated with them

Attributes: name, description, outcome

Interaction Represents the communication process between Actors

and also generates Artifacts

Attributes: behavior, feeling

Discussion Specialization of Interaction class that represents the d

Attributes: topic, exchanged gesture

Message Specialization of Interaction class that represents the co

Attributes: contents, message type

The third layer is the Domain Metamodel. This metamodelspecifies the basic concepts required to build a domainmodel. Therefore, we adopted a standard Domain Metamodelfrom the package of classes Foundations|Core of the UnifiedModeling Language [37] because it is commonly used tosupport the modeling of Class Diagrams. Fig. 6i illustrates thismetamodel.

that consumes and produces information and Artifacts and requires Actors to

ieved goal

activity through his/her skills, personal information and the relationship between

n-human actors

hat is assigned to each process activity. Roles have a hierarchy among themselves

tivity that can serve as input to other activities

ss that is running

terial, and work environments that have UseRestriction; it maybe specialized in

the organization) or Computational System (software application), depending on

scope

appropriately

ss knowledge

business. Can be directly linked to an organization as a whole or can be linked to a

re or to influence its behavior. It can be related to internal constraints, such as

ulations

the role associated with them at the moment) or triggered by the Activity through

required to perform an Activity that occurs through some Communication Means

ebates held between Actors participating in a Process

ntents of the messages exchanged during interactions

Fig. 5. Example of interaction between context and process layers.


This package is the language component that specifies the staticstructure of the models and contains the sub-packages Core,Extension Mechanisms and Data Types. The Core subpackagespecifies the basic concepts, and the metamodel defines anarchitectural framework that allows for the association ofadditional constructors. The main concepts for our work aredescribed in Table 3.

Domain models created based on the Domain Metamodel aimto represent the vocabulary and key concepts of a specificknowledge area through the description of the entities, attributes,roles and relationships involved, as well as restrictions that ensurethe integrity of a particular domain. Therefore, the models areunique and should be built for each particular case.

3.4. Relationship between Context and Business Process layers

As mentioned previously, the three layers Context, BusinessProcess and Domain constitute an approach to context-awarebusiness process representation, and therefore, they are linked. Inthis proposal, the relationships between layers are defined byrules. Rules connecting Context and the Business ProcessMetamodels are generic, and they define fundamental relation-ships and constraints between some of their elements. Further-more, the definition of the rules guarantees that a relationshipexists between the models built from the metamodels.

Rule 1 (Formalization of the Relationship between ContextualElement and Situation):

Given CE as the set of contextual elements, for all contextualelements cei 2 CE, where 1 � i � n and n ¼ CEj j, a domain(Dom(cei)) is associated, indicating the possible values that thecontextual element can assume.

Given DomðceiÞ ¼ fdi1; di2; . . . ; diMig, where Mi ¼ DomðceiÞj j, the

set E is defined as the set of all contextual elements with theirassociated values:

E ¼ fce1 ¼ d11; . . . ; ce1 ¼ d1M1; ce2 ¼ d21; . . . ; ce2 ¼ d2M2

; . . . ; cen

¼ dn1; . . . ; cen ¼ dnMng

A Situation is defined as a sub-set of E(S � E), where a certaincontextual element only appears once.

Rule 2 (Formalization of the Relationship between Focus andContextual Element):

IF Focus(is_active = True)AND Contextual Element (name = X)THEN the Contextual Element instantiated X is associated withFocus

Rule 3 (Formalization of the Relationship between Focus andActivity):

IF Activity (name = A, expected goal = Z, action = L)AND Focus (is_active = True)THEN Focus = L.

Fig. 6. Domain Metamodel

Reproduced from [37]


Rule 4 (Formalization of the Relationship between ContextualElement and Contextual Entity)

IF Contextual Entity (is_charaterized = Active)AND Contextual Element (name = A)THEN the Contextual Entity is characterized by ContextualElement A

Table 3Domain Metamodel concepts.


Element Base class for all elements that compose the UML metamod

Model_element Represents all business elements that are specified with the

Characteristic Represents a possible classification of the Model_element. D

structural and behavioral features

Restriction Represents a possible classification of the Model_element. D

restriction expressed in text

Attribute Defines values that represent the state of an instance of a C

Operation Behavioral aspect of a Classifier

Method Behavioral aspect of a Classifier

Element_property Sets the visibility of an element model contained in a Name

The first rule relates Contextual Element and Situation. Notethat a Situation is a set of values associated with ContextualElements. The second rule relates Contextual Element and Focus.The Focus provides a reference for the determination of ContextualElements that must be instantiated to compose the Situation. Thus,if we have the Focus active for a Contextual Element X, then we canassume that this instantiated Contextual Element is associated

el. It is the atomic constituent of the model

UML

efines a way to represent a particular domain element. It is a generalization of

efines a way to represent a particular domain element. Semantic condition or

lassifier

space


with the Focus. The third rule relates Focus and Activity. AnActivity is a set of actions aimed to achieve one or more goals,hence setting the Focus. Thus, if we have an Activity A, goal Z andaction L and the Focus is active, then we can infer that the focus isequal to L. The fourth rule relates Contextual Entity and ContextualElement. A Contextual Entity represents entities to be consideredfor the purpose of manipulating context information and ischaracterized by at least one Contextual Element. Therefore, if wehave a Contextual Entity characterized and a Contextual Elementoccurrence A, then the Contextual Entity is characterized by theContextual Element A. For example, Contextual Entity = AirportLane X and a possible Contextual Element = Lane (informationabout the lane). Thus, the Contextual Entity and ContextualElement are related, and this relationship depends on the Focus, asspecified in Rule 2.

3.5. Applying the proposal to build a model

Process models are designed in accordance with the classespresented in the process layer, as well as the application of theconcepts defined in the domain layer. Thus, for the same domainmodel, there may be several processes, and consequently a numberof process models, within an organization. The Situation andActivity classes that appear in the domain model are referencesfrom other layers. Each domain class could potentially be identifiedas a contextual element. Therefore, the relationships betweenthese concepts must be established. For example, the conceptBilling Address (which could be a class or Model Element of thedomain used as an example in Section 1) could be a specializationof Contextual Element (in Context Metamodel) for the case of aspecific Process (Sell Items) in which an Activity (Payable Invoice) isperformed.

Our approach aims to make the manipulation of context moreflexible because each layer can express the existence of relation-ships between concepts included in the model. Thus, someconcepts defined in a layer will be related to other concepts inother layers. The complete model should be built according to thefollowing steps:

(i) Define the domain of a given application and model it (thirdlayer)

(ii) Model the target process (second layer);(iii) Establish the relationships between the domain and process

models by identifying the elements of the process thatcorrespond to the elements that make up the domain;

(iv) Identify in those two models which elements to consider ascontextual elements and establish an explicit relationship among

them and the corresponding concepts in the first layer;(v) Characterize Situations. The contextual elements should be

analyzed because the values they can assume in the instancesof business process might define the situation. Therefore,when a situation occurs, a decision regarding the course of theprocess should be taken. Thus, inference rules should becreated.

For the steps (iv) and (v), we propose to apply the proposalsdescribed in [1,43,14]. Anastassiu and Santoro [1] propose amethod for identifying business processes contextual elements

internal to the organization. This method analyzes the processmodel searching initially for the essential activities and theneliciting which of their attributes are able to produce influences inthe results of the process. Complementary to this first approach,Ramos et al. [43] describe a proposal to discover external contextual

elements, based on algorithms that perform automatic analysis ofrelationships among a number of environment variables and thelogs of execution of the process in focus.

Moreover, the development of the relationships among theelements (i.e., the rules) could be made through interviews withexperts in the domain (such as building expert systems), or yet, byanalyzing the execution logs of the process to infer possiblerelations among them. Carvalho et al. [14] describes an imple-mentation of the Apriori algorithm (that discovers associationrules), which scans the data set (log) looking for subsets thatpresent frequent relationships [42].

Anyway, we highlight that the method and procedures for theelicitation of contextual elements, as well the definition ofrelationships among them are out of the scope of this paper.More details about it can be found in [1,43,14].

Based on the model built using the proposed approach, themonitoring of contextual elements of the process makes it possibleto identify the Situation of an Activity, which in turn, may signalthe need for adaptation. The metamodel has already been used inthe ‘‘Context Management Architecture for Dynamic ProcessAdaptation’’ (see details in [35,36]). In this system, a Mediator,the component responsible for adaptation, identifies adaptationneeds when a Situation occurs. Its key features are intelligentbehavior and decision-making support. During a process instanceexecution, this component should reason over: (i) the possibleadaptations, (ii) in which parts of the process the adaptationsshould be applied, and (iii) the impact on process and organiza-tional goals. So, the Mediator reasons over the situation that willnot lead the process instance to a stable state (i.e., achieve its goal)or that will not likely lead the process instance into its bestperformance, in order to decide what adaptations to be taken.

The next section presents a case study performed under realconditions to evaluate the proposal. All of the steps followed tobuild the models are described, and the validity of the modelsbased on assessments by specialists is discussed.

4. Evaluation: a case study and analysis

In this paper, we address the problem of providing formal modelsthat associate process with the context. In this sense, we shouldinvestigate the applicability of the proposal. So, our researchquestion is ‘‘How to build a formal representation that is able to linka process with its contextual elements?’’ In order to discuss thisquestion, the model-building approach proposed herein wasevaluated through a case study [56], which is an approach aimedto investigate a phenomenon within its real context, where there islittle control over events. According to [56], an exploratory casestudy could be used to explore those situations in which theintervention being evaluated has no clear, single set of outcomes.

The situation considered is a real scenario that is extremelycomplex, critical and relevant: Airspace Control. In this environ-ment, there is no possibility of conducting experiments without acomprehensive study, tested to exhaustion, so as not to compro-mise the integrity of the systems involved and flight safety. Thecase study was carried out in several steps, which are detailed inthe following sections:

(i) Understanding the scenario: The main concepts related to airtraffic control and the operation of an aerodrome controltower were elicited.

(ii) Creating the domain model: The model was built based on thewell-established 5M Model (see [52]), which features fivepotential factors that could affect the implementation of theprocess.

(iii) Modeling the process: The process to be used in the case studywas selected and modeled. The process chosen was the takeoffof aircraft.

(iv) Consolidation of the approach: The relationships between thelayers were defined.

Table 45M Model factors.

5M Factor

Man Human elements, such as psychological, physiological aspects of proficiency and experience in performing tasks

Media The environment where the task is performed, including weather conditions, runway conditions, obstructions, airspace illumination and

navigational aids available

Machine Manufacturing and maintenance of aircraft and reliability and performance of equipment

Management The ability to manage situations in terms of regulations, policies and attitudes toward safety

Mission The type of work performed, whether it is complex or routine


(v) Definition of the data set: Data were extracted from the DailySituation Report delivered by the Center for Management ofAir Navigation (CGNA). This report relates instances of airtraffic under various scenarios. We selected data related to theoccurrence of elements defined in the domain model becausethey were considered the factors relevant to the execution ofthe process.

(vi) Creating an activity log: Data obtained in the previous stepwere disposed in a log table format. The log identified whichof the monitored activities happened in the occurrence report.Each occurrence was understood as a process instance.

(vii) Conducting Interviews: Rules defining situations based on thecombination of values of contextual elements were created.These rules were evaluated through interviews with experts,which also served to validate the proposed model.

4.1. Case study scenario

The Airspace Traffic Control (ATC) scenario was chosen due toits remarkable relevance, as well as its highly dynamic nature, andbecause it presents a number of factors that could possiblyinterfere with the process execution. ATC is a service provided bycontrollers on the ground to guide and monitor aircraft in the airand on the ground to ensure a safe and organized traffic flow. Airtraffic controllers provide indications and authorizations to fly inaccordance with the operating characteristics of aircraft and trafficconditions at any given time. Controllers may provide guidanceregarding the route, altitude and/or speed proposed by the aircraftoperator for a particular flight; pilots must comply with theinstructions and authorizations received.

In many countries, ATC services are provided throughout thelength of an airspace, and these services are used by private,military and commercial aircraft companies. The airspaces wherethe controller sends authorizations are called controlled airspaces,as opposed to uncontrolled airspaces, where aircraft pilots are

Fig. 7. ATC dom

responsible for their own safety and navigation. Depending on thetype of flight and the class of airspace, the air traffic controllerprovides instructions that pilots must follow or merely assist pilotsoperating in a certain airspace. In addition to being dedicated topassenger safety, ATC aims to speed up aircraft deployment,preventing delays and reducing operating costs for users.

4.2. Building the Domain Model

Based on interviews with experts conducted during themodeling process, the following were identified as the mainelements of the domain: request for takeoff, authorization fortakeoff, regulation, mission type, weather conditions, runway,pilot, air traffic controller and aircraft. Additionally, we adoptedthe approach used by the U.S. Air Force for operational riskmanagement [52], which analyzes hazard factors associated withaviation: the 5M Model. A hazard is defined as any real or potentialcondition that can cause degradation, injury, illness, death, damageor loss of equipment or property [52]. For example, a controllermay answer the phone while he or she is setting the parametersand negligently report an incorrect parameter to a pilot. This is anexample of a human danger that can affect this process. Therefore,such risk factors should be monitored to allow for changes in theprocess if necessary. The 5M Model defines five factors thatcharacterize the existence of a hazard (Table 4).

The construction of the domain model requires the instantia-tion of the Domain Metamodel. Thus, from the Domain Metamodelin Fig. 6, the Domain Model composed with Classes (ModelElements) and its Structural Features (Attributes) was built. Thismodel is illustrated in Fig. 7, and a brief description of each classand attributes is provided in Table 5.

Moreover, we selected the Aircraft Takeoff process in this casestudy because of its importance to aviation, with thousands ofinstances being performed daily. The model developed is based onthe Business Process Metamodel. Both the domain and process

ain model.

Table 5Domain Model (classes and attributes with their set of possible values).

Take_off Represents the action of an airplane taking off

Take_off_Request Represents the document that is issued to request authorization to perform the activity

Take_off_Permission Represents the document that is issued to authorize the execution of the Activity

Hazard Represents a real or potential condition that can cause degradation, injury, illness, death, damage or loss of equipment or property

Man Refers to human elements, such as psychological, physiological, proficiency and experience in carrying out activities. Specialization

of the class Hazard

Machine Refers to aspects of manufacturing and maintenance of aircraft and equipment performance and reliability. Specialization of

the class Hazard

Media Refers to the environment where the activity is performed, including weather conditions, runway conditions, obstructions,

airspace and flow management. Specialization of the class Hazard

Mission Refers to the type of work performed, whether complex or routine. Specialization of the class Hazard

Management Refers to management capacity in terms of regulations, policies and attitudes toward safety. Specialization of the class Hazard

Pilot Refers to the person who will fly the aircraft. Specialization of the class Man

Air_Traffic_Controller Refers to the person who will monitor the implementation of the activity. Specialization of the class Man

Position_Ground_Control Refers to the person who will monitor the implementation of the activity on the ground position. Specialization of the

class Air Traffic Controller

Position_Flight_Data-

Clearance_Delivery

Refers to the person who will monitor the implementation of Activity in the Position of Traffic Authorization. Specialization of the


Position_Tower Refers to the person who will monitor the implementation of Activity in the Position of Tower Specialization of the


AIS_Operator Refers to the person responsible for activities performed in AIS. Specialization of the class Man

Ground_Worker Refers to the person responsible for support activities performed on the ground, i.e., at the aerodrome. Specialization of the class Man

Aircraft Represents the equipment used by the pilot to perform the Activity. Specialization of the class Machine

Aerodrome_Equipment Represents the technical equipment installed at the Aerodrome to enable the implementation of the Activity. Specialization

of the class Machine

Meteorological_Condition Represents weather conditions at the aerodrome and surrounding area. Specialization of the class Media

Air_Space Represents the conditions of the airspace near the aerodrome. Specialization of the class Media

Flow_Management Represents the set of actions performed to manage the flow of aircraft between Aerodromes. Specialization of the class Media

Runaway Represents the area of an aerodrome intended for aircraft takeoff and landing

Mission_Type Represents the purpose of the activity, which may be conventional, e.g., a civilian aircraft takeoff routine, or priority,

e.g., military missions, transporting sick, transporting organs, etc. Specialization of the class Mission

Regulation Represents the regulations that guide the implementation of activities or inform about aerodrome conditions. Specialization

of the class Management


models were built with the help of specialists through interviews.We interviewed the following professionals: two air trafficcontrollers, who are the heads of the airport control tower atGaleao Airport in Rio de Janeiro, Brazil, each with over 30 years ofexperience, and an airline pilot with 29 years of experience andmore than 2500 flight hours. Furthermore, the process applies toaerodromes that have a control tower, which constitutes asignificant portion of flights conducted in Brazilian airspace. Theflow of activities in the Aircraft Takeoff process is depicted in Fig. 8.The flow was modeled using the software BizAgi Process Modeler[8] with the Business Process Model and Notation (BPMN)standard notation [38]. Although the metamodel proposed in thispaper is not the one of BPMN, we adopted this notation since we itwould be important to have a visual presentation of the processmodel. Nevertheless, we argue this decision does not impactthe results because the Task in BPMN is similar to Activity inour metamodel, and this was the main element used in therepresentation built.

After modeling the process, it was necessary to identify whichof these activities are important to monitor in accordance with theobjective of this study. Thus, the experts also indicated theactivities that contain elements that characterize certain situationsand therefore might potentially require adaptations. The selectedactivities are highlighted in Fig. 8.

4.3. Model consolidation

In this step, the domain model was attached to the third layer ofthe structure. The complete model is consolidated only when therelationships between the elements of the each model areestablished. There, the goal was to link classes that representcontextual elements with the corresponding classes in the domainand in the process model. Moreover, each activity that has to bemonitored should be linked to the Focus class. Because an activity

is a focus, it is automatically linked to the contextual elements,which describe the contextual entities for that focus.

Fig. 9 illustrates the relationships among the elements in eachlayer. In the particular scenario shown in the figure, the focusactivity is Takeoff and the contextual elements are the hazards.Thus, the element Hazard in the domain model is linked to ExternalData in the process model (because it is modeled like this in theprocess model); External Data is linked to Contextual Element; andthe Activity Takeoff is the Focus. It is important to note that thisdiagram should be constructed for all activities to be monitored.Thus, at any time that one activity is the Focus; the correspondingcontextual elements (which are domain elements considered inthe business process) will be analyzed.

4.4. Data set definition

A sample of real data regarding instances of the Aircraft TakeoffProcess was used to help define the corresponding situations,which constitutes the most important component of our modeland highlights what context is about. Data were extracted fromdaily reports released by the Center for Management of AirNavigation (CGNA). The CGNA centralizes information regardingthe operational components of the infrastructure needed tomanage the use of airspace in Brazil. By managing this information,the CGNA is able to monitor the status of the SISCEAB (BrazilianAirspace Control System) to eliminate or reduce uncertainty indecision making and planning in the short, medium and long term.It is also responsible, in conjunction with the Brazilian AirportInfrastructure Company (Infraero), for the analysis of intentions tofly in Brazilian airspace.

The daily report, which aims to support the evaluation of thequality of services provided, generates indicators for aeronauticalinfrastructure planning and presents wide-ranging information,including rates of flight delays, weather conditions at airports,

Fig. 8. Aircraft takeoff process model.


adverse weather conditions, airport infrastructure (inoperative-ness of technical equipment, problems on runways), flowmanagement measures and other occurrences. These reportsprovide a rich amount of information to be handled, which allowed

us to explore the elements of context and define situations. Weanalyzed the reports corresponding to a period of six months, fromJune to December 2011. Over this period, 1320 occurrences relatedto contextual elements were identified. These occurrences were

Fig. 9. Consolidated model for the representation of context where the activity ‘‘takeoff’’ is the focus.


manually mapped and organized in the format of a log, asexplained in the next section.

4.5. Assembly of the log

The log represents the set of values assumed by each of thecontextual elements defined in the domain model for theoccurrence of each of the activities chosen (highlighted inFig. 8). Each occurrence obtained from the reports is a processinstance. In other words, for each instance, the behavior of thecontextual elements was observed to identify deviations in theprocess that possibly characterize a Situation. The contextualelements considered in the log were Regulation, Mission Type,

Weather Condition, Runway, Pilot, Air Traffic Controller andAircraft. Although important contextual elements for the process,neither Takeoff Authorization nor Takeoff Request were includedin the log because the daily reports from which the data wereextracted do not include this type of information. It should be notedthat only the occurrences that had some impact on the processwere handled. The log consists of the fields and possible values, aslisted in Table 6. The values were mapped manually because theywere identified using the data. Values related to normal operation,i.e., no changes in the process, are indicated in bold.

Fig. 10 illustrates part of the log for one process instance. In thisexample, the occurrence is a restriction in takeoffs to SBSP due to apartial break made by the access ramp personnel of a company

Table 6Log structure.

Column Description/values

Description Transcription of the occurrence reported in the daily situation report

Process code Code of the monitored process

Instance code Code of the monitored instance

Activity code Code of the monitored activity. Values: A, C, E, F, G, J, M, N, O, Q, R

Id Identifier of the record

Activity Description of the monitored activity

Report date Date of the report from which the information was extracted

Cause Description of the occurrence source. Values: balancing flow, collision with animal, adverse weather condition, lack of personal,

strike, aircraft intercepted, obstacle in aerospace, track taxi runway interdicted, runway interdicted, issue of communication,

medical emergency

Impact in process Description of the effect of occurrence on the process. Values: no impact, delay, flight cancelation, unauthorized takeoff,

suspended takeoff, runway shift

Air traffic controller Description of the conditions of the air traffic controller during the execution of the activity. Contextual Element related to Man.

Values: standard performance, discontinued operation

Pilot Description of the conditions of the pilot during the execution of the activity

Contextual Element related to Man. Values: standard performance, discontinued operation

Ground worker Description of the conditions of the ground worker during the execution of the activity. Contextual Element related to Man.

Values: standard performance, discontinued operation

Interference of the man Interference in the process for one of the Man CE. Values: true, false

Mission type Description of the type of mission that was being performed during the activity instance. Contextual Element related to Mission.

Values: conventional, priority

Interference of the mission Interference in the process for one of the Mission CE. Values: true, false

Aircraft Description of the conditions of the aircraft during the activity instance. Contextual Element related to Machine.

Values: operational, non-operational

Aerodrome equipment Description of the conditions of the aerodrome equipment during the activity instance. Contextual Element related to Machine.

Values: operational, non-operational, partially operational.

Interference of the machine Interference in the process for one of the Machine CE. Values: true, false

Meteorological condition Description of the meteorological conditions during the activity instance. Contextual Element related to Media. Values: favorable,

unfavorable, impeditive

Runway Description of the runway conditions during the activity instance. Contextual Element related to Media. Values: operational,

non-operational

Air space Description of the air space conditions during the activity instance. Contextual Element related to Media. Values: operational,

non-operational, operational with restrictions

Interference of the media Interference in the process for one of the Media CE. Values: true, false

Flow management Description of the flow management conditions during the activity instance. Contextual Element related to Management.

Values: inactive, active

Regulation Description of the regulation during the activity instance. Contextual Element related to Management. Values: accordance,

non-accordance

Interference of the

management

Interference in the process for one of the Management CE. Values: true, false


called TAM. This process is code 1, instance 7, reported at 22/11/201. The reason for the occurrence was attributed to a strike; theimpact was a delay in process. In this instance, the contextualelements were monitored for all of the activities previouslyindicated. We observed that all of the contextual elements behavedas expected, with normal operation, except for the Ground Worker,for which the value assumed was ‘Interrupted Performance’. Thisindicated that the contextual element ‘Man’ provoked aninterference in the process.

4.6. Definition of the situations

Once the log was organized, it was used to finish building themodel. In view of the relationship between the elements of thethree models, it was possible to define which domain modelelements represent contextual elements. After detailing thecontextual elements along with their values, we could describethe set E, which contains all contextual elements with their values.Based on this information, it is possible to characterize situations.As discussed earlier, a situation is a set of instantiated contextualelements, which constitutes a certain behavior signaling thepossible adaptation needs of a process. These situations werecreated manually based on the log. They were characterizedaccording to the probability of the aircraft takeoff activity: Takingoff extremely probable (TEP); Taking off probable (TP); Taking offimprobable (TI); Taking off extremely improbable (TEI). Thefollowing rules were defined based on the data:

Situation Taking off Extremely Probable 1 (TEP1)

TEP1 = {Aerodrome_Equipment = ‘‘Operational’’, Pilot = ‘‘Stan-dard Performance’’}

Situation Taking off Extremely Probable 2 (TEP2)

TEP2 = {Flow_Management = ‘‘Inactive’’, Mission_Type =‘‘Priority’’}

Situation Taking off Probable 1 (TP1)

TP1 = {Runway = ‘‘Operational’’, Flow_Management = ‘‘Active’’}

Situation Taking off Probable 2 (TP2)

TP2 = {Aerodrome_Equipment = ‘‘Non Operational’’, Air_Traffic_Controller = ‘‘Standard Performance’’}

Situation Taking off Improbable 1 (TI1)

TI1 = {Air_Space = ‘‘Operational with Restrictions’’, Meteorolo-gical_Condition = ‘‘Unfavorable’’}

Situation Taking off Improbable 2 (TI2)

TI2 = {Air_Traffic_Controller = ‘‘Discontinued Operation’’, Mis-sion_Type = ‘‘Priority’’}

Fig

.1

0.

Ex

tra

cto

fth

eLo

go

fo

ne

pro

cess

inst

an

ce.


Table 7Comparison of Contextual Elements.

Hazard Contextual Element Interviewee 1 Interviewee 2 Interviewee 3

Man Air traffic controller Air traffic controller Air traffic controller Air traffic controller

Pilot Pilot Pilot Pilot

Ground Worker – – –

Media Meteorological condition Ceiling, Wind, Visibility

(Contextual Element

Meteorological Condition)

Rain, Wind, Ceiling, Visibility

(Contextual Element Meteorological

Condition)

Rain, Rail, Wind, Ceiling, Visibility

(Contextual Element Meteorological

Condition)

Flow management – – –

Runway Runway Runway, Taxi runway (Contextual

Element Runway)

Runway, Taxi runway (Contextual

Element Runway)

Airspace – – Airspace

Machine Aircraft – – –

Aerodrome equipment Airspace Control Equipment,

Telecommunications Equipment

(Contextual Element Aerodrome

Equipment)

Radio Communication between the

pilot and controller(Contextual Element

Aerodrome Equipment)

Electronic and System (Contextual

Element Aerodrome Equipment)

Mission Mission type – – –

Management Regulation – NOTAM for the airport (Contextual

Element Management)

–

3 Note information concerning the establishment, condition or change in any

aeronautical facility, service, procedure or hazard; immediate awareness is

essential for staff in charge of flight operations.


Situation Taking off Extremely Improbable 1 (TEI 1)

TEI1 = {Pilot = ‘‘Discontinued Operation’’, Air_Space =‘‘Opera-tional’’}

Situation Taking off Extremely Improbable 2 (TEI 2)

TEI 2 = {Air Space = ‘‘Non Operational’’, Aircraft = ‘‘Opera-tional’’}

It is important to note that this set of situations is notexhaustive. Indeed, there may be other combinations of elementsthat characterize situations. These situations were analyzed byexperts to enable evaluate the proposal. In the following sections,these two steps are detailed.

4.7. Interviews report

The situations were evaluated by experts through interviews.We interviewed three experts: one pilot and two air trafficcontrollers. The interviews were conducted individually, followinga structured script. First, a brief description of the research focusand the objectives of the study and the interview were discussed.Then, we asked the respondents about their knowledge of theprocess. We then introduced the process model to the interviewees.Finally, we presented the list of the types of situations and theconditional clauses of the rules to be assessed. The intervieweeswere asked to associate each of the conditional clauses of the ruleswith one of the situations, depending on which best applied, and tocomment on each of their choices. The respondents could alsoanswer that ‘‘nothing can be concluded’’ about a particular clause.At the end, they were asked to voice further concerns.

4.7.1. Interviewee 1 – Pilot A

The first respondent serves as a pilot approximately twice aweek, has 28 years of experience and 2400 h of flight time. Whenasked about which elements he considers relevant to be monitoredfor this process, he listed the Pilot, Air Traffic Controller, Runway,Airspace Control Equipment, Telecommunications Equipment,Ceiling, Wind and Visibility. He suggested that the contextualelements should be more fine-grained because they are toogeneric, which can lead to inaccuracies in the rules. He cited theAerodrome as an example, for which, depending on whatequipment is used and what is involved in aircraft takeoff, theremay be a variation in the response.

4.7.2. Interviewee 2 – air traffic controller B

The second respondent, air traffic controller B, has 34 years ofexperience. He served as an air traffic controller for 30 years, asan air traffic controller in a tower for 12 years and has been atower supervisor for 5 years. When asked about which elementshe considered relevant to be monitored for this process,the respondent indicated the Pilot, Air Traffic Controller,Runway, Taxiway, Radio Communication between the pilotand controller, the existence of the NOTAM3 for the airport, Rain,Wind, Ceiling and Visibility. The respondent did not commentfurther.

4.7.3. Interviewee 3 – air traffic controller C

The third respondent, air traffic controller C, has 32 years ofexperience. He served as an air traffic controller for 25 years, as anair traffic controller in a tower for 6 years and has been a towersupervisor for 7 years. When asked about which elements heconsidered relevant to be monitored for this process, therespondent mentioned the Pilot, Air Traffic Controller, Runway,Taxiway, Electronic Equipment, Systems, Condition of airspace,Rain, Hail, Wind, Ceiling and Visibility. The respondent made thefollowing additional comments:

� The elements should be less generic because the values that arule takes can vary greatly. For example, the decisions made willbe different if the weather conditions involve fine rain or snow.� There should be a mechanism to weight each element because

their relevance could be very different; each element has adifferent weight. They do not have the same relevance whencreating a rule.

The data collected from the interviews were analyzed from twoperspectives: the relevance of contextual elements indicatedwithin the model and the validation of the rules created(Situations). For the first investigation, it was necessary to makea comparison between the contextual elements mapped by theresearchers and the elements considered significant to therespondents. Table 7 summarizes these results. A general analysisreveals that the contextual elements Air Traffic Controller, Pilotand Runway were listed by all respondents, and contextualelement Airspace was identified by one of them.


It should be noted that all respondents identified othercomponents of the domain as contextual elements. The respon-dents are domain experts, so, when asked about their perception ofcontextual elements they identified items of the domain in a verysmall granularity level than we expected at first. Within thedomain model built, those items are attributes of some classes, oreven possible specializations of those classes, and not the classitself. So, we concluded that the attributes of both classes and sub-classes can also be considered contextual elements. Therefore, wehave the following scenario:

� The first interviewee identified the elements MeteorologicalCondition (through its attributes Ceiling, Wind and Visibility)and Aerodrome Equipment (through its sub-classes AirspaceControl Equipment, Telecommunications Equipment).� The second interviewee identified the Meteorological Condition

(through its attributes Rain, Wind, Ceiling and Visibility), theAerodrome Equipment (through its attribute Radio Communi-cation between the pilot and controller) and Regulation (throughits attribute NOTAM).� The third interviewee identified the Meteorological Condition

(through its attributes Rain, Hail, Wind, Ceiling and Visibility)and Aerodrome Equipment (through its sub-classes Electronicand System Electronic and System).

The results suggest the validity of the contextual elementsassociated with the domain model because most of the contextualelements were also recognized by experts. On the other hand, thecontextual elements Ground Worker, Flow Management, Aircraftand Mission Type were not reported by any of the respondents.This suggests that these contextual factors, while important for thedomain composition – because, by mapping the data, we observedoccurrences related to them – were not remembered or do nothave a significant impact in the opinion of the respondents.

The second analysis assessed whether there is evidence thatmight validate the proposition that it is possible to characterize thesituations (context) of business process activities, which wouldcomplete the model proposed in this paper. Table 8 presents a tablecomparing the rules defined by the researchers and the referencesassigned to the same rules for each of the three experts.

For the first rule, all respondents agreed with the predictedvalue for the situation, which suggests that it is a valid rule. Thisresult may be due to the fact that all of the contextual elementstake the default values, i.e., values that do not represent badperformance for the process.

For the second rule, again there was consensus among therespondents, suggesting that the combination of these elementscharacterize a situation. In this case, the inactivity of flowmanagement indicates that the flow to and from an aerodromeis normal. The fact that the second element is a mission type set as

Table 8Comparison of the rules (situation).

Rule Element 1 Element 2

1 Aerodrome Equipment =

‘‘Operational’’

Pilot = ‘‘Standard Performance’’

2 Flow Management = ‘‘Inactive’’ Mission Type = ‘‘Priority’’

3 Runway = ‘‘Operational’’ Flow Management = ‘‘Active’’

4 Aerodrome Equipment =

‘‘Non-Operational’’

Air Traffic Controller = ‘‘Standard

Performance’’

5 Airspace = ‘‘Operational

with Restrictions’’

Meteorological Condition =

‘Unfavorable’’

6 Air Traffic Controller =

‘‘Discontinued Operation’’

Mission Type = ‘‘Priority’’

7 Pilot = ‘‘Discontinued Operation’’ Airspace = ‘‘Operational’’

8 Airspace = ‘Non-Operational’’ Aircraft = ‘‘Operational’’

a ‘‘priority’’ further indicates that the takeoff is extremely probablebecause that takeoff has precedence over others.

For the third rule, all participants understood the situation asprobable takeoff. In this case, although we have an operationalrunway, flow management is currently active to regulate the trafficin the area. According to the expert analysis, the takeoff is probablebecause traffic will cease immediately, i.e., the traffic will beresized or relocated. An example of this scenario is when there aremany aircraft waiting to take off or land because an airport isclosed due to bad weather.

For the fourth rule, none of the participants agreed with the pre-defined reference, which was Takeoff Probable. Two of the threerespondents agreed with each other, and the value attributed tothe rule was Takeoff Extremely Probable; the other respondedaffirmed that ‘‘nothing can be concluded’’ about this case. Therespondents who agreed with each other were the air trafficcontrollers, which may indicate that personal experiences can leadto different interpretations. Both of air traffic controllers disagreedwith the proposed value for the rule. The respondents indicatedthat equipment not operating at the aerodrome cannot cause adisturbance in the takeoff process because the drivers are trainedto operate in a conventional manner when there is failure in someequipment. The pilot, who said ‘‘nothing could be concluded’’,claimed that those two elements alone were not enough todetermine whether there are any deviations in the process.According to the pilot, the type of hardware used has an effect inthis scenario, as well as other factors such as weather conditions. Itis possible that other elements of context should be considered indefining this situation.

For the fifth rule, two respondents agreed partially with thereference value; they argued that the takeoff would be extremelyimprobable due to bad weather conditions. The fact that the tworespondents considered the takeoff to be ‘‘extremely’’ improbable,whereas the rule only stated that it was improbable, highlights theneed for a refinement of the rules. The other interviewee justifiedhis answer in the same way, adding that it is necessary to know thetype of restriction in airspace and weather conditions.

For the sixth rule, one respondent agreed partially with the rule,once he deemed it highly improbable to achieve a takeoff, claimingthat priority missions in general are very dependent on theperformance of the controllers, which in this rule assumes thevalue ‘‘Discontinued Operation’’. The other two respondentsagreed with each other that ‘‘nothing can be concluded’’. Theresults suggest that these two elements alone are not enough tosay assess the takeoff. The condition of the Runway, for example,could be a contributing element to this rule. Again, it is clear that inthe majority of cases, the respondents’ answers somewhat alignwith the model results. This agreement is an important indicationthat these types of rules are able to characterize situations inbusiness processes.

Inferred situation Interviewee 1 Interviewee 2 Interviewee 3

TEP TEP TEP TEP

TEP TEP TEP TEP

TP TP TP TP

TP Nothing can be

concluded

TEP TEP

TI Nothing can be

concluded

TEP TEP

TI Nothing can be

concluded

Nothing can be

concluded

TEP

TEP TEP TEP TEP

TEP TEP TEP TEP


For the seventh rule, all respondents agreed with the referencevalue. According to the respondents, the pilot’s condition of‘‘Discontinued Operation’’ makes it nearly impossible to take off.The only option would be to replace the pilot or for the co-pilot totake over. Both are unlikely.

Finally, for the eighth rule, all respondents again agreed withthe same reference value for the rule. They were unanimous inaffirming that the fact that the airspace assumes the value ‘‘Non-operational’’ carries great weight in determining whether anaircraft can takeoff. The fact that the aircraft is operationalbecomes irrelevant.

These results led to the conclusion that it is possible to identifythe context of a process by rules that characterize situations.However, it is necessary to evaluate the relevance of eachcontextual element for a given context.

4.8. Case study discussion

Through a comprehensive analysis, it is possible to observe thatin five of the eight situations all respondents agreed with thedefinition of the situations. For all rules, two or more responsescoincide with each other. Thus, there is evidence that the model isvalid because experts have a very similar understanding about theimpacts of the relationship between contextual elements in aprocess. Through this case study, we were able to identifyimportant aspects of the proposed approach:

� Extreme situations yielded greater agreement among respon-dents in terms of the reference values.� Contextual elements affect a situation to different extents.� The greater the number of contextual elements considered in

characterizing situations, the more precisely situations will bedefined.� Experts tend to have similar perceptions of the proposed scenario

and the associations between contextual elements.

These conclusions point to issues that require further attention,such as, the need to consider the relevance of each element as acomponent of a situation, and the need to create mechanisms tobetter delineate the boundaries between situations. The classRelevance is already part of the context metamodel, but it was notinstantiated in this case study.

Although the rules elicited and evaluated with the collaborationof the experts were related to the domain, it is important toemphasize that the characterization of situations presented in thiscase study made it possible to evaluate the approach as a whole. Asexpected in our proposal, the classes within the three layers(context, process and domain) were connected, and the relation-ships among those classes in the three layers were explained byrules. The rules that define the relationships within the domainmodel are more specific, but they refer to elements in all layers.

This case study had some limitations, first with respect to theparticipants and second with respect to the data used. Moreover,only one case was analyzed in a single domain.

Only three experts were interviewed, and all are based in Rio deJaneiro; moreover, the two air traffic controllers work in the sameorganization. Although the respondents are very experiencedprofessionals, this very fact might have influenced their stancesdue to their current perspective of the facts.

The data log was assembled manually through a careful analysisof the reported occurrences; therefore, the situations wereidentified manually. If there was a digital log that could be mined,perhaps other situations could be identified more precisely usingan automated method.

The next section discusses related research studies anddemonstrates our contribution and improvement to the studyareas of business processes and context.

5. Related work

Saidani and Nurcan [46] presented an approach for modelingbusiness processes that supports the description of a context inaction. To the authors, the ability to integrate Context RelatedKnowledge (CRK) enables BPMs to become flexible, active andcapable of expressing a variety of business rules. This approach isbased on four steps: elicitation, categorization, adaptation andmeasurement of context and business process instantiation.Moreover, the authors also present a taxonomy of context thatcaptures the most common CRK: location, time, human resourcesand organization. Unlike our proposal, this model considers a fewfixed elements as context and does not provide flexibility to modeldifferent domains.

Han and Park [24] proposed a framework for a knowledgemodel centered on business processes and ontology to store thecontextual knowledge needed to perform a task. The work aimedto identify and categorize the type of knowledge being generatedand accumulated. There are two types of knowledge: processknowledge and task support knowledge. The business ontologyrepresents the concepts of large companies and their relationships.All domain concepts are related to the concept process. The goal ofthis proposal is to support users in the execution of process tasks; itdoes not encompass all the details necessary to model context asour context metamodel intends to.

Rosemann et al. [45] proposed a framework for betterunderstanding the different types of context and their impacton business processes. The so-called Onion framework distin-guishes four types of context: immediate (e.g., organizationalresources responsible for the execution of the activities), internal(e.g., resources, rules, values, concepts, interests, strategies,structure and culture), external (e.g., vendors, investors, compe-titors and customers) and environmental (e.g., society, nature,technology and economics). The authors presented an approach togoal-oriented process modeling in which context can be concep-tualized, classified and integrated. The proposal also included ametamodel for classifying context and a basic procedure detailinghow to apply the framework. Although, this metamodel helps torepresent context for process, it does not relates to the concepts ofthe business domain as in our proposal.

Soffer et al. [49] presented an automated approach for learningfrom experience to improve business processes over time. In thisapproach, three aspects of business processes are combined: realpaths, context and goals. Based on this framework, a learning cyclewas proposed, including a phase where the relevant context isidentified and used to make improvements in the BPM. Moreover,the approach features an application phase at runtime, wherein theimproved BPM is applied at runtime and actual results are storedfor the next learning cycle.

From this literature review, we concluded that proposalsaddressing context in business processes have one of the followingcharacteristics: (i) they are focused on context-aware applications,(ii) restricted to the analysis of user information, environment anddevices or (iii) apply only to a specific domain or process.Furthermore, the proposals do not include a formal description ofthe concept of context related to business processes, whichprevents the instantiation in any domain and/or organizationprocess and the identification of the context of an activity by theassociation of contextual elements.

Although not focused on integrating the concepts of contextand business process, three studies present basic concepts that arequite similar to those specified in our proposal. Feng et al. [20] alsodistinguish context and situation. Context involves the elements inan environment defined in time and space, the comprehension oftheir meaning and the projection of their status in the near future,and situation is related to the collection of immediate people and

Table 9Related work comparative analysis.

Approach presented

in literature

Main characteristics related to the discussion of the paper Advantages of the metamodel proposed in this paper

[46] Presents a taxonomy that comprises the following contextual

elements: location, time, human resources and organization

Provides flexibility to model different domains and types of

contextual elements

[24] Supports users in the execution of process tasks, based on very

generalist concepts of context: process knowledge and task

support knowledge

Encompasses the details necessary to model context related to a

domain

[45] Provides a framework that distinguishes four types of context:

immediate, internal, external and environmental

Allows any type of context to be linked to the business domain

concepts

[49] Presents an application that helps learning from experience to

improve business processes where three aspects of business

processes are combined: real paths, context and goals

Includes a formal description of the concept of context related to

business processes

[20] Distinguishes the concepts of context and situation and focuses on

physical entities and their attributes, such as location, and our

model involves the modeling of any domain

Provides flexibility to model different types of contextual

elements, not limited to the traditional physical entities

[6] Uses the concept of Situation to aggregate and model specific

conditions and constraints that need to be recognized to signal the

need to execute certain actions

Guarantees the application of the concept of Situation in business

processes

[16] Applies the concept of current situation to allow handheld devices

providing information and offer services to users over mobile

networks

Focuses on business processes in general, rather than users’

conditions requiring actions

[29]/[2] Uses the concept of context to address the problem of achieving

more comprehensible models in process mining

Provides a basis to dynamic process adaptation based on context


objects, as well as changes to those objects over time. As stated bythe authors, situation awareness focuses on the modeling of auser’s environment, whereas context awareness is about exploit-ing the context of a user and supporting the user to have a moreeffective interaction with a system by adapting the system’sbehavior according to the user’s current context or situation. TheSituation Model proposed is composed of associated entities andevents. Although the concepts used are similar to those developedin our proposal, they focus on physical entities and their attributes,such as location, and our model involves the modeling of anydomain.

Situation is defined by Bettini et al. [6] as a semantic abstractionof low-level data. The authors used this concept to aggregate andmodel specific conditions and constraints that need to berecognized to signal the need to execute certain actions. Ciminoet al. [16] also address the topic of situation awareness, stating thatthe understanding of a current situation can allow handhelddevices to provide information and offer services to users overmobile networks. The authors propose a framework based ongeneral rule-based approach to manage situation awareness. Intheir proposal, an extension of the ECA (Event Condition Action)architectural pattern, referred to as ECAA (Event Control ActionAdaptation), provides a high-level structure that facilitates thedesign of situation-aware applications, solving problems associat-ed with the management of situational information upon changesin users’ context. Thus, the modeling of Situation is quite similar tothat adopted in our proposal; however, the authors concentratedon users’ conditions, while in our case, the business process is thefocus.

According to van der Aalst et al. [2], process mining techniquesaims to discover, monitor and improve real processes by extractingknowledge from event logs available in information systems. A fewworks relate process mining to context awareness, such as [9,29].However, those works use the concept of context to address theproblem of achieving more comprehensible models. They arguethat context-dependent patterns could be used to obtain event logsat a higher abstraction level. In our proposal, we are not dealingwith process discovering; instead, the intention to supportdynamic process adaptation based on context. So, this is not thecase of discovering or even improving, but to model relevantcontextual variables, that when monitored could support aninstance to be adapted. That is why representing context is

important. Our work aims to provide a basis for this, by proposing ametamodel that integrates context to process.

Table 9 highlights the main achievements of each work inliterature related to the discussion of this paper, and presents thedifferences and advantages between them and our proposal.

6. Conclusions

The success of an organization increasingly depends on itsability to be flexible and react quickly to changes. Thus, businessprocesses must be able to adapt to such changes, the so-calledcontext. Although there are some models proposed in the literaturethat address the context associated with business processes, thereis still no model for representing context in business processes. Inthis paper, we proposed an approach to represent the context of anactivity of a business process in a given domain. This approach wasdeveloped through conceptual metamodels structured in layersthat incorporate aspects related to context. The metamodels wereevaluated by a case study involving a complex, critical and relevantreal scenario: Airspace Control. The results of this assessmentprovided evidence of the feasibility of the formalization proposed.There is an initial and relatively high cost to build the models andestablish the necessary relationships, because the domain and itsenvironment should be analyzed. However, when it is done, theexecution of all instances of the process could be made basedon that model, and we argue that this would make adaptationseasier to be applied. Besides, the domain model and the contextcould be at least partially reused for other processes in the sameorganization, since dealing with the same business.

The motivation of this proposal is the focus on the use of contextto adapt business processes. Most context models found in theliterature are limited to the analysis of user information, devicesand environment. Thus, our main contribution is an approach thatis more comprehensive and flexible and that can be applied in anydomain and process of an organization.

Another advantage over existing models is the formal descrip-tion of the Situation of an activity, which highlights the notion thatcontext is a complex concept that should be defined through acombination of independent contextual elements that act togeth-er. The conceptual metamodel can support the adaptation processbecause it not only considers current circumstances but alsocaptures how these conditions affect the process.


An important point to emphasize is that the focus of theevaluation performed in this study was the concept of situationand its relationship with other model elements. In this proposal,the process model, derived from the Business Process Metamodel,was constructed based on the concepts of this layer. The ContextModel was created based on the concepts of the ContextMetamodel, which includes the elements Situation and ContextualElement. Subsequently, its instances were also created, whichconsequently led to the incorporation of other elements of themetamodel, for example, Activity, Role and Actor.

For the Business Process Metamodel, we decided to use at firstour own metamodel, instead of trying the most obvious BPMN, EPCor UML (Activity Diagram) metamodels, mainly due to thepossibility of representing some attributes of an activity thatcould be typically considered context. However, it does not meanwe suggest abandoning the established metamodels. We shouldstudy the costs of extending each of them and compare with thesolution proposed here.

The case study allowed us to observe the effects of the absenceof the element Relevance. Relevance is the level of importance of acontextual element in relation to the Focus. The effects of theelement’s absence were made evident when experts indicated theimportance of considering the weights of each Contextual Elementto make better decisions about the Situation. This finding brings usto the issue of which other elements of the metamodel context mayalso be relevant as components of the proposed approach and arenot yet being considered as components of the context model. Twoconcepts to consider are Focus and Context Entity. Because theFocus determines what can be considered to be relevant in acontext, it might be explored in conjunction with Relevance toestablish more precise situations. In addition, Contextual Entity,for which information is provided by contextual elements, can beapplied to help characterize situations, which in turn facilitatedecision making regarding the course of a process.

Moreover, the proposed approach is not exhaustive. Indeed, inthe context and process metamodels, other elements could beconsidered, i.e., the models should evolve. The models considerpreviously known contextual elements, defined as relevant, to bemonitored. If, for example, a new contextual element arises duringthe execution of a process, the current model does not handle thiselement, which will be monitored only when the model is revised.

In future work, we intend to apply and evaluate the modelproposed in other scenarios with a greater number of expertswith different backgrounds and diverse working locations. Newcase studies would support the comparison of results, andgeneralization.

We will also extend the proposed approach to the definition andvalidation of new rules within the metamodels, applyinginferences and developing the model to consider the contextualrelevance of each element and the impact of each contextualelement in every single activity.

Although the metamodel proposed provides a basis foradaptation of processes, it does not comprise the completesolution in the sense that it deals with predefined elements.One important issue that should be considered is that context isalso dynamic, and as so, new situations could arise or even somesituations could lose its relevance. Thus, a context-based adapta-tion system should, not only represent context associated withprocess under a domain, but it should learn from adaptationdecisions made, as well as continuously identify new unforeseensituations (sets of contextual elements). In [14], we present thepreliminary results from the implementation of schemes for theidentification of relevant contextual elements and situations byapplying Data Mining techniques in process logs. We present a firststep to the computational engine that infers the need to updatesituations and identify the contextual elements through mining

technique, providing a solution for the evolvement of the contextmodel.

References

[1] M. Anastassiu, F.M. Santoro, A method for identification of relevant context inbusiness process, in: Proceedings of the 1st International Workshop for Context inBusiness Process Management (CBPM’13) in conjunction with CONTEXT 2013,Annecy, France, 2013, Available at: http://grid.lzu.edu.cn/psrl/cbpm/program.html.

[2] W.M.P. van der Aalst, A. Adriansyah, A.K.A. Medeiros, F. de Arcieri, T. Baier, T.Blickle, J.C. Bose, P. van den Brand, R. Brandtjen, J. Buijs, et al. Lecture Notes inBusiness Information Processing 99 (2) (2012) 169–194.

[3] M. Bazire, P. Brezillon, Understanding context before using it, in: 5th Internationaland Interdisciplinary Conference, CONTEXT 2005, Paris, France, Lecture Notes inComputer Science 3554 (2005) 29–40.

[4] J. Bauer, Identification and modeling of contexts for different information scenariosin air traffic, Diplomarbeit, Technische Universitat Berlin, 2003.

[5] C. Bauer, A comparison and validation of 13 context meta-models, in: Proceedingsof the 20th European Conference on Information Systems (ECIS 2012), Barcelona,Spain, paper 17, 2012, http://aisel.aisnet.org/ecis2012/17.

[6] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Rangabathan, D.Riboni, A survey of context modeling and reasoning techniques, Pervasive andMobile Computing 6 (2) (2010) 161–180.

[7] I. Bider, Masking flexibility behind rigidity: notes on how much flexibility peopleare willing to cope with, in: Proceedings of the CAiSE’05 Workshops, Workshopon Business Process Modeling, Development and Support, Porto, Portugal, (2005),pp. 7–18.

[8] Bizagi Process Modeler, Version 1.6.1.0, 2012. BPMN Software. Available at:http://www.bizagi.com. (accessed March 2013).

[9] R.P.J.C. Bose, W.M.P. van der Aalst, Context Aware trace clustering towardsimproving process mining results, in: Proceedings of the SIAM InternationalConference on Data Mining, SDM, 2009, pp. 401–412.

[10] P. Brezillon, L. Pasquier, J.C. Pomerol, Reasoning with contextual graphs, EuropeanJournal of Operational Research 136 (2) (2002) 290–298.

[11] P. Brezillon, Representation of procedures and practices in contextual graphs,Knowledge Engineering Review 18 (2) (2003) 147–174.

[12] P. Brezillon, Context in problem solving: a survey, The Knowledge EngineeringReview 14 (1) (1999) 1–34.

[13] P. Brezillon, J.C. Pomerol, Contextual knowledge sharing and cooperationin intelligent assistant systems, Le Travail Humain, 62, PUF, Paris, 1999,pp. 223–2463.

[14] J.E.S. Carvalho, F.M. Santoro, K. Revoredo, V.T. Nunes, Learning context to adaptbusiness processes, in: Proceedings of the 2013 IEEE 17th International Confer-ence on Computer Supported Cooperative Work in Design (CSCWD), Whistler,Canada, (2013), pp. 229–234.

[15] H. Chen, T. Finin, A. Joshi, An intelligent broker for context aware systems,Computer and Information Sciences 54 (November) (2004) 129.

[16] M.G.C.A. Cimino, B. Lazzerini, F. Marcelloni, A. Ciaramella, An adaptive rule-basedapproach for managing situation-awareness, Expert Systems with Applications39 (2012) 10796–10811.

[17] K. Cheverst, K. Mitchell, N. Davies, Design of an object model for a contextsensitive tourist GUIDE, Computers and Graphics 23 (6) (1999) 883–891.

[18] E. Chtcherbina, M. Franz, Peer-to-peer coordination framework (p2pc): enabler ofmobile ad-hoc networking for medicien, business, and entertainment, in: Pro-ceedings of International Conference on Advances in Infrastructure for ElectronicBusiness, Education, Science, Medicine, and Mobile Technologies on the Internet(SSGRR2003w), L’Aquila, Italy, January, 2003.

[19] T. DeMarco, Structured Analysis and System Specification, Yourdon Press,New York, 1978.

[20] Y.H. Feng, T.H. Teng, A.H. Tan, Modeling situation awareness for context-awaredecision support, Expert Systems with Applications 36 (2009) 455–463.

[21] Gartner Group, Meeting the Challenge: The 2009 CIO Agenda. EXP Premier ReportJanuary 2009, Gartner, Inc., Stamford, Connecticut, 2009.

[22] C. Ghidini, F. Giunchiglia, Local models semantics, or contextual reasoning localitycompatibility, Artificial Intelligence 127 (2) (2001) 221–259.

[23] T. Gu, H.K. Pung, D.Q. Zhang, A middleware for building context-aware mobileservices, in: Proceedings of IEEE Vehicular Technology Conference (VTC), Milan,Italy, 2004.

[24] K.H. Han, J.W. Park, Process-centered knowledge model and enterprise ontologyfor the development of knowledge management system, Expert Systems withApplications 36 (4) (2009) 7441–7447.

[25] A. Held, S. Buchholz, A. Schill, A modeling of context information for pervasivecomputing application, in: Proceedings of the Sixth Multiconference onSystemics, Cybernetics and Informatics (SCI 2002/ISAS 2002), USA, 2002.

[26] T. Hofer, W. Schwinger, M. Pichler, G. Leonharsberger, J. Altmann, Context-awareness on mobile devices – the hydrogen approach, in: Proceedings ofthe 36th Annual Hawaii International Conference on System Sciences, 2002,pp. 292–302.

[27] J. Hong, E. Suh, S.J. Kim, Context-aware systems: a literature review and classifi-cation, Expert Systems with Applications 36 (2009) 8509–8522.

[28] K. Kumar, M. Narasipuram, Defining requirements for business process flexibility,in: Proceedings of the CAiSE’06 Workshop. Workshop on Business ProcessModeling, Development, and Support (BPMDS’06), 2006, pp. 137–148.


[29] J. Li, R.P.J.C. Bose, W.M.P. van der Aalst, in: Jianwen Su, Michael zur Muehlen(Eds.), Business Process Management Workshops (BPM 2010 International Work-shops, Hoboken NJ, USA, September 13, 2010). Lecture Notes in Business Infor-mation Processing, 66, Springer, Berlin, 2010, pp. 109–121.

[30] T. Mattos, F.M. Santoro, K. Revoredo, V.T. Nunes, Formalizing the situation of abusiness process activity, in: Proceedings of the 16th IEEE International Con-ference on Computer-Supported Cooperative Work in Design, Wuhan, (2012),pp. 128–134.

[31] J. McCarthy, Notes on formalizing context, in: Proceedings of the 13th Interna-tional Joint Conference on Artificial Intelligence, France, (1993), pp. 555–560.

[32] N.F. Noy, D.L. McGuinness, Ontology Development 101: A Guide to Creating YourFirst Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, 2001March.

[33] V.T. Nunes, F.M. Santoro, M.R.B. Borges, Context in knowledge intensive collabo-rative work, in: 10th International Conference on CSCW in Design, 2006, Nanjing,Vol. 2, (2006), pp. 793–798.

[34] V.T. Nunes, F.M. Santoro, M.R. Borges, A context-based model for knowledgemanagement embodied in work processes, Information Sciences 179 (15) (2009)2538–2554.

[35] V.T. Nunes, C.M.L. Werner, F.M. Santoro, Dynamic process adaptation: a context-aware approach, in: 15th International Conference on Computer SupportedCooperative Work in Design, Lausanne Switzerland, (2011), pp. 97–104.

[36] V.T. Nunes, C.M.L. Werner, F.M. Santoro, Mediating process adaptation through agoal-oriented context-aware approach, in: Proceedings of the 16th IEEE Interna-tional Conference on Computer-Supported Cooperative Work in Design, Wuhan,(2012), pp. 160–167.

[37] UML-OMG, Object Management Group Unified Modeling Language, 2013 Avail-able at: http://www.uml.org (accessed April 2013).

[38] BPMN, OMG – Object Management Group Business Process ManagementNotation, 2013 Available at: http://www.bpmn.org (accessed April 2013).

[39] ONTOVIZ – Available at http://protegewiki.stanford.edu/index.php/OntoViz_1.0(accessed April 2013).

[40] K. Ploesser, J. Recker, Context-aware methods for process modeling, in: J.A.Beckmann (Ed.), Business Process Modeling: Software Engineering, Analysisand Applications, Nova Publishers, Hauppauge, New York, 2011.

[41] PROTEGE OWL. – ‘‘Protege OWL Editor’’, Version 3.4.8, Available at: http://protege.stanford.edu/overview/protege-owl.html (accessed April 2013).

[42] A. Rakesh, S. Ramakrishnan, Fast algorithms for mining association rules in largedatabases, in: Proceedings of the 20th International Conference on Very LargeData Bases (VLDB), Santiago, Chile, (1994), pp. 487–499.

[43] E.C. Ramos, F.M. Santoro, F.A. Baiao, Thinking out of the box: discovering therelevance of external context to business processes, Knowledge Discovery,Knowledge Engineering and Knowledge Management Communications in Com-puter and Information Science 348 (2013) 455–470.

[44] J. Recker, M. Rosemann, M. Indulska, P. Green, Business process modeling – acomparative analysis, Journal of the Association for Information Systems 10 (4)(2009) 333–363.

[45] M. Rosemann, J. Recker, C. Flender, Contextualization of Business Processes,International Journal of Business Process Integration and Management 3 (1)(2008) 47–60.

[46] O. Saidani, S. Nurcan, Towards context aware business process modeling, in:Workshop on Business Process Modeling, Development, and Support (BPMDS),Trondheim, Norway, 2007.

[47] W.N. Schilit, A system architecture for context-aware mobile computing, PhDthesis, Columbia University, 1995.

[48] H. Schonenberg, R. Mans, N. Russel, Process flexibility: a survey of contemporaryapproaches, in: 4th International Workshop CIAO, and 4th International Work-shop EOMAS, CAiSE 2008. PC Montpellier, France, 2008, 16–30.

[49] P. Soffer, J. Ghattas, M. Peleg, A goal-based approach for learning in businessprocesses, in: Nurcan, Salinesi, Souveyet, Ralyte (Eds.), Intentional Perspectiveson Information Systems Engineering, Springer, 2010, pp. 239–256.

[50] T. Strang, C. Linhoff-Popien, A context modeling survey, in: 1st InternationalWorkshop on Advanced Context Modeling, Reasoning and Management, Ubi-Comp 2004 – The Sixth International Conference on Ubiquitous Computing,Nottingham/England, 2004.

[51] Y. Tao, J. Wang, X. Wang, D. He, S. Yang, Knowledge-based flexible businessprocess management, in: TENCON 2006. 2006 IEEE Region 10 Conference, 2006.

[52] UNITED STATES. Department of Transportation–Federal Aviation Administration,FAA System Safety Handbook, Chapter 15, Operational Risk Management, 2000Available at: http://www.faa.gov/library/manuals/aviation/risk_management/ss_handbook/media/chap15_1200.pdf (accessed May 2012).

[53] M. Uschold, M. Gruninger, Ontologies: principles, methods, and applications,Knowledge Engineering Review 11 (2) (1996) 93–155.

[54] V. Vieira, P. Tedesco, A.C. Salgado, Designing context-sensitive systems: anintegrated approach, Expert Systems with Applications 38 (2) (2011) 1119–1138.

[55] V. Vieira, P. Tedesco, A.C. Salgado, P. Brezillon, Investigating the specifics ofcontextual elements management: the CEManTIKA approach, in: CONTEXT’07Proceedings of the 6th International and Interdisciplinary Conference on Model-ing and Using Context, Berlin, (2007), pp. 493–506.

[56] R.K. Yin, Case Study Research: Design and Methods, SAGE Publications, 2002.[57] M. Weske, Business Process Management: Concepts, Languages, Architectures,

1st ed, Springer, 2007.[58] R.J. Wieringa, D.N. Jansen, Techniques for reactive system design: the tools in

TRADE K.R, in: A. Dittrich, M.C. Geppert, Norrie (Eds.), CAiSE 2001, LNCS 2068,Springer-Verlag, Berlin/Heidelberg, 2001, pp. 93–107.

[59] Z. Zainol, K. Nakata, Generic context ontology. Generic context ontology model-ing: a review and framework, in: Proceedings of the 2nd International Conferenceon Computer Technology and Development (ICCTD 2010), Cairo, Egypt, (2010),pp. 126–130.

Talita da Cunha Mattos received her M.Sc. degree inInformatics from Federal University of the State of Riode Janeiro, Brazil, in 2012 and the B.Sc. degree inElectronic Engineering from Federal University of Rio deJaneiro, Brazil, in 2005. Her research focuses onInformation Systems, especially on the followingsubjects: Business Process Management and ContextManagement. Currently she is an engineer at BrazilianAir Force, supporting IT systems for Air Traffic Controland Air Defense.

Flavia Maria Santoro is an Associate Professor atApplied Informatics Department of the Federal Univer-sity of the State of Rio de Janeiro, Brazil. She receivedher Ph.D. and M.Sc. degrees in Computer Science fromFederal University of Rio de Janeiro (COPPE-UFRJ). Herresearch focuses on Information Systems, especially onthe following subjects: Business Process Management,Knowledge Management, Computer-Supported Coop-erative Work and Computer-Supported CollaborativeLearning. She participated in Latin-American researchprojects and has experience in organizing workshopsand conferences. She joint the Universite Pierre et MarieCurie – Paris VI, Franca (2004–2005) and QueenslandUniversity of Technology, Australia (2012–2013) insabbatical research projects.

Kate Cerqueira Revoredo is a Professor at AppliedInformatics Department of the Federal University of theState of Rio de Janeiro, Brazil. She obtained her M.Sc andD.Sc. degrees in Computer Science from FederalUniversity of Rio de Janeiro (COPPE-UFRJ). During theyear 2006 she worked for six months at the Universityof Freiburg, Freiburg (Germany) as part of her D.Sc.research. Her experience and research work focus onmachine learning, data mining, social media analyticsand ontology alignment. She participates in severalprogram committees of national and internationaljournals and conferences, and is a member of theBrazilian Computer Society and the Special Commissionin Artificial Intelligence.

Vanessa Tavares Nunes is a D.Sc. student at theSystems and Computing Engineering Department ofCOPPE Institute from the Federal University of Rio deJaneiro, Brazil. She received her M.Sc. degree inComputer Science from Federal University of Riode Janeiro (NCE-UFRJ). Her research focuses onInformation Systems, especially on the followingsubjects: Business Process Management, KnowledgeManagement, Context Management and Organiza-tional Architecture. She coordinates consulting pro-jects at companies in the field of Organizationalmodeling, Business Process Management and Softwaredevelopment.

A Formal Representation for Context-Aware Business Processes

Documents

Transcript of A Formal Representation for Context-Aware Business Processes