Ambient-Oriented Programming

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Example Applications ======
The CRIME distribution comes with a suite of example applications, most of which are implemented in Java. This page describes the provided applications, how to deploy them, describes the rules they use internally and provides pointers on how to extend them.

===== IN/OUT Board =====
The IN/OUT Board is a classic context-aware application proposed by [Dey et al.] during their seminal work on the context toolkit. The IN/OUT Board implemented using CRIME is used to visualise the current location of a user. The said location is expected to be published as a fact to allow applications to adapt their behaviour accordingly. When users are out of reach, the application keeps a record of when the user was last seen by the system.

==== Deploying the application ====

The CRIME distribution contains a script file ''server.sh'', which starts a host-level CRIME Fact Space. It is important to start this server prior to running any CRIME application. After all, it is only through the mediation of the host-level Fact Space that different CRIME applications discover one another both locally and remotely. To start the IN/OUT Board, run the included script file ''inout.sh''. The CRIME engine will evaluate the rules specified below.

<code>
cd crime-1.0.0/
./server.sh &
./inout.sh
</code>

==== The Rules ====

The IN/OUT Board consists of an application class which manages the information on which users are located where which is coupled to simple user interface class written in Java. The application also offers a few classes which subclass from the Action class offered by the CRIME engine. These classes can be used in the CRIME rules which specify when the application will be notified of changes in its environment.

The Action class is an abstract class which expects its subclasses to implement two methods: The method ''activated'' is invoked whenever a CRIME rule can be derived which triggers the action. The method ''deactivated'' is invoked when the supporting evidence that allowed this rule to fire is dropped (due to a retract or a disconnection of a provider).

The rule below triggers the SetBoard action whenever it detects that a particular person (''?name'') is detected within a particular ''?room''. The ''activated'' method is invoked and will display the said information in its GUI. When the person leaves the room, the ''deactivated'' method of SetBoard is triggered which adds a ''history'' fact (used in the next rule), containing the persons last known whereabouts and a timestamp of when the ''deactivated'' method was invoked.

<code>
:edu.vub.crime.examples.board.SetBoard(?name, ?room, ?number) :-
	person(?id, ?name, student),
	location(?id, ?room).
</code>

As described in the original paper by [Dey et al.], variations in the functionality of the IN/OUT Board can be conceived where some versions may also display the last known whereabouts of a particular user on the screen. This can be achieved using the ''history'' fact which is published when the SetBoard action is deactived. When using the rule given below, the appearance of such a fact will trigger the HistoryBoard action which updates the GUI with the required information.
<code>	
:edu.vub.crime.examples.board.HistoryBoard(
    ?name, ?room, ?phone, ?time) :-
	history(?name, ?room, ?phone, ?time).
</code>

<note>**Action Names** \\
In the code snippets given above, the action names are fully qualified. The distribution of CRIME does however allow one to 
specify the scope of these rules as follows: ''%package edu.vub.crime.examples.board''. If this construct is used, the action classes can be referred to without full qualification. In the remaining examples, we will use the latter syntax
</note>
Ambient-Oriented Programming

User Tools

Site Tools

Page Tools
