Systematic Hypermedia Application Design with OOHDM

Daniel Schwabe, Gustavo Rossi *, Simone D.J. Barbosa

Departamento de Informitica
Pontif~cia Universidade Cat61ica
R. Marqui% de S50 Vicente, 225
Rio de Janeiro, RJ 22453-900, Brazil
Tel: +55-21-529 9544
E-mail: [schwabe,rossi, sire] @?inf.puc-rio.br
(*) also LIFIA, F. Cs. Exactas-UNLP, and CONICET,. Argentina
ABSTRACT design process; object orientation comes in as a convenient
In this paper we analyze the process of hypermedia and concise language in which to specify the several
applications design and implementation, focusing in models used in the method. There are a number of benefits
particular on two critical aspects of these applications: the in using an object oriented approach, but this will not be
navigational and interface structure. elaborated in this paper. The structure of this paper is as
follows: we first present an example of an application that
We discuss the way in which we build the navigation and has been developed using 00HDM, and implemented in
abstract interface models using the Object-Oriented both HTML and Toolbook. We then present the 00HDM
Hypermedia Design Method (OOHDM); we show which design process, stressing which design concerns are taken
concerns must be taken into account for each task by giving into account in each activity and which modeling and
examples from a real project we are developing, the abstraction mechanisms are used during each step in the
Portinari Project. We show which implementation concerns development cycle, using the example for illustrating the
must be considered when defining interface behavior, various concepts. Next, we make a few remarks about the
discussing both a Toolbook and a HTML implementation main points of 00HDM. Finally we compare our method
of the example application. with others in the hypermedia field and indicate some
further work in hypermedia design.
KEYWORDS: Hypermedia Design, Methodology,
Modeling, Object Orientation, Navigation, Interfaces 2. AN EXAMPLE APPLICATION
Since space limitation prevents us from going into detail of
1. INTRODUCTION all the formalisms, we will make a more “informal”
In the past three years there has been growing interest in presentation of the main concepts of 00HDM. To help
hypermedia design approaches [15, 9, 18]. There are many that, we present as an example an application that was
different problems the hypermedia designer has to deal developed using 00HDM, and implemented both in
with, since the combination of navigation through an HTML and Toolbook. This example also illustrates typical
intricate information space with the unstructured and domains and applications that can benefit from
dynamic nature of multimedia data poses new and complex methodologies such as 00HDM. We show the HTML
problems that must be solved in a systematic and modular implementation (see <http://www.lids.puc-rio.br/-pp>) of a
way (see for example [13]). Each design activity in a design hypermedia presentation of the material collected by the
methodology should address different concerns at the Portinari Project [19]. This collection includes all the works
proper stage and at the proper level of abstraction [Nanard produced by one of the foremost Brazilian painters,
95], and design decisions should be recorded and traced Candido Portinari, as well as documents (books, photos,
backward and forward in the development process. videos, letters, newspaper and magazine articles, recorded
interviews, etc... ) documenting his life and of his
In this paper we argue that using the Object-Oriented contemporaries, which include many of the most important
Hypermedia Design Methodology (OOHDM) [28,30, 31, intellectuals, artists and political figures of his generation.
24], we can solve these problems while maintaining the The application is intended to present the material of the
“exploratory” nature of the hypermedia paradigm. The Portinari Project to the general public, for access in a kiosk
main contribution of 00HDM is the way it structures the or through the Word Wide Web.

Permissionto make digital/hard copies of alI or part of tM material for

persortal or claaaroom use is granted without fee provided that the copies
are not made or distributed for profit or commemiaI advantage, the copy-
right notice, the title of the publication and its date appear, and notice is
given that copyright is by permission of the ACM, Inc. To copy otherwise,
to repubtish, to post on servers or to redistribute to Ma, requires specific
permission and/or fee.
Hypertext ’96, Washington DC USA
@1996 ACM o-89791-778-2196103. .$3.50

116
 Figure 1: The Main Menu in the Portinari Project Application (WWW version)

Figure 1 shows the main menu, where the user has a choice
of viewing a timeline; an alphabetical index of persons
and entities; hierarchical theme index; a hierarchical subject
index (pointing to different types of documents); a
hierarchical index of techniques ; a guided tour; and a
search function.

(a)
Figure 2:
(a) A screen of the guided tour about the “War” and “Peace” panels at the UN headquarters
(b) A screen showing the information about a photograph in the collection

117
Each screen may contain references to documents or
artworks that are part of the collection, such as an interview
(which may be heard by clicking on the speaker icon). For
instance, clicking on the picture, it is possible to find out
more information about this document (a photograph), as
shown in figure 2b. In this screen, the arrows next to the
date allow the user to navigate through other available
photographs in chronological order (and it is indicated that
this is the 12th out of 14 photographs available). Since the
reader arrived at this photograph via the guided tour, the
bottom left row indicates that it is possible to navigate
directly to other items cited in the guided tour (by clicking
on the arrows), or to navigate back to the guided tour (by
clicking on the guided tour name to the right of the arrows).
This information would not be present if the reader had
arrived through other paths.
Changing subject, let us assume the reader has chosen the
“theme” button in the main menu. A series of hierarchically
nested indexes of subjects will be presented eventually
leading to a particular theme, for example “Brazilian
culture/children’s games/top”. Upon choosing this theme,
the reader will see the screen in figure 3.

Figure 3: A screen showing information about an artwork

documented by the Portinari Project

This screen shows information about an artwork (a painting the artwork will show a large scale, full screen version of
in this case). On the top left, the first three rows indicate the the image.
theme, date and technique of the artwork. For each row, the
left column (darker area) gives contextual information, such The anchor “description” presents a textual description of
as the fact that this is only painting with this theme the artwork; the anchor “history” presents a textual
(indicat~d by 1/1). Clicking on the right (left) arrow in each description of its history (who bought it, if and where it
row will take the reader to the next (previous) artwork with was shown as part of an exhibit or auction, etc...); the
the same theme, the next (previous) artwork in anchor “references” presents a list of documents in the
chronological order or the next (previous) artwork using the collection that make reference to this artwork; and anchor
same technique. “persons and entities” shows a list of persons or entities
related to this artwork. Let us assume the reader has clicked
The descriptive text below these lines shows general on “history”, and sees the information shown in picture 4a.,
comments about the artwork, including references to other where it is mentioned that this artwork was shown in the
artworks as is the case when, for example, the current “Mostra di Candido Portinari” exhibit. Clicking on the
artwork is a study for another one. Clicking on the image of exhibit’s name, the user will see a screen with information
about it, shown in figure 4b.

118
 (a) (b)
Figure 4:
(a) Additional information about an artwork, including an exhibit in which it appeared
(b) A screen showing information about an exhibit documented by the Portinari Project

This screen follows the same conventions as the previous from an artwork, which has also been shown in other
ones. The first row at the top left allows the user to exhibits. Clicking on the button “artworks” the user can see
navigate, by clicking on the arrows, to other exhibits in a (clickable) list of the artworks that participated in this
chronological order, and it is indicated that this is the third exhibit and if the user now chooses the same artwork, the
out of four exhibits available. The bottom row, on the left, screen in figure 5 will appear (compare with figure 3b).
shows that the reader has arrived at this exhibit navigating

Figure 5: Information about an artwork, with contextual information about exhibits in which it appeared

119
The bottom row now shows information about the artworks models describing particular design concerns are built or
that participated in the event “Mostra di Candido Portinari”. enriched from previous iterations.
Clicking on the right (left) arrow will show the next
(previous) artwork that appeared in that exhibit (this is the 2.1 Conceptual Design
fifth of nine) in chronological order. If the user clicks on During Conceptual Design a model of the application
the name of the context (“artworks in Mostra di Candido domain is built using well known object-oriented modeling
Portinari”), an index (in this case, a screen with thumbnail principles (OMT, [26]), augmented with some primitives
images) of all the artworks in that context is shown, and the such as attribute perspectives and sub-systems. Conceptual
user may select one to continue navigation. It should be classes may be built using aggregation and
noted that this “selective appearance” of contextual generalization/specialization hierarchies typical of object
information was a design decision for this application. orientation. The main concern during this step is to capture
the domain semantics as “neutrally” as possible, with very
2. 00 HDM’S DESIGN PROCESS little concern for the types of users and tasks. The product
The Object-Oriented Hypermedia Design Method is a of this step is a class and instance schema built out of Sub-
model-based approach for building hypermedia Systems, Classes and Relationships.
applications. It comprises four different activities namely
conceptual design, navigational design, abstract interface Figure 6 shows (a simplified version of) the conceptual
design and implementation. They are performed in a mix of schema for the example application, where, for the sake of
incremental, iterative and prototyped-based development conciseness, we have not shown all attributes of all classes.
style, as discussed in [22]. During each activity, except for A brief inspection of this schema shows that it has
the last one (implementation), a set of object-oriented information that can be used by many different types of
users for many different purposes.

----- -----------;
references 1
I M
I
! 1

I ~ext, Sound, Picture] = ‘-- ;Corresp;ndence ~

