Developing Hypermedia Applications using OOHDM

Daniel Schwabe* and Gustavo Rossi**

(*)Departamento de Informtica. PUC-RIO, Brazil
E-mail: schwabe@inf.puc-rio.br
(**)LIFIA, Fac Cs. Exactas, UNLP, Argentina; CONICET; UNLM
E-mail: gustavo@sol.info.unlp.edu.ar

Abstract
In this paper we discuss the use of an object-oriented approach for
hypermedia applications design, including web-based, based on the Object Oriented
Hypermedia Design Method (OOHDM).

We first motivate our work discussing the problems encountered while

designing large scale, dynamic web-based applications, which combine complex
navigation patterns with sophisticated computational behavior. We argue that a
method providing systematic guidance to design is needed. Next, we introduce
OOHDM, describing its main activities, namely: conceptual design, navigational
design, abstract interface design and implementation, and discuss how OOHDM
designs can be implemented in the WWW. Finally, related work and future
research in this area are further discussed.

1. A Brief Overview of OOHDM

The Object-Oriented Hypermedia Design Method is a model-based
approach for building large hypermedia applications. It has been used to design
different kinds of applications such as: web sites and information systems,
interactive kiosks, multimedia presentations, etc.

OOHDM comprises four different activities namely, Conceptual Design,

Navigational Design, Abstract Interface Design and Implementation. They are
performed in a mix of incremental, iterative and prototype-based development
styles. During each activity a set of object-oriented models describing particular
design concerns are built or enriched from previous iterations.

As we explain below, treating conceptual, navigational and interface design

as separate activities allows us to concentrate on different concerns one at a time.
As a consequence we get more modular and reusable designs, and we obtain a
framework to reason on the design process, encapsulating design experience
specific to that activity. Besides, the interface design primitives can be easily
mapped to non object-oriented implementation languages or environments (such
as HTML or Toolbook) and thus OOHDM can be used regardless of whether the
target system is a pure object-oriented environment one or a hybrid one (as those
we usually find in the Internet). In Figure 1 we show a sketch of the activities in
OOHDM and in Figure 2 we briefly describe OOHDM activities, primitives,
concerns and abstraction mechanisms (an extension of the one shown in [Schwabe
95]).

1
Figure 1: OOHDM design models

Activities Products Formalisms Mechanisms Design

Concerns

Conceptual Classes, sub- Object-Oriented Classification, Model the

Modeling systems, Modeling aggregation, semantics
relationships, constructs generalization and of the application
attribute (classes, specialization domain
perspectives relationships,
use cases)

Navigational Nodes, links, Object-Oriented Classification Users profile and

Design access structures, Views Aggregation, task. Emphasis on
navigational Object-Oriented generalization and cognitive aspects.
contexts, State charts specialization
navigational Context Classes
transformations User centered
Scenarios
Design Patterns

Abstract Interface Abstract interface Abstract Data Mapping between Model perceptible
Design objects, responses Views navigation and objects,
to external events, Configuration perceptible implementing
interface Diagrams objects. chosen
transformations ADV-Charts Composition and metaphors.
Design Patterns generalization/ Describe interface
specialization for navigational
objects
Define lay-out of
interface objects

Implementation Running application Those supported Those provided by Performance,

by the target the target completeness
environment environment

Figure 2: Summary of the OOHDM Methodology

In the next sections, we describe each phase in more detail.

2
2. Conceptual Modeling
During Conceptual Design a model of the application domain is built using
well known object-oriented modeling principles, with a notation similar to UML.
The product of this step is a class schema built out of Sub-Systems, Classes and
Relationships. The major differences with UML are the use of multiple-valued
attributes, and the use of directions explicitly in the relations

Conceptual classes may be built using aggregation and generalization/

specialization hierarchies. The main concern during this step is to capture the
domain semantics as neutrally as possible, with very little concern for the types
of users and tasks. If the application involves operations on those objects as in
dynamic Web-applications, the conceptual model will evolve into an object model
that will be implemented in the target environment (for example in a W W W
server). In this case, navigation objects will act as observers [Gamma95] of these
application objects.

OOHDM does not prescribe any particular method to produce the

Conceptual Class Schema; any of the well known methodologies (OMT, UML) may
be employed.

Figure 3 shows a Conceptual Schema for the Academic Department Web

site. Perspectives (multiple valued attributes) are denoted by enumerating the
possible types, with a + next to a default type. Thus, description: [text+, image]
means attribute description has a text perspective (always present), and may have
also a photo perspective.

