Analysis and Design of Web-based Information Systems

Origin site: Analysis and Design of Web-based Information Systems

Abstract

We have developed a method for analysis and design of Web-based information systems (WBISs), and tools to support the method, WebArchitect and PilotBoat. The method and the tools focus on architectures and functions of Web sites, rather than on appearance of each Web resource (page), such as graphics and layouts. Our goal is to efficiently develop WBISs that best support particular business processes at lowest maintenance cost. Our method consists of two approaches, static and dynamic. We use the entity relation (E-R) approach for the static aspects of WBISs, and use scenario approach for the dynamic aspects. The E-R analysis and design, based on relationship-management methodology (RMM) developed by Isakowitz et al., defines what are entities and how they are related. The scenario analysis defines how Web resources are accessed, used, and changed by whom. The method also defines attributes of each Web resource, which are used in maintaining the resource. WebArchitect enables designers and maintainers to directly manipulate meta-level links between Web resources that are represented in a hierarchical manner. PilotBoat is a Web client that navigates and lets users collaborate through Web sites. We have applied our approaches to the WWW6 proceedings site.

1. Introduction

Recently Web-based information systems (WBISs) are attracting significant interest among business process practitioners as flexible and low-cost solutions to distributed collaborative work. "Intranet " is a typical targeted environment for WBISs. A WBIS not only disseminates information, but also proactively interacts with users and processes their business tasks to accomplish their business goals. Thus, analysis and design of WBISs need an approach different from those for Web sites that mainly provided information uni-directionally on users' requests, such as catalog, directory, and advertisement sites. There is a lot of work on graphical and user-interface aspects of Web site design [Nielsen, 1995; Sano, 1996]. They emphasis visual design of each Web page but do not provide a systematic way of designing logical structure of Web sites as a whole. There are also design methods of Web sites, such as OOHDM [Schwabe et al, 1996] and RMM [Isakowitz et. al, 1995]. These methods are useful in formally modeling kiosk-type applications to navigate users to desired information in a systematic manner. However, for users of WBISs, access to a particular piece of information is only one part of their business goals. They also need to process business data and communicate and collaborate with colleagues by using WBISs. These formal modeling approaches do not answer important questions in analyzing and designing WBISs, such as "Whether and how do users accomplish their business goals using WBISs?" "How do WBISs process and respond to users inputs?" and "How do users interact with other users via WBISs?" Maintenance is also a very important issue as Web sites become larger. However there id very little research on maintenance of Web sites, although there are several commercial tools, such as WebAnalyzer(tm) developed by InContext Corp. These tools are useful in identifying broken links and other problems in existing Web sites but do not provide a solution to or a way of avoiding the problems. As software engineering research reports [Boehm, 1981; Davis, 1990; Humphrey, 1989], maintenance cost can be dramatically reduced if errors are detected in the analysis and design phases and the maintenance procedure (i.e. when and who changes what) is defined in the early phase.

We propose a method for analyzing and designing WBISs, and describe WebArchitect and PilotBoat, tools to support the method. The method and the tools focus on architectures and functions of Web sites, rather than on appearance of each Web resource (page), such as graphics and layouts. In other words, our concern is with what Web resources contain, and how they are linked each other, and best managed to support particular business processes at lowest maintenance cost.

Our method consists of two approaches, static and dynamic. We use the entity relation (E-R) method for static analysis and design of WBISs, and use scenario method for dynamic analysis and design. The E-R method, based on relationship management methodology (RMM) [Isakowitz et al., 1995], defines what entities are and how they are related. The scenario method defines how Web resources are accessed, used, and changed by whom. The method also defines the attributes of each Web resource, which are used in maintaining the resource.

