Metodologas de Concepcin para Aplicaciones Hipermedia:

Anlisis crtico
Philippe Lopistguy, Begoa Losada, Pantxika Dagorret Facultad de Informtica,
Universidad del Pas Vasco (jiplopop,jiblopeb)@si.ehu.es
I.U.T. de Bayonne-Pays Basque Universit des Pays de l'Adour Bayonne France
Pantxika.Dagorret@iutbay.univ-pau.fr

Resumen
El principio de navegacin se ha extendido a nivel del gran pblico gracias a su
uso masivo en dominios tales como Internet y a la comercializacin de software
"amigable" para el desarrollo de aplicaciones con capacidades hipermedia.
Recientemente, se han desarrollado modelos y mtodos para el diseo de aplicaciones
hipermedia con la finalidad de sugerir aproximaciones de diseo de acuerdo con las
normas de calidad comnmente aceptadas en ingeniera de software.
Este artculo realiza un estudio de estas aproximaciones, centrndose
principalmente en la forma en que se efecta la integracin de las abstracciones
hipermedia sobre el dominio de la aplicacin. Primero, presentamos lo que, desde
nuestro punto de vista, constituyen los puntos claves de la integracin hipermedia, a
continuacin, efectuamos un anlisis crtico de un conjunto significativo de mtodos y
finalmente, concluimos con una sntesis sobre sus contribuciones a la concepcin de
aplicaciones hipermedia.
Palabras-clave : Hipermedia, Concepcin, Metfora

1. Introduccin.
El principio de navegacin hipermedia entre elementos de informacin se ha
extendido ampliamente a nivel del gran pblico gracias a los avances tecnolgicos
(puestos de informacin, PC multimedia, Internet,...), y se ha revelado como fcil de
implementar gracias a herramientas software sencillas y potentes (HyperCard,
AuthorWare, parsers HTML,...). Trabajos ms recientes y especficos extienden este
principio de navegacin a dominios diferentes tales como las Bases de Datos [Garz93b],
o la Integracin de Aplicaciones [Gron94], [Filg95].
Paralelamente a estos trabajos, se han realizado esfuerzos en la especificacin de
modelos hipermedia para la definicin de estructuras y funcionalidades comunes a la
mayora de los sistemas hipermedia. Existen diferentes modelos de representacin
[Garg88], [Afra90], [Lang90], [Hala94], siendo su punto comn estar definidos a partir
de funcionalidades abstractas basadas en una concepcin similar de nodos y enlaces.
Ms recientemente, el inters se ha volcado en los modelos y mtodos de
concepcin de aplicaciones bien estructurados. El objetivo de estos trabajos es proponer
aproximaciones incrementales de concepcin de aplicaciones hipermedia segn las
reglas del arte: concepcin bien documentada y reusable, aplicacin sencilla y fcil de

mantener... Se puede considerar que la situacin actual de la concepcin de aplicaciones

hipermedia es similar a la denominada crisis del software en la que los programas y
materiales permitan la realizacin rpida de aplicaciones efectivas mientras que su
concepcin pecaba de falta de metodologa. El resultado eran aplicaciones poco
estructuradas y difciles de mantener. Las tcnicas de la programacin estructurada y
modular -y sus conceptos subyacentes- han proporcionado una solucin a esta situacin.
Este artculo se inscribe dentro de esta lnea de preocupacin y se interesa
particularmente en el proceso que se sigue en la integracin de abstracciones hipermedia
en la concepcin de una aplicacin.
La primera seccin del artculo expone nuestro punto de vista sobre aspectos
fundamentales de la concepcin de aplicaciones hipermedia, la seccin siguiente
presenta una descripcin crtica de modelos y mtodos significativos de concepcin
hipermedia, y la ltima parte efecta una sntesis sobre las aportaciones de estos
mtodos a la concepcin de aplicaciones hipermedia.

2. Puntos clave del proceso de hiperizacin.

Hemos constatado [Lopi96] que en la concepcin de una aplicacin, la
adquisicin de funcionalidad hipermedia consiste en dotar a determinados elementos del
dominio de la aplicacin de "metfora hipermedia1 ". Consideramos este aspecto como
el punto clave de la concepcin de aplicaciones hipermedia y en esta seccin abordamos
las etapas que caracterizan su realizacin.

2.1 Dotar a los elementos de la aplicacin de metfora

hipermedia.
Consideramos que toda concepcin de aplicacin hipermedia supone, entre
otras, las tres tareas siguientes cuya combinacin consigue la integracin del paradigma
hipermedia.
1 - Identificar/definir elementos del dominio de la aplicacin.
2 - Identificar/definir elementos hipermedia.
3 - Identificar/definir la relacin que les une.
Entendemos por elemento del dominio de la aplicacin todo componente
(objeto, entidad, relacin, atributo, evento, operacin, abstraccin, ...) especificado en el
curso del ciclo de vida de la aplicacin, y por elemento hipermedia todo componente
(nodo, enlace, ancla, mtodo, evento, ...) propio de los modelos hipermedia.
Aunque estas tres tareas estn numeradas, su realizacin no implica el respeto de
este orden y la realizacin de una no implica el comienzo de la siguiente. Sin embargo,
desde un punto de vista metodolgico, el estudio preliminar de la organizacin del
dominio es necesario ante cualquiera de estas tareas.

