Architectural Support for

Context-Aware Applications:
From Context-Models to
Services Platforms

10/05/2012
Patrícia Dockhorn Costa
[email protected]
www.inf.ufes.br/~pdcosta
Healthcare Scenario
• Mr. Janssen suffers from epilepsy
– limitations in lifestyle
– need of constant supervision
• Healthcare application
– detects upcoming seizures
– informs caregivers
– increases quality of life
Context-Aware Application

location
proximity

user interaction context-aware

application
temperature context
information
end-user
medical
conditions
context

• Context
– the set of possibly interrelated conditions in which an entity
exists
Context Concepts
• Context
• Context Model
• Context Modelling
• Context Information
• Context-Aware Application
• Situations
• Quality of Context
Context Concepts
Challenges
• Capturing context
– aggregation
– reasoning
– inference
• Time sensitive
• Sensors are imperfect (Quality of Context)
• Sensors are distributed
• Applications are distributed (mobile)
• Application adaptation, reactivity
• Security, privacy
Objective
• Integrated solution for the development of
context-aware applications:
– Reference Architecture
– Context Handling Platform
– Context Modelling
Reference Architecture
• Context-Aware Patterns
– Event-Control-Action pattern
– Context Sources and Managers Hierarchy Pattern
– Actions Pattern

context observe trigger action

controller performer
processor

condition rule

behavior
description

event control action

Reference Architecture
• Components and Interfaces
– Context sources
– Context managers
– Controllers
– Action components
Context Handling Platform

generic

user interaction context-aware!

application
context
information
end-user

context
Context Handling Platform
• Generalizes functionality that can be reused by
several context-aware applications
• Gathers context information, performs context
processing
• Detects situations in a distributed fashion
• Allows delegation of application rules
• Performs adaptation on behalf of applications
Context Handling Platform
(a)
user’s user’s
context1 context2
user1 user2

ip-a1 ip-c1 ip-d1 ip-a2 ip-c2 ip-d2

application-specific application-specific
components components

ip-e1 ip-e2

context handling platform

focusing on infrastructure
interactions user’s
context

ip-d

(b) application-specific
components
ip-e

context handling platform

Context Handling Platform

application1-specific components

ip-m’1 ip-m’’1 ip-e’’1 ip-e’’’1

user’s context action external action

context ip-d’ source1 ip-l’ ip-f’ controller1 ip-g’ resolver1 ip-i’ provider1
context
manager
external context context 2 action external action
processor ip-i source2 ip-l’’ ip-f’’ controller ip-g’’ ip-i’’
resolver2 providern

ip-m’2 ip-m’’2 ip-e’’2 ip-e’’’2

application2-specific components
Context Modelling

location
context-aware
proximity application

temperature

end-user
user interaction

context
information
•locationValue (lat, long, alt)
•temperatureValue (Celsius)
•heartBeatValue (ECG)

medical
code
conditions context generation
«Entity» isContainedIn
SpatialEntity 1..*
1..*

hasContainment «RelationalContext»
ContainerEntity
Containment
1 1
hasSocialNetwork «RelationalContext»
Person
SocialNetwork
1..* 0..*
1 hasDeviceAvailability «RelationalContext»
DeviceAvailability
«Entity» 1
SpatialEntity isDeviceAvailableTo
Device 1..* 1..*
0..*
1 callee

Person
«RelationalContext»
TelephoneCall
models
caller
1 0..*
Context Modelling
• Abstractions to facilitate representation of
context information
• Situation modelling (aggregation, reasoning)
• Automatic code generation
• Quality of Context (QoC)
 Application’s universe of discourse and state-of-
affairs
• Tourist Application

John and
Mary’s device
Mary
John has to
close
is connected to

pr
ox
a museum

im
access to a

ity
WLAN
Bluetooth
network
Context Modelling Requirements
• In order to support context-aware applications
one needs amongst others (meta)models that
define
– Context and situation types and their relationships
– The “imperfection” of context information (Quality of
context)
– Adaptation rules based on context and situations

• Context models should:

– Support common understanding, problem-solving,
and communication among the various stakeholders
involved in application development
– Represent context unambiguously
Goal of Context Modelling
• Provide basic conceptual foundations for context
modeling, which allow context-aware application
designers to represent (i) relevant elements of a
context-aware application’s universe of discourse;
and (ii) particular state-of-affairs of interest

• We consider results from foundational ontologies to

support our conceptual context modelling approach
 Foundational ontologies: related work

< composed by < composed by

