Specification of personalization in web application design

Specification of personalization in web application design

Irene Garrigós a,*, Jaime Gomez a, Geert-Jan Houben b,1

a Software and Computing Systems Department, Universidad de Alicante, Apartado de Correos 99, 03080 Alicante, Spainb 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

Article history:Received 1 June 2009Received in revised form 28 February 2010Accepted 12 April 2010Available online 18 April 2010

Keywords:PersonalizationWeb engineeringReusabilityRule language

a b s t r a c t

Personalization of websites has become an important issue in Web modeling methods due to their bigand heterogeneous audience. However, due to the existence of too many notations to represent the samedesign concepts in different methodologies, personalization specifications cannot be used out of thescope of a single tool or method. Moreover, in some cases, personalization is not defined as a separateaspect, being difficult to maintain and update. This paper tackles the aforementioned problems present-ing a generic modeling technique to facilitate the specification of the personalization. Personalizationspecifications 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 togetherwith the existence of a heterogeneous audience that implies thatthe website design should cope with different users’ needs, goals,preferences, and capabilities. Adapting the information contentand services for different user groups as well as for concrete usersmakes websites available to a broad audience and so, it has becomea 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 isnot a universal definition. We define Web personalization as theprocess of changing the content and structure of a website to adaptit to the specific needs, goals, interests and preferences of each usertaking advantage of the user’s navigational behaviour and context.

When designing personalized websites, ad-hoc design becomesunworkable. On one hand, many existing commercial approachesare based on rules and offer powerful specification means and toolsfor 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 usenot only different modeling techniques but also different imple-mentation methods. Other problems of these approaches are thelow abstraction level and the insufficient separation from the

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

To tackle the aforementioned problems, we propose to dealwith personalization as an orthogonal concern (i.e. as a separateaspect of the website), independent of the underlying technologyallowing the definition of abstract personalization specificationswhich is a prerequisite for portability and reuse. Reuse in softwareengineering/programming is generally accepted and promoted toimprove productiveness [11,12]. The proposed solution is basedon a high level rule language called PRML (Personalization RulesModeling Language) [13,14] that can be used by the designer tospecify at design time the personalization to be performed at run-time. PRML is defined as an abstract personalization language, thisis important for many reasons: it allows to specify personalizationdesigns before the target platform is selected. This also avoids the‘‘noise” that may be included in the platform-specific languageenabling discussions of personalization designs by design teams,and allowing to take more clear decisions on personalizationrequirements. 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: [email protected] (I. Garrigós), [email protected] (J. Gomez),

[email protected] (G.-J. Houben).1 Tel.: +32 2 6293308; fax: +32 2 6293525.

Information and Software Technology 52 (2010) 991–1010

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

http://www.elsevier.com/locate/infsof

http://dx.doi.org/10.1016/j.infsof.2010.04.001

mailto:[email protected]



http://www.sciencedirect.com/science/journal/09505849

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

This paper has twomain objectives: on one hand, the paper aimsto describe our experience in creating an abstract modelling lan-guage and presenting it, explaining how it can be used within aWeb modelling approach. For this purpose, the syntax and seman-tics of PRML is described and illustrated by means of examples, aswell as a set of guidelines for the designer. On the other hand, wewant 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 Webdesign methods: UWE [9] and Hera [7]. These transformations havebeen implemented in a prototype tool to show its feasibility. Theobjective is that the reader can clearly see the equivalence inexpressiveness, modelling the personalization in PRML or in theUWEorHera approaches, and that the samepersonalization rule ex-pressed in PRML can be transformed into the specifics of UWE andHera (and thus reused). To wrap up, this paper extends previouswork by defining PRML in an exhaustive way, providing guidelinesto the designer and formally defining the transformations fromPRML to other approaches. Moreover, it is important to note thatprevious studies did not take into account the UWE methodology.

We want to stress that this work has been done in the context ofthe MDWEnet project [16] which goal is to improve currentpractices and tools for the model-driven development of Webapplications 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 shareand exchange the adaptation among different systems.

The remainder of the paper is as follows: related work regardingWeb engineering methodologies is presented in Section 2. Section3 explains how personalization is modelled in the context of a Webdesign method by means of a running example. Furthermore, therequirements for the use of PRML within a Web modelling ap-proach are explained. Section 4 introduces the fundamentals ofthe PRML language. In Section 5, transformation rules2 from PRMLinto 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 toolcreated for supporting our approach. Section 7 presents our conclu-sions and further work. Finally, in the Appendix A of the paper, theBNF3 grammar of the PRML language is shown.

2. Related work

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

different notations for the modelling concepts the Web approachesuse, as far as the authors are concerned, in the existing Web designmethodologies 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 OOHDMnotation uses a small set of primitives for specifying personalizedattributes and methods referring the OOHDM modelling concepts.To model relevant information about the user, OOHDM adapts theuser class in the conceptual model. Attributes of the user class cansubsequently be used in the navigation class model to adjust theinformation that is shown to the user.

In WSDM [4,19], in the context of audience-driven design, aWSDM-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 thestructure and the navigation possibilities in the website. ASL rulesare defined to act on the WSDM design models. Note that person-alization is not supported, i.e. adaptivity for a single user, but theaim is to provide adaptivity for all users; that is also called optimi-zation. However, although personalization is not explicitly sup-ported, it would only require some modification to include a usermodel in an exactly similar way as the existing website overlaymodel. Subsequently, allowing ASL to access this user model yieldspersonalization support. In the context of this paper, ASL is thus asrelevant as any other adaptation specification mechanism which isaimed at personalization.

In UWA [8], in the context of ubiquitous computing, customiza-tion rules allow the designer to specify the adaptation to performwhen a certain context is detected. These rules are specified withina 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 tocustomization.

WebML [5] also uses a proprietary notation. Personalization isspecified 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 contextparameters 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 ECArules supported by an engine for rule execution known as Chimera-Exception Language has been described. Chimera-Web, a newversion of Chimera-Exception addressing Web events and Webadaptivity actions, is used to specify sparse adaptivity rules, whoseexecution 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 aframework that keeps the advantages of conceptual modelingand automatic code generation. Authors claim that the resultingarchitecture enhances separation of concerns, and supports flexi-bility and evolvability. However, this integration has not beencompleted, as they are still working on implementing some mod-ules the integration is based on, namely the Web Action Enactorand the Web Event Dispatcher [20]. To the best of our knowledgethe Chimera-Web language allows separation of concerns, how-ever for being able to use it within a modelling method a processof integration is needed, which is not needed if using PRML. Thisis due because the Chimera-Web language is thought of being gen-eric but is built taking into account the WebML approach only. Todefine 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.3 Backus–Naur form.

992 I. Garrigós et al. / Information and Software Technology 52 (2010) 991–1010

http://www.grapple-project.org

http://www.grapple-project.org

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

Problems arise when personalization strategies are specificallydefined for concrete application environments: reusability amongdifferent approaches of the personalization strategies becomes al-most impossible. As explained in Section 1, defining an abstractspecification 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 theconcrete approach. This has some disadvantages like the depen-dency of the personalization specifications on the target platformand that the personalization specifications cannot be exchangedamong different systems. Moreover, for being able to specify a per-sonalization specification that is portable between two approachesthe set of adaptivity actions, the way of specifying conditions andthe possible events to trigger personalization should be equivalent.In addition to this, the designer would have a high learning curvehaving to learn how to specify personalization in each proprietarysolution. As motivated in Section 1, PRML’s main goal is to solvethese problems. PRML is a high-level language which is a DomainSpecific Language (DSL) [21] so the rules defined with it are veryintuitive and easy to learn. DSLs allow solutions to be expressedin 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 designerusing PRML to specify personalization strategies should be adomain expert (personalization expert). The learning curve of thedesigner is reduced due to two reasons. The first one is that weshield the designer from the programming code and the secondone is that the designer can define personalization using PRMLand then transformations into the specifics of each methodologycan 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 wehave used them in this paper as a proof of concept. As it will be ex-plained in Section 3.4, to create PRML we have done a study foridentifying a common denominator of a set of existing modellinglanguages and abstracting the core set of concepts. That is whyPRML can also be applied to those studied methodologies. A reasonfor choosing these approaches is that are well-known by theauthors of the paper. This is important to specify efficient transfor-mations. Another reason for choosing those approaches is that theyare 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 amodel-driven and object-oriented approach whose distinguishingfeature is the fact that it complies with the Unified Modeling Lan-guage since UWE is defined in the form of a UML profile and anextension to the UML meta-model. UWE follows the principles ofthe Unified Software Development Process and supports the sys-tematic development of Web applications focusing on the specifi-cation of adaptive (personalized) applications. An extension ofArgoUML known as ArgoUWE gives support to the approach.UWE provides a reference model for adaptive hypermedia systemscalled Munich reference model, based on the Dexter referencemodel. The purpose of this model is to identify the main featuresof adaptive hypermedia and personalized Web applications, as aprior step to the definition of appropriate modeling techniques.

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