2.2 Los elementos del dominio de la aplicacin.

1

Los elementos del dominio de la aplicacin son dotados de funcionalidades hipermedia que les
proporciona un comportamiento hipermedia.

En cuanto a la organizacin del dominio, se han propuesto varios modelos, en

funcin del mtodo empleado; modelo objeto para OMT [Rumb91], modelo EntidadRelacin y diagramas de flujo de datos o modelos conceptuales de tratamiento para
mtodos estructurados como Merise o Mtrica. Globalmente, los elementos
especificados en estos modelos son clases, entidades, relaciones, procesos, mensajes o
eventos y segn nuestra aproximacin, estos elementos son, sin restriccin, candidatos
potenciales a ser dotados de metfora hipermedia, lo que extiende el propsito general
de las aproximaciones ms conocidas como veremos a continuacin.
Los elementos de base del dominio son el origen de la integracin del paradigma
hipermedia, teniendo en cuenta que no todos tienen sistemticamente "necesidad" de
una imagen hipermedia. Cuando la identificacin del elemento no es adecuada, puede
ser necesario definir nuevos elementos de aplicacin por mecanismos de especializacin
o de combinacin-agregacin. Esta actividad constituye la primera de las tareas que
hemos identificado como punto clave del proceso de hiperizacin.
El modelo resultante de esta actividad se denomina modelo enriquecido del dominio.

2.3 Los elementos hipermedia.

Generalmente, los elementos hipermedia ms comunes son aquellos reagrupados
bajo el trmino de hiperobjeto, que se atribuye a los nodos, enlaces y anclas as como a
sus mltiples variantes tales como enlaces mono-bi-multi-direccionales o nodos simples
o compuestos. Otras estructuras ms complejas pero igualmente clsicas son menos
utilizadas, como ndices, visitas guiadas (guided tour), histricos, caminos (trail, path),
mapas (map), navegadores (browser), marcadores (bookmark, landmark) o incluso
anotaciones. Sin embargo, aunque la semntica de estos hiperobjetos est bien
establecida, el detalle de sus caractersticas difiere a menudo en cada aplicacin.
Adems de los hiperobjetos, otros elementos hipermedia como mtodos
(CrearNodo asociado al elemento de aplicacin NuevaEntidad), atributos
(ContenidoNodo asociado al elemento de aplicacin NombreApellido) o eventos
(CerrarNodo asociado al elemento de aplicacin TimeOut) pueden ser, a nuestro modo
de ver, interesantes para el diseador.
Por lo tanto, es necesario que ste pueda definir el elemento hipermedia que
corresponda mejor a la metfora hipermedia que desea dar al elemento de aplicacin.
Puede hacerlo bien precisando las caractersticas de un hiperobjeto (accesibilidad,
comportamiento, ...), bien definiendo claramente un elemento hipermedia (evento,
atributo, composicin de elementos hipermedia, ...). El modelo hipermedia enriquecido
as obtenido podr resultar de un modelo inicial adaptable y extensible. El modelo
resultante de esta actividad se denomina modelo hipermedia enriquecido. Remarquemos
que el enriquecimiento del modelo hipermedia podr resultar del mecanismo de
correspondencia que estamos describiendo.
En efecto, si el dominio de la aplicacin es el dominio hipermedia mismo,
gracias a este mecanismo de correspondencia ser posible, por ejemplo, asociar una lista
de nodos a un nodo, obteniendo as nodos cuyo contenido son asimismo nodos. Esta
tcnica autoriza la definicin de elementos hipermedia a partir de otros elementos
hipermedia y en el caso de nodos compuestos o de ndices, esto evita la creacin de

enlaces ambiguos entre el nodo compuesto y los nodos componentes, conforme a las
recomendaciones de [Hala91].

2.4 La metfora hipermedia.

El principio de correspondencia entre elementos de aplicacin y elementos
hipermedia es subyacente a los mtodos presentados en la seccin tercera, incluso si no
se expresan en trminos tan genricos como en nuestro anlisis. Nos hemos esforzado a
abstraer mecanismos tipo y, adems del principio de metfora, hemos identificado
aspectos de Correspondencia y de Proceso de concepcin que detallamos en esta
seccin.

2.4.1 Definicin de correspondencias.

