Goal-Based Behavioral Customization of Information Systems - Advanced Information Systems Engineering - page 86

methods canBePerformed(t) and performed(t) to query/manipulate the tree did not pose
any obvious perception problems or design issues requiring intense problem solving
effort.
Anchoring the Policy Control Process. An issue that triggered further investigation is
that of scoping behaviors. In our example, a plan prefix reflects the use of the system
by one user at a particular time. The same or a different behavior may unfold from the
beginning in a different client system (some other customer trying to buy something),
or by the same customer later that day. With the term anchor we refer to any type of
entity, or group thereof, whose lifetime is bound to a plan prefix. In our example, the an-
chor is the web session. If, for example, the session expires so does the plan prefix that
has been constructed to that point. A new session always means an empty plan prefix
(i.e. state pointer points to the root of the policy tree) waiting to be expanded through
user actions. In different applications different anchoring entities can be thought. In an
application processing business process, e.g. for academic admissions, a student appli-
cation can be considered as the anchoring entity. Thus, for each new application that
arrives a new empty prefix is constructed which is then augmented (through progres-
sion of the state pointer) based on tasks that are performed to process that particular
application. Interestingly, different anchoring entities can be treated by different policy
trees. For example different users of our on-line store (identified through e.g. a cookie
mechanism) may experience different behavioral customizations, through assigning a
separate policy tree to each of them.
Performance and Tool Considerations. The construction of a policy tree is an off-line
activity and can afford longer computation times on separate computing infrastructure.
This way, we avoid unpredictably expensive computational steps to intervene in the
normal control flow. In our experimentation with several CFs over the bookseller goal
model we found that the first hundred of admissible plans can be calculated within a
time period ranging between one and 30 minutes. It is important to note that a working
customization can be achieved even if a subset (in our case some tens) of all admissible
plans is provided, though the resulting policy may prevent behaviors that are otherwise
desired. The policy tree can keep being updated as the planner returns new plans. We
definitely anticipate improved performance as the field of preference-based planning
is fast progressing. For example, an HTN-based planner with preferences has recently
been introduced which offers dramatically better performance through utilization of the
domain knowledge expressed as task hierarchies ([14]). The principles applied in this
paper are applicable to any preference-based planner that can generate sets of plans.

5 Related Work

Our proposal for requirements-driven software customization relates to research on a
variety of topics including adaptive systems, product lines and software/service com-
position.
General goal-driven adaptation has been proposed by several authors. Thus, Zhang
et al. [15] use temporal logic to specify adaptive program semantics. Further, work
by Brown et al. [16] uses goal models to explicitly specify what should occur during