I
I
I
I
I
I
recewes
:
i
I
I
I
Date-Place: String 1
I Description: Text .,,. 4
I
1
!

w
Biography Text .wn.&<’ ‘
WUG. lte~er
II

I
I Date-Place: String
I depicts Theme: Strin
I Description: [Ymage, Te t]
I Techmqua String
Comments: Text
I Date-of-Visit Date
! Photographer Strina

i I Event
J is exhibited in

I
I
I
I mentions
~
7
i..__L..__...__...~..––––– -––..--~
Figure 6. Then conceptual schema for the “Portinari Project”

In this example, class “Artwork” has attribute arrow between “Reference” and the dashed box is a
“Description” which has two perspectives, “Text” and shorthand to indicate that “Reference” is related to all other
“Picture”, corresponding to textual (which may be used for classes within the dashed box via the “references” relation;
full text search) and pictorial representations of the artwork, the same holds for “Historical Comments”.
exemplifying an extension 00HDM makes to OMT. The

120
2.2 Navigational Design Person

In order to have an application that can be used by a set of Name: String

intended users, trying to accomplish a certain set of tasks, it Code Integer
is necessary, in general, to reorganize the information Date-Place String
represented in the conceptual model. In OOHDM, this is Description: Anchored Text
Picture Image from
achieved by defining a navigational model that is a view (in Artwork.Description.image ,,
the sense of databases) of the conceptual model. This Reference. Description. Picture
reflects the point of view that one of the key distinguishing Artwork Anchor(depicts-l+ owns-l)
features of hypermedia applications is the notion of Reference Anchor(authors+
navigation, and the navigation space must be designed grants+ receives)
Biography: Text
taking into account the types of intended users and the set
of tasks they are to perform using the application. Different
navigational models may be built for the same conceptual
schema, entailing possibly several applications, each
Guided Tour Commentary 1
catering to different set of users and tasks.

