Modeling Context-aware Systems: A Conceptualized Framework

Achiya Elyasaf

and Arnon Sturm

Ben Gurion University of the Negev, Israel

Keywords:

Modeling, Context, Context-aware Systems, Conceptual Framework, Benchmark.

Abstract:

Context-aware systems keep on emerging in all of our daily activities. Context, which can be a location, a user,

an actual activity, or physical conditions, plays a major role in such systems. Actually, everything we refer

to in our systems can be considered as context. To cope with this new situation, mechanisms for managing

context were devised, including frameworks and programming languages. However, modeling languages that

address the notion of context are rare. In this paper, we aim at framing and further deﬁning the requirements for

context modeling languages. Such a conceptualized framework sets the ground for designing and evaluating

modeling languages for context-aware systems. We demonstrate a possible use of the proposed framework

through the evaluation of CO-LSC, a context-oriented modeling language.

1 INTRODUCTION

Context-aware systems are all around us and are

actually involved in every domain of our daily

socio-technological life, for example, in health

care (Bricon-Souf and Newman, 2007), in educa-

tion (Ireri et al., 2018), and in ambient intelligent sys-

tems (Ramos et al., 2011). Such systems sense their

environment and their internal state and adapt their

behavior accordingly. Thus, both the environment

and the internal state can be considered as context.

Environmental context can be location, temperature,

or user attributes, and internal context, i.e., the sys-

tem state, can be a combination of objects’ properties

or sequences of operations. Thus, a context is an ab-

straction of certain circumstances that are of interest

to the system and plays a major role in designing such

systems, as it facilitates situational information (Dey

et al., 2000).

As it appears that everything can be con-

sidered as a context, various context-oriented,

context-based, and context-aware techniques have

emerged, including Context-Oriented Programming

(COP) (Hirschfeld et al., 2008), context-oriented be-

havioral programming (Elyasaf, 2021; Elyasaf et al.,

2019), and modeling facilities (Sindico and Grassi,

2009). Nevertheless, these studies address context to

a limited extent and only focus on certain aspects of it.

One prominent reason for this gap is that the context

https://orcid.org/0000-0002-4009-5353

https://orcid.org/0000-0002-4021-7752

deﬁnition, and the requirements from it, are still quite

vague and there is no consensus of what a context is.

Is it external or internal? Is it a set of information or

processes? Is it static or dynamic?

With the vast knowledge of context-aware systems

and context-oriented techniques that emerged during

the last two decades, we believe it is time to clarify

the requirement for context modeling and further con-

ceptualize the notion of a context along with its many

facets. Speciﬁcally, we wish to describe the relation-

ships between the context of the system and its be-

havior, and how the data aspects and the behavioral

aspects of the system interact and inﬂuence one an-

other.

Various attempts to conceptualize context have

been suggested (Cabrera et al., 2017; Bettini et al.,

2010).Yet, these refer mainly to the structure and con-

text types neglecting the relationship to the system be-

havior.

The contribution of this paper is two-folded. First,

we provide a concise and clear view of a context for

the purpose of modeling context-aware systems. Sec-

ond, we deﬁne a framework that can be used for ana-

lyzing and developing context-oriented modeling lan-

guages (and techniques).

The paper is organized as follows. In Section 2

we revisited the requirements for context modeling

language, review studies that aim at similar goals as

ours, i.e., framing the notion of context, and refer to

existing context modeling languages. In Section 3 we

present a case study that serves us for demonstrat-

Elyasaf, A. and Sturm, A.

Modeling Context-aware Systems: A Conceptualized Framework.

DOI: 10.5220/0010818200003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 26-35

ISBN: 978-989-758-550-0; ISSN: 2184-4348

ing the context conceptual framework we suggest in

Section 4. In Section 5 we demonstrate potential use

of the framework, i.e., use it as a benchmark to ex-

amine a speciﬁc context-oriented modeling language.

Finally, in Section 6 we conclude and refer to further

framework utilization.

2 RELATED WORK

To set a conceptualized framework for context model-

ing we begin with setting the requirements. In doing

so, we refer to existing studies, such as (Bettini et al.,

2010) and to the experience we gained in context-

aware systems. In the following, we list the require-

ments we gathered. A context-oriented modeling lan-

guage should:

• Handle the heterogeneity of context information

sources.

• Capture the relationships between contexts and

system behaviors.