WebArchitect enables designers and maintainers to directly manipulate meta-level links between Web resources that are represented in a tree graph. PilotBoat is a Web client that navigates and lets users collaborate through Web sites. We have applied our approaches to several Web site development projects, including the CommerceNet Web site and WWW6 conference site. Throughout this paper, examples for development of the WWW6 conference site will be used. The conference site is a typical WBIS, which provides various services for a variety of users, such as on- line registration for attendees, agenda tracking for the organizing committee, and interactive discussions of papers between authors and readers.

2. A method of analysis and design of Web sites

Our method for analysis and design of WBISs consists of the following activities: E-R analysis, scenario analysis, architecture design, and attribute definition (Figure 1). First, the problem domain, where a WBIS is expected to operate, is analyzed by E-R analysis. Next, scenario analysis determines how potential users interact with the WBIS to accomplish their business goals. Based on the results from these analyses, the architecture of the WBIS is designed. Then attributes of the Web resources that consist of the WBIS are defined for maintenance. The WBIS is constructed based on the design. Finally, the WBIS is tested using the scenarios and introduced into the work place. It continues to be maintained and revised after the introduction throughout its life time.

Figure 1. A flow of analysis and design of WBIS

2.1 E-R Analysis Of Problem Domain

A given problem domain is analyzed to understand the domain and determine the scope of the target WBIS by entity-relation (E-R) analysis. Entities are identified and relations between them are established. The entities and their relations are the basis of the WBIS structures. Entities are categorized into three types: agent, event, and product. We categorize them because the categorization enables us to capture and handle the dynamic nature of WBISs (i.e. "who produces what"), and to define and manage attributes specific to each type in maintenance. Agents are entities that act on and affect other entities, including organizations or groups (e.g., a company) and individuals. For example, the Organizing Committee is an agent in the WWW6 conference problem domain. Events are those which agents schedule and conduct, including meetings. For example, an Organizing Committee meeting is an event. Products are those produced by agents and resulting from events. For example, the minutes of Organizing Committee meeting is a product. In short, an agent conducts an event that result in products (e.g., the organizing committee has a meeting that is recorded in minutes). This analysis can be conducted based on precedent requirements analysis.

Results from the analysis are represented in extended E-R diagrams in which agents, events, and products are depicted differently. Figure 2 shows an E-R diagram for the WWW6 conference.

Figure 2. An E-R diagram for the WWW6 conference
(A larger figure is here.)

2.2 Scenario Analysis

Following the E-R analysis, scenario analysis is conducted to identify who are potential users, what Web resources they need, how they visit and use the resources, and how WBISs respond to the users to achieve the users' goals. Scenario analysis is a well-accepted practice in the software engineering field [Anton et al., 1994; Dardenne, 1993; Potts, 1995; Potts et al., 1994]. We apply this technique to the analysis and design of WBISs, which is a kind of software system. The scenario analysis is conducted as follows: first, the users' goals are identified. Then scenarios are scripted to describe how to accomplish each goal in different situations. For example, three different scenarios are identified for a goal of users of the WWW6 conference site to read and discuss a paper: (1) for registered attendees accessing from the conference homepage (Table 1), (2) for non-registered users finding the paper by using an outside search engine, and (3) for registered attendees accessing from the program homepage and planning their schedules. A scenario is represented in a table, where each row represents a step in the sequence of a scenario. A row (step) has three types of columns: an agent, action that the agent takes, and Web resources involved in the action.

Scenario analysis and architecture design (described in the next section) are complementary and conducted concurrently with close cross-checks. Scenario analysis elicits navigation paths and Web resources needed to accomplish users' goals. These paths and resources become building blocks in the architecture design. Once the architecture has been designed, it can be validated by going through the scenarios. Through the analysis and design, entities and relations in the E-R diagrams are transformed into corresponding Web resources and navigation links in the architecture, respectively.

Programs that process users' tasks, such as CGI and Java(tm) applets, are also designed based on the scenarios, as in scenario-based software development [Rubin and Goldberg, 1992]. In the testing phase after construction of WBISs, scenarios are used as test cases.