Navigation
navigational
design is expressed in two schemas, the
class schema, and the navigation context
schema. The navigable objects of a hypermedia application
are defined by a navigational class schema whose classes
reflect the chosen view over the application domain. In
LHistorical Commentary. Description.Te

Illustration

OOHDM, similarly to HDM [9] and RMD [15], there is a Picture Image from
Artwork.Description.image n
set of pre-defined types of navigational classes: nodes, Reference. Description. Picture
links, and access structures. The semantics of nodes and
links are the usual in hypermedia applications; access
structures such as indexes and guided tours represent
possible ways of accessing nodes. I Artwork

Title: String
Nodes are defined as object-oriented views of conceptual Date: String
Theme: String
classes defined during conceptual design, using a query
Picture: Image (from
language similar to the one in [17], allowing a node to be Artwork. Descriptlion.image)
defined by combining attributes of different related classes Description: Text (from
in the conceptual schema. They contain single typed Artwork. Description. Text)
attributes and link anchors, and may be atomic or Technique: String
Comments: Anchored Text
composites as in [11]. Links reflect relationships intended
Trajectory String
to be explored by the final user and are also defined as References: Anchored Text
views on relationships in the conceptual schema. Persons: Anchor (depicts + owns)
Previous-Th: Anchor (previous-theme)
Figure 7 shows three navigational class definitions for the Next-Th: Anchor (next-theme)
example. Although there is some similarity with the Previous-Dt Anchor (previous-date)
Next-Dti Anchor (next-date)
conceptual classes, several differences are worth noting. Previous-Tq: Anchor (previous-technique)
For example, node class “Artwork” does not contain Next-Tq: Anchor (next-technique)
several attributes of the “Artwork” conceptual class – e.g.,
photographer’s name, date of visit (by photographer), name
of researcher, etc .... –, as they represent information
deemed of no interest to the intended audience. Note also Figure 7: Navigational Class Schema for the
that attributes with multiple perspectives become different Portinari Project application
attributes of the node class, for example
“Description’’/’’Text” becomes “Description” and Navigational class “Person” also shows an example of
“Description’’/’’Image” becomes “Picture”. “cutting and pasting” of attributes, since it essentially
enriches conceptual class “Person” with the
“Description’’/’’Image” perspective taken from the
corresponding attribute of a “Photograph” (or “Artwork”)
to which the “Person” is related via the “is referenced” (or
“depicted in”) relation. Similarly, navigational class
“Guided Tour Commentary” is built by combining the
“Description’’/’’Text” attribute of conceptual class
“Historical Commentary” with an aggregation of
“Illustration”s, whose “Picture” attribute is derived from
the “Description’’/’’Image” attribute of “Photograph” or of

