Information Technology Reference
In-Depth Information
The policy tree is also supplied with a pointer that points to one of the nodes of the
tree. We call this the
state pointer
. The role of the state pointer is to maintain informa-
tion about what tasks have been performed in a given use scenario at run time. Thus, the
state pointer pointing to a given node means that the tasks of the plan prefix associated
to that node (the
associated prefix
) have already been performed. On the other hand, the
tasks that can possibly be performed from that point are restricted to the children of the
node currently pointed at, or any of the tasks in the associated prefix - in a sense that
these tasks can be repeated.
In Figure 4, for example, on the left side of the bottom frame, part of a policy tree
can be seen together with the CF it originated from (
useCart
). Through use of the
planner, that CF results in a set of admissible plans, say
P
. Some of those plans have a
prefix
¬
. Thus, in the resulting policy tree that is depicted, there is a
path from the root to the node
t
10
that constructs this prefix. By looking at the children
of node
t
10
, we infer that only two expansions of the prefix at hand will yield a longer
prefix that also exists in
P
and therefore is admissible with respect to the CF:
t
9
and
t
11
. In practice, this means that if we are to keep satisfying the CF, we should either
perform one of those two actions or repeat actions of the existing prefix (but without
moving the state pointer).
An algorithm for constructing a policy tree, from a list of admissible plans that the
planner returns can be found in our technical report [13]. It is important to note here
that a new plan can always be appended to an existing policy tree in linear time and
enrich the behavioral possibilities. This allows us to use partial outputs of the planner
immediately while gradually enriching the tree as new plans are generated.
[
t
1
,t
7
,t
6
,t
4
,t
10
,...
]
3.5
Conditioning and Instrumenting the Source Code
Let us now see how the policy tree can be plugged into the software system to enable
a behaviors that comply with the expressed customization desires. Preparation for this
needs to actually happen at design time, when the application is developed. Recall that
the system is built following the principles of task separation and task instrumentation.
This means that, on one hand, each mixed-agent task is associated with a set of state-
ments (the mapped code) whose removal can prevent execution of the task, and on the
other hand, for each task there is a well defined location in the code that marks comple-
tion of the task. The policy tree is integrated by conditioning access to the mapped code
based on the position of the state pointer, and by adding statements in the instrumenta-
tion points that advance the position of the state pointer accordingly.
More specifically, the former is implemented through the use of the function
can-
BePerformed(t)
. The function
canBePerformed(t)
returns true iff task
t
is one of the
children of the node currently pointed at by the state pointer or part of the associated
prefix. In other words, the code fragment can be entered only if the new plan prefix that
would result from performing the task that maps to that fragment belongs to at least one
of the admissible plans. For example the mapped code of the task
Use Cart
involves
buttons for adding items to the cart, text fields for specifying quantities, links for view-
ing the cart content etc. All these will be displayed only if
canBePerformed(useCart)
is
true, that is the task
Use Cart
is in one of the children of the state pointer, or it is part
of the path from the root to the state pointer. If this is not the case, the mapped code