Generalmente, los tipos de correspondencia propuestos al diseador son
especficos de cada mtodo, es decir que es dificil encontrar correspondencias similares
en dos mtodos diferentes.
La correspondencia se define para tipos particulares de elementos del modelo del
dominio, como por ejemplo Relacin <-> Enlace o bien para elementos del dominio
enriquecido construidos segn mecanismos de fragmentacin o de composicin propios
del mtodo, como por ejemplo Trozo <-> Nodo [Isak95]. As, en el curso de una de las
etapas del mtodo, el diseador identifica/define elementos del dominio, y les atribuye
una de las metforas tipo entre las correspondencias propuestas.
Cuando los mtodos tienen una herramienta de concepcin asociada, los tipos de
correspondencia especficas y preestablecidas toman todo su inters puesto que el
trabajo de implementacin est parcial o totalmente efectuado por la herramienta. Sin
embargo, la potencialidad hipermedia est limitada y no se explota en su totalidad.
Aunque el principio de los tipos de correspondencia preestablecidos sea
interesante para el diseador, la posibilidad de seleccionar un elemento de aplicacin en
lugar de otro es un punto crtico. Diferentes trabajos tienden a considerar la concepcin
hipermedia como la "ciencia de las relaciones", en los que el punto clave reside en las
relaciones que unen los elementos del dominio. As, segn esta aproximacin, la
metfora de enlace est asociada al concepto de relacin [Bieb96].
En cuanto a la tarea de seleccin de elementos del dominio, puede ser interesante
entonces poder identificar diferentes tipos de relaciones. Por ejemplo:
relaciones de proceso, que dan acceso directo a operaciones y procesos.
relaciones estructurales, que dan acceso a objetos de la estructura interna de una
aplicacin.
relaciones de metainformacin, que dan acceso a los parmetros y a la informacin
descriptiva de los objetos de una aplicacin.
relaciones de ocurrencia, que dan acceso a todas las apariciones de un elemento
dado.
Para cada una de estas relaciones hay que proponer una correspondencia -o
metfora- de enlace especfica.

En el caso de aplicaciones con capacidad de authoring hipermedia, el usuario es a su

vez diseador. Incluso si la aplicacin no lo especifica explcitamente, permite al
usuario, bajo forma de men u otra, seleccionar un elemento del dominio y relacionarlo
con un elemento hipermedia (ancla, enlace, nodo, anotacin2 ). Podemos citar como
ejemplo MetaEdit+ que es una herramienta CASE [Oina96] dotada de capacidades
hipermedia para documentar, relacionar y confrontar diferentes decisiones de
concepcin.
De esta forma, el mecanismo de metfora permanece subyacente, las tareas para
llevarlo a cabo son implementadas bajo forma de servicios y las correspondencias se
realizan en el momento en que surge la necesidad. Es decir que la seleccin del
elemento del dominio no es inducido directamente por el modelo conceptual del
dominio.

2.4.2 Proceso de establecimiento de la correspondencia.

Hemos podido observar que, segn los modelos y los mtodos, el impacto de la
correspondencia puede afectar a la globalidad de los elementos del dominio o slamente
a una parte de ellos.
Cuando la correspondencia se aplica al conjunto de los elementos, el mtodo
puede ser calificado de impositivo y enfocado a la obtencin de aplicaciones tipo. En
este caso, el proceso de concepcin propone etapas con la finalidad de concebir
aplicaciones hipermedia estereotipadas. La correspondencia es sistemtica, el modelo
del dominio est enriquecido con elementos predefinidos y cuya correspondencia est
preestablecida. La ventaja de este proceso es ofrecer una lnea de trabajo precisa que
facilita la concepcin e impide iniciativas "peligrosas".
Por otra parte, cuando la correspondencia se aplica a una parte de los elementos,
el mtodo puede ser calificado de abierto y enfocado a la obtencin de aplicaciones
dotadas de funciones variadas. Un ejemplo de aplicaciones de este tipo son los sistemas
tutores inteligentes que dan acceso libre a la informacin. En efecto, sus capacidades
hipermedia y de tutora deben cohabitar desde el nivel conceptual.
La finalidad que persigue es permitir la integracin de funcionalidades
hipermedia durante el proceso de concepcin. En este caso, la correspondencia entre
elementos del dominio3 y elementos hipermedia no es sistemtica, admite variaciones.
La libertad de eleccin es preferible, aunque tambin deben poder ser propuestos modos
de correspondencia tipo a fin de facilitar la tarea y de evitar errores conceptuales.
As, hacemos una distincin entre las aplicaciones concebidas totalmente segn
una aproximacin hipermedia, y las aplicaciones que disponen de funcionalidades
hipermedia en las que el paradigma hipermedia no es tenido en cuenta ms que en una
parte de su proceso de concepcin.

2
3

Hacemos notar que, an no siendo un elemento hipermedia tpico, la anotacin es un elemento dificil
de integrar en una etapa de anlisis conceptual hipermedia.
Por dominio entendemos el de la aplicacin en su globalidad y no el "dominio" a ensear, en el sentido
de los tutores inteligentes.

3. Diferentes aproximaciones de concepcin de aplicaciones

hipermedia.
El proceso de concepcin de una aplicacin puede ser implcita o bien explcita
y en este ltimo caso, los diseadores siguen o bien un proceso propio (ad-hoc), o bien
una aproximacin genrica. En nuestro estudio, hemos retenido los procesos de este
ltimo tipo. En esta seccin, repasamos brevemente, para los lectores no familiarizados
con el dominio, la aproximacin y la terminologa de los modelos y mtodos que nos
han parecido significativos. Posteriormente, efectuamos un anlisis crtico de cada uno
basado en los puntos comentados en la seccin precedente; esto es, en trminos de
dominio enriquecido, hipermedia enriquecido, correspondencia preestablecida y proceso
abierto o impositivo. El lector experto se centrar en las partes de anlisis.

3.1 HDM : A Model-based

