Information and Software Technology

Specification of personalization in web application design

Irene Garrigós

, Jaime Gomez

, Geert-Jan Houben

a_{Software and Computing Systems Department, Universidad de Alicante, Apartado de Correos 99, 03080 Alicante, Spain} b_{Technische Universiteit, Delft Web Information Systems, PO Box 5031, 2600 GA Delft, The Netherlands}

a r t i c l e i n f o

Received 1 June 2009

Received in revised form 28 February 2010 Accepted 12 April 2010

Available online 18 April 2010 Keywords: Personalization Web engineering Reusability Rule language

a b s t r a c t

Personalization of websites has become an important issue in Web modeling methods due to their big and heterogeneous audience. However, due to the existence of too many notations to represent the same design concepts in different methodologies, personalization specifications cannot be used out of the scope of a single tool or method. Moreover, in some cases, personalization is not defined as a separate aspect, being difficult to maintain and update. This paper tackles the aforementioned problems present-ing a generic modelpresent-ing technique to facilitate the specification of the personalization. Personalization specifications can be reused across different websites and different development environments.

!2010 Elsevier B.V. All rights reserved.

1. Introduction

Web idiosyncrasy introduces new challenges for the design pro-cess that go further than the specification of the navigation map, including aspects such as continuous website evolution together with the existence of a heterogeneous audience that implies that the website design should cope with different users’ needs, goals, preferences, and capabilities. Adapting the information content and services for different user groups as well as for concrete users makes websites available to a broad audience and so, it has become a vital feature of modern Web applications. This adaptivity to indi-vidual users or user groups in a website is called personalization. There are many definitions of personalization[1–3], but there is not a universal definition. We define Web personalization as the process of changing the content and structure of a website to adapt it to the specific needs, goals, interests and preferences of each user taking advantage of the user’s navigational behaviour and context. When designing personalized websites, ad-hoc design becomes unworkable. On one hand, many existing commercial approaches are based on rules and offer powerful specification means and tools for personalization (e.g. ILog JRules, LikeMinds, WebSphere, Rain-bow, etc.) that make the use of personalization easier. However, in most cases, specifications are not portable, because they use not only different modeling techniques but also different imple-mentation methods. Other problems of these approaches are the low abstraction level and the insufficient separation from the

application’s functional specification that cause reuse problems and make the maintenance and scalability of the resultant person-alized applications difficult. On the other hand, website modeling methods[4–10]provide a conceptual and systematic approach to complex Web application design and implementation. These meth-odologies allow developing personalized websites where the per-sonalization specifications are tightened to the underlying modelling methodology. As a consequence, and due to the exis-tence of too many notations to represent the same design concepts in the different methods, personalization specifications cannot be used out of the scope of a single tool or method, and thus cannot be shared among different approaches. Moreover, in some cases, the personalization is embedded in their design models, causing some problems like the difficulty of maintenance.

To tackle the aforementioned problems, we propose to deal with personalization as an orthogonal concern (i.e. as a separate aspect of the website), independent of the underlying technology allowing the definition of abstract personalization specifications which is a prerequisite for portability and reuse. Reuse in software engineering/programming is generally accepted and promoted to improve productiveness[11,12]. The proposed solution is based on a high level rule language called PRML (Personalization Rules Modeling Language) [13,14] that can be used by the designer to specify at design time the personalization to be performed at run-time. PRML is defined as an abstract personalization language, this is important for many reasons: it allows to specify personalization designs before the target platform is selected. This also avoids the ‘‘noise” that may be included in the platform-specific language enabling discussions of personalization designs by design teams, and allowing to take more clear decisions on personalization requirements. Moreover, it allows personalization designs to be 0950-5849/$ - see front matter!2010 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2010.04.001

* Corresponding author. Tel.: +34 965903772; fax: +34 965909326.

E-mail addresses:igarrigos@dlsi.ua.es(I. Garrigós),jgomez@dlsi.ua.es(J. Gomez),

g.j.p.m.houben@tudelft.nl(G.-J. Houben). 1 _{Tel.: +32 2 6293308; fax: +32 2 6293525.}

Contents lists available atScienceDirect

Information and Software Technology

exchanged across websites and between website design authori-ties. Adopting an abstract language may make it easier to work on standards for domain models for personalization in a specific application domain. An abstract model could be used for encoding personalization models that users could take with them between different websites. PRML is not yet another language for specifying personalization. One of the goals of this language is avoiding the problems due to the existence of too many notations for personal-ization. A possible scenario where this is an advantage is the reuse of personalization strategies by means of defining personalization patterns (e.g. a proven solution for a recurrent personalization requirement) that could be reused among different Web applica-tions or Web methodologies. To summarize, the benefits of the proposed approach are: unique notation, separation of concerns, which implies an easier maintenance and update, portability and reuse across different systems and methodologies.

This paper has two main objectives: on one hand, the paper aims to describe our experience in creating an abstract modelling lan-guage and presenting it, explaining how it can be used within a Web modelling approach. For this purpose, the syntax and seman-tics of PRML is described and illustrated by means of examples, as well as a set of guidelines for the designer. On the other hand, we want to formally show that the reusability of personalization strat-egies is possible. For this purpose, we have defined a set of transfor-mation rules from PRML to the specifics of two well known Web design methods: UWE[9]and Hera[7]. These transformations have been implemented in a prototype tool to show its feasibility. The objective is that the reader can clearly see the equivalence in expressiveness, modelling the personalization in PRML or in the UWE or Hera approaches, and that the same personalization rule ex-pressed in PRML can be transformed into the specifics of UWE and Hera (and thus reused). To wrap up, this paper extends previous work by defining PRML in an exhaustive way, providing guidelines to the designer and formally defining the transformations from PRML to other approaches. Moreover, it is important to note that previous studies did not take into account the UWE methodology.

We want to stress that this work has been done in the context of

the MDWEnet project [16] which goal is to improve current

practices and tools for the model-driven development of Web applications for better interoperability. The need of porting person-alization specifications is a recognized problem for designers[17]:

as an example we can mention the GRAPPLE project (http://

www.grapple-project.org) which concentrates on ways to share and exchange the adaptation among different systems.

The remainder of the paper is as follows: related work regarding Web engineering methodologies is presented in Section2. Section 3explains how personalization is modelled in the context of a Web design method by means of a running example. Furthermore, the requirements for the use of PRML within a Web modelling ap-proach are explained. Section 4 introduces the fundamentals of the PRML language. In Section5, transformation rules2_{from PRML} into the specifics of UWE and Hera methods are described. Further-more, in this section, examples of transformations for both method-ologies are put forward. Section 6 describes the prototype tool created for supporting our approach. Section7presents our conclu-sions and further work. Finally, in theAppendix Aof the paper, the BNF3_{grammar of the PRML language is shown.}

2. Related work

Personalization is defined by means of conditions, filters or adaptation rules over the different design concepts. Due to the

