A Methodology for the Design of WWW Sites. F. Casati, B. Pernici. becoming more and more widespread and important.

Transcription

1 A Methodology for the Design of WWW Sites and its Application to Distance Education F. Casati, B. Pernici Dipartimento di Elettronica e Informazione - Politecnico di Milano Piazza L. Da Vinci, 32 - I20133 Milano, Italy [casati,pernici]@elet.polimi.it Abstract. Providing information about organizations on the WWW is becoming more and more widespread and important. Such information is usually provided focusing on the construction of single Web pages, linking them as need arises. In the present paper, we advocate the need for a systematic design of the structure and of the interaction patterns with a Web site. We propose a methodology for the conceptual and detailed design of a Web site and we illustrate our methodology with the design of a site for distance education. The methodology is based on the entity relationship model for representing the contents of the site and a Workow conceptual model for representing interactions of dierent types of users of the site. Detailed design is based on extensions of hypermedia design techniques and allows semi-automatic derivation of the structure of the Web pages from the conceptual schemas. 1 Introduction The last few months have seen an unprecedented phenomenon which has taken many organizations, both public and private, as well as individual users to provide information in the context of the World Wide Web [2]. The World Wide Web provides standards for representation of multimedia information and protocols which allow access and navigation to multimedia documents in the Internet. In many organizations, the design of Web pages has been based on a bottom up approach, both from the requirements collection and from the construction point of view: the decision to provide information is made, the design (and graphical presentation) of single pages is the focus of the work, and then pages are linked to each other based on case by case decisions. On the other hand, in most WWW applications, and in particular within organizations, the type of information provided in a Web site is based on organizational data, in many cases already stored in an existing information system or, at least, available on paper. While for designing the computer supported information system of an organization is quite established the use of a systematic approach, in the case of Web sites such an approach is not a common practice. The result of a lack of a systematic approach to designing WWW sites is the well know diculty in navigation, in retrieving the required information, and one of the consequences is the mostly navigational and "surng" approach to the use of the Web. In the past, a similar problem has emerged in the eld of

2 designing conventional hypermedia applications, resulting also in that area in poorly designed applications and in diculty of use of such applications [4, 7]. In recent times, some proposals have emerged for a systematic design of hypermedia applications. The rst proposal has been HDM [8], based on a semantic model of information in the application and the study of navigational patterns. HDM has been developed in subsequent approaches, e.g. OOHDM [11], based on an object-oriented approach to multimedia applications design and RMM, starting from entity-relationship schemas in the rst design phases. All these approaches focus on the data to be presented, and on establishing links between data for navigational and presentation purposes. The importance of data modeling is widely recognized in hypertext design [9, 8]. In HDM [8], for instance, the hypertext is modeled through an application schema, describing classes of information elements according to common presentation characteristics, internal structure, and mutual interconnections. HDM is very close to a relational model, and there is often a 1-1 mapping between entities and classes of information elements. In general, these methodologies try to achieve a navigational schema, i.e., a graph in which nodes represent pages (or group of related pages), and oriented arcs represent monodirectional links between pages. Methods and techniques proposed for designing hypermedia applications can also be applied to the design of Web sites (such as, for instance, in [1], based on RMM). However, in the design of such applications the representation of dynamic aspects is limited to the consideration of navigational aspects. Many Web sites are instead providing also facilities to users which are typical of applications developed for information systems, and in particular for systems in which the user is following predened patterns of interaction. Such cases include order processing and conference registration, for instance. The trend to provide such services through the Internet and Web sites is growing, and is going to be very soon coupled with the interaction with existing organizational information systems. Architectural proposals for this purpose are being discussed [10], and some prototypes and commercial products are emerging. While the eort of the product side is increasing, the design and development of applications is still following the bottom up approach described above, still resulting in site with poor functionalities and presentation characteristics. In the present paper, we advocate the use of a methodological approach to the design of a WWW application. We base our approach on the integration of techniques adopted for data conceptual modeling, Workow conceptual design, hypermedia design, structuring the approach in dierent phases, considering conceptual and functional aspects rst, and then systematically deriving the structure of the site and of single Web pages from the initial conceptual design. The problem of separating information to be provided directly to the user and information which is at the basis for interaction, but not necessarily explicitly shown to the user, is discussed. The approach is illustrated discussing the realization of a site for distance education under development at Politecnico di Milano. The paper is structured as follows. In Section 2, we present our approach to