3
 belongs
produces
0..N 0..N
Sponsor Laboratory Personel
Name: string Name: string Name: string
UrlSponsor: string Description: string Degree: string
0..N N Description: [text+, image]
conducted in Equipment belongs Email: string
funds HomePage: string
Name: string
N
N
Research Project N N
Academic Technical Administrative
Name: string participates N
N Description: string 0..N
N
Budget: real N N N N
Professor advises Student produces Students Production
0..N N N
Rank: string N N OnLineContent: string
belongs Degree: string
N
belongs
1
Area of Research teaches
N
N Graduation Thesis
Name: string Course Offering
Description: string attend Project
N
Semester: string 1
N 1
N Schedule: string Evaluation: integer pursues PhD MSc
Classroom: string
1 1
N StudentID: integer
BeginningDate: date
Complementary Material EndingDate: date
related OnLineContent: string
Location: string

belongs offered
requires
Slide WorkBook Exercise
N
N Degree
has elective
N
Name: string
Course N RequiresAmount : integer
1 Name: string ElectivesAmount : integer
0..N N
has required
belongs Description: string
N NumberOfCredits: integer N
N Research Result 1
SuggestedPeriod : string
Title: string Syllabus : text Graduate Undergraduate
PublicationDate: date
Abstract: text 0..N 0..N
Autors: set of string requires
1
MSc PhD requires
1
requires
Book Technical Report Paper Software Hardware
Edition: string Code: string BiblioReference: string OnLineContent: string
Publishing: string OnLineContent: string OnLineContent: string

Conference Paper Journal Paper

UrlConference: string UrlJournal : string

Figure 3: Conceptual Schema of the Academic Department Site

3. Navigational Design
In OOHDM, an application is seen as a navigational view over the
conceptual model (see Figure 2). This reflects one of the major innovations of
OOHDM, which recognizes that the objects (items) the user navigates are not the
conceptual objects, but other kinds of objects that are built from one or more
conceptual objects. Therefore, node attributes are defined as object-oriented views
of conceptual classes, using a query language similar to the one in [Kim94],
allowing a node to be defined by providing access to attributes of different related
classes in the conceptual schema. This view is oriented towards a certain class of
users and their respective tasks. Nodes generalize the Observer concept from
[Gamma95].

4
 For example, in the conceptual model a research project is linked to its
sponsors (a separate class). However, for most classes of users, there is no need to
have a separate node describing the sponsor; it suffices to have their respective
names and URLs to their sites as a reference. Therefore, in the navigational node
corresponding to research project is defined as having two virtual attributes
whose values are respectively a list of sponsors names and URLs, mapped from
the corresponding attributes of the conceptual class sponsor.

The implementation of this functionality depends on the target

implementation environment; in a full object-oriented system, nodes will contain
a method that returns the sponsors name and URL by collaborating with the
corresponding object. In a hybrid implementation, the sponsor's name and URL
will be implemented in the sponsors node (and in its corresponding interface).

The navigational structure of a hypermedia application is defined by a

schema specifying navigational classes. In OOHDM there is a set of pre-defined
types of navigational classes: nodes, links, anchors and access structures. The
semantics of nodes, links and anchors are the usual in hypermedia applications.
Access structures, such as indexes, guided tours, etc represent possible ways of
accessing nodes.

In the same way as navigation objects, links reflect conceptual relationships

intended to be explored by the final users. Different applications (over the same
domain) may contain different linking topologies according the users profile. For
example an Academic Web site may have a view for use by students and
researchers, and another view for use by administrators. In the second view, a
professor's node may contain salary information, which would not be visible in
the first view.

5
 belongs
conducted in N
N N 0..N
N Students Production
Research Project Laboratory
OnLineContent: string
0..N Name: string Name: string Personel
Description: string Description: string
Budget: real Equipments: set of string Name: string
Degree: string
SponsorNames: list of anchor ( UrlSponsor ) PrfsIdx : index (Professor by Laboratory) Graduation Thesis
Sts : anchor( index (Student by Laboratory) ) Description: image Project
N Bio: text
0..N Prjs : anchor( index (Research Project by Laboratory) )
Email: string 1
0..N HomePage: string PhD MSc
participates
belongs produces 1 1
N N

Academic Technical Administrative

Rsts : anchor ( index (Research Result + Students Production by Author) )

Prjs : anchor ( index (Research Project by Person) )
N
produces N