Application Design.

Approach

to

Hypertext

HDM [Garz93a] constituye un primer paso en la definicin de un mtodo

descendente de concepcin de aplicaciones hipertexto. Ha sido la fuente de inspiracin
de los mtodos RMM [Bala94], [Isak95] y OOHDM [Schw95]. El modelo HDM no se
interesa en la concepcin del contenido de los nodos (authoring in the small), se centra
nicamente en la concepcin topolgica de las aplicaciones (authoring in the large).

3.1.1 Los elementos del modelo.

HDM propone un conjunto de elementos que permiten al diseador especificar
una aplicacin. Estos elementos son las entidades, los componentes, las perspectivas, las
unidades y los enlaces. El trmino entidad se ha extrado del modelo Entidad-Relacin,
pero se ha extendido para poder representar una estructura compleja que contenga
enlaces y una semntica de navegacin internas.
Una entidad es una jerarqua de componentes que "heredan" las propiedades de
la entidad y que no pueden existir ms que como partes de la entidad. Las perspectivas
permiten representar la multiplicidad de las presentaciones de un mismo contenido de
informacin (presentacin en diferentes lenguas de un mismo texto,....). Las unidades
son los depsitos de la informacin contenida en la aplicacin. Una unidad representa
un fragmento del contenido de una entidad presentada bajo una perspectiva particular.
Un componente es una abstraccin para disear un conjunto de unidades que
representan todas las perspectivas de un mismo contenido de informacin. Si una
entidad tiene dos perspectivas, todos sus componentes tendrn dos perspectivas.
En el modelo, los enlaces hipermedia tienen un papel doble; el de representar la
semntica del dominio y el de permitir la navegacin. Para esto, HDM define tres tipos
de enlaces: enlaces estructurales entre componentes de una misma entidad, enlaces de
perspectiva entre unidades de un mismo componente, y enlaces de aplicacin entre
entidades o componentes. Las ventajas aportadas por esta clasificacin son una
utilizacin ms consistente de los enlaces, esquemas de navegacin definidos de
antemano, una semntica de navegacin por defecto y la puesta en marcha, desde la fase
de desarrollo, de mecanismos como la derivacin de enlaces. Durante la concepcin de

la aplicacin, los enlaces de perspectiva y estructurales se derivan automticamente del

esquema (de la estructura de las entidades).
La aportacin principal de HDM2 [Garz93c] con respecto a HDM consiste en la
aadidura al modelo de estructuras de accesos como los ndices y las visitas guiadas.

3.1.2 Anlisis crtico.

Por su condicin de modelo, HDM no se centra en la especificacin del dominio
de la aplicacin. Su aportacin se situa ms all, proponiendo un modelo que sirva de
base a la aplicacin de correspondencias tipo. En efecto, los elementos (entidad,
componente, perspectiva, unidad, enlace) constituyen un lenguaje de especificacin que
permite al diseador definir un modelo enriquecido del dominio. Mediante las
correspondencias preestablecidas por HDM, este modelo enriquecido define la
estructura navegacional de la aplicacin.
Entre los elementos del dominio, distinguimos las entidades y componentes (que
permiten definir la estructura de la informacin a hiperizar) de las perspectivas y
unidades (que permiten definir las variaciones de semntica de la informacin). El
sistema de correspondencias preestablecidas asocia estos elementos al elemento
hipermedia Nodo. Las relaciones recogidas de las primitivas propias de HDM (entidad,
componente, unidad) son estructurales, y se les asocia la metfora preestablecida de
Enlace. Sin embargo, el concepto de enlace se deja disponible para ser asociado
igualmente a relaciones de semntica o de aplicacin.
Como conclusin, podemos decir que HDM propone un modelo enriquecido
para especificar el dominio de la aplicacin. A partir de este dominio enriquecido, y
gracias a un mecanismo de correspondencia preestablecido, se describe la estructura
navegacional de la aplicacin. Por otra parte, si bien es cierto que HDM2 introduce
estructuras de acceso, el modelo hipermedia subyacente es mnimo y no enriquecido.
Los calificativos de abierto o de impositivo - que se aplican al proceso de concepcinno son pertinentes para HDM ya que ste es slo un modelo. Las dos subsecciones
siguientes se consagran a dos mtodos inspirados de este modelo; uno impositivo, el
otro abierto.

3.2 RMM : Relationship Management Methodology.

El mtodo est definido como un proceso de anlisis, diseo y desarrollo de
aplicaciones hipermedia cuya estructura es estable y cuyo contenido sufre
modificaciones frecuentes. Los elementos principales de este mtodo son el modelo E-R
(Entity-Relationship) y el modelo RMDM (Relationship Management Data Model)
basado en el modelo HDM [Garz93a,c]. Las aportaciones con respecto a HDM residen
en la descripcin detallada de las etapas diferentes del proceso de concepcin por una
parte, y por otra parte, en la manera en que los diferentes elementos del modelo deben
ser utilizados.

3.2.1 El modelo RMDM.

El modelo propone un lenguaje que permite describir los objetos del dominio,
sus interrelaciones y los mecanismos de navegacin hipermedia de la aplicacin.

Los objetos del dominio se definen con la ayuda de entidades, atributos y