• Refer to past states of the system.

• Deal with the uncertainty of both data and behav-

ior.

• Facilitate reasoning in detecting problems in the

model and during execution.

• Manage the complexity of context.

In light of these requirements, we start with re-

viewing studies related to context conceptualization

and then refer to speciﬁc modeling languages.

2.1 Conceptualizing Context

When referring to context conceptualization there are

two major directions. One refers to metamodels and

the other to ontology speciﬁcation. We ﬁrst be-

gin with analyzing metamodels followed by ontology

studies.

Referring to service-oriented computing, a meta-

model that emphasizes the structure of contextual en-

tities and also refers to the system behaviors that are

determined by the context is presented (Vieira et al.,

2011). It refers to both static and dynamic aspects

of context-sensitive systems. The approach taken ad-

dresses the handling of many information sources and

captures the relationships between context and behav-

ior via contextual graph. Nevertheless, it neglects past

states, uncertainty, the management of contexts, and

reasoning.

In the case of service adaptation, a metamodel is

proposed for conceptualizing context-aware systems

(Peinado et al., 2015). While the metamodel includes

the notion of context, its abstraction is limited and

mainly refers to the system architecture rather than

modeling contexts and their binding to the system be-

haviors. Past states, uncertainty, and reasoning are

also neglected.

Domain-speciﬁc languages are also means for ad-

dressing context modeling, for example via a UML

proﬁle for context modeling (Simons, 2007). Such a

proﬁle includes a static view of a system and refers

to contexts as classes. It addresses the notion of dif-

ferent information sources, yet the other requirements

set above are mostly neglected. The metamodel of the

language is centered around the notion of an entity

that is assigned with a context. It further elaborates

on various types of contexts including physical (e.g.,

time, speed), environmental (e.g., distance, location),

computational (e.g., network trafﬁc, hardware status),

personal (e.g., age, gender, preferences), social (e.g.,

law, rules, roles, friends), and task (e.g., activities that

need to be performed or are already being executed)

that set the context landscape. It refers to informa-

tion sources and to various properties of a context.

However, the relationship to the system behavior, un-

certainty, past states, and reasoning features are not

explicated.

A model–based approach for context-aware sys-

tems is suggested in (L

opez-Jaquero et al., 2016). It

is centered around a goal-oriented approach and thus

the main entity that considers the context for its oper-

ation is a task. A task in that metamodel consists of

contexts that comprise context elements which are ac-

tually data information in the form of attributes, that

are monitored to identify a context. The metamodel

also includes resources that support awareness. In ad-

dition, the paper presents a context metamodel that

further elaborates the context components that corre-

spond to either the static or dynamic aspects of a con-

text. Here again, the operation of a context, i.e., its

activation and execution implications are ignored (in-

cluding references to past states, reasoning, and un-

certainty).

A comprehensive framework for model-driven

development of context as a service is presented

in (Moradi et al., 2020). The authors introduce var-

ious viewpoints on context and its related aspects.

In particular, they refer to modeling context-aware

objects, high-level contexts, situations, context ele-

ments, context sources, and changes in context. In

addition to the above, the resulting metamodel also

consists of derivation rules according to which con-

texts are created. However, the framework focuses on

context execution and provides little evidence for its

speciﬁcation (including reference to past states, rea-

soning, and uncertainty).

Modeling Context-aware Systems: A Conceptualized Framework

Following two surveys (Bettini et al., 2010; Cabr-

era et al., 2017) dealing with ontology with respect to

context modeling, the authors emphasize two issues:

context information model and reasoning techniques,

see for example, (Brings. et al., 2018; Ejigu et al.,

2007; Aguilar et al., 2018). In that sense, ontology-

based approaches focus on the system/context struc-

ture and facilitate reasoning capabilities, yet these ne-

glect the behavioral aspect. The context information

is classiﬁed following a pre-deﬁned ontology, thus,

sometimes it limits the ﬂexibility of the context infor-

mation model.

2.2 Context-Oriented Modeling

Techniques

Various context-oriented modeling techniques were

devised. For example, Context-Oriented Domain

Analysis (CODA) adds the notion of context on top

of feature diagrams to model software requirements

(Desmet et al., 2007). The approach mainly refers

to the system structure and functionality, yet the ac-

tual behaviors are not elaborated. As it utilizes feature

models reasoning is also applicable.

Context modeling can also be modeled using