Fig. 1. Excerpt of the Hera metamodel (extended with SeRQL).

I. Garrigós et al. / Information and Software Technology 52 (2010) 991–1010 993

that the user must execute. The static user model is represented asa class diagram, expressing the view that the system has of theuser. It includes the user’s attributes, and their values, relevant tothe 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 theobjects, that is an instantiation of the user model, can be expressedby rules of the adaptation model. The adaptation model consists ofcontainers for user’s behaviour, a set of rules and a set of functionsto perform the adaptation functionality. A rule is modeled as aclass 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 beconsulted in [26]. Examples of instantiations of this metamodelwill be shown at the end of Section 5.1.

2.2. The Hera approach

The Hera methodology [7,25] is a model-driven approach fordesigning and developing Web Information Systems (WISs). Fromthe gathering of requirements to the maintenance of the opera-tional application, most information system design methodologiesdistinguish several phases in the design process. Hera’s target is tofacilitate the automatic execution of the design. Hera uses severalmodels to capture the different design aspects. Due to the fact thatthese 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 theirinstances.

Hera supports two types of adaptation: static based on theuser’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) information. In this model, the dynamic user’spreferences and platform capabilities are captured. The user modelchanges during user browsing. At this layer, there is another modelcalled adaptation model, to specify how adaptation is carried outby using the data coming from UP or UM. This is performed byusing inclusion conditions attached to model elements. Conditionsbased on UP attributes define the so-called adaptability – presen-tation is fixed before user browsing – while conditions based onUM model define the so-called adaptivity – presentation changesduring user browsing – of the system. These appearance conditionsover the different model elements are expressed using an exten-sion of the SeRQL [28] query language implemented by theHPG-Java engine. This engine is a Java servlet that, based on Heramodels, generates pages on demand. In Fig. 1, an excerpt of theHera metamodel for supporting adaptivity is shown. It is extendedwith 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 thetransformations between PRML and SeRQL and examples of instan-tiations of this metamodel will be shown at the end of Section 5.1.

In the next section, we will explain how to add personalizationusing PRML to a Web design method. A case study will be pre-sented and modeled in the context of UWE and Heramethodologies.

3. Personalization modeling in web design methods

Typically, Web design methods define three main models whendesigning 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 domaindata 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 modelsare added to the above set of models:

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

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

In the following sections, we will define the different models ofthe typical Web application design phases for the UWE and Heraapproaches (except for the presentation model because personali-zation of the presentation is outside the scope of this work). Forillustration purposes, the case study modeled in this paper is anonline book store. In this system, the user browses through a listof books and can order selected books. Later, in Section 5, we willdescribe 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 Webapplication domain data. The upper part of Fig. 2 shows the UWEDM for the running example. In UWE, the DM is defined as aUML-compliant class diagram. Concepts are represented by classeswith attributes and operations. There are associations betweenthem representing concepts relationships. In our case study, allbooks 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 UWEDM by the Buy() method).

The Hera DM for the same example is depicted in the upper partof Fig. 3. As aforementioned, in Hera, all models are expressed inRDFS [27]. Rounded rectangles represent concepts and rectanglesrepresent literal attributes. Concepts also have concepts relation-ships represented by arrows between concepts. We store the sameinformation as in the UWE DM. The Hera DM does not specifyoperations; the application logic (i.e. the Buy() method) is directlyspecified in the navigation model.

3.2. Navigation model

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

UWE NM is composed of navigational classes, which representviews5 of the classes of the DM (the above-defined nodes) and theirrelationships (i.e. links). In the Hera NM (see Fig. 5) slice shapes rep-resent navigation nodes. These nodes are based on DM or UM con-cepts that are called root concepts, represented by ovals attachedto the slice shapes. Overlaying areas of slices and ovals contain attri-butes of the root concept. Attributes of related concepts are locatedin 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 navigateto different slices, and can serve as menu items, and links associatedwith submitting forms. For a more extensive description of UWE andHera NM we refer the reader to [9,7], respectively.

Figs. 4 and 5 show the NM for UWE and Hera respectively. Wecan see that both models have the same expressiveness. In bothcases, the final website will have the home page where we can finda collection of links (i.e. menu) with the links Consult Books andRecommendations as a starting point. If the user navigates throughthe first link (Consult Books) he/she will find a list of all the books ina new page; in the UWE model it is represented by the navigationclass Book and in the Hera model represented by theBook slice. Thisset of books is an indexed list, so the user can click on one of thebooks’ names to view the details of a chosen book (the BookDetailsclass in UWE and the BookDetails slice in Hera). When the userclicks on Recommendations, personalized book suggestions shouldappear (based on the information from the user model). The ‘‘Rec-

ommendations” page is represented in UWE by the Recommenda-tions class, and as the Recommendations slice in Hera. To fulfill apersonalization 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 theset of models. They are described along the next sections.

3.3. User and personalization models

3.3.1. Adding the user modelTo 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 concreteapplication. Typically these data (i.e. personalization data) is insome 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.

Fig. 3. DM-UM for Hera.


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 andlanguage) but also information related to the browsing behaviourof the user, as well as session information and information aboutthe context in which the user is using the site. It also can containuser data referring to the domain (for example, information onthe 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 thepersonalization model with the classes needed to store therequired information to base the personalization on.

! The information type we store in the user model can be usercharacteristics, preferences, user requirements, context of theuser 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 ofsome information, thenwe can create a generalization in the usermodel 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 fulfilledin the website. The personalization requirements specified forthe running example are the following:

1. Users that have bought more than a minimum number of bookswill 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 storedin the UM.

Fig. 4. UWE navigation model.

Fig. 5. Hera navigation model.


2. Users will see recommendations of books of authors that they areinterested in.This requirement states that users will be offered a set of rec-ommended books, based on the user’s interest. For fulfilling thisrequirement we need to acquire and update the user’s interestin the different authors.

3. If the user does not have enough interest in any book’s author toobtain personalized recommendations, the link called recommen-dations is not shown.For fulfilling this requirement we can check the interest in thedifferent 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) and Fig. 3 (lower part), respectively. While a UM isconceptually a separate model, it is used in a similar way as aDM and is typically associated with the DM. The UWE UM is de-fined as a UML-compliant class diagram and the Hera UM is de-fined using RDFS [27]. UML classes in UWE are equivalent toRDFS concepts in Hera. Associations defined between classes inUML are defined in RDFS as properties between concepts. A singleattribute specified in a UML class is defined as a literal in RDFS.

In the updatable data space defined by the UM, specified usingboth methods here, information describing the user’s interests inauthors is stored, according to the defined personalization require-ment. In the UM, we also have the NodeVisiting class/concept. Thisclass/concept stores the number of clicks on different links; in ourexample we store the clicks performed on the link Buy in the attri-bute buyClicks. Then, we will use this information to fulfill the firstpersonalization requirement of the running example. Note that tostore the number of clicks on any other link we would just have toadd a new attribute to the NodeVisiting class/concept.

3.3.2. Adding the personalization modelThe personalization model (PM) we define it is based on event–