Table 1 shows a scenario for the WWW6 proceedings site, which is called "Hyperproceedings". Hyperproceedings uses HyperNews developed at NCSA and lets users discuss papers via Web using net news systems. In this scenario, a registered attendee reads and discusses a paper with one of the authors by using Hyperproceedings. He accesses the paper from the conference homepage, reads and discusses it, and schedules himself to attend the paper presentation.

2.3 Architecture Design

Based on the scenario analysis, architectures of WBISs are designed and represented in an RMDMW (Relationship Management Data Model for WBISs) diagram. RMDMW is again based on RMDM [Isakowitz et al., 1995] and enhanced to differentiate agents, events, and products. RMDMW diagrams are evolved from the E-R diagrams. This evolution includes transforming entities and relations in E-R diagrams into Web resources and navigational links, respectively. Here designers determine (1) the navigation methods employed by users to access Web resources, and (2)ways to map the navigation methods to Web resources. There are three navigation methods: guided tour, index, and indexed guided tour. A guided tour navigates users through a series of linked resources. An index is a set of links to related resources. An indexed guided tour is a mixture of the two methods. For example, we use an index for comments on papers in Hyperproceedings. These methods are fully described in [Isakowitz et al., 1995]. A navigation method can be implemented as a part of a Web page or as an independent Web page. The decision is made based on the design policy, and the length of the contents and the number of indexed items linked from the contents. In Hyperproceedings, we implement the table of contents as an independent page, while we embed the index of comments on a paper into the paper page. Figure 3 shows the RMDMW diagram for Hyperproceedings.

Figure 3. RMDMW diagram for Hyperproceedings.

2.4 Attributes definition

Attributes of Web resources are defined for maintenance. There are attributes intrinsic to the type of the resource (agent, product, or event) and those common to all the types. The common attributes are described below. The examples of the attributes value are those of a paper page.

• Title: shows the name of the Web resource (e.g., Psychic Search)


• Managed by: describes who (and/or which program) is responsible for managing the Web resource (e.g., CGI script of Hyperproceedings, Hyperproceedings staff)


• Access right: defines who can read and/or write to the Web resource. "r" means the read access right. "w" means the write access right. (e.g., Hyperproceedings staff "rw", Others "r")


• Created/Modified (when, and by whom): keeps track of records about who created and modified the Web resource. (e.g., 12/9/97 by Kenji)


• Published since: describes when the Web resource is published. (e.g., 3/7/97)


• Expired when: describes when the Web resource expired. (e.g., 4/12/97)


• Version: describes the version of the Web resource. (e.g., published_version_1)


• Derived from: describes Web resource(s) from which the Web resource is derived. (e.g., "submitted_version")


• Relevant resources: refers to relevant Web resource(s). (e.g., Panel, Poster)

2.4.1 Product

The product type of Web resources has the following intrinsic attribute. An example of the attribute value is that of the organizing committee meeting minutes.

• Resulted from: describes the event type resource(s) which the product resulted from. (e.g., Organizing committee meeting)

2.4.2 Agent

The agent type of Web resources has the following intrinsic attributes. Examples of the attributes value are those of the organizing committee of the WWW6 conference.

• Representative: describes a representative of the agent. This is defined only if the agent is a set of agents. (e.g., Benay)


• List of members: lists-agent type Web resources that belong to the agent. This is defined only if the resource is a set of agents. (e.g., Ann, Nick, Kenji)


• Products produced: describes product-type Web resource(s) that the agent produces. (e.g., Organizing Committee meeting minutes)


• Events related to: describes event-type Web resource(s) that the agent is related to. (e.g., Organizing committee meeting)

2.4.3 Event

The event type of Web resources has the following intrinsic attributes. Examples of the attributes value are those of a session in the WWW conference.

• Schedule: describes time and place of the event. (e.g., 3:00pm to 5:00pm on 4/8/97 at room A in Santa Clara Convention Center)