3 the development of Web sites, and we present the case study for the development of a course on database systems for distance education. In Section 3, the Requirements analysis phase and requirements specication using ER and WF conceptual models are discussed. In Section 4, the derivation of the structure of the Web site and design in the small of Web pages are illustrated. 2 A systematic approach to design and development of WWW applications A systematic approach to information system design has been advocated and resulted in several design methodologies and models [5]. Such methodologies traditionally concentrate on the rst development phases, to capture the static and dynamic aspects to be supported by the information systems. From several points of view, the development of a Web application has many characteristics in common with traditional information systems. On the other hand it has also many aspects typical of conventional hypermedia applications. New characteristics are anyway typical of Web applications: { the diculty of characterizing the users which are going to access the application, with the exception of the case in which the user community is restricted as a requirement of the application; also in these situations, access is usually mixed, partly open to any user, and partly restricted; therefore an analysis of the expected user community is needed. { the variety of access interfaces, which are not under control of the application developer, and have to be taken into consideration in order to provide an adequate user interface to most frequent users. This particular problem is typical mainly to Web applications, and it is subject to a continuous evolution of the available interfaces. { the possibility of performing coordinated work through the Web, with some predened interaction patterns for some types of users. While this is an aspect common to many information systems, the particular characteristics of the interaction modes make the problems similar mainly to those encountered when developing Workow applications, with the dierence of the type of environment, which is usually closed in Workow applications, and open for Web applications. A design methodology to develop Web applications taking into consideration all these dierent aspects is essential in order to create applications fruitful to a great number of users, possibly visiting a site with dierent purposes and dierent technological capabilities. Some advantages of having a well dened methodology are: { Abstract conceptualization: the developer can focus on the meaning of the contents and of the relations between data, avoiding the analysis of implementative issues, misleading in an early design phase. Furthermore, it reduces the risk of inconsistencies in the application.

4 { Interaction with the users: when users types are identied, the use of a high-level language can help the designer in understanding user requirements. { Design for change: a high level modelization helps Web site maintenance. In particular, it forces the addition of new pages to follow the conceptual structure of the site, avoiding adds-on in a somewhat random manner. { Systematic development process: starting from an abstract conceptualization, the methodology suggests how to derive the implementation in terms of single Web pages. This process can often be supported by automatic tools. In developing on-line courses, the use of a well dened methodology is perhaps even more important than in ordinary Web applications. The focus here is not on attracting the greatest possible number of persons to visit the site, but to oer a clear, logical structure to present the available material, without risking to loose the visitors in insignicant details or links which distract the attention of the user from the educational goals. The methodology we propose has the purpose of keeping the design of Web sites at the highest possible level of abstraction, to force the developer to deeply analyze all conceptual issues before addressing low-level topics such as links between HTML pages. Rather than introducing new models and symbols, we reuse existing, consolidated representations (in particular, E-R to describe data and a Workow conceptual model to describe the processes) that are familiar also to people not concerned with Web design. This is a crucial point in the understanding of the application requirement and of the relations among the dierent parts of the application data. In addition, particular emphasis is put on the analysis of the characteristics of the expected user population, and in the semi-automatic derivation of Web pages. The methodology consists of the following four steps: 1. Analysis of requirements: the objectives of the site are dened. In particular, an analysis of the possible users and of their needs is carried out. 2. Specications of requirements: Requirements include the modeling of the user that visit the site, the representation of the data which constitute the contents of the site and of the data needed to process requests to the Web site (we will call this type of information administrative data in the following), the representation of the patterns of user interaction of the sites, in particular when the WWW application is not limited to providing navigational access. 3. Design in the large: the structure of the Web site is derived from the models dened in the specication phase. 4. Design in the small: details concerning pages and links are dened. In the following, we describe the case study which has been at the basis of our experimentation of the approach and will be used throughout this paper to exemplify the concepts that will be introduced.

5 2.1 Case Study: A Course on Database Systems The case study concerns the construction of a WWW application for educational purposes. In particular, experimentation has been performed on database courses, but the approach to the site design has been generic with respect to the type of course to be supported. Available course material includes a set of slides, taken from lessons at universities, summer stages, or seminars. The main objective is to give students a complete course on database systems, including basic concepts as well as advanced issues; we only assume that the reader has a basic computer science literacy. Users will mainly be part of the computer science degree course, but students from other degree courses, or graduates, may be willing to participate as well. The Web site should provide dierent access paths, targeted to the students' needs. At the end of every lesson module and at the end of the course, some tests and exercises will enable the student to evaluate his learning. This should be achieved mainly through automatic correction. It is also planned that a tutor will be assigned to every registered student. The tutor is required to answer to students' questions and to review exercises that cannot be automatically corrected. Among the objectives of the Web site there is support to instructors and researchers. In particular, researchers should be able to nd, in the advanced section, materials on some hot research topics, as well as pointers to papers and other material. The following sections will contain references to this case study, detailing how each part of the methodology has been applied to the design of the course on database systems. 3 Requirements Analysis and Specication 3.1 Requirements analysis Analyzing the site objectives and dening possible users is the very rst step of the design. In particular, there is the need of segmenting all potential visitors, in order to understand the information and the functionalities to be provided for each category. Segmentation is performed according to two dierent criteria: background/objectives and non-functional requirements. Background/objectives segmentation This segmentation has the purpose of determining which views of the existing material should be proposed to which visitor. By segmenting possible users (just like as market segmentation in a marketing development strategy), the designer can analyze the characteristics of the visitors, and can oer a personalized access to each segment. The segmentation process can be multilevel: at rst, users are segmented according to a certain factor (e.g., the degree course of a student). Then each of the segment is further

6 divided into smaller groups by segmenting according to other factors (e.g., year in the degree course, or the attendance to a specic course). In this way the designer obtains a segmentation tree. At the end of the process, the leaves will represent the dierent categories for which the designer may want to oer a personalized access path. Below the rst level, some factor could further divide only some of the nodes at a certain level. It is not required that dierent views be provided for every node of the segmentation tree: for some branch of the tree the designer could decide to provide personalization only to a certain level, considering unnecessary to go deeper. The goal of this phase is to identify the objectives and needs for each user prole, and to group the dierent users proles in homogeneous groups with respect to common goals. Personalization can often be dened in an incremental way, descending the tree towards the leaves. For instance, the designer could dene access for students of Politecnico di Milano, and then add to that some functionalities available only for computer science students. In the database course example the segmentation is shown in Figure 1. At the rst level, users are divided into students, researchers, instructors, and tutors. With respect to instructors, users interested in database technology are handled dierently, since they may whish to download or upload course material. Students are further divided according to their university (Politecnico di Milano or other universities). This is because students from Politecnico can receive a 'direct' assistance, and the course can be better tailored since their background is known. Further segmentations include, for Politecnico students, their background in terms of other courses already taken by the student, and for other students their background in database systems. Tutors are a very particular kind of user: they are not interested in accessing the course, but rather on interacting with students. Their view will therefore be focused on students' exercises and questions. Researcher sand tutors are not segmented further. Non-functional requirements For non-functional requirements, the segmentation process should relate hardware and software requirements, and connection speed. Hardware and software greatly dier when dierent countries are considered. Problems for connection speed are even higher. If we just want to serve students of our college on campus, we can expect fast connection with up-todate, graphical browsers including the required helper application. It is therefore possible to use advanced multimedia features, and even non-standard HTML or Java. In the general case, however, dierent access modalities should be provided for dierent clients. In particular, it is wise to provide pages readable by textual browsers and to make available some sub-courses for downloading, in order to be viewed locally. This kind of segmentation is often orthogonal to the background/objectives one. Sometimes, however, they may be related, such as when considering students of a dened faculty. Figure 2 shows the segmentation for non-functional requirements in our case study.

7 Visitor Instructor Researcher Student Tutor of DB courses others from Politecnico di Milano from other universities followed course CS1 followed course CS2 followed course CS2+Op.System No DB knowledge Basic DB knowledge Good DB knowledge Fig. 1. Multilevel segmentation for the DB course case study Europe, USA, Australia, Japan Connection speed from universities or institutions: 512 kbit/s or higher Connection speed from home: 28 kbit/s or ISDN Client type/power: graphic terminal, high processing capabilities, and advanced browser type with several media players. Other countries Connection speed from universities or institutions: 64 kbit/s or higher Connection speed from home: Various (from 1200bit/s to ISDN) Client type/power: graphic or textual terminal, sufficient processing power Browser : from textual to advanced Fig. 2. Connection segmentation for the DB course case study

8 3.2 Requirements Specication As mentioned in Section 2, requirements specication focuses mainly in representing the following characteristics: { data specication: information to be provided and administration data { process specication: patterns of interactions with the WWW application. Data Specication Setting up a Web site always requires a careful organization of the available data. A bad (or missing) data modeling often results in a bad organization of the course, which causes disorientation in the users. Modeling with the E-R model helps to understand the structure of complex data, and therefore helps in structuring its access by users from the navigational point of view. In particular, courses are usually characterized by a great amount of heterogeneous material. It is essential that the data have a clear and dened logical organization, otherwise the visitor will get lost in the Web due to disorientation problems. In designing on-line courses, along with lectures data that will form the pages, an important role is played by 'back-oce' or administration data, that is, information on student visits. This information must be tightly coupled with the course contents, in order to provide a 'personalized' access to students and to monitor the site by instructors and tutors. Student data are composed by static and dynamic information. Static data are those requested to the student as he visits the site for the rst time and lls in the registration form containing personal data (name, university, faculty, ), cultural background on course related topics, and objectives. Relating static data, personalization means suggesting the appropriate course or access path, or perhaps refusing the visitor until he follows some preliminary lessons. Dynamic data are those related to student visits. They include followed lessons and exercises, and in particular the results obtained in these exercises. Dynamic data bring to dynamic personalization, in which dierent lessons (or, in general, dierent actions) are suggested to the student every time he logs in or after every exercise. Typically, after an exercise is badly executed, the system could suggest to follow again a specic lesson, or to refer to the tutor. In determining the contents of the pages and the navigational structure, student data must be handled dierently from course data. Most of student data must not be directly mapped into HTML pages: on the contrary, they could not be displayed at all. Usually these data are used to generate pages (or set of related pages) on-the-y. For instance, in the database course example, student data are used to generate a page containing exercises results, topics in which the student needs another lesson, and pointers to these lessons; this page could be generated and displayed every time the student logs in. Another type of data is system data, in particular concerning statistical and historical analysis. This kind of data is usually weakly integrated with lectures and users data, and is mostly accessed by the webmaster. Figure 3 shows the

9 E-R diagram of the database course case study. In the gure, entities related to administration data are represented by shaded rectangles. Process Specication Modeling the user access to the application is a basic step towards building a Web site focused on user needs, removing in these early design phases the constraint given by the implementation. Rather than starting the design of a Web site from the modelization of pages and of links between pages, in fact, our methodology derives physical links among pages from higher level models, as will be shown in the next section. In fact, starting a project from the navigational structure has some major drawbacks. The problem is that the attention of the designer focuses on determining what are the possible links among available data. In this link-driven approach, often it happens that the visitor has too much (or too limited) freedom of navigating through data. In on-line courses, this is an even bigger problem since the student might be tempted to 'surf' on the sea of available material rather than eectively follow the lessons. Limitation of accesses in this type of applications is in fact recommended. In our methodology, therefore, the link structure and other connection dependent issues are considered a design problem and therefore examined in a following phase. In customer-interaction specication at the conceptual level (student interaction design in this case), the designer focuses on trying to determine what could be the most eective student behaviour. User behaviour may be specied by using Workow conceptual models. These models allow describing at the same time, and inside the same model, both manual action and automatic actions (such as database updates). A Workow is a computer model of a process in the real world. It is composed of tasks, that represent actions (either manual or automated actions). Tasks are executed in the order specied by the ow description. Connectors are used to dene possible routing paths among tasks. By using Workows, the designer can use the same representation to manage high-level and low-level issues, easing the process of deriving low-level description from abstract ones. In this early design phase, the designer should model the behaviour of the student following the course independently from the specic aspects of the Web server connection. This forces the designer to try to capture what would be the desired, ideal student Workow. Figure 4 oers an example of this modelization according to the model described in [3]. The Workow presents the student view to accessing a database course (we assume all students will have access to the material according to this pattern; dierent pages will be shown to dierent student proles when necessary); as the Figure shows, the student rst register himself, and then chose the course he wants to take (the server will suggest some choices, depending on the student's background). When a course has been chosen, the student accesses (sequentially) the course lesson modules, from the rst to the last. modules are composed of slides, that must be read sequentially as well. At the end of a lesson module, and at the end of the whole course, the student will is proposed some

10 Tutor 1,1 Related 1,1 to Course Related to 0,n Made of 1,n Student 0,n 1,n 1,1 Related to Module 1,n Made 1,1 of Slide 0,n 1,1 Did Related to Proposes 0,n 1,n 1,1 Instructor Course 0,n 1,1 (t,o) Completed 1,1 Completion 0,n of 1,1 Proposes 1,1 0,n Evaluation of Fig. 3. E-R diagram describing DB course data

11 Register Choose Course Read Module Read Slide more slides skip exercises lesson is over do exercises Choose & Do s TASK skip exercises course is over do exercises more lessons CYCLE, CYCLE CONDITION CONDITIONAL FORK JOIN Choose & Do Course s START/STOP SYMBOL More courses No more courses Fig. 4. WF representing the student conceptual visit

12 exercises (which he can skip, if he wants to). Finally the student may decide to take another course, or just leave the DB course. 4 Design This section describes how the process and data models can be used as an input to determine the structure of the Web site. The design of a Web site is generally composed of two phases: { design in the large: the overall structure of the Web site is described by high level models, that describe links between logically related groups of information. Details of the implementation are not described in this phase. In Section 4.1 we show how it is possible, starting from the E-R diagram, and with the guidelines given by the workow representation, to progressively derive a description of the navigational schema (a schema that describes groups of logically related information, as well as access modalities (e.g., through an index or a dened path) to this information) and a HDM description of the Web site (a hierarchical description of links connecting the dierent information elements). The result is the basic structure of pages and links between pages for the Web site. { design in the small: the detailed project of the HTML pages is performed. An analysis of design in the small techniques is outside the scope of this paper. 4.1 Deriving the Navigational Schema The purpose of this subsection is to describe a methodology that allows the derivation of the navigational schema starting from the E-R and workow models. We will mostly borrow the syntax from RMM [9]. In RMM, an RMDM (Relation Management Data Model) diagram is obtained as the result of the design, starting from an E-R description of the data. The extended RMDM diagram proposed in this section includes the entities dened in the E-R along with (directed) links among entities derived from relationships in the E-R schema and dening the navigation patterns between entities. We extend the RMM notation allowing the denition of triggers as a type of link that can be dened to access entities, besides purely navigational links. Links of the following types can be dened: { menu: information represented by the entity can be accessed via a menu; { sequence: information represented by the entity can be accessed in a sequential way, controlled by the server, from the rst to the last item; { trigger: Triggers denote actions, that represent interfaces between contents (course) data and administrative data. Actions corresponds to services offered by the Web server.

13 Besides entity and links, the RMDM also include an entry point, representing the home page of the Web site. In the DB course, for instance, we want to access courses by a menu, while lessons in a course are accessed in a sequential way. The execution of an exercise is represented, in the diagram, by a trigger between exercises and completed exercise. The RMDM derivation process takes advantage from the fact that the WF specication shows how a student accesses the dierent parts of the course. These access modalities are represented in the workow description respectively by tasks representing user choices or by cycles; therefore, the transformation of choices and cycles in the workow into the appropriate access to an entity in the navigational schema is the main aspect of the derivation process. An algorithm for the semi-automatic derivation of an extended RMDM diagram from the E-R and WF schemas is dened. The algorithm analyzes the tasks in the workow: every task corresponds to a (possibly null) operation on the RMDM diagram, dening the type of navigational links between entities. The characteristics of a task relevant to the algorithm are: { Name: a string in natural language { Type: every task can be subdivided into: access tasks, describing the access to information (e.g., 'Read lesson Module') choice tasks, describing access performed through menus (e.g., 'Choose Course') action tasks, describing actions performed by the visitor (e.g., 'Register') { Predecessor: the workow object connected as an input to the task. It can be another task, a join, a cycle, a cycle condition, a conditional fork, or the start symbol. { Entity: the entity in the E-R associated to the task. For instance, tasks 'Choose Course' and 'Read Module' are associated respectively to entities Course and Module. Some tasks could have no associated entities (e.g., 'register' to the course Web server). For every task we can therefore dene four functions name(task), type(task), predecessor(task), and entity(task) returning the task's name, type, predecessor, and associated entity. In particular, function entity bridges the workow representation to the RMDM one, since the entity is an object of the RMDM diagram. Relevant characteristics of connectors are the type (that can be conditional fork, cycle, cycle condition, or join), and the set of predecessors. Unlike tasks, some connectors (namely the joins) may have more predecessors. As for the task, we can dene for connectors the functions type(connector) and predecessor(connector). Based on the denitions above, we introduce the function predecessorentity, that will be used by the algorithm. The function examines recursively the predecessor of a task, until tasks to which an associated entity exists are found.

14 The function receives a task or connector as argument, and returns a set of predecessor entities (PEset). The function is described in pseudo-language as follows: predecessorentity(object): if predecessor(object)='start' then add_to(peset, 'Home'); return; endif for every object O in the set predecessor(object) do: if entity(o)<>null add_to(peset, entity(o)); // adds an element to a set else add_to (PEset, predecessorentity(o)) endfor endprocedure The RMDM generation algorithm examines the tasks in the workow that have an associated entity); for each of these, it links the associated entity with the predecessor entities in the appropriate way, based on the predecessorentity function. Tasks with no associated entity are not considered in this transformation, since they relate access to information not included in the E-R modelization, and that is therefore outside the logical structure of the site. Links are added to the RMDM diagram with function link, that receives in input the two entities to be linked and the link mode (via a direct link, a menu access, a sequential access, or a trigger). For every task T in the workflow do if entity(t)<>null and type(t) <> action then if type(predecessor(t))=cycle and cycle condition is determined by the system then linkmode=sequential else case type(t) of access : linkmode=direct; choice : linkmode=menu; endcase endif PEset=predecessorEntity (T); for every entity E in PEset do link(e, entity(t), linkmode) endfor endfor For instance, consider task 'Read Module'. The predecessorentity function for this task would return a set containing only the 'Choose Course' task, whose associated entity is 'Course'. The link mode for the entity is sequential, since the task is preceded by a cycle whose condition is determined by the system. On the other hand, considering the 'Choose Course' task, the only

15 predecessor entity is the home symbol, and the access is via a menu, since the task is a choice task. Figure 5 represent the RMDM-like diagram for the DB course example. The gure also include links derived from the application of the algorithm to other WFs, describing the instructor, the tutor, and the server, which are not described in this paper. 4.2 Deriving the HDM representation The RMDM-like representation can be used as an input to determine lower-level representations. This section shows how the RMDM can be used to derive a HDM description of the web site. HDM underlines the hierarchical structure of links (that is somewhat hidden in the RMDM), in a way closer to the actual Web implementation. A hierarchy among entities can be determined, from the RMDM, by following the links starting from the home page symbol: entities directly connected to the home symbol are at level 1, entities connected with level 1 entities are at level 2, and so on. If entities can be reached by dierent paths, they are assigned the lowest possible level number. In the HDM the hierarchy is made explicit by representing entities and links among entities at dierent levels. The top level diagram describes links among level 1 entities giving the overall view of the Web site; other diagrams describe the structure of the links departing from entities placed at a higher level in the hierarchy. If the home symbol brings to only one entity, the top-level diagram coincides with the level 1 diagram. The derivation of the HDM proceeds as follows: A diagram is built for every entity that is connected to some other entity with a higher level number in the hierarchy. Relating an entity, the links spawned by that entity in the RMDM are considered. Links among entities are translated according to the access type: menu accesses from an entity to another are translated through a line with an asterisk. Sequential accesses are translated into connections to the rst item of a sequence, which is then connected to the successors by a dotted line (usually only the rst and last item are drawn). Figure 6 describes examples of translations that bring from the RMDM to the HDM. Only links bringing to entity with a higher level number are considered. This oer a modularized view of the Web structure, starting from the top level diagram to the bottom ones, at an increasing level of logical detail. In the DB course example, level 1 diagram is drawn by looking at entity is 'Course', which is linked to 'Course ' and ' Module' (see Figure 7). As it can be seen, in HDM diagrams some additional low-level information elements not represented in the E-R are also introduced (e.g., Introduction in both gures, with information on the course and on the lesson module respectively). Figure 8 represents the HDM relating the ' Module' entity.

16 Tutor Exchange mail with students folllowing the Course Menu Course Register student to Sequence of s Student Module Sequence of Slides Slide Course Menu Menu Sends message proposing Instructor Course (t,o) Submit Completed Compare Sends message proposing Legenda: Home Access via a menu Sequential Access Trigger (services offered by the Web server) Fig. 5. RMDM-like description of the integrated navigational schema

17 Module Module Menu Translated into * s (a) Module Module Translated into Sequence of Slides Slide Slide1 Sliden (b) Fig. 6. (a) - RMDM to HDM translation of the menu access; (b) - RMDM to HDM translation of the sequential access

18 Course * Introduction Course s Module 1 Module n Fig. 7. HDM schema - level Design in the Small The HDM description can be used to derive the structure of single HTML pages. While a description of design in the small techniques is outside the scope of this paper, we note that HDM is useful in dening links among information elements, and in explicating the structure of pages introducing the dierent information elements. For instance, the diagram of Figure 8 suggests that the page presenting a lesson module should include an introduction, and links to the rst slide and to lesson exercises. 5 Concluding remarks A methodology and systematic development techniques for the design and implementation of Web sites have been presented in the paper. Initial design phases are

19 Module * Introduction s Slide1 Sliden Fig. 8. HDM schema - level 2. Module based on conceptual design, and in particular on conceptual data modeling and on specication of interactions with dierent types of users through a Workow conceptual model. Particular attention has been paid to the problem of analyzing the characteristics of the population which is the target of the site. Segmentation criteria have been proposed for analyzing functional and non functional requirements of the population. Design techniques have been oriented towards a systematic derivation of Web pages from the conceptual schemas obtained in the rst phases. A case focusing on supporting interactions with database course students has been discussed. Future work will concentrate in providing a design support environment for the development of new applications. Tools to develop new courses based on the available schemas will be realized. In addition, advanced development environments focusing on the semi-automatic derivation of the structure of the Web pages from conceptual schemas will be experimented and integrated with available tools supporting Web pages production and with a DBMS to store WF support information. Acknowledgements Part of this work has been supported by a scholarship by Hewlett-Packard for the design of a WWW site supporting advanced database courses.

20 References 1. Balasubramanian, V., Min Ma, B., Yoo, J., A systematic approach to designing a WWW application, Communications of the ACM, August Berners-Lee T., Cailliau R., Luotonen A., Nielsen H., Secret S., the World Wide Web, Communications of the ACM, August Casati F., Ceri S., Pernici B., Pozzi G., \Conceptual Modeling of Workows", Proc. of the Object- Oriented and Entity-Relationship Conf., Gold Coast, Australia, Communications of the ACM, Special issue on Designing hypermedia applications, August Olle T., Hagelstein J, Macdonald I., Rolland C., Sol H., Van Assche F., Verrijn- Stuart A., Information Systems Methodologies, edited by Allison Wesley 6. Ellis C., Nutt G., \Modeling and Enactment of Workow Systems", in Application and Theory of Petri Nets, M. Ajmone Marsan Ed., Lecture Notes in Computer Science 691, New York: Springer Verlag, Garzotto F., Mainetti, L., Paolini P., Hypermedia design, analysis, and evaluation issues, Communications of the ACM, August Garzotto F., Paolini P., Schwabe D. HDM: A Model Based Approach to Hypertext Design Application Design, ACM Transactions on Information Systems, January Isakowitz T., Sthor E., Balasubramanian P. RMM: A Methodology for Structured Hypermedia Design, Communications of the ACM, August Perrochon L., W3 Middleware: Notions and Concepts, 4th WWW International Conference, Boston, Dec Schwabe, D. and Rossi, G., The object-oriented hypermedia design model, Communications of the ACM, August This article was processed using the LaT E X macro package with LLNCS style