condition–action rules. In this model, the personalization actionsto be performed are specified.

For satisfying a personalization requirement we often have todefine how to update the knowledge about user (acquisition rule).This information is stored in the UM data space. Furthermore, wehave to define the effects that this personalization causes to thepresented content and navigation structure (personalization rules).These rules use the information specified by the UM to describeadaptation 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 rulesare such because in this work we consider the personalization ofthe content and the navigation of the website. As already men-tioned, the personalization of the presentation is out of the scopeof this work.

As previously stated, the rules of the PM are defined using thePRML language. It is based on a MOF [30] metamodel (see Fig. 6)which defines the set of constructs of the language such as the dif-ferent parts that form a PRML rule and the different events and theactions supported. The main element of the metamodel is the rulemetaclass which represents the concept of rule containing the ele-ments that define it. The elements defining a rule are those thatrepresent its main structure and are explained in this paper. Thebasic 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 containsa condition (optional) and an action to be performed. The eventpart of the rule states when the rule should be triggered. Once trig-gered the rule, the condition is evaluated (if any) and if it is evalu-ated positively, then the action is performed. A Foreach expressioncan also be present in the rule when the action and the conditionact on a set of instances.

Fig. 6. Simplified PRML metamodel.


As it has been shown, UWE and Hera use different modelinglanguages 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 previousexamples. This is important in order to use the same personaliza-tion model, specified with PRML, in both approaches. To see ifthe expressiveness of the Web methodology is sufficient for theuse of PRML and therefore if the portability and reuse of personal-ization strategies is possible, we define some requirements thatneed 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 firststep is to identify a common denominator of a set of existing mod-eling languages and abstracting the core set of concepts. DifferentWeb design methods supporting personalization were studied. Theapproaches considered for this study were WebML [5], OOHDM[10], UWE [9], Hera [7] and WSDM [4]. This set of approaches isrepresentative enough to show the generality of PRML. All of themhave personalization support except for WSDM, which currentlysupports adaptation for all the users of the website but could beeasily extended to model personalization. After this study, someessential requirements to be able to accommodate PRML personal-ization specification were defined:

R1: A domain model (DM) should be a part of a Web applicationspecification. The data structure of the website should havea 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 specification. 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 conceptsbut can also be static nodes with no concept associ-ated. Each node can be associated to a concept fromthe DM or the UM. Nodes contain the attributes andoperations that are going to be shown in thenavigation.

Requirements R1 and R2 ensure that the target of the personal-ization rules exists and its data content can be properly referencedby condition and action parts of the rules. Domain and navigationspecification 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 foraccessing the data content of user model objects. Require-ment R3 ensures that the target of the acquisition (dataupdating) rules exists and can be properly referenced. Allmodern methods also support some personalization or atleast allow association of user actions with data updates.R3.1: Analogous to the DM, the UM should also be

composed of concepts, attributes and conceptsrelationships.

R4: Within the NM and UM, it should be possible to use eventsto trigger personalization, and conditions to execute the spe-cific personalization policy. Requirement R4 ensures thatpersonalization can be triggered by events supported bythe different methodologies. The personalization actions willbe executed depending on the condition evaluation.

R5: Besides the previous requirements, it should be possible todefine 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 differentmethods.

Once having abstracted the models and concepts over whichPRML has to operate, some aspects have to be defined to developa 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 differentmodels as well as the comparison operators supported in PRMLconditions need to be specified.

" Operations over concepts. Finally, the operations allowed inPRML over the different concepts need to be described.

The development of the rule language regarding these issueswill be presented in next section. In further sections we will ex-plain how a PRML personalization specification can be mapped toUWE and Hera methods.

4. PRML fundamentals

4.1. Timing of the adaptation

To specify when an adaptation (personalization) action shouldbe performed, PRML allows specifying user browsing events. PRMLincludes browsing events relevant for a website including itsbrowsing sessions. We argue that the majority of mature Websystems and design methods distinguish the following browsingevents: link navigation, node loading, starting a browsing session,and ending a browsing session. Browsing events are implicitlyassociated with the user clicks and may trigger the activationof 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 ofthe NM. The difference between this event and the previous oneis that the LoadElement event is triggered independently of thelink that loads the node. This is useful when a set of links havethe same target node and we want to personalize during theactivation of any of those links.

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

" End event: triggered when the browsing session expires aftercertain inactivity of the user in the system, or when the userexplicitly finishes the session.

The way the events are captured depends on the implementa-tion done. We have implemented a prototype tool for testing thePRML execution [14] in which the events’ gathering is not tightlyintegrated with the Web application. Next, the specification ofthese 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. Navigation and LoadEle-ment events) information about navigation is passed as aparameter. As aforementioned, nodes are restricted views overthe DM or UM concepts. The parameter contains information aboutwhich instances of concepts of the DM/UM are to be shown in theactivated node. The instances to be shown in the nodes are adaptedto 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 theDM/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, whichmay trigger one or more rules. The parameter is the instance orset of instances from the root concept of the DM/UM (activeCon-cept) to be shown in the activeNode. The distinction into simpleand complex parameters is carried out to improve the readabilityand maintenance of the rules for the designer. In other words, ifa complex parameter is transferred then a loop will be needed togo over the set of instances.

In the case of the running example, for specifying that an eventshould be triggered when the user clicks on the ViewDetails link inPRML, we express it as:

When Navigation. ViewDetails(NM.Book book) do

This event transfers a simple parameter (an instance of the bookvisited). An example of transferring a complex parameter is shownbelow:

When Navigation. Recommendations(NM.Book* books) do

When the user clicks on Recommendations, a set of books (zeroor more) will appear (with no adaptation action applied). Anappropriate PRML rule will adapt the set of books for a particularuser (explained in Section 4.3.3).

The browsing session events (i.e. Start and End events) do nottransfer any parameter. Their PRML representation is very simple:

When SessionStart doWhen SessionEnd do

The BNF specification for the PRML events can be found in theAppendix A of 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 multiplemethodologies. When specifying conditions two aspects have to bedecided: (i) how to refer to the different elements of the modelsdefined in the website; (ii) how to specify conditions over theseelements.

When specifying conditions, PRML rules can refer to differentelements of the models defined for the website. As already ex-plained, personalization is based on the user’s data stored in theUM. This information can be updated and consulted (specifyingconditions over those data to base the personalization on). Forupdating this information adequate actions are defined (see Sec-tion 4.3). Nevertheless, a mechanism to access the UM structuresis needed. Besides, a PRML rule can also refer to information fromthe DM and from the NM for specifying some needed conditions todefine adaptation actions. To indicate the access to data of a partic-ular model the prefixes ‘‘DM”, ‘‘UM” or ‘‘NM” are added in PRMLrules to the expressions referring to the particular information. Inthe case of accessing information defined in the UM, the sourceconcept is always ‘‘User”, to identify the user that is actuallybrowsing the website.

To access a certain element of a model, PRML navigates over themodel using path expressions (PE). The PEs are based on the pathexpressions defined in OCL [26]. As an example for a PE, considerthat 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 inFigs. 2 and 3, respectively). For building the PE the following stepsare to be taken:

! As already mentioned, the PE starts with a prefix indicating themodel that is being navigated." E.g UM

! After that, it follows a dot and then the source concept whichthe 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 concepts relationships PEsrefer to links. The BNF specification for a PE is described in Appen-dix A of 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 checkedfor all instances of the specified concept. This can be useful whenwe need to evaluate the condition for a set of instances but wewant to perform the action only once (i.e. when the condition holdsfor all instances).

4.3. Operations supported

PRML contains a set of constructs tomodel the personalization ofawebsitemanipulating the UMandNM. These constructs representpersonalization actions over the different elements of those models(note that the elements of the different models were explained inSection 3.4). As aforementioned, actions supported by PRML havebeen abstracted from a selection of well-known modeling ap-proaches. The adaptation actions supported by the studied ap-proaches include the user data manipulation. All approaches allowfiltering the content to show and most of them (UWE, Hera andOOHDM) allow filtering the links as well. In Table 1, we can seewhich actions are supported by each of the studied methodologies.