Professor Student 1
belongs
N Rank: string
1 PrdsIdx: index (Students Production by Student)
belongs ArsIdx : index (Area of Research by Professor) CrsIdx : index(Course Student by Student)
Crs : anchor ( index (Course Offering by Professor) )
1 1 1
N N
Sts : anchor ( index (Supervised Student by Professor) )
1 1
Area of Research supervised took degree
teaches advises requires
Name: string
Description: string N N N N
PrfsIdx : index (Professor by Area of Research)
related Crs : anchor ( index (Course by Area of Research) ) Course Offering Supervised Student Degree Student
Prjs: anchor ( index (Research Project CourseName: string StudentName: string attend StudentName: string
by Area of Research) ) NumberOfCredits: integer ProfessorName: string DegreeName: string
Rsts: anchor ( index (Research Result SuggestedPeriod : string Degree: string StudentID: integer
+ Students Production by Area of Research) ) ResearchArea: string BeginningDate: date
1
Lbs: anchor ( index (Laboratory by Area of Research) ) ProfessorName: string EndingDate: date
N Semester: string
N 1 enrolled N
Schedule: string Course Student
Classroom: string
N StudentName: string N
N Semester: string
Complementary Material CourseName: string
Evaluation: integer
OnLineContent: string
Location: String pursues
belongs offered

Slide WorkBook Exercise

1
Course
N N Degree
Name: string has elective
N 1 Description: string Name: string
NumberOfCredits: integer RequiresAmount : integer
N Research Result N
belongs SuggestedPeriod : string has required ElectivesAmount : integer
Title: string N N CrsIdx : index (Course by Degree)
ResearchArea: string
0..N
PublicationDate: date Syllabus : text
Abstract: text RqsIdx : index (Course by Requirement) 1
Autors: set of string Offs : anchor ( index( CourseOfferings by Course) )
Graduate Undergraduate
0..N 0..N
requires
1
Technical Report Paper Software MSc PhD requires
Code: string BiblioReference: string OnLineContent: string 1
OnLineContent: string OnLineContent: string requires

Book Conference Paper Journal Paper Hardware

Edition: string UrlConference: string UrlJournal : string

Publishing: string

Figure 4 Navigation Class Schema for the Academic Web site. Note the conversion
of relations with attributes into classes (e.g., Professor advises
Students on a Degree)

Once the navigation classes have been decided, it is necessary to structure

the navigation space that will be made available to the user. In OOHDM this
structure is defined by grouping navigation objects into sets called contexts. Each
context definition includes, besides which elements are included in it, the
specification of its internal navigation structure, an entry point, access restrictions
in terms of user classes and operations, and an associated access structure.

There are six different ways to define contexts:

1- Simple class derived - all objects of a class that satisfy some property;
e.g., professors with rank equal associate. A variant of this type is the
query based context, where the property is defined by the user at
navigation time.

Graphically:

6
 2- Class derived group - a set of simple class derived contexts, where the
defining property of each context is parameterized; e.g. professors by
rank (rank can vary).

Graphically:

3- Simple link derived - all objects related to a given object; e.g., courses
taught by professor Smith. Graphically, same as 1.

4- Link derived group - a set of link derived contexts, each of which is

obtained by varying the source element of the link; e.g. courses taught,
by professor (professor varies). Graphically, same as 2.

5- Arbitrary - is an enumerated set; e.g., a guided tour. Graphically, same as

1

6- Dynamic - is a set where the elements change during navigation; e.g.,

history.

Graphically:

Associated to the contexts, there are access structures (indices). They are
denoted graphically by:

Index:

Dynamic Index:

Index with multiple orderings:

In any of the above, if there is an access structure defined for it, the
corresponding graphical notation contains a small black square in the upper left
corner.

The navigation structure of the application is defined in a context diagram,

which shows all the access structures and contexts defined for this application, and
the possible navigations between them. Figure 5 shows the context diagram for the
academic site.

7
 Supervised Student
by Professor
Personel
Personel Category Professors
Academic
Menu
Professor
Courses
Courses Professors Alphabetic
Menu
by Laboratory
Current by Research Project
Offerings
by Area of Research
Offerings for
Next Semester Student
Students
Students Alphabetic

Main Menu Employees by Laboratory

Employees
by Research Project
Course Offering
Technical +
by Semester Administrative Course Student
Enrollment Choices Alphabetic by Student

Currents by Professor
Research Result +
Students Production
by Course
by Author

by Area of Research
Course
To consult
Alphabetic Courses results Results by Query