states (Yue et al., 2017). In that case, each state

represents a context instance with values of several

attributes. The transitions between the contexts de-

scribe the system behavior. Nevertheless, it seems

that describing context instances using that approach

may result in states explosion.

Context Modeling Language (CML) was also de-

vised for the purpose of developing context-aware

systems (Henricksen and Indulska, 2006). The lan-

guage focuses on the context information and the re-

lationships among that information. It neglects the

binding to the system behavior, yet it facilitates rea-

soning.

The search we performed for context-oriented

modeling reveals that the modeling needs for context-

aware systems are addressed only to a limited extent.

It seems that no comprehensive language that takes

into account the overall needs exist and there is also

a need to deﬁne such requirements. In this paper, we

aim at addressing the latter.

Summary. Back to the requirements, we set be-

fore, it seems that the majority of the approaches

address the context information (static) model to a

large extent. In some cases, reasoning capabilities

are also provided. However, most approaches neglect

the binding of the context to behavior, the past sys-

tem state, the uncertainty, and the management of the

context complexity. We believe that a major reason

for that is the lack of conceptualizing these aspects.

Thus, in this paper, we aim at framing the notion of

context, its components, and the semantics that need

to be taken care of.

3 THE TRAINING SYSTEM

As mentioned before, in this paper, we propose a

framework for conceptualizing context. To clarify

the deﬁnitions and the concepts of this framework,

we demonstrate them via a training-system case study

that we now describe. The system allows trainers to

plan the training for their trainees and adapt the plans

to various situations and circumstances. A simpliﬁed

(class) model of such a system is depicted in Figure 1

and the basic training behavior is depicted in Figure 2.

A trainer selects a training type for the trainee and

executes it, where each training is composed of one

or more activities. Note that we deliberately omit the

many details of the models (such as relationship types

and multiplicities, as well as exact navigation across

objects) as these are of limited importance for this pa-

per.

Naturally, this basic training behavior might re-

quire some adjustments, depending on the context.

For example, the actual training has to be adjusted for

senior trainees or be rescheduled upon bad weather

(Figure 3).

4 CONCEPTUALIZING

CONTEXT

A context according to Dey is “any information that

can be used to characterize the situation of an entity.

An entity is a person, place, or object that is consid-

ered relevant to the interaction between a user and an

application, including the user and application them-

selves” (Dey et al., 2000). Such a deﬁnition which is

adopted in many studies is too vague and refers only

to some facets of a context.

In this paper, we propose to further reﬁne the def-

inition of context and refer to its components, opera-

tions, and states. To do that, we devise a metamodel

and a life cycle of a context, based on related stud-

ies and experience we gained in context-oriented sys-

tems.

4.1 Preliminaries

The Word ‘Context’. Generally, when describing

systems, the term “context” is used in two different

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Trainer

name

expertise

TrainingType

duration

location

levelOfDifﬁculty

ActualTraining

date

location

levelOfDifﬁculty

Trainee

age

status

experience

Weather

temprature

wind

humidity

ActivityType

name

description

levelOfDifﬁculty

ActualActivity

repetition

weight

Equipment

EquipmentType

name

CivilCondition

status:{regular, lockdown, partial}

Figure 1: The class diagram of the training system.

Title: A regular training session

loop

tr:

Trainer

:Object

TrainingType

t1:

TrainingType

:Object

ActivityType

at1:

ActualTraining

ActivityType

create

pick(te):t1

execute()

chooseByOrder():a

execute()

aa1:

ActualActivity

create()

te:

Trainee

Figure 2: The default training behavior.

ways:

• System Context — the internal and environmen-

tal state of the system. For example, the system

context in the training system includes the state of

all system objects (that also represent the environ-

ment) and the state of the executing behaviors.

• Behavior Context — the context of each of the

system’s behaviors. Such a context is a projec-

tion of the system context in view of the speciﬁc

behavior. For example, “During a lockdown, all

training sessions must be held virtually, i.e., via

Zoom. Thus, only indoor activities are permitted

and these should require only equipment that is

available at the trainee location.” In such a case

the ”during lockdown” is the context that matters

for the training behavior. It is important to stress

that contexts only affect the system behaviors.

As the two meanings of context may confuse,

some paradigms use different terms for each mean-

ing. In context-oriented programming, for example,

the term context refers to the system context, while

the term layer refers to the context of a behavioral as-