After this study we can conclude that PRML should contain thefollowing 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 attributeof a concept of the UM.

2. Filtering attributes in theNMnodes (selectAttribute):Bymeansof this action a node can be restricted by hiding or showingsome 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 conceptfor a user depending on the personalization requirementsthat 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 ofthe studied methodologies (and thus not supported by PRML) arealso interesting for personalization actions. Some of these actionsare defined in a more complete version of PRML limiting thoughthe reusability (PRML Full). As we have already explained, in thispaper we will focus on the common actions, elaborating them bymeans 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 Section 3 of an onlinebook store. The acquisition of the information that needs to bestored in the UM is carried out by means of acquisition rules whichperform the setContent action.

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

When Navigation.Buy (NM.Book b) dosetContent(UM.User.userToNodeVisiting.buyClicks,UM.User.userToNodeVisiting.buyClicks + 1)

endWhen

This rule is triggered by a Navigation event when the user acti-vates the link Buy. It updates the number of books bought whenthe user clicks on the Buy link (updating the attribute buyClicksof the NodeVisiting concept of the UM) using the PRML setContentaction.

! To cope with the 2nd requirement the user’s interest in theauthors of the books has to be gathered. In this example, theinterest of the user is defined in the following way: the user isinterested in an author when he consults a book of him/her.

When Navigation.ViewDetails (NM.Book book) doForeach a, b in (UM.User.userToInterest, book.bookToAuthor)

If(b.ID = a.interestToAuthor.ID) thensetContent (a.degree,a.degree + 10)

endIfendForeachendWhen

This rule is triggered by a Navigation event when the user acti-vates the link ViewDetails. It updates the interest of the user inthe author of the visited book (by updating the attribute Inter-est.degree of the UM).

The foreach expression of the rule is needed to go over each ofthe instances of the Interest concept (referenced by the PathExpression UM.User.userToInterest) in the UM (see Figs. 2 and 3)in order to check the proper instance to update. The foreach expres-sion also goes over the set of authors of the consulted book. If theinstance of the author checked in the UM is the same as one of theauthors of the book the user is consulting when clicking the View-Details link then we will update the interest degree in that authorin the UM, using the PRML 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 booksbought is greater than 10, we will show an attribute ‘‘discount” tothe user (note that this attribute was not previously selected tobe shown in the navigation model but is present in the domainmodel).

When Navigation.ViewDetails(NM.Book book) doIf UM.User.userToNodeVisiting.buyClicks > 10 thenbook.Attributes.selectAttribute(discount)

endIfendWhen

In this rule from the set of attributes of a book, the attribute of-fer is selected. The rule is triggered by a Navigation event, result ofclicking on the ViewDetails link. Events pass a parameter with theinformation of the node to be shown, in this case the concrete bookof which we are going to see the details. If the number of clicks onthe Buy link (stored in the user model with a rule explained in Sec-tion 4.3.1) is greater than 10, we will select the attribute discountfrom the book concept to be shown using the PRML selectAttrib-ute action.

4.3.3. Filtering node instances (selectInstance)Let’s consider now the 2nd requirement of the case study in

which recommended books based on the interest of the user areshown. The interest of the user needs to be stored in the UM withan acquisition rule taking into account the user’s browsing behav-iour (this rule has been explained in Section 4.3.1). The personali-zation rule that displays the book names if the user has an interestdegree in the book author greater than 100 is as follows:

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

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

books? selectInstance (b)endIf

endForeachendWhen

The rule is triggered by a Navigation event, which is the result ofclicking on the Recommendations link. As aforementioned, naviga-tion events pass a parameter with the information of the node tobe shown, in this case the set of all the books which is filtered toonly show the recommended books.

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

Table 1Actions supported by the different methodologies.

Action/methodology UWE Hera WebML OOHDM WSDM

1. Updating UM content Yes Yes Yes Yes No2. Filtering content (concept

attributes)Yes Yes No No Yes

3. Filtering content (conceptinstances)

Yes Yes Yes Yes Yes

4. Link hiding Yes Yes No Yes Yes5. Sorting content No No No No No6. Sorting links Yes No No No No7. Adding/deleting links No No/

NoYes/Yes No Yes

8. Adding/deleting concepts No No Yes/Yes No No9. Dynamically grouping users No No No No No10. Link annotation Yes No No No No


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

4.3.4. Link hidingTo illustrate the hideLink action 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 notconsulted the details of any book yet, maybe because it is the firsttime the user goes into the website) the Recommendations link isnot shown. Note that there is only one Recommendations link inthe website for each user.

When SessionStart doIf ForAll (UM.User.usertoInterest)

(UM.User.usertoInterest.degree = null or UM.User.usertoInterest.degree < 100) thenhideLink(NM.Recommendations)

endIfendWhen

The rule is triggered by a SessionStart event, when the user en-ters the website. In this case, our purpose is to check a conditionover 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 the Forall statement is added to the con-dition stating the collection over which the condition should betrue. This condition checks if the interest degree of the user inthe different authors has any value. If it has no value, it means thatthe Recommendations link should not be shown, so it is hidden byusing the PRML hideLink action.

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

Rule: suggestions type: Pers-Content priority: highactivation: 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 whichthe 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 sametriggering event is unspecified unless it is enforced using priority.This rule has a high priority which means that will be executed ear-lier than rules having medium and low priority. 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 theybecome active (i.e. their condition evaluation is true), all the activerules are collected in a queue (stack) and executed sequentially.Parallel execution would require a conflict resolution mechanismin case of several active rules performing conflicting actions. Theexecution of a rule may activate or deactivate other rules, so otheractive rules in the queue may become inactive before they are se-lected for execution. A different execution order of the rules in thequeue can affect the final state (those rules will have execution or-der-dependence). For the same user the system should provide thesame result, and thus the same final state, which is called conflu-

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

! Acquisition rules have always higher priority than personalizationrules. When an acquisition rule and a personalization rule aretriggered on the same event we want to update the informationacquired before applying the personalization. In this way weassure the information used to base the personalization on isalways updated.

! Personalization rules triggered by the same event affecting thesame element should be defined taking into account that:" Filteringattributeshashigherpriority thanfiltering instances." The order of execution of two rules with the same action

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

! Multiple acquisition rules sharing the same event should beavoided. The reason is that when unsynchronized data updatestake 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 ofthe designer to take them into account when defining a set of rulesfor fulfilling a personalization strategy. If these guidelines are nottaken 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 forthe use of PRML. First of all, if a designer wants to use PRML forspecifying personalization strategies in a website, he should checkthe requirements specified for the use of PRML (explained in Sec-tion 3.4). Then, if the Web methodology used in the website fulfilsthe specified requirements the designer has to follow the nextsteps:

1. Define the personalization requirements to support in thewebsite.

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 informationstored 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. 7 shows an overview of the approach presented. The web-site is specified by a set of design models of a concrete Webmethodology. The personalization model is specified by the per-sonalization designer (or reused from a personalization 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. Wehave developed such an engine in order to test the PRML language[15].6 An overview of this implementation is explained in the lastparagraph of Section 6.

So far, we have presented the PRML language. From now on, wewill present how the transformations from PRML into UWE andHera approaches are possible. The aim of the transformations is thatof 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 UWEand Hera methods

In this section, we will describe the transformations from PRMLinto 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 DrivenArchitecture) standard as a means of defining formal and auto-matic transformations between models. Defining transformationsby 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, usingQVT 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. Thedeclarative part provides mechanisms to define relations that musthold between the model elements of a set of candidate models(source and target models). This declarative part can be split intotwo layers according to the level of abstraction: the relational layerthat provides graphical and textual notation for a declarative spec-ification of relations, and the core layer that provides a simpler, butverbose, 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 purelydeclarative specification of a relation.

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

! Two or more domains: each domain is a set of elements relatedto a source or a target model. The kind of relation betweendomains must be specified: checkonly (C), i.e., it is only checkedif the relation holds or not; and enforced (E), i.e., the targetmodel can be modified to satisfy the relation.