by Requirement
Research Project
by Area of Research Research Project Research Alphabetic
Projects
by Degree
by Person
by Laboratory
Courses Degree
by Area of Research

Degree Degrees
Alphabetic Degrees Laboratory
Laboratories
Laboratories Alphabetic

by Area of Research

Areas of Research Area of Research

Areas of
Research Alphabetic

by Professor

Figure 5: The Context Schema for the Academic Department Example

The context diagram does not contain all the information needed to specify all
contexts; each context and access structure must be further detailed in a CRC
Card such as the one shown in Figure 6 and Figure 7.

8
 Context: Course Offering Enrollment Choices Type: dynamic
Attributes:
Parameters: <period>
Include: co Course Offering | co.inContext(Course Offering by Semester )
Selected(co) not SchedulesConflict(co)
Methods:
RemoveCourseOffering (co)
if Selected(co) not Obligatory(co, <period>) then
Context( Course Offering Enrollment Choices ) =
Context (Course Offering Enrollment Choices ) - co
end_if
end RemoveCourseOffering
Classes in context:
Context changes:
Entry points: (1 node default): Any element of the context.
Path: To index. Ordering: [ (by Time Slot)+, (by Name) ]
Type of context link:
Export / Import:
Use restrictions:
User: Permission:
Comments: Group of courses that has been selected during a session to configure
a enrollment (organized by name or by scheduling -days of week -).
Trace backward: Trace forward:

Figure 6: An example of a CRC Card for a context

Access Structure: Offerings for Next Semester Type: class derived

Attributes: NameCourse: string, NumberOfCredits: integer;
SuggestedPeriod: string; ResearchArea: string; ProfessorName: string
Selectors: NameCourse: string
Structure: Set ordered
Ordering: [ (by CourseName ascending)+, (by NumberOfCredits),
(by SuggestedPeriod), (by ResearchArea), (by Professor) ]
by NumberOfCredits: ordered by NumberOfCredits asc NameCourse asc
by SuggestedPeriod: ordered by SuggestedPeriod asc NameCourse asc
by ResearchArea: ordered by ResearchArea asc NameCourse asc
by Professor: ordered by ProfessorName asc NameCourse asc
Destination: co Course Offering inContext(Course Offering by Semester )
Parameters:
Predicate: co Course Offering | co.Semester = next_semester()
Comportment:
Refined in:
Comments: Index of the course offerings to the next semester.
Trace backward: Trace forward:
Figure 7: An example CRC card for an access structure

Once contexts have been defined, it is possible to extend a class definition with a
decorator (see [Gamma 95]), which is called an InContext class. This class adds
attributes to an existing class, when accessed from within a specified context. For
example, the attribute professors name may be included in projects when

9
accessed within research projects by research area, but not when accessed within
context research projects by professor, since the professor's name is implicit.

OOHDM itself does not prescribe any particular procedure to synthesize navigation
designs. To aid the designer, we have developed a method based on user specified
scenarios to guide this process [Gell 98]. According to this method, navigation
design proceeds in the following steps (see Figure 8):

1. Determination of user profiles (types of users); identification of user tasks

2. Scenario collection

3. Analysis of scenarios, producing a simple diagrammatic representation of the

navigation path described in the scenario. In most cases, in this step the
designer has to fill in incomplete information such as implied indexes, missing
orderings, exception handling, etc The designer may use Design Patterns to
help in this step. A second result of this step is a revision of the preliminary
navigation class diagram, as well as a description of how each class used in the
scenario is viewed in it.

4. Synthesis of a partial context diagram, specifying navigation in contexts that

support the task described in the scenario. Again, design patterns describing
known navigation solutions may be employed in this step.

5. Synthesis of final context diagram, through a process of union and

amalgamation of partial schemas produced in the analysis of each scenario in
step 4. Once this final context diagram has been defined, it also possible to
define the navigation class and its InContext classes (decorators). Eventually, a
revision of the navigation class schema may be done.

10
 Preliminary Navigation
Class Schema
For cada
Para eachcenrio:
scenario: Graphic
Esboo grfico,
Para cada
sketch; cenrio: Alternatives;
Questions; Esboo grfico,
Scenario Argumentos, Questes,
Scenarios Argumentos, Questes,
Cenrios
Cenrios Argumentation; Solutions
Alternativas e Solues
Analysis Alternativas e Solues

Design
Patterns Refined Navigation
Class Schema

Design
Patterns Synthesis of Partial
Navigation Schema

