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

Data models and methodologies for hypermedia design

The RMM RMDM methodology and model

        RMM - Relationship Management Methodology

        RMDM - Relationship Management Data Model

o       Model is based on Entity-Relationship modeling:

         Entities

         Attributes

         one-one relationship

         one-many associative relationship

o       RMDM adds:

         domain primitives (slices: attributes of entities are grouped for presentation)

         access primitives which support navigation (unidirectional link, bidirectional link, grouping, index ...).

         Steps of the RMM methodology are:

1.      E-R design

2.      slice design

3.      navigation design

4.      conversion protocol design

5.      User-Interface Design

6.      Run-time behavior design

7.      construction

Entity-relationship model

        Real life objects are abstracted into entities( a.k.a rows):

e.g. Students, Employees, Airplanes, Cars, Hotels

        Entities are composed of several attributes(also called columns):

e.g, attributes of the entity Students could be Name, Surname, Identity number, Nationality, Date of birth, ...

        Each entity can have an unlimited number of rows that are specific members of the entity

e.g, some of the rows of Students can be those corresponding to Garrett, Dani, Claudia, ...

        Combining these three elements creates the classical structure of a table.

        e.g., 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

...

 

 

 

Relationships among entities can be of three different types:

  1. 1 to1: a row of a table (an object of an entity) is related to one row at most of another table

e.g., the relationship capital of a country is 1 to 1

 

  1. 1 to N: a row of a table can be related to more than one row of another table.

e.g., 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.

 

  1. N to M: a row of an entity can be related to several rows of another one, and reciprocally.

e.g., 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:

Relationship 1:1

Relationship 1:N

Relationship M:N

 

RMDM

        The data model RMDM (Relationship Management Data Model)extends the E-R model for hypermedia information systems design.

        RMDM distinguishes two types of primitives:

o       domain primitives - model domains or classes of objects

o       access primitives - support modeling for the navigation

 

        Domain primitives - RMDM includes:

o       Entities

o       Attributes

o       one-one associative relationship

o       one-many associative relationship

        New primitive called slice:

o       denotes attributes that are grouped together (mainly for presentation purposes).

o       The graphical representation of an entity and a specific slice is:

 

Access primitives support navigation:

 

Examples:

 

        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:

 

        Conditional Indexed Guided Tour as a hybrid solution of an index which leads 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

        RMM (Relationship Management Methodology) is a methodology for hypermedia application design based on RMDM.

        The different steps of the methodology

Step 0: Feasibility and requirements analysis

Step 1: E-R design

        An E-R diagram is created, separating N:M relationships into two 1:N relationships.

        Hypermedia goal of this phase is to uncover the relationships of the objects, which potentially will indicate navigation paths later.

 

        Consider an information system of hotels in a region

        There are five entities: Hotel, Town, Service, Room and Category;

        the town-hotel, category-hotel, hotel-room are 1:N relationships

        service-hotel is a N:M relationship

 

Step 2: Slice design

        The attributes of an entity are divided into slices.

        Structural links for navigation between slices are defined

        Hypermedia point of view is that of the navigation.

        e.g.,

o       all hotel information could be in the same slice (we would need a window with scrolling to be able to show that)

o       alternative - general information in a slice, with another slice containing the name and multimedia material (e.g., video).

o       alternative - general information is too complex - choose a summary slice, and two other slices containing detailed textual information and multimedia information.

        RMDM introduces the concept of slice head - default access to an entity

        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

        Relationships obtained in step 1 are replaced by RMDM access primitives.

        Slice heads are defined in this step.

        Suggestions about structure:

o       A guided tour is not advisable when there is a large number of instances, but it might be convenient for a small number.

o       An index should help when there is a large number; and a conditional guided tour could be a compromise.

o       Group primitives are used for menus.

o       Although a hierarchy can be created, extensive depth is counterintuitive for most users.

        Final result is in the RMDM diagram below.

o       The following diagram corresponds to an index for hotel-service and category-hotel, a guided tour for hotel-room and an indexed guided tour for town-hotel.

 

o       Most "backwards" links are not explicit in this diagram, because they would be too redundant

 

o       Grouping for menus example - enable access either through towns (via conditional index) or hotel category (via index).

o       This would be represented as:

 

Step 4: Conversion protocols design

o       Steps 4 to 6 can be performed simultaneously from the RMDM diagram.

o       Step 4 defines how to transform each RMDM element into the hardware-software platform chosen.

Step 5: User interface design

o       Graphical designs of screens that represent the RMDM elements are obtained.

o       Important issues: slices, access structures, general navigation tools, anchor appearance, ...

o       Prototyping in low-fidelity (paper) or high-fidelity (photoshop) should be of help.

 

Step 6: Run-time behaviour design

o       Defining the mechanisms (algorithms) to be implemented for traversing links, for keeping history, to allow backtracking, ...

 

Step 7: Construction and testing

o       This phase is the effective construction of databases, algorithm implementation, ...

o       Testing.

 

RMM and RMDM modifications and improvements

Modifications proposed by the authors of RMM and RMDM

o       Several modifications and improvements to the data model RMDM and methodology RMM.

o       Hybrid slices - combine attributes from different entities and access structures

o       minimal slices - the minimal meaningful way of referring to a slice.

o       Limitations of RMM (from Russian Dolls and Hypertext):

o       Inability to specify what information is to be shown as the content of an anchor

o       Inability to allow aggregation of attributes outside a single entity

o       No element can contain both attributes and access structures

 

o       Solution - introduce m-slices - used to group information into meaningful units, replacing slices and group constructs.

o       M-slices are owned (each by one specific entity) although they might contain attributes of other entities and access structures.

o       They define what information is to be part of a construct and where to obtain it.

o       M-slices do not say how this information is to be presented.

o       They can be nested up to arbitrary levels.

o       Also anchoring is supported.

Modifications introduced in the CD-ROM Atles de les Illes Balears

o       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

        The authors of HDM (Hypertext Design Model) were Garzotto, Paolini and Schwabe.

        The model should be useful to design a hypertext or hypermedia application.

        Use the following terminology:

o       authoring-in-the-large - denotes the specifications and design of the global or structural aspects of the application

o       authoring-in-the-small - denotes the aspects of development of the content of the nodes.

 

HDM primitives

Entities and entity types

        Entities are information chunks of reasonable although minimal size, which are meaningful autonomously.

        Entities are grouped into entity types.

e.g. Painter, Artists' Live, Picture type, Subject.

        Each entity is made of a hierarchy of components

        Entities cannot be components of other entities.

The logical structure of the presentation is not altered.

 

Links and types of links

Collections

Schemas

 

Outlines

HDM structure and browsing semantics

 

OOHDM - Object-Oriented Hypermedia Design Method

Evolution of HDM

        Model-based approach for building hypermedia applications

 

        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

1 Requirements Gathering

        The first step is to gather the stakeholder requirements.

        Necessary to first identify the actors (stakeholders) and the tasks they must perform.

        Scenarios are collected (or drafted), for each task and type of actor.

        Scenarios are then collected to form a Use Case, which is represented using User Interaction Diagrams.

o       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

The conceptual schema for the "Portinari Project"

3 Navigational Design

 

Figure: Navigational Class Schema for the Portinari Project application

 

4 Abstract Interface Design

        Must 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 visualization level, and thus we call those objects interface objects to differentiate them from the conceptual or navigational objects.

        OOHDM uses Abstract Data Views - 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.

5 Implementation

Map the navigational and abstract interface models into concrete objects available in the chosen implementation environment (or possible to build).