different notations for the modelling concepts the Web approaches use, as far as the authors are concerned, in the existing Web design methodologies found in the literature personalization specifica-tions are tightened to the specifics of the underlying methodology. Moreover, in some cases, the personalization embedded in the de-sign process, causing maintenance and reusability problems.

For describing personalization, OOHDM[10,18]uses a proprie-tary notation with an underlying design framework. The OOHDM notation uses a small set of primitives for specifying personalized attributes and methods referring the OOHDM modelling concepts. To model relevant information about the user, OOHDM adapts the user class in the conceptual model. Attributes of the user class can subsequently be used in the navigation class model to adjust the information that is shown to the user.

In WSDM [4,19], in the context of audience-driven design, a WSDM-specific rule language (Adaptation Specification Language, ASL) is provided to help the designer defining adaptive behaviour, focusing on the adaptation for a group of users by adapting the structure and the navigation possibilities in the website. ASL rules are defined to act on the WSDM design models. Note that person-alization is not supported, i.e. adaptivity for a single user, but the aim is to provide adaptivity forall users; that is also called optimi-zation. However, although personalization is not explicitly sup-ported, it would only require some modification to include a user model in an exactly similar way as the existing website overlay model. Subsequently, allowing ASL to access this user model yields personalization support. In the context of this paper, ASL is thus as relevant as any other adaptation specification mechanism which is aimed at personalization.

In UWA[8], in the context of ubiquitous computing, customiza-tion rules allow the designer to specify the adaptacustomiza-tion to perform when a certain context is detected. These rules are specified within a UML annotation, using the stereotype <<CustomizationRule>>. The specification of such a rule comprises a unique name, a refer-ence to one or more requirements, and an ECA triplet. The annota-tion is attached to those models’ elements being subject to customization.

WebML[5]also uses a proprietary notation. Personalization is specified by means of ECA rules which refer to the WebML concep-tual models, in which the event consists of a page request; the con-dition for rule activation consists of the evaluation of context parameters previously acquired and the action consists of adapta-tions of the hypertext front-end. In addition, WebML has been ex-tended by enriching the different models for adaptivity support. At [20], the integration of WebML with a language for expressing ECA rules supported by an engine for rule execution known as Chimera-Exception Language has been described. Chimera-Web, a new version of Chimera-Exception addressing Web events and Web adaptivity actions, is used to specifysparseadaptivity rules, whose execution is completely detached from the execution of the appli-cation itself and whose effects are not necessarily bound to in-stances of modeling constructs. Such integration leads to a framework that keeps the advantages of conceptual modeling and automatic code generation. Authors claim that the resulting architecture enhances separation of concerns, and supports flexi-bility and evolvaflexi-bility. However, this integration has not been completed, as they are still working on implementing some mod-ules the integration is based on, namely the Web Action Enactor and the Web Event Dispatcher[20]. To the best of our knowledge the Chimera-Web language allows separation of concerns, how-ever for being able to use it within a modelling method a process of integration is needed, which is not needed if using PRML. This is due because the Chimera-Web language is thought of being gen-eric but is built taking into account the WebML approach only. To define PRML however, we have investigated some of the most rep-resentative Web modelling methods[5–10]. We could use PRML in 2 _{These transformations are defined in an unidirectional way.}

the studied approaches, however we could also defining transfor-mations rules (in the same way as done in this paper with Hera and UWE) to formally show it is possible.

Problems arise when personalization strategies are specifically defined for concrete application environments: reusability among different approaches of the personalization strategies becomes al-most impossible. As explained in Section1, defining an abstract specification of personalization is a prerequisite for portability. The studied approaches do not fulfill this requirement, the person-alization specifications they define are specifically created for the concrete approach. This has some disadvantages like the depen-dency of the personalization specifications on the target platform and that the personalization specifications cannot be exchanged among different systems. Moreover, for being able to specify a per-sonalization specification that is portable between two approaches the set of adaptivity actions, the way of specifying conditions and the possible events to trigger personalization should be equivalent. In addition to this, the designer would have a high learning curve having to learn how to specify personalization in each proprietary solution. As motivated in Section1, PRML’s main goal is to solve these problems. PRML is a high-level language which is a Domain Specific Language (DSL)[21]so the rules defined with it are very intuitive and easy to learn. DSLs allow solutions to be expressed in the idiom and at the level of abstraction of the problem domain. Consequently, domain experts themselves can understand, vali-date, modify, and even develop DSL programs[22,23]. The designer using PRML to specify personalization strategies should be a domain expert (personalization expert). The learning curve of the

designeris reduced due to two reasons. The first one is that we shield the designer from the programming code and the second one is that the designer can define personalization using PRML and then transformations into the specifics of each methodology can be performed.

As aforementioned, the approaches selected to show the porta-bility of PRML are UWE[9,24]and Hera[7,25]. Note that the pre-sented approach is not limited to these methodologies, but we have used them in this paper as a proof of concept. As it will be ex-plained in Section3.4, to create PRML we have done a study for identifying a common denominator of a set of existing modelling languages and abstracting the core set of concepts. That is why PRML can also be applied to those studied methodologies. A reason for choosing these approaches is that are well-known by the authors of the paper. This is important to specify efficient transfor-mations. Another reason for choosing those approaches is that they are different enough to show the generality of the approach pre-sented. An overview of these approaches is presented next.

2.1. The UWE approach

The UWE (UML-based Web Engineering) method[9,24] is a

model-driven and object-oriented approach whose distinguishing feature is the fact that it complies with the Unified Modeling Lan-guage since UWE is defined in the form of a UML profile and an extension to the UML meta-model. UWE follows the principles of the Unified Software Development Process and supports the sys-tematic development of Web applications focusing on the specifi-cation of adaptive (personalized) applispecifi-cations. An extension of ArgoUML known as ArgoUWE gives support to the approach. UWE provides a reference model for adaptive hypermedia systems called Munich reference model, based on the Dexter reference model. The purpose of this model is to identify the main features of adaptive hypermedia and personalized Web applications, as a prior step to the definition of appropriate modeling techniques.

UWE stresses on personalization features, such as the definition of a user model and an adaptation model, or a set of adaptive nav-igation features, which depend on preferences, knowledge or tasks

that the user must execute. The static user model is represented as a class diagram, expressing the view that the system has of the user. It includes the user’s attributes, and their values, relevant to the adaptive application. These attributes can be domain depen-dent, in other words, they will have a value for each domain com-ponent or domain independent attributes. State transitions of the objects, that is an instantiation of the user model, can be expressed by rules of the adaptation model. The adaptation model consists of containers for user’s behaviour, a set of rules and a set of functions to perform the adaptation functionality. A rule is modeled as a class rule that consists of one condition, one action and attributes. Rules are expressed as OCL expressions in the context of the exec-utor method of the rule. The OCL metamodel for expressions can be consulted in[26]. Examples of instantiations of this metamodel will be shown at the end of Section5.1.

