Information Technology Reference
In-Depth Information
Connection of Objects.
Often some objects within a given ensemble have
some kind of strong and more or less static interconnection, even though the
correct location of the objects is usually not fixed. For this, the system creates
proxy objects of remote objects. Those can be used like local objects. This kind
of dependency, or resulting functionality, could also be implemented within the
publish/subscribe system, or any other message-passing protocol. But in situa-
tions requiring a rather fixed connection between objects the proposed approach
has turned out to be better usable than purely event-based communication.
Declaration of Goals.
To allow goal-based interaction with deployed objects,
we need to define the goals achievable for a given object. For this, we employ a
PDDL-like notion as known from planning. Every action provided by the object
is annotated with its preconditions and effects as shown in Ex. 3. Usually, all
proposition not being valid after executing a given action, need to be listed as so
called negative effects. In object oriented programming, in contrast to planning
in general, most of the properties are functional. That is, it can not be that the
two propositions
(dimValue Lamp true)
and
(dimValue Lamp false)
hold at
the same time. By convention, all properties declared by some object are assumed
to be functional, which allows a shorter formalisation.
Example 3. The functionality of our lamp can be formalised as follows:
(:action turnOn
:precondition (not isOn ?@)
:effect ((isOn ?@)
(dimValue ?@ 1)) )
The special variable
?@
refers to the deployed object itself, in our example a lamp.
Asking a lamp which is turned off to achieve the state
(dimValue Lamp3 0.5)
would result in the following action sequence computed from the specification:
(turnOn Lamp3) (dimValue Lamp3 0.5)
.
(:action dimLight
:parameters (?v - float)
:precondition (isOn ?@)
:effect (dimValue ?@ ?v) )
◦
So far we have been concerned with effects on internal state properties only. In
principle, two types of effects can be distinguished: those concerning internal and
those for external parameters. But instead of annotating actions with external
effects, we define a mapping between internal and external properties as shown
in Ex. 4. Please note, that the specification of the objects functionality as shown
in Ex. 3 is completely independent from the environment the object is deployed
into. Both, the object and its environment are linked by specifying the property
map shown in Ex. 4. To allow the goal based interaction with objects, they are
deployed by providing the specification and the effect map.
Example 4. To link internal and external properties, all objects are annotated
with mappings as follows:
(dimValue ?@ ?v) => (luminosity @position ?v)
This mapping connects the internal
dimValue
with the external
luminosity
property. Please note that the position, is only available within the deployment
system, the lamp itself has no knowledge of it, and should not have.
◦