• Status: describes the status of the event - whether it has not started, is in progress, postponed, canceled, or finished. (e.g., not started yet)


• List of participants: lists which agent type Web resources participate in the event. (e.g., Authors, Attendees, Chair) Announced by: describes whether and how the event is announced. (e.g., Program Committee by e-mail to Authors and Chair)


• Reported by: describes who reports the event (e.g., Ann) Organized by: describes who organizes the event (e.g., session chair)


• Resulted in: describes which product type Web resource(s) results from the event. (e.g., WWW6 report)

3. Tool support for development of WBISs

Here we describe WebArchitect and PilotBoat, tools for construction and maintenance of WBISs based on our method. Both tools use meta-level links, which are described in the next section, to relate and manipulate Web resources. Resulting WBISs are also implemented by using meta-level links. We use the WWW6 proceedings site for illustration again. We used our tools in the prototyping of the site architecture, but the version of the site in service is implemented without using meta-level links.

3.1 Meta-level Links and Attributes

A meta-level link establishes a semantic relationship between two Web resources outside of their contents. Types of meta-level links are defined based on their semantics. Thus a navigation link in an RMDMW diagram can be implemented as a meta-level link with the same type name.

Conventionally links are represented by reference anchors (i.e. <a href ...> tags) in HTML files. Because these links themselves are a part of the contents of Web resources, maintainers have to check every resource and fix errors, if any. This makes it very difficult to maintain the integrity of relationships between Web resources in WBISs.

The meta-level link mechanism is our answer to the relation management problem. The mechanism lets users establish and manipulate a relationship between two Web resources from remote sites without the need to access and modify the contents of the resources. The mechanism uses two HTTP methods, LINK and UNLINK, and transmits the link information in LINK header fields of HTTP. The LINK method establishes a meta- level link between two resources. The UNLINK method deletes a meta- level link. Because the mechanism uses only HTTP, users can work on Web resources on remote sites through firewalls with appropriate security provision.

In addition, the meta-level mechanism has two other advantages over HTML links in managing relationships between Web resources:

• (1) meta-level links can relate Web resources that are not written in HTML.


• (2) meta-level links can be obtained faster. This is because clients have to get only headers from servers to obtain meta-level links. Whereas to obtain HTML links, clients have to get the bodies of Web resources from servers, and interpret and extract the links.