121
“Artwork”. It should also be noted that node classes include In OOHDM the navigation space is structured using the
“Anchor” attributes for all the outgoing links, which in turn notion of navigational context (see [1, 29] for a more
are views of relations in the conceptual schema. The extensive discussion). A navigational context is a set of
anchors corresponding to “previous” and “next” in some of nodes, links, context classes and other (nested) navigational
the examples shown in section one will be further explained contexts. They are induced from navigation classes – nodes,
after we discuss navigational contexts. links, indexes, and guided tours. They may be defined
intentionally by defining a property that all nodes and links
In well-designed hypermedia applications the author must in the context holder, or extensionally by enumerating its
take into account the way in which the user explores the members. For example, a l-to-n link induces a navigational
hypermedia space in order to avoid redundant information context that allows traversing sequentially all the link
and to prevent the user from getting “lost in hyperspace”. targets (e.g., all references to an artwork). In the same way
For example, one may access artworks in chronological an index (e.g., all paintings about childhood) or a guided
order. When examining one artwork, the user may decide tour (some selected paintings) defines a navigational
that he is interested in looking at other artworks with a context. Navigational contexts play a similar role as
similar theme. At that point, it should be made clear to the collections [10] and have been inspired in the concept of
user that there are now options of continuing to examine the nested contexts [5].
artworks by theme or in chronological order, and the user
should have the means to indicate his choice of navigation. Figure 8 shows the navigation context schema for the
As a consequence, a different situation arises when Portinari Project application, and figure 9 shows the
presenting the same material in different contexts, as definition of one of the contexts that appear in the
exemplified in figures 3b and 5. navigation schema.

iuidedTour Item
Main Menu
I ~ Artwork
----- ----- --

\
I Themes ‘“ ‘> ~ (Hierarchical)Theme Index ~-
------ -----s ,
4
r------- . . . . .
!
I
Techniques

Tlmelme
‘+ .:+, (Hierarchical)TechniqueIndexL
-------
, . . “w
----e. -I

I .W ----- . . . . . . . . . . . . . . -

f
I ‘t 4
yiimmvEvent
rtwor ocumerl

I Personsand Entities .. —..-”, . .. . . . . . .

----- -----
.

--
~.