relaciones asociativas. El modelo introduce el concepto de trozo (slice) con el fin de
modelizar los aspectos unidos a la presentacin de las entidades. Un trozo corresponde a
un subconjunto de atributos de una misma entidad destinados a ser presentados de
forma agrupada. La navegacin se modeliza con la ayuda de primitivas de acceso;
enlaces estructurales (unidireccional y bidireccional) que permiten especificar la
navegacin entre trozos, y visita guiada condicional, ndice condicional y agrupacin,
que permiten especificar la navegacin entre entidades.
El esquema completo del dominio y de la navegacin de la aplicacin se
denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del
mtodo.

3.2.2 Las etapas del mtodo.

La primera etapa consiste en representar los objetos del dominio con la ayuda
del modelo Entidad-Relacin ampliado con relaciones asociativas (aquellas que
permiten representar caminos navegacionales entre entidades puestos en evidencia en la
fase de anlisis).
La segunda etapa consiste en determinar la presentacin del contenido de las
entidades de la aplicacin as como su modo de acceso. El esquema obtenido como
resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema EntidadRelacin en el que cada entidad ha sido reemplazada por su esquema de entidad. Un
esquema de entidad est constituido por nodos (los trozos) unidos por relaciones
estructurales.
La tercera etapa consiste en definir los caminos de navegacin inducidos por las
relaciones asociativas del esquema E-R+. A continuacin, es posible definir estructuras
de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicacin de accesos
jerrquicos a niveles diferentes de los trozos de informacin. El esquema RMDM
resultante se obtiene aadiendo al esquema E-R+ las agrupaciones y caminos
navegacionales definidos en esta etapa.
Las cuatro etapas restantes consisten en -1- definicin del protocolo de
conversin de elementos del diagrama RMDM en objetos de la plataforma de
desarrollo, -2- concepcin del interfaz usuario, -3- concepcin del comportamiento en
ejecucin y -4- construccin del sistema y test.

3.2.3 Anlisis crtico.

De acuerdo con HDM, RMM define correspondencias tipo. Propone el modelo
Entidad-Relacin para especificar el dominio y lo enriquece introduciendo los
conceptos de trozo y de relacin estructural para los cuales una metfora hipermedia es
preestablecida. Los trozos y las entidades se asocian con nodos y las relaciones
asociativas (entre entidades) y las relaciones estructurales (entre trozos) se asocian con
enlaces.

El modelo del dominio se enriquece, por lo tanto, con dos tipos de elementos
preestablecidos que tienen una correspondencia clara en trminos hipermedia.
En RMM, el modelo hipermedia retoma los elementos enlace, ndice y visitas
guiadas de HDM enriquecindolos con capacidades condicionales. Sin embargo, el
mtodo no permite al diseador difinir elementos hipermedia propios que tengan
capacidades especficas ya que impone la utilizacin de metforas preestablecidas.
Calificamos, por tanto, a RMM de mtodo impositivo pues da precisiones sobre
todas las etapas a realizar, desde la concepcin del esquema del dominio hasta el
desarrollo de la aplicacin hipermedia.

3.3 OOHDM
Methodology.

Object

Oriented

Hypermedia

Design

Al igual que RMM, este mtodo se inspira en el modelo HDM. Lo que lo

distingue claramente de RMM es el proceso de concepcin orientado a objetos.
OOHDM [Schw96] tiene cuatro etapas, cada una centrada en un aspecto de la
concepcin.

3.3.1 Los elementos del dominio y etapas del mtodo.

Cada etapa de la concepcin define un esquema objeto especfico en el que se
introducen nuevos elementos (clases). En la primera etapa, el anlisis del dominio
consiste en establecer un esquema conceptual en trminos de clases, relaciones y
subsistemas. Para ello, el mtodo propone el modelo objeto de OMT. En la segunda
etapa, el diseador define clases navegacionales tales como nodos, enlaces, ndices y
visitas guiadas inducidas del esquema conceptual. Los enlaces derivan de relaciones y
los nodos representan ventanas lgicas (views) sobre las clases conceptuales. A
continuacin, el diseador describe la estructura navegacional en trminos de contextos
navegacionales. Estos contextos definen agrupaciones -en el sentido de HDM- de
objetos navegacionales (nodos, enlace,....). Durante esta etapa, es posible adaptar los
objetos navegacionales para cada contexto, de forma similar a las perspectivas de HDM.
La tercera etapa, dedicada a la especificacin del interfaz abstracto, describe los objetos
de interfaz y los asocia con objetos de navegacin. Por fin, la ltima etapa, consagrada a
la implementacin, hace corresponder los objetos de interfaz con objetos de
implementacin.

3.3.2 Anlisis crtico.

OOHDM no propone un modelo enriquecido para el dominio de la aplicacin, lo
que deja al diseador libre para elegir el modelo de especificacin del dominio. Por
contra, el modelo hipermedia est definido en dos niveles de abstraccin; las clases
navegacionales y los contextos navegacionales.
En el momento de la especificacin de las clases navegacionales es cuando el
diseador define las correspondencia. Aunque OOHDM sugiere algunas, no impone
metforas preestablecidas tan sistemticamente como RMM. Los nodos inducidos de las
clases del modelo del dominio y los enlaces inducidos de las relaciones del modelo del
dominio pueden ser precisados. El segundo nivel est consagrado a la especificacin de