pect (Hirschfeld et al., 2008). We believe that there

is no difference between the two, and artiﬁcially sep-

arating them may be confusing even more. Thus, in

the proposed meta-model we refer to the system con-

text as a composition of other contexts that combine

many simple and complex elements, where each con-

text corresponds to a different behavioral aspect of the

system.

Separation of Concerns. Many times, several be-

haviors are bound to the same context, as in the case

of the “bad weather” context, where both the fol-

lowing behaviors are bound to it — “Suspend active

training when the weather gets bad” and “Reschedule

training before it starts when weather is bad” (Fig-

ure 3b). Similarly, multiple conditions can lead us to

determine that we are in the context of bad weather,

such as weather forecast; sensors data; or even a se-

quence of events, like three sequential sensor read-

ings. The proposed metamodel and life cycle sup-

port this separation of concerns between “what to do

in context x”, i.e., the system behavior, and “when is

context x active”, i.e., the context information model.

Context Data. Furthermore, when describing

context-dependent behaviors, we encapsulate the

relevant data for speciﬁc behavior in the context. For

example in Figure 3a, given the context “a training

session with a senior trainee”, the actual adjustment

may rely on the age of the trainee. Such data is

encapsulated within the context.

Inter-context Relationship. Different contexts

may relate to other contexts in different ways. The

relations can be structural, temporal, and dependency.

Another type of relation is priority, which deﬁnes the

priority of context-dependent behaviors, based on the

priority of the context that they are bound to. The

use of priorities is one of the approaches for handling

contradicting behaviors.

Modeling Context-aware Systems: A Conceptualized Framework

loop

tr:

Trainer

:Object

TrainingType

t1:

TrainingType

:Object

ActivityType

at1:

ActualTraining

ActivityType

create

pick(te):t1

execute()

chooseByOrder():a

execute()

aa1:

ActualActivity

create()

adjust()

te:

Trainee

Title: Adjust activities for senior trainees

(a) Adjust activities in the context of a senior trainee.

tr:

Trainer

:Object

TrainingType

pick(te):t1

te:

Trainee

BadWeather

cancel()

reschedule()

Title: Reschedule training before it starts when weather is

bad

(b) Reschedule training in the context of bad

weather.

Figure 3: Context-dependent behavioral variations of Figure 2.

4.2 The Context Metamodel

To cope with the above deﬁnitions we devise the

metamodel presented in Figure 4. In the following,

we explain the various components of a context, ex-

plicate their rationale, and demonstrate these via the

training system.

Generally, each behavior in a system is bound to

a context, meaning that the behavior is relevant only

when the context preconditions are met. Of course, a

context-independent behavior is a special case of the

general behavior, where the context is always active

(e.g., the context “the system is running”).

Context. An information that refers to elements and

their activities. A context is deﬁned by its precondi-

tions and the data that it encapsulates. For example,

the context “a training session with a senior trainee”

(Figure 3a) is active whenever a session with a senior

trainee is started. The preconditions in this example

are both behavioral (something happens) and struc-

tural (constraints on the Trainee element). The data

of this context is a speciﬁc training session with a se-

nior trainee, meaning that it encapsulates structural

elements that are relevant for this context, such as

Trainee, Trainer, Training Type, and ActualTraining.

Each system behavior (behavioral element) is bound

to a speciﬁc context, recall that unbound behavior is

a private case of general behavior, and whenever the

context’s preconditions are met, the system behavior

starts running, with the relevant context data given as

a parameter for the behavior. For example, as men-

tioned before, the actual age of a trainee might affect

the required adjustment.

Context Type. Context has a type. It can be static,

i.e., predeﬁned and constant, such as a speciﬁc loca-

tion, like a training studio. It can also be dynamic,

that is, the structure of the context is deﬁned, yet it

is populated during run time, such as the Weather. It

can also be behavioral, that is, refers to a sequence of

operations, such as three Actual Training in a Week.

The context type is not explicated in the metamodel,

yet, it is derived from the elements that deﬁne it.

Simple Context. A simple context is an atomic

piece of information or an action. For example, the

location of the training, a trainee at a certain age/age

range, and the weather, when referring to information.

When referring to an action or a behavior, a context

can be, for example, running, swimming, functional

exercise, or on the way (for training).

Complex Context. A complex context consists of

multiple other contexts. For example, the “training

session” context consists of the following simple con-