(
T
~, erson/Entity by Nam

E’ 7
t

1 Documents - > I (Hierarchical)Subject Index

I ----- ----- --
~
1/
--’”’’-’”lHis’O’a::::dTOurb
Figure 8: Navigational Schema for the Portinari Project application

In the diagram in figure 8, the actual navigation contexts drawn in detail, as they would be very complex. The boxes
are boxes with light gray border (e.g., “Artwork by on the left (“Main Menu” items) are just place-holders to
Theme”); boxes with darker gray borders are used to group indicate the nesting of the elements pointed to by the gray
contexts for referencing purposes, such that arrows pointing arrows.
to solid boxes indicate links to any enclosed item; the
hierarchical indexes drawn with light dashed lines were not

122
 m allow querying the specification against desired properties
Artwork by <event>
includes: such as safety, livenesss, etc.
v a .s Artwork, e e Event I (e,a) e exhibited A

e.Title= <event> 2.3 Abstract Interface Design

Once the navigational structure has been defined, it must be
entry pointa:el [first node]
I made perceptible to the user through the application
path circular, ordered ascending on interface, which is done in this step by defining an abstract
interface model. This means defining which interface
~ objects the user will perceive, and in particular the way in
which different navigational objects will appear, which
interface objects will activate navigation, the way in which
Figure 9: Definition of Navigational context multimedia interface objects will be synchronized and
“Artwork by Event” which interface transformations will take place.

Context classes complement the definition of a navigational A clean separation between both concerns, navigational and
class (a node) indicating which information is shown and abstract interface design, allows building different
which anchors are available when accessing the object in a interfaces for the same navigational model, leading to a
particular context. This mechanism achieves a “layering” higher degree of independence from user-interface
effect whereby the information in a node can be further technology. In addition, this separation allows a better
customized depending on the context in which the node is understanding of the overall application structure by clearly
being looked at. There is no equivalent mechanism in indicating which transformations in the interface are also
traditional object oriented models. navigational transformations and which are simply local
interface transformations that do not affect the state of the
The navigational context defined in figure 9 collects the navigation.
artworks that were shown in a given exhibit; its elements
are instances of navigational class “Artwork”. Navigation In spite of the previously mentioned interest in hypermedia
within the context is achieved by extending this class with design methods, and even though interface design is a
the context class “Artwork in Event”, whose definition is critical aspect of the creation of large hypermedia
shown in figure 10 below. This context class essentially applications [27], human-computer interfaces are usually
adds the context navigation anchors that allow the user to described using implementation and environment
browse through the elements of this context (see figure 5, dependent tools, and design decisions at the interface level
bottom row on the left). A common use for context classes are seldom documented.
is to add comments (oftentimes as narration) that are only
visible within the particular context, for example in a In 00HDM we use the Abstract Data View (ADV) design
guided tour, approach for describing the user interface of a hypermedia
application [7]. Abstract Data Views are formal, object-
I cc
oriented models of interface objects and they are specified
Artwork in Event I by showing:

E
● The way in which they are structured using aggregation
and generalizationlspecialization as abstraction
mechanisms. ADV’S express the static lay-out structure
that implements the interface metaphor [12, 27].
Perception properties are also specified as attributes or
Figure 10: Context class “Artwork in Event” parts of an ADV. ADVS allow defining the interface
extends class “Artwork” within the “Artwork by appearance of navigational objects and of other useful
interface objects (such as menu bars, buttons and
Event” context
menus).

The dynamic navigational structure is completely specified c The way in which they are statically related to navigation
by defining the navigational transformations that occur objects. We use Configuration Diagrams [6] as a
while traversing links. In some cases, for instance, we may diagrammatic tool for expressing these relationships.
want specify that the source node remains active, and the c How they behave when reacting to external events; in
target node becomes active as well; or that all destination particular how they trigger navigation, and which
nodes of a one-to-many link become active simultaneously. interface transformations occur when the user interacts
In OOHDM we use an object-oriented state-transition with the application. We use ADV-Charts [3], another
model derived from Statecharts [14], that we call derivative of Statecharts, that adds both structural and
Navigation Charts, supporting structural and behavioral behavioral nesting and a Petri-Net like notation for
nesting and allowing expressing dynamic navigational expressing synchronization issues typical of
behavior. The Navigation Chart definition is complemented multimedia data.
with a set of predicates expressed in Temporal Logic that

123
The modeling constructs we use during navigational and We give brief example using the navigation class
abstract interface design are very similar – in fact we use “Artwork” (from the schema in figure 7) and its associated
classes and objects with a formal connection model – and interface objects, by presenting the behavioral specification
thus we obtain a seamless transition between both of the corresponding Abstract Data View in just enough
activities, allowing incremental construction of the detail to show that we can build a formal but nevertheless
navigational and abstract interface models. At the same simple and readable specification.
time, crucial design decisions are recorded using a notation
that is powerful and concise. Navigation- and ADV-charts Figure 11 shows a simplified Configuration Diagram
may be easily related and combining information in specifying some abstract interactions among interface and
interface and navigation classes results in a strong navigational objects (called “owners” of the interface
traceability model. The reader may find a complete object). Dashed lines are required services while full ones
description of our approach in [24]. are provided services. Attributes “theme”, “date” and
“technique” act as static interface objects, i.e. they do not
react to external events.

Ei57L-,F
MouseOn I E

MouseClickecll 1- ~:chor ,

Selected I
Qw!Y

Figure 11: Configuration Diagram for ADV “artwork”

Nested Abstract Data Views “Picture”, “Description”, “Subject” and “Name” and “AnchorSelected”. When both
“Context Interface”, “Show Description” and “Show ADV and node attributes have the same name and type we
References” exhibit a user-perceivable behavior. For can omit specifying services like “GetDate” because it can
example when the user clicks on “Show Description” the be unambiguously understood by implementors. Note that
ADV “Description” is displayed. “Context Interface” is in “Show Description” and “Show References” do not trigger
turn composed of nested ADVS implementing anchors for navigation, they just implement local interface behavior.
context navigation as previously discussed.
In the figure above some interface objects (such
This dynamic description is specified using ADV-Charts, “References”) may have embedded anchors triggering
that extend StateCharts to user interface specification (see navigation; in this case the owner (node “Artwork”) is sent
25). We can specify the behavior of each nested ADV using the message “anchorSelected” with corresponding anchor
a different statechart or use a concise specification as as argument and the interface objects are removed from the
shown in figure 12. For example, ADV “Artwork” can perception context (“Artwork” in state “Off’).
react to external events MouseOn, MouseClicked and
Display, while node “Artwork” provides “GetDate”,

124
 ,.,..—.. .--, .—,. . . . . ...
vvnen mousebllcKea on mcnol
DV artwork
ownerAnchorSelected(),
PaintingOff
w /
When MouseClicked

❑m
self ShowLargeImage
\ Picture escn tlon
WhenShow
- self Oisplay
On
When MouseClicked
Descriptionshow
WhenMoueeClicked
\

R4
References and not Focus,
~self Hide
When MouseClicked ‘lzz7
Referenceshow >
s how On

L /[

Figure 13: ADV Chart for ADV “Artwork”

2.4. Implementation “History”, “References” and “Persons and Entities”, when

To obtain a running implementation, the designer has to activated, produce different behavior than the HTML
map the navigational and abstract interface models into version. In the Toolbook-based one the expression: self
concrete objects available in the chosen implementation Display is implemented by a scrollable “pop-up” field
environment. The model generated after performing which shows the corresponding information, while in the
previously defined activities can be implemented in a HTML implementation this effect is achieved by a local
straightforward way using many of the currently available scroll effect using a local anchor (see figure 4a). Similarly
hypermedia platforms such as Hypercard, Toolbook, the expression “self ShowLargeImage” (in “Picture”) is
Director, HTML, etc. implemented in different ways in both implementations.
The condition “not Focus” in “Description”, easily
The object-oriented style of the abstract interface implemented in Toolbook, is changed in the HTML
specification allows simplifying the interface in implementation by providing a button for scrolling back,
implementations in different platforms. For example, figure although it could also be implemented using the “back”
14 shows the Toolbook version of the same node shown in button of the browser.
figure 5. In this implementation, the anchors “Description”,

Figure 14. Toolbook version of the screen for “Artwork”

125
There are other differences in each implementation of the interface, as for instance the fact that it is not possible to
example, For instance, the guided tour in the Toolbook have “pop-up” fields (or more generally, layering) in
version has additional transition effects, as well as HTML browsers.
soundtrack, The observing reader will have noticed that the
Toolbook version has a “back” button in the bottom right 3.2. Related Work
set of controls, which is not present in the HTML version. OOHDM is a direct descendant of HDM. It differs from
The reason is that the semantics of the “back” function in HDM first in its object-oriented nature, and in that it
the web browser is exactly the same as the “previous” link includes special purpose modeling primitives for both
in navigation contexts, whereas the same function in navigational and interface design. In RMM [15] the authors
Toolbook has different semantics, and therefore it has to be also emphasizes the need for an iterative and incremental
programmed explicitly. development life cycle; they also consider navigational and
interface design to be important activities. 00HDM differs
Another interesting kind of implementation for OOHDM- from RMM in that it includes the concept of navigational
based projects is the one provided by object-oriented contexts and in that it explicitly models the user-interface
frameworks [16]. We have designed an implemented a interaction and the effect of each user-generated event both
framework that allows adding hypermedia functionality to in the interface and in the navigational state of the
object-oriented applications. In this case the conceptual application.
model is finally implemented using an object-oriented
language and navigational classes are instantiated from the Navigational contexts are similar to “collections” as
framework (see [25, 4]). reported in [1 O]. Although not cast in an object-oriented
framework, collections play a similar role as navigational
3. DISCUSSION contexts. There is no close equivalent to navigational
3.1 Relations between the models objects as mappings of conceptual objects and collections
As the reader may have noticed there are some do not allow object extension as is possible with context
relationships among the conceptual and navigational objects. The possible navigation semantics for collections
models; in fact in other hypermedia design methods (like are a subset of the navigational semantics allowed by
HDM or RDM) both activities employ the same kind of contexts.
modeling primitives. We find conceptual modeling a
different activity when either we are planning to build more Other authors have proposed the use of formal models for
than one application in the same domain (for different users specifying hypertext semantics. In [32] for example,
profiles or tasks) or when we want to stress the difference StateCharts are used for modeling different browsing
among conceptual classes and attributes and more semantics in hypertext. Our work is similar in that it uses
opportunistic and navigation oriented objects. In simpler ADVcharts (a derivative of StateCharts) for expressing the
applications, however, the conceptual and navigational dynamics of the application. However it is different
models will be very similar. Derived entities in HDM play because it clearly separates navigational behavior (a
the same role, as they may represent combinations among concern of navigational design) from interface
conceptual objects (entities in HDM) similar to our specification; moreover as ADVS may be composed to form
navigational classes. higher level ADVS, nesting in ADVcharts not only indicate
composition by behavior as in StateCharts, but also
Another interesting issue arises when comparing the structural composition.
navigational and interface models. It is clear that each
navigational transformation (e.g. leaving a node and 3.2. Using Object Orientation
reaching another) causes an interface transformation (e.g. a As stated in the introduction, we do not delve in this paper
window is closed and another is opened). However, not in the object orientation aspects of 00HDM, but for the
every interface transformation is caused by a navigational sake of completeness we mention here a few key points.
operation - for example a “local” scroll effect showing The advantages of using structural object-oriented
more information of a node is not caused by a link modeling constructs in hypermedia (i.e., exploring the data
traversal, even if a new window (or interface element) structuring definition facilities) have been discussed
appears. Understanding this difference helps in obtaining elsewhere [21]. These kind of advanced data modeling
better design models that can be more easily implemented approaches provide high level abstraction and composition
in multiple platforms. By having the two models, 00HDM mechanisms (e.g. classification, aggregation and
facilitates this separation of concerns, helping the designer inheritance hierarchies) with well-defined semantics, As
focus on the important issues during each step of the design object-oriented methods are now mature we can profit from
process. both the process models [20] and the heuristics defined in
those methods [23]. We also benefit from the work on
Finally, although in theory one could completely separate views in object oriented databases [17], which allows us to
the abstract interface specification from the define navigational models as views of conceptual models,
implementation, in practice we have observed that many with well defhed semantics.
times some features of the implementation environment, if
already chosen, may condition “low-level” aspects of the

126
In addition to these benefits, fully using object orientation Computer Interaction”. Cambridge University Press,
by allowing all our primitive classes to have behavior as 1994.
well allows us to
[4] S. Carvalho, G. Rossi; A. Garrido, “Design Patterns in
● extend the conceptual and navigational models with an Object-Oriented Framework for Hypermedia”,
classes defining other design artifacts such as editors Proceedings of the Conference of the Chilean
and browsers, with well-defined communication Computer Science Society, forthcoming.
patterns with hypermedia components. This is
important both for applications combining hypermedia [5] Casanova, M.A.; Tucherman, L.; Lima, M.J.; Netto, J.
with other kind of computations [2] as for example L. R; Rodriguez, N.; Soares, L.F.G., “The Nested
Software Engineering Environments or Geographic Context Model for Hyperdocuments”, Proceedings of
Information Systems, and for applications that also Hypertext’91, San Antonio, 1993.
allow the user to edit and modify the hyperbase [25].
[6] D. Coleman; F. Hayes; S. Bear, “Introducing
● conform with existing models and tools for dealing with
Objectcharts or How to use Statecharts in Object-
the human-interface of multimedia applications,
Oriented Design”, IEEE Transactions on Software
defining the interface model as a reactive model that
Engineering, 18(1), 9-18, January 1992.
interacts with the navigational model to achieve the
desired navigational and interface transformations [24].
[7] D. D. Cowan; C. J. P. Lucena, “Abstract Data Views,
● reason about common navigation and interaction design An Interface Specification Concept to Enhance Design
patterns [8] in order to build new hypermedia for Reuse”, IEEE Transactions on Software
applications by reusing design ideas and to have a Engineering, VO1.21, No.3, March 1995.
common vocabulary among designers [25].
5. CONCLUSIONS [8] E. Gamma, R. Helm, R. Johnson and J. Vlissides,
We have presented the Object Oriented Hypermedia Design “Design Patterns, Elements of Reusable Object-
Method, discussing each of its four basic steps. A full Oriented Software”, Addison Wesley, 1994.
discussion of all models used would each take a full paper
by itself, so have tried to illustrate the main points by using [9] F. Garzotto, D. Schwabe, P. Paolini, “HDM- A
an example taken from an actual implementation, running Model Based Approach to Hypermedia Application
both on the WWW and in Toolbook. Design”, ACM Transaction on Information Systems,
Vol. 11, #l, Jan. 1993, pp. 1-26.
We are now pursuing investigation in several topics, among
which are [10] F. Garzotto, L. Mainetti and P. Paolini, “Adding
Multimedia Collections do the Dexter Model”,
● ways to express design patterns at all levels; Proceedings ECHT’94, Edinburgh, Sept. 1994.

● tools to at least semi-automate the translation of 00HDM

[11] K. Gronbaek, “Composites in a Dexter-Based
models into runtime environments such as the WWW,
Hypermedia Framework”, Proceedings of the ACM
Toolbook and Director;
European Conference on Hypermedia Technology,
● graphical “wysiwyg” tools to simplify abstract interface Edinburgh, 1994.
specification;
● incorporating intentionally specified links; [12] J. Hannemann, M. Thuring, “What matters in
developing interfaces for hyperdocument
● ways to specify navigation contexts at high levels of
presentation?’, Workshop in Methodological Issues
abstraction, using, for example, notions from
on the Design of Hypertext-based User Interfaces,
linguistics such as Rhetorical Structure Theory.
Darmstadt, Germany, July 1993.
6. REFERENCES
[1] S. D. J. Barbosa,. “Modeling and Specification of 13] L. Hardman; D. Bulterman; G. Van Rossum,
Navigation in Hypermedia Applications”, MSC “Links in Hypermedia, the Requirements for
Thesis, Dept. of Informatics, PUC-Rio, Feb. 1995 (in Context”, Proceedings Hypertext’93, ACM, pp 183-
Portuguese). 191.

[2] M. Bieber; C. Kacmar, “Designing Hypertext Support 14] D. Harel; A. Pnueli; J.P. Schmidt; R. Sherman, “On
for Computational Applications”, Comm ACM, the formal semantics of statecharts”. Proc. 2nd. IEEE
August 1995, pp 99-107. Symposium on Logic in Computer Science, Ithaca,
N. Y., June 1987.
[3] L.M.F. Carneiro; M.H. Coffin; D. D. Cowan; C.J.P.
Lucena, “ADVcharts, a Visual Formalism for Highly [15] T. Isakowitz; E. Stohr; P. Balasubramaniam, “RMM,
Interactive Systems”. In M.D. Harrison and C. A methodology for structured hypermedia design”,
Johnson editors, “Software Engineering in Human- Comm ACM, August 1995, pp 34-48.