la navegacin, expresada exclusivamente sobre los objetos navegacionales (no sobre los
elementos del modelo del dominio), lo que constituye un mecanismo que permite
enriquecer el modelo hipermedia.
Aunque los ejemplos que ilustran el mtodo sean siempre del mismo tipo,
calificamos OOHDM de mtodo abierto porque, por una parte, el modelo del dominio
no viene impuesto y por otra parte, el soporte en objetos del mtodo permite la
especializacin de las clases navegacionales y de los contextos navegacionales. En
efecto, el objetivo de OOHDM es cubrir la concepcin de todo tipo de aplicaciones
hipermedia.

3.4 EORM : Enhanced Object-Relationship Model.

El mtodo se define como un proceso informal de concepcin de sistemas de
informacin dotados de funcionalidades hipermedia. El proceso propuesto consiste en
llegar a esquemas EORM que sirvan de especificacin para la concepcin de
aplicaciones.

3.4.1 El enlace, elemento clave del modelo.

Los esquemas EORM se constituyen a partir de un modelo conceptual
completado con clases de enlaces que especifican sus aspectos estticos y dinmicos. Se
proponen clases tipo aunque el diseador define preferiblemente clases enlace ad-hoc,
segn sus necesidades. Este aspecto constituye la filosofa y caracterstica principal de
EORM.

3.4.2 Las etapas del mtodo.

La primera etapa consiste en un anlisis del sistema con la ayuda de un mtodo
orientado a objetos (OMT), que define la estructura de las informaciones (modelo
objeto), su comportamiento (modelo dinmico) y sus interrelaciones.
La segunda etapa consiste en crear el esquema EORM de la aplicacin a partir
de los elementos proporcionados por la etapa anterior. Este esquema especifica las
relaciones de interaccin de la aplicacin, en donde las relaciones entre objetos son
vistas como caminos de interaccin semnticamente ricos (es decir, que tienen una
estructura y un comportamiento), ms que como simples relaciones estructurales.
De esta forma, las relaciones definidas en el modelo objeto de OMT pueden ser
representadas por clases de enlaces hipermedia. Estas clases aaden a las relaciones del
modelo objeto la semntica navegacional de la aplicacin. Estn organizadas en una
jerarqua de herencia propuesta por el mtodo bajo la forma de una biblioteca de clases.
La semntica relativa a las propiedades hipermedia de las relaciones encuentra, por
tanto, una representacin en EORM bajo la forma de clases.
Finalmente, la tercera etapa consiste en transformar los esquemas EORM en
cdigo, en salvaguardarlos en una Base de Datos Orientada a Objetos, y en elaborar
formularios de consulta de las clases con la ayuda de un editor grfico de interfaces.

3.4.3 Anlisis crtico.

El modelo EORM no enriquece el dominio con nuevos conceptos. Los

elementos candidatos a la metfora hipermedia se reducen por tanto, a las clases y
relaciones del modelo OMT.
Por otra parte, toda la semntica de las relaciones de la aplicacin se expresa por
medio de enlaces hipermedia reagrupados en una jerarqua de clases. Es interesante
resaltar que el comportamiento definido sobre los enlaces permite tener en cuenta una
parte de la semntica de la navegacin de la aplicacin. Asimismo, permite alterar la
propia estructura navegacional de la aplicacin mediante operaciones de creacin,
destruccin o de modificacin de elementos hipermedia. Est claro que la aproximacin
adoptada por EORM ha consistido en concentrarse en el enriquecimiento de los
elementos hipermedia.
En cuanto al establecimiento de correspondencias entre elementos del dominio y
elementos hipermedia, el mtodo EORM da una cierta libertad en la eleccin de las
metforas para los enlaces. En efecto, precisa que no toda relacin del dominio est
determinada en convertirse en enlace navegacional y que los enlaces se deben adaptar a
las necesidades del anlisis.
Por contra, el proceso de realizacin de la correspondencia es impositiva, en el
sentido de que una entidad siempre se transforma en nodo y una relacin en enlace. Esto
est justificado por el mtodo puesto que considera que las relaciones son las claves de
la hiperizacin.

3.5 El modelo Trellis.

Trellis [Furu90] es un modelo generalizado de hipermedia. No propone un
mtodo de concepcin. Indica que un sistema hipermedia est compuesto por tres
elementos distintos; el contenido de la informacin, la estructura navegacional y el
control navegacional (esto es, el control de la dinmica de la aplicacin).

3.5.1 Los elementos del modelo.