texts: Trainee, Trainer, Training Type, and Actual-

Training. The “training session with a senior trainee”

consists of the complex context “training session” and

the simple context “a senior trainee”. This is, of

course, only one way to model such contexts.

Inter-context Relationship. Different contexts

may have various types of relationships among

them. In the following we elaborate on common

relationships we identiﬁed:

• Structural, including Association and General-

ization. Association refers to cases in which a

context in associated with another context. For

example, an ActualTraining is associated with an

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Context

Simple

Context

Complex

Context

Data

Precondition

Element

Behavioral

Element

Structural

Element

Inter-Context

Relationship

Dependency

Temporal

Structural

Priority

target

source

encapsulates

n n

bound

Figure 4: A context metamodel.

ActualTrainee. Generalization refers to cases in

which a context may be reﬁned. For example,

the VirtualTraining context and PhysicalTraining

context are both reﬁnements of the Training con-

text. In that case, it means that all properties, con-

straints, dependencies, and relationships that refer

to the Training context are applied to the other two

unless speciﬁed otherwise.

• Context Dependency. Context dependency

refers to cases when one context relies on another

one. For example, every actual training depends

on the Weather context, though not necessarily

vice versa.

• Context Temporal. The context temporal rela-

tionship refers to temporal relationships between

contexts. For example, the period between two

Actual Trainings should be at least 24 hours.

• Context Priority. In some cases, several contexts

are simultaneously active, which may result in

several active context-dependent behaviors. This

may be problematic if two contradicting behav-

iors are active at the same time. For example,

the context of a speciﬁc activity within a training

requires X repetitions, yet in another context in

which the Trainee fails in accomplishing the goal,

the number of repetitions should be reduced by

30%. There are many ways to overcome such

contradictions, for example, by deﬁning the pri-

ority of each context of behavior. While priorities

may be dangerous, as they require a cross-aspect

perspective on the system, it is still a popular op-

tion, as in the case of rule-based systems, which

is why we include this type of relation. Yet, other

solutions may be more robust to constant changes,

such as explicitly deﬁning the behavior when the

two contexts are simultaneously active.

Speciﬁcation Activation Deactivation

Figure 5: The context life cycle.

4.3 The Context Life Cycle

Another important observation we had is that context

has both a type (its speciﬁcation) and occurrences (in-

stances). Thus, the life cycle of a context can be sum-

marized as appears in Figure 5.

Context Speciﬁcation: refers to its deﬁnition. The

activity is dashed since it is usually done before the

system runs, though it can also be done during run

time, in cases of self-adaptive systems.

Context Activation: refers to the instantiation of a

context, based on its preconditions. Meaning that the

system tracks the elements’ state (i.e., the state of the

system) and the set of context preconditions. At the

moment that some elements become to a state that re-

sembles the elements’ state of context preconditions

– then the context is instantiated. In the case of the

training system, the identiﬁcation of the bad-weather

context occurs when the temperature actually drops

below zero.

Once a new context instance is generated, the be-

haviors that are bound to this context take place. In

the case of the training system, the behavior in Fig-

ure 3b takes place whenever the bad-weather context

is active.

Context Deactivation: refers to the point in which

a context is not relevant anymore. So, in the case of

the above example, due to heating devices, the tem-

perature crosses zero and the training should get back

to normal. This should also affect the system’s opera-

tion.

Modeling Context-aware Systems: A Conceptualized Framework

In this case, the active behaviors that are bound to

the bad-weather context, are either immediately ter-

minated, or they may perform a “cleanup” action be-

fore terminating, such as: gracefully ending the cur-

rent activity before returning to normal.

4.4 Reﬂection over the Metamodel

Here again, we review the devised metamodel in

light of the requirements set in Section 2. In the

metamodel, we did not elaborate on the context in-

formation. To cope with heterogeneous information

sources, such information can be associated with the

context element. Relationships are explicitly deﬁned

in the metamodel. References to past states can be

accomplished by the behavioral aspect speciﬁed in

the metamodel. The complexity is dealt with through

the context hierarchy and its relationships. Applying

reasoning capabilities depends on the implementation

approach and uncertainty can be handled by the bind-

ing and priority mechanisms.

5 UTILIZING THE PROPOSED

FRAMEWORK

In this section, we aim at demonstrating the usage of

the framework we suggested. For that purpose, us-

ing the framework, we examine an existing context-