{ disjoint, complete} { disjoint, complete}

Foundational Context Concepts
• Context
– the set of possibly interrelated conditions in which an
entity exists
Foundational Context Concepts: situation
Foundational Context Concepts: situation
Foundational Context Concepts
(UML profile)

• Artifacts for specification

– Context profile: <<Entity>>,
<<RelationalContext>>, <<IntrinsicContext>>,…
– Situation profile: <<IntrinsicSituation>>,
<<FormalRelationSituation,
<<RelationalSituation>>, …
• Products of specification
– Context Models: person, Temperature, GeoLocation,
GeoLocationCoordinates, Device, etc
– Situation Models: SituationFever,
SituationConnected, SituationPresentation, etc
Foundational Context Concepts: summarized
Foundational context Description
concepts
Entity an object that beares context
Context a particular condition that inheres in an entity
Intrinsic Context a particular type of context that belongs to the essential nature of a
single entity
Relational Context a particular type of context that depends on the relation between
distinct entities
Contextual Formal a relation that holds directly between two or more entities’ intrinsic
Relation values (qualities)
Context Situation a composite concept that defines particular application’s state-of-
affairs. It can be composed of entities, contexts, and other
situations
Intrinsic Situation a context situation composed of a single entity and one of its intrinsic
contexts
Relational Situation a context situation composed of at least two entities and their
pertinent relational contexts
Formal Relation a context situation composed of a single entity type and two or more
Situation of its intrinsic contexts
Situation of Situations a context situation composed of other context situations
Combined Situations a context situation composed of other contexts, entities, and other
Context Models: Entity Types

«Entity» «Entity»
IntangibleEntity SpatialEntity
{ disjoint} { disjoint}

Application Network PointEntity ContainerEntity

{ disjoint}

Device Person Building Room Vehicle

* { overlaping}
* + livesAt
Home Office
*
+ worksAt *
Intrinsic Context Types

«Entity»
SpatialEntity
hasHeartRate «IntrinsicContext»
HeartRate
1
hasMood «IntrinsicContext»
1
Mood
1
hasActivity «IntrinsicContext»
Person
Activity
1..* 1
hasMentalState «IntrinsicContext»
1 MentalState
1..*

Desire Belief Intention

Intrinsic Context Types

«Entity» hasGeoLocation «IntrinsicContext»

SpatialEntity GeoLocation
1 1
hasBatteryPower «IntrinsicContext»
Device
BatteryPower
1 1
«Entity»
IntangibleEntity

hasBandwidth «IntrinsicContext»
Network
Bandwidth
1 1
Relational Context Types

«Entity» «Entity»
SpatialEntity IntangibleEntity

Device Network
*
1 1 hasNetworkAvailability «RelationalContext» isNetworkAvailableTo
*
NetworkAvailability Channel
1 *
hasChannelAvailability «RelationalContext» isChannelAvailableTo
ChannelAvailability *
1
Relational Context Types

«Entity» isContainedIn
SpatialEntity 1..*
1..*

hasContainment «RelationalContext»
ContainerEntity
Containment
1 1
hasSocialNetwork «RelationalContext»
Person
SocialNetwork
1..* 0..*
1 hasDeviceAvailability «RelationalContext»
DeviceAvailability
1
isDeviceAvailableTo
Device 1..* 1..*
Contextual Formal Relations

«Entity» hasGeoLocation «IntrinsicContext»

SpatialEntity GeoLocation
1 1
+ coordinates

«datatype»
GeoLocationCoordinates
+ latitude : Real
+ longitude : Real
+ altitude : Real
+ nearness(in entity1 : GeoLocationCoordinates, in enitty2 : GeoLocationCoordinates) : Boolean
+ distance(in entity1 : GeoLocationCoordinates, in entity2 : GeoLocationCoordinates) : Real
Contextual Formal Relations
«datatype»
GeoLocationCoordinates
+ latitude : Real
+ longitude : Real
+ altitude : Real
+ nearness(in entity1 : GeoLocationCoordinates, in enitty2 : GeoLocationCoordinates) : Boolean
+ distance(in entity1 : GeoLocationCoordinates, in entity2 : GeoLocationCoordinates) : Real

«Entity» hasGeoLocation «IntrinsicContext» + coordinates

SpatialEntity GeoLocation
1 1

hasSpatialCoordinates «IntrinsicContext»
ContainerEntity
SpatialCoordinates
* 1
+ dimension