2.2. The Hera approach

The Hera methodology[7,25]is a model-driven approach for designing and developing Web Information Systems (WISs). From the gathering of requirements to the maintenance of the opera-tional application, most information system design methodologies distinguish several phases in the design process. Hera’s target is to facilitate the automatic execution of the design. Hera uses several models to capture the different design aspects. Due to the fact that these models are considered Web metadata descriptions that spec-ify different aspects of a WIS, authors chose to use the Web meta-data language, i.e. RDF(S)[27], to represent all models and their instances.

Hera supports two types of adaptation: static based on the user’s profile data, that is stored in the user/platform profile model (UP), which stores the static (i.e. fixed at design time) user prefer-ences and platform capabilities. Dynamic based on the user/plat-form model (UM) inuser/plat-formation. In this model, the dynamic user’s preferences and platform capabilities are captured. The user model changes during user browsing. At this layer, there is another model called adaptation model, to specify how adaptation is carried out by using the data coming from UP or UM. This is performed by using inclusion conditions attached to model elements. Conditions based on UP attributes define the so-called adaptability – presen-tation is fixed before user browsing – while conditions based on UM model define the so-called adaptivity – presentation changes during user browsing – of the system. These appearance conditions over the different model elements are expressed using an

exten-sion of the SeRQL [28] query language implemented by the

HPG-Java engine. This engine is a Java servlet that, based on Hera models, generates pages on demand. InFig. 1, an excerpt of the Hera metamodel for supporting adaptivity is shown. It is extended with the SeRQL syntax needed to specify the appearance condi-tions and queries on the different elements of the application

mod-el. Section 5 will refer to this metamodel to define the

transformations between PRML and SeRQL and examples of instan-tiations of this metamodel will be shown at the end of Section5.1. In the next section, we will explain how to add personalization using PRML to a Web design method. A case study will be pre-sented and modeled in the context of UWE and Hera methodologies.

3. Personalization modeling in web design methods

Typically, Web design methods define three main models when designing a Web application: a domain model, in which the struc-ture of the domain data is defined, a navigation model,4_{in which}

the structure and behaviour of the navigation view over the domain data is defined, and finally the presentation model, in which the lay-out of the generated hypermedia presentation is defined. In general, to be able to model personalization at design time two new models are added to the above set of models:

(1) A personalization model, in which personalization policies are specified. Together with the personalization of the con-tent, navigation structure and presentation, the personaliza-tion model also defines updates of the user informapersonaliza-tion specified in the user model (described next).

(2) A user model, in which the structure of information needed for personalization is described. Typically, information cap-tures beliefs and knowledge that the system has about the user and it is a foundation for personalization actions described in the personalization model.

In the following sections, we will define the different models of the typical Web application design phases for the UWE and Hera approaches (except for the presentation model because personali-zation of the presentation is outside the scope of this work). For illustration purposes, the case study modeled in this paper is an online book store. In this system, the user browses through a list of books and can order selected books. Later, in Section5, we will describe how personalization strategies can be applied to appropri-ate models of both methods using the same set of PRML rules.

3.1. Domain model

The domain model (DM) specifies the structure of the Web application domain data. The upper part ofFig. 2shows the UWE DM for the running example. In UWE, the DM is defined as a UML-compliant class diagram. Concepts are represented by classes with attributes and operations. There are associations between them representing concepts relationships. In our case study, all books can have an associated review. We store the name of a book, a summary of it, the price and the name of the author(s). Moreover, there is the possibility of buying the book (specified in the UWE DM by theBuy()method).

The Hera DM for the same example is depicted in the upper part ofFig. 3. As aforementioned, in Hera, all models are expressed in RDFS[27]. Rounded rectangles represent concepts and rectangles represent literal attributes. Concepts also have concepts relation-ships represented by arrows between concepts. We store the same information as in the UWE DM. The Hera DM does not specify operations; the application logic (i.e. theBuy()method) is directly specified in the navigation model.

3.2. Navigation model

The navigation model (NM) describes a navigation view on the data specified by the DM. A generic NM is composed of nodes and links. Nodes are restricted views of domain concepts or can contain static nodes including information independent of the domain.

UWE NM is composed of navigational classes, which represent views5_{of the classes of the DM (the above-defined nodes) and their} relationships (i.e. links). In the Hera NM (seeFig. 5) slice shapes rep-resent navigation nodes. These nodes are based on DM or UM con-cepts that are called root concon-cepts, represented by ovals attached to the slice shapes. Overlaying areas of slices and ovals contain attri-butes of the root concept. Attriattri-butes of related concepts are located in the slice areas not overlapping with the ovals. In Hera, arrows rep-resent links that have attributes as anchors and slices as targets. There are also three types of links: navigational links, constant links 4 _{In Hera, this model is called application model.} 5_{Views contain partial information of the class}

that do not carry information about slice instances but only navigate to different slices, and can serve as menu items, and links associated with submitting forms. For a more extensive description of UWE and Hera NM we refer the reader to[9,7], respectively.

Figs. 4 and 5show the NM for UWE and Hera respectively. We can see that both models have the same expressiveness. In both cases, the final website will have the home page where we can find a collection of links (i.e. menu) with the linksConsult Booksand

Recommendationsas a starting point. If the user navigates through the first link (Consult Books) he/she will find a list of all the books in a new page; in the UWE model it is represented by the navigation classBookand in the Hera model represented by theBookslice. This set of books is an indexed list, so the user can click on one of the books’ names to view the details of a chosen book (theBookDetails

class in UWE and theBookDetailsslice in Hera). When the user clicks onRecommendations, personalized book suggestions should appear (based on the information from the user model). The

‘‘Rec-ommendations” page is represented in UWE by the Recommenda-tions class, and as theRecommendationsslice in Hera. To fulfill a personalization requirement and, in this case, show recommenda-tions of books to the users based on their interest in authors, as ex-plained, we need to add the user and personalization models to the set of models. They are described along the next sections.

3.3. User and personalization models

3.3.1. Adding the user model

To store the updatable information about the user needed for fulfilling the personalization requirements, the user model is de-fined. The user model data should be defined based on the person-alization requirements that we want to support in a concrete application. Typically these data (i.e. personalization data) is in some way related to the domain data. It is composed by descrip-tions that are considered relevant about the knowledge and user’s Fig. 2.DM-UM for UWE.

aptitudes, providing information for the environment of the sys-tem for being adapted to the individual user. It can also contain do-main independent traditional characteristics (like age and language) but also information related to the browsing behaviour of the user, as well as session information and information about the context in which the user is using the site. It also can contain user data referring to the domain (for example, information on the user’s knowledge of topics occurring in the website).

We can provide some guidelines for modelling the user and do-main models:

!In the domain model we define data structures of the informa-tion referring to the domain (not user-specific).

!Depending on the personalization requirements, we build the personalization model with the classes needed to store the required information to base the personalization on.