aware modeling technique based on live-sequence

charts (LSC) (Harel and Marelly, 2003), an extension

of message-sequence charts (MSC) with the ability to

specify possible and mandatory behaviors of reactive

systems (Harel and Pnueli, 1985), as well as forbid-

den behavior. LSC has execution semantics that al-

lows for synthesizing the model and verifying its cor-

rectness (Harel et al., 2010; Harel and Marelly, 2003).

Elyasaf et al. proposed an extension to LSC (CO-

LSC) that allows for subjecting charts to context and

demonstrated it on a case study of a smart-home sys-

tem (Elyasaf et al., 2018). Speciﬁcally, they pro-

posed to handle contextual data in terms of a rela-

tional data model, where preconditions are speciﬁed

as ‘select’ queries, and any change to the contextual

data is done using ‘update’ queries. The charts can

be bound to one or more contexts, represented as the

queries’ names. They also presented translational se-

mantics to the LSC semantics and implemented them

in a tool that enables the execution and veriﬁcation of

the charts. According to these semantics, whenever

the context preconditions are met (i.e., there is a new

answer to the query), a new live copy of the chart is

created, with the context’s data encapsulated as a pa-

rameter for the chart.

<<device>>

AirCondition

<<device>>

SmartLight

<<device>>

MotionDetector

Office Restroom Kitchen

Emergency

Building

Room

hasPerson:bool

Figure 6: The contextual-data schema of (Elyasaf et al.,

2018).

Figure 6 depicts the schema of the contextual data

of the smart home application and Table 1 presents

the deﬁnition of contexts, i.e., the names of the con-

texts, their preconditions, and the deﬁnition of the

context encapsulated data. We note that the queries’

elements are all structural, and while it may seem that

the preconditions are using structural elements only,

it is not the case, as depicted in Figure 7. The chart

on the left is bound to the context of “Nonempty-

Room”, specifying that whenever a room becomes

nonempty, then the lights should be turned on, and

when the context ends (deactivated) – they should be

turned off (allowing for performing “cleanup” actions

when the context becomes deactivated). The chart on

the right demonstrates how the NonemptyRoom is ac-

tivated/deactivated based on the detection of a mo-

tion. While the NonemptyRoom precondition is de-

ﬁned by a structural element, the state of this element

is controlled by a behavioral element – the chart in

Figure 7b.

The charts in Figure 7 demonstrate the separation

of concerns between the speciﬁcation of what to do

in a nonempty room, and the speciﬁcation of how

we know that a room is nonempty using the update

queries appear in Table 2.

Finally, Figure 8 depicts the use of a complex con-

text. In CO-LSC there is no explicit composition

of contexts, but rather implicit composition within a

query.

In the following we discuss the inter-context rela-

tionships support in CO-LSC:

1. Structural — In CO-LSC there are no explicit re-

lationships among contexts. Nevertheless, such

relationships can be expressed via the query op-

erators. For example, an association can be spec-

iﬁed using additional phrases of a query. Gener-

alization can be speciﬁed by adding conditions to

further reﬁne the query results.

2. Dependency and Temporal — since CO-LSC is

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Table 1: Context Deﬁnition of (Elyasaf et al., 2018).

ID Context Name Pre-Conditions Encapsulated Data

1 Room r ∈ Room Room

2 Emergency e ∈ Emergency Emergency

3 NonemptyRoom r ∈ Room: r.hasPerson Room & Person

Name: Turn lights on/off in

nonempty rooms

Context: r ∈ NonemptyRoom

r.light r

setOn()

ended(“NonemptyRoom”)

setOff()

(a) Binding charts to dynamically created context.

Name: Activate/deactivate “NonemptyRoom”

based on motion detection

Context: r ∈ Room

r r.mSensor

motionDetected()

execute(“Mark room as nonempty”, r)

motionStopped()

execute(“Mark room as empty”, r)

(b) Execute ‘update’ queries to activate/deactivate context(s).

The gears lifeline denotes a contextual data controller that

allows for querying and updating the system context.

Figure 7: The smart-home system of (Elyasaf et al., 2018). Charts are bound to contexts Room and NonemptyRoom.

Table 2: Context Initiation of (Elyasaf et al., 2018).

ID Context Name Operation

1 Mark room as nonempty r.hasPerson = true

2 Mark room as empty r.hasPerson = false

Name: Lights During Emergency