For example, a technical paper page is related to the session page (URL: http:// www6program_host/session/search.html) in which the paper is presented by a "Presented in" meta-level link. This link is defined as follows:

Link: <"http://program_host/session/search.html"> rel ="Presented in"

Figure 4 compares the two pairs of the paper and session pages, one linked with HTML links and the other linked with meta-level links.

Figure 4. Comparison of HTML links and meta-level links

Attributes of a Web resource are described in another Web resource that is linked by a meta-level link, whose type is "Attribute." The "Attribute" meta-level links should not be used to represent other relationships and a Web resource has only one "Attribute" meta-level link. For example, the technical paper page has a meta-level link to its attributes resource (URL: http://proceedings_host/tech_paper/tp15.atr) as follows:

3.2 WebArchitect

WebArchitect is a tool for constructing and maintaining WBISs. It visualizes the architecture of a WBIS in a hierarchical manner. It lets users manipulate meta-level links in a WYSWYG way and maintain attributes of Web resources.

Users can construct the architecture of a WBIS by drawing tree graphs based on the RMDMW diagram with simple mouse operations. This results in the overall architecture of the WBIS that consists of Web resources linked with meta-level links that implement the RMDMW relationships. WBISs can be constructed in both top-down and bottom-up ways using WebArchitect. Users construct the WBIS architectures first with empty Web resources and then fill in the body of each resource in a top-down way. In the bottom-up way, they prepare Web resources first by creating Web resources and/or reusing existing ones, and then construct the WBISs by linking the Web resources. Users, of course, can use both ways as needed.

In maintenance, WebArchitect lets users manage the attributes of Web resources in WBISs and revise the WBIS architectures using meta-level link functions. Using WebArchitect users can retrieve, check, and make changes to Web attributes. WebArchitect also notifies users that changes have been made to Web resources or changes does not happen within prescribed periods.

General end users can use the visualized architecture as the navigational aid with appropriate access control. Figure 5 shows the architecture of the WWW6 proceedings site visualized by WebArchitect.

Macro client

Micro client

Figure 5. The architecture of the WWW6 proceedings site visualized by WebArchitect

3.2.1 Architecture

WebArchitect consists of graphical clients and notification agents, and works with enhanced HTTP servers that comprise the targeted WBISs (Figure 6). The servers can handle two methods for meta-level links, LINK and UNLINK . WebArchitect can handle a distributed WBIS, which consists of more than one servers in different hosts. There are two types of clients: macro and micro view clients. Macro clients show an overview of the architecture of a WBIS. Micro clients provide a detailed view of a part of the architecture and functions for manipulating Web resources. The rectangle region in the macro client is displayed in detail in micro clients (as shown in Figure 5). Both views are cooperative- if one view moves or changes, the other view behaves accordingly.

The notification agents monitor the response messages multicasted by the servers using SNP (simple notification protocol) developed by us. If the notification agents detect events specified by users, the agents notify the users of the events via prescribed communication media (e.g., e-mail, beeper, etc.). In the following sections, we describe the functions of WebArchitect.

Figure 6. Architecture of WebArchitect

3.2.2 Visualizing Web architecture

WebArchitect visualizes the architecture of WBISs as tree graphs. We use tree graphs because hierarchy is a basic structure for the architectures of any practical WBISs. Loops, however, are also included in the architecture. We use a "back link" approach, where tree structures are created first and then back links to nodes already created are established as they are detected. WebArchitect visualizes the Web structure in interactive and batch modes. In the interactive mode, it dynamically spreads the tree structure from the Web resource specified by users. In the batch mode, it generates the tree structure from a starting Web resource (e.g., homepage) specified by users to the specified depth.

Users can filter the view of Web architectures by meta-level link types and attributes, such as access rights or publishing and expiration dates.

3.2.3 Manipulating meta-level links

WebArchitect lets users create and change the architecture of WBISs. Users can attach, detach, connect, and move Web resources via drag-and- drop operations in the micro clients. The micro client issues LINK and UNLINK methods to the servers according to operations of the user. Operations on the architecture visualized on the client immediately act on the real architecture stored in the servers. Thus visualized and stored architectures are always the same. For example, if a user moves a technical paper page currently under (i.e., linked to) the "Search" session page to be under (i.e., re-linked to) the "Cache" session page, the following methods are issued inside of WebArchitect:

• (1) UNLINK http://proceedings_host/session/search.html Link: http://proceedings_host/tech_paper/tp15.html; rel = "Presented in"


• (2) LINK http://proceedings_host/session/cache.html http://proceedings_host/tech_paper/tp15.html rel = "Presented in"

(here http://proceedings_host/session/search.html and http://proceedings_host/session/cache.html are URLs for the search and cache session pages, respectively. http://proceedings_host/tech_paper/tp15.html is URL for the paper page.)

3.2.4 Managing attributes

WebArchitect provides functions for managing attributes to support maintenance of WBISs. Users can display the attributes of a Web resource and change their values. Users can also search for Web resources that have a particular attribute value. For example, a maintainer can detect obsolete Web pages by checking out pages that have expiration date attributes earlier than today. Also as described in 3.2.2, maintainers can check out different views for different types of users by filtering the view of Web architectures by access rights. For example, only maintainers can see the "Access statistics" resources of Hyperproceedings. Maintainers also determines how the view of architecture for public users changes over time by defining publishing and expiration dates of the Web resources.

3.2.5 Notification of changes

A user has his/her own notification agent and asks the agent to inform him/her of specific events. Users can know the following events, (1) creation, revision and deletion of Web resources, (2) establishment and deletion of meta-level links between Web resources, and (3) access to Web resources and headers.

The notification agents have two notification mechanism: action-based and time-based mechanisms. The action-based mechanism notifies users when a specified event (e.g., a change to a Web resource) has happened to a specified Web resource. Using this mechanism, members of a development team of a WBIS can be efficiently coordinated and maintain the consistency of the WBIS by knowing what changes other members have made. The time-based notification mechanism can also notify users if a given event did not occur during a specified period. Using this mechanism, a development team can manage the development project in a timely manner by prompting scheduled tasks and by knowing how much of the scheduled Web resources have been developed. The WebArchitect clients themselves also can be notified of the changes in WBISs and renew graphs that they display according to the change.

The event information is multicasted by the WebArchitect servers in real time using SNP. SNP is transmitted over IP multicast, which enables us to send the information to more than one agents and clients in a scalable manner [Kumar, 1995].

3.3 PilotBoat: a Meta-Level link Navigator

PilotBoat is a client to navigate users through meta-level linked Web resources. The PilotBoat client works with existing Web browsers, such as Netscape Navigator(tm), and the meta-level linkable HTTP servers. Users use PilotBoat to handle meta-level links and use existing browsers to display Web pages. PilotBoat can invoke and control Netscape Navigator upon users' requests. PilotBoat clients communicate with each other using IP multicasting to share the same Web resource. Figure 7 shows a screen image of PilotBoat.

Figure 7. A screen image of PilotBoat

PilotBoat has the following functions:

Navigating meta-level links PilotBoat clients display the meta-level links that a Web resource has. Users can visit a Web resource linked with a meta-level link shown in the clients by double clicking it and display the contents of the resource on the Web browser.

Sharing a Web resource Users can set up a shared session using PilotBoat. In the shared session, all the users joining the session will receive the same Web resource from the servers. If one of the users gets a different source, then the others get the same source he/she got so that all the users can have the same resource on their own PilotBoat clients. In such a shared session, if a user asks his/her PilotBoat client to get a Web resource, the client notifies the other clients that it gets the resource and then, prompted by the notification, the others get the same resource.

3.4 Status

We have implemented all the functions described except the sharing function of PilotBoat. The WebArchitect clients are written in Java using SubArctic [Hudson and Smith, 1996]. The enhanced sever is also written in Java using JDK 1.0(tm) developed by Sun Mircosystems. PilotBoat is developed using MetaCard(tm), a product of MetaCard Corporation, and the libWWW library written by Henrik Frystyk Nielsen at W3C.

4. Discussion

There are other approaches to analysis and design as described in Section 1, including formal modeling methods and usability engineering. Our approach is focusing on WBISs, which interactively processes users tasks, and therefore is different from these conventional approaches in the following points:

• (1) it incorporates the scenario analysis to analyze the dynamic interactions among users and WBISs.


• (2) it also supports the maintenance of WBISs.


• (3) it is implemented as tools to enable distributed users to construct and maintain WBISs in a consistent manner using meta-level links and IP multicast-based notification.

Our approach, however, does not support graphic design of Web resources (or pages). Although the graphic design is not within the scope of this paper, it is important and we need to incorporate it to our approach.

5. Future work

We have applied our method and tools to several analysis and design projects followed by informal and qualitative evaluation, but we still need to conduct formal evaluation through the entire life cycle of WBISs. We plan to apply our method and tools to Intranet for our laboratories, which is a WBIS distributed globally among Tokyo, Palo Alto and Atlanta.

WebArchitect should also integrate support for analysis and design with its construction and maintenance support in a seamless manner. Our analysis and design methods extensively use diagrams and tables, which have specific formats. Thus analysts and designers can be more productive by using functions for creating and checking diagrams and tables, which CASE (computer aided software engineering) tools provide. Furthermore a part of the architectures of WBISs can be automatically generated and tested, based on the results from analysis and design in the integrated support environment. We plan to implement such functions for editing diagrams and tables, and for generating WBIS architectures.

Acknowledgments

We deeply thank Kathryn Henniss, SLAC at Stanford University, for her leadership and passion in the WWW6 conference site project. We also thank Benay Dara-Abrams, who is the chair of the Organizing Committee of the WWW6 conference and with Sholink Corporation, for giving us the opportunity to participate in the project. Thanks are due to other Organizing Committee members of the WWW6 conference. It is our pleasure and honor to work with them. Finally, we thank Masafumi Higuchi and Katsuyuki Hasebe, Hyperproceedings project members at NTT MCL, for nicely implementing the site.

References

[Anton et al., 1994] A. I. Anton, W.M. McCracken and C. Potts "Goal Decomposition and Scenario Analysis in Business Process Engineering", Advanced Information Systems Engineering, Proc. 6th Int. Conf. CAiSE'94, Utrecht, Springer-Verlag Lecture Notes in Computer Science, 811, 1994.
[Boehm, 1981] B. Boehm, Software Engineering Economics, Prentice- Hall, Englewood Cliffs, New Jersey, 1981.
[Davis, 1990] A. Davis, Software Requirements : Analysis & Specification, Prentice-Hall, 1990.
[Dardenne, 1993] A. Dardenne, "On the Use of Scenarios in Requirements Acquisition", Oregon Technical Report, CIS-TR-93-17, 1993.
[Humphrey, 1989] W. S. Humphrey, Managing the Software Process, Addison Wesley Publishing, 1989.
[Hudson and Smith, 1996] S. Hudson and I. Smith, "Ultra-Lightweight Constraints", Proc. of ACM Sympo. On User Interface Software and Technology, pp. 147-155, 1996.
[Isakowitz et al., 1995] T. Isakowitz, E. A. Stohr, and P. Balasubramanian, "RMM: A Methodology for Structured Hypermedia Design", Comm. ACM, Vol. 38, No. 8, August 1995, pp. 34-44.
[Jacobson, 1992] Jacobson, I., "Object-Oriented Software Engineering: A Use-case Driven Approach", Addison-Wesley, 1992.
[Karat and Bennet, 1991] Karat, J. and Bennett, J., "Using Scenarios in Design Meetings ÷ A Case Study Example", in Karat, J. (ed.), Taking Software Design Seriously, Academic Press, 1991.
[Kumar, 1995] V. Kumar, Mbone: Interactive Multimedia on the Intenet, Macmillan Publishing, Simon & Schusternet, 1995.
[Nielsen, 1995] J. Nielsen, Multimedia and Hypertext the Internet and Beyond, Academic Press, 1995
[Potts, 1995] C. Potts, "Using Schematic Scenarios to Understand User Needs", Proc. Sympo. Designing Interactive Systems: Processes, Practices, Methods & Techniques (DIS'95), August 23-25, 1995, pp. 247-256.
[Potts et al., 1994] C. Potts, K. Takahashi and A. I. Anton, "Inquiry-based Scenario Analysis of System Requirements", IEEE Software, ??, March 1994, pp. 21-32.
[Rubin and Goldberg, 1992] K. S. Rubin and A. Goldberg, "Object Behavior Analysis",, "Object Behavior Analysis", Comm. ACM., Vol. 35, No. 9, 1992, pp. 48-62.
[Sano, 1996] D. Sano, Designing Large-scale Web Sites, Wiley Computer Publishing, 1996.
[Schwabe et al., 1996] D. Schwabe, G. Rossi, and S. D. J. Barbosa, "Systematic Hypermedia Application Design with OOHDM", Proc. Hypertext '96, 1996, pp. 116 - 128.

URL references

• HyperNews (http://union.ncsa.uiuc.edu/HyperNews/get/hypernews.html)


• libwww (http://www.w3.org/pub/WWW/Library/Activity.html)