«datatype»
SpatialDimension
+ radius : Real
+ containment(in point : GeoLocationCoordinates, in container : GeoLocationCoordinates, in dimension : SpatialDimension) : Boolean
+ containment(in entity1 : GeoLocationCoordinates, in dimension1 : SpatialDimension, in entity2 : GeoLocationCoordinates, in dimension2 : SpatialDimension) : Boolean
Context Situation Types: Situation Fever

{ Context SituationFever inv:

temp = person.hasTemperature AND
person.hasTemperature.value > 38}

person
Person
0..1
1
1
«IntrinsicSituation»
SituationFever
1
hasTemperature
0..1
temp «IntrinsicContext»
Temperature
1
Context Situation Types: Context Types

Person

«enumeration» «enumeration»
«IntrinsicContext»
«role» hasMsnStatus MsnStatusEnum SkypeStatusEnum
MsnStatus
MsnUser + online + online
1 1 + status : MsnStatusEnum
+ busy + offline
+ beRightBack + skypeMe
«IntrinsicContext» + away + away
«role» hasSkypeStatus SkypeStatus
SkypeUser + inCall + notAvailable
1 1 -status : SkypeStatusEnum + outToLunch + doNotDisturb
Intrinsic Situation Types: SituationAvailable

«role» hasMsnStatus «IntrinsicContext»

MsnUser MsnStatus
1 1
msnUser msnStatus { Context SituationAvailable inv:
0..1 0..1
(skypeUser = msnUser) AND
((not skypeUser.oclIsUndefined()) AND
«IntrinsicSituation» (skypeUser.skypeStatus = skypeStatus) AND
0..1 SituationAvailable 0..1
0..1
((skypeStatus.value = "Online")
Person
OR(skypeStatus.value = "SkypeMe")))
OR
0..1 ((not msnUser.oclIsUndefined()) AND
(msnUser.msnStatus = msnStatus) AND
0..1 ((msnStatus.value = "Online")
skypeUser 0..1 skypeStatus OR(msnStatus.value = "BeRightBack"))))}
«role» hasSkypeStatus «IntrinsicContext»
SkypeUser SkypeStatus
1 1
Relational Situation Types: SituationConnected
1 1
hasConnection «RelationalContext» isConnectionOf
Device Network
Connection
1 0..1

WLAN Bluetooth

«RelationalSituation»
{ Context SituationConnected inv:
*SituationConnected
not device.hasConnection.oclIsUndefined() }

* *
1
device
hasConnection *«RelationalContext»
Device
Connection
1 0..1
*
network 0..*
isConnectionOf
Network
1
Formal Relation Situation Types:
SituationWithinRange

{ Context SituationWithinRange inv:

entityA.hasGeoLocation = locationA AND
entityB.hasGeoLocation = locationB AND
locationA.value-> distance(locationB.value) < range}
*
«FormalRelationSituation»
* SituationWithinRange
*
+ range
*
1 1 1 1
entityA entityB locationA locationB
«Entity» hasGeoLocation «IntrinsicContext»
SpatialEntity GeoLocation
1 1
Situation of Situations Types: SituationSwitch

{ Context SituationSwitch inv:

(wlan.device = bluetooth.device) AND
(wlan.device.hasConnection.network.oclIsTypeOf(WLAN)) AND
(bluetooth.device.hasConnection.network.oclIsTypeOf (Bluetooth)) AND
(bluetooth.initialtime - wlan.finaltime < 1)}

«RelationalSituation» wlan «SituationOfSituations»

SituationConnected SituationSwitch
1 0..1
bluetooth
1 0..1
Situation of Situations Types: SituationSwitch

{ Context SituationDuration inv:

((not SituationWithinRange.finaltime.isOclUndefined()) AND
(SituationWithinRange.finaltime - SituationWithinRange.initialtime > 60))
OR
((SituationWithinRange.finaltime.isOclUndefined()) AND)
(Time.now() - SituationWithinRange.initialtime> 60))}

«SituationOfSituations» «FormalRelationSituation»
SituationDuration SituationWithinRange
* 1 + range
Context Information Models
«datatype»
GeoLocationCoordinates
+ latitude : Real
+ longitude : Real
+ altitude : Real
+ nearness(in entity1 : GeoLocationCoordinates, in enitty2 : GeoLocationCoordinates) : Boolean
+ distance(in entity1 : GeoLocationCoordinates, in entity2 : GeoLocationCoordinates) : Real

«Entity» hasGeoLocation «IntrinsicContext» + coordinates 1

SpatialEntity GeoLocation
1 1 *

conceptual model