Context: r ∈ Room, e ∈ Emergency

r.light r

setOff()

Forbid

Figure 8: A Complex context, binding to more than one

simple context.

provided with execution semantics, these relation-

ships exist during execution and veriﬁcation. For

example, the contexts EmptyRoom and Nonemp-

tyRoom are temporally related, as they cannot

be simultaneously active. Thus dependency and

temporal relations are speciﬁed in the behavioral

charts. Furthermore, reasoning techniques can be

applied to the model for extracting the implicit

temporal and dependency relationships.

3. Priority — CO-LSC supports priorities for events

through the mechanism of smart play-out (execu-

tion) (Harel et al., 2010; Harel et al., 2002). If

a certain behavior in a speciﬁc context requires

a higher priority than another, then it is possi-

ble to prioritize the events of the ﬁrst. Yet, CO-

LSC does not provide an idiom for prioritizing all

the behaviors that are bound to a speciﬁc context.

While it is technically possible to create such an

idiom, it might not be safe to prioritize a context

with all the current and future behaviors that are

bound to it. In addition, CO-LSC does not support

the prioritization of contexts.

4. Life Cycle Support — CO-LSC supports the

entire context life cycle. Contexts are speci-

ﬁed using queries and are activated and deacti-

vated based on the system behavior and the update

queries.

To conclude, it seems that CO-LSC provides com-

prehensive support for context-aware systems. How-

ever, it can beneﬁt from explicit references to the con-

text core elements.

6 SUMMARY

This paper proposes a framework for supporting the

evaluation of context-oriented development methods

(i.e., modeling techniques and programming lan-

guages). It conceptualizes and explicates the build-

ing blocks of context-aware systems. Such a frame-

work can be used for evaluating existing development

methods (as we demonstrated in this paper) and for

Modeling Context-aware Systems: A Conceptualized Framework

the development of new ones.

We do not claim that the framework is complete,

yet it certainly can serve as a starting point for bench-

marking of context-oriented development methods.

For that reason, we suggest adopting the framework

with caution as more reﬁnements may emerge. In

future work, we wish to continue to examine the

proposed framework and further examine context-

oriented/aware programming/modeling approaches.

REFERENCES

Aguilar, J., Jerez, M., and Rodr

ıguez, T. (2018). Cameonto:

Context awareness meta ontology modeling. Applied

Computing and Informatics, 14(2):202–213.

Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J.,

Nicklas, D., Ranganathan, A., and Riboni, D. (2010).

A survey of context modelling and reasoning tech-

niques. Pervasive and Mobile Computing, 6(2):161–

180. Context Modelling, Reasoning and Management.

Bricon-Souf, N. and Newman, C. R. (2007). Context aware-

ness in health care: A review. International Journal

of Medical Informatics, 76(1):2–12.

Brings., J., Daun., M., Hildebrandt., C., and T

orsleff.,

S. (2018). An ontological context modeling frame-

work for coping with the dynamic contexts of cyber-

physical systems. In Proceedings of the 6th Inter-

national Conference on Model-Driven Engineering

and Software Development - MODELSWARD,, pages

396–403. INSTICC, SciTePress.

Cabrera, O., Franch, X., and Marco, J. (2017). Ontology-

based context modeling in service-oriented comput-

ing: A systematic mapping. Data and Knowledge En-

gineering, 110:24–53.

Desmet, B., Vallejos, J., Costanza, P., De Meuter, W., and

D’Hondt, T. (2007). Context-oriented domain anal-

ysis. CONTEXT’07, page 178–191, Berlin, Heidel-

berg. Springer-Verlag.

Dey, A. K., Abowd, G. D., et al. (2000). The context

toolkit: Aiding the development of context-aware ap-

plications. In Workshop on Software Engineering for

wearable and pervasive computing, pages 431–441.

Citeseer.

Ejigu, D., Scuturici, M., and Brunie, L. (2007). An

ontology-based approach to context modeling and rea-

soning in pervasive computing. In Proceedings of

the Fifth IEEE International Conference on Pervasive

Computing and Communications Workshops, PER-

COMW ’07, page 14–19, USA. IEEE Computer So-

ciety.

Elyasaf, A. (2021). Context-Oriented Behavioral Pro-

gramming. Information and Software Technology,

133:106504.

Elyasaf, A., Marron, A., Sturm, A., and Weiss, G. (2018).

A Context-Based Behavioral Language for IoT. In

