Information Technology Reference
In-Depth Information
Note, again, that the injection of conditioning and instrumentation code discussed
above is taking place at design time and based on the goal model. It is therefore in-
dependent of the actual structure of the policy tree, which, once the system is up and
running, varies based on the customization constraints that are in effect each time.
3.6
In Action
Let us now see a complete example of how a system is customized through expression
of high-level customization desires. Back to our on-line shop, consider the scenario in
which the shop-owner wants to construct CFs for newly identified groups within her
customer base. In Figure 4, two different CF scenarios she devised can be seen together
with screen-shots showing the effect they have to system behavior. On the scenario
on the top frame the CF prevents the users from - among other things - viewing any
product information before they login. In effect this means that once the session starts
the only user action that is allowed is logging in. Indeed, in the policy tree, login is the
only child of the root. This explains the bare-bones screen that is offered to the users
(upper screen-shot labeled [I]). Later in the same scenario of the top frame the user
has logged in and is browsing products. However, the CF prevents the user from adding
any comments. Hence, this facility is absent when viewing detailed product information
(screen-shot [II]). Nevertheless, at that stage, making use of the cart or logging out is
possible as seen in the policy tree. Thus, the button “Add to cart” is visible next to the
product and the button “Logout” on the top left of the screen. The scenario on the lower
frame of Figure 4, on the other hand, tailored to e.g. customers from a particular country
overseas, prevents use of the cart but does not prevent addition of comments. Thus, at a
stage where detailed product information is viewed, the user cannot add the item to the
cart as before, but she can post a comment or log-out (screen-shot [III]). This is exactly
what the state pointer indicates.
4
Applying Goal-Based Customization
Let us now discuss some of the experiences we acquired from our case study with our
on-line cart system. A detailed account on this application can be found in [13].
Code Development and Instrumentation.
The on-line cart system we built is a 5 thou-
sand lines-of-code (5KLOC) application in PHP, following a common 3-layer architec-
tural style - i.e. separating view, application logic and storage layers. Two developers,
senior undergraduate students at that time, where asked to develop the system following
a standard textbook object-oriented approach with the only goal model related restric-
tion that the leaf level tasks of the goal model (which was maintained exclusively by the
first author) would be treated as acceptance tests for the end-product and that optional
and alternative tasks maintain that status in the implementation. Looking at the result
afterwards we found that task separation not only was possible but emerged naturally
in the development process. Interestingly, the mapped code would tend to appear at the
view layer of the application. Furthermore, subsequent conditioning and instrumenta-
tion of the mapped code did not pose difficulties either. Policy trees, on the other hand,
are plugged as separate globally visible PHP classes in the application. The use of the