! When clause: it specifies the conditions under which the rela-tion needs to hold (i.e. precondition).

! Where clause: it specifies the conditions that must be satisfiedby all model elements participating in the relation (i.e.postcondition).

The following sections will explain the QVT relations defined forthe transformation of a PRML specification to the specifics of UWEandHeramethodologies. Transformations are defined in a unidirec-tionalway fromPRML to concrete languages. These transformationsare done to formally show the equivalence of the expressiveness inPRML and the target approaches. In this process, no information islost because all the specifications that can be done with PRML canalso be specified in the target languages. This is assured by theway 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 OCLexpression that represents the same personalization rule for theUWE approach. Therefore, the output of a QVT transformation fromPRML to UWE is an OCL expression based on the abstract syntaxdefined 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.

6 http://www.lucentia.es.


http://www.lucentia.es

attribute) representing the same personalization rule for the Heraapproach. These queries allow data manipulations and some ofthem are conditions determining the set of instances of concepts,links or attributes to be displayed. The mentioned queries arebased 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 OCLexpressions and from PRML and SeRQL expressions, useful forapplying 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 theircorresponding metamodels (PRML, OCL and SeRQL).

In Fig. 8, we can see the sequence of transformations that areneeded for the different types of PRML rules. This set of relationsis applied according to the structure of a PRML rule (see Section3.3.2): firstly, the PRMLRule relation is applied to drive the wholetransformation. 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 is Navigation, then the PRMLNaviga-tion relation is applied. The PRMLNavigation relation has to call thePRMLAction relation, since the main part of a PRML rule is the ac-tion to be performed. The PRMLAction relation deals with executingthe right relation according to the kind of action. Then, if the actionis SelectInstance, the PRMLSelectInstance relation is applied. Thisrelation together with PRMLCondition and PRMLForEach relationsare 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 onlyshow in this paper a subset of these relations, which allow us todeal with a PRML rule triggered by a Navigation event and the Selec-tInstance action.

5.1.1. PRMLRuleThe 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 PRMLrule, calling the appropriate QVT relation. Please, note that in thispaper we only focus on the navigation event, so in the ‘‘where”clause only the PRMLNavigation relation is called.

5.1.2. PRMLNavigationThe PRML Navigation QVT relation states that a PRML Naviga-

tion event is transformed into a user browsing event. In UWEFig. 8. Sequence of transformations.

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

Fig. 9. (a) UWE PRMLRule relation; (b) Hera PRMLRule relation.


(Fig. 10a) this transformation is straightforward. For Hera, it statesthat a PRML Navigation event is transformed into a Condition queryapplied over the node activated by the event and into a Sessionquery (with a Result query attached) for storing the parameter ofthe PRML navigation event as a Hera session variable (Fig. 10b).The ‘‘where” clause contains a relation that extends the previousone (i.e. PRMLAction) and it is described below.

5.1.3. PRMLActionThe 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 an appearanceCondition(query) (Fig. 11b). This relation checks the kind of actionin order to call the adequate relation in the ‘‘where” clause. Notethat we only focus on the SelectInstance action.

5.1.4. PRML SelectInstanceThis relation checks that there is a set of elements in the PRML

rule that represent a SelectInstance action according to the PRMLmetamodel (see Fig. 6). These elements are: a SelectInstance classtogether with the corresponding variable that represents a collec-tion and the type of this variable.

When transforming PRML into UWE, this relation enforces thatthe corresponding OCL expression has the following elements: anIteratorExp class, whose type is ‘‘Select”, a collection of ele-ments,that represents the source of the IteratorExp of the sametype of the Variable of the PRML SelectInstance (see Fig. 12a).

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

is a query of type ‘‘Select” where SelectClause acts over a collectionof elements of the same type of the Variable of the PRML SelectIn-stance (see Fig. 12b).

Once this relation holds, the PRMLForEach and the PRMLCondi-tion relations 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 corresponding elements in the OCLexpression or SeRQL query will be created.

5.1.5. PRMLForEachThis relation checks that there is the following set of elements

in the PRML rule: a ForEach element, with a variable which has atype and a PathExpression. This relation enforces that the OCLexpression contains an IteratorExpression which has a variable(with its type). This variable is the iterator of the IteratorExpression(Fig. 13a). This relation enforces that the Hera Select query has afrom clause with the same PathExpressions as in the PRML Foreachexpression (Fig. 13b)

5.1.6. PRMLConditionThis 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 the IteratorExpression, as an OCL expressionthat corresponds to the Boolean expression of the condition ele-ment in the PRML rule (Fig. 14a).

In Hera transformations these elements enforce the whereclause of the query select of the appearance condition as an expres-

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

Fig. 12. (a) UWE PRMLSetInstance relation; (b) Hera PRMLSetInstance relation.


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

As an example, let us see how the transformation needed for thefollowing PRML rule is performed. This rule was defined in Section4.3.3 to fulfill the 2nd personalization requirement described in therunning example (i.e. offer recommendations). This rule selects theinstances to be displayed of the books’ conceptwhich arewritten byan author in who the user has an interest degree greater than 100.

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

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

books? selectInstance (b)endIf

endForeachendWhen

In UWE the 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.interestToAuthorjb.bookToAuthor.ID = a.ID and UM.User.userToInterest.degree > 100).

In the postcondition of the rule, a Select OCL expression selectsthe instances of the book in which the user has an interest degreegreater 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 intoa user browsing event. This transformation cannot be seen inthe textual representation because it directly affects the UWEadaptation 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 the SelectInstance action exist in the PRML rule, the rela-tion enforces that the corresponding OCL expression has thefollowing elements: an IteratorExp class, 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 PRMLSelectInstance.

Post: result=Collect(NM.Book)? Select()! PRMLForEach: The ForEach element (with a variable which hasa type and a PathExp) of the PRML rule is transformed into anIteratorExp which has a variable (with its type). This variableis the iterator of the IteratorExp

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

! PRMLCondition: The body of the IteratorExp is defined as anOCL expression that corresponds to the boolean expression ofthe condition element in the PRML rule.

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

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

Fig. 14. (a) UWE PRMLCondition relation; (b) Hera PRMLCondition relation.


In Hera the corresponding set of queries is the following:Session and Result QueriesThis set of queries fills the ‘‘book” session variable with the set

of books of the domain model.

<rdfs:Class rdf:ID="Query_ID1"><rdfs:subClassOf rdf:resource="&Query"/>

<slice:queryString>SELECT * FROM <cm:books></slice:queryString>

</rdfs:Class><rdfs:Class rdf:ID="QueryResult_ID1" slice:result-Name=books slice:useAsSessionVar="Yes">

<rdfs:subClassOf rdf:resource="&slice:QueryRe-sult"/>

</rdfs:Class><rdf:Property rdf:ID="result-ref_ID1">

<rdfs:subPropertyOf rdf:resource="&Slice#re-sult-ref"/><rdfs:domain rdf:resource="#Query_ID1"/><rdfs:range rdf:resource="#QueryResult_ID1"/>

</rdf:Property>

Condition QueryThis query is a condition over the recommendation slice. It

checks the conditions specified in the 2nd requirement (i.e. theinterest degree in a book’s author has to be greater than 10). Ifthe condition holds, the proper instances of the recommendationslice will be visible.

<rdfs:Class rdf:ID:’SliceCondition_ID1’’><rdfs:subclassOf rdf:resource=”http://www.is.win.tue.nl/$hera/ns/slice#SliceCondition”/>

<slice:queryString>SELECT BFROM{B} <cm:booksToAuthor> (BTA} <um:ID> {ID},<um:userToInterest> {UI} <um:degree> {D},<um:userToInterest> {UTI} <um: interestToAuthor>{ITA} <um:ID> {ID2},

{session} <session:user> {U}WHERE D > 100 and ID= ID2 and B in Select * fromsession:books</slice:queryString>

<rdfs:Class><rdf:Property rdf:ID="condition-ref_ID1">