For each
Para cadascenario: Partial
cenrio: Esquema Final Context Schema;
Para cada Context
Navigation cenrio: Esquema Union of partial Final InContext Class
parcial de contextos de
parcialInContext
Schema, de contextos de
Class solutions Schema
navegao, Vises das classes
navegao, Vises das classes
definitions
nosfor contexts in
contextos
nos contextos
the scenario
Revised Navigation
Class Schema

Figure 8: Steps in synthesizing navigation design using scenarios

In the table below, we summarize user categories and tasks to be supported

in the example.

User TASK
Class
Currents Students

Find out the information necessary to select classes for enrollment in the coming
semester

Find out information about a given course being offered

Choose an advisor

Find out the professors that have taught a given course, and look at the material used in
each offering

11
 User TASK
Class
Prospective
Find general information about the department
Students

Choose a potential advisor

Get the status of a project he sponsors

Sponsors

Find out if there is some research of interest that can be sponsored

Find out a known professor, in order to get in touch with him or her.

Find out information about a given student

Find out a professor to teach a course

All

Find information about the Laboratories

Find information about employees

Look at the academic production of the department

For each category, one must select representative user(s), and ask them to
write a scenario describing how they envisage the system helping them to perform
the task. Figure 9 shown an example.

Task:
Peruse the required courses for obtaining an undergraduate degree in Computer Science

Context:

I am a CS student and I want to study the required courses for my degree credits and
prerequisites in order to plan which courses I will take next semester.

Actions:

1. I look for a Course Structure section, possibly under the Computing Engineering area;

2. I select one course, and I get information on the number of credits, the prerequisite courses and the
suggested semester within the course in which it should be taken.

Figure 9 An example of a scenario description for the Academic Site.

After collecting scenarios, the designer represents them in a simple

graphical notation, to validate it with the user; Figure 10 (a) shows an example. In
sequence, he analyses each one of them, looking for missing information. Users

12
typically omit several types of details, such as access structures, selection attributes
to be used in indexes, orderings, treatment of exceptions, etc The designer can
either supply the missing information out of his own understanding of the
problem domain, or ask the user, or use a previously seen solution for a similar
problem effectively applying a design pattern (see Figure 10 (b)).

Computing Engineering Computing Engineering Course X

Courses {Pre-requisites}
Suggested semester

(a)

(1) Undergratuate
Undergraduate Courses Computing (2)
Courses Engineering Course Course X
Computing Offerings
Engineering Course {Pre-requisites}
Offerings CourseX Suggested
semester

(b)

Figure 10: (a) Simple graphical representation of a scenario;

(b) a revised scenario where missing information has been filled in by
the designer

As an example of the use of Design Pattern, consider the following

fragment of the Navigation Context Diagram shown in Figure 5. This part of the
site supports the enrollment task by providing an index to the courses being
offered in the next semester; this index can have multiple ordering of its entries
(box with a triangle at left). Once the user has chosen the semester, he can browse
the course offerings grouped by semester (for this semester). As the user browses
the courses, he can select some to enroll, building the dynamic context
enrollment choices (box with black bar at right).

This is an instance of the Configuration navigation design pattern,

which describes the situation when a user chooses elements from a set, according
to some restriction, and can later perform computation with the set of chosen
items. A well known use of this pattern is the Shopping Basket found in many
websites. More details on the use of Design Patterns for hypermedia applications
can be found in [Rossi 97, Rossi 98a].

13
 Course Offering

Offering for Next by Semester

Semester

Enrollment
Choices

Figure 11: A Navigation Pattern employed in the Academic Web site

4. Abstract Interface Design

In the Abstract Interface Design activity we specify which interface objects
the user will perceive. It should be recognized that there is a distinction between
navigation operations and interface operations; not everything that happens in the
interface is navigation related. Furthermore, it is useful to design interfaces at an
abstract level, to achieve, among other things, independence of implementation
environment.

The Abstract Interface Specification includes the way in which different

navigational objects will look like, which interface objects will activate navigation,
the way in which multimedia interface objects will be synchronized and which
interface transformations will take place.

User interface design is a critical activity in interactive applications,

including hypermedia. Though objects have been used for years in the field of
user-interface design, the focus has been mainly applied to the software substrate
(as for example the MVC paradigm [Krasner88]) and not to the specification of
contents.

In OOHDM we use the Abstract Data View (ADV) design approach for
describing the user interface of a hypermedia application [Cowan95]. Abstract Data
Views are formal models of interface objects and they are specified by showing:

a-The structural, static aspects of the interface objects using composition.