!The information type we store in the user model can be user characteristics, preferences, user requirements, context of the user or user browsing behaviour.

!If some information is related to a concept of the domain model (e.g. user interest in one author) we add a relationship to it, since both models can be connected.

!If there are several roles for the user, possibly with overlap of some information, then we can create a generalization in the user model from one specific class (i.e. user role) to the User class. For more detailed information about the modelling of a person-alized website we can refer the reader to[29].

As explained, the information to store in the user model de-pends on the personalization requirements defined to be fulfilled in the website. The personalization requirements specified for the running example are the following:

1. Users that have bought more than a minimum number of books will be offered a discount in all books’ prices.

In this case, to fulfill this requirement (and offer the price dis-count to the user) the number of books bought should be stored in the UM.

Fig. 4.UWE navigation model.

2. Users will see recommendations of books of authors that they are interested in.

This requirement states that users will be offered a set of rec-ommended books, based on the user’s interest. For fulfilling this requirement we need to acquire and update the user’s interest in the different authors.

3. If the user does not have enough interest in any book’s author to obtain personalized recommendations, the link called recommen-dations is not shown.

For fulfilling this requirement we can check the interest in the different authors, stored in the UM to fulfill the previous per-sonalization requirement.

We can see the UM for the UWE and Hera methods in Fig. 2 (lower part) andFig. 3(lower part), respectively. While a UM is conceptually a separate model, it is used in a similar way as a DM and is typically associated with the DM. The UWE UM is fined as a UML-compliant class diagram and the Hera UM is de-fined using RDFS [27]. UML classes in UWE are equivalent to RDFS concepts in Hera. Associations defined between classes in UML are defined in RDFS as properties between concepts. A single attribute specified in a UML class is defined as a literal in RDFS.

In the updatable data space defined by the UM, specified using both methods here, information describing the user’s interests in authors is stored, according to the defined personalization require-ment. In the UM, we also have theNodeVisitingclass/concept. This class/concept stores the number of clicks on different links; in our example we store the clicks performed on the linkBuyin the attri-butebuyClicks.Then, we will use this information to fulfill the first personalization requirement of the running example. Note that to store the number of clicks on any other link we would just have to add a new attribute to theNodeVisitingclass/concept.

3.3.2. Adding the personalization model

The personalization model (PM) we define it is based on event– condition–action rules. In this model, the personalization actions to be performed are specified.

For satisfying a personalization requirement we often have to define how to update the knowledge about user (acquisition rule). This information is stored in the UM data space. Furthermore, we have to define the effects that this personalization causes to the presented content and navigation structure (personalization rules). These rules use the information specified by the UM to describe adaptation actions. Depending on the object of the adaptation, two kinds of personalization rules are considered: navigation per-sonalization rules (to alter navigation), and content personaliza-tion rules (to add/remove/adapt content). These types of rules are such because in this work we consider the personalization of the content and the navigation of the website. As already men-tioned, the personalization of the presentation is out of the scope of this work.

As previously stated, the rules of the PM are defined using the PRML language. It is based on a MOF[30]metamodel (seeFig. 6) which defines the set of constructs of the language such as the dif-ferent parts that form a PRML rule and the difdif-ferent events and the actions supported. The main element of the metamodel is the rule metaclass which represents the concept of rule containing the ele-ments that define it. The eleele-ments defining a rule are those that represent its main structure and are explained in this paper. The basic structure of a rule defined with PRML is the following:

When event do

[Foreach expression]

If condition then action endIf [endForeach]

endWhen

A PRML rule is formed by an event and the body, which contains a condition (optional) and an action to be performed. Theevent

part of the rule states when the rule should be triggered. Once trig-gered the rule, theconditionis evaluated (if any) and if it is evalu-ated positively, then theactionis performed. AForeach expression

can also be present in the rule when the action and the condition act on a set of instances.

As it has been shown, UWE and Hera use different modeling languages to define a Web application. Despite the differences, the conceptual (domain and navigational) models of both method-ologies have the same expressiveness as we can see in the previous examples. This is important in order to use the same personaliza-tion model, specified with PRML, in both approaches. To see if the expressiveness of the Web methodology is sufficient for the use of PRML and therefore if the portability and reuse of personal-ization strategies is possible, we define some requirements that need to be fulfilled, they are explained in the next section.

3.4. Requirements for the use of PRML

To properly define a method-independent language, the first step is to identify a common denominator of a set of existing mod-eling languages and abstracting the core set of concepts. Different Web design methods supporting personalization were studied. The approaches considered for this study were WebML[5], OOHDM [10], UWE[9], Hera[7]and WSDM[4]. This set of approaches is representative enough to show the generality of PRML. All of them have personalization support except for WSDM, which currently supports adaptation for all the users of the website but could be easily extended to model personalization. After this study, some essential requirements to be able to accommodate PRML personal-ization specification were defined:

R1:A domain model (DM) should be a part of a Web application specification. The data structure of the website should have a way of being specified.

R1.1: The DM should be composed of concepts, attributes

and concepts relationships.

R2:A navigation model (NM) should be a part of a Web applica-tion specificaapplica-tion. There should be a mechanism for access-ing the data content of the navigation objects.

R2.1: The NM should have nodes and links as main

compo-nents. Nodes are restricted views of domain concepts but can also be static nodes with no concept associ-ated. Each node can be associated to a concept from the DM or the UM. Nodes contain the attributes and operations that are going to be shown in the navigation.

Requirements R1 and R2 ensure that the target of the personal-ization rules exists and its data content can be properly referenced by condition and action parts of the rules. Domain and navigation specification are typically present in Web modeling approaches.

R3:A user model (UM) should be a part of an application speci-fication. An alternative can be a specification of updatable (temporary) data space. There should be a mechanism for accessing the data content of user model objects. Require-ment R3 ensures that the target of the acquisition (data updating) rules exists and can be properly referenced. All modern methods also support some personalization or at least allow association of user actions with data updates.

R3.1: Analogous to the DM, the UM should also be

composed of concepts, attributes and concepts relationships.

R4:Within the NM and UM, it should be possible to use events to trigger personalization, and conditions to execute the spe-cific personalization policy. Requirement R4 ensures that personalization can be triggered by events supported by the different methodologies. The personalization actions will be executed depending on the condition evaluation. R5:Besides the previous requirements, it should be possible to

define actions over the elements of the models.

Requirement R5 ensures that PRML actions have their counter-parts in possible actions that can be specified using different methods.

Once having abstracted the models and concepts over which PRML has to operate, some aspects have to be defined to develop a common rule language on top of these abstract concepts:

"Timing of the adaptation: when to personalize?The events

sup-ported in PRML to trigger the rules should be defined. "Conditions. The manner to refer to the concepts of the different

models as well as the comparison operators supported in PRML conditions need to be specified.

"Operations over concepts. Finally, the operations allowed in