<rdfs:subPropertyOf rdf:resource="&Slice#condi-tion-ref"/><rdfs:domain rdf:resource="#SLice.Recommenda-tion_ID1"/><rdfs:range rdf:resource="#SliceCondition_ID1"/>

</rdf:Property>

In Hera the corresponding set of queries is obtained by applyingthe QVT relations in the following way:

! PRMLRule: A PRML rule is transformed into a set of queries.! PRMLNavigation: A PRML navigation event is transformed intoa query condition over the recommendations slice. (SliceCondi-tion_ID1) and into a session and result queries (Query_ID1 andQueryResult_ID1) storing the set of books received as an eventparameter in the PRML rule as a session variable.

! PRMLAction: A PRML action is transformed into a conditionquery that has to be built depending on the action type.

! PRML SelectInstance: Once checked that the elements repre-senting the SelectInstance action exist in the PRML rule, the rela-tion enforces that the corresponding Condition query has aSelectClause in the appearance condition acting over a collectionof elements of the same type of the variable of the PRMLSelectInstance.

SELECT B

! PRMLForEach: The ForEach element (with a variable which hasa type and a PathExp) of the PRML rule is transformed into afrom clause in the Condition querywith the same PathExpressionsas in the PRML foreach expression.

FROM{B} <cm:booksToAuthor> (BTA} <um:ID> {ID},<um:userToInterest> {UI} <um:degree> {D},<um:userToInterest> {UTI} <um:interestToAu-thor> {ITA} <um:ID> {ID2},{session} <session:user> {U}

! PRMLCondition: The body of the IteratorExp is defined in thewhere clause of the query select of the appearance condition asan expression that corresponds to the boolean expression ofthe condition element in the PRML rule.

WHERE D > 100 and ID= ID2 and B in Select * fromsession:books

6. Implementation