b-The way in which they are statically related with navigation objects. We
use Configuration Diagrams [Coleman92] for expressing these relationships. An
ADV is related with a corresponding application object which acts as a behavioral
server for those operations not specific to the interface. This object is called the
ADV owner and it is similar to the model object in the well known model-view-
controller object-oriented interface paradigm.

c-How they behave when reacting to external events; in particular how

they trigger navigation and which interface transformations occur when the user
interacts with the application. We use ADV-charts [Carneiro94], a derivative of
Statecharts, that adds both structural and behavioral nesting and a Petri-Net like
notation for expressing synchronization issues usually found when dealing with
multimedia data.

14
 In Figure 12 we show the ADV Professors by Laboratory together with a
mock-up of the actual interface.

Professor by Laboratory ADV

Professor ADV
SelectedAnchor()
Laboratory Alfabetic
Back_Lab : anchor ( Laboratory
Alfabetic (<laboratory>) )

SelectedAnchor()
Next_Prof : anchor( next(
Professor by Laboratory ) )
Professor by Laboratory

Prev_Prof : anchor( previous( SelectedAnchor()

Professor by Laboratory ) )
Academic ADV

Personel ADV

Results: anchor( index(Results by Producer ) )

Projects: anchor ( index(Research Project by

Person) )

Area of
Research
by Professor

SelectedAnchor()

Professor ADV

Academic ADV

AreasIdx : list of ( anchor( Area of

Personel ADV Research by Professor ) )

PersonelCategoryIdx:list of ( anchor(
Personel) ) Courses: anchor ( index(Course
Offering by Professor) )

Name: string
Degree:string Students: anchor ( index(Supervised
Bio: text Student by Professor) )
Description: Image
Email: anchor(self. Email)

HomePage: anchor(self.UrlHomePage)

Figure 12: ADV Professor by Laboratory and its actual interface

See [Schwabe 96, Rossi 96, Schwabe 98b] for further details.

5. Implementation
In this phase, the designer will actually implement the design. Up to now,
all models were deliberately constructed in such a way as to be independent of the
implementation platform; in this phase the particular runtime environment is
taken into account. We will briefly indicate how OOHDM designs can be
implemented in the W W W by looking at one particular approach we have
followed.

15
 Although OOHDM is cast in terms of OO models, it does not require an OO
implementation environment; an implementation based on an OODMBS (O2)
(but not on the web) is described in [Milet 96]; Java-based implementations are
under development.

When the implementation phase is reached, the designer has already

defined the information items that are part of the problem domain. He also has
identified how these items should be organized according to the users profile and
tasks; he has decided what the interface will look like, and how it will behave. In
order to implement all of this in the WWW environment, the designer has to
decide how the information items (both conceptual and navigation objects) will be
stored. He must also decide how the interface appearance and behavior will be
realized using HTML and possibly use some extensions. Notice that, in general, the
actual appearance will be defined by a graphics design professional that should be
part of the design team.

5.1.1 Mapping Information Items

The information items (which correspond to the ADOs in the Abstract

Interface Model) may be stored in files or in a database. Due to the nature and
complexity of the types of applications for which OOHDM is most suited, we
strongly recommend using a database to store the Conceptual and Navigation
objects. Since the majority of DBMSs available on the market today are relational, a
mapping of the OO models onto equivalent relational models must be made.
There are several techniques and heuristics for doing this see for example, [Keller
97]. The methods associated with the classes are implemented as a set of procedures
that access the database to perform their computations.

One mapping alternative that can be used maps each class in the OO model
to be implemented onto a table, where each column stores an attribute, and each
row corresponds to an object of that class. The database key can be a distinguished
attribute, or an internal identifier can be generated.

In section 3 it was stated that the Navigation Model is a view over the
Conceptual model. The designer has the option of reflecting this organization in
the databases corresponding to each model. In other words, he may define the
database containing the Navigation objects (nodes, links, etc...) as a view, supported
by the DBMS, of the database corresponding to the Conceptual model. In the case
where the DBMS does not directly support the view mechanism, or for efficiency
reasons, the designer has the option of computing the view by hand. In this case,
he will only implement the Navigation model, since it is the one the user will be
accessing. Implementing views in the DBMS is useful when companies already
have corporate DBs, and want to use it as the basis for sites in the WWW or in
Intranets.

Once the databases are defined, they must be integrated in the W W W

environment. There are many ways in which this can be done [Hunter 95, Varela
95], and we will not elaborate this further; it suffices to say that any of these
techniques may be employed. In this respect, the criteria for choosing the
integration method are the same as other applications, as discussed in the
literature.