«datatype»
GeoLocationMeasurement
«datatype» «datatype» «enumeration»
RangePrecision Freshness + entityID : String
Origin
+ geoLocation : GeoLocationCoordinates
+ minValue : Real + creationtime : Time + sensed + precision : RangePrecision
+ maxValue : Real + temporalResolution : RangePrecision + derived + freshness : Freshness
+ profiled + origin : Origin
+ probabilityOfCorrectness : Real
context information model
Context Information Models
«role» «IntrinsicContext»
hasMsnStatus
MsnUser MsnStatus
1 + status : MsnStatusEnum
1
0..1 msnUser msnStatus
0..1

0..1 «IntrinsicSituation» 0..1

0..1 SituationAvailable

0..1 skypeStatus
0..1
skypeUser
«IntrinsicContext»
0..1
«role» SkypeStatus
hasSkypeStatus
SkypeUser 1 + status : SkypeStatusEnum
1

conceptual model

«datatype»
SituationAvailableMeasurement
+ personID : String
+ msnStatus : MsnStatusEnum
+ skypeStatus : SkypeStatusEnum
+ probabilityOfCorrectness : Real
context information model + freshness : Freshness
Context Information Models
«role» «IntrinsicContext»
hasMsnStatus
MsnUser MsnStatus
1 + status : MsnStatusEnum
1
0..1 msnUser msnStatus
0..1

0..1 «IntrinsicSituation» 0..1

0..1 SituationAvailable

0..1 skypeStatus
0..1
skypeUser
«IntrinsicContext»
0..1
«role» SkypeStatus
hasSkypeStatus
SkypeUser 1 + status : SkypeStatusEnum
1

conceptual model

«datatype»
SituationAvailableMeasurement
+ personID : String
+ msnStatus : MsnStatusEnum
+ skypeStatus : SkypeStatusEnum
+ probabilityOfCorrectness : Real
context information model + freshness : Freshness
Situation Realization
• Rule-based approach
– Fits nicely the nature of situation detection
– Rules (OCL invariants) are repeatedly
applied to a collection of facts (context
information)
• Jess
– Shadow facts
– Main components: working memory and
rule-base
Situation Realization (overview)
specification realization
“shadow”
contextmodels
models context models mechanism context fact
context context models
(Java classes)
context models
(UML class (UML + OCL) templates (Jess)
(UML + OCL)
(UML + OCL)
diagram)

application
designer
situation models
situation models
(UML
(UML class
+ OCL)
diagram)
situation models
context models
(Java classes)
(UML + OCL)
“shadow”
mechanism situation
context
templates
fact
models
(UML + OCL) (Jess)

situation models situation detection

situation models context models
Template level (OCL invariants)
(UML + OCL) rules (Jess)
(UML + OCL)
(design-time)

Universe of discourse
Instance level
(run-time) State-of-affairs
condition 1
context sources

condition 2

rule
set
working app.
service users
memory entity
condition 3 context sources rule
J engine

context
Situation Lifecycle
Situation Detection

Creation Rule Deactivation Rule

(situation type invariant) (not (situation type
(not (situation exists)) invariant))
=> (situation exists)
create (situation) =>
[RaiseEvent()] deactivate (situation)
[RaiseEvent()]
Mappings
Context Models => Java
• Octopus (www.klasse.nl/octopus/index.html)
– Generates java code from UML classes, and statically
checks OCL constraints
– UML classes to Java classes
– Associations to class attributes
• One-to-one (one attribute in each class)
• One-to-many (one of the attributes is a collection)
• Many-to-many (both attributes are collections)
– Subsets association
Situation Models => Java + Jess

OCL language Jess language

object (ObjectType (OBJECT ?object))
object.pdatatype (ObjectType (OBJECT ?object) (pdatatype ?pdatatype))
object1.object2 (ObjectType1 (OBJECT ?object1) (object2 ?object2))
object1.object2.object3 (ObjectType1 (OBJECT ?object1) (object2 ?object2))
(ObjectType2 (OBJECT ?object2) (object3 ?object3))
(ObjectType3 (OBJECT ?object3))

object1.datatype (ObjectType1 (OBJECT ?object1) (datatype ?pdatatype))

object1.datatype.pdatatype (ObjectType1 (OBJECT ?object1) (datatype ?datatype))
(DataType (OBJECT ? datatype) (pdatatype ?pdatatype))

object1.object2. datatype. pdatatype (ObjectType1 (OBJECT ?object1) (object2 ?object2))

