Analysis and Design of Web-based Information
Systems
Kenji Takahashi
NTT Multimedia Communications Laboratories
kt@nttlabs.com
Eugene Liang
College of Computing
Georgia Institute of Technology
eugene@cc.gatech.edu
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.
Table 1. A scenario for reading and discussing a paper on the
Hyperproceedings
| No. | Agent
| Action | Web entities
|
| 1 | Registered attendee |
visits the Conference homepage | Conference homepage visited
|
| 2 | Registered attendee |
visits the Hyperproceedings homepage | Hyperproceedings homepage visited
|
| 3 | Registered attendee |
visits the table of contents (TOC) page | TOC page visited
|
| 4 | Registered attendee |
finds the "searching technique" session
| ( "searching technique" proc session index item found)
|
| 5 | Registered attendee |
finds the "psychic search" paper |
( "psychic search" paper index item found)
|
| 6 | Registered attendee |
visits the "psychic search" paper page
| "psychic search" paper page visited
|
| 7 | Registered attendee |
prints out and reads the paper | "psychic search" paper page printed out
|
| 8 | Registered attendee |
visits the trial page to learn how to make comments
| trial page visited |
| 9 | Registered attendee |
returns to the paper page | "psychic search" paper visited
|
| 10 | Registered attendee |
makes a comment on the paper |
|
| 11 | Hyperproceedings | adds the comment to a thread of a discussion
| a new comment page created
a new comment index item created
|
| 12 | Registered attendee |
subscribes himself to be notified of responses to the comment
| |
| 13 | Hyperproceedings | adds Registered attendee to the subscriber list
| a new subscriber entry created |
| 14 | Hyperproceedings | sends Author a comment e-mail
| comment e-mailed |
| 15 | Author | receives and reads the comment e-mail
| |
| 16 | Author | visits the paper page
| "psychic search" paper visited |
| 17 | Author | visits the comment page
| comment page visited |
| 18 | Author | inputs a response to the comment
| |
| 19 | Hyperproceedings | adds the comment to a thread of a discussion
| A new comment page created
a new comment index item created
|
| 20 | Hyperproceedings | sends Registered attendee the response e-mail
| comment e-mailed |
| 21 | Registered attendee |
receives and reads the response e-mail |
|
| 22 | Registered attendee |
finds a link to the presentation session information on the paper page
| |
| 23 | Registered attendee |
visits the session page on the program site |
session page visited |
| 24 | Registered attendee |
stores the presentation information and schedules his personal calendar to attend the presentation
| a new schedule item created |
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:
Link: <"http://proceedings_host/tech_paper/tp15.atr"> rel ="Attribute"
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)
Return to Top of Page
Return to Technical Papers Index