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:

• entities as boxes with the name inside
• relationships are represented as

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.

Exercises

Develop the RMM analysis of an application.
Develop the HDM analysis of the same application as before and compare the two models.

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.

Navarrete T: Una metodología relacional hipermedia: Estudio en casos prácticos, Final project of the engineering degree.

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.