127
[16] R. E. Johnson; B. Foote. “Designing Reusable [28] D. Schwabe; G. Rossi, “From Domain Models to
Classes”, Journal of Object-Oriented Programming, Hypermedia Applications. An Object-Oriented
June/July 1988, Volume 1, Number 2, pages 22-35. Approach”, International Workshop on Methodologies
for Designing and developing Hypermedia
[17] W. Kim, “Advanced Database systems”, ACM Press, Applications , Edinburgh, September 1994.
1994.
[29] D. Schwabe; S. D: J. Barbosa, “Navigation Modeling
[18] D. Lange, “An Object-Oriented design method for of Hypermedia Applications”, Technical Report
hypermedia information systems”, Proceedings of the MCC 42/94, Departamento de Inform&ica, PUC-Rio,
27th. Annual Hawaii International Conference on 1994 (available at <ftp:llftp.inf.puc-rio.brlpubldocsf
System Science, January 1994. techreports/ 94_42_barbosa.ps. gz>)

[19] Lanzelotte, R. S.G.; Marques, M.P.; Penna, M. C. S.G.; [30] D. Schwabe and G. Rossi, “Building Hypermedia
Portinari, J. C.; Ruiz, F. D.; Schwabe, D., “The Applications as Navigational Views of Information
Portinari Project, Science and Art team up together to Models”, Proceedings of the Hawaii International
help cultural projects”, Proc. of the Second Conference on System Sciences, Hawaii, Jan. 1995.
International Conference on Hypermedia and (available at <ftp://ftp.inf. puc-rio.br/publdocs/
Interactivity in Museums (ICHIM’93), Cambridge, techreports/ 94_41_schwabe.ps .gz>)
UK, Sep. 1993.
[31] D. Schwabe and G. Rossi:, “The Object Oriented
[20] J. Mc. Gregor; T. Korson, “Integrated Object-Oriented Hypermedia Design Model”, Comm. of the ACM,
Testing and Development Process”, Comm ACM, vol. 38, #8, Aug. 1995. (available at
September 1994, <http://irss.njit. edu:5O8O/cgi-bin/bin/option.csh?
sidebars/schwabe. html>).
[21] J. Nanard; M. Nanard. “Using Structured Types to
Incorporate Knowledge in Hypertext”, Third ACM [32] Y. Zheng, M-C. Pong: “Using Statecharts to Model
Conferences on Hypertext Proceedings, Hypertext’91 Hypertext”, Proceedings of the ACM European
ed. ACM Press. pp.. 329. Conference on Hypertext, Milano, December 1992.