Este modelo propone las redes de Petri [Reis85], esquematizadas por un grafo
orientado construido a partir de places, de transitions y de tokens, para especificar las
caractersticas de interaccin de una aplicacin. Los elementos places representan los
contenidos de informacin, los tokens indican cules son las informaciones en curso de
presentacin, los elementos transitions representan el encadenamiento de las
presentaciones y el grafo en su conjunto describe la estructura navegacional de la
aplicacin.
Cuando los elementos places situados a continuacin de una transicin se
convierten en token, se dice que la transition es activable. El usuario puede
seleccionarla para acceder (navegar) a los contenidos de informacin colocados ms
abajo. Las transitions estn dotadas de atributos (tiempo de espera, tiempo de
liberacin) que permiten al diseador asociarles caractersticas temporales. El tiempo de
espera es el lapso de tiempo que indica al cabo de cunto tiempo una transition
activable puede ser seleccionada por el usuario. El tiempo de liberacin es el lapso de

tiempo que indica al cabo de cunto tiempo una transition seleccionable ser franqueada
automticamente por el sistema en caso de no accin por parte del usuario. El modelo
permite por lo tanto, una especificacin cmoda de la sincronizacin, concurrencia y
secuenciacin de presentacin de contenidos de informacin.
El modelo se define como genrico puesto que extiende la nocin de
presentacin de la informacin a la de ejecucin de programa. As, el control de la
navegacin especifica la sincronizacin, la concurrencia y la secuenciacin de
programas en sentido amplio.

3.5.2 Anlisis crtico.

Trellis no propone un modelo enriquecido para especificar el dominio. Como se
centra en las especificaciones navegacionales, propone un modelo grfico que ilustra su
aproximacin.
Define correspondencias preestablecidas. El elemento place (nodo) modeliza a
la vez el contenido y el tipo de la presentacin. Las transitions (enlaces) corresponden a
enlaces multidireccionales condicionales cuya activacin no es posible ms que si todos
los nodos origen se presentan y cuya seleccin tiene por efecto presentar todos los
nodos destino.
El modelo hipermedia est fijado pero constituye segn el autor un mecanismo
elemental que permite especificar elementos complejos.
Aunque el modelo no propone un proceso de concepcin, est claro que se
distingue de los modelos precedentes para los que la hiperizacin se deriva
esencialmente del modelo del dominio. Con Trellis, el diseador deber prestar una
atencin particular al control de la navegacin y al la sincronizacin ya que esto
constituye, segn el modelo, los elementos clave de la hiperizacin.

4. Conclusin y futuros trabajos.

Desde hace algn tiempo, van apareciendo mtodos de concepcin de
aplicaciones hipermedia. Tienen por objetivo poner a la disposicin del diseador un
proceso -a veces incluso una herramienta/taller- fundado en un modelo, que le permite
construir aplicaciones hipermedia que tienen en cuenta criterios de calidad adoptados
commente en programacin.
Hemos analizado un conjunto de mtodos y modelos subyacentes (HDM, RMM,
OOHDM, EORM, modelo de Trellis) que, por sus puntos comunes y divergentes,
representan, segn nuestro modo de ver, una muestra significativa del estado del arte en
este dominio. El resultado que se repite en este estudio es que estos mtodos no definen
de forma satisfactoria las etapas que constituyen un proceso completo y genrico de
cualquier tipo de aplicacin hipermedia.
En efecto, es dificil hacer una distincin entre los conceptos relativos al modelo
del dominio de la aplicacin y aquellos del modelo hipermedia. As, el dominio de la
aplicacin se especifica a menudo con la ayuda de trminos de semntica hbrida, de tal
forma que las responsabilidades hipermedia son difusas y dificilmente identificables.
Como consecuencia de esta ambigedad, constatamos que los mecanismos de

correspondencia entre los conceptos del dominio de la aplicacin y los del dominio
hipermedia son propios de cada mtodo.
Para realizar este estudio, hemos analizado los mtodos y modelos segn tres
puntos que consideramos claves en la concepcin de aplicaciones hipermedia, esto es: 1- definicin de los elementos del dominio de la aplicacin, -2- definicin de los
elementos hipermedia y, -3- definicin de la metfora hipermedia.
Segn estos puntos clave, el mtodo RMM propone enriquecer el modelo del
dominio con conceptos como trozo, componente, unidad, para atribuirles a continuacin
metforas hipermedia. Por contra, los mtodos OOHDM y EORM suponen un dominio
modelizado, con OMT, y proponen mecanismos para atribuir metforas hipermedia a
los elementos del modelo conceptual. El modelo Trellis y HDM no se interesan por este
aspecto ya que son modelos hipermedia.
En cuanto a los elementos hipermedia, HDM y RMM proponen elementos
preestablecidos y fijos. El modelo EORM propone exclusivamente un mecanismo de
especializacin de enlaces, mientras que Trellis propone elementos de base aptos para la
construccin de elementos ms complejos.
Igualmente, hemos constatado que el criterio de hiperizacin vara segn los
mtodos; para el modelo Trellis se trata de la estructura navegacional y de los
mecanismos de sincronizacin, para EORM se trata de las relaciones, y finalmente, para
RMM y OOHDM se trata de estructuras de datos - mientras que HDM (su modelo
subyacente) no precisa nada en este sentido-.
Se deduce de este estudio que cada uno de los mtodos se ha interesado ms
particularmente en uno u otro de los puntos clave, lo que nos incita a considerar que la
importancia de estos puntos es significativa en el proceso de concepcin de aplicaciones
hipermedia y que pueden servir, por lo tanto, como referencia para futuros trabajos.
Actualmente, nuestra actividad se centra en la especificacin de un taller
hipermedia que soporte la integracin libre de funcionalidades hipermedia. El objetivo
es proponer al desarrollador herramientas de prototipado poderosas que le permitan
explorar posibilidades nuevas para mezclar el dominio hipermedia con otros dominios.
Este taller se construir sobre HyperFrame [Rodr97], un hypermedia software
framework fundamentado en los tres puntos clave del proceso de integracin.
HyperFrame define los componentes hipermedia ms elementales, sus interdependencias, mecanismos de construccin hipermedia as como un mecanismo de
correspondencia (mapping), que permite asociar todo elementos hipermedia con un
elemento del dominio externo. Este tipo de herramienta constituye, a nuestro entender,
un soporte informtico bien adaptado a la puesta en obra de la hiperizacin segn los
tres puntos claves que hemos definido.

