A Generative World Wide Web Object-Oriented ... - Semantic Scholar

A Generative World Wide Web Object-Oriented Model Giovanni Vigna, Francesco Coda, Franca Garzotto, and Carlo Ghezzi Dipartimento di Elettronica e Informazione Politecnico di Milano Piazza Leonardo da Vinci, 32 20133 Milano, Italy [vigna|coda|garzotto|ghezzi]@elet.polimi.it

June 30, 1997

$EVWUDFW 7KH :RUOG :LGH :HE :::  KDV EHFRPH WKH OHDGLQJ WHFKQRORJ\ WR H[FKDQJH LQIRUPDWLRQ DQG LQWHUDFW ZLWK XVHUV RQ WKH ,QWHUQHW:HEVLWHVKDYHHYROYHGIURPVLPSOHXQVWUXFWXUHGJUDSKVRISDJHVWRKXJHFRPSOH[DQGKLJKO\LQWHUFRQQHFWHGK\SHUPHGLD EDVHV 7KLV HYROXWLRQ RI FRQWHQWV KDV QRW EHHQ VXSSRUWHG E\ D FRUUHVSRQGLQJ LPSURYHPHQW RI PHWKRGRORJLHV DQG WHFKQRORJLHV :HE VLWHVGHYHORSPHQWLVFDUULHG RXWLQDQXQVWUXFWXUHGDQG RIWHQFKDRWLFZD\ZLWKRXWDFDUHIXOGHVLJQSKDVHWKDW SURYLGHV D KLJKOHYHO GHVFULSWLRQ RI WKH DSSOLFDWLRQ FRQWHQWV DQG KLJKOLJKWV UHFXUULQJ UHSUHVHQWDWLRQ DQG QDYLJDWLRQ SDWWHUQV 0RUHRYHU WKH FXUUHQW :::LPSOHPHQWDWLRQWHFKQRORJ\SURYLGHVORZOHYHODEVWUDFWLRQVWKDWGRQRWVXSSRUWDV\VWHPDWLFLPSOHPHQWDWLRQRIWKHXQGHUO\LQJ GHVLJQ FRQFHSWV (YHQ ZRUVH WKH LPSOHPHQWDWLRQ WHFKQRORJ\ LV VR VHPDQWLFDOO\ SRRU WKDW PDQDJHPHQW RI :HE VLWHV DQG LQ SDUWLFXODU:HEVLWHHYROXWLRQFDQEHTXLWHGLIILFXOW7KLVZRUNSUHVHQWVDQHZREMHFWRULHQWHGPRGHODQGDQDXWKRULQJWRROEDVHGRQ VXFK PRGHO 7KH PRGHO HQULFKHV H[LVWLQJ :HE DEVWUDFWLRQV DQG H[WHQGV WKH VHPDQWLFV RI :HE WHFKQRORJLHV VR WKDW GHVLJQ FRQFHSWV FDQEHLPSOHPHQWHGPRUHHDVLO\DQGLQIRUPDWLRQPDQDJHPHQWFDQEHJUHDWO\LPSURYHGDQGDXWRPDWHG7KHPRGHOLVJHQHUDWLYHLH DWDUJHW:HEVLWHLVJHQHUDWHGIURPLWVREMHFWRULHQWHGPRGHO

.H\ZRUGV:RUOG:LGH:HEREMHFWRULHQWHGPRGHODXWKRULQJK\SHUPHGLD

1 Introduction The World Wide Web (WWW) is evolving at an incredibly fast pace. From its first introduction in 1990[3], the WWW has been changing both in size, technology, and intended use. The number of WWW sites has increased exponentially as Internet users understood the benefits that could stem from a globally connected hypermedia system. Almost every company, organization, and university owns a WWW site that provides information and services for customers and users. The underlying technology has evolved to include active contents in static hypertext pages by means of languages and technologies like Java [14] or ActiveX [16], scripting languages for browsers like VBScript [19] or JavaScript [6], support for image animation, and so on. This technological improvement has been used as the lever fulcrum for the shift from the mere distribution of information towards the provision of services. In fact, while the first implementation of the WWW system was finalized to the distribution of scientific information, the present WWW infrastructure

1

is becoming a platform for the development of distributed applications providing advanced services to users [5]. This promising scenario is characterized by an unstructured, or even chaotic, evolution and lack of methodologies. Most of the current research efforts focus on the development of new technologies or on the integration of the existing ones in a WWW setting. These technologies provide low-level mechanisms that enable particular visual effects or application integration. On the other side, research on hypertexts developed methodologies for the design of hypermedia information systems. Most current WWW site development practices, however, do not follow systematic methodologies; rather, information structuring and management is based only on the developer’s knowledge and practical skills. This situation reminds the childhood of software development when software was developed without methodological support, without the right tools, simply on the basis of good common sense and individual skills. WWW site development suffers from a similar problem. Most WWW developers do not follow a well-defined development process and, after a first vague requirements acquisition and informal design phase, they put all their effort in the implementation phase. Thus, they have to implement high-level requirements and design concepts with low-level technology, such as HTML [22], that does not provide suitable constructs. Using the analogy with conventional software development, this approach corresponds to implementing high-level software designs through direct mapping into an assembly-level language. Furthermore, the lack of suitable abstractions makes it difficult to reuse previously developed artifacts, or to develop frameworks that capture the common structure of classes of applications and allow fast development by customization. Finally, the management of the resulting Web site is difficult and error prone, because change tracking and structural evolution must be performed directly at the implementation level. This problem is particularly critical since WWW systems, by their very nature, are subject to frequent updates and even redesigns. Software engineering research has delivered technologies (e.g., object-oriented programming languages), methodologies (e.g., design paradigms), and tools (e.g., integrated development environments) that support the software development process [12]. Being effectively supported, software developers are able to deliver quality products in a timely and cost-effective manner. A similar approach has to be followed in order to bring WWW development out of its immaturity. The problem of WWW site development must be tackled by providing methodological and technological support for each phase of the development process. While the conceptual modeling of a WWW site, being independent of the implementation technology, can be effectively supported by notations developed for hypermedia systems, there is a strong need for an implementation methodology and a corresponding technological support that bridges the gap between highlevel design and low-level implementation, by providing suitable high-level abstractions and constructs.

This paper addresses these problems by proposing a WWW object-oriented model, called WOOM, that provides concepts and abstractions that help in the mapping from high-level design of a Web site into an implementation that uses “standard” WWW technology. This model extends the basic Web model by

2

providing richer semantics, new constructs, and support for complex management tasks. In addition, we built an authoring tool that supports WWW site development using WOOM concepts and abstractions and that is able to automatically produce an implementation of a WOOM model instance in the conventional WWW technologies. The resulting process is similar to the compilation of high-level languages to binary code. It is not a simple translation, though. Rather, it is based on a powerful transformation scheme that allows high-level object descriptions, given in WOOM, to be customized in a context-sensitive way as they are translated into the target Web site. As a result, this approach clearly separates the description of the data from the way the data are presented through the Web interface. The same data can be presented differently in different contexts. This separation not only helps in designing the application, but also provides support to changes and Web site evolution.

This work is structured as follows. Section 2 presents some approaches to the problem of supporting Web site development. Section 3 presents our model. Section 4 describes how the model may be used inside the WWW site development process. Section 5 describes a tool based on our model that allows a developer to create and manage a Web site. Section 6 presents the application of the previously described process to a case study. Section 7 draws some conclusions and outlines future work.

2 Related work The problem of supporting the development and management of a Web site has been tackled in different ways. The various approaches are characterized by different levels of abstraction and granularity. We distinguish among a resource-oriented approach, a site-oriented approach, a design-oriented approach, and a model-oriented approach. A resource-oriented approach focuses on the information elements that compose a site. This approach provides tools for the development and management of a single resource as an HTML page or an image. Example of tools that belong to this approach are HTML editors, like Hot Metal [13] [24] and Netscape Editor [21], that support the development of single HTML pages by providing syntax-driven editing and WYSIWYG interfaces; format converters, that allow a user to translate information into a format that is suitable to inclusion in a Web site (e.g., Word-to-HTML translators); image editors, that support the creation of graphic content; HTML syntax checkers, that allow to flag out errors in the syntax of an HTML document; link validators, that verify that each hypertext reference in an HTML page has a valid destination; active resources development tools, that support the development of client and server-side programs like CGI scripts or applets (e.g., Jamba [1] or ScriptDebugger [18]). A site-oriented approach abstracts away from single resources and tries to provide the developer with a general view of the whole site. The developer can define the overall Web site structure in terms of resources (pages, images, etc.) and folders. In addition, one may define some aspects that are common to all the resources of the site, like banners or background images. After all this information has been defined, these tools allow the developer to publish the site, i.e., to create a snapshot of the site on the file system that

3

is made accessible to users by a standard HTTP daemon. In addition, these tools support site-oriented management tasks like link validation or site restructuring. A notable example of this approach is Microsoft FrontPage [17], which provides an integrated environment for Web site development. FrontPage offers wizards and templates for fast creation of groups of pages, and a basic mechanism, called WebBot, that allows the developer to associate an HTML page with a script that is invoked during the publishing process. WebBot scripts may modify the contents or the structure of the page, for example by including a banner or by generating an index of the hypertext references within the page. Another example is represented by NetObjects Fusion [20]. A distinguishing characteristic of Fusion is the explicit representation of navigational links that allows the developer to modify them without accessing the resources involved, and a conditional publication mechanism that allows for creating different versions of the same site (e.g., textual or with low resolution images for users connected with slow links). Tools that follow the site-oriented approach solve the problem of providing an overall view of the site structure and contents, but fail to provide higher-level abstractions because they are still strictly based on the low-level concepts of “page” and “page element” provided by WWW technology. A design-oriented approach tries to provide primitives and notations that compensate for such lack of highlevel abstractions. This approach applies the results of research on hypermedia design to the World Wide Web domain. Design notations like HDM [9], RMDM [2] or OOHDM [23], support the developer in modeling the information of the application domain under consideration in terms of entities and relationships among entities. In addition, they provide support for specifying the access structures (i.e., the “entry points”) to the hyperbase contents, using constructs like guided tours and indexes. The main drawback of this approach is that, after design, the developer is faced with an implementation phase in which high-level concepts must be implemented with low-level technology. In addition, once the site is implemented, it is difficult to maintain the relationships between design and implementation and therefore management can lead to inconsistencies and errors. A model-based approach tries to abstract away from the low-level nature of the Web technology by modeling the entities involved in Web site development. The modeled entities are then enriched in order to allow for greater flexibility and easier management. In addition, new entities are introduced, for example by composing the existing ones, in an effort to provide the developer with the semantically rich abstractions needed for effective implementation and management. The tools that are based on this approach allow the developer to work with the model entities and then, as in the case the site-oriented tools, to create a “realworld” Web site via a publishing process. A notable example of this approach is WebComposition [10]. In WebComposition, Web entities are modeled by component objects with a state and a set of operations that specify the component’s behavior. Components can be derived by other components using prototyping and can be reused. Our approach described in this paper can be classified as both design-based and model-based. It integrates the advantages of a well-defined design with the support to development and maintenance provided by the model-based approach. This way it is possible to support the developer throughout the overall development

4

process, providing high-level design abstractions and suitable implementation constructs that can be used by the developer in a natural way, without loosing control over the underlying low-level Web technology.

3 The proposed approach In the development of a Web application, the developer faces a gap between the high-level description of the information to be managed by the application and the low-level technology used to describe the contents, the associated structure, and the application behavior. This gap can be filled by providing suitable abstractions and constructs and by defining a mapping from these primitives into “standard” Web technology. In order to identify these abstractions and constructs, we envisage the following bottom-up approach from the implementation to its high-level specification, highlighting a number of intermediate levels (see Figure 1-a).

Requirements Model

Hypertetxt Design Model

Web Object-Oriented Model

Requirements and Specification

Applic Spec

WOOM Model

WWW Appl

(a)

HDM Design

High Level Implementation

Translation

Web Basic Model

WWW Technology

Design

WBM Model

Instantiation

(b)

Figure 1: Modeling and development processes. A first step is a modeling process that abstracts away from the implementation technology and defines a higher-level view of the concepts that come into play in a WWW application. The resulting model, called WBM (Web Basic Model), can be viewed as an abstract representation of the existing Web entities. It does not provide any new, higher-level conceptual entities but simply maps the entities found in a Web implementation into cleaner abstractions. A second step introduces a higher-level model, called WOOM (Web Object-Oriented Model). WOOM extends and enriches the abstractions defined by WBM, by providing new concepts and mechanisms that support the development of complex Web applications. A third step abstracts away completely from the implementation and tries to catch the conceptual structure of the application at hand. This step provides the developer with the notations for the design of the application. For this purpose we use an existing hypermedia design model, namely HDM (Hypertext Design Model) [7].

5

Finally, a further abstraction step defines concepts and notations for hypermedia requirement elicitation, representation, and analysis. If Figure 1-a is interpreted top-down, the corresponding development process proceeds though a number of phases (see Figure 1-b). After a first requirements collection and specification phase, a design phase is carried out using HDM. The HDM design is then given a high-level implementation by using the abstractions and constructs provided by WOOM. This model instance is subsequently translated into a WBM instance that, eventually, is mapped into the constructs of the conventional Web technology. This process is similar to the conventional software development process. After requirements specification, a design phase is carried out using, for instance, the Booch notation [4]. Then, the design is implemented using a tool (a programming language [11], e.g., C++) that supports the implementation of design concepts by means of suitable abstractions. The high-level implementation is then translated to a lower-level description (such as bytecode or assembly code), that is quite close to the final machine language. Eventually, a simple translation step produces the executable representation of the application.

In the following sections we will present the models associated with the steps described above. In Section 3.1 we introduce WBM, while in Section 3.2 we present the extended WOOM model and the mapping between WOOM and WBM.

3.1

Modeling a Web server

The WWW stemmed out of an experiment to exchange scientific information among research centers. Its pragmatic nature was one of its key success factors, but somehow it prevented the Web to be given a precise definition of the underlying model. This is exactly the goal of the World Wide Web basic model (WBM). WBM is a concise and precise model for the Web, which abstracts away from technology and implementation details. As we mentioned before, WBM can be viewed also as an intermediate stage in the translation from WOOM into the actual Web implementation, in much the same way as an intermediate language can be used as an intermediate stage in the compilation from a high-level language into machine language. In WBM, we are not concerned with the modeling of all entities involved in a WWW application. Rather, we are interested in defining the entities composing a WWW information provider. We do not model the information consumer, such as a user equipped with a browser or an information retrieval application. In our view, the user is an entity that asks for resources by means of some name or reference, obtains the resource contents, or result, and, on the basis of such results, may produce new requests (see Figure 2).

6

Request

WBM Producer

Consumer

Result

Figure 2: The WBM scope. According to WBM, a Web application can be defined in terms of the following entities: resources, elements, sites, servers, references, requests, and multimedia objects. Resources are the fundamental entities of the model. They model the contents and the structure of a collection of information. Resources can be divided into containers and basic resources. A container is a collector of resources. The containment relationship among containers defines a tree, in which containers are nodes and basic resources are leaves. The root of the tree is called the root container. Therefore each resource, with the notable exception of the root container, is placed in just one container and there cannot be circular containment relationships (see Figure 3). Legend: Container Basic resources

Containment relationship

Figure 3: Containment relationships between containers and basic resources. Basic resources are information repositories. They are distinguished into opaque resources and hyper pages. Opaque resources are unstructured resources. Subclasses of this class are images, i.e., graphic objects, applets, i.e., programs that are activated on the client’s side, scripts, i.e., applications that are activated on the server’s side, and external. External resources are those types of information that are not directly supported by the current Web technology and are managed by means of external helper applications. These resources include audio and video information, PostScript files, binaries and similar. Hyper pages are hypertext documents, composed of a set of elements. An element is a structural element, like a text paragraph, an anchor, or a dotted list. Elements can be simple or complex. Simple elements are atomic data containers, while complex elements contain an ordered list of other elements. For example, the image placeholder element (IMG) is a simple element, while the BODY element may be composed of some paragraphs, a table etc. Elements can belong to just one hyper page. Each element has an associated set of

7

attributes that specify its behavior. Figure 4 outlines the class diagram [4] for WBM1 resources and elements. Each class of resources has an associated projection operation that takes some parameters and returns a multimedia object, which represents the view of the resource contents that is actually delivered to the user as a response to a resource request. The projection operation for a container returns a description of the contained resources. Images, applets, external resources, and hyper pages have a simple projection operation that extracts from the resource a flat representation of the associated information. Scripts have a projection operation that activates the program associated to the resource and returns the multimedia object produced by program execution. Resource projection(parameters) A

Container

Basic resource A

Opaque A

Image

Applet

Element

Hyper page

A

Script

External

HR

Simple A

BR

…

Complex A

IMG

A

FORM

APPLET

…

P

Figure 4: Resources and elements class diagram. Each resource can be uniquely identified by a name. Resources belonging to the same container cannot have the same name. The tree structure imposed by the containment relationship allows resources to be uniquely identified also through a pathname, which describes the relative position of the resource with respect to another resource. This identification mechanism is similar to the well-known naming scheme based on pathnames adopted by operating systems. A site is composed of a root container and one or more servers. A site models a set of related information, represented by the set of resources contained (directly or indirectly) in the root container. The associated servers are access points to the resources belonging to the site. Each server is characterized by a unique address and has an associated container that limits the scope of the resources that are accessible by the 1

Since hyper pages are implemented in the target Web technology as HTML pages, elements correspond to HTML semantic entities. Figure 4 shows only a few of them.

8

server (see Figure 5). An external entity can access the resources of a site by contacting a server and providing the relative position of the required resource with respect to the container associated with the server, possibly passing parameters to be used when invoking the projection operation on the resource. The server, in turn, retrieves the specified resource, applies the projection operation using the parameters, and returns a resulting multimedia object. Site n

1

0..m

1

Server

Container

Figure 5: Site and servers class diagram. Figure 6 represents a site composed of the root container C1, and of three servers S1, S2, S3 with associated containers C2, C3, C4 respectively. C1

C3

C2 S1

C4

R1

C5

S2

C6

R8

S3

ref1 R2

R3

R4

R5

R6

R7

R9

R10

R11

ref2

Figure 6: A site structure. References model relationships between a source element (e.g., an anchor) and a destination resource. References are not first-class objects: they are expressed as an attribute of the source element. References are directed, and cannot be resolved from the destination resource back to the source. References may span across different sites or they can connect resources contained in the same site. References are composed of a resource position specification, some parameters that specify values to be passed to the projection operation to be invoked on the denoted resource, and a fragment that specifies a particular part of the resource. Resource positions can be relative or absolute. Relative positions denote a resource by means of a pathname relative to the resource containing the source element; absolute positions identify a resource by means of a server address and the path to the resource starting from the server container. Relative

9

references should specify resources that are accessible from the same set of servers from which the resource containing the source element can be retrieved. Otherwise, inconsistencies may arise. Consider, for example, Figure 6. Resource R5 should not contain a reference ref1 to resource C5, even if both resources belong to the resource tree served by server S1. In fact, if R5 would be requested by using server S3, resource C5 could not be referenced because it is out of the scope of server S3. This situation does not occur in the case of reference ref2. Absolute references can solve this problem. On the other hand, moving a resource may invalidate absolute references while moving groups of resources interconnected by relative references requires no modification. In general, moving resources in the site container tree may generate inconsistencies and dangling references.

A WBM model instance can be directly translated into its corresponding implementation in the conventional WWW technology. The “real-world” counterpart of the server object is an http daemon that insists on a directory that is the counterpart of the corresponding server container. The mapping among WBM entities and WWW entities is described in Table 1.

WBM

WWW

Containers

Directories

Hyper pages

HTML files

Elements

Character strings in an HTML file

References

URLs

Images

JPEG, GIF files

Applets

Bytecode files

Scripts

CGI Executable files

Opaque resources

Byte stream files (PostScript, Binaries, MPEG, WAV etc)

Servers

HTTP daemon processes

Multimedia objects

MIME objects

Table 1: WBM – WWW mapping.

3.2

WOOM

The abstractions provided by the WBM model are quite poor and have some inherent limitations. It is not possible to represent entities composed of several resources structured by relationships other than containment. In addition, it is not possible to share the same resource in different contexts to support reuse effectively. Furthermore, there are no mechanisms to define different views of the information contained in a resource and to extract specific views depending on particular contexts. Reuse “in-the-small” is limited because elements cannot be placed in more than one hyper page. For example, banners and logos common

10

to several hyper pages must be replicated in each of them. Management of such elements can be a difficult task since replication makes maintenance error prone. Another limit of the Web basic model is that references are not first-class objects. They are embedded in attributes of elements and cannot be resolved in both directions. Therefore management of cross-references requires access to the resource (and element) inner structure. These problems make it difficult to implement and maintain a site. To overcome these limitations we have developed WOOM - a new WWW object-oriented model. Thanks to its richer semantics and its higherlevel constructs, the model provides support to both implementation and management activities. Resources

Occurrences

C1

O1 (C1)

C3

C2

C4

R1

R2

C5

R3

O2 (C2)

R5

R4

O4 (R1)

O5 (C4)

O9 (R2)

O10 (R3)

O3 (C3)

O6 (C5)

O11 (R3)

O12 (R4)

O7 (C5)

O13 (R3)

O8 (R5)

O14 (R4)

Figure 7: Resources and occurrences As in WBM, resources model the contents and structure of the site. Resources are divided into containers and basic resources. Basic resources, in turn, may be either opaque resources or hyper pages. Differently from WBM, WOOM resources can be placed in more than one container, but circular containment relationships are not allowed. Therefore, the containment relationship defines a DAG, where containers are the nodes and basic resources are the leaves. Since a resource can be placed in more than one container we distinguish between resources and occurrences. An occurrence is a resource with an associated context. A context, in turn, is a path from the root to the resource in the resource DAG. For example, let us consider Figure 7. The left-hand side describes the containment relationship among resources, while the right-hand side shows the containment relationship among occurrences (the occurrence tree). Resource R3 is put in three contexts, because it is placed in both containers C4 and C5, and container C5 is put in both containers C2 and C3. Therefore, resource R3 is accessible through paths C1/C2/C4/R3, C1/C2/C5/R3, and C1/C3/C5/R3. Occurrences are introduced to distinguish among different instances of the same information in different contexts. For

11

example a user may request a hyper page containing the description of a movie as a page included in a container dedicated to all the movies of a particular director. The same information may be retrieved by following the description of –say- “thrillers”. Furthermore, by distinguishing among different occurrences one may define different ways of presenting the same information for each occurrence, as we will discuss shortly. As in WBM, WOOM elements are the building blocks of hyper pages, and can be simple or complex. Differently from WBM, elements can be placed in more than one complex element. In addition, since complex elements are ordered lists of elements, an element can appear more than once in the same complex element. Therefore, as for resources, we may have different occurrences of the same element. Occurrences are distinguished by using a path mechanism, extended with a positional notation in order to distinguish among multiple occurrences of an element within a complex element. In WOOM, both elements and resources may have attributes that specify some entity properties, such as: expiration date, version, relevance, etc. A portion of the class diagram for the WOOM model is presented in Figure 8.

Resource

Resource occurrence

projection(parameter)

projection(parameter)

A

A

Container

Basic resource

Basic resource occurrence A

Container occurrence

A

Opaque A

Image

Applet

Link

Element

Hyper page

A

Script

External

HR

Simple A

BR

…

Complex A

IMG

A

FORM

APPLET

…

P

Figure 8: WOOM class hierarchy A site is associated with a root container. Since the root container is not placed in any other container, its context is determined by the site. The root container has a single occurrence. As in WBM, sites have one or more servers. A server is an access point to site resources. Each server has an associated container occurrence that limits the scope of the information that is accessible through the server. In this way it is

12

possible to provide access to different views of the same information by associating different servers with different occurrences of the same container. In WOOM references are modeled with links.Links are first-class objects that associate a source element to a destination resource occurrence. By keeping track of the context of the destination resource, WOOM links may lead to a particular view of the resource. Root container

Departments

Employees

Managers

People data

Production

HTML

HEAD

HTML

BODY

TITLE

HEAD

UL

LI

LI

Manager

Laboratories

LI

BODY

TITLE

LI

LI

TEXT

LI

Manager

Figure 9: An example WOOM model instance. A WOOM model instance defines the specific data entities that eventually populate the target Web site. Such data entities are instances of the Resource and Element classes. For example (see Figure 9), a Web site providing access to information about an organization might define Department, Employees, Managers, and Laboratories as specific containers. It might define People data as a hyper page contained in Employees which provides names and details (office phone number, home address, and home phone number) of every employee. The hyper page is composed of a single HTML element that contains a HEAD and a BODY element. The HEAD element contains a TITLE element, whose content is the page title. The BODY element contains an unordered list element (UL) which is structured into several list items (LI). Each LI contains a string representing the data associated with an employee and owns an attribute specifying if the employee is a manager. The design process that identifies and organizes access to these application specific data is not described here. It will be outlined in Section 4.2 in the context of the overall Web site development process. What we discuss here is the translation process that generates a WBM instance through a recursive translation process that operates on the WOOM model instance, starting from its root container and propagating the translation in a top-down fashion to the entire WOOM instance DAG. The translation process is described here informally, but can be formalized via a variant of attribute grammars.

13

When applied to a resource or element X, the translation process creates a list of objects that are instances of resource or element classes of the basic Web model, depending on X’s contents, its attributes, and its context, i.e., the container or complex element that invoked the translation operation on X. Context dependent information is propagated by using transformer objects. Each node of the WOOM DAG may have an associated list of transformer objects that parameterize the translation process of its contents. Transformer objects have a state and a transform method that takes as parameter a resource or element objects and returns an object of the same type. During the translation process, each node receives a list of transformer objects from one of its ancestors. Then, the node creates a shallow copy of itself (i.e., a resource or an element is created). Such a copy is passed to the transform method of the first transformer belonging to the list received during the translation invocation. The transformer modifies the copy depending on its state and the values of the copy attributes. The modified object is then passed to the transform method of the transformer object that appears next in the received transformer list, until the last transformation has been applied. At this step of our work, we do not constrain what transformer objects can do. Transformer objects may add, delete, and modify the object attributes or reconfigure the containment relationship, adding new sub-entities, and deleting or reordering references to existing sub-entities. In addition, the composition of transformers may eventually return a null object, meaning that the current resource or element must not be translated at all. If the returned object is not null, the translation operation is invoked on every descendent node, passing the list of transformers received during the invocation of the translation operation appended with the list of transformers associated with the node being translated. The translation of descendent nodes returns a list of WBM objects. These objects are used by the node to produce its translation that is returned to the upper resource or element.

The translation process, as we mentioned, can imply an elaborate transformation that customizes the presentation of the data entities as they will appear in each target context in WBM. In the example, let us assume that the Managers container includes the People data page and a Production page containing strategic “classified” information about the organization in the form of a TEXT element. Employees can access just the data contained in the Employees container, while the managers are able to access information under the container Managers. Access control is enforced by means of two different servers associated with the two containers. In the translation from WOOM into WBM, we want to make any information about managers inaccessible to normal employees. To do so, the page People data is translated differently in the context of Employees and in the context of Managers.

14

Root container

Employees Transformer object

The transformer inhibits translation of item

Employees container

Managers

People data

Production

HTML

HEAD

BODY

TITLE

HEAD

UL

LI Manager

HTML

Manager

LI

LI

BODY

TITLE

LI

LI

TEXT

LI

Manager

Figure 10: Transformation of the example in Figure 9. The Employees container has a transformer object that controls the publication of the contained information. For the sake of simplicity, we assume that all the other resources and elements have no transformer objects. When the translation operation is invoked on the Employees container, the translation is propagated to the contained People data page passing the Employees transformer object. When the translation reaches an LI element containing manager information (see Figure 10), the corresponding shallow copy is created (this is indicated by the gray elements in Figure 10) and passed to the transform method of the transformer object that was inherited during the propagation of the translation process. When the Employees transformer examines the (copied) LI object, it recognizes that the element contains information that should not be published and therefore returns an empty object. On the contrary, when the same LI element is reached by the translation process that propagates from the Managers container, there is no transformer to inhibit the element translation and therefore the corresponding information will appear in the People data page under Managers.

3.2.1

Enriching the model

The basic abstractions and mechanisms of WOOM, described in the previous section, are used to support site development and maintenance by defining new constructs that represent modularization units, frequently used structures, and common navigation patterns. New containers have been defined, extending the simple containment functionality. These containers add a navigational semantics to the enclosed resources by using the transformer mechanism. During the translation process, their transformer objects are passed to the enclosed resources. When activated, the

15

transformers modify the resources by adding the navigational garnishment. Examples of these new containers are resource lists, resource trees, resource indexes, and resource sets. A resource list is a container that imposes a list structure and a linear navigation pattern to the enclosed resources. When resources contained in a list are translated, they are reshaped by the list container transformer to include navigation bars that allow a user to move from one resource to the previous, the next, the first, or the last. A resource tree is a container that imposes a tree structure to the enclosed resources, and an associated navigation pattern that allows a user to move from a node upwards to the parent or to the root of the tree, downwards to children, and horizontally to siblings. A resource index is a container that acts as an entry point to a set of resources. When translated, it produces a hyper page containing a list of references to the enclosed resources. Resources, in turn, are modified to include references that allow the user to navigate back to the index hyper page. Resource sets group resources without navigational semantics but characterized by some common property, such as their visual aspect (e.g., the same background image.) In addition, a developer can build customized resource containers with particular navigational semantics, simply by creating the appropriate transformers. We have enriched the model by defining some subclasses of the hyper page resource that specialize the generic hyper page to play specific roles. Examples are page templates and TOC pages. A page template resource is a hyper page that has a basic structure, customizable into particular instances during the instantiation process. For example, a page template for painters may take as parameters, at creation time, a paragraph containing the painter’s biography, and a list of strings describing his/her paintings. This information is merged with the static part of the template to produce a complete page. Web site developers can use the predefined templates or create new templates with custom structures. A TOC page is a page with an initial table of contents that has references to the rest of the document, through internal links. The resource and elements attributes have been used to provide an information labeling mechanism that allows for dynamic filtering of information. Resources and elements have a predefined relevance attribute, based on which it is possible to apply a conditional translation of contents of a specified relevance. For example, it is possible to produce either a sketch or a complete version of the same information. In addition, developers can easily add attributes and suitable transformers for specific applications. In order to support the development phase that builds the WOOM instance starting from the design of the site, we introduced design elements. As we will explain in the sequel, these elements allow for representing design entities in the WOOM model and describing relationships between design entities and the corresponding implementation resources (see Section 4.3)

4 A WWW Development process The development of a Web site that provides structured access to a large amount of information, possibly under different views, is a complex activity. Therefore, in order to be able to deliver high-quality Web applications with limited time and budget, developers should follow a well-defined development process, possibly supported by suitable tools.

16

In the following, we will discuss the phases of Web site development process, showing how the model described in Section 3 comes into play during the process.

4.1

Requirements analysis

During requirement analysis, the developer collects the needs of the stakeholders, in terms of contents, structuring, access, and layout. Contents requirements define the domain-specific information that must be made available through the Web site. Structuring requirements specify how contents must be organized. This includes the definition of relationships and views. Relationships highlight semantic connections among contents. For example, relationships could model generalization (is-a), composition (is-composedof), or domain-dependent relationships. Views are perspectives on information structures that “customize” contents and relationships according to different situations of use. For example, different views of the same contents could be provided to different classes of user (e.g., an abstract or a document outline instead of a complete document). Access requirements define the style of information access that must be provided by the Web site. This includes priorities on information presentation, indexing of contents, query facilities, and support for guided tours over sets of related information. Layout requirements define the general appearance properties of the Web site, such as emphasis on graphic effects vs. text-based layout.

4.2

Design

Based on the results of requirements analysis, the design phase defines the overall structure of a WWW site, describing how information can be organized and how users can navigate across it. The output of the design phase should be the guide for the actual implementation of the site and the baseline for any subsequent evolution of the application. A careful design activity should highlight the fundamental constituents of a site, abstracting away from low-level implementation details, and should allow the designer to identify recurring structures or navigation patterns to be reused [8]. As such, a good design can survive the frequent changes in the implementation, fostered by the appearance of new technologies. Being largely implementation-independent, the design activity can be carried out using notations and methodologies that are not explicitly web-oriented; any design model for hypermedia applications could be used. In the following, we will adopt the HDM (Hypertext Design Model) notation [9], shortly described in the rest of this subsection. In designing a hypermedia, HDM distinguishes between the hyperbase layer and the access layer. The hyperbase layer is the backbone of the application and models the information structures that represent the domain content, while the access layer provides entry points to access the hyperbase constituents. The hyperbase consists of entities connected by application links. Entities are “first-class” structured pieces of information. They are used to represent conceptual or physical objects of the application domain. An example of entity in a cinema application is “Director”. Application links are used to describe domainspecific, non-structural relationships among different entities (e.g., from a “director” to the “movies” he has directed). Entities are structured into components, i.e., clusters of information that are perceived by the user as conceptual units (for example, a director’s “biography”). Complex components can be structured

17

recursively in terms of other components. Information contained in components is modelled by means of nodes. Usually, components contain just one node, but more than one node can be used to give different or alternative views (perspectives, in HDM) of the component information (e.g., to describe a piece of content in different languages, or to present it in a “short” vs. an “extended” version). Navigation paths inside an entity are defined by means of structural links, which represent structural relationships among components. Structural links may, for example, define a tree structure that allows the user to move from a root component (for example, the data-sheet for a movie) to any other component of the same entity (e.g., credits, plot, reviews, etc.) Once entities and components are specified, as well as their internal and external relationships, the access layer defines a set of collections that provide users with the structures to access the hyperbase. A collection groups a number of “members”, in order to make them accessible. Members can be either hyperbase elements or other collections (nested collections). Each collection owns a special component called collection center that represents the starting point of the collection. Examples of collections are guided tours, which support linear navigational across members (through next/previous, first/last links), or indexes, where the navigation pattern is from the center to the members and viceversa. A complete example of HDM design is presented in Section 6.1

4.3

Implementing design

The implementation phase creates an actual Web site from the site design. The first step of implementation is the explicit representation into the WOOM model of the design elements identified in the previous step. This can be done by using the design element classes defined in the WOOM model fragment in Figure 11. This further fragment, of course, is not used if Web site design does not first go through a HDM design phase. Design element

Entity

Component

Link

Node

Structural link

Application link

Figure 11: Design elements. Each HDM entity, component, node, structural or application link is represented as an object instance of the corresponding Entity, Component, Node, Structural/Application link class of the WOOM model. Then, the site developer uses WOOM abstractions and constructs in order to define the implementation mapping from design elements into WOOM resources. In particular, for each HDM entity a suitable resource must be specified. The choice of the particular type of resource is performed on the basis of the inner structure of

18

the entity. For instance, according to the example discussed in Section 3.2, we may introduce an implementation link from Employees (an instance of the design class Entity) to class container. Entities that feature particular structures may require customized containers. These containers can be easily defined by inheriting from the existing classes and then using the transformer mechanism to define the navigational semantics (structural links) imposed over the entity components. Implementation of structured components follows the same procedure. Simple components are usually implemented by creating the appropriate hyper page template. Templates describe the components’ structure in-the-small and allow for parameterized instantiation of the different instances. Nodes inside a component are implemented by using elements characterized by relevance attributes. During translation, the selection of the appropriate attributes allows for selecting the desired view of the component contents. HDM application links are implemented using WOOM links. Design links with particular semantics can be implemented by user-defined subclasses of the link class. Relationships between design elements and resources implementing them are maintained by means of implementation links, that associate a design element object with a class in the WOOM hierarchy. This way the mapping of design concepts into WOOM resources is made explicit, to enable changes in the implementation to be tracked back to design entities and viceversa. Once the structure of the WOOM model has been defined in terms of extensions to and customization of the class schema, the associated site is populated by creating the corresponding resource instances. Then servers are created in order to give selected access to the information. Different servers can be used in order to limit the access to information to particular classes of users or to provide different views to the site contents. Eventually, the translation process is invoked on the root folder. The process propagates to all the site resources that are translated into WBM objects. At last, WBM objects are instantiated into real structures (files, HTML code, httpd processes etc.)

4.4

Managing Web evolution

Web sites have an inherently dynamic nature, since information may be continuously added, removed and modified. In addition, the layout and visual arrangement of the information may need to be changed. Thus, maintenance is a continuous process. If the site has a complex structure, its management can require a great amount of work and skill. The WOOM model provides the mechanisms to build high-level constructs and abstractions that provide a modular description of the site contents. The same mechanisms and abstractions allow the site maintainer to perform common tasks more easily and to carry out complex operations that are very time-consuming on the low-level implementation of the Web site. First, we distinguish among the contents of a resource, its occurrence in different contexts, and the way the resource is presented in each different context. If the contents must be updated, this is done only once, and the change automatically affects all occurrences in different contexts. If the presentation of an occurrence in a certain context must be changed, only transformers must be modified.

19

By using resource and elements attributes, it is possible to perform resource and element versioning and benefit from good configuration management practices [15]. In addition, it is possible to track information aging at any level of granularity. Every element and resource can have an associated expiration date attribute. It is then possible to use the transformer mechanism to hide expired information, or to highlight new information in a completely automatic way. Since structural and application relationships are explicit and well-defined in terms of containers and links, it is possible to perform complex structural management operations. For example, it is very easy to track dangling links and internal inconsistencies, e.g., unreachable resources. In addition, it is possible to perform “smart” updates: when resources or set of resources are moved from container to container, links are preserved or inconsistencies are immediately flagged out. The explicit description of the site structure makes it also possible to gather statistics about resources usage (fan-in and fan-out), resource and element reuse level etc., or even to generate automatically a site guide that gives to the user a very high-level view of the site contents.

5 The tool We developed a prototype authoring tool, written in Java, that implements the WOOM model. The tool allows the developer to use WOOM constructs to create the resources that compose a Web site, to perform complex management operations, and to translate the WOOM instance into the Web original model and eventually to the file system. The main components of the tool are presented in Figure 12.

CONTROL APPLICATION

WOOM API

WOOM SCHEMA DEFINITION

REPOSITORY

Figure 12: The authoring tool. The WOOM and WBM object-oriented schemas (i.e., the set of built-in WOOM classes) are stored in the Schema definition module using a Java class hierarchy. Web site instances, composed of site-dependent

20

schema extensions (classes and transformers) and resource objects are persistently2 stored in the Repository module. The control application accesses the WOOM schema and instances by means of the WOOM API. The control application is a Java application that uses the primitives offered by the API to: •

create a new site and extend the WOOM schema with application-specific classes and transformers;

•

create the resources composing a Web site;

•

load and store a Web site instance;

•

perform management operations on the Web site;

•

translate the site instance into a target WWW site.

We are currently working on a graphic interface that allows the developer to access WOOM services in a intuitive and user-friendly way.

6 A simple example Hereafter, we apply our approach described in Sections 3-4 to a simple example, in which we develop a site devoted to information about movies. This example highlights the steps to be carried out during the development process and how WOOM provides support for each step. For the sake of simplicity we suppose that the requirements specification phase has been already carried out, and we focus on design, implementation and maintenance.

6.1

Design

During design the developer models the entities of the application domain at hand and highlights relationships and navigational access structures.

6.1.1

Entities and Links

We have defined three entity types: Director, Movie, and Actor. Application links that model the relationship direct/is_directed_by connect Director entities to Movie entities. Movie entities and Actor entities are connected by application links that model the relationship plays_in/is_in_cast (see Figure 13). Actor

plays in

has in cast Director

directs

is directed by

Movie

Figure 13: Entities and application links. The Director entity is composed by four components, each constituted by a single node (see Figure 14): • a personal profile, including a brief presentation of the director and an image; • a biography, with detailed information about director’s life and career; • a set of directed movies; 2

Persistency is achieved by using Java serialization mechanism. 21

• a component describing ongoing projects that gathers the latest news about director’s activities (work in progress, public appearances, events, etc.) Director Personal profile

Biography

Movies

Projects

Figure 14: The Director entity. The Movie entity is composed by four components (see Figure 15): • a data sheet that gathers most important information (title, publication year, director, main actors, duration) and an image (the movie poster or excerpts from the movie). The data sheet has two nodes: a director’s view node and a general view node. The former presents the movie as a step in the work of the director while the latter provides general, director-independent information; • a credits component that specifies the people involved and the corresponding roles (director, actors, producers, technicians, soundtrack authors, etc.); • a plot component; • a list of reviews of the movie. Data sheet Director’s view

Credits

Movie

General view

Plot

Reviews

Figure 15: The Movie entity. The Actor entity is composed by four components. Each components has a single node (see Figure 16): • a personal profile that presents the most important information about the actor (name, age, nationality, most famous films, etc.) and an actor’s image; • a biography that reports detailed information about the actor’s life and career; • a set of interpreted movies; • a component describing ongoing projects that gathers the latest news about the actor’s activities.

22

Actor Personal profile

Biography

Interpreted movies

Projects

Figure 16: The Actor entity. Actor and Director entities are quite similar. They differ with respect to the their role. If an actor is also a director then he/she is represented with two different entities in the hyperbase.

6.1.2

Access structures

Hyperbase entities (directors, actors, and movies) are accessible by means of a set of indexes and guided tours (see Figure 17). There is a first general index that represents the front-end of the site and allows the user to access a number of second-level indexes, i.e., the actors alphabetical index, the directors alphabetical index, and the movie index. Movies can be accessed through an alphabetical index, through a chronological index, and through an index of genre guided tours. General index

Actors index

Directors index

Movie index

Alphabetical order

Guided tours

Chronological order

Horror

* Actor

* Director

War

Adventure

* Director’s guided tour

Movie *

*

Figure 17: Access structures.

23

6.2

Implementation

The implementation of the site design starts with the introduction in the WOOM model instance of the design elements. First of all we create an object called Director, instance of class Entity3. Then we create objects named Personal profile, Biography, Movies, and Projects of class Component and their corresponding nodes named PersonalNode, BiographyNode, MoviesNode, and ProjectsNode, instances of the Node class. The nodes are inserted in their respective component objects, which, in turn, are inserted into the Director object. Then we create three objects of class Structural link and we use them to describe the internal structure of the Director entity. The resulting set of objects is shown in Figure 18. Director

Personal Profile

Biography

BiographyNode

Movies

MovieNode

PersonalNode

Projects

ProjectsNode

Figure 18: Director entity represented as objects in the WOOM model. This step is iterated until all of the design objects are described in the model, including indexes and guided tours. In the second step, we decide which WOOM constructs will be used to implement each design element. For example, one could choose to create a custom hyper page template for each component. In such a case, the Director’s Personal profile component would be implemented by PersonalProfilePage, a subclass of hyper page whose constructor takes as parameters the name of the director, an image (i.e., a WOOM object of class Image) and a text paragraph (i.e., a P element) that presents the director. The constructor arranges the element as shown by the example in Figure 19.

3

Note that design elements (e.g., “Director”, “Movie”, etc.) are represented in WOOM as objects (instances of the design element Entity). In the target Web site, however, they behave as classes, since the site is populated by instances of such design elements.

24

Figure 19: Stanley Kubrick’s profile. A similar process is followed for the other Director’s components, creating templates Biography, Movies, and Projects as subclasses of hyper page. Since the Director entity has a tree structure, with Personal profile as the root and the other components as leaves, one may decide to implement the Director entity using a resource tree container. The resource tree container will add, during translation, the navigational links that take from the root to the leaves and viceversa. Now suppose that one wants to add a particular background to all the hyper pages of the resource tree and also some image to the page title. Several implementation choices are possible: the resource tree as a whole could be inserted in a resource set that defines these characteristics; or one may define a new transformer that is added to each resource tree instance; or one may create a subclass of resource tree with the specified characteristics. Once an implementation has been chosen, instances of resources representing directors are created, passing as parameters the hyper pages representing the Director’s components. After translation, the PersonalProfilePage shown in Figure 19 appears as in Figure 20.

25

Figure 20: Kubrick’s profile in the Director page tree. A similar process is followed to implement the Actor and Movie entities. The next step implements access structures. For each index or guided tour one may choose a resource index container and a resource list container, respectively. Once objects of these classes are created, the appropriate resources are inserted. During translation, the transformer of these containers will add the navigational bars that allow the user to browse according to the particular context. For example, let us consider the Horror genre and the Kubrick’s movies guided tours. The former is a tour over horror movies while the latter is a tour over Stanley Kubrick’s movies. Both tours are implemented as resource list containers. Kubrick’s horror movie, The Shining, will be placed in both containers. When a movie is accessed during the Horror genre guided tour, the appropriate next/previous navigational bars will be included; in addition, when the page associated with the data sheet component of a movie is accessed, just the node that represent the general information about the movie will be presented (see Figure 21, left-hand side). On the other hand, when the same resource is accessed as a step in the Kubrick’s movies guided tour, the node with the director’s view on the movie will be displayed as well (see Figure 21, right-hand side).

26

Note that in the two views of the movie, the next/previous buttons at the top of the page lead to the next/previous horror movie and next/previous Kubrick’s movie respectively.

Figure 21: The Shining in context. When all the resources have been created, the translation operation is invoked on the root container of the site. The translation is propagated recursively using the mechanisms described in Section 3.2, producing an instance of the WBM model which, in turn, is instantiated into a “real-world” Web site composed of files, directories, and HTTP daemons. From this point on the site can be accessed by users using standard Web browsers.

6.3

Managing Web evolution

Let us suppose we want to add a new director to our site. This requires the creation of instances of the hyper pages implementing Director’s components. These resources are then inserted in a resource tree representing the Director entity, which, in turn, is inserted in the appropriate access structures. Eventually, we invoke the translation operation that, with the WBM intermediate step, generates the Web site. The pages corresponding to the new director will include all the required navigational bars and, in addition, the profile page will be modified by the enclosing access structures. If we need to make corrective modification to small elements, for example the name of an actor, we just need to modify the element object that contains the actor’s name. Automatically, all the resources that contain that element will be updated. We can observe that if this operation would have been performed directly on a Web site developed using traditional tools, it would have required to scan all the HTML pages for occurrences of the actor name in order to correct the error. Now let us suppose that we decide that John Carpenter’s Escape from NY is not actually a horror movie and we decide to remove the movie from the corresponding guided tour. We can obtain the desired result just by removing the resource tree object representing the movie from the corresponding resource list. During

27

translation, the resource associated to the movie will not be inserted in the tour anymore and the references of the previous/next movie in the guided tour will be updated accordingly.

7 Conclusions and future work The development of Web sites is a significantly complex and time-consuming task. When huge amounts of information have to be presented to end-users in a well-structured and easily accessible way, the semantically poor abstractions offered by the current WWW technology are inadequate. Web sites, by their very nature, experience frequent contents updating and structure rearrangement. Consequently, change management may become a difficult and error prone task. A number of approaches have been proposed in order to fill the gap between the high-level concepts used during Web site design and the inherently lowlevel concepts used in its implementation. In this paper we have proposed a new object-oriented model that extends and enriches the Web basic abstractions and mechanisms to provide high-level constructs. These constructs are used to implement higher-level design entities and provide the developer with powerful, customizable, and reusable patterns. In addition, the model supports complex management tasks by representing explicitly relationships and links among the site constituents. A prototype tool based on the model has been developed. The experience gathered so far on the use of the tool has shown that by following a clearly defined, tool-supported development process it is possible to produce high-quality Web site with reduced effort. Future work will include the development of a user-friendly graphical interface for the tool that will allow the site developer to use the features of the model more naturally. In addition, the set of predefined resource patterns (e.g., page lists) provided by the model will be extended to include more representation and navigation patterns that can be used with minimal modifications by the developer in a number of application domains. We will address the issue of incremental Web translation. Presently, a complete target Web site is generated after each change in the high-level model. In an incremental schema, we would like to regenerate only the minimum amount of target information affected by the change.

8 Bibliography [1] Amitech Corp., Jamba Home Page, http://www.jamba.com/ [2] V. Balasubramanian, T. Isakowitz, and E. A. Stohr, RMM: A Methodology for Structured Hypermedia Design, Communications of the ACM, 38(8), August 1995. [3] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen and A. Secret, The World Wide Web, Communications of the ACM, vol. 37, num. 8, August 1994. [4] G. Booch, Object-Oriented Analysis and Design with Applications, 2nd Edition, Benjamin Cummings, 1994.

28

[5] A. Carzaniga, G.P. Picco, and G. Vigna, Designing Distributed Applications using Mobile Code Paradigms, Proceedings of the 19th International Conference on Software Engineering, Boston Mass., 1997. [6] D. Flanagan, JavaScript – The Definitive Guide, 2nd Edition, O’Reilly & Ass., January 1997. [7] F. Garzotto, L. Mainetti, and P. Paolini, Hypermedia Design, Analysis, and Evaluation Issues, Communications of the ACM, Vol. 38, No. 8, August 1995. [8] F. Garzotto, L. Mainetti, and P. Paolini, Information Reuse in Hypermedia Applications, Proceedings of ACM Hypertext ’96, Washington DC, ACM Press, March 1996. [9] F. Garzotto, P. Paolini, and D. Schwabe, HDM – A Model-Based Approach to Hypertext Application Design, ACM Transactions on Information System, Vol. 11, No. 1, January 1993. [10] H. Gellersen, R. Wicke, and M. Gaedke, WebComposition: An Object-Oriented Support System for the Web Engineering Lifecycle, in Proceedings of the Sixth International World Wide Web Conference, 1997. [11] C. Ghezzi and M. Jazayeri, Programming Language Concepts, 3rd edition, Wiley, 1997. [12] C. Ghezzi, M Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering, Prentice Hall, 1991. [13] T. W. Giorgis, 8 Tools for Weaving Your Web Site, BYTE, January 1997. [14] J. Gosling and H. McGilton, The Java Language Environment: a White Paper, Technical Report, Sun Microsystems, October 1995. [15] A. Haake and D. Hicks, VerSE: Towards Hypertext Versioning Styles, Proceedings ACM Hypertext’96, Washington DC, ACM Press, March 1996. [16] Microsoft Corp., ActiveX Home Page, http://www.microsoft.com/activeplatform/ [17] Microsoft Corp., FrontPage Home Page, http://www.microsoft.com/FrontPage/ [18] Microsoft Corp., ScriptDebugger Home Page, http://www.microsoft.com/workshop/prog/scriptie/ [19] Microsoft Corp., VBScript Home Page, http://www.microsoft.com/vbscript/ [20] NetObjects Inc., Fusion Home Page, http://www.netobjects.com/ [21] Netscape Inc., Netscape Editor, http://www.netscape.com/ [22] D. Ragget, Hypertext Markup Language 3.2 Reference Specification, W3C recommendation, http://www.w3.org/TR/REC-html32.html [23] D. Schwabe and G. Rossi, From Domain Models to Hypermedia Applications: An Object-Oriented Approach, Proceedings of the International Workshop on Methodologies for Designing and Developing Hypermedia Applications, Edimburgh, September 1994. [24] SoftQuad Corp., HotMetal Home Page, http://www.sq.com/

29