Regina Hebig and Thorsten Berger, editor, CEUR

Workshop Proceedings, volume 2245, pages 485–494,

Copenhagen, Denmark. CEUR-WS.org.

Elyasaf, A., Sadon, A., Weiss, G., and Yaacov, T. (2019).

Using Behavioral Programming with Solver, Con-

text, and Deep Reinforcement Learning for Play-

ing a Simpliﬁed RoboCup-Type Game. In 2019

ACM/IEEE 22nd International Conference on Model

Driven Engineering Languages and Systems Compan-

ion (MODELS-C), pages 243–251. IEEE.

Harel, D., Kugler, H., Marelly, R., and Pnueli, A. (2002).

Smart Play-out of Behavioral Requirements. In

Aagaard, M. and O’Leary, J. W., editors, Formal

Methods in Computer-Aided Design, 4th Interna-

tional Conference, FMCAD 2002, Portland, OR, USA,

November 6-8, 2002, Proceedings, volume 2517 of

Lecture Notes in Computer Science, pages 378–398.

Springer.

Harel, D., Maoz, S., Szekely, S., and Barkan, D. (2010).

PlayGo: Towards a Comprehensive Tool for Scenario

Based Programming. In ASE’10 - Proceedings of the

IEEE/ACM International Conference on Automated

Software Engineering, pages 359–360.

Harel, D. and Marelly, R. (2003). Come, Let’s Play:

Scenario-Based Programming Using LSCs and the

Play-Engine. Springer Science & Business Media.

Harel, D. and Pnueli, A. (1985). On the Development of

Reactive Systems. In Logics and models of concurrent

systems, pages 477–498. Springer.

Henricksen, K. and Indulska, J. (2006). Develop-

ing context-aware pervasive computing applications:

Models and approach. Pervasive and Mobile Comput-

ing, 2(1):37–64.

Hirschfeld, R., Costanza, P., and Nierstrasz, O. M. (2008).

Context-oriented programming. Journal of Object

technology, 7(3):125–151.

Ireri, B. N., Wario, R. D., and Mwingirwa, I. M. (2018).

Choosing and adapting a mobile learning model for

teacher education. In Handbook of Research on Dig-

ital Content, Mobile Learning, and Technology Inte-

gration Models in Teacher Education, pages 132–148.

IGI Global.

opez-Jaquero, V., Rodr

ıguez, A. C., Teruel, M. A., Mon-

tero, F., Navarro, E., and Gonzalez, P. (2016). A

bio-inspired model-based approach for context-aware

post-wimp tele-rehabilitation. Sensors, 16(10):1689.

Moradi, H., Zamani, B., and Zamanifar, K. (2020). Caasset:

A framework for model-driven development of con-

text as a service. Future Generation Computer Sys-

tems, 105:61–95.

Peinado, S., Ortiz, G., and Dodero, J. M. (2015). A meta-

model and taxonomy to facilitate context-aware ser-

vice adaptation. Computers & Electrical Engineering,

44:262–279.

Ramos, C., Marreiros, G., and Santos, R. (2011). A sur-

vey on the use of emotions, mood, and personality

in ambient intelligence and smart environments. In

Handbook of Research on Ambient Intelligence and

Smart Environments: Trends and Perspectives, pages

88–107. IGI Global.

Simons, C. (2007). Cmp: a uml context modeling proﬁle

for mobile distributed systems. In 2007 40th Annual

Hawaii International Conference on System Sciences

(HICSS’07), pages 289b–289b. IEEE.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Sindico, A. and Grassi, V. (2009). Model driven devel-

opment of context aware software systems. In Inter-

national workshop on context-oriented programming,

pages 1–5.

Vieira, V., Tedesco, P., and Salgado, A. C. (2011).

Designing context-sensitive systems: An integrated

approach. Expert Systems with Applications,

38(2):1119–1138.

Yue, S., Smith, R., and Yue, S. (2017). A state-based ap-

proach to context modeling and computing. In 2017

IEEE SmartWorld, Ubiquitous Intelligence Comput-

ing, Advanced Trusted Computed, Scalable Comput-

ing Communications, Cloud Big Data Computing,

Internet of People and Smart City Innovation (Smart-

World/SCALCOM/UIC/ATC/CBDCom/IOP/SCI),

pages 1–6.

Modeling Context-aware Systems: A Conceptualized Framework