PRML over the different concepts need to be described. The development of the rule language regarding these issues will be presented in next section. In further sections we will ex-plain how a PRML personalization specification can be mapped to UWE and Hera methods.

4. PRML fundamentals

4.1. Timing of the adaptation

To specify when an adaptation (personalization) action should be performed, PRML allows specifyinguser browsing events. PRML includes browsing events relevant for a website including its browsing sessions. We argue that the majority of mature Web systems and design methods distinguish the following browsing events:link navigation, node loading, starting a browsing session, and ending a browsing session. Browsing events are implicitly associated with the user clicks and may trigger the activation of one or more rules. PRML considers the following user brows-ing events:

"Navigation event:caused by the activation of a link of the NM. "LoadElement event:it is caused by the instantiation of a node of

the NM. The difference between this event and the previous one is that theLoadElementevent is triggered independently of the link that loads the node. This is useful when a set of links have the same target node and we want to personalize during the activation of any of those links.

"Start event:triggered with the start of the browsing session by a user.

"End event:triggered when the browsing session expires after

certain inactivity of the user in the system, or when the user explicitly finishes the session.

The way the events are captured depends on the implementa-tion done. We have implemented a prototype tool for testing the PRML execution[14]in which the events’ gathering is not tightly integrated with the Web application. Next, the specification of these events in PRML rules is explained.

In PRML, in the case of user browsing events which imply nav-igation of the user within the website (i.e.Navigationand

LoadEle-ment events) information about navigation is passed as a

parameter. As aforementioned, nodes are restricted views over the DM or UM concepts. The parameter contains information about which instances of concepts of the DM/UM are to be shown in the activated node. The instances to be shown in the nodes are adapted to each user (i.e. personalized) by means of PRML rules. Two differ-ent types of parameters are possible:

!Simple parameter:This parameter refers to an instance of a con-cept of the DM/UM. The event passes a simple parameter when

in the target node an instance (always one) of a concept of the DM/UM is shown.

!Complex parameter:This parameter refers to a set of instances (one or more instances) of a concept of the DM/UM.

Every time the user activates a link (activeLink) a node is acti-vated (activeNode) and the associated event is launched, which may trigger one or more rules. The parameter is the instance or set of instances from the root concept of the DM/UM ( activeCon-cept) to be shown in the activeNode. The distinction into simple and complex parameters is carried out to improve the readability and maintenance of the rules for the designer. In other words, if a complex parameter is transferred then a loop will be needed to go over the set of instances.

In the case of the running example, for specifying that an event should be triggered when the user clicks on theViewDetailslink in PRML, we express it as:

When Navigation.ViewDetails(NM.Book book) do This event transfers a simple parameter (an instance of the book visited). An example of transferring a complex parameter is shown below:

When Navigation.Recommendations(NM.Book* books) do When the user clicks onRecommendations, a set of books (zero or more) will appear (with no adaptation action applied). An appropriate PRML rule will adapt the set of books for a particular user (explained in Section4.3.3).

The browsing session events (i.e.StartandEndevents) do not transfer any parameter. Their PRML representation is very simple:

When SessionStart do When SessionEnd do

The BNF specification for the PRML events can be found in the Appendix Aof this paper.

4.2. Conditions in PRML rules

PRML offers a high degree of freedom in defining conditions, while it is still simple and minimal enough to be used in multiple methodologies. When specifying conditions two aspects have to be decided: (i) how to refer to the different elements of the models defined in the website; (ii) how to specify conditions over these elements.

When specifying conditions, PRML rules can refer to different elements of the models defined for the website. As already ex-plained, personalization is based on the user’s data stored in the UM. This information can be updated and consulted (specifying conditions over those data to base the personalization on). For updating this information adequate actions are defined (see Sec-tion4.3). Nevertheless, a mechanism to access the UM structures is needed. Besides, a PRML rule can also refer to information from the DM and from the NM for specifying some needed conditions to define adaptation actions. To indicate the access to data of a partic-ular model the prefixes ‘‘DM”, ‘‘UM” or ‘‘NM” are added in PRML rules to the expressions referring to the particular information. In the case of accessing information defined in the UM, the source concept is always ‘‘User”, to identify the user that is actually browsing the website.

To access a certain element of a model, PRMLnavigatesover the model using path expressions (PE). The PEs are based on the path expressions defined in OCL[26]. As an example for a PE, consider that we want to access the interest degree of the user in the

differ-ent authors stored in the UM (the UWE and Hera UM are shown in Figs. 2 and 3, respectively). For building the PE the following steps are to be taken:

!As already mentioned, the PE starts with a prefix indicating the model that is beingnavigated.

" E.gUM

!After that, it follows a dot and then the source concept which the expression departs from.

" E.g.UM.User

!For traversing the concepts, the target roles of the concepts rela-tionships are added to the PE (with dots).

" E.g.UM.User.userToInterest

!It finishes with either a concept or an attribute of a concept.

" E.g.UM.User.userToInterest.degree

When accessing information defined in the NM instead of con-cepts PEs refer to nodes, and instead of concon-cepts relationships PEs refer to links. The BNF specification for a PE is described in Appen-dix Aof this paper. The following operators and structures may ap-pear in a PRML condition:

