Empowering End-User Programming in Context-Aware Applications by tzm16628

VIEWS: 71 PAGES: 2

									  Empowering End-User Programming in Context-Aware
                   Applications
                                            Tao Zhang, Bernd Brügge
                                         Technische Universität München
                                  Institut für Informatik/ I1, Boltzmannstraße 3
                                     85748 Garching b. München, Germany
                                           {zhang,bruegge}@cs.tum.edu


ABSTRACT
End-user programming becomes increasingly important
for context-aware computing since the system behavior of
existing context-aware systems does not reflect the
situation the end-user intended. In this paper, we present
a general proposed framework, which enables end-users
to program, customize and control context-aware system
behavior in a simple way. We discuss the building
prototypes and conclude this paper with a short
evaluation and an outlook into the future work.
KEYWORDS
Context-aware, Framework, End-user Programming

INTRODUCTION
To develop a context-aware application, developers
usually have two options: Either they build a proactive          Figure 1. Three-tier architecture for context-aware systems
system using inference engine, or they predefine and
hardcode a system behavior. Recent research [2] has              interface layer (Figure 1). The context layer is
shown that both of these approaches have not proven long         responsible for the physical sensor context acquisition,
term compatibility with the end-users expectations. An           delivering, and handling. The system behavior, written in
inference engine cannot predict the system behavior              ECA (Event, Condition, Action) rule specification
correctly, since there are many human or social aspects of       language, is separated from the underlying context-layer.
context that cannot be sensed or even inferred by sensors        While the developers are primarily responsible for the
or devices available today. The behavior of the context-         context layer and rule layer, end-users have a toolkit (user
aware system cannot be recognized and hardcoded by the           interface layer) to modify and control the overall system
developer, since it is very difficult for the developer to       behavior.
foresee what information and sensors are necessary to
infer a contextual state. Moreover he cannot foretell            We select the context-toolkit [1], a framework developed
whether the results produced by the system are                   by the Georgia Tech, to implement our low-level
meaningful to the end-users. People may feel like they are       communication infrastructure. Context widgets provide
loosing control of the system and begin to fight the             applications with access to context (e.g. location) from
context-unaware system. We believe that the only way a           their operating environment. Each context widget has a
system can agree with the users’ expectations is to have         state that is a set of attributes and a behavior that is a set
the users program the system behavior themselves in a            of callback functions triggered by context changes. In our
most simple way.                                                 approach, the system behavior is not hardcoded in the
Today, there are few frameworks available, which                 widgets like context toolkit did, but specified with ECA
support end-user programming in this research area [3].          rules that are visible to the end-users. Depending on the
In this paper, we present a general proposed framework,          incoming Sensor Events (e.g. somebody enters the room)
which enables end-users to program, customize and                from the Context Layer, the Rule Monitor evaluates
control context-aware system behavior in a simple way,           initially all the ECA-rules which Event parts are matched
where end-user is referred to as a person who has had            the actual situation (situation is an aggregate of simple
experiences with handheld devices like mobile phones or          events). These selected rules may conflict with each other
PDAs, but cannot program in JAVA or C++.                         if the Event parts of more than one rule are matched
                                                                 concurrently or if the services to be executed are
ARCHITECTURE                                                     exclusive. Rule Monitor then delegates those rules with
In [4], we presented an architecture, which is constructed       conflicts to a component we call Rule Conflict Manager,
of three layers: context layer, rule layer and user              w h i c h solves the rule conflicts before calling the


                                                             1
corresponding Services of the Context Layer. R u l e
Discoverer is a software component that can discover
user behavior patterns using AI methods such as frequent
pattern discovery. Since it is quite challenging to provide
good rules by just collecting sensor information, users are
currently still expected to refine the rules by removing
noise information from sensors.

The end-users can “program” individual personal context-
aware applications with high-level ECA rules. Users can                     Figure 3. Prototype-based User Interface
not only read the rules, but also modify them, delete
them, make each of them active or inactive (Rule Builder
& Rule Inspector). End-users are now able to personalize           Since the JESS syntax is not easy to understand, we
the rules to suit his needs and notions for how the                implemented Rule Builder using puzzle-like components
environment should react to his actions. Rules that are            (Figure 3). In this so-called prototype-based approach,
effectively executed are listed in chronological order. In         end-users can simply copy and refine existing rules
case that the user has difficulties to understand the system       (prototypes), which are either predefined by the
behavior, the user is able to track any executed rules in          developers, or partly recommended by the Rule
the past and figure out its rationale, he can then                 Discoverer. Since the behavior pattern of end-users is
eventually undo, redo some actions, or overwrite some              highly individual and changes over time, end-users can
rules (Rule Debugger).                                             program new system behavior by adding or removing
                                                                   components with the drag and drop feature. For Example,
                                                                   one can define the following rule for his daughter, who
STATUS                                                             always goes to bed between 20:00 and 20:30 with her
All the components have been now implemented to                    teddy bear (with RFID-tag):
evaluate our approach. In this paper, the primary focus
was directed towards the rule conflict management and              Scenario:         Good Night
user interface issue, which are related to defining rules.         Event part:       When daughter enters her bedroom,
                                                                   Condition part:   (and) it is between 8 pm and 8:30pm,
We implemented the Rule Monitor and Rule Conflict
                                                                   Action part:      (then) turn off the light,
Manager using JESS – a rule-based expert system written
                                                                                     (and) turn on the night-light,
in java. In the current implementation, end-user defined
                                                                                     (and) play night music for 20 Minutes.
rules and policies (meta rules with priority) are stored in
an external database (mySQL) and will be uploaded into             EVALUATION
the JESS internal Rule Base at runtime. Depending on the           We evaluated our framework in a laboratory-based
incoming events and context (e.g. state of system                  intelligent environment during winter semester 2003/04.
components), the facts in the JESS Working Memory will             About twenty computer science students have been asked
be updated. Pattern Matcher then search automatically              to build and modify the context-aware application
through vast amounts of combinations of facts to find              behavior (e.g. Good Night Scenario) with our framework.
those combinations that satisfy rules to figure out which          By using handheld computers like Palms, 90% of the
rules should be fired, while Agenda is responsible for             students can finish their task within 3 minutes with only
using the conflict strategy (defined by end-users) to              few helps. However, in order to find out if the average
decide which of the rules, out of all those that apply, have       user is capable of precisely specifying personal ECA
the highest priority and should be fired first. The                rules, a great deal more evaluation work with non-
Execution Engine is the component that fires the rules. It         computer scientists will be required in the future.
calls the external services, which eventually change the           REFERENCES
context [5]. (Figure 2)                                               1. Dey, A.K. et al. A conceptual framework and a toolkit
                                                                         for supporting the rapid prototyping of context-aware
                                                                         applications. HCI Journal 16(2-4), 2001, 97-166.
                                                                       2.   Bellotti, V. & Edwards, K, Intelligibility and
                                                                            Accountability: Human Considerations in Context
                                                                            Aware Systems. Human-Computer Interaction, 16.
                                                                            2001
                                                                       3.   Sohn, T. and Dey, A.K. iCAP: An Informal Tool for
                                                                            Interactive Prototyping of Context-Aware
                                                                            Applications. Extended Abstracts of CHI 2003, 974-5.
                                                                       4.   Zhang, T., An Architecture for Building Customizable
                                                                            Context-Aware Applications by End-Users, Pervasive
                                                                            2004 Doctoral colloquium.
                                                                       5.   Zhang, T., Brügge B, Empowering the User to Build
                                                                            Smart Home Applications, ICOST 2004.
         Figure 2. Using JESS for the Rule Layer



                                                               2

								
To top