through the proposition of a Web Application Extension. [4] or works such as WebML [5], have shown to offer. WIS designers a suited way to formalize systems ...
Design and Generation of Adaptable Web Information Systems with KIWIS Marlène Villanova-Oliver, Jérôme Gensel, Hervé Martin, Christelle Erb Laboratoire LSR – IMAG, BP 72, 38402 Saint Martin d’Hères cedex, France. email: {villanova, gensel, martin, erb}@imag.fr
Abstract Web-based Information Systems (WIS) are now widely used for diffusing and processing information over the network. Methodological guidelines which assist WIS developers in their task must take into account the specificities of WIS (a hypermedia structured information, navigation features, etc.). This paper presents KIWIS, a generator of WIS, which addresses the issue of designing and automatically deploying such WIS. Using KIWIS, designers can specify, at a conceptual level, the features of the WIS to be generated. This features are made operational by KIWIS by instantiating different models dedicated to the description of the application domain, the expected functionalities, and some features concerning adaptability. Any WIS described and generated with KIWIS can be considered adaptable since users can progressively access the content of information while the presentation of information respects the graphical charters selected or defined by users.
1. Introduction In various application areas such as e-business, geographical information systems, education, etc., the Web is widely considered a reliable approach to support information diffusion. Most of Web sites propose visually attractive and elaborated graphical web pages, but requirements of Web-based Information Systems (WIS) are beyond visual design. A WIS can be seen as a set of technical means for collecting, structuring, storing, managing and diffusing information as any traditional Information System does. The difference is that these actions are completed over a Web infrastructure. Consequently, WIS deal with a huge quantity of information, coming from numerous sources, in various formats, and processed by software environments which evolve rapidly. Moreover, services managed by WIS usually have a high level of complexity as, for example, the management of the user’s shopping cart in e-business sites. Then, the design of a WIS is a complex task which requires some methods and tools in order to assist developers. However, most of the time, developments of WIS are ad hoc and lead to more or less successful results
[1]. Indeed, few proposals have been made in order to avoid the ' Website crisis' , described in [2] and which results from no prior planning or analysis in web application development. Middleware approaches provide a uniform view of the data model and help to reduce the gap between the conceptual view of the system and the technical aspects. Different data models (e.g. relational, object, and now XML, …) can be used to represent information at this level. Recently, the UML approach [3], through the proposition of a Web Application Extension [4] or works such as WebML [5], have shown to offer WIS designers a suited way to formalize systems services (including navigational features) at a high abstraction level. These efforts in the design of today' s WIS have to be pursued and, specially, to be concentrated on the adaptability issue. Adaptability can be defined as the ability a system has to dynamically adapt itself to any user by giving her/him the feeling that the system has been designed specially for her/him. The objective is threefold and can be reached by providing each user with 1) an adequate content, 2) adequate interfaces for acting on the system and 3) personalized presentation. Then, adaptability relies on the knowledge the system has about its users. This knowledge can be acquired either by an explicit technique (the user fulfils an informative form) or an implicit one (user’s actions are tracked and analyzed). In our approach, knowledge about users is supported by a model in which users are considered either as members of groups or as individuals. Therefore, when the user access the WIS, information is delivered to her/him according to the features of her/his group, her/his personal characteristics, or a combination of both. The idea is that both content and presentation of information are adapted by the WIS to the user' s profile (in terms of needs, preferences, rights, expertise, …). In addition, we propose to give users (and at least to WIS designers) the opportunity to organize their own information space through the definition of different levels of information. Then, our proposal can be seen as the possibility to define several ordered views [6] on the same information space the user can access through a “view by view” progression mechanism. This way, users who do not want to waste their time navigating through and visualizing non-relevant, and therefore parasitic, information, can access to more or
less complete representations of information. This structuring of the information space is also described by a model. Concerning presentation, the challenge is to provide users with Web pages matching with their preferences in terms of pages layout, polices, colors, etc. Again, our approach consists in allowing the specification of these presentation parameters at a conceptual level. Through a third model dedicated to presentation, the different graphical components of a Web page displayed by the WIS are linked to one or more graphical charters defined by the user or chosen in a library. These three models have been implemented in KIWIS [7], a generator of WIS. KIWIS is a tool for WIS developers which puts the emphasis on adaptability to users, by focusing on data access and presentation. It offers guidelines for the design steps of a WIS and is in charge of the automatic deployment of this WIS. This paper present the different design steps of a WIS using KIWIS and is organized as follows. The design approach supported by KIWIS is presented in section 2. The architecture of KIWIS is detailed in section 3. Then, we compare our approach and prototype with some related works in section 4.
2. WIS Design with KIWIS KIWIS (which stands for Knowledge for Improving Web Information Systems) is an environment dedicated to the automatic generation of WIS given some conceptual specifications. This means that KIWIS users are IS designers who are provided with generic design guidelines which can be followed whatever the application domain is. Once the different steps of the guidelines are achieved, KIWIS automatically generates the WIS, according to its specifications, making it ready to be used by end-users. The design approach of KIWIS is resumed in Table 1. Each of these steps is presented in the following section.
2.1. Functional Requirements Analysis The first step corresponds to the analysis of the functional requirements of the expected WIS. For identifying users needs in terms of functionalities, traditional use cases description in UML can be used. In the case of KIWIS, we propose an extension of traditional use cases, called Adaptable Use Cases (AUC), in order to take into account the description of the adaptability dimension in use cases. AUC graphical notation is shown at the top of Figure 1. AUC express that a given functionality of the system will be achieved differently in order to be adapted to the concerned actors. One AUC corresponding to one functionality is associated with several sequence diagrams, one per actor. Each sequence diagram describes how the AUC must be implemented to fit the actor’s needs. Although this choice of description increases the number of specifications, it clearly identifies adaptability features at the conceptual level. We illustrate how AUC can be used through the example of a WIS, dedicated to natural hazards (river floods) [8], and developed using KIWIS. A functionality “consult the list of flood events” is identified as an AUC; two actors types, the expert and the visitor, can both use this functionality, but the designer of the WIS has decided they will be presented different content. Indeed, only the descriptive information of flood events are shown to visitors (name of the inundate city, the date at which the event occurred, meteorological conditions, etc.), while experts can access some additional information dealing with the geographic and histological analysis of the phenomenon. Consequently, two sequence diagrams are built. At the end of this first step, the whole set of expected functionalities are identified and their specifications are available in several actor-adapted versions. The following step consists of the definition of the data schema.
Table 1. Design steps in KIWIS. Step
Task
Model
1
Analysis of the functional requirements of the WIS Adaptable Use Cases, UML Use Cases and Sequence Diagrams
2
Definition of the schema of the application domain Data model expressed through a UML class diagram
3
Specification of the user’s profile
Generic User Model (GUM) expressed as a specific UML class diagram
4
Modeling of the progressive access to information
Progressive Access Model (PAM) expressed as a specific UML class diagram
5
Description of the hypermedia features.
Graphical charter in XML format for inventorying the components, and XSL format for describing the components appearance. Model of Pages in XML and XSL format.
6
Instantiation of the models
Instantiated Data Model as an AROM KB and XSD/XML files Instantiated GUM as an AROM KB and XSD/ XML files Instantiated PAM as an AROM KB and XSD/ XML files
List of actors names
detailed
Adaptable Use Case name
actor 1
The AUC ellipse is linked to a package which aims at detailing the AUC.
actor n
The “detailed AUC” package encompasses the sequence diagrams created for each actor associated with the AUC
Figure 1. Adaptable Use Case graphical notation (top left), and the package containing the corresponding sequence diagrams linked to the AUC.
2.2. Definition of the Data Model The definition of the application domain schema follows the UML approach and meets the requirements established during previous analysis steps. Classically, it consists in describing the class diagram which contains the structural and semantic knowledge about the application domain addressed by the WIS. In KIWIS, the resulting model is called the Data Model. Once the application domain is modeled, users of the WIS must, at their turn, be modeled in order to adapt the information to their expectations.
2.3. User Modeling In a traditional design process using UML, users are considered as members of users categories (i.e. actors). Information and services are generally adapted to groups but not to individuals. Such a limitation does not allow to manage easily the needs and preferences of a single user. In order to assist WIS designers in this third step, we propose a model, called the Generic User Model (GUM), which aims at explicitly representing specific users of a WIS. By distinguishing between the group and the individual levels, this model constitutes a basis for the management of adaptability. The GUM is an extensible object model, for representing users of the system as individuals. Thus, the GUM contains two classes named Group and Individual. The class Group describes information shared by members of groups, such as access rights. The class Individual maintains for a user some personal information such as the ones required for her/his connection (login, password, …). The classes Group and Individual are linked by an association modeling the membership relation: one instance of Group is made up of one or more instance(s) of Individual, and one instance of Individual belongs to one or more instance(s) of Group. If needed, the designer can extend the GUM classes in order to store some additional information about users. For example, in the SPHERE system presented herein, the
class Individual is extended to store the name of the city in which the user lives: this information is used to personalize the delivery of information. Note that the adaptability features (concerning both content and presentation) are not directly expressed in the GUM. They appear through the connections established between the GUM and the other models managed by KIWIS. The model in charge of modeling how information can be accessed in a progressive way by users, is designed in the next step.
2.4. Progressive Access Modeling A particularity of WIS generated with KIWIS is to provide users with the possibility to structure their information space in different levels. This is achieved thanks to a Progressive Access Model (PAM) [9] we propose to WIS designer for the fourth design step. The PAM is centered around the two notions of masks and multiple formats. Masks are ordered and more or less complete representations of information which allow users to access data at different levels of detail. For instance, one class of the data model can be structured in different representations or masks. From one mask to another, the number of variables which are visible when accessing objects of this class, increases (or decreases). The same gradual visibility can be obtained on the whole schema. Classes and associations visible at each level are defined. Multiple formats give multiple representations of a multimedia information (a text, image, audio or video), providing users with a more or less detailed content of this information. For instance, a video can be substituted by an excerpt or an abstract of it. Then, when users do not have enough time to entirely see the video, they can still access parts of it. Mask and multiple formats play a central role in the adaptability of the content of information to users. The PAM establishes links between the Generic User and Data models. The design task consists in defining for each group, the appropriate mask and multiple format structuring. By default, individual users are initially provided with the same progressive access as their group. They will define their own structuring using a specific interface of the WIS, if needed and if they are allowed. At this stage, the dimensions related to the WIS content, users, and progressive access modalities have been specified. The next step deals with the way the WIS delivers (i.e. displays or presents) information to users.
2.5. Description of the Hypermedia Model Traditional development processes do not consider hypermedia dimension of WIS and, most of the time, presentation features are left out of the design process. In KIWIS, adaptability also concerns information rendering.
This is achieved in our design approach thanks to the Hypermedia Model. The specifications of this model are fulfilled in two steps: 1. The choice or the definition of a graphical charter. This charter describes all the possible components (title area, frames, navigational and tools bars, etc.) and subcomponents (sub-areas, buttons, links, etc.) of a Web page to be dynamically displayed by the WIS. Among these graphical components, one can distinguish Data Model Related components (DMR) which embed content extracted from the data model. DMR are tables, lists, complex links1, etc. The appearance and default position of each component are described in the graphical charter. A default graphical charter is provided by the Hypermedia Model, but the designer can also define new ones. Notably, adaptability features in terms of presentation for each group is materialized by an association between this group in the GUM and a charter. As for the PAM, individual users will be able to define their own graphical charter, once the WIS will be used. 2. The creation of the WIS hypermedia pages. During this step, the designer creates the hypermedia pages from a list of pages provided by KIWIS and automatically extracted from the defined sequence diagrams. By default, the system generates one page per described functionality. In the example of section 2.1, two pages are required for the consultation of flood events list: one for experts and one for visitors. By default, KIWIS generates hypermedia pages based on the default graphical charter and on default page composition and navigation protocols. However, designers can compose themselves those pages and associate each page or component of page with a graphical charter, and/or establish navigation modalities as they whish. The final step, before the WIS generation, consists in filling the different models with information.
2.6. Instantiation of the Models Using the specific interfaces offered by KIWIS, the designer can easily instantiate the Data Model, the GUM, the PAM and the Hypermedia Model. Only the aspects related to groups are instantiated by the designer in the three last models. If they are allowed, user will instantiate these models at their turn. In KIWIS, these instantiations can optionally be done using a form-based interface or through the graphical interface of an Object-Based Knowledge Representation System, called AROM [10], and whose notations are close to UML ones. At the end of the five steps described above, the WIS deployment can be launched. In the next section, we describe the architecture of KIWIS and highlight the components which support the design approach. 1
Complex links are links whose value is a reply to a query.
3. Architecture of KIWIS KIWIS is written in Java. Five packages of Java classes, called Managers (see Figure 2) constitute its kernel. The Deployment Manager allows designers to download the KIWIS environment while the other managers are dedicated to specific functionalities for the WIS design, management and utilization. End-user workstation ( IE5, Netscape, etc )
network
HTTP Server (Apache) Servlet Engine (TOMCAT 4.0) JDK Web publishing framework
XML Query (XML – QL)
COCOON 2 (Xerces, FOP, Xalan)
K I W I S
AROM
AROM / XML
Parser
API User Manager
Presentation Manager
Designer Environment
KERNEL Data Manager
Query Manager
Deployment Manager
Data Storage (XML, XSL, XQL files)
Figure 2. The architecture of the KIWIS platform.
3.1. Deployment Manager The role of the Deployment Manager is to automatically install the KIWIS environment on the designer workstation. The KIWIS Kernel and API are downloaded, as well as the following components: - the System AROM we use for modeling in KIWIS, - the http server Apache, - the servlet engine Tomcat, - the publishing framework Cocoon, - the Java Development Kit, - the X-Query module, for querying XML files and - a specifically developed parser for the conversion of AROM models content to XML Schemas and files.
3.2. Data Manager Data description, instantiation, modification and deletion in KIWIS are performed under the control of the Data Manager. Both the domain application data and the data dedicated to adaptability are managed by this module. The management of data can be performed in two ways. First, a set of Java classes provides an interface (textual capture) for the creation of XSD and XML files which respectively maintain information about schemas and instances. Second, the Data Manager exploits the API of the AROM system. In this case, AROM is simultaneously used for describing and instantiation the Knowledge Base schema of the application domain, the GUM, the PAM and the Hypermedia Model. The Data Manager calls a
specifically developed AROM/XML parser which ensures the conversion of AROM models content to XML Schemas and files. This way, exchanges and exploitation of information by other Managers are facilitated.
3.3. Presentation Manager This module is associated with the Hypermedia Model and offers mechanisms to retrieve, use, create or modify a graphical charter to which the hypermedia pages must conform. The Presentation Manager also provides functionalities for the composition of pages and the specification of navigation features.
which executes the query on the Data Model ú. This Manager then creates an XML files ÷ which contains the result of the query. At this stage, the content to be returned is adapted to the user’s presentation preferences which are also extracted from GUM ó and are transmitted from the User Manager to the Presentation Manager ø. The Presentation Manager queries the Hypermedia Model í for delivering the adequate presentation in an XSL files û. XML and XSL files are sent to Cocoon in order to publish the page corresponding to the reply to the query. This page, adapted from both content and presentation viewpoints, is finally returned to the user ç.
3.4. User Manager This module manages the Generic User Model. The User Manager provides the required mechanisms for extending the Generic User Model, for creating a new user (definition of her/his rights, preferences, etc.), managing the profiles (access and modification of their own profiles by users), querying the PAM and Hypermedia models (extraction of information concerning rights and preferences of a user in order to adapt the content and the presentation to her/him).
Resulting page
Cocoon 2
û
ø
PRESENTATION MANAGER
í
Query
ç
XSL
Hypermedia Model
ö
DATA MANAGER
XML
÷
ó
USER MANAGER
ì
GUM
PASM
Data Model ú
Figure 3. Functional Architecture of a WIS
3.5. Query Manager
4. Related Work
This manager provides a set of predefined and generic queries used in every WIS generated with KIWIS. Such queries are frequent ones, as for instance, the connection query which necessitates to identify users. The Query Manager is also involved in the execution of domain specific queries (that is queries on the Data Model). The X-Query module is used by this manager for queries interpretation since data are stored in XML files.
Most of the Web application design approaches proposed at the end of the 90’s are inspired from earlier hypermedia design methodologies (HDM [11] or RMM [12]) which address content, presentation and navigation issues [13]. These three dimensions are also taken into account in our approach, with a special emphasis put on adaptability to user. As a consequence, we propose an explicit modeling of users as opposed to Araneus [14] or Takahashi method [15]. UR-WSDM (User-Requirement for Website Design Method [16]) also represents users explicitly, but does not take into account the individual level. The GUM allows us to manage adaptability to user at both the group and the individual levels as it is the case in WebML. The content adaptability is based on the processing of queries in order to provide users with replies containing relevant information with regard to theirs rights and needs. That is what most of the IS design methods intend to do, but the PAM adds the notion of personalized information space structuring. This approach increases the system usability by offering a progressive access to knowledge. This aspect constitutes a particularity of WIS generated with KIWIS. Adaptability also appears through the choice of a graphical charter, and through the composition of pages which can be define in KIWIS either for a group or one user. The independence between content and presentation,
3.6. Functional Architecture Overview Figure 3 illustrates the way the previously presented Managers work together for processing the query sent by a user to a WIS built with KIWIS. A query sent to the generated WIS by a user is first sent to the User Manager , which consults2 information from the GUM and the PAM in order to reinterprets the query. The GUM ó informs about who is the user and which are her/his rights on data. The PAM ì provides information about the data organizational features specified for this user (in particular, the default level of masks and multiple formats). Then, the User Manager transmits the reinterpreted query to the Data Manager ö, 2 Note that the Query Manager is called each time the other Managers extract information from their corresponding models, although this does not appears in the figure for a matter of visibility.
notably allowed by the XML/XSL technology, promotes adaptability since it makes possible the association of different presentations for a same content. WebML adopts a similar approach, but with lesser possibilities for users for composing the pages by themselves. Similarly to KIWIS, tools for Web application development support the steps of their associated methods, and generally perform the WIS generation. A particularity of KIWIS is to combine an Object-Based Knowledge Representation System for the knowledge management and an XML/Java technology for the storage and the processing of information.
5. Conclusion In this paper, we have presented the KIWIS environment which allows to generate WIS according to various design specifications. These specifications encompass usual specifications as those proposed in UML but also special specifications for adaptability. Adaptability consists in providing users with appropriate content and presentation according to their preferences. Knowledge about users is maintained in a Generic User Model and throughout its close relations with both the Hypermedia Model (which specifies the presentation features in terms of pages composition and graphical charter) and the Progressive Access Model (dedicated to the structuring of information space in different levels). Information Systems developed with KIWIS are Webbased (modification, consultation, query through a Web browser), portable (accessibility through any client Web browser), multimedia (management of video, audio, image, text, …), flexible (masks and multiple formats for information structuring), and user adaptable (adaptability to groups and users from both a content and a presentation points of view). We have also initiated a more dynamic adaptability process (also referred as adaptivity [16]) with the use of cookies technology to track information about users’ sessions in order to automatically learn from users' behaviors and then adapt information. This work has been first experimented in the context of the design and generation of a WIS dedicated to flood events management. The required adaptability features have been easily expressed in terms of both content and presentation using our approach. They also appears in the generated WIS. Perspectives of this work essentially concern two aspects. First, we currently focus on adaptivity techniques to react more efficiently to users actions. As shown by commercials tools (such as Interligo, http://www.interligo.com) which aim at developing ‘intelligent’ Web sites, dynamic adaptability is an essential criteria for satisfying users. Second, we want to address the security issue by integrating into our design approach a step for expressing groups and users rights on data at the
conceptual level. The security model will extend the GUM and will also offer a support to the expression of the security related to the actions performed on the system.
References [1] C. Rolland, Information Systems and Web Information Systems: a Methodological Perspective, Int. Forum cum Conf. on Information Technology and Communication at the Dawn of Millenium, Bangkok, Thailand, August 2000. [2] W. Goedefroy, R Meersman, and O. De Troyer, URWSDM: Adding User Requirement Granularity to Model Web Based Information Systems, 1st Int. Workshop on Hypermedia Development, Pittsburgh, PA, June 20-21, 1998. [3] J Rumbaugh., I. Jacobson and G. Booch, The Unified Modeling Language Reference Manual., Addison-Wesley, 1999. [4] J. Conallen, Building Web Applications with UML, Addison-Wesley, 1999. [5] S. Ceri, P. Fraternali and A. Bongio, Web Modeling Language (WebML) : a modeling language for designing Web sites, WWW9 Conf., Amsterdam, May 2000. [6] S. Abiteboul and A. Bonner, Objects and Views, SIGMOD, pp 238-347, 1991. [7] M. Villanova, J. Gensel and H. Martin, Progressive Access to Knowledge in Web Information Systems through Zooms, 7th Int. Conf. on Object Oriented Information Systems, Calgary, Canada, August, 2001. [8] P.A. Davoine, H. Martin, A. Trouillon, D. Cœur, M. Lang, M. Bariendos and C. Llasat, Historical Flood Database for the European SPHERE Project, 21th Gal Assembly of the European Geophysical Society, Nice, march, 2001. [9] M. Villanova-Oliver, J. Gensel, H. Martin, and C. Erb, Masks and Multiple Formats: Two Notions for A Progressive and Adapted Access to Information, ITCC2002. [10] M. Page, J. Gensel, C. Capponi, C. Bruley, P. Genoud, D. Ziébelin, D. Bardou and V. Dupierris, A New Approach in Object-Based Knowledge Representation : the AROM System, IEA/AIE 2001, Budapest, Hungary, June, 2001. [11] F. Garzotto, P. Paolini and D. Schwabe, HDM. A modelbased approach to hypertext application design, ACM Trans. on Information Systems, 11(1), pp 1-26, January 1993. [12] T. Isakowitz, A. Stohr and E. Balasubramanian, RMM : A methodology for structured hypermedia design. Communicatios of the ACM 38(8), pp 34-44, August 1995. [13] P. Fraternali, Tools and Approaches for Developing DataIntensive Web Applications : A Survey, ACM Computing Surveys, Vol 31, N° 3, September 1999. [14] P.Atezni, G. Mecca and P. Merialdo, To Weave the Web, 23rd Conf. on Very Large Databases (VLDB’97), pp 206-215, Athens, Greece, August 1997. [15] K. Takahashi and E. Liang, Analysis and Design of Web Based Information Systems, 6th Int. World Wide Web Conference (WWW6), Santa Clara, CA, USA, April 1997. [16] D. Schwabe, G. Rossi and S. Barbosa, Systematic Hypermedia Application Design with OOHDM, ACM Hypertext, 1996. [17] C. Stephanidis, A. Paramythis, D. Akoumianakis and M. Sfyrakis, Self-Adapting Web-based Systems: Towards Universal Accessibility, 4th Workshop on User Interface For All, Stockholm, Sweden, October, 1998.