!Relational operators (> , <, >=, <=, =, !=) !Arithmetic operators (+,#, /, *) !Logical operators (and/or) !Negation (not)

!ForAll Conditions

If ForAll (UM.User.usertoInterest)

(UM.User.usertoInterest.degree=null or UM.User. usertoInterest.degree<100) then

The ForAll condition is a special kind of condition: it is checked for all instances of the specified concept. This can be useful when we need to evaluate the condition for a set of instances but we want to perform the action only once (i.e. when the condition holds for all instances).

4.3. Operations supported

PRML contains a set of constructs to model the personalization of a website manipulating the UM and NM. These constructs represent personalization actions over the different elements of those models (note that the elements of the different models were explained in Section3.4). As aforementioned, actions supported by PRML have been abstracted from a selection of well-known modeling proaches. The adaptation actions supported by the studied ap-proaches include the user data manipulation. All apap-proaches allow filtering the content to show and most of them (UWE, Hera and OOHDM) allow filtering the links as well. InTable 1, we can see which actions are supported by each of the studied methodologies. After this study we can conclude that PRML should contain the following set of operations over the UM and NM elements:

!Actions over attributes (UM and NM):

1. Updating an attribute value from the UM (setContent):This action allows modifying/setting the value of an attribute of a concept of the UM.

2. Filtering attributes in the NM nodes (selectAttribute):By means of this action a node can be restricted by hiding or showing some of the attributes of the DM/UM related concept.

!Actions over nodes (NM):

3. Filtering node instances (selectInstance):This action allows us to show only the selected instances of a DM/UM concept for a user depending on the personalization requirements that we are aimed to support.

!Actions over links (NM):

4. Hiding links and their target nodes (hideLink):Analogous to filtering data content, PRML also supports filtering links. However, some adaptive operations not supported by most of the studied methodologies (and thus not supported by PRML) are also interesting for personalization actions. Some of these actions are defined in a more complete version of PRML limiting though the reusability (PRML Full). As we have already explained, in this paper we will focus on the common actions, elaborating them by means of the presented running example.

4.3.1. Updating a value (setContent)

This action changes the value of an UM attribute. Consider the scenario presented in the running example in Section3of an online book store. The acquisition of the information that needs to be stored in the UM is carried out by means of acquisition rules which perform thesetContentaction.

!To fulfill the 1st requirement described in Section 3.3.1, the number of books bought by a user has to be stored in the UM. The following rule updates the number of books bought when the user clicks on theBuylink.

When Navigation.Buy (NM.Book b) do setContent

(UM.User.userToNodeVisiting.buyClicks, UM.User.userToNodeVisiting.buyClicks + 1) endWhen

This rule is triggered by aNavigation eventwhen the user acti-vates the linkBuy. It updates the number of books bought when the user clicks on the Buylink (updating the attribute buyClicks

of theNodeVisitingconcept of the UM) using thePRML setContent action.

!To cope with the 2nd requirement the user’s interest in the authors of the books has to be gathered. In this example, the interest of the user is defined in the following way: the user is interested in an author when he consults a book of him/her. When Navigation.ViewDetails (NM.Book book) do Foreach a, b in (UM.User.userToInterest, book. bookToAuthor)

If(b.ID = a.interestToAuthor.ID) then setContent (a.degree,a.degree + 10) endIf

endForeach endWhen

This rule is triggered by aNavigation eventwhen the user acti-vates the link ViewDetails. It updates the interest of the user in the author of the visited book (by updating the attribute Inter-est.degreeof the UM).

Theforeach expressionof the rule is needed to go over each of the instances of the Interest concept (referenced by the Path ExpressionUM.User.userToInterest) in the UM (seeFigs. 2 and 3) in order to check the proper instance to update. Theforeach expres-sionalso goes over the set of authors of the consulted book. If the instance of the author checked in the UM is the same as one of the authors of the book the user is consulting when clicking the View-Detailslink then we will update the interest degree in that author in the UM, using thePRML setContent action.

4.3.2. Filtering attributes in the NM nodes (selectAttribute)

To illustrate the selectAttribute action of PRML, we consider the 1st_{personalization requirement: When the user clicks on the}

View-Details link to consult a specific book, if the number of books bought is greater than 10, we will show an attribute ‘‘discount” to the user (note that this attribute was not previously selected to be shown in the navigation model but is present in the domain model).

When Navigation.ViewDetails(NM.Book book) do If UM.User.userToNodeVisiting.buyClicks>10 then book.Attributes.selectAttribute(discount) endIf

endWhen

In this rule from the set of attributes of a book, the attribute of-fer is selected. The rule is triggered by aNavigation event, result of clicking on theViewDetailslink. Events pass a parameter with the information of the node to be shown, in this case the concrete book of which we are going to see the details. If the number of clicks on theBuylink (stored in the user model with a rule explained in Sec-tion4.3.1) is greater than 10, we will select the attributediscount

from the book concept to be shown using thePRML selectAttrib-ute action.

4.3.3. Filtering node instances (selectInstance)

Let’s consider now the 2ndrequirement of the case study in which recommended books based on the interest of the user are shown. The interest of the user needs to be stored in the UM with an acquisition rule taking into account the user’s browsing behav-iour (this rule has been explained in Section4.3.1). The personali-zation rule that displays the book names if the user has an interest degree in the book author greater than 100 is as follows:

When Navigation.Recommendations(NM.Book* books) do Foreach b,a in (books,UM.User.usertoInterest. interestToAuthor) do

If (UM.User.userToInterest.degree>100) and a.ID = b.booksToAuthor.ID) then

books?selectInstance (b) endIf

endForeach endWhen

The rule is triggered by aNavigation event, which is the result of clicking on theRecommendationslink. As aforementioned, naviga-tion events pass a parameter with the informanaviga-tion of the node to be shown, in this case the set of all the books which is filtered to only show the recommended books.

In this example aforeach expressionis needed to go over all in-stances of the set of books passed as an event parameter, and the Table 1

Actions supported by the different methodologies.

Action/methodology UWE Hera WebML OOHDM WSDM 1. Updating UM content Yes Yes Yes Yes No 2. Filtering content (concept

attributes)

Yes Yes No No Yes

3. Filtering content (concept instances)

Yes Yes Yes Yes Yes

4. Link hiding Yes Yes No Yes Yes

5. Sorting content No No No No No

6. Sorting links Yes No No No No

7. Adding/deleting links No No/ No

Yes/Yes No Yes 8. Adding/deleting concepts No No Yes/Yes No No 9. Dynamically grouping users No No No No No

loop also goes over all instances of the author concept. If the user has an interest degree greater than 100 related to the instance of the author we are checking, then the book instance checked is se-lected to be shown using thePRML selectInstance action.

4.3.4. Link hiding

To illustrate thehideLinkaction of PRML, we consider the 3rd personalization requirement: if the user interest degree in the dif-ferent authors is not initialized (this means that the user has not consulted the details of any book yet, maybe because it is the first time the user goes into the website) theRecommendationslink is not shown. Note that there is only oneRecommendationslink in the website for each user.

When SessionStart do

If ForAll (UM.User.usertoInterest)

(UM.User.usertoInterest.degree = null or UM. User.usertoInterest.degree<100) then

hideLink(NM.Recommendations) endIf

endWhen

The rule is triggered by aSessionStart event, when the user en-ters the website. In this case, our purpose is to check a condition over a set of instances of a concept, as well as to perform an action (hide the link) only if the condition is true for all the evaluated in-stances. For this purpose theForallstatement is added to the con-dition stating the collection over which the concon-dition should be true. This condition checks if the interest degree of the user in the different authors has any value. If it has no value, it means that theRecommendationslink should not be shown, so it is hidden by using thePRML hideLink action.

For clarity reasons the rules specified in this paper have been simplified by omitting some rule features (e.g. rule name, priority, activation and expiration dates, etc.). When specifying a PRML rule we can state a set of rule features like the activation date on which the rule is first triggered, the expiration date on which the rule be-comes inactive (and thus not anymore triggered), the name and the type of the rule and thepriorityover other rules. An example of such features specification is:

Rule: suggestions type: Pers-Content priority: high activation: 22-10-2005 expiration: 22-10-2006

This rule is called ‘‘suggestions”, the type of the rule is Person-alization-Content. It has an activation date (22-10-2005) on which the user is triggered for the first time, and an expiration date (22-10-2006) on which the rule becomes inactive and thus not trig-gered anymore. The order of execution for rules sharing the same triggering event is unspecified unless it is enforced using priority. This rule has ahighpriority which means that will be executed ear-lier than rules havingmedium andlowpriority. Next section ex-plains how to specify the execution order of the different rules.