16
5.1.2 Implementing Contexts

To support contexts, the underlying database model or set of files must also
contain the their definitions. With the exception of arbitrary contexts (whose
specification is essentially an enumeration of its members), other types of contexts
include a query or function specification that must be evaluated to compute the
members of the context.

Navigation operations within contexts require keeping state information.

For example, to determine what is the next paper by this author requires
knowing which paper the user is currently looking at, which papers make up the
referenced context (Papers by author), and what is the ordering defined for that
context.

5.1.3 Implementation of the Interface

The actual interface organization and behavior is specified in the ADVs,

and the physical layout and appearance must be defined in this phase. The
implementation of ADVs requires defining page layouts in HTML that are
consistent with the ADV specifications. In those cases when the values of instance
variables are computed at runtime, pages must be generated dynamically, based on
HTML templates previously specified by the designer. These templates usually
contain a mixture of HTML code and calls to functions in some scripting language.
The execution of these functions will retrieve or compute the instance data to fill
in the missing data that make up the final HTML page.

We have designed and implemented an environment based on the

scripting language Lua [Ierusalimschy 96] and on the CGILua environment [Hester
97] called OOHDM-Web [Pontes97]. This environment implements templates that
are a mixture of plain HTML and calls to functions in a library giving access to the
Navigation objects stored in a relational database, accessed via ODBC. Figure 13
contains a schematic representation of the architecture of the OOHDM-Web
environment.

Interface Appearance OOHDM-Web OOHDM Navigation Schema

Environment

Template mixing HTML - Tables describing navigation

with commands using HTML Pages classes
OOHDM-Web library - Tables identifying contexts
functions and CGI-Lua - Tables describing contexts

HTTP Server

Browser

Figure 13 - The structure of the OOHDM-Web Environment

17
 More details about OOHDM Web can be found in [Pontes 97, Schwabe 98a].

6. Conclusions
We are now pursuing several lines of research, as outgrowth or
continuation of the research reported here:

development of a rich and dense set of design patterns that will allow complete
designs to be expressed almost entirely in terms of pattern compositions and
instantiations;
development of a direct manipulation language that will allow rapid
prototyping of interface specifications for HTML documents;
design and implementation of a set of tools that will constitute a development
environment based on OOHDM, for web-based applications, so that designers
are able to deal with entire sites at the more appropriate level of abstraction; a
first component in this environment is OOHDM-Web;
design and implementation of a Java-based substrate to support direct
implementation of OOHDM designs;
extension of OOHDM to incorporate user models and tasks, a security model
and definition of dynamic contexts; a first definition can be found in [Gell 98].
extension of OOHDM to support groupware, and investigation on support for
distributed group authoring using OOHDM.
Acknowldedgment: We would like to thank Natacha Gell Barroso and Patricia Vilain for their
help in preparing the example. Daniel Schwabe is partially supported by a grant from CNPq;

7. References
[Bieber95] M. Bieber; C. Kacmar, Designing Hypertext Support for Computational
Applications, Comm ACM, August 1995, pp. 99-107.

[Carneiro 94] Carneiro, L.M.F.; Coffin, M.H.; Coewan, D.D.; Lucena, C.J.P.L; ADVCharts: a
Visual Formalism for Highly Interactive Systems, in M.D. Harrison, C. Johnson,
eds, Software Engineering in Human-Computer Interaction, Cambridge University
Press, 1994.

[Coleman92] D. Coleman; F. Hayes; S. Bear, Introducing Objectcharts or How to use Statecharts

in Object-Oriented Design, IEEE Transactions on Software Engineering, 18(1), 9-18,
January 1992.

[Cowan95] D. D. Cowan; C. J. P.Lucena, Abstract Data Views, An Interface Specification

Concept to Enhance Design for Reuse, IEEE Transactions on Software Engineering,
Vol.21, No.3, March 1995.

[Gamma95] Gamma, R. Helm, R. Johnson and J. Vlissides: Design Patterns: Elements of reusable
object-oriented software, Addison Wesley, 1995.

[Gell 98] Gell B., N; User centered design of hypermedia applications, MSc thesis, Dept.
of Informatics, PUC-Rio, 1998 (in Portuguese).