The presented transformations have been implemented to showits feasibility. We have already successfully performed the trans-formations from PRML into the HPG engine (Hera specification)as well as into the UWE specification (OCL). We are currentlyworking on the implementation of the transformations from PRMLto different Web design methods. We have generated a PRML par-ser using the ANTLR (ANother Tool for Language Recognition,http://www.antlr.org/) parser generator. Together with this, trans-lators from PRML into Hera and UWE specifications have beenimplemented in Java. In Fig. 15 we can see a schema of how thePRML to Hera translator works and its relation with the ANTLR.

In the file where the PRML grammar is defined we find all thetokens that the PRML language uses. The second file that is the in-put of the ANTLR contains the PRML syntax and its translation intothe target methodology. When executing the ANTLR with thosetwo files as an input, the output is a file with source code (in ourcase Java). Once the code is generated it has to be compiled onlyonce, and it is ready for its execution. A screenshot of the Webinterface of the prototype PRML Translator is shown in Fig. 16. In

Fig. 15. PRML into Hera translator.


http://www.is.win.tue.nl/~hera/ns/slice#SliceCondition



http://www.antlr.org/

the upper part of this figure, the PRML rule or set of rules are intro-duced. Then the user chooses if the translation has to be made intoHera or into UWE and the translated rule is shown.

The implementation of these transformations is also beingtested by using the Web Transformation Engine (WebTE). This isa tool developed by the IWAD research group of the University ofAlicante. It implements transformations between models usingthe UPT language [32]. UPT is a declarative transformation lan-guage which specifies the transformations using the standardUML and is based on QVT.

Moreover, the PRML language has been tested by implementinga prototype tool [14,15]7 which contains several modules like a Web

engine and a rule evaluator, allowing the execution of PRML rules ina running website. The generated Web Application has a three lay-ered architecture: The first layer is the user interface, through whichthe user can generate http requests and receive http responses. Thesecond layer contains the main modules of the Web Application formanaging the personalization (i.e. Website Engine and PRML Evalu-ator). The Website Engine interacts with the user, gathering the re-quests and giving back the response. The conceptual models aremodified for each particular user (i.e. each user will have a differentset of models depending on the adaptation actions performed onthem). The Website engine loads the models (from the applicationdatabase) of the particular user when s/he starts a new session.These models are modified along the different sessions dependingon the adaptation actions performed. This implies each user willsee a different adaptive view of the Website every session s/he

Fig. 16. Screenshot of the PRML translator.

Fig. 17. Screenshot of the recommendations page.

7 http://www.lucentia.es


http://www.lucentia.es

browses it. The Website engine captures the events the user per-forms with his browsing actions and sends them to the PRML Eval-uator module. This module is responsible of evaluating andperforming the personalization rules attached to the events. Whena rule is triggered, to evaluate the rule conditions and perform theproper actions we have implemented a .NET component using theANTLR Parser generator From the PRML grammar we can generatethe syntactic trees which help us to evaluate the rule conditionsand perform them if necessary. Finally to execute the actions ofthe rules, we have implemented in C# the different actions typesthat we can find in PRML. The third layer contains the Applicationdatabase and a text file containing the set of rules defining person-alization policies on the Website.

For further details consult [14,15]. An example of execution isexplained next: in Fig. 17 the recommendations page is shownfor two different users. Depending on the user interest (stored inthe user model) the books to recommend vary. To properlyshow the recommendations to the user the implemented toolfollows the next steps: the website engine gathers the request ofthe user for the recommendations page and triggers the userbrowsing event (i.e. click on recommendations) sending it to thePRML evaluator module. This module checks if there is any ruletriggered, and finds the ‘‘showRecommendations” rule (see Section4.3.3) which executes. This rule selects the corresponding book in-stances to be shown from the navigational model. These recom-mendations won’t change until the next time the user starts asession. This decision has been taken not to overwhelm the userwith constant updates.

7. Conclusions and further work

Website modeling methodologies provide a conceptual and sys-tematic approach to complex Web application design and imple-mentation. Most of these methodologies allow developingpersonalized websites where the personalization specificationsare tightened to the underlying technology and in some casesembedded in their design models. This can cause some problemslike the difficulty of maintenance of the personalization and theinability of reusing the personalization specification among differ-ent approaches. In this paper we have presented a solution basedon a high level rule language called PRML (Personalization RulesModeling Language) which allows us to specify personalization atdesign time as an orthogonal concern of the website, independentof the underlying technology.

PRML can be used within other approaches or websites in dif-ferent ways: the reuse of the rule language within different Webmethodologies is possible. To achieve this goal PRML has been de-fined as a method-independent language by identifying the com-mon denominator of the most representative Web designmethodologies. This is performed by abstracting the basic model-ing elements which the primitives and techniques that are usedfor personalization act on. PRML has been developed using theseabstract modeling elements that have been explained in Section3.4.

Reusability of personalization strategies among different web-sites is also possible. In this case, personalization strategies canbe seen as patterns stored in a repository that we can reuse in dif-ferent Web applications. An example of a real world case study isrecommendation systems. In order that users are not overwhelmedby too much information, e-commerce is widely adopting recom-mendation systems. A common example in e-commerce is the‘‘Customers who bought” feature. Examples of websites in whichthis feature is used are: amazon (http://www.amazon.com), asos(http://www.asos.com), pharmacy-online (http://www.pharmacy-online.com.au), orcashop (http://www.orcasurf.co.uk), etc. With

the help of this feature, these systems recommend similar productsto the current buyer based on the purchase histories of previouscustomers who bought the same product. Given the existing com-plexity of systems, reusability is required. PRML ameliorate thiscomplex scenario allowing the designer specifying recommenda-tions whatever the system is, because PRML is independent ofthe target platform so personalization strategies specified withPRML can be used in different systems. Regarding the previousexample, using PRML we could specify the recommendation sys-tem by means of PRML acquisition and personalization rules. Wewould need acquisition rules in order to store the purchase historyof the users. Personalization rules would specify a recommenda-tion algorithm to calculate the probability interest of the user bytaking the average of the interest of other customers in the samecategory or product. The specification of this strategy could be re-used in several websites with shared adaptation requirements.

Moreover, the personalization strategies are portable to differ-ent approaches. We are able to apply personalization strategiesspecified in PRML in different methods. This is possible if the differ-ent Web design methods define their models according to therequirements that have been specified in Section 3.4. Theserequirements define the abstract conceptual models, on whichPRML can work/act. To be able to use PRML and then reuse thesame personalization strategy, these approaches must have equiv-alent models to specify a Web application. We have identified foreach different approach a subset of its models. We can guaranteethat the expressiveness of this subset of models corresponds toPRML abstract models. Therefore, these subsets of the models ofdifferent approaches have equivalent expressiveness. In this paper,UWE and Hera approaches are used to show this fact. Section 3 ex-plains how the abstract models map to the specifics of Hera andUWE, having the same expressiveness and how they fulfil the de-fined requirements. Section 5 presents formal transformationsfrom PRML into UWE and Hera using the standard language QVTto formally show the portability of the PRML approach and its reus-ability among different methodologies. To illustrate this fact, con-crete examples of PRML rules are transformed into Hera and UWE,considering that they access the set of models that are presented inSection 3. Finally, we have presented a tool that automatically per-forms such transformations.

Considering that is impossible to cover all the aspects of person-alization some boundaries were set to this work and some limita-tions exist:

! Adapting the presentation. We do not consider the personaliza-tion of the presentation in this work.

! Limitation considering context-aware websites. This work doesnot consider in detail the context based adaptation, as it is outof the scope of this work. However, the approach supports somekind of context-awareness. For this purpose the UM should beextended with context entities.

! Limitations of the portability of PRML. Defining transformationsfrom PRML to other approaches (besides UWE and Hera) wouldstrengthen the obtained results. However it should be notedthat being able to transform PRML to these different approachesis enough to show our claims.

As explained in Section 4.3, due to the generality of the lan-guage, some personalization actions are not possible. We havebeen working in splitting PRML into two conformance levels [29](i.e. PRML Lite and PRML Full) in which the second level allowsto define more complex personalization (not just the commondenominator) thus reducing the reusability. The double objectiveof PRML is that of making possible the portability of personaliza-tion strategies among different approaches and that of allowingthe definition of more complex and specific personalization


http://www.amazon.com

http://www.asos.com

http://www.pharmacyonline.com.au

http://www.pharmacyonline.com.au

http://www.orcasurf.co.uk

actions. For this purpose, two conformance levels are defined inthis language:

! PRML Lite: This level comprises the basic operations supportedby the most representative Web modeling methods [4,5,7,9,10].It allows the independence from the Web modeling methodol-ogy and thus, the portability and reuse. The purpose of its def-inition is to be able to specify a universal personalization policy.

! PRML Full: The purpose of this level is to give support to specificpersonalization actions, though limiting portability. With theconstructs defined at this level, more complex personalizationstrategies can be specified. PRML Lite is a subset of PRML Full;therefore the particularities defined in PRML Lite are also validfor PRML Full.

Ongoing work includes the definition of transformation rules ofPRML in the context of other Web design methods like OOHDM orWebML. Moreover, we have the purpose of investigating eventualextensions of PRML full actions to better cover all possible person-alization strategies and scenarios. Another important issue that wewould like to consider is checking the consistency of the modelsbefore transformations. Therefore, before processing conditionsand operations we will check the parameters for their consistencywith the navigation model structure and with the user model. Asfuture work we also consider to study the usability of PRML in aformal way (e.g. through usability tests). Studying the impact ofthe Web 2.0 and AJAX on PRML is also interesting to take into ac-count for further experiments. For this purpose we plan to extendthe set of PRML events, studying these issues.

Another issue to consider as future work is studying the possi-ble extension of the user model with the needed elements in orderto adapt the proposal to support other type of applications like forexample mobile, GUI or voice-based applications. We would alsohave to study if the PRML syntax should be modified in any case.

Acknowledgements

This work has been partially supported by the ESPIA (TIN2007-67078) project from the Spanish Ministry of Education and Science.

Appendix A. BNF specification of PRML

Rule Specification

<rule> ::= <features> ‘When’ <event>‘do’ <body>‘endWhen’<features> ::= ‘Rule:’ <ruleName> ‘type:’ <type>‘priority:’ <priority> ‘activation:’ <activation-Date> ‘expiration:’ <expirationDate><type> ::= (’Acquisition’ j ‘Pers-Navigation’ j‘Pers-Content’ j ‘Pers-Presentation’)<priority> ::= (’high’j’medium’j’low’)<body> ::= ( <foreachExp>)? (’If (’ <condition>’) then’)?<action> ‘endIf’? ‘endForeach’?

Event

<event> ::= (’SessionStart’ j <navigation> j<loadEle-ment> j‘SessionEnd’)<navigation> ::=’Navigation.’ <activeLinkName>( <parameterExpression>)<loadElement> ::=’LoadElement.’ <activeNodeName>(<parameterExpression>)<parameterExpression> ::=’NM.’ <activeNodeName>‘*’? <parameterName>

Condition Expressions

<condition> ::=( <boolExpression>)( <booloperator> (<boolExpression> )*<boolExpression> ::= ‘not’? <operand> <compOperator>(<value>j<operand> j<literal>)<foreachExp> ::=‘Foreach’ (<variableName> ‘,’?)+ ‘in(‘((<PE> j<conceptName>) ,)+’) do’<operand> ::= <PE> (( <arithmeticOperator>) ( <PE> j<number>))?<PE> ::= (‘UM.User’ j ‘DM.’ <conceptName> j<parameter-Name>) {‘.’ <targetRole>}* ‘.’( <attributeName> j <conceptName>)?<PE> ::=’NM.’ <nodeName> ‘.’{<linkName> }* ‘.’( <attributeName> j <nodeName>)? j <parameterName>{’.’ <attributeName> }<compOperator> ::= ‘<’ j ‘>’ j ‘=’ j ‘<=’ j ‘>=’ j ‘<>’<booloperator> ::= ‘and’ j ‘or ’ j ‘not’<arithmeticOperator> ::= ‘+’ j ‘#’ j ‘*’ j ‘/’

Action

<action> ::= <setContent> j<selectInstance> j<selec-tAttribute> j<hideLink><setContent> ::= ‘setContent(’( <PE> j<operand>) ‘,’( <PE> j<operand> j<literal>) ‘)’<selectInstance> ::= ( <PE> j<parameterName>)‘?selectInstance(‘<variableName>’)’<selectAttribute> ::= ( <PE> j<parameterName>) ‘.Attributes? selectAttribute(‘<PE>’)’<hideLink> ::= ‘hideLink(NM.‘<linkName>’)’

Miscellaneous

<ruleName>::= <string><activeLinkName>::= <string><activeNodeName>::= <string><parameterName>::= <string><variableName>::= <string><conceptName>::= <string><targetRole>::= <string><attributeName>::= <string><linkName>::= <string><nodeName>::= <string><value>::= <number>+ j <boolean>

Data Types

<number>::= ‘-’? ( <integer>j <float>j<exponential>)<integer>::= <nonzero-digit> <digit>*<float>::= <integer>‘.’ <digit> <digit>*<exponential>::= <digit>‘.’ <digit> <digit>* ‘E’ (‘+’j‘-’ ) <integer><digit>::= ‘0’ j <nonzero-digit><nonzero-digit>::= ‘1’ j ‘2’ j ‘3’ j ‘4’ j ‘5’ j ‘6’ j ‘7’ j‘8’ j ‘9’<boolean>::= ‘true’ j ‘false’<string>::= <char> +<literal>::= ‘’’’ (<string>j ‘’ j <number>j ‘,’ j ‘%’)*‘’’’<char>::= ‘a’ j ‘b’ j ‘c’ j ‘d’ j ‘e’ j ‘f’ j ‘g’ j ‘h’ j ‘i’ j‘j’ j ‘k’ j ‘l’ j‘m’ j ‘n’ j ‘o’ j ‘p’ j ‘q’ j ‘r’ j ‘s’ j ‘t’ j‘u’ j ‘v’ j ‘w’ j ‘x’ j ‘y’ j ‘z’ j ‘A’ j ‘B’ j ‘C’ j ‘D’ j ‘E’ j‘F’ j ‘G’ j ‘H’ j ‘I’ j ‘J’ j ‘K’ j ‘L’ j ‘M’ j ‘N’ j ‘O’ j ‘P’ j‘Q’ j ‘R’ j ‘S’ j ‘T’ j ‘U’ j ‘V’ j ‘W’ j ‘X’ j ‘Y’ j ‘Z’


References

[1] J. Blom, Personalization: a taxonomy, in: Proceedings of CHI ’00, ExtendedAbstracts on Human Factors in Computing Systems, ACM, 2000, pp. 313–314.

[2] I. Cingil, A. Dogac, A. Azgin, A broader approach to personalization,Communications of the ACM 43 (2000) 136–141.

[3] W. Kim, Personalization: definition, status, and challenges ahead, Journal ofObject Technology 1 (2002) 29–40.

[4] S. Casteleyn, O. De Troyer, S. Brockmans, Design time support for adaptivebehaviour in websites, in: Proceedings of the 18th ACM Symposium on AppliedComputing, Melbourne, USA, ACM, 2003, pp. 1222–1228.

[5] S. Ceri, F. Daniel, F. Facca, Modeling Web Applications Reacting to UserBehaviors, Elsevier Computer Networks – Special Issue on Web Dynamics, vol.50 (10), 2006, pp. 1533–1546.

[6] J. Gómez, C. Cachero, O. Pastor, conceptual modeling of device-independentweb applications, IEEE Multimedia Special Issue onWE, vol. 8, 2001, pp. 26–39.

[7] G.J, Houben, F. Frasincar, P. Barna, R. Vdovjak, Modeling user input andhypermedia dynamics in Hera, in: International Conference on WebEngineering, Munich, Springer-Verlag, 2004, pp. 60–73.

[8] G. Kappel,W. Retschitzegger, E. Kimmerstorfer, B. Proll,W. Schwinger, Th. Hofer,Towards a generic customization model for ubiquitous web applications, in:Proceedings of the 2nd International Workshop on Web Oriented SoftwareTechnology (IWWOST), in conjunction with the 16th European conference onObject-Oriented Programming (ECOOP), Malaga, Spain, Springer-Verlag, 2002.

[9] N. Koch, Software Engineering for Adaptive Hypermedia Systems, ReferenceModel, Modeling Techniques and Development Process, PhD Thesis, Munich,Germany. Ludwig-Maximilian University, Munich, 2001.

[10] G. Rossi, D. Schwabe, M. Guimaraes, Designing personalized web applications,in: Proceedings of the World Wide Web Conference (WWW’10), Hong Kong,ACM, New York, 2001, pp. 275–284.

[11] J. Li, A. Gupta, J. Arvid, B. Borretzen, R. Conradi, The empirical studies on qualitybenefits of reusing software components, in: Computer Software andApplications Conference, Beijing, China, IEEE Computer Society, 2007, pp.399–402.

[12] C. McClure, Software Reuse: A Standards-Based Guide, Wiley-IEEE ComputerSociety Pr, New York, 2001.

[13] I. Garrigós, J. Gómez, P. Barna, G.J. Houben, A reusable personalization model inweb application design, in: Proceedings of the ICWE 2005 Workshop on WebInformation Systems Modelling, Workshop at ICWE2005, InternationalConference on Web Engineering, Sydney, Australia, University ofWollongong, School of IT and Computer Science, 2005, pp. 40–49.

[14] I. Garrigós, C. Cruz, J. Gómez, A prototype tool for the automatic generation ofadaptive websites, in: Proceedings of the 2nd International Workshop onAdaptation and Evolution in Web Systems Engineering (AEWSE’07), Como,Italy, Dipartamento di Elettronica e Informazione, Politecnico di Milano, 2007,pp. 13–27.

[15] I. Garrigós, O. Glorio, P. Hernández, A. Mate, Una Aplicación basada en Eclipsepara la Personalización de Aplicaciones Web Dirigida por Modelos. XIV

Jornadas de Ingenierı́a del Software y Bases de Datos (JISBD’09), San Sebastian,Spain, 2009, pp. 363–366.

[16] A. Vallecillo et al., MDWEnet: a practical approach to achievinginteroperability of model-driven web engineering methods, in: Proceedingsof the 3rd International Workshop on Model Driven Web Engineering, Como,Italy, Dipartamento di Elettronica e Informazione, Politecnico di Milano, 2007,pp. 246–254.

[17] L. Aroyo, P. Dolog, G.J. Houben, M. Kravcik, A. Naeve, M. Nilsson, F. Wild,Interoperability in personalized adaptive learning, Journal of EducationalTechnology and Society 9 (2006) 4–18.

[18] D. Schwabe, G. Rossi, An object oriented approach to Web-based applicationsdesign, Theory and Practice of Object Systems 4 (1998) 207–225..

[19] S. Casteleyn, Designer Specified Self Re-organizing Websites, Phd thesis, VrijeUniversiteit Brussels, 2005.

[20] F. Daniel, M. Matera, G. Pozzi, Combining conceptual modeling and active rulesfor the design of adaptive web applications, in: First international Workshopon Adaptation and Evolution in Web Systems Engineering (AEWSE’06), in:Workshop Proceedings of the Sixth International Conference of WebEngineering, Palo Alto, CA, USA, ACM Digital Library, 2006.

[21] M. Mernik, J. Heering, A. Sloane, When and how to develop domain-specificlanguages, ACM Computing Surveys (CSUR) 37 (2005) 316–344.

[22] M. Nussbaumer, P. Freudenstein, M. Gaedke, Web application developmentemploying domain-specific languages, in: Proceedings of the IASTEDInternational Conference on Software Engineering, Innsbruck, Austria,IASTED/ACTA Press, 2006, pp. 13–18.

[23] A. Van Deursen, P. Klint, J. Visser, Domain-specific languages: an annotatedbibliography, ACM SIGPLAN Notices 35 (2000) 26–36.

[24] N. Koch, M. Wirsing, The Munich reference model for adaptive hypermediaapplications, in: Second International Conference on Adaptive Hypermediaand Adaptive Web-based Systems, Málaga, Spain, 29–31 May, Springer-Verlag,2002, pp. 213–222.

[25] R. Vdovjak, F. Frasincar, G.J. Houben, P. Barna, Engineering semantic webinformation systems in Hera, Journal of Web Engineering (JWE) 2 (2003) 3–26.

[26] UML 2.0 OCL specification http://www.omg.org/docs/ptc/03-10-14.pdf.[27] D. Brickley, R. Guha, RDF Vocabulary Description Language 1.0: RDF Schema.

W3C Recommendation 10 February 2004.[28] OpenRDF, The SeRQL query language (2006), rev. 1.1. <http://

www.openrdf.org/doc/sesame/users/ch06.htm>.[29] I. Garrigós, A-OOH: Extending Web Application Design with Dynamic

Personalization, Phd thesis, University of Alicante, 2008.[30] OMG: Meta Object Facility (MOF) (2002) v1.4, OMG doc.formal/02-04-03.[31] OMG: Query/View/Transformation (2006). http://www.omg.org/cgi-bin/

doc?ptc/2005-11-01.[32] S. Meliá, J. Gomez, UPT: a graphical transformation language based on a UML

profile, in: Proceedings of European Workshop on Milestones, Models andMappings for Model-Driven Architecture (3M4MDA 2006), Workshop at 2ndEuropean Conference on Model Driven Architecture (EC-MDA 2006), Bilbao,Spain, CTIT Workshop Proceedings, 2006.


http://www.omg.org/cgi-bin/doc?ptc/2005-11-01

http://www.omg.org/docs/ptc/03-10-14.pdf

http://www.openrdf.org/doc/sesame/users/ch06.htm

http://www.openrdf.org/doc/sesame/users/ch06.htm

http://www.omg.org/cgi-bin/doc?ptc/2005-11-01

Date post:	02-Mar-2023
Category:	Documents
Upload:	independent
View:	0 times
Download:	0 times

Specification of personalization in web application design

Documents