4.4. Execution order

When a set of rules are triggered by the same event and they become active (i.e. their condition evaluation is true), all the active rules are collected in a queue (stack) and executed sequentially. Parallel execution would require a conflict resolution mechanism in case of several active rules performing conflicting actions. The execution of a rule may activate or deactivate other rules, so other active rules in the queue may become inactive before they are se-lectedfor execution. A different execution order of the rules in the queue can affect the final state (those rules will have execution or-der-dependence). For the same user the system should provide the same result, and thus the same final state, which is called

conflu-ence. To decide the execution order of the active rules a priority parameter is defined, however if the order-dependent set of rules is greater than 3 (there are only three priority values:high, medium, low) we need another mechanism for assuring theconfluence. Usu-ally the order of execution by the rule engine is unspecified and de-pends on the specific rule engine used, but some constraints are defined:

!Acquisition ruleshave always higher priority thanpersonalization rules. When an acquisition rule and a personalization rule are triggered on the same event we want to update the information acquired before applying the personalization. In this way we assure the information used to base the personalization on is always updated.

!Personalization rulestriggered by the same event affecting the same element should be defined taking into account that: " Filtering attributes has higher priority than filtering instances.

" The order of execution of two rules with the same action

type (over the same element) should be specified by means of the priority feature.

!Multiple acquisition rules sharing the same event should be avoided. The reason is that when unsynchronized data updates take place can lead to possible data inconsistency.

These constraints are not automatically checked, they are con-sidered as guidelines for the designer. Therefore it is the task of the designer to take them into account when defining a set of rules for fulfilling a personalization strategy. If these guidelines are not taken into account we cannot assure the confluence and the inex-istence of conflicts among rules.

4.5. Methodology for the use of PRML

In this section we explain the steps a designer should follow for the use of PRML. First of all, if a designer wants to use PRML for specifying personalization strategies in a website, he should check the requirements specified for the use of PRML (explained in Sec-tion3.4). Then, if the Web methodology used in the website fulfils the specified requirements the designer has to follow the next steps:

1. Define the personalization requirements to support in the website.

2. Define the conceptual models of the website (domain, naviga-tion, presentation).

3. Define a user model where the information needed to personal-ize is stored.

4. Define acquisition rules to gather and update the information stored in the user model.

! With similar personalization requirements we can reuse the acquisition rules defined for previous websites.

5. Define personalization rules to specify the personalization actions defined in the personalization requirements.

! If we have some personalization rule which define some strategy to cope with one or more of the defined personali-zation requirements, we can reuse it here.

6. Deploy and activate the rules.

7. Once at runtime, we can modify the personalization strategies if needed without regenerating the rest of the application. Fig. 7shows an overview of the approach presented. The web-site is specified by a set of design models of a concrete Web methodology. The personalization model is specified by the per-sonalization designer (or reused from a perper-sonalization repository) by using PRML. This specification can be directly used or trans-formed to the specifics of the target Web methodology after the

design of the system. The reader should note that in the first case, the target approach needs a rule engine which supports PRML. We have developed such an engine in order to test the PRML language [15].6_{An overview of this implementation is explained in the last} paragraph of Section6.

So far, we have presented the PRML language. From now on, we will present how the transformations from PRML into UWE and Hera approaches are possible. The aim of the transformations is that of showing the portability of the PRML approach, and thus the reus-ability of a PRML specification among different methodologies. 5. Transformations from PRML into the specifics of the UWE and Hera methods

In this section, we will describe the transformations from PRML into the specifics of UWE and Hera methodologies For this purpose, we will use the MOF 2.0 Query/View/Transformation language (QVT)[31]which is a standard approach proposed by OMG. Fur-thermore, QVT is an essential part of the MDA (Model Driven Architecture) standard as a means of defining formal and auto-matic transformations between models. Defining transformations by specifying QVT relations has several advantages: (i) transforma-tions are formally established, easy to understand, reuse and main-tain, (ii) they do not have to be manually performed by an expert, which is a tedious and time-consuming task. On the contrary, using QVT allows defining transformations at the metamodel level, allowing the designer to use them in each project, and (iii) rela-tions can be easily integrated into an MDA approach.

QVT consists of two parts: declarative and imperative. The declarative part provides mechanisms to define relations that must hold between the model elements of a set of candidate models (source and target models). This declarative part can be split into two layers according to the level of abstraction: the relational layer that provides graphical and textual notation for a declarative spec-ification of relations, and the core layer that provides a simpler, but verbose, way of defining relations. The imperative part defines

operational mappings that extend the declarative part with imper-ative implementations when it is difficult to provide a purely declarative specification of a relation.

In this paper, we focus on the relational layer of QVT. This layer supports the specification of relationships that must hold between models by means of a relations language. A relation is defined by the following elements:

!Two or more domains:each domain is a set of elements related

to a source or a target model. The kind of relation between domains must be specified: checkonly (C), i.e., it is only checked if the relation holds or not; and enforced (E), i.e., the target model can be modified to satisfy the relation.

!When clause:it specifies the conditions under which the

rela-tion needs to hold (i.e. precondirela-tion).

!Where clause: it specifies the conditions that must be satisfied

by all model elements participating in the relation (i.e. postcondition).

The following sections will explain the QVT relations defined for the transformation of a PRML specification to the specifics of UWE and Hera methodologies. Transformations are defined in a unidirec-tional way from PRML to concrete languages. These transformations are done to formally show the equivalence of the expressiveness in PRML and the target approaches. In this process, no information is lost because all the specifications that can be done with PRML can also be specified in the target languages. This is assured by the way PRML constructs are built.

5.1. QVT relations: transformations from PRML to UWE and Hera

In the case of UWE, a PRML rule is transformed into an OCL expression that represents the same personalization rule for the UWE approach. Therefore, the output of a QVT transformation from PRML to UWE is an OCL expression based on the abstract syntax defined in the specification[26].

In the case of Hera, a PRML rule is transformed into a set of SeR-QL queries attached to an element of the Hera NM (a slice, link or Fig. 7.Approach overview.

attribute) representing the same personalization rule for the Hera approach. These queries allow data manipulations and some of them are conditions determining the set of instances of concepts, links or attributes to be displayed. The mentioned queries are based on an extension to the SeRQL query language and thus con-tain path expressions and conditions.

It is quite straightforward to obtain a model from PRML and OCL expressions and from PRML and SeRQL expressions, useful for applying the QVT transformations. Therefore, in this paper we fo-cus on presenting PRML and UWE rules and Hera queries in textual

notation, although the QVT relations have been defined over their corresponding metamodels (PRML, OCL and SeRQL).

InFig. 8, we can see the sequence of transformations that are needed for the different types of PRML rules. This set of relations is applied according to the structure of a PRML rule (see Section 3.3.2): firstly, the PRMLRule relation is applied to drive the whole transformation. In this way, this rule decides about which the fol-lowing relation to be applied, according to the expression in the ‘‘where” clause, is. If the event isNavigation, then the PRMLNaviga-tionrelation is applied. ThePRMLNavigationrelation has to call the