(ObjectType2 (OBJECT ?object2) (datatype ?datatype))
(DataType (OBJECT ?datatype) (pdatatype ?pdatatype))

Object->collection (ObjectType (OBJECT ?object) (collection ?collection)

Context Models => Java

Context Models SituationContained

specification

UML classes UML classes OCL invariant to realization

to Java classes to Java classes Jess code

public class Entity...

public class ContextJ (defrule entertrue_situation_contained )
public class IntrinsicContext extends Context... (defrule enterfalse_situation_contained )
public class SpatialEntity extends Entity...
public class PointEntity extends SpatialEntity ...
public class ContainerEntity extends SpatialEntity J
public class Person extends PointEntityJ
public class Building extends ContainerEntity... public class SituationType...
public class GeoLocation extends IntrinsicContext... public class SituationContained extends SituationType...
public class SpatialCoordinates extends IntrinsicContextJ
...
EnterTrue Rule SituationContained

(defrule entertrue_situation_contained
(Person (OBJECT ?person)( hasGeoLocation ? person_hasGeoLocation))
(GeoLocation (OBJECT ?locationPerson&:(eq ?locationPerson ? person_hasGeoLocation)))
(Building (OBJECT ?building)(geoLocation ?building_hasGeoLocation))
(GeoLocation (OBJECT ?locationBuilding&:(eq ?locationBuilding ?building_hasGeoLocation)))
(Building (OBJECT ?building)(spatialCoordinates ?building_hasSpatialCoordinates))
(SpatialCoordinates (OBJECT ?spatialCoord&:(eq ?spatialCoord ?building_hasSpatialCoordinates)))
(GeoLocation (OBJECT ?locationPerson) (location ?locationPerson_coordinates))
(GeoLocation (OBJECT ?locationBuilding) (location ?locationBuilding_coordinates))
(SpatialCoordinates (OBJECT ?spatialCoord) (dimension ?spatialCoord_dimension))
(test (call context_control.SpatialDimension Containment ?locationPerson_coordinates
?locationBuilding_coordinates ?spatialCoord_dimension))
(not (SituationContained (OBJECT ?st)(person ?person) (building ?building) (finaltime nil)))
=>
(bind ?SituationContained (new situation_control.SituationContained ?person ?building))
(definstance SituationContained ?SituationContained)
)
EnterFalse Rule SituationContained

(defrule enterfalse_situation_contained
(not (and (Person (OBJECT ?person)( hasGeoLocation ? person_hasGeoLocation))
(GeoLocation (OBJECT ?locationPerson&:(eq ?locationPerson ? person_hasGeoLocation)))
(Building (OBJECT ?building)(geoLocation ?building_hasGeoLocation))
(GeoLocation (OBJECT ?locationBuilding&:(eq ?locationBuilding ?building_hasGeoLocation)))
(Building (OBJECT ?building)(spatialCoordinates ?building_hasSpatialCoordinates))
(SpatialCoordinates (OBJECT ?spatialCoord&:(eq ?spatialCoord ?building_hasSpatialCoordinates)))
(GeoLocation (OBJECT ?locationPerson) (location ?locationPerson_coordinates))
(GeoLocation (OBJECT ?locationBuilding) (location ?locationBuilding_coordinates))
(SpatialCoordinates (OBJECT ?spatialCoord) (dimension ?spatialCoord_dimension))
(test (call context_control.SpatialDimension Containment ?locationPerson_coordinates
?locationBuilding_coordinates ?spatialCoord_dimension))
(SituationContained (OBJECT ?st)(person ?person) (building ?building) (finaltime nil))
=>
(call ?SituationContained deactivate)
)
Distribution
• Service-oriented approach: components
encapsulate Jess engines, and situation
information is exchange by means of the
component services
• DJess: separate engines virtually share working
memory. Rule engines running on different
nodes can apply rules on shared facts
Conclusions
• Context models help understanding context
concepts and how they relate to each other
• Context models are static
• Situations allow one to define state-of-affairs of
concern for context-aware applications
• Behaviours can be defined in terms of how the
system evolves from situation to situation!
• Situations can be used to define conditions that
trigger a rule system, as, e.g., in ECA rules
• Situations can be composed of situations
themselves
– modularization of the situation models, improving
organization and reuse of situation specifications
Conclusions (2)
• Situation realization is rule-based
– Allows attentive situation detection as opposed to
query-based solutions
• Model-driven approach
– Specification elements are systematically mapped
to realization elements
– UML as a mature technology in model-driven
developments