[Hester 97] A.M. Hester; R.C.Borges; R. Ierusalimschy; CGILua: A Multi-Paradigmatic Tool for
Creating Dynamic WWW Pages, Proceedings of the XI Brazilian Software
Engineering Symposium (SBES97) pp.347-360, Fortaleza, Brazil, 1997 (available at

18
 http://www.tecgraf.puc-rio.br/~anna/cgilua/ cgilua.ps.gz)

[Hunter 95] A. Hunter, I. Ferguson, S. Hedges: Swoop: An application generator for

Oracle/WWW Systems. Proceedings of the Fourth International World Wide Web
Conference. pp. 185-194, 1995.

[Ierusalimschy 96]R. Ierusalimschy, L. H. de Figueiredo and W. Celes, Lua - an extensible extension

language, Software: Practice & Experience 26 #6 (1996) 635-652. (see also
http://www.tecgraf.puc-rio.br/lua/).

[Keller 97] Keller, W.; Mapping Objects to Tables A Pattern Language, Proc. Of European
Conference on Pattern Languages of Programming Conference (EuroPLOP)97,
Bushman, F. and Riehle, D.; (eds), Irsee, Germany, 1997.
(http://www.sdm.de/g/arcus/publicat/index.phtml#Mapping_Objects_To_Tables)

[ Kim 94] W. Kim, Advanced Database systems, ACM Press, 1994.

[Krasner 88] G. Krasner, S. Pope. A cookbook for using the model-view-controller user interface
paradigm in Smalltalk-80. Journal of Object-Oriented programming, 1(3), pp. 26-49,
August/September, 1988.

[Milet 96] J.Renato Milet; D. Schwabe; R. S. G. Lanzelote, Hypermidia Application

Authoring Using Object Oriented Databases, Proc. of the XI Brazilian Symposium
on Databases (SBBD), SBC, So Carlos, Oct. 1996 (in Portuguese).

[Pontes 97] Pontes, R.C.A., An Environment to Support Hypermedia Applications in the

WWW, MSc thesis, PUC-Rio, 1997 (in Portuguese).

[Rossi96] G. Rossi: An Object-Oriented Method for Designing Hypermedia Applications.

PHD Thesis, Departamento de Informtica, PUC-Rio, Brazil, July 1996 (in
Portuguese).

[Rossi97] G. Rossi, D. Schwabe and A. Garrido: Design Reuse in Hypermedia Applications

Development Proceedings of ACM International Conference on Hypertext
(Hypertext97), Southampton, April 7-11, 1997, ACM Press.

[Rossi 98 a] G. Rossi, A. Garrido and D. Schwabe: Navigating between Objects: Lessons from an
Object-Oriented Framework Perspective, to appear in ACM Computing Surveys.

[Rossi 98 b] G. Rossi and A. Garrido: Capturing Hypermedia Functionality in an Object-

Oriented Framework, to appear in Object-Oriented Frameworks, Wiley 1998.

[Rumbaugh91] Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W.Lorensen: Object Oriented

Modeling and Design, Prentice Hall Inc. 1991.

[Schwabe 95b] D. Schwabe and G. Rossi:, The Object Oriented Hypermedia Design Model, Comm.
of the ACM, Vol. 38, #8, pp45-46 Aug. 1995. (available at
<http://irss.njit.edu:5080/cgi-bin/bin/option.csh?sidebars/schwabe.html>).

[Schwabe96] Schwabe, G. Rossi and S. Barbosa: Systematic Hypermedia Design with OOHDM.
Proceedings of the ACM International Conference on Hypertext (Hypertext'96),
Washington, March 1996.

[Schwabe98a] Schwabe, D.; Pontes, R.A.; Rapid Prototyping of Hypermedia Applications in the
Web, Technical Report MCC 08-98, Dept. de Informtica, PUC-Rio, 1998.
Available at ftp://ftp.inf.puc-rio.br/pub/docs/techreports/98_08_schwabe.pdf.gz

[Schwabe 98b] Schwabe, D.; Rossi, G.; An Object Oriented Approach to Web-Based Application
Design, accepted for publication, Theory and Practice of Object Systems 4 (4), J.
Wiley, 1998

[UML 97] UML Document Set. Version 1.013 January, 1997, Rational, 1997. (available at

19
 http://www.rational.com/uml/references/index.html)

[Varela 95] C. Varela, D. Nekhayev, P. Chandrasekharan, C. Krishnan, V. Govindan, D.

Modgil, S. Siddiqui, , D. Lebedenko, M. Winslett: DB: Browsing Object-Oriented
Databases over the Web. Proceedings of the Fourth International World Wide Web
Conference. pp. 209-220, 1995.

20