PRMLActionrelation, since the main part of a PRML rule is the ac-tion to be performed. ThePRMLActionrelation deals with executing the right relation according to the kind of action. Then, if the action is SelectInstance, the PRMLSelectInstance relation is applied. This relation together withPRMLConditionand PRMLForEachrelations are used for creating the corresponding UWE or Hera personaliza-tion model from the PRML model.

As a proof of concept and due to space constraints we can only show in this paper a subset of these relations, which allow us to deal with a PRML rule triggered by aNavigation eventand the Selec-tInstanceaction.

5.1.1. PRMLRule

The first QVT relation states that a PRML rule is transformed into an UWE rule (Fig. 9a) and, in Hera NM, as a set of queries (Fig. 9b). The ‘‘where” clause checks the event type of the PRML rule, calling the appropriate QVT relation. Please, note that in this paper we only focus on the navigation event, so in the ‘‘where” clause only the PRMLNavigation relation is called.

5.1.2. PRMLNavigation

The PRML Navigation QVT relation states that a PRML Naviga-tion event is transformed into a user browsing event. In UWE Fig. 8.Sequence of transformations.

Fig. 10.(a) UWE PRMLNavigation relation; (b) Hera PRMLNavigation relation.

(Fig. 10a) this transformation is straightforward. For Hera, it states that a PRML Navigation event is transformed into aCondition query

applied over the node activated by the event and into a Session query (with a Result query attached) for storing the parameter of the PRML navigation event as a Hera session variable (Fig. 10b). The ‘‘where” clause contains a relation that extends the previous one (i.e. PRMLAction) and it is described below.

5.1.3. PRMLAction

The PRMLAction relation states that a PRML action is trans-formed into an OCL expression that represents the UWE rule (Fig. 11a). In Hera, a PRML action is transformed into anappearance Condition(query)(Fig. 11b). This relation checks the kind of action in order to call the adequate relation in the ‘‘where” clause. Note that we only focus on theSelectInstanceaction.

5.1.4. PRML SelectInstance

This relation checks that there is a set of elements in the PRML rule that represent a SelectInstance action according to the PRML metamodel (seeFig. 6). These elements are: aSelectInstanceclass together with the corresponding variable that represents a collec-tion and the type of this variable.

When transforming PRML into UWE, this relation enforces that the corresponding OCL expression has the following elements: an

IteratorExp class, whose type is ‘‘Select”, a collection of ele-ments,that represents the source of the IteratorExp of the same type of the Variable of the PRMLSelectInstance(seeFig. 12a).

When transforming PRML into the specifics of Hera, this rela-tion enforces that the corresponding Hera appearance condirela-tion

is a query of type ‘‘Select” whereSelectClauseacts over a collection of elements of the same type of the Variable of the PRML SelectIn-stance(seeFig. 12b).

Once this relation holds, thePRMLForEachand the PRMLCondi-tionrelations must be performed, according to the ‘‘where” clause. In this way, each part of a PRML rule will be checked with its cor-responding QVT rule, and the corcor-responding elements in the OCL expression or SeRQL query will be created.

5.1.5. PRMLForEach

This relation checks that there is the following set of elements in the PRML rule: aForEachelement, with a variable which has a type and a PathExpression. This relation enforces that the OCL expression contains an IteratorExpression which has a variable (with its type). This variable is the iterator of theIteratorExpression

(Fig. 13a). This relation enforces that the Hera Select query has a

from clausewith the samePathExpressionsas in the PRMLForeach expression(Fig. 13b)

5.1.6. PRMLCondition

This relation checks the condition class together with its bool-ean expression (BoolExp) within the PRML rule.

When transforming into the specifics of UWE, these elements enforce the body of theIteratorExpression, as an OCL expression that corresponds to the Boolean expression of the condition ele-ment in the PRML rule (Fig. 14a).

In Hera transformations these elements enforce the where clauseof the queryselectof the appearance condition as an

expres-Fig. 11.(a) UWE PRMLAction relation; (b) Hera PRMLAction relation.

sion that corresponds to the boolean expression of the condition element in the PRML rule (Fig. 14b).

As an example, let us see how the transformation needed for the following PRML rule is performed. This rule was defined in Section 4.3.3to fulfill the 2nd personalization requirement described in the running example (i.e. offer recommendations). This rule selects the instances to be displayed of the books’ concept which are written by an author in who the user has an interest degree greater than 100. When Navigation.Recommendations(NM.Book* books) do

Foreach b,a in (books,UM.User.usertoInterest. interestToAuthor) do

If (UM.User.userToInterest.degree>100) and a.ID = b.booksToAuthor.ID) then

books?selectInstance (b) endIf

endForeach endWhen

InUWEthe corresponding rule is the following:

Context: Rule::Executor(uid: ComponentUID,ui:UserID, ub:UserBehaviour)

Post: result = Collect (NM.Book)?Select (b:NM.Book, a:UM.User.usertoInterest.interestToAuthor

jb.bookToAuthor.ID = a.ID and UM.User.userToInterest. degree>100).

In the postcondition of the rule, a Select OCL expression selects the instances of the book in which the user has an interest degree greater than 100.

In this rule we can see how QVT relations described in this sec-tion are applied:

!PRMLRule:A PRML rule is transformed into an UWE rule.

!PRMLNavigation:A PRML navigation event is transformed into

a user browsing event. This transformation cannot be seen in the textual representation because it directly affects the UWE adaptation metamodel.

!PRMLAction: A PRML action is transformed into an OCL

expres-sion that represents the UWE rule.

!PRML SelectInstance:Once checked that the elements

repre-senting theSelectInstanceaction exist in the PRML rule, the rela-tion enforces that the corresponding OCL expression has the following elements: anIteratorExpclass, whose type is ‘‘Select”, a collection of elements, that represents the source of the Iter-atorExp, of the same type of the Variable of the PRML

SelectInstance.

Post: result=Collect(NM.Book)?Select()

!PRMLForEach:The ForEach element (with a variable which has

a type and a PathExp) of the PRML rule is transformed into an IteratorExp which has a variable (with its type). This variable is the iterator of the IteratorExp

Post: result=Collect (NM.Book)? Select(b:NM.-Book, a:UM.User.usertoInterest.interestToAuthor_j)

!PRMLCondition:The body of the IteratorExp is defined as an

OCL expression that corresponds to the boolean expression of the condition element in the PRML rule.

Post: result=Collect(NM.Book)?Select(b:NM.Book, a:UM.User.usertoInterest.interestToAuthor jb.bookToAuthor.ID=a.ID and UM.User.userTo Interest.degree>100)

Fig. 13.(a) UWE PRMLForEach relation; (b) Hera PRMLForEach relation.