[22] J. Nanard; M. Nanard, “Hypertext Design

Environments and the Hypertext Design Process”,
Comm. of the ACM, Vol. 38, #8, Aug. 1995.

[23] J. Odell, “Six different kinds of compositions”,

Journal of Object Oriented Programming, Vol. 5 ++8,
1994.

[24] G. Rossi; D. Schwabe; C.J.P. de Lucena; D.D.

Cowan, “An Object-Oriented Model for Designing the
Human-Computer Interface of Hypermedia
Applications”, Proceedings of the International
Workshop on Hypermedia Design (IWHD’95),
Springer Verlag Workshops in Computing Series,
forthcoming. (available at <ftp://ftp.inf. puc-
rio.brlpubldocsltechreportsl 95_07_rossi.ps. gz>).

[25] G.Rossi; A. Garrido; S. Carvalho, “Object-Oriented

Patterns for Hypermedia Applications”, Proceedings
of Patterns Languages of Programs (PLOP’95),
forthcoming.

[26] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and

W. Sorensen: “Object Oriented Modeling and Design”,
Prentice Hall Inc. 1991.

[27] W. Schuler, “A Design Space for Hypermedia

Interface”, Workshop on Methodologies for
Designing and developing Hypermedia Applications ,
Edinburgh, September 1994.

128