5.Bibliografa.
[Afra90]

A hypertext model supporting query mechanisms, F. Afrati, C.D. Koutras,

Proceedings of the European Conference on Hypertext, Editions
Cambridge University Press, The Cambridge series on Electronic
Publishing, 1990.

[Bala94]

Designing Hypermedia Applications, P. Balasubramanian, Toms

Isakowitz, Edward A. Stohr, Proceedings International Conference on
System Sciences (HICSS), IEEE Computer Society Press, 1994.

[Bieb96]

What Every Information Systems Developer Should Know About

Hypertext, M. Bieber, Proceedings Hypertext'96 - Workshop on
Incorporating
Hypertext
Functionality
into
Software
Systems,
Washington, USA, 1996.

[Filg95]

Towards an Open Hypermedia Systems, J.M. Filgueira, I. Usandizaga, T.

Prez, Proceedings INFORSID'95, Grenoble, France, 1995.

[Furu90]

Generalizing Hypertext : Domains of the Trellis Model, R. Furuta, P.

David Stotts, Technique et Science Informatique (TSI), Edition. AfcetBordas, vol. 9, no. 6.

[Garg88]

Abstraction mechanisms in hypertext, P.K. Garg, Communications of the

ACM, vol. 31, no. 7, 1988.

[Garz93a]

HDM. A model-based approach to hypertext application design, F.

Garzotto, P. Paolini, D. Schwabe, ACM Transactions on Information
Systems, vol. 11, no. 1, 1993.

[Garz93b]

Navigation patterns in hypermedia databases, Proceedings Hawaii

International Conference on System Sciences (HICSS), IEEE Computer
Society Press, 1993.

[Garz93c]

HDM2 : Extending the E-R Approach to Hypermedia Application Design,

F. Garzotto, L. Mainetti, P. Paolini, Proceedings International Conference
on the Entity-RelationShip Approach, Arlington, USA, 1993.

[Gron94]

Design Issues for a Dexter-based hypermedia system, K.Gronbaek, R.H.

Trigg; Communications of the ACM, vol. 37, no. 2, pp. 40-49, 1994.

[Hala91]

Seven Issues : Revisited, F. Halasz, Report SSL-91-149, Systems Science

Laboratory, Palo Alto Research Center, Palo Alto, CA, 1991.

[Hala94]

The Dexter hypertext reference model, F. Halasz, M. Schwartz, in

Communications of the ACM, vol. 37, no. 2, 1994.

[Isak95]

RMM : a Methodology for Strutured Hypermedia Design, Toms

Isakowitz, Edward A. Stohr, P. Balasubramanian, in Communications of
the ACM, vol. 38, no. 8.

[Lang90]

A formal model of Hypertext, D.B. Lange, Proceedings of the Hypertext

Standardization Workshop, National Institute of Standards and
Technology Editions, 1990.

[Lopi96]

Experiences and Reflection on the Use of a Hypermedia Framework for

Hypermedia Functionality Integration, P. Lopistguy, I. Usandizaga, J.M.
Filgueira, Proceedings Hypertext'96 - Workshop on Incorporating
Hypertext Functionality into Software Systems, Washington, USA, 1996.

[Oina96]

Hypermedia functionality in modeling tools, H. Oinas-Kukkonen,

Proceedings Hypertext'96 - Workshop on Incorporating Hypertext
Functionality into Software Systems, Washington, USA, 1996.

[Reis85]

Petri Nets : An Introduction , W. Reisig. Springer-Verlag, 1985.

[Rodr97]

Proceso y arquitectura para la construccin de aplicaciones hipermedia,

D. Rodrguez, J.M. Filgueira, P. Lopistguy, Proceedings Jornadas sobre
Ingeniera del Software, San Sebastin, Espaa, 1997.

[Rumb91]

Object Modeling Modeling and Design, J. Rumbauch, M. Blaha, W.

Premerlani, F. Eddy, W. Lorensen. Englewood Cliffs, NJ: Prentice Hall,
1991.

[Schw95]

The Object Oriented Hypermedia Design Model, D. Schwabe, G. Rossi,

Communications of the ACM, vol. 38, no.8, 1995.

[Schw96]

Systematic Hypermedia Application Design with OOHDM, D.Schwabe,

G.Rossi, S.Barbosa, Proceedings ACM-Hypertext96, 1996.