Download Modeling and Using Imperfect Context Information

Automating Context-Aware Application
Development
Ted McFadden and Karen
Henricksen
Jadwiga Indulska
CRC for
Enterprise Distributed
Systems Technology
(DSTC)
School of Information
Technology and Electrical
Engineering,
The University of Queensland
Motivation

Need powerful yet generic abstractions and infrastructure for
context-aware systems

We have developed:


Context modelling concepts (graphical and logical)

Preference model to capture context-dependent requirements

Programming models/toolkit

Context and preference management infrastructure
Shortcomings of the generic approach:

APIs and data structures are not the most natural to use


repetitive, boiler-plate code is required
Changes in the context model often imply modification of code
Motivation (continued)


Solution - provide tools to:

customise generic infrastructure for particular context models

automate the generation of repetitive code
Benefits of this approach:



improved error checking
improved ability to evolve context models independently of
applications
increased opportunity for modifying aspects of the infrastructure
with minimal impact on applications
Generic infrastructure for
context-aware systems
Application 1
Application 2
Application layer
Application n
Toolkit layer
Context Programming Toolkit
Context
Database
Situation
Database
Context
Manager
Context
Gateway
Sensors
Preference
Manager
Context and
Preference preference
Database management layer
Context gathering
layer
Legend
Elvin notification
RMI
JDBC
Infrastructure components

Programming toolkit layer:


Supports two programming models:

Situation-based triggering: using a variant of the ECA model

Branching: selection from set of candidate choices based on:

context

context-dependent preferences
Context manager:

Controls repositories of context and situation information

Supports context query, update, notification of changes

Allows querying of model meta-data (for context tools)
Infrastructure components
(continued)


Preference manager:

Controls repositories of user and system preferences/policies

Evaluates preferences with respect to a context

Supports dynamic preference modification
Context gateway:


Interprets notifications from sensors
Provides a mapping to the fact representation used by the
context manager
Additional tool support

To reduce the coding effort required to use the generic
infrastructure, we have developed additional tools for
generating:



scripts to load and remove context models from the context
databases
model-specific classes for context manipulation
model-specific classes for transmitting context notifications over
a content-based publish-subscribe router
Approach



Tools rely on a context schema representation of our context
models
This is a SQL-like textual representation of context fact types
and situations
Schema is parsed by a common back-end schema compiler,
which can be connected to arbitrary front-ends
Context schema notation
CREATE CONTEXT SCHEMA DSTC.PACE.COMM
...
CREATE DOMAIN PersonID AS Identity...
CREATE DOMAIN ChannelID AS Identity...
CREATE PROFILED FACT TYPE PersonHasChannel (
KEY (
person PersonID,
channel ChannelID ) )
...
CREATE ALT SENSED FACT TYPE PersonLocatedAtPlace QUALITY(Certainty) (
person PersonID KEY,
place PlaceName ALTROLE )
...
CREATE PROFILED TEMPORAL FACT TYPE PersonEngagedInActivity
DEPENDS(PersonLocatedAt) (
person PersonID KEY,
activity ActivityName
)
...
CREATE SITUATION Occupied(person PersonID):
exists activity
. PersonEngagedInActivity[person,activity]
. activity = “meeting” or activity = “on.phone”
Context schema tool family
Context
Management
Mapping Tool
Common Tool
Back End
Context
Schema
Context
Schema
Compiler
Model-Specific
Library Tool
SQL Database
Schema
Fact Binding
Classes
Domain Classes
Intermediary
Form
Elvin Notification
Library Tool
Elvin Classes
Future Tools
Tool Outputs
Task Specific Tool Front Ends
Context management mapping tool



Generates database
administration scripts
for our context
manager (SQL-based)
Context modelling
concepts translated
into:

database constraints

metadata
Addresses deployment
issues (namespaces)
CREATE SCHEMA DSTC_PACE_COMM;
CREATE DOMAIN DSTC_PACE_COMM.PersonID
AS VARCHAR(255)...
CREATE TABLE DSTC_PACE_COMM.PersonHasChannel(
person DSTC_PACE_COMM.PersonID,
channel DSTC_PACE_COMM.ChannelID,
PRIMARY KEY (person, channel)
);
CREATE TABLE DSTC_PACE_COMM.PersonLocatedAtPlace(
person DSTC_PACE_COMM.PersonID,
place DSTC_PACE_COMM.PlaceName,
qCertainty DSTC_PACE_COMM.Certainty,
PRIMARY KEY (person, place)
);
CREATE TABLE DSTC_PACE_COMM.PersonEngagedInActivity(
person DSTC_PACE_COMM.PersonID,
activity DSTC_PACE_COMM.ActivityName,
fStartTime TIMESTAMP,
fEndTime TIMESTAMP,
PRIMARY KEY (person, fStartTime)
);
…
Model-specific library generator


Generates custom code for context manipulation for a given context model
Advantages:


Eliminates boiler-plate code for common usage cases
Catch more errors at compile time


Catch more errors at run-time


Strongly typed methods
Generate validation code
IDE integration
Elvin notification library tool


Context events are often sent as Elvin notifications
Tool provides:




model-specific code to automate event emission and reception
model-specific context gateway that feeds context events into context manager
Operates as follows:
1.
Tool generates a context interface (sample Java interface shown
below)
2.
Elvin stub generator is run over interface to generate emitter and
collector stubs (Java, Python)
3.
Tool generates context gateway
Supports flexible (n:m) messaging
Conclusions


Generic infrastructures for context-aware systems are essential but
can be cumbersome to use
To overcome this problem, we:




adopt a model-driven development approach
provide a suite of tools for automatically generating repetitive, boilerplate code
Tools rely on a textual schema notation and a common schema
compiler
We currently generate:



scripts to load/remove context models from context databases
model-specific classes for context manipulation
model-specific classes for transmitting context notifications
Conclusions (continued)

Future work:

mapping to OWL to enable reasoning over models for:



validation
interoperation
additional tools