Automating Context-Aware Application Development

1
Automating Context-Aware Application Development

• Ted McFadden and Karen Henricksen
• CRC for
• Enterprise Distributed Systems Technology (DSTC)

Jadwiga Indulska School of Information
Technology and Electrical Engineering, The
University of Queensland
2
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

3
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

4
Generic infrastructure for context-aware systems
Application layer
Application 1
Application 2
Toolkit layer
Context Programming Toolkit
Context and preference management layer
Context Database
Preference Database
Context Manager
Preference Manager
Situation Database
Context gathering layer
Context Gateway
Legend
Sensors
Elvin notification RMI JDBC
5
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)

6
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

7
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

8
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

9
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
• )

10
Context schema tool family
Context Management Mapping Tool
SQL Database Schema
Common Tool Back End
Fact Binding Classes
Model-Specific Library Tool
Context Schema Compiler
Domain Classes
Intermediary Form
Context Schema
Elvin Notification Library Tool
Elvin Classes
Future Tools
Tool Outputs
Task Specific Tool Front Ends
11
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.Perso
nHasChannel( 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) )
12
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
• Strongly typed methods
• Catch more errors at run-time
• Generate validation code
• IDE integration

13
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
• Tool generates a context interface (sample Java
  interface shown below)
• Elvin stub generator is run over interface to
  generate emitter and collector stubs (Java,
  Python)
• Tool generates context gateway
• Supports flexible (nm) messaging

14
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, boiler-plate 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

15
Conclusions (continued)

• Future work
• mapping to OWL to enable reasoning over models
  for
• validation
• interoperation
• additional tools