A Formal Representation For Context-Aware Business Processes

Computers in Industry 65 (2014) 11931214
Contents lists available at ScienceDirect
Computers in Industry
journal homepage: www.elsevier.com/locate/compind
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, Brazil
b
COPPE, Universidade Federal do Rio de Janeiro (UFRJ), Rio de Janeiro, RJ, Brazil
A R T I C L E I N F O
A B S T R A C T
Article history:
Received 23 July 2013
Received in revised form 19 April 2014
Accepted 9 July 2014
Available online 1 August 2014
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 exibility 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 specicity. This information denes 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.
Keywords:
Business process
Context
Situation
Business process adaptation
1. Introduction
A business process is a set of activities performed in a
coordinated manner within an organizational and technical
environment to achieve a business goal [57]. Processes remain a
top priority in a business setting; however, some aspects of their
effective implementation remain a challenge [21]. Deviations in
working routines are one of them. Thus, managing processes
without dealing with these possible changes can lead to the
inadequate performance of an organization [40].
The exibility of a process is related to an understanding of
unexpected events, which occur when people, systems and
resources interact and may require adjustments. Thus, business
processes must be designed to respond to different events and
their specicity, as well as to unpredictable conditions in an
environment. 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: talita.mattos@uniriotec.br (T.d.C. Mattos),
avia.santoro@uniriotec.br (F.M. Santoro), katerevoredo@uniriotec.br
(K. Revoredo), vanunes@cos.ufrj.br (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 information might indicate the need for modications in processes,
which facilitates learning from the past to support decision
making.
According to Bider [7], a great part of everyday life events can be
predicted but never a hundred percent of all events. Not all
possibilities of action are known in advance. Moreover, even if it
was possible to represent all possibilities in a process model, this
would likely reduce the ability to understand the model due to the
high degree of complexity required [7,28].
As an example, let us consider the following scenario: an
American company named ABC sells products through the
Internet. A customer, John, living in Brazil, has a daughter who
lives in the United States. He decides to send her an item from ABC
as a gift. Thus, this item would have to be delivered in the United
States. However, when he tries to make a purchase with his
international credit card, it is denied. Although the card is valid, the
process expects the delivery country to be the same as that where
the credit card invoice is received. In this case, the delivery address
is in the United States, whereas the billing address is in Brazil. The
fact that the country where the credit card bill is received is
different from the delivery country is not a predictable scenario,
and so, the purchase is not authorized. Nonetheless, the situation
undermines the primary purpose of the process, which is to
achieve sales. This example illustrates the importance of developing adequate approaches that can handle new situations, allowing
for the adaptation of a running process.
1194
T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214
Hong et al. [27] performed an extensive literature review

regarding context-aware information systems and classied
studies according to a framework based on the most common
architecture for such systems, which consists of ve layers:
concept and research, network, middleware, application and user
infrastructure. They also proposed a research agenda for this area
of study, identifying gaps in each layer. One particular conclusion
reached by the authors supports our research, highlighting the
need for a formalization approach: the integration of contextaware theory and concept studies may broaden our horizon on this
subject. Although there are several proposals that address the
concept of context associated with business processes (including
[45,46,24,49,35,36]), to the best of our knowledge, none of them
have yet presented a generic and formal model to support the
representation of such scenarios, exposing adaptation needs to
enable organizations to achieve their goals. The problem addressed
here is the lack of formal models that associate process models
with the contextual elements that might impact the execution of
the process instances.
Therefore, this paper presents a formal description of how the
context of a business process activity in a given domain can be
represented. The formalization is made through a metamodel. A
metamodel typically denes the language and/or the processes
from which to form a model, i.e., a collection of concepts within a
certain domain. While a model is an abstraction of phenomena in
the real world; a metamodel is yet another abstraction, highlighting properties of the model itself. The metamodel presented is
structured in three layers, that together, are able to support the
representation of relevant contextual variables (associated to
process model within its domain). When monitored, those
variables might support a process instance to be dynamically
adapted.
Our main contribution lies in extending the proposals reported
in the literature to build a broad and exible model as a basis for
adapting business processes based on context. The metamodel can
be applied to any organization domain and business process; since
it is generic (i.e. it does not use a domain-specic metamodel). The
advance provided by the layered approach is based on two
arguments. First, the establishment of explicit relationships among
the elements of each layer (for example, a process model element,
the external data billing address, is explicitly nominated as a
contextual element). Second, the Situation, which is dened as part
of the Context metamodel, integrates a set of contextual elements
through a formalism based on logic. This element is associated
with Activity element in the Process layer. From this point on,
contextual elements and the situations composed by them could
be monitored as so by a process-aware information system.
The paper is organized as follows: Section 2 presents the
theoretical background; Section 3 presents our proposed metamodel; Section 4 discusses a case study to investigate the
applicability of the proposal; Section 5 describes related work in
context-aware business processes, highlighting the gaps in the
literature; and Section 6 provides conclusions and proposes future
studies in this line of research.
2. Background knowledge
In this section, we review the elements that might compose a
business process model (see Section 2.1) and different denitions
of context for general use (see Section 2.2). These concepts are the
foundation of our proposal.
2.1. Business process model
In a highly dynamic market, organizations are constantly
evolving to remain competitive. In this scenario, business
processes are the factors that sustain and improve the core
competencies of organizations [51]. Moreover, a business process
can be represented through a business process model. The model
creates an abstraction of a business process, providing an
understanding of how various activities are conducted. The model
represents a set of orderly and structured activities with welldened inputs and outputs and also indicates the actors
responsible for performing tasks.
According to [44], process modeling is a practice used to
visualize and formally describe current (as-is) and redesigned (tobe) business processes. However, although traditional and wellestablished languages (and the metamodels behind them), such as
BPMN, EPC, UML (Activity Diagram) are able to represent scenarios
of a process, they do not include the concept of context explicitly.
Besides, we argue that any attribute related to the activity of a
process might be considered a contextual element. We notice that
those metamodels (although they are extendable) do not comprise
some of these attributes, as for example, business rule, term, and
discussion/interaction. Thus, we decided to use an ontology
developed before within our research group.
Nunes et al. [33] proposed a metamodel to support the creation,
manipulation and reuse of contextual information related to the
activities of a business process based on an ontology. In [33], all of
the elements of a process model were considered specializations of
a class called Context; thus, all of them were considered potential
contextual elements (Fig. 1). The main subjects presented in this
ontology are (i) information that exists during an activity
represented by the classes Resources, Time, Glossary, Business
Rule, Process, Artifacts and External Data; and (ii) information
about the individuals and the group as a whole that executes an
activity and the interactions that occur between them represented
by the classes Actors, Person, Group, Role, Competence and
Interaction. Therefore, the model was characterized as a business
process metamodel [34] that might support the creation of
business process models; hence, it was chosen as the basis for
our research.
2.2. Context representation
The concept of context has been dened in various ways in the
literature. Early in Software Engineering, for example, a Context
Diagram denes the boundary between a system, or part of a
system, and its environment, showing the entities that interact
with it [19]. Techniques for reactive systems design also mention
the notion of environment as a kind of context in which a system
performs, i.e., the interactions of a software system consist of
exchanges of occurrences (e.g. data items, events) with the
environment [58]. Those denitions are similar to the one used
in this paper: context makes a distinction between a focus and its
environment.
An action is executed or an event occurs in a context. While an
event is a real-world occurrence that can be distinguished, context
can be dened as a complex description of the knowledge shared
on physical, social, historical and other circumstances where
actions or events happen. All this knowledge is not a part of the
action or the event, but will constrain the execution of the action or
the interpretation of the event [12]. In a business process scenario,
in which organizations must quickly detect and respond to
changes in their routines, context is the minimal set of variables
that contains all relevant information impacting the design and
implementation of a business process [45]. Due to the relevance of
context in various knowledge domains or applications [3], some
efforts have been made to create languages and metamodels that
are able to specify context.
Languages provide the appropriate syntax to represent the
elements necessary for the construction of both metamodels and
1195
Fig. 1. Context model based on ontology [33].
specic models resulting from them. Languages are usually data

structures used for the representation and exchange of contextual
information [6]. We identied the following types of languages:
key-value [47,50], markup schemes [25,18], graphics (UML activity
diagram extended [4]; Contextual Graphs [10,11]), objectoriented [26,17], languages based on logic [31,22] and languages
based on ontology [23,15].
A metamodel of context provides structure at a generic level
that is not tied to any specic system or approach, whereas a
context model species the relevant context for a particular
context-aware service/system. Metamodels dene context at an
abstract level, establishing the basis for constructing context
models to support system designers in their decisions about what
context variables must be integrated into a system [5]. Moreover,
the models are intended to enumerate the concepts that should be
addressed as context by a context-aware system.
Bauer [5] compared thirteen metamodels of context and
categorized them according to the degree to which they abstracted
a given context from the real world. Thus, a metamodel with a high
degree of abstraction describes the world using generic categories.
A metamodel with a low level of abstraction represents context
with more specic categories. Among the works studied [59]
proposed an ontology of context composed of three basic classes:
extrinsic context, interface context and intrinsic context, which are
related to the physical world and individual and technological
dimensions, respectively.
Brezillon and Pomerol [13] proposed a theory that classies
context according to the focus of attention. To these authors,
context cannot be isolated but must always relate to a focus. This
focus determines what can be considered relevant within a given
context and is represented by a task, a step in problem solving or
decision making, or even the goal of a given process and
organization.
Vieira et al. [54] adopted the denition of context proposed by
Brezillon and Pomerol [13] and distinguished between the
concepts of contextual element and context: (i) a contextual
element is any piece of data or information that allows an entity to

be characterized within a domain; and (ii) context is the set of
instantiated contextual elements that are needed to support a task
performed by an agent (human or software). Additionally, the
elements that compose context have a relevant relationship with
the task that the agent is performing. Moreover, a contextual
element is stable and can be set at designated time, whereas
context is dynamic and must be constructed at runtime, when the
interaction occurs.
The context metamodel proposed by Vieira et al. [55] denes
the semantics of the core concepts used to build context models
and is an extension of UML 2.0 [37]. The metamodel is divided into
two main packages that organize concepts into two categories:
context.metamodel.structure: describes concepts related to the
conceptual and structural elements of a context-aware system, and
context.metamodel.behavior: incorporates concepts related to
behavioral aspects of a context-aware system. The structure of
the metamodel involves the following concepts: Contextual Entity,
Contextual Element, Context Source, Focus and Rule:
Contextual Entity represents the entities that should be
considered for the manipulation of context. An entity is a
concrete representation of a real-world object that can be
distinctly identied 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 in
the context metamodel and can be identied from the set of
attributes and relationships associated with an entity. A context
will consist of an aggregation of contextual elements.
Context Source provides information about how a contextual
element is acquired. The ways in which element contexts are
acquired may differ depending on the nature of the contextual
element 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 be
instantiated and used to compose the context. It is determined
1196
by the Task together with the Agent who is running the Task. An
Agent 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 value
of true, false or null (unknown), when combined with the
available data. An action indicates a procedure that should be
performed when the rule conditions are met.
The metamodel also supports concepts such as: Task, Agent,
Role, Relevance and Acquisition. An important issue is the
possibility of associating the Focus with all contextual elements
that are relevant to support it. The level of relevance of this
association is affected by the agent who is performing the task.
Once they were identied, we were able to divide the main
reference studies on context modeling into two groups. The rst
group concerns the languages on which metamodels/models are
developed. The second group concerns more generic metamodels
that describe the concepts of context. Our proposal ts within the
second group because it aims to provide conceptual models
structured in layers for the representation of context.
We used the work of Vieira et al. [54] as the starting point for
our proposal. However, it is important to note that despite the fact
that Vieira et al. metamodel denes the concept of context, it is not
specically suited for business processes; therefore, it does not
make explicit the relationships between the relevant concepts and
the domain of a business. Thus, describing how to use the concept
of context in business processes remains an important issue to be
addressed.
Furthermore, in order to use the metamodel in a real domain, it
is necessary to extend the concept of contextual element to the
specic domain concepts. We argue that the domain model should
be built separately for the sake of modularity and to better express
the three groups of concepts involved: context, process and
domain. The next section presents our proposal to establish a
formal relationship between business processes and the concept of
context in a given domain, which will support the development of
context-aware process based systems.
3. A layered metamodel for context-aware business processes
The dynamic nature of a modern business environment makes a
business process subject to a wide range of variations; thus,
exible approaches are needed to respond to such variations [48].
Business process models tend to be rigid in format and are not able
to easily encompass either foreseen or unforeseen variations in the
environment in which they operate. It is due to rst, it is very hard
to predict all the possible variations, and second, if the modeler
tries to include all the possible variations in the model, it would
probably turn to be very difcult to manage. So, the approach here
is to deal with relevant variations as context and address them
adapting the process when they occur.
Each instance of a business process is subject to changes in
context, i.e., each iteration is a set of context-related information.
Additionally, contextual knowledge can add relevant information
to support the execution of activities and describe artifacts or
explain why certain decisions were made.
We propose the representation of context in business processes
based on conceptual models. The fundamental concept adopted
here is that context is the set of instantiated and combined
(Situation) contextual elements that are necessary to support an
activity in a business process. A layered approach provides a
conceptualization of the various aspects related to context. Thus, it
is possible to isolate the elements belonging to each layer and
thereby establish their relationships. Moreover, the modular
characteristic of this proposal should facilitate the maintenance
and development of the model, as shown in Fig. 2.
The rst layer is the Context Metamodel, which refers to the

elements related to the manipulation of context, including the
concept of Situation [30], and their relationship. It is based on the
proposal of Vieira et al. [54]. The second layer is the Business Process
Metamodel, which denes the elements that should be used to
describe a process, with the focus on the activity of the work
process. It is based on the model of Nunes et al. [33]. Finally, the
third layer represents the Domain Metamodel, which is responsible
for supporting the denition of the data structure, functions,
relationships and constraints of the knowledge area considered.
This layered approach provides different levels of abstraction and
aims to support not only the representation of context but also the
properties necessary to deal with context in a business process.
An ontology formalism [53] was adopted to build the
conceptual metamodels. According to Noy and McGuinness [32],
ontologies are developed to facilitate the sharing and reuse of
information to describe concepts, properties, constraints and
relationships. In our case, to enable the use of this information, it is
important to understand the underlying semantics and be able to
manipulate the information. The ontology was developed using the
software [41], and a graphic model was generated using the plugin
[39]. Classes are represented by rectangles and relationships by
arrows. The metamodels are described in detail in the following
sub-sections.
In the following sections the three Metamodels are described in
more details.
3.1. Context Metamodel layer
The Context Metamodel comprises the concepts related to
context and their relationships. It was adapted from the
context.metamodel.structure package of the context model proposed by Vieira et al. [54], where the main differences are as
follows: the classes Agent, Role and Task were excluded because
they are related to the Business Process and therefore will be
represented in the second layer (see Section 3.2); the class
Situation, which is characterized by a set of instantiated contextual
elements, was included [30]; and nally, a new relationship
between the classes Acquisition and Context Source was established. Fig. 3 depicts the Context Metamodel. The classes and
attributes are described in Table 1.
The goal of the Context Metamodel layer is to support the
construction of specic context models, since it distinguishes
the classes and relationships necessary. The analyst responsible
for building this context model should decide how to instantiate
the classes depending on the specic environment. The
context model, in turn, will be employed in each instance of
the process, enabling the relationship between the layers to be
determined.
3.2. Business Process Metamodel layer
In our formalism, we propose a layer to specically dene
concepts of context and their relationships. Thus, to express the
elements of a business model, we modied the ontology proposed
by Nunes et al. [33] depicted in Section 2, excluding the class
Context and establishing new relationships between the two
layers. Moreover, the formalism presented in this paper improves
the original ontology by making all of the relevant concepts related
to context explicit in a separate model (the rst layer) and
highlighting in the second layer a process metamodel. This
metamodel should be taken as a basis for building the process
models, which is needed to identify and monitor the context. Fig. 4
depicts the Business Process Metamodel. The main classes that
compose this metamodel and their attributes are described in
Table 2.
1197
Fig. 2. Layered Metamodel for context-aware business processes.
Depending on the elements of the business process and of the

domain, only a subset of them will be considered relevant to
actually be monitored as context. A process model element or a
domain element becomes a contextual element if their corresponding classes are extensions of the Contextual Element class.
For example, in a specic process, an artifact can be chosen as
relevant 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 in
the process layer and the Contextual Element in the context layer.
Fig. 5 illustrates examples of possible relations that occur
between a context and process: (i) a relationship between the class
Contextual Element (in Context Metamodel) and Artifact (in
Business Process Metamodel); (ii) a relationship between the
1198
Fig. 3. Context Metamodel.
classes Activity (in Business Process Metamodel) and Focus (in

Context Metamodel).
It is important to note that the Business Processes Metamodel
layer, analogous to the context layer, aims to guide the
construction of process models based on the concepts dened in
the layer.
3.3. Domain Metamodel layer

Any business is related to a specic domain. Thus, everything
that inuences a process (either internal or external variables)
should be understood as part of this domain. A Domain Model is a
high-level conceptual model that denes physical and abstract
Table 1
Context Metamodel classes and attributes.
Class
Description and attributes
Contextual Entity
Represents entities (person, place, object, user, application) to be considered for the purpose of manipulating context information. It is
characterized by at least one contextual element
Attributes: name, type, description, is_characterized
Represents a property used to characterize a contextual entity. It is the basic unit of the model, identied by a set of attributes and
relationships associated to an entity.
Attributes: name, description, value
Represents the contextual elements categorization according to the type of information that it provides. Indicates when a contextual
element is related to a set of questions on their attributes
Attributes: value
Represents ways in which contextual elements instances can be derived from heterogeneous and external sources (physical sensors,
desktops sensors, user-interface dialog, etc.).
Attributes: name, origin, type
Represents ways of capturing contextual elements. It parameterizes the relationship between a contextual element and a source context
Attributes: acquisition type, frequency of updating
Classies the contextual element according to the way it is acquired
Attributes: value
Classies the contextual element according to the way it is acquired, in terms of the updating frequency
Attributes: value
Allows for the determination of which contextual elements should be instantiated and used to compose a Situation.
Attributes: function, description, goal, is_active
Logical statement that species the execution of one or more actions when pre-dened conditions are met. Conditions are characterized
according to the value that one contextual element or a combination of contextual elements assumes. An action indicates a procedure that
should be performed when a condition is met. Actions can be, for example, triggering a system action, assigning a new value to a contextual
element or assigning a new weight to the relevance between a focus and a contextual element
Attributes: name, type, goal
Represents the level of importance of a contextual element in relation to the focus. It is characterized by a weight (Relevance_Type) that can
be low, medium or high
Attributes: description, weight
Represents the set of instantiated contextual elements featuring an adaptation
Attributes: description, outcomes, is_characterized
Contextual Element
Context_Type
Context_Source
Acquisition
Acquisition_Type
Updating_Type
Focus
Rule
Relevance
Situation
1199
Fig. 4. Business Process Metamodel.
objects in a knowledge area. It is frequently used to explain the

terms of a domain by describing the main entities, their attributes,
roles and relationships, as well as the constraints that rule the
domain. In a domain model, a class should represent a group of
objects instead of a programming object. Domain models may
improve accuracy and focus discussions among stakeholders,
business teams or technical teams.
The third layer is the Domain Metamodel. This metamodel

species the basic concepts required to build a domain
model. Therefore, we adopted a standard Domain Metamodel
from the package of classes Foundations|Core of the Unied
Modeling Language [37] because it is commonly used to
support the modeling of Class Diagrams. Fig. 6i illustrates this
metamodel.
Table 2
Business Process Metamodel classes and attributes.
Class
Activity
Set of actions aimed at reaching one or more objectives that consumes and produces information and Artifacts and requires Actors to
execute it
Attributes: name, description, action, expected goal, achieved goal
Represents professionals involved in the execution of an activity through his/her skills, personal information and the relationship between
them. They are specialized in Individual, Group and Non-human actors
Attributes: name, type
A function that is performed by one or more Actors and that is assigned to each process activity. Roles have a hierarchy among themselves
and require some Competence
Attributes: name, function
Concrete product resulting from the execution of an activity that can serve as input to other activities
Attributes: name, type, description
Information external to the organization or work process that is running
Attributes: name, description, type
Element related to computing platforms, hardware, material, and work environments that have UseRestriction; it maybe specialized in
specic subclasses such as Environment (location within the organization) or Computational System (software application), depending on
the domain. . .
Attributes: name, function, type
Concept established by the domain and the application scope
Attributes: name, description, type.
Skill required for a specic actor to perform an activity appropriately
Attributes: technological knowledge, leadership, business knowledge
Information that denes or constrains some aspect of the business. Can be directly linked to an organization as a whole or can be linked to a
specic domain. It aims to support the business structure or to inuence its behavior. It can be related to internal constraints, such as
standards, or external constraints, such as laws and regulations
Attributes: name, type
Norm or standard that is executed by Actors (according to the role associated with them at the moment) or triggered by the Activity through
some action associated with them
Attributes: name, description, outcome
Represents the communication process between Actors required to perform an Activity that occurs through some Communication Means
and also generates Artifacts
Attributes: behavior, feeling
Specialization of Interaction class that represents the debates held between Actors participating in a Process
Attributes: topic, exchanged gesture
Specialization of Interaction class that represents the contents of the messages exchanged during interactions
Attributes: contents, message type
Actor
Role
Artifact
External Data
Resource
Term
Competence
Business Rule
Procedure
Interaction
Discussion
Message
1200
Fig. 5. Example of interaction between context and process layers.
This package is the language component that species the static

structure of the models and contains the sub-packages Core,
Extension Mechanisms and Data Types. The Core subpackage
species the basic concepts, and the metamodel denes an
architectural framework that allows for the association of
additional constructors. The main concepts for our work are
described in Table 3.
Domain models created based on the Domain Metamodel aim
to represent the vocabulary and key concepts of a specic
knowledge area through the description of the entities, attributes,
roles and relationships involved, as well as restrictions that ensure
the integrity of a particular domain. Therefore, the models are
unique and should be built for each particular case.
3.4. Relationship between Context and Business Process layers
As mentioned previously, the three layers Context, Business
Process and Domain constitute an approach to context-aware
business process representation, and therefore, they are linked. In
this proposal, the relationships between layers are dened by
rules. Rules connecting Context and the Business Process
Metamodels are generic, and they dene fundamental relationships and constraints between some of their elements. Furthermore, the denition of the rules guarantees that a relationship
exists between the models built from the metamodels.
Rule 1 (Formalization of the Relationship between Contextual
Element and Situation):
Given CE as the set of contextual elements, for all contextual

elements cei 2 CE, where 1 i n and n jCEj, a domain
(Dom(cei)) is associated, indicating the possible values that the
contextual element can assume.
Given Domcei fdi1 ; di2 ; . . . ; diMi g, where M i jDomcei j, the
set E is dened as the set of all contextual elements with their
associated values:
E fce1 d11 ; . . . ; ce1 d1M1 ; ce2 d21 ; . . . ; ce2 d2M2 ; . . . ; cen
dn1 ; . . . ; cen dnMn g
A Situation is dened as a sub-set of E(S E), where a certain
contextual element only appears once.
Rule 2 (Formalization of the Relationship between Focus and
Contextual Element):
IF Focus(is_active = True)
AND Contextual Element (name = X)
THEN the Contextual Element instantiated X is associated with
Focus
Rule 3 (Formalization of the Relationship between Focus and
Activity):
IF Activity (name = A, expected goal = Z, action = L)
AND Focus (is_active = True)
THEN Focus = L.
1201
Fig. 6. Domain Metamodel

Reproduced from [37]
Rule 4 (Formalization of the Relationship between Contextual

Element and Contextual Entity)
IF Contextual Entity (is_charaterized = Active)
AND Contextual Element (name = A)
THEN the Contextual Entity is characterized by Contextual
Element A
The rst rule relates Contextual Element and Situation. Note

that a Situation is a set of values associated with Contextual
Elements. The second rule relates Contextual Element and Focus.
The Focus provides a reference for the determination of Contextual
Elements that must be instantiated to compose the Situation. Thus,
if we have the Focus active for a Contextual Element X, then we can
assume that this instantiated Contextual Element is associated
Table 3
Domain Metamodel concepts.
Class
Element
Model_element
Characteristic
Base class for all elements that compose the UML metamodel. It is the atomic constituent of the model
Represents all business elements that are specied with the UML
Represents a possible classication of the Model_element. Denes a way to represent a particular domain element. It is a generalization of
structural and behavioral features
Represents a possible classication of the Model_element. Denes a way to represent a particular domain element. Semantic condition or
restriction expressed in text
Denes values that represent the state of an instance of a Classier
Behavioral aspect of a Classier
Behavioral aspect of a Classier
Sets the visibility of an element model contained in a Namespace
Restriction
Attribute
Operation
Method
Element_property
1202
with the Focus. The third rule relates Focus and Activity. An
Activity 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 and
action L and the Focus is active, then we can infer that the focus is
equal to L. The fourth rule relates Contextual Entity and Contextual
Element. A Contextual Entity represents entities to be considered
for the purpose of manipulating context information and is
characterized by at least one Contextual Element. Therefore, if we
have a Contextual Entity characterized and a Contextual Element
occurrence A, then the Contextual Entity is characterized by the
Contextual Element A. For example, Contextual Entity = Airport
Lane X and a possible Contextual Element = Lane (information
about the lane). Thus, the Contextual Entity and Contextual
Element are related, and this relationship depends on the Focus, as
specied in Rule 2.
3.5. Applying the proposal to build a model
Process models are designed in accordance with the classes
presented in the process layer, as well as the application of the
concepts dened in the domain layer. Thus, for the same domain
model, there may be several processes, and consequently a number
of process models, within an organization. The Situation and
Activity classes that appear in the domain model are references
from other layers. Each domain class could potentially be identied
as a contextual element. Therefore, the relationships between
these concepts must be established. For example, the concept
Billing Address (which could be a class or Model Element of the
domain used as an example in Section 1) could be a specialization
of Contextual Element (in Context Metamodel) for the case of a
specic Process (Sell Items) in which an Activity (Payable Invoice) is
performed.
Our approach aims to make the manipulation of context more
exible because each layer can express the existence of relationships between concepts included in the model. Thus, some
concepts dened in a layer will be related to other concepts in
other layers. The complete model should be built according to the
following steps:
(i) Dene the domain of a given application and model it (third
layer)
(ii) Model the target process (second layer);
(iii) Establish the relationships between the domain and process
models by identifying the elements of the process that
correspond to the elements that make up the domain;
(iv) Identify in those two models which elements to consider as
contextual elements and establish an explicit relationship among
them and the corresponding concepts in the rst layer;
(v) Characterize Situations. The contextual elements should be
analyzed because the values they can assume in the instances
of business process might dene the situation. Therefore,
when a situation occurs, a decision regarding the course of the
process should be taken. Thus, inference rules should be
created.
For the steps (iv) and (v), we propose to apply the proposals
described in [1,43,14]. Anastassiu and Santoro [1] propose a
method for identifying business processes contextual elements
internal to the organization. This method analyzes the process
model searching initially for the essential activities and then
eliciting which of their attributes are able to produce inuences in
the results of the process. Complementary to this rst approach,
Ramos et al. [43] describe a proposal to discover external contextual
elements, based on algorithms that perform automatic analysis of
relationships among a number of environment variables and the
logs of execution of the process in focus.
Moreover, the development of the relationships among the

elements (i.e., the rules) could be made through interviews with
experts in the domain (such as building expert systems), or yet, by
analyzing the execution logs of the process to infer possible
relations among them. Carvalho et al. [14] describes an implementation of the Apriori algorithm (that discovers association
rules), which scans the data set (log) looking for subsets that
present frequent relationships [42].
Anyway, we highlight that the method and procedures for the
elicitation of contextual elements, as well the denition of
relationships 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, the
monitoring of contextual elements of the process makes it possible
to identify the Situation of an Activity, which in turn, may signal
the need for adaptation. The metamodel has already been used in
the Context Management Architecture for Dynamic Process
Adaptation (see details in [35,36]). In this system, a Mediator,
the component responsible for adaptation, identies adaptation
needs when a Situation occurs. Its key features are intelligent
behavior and decision-making support. During a process instance
execution, this component should reason over: (i) the possible
adaptations, (ii) in which parts of the process the adaptations
should be applied, and (iii) the impact on process and organizational goals. So, the Mediator reasons over the situation that will
not lead the process instance to a stable state (i.e., achieve its goal)
or that will not likely lead the process instance into its best
performance, in order to decide what adaptations to be taken.
The next section presents a case study performed under real
conditions to evaluate the proposal. All of the steps followed to
build the models are described, and the validity of the models
based on assessments by specialists is discussed.
4. Evaluation: a case study and analysis
In this paper, we address the problem of providing formal models
that associate process with the context. In this sense, we should
investigate the applicability of the proposal. So, our research
question is How to build a formal representation that is able to link
a process with its contextual elements? In order to discuss this
question, the model-building approach proposed herein was
evaluated through a case study [56], which is an approach aimed
to investigate a phenomenon within its real context, where there is
little control over events. According to [56], an exploratory case
study could be used to explore those situations in which the
intervention being evaluated has no clear, single set of outcomes.
The situation considered is a real scenario that is extremely
complex, critical and relevant: Airspace Control. In this environment, there is no possibility of conducting experiments without a
comprehensive study, tested to exhaustion, so as not to compromise the integrity of the systems involved and ight safety. The
case study was carried out in several steps, which are detailed in
the following sections:
(i) Understanding the scenario: The main concepts related to air
trafc control and the operation of an aerodrome control
tower were elicited.
(ii) Creating the domain model: The model was built based on the
well-established 5M Model (see [52]), which features ve
potential factors that could affect the implementation of the
process.
(iii) Modeling the process: The process to be used in the case study
was selected and modeled. The process chosen was the takeoff
of aircraft.
(iv) Consolidation of the approach: The relationships between the
layers were dened.
1203
Table 4
5M Model factors.
5M
Factor
Man
Media
Human elements, such as psychological, physiological aspects of prociency and experience in performing tasks
The environment where the task is performed, including weather conditions, runway conditions, obstructions, airspace illumination and
navigational aids available
Manufacturing and maintenance of aircraft and reliability and performance of equipment
The ability to manage situations in terms of regulations, policies and attitudes toward safety
The type of work performed, whether it is complex or routine
Machine
Management
Mission
(v) Denition of the data set: Data were extracted from the Daily
Situation Report delivered by the Center for Management of
Air Navigation (CGNA). This report relates instances of air
trafc under various scenarios. We selected data related to the
occurrence of elements dened in the domain model because
they were considered the factors relevant to the execution of
the process.
(vi) Creating an activity log: Data obtained in the previous step
were disposed in a log table format. The log identied which
of the monitored activities happened in the occurrence report.
Each occurrence was understood as a process instance.
(vii) Conducting Interviews: Rules dening situations based on the
combination 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 Trafc Control (ATC) scenario was chosen due to
its remarkable relevance, as well as its highly dynamic nature, and
because it presents a number of factors that could possibly
interfere with the process execution. ATC is a service provided by
controllers on the ground to guide and monitor aircraft in the air
and on the ground to ensure a safe and organized trafc ow. Air
trafc controllers provide indications and authorizations to y in
accordance with the operating characteristics of aircraft and trafc
conditions at any given time. Controllers may provide guidance
regarding the route, altitude and/or speed proposed by the aircraft
operator for a particular ight; pilots must comply with the
instructions and authorizations received.
In many countries, ATC services are provided throughout the
length of an airspace, and these services are used by private,
military and commercial aircraft companies. The airspaces where
the controller sends authorizations are called controlled airspaces,
as opposed to uncontrolled airspaces, where aircraft pilots are
responsible for their own safety and navigation. Depending on the

type of ight and the class of airspace, the air trafc controller
provides instructions that pilots must follow or merely assist pilots
operating in a certain airspace. In addition to being dedicated to
passenger 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 the
modeling process, the following were identied as the main
elements of the domain: request for takeoff, authorization for
takeoff, regulation, mission type, weather conditions, runway,
pilot, air trafc controller and aircraft. Additionally, we adopted
the approach used by the U.S. Air Force for operational risk
management [52], which analyzes hazard factors associated with
aviation: the 5M Model. A hazard is dened as any real or potential
condition that can cause degradation, injury, illness, death, damage
or loss of equipment or property [52]. For example, a controller
may answer the phone while he or she is setting the parameters
and negligently report an incorrect parameter to a pilot. This is an
example of a human danger that can affect this process. Therefore,
such risk factors should be monitored to allow for changes in the
process if necessary. The 5M Model denes ve factors that
characterize the existence of a hazard (Table 4).
The construction of the domain model requires the instantiation of the Domain Metamodel. Thus, from the Domain Metamodel
in Fig. 6, the Domain Model composed with Classes (Model
Elements) and its Structural Features (Attributes) was built. This
model is illustrated in Fig. 7, and a brief description of each class
and attributes is provided in Table 5.
Moreover, we selected the Aircraft Takeoff process in this case
study because of its importance to aviation, with thousands of
instances being performed daily. The model developed is based on
the Business Process Metamodel. Both the domain and process
Fig. 7. ATC domain model.
1204
Table 5
Domain Model (classes and attributes with their set of possible values).
Take_off
Take_off_Request
Take_off_Permission
Hazard
Man
Machine
Media
Mission
Management
Pilot
Air_Trafc_Controller
Position_Ground_Control
Position_Flight_DataClearance_Delivery
Position_Tower
AIS_Operator
Ground_Worker
Aircraft
Aerodrome_Equipment
Meteorological_Condition
Air_Space
Flow_Management
Runaway
Mission_Type
Regulation
Represents the action of an airplane taking off

Represents the document that is issued to request authorization to perform the activity
Represents the document that is issued to authorize the execution of the Activity
Represents a real or potential condition that can cause degradation, injury, illness, death, damage or loss of equipment or property
Refers to human elements, such as psychological, physiological, prociency and experience in carrying out activities. Specialization
of the class Hazard
Refers to aspects of manufacturing and maintenance of aircraft and equipment performance and reliability. Specialization of
the class Hazard
Refers to the environment where the activity is performed, including weather conditions, runway conditions, obstructions,
airspace and ow management. Specialization of the class Hazard
Refers to the type of work performed, whether complex or routine. Specialization of the class Hazard
Refers to management capacity in terms of regulations, policies and attitudes toward safety. Specialization of the class Hazard
Refers to the person who will y the aircraft. Specialization of the class Man
Refers to the person who will monitor the implementation of the activity. Specialization of the class Man
Refers to the person who will monitor the implementation of the activity on the ground position. Specialization of the
class Air Trafc Controller
Refers to the person who will monitor the implementation of Activity in the Position of Trafc Authorization. Specialization of the
Refers to the person who will monitor the implementation of Activity in the Position of Tower Specialization of the
Refers to the person responsible for activities performed in AIS. Specialization of the class Man
Refers to the person responsible for support activities performed on the ground, i.e., at the aerodrome. Specialization of the class Man
Represents the equipment used by the pilot to perform the Activity. Specialization of the class Machine
Represents the technical equipment installed at the Aerodrome to enable the implementation of the Activity. Specialization
of the class Machine
Represents weather conditions at the aerodrome and surrounding area. Specialization of the class Media
Represents the conditions of the airspace near the aerodrome. Specialization of the class Media
Represents the set of actions performed to manage the ow of aircraft between Aerodromes. Specialization of the class Media
Represents the area of an aerodrome intended for aircraft takeoff and landing
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
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 trafc
controllers, who are the heads of the airport control tower at
Galeao Airport in Rio de Janeiro, Brazil, each with over 30 years of
experience, and an airline pilot with 29 years of experience and
more than 2500 ight hours. Furthermore, the process applies to
aerodromes that have a control tower, which constitutes a
signicant portion of ights conducted in Brazilian airspace. The
ow of activities in the Aircraft Takeoff process is depicted in Fig. 8.
The ow 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 this
paper is not the one of BPMN, we adopted this notation since we it
would be important to have a visual presentation of the process
model. Nevertheless, we argue this decision does not impact
the results because the Task in BPMN is similar to Activity in
our metamodel, and this was the main element used in the
representation built.
After modeling the process, it was necessary to identify which
of these activities are important to monitor in accordance with the
objective of this study. Thus, the experts also indicated the
activities that contain elements that characterize certain situations
and therefore might potentially require adaptations. The selected
activities are highlighted in Fig. 8.
4.3. Model consolidation
In this step, the domain model was attached to the third layer of
the structure. The complete model is consolidated only when the
relationships between the elements of the each model are
established. There, the goal was to link classes that represent
contextual elements with the corresponding classes in the domain
and in the process model. Moreover, each activity that has to be
monitored 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 each
layer. In the particular scenario shown in the gure, the focus
activity is Takeoff and the contextual elements are the hazards.
Thus, the element Hazard in the domain model is linked to External
Data in the process model (because it is modeled like this in the
process model); External Data is linked to Contextual Element; and
the Activity Takeoff is the Focus. It is important to note that this
diagram should be constructed for all activities to be monitored.
Thus, at any time that one activity is the Focus; the corresponding
contextual elements (which are domain elements considered in
the business process) will be analyzed.
4.4. Data set denition
A sample of real data regarding instances of the Aircraft Takeoff
Process was used to help dene the corresponding situations,
which constitutes the most important component of our model
and highlights what context is about. Data were extracted from
daily reports released by the Center for Management of Air
Navigation (CGNA). The CGNA centralizes information regarding
the operational components of the infrastructure needed to
manage the use of airspace in Brazil. By managing this information,
the CGNA is able to monitor the status of the SISCEAB (Brazilian
Airspace Control System) to eliminate or reduce uncertainty in
decision making and planning in the short, medium and long term.
It is also responsible, in conjunction with the Brazilian Airport
Infrastructure Company (Infraero), for the analysis of intentions to
y in Brazilian airspace.
The daily report, which aims to support the evaluation of the
quality of services provided, generates indicators for aeronautical
infrastructure planning and presents wide-ranging information,
including rates of ight delays, weather conditions at airports,
1205
Fig. 8. Aircraft takeoff process model.
adverse weather conditions, airport infrastructure (inoperativeness of technical equipment, problems on runways), ow
management measures and other occurrences. These reports
provide a rich amount of information to be handled, which allowed
us to explore the elements of context and dene situations. We

analyzed the reports corresponding to a period of six months, from
June to December 2011. Over this period, 1320 occurrences related
to contextual elements were identied. These occurrences were
1206
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, as

explained in the next section.
4.5. Assembly of the log
The log represents the set of values assumed by each of the
contextual elements dened in the domain model for the
occurrence of each of the activities chosen (highlighted in
Fig. 8). Each occurrence obtained from the reports is a process
instance. In other words, for each instance, the behavior of the
contextual elements was observed to identify deviations in the
process that possibly characterize a Situation. The contextual
elements considered in the log were Regulation, Mission Type,
Weather Condition, Runway, Pilot, Air Trafc Controller and

Aircraft. Although important contextual elements for the process,
neither Takeoff Authorization nor Takeoff Request were included
in the log because the daily reports from which the data were
extracted do not include this type of information. It should be noted
that only the occurrences that had some impact on the process
were handled. The log consists of the elds and possible values, as
listed in Table 6. The values were mapped manually because they
were identied 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 this
example, the occurrence is a restriction in takeoffs to SBSP due to a
partial break made by the access ramp personnel of a company
1207
Table 6
Log structure.
Column
Description/values
Description
Process code
Instance code
Activity code
Id
Activity
Report date
Cause
Transcription of the occurrence reported in the daily situation report

Code of the monitored process
Code of the monitored instance
Code of the monitored activity. Values: A, C, E, F, G, J, M, N, O, Q, R
Identier of the record
Description of the monitored activity
Date of the report from which the information was extracted
Description of the occurrence source. Values: balancing ow, 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
Description of the effect of occurrence on the process. Values: no impact, delay, ight cancelation, unauthorized takeoff,
suspended takeoff, runway shift
Description of the conditions of the air trafc controller during the execution of the activity. Contextual Element related to Man.
Values: standard performance, discontinued operation
Description of the conditions of the pilot during the execution of the activity
Contextual Element related to Man. Values: standard performance, discontinued operation
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 in the process for one of the Man CE. Values: true, false
Description of the type of mission that was being performed during the activity instance. Contextual Element related to Mission.
Values: conventional, priority
Interference in the process for one of the Mission CE. Values: true, false
Description of the conditions of the aircraft during the activity instance. Contextual Element related to Machine.
Values: operational, non-operational
Description of the conditions of the aerodrome equipment during the activity instance. Contextual Element related to Machine.
Values: operational, non-operational, partially operational.
Interference in the process for one of the Machine CE. Values: true, false
Description of the meteorological conditions during the activity instance. Contextual Element related to Media. Values: favorable,
unfavorable, impeditive
Description of the runway conditions during the activity instance. Contextual Element related to Media. Values: operational,
non-operational
Description of the air space conditions during the activity instance. Contextual Element related to Media. Values: operational,
non-operational, operational with restrictions
Interference in the process for one of the Media CE. Values: true, false
Description of the ow management conditions during the activity instance. Contextual Element related to Management.
Values: inactive, active
Description of the regulation during the activity instance. Contextual Element related to Management. Values: accordance,
non-accordance
Interference in the process for one of the Management CE. Values: true, false
Impact in process
Air trafc controller
Pilot
Ground worker
Interference of the man
Mission type
Interference of the mission
Aircraft
Aerodrome equipment
Interference of the machine
Meteorological condition
Runway
Air space
Interference of the media
Flow management
Regulation
Interference of the
management
called TAM. This process is code 1, instance 7, reported at 22/11/

201. The reason for the occurrence was attributed to a strike; the
impact was a delay in process. In this instance, the contextual
elements were monitored for all of the activities previously
indicated. We observed that all of the contextual elements behaved
as expected, with normal operation, except for the Ground Worker,
for which the value assumed was Interrupted Performance. This
indicated that the contextual element Man provoked an
interference in the process.
Situation Taking off Extremely Probable 1 (TEP1)

TEP1 = {Aerodrome_Equipment = Operational, Pilot = Standard Performance}
Situation Taking off Extremely Probable 2 (TEP2)
TEP2 = {Flow_Management = Inactive,
Priority}
Mission_Type =
Situation Taking off Probable 1 (TP1)

4.6. Denition of the situations
TP1 = {Runway = Operational, Flow_Management = Active}
Once the log was organized, it was used to nish building the
model. In view of the relationship between the elements of the
three models, it was possible to dene which domain model
elements represent contextual elements. After detailing the
contextual elements along with their values, we could describe
the 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 contextual
elements, which constitutes a certain behavior signaling the
possible adaptation needs of a process. These situations were
created manually based on the log. They were characterized
according to the probability of the aircraft takeoff activity: Taking
off extremely probable (TEP); Taking off probable (TP); Taking off
improbable (TI); Taking off extremely improbable (TEI). The
following rules were dened based on the data:
Situation Taking off Probable 2 (TP2)

TP2 = {Aerodrome_Equipment = Non Operational, Air_Trafc_
Controller = Standard Performance}
Situation Taking off Improbable 1 (TI1)
TI1 = {Air_Space = Operational with Restrictions, Meteorological_Condition = Unfavorable}
Situation Taking off Improbable 2 (TI2)
TI2 = {Air_Trafc_Controller = Discontinued Operation, Mission_Type = Priority}
Fig. 10. Extract of the Log of one process instance.
1208
1209
Table 7
Comparison of Contextual Elements.
Hazard
Contextual Element
Interviewee 1
Interviewee 2
Interviewee 3
Man

Pilot
Ground Worker
Meteorological condition

Pilot
Ceiling, Wind, Visibility

(Contextual Element
Meteorological Condition)
Runway

Pilot
Rain, Wind, Ceiling, Visibility

(Contextual Element Meteorological
Condition)
Runway, Taxi runway (Contextual

Element Runway)
Radio Communication between the

pilot and controller(Contextual Element
Aerodrome Equipment)

Pilot
Rain, Rail, Wind, Ceiling, Visibility

(Contextual Element Meteorological
Condition)
Runway, Taxi runway (Contextual

Element Runway)
Airspace
Electronic and System (Contextual

Element Aerodrome Equipment)
NOTAM for the airport (Contextual

Element Management)
Media
Flow management
Runway
Machine
Airspace
Aircraft
Aerodrome equipment
Mission
Management
Mission type
Regulation
Airspace Control Equipment,

Telecommunications Equipment
(Contextual Element Aerodrome
Equipment)
Situation Taking off Extremely Improbable 1 (TEI 1)

TEI1 = {Pilot = Discontinued Operation, Air_Space =Operational}
Situation Taking off Extremely Improbable 2 (TEI 2)
TEI 2 = {Air Space = Non Operational, Aircraft = Operational}
It is important to note that this set of situations is not
exhaustive. Indeed, there may be other combinations of elements
that characterize situations. These situations were analyzed by
experts 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 trafc
controllers. The interviews were conducted individually, following
a structured script. First, a brief description of the research focus
and the objectives of the study and the interview were discussed.
Then, we asked the respondents about their knowledge of the
process. We then introduced the process model to the interviewees.
Finally, we presented the list of the types of situations and the
conditional clauses of the rules to be assessed. The interviewees
were asked to associate each of the conditional clauses of the rules
with one of the situations, depending on which best applied, and to
comment on each of their choices. The respondents could also
answer 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 rst respondent serves as a pilot approximately twice a
week, has 28 years of experience and 2400 h of ight time. When
asked about which elements he considers relevant to be monitored
for this process, he listed the Pilot, Air Trafc Controller, Runway,
Airspace Control Equipment, Telecommunications Equipment,
Ceiling, Wind and Visibility. He suggested that the contextual
elements should be more ne-grained because they are too
generic, which can lead to inaccuracies in the rules. He cited the
Aerodrome as an example, for which, depending on what
equipment is used and what is involved in aircraft takeoff, there
may be a variation in the response.
4.7.2. Interviewee 2 air trafc controller B

The second respondent, air trafc controller B, has 34 years of
experience. He served as an air trafc controller for 30 years, as
an air trafc controller in a tower for 12 years and has been a
tower supervisor for 5 years. When asked about which elements
he considered relevant to be monitored for this process,
the respondent indicated the Pilot, Air Trafc Controller,
Runway, Taxiway, Radio Communication between the pilot
and controller, the existence of the NOTAM3 for the airport, Rain,
Wind, Ceiling and Visibility. The respondent did not comment
further.
4.7.3. Interviewee 3 air trafc controller C
The third respondent, air trafc controller C, has 32 years of
experience. He served as an air trafc controller for 25 years, as an
air trafc controller in a tower for 6 years and has been a tower
supervisor for 7 years. When asked about which elements he
considered relevant to be monitored for this process, the
respondent mentioned the Pilot, Air Trafc Controller, Runway,
Taxiway, Electronic Equipment, Systems, Condition of airspace,
Rain, Hail, Wind, Ceiling and Visibility. The respondent made the
following additional comments:
The elements should be less generic because the values that a
rule takes can vary greatly. For example, the decisions made will
be different if the weather conditions involve ne rain or snow.
There should be a mechanism to weight each element because
their relevance could be very different; each element has a
different weight. They do not have the same relevance when
creating a rule.
The data collected from the interviews were analyzed from two
perspectives: the relevance of contextual elements indicated
within the model and the validation of the rules created
(Situations). For the rst investigation, it was necessary to make
a comparison between the contextual elements mapped by the
researchers and the elements considered signicant to the
respondents. Table 7 summarizes these results. A general analysis
reveals that the contextual elements Air Trafc Controller, Pilot
and Runway were listed by all respondents, and contextual
element Airspace was identied by one of them.
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 ight operations.
1210
It should be noted that all respondents identied other

components of the domain as contextual elements. The respondents are domain experts, so, when asked about their perception of
contextual elements they identied items of the domain in a very
small granularity level than we expected at rst. Within the
domain model built, those items are attributes of some classes, or
even possible specializations of those classes, and not the class
itself. So, we concluded that the attributes of both classes and subclasses can also be considered contextual elements. Therefore, we
have the following scenario:
The rst interviewee identied the elements Meteorological
Condition (through its attributes Ceiling, Wind and Visibility)
and Aerodrome Equipment (through its sub-classes Airspace
Control Equipment, Telecommunications Equipment).
The second interviewee identied the Meteorological Condition
(through its attributes Rain, Wind, Ceiling and Visibility), the
Aerodrome Equipment (through its attribute Radio Communication between the pilot and controller) and Regulation (through
its attribute NOTAM).
The third interviewee identied the Meteorological Condition
(through its attributes Rain, Hail, Wind, Ceiling and Visibility)
and Aerodrome Equipment (through its sub-classes Electronic
and System Electronic and System).
The results suggest the validity of the contextual elements
associated with the domain model because most of the contextual
elements were also recognized by experts. On the other hand, the
contextual elements Ground Worker, Flow Management, Aircraft
and Mission Type were not reported by any of the respondents.
This suggests that these contextual factors, while important for the
domain composition because, by mapping the data, we observed
occurrences related to them were not remembered or do not
have a signicant impact in the opinion of the respondents.
The second analysis assessed whether there is evidence that
might validate the proposition that it is possible to characterize the
situations (context) of business process activities, which would
complete the model proposed in this paper. Table 8 presents a table
comparing the rules dened by the researchers and the references
assigned to the same rules for each of the three experts.
For the rst rule, all respondents agreed with the predicted
value for the situation, which suggests that it is a valid rule. This
result may be due to the fact that all of the contextual elements
take the default values, i.e., values that do not represent bad
performance for the process.
For the second rule, again there was consensus among the
respondents, suggesting that the combination of these elements
characterize a situation. In this case, the inactivity of ow
management indicates that the ow to and from an aerodrome
is normal. The fact that the second element is a mission type set as
a priority further indicates that the takeoff is extremely probable

because that takeoff has precedence over others.
For the third rule, all participants understood the situation as
probable takeoff. In this case, although we have an operational
runway, ow management is currently active to regulate the trafc
in the area. According to the expert analysis, the takeoff is probable
because trafc will cease immediately, i.e., the trafc will be
resized or relocated. An example of this scenario is when there are
many aircraft waiting to take off or land because an airport is
closed due to bad weather.
For the fourth rule, none of the participants agreed with the predened reference, which was Takeoff Probable. Two of the three
respondents agreed with each other, and the value attributed to
the rule was Takeoff Extremely Probable; the other responded
afrmed that nothing can be concluded about this case. The
respondents who agreed with each other were the air trafc
controllers, which may indicate that personal experiences can lead
to different interpretations. Both of air trafc controllers disagreed
with the proposed value for the rule. The respondents indicated
that equipment not operating at the aerodrome cannot cause a
disturbance in the takeoff process because the drivers are trained
to operate in a conventional manner when there is failure in some
equipment. The pilot, who said nothing could be concluded,
claimed that those two elements alone were not enough to
determine whether there are any deviations in the process.
According to the pilot, the type of hardware used has an effect in
this scenario, as well as other factors such as weather conditions. It
is possible that other elements of context should be considered in
dening this situation.
For the fth rule, two respondents agreed partially with the
reference value; they argued that the takeoff would be extremely
improbable due to bad weather conditions. The fact that the two
respondents considered the takeoff to be extremely improbable,
whereas the rule only stated that it was improbable, highlights the
need for a renement of the rules. The other interviewee justied
his answer in the same way, adding that it is necessary to know the
type 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, claiming
that priority missions in general are very dependent on the
performance of the controllers, which in this rule assumes the
value Discontinued Operation. The other two respondents
agreed with each other that nothing can be concluded. The
results suggest that these two elements alone are not enough to
say assess the takeoff. The condition of the Runway, for example,
could be a contributing element to this rule. Again, it is clear that in
the majority of cases, the respondents answers somewhat align
with the model results. This agreement is an important indication
that these types of rules are able to characterize situations in
business processes.
Table 8
Comparison of the rules (situation).
Rule
Element 1
Element 2
Inferred situation
Interviewee 1
Interviewee 2
Interviewee 3
Aerodrome Equipment =
Operational
Flow Management = Inactive
Runway = Operational
Aerodrome Equipment =
Non-Operational
Airspace = Operational
with Restrictions
Air Trafc Controller =
Discontinued Operation
Pilot = Discontinued Operation
Airspace = Non-Operational
Pilot = Standard Performance
TEP
TEP
TEP
TEP
Mission Type = Priority

Flow Management = Active
Air Trafc Controller = Standard
Performance
Meteorological Condition =
Unfavorable
Mission Type = Priority
TEP
TP
TP
TEP
TP
Nothing can be
concluded
Nothing can be
concluded
Nothing can be
concluded
TEP
TEP
TEP
TP
TEP
TEP
TP
TEP
TEP
TEP
Nothing can be
concluded
TEP
TEP
TEP
2
3
4
5
6
7
8
Airspace = Operational
Aircraft = Operational
TI
TI
TEP
TEP
TEP
TEP
For the seventh rule, all respondents agreed with the reference
value. According to the respondents, the pilots 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 to
take over. Both are unlikely.
Finally, for the eighth rule, all respondents again agreed with
the same reference value for the rule. They were unanimous in
afrming that the fact that the airspace assumes the value Nonoperational carries great weight in determining whether an
aircraft can takeoff. The fact that the aircraft is operational
becomes irrelevant.
These results led to the conclusion that it is possible to identify
the context of a process by rules that characterize situations.
However, it is necessary to evaluate the relevance of each
contextual element for a given context.
4.8. Case study discussion
Through a comprehensive analysis, it is possible to observe that
in ve of the eight situations all respondents agreed with the
denition of the situations. For all rules, two or more responses
coincide with each other. Thus, there is evidence that the model is
valid because experts have a very similar understanding about the
impacts of the relationship between contextual elements in a
process. Through this case study, we were able to identify
important aspects of the proposed approach:
Extreme situations yielded greater agreement among respondents 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 be
dened.
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 a
component of a situation, and the need to create mechanisms to
better delineate the boundaries between situations. The class
Relevance is already part of the context metamodel, but it was not
instantiated in this case study.
Although the rules elicited and evaluated with the collaboration
of the experts were related to the domain, it is important to
emphasize that the characterization of situations presented in this
case study made it possible to evaluate the approach as a whole. As
expected in our proposal, the classes within the three layers
(context, process and domain) were connected, and the relationships among those classes in the three layers were explained by
rules. The rules that dene the relationships within the domain
model are more specic, but they refer to elements in all layers.
This case study had some limitations, rst with respect to the
participants 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 de
Janeiro; moreover, the two air trafc controllers work in the same
organization. Although the respondents are very experienced
professionals, this very fact might have inuenced their stances
due to their current perspective of the facts.
The data log was assembled manually through a careful analysis
of the reported occurrences; therefore, the situations were
identied manually. If there was a digital log that could be mined,
perhaps other situations could be identied more precisely using
an automated method.
The next section discusses related research studies and
demonstrates our contribution and improvement to the study
areas of business processes and context.
1211
5. Related work
Saidani and Nurcan [46] presented an approach for modeling
business processes that supports the description of a context in
action. To the authors, the ability to integrate Context Related
Knowledge (CRK) enables BPMs to become exible, active and
capable of expressing a variety of business rules. This approach is
based on four steps: elicitation, categorization, adaptation and
measurement of context and business process instantiation.
Moreover, the authors also present a taxonomy of context that
captures the most common CRK: location, time, human resources
and organization. Unlike our proposal, this model considers a few
xed elements as context and does not provide exibility to model
different domains.
Han and Park [24] proposed a framework for a knowledge
model centered on business processes and ontology to store the
contextual knowledge needed to perform a task. The work aimed
to identify and categorize the type of knowledge being generated
and accumulated. There are two types of knowledge: process
knowledge and task support knowledge. The business ontology
represents the concepts of large companies and their relationships.
All domain concepts are related to the concept process. The goal of
this proposal is to support users in the execution of process tasks; it
does not encompass all the details necessary to model context as
our context metamodel intends to.
Rosemann et al. [45] proposed a framework for better
understanding the different types of context and their impact
on business processes. The so-called Onion framework distinguishes four types of context: immediate (e.g., organizational
resources responsible for the execution of the activities), internal
(e.g., resources, rules, values, concepts, interests, strategies,
structure and culture), external (e.g., vendors, investors, competitors and customers) and environmental (e.g., society, nature,
technology and economics). The authors presented an approach to
goal-oriented process modeling in which context can be conceptualized, classied and integrated. The proposal also included a
metamodel for classifying context and a basic procedure detailing
how to apply the framework. Although, this metamodel helps to
represent context for process, it does not relates to the concepts of
the business domain as in our proposal.
Soffer et al. [49] presented an automated approach for learning
from experience to improve business processes over time. In this
approach, three aspects of business processes are combined: real
paths, context and goals. Based on this framework, a learning cycle
was proposed, including a phase where the relevant context is
identied and used to make improvements in the BPM. Moreover,
the approach features an application phase at runtime, wherein the
improved BPM is applied at runtime and actual results are stored
for the next learning cycle.
From this literature review, we concluded that proposals
addressing context in business processes have one of the following
characteristics: (i) they are focused on context-aware applications,
(ii) restricted to the analysis of user information, environment and
devices or (iii) apply only to a specic domain or process.
Furthermore, the proposals do not include a formal description of
the concept of context related to business processes, which
prevents the instantiation in any domain and/or organization
process and the identication of the context of an activity by the
association of contextual elements.
Although not focused on integrating the concepts of context
and business process, three studies present basic concepts that are
quite similar to those specied in our proposal. Feng et al. [20] also
distinguish context and situation. Context involves the elements in
an environment dened in time and space, the comprehension of
their meaning and the projection of their status in the near future,
and situation is related to the collection of immediate people and
1212
Table 9
Related 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
Supports users in the execution of process tasks, based on very
generalist concepts of context: process knowledge and task
support knowledge
Provides a framework that distinguishes four types of context:
immediate, internal, external and environmental
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
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
Uses the concept of Situation to aggregate and model specic
conditions and constraints that need to be recognized to signal the
need to execute certain actions
Applies the concept of current situation to allow handheld devices
providing information and offer services to users over mobile
networks
Uses the concept of context to address the problem of achieving
more comprehensible models in process mining
Provides exibility to model different domains and types of

contextual elements
Encompasses the details necessary to model context related to a
domain
[24]
[45]
[49]
[20]
[6]
[16]
[29]/[2]
objects, as well as changes to those objects over time. As stated by

the authors, situation awareness focuses on the modeling of a
users environment, whereas context awareness is about exploiting the context of a user and supporting the user to have a more
effective interaction with a system by adapting the systems
behavior according to the users current context or situation. The
Situation Model proposed is composed of associated entities and
events. Although the concepts used are similar to those developed
in our proposal, they focus on physical entities and their attributes,
such as location, and our model involves the modeling of any
domain.
Situation is dened by Bettini et al. [6] as a semantic abstraction
of low-level data. The authors used this concept to aggregate and
model specic conditions and constraints that need to be
recognized to signal the need to execute certain actions. Cimino
et al. [16] also address the topic of situation awareness, stating that
the understanding of a current situation can allow handheld
devices to provide information and offer services to users over
mobile networks. The authors propose a framework based on
general rule-based approach to manage situation awareness. In
their proposal, an extension of the ECA (Event Condition Action)
architectural pattern, referred to as ECAA (Event Control Action
Adaptation), provides a high-level structure that facilitates the
design of situation-aware applications, solving problems associated with the management of situational information upon changes
in users context. Thus, the modeling of Situation is quite similar to
that adopted in our proposal; however, the authors concentrated
on users conditions, while in our case, the business process is the
focus.
According to van der Aalst et al. [2], process mining techniques
aims to discover, monitor and improve real processes by extracting
knowledge from event logs available in information systems. A few
works relate process mining to context awareness, such as [9,29].
However, those works use the concept of context to address the
problem of achieving more comprehensible models. They argue
that context-dependent patterns could be used to obtain event logs
at a higher abstraction level. In our proposal, we are not dealing
with process discovering; instead, the intention to support
dynamic process adaptation based on context. So, this is not the
case of discovering or even improving, but to model relevant
contextual variables, that when monitored could support an
instance to be adapted. That is why representing context is
Allows any type of context to be linked to the business domain

concepts
Includes a formal description of the concept of context related to
business processes
Provides exibility to model different types of contextual
elements, not limited to the traditional physical entities
Guarantees the application of the concept of Situation in business
processes
Focuses on business processes in general, rather than users
conditions requiring actions
Provides a basis to dynamic process adaptation based on context
important. Our work aims to provide a basis for this, by proposing a

metamodel that integrates context to process.
Table 9 highlights the main achievements of each work in
literature related to the discussion of this paper, and presents the
differences and advantages between them and our proposal.
6. Conclusions
The success of an organization increasingly depends on its
ability to be exible and react quickly to changes. Thus, business
processes must be able to adapt to such changes, the so-called
context. Although there are some models proposed in the literature
that address the context associated with business processes, there
is still no model for representing context in business processes. In
this paper, we proposed an approach to represent the context of an
activity of a business process in a given domain. This approach was
developed through conceptual metamodels structured in layers
that incorporate aspects related to context. The metamodels were
evaluated by a case study involving a complex, critical and relevant
real scenario: Airspace Control. The results of this assessment
provided evidence of the feasibility of the formalization proposed.
There is an initial and relatively high cost to build the models and
establish the necessary relationships, because the domain and its
environment should be analyzed. However, when it is done, the
execution of all instances of the process could be made based
on that model, and we argue that this would make adaptations
easier to be applied. Besides, the domain model and the context
could be at least partially reused for other processes in the same
organization, since dealing with the same business.
The motivation of this proposal is the focus on the use of context
to adapt business processes. Most context models found in the
literature are limited to the analysis of user information, devices
and environment. Thus, our main contribution is an approach that
is more comprehensive and exible and that can be applied in any
domain and process of an organization.
Another advantage over existing models is the formal description of the Situation of an activity, which highlights the notion that
context is a complex concept that should be dened through a
combination of independent contextual elements that act together. The conceptual metamodel can support the adaptation process
because it not only considers current circumstances but also
captures how these conditions affect the process.
An important point to emphasize is that the focus of the

evaluation performed in this study was the concept of situation
and 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 Context
Model was created based on the concepts of the Context
Metamodel, which includes the elements Situation and Contextual
Element. Subsequently, its instances were also created, which
consequently led to the incorporation of other elements of the
metamodel, for example, Activity, Role and Actor.
For the Business Process Metamodel, we decided to use at rst
our own metamodel, instead of trying the most obvious BPMN, EPC
or UML (Activity Diagram) metamodels, mainly due to the
possibility of representing some attributes of an activity that
could be typically considered context. However, it does not mean
we suggest abandoning the established metamodels. We should
study the costs of extending each of them and compare with the
solution proposed here.
The case study allowed us to observe the effects of the absence
of the element Relevance. Relevance is the level of importance of a
contextual element in relation to the Focus. The effects of the
elements absence were made evident when experts indicated the
importance of considering the weights of each Contextual Element
to make better decisions about the Situation. This nding brings us
to the issue of which other elements of the metamodel context may
also be relevant as components of the proposed approach and are
not yet being considered as components of the context model. Two
concepts to consider are Focus and Context Entity. Because the
Focus determines what can be considered to be relevant in a
context, it might be explored in conjunction with Relevance to
establish more precise situations. In addition, Contextual Entity,
for which information is provided by contextual elements, can be
applied to help characterize situations, which in turn facilitate
decision making regarding the course of a process.
Moreover, the proposed approach is not exhaustive. Indeed, in
the context and process metamodels, other elements could be
considered, i.e., the models should evolve. The models consider
previously known contextual elements, dened as relevant, to be
monitored. If, for example, a new contextual element arises during
the execution of a process, the current model does not handle this
element, which will be monitored only when the model is revised.
In future work, we intend to apply and evaluate the model
proposed in other scenarios with a greater number of experts
with different backgrounds and diverse working locations. New
case studies would support the comparison of results, and
generalization.
We will also extend the proposed approach to the denition and
validation of new rules within the metamodels, applying
inferences and developing the model to consider the contextual
relevance of each element and the impact of each contextual
element in every single activity.
Although the metamodel proposed provides a basis for
adaptation of processes, it does not comprise the complete
solution in the sense that it deals with predened elements.
One important issue that should be considered is that context is
also dynamic, and as so, new situations could arise or even some
situations could lose its relevance. Thus, a context-based adaptation system should, not only represent context associated with
process under a domain, but it should learn from adaptation
decisions made, as well as continuously identify new unforeseen
situations (sets of contextual elements). In [14], we present the
preliminary results from the implementation of schemes for the
identication of relevant contextual elements and situations by
applying Data Mining techniques in process logs. We present a rst
step to the computational engine that infers the need to update
situations and identify the contextual elements through mining
1213
technique, providing a solution for the evolvement of the context

model.
References
[1] M. Anastassiu, F.M. Santoro, A method for identication of relevant context in
business process, in: Proceedings of the 1st International Workshop for Context in
Business Process Management (CBPM13) 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 in
Business Information Processing 99 (2) (2012) 169194.
[3] M. Bazire, P. Brezillon, Understanding context before using it, in: 5th International
and Interdisciplinary Conference, CONTEXT 2005, Paris, France, Lecture Notes in
Computer Science 3554 (2005) 2940.
[4] J. Bauer, Identication and modeling of contexts for different information scenarios
in air trafc, Diplomarbeit, Technische Universitat Berlin, 2003.
[5] C. Bauer, A comparison and validation of 13 context meta-models, in: Proceedings
of 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 and
Mobile Computing 6 (2) (2010) 161180.
[7] I. Bider, Masking exibility behind rigidity: notes on how much exibility people
are willing to cope with, in: Proceedings of the CAiSE05 Workshops, Workshop
on Business Process Modeling, Development and Support, Porto, Portugal, (2005),
pp. 718.
[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 towards
improving process mining results, in: Proceedings of the SIAM International
Conference on Data Mining, SDM, 2009, pp. 401412.
[10] P. Brezillon, L. Pasquier, J.C. Pomerol, Reasoning with contextual graphs, European
Journal of Operational Research 136 (2) (2002) 290298.
[11] P. Brezillon, Representation of procedures and practices in contextual graphs,
Knowledge Engineering Review 18 (2) (2003) 147174.
[12] P. Brezillon, Context in problem solving: a survey, The Knowledge Engineering
Review 14 (1) (1999) 134.
[13] P. Brezillon, J.C. Pomerol, Contextual knowledge sharing and cooperation
in intelligent assistant systems, Le Travail Humain, 62, PUF, Paris, 1999,
pp. 2232463.
[14] J.E.S. Carvalho, F.M. Santoro, K. Revoredo, V.T. Nunes, Learning context to adapt
business processes, in: Proceedings of the 2013 IEEE 17th International Conference on Computer Supported Cooperative Work in Design (CSCWD), Whistler,
Canada, (2013), pp. 229234.
[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-based
approach for managing situation-awareness, Expert Systems with Applications
39 (2012) 1079610811.
[17] K. Cheverst, K. Mitchell, N. Davies, Design of an object model for a context
sensitive tourist GUIDE, Computers and Graphics 23 (6) (1999) 883891.
[18] E. Chtcherbina, M. Franz, Peer-to-peer coordination framework (p2pc): enabler of
mobile ad-hoc networking for medicien, business, and entertainment, in: Proceedings of International Conference on Advances in Infrastructure for Electronic
Business, Education, Science, Medicine, and Mobile Technologies on the Internet
(SSGRR2003w), LAquila, Italy, January, 2003.
[19] T. DeMarco, Structured Analysis and System Specication, Yourdon Press,
New York, 1978.
[20] Y.H. Feng, T.H. Teng, A.H. Tan, Modeling situation awareness for context-aware
decision support, Expert Systems with Applications 36 (2009) 455463.
[21] Gartner Group, Meeting the Challenge: The 2009 CIO Agenda. EXP Premier Report
January 2009, Gartner, Inc., Stamford, Connecticut, 2009.
[22] C. Ghidini, F. Giunchiglia, Local models semantics, or contextual reasoning locality
compatibility, Articial Intelligence 127 (2) (2001) 221259.
[23] T. Gu, H.K. Pung, D.Q. Zhang, A middleware for building context-aware mobile
services, in: Proceedings of IEEE Vehicular Technology Conference (VTC), Milan,
Italy, 2004.
[24] K.H. Han, J.W. Park, Process-centered knowledge model and enterprise ontology
for the development of knowledge management system, Expert Systems with
Applications 36 (4) (2009) 74417447.
[25] A. Held, S. Buchholz, A. Schill, A modeling of context information for pervasive
computing application, in: Proceedings of the Sixth Multiconference on
Systemics, Cybernetics and Informatics (SCI 2002/ISAS 2002), USA, 2002.
[26] T. Hofer, W. Schwinger, M. Pichler, G. Leonharsberger, J. Altmann, Contextawareness on mobile devices the hydrogen approach, in: Proceedings of
the 36th Annual Hawaii International Conference on System Sciences, 2002,
pp. 292302.
[27] J. Hong, E. Suh, S.J. Kim, Context-aware systems: a literature review and classication, Expert Systems with Applications 36 (2009) 85098522.
[28] K. Kumar, M. Narasipuram, Dening requirements for business process exibility,
in: Proceedings of the CAiSE06 Workshop. Workshop on Business Process
Modeling, Development, and Support (BPMDS06), 2006, pp. 137148.
1214
[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 Workshops, Hoboken NJ, USA, September 13, 2010). Lecture Notes in Business Information Processing, 66, Springer, Berlin, 2010, pp. 109121.
[30] T. Mattos, F.M. Santoro, K. Revoredo, V.T. Nunes, Formalizing the situation of a
business process activity, in: Proceedings of the 16th IEEE International Conference on Computer-Supported Cooperative Work in Design, Wuhan, (2012),
pp. 128134.
[31] J. McCarthy, Notes on formalizing context, in: Proceedings of the 13th International Joint Conference on Articial Intelligence, France, (1993), pp. 555560.
[32] N.F. Noy, D.L. McGuinness, Ontology Development 101: A Guide to Creating Your
First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-0105 and Stanford Medical Informatics Technical Report SMI-2001-0880, 2001
March.
[33] V.T. Nunes, F.M. Santoro, M.R.B. Borges, Context in knowledge intensive collaborative work, in: 10th International Conference on CSCW in Design, 2006, Nanjing,
Vol. 2, (2006), pp. 793798.
[34] V.T. Nunes, F.M. Santoro, M.R. Borges, A context-based model for knowledge
management embodied in work processes, Information Sciences 179 (15) (2009)
25382554.
[35] V.T. Nunes, C.M.L. Werner, F.M. Santoro, Dynamic process adaptation: a contextaware approach, in: 15th International Conference on Computer Supported
Cooperative Work in Design, Lausanne Switzerland, (2011), pp. 97104.
[36] V.T. Nunes, C.M.L. Werner, F.M. Santoro, Mediating process adaptation through a
goal-oriented context-aware approach, in: Proceedings of the 16th IEEE International Conference on Computer-Supported Cooperative Work in Design, Wuhan,
(2012), pp. 160167.
[37] UML-OMG, Object Management Group Unied Modeling Language, 2013 Available at: http://www.uml.org (accessed April 2013).
[38] BPMN, OMG Object Management Group Business Process Management
Notation, 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, Analysis
and 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 large
databases, in: Proceedings of the 20th International Conference on Very Large
Data Bases (VLDB), Santiago, Chile, (1994), pp. 487499.
[43] E.C. Ramos, F.M. Santoro, F.A. Baiao, Thinking out of the box: discovering the
relevance of external context to business processes, Knowledge Discovery,
Knowledge Engineering and Knowledge Management Communications in Computer and Information Science 348 (2013) 455470.
[44] J. Recker, M. Rosemann, M. Indulska, P. Green, Business process modeling a
comparative analysis, Journal of the Association for Information Systems 10 (4)
(2009) 333363.
[45] M. Rosemann, J. Recker, C. Flender, Contextualization of Business Processes,
International Journal of Business Process Integration and Management 3 (1)
(2008) 4760.
[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, PhD
thesis, Columbia University, 1995.
[48] H. Schonenberg, R. Mans, N. Russel, Process exibility: a survey of contemporary
approaches, in: 4th International Workshop CIAO, and 4th International Workshop EOMAS, CAiSE 2008. PC Montpellier, France, 2008, 1630.
[49] P. Soffer, J. Ghattas, M. Peleg, A goal-based approach for learning in business
processes, in: Nurcan, Salinesi, Souveyet, Ralyte (Eds.), Intentional Perspectives
on Information Systems Engineering, Springer, 2010, pp. 239256.
[50] T. Strang, C. Linhoff-Popien, A context modeling survey, in: 1st International
Workshop on Advanced Context Modeling, Reasoning and Management, UbiComp 2004 The Sixth International Conference on Ubiquitous Computing,
Nottingham/England, 2004.
[51] Y. Tao, J. Wang, X. Wang, D. He, S. Yang, Knowledge-based exible business
process management, in: TENCON 2006. 2006 IEEE Region 10 Conference, 2006.
[52] UNITED STATES. Department of TransportationFederal Aviation Administration,
FAA System Safety Handbook, Chapter 15, Operational Risk Management, 2000
Available 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) 93155.
[54] V. Vieira, P. Tedesco, A.C. Salgado, Designing context-sensitive systems: an

integrated approach, Expert Systems with Applications 38 (2) (2011) 11191138.
[55] V. Vieira, P. Tedesco, A.C. Salgado, P. Brezillon, Investigating the specics of
contextual elements management: the CEManTIKA approach, in: CONTEXT07
Proceedings of the 6th International and Interdisciplinary Conference on Modeling and Using Context, Berlin, (2007), pp. 493506.
[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. 93107.
[59] Z. Zainol, K. Nakata, Generic context ontology. Generic context ontology modeling: a review and framework, in: Proceedings of the 2nd International Conference
on Computer Technology and Development (ICCTD 2010), Cairo, Egypt, (2010),
pp. 126130.
Talita da Cunha Mattos received her M.Sc. degree in
Informatics from Federal University of the State of Rio
de Janeiro, Brazil, in 2012 and the B.Sc. degree in
Electronic Engineering from Federal University of Rio de
Janeiro, Brazil, in 2005. Her research focuses on
Information Systems, especially on the following
subjects: Business Process Management and Context
Management. Currently she is an engineer at Brazilian
Air Force, supporting IT systems for Air Trafc Control
and Air Defense.
Flavia Maria Santoro is an Associate Professor at

Applied Informatics Department of the Federal University of the State of Rio de Janeiro, Brazil. She received
her Ph.D. and M.Sc. degrees in Computer Science from
Federal University of Rio de Janeiro (COPPE-UFRJ). Her
research focuses on Information Systems, especially on
the following subjects: Business Process Management,
Knowledge Management, Computer-Supported Cooperative Work and Computer-Supported Collaborative
Learning. She participated in Latin-American research
projects and has experience in organizing workshops
and conferences. She joint the Universite Pierre et Marie
Curie Paris VI, Franca (20042005) and Queensland
University of Technology, Australia (20122013) in
sabbatical research projects.
Kate Cerqueira Revoredo is a Professor at Applied
Informatics Department of the Federal University of the
State of Rio de Janeiro, Brazil. She obtained her M.Sc and
D.Sc. degrees in Computer Science from Federal
University of Rio de Janeiro (COPPE-UFRJ). During the
year 2006 she worked for six months at the University
of Freiburg, Freiburg (Germany) as part of her D.Sc.
research. Her experience and research work focus on
machine learning, data mining, social media analytics
and ontology alignment. She participates in several
program committees of national and international
journals and conferences, and is a member of the
Brazilian Computer Society and the Special Commission
in Articial Intelligence.
Vanessa Tavares Nunes is a D.Sc. student at the
Systems and Computing Engineering Department of
COPPE Institute from the Federal University of Rio de
Janeiro, Brazil. She received her M.Sc. degree in
Computer Science from Federal University of Rio
de Janeiro (NCE-UFRJ). Her research focuses on
Information Systems, especially on the following
subjects: Business Process Management, Knowledge
Management, Context Management and Organizational Architecture. She coordinates consulting projects at companies in the eld of Organizational
modeling, Business Process Management and Software
development.

A Formal Representation For Context-Aware Business Processes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Formal Representation For Context-Aware Business Processes

Uploaded by

Copyright:

Available Formats

Computers in Industry 65 (2014) 11931214

Contents lists available at ScienceDirect

A formal representation for context-aware business processes

* Corresponding author at: Applied Informatics Department, Federal University

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Hong et al. [27] performed an extensive literature review

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

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

specic models resulting from them. Languages are usually data

element is any piece of data or information that allows an entity to

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

The rst layer is the Context Metamodel, which refers to the

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

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

Depending on the elements of the business process and of the

be an extension of the Contextual class for this domain. Therefore,

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Fig. 3. Context Metamodel.

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

3.3. Domain Metamodel layer

Description and attributes

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Fig. 4. Business Process Metamodel.

objects in a knowledge area. It is frequently used to explain the

The third layer is the Domain Metamodel. This metamodel

Description and attributes

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

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

This package is the language component that species the static

Given CE as the set of contextual elements, for all contextual

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Fig. 6. Domain Metamodel

Rule 4 (Formalization of the Relationship between Contextual

The rst rule relates Contextual Element and Situation. Note

Description and attributes

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Moreover, the development of the relationships among the

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

responsible for their own safety and navigation. Depending on the

Fig. 7. ATC domain model.

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Represents the action of an airplane taking off

models were built with the help of specialists through interviews.

is a focus, it is automatically linked to the contextual elements,

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Fig. 8. Aircraft takeoff process model.

us to explore the elements of context and dene situations. We

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

manually mapped and organized in the format of a log, as

Weather Condition, Runway, Pilot, Air Trafc Controller and

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Transcription of the occurrence reported in the daily situation report

called TAM. This process is code 1, instance 7, reported at 22/11/

Situation Taking off Extremely Probable 1 (TEP1)

Situation Taking off Probable 1 (TP1)

Situation Taking off Probable 2 (TP2)

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Fig. 10. Extract of the Log of one process instance.

T.C. Mattos et al. / Computers in Industry 65 (2014) 11931214

Air trafc controller

Air trafc controller

Ceiling, Wind, Visibility

Air trafc controller