CS835
- Data and Document Representation & Processing
|
|
Lecture 11 - Hypermedia V - Design:
OOHMD, RMM |
Hypermedia
application models (and methodologies)
From: http://www.iua.upf.es/~jblat/material/doctorat/application_models.html
Introduction
We recall that a hypertext or hypermedia application
is a specific network of interconnected information, while a system is a
tool which can be used to create applications. In this part we discuss models
(and methodologies) which might help improve the design and construction of
hypermedia applications (products).
Software products are currently built using software
engineering, which should help improve the quality of the products. Two key
components of this engineering are data modelling which provides an
abstraction of the “objects” the software deals with; and methodologies
which are systematic steps to be followed in the design and construction of the
software.
Hypermedia applications are quite different
from the classical software applications, such as the data processing system of
a bank. In a classical application there is a massive amount of data, and/or
processing of these data; and the user usually wants to access a small part of
these data very quickly, and perhaps modify it in some way. In a hypermedia
application the user wants to go through a significant part of the data, the
information; one of the key aspects is association as V Bush introduced it; and
the design of the application should help the user navigate this information
through these associations. It is likely that the data models and the
methodologies for “engineering” hypermedia applications should be quite
different.
In this part we deal with these questions.
We are going to discuss several proposals for data models and methodologies for
hypermedia design, starting by a relatively simple one, RMDM - RMM. We will
give a short introduction to the Entity-Relationship modelling necessary for
the understanding and discussion of the aspects we present here.
The RMM – RMDM
methodology and model
RMM stands for Relationship Management
Methodology; RMDM is an acronym of Relationship Management
Data Model. The model is strongly based on the most used way of
modelling software applications currently, the Entity-Relationship modelling
which we introduce very briefly after summarising RMDM and RMM.
RMDM adds some domain primitives (slices:
attributes of entities are grouped for presentation) to the E-R ones (entities,
attributes, one-one and one-many associative relationship), and access
primitives which support navigation (unidirectional link, bidirectional
link, grouping, index ...). The steps of the RMM methodology
are: S1 is the E-R design, S2 is the slice design, S3 is the navigational
design, S4 is the conversion protocol design, S5 is User-Interface
Screen Design, S6 is Run-time behaviour design, S7 is construction.
The entity-relationship
model
The Entity-Relationship model allows us to
abstract the structure of a database and it is a key step in a good design of
the database. It is also important that the model is represented graphically.
Both things ensure that the forecasted needs are fulfilled in an optimal way.
Most current databases are relational (the object-oriented databases, likely to
replace them, are not yet widespread). Let us see some important points of the
relational model.
Objects that appear in real life, are
abstracted into what is called entities; Students, Employees,
Aeroplanes, Cars, Hotels, ...can be examples of very different types of
entities. Entities are composed of several attributes; for instance, the
attributes of the entity Students could be Name, Surname, Identity number,
Nationality, Date of birth, ... Attributes are also called columns. Each
entity can have an unlimited number of rows, which are specific members
of the entity; some of the rows of Students can be those corresponding to
Garrett, Dani, Claudia, ... Combining these three elements, there appears the
classical structure of a table. That is why attributes are also called
columns and objects rows; those concepts are similar to those of file -
table -, field - attribute - and register - row -. The following
is a simple example of a table.
Table Students:
|
Name |
Identity no |
Nationality |
Date of birth |
|
Garrett |
99.999.999 |
Irish |
2-2-1969 |
|
Dani |
88.888.888 |
Spanish |
8-8-1968 |
|
Claudia |
77.777.777 |
Colombian |
7-7-1967 |
|
... |
|
|
|
Another concept of this model is the relationship
amongst entities. Relationships can be of three different types:
- 1
to1: a row of a table (in other words, an object of an entity) is related
to one row at most of another table. For instance, the relationship capital of
a country is 1 to 1: consider an entity with countries, and another one with
cities: each country will have just one city which is its capital; and a city
will be capital of just one country.
- 1 to N: a
row of a table can be related to more than one row of another table. For
example, the relationship nationality of a student: each student has a
nationality (we suppose that h/she can have only one), but there can be several
students of the same nationality.
- N to M: a
row of an entity can be related to several rows of another one, and reciprocally.
The relationship of a student being enrolled in a subject of a course is an
example of this type. A student is usually enrolled in more than one subject
(relation 1:N), and a subject has got several students (relation 1:M).
The model can be represented
graphically in the following way:
- entities as boxes with the name inside
- relationships are represented as
Relationship
1:1
Relationship
1:N
Relationship
M:N
RMDM
The data model RMDM (Relationship Management
Data Model), extends the model E-R just described, in order to provide
appropriate modelling for the design hypermedia information systems. RMDM
distinguishes two types of primitives: domain primitives which
model domains or classes of objects, and access primitives which support
modelling for the navigation.
For the domain primitives, RMDM includes
some coming from the E-R model: entities, attributes, one-one associative
relationship, one-many associative relationship. But it introduces a new one
called slice, which denotes some attributes which are grouped together
(mainly for presentation purposes). The graphical representation of an entity
and a specific slice can be as follows:
As we said, access primitives support
navigation; RMDM introduces the following ones: unidirectional and bi-directional
links, for access between slices of an entity; grouping which is a
construct supporting menu-like access or index, which is a table of
contents to a list of entities; conditional index, an index which can be
qualified by a predicate, guided tour, defined as a linear path through
a collection of items; conditional indexed guided tour, which represents
a guided tour qualified by a predicate.
Let us give a simple example illustrating
the meaning of these concepts. The hotel entity could be visited through a Conditional
Index : the list of the hotels (of a certain category - which is the
condition -) appears on the screen and we can choose the one we want to see.
The following diagram is used to represent this type of access.
We could use a Conditional Guided
Tour, indicating that we go from the first hotel to the following one and
so on; we can go forwards and backwards. The graphical representation is:
We use a Conditional Indexed Guided Tour
as a hybrid solution of an index which leads us to a (partial) guided tour. The
representation is:
The grouping primitive is used to
model a menu: as many options as wished hang from this primitive, which is
represented as an inverted triangle.
A menu allowing the three types of access
would be represented as:
The following table is a summary of the
concepts and representations just seen:
|
Domain primitives |
Entity |
|
|
|
Attribute |
Attribute |
|
|
Slice |
|
|
Access primitives |
Index |
|
|
|
Guided tour |
|
|
|
Indexed guided tour |
|
|
|
Grouping |
|
|
|
Link |
|
The links, which represent
connections between slices, are also called structural links. The associative
relationships interconnect different entity instances or different entities.
When a user traverses an associative link, the information context
changes. However, when a structural link is traversed, the information context
remains within the same entity.
RMM
A methodology is a systematic procedure to
build applications. RMM (Relationship Management Methodology) is a
methodology for hypermedia application design based on RMDM. We describe
briefly the different steps of the methodology.
Step 0: Feasibility and requirements
As in every methodology, the initial step is
a feasibility study and requirements analysis (both of the information and
navigation). Usually hardware selection is also performed.
Step 1: E-R design
This is a typical step in current
methodologies. An E-R diagram is created, separating N:M relationships into two
1:N relationships. The specific hypermedia goal of this phase is to uncover the
relationships of the objects, which potentially will indicate navigation paths
later.
The following simple example is from Toni
Navarrete and we follow it through all the steps. Let us consider an
information system of hotels in a region, with five entities: Hotel, Town,
Service, Room and Category; the town-hotel, category-hotel, hotel-room are 1:N
relationships, while service-hotel is N:M.
Attributes are also specified in this phase;
but in this example we perform it in the following step.
Step 2: Slice design
The attributes of an entity are divided into
slices. The hypermedia point of view is that of the navigation. For instance,
the whole information of a hotel could be in the same slice (we would need a
window with scrolling to be able to show that); but an alternative could be
general information being a slice, and another one with the name and multimedia
material (for instance, video). Perhaps the general information is too big and
we choose a summary slice, and two other slices, more detailed textual
information and multimedia information.
RMDM introduces the concept of slice head,
which is the one accessed by default when accessing the entity (perhaps the
summary in the case of a hotel). In this step one also defines the structural
links, for navigation between slices
The following table could be an example of
hotel slices
|
General * (head) |
Name |
|
|
Address |
|
|
Telephone |
|
|
Fax |
|
|
E-mail |
|
|
URL |
|
|
Number of floors |
|
|
Date of construction |
|
|
Number of rooms |
|
Situation |
How to get there |
|
|
Distance to the beach |
|
|
Distance to the airport |
|
|
Distance to the main city |
|
|
Distance to the bus stop |
|
Multimedia |
Video |
The structural links in this case could be
as:
Step 3: Navigational design
The relationships obtained in step 1 are
replaced in this step by RMDM access primitives. A guided tour is not advisable
when there is a large number of instances, but it might be convenient for a
small number. An index should help when there is a large number; and a
conditional guided tour could be a compromise. Group primitives are used for
menus. Although a hierarchy can be created, a big depth is counterintuitive for
most users.
Slice heads are also defined in this step.
The final result of these steps is an RMDM
diagram.
In the example we are doing, the following
diagram would correspond to an index for hotel-service and category-hotel, a
guided tour for hotel-room and an indexed guided tour for town-hotel.
Most "backwards" links are not
explicit in this diagram, because it would give too much redundancy, but we
consider, for instance that we can go from category to hotel and backwards
(although this is not explicit).
An example of the use of grouping for menus
would be enabling the access either through towns (via conditional index) or
hotel category (via index). This would be represented as:
Step 4: Conversion protocols design
Steps 4 to 6 can be performed simultaneously
from the RMDM diagram.
Step 4 is defining how to transform each
RMDM element in the hardware-software platform chosen. This could be an
automatic conversion program, or more often instructions to the programmers.
For instance, entities transformed into database tables, attributes as columns,
...
Step 5: User interface design
In this step, the graphical design of the
screens which represent the RMDM elements should be obtained. Important aspects
to be taken into account are: slices, access structures, general navigation
tools, anchor appearance, ... Prototyping in low-fidelity (paper, for instance)
or high-fidelity (photoshop) should be of help.
Step 6: Run-time behaviour design
Defining the mechanisms (algorithms) to be
implemented for traversing links, for keeping history, to allow backtracking,
...
Step 7: Construction and testing
This phase is the effective construction of
databases, algorithm implementation, ... Finally, extensive testing is
suggested.
RMM and RMDM
modifications and improvements
Modifications proposed by the authors of
RMM and RMDM
There have been several modifications and
improvements to the data model RMDM and methodology RMM, mainly proposed by
their authors which we describe first.
In the paper Systematic hypermedia design
the authors propose hybrid slices, which combine attributes from
different entities and access structures; and minimal slices, as the
minimal meaningful way of referring to a slice.
In the later paper Russian Dolls and
Hypertext three main limitations of RMM are described: Inability to specify
what information is to be shown as the content of an anchor; inability to allow
aggregation of attributes outside a single entity; no element can contain both
attributes and access structures. The solution proposed is to introduce m-slices,
which are used to group information into meaningful units, replacing slices and
group constructs. M-slices are owned (each by one specific entity) although
they might contain attributes of other entities and access structures. They
define what information is to be part of a construct and where to obtain it.
M-slices do not say how this information is to be presented. They can be nested
up to arbitrary levels. Also anchoring is supported.
In a later paper of the authors, The
extended RMM methodology for Web publishing, they describe the evolution of
RMM in response to the rapid growth in demand for hypermedia applications on
the World Wide Web. They discuss database integration, top-down versus bottom
up approaches to Web Information System (WIS) development, graphical and
programming language notations for RMM’s new constructs.
Modifications introduced in the CD-ROM Atles
de les Illes Balears
Toni Navarrete introduced some modifications
both to RMM and RMDM in his work for the Atles de les Illes Balears.
|
|
Hyperlink inferred in
hierarchical relationships 1:N |
|
|
Random access |
|
|
Simultaneous access |
|
|
Multiple index |
|
|
Multiple guided tour |
|
|
Multiple indexed guided
tour |
|
|
Access in relationships
N:M |
HDM
Introduction
The authors of HDM (Hypertext Design
Model) were Garzotto, Paolini and Schwabe. The model should be useful to
design a hypertext or hypermedia application.
In the model they introduce the following
terminology: authoring-in-the-large, to denote the specifications and
design of the global or structural aspects of the application, and authoring-in-the-small,
to denote the aspects of development of the content of the nodes. This
separation into different aspects might also promote a better design. This part
deals mainly with the former, as the latter is both more specific of
applications and dependent on development tools.
HDM primitives
Entities and entity types
The basic bricks of the model are called entities:
they are information chunks of reasonable although minimal size, which are
meaningful autonomously. Entities are grouped into entity types. Some
examples of entity types could be Painter, Artists' Live, Picture type,
Subject.
Perhaps it is worth remarking that entities
for HDM are a lot more complex, and more structured internally than entities in
the E-R model.
Components and units; the structure of an
entity and the perspective
Each entity is made of a hierarchy of components;
components can be made of units. The units are the smallest pieces of
information and can be visualised from a specific perspective.
More specifically, an entity is a
hierarchically structured collection of components, in a tree structure; there
is a root, which has son components (mutually brothers), which might have other
sons, until we get to the leaf components (the last ones). The most common
relationship is part-all. Units are information containers and components are
abstractions of sets of components. In HDM entities cannot be components of
other entities.
The notion of perspective allows for
different presentations of the same content. For instance, in a multi-lingual
presentation, the different languages give different perspectives. Remark that
the logical structure of the presentation is not altered.
A unit corresponds to a component associated
to a specific perspective. A unit is characterised by its name (an identifier)
and a body. The bodies are the locations where the information is
stored; a unit usually combines atomic parts of information which are shown
together.
Links and types of links
Links are also primitives in HDM, which distinguishes three types. Structural
links are those connecting together components of the same entity. Perspective
or component links are those connecting different units of the same
component. Finally, applicative links denote domain dependent
relationships; they can be divided into two broad categories: schema links,
which have pre-defined syntactic and semantic features, and generic links,
which are more specific. For instance, if there is an entity type Historical
Period, and another one Painter, an applicative link might go from Goya to
XVIII and XIX Century; this link would probably be a schema link, as each
painter will be linked to his/her historical period. A generic link might go
from Goya to Duquesa de Alba (that link would not exist in general for many
painters, usually female relationships are not that important systematically).
Usually, perspective and structural links are automatically derived from the
structure, and schema links can be automatic too. Perspective, structural and
applicative links will usually have names, and will be specifically typed. In
the previous example, the schema link could be called Historical period of the
painter; it would probably be symmetrical (or bi-directional).
Collections
Collections are ordered sets of objects (entities, components,
other collections). They are used mainly for navigational purposes. In HDM
there is a special one, dynamically generated, which is the ordered set of
units visited.
Schemas
HDM specification of a hypertext application
consists of a schema definition, which specifies a set of entity types
and link types; and a set of instance definitions, the definition of the
instances is only allowed to be inserted if the instance matches the
constraints of the schema. This terminology derived from databases; schemas are
sort of templates.
Outlines
An application in HDM can be divided in two
portions: a hyperbase of the structured nodes, links, ... as we have
defined them and a set of access structures which should give entry
points for the navigation. The only access structure defined in HDM is the outline,
which is a tree for the main access of the hyperbase.
HDM structure and
browsing semantics
First, we remark that part of the primitives
belong to the structure-in-the-large, while another part to the
structure-in-the-small. For instance entity types, structural and schema links
belong to the former structure, as well as collections. Units and perspective
links belong the latter.
A second remark is that links could be
automatically generated. For perspective links, an example could be that if
Opera has two perspectives, Score and Sound, for each one two links are
created. For structural links and using the hierarchical structure, operators
such as up, down, upN, downN, ... would create automatic patterns. Other
operators such as inversion, composition, ... would enable the computation of
derived links and even of derived link types.
The browsing semantics has a default
one: units are identified to nodes (loci of navigation control) and perspective
links enable navigation from the nodes. There is a default representative of
each unit, ... and a default perspective; links become thus concrete. The
structural links become links between corresponding perspectives of linked
components. Alternatively, another semantics could be defined. For the
perception of links anchors are defined and anchor types,
corresponding to link types, are also introduced.
The structure-in-the-large is made of the
general organisation (a set of collections) and structural and schema links.
The dynamics-in-the-large is the definition of: the navigation of the
collection, which can be through visiting one member after the other - guided
tour - or by index; and the structural and schema link navigation.
OOHDM
OOHDM stands for Object-Oriented Hypermedia
Design Method. It is an evolution of HDM, and it is more than a model, it is
also a method. Specifically, it is a model-based approach for building
hypermedia applications. It comprises four different activities: conceptual
design, navigational design, abstract interface design and implementation.
We will describe it according to the paper Systematic Hypermedia Application
Design with OOHDM, where the authors (Schwabe, Rossi, Barbosa) describe it
using an example, the Portinari Project about a famous Brazilian painter, as
illustration.
Conceptual Design
In this step, a model of the application
domain is built using object-oriented modeling principles (OMT), augmented with
some primitives such as attribute perspectives and sub-systems. According to
the authors, 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. The product of this step is a class and
instance schema built out of Sub-Systems, Classes and Relationships. In the
Portinari Project examples of classes are Artwork, Interview, ... An attribute
of Artwork is Description, which has two perspectives, Text and Picture. There
is a parallel with the concepts of HDM (entity types, components, perspectives,
...)
|
The figure shows (a
simplified version of) the conceptual schema for the Portinari Project,
where, for the sake of conciseness, all attributes of all classes are not
shown.
The conceptual schema
for the "Portinari Project" |
Navigational design
A navigational model is a view, in the sense
of databases, of the conceptual model, and according to the authors it is
targeted to a set of intended users. The separation from the previous step
would help the re-use, as different navigational models may be built for the
same conceptual schema, for different set of users and tasks.
Navigation design is expressed in two
schemas, the navigational class schema, and the navigation context
schema. For the navigational class schema, there is a set of pre-defined
types of navigational classes: nodes, links, and access
structures (indexes and guided tours, ...). In OOHDM, nodes are defined as
object-oriented views of the conceptual classes defined previously. The node
can be defined by combining attributes of different related classes in the
conceptual schema. They contain single typed attributes and link anchors, and
may be atomic or composites. Links are also defined as views on relationships
in the conceptual schema. The relationships which are interesting for the users
are transformed into access structures.
The second part of the navigational design
proceeds after introducing the notion of navigational context, which is a set
of nodes, links, context classes and other (nested) navigational
contexts. Navigational contexts play a similar role as collections in HDM.
Somehow, they allow to introduce the contexts (to encapsulate the way the user
navigates the application).
|
The figure shows three
navigational class definitions for the example. |
Figure: Navigational
Class Schema for the Portinari Project application |
Abstract interface
design
After navigation has been designed, the
following step is to perform an abstract interface design, which means defining
the objects the user will perceive. OOHDM proposes doing that in a well
structured and documented way, using Abstract Data Views. We have to
design the way in which navigational objects will appear, which objects will
activate navigation, the way in which multimedia objects will be synchronized
and which transformations will take place, all at the visualisation level, and
thus we call those objects interface objects to differentiate them from the
conceptual or navigational objects.
Abstract Data Views are formal,
object-oriented models of interface objects and they are specified by showing:
- the static lay-out structure that
implements the interface (with all the elements, including menus, ...), with
perception properties as attributes or parts of an ADV
- how interface objects are related to
navigation objects: Configuration Diagrams are used for that
- how interface objects behave when reacting
to external events; ADV-Charts that add both structural and behavioral nesting
are used; Petri-Net like notation is used for expressing synchronization
issues.
Implementation
Finally, during the implementation phase the
first step is to map the navigational and abstract interface models into
concrete objects available in the chosen implementation environment (or
possible to build). And then implementing them.
Prototyping, ...
The authors of OOHDM insist that these steps
should be performed in a mix of incremental, iterative and prototyped-based
development style. During each activity, except for the last one
(implementation), a set of object-oriented models describing particular design
concerns should be built or enriched from previous iterations.
References
The RMM page, where a lot of things can be retrieved.
Balasubramanian V., Bieber M., Isakowitz T.:
Systematic hypermedia design, preprint, http://eies.njit.edu/~333/bala.html,
CRIS Working Paper series 5/10/96, 1996.
Garzotto F, Paolini P, Schwabe D: HDM - A
model-based approach to hypermedia applications design, ACM Transactions on
Information Systems, 11, 1-23, 1993.
Garzotto F, Mainetti L, Paolini P:
Hypermedia design, analysis, and evaluation issues, Comm ACM, 38(8),
74-86, 1995.
Isakowitz T, Stohr E A, Balasubramanian P:
RMM: A methodology for structured hypermedia design, Comm ACM, 38(8),
34-44, 1995.
Isakowitz T., Kamis A., Koufakis M.:
Extending the capabilities of RMM: Russian dolls and Hypertext, pre-print,
http://www.stern.nyu.edu/~tisakowi, 1996.
Isakowitz T., Kamis A., Koufakis M.: The
extended RMM methodology for Web publishing, pre-print, 1999.
Schwabe D, Rossi G, Barbosa S D J:
Systematic Hypermedia Application Design with OOHDM, Proceedings of the ACM
International Conference on Hipertext (Hypertext'96), Washington, March
1996, pp 116-128.
Summary of OOHDM
From: http://www.oohdm.inf.puc-rio.br:8668/space/summary+of+OOHDM
Hypermedia applications are
seen as systems that are built to function as part of a man-machine team. The
part of the problem to be solved by the machine uses whatever techniques that
are appropriate - Data Bases, Knowledge Based Systems, Hypermedia, Information
Retrieval Systems, etc.... The part of the problem that is solved by the human
being uses a hypermedia framework to aid the human being in managing the stored
knowledge. The hypermedia paradigm is used also to smoothly integrate the formal
(used by the machine) and informal (used by the human being) knowledge
representations. A significant (sub) problem is how to develop Hypermedia
applications, and how to integrate these applications in the framework
described above. Hypermedia applications typically include complex information,
and may allow sophisticated navigation behavior. The Object-Oriented Hypermedia
Design Method (OOHDM) uses abstraction and composition mechanisms in an object
oriented framework to, on one hand, allow a concise description of complex
information items, and on the other hand, allow the specification of complex
navigation patterns and interface transformations.
In OOHDM, a hypermedia application is built in a
four-step process supporting an incremental or prototype process model. Each
step focuses on a particular design concern, and an object-oriented model is
built. Classification, aggregation and generalization/specialization are used
throughout the process to enhance abstraction power and reuse opportunities.
The table below summarizes the steps, products, mechanisms and design concerns
in OOHDM.
|
Activities |
Products |
Formalisms |
Mechanisms |
Design
Concerns |
|
Requirements Gathering |
Use Cases, Annotations |
Scenarios; User Interaction Diagrams; Design Patterns |
Scenario and Use Case Analysis, Interviews, UID mapping to
Conceptual Model |
Capture the stakeholder requirements for the application. |
|
Conceptual Design |
Classes, sub-systems, relationships, attribute
perspectives |
Object-Oriented Modeling constructs; Design Patterns |
Classification, aggregation, generalization and
specialization |
Model the semantics of the application domain |
|
Navigational Design |
Nodes, links, access structures, navigational contexts,
navigational transformations |
Object-Oriented Views; Object-Oriented State charts;
Context Classes; Design Patterns; User Centered Scenarios |
Classification, Aggregation, generalization and
specialization. |
Takes into account user profile and task. Emphasis on
cognitive aspects. Build the navigational structure of the application |
|
Abstract Interface Design |
Abstract interface objects, responses to external events,
interface transformations |
Abstract Data Views; Configuration Diagrams; ADV-Charts;
Design Patterns |
Mapping between navigation and perceptible objects |
Model perceptible objects, implementing chosen metaphors.
Describe interface for navigational objects. Define lay-out of interface
objects |
|
Implementation |
Running application |
Those supported by the target environment |
Those provided by the target environment |
Performance, completeness |
A
Summary of the OOHDM Methodology
1
Requirements Gathering
The first step is to gather the stakeholder
requirements. To achieve this, it is necessary to first identify the actors
(stakeholders) and the tasks they must perform. Next, scenarios are collected
(or drafted), for each task and type of actor. The scenarios are then collected
to form a Use Case, which is represented using User Interaction Diagrams. These
diagrams provide a concise graphical representation of the interaction between
the user and the system during the execution of a task.
The UIDs are validated with the actors, and
redesigned if necessary. In sequence, a set of guidelines are applied to the
UIDs to extract a conceptual model.
2
Conceptual Design
In this step a conceptual model of the application
domain is built using well-known object-oriented modeling principles, augmented
with some primitives such as attribute perspectives (multiple valued
attributes, similar to HDM perspectives. Conceptual classes may be built using
aggregation and generalization/specialization hierarchies. There is no concern
for the types of users and tasks, only for the application domain semantics. A
conceptual schema results, built out of sub-systems, classes and relationships.
3
Navigational Design
Here we describe the navigational structure of a
hypermedia application in terms of navigational contexts, which are induced
from navigation classes such as nodes, links, indices, and guided tours.
Navigational contexts and classes take into account the types of intended users
and their tasks. Nodes in OOHDM represent logical "windows" (or
views) on conceptual classes defined during domain analysis. Different
navigational models may be built for the same conceptual schema to express
different views on the same domain. Links are derived from conceptual
relationships defined in step 1. By defining the navigational semantics in
terms of nodes and links, we can model movement in the navigation space (i.e.,
the subset of nodes with which users can interact at any given moment)
independently of the conceptual model. The navigational model may evolve
independently from the conceptual model, simplifying maintenance .
4
Abstract Interface Design
The abstract interface model is built by defining
perceptible objects (e.g. a picture, a city map, etc.) in terms of interface
classes. Interface classes are defined as aggregations of primitives classes
(such as text fields and buttons) and recursively of interface classes.
Interface objects map to navigational objects, providing a perceptible
appearance. Interface behavior is declared by specifying how to handle external
and user-generated events and how communication takes place between interface
and navigational objects.
5
Implementation
Implementation maps interface objects to
implementation objects and may involve elaborated architectures, e.g.,
client-server, in which applications are clients to a shared database server
containing the conceptual objects. A number of CD ROM based applications, as
well as web-sites, have been developed using OOHDM.