Metodologia de Hipermedia RMM

Una metodologa relacional hipermedia
Estudio en casos prcticos
Antonio Navarrete Terrasa

Proyecto final de carrera dirigido por Josep Blat Gimeno
Muchsimas gracias a:
Mi familia, por su apoyo constante
Virginia, por estar siempre a mi lado
Mi director de proyecto, por haber confiado en m
Mis compaeros del Atlas y Mintour
Esto no habra sido posible sin vosotros.
Este proyecto final de la carrera Ingeniera Superior en Informtica se ha desarrollado en

Palma de Mallorca, durante los aos 1996, 1997 y 1998, bajo la direccin del Doctor Josep
Blat Gimeno.
Las ilustraciones que componen la imagen de la portada aparecen con el permiso de su autor,
Antonio Fernndez Coca.
Una metodologa relacional hipermedia. Estudio en casos prcticos
Contenidos generales
CONTENIDOS
CONTENIDOS............................................................................................................................................3
CAPTULO I - INTRODUCCIN............................................................................................................7
1.1. ESTRUCTURA DEL PROYECTO..................................................................................................................7
1.2. CONCEPTOS FUNDAMENTALES ..............................................................................................................10
1.2.1. Hipertexto, multimedia e hipermedia...........................................................................................10
1.2.1.1. Hipertexto............................................................................................................................................. 10
1.2.1.2. Multimedia ........................................................................................................................................... 11
1.2.1.3. Hipermedia ........................................................................................................................................... 11
1.2.1.4. Resumen ............................................................................................................................................... 11
1.2.2. Ingeniera del software ................................................................................................................12

1.2.2.1. Anlisis................................................................................................................................................. 13
1.2.2.2. Diseo................................................................................................................................................... 14
CAPTULO II - LOS PRIMEROS MODELOS HIPERMEDIA .........................................................15

2.1. MODELO DE HIPERTEXTO DE DEXTER ..................................................................................................15
2.1.1. Breve descripcin del sistema ......................................................................................................15
2.1.2. Modelo simple de la capa de almacenamiento ............................................................................17
2.1.2.1. Enlaces span-to-span............................................................................................................................ 18
2.1.3. Capa de tiempo de ejecucin .......................................................................................................21

2.1.4. Conclusiones ................................................................................................................................23
2.2. MODELO DE HIPERMEDIA DE AMSTERDAM ...........................................................................................24
2.2.1. Descripcin de los conceptos del AHM .......................................................................................24
2.2.1.1. Hipertexto, multimedia e hipermedia.................................................................................................... 24
2.2.1.2. Informacin temporal ........................................................................................................................... 26
2.2.1.3. Enlaces en hipermedia .......................................................................................................................... 27
2.2.1.4. Atributos de especificacin de la presentacin a alto nivel .................................................................. 28
2.2.2. El modelo de hipermedia de Amsterdam......................................................................................28

2.2.3. Relaciones temporales .................................................................................................................30
2.2.4. Otras contribuciones del modelo .................................................................................................31
2.2.4.1. Contexto de los enlaces ........................................................................................................................ 31
2.2.4.2. Canales ................................................................................................................................................. 31
2.2.5. Conclusiones ................................................................................................................................31

CAPTULO III - EL MODELO HDM ...................................................................................................32
3.1. OBJETIVOS Y MOTIVACIONES ................................................................................................................32
3.2. PRIMITIVAS ...........................................................................................................................................34
3.2.1. Entidades y tipos de entidades .....................................................................................................35
3.2.2. Componentes................................................................................................................................35
3.2.3. Perspectivas .................................................................................................................................35
3.2.4. Unidades ......................................................................................................................................36
3.2.4. Enlaces en general .......................................................................................................................36
3.2.5. Enlaces de perspectiva o de componentes ...................................................................................36
3.2.6. Enlaces estructurales ...................................................................................................................37
3.2.7. Enlaces de aplicacin y tipos de enlaces .....................................................................................37
3.2.8. Esquema HDM .............................................................................................................................37
3.3. EVALUACIN DE UNA APLICACIN USANDO HDM ................................................................................39
3.4. CONCLUSIONES .....................................................................................................................................41
CAPTULO IV - LA METODOLOGA RMM......................................................................................42
4.1. LA PRIMERA FORMULACIN DE LA METODOLOGA RMM......................................................................42
4.1.1. El modelo RMDM ........................................................................................................................42
4.1.2. Etapas de la metodologa.............................................................................................................46
4.1.2.1. Etapa 0.................................................................................................................................................. 46
4.1.2.2. Etapa 1: Diseo Entidad-Relacin........................................................................................................ 46
4.1.2.3. Etapa 2: Diseo de slices ...................................................................................................................... 47
Pg. 3
4.1.2.4. Etapa 3: Diseo navegacional............................................................................................................... 48

4.1.2.5. Etapas 4 a 7: Interfaz de usuario y construccin................................................................................... 50
4.1.2.6. Relacin con las etapas tradicionales de la Ingeniera del Software ..................................................... 51
4.1.4. Conclusiones y discusin .............................................................................................................51

4.2. EVOLUCIONES DE RMM .......................................................................................................................54
4.2.1. Estructura de datos y navegacin ................................................................................................54
4.2.1.1. Slice mnimo y slice hbrido ................................................................................................................. 54
4.2.1.2. Los m-slices .......................................................................................................................................... 55
4.2.1.3. Conclusiones ........................................................................................................................................ 56
4.2.2. Las etapas de interfaz de usuario.................................................................................................57

4.2.2.1. Etapa 4: Diseo de protocolos de conversin....................................................................................... 57
4.2.2.2. Etapa 5: Diseo de la interfaz de usuario ............................................................................................. 58
4.2.2.3. Etapa 6: Diseo del comportamiento en tiempo de ejecucin .............................................................. 58
4.2.2.4. Etapa 7: Construccin y tests................................................................................................................ 59
4.2.2.5. Conclusiones ........................................................................................................................................ 59
4.3. MEJORAS EN ESTRUCTURAS NAVEGACIONALES PARA RMM.................................................................60

4.3.1. Caso A: accesos jerrquicos ........................................................................................................60
4.3.2. Caso B: acceos en relaciones N:M ..............................................................................................62
4.3.3. Caso C: accesos mltiples............................................................................................................65
4.3.4. Conclusiones ................................................................................................................................69
CAPTULO V - 1ER CASO: CD-ROM DEL PARC NATURAL DE SALBUFERA..........................71
5.1. QU ES EL CD-ROM DE PARC NATURAL DE SALBUFERA ...................................................................71
5.1.1. Introduccin .................................................................................................................................71
5.1.2. Estructura de la aplicacin ..........................................................................................................72
5.1.3. Premios recibidos.........................................................................................................................75
5.2. MODELADO DE LA NAVEGACIN DEL CD..............................................................................................76
5.3. APLICACIN DE TODAS LAS FASES DE LA METODOLOGA.......................................................................82
5.3.1. Primera etapa: Diseo entidad-relacin .....................................................................................82
5.3.2. Segunda fase: Diseo de slices ....................................................................................................84
5.3.3. Tercera fase: Diseo navegacional..............................................................................................86
5.4. CONCLUSIONES .....................................................................................................................................89
CAPTULO VI - 2 CASO: PROYECTO EUROPEO MINTOUR .....................................................90
6.1. QU ES MINTOUR ................................................................................................................................92
6.1.1. Por qu nace MINTour ................................................................................................................92
6.1.2. Objetivos ......................................................................................................................................92
6.2. 1 ETAPA: ANLISIS ENTIDAD-RELACIN .............................................................................................94
6.2.1. reas geogrficas.........................................................................................................................94
6.2.2. Alojamientos.................................................................................................................................97
6.2.3. Playas.........................................................................................................................................100
6.2.4. Deportes .....................................................................................................................................102
6.2.5. Eventos culturales ......................................................................................................................105
6.2.6. Museos y monumentos................................................................................................................107
6.2.7. Naturaleza ..................................................................................................................................109
6.2.8. Entretenimientos ........................................................................................................................111
6.2.9. Restaurantes...............................................................................................................................113
6.2.10. Rent-a-car ................................................................................................................................115
6.2.11. Tienda ......................................................................................................................................117
6.2.12. Transporte areo......................................................................................................................119
6.2.13. Transporte martimo ................................................................................................................122
6.2.14. Transporte terrestre .................................................................................................................125
6.2.15. Transporte Urbano...................................................................................................................128
6.2.16. Taxis .........................................................................................................................................132
6.2.17. Paquete turstico ......................................................................................................................133
6.2.18. Excursiones ..............................................................................................................................134
6.2.19. Telfonos y direcciones tiles ..................................................................................................136
6.2.20. Agencias de viaje .....................................................................................................................137
6.3. 2 ETAPA: DISEO DE SLICES ..............................................................................................................139
6.3.1. reas geogrficas.......................................................................................................................139
Pg. 4
6.3.2. Alojamientos...............................................................................................................................141
6.3.3. Playas.........................................................................................................................................144
6.3.4. Deportes .....................................................................................................................................145
6.3.7. Naturaleza ..................................................................................................................................151
6.3.9. Restaurantes...............................................................................................................................155
6.3.10. Rent-a-car ................................................................................................................................157
6.3.11. Tienda ......................................................................................................................................159
6.3.12. Transporte areo......................................................................................................................161
6.3.16. Taxis .........................................................................................................................................173
6.3.18. Excursiones ..............................................................................................................................175
6.4. 3 ETAPA: DISEO NAVEGACIONAL.....................................................................................................179
6.4.1. reas geogrficas.......................................................................................................................180
6.4.2. Alojamientos...............................................................................................................................182
6.4.3. Playas.........................................................................................................................................184
6.4.4. Deportes .....................................................................................................................................185
6.4.7. Naturaleza ..................................................................................................................................189
6.4.9. Restaurantes...............................................................................................................................191
6.4.10. Rent-a-car ................................................................................................................................192
6.4.11. Tienda ......................................................................................................................................193
6.4.12. Transporte areo......................................................................................................................194
6.4.16. Taxis .........................................................................................................................................202
6.4.18. Excursiones ..............................................................................................................................204
6.4.21. Jerarqua de mens ..................................................................................................................207
6.5. ETAPAS 4 A 7: INTERFAZ DE USUARIO Y CONSTRUCCIN ....................................................................209
6.6. CONCLUSIONES ...................................................................................................................................211
CAPTULO VII - 3ER CASO: CD-ROM DEL ATLES DE LES ILLES BALEARS.........................213
7.1. QU ES EL ATLES DE LES ILLES BALEARS ..............................................................................................213
7.2. PRIMER ESTUDIO DEL CASO.................................................................................................................215
7.2.1. Etapa 0: anlisis de requerimientos...........................................................................................215
7.2.2. Etapa 1: Diseo Entidad-Relacin ............................................................................................216
7.2.3. Etapa 2: Diseo de slices...........................................................................................................217
7.2.4. Etapa 3: Diseo navegacional ...................................................................................................218
7.3. SEGUNDO (Y DEFINITIVO) ESTUDIO DEL CASO .....................................................................................220
7.3.1. Etapa 0: anlisis de requerimientos...........................................................................................221
7.3.2. Etapa 1: Diseo Entidad-Relacin ............................................................................................221
7.3.3. Etapa 2: Diseo de slices...........................................................................................................222
7.3.4. Etapa 3: Diseo navegacional ...................................................................................................223
7.3.5. Etapa 4: Diseo de protocolos de conversin ...........................................................................225
7.3.6. Etapa 5: Diseo de la interfaz de usuario..................................................................................226
7.3.6.1. Conclusiones de esta etapa ................................................................................................................. 232
Pg. 5
7.3.7. Etapa 6: Diseo del comportamiento en tiempo de ejecucin ...................................................233

7.3.8. Etapa 7: Construccin y tests.....................................................................................................233
7.4. CONCLUSIONES ...................................................................................................................................234
CAPTULO VIII - CONCLUSIONES ..................................................................................................235
8.1. RESUMEN FINAL Y CONCLUSIONES ......................................................................................................235
8.1.1. Modelo de Dexter.......................................................................................................................235
8.1.2. Modelo de Amsterdam................................................................................................................236
8.1.3. Modelo HDM .............................................................................................................................237
8.1.4. Metologa RMM .........................................................................................................................237
8.1.4.1. Evoluciones de RMM......................................................................................................................... 238
8.1.4.1. Mejoras en las estructuras de navegacin en RMM............................................................................ 239
8.1.5. Casos de estudio.........................................................................................................................241

8.1.5.1. CD-ROM del Parc Natural de SAlbufera ......................................................................................... 241
8.1.5.2. Proyecto MINTour ............................................................................................................................. 242
8.1.5.3. CD-ROM del Atles de les Illes Balears .............................................................................................. 243
8.2. LNEAS DE FUTURO .............................................................................................................................244

CAPTULO IX - BIBLIOGRAFA .......................................................................................................245
Pg. 6
I - Introduccin
Captulo I
INTRODUCCIN
Las metodologas de Anlisis y Diseo estn orientadas a obtener un software fiable y
eficiente, que cumpla los requerimientos preestablecidos.
Pero el desarrollo de una aplicacin multimedia-hipermedia presenta dos aspectos
especficos respecto al desarrollo del software tradicional:
En el desarrollo de una aplicacin multimedia pueden participar tipos de
gente muy diferentes, como, por ejemplo, informticos, diseadores, artistas,
gegrafos, historiadores, fillogos, ..., cada uno de ellos con un lenguaje muy
distinto, en mayor medida y con diferente papel que en otras aplicaciones.
Se le da mayor importancia a la interfaz de usuario, ya que las aplicaciones se
orientan al disfrute, a la consulta extensiva, ... frente al modelo transaccional
clsico. Es por ello que es frecuente la utilizacin del prototipado.
Varios intentos ha habido de crear modelos o metodologas orientados a este campo de
la multimedia-hipermedia con el objetivo de dotar de un lenguaje comn a los miembros
del equipo y especialmente de mejorar las estructuras de navegacin, hacindola,
sobretodo, ms intuitiva al usuario final; y por supuesto que sin olvidar el propsito de
conseguir que el producto resultante sea lo ms fiable y eficiente posible.
El objetivo general es el de determinar una metodologa que sea de utilidad para el
desarrollo de proyectos en el mbito de la hipermedia. En nuestro proyecto se examinan
de forma relativamente breve algunas de las metodologas propuestas y los conceptos
bsicos. Una de ellas, RMM, ser aplicada y estudiada en gran detalle mediante tres
casos prcticos que se corresponden a tres aplicaciones multimedia, en dos de los cuales
el proyectista participa activamente. Ventajas, inconvenientes y posibles modificaciones
a la metodologa son propuestas.
Para ello la metodologa ser aplicada y estudiada mediante tres casos prcticos, que se
corresponden a tres aplicaciones multimedia, en dos de los cuales el proyectista
participa activamente.
1.1. Estructura del proyecto

La estructura en que se presenta el proyecto no coincide exactamente con la evolucin
temporal que ste ha seguido, ya que los casos de estudio han determinado las
propuestas de mejora a la metodologa, aunque en el presente documento stas se
explican con anterioridad.
En este primer captulo se definen los conceptos fundamentales entorno de los cuales va
a girar todos el proyecto, como son hipertexto, multimedia e hipermedia por un lado, y
Pg. 7
I - Introduccin
la ingeniera del software, por otro, describiendo brevemente qu es una metodologa y

qu se entiende por anlisis y diseo de software.
En el segundo captulo, comenzaremos a centrarnos en las metodologas orientadas a la
hipermedia. En primer lugar analizaremos el modelo de Dexter, el primer intento, que
data de finales de los 80, de investigar las caractersticas propias de la hipermedia,
ofreciendo un modelo que describe su estructura. Dexter proporciona tambin una
terminologa que a partir de entonces se considerara estndar en este campo.
Posteriormente se analiza el modelo de Amsterdam, fuertemente basado en el anterior,
al que se aade el concepto de tiempo, que Dexter no consider, principalmente debido
a que Dexter se cie fundamentalmente a hipertexto, y no considera la variedad de
medios existentes y el principal problema que conllevan, que son las relaciones
temporales.
En el tercer captulo trataremos el modelo HDM (Hypertext Design Model). El objetivo
del modelo HDM ya es, ms que describir la estructura interna de una aplicacin
hipermedia como era el caso de Dexter y Amsterdam, crear un modelo que sea de
utilidad para realizar el diseo de una aplicacin, a partir de la estructura de datos. Es de
gran importancia este hecho de centrar en la estructura de datos un buen diseo de la
aplicacin. Tambin el modelo basado en la estructura de datos es muy til para el
anlisis de aplicaciones ya existentes y comparaciones entre ellas.
Y en el cuarto captulo nos centraremos en la metodologa RMM (Relationship
Management Methodology), que no slo ofrece un modelo basado en la estructura de
datos, como el caso de HDM, sino que ya es una metodologa completa. Se definen una
serie de etapas y modelos para cada una de ellas, desde el anlisis inicial de requisitos
hasta la implementacin y pruebas. A continuacin, explicaremos por qu elegimos
RMM para nuestros casos de estudio y veremos, basados en la experiencia que stos nos
han deportado, los principales defectos y carencias que hemos encontrado en RMM y las
mejoras que nosotros hemos propuesto, fundamentalmente basadas en unos nuevos
patrones de acceso a la informacin.
Los siguientes tres captulos corresponden a los tres casos de estudio:
Al realizar el anlisis del CD-ROM del Parc Natural de SAlbufera fue la
primera vez que utilizamos la metodologa RMM con un problema
relativamente grande. Se trata del anlisis de una aplicacin ya finalizada con
el objetivo de encontrar enlaces de navegacin que no se contemplaron al
desarrollarla.
El segundo caso de estudio, el proyecto MINTour, es con mucho, el de mayor
envergadura. Se trata de un gran proyecto europeo sobre informacin
turstica. Hemos realizado el anlisis y diseo completo, si bien el modelo
final no fue implementado al alejarse el proyecto europeo de las
especificaciones iniciales. Nos ha sido de gran ayuda para identificar los
problemas de RMM y los patrones de las estructuras navegacionales que
proponemos como mejora.
Pg. 8
I - Introduccin
El tercer caso de estudio, el Atles de les Illes Balears, s que ha dado lugar a la
implementacin de la aplicacin basada en el anlisis y diseo utilizando
RMM. Es la confirmacin de que RMM con nuestras mejoras es realmente
utilizable. Nos ha sido muy til en los aspectos correspondientes a disear
interfaz grfica estructurada, basada en el anlisis.
Por ltimo, en el captulo final se ofrecen un resumen final, conclusiones y posible
lneas de accin futuras.
Pg. 9
I - Introduccin
1.2. Conceptos fundamentales

1.2.1. Hipertexto, multimedia e hipermedia
1.2.1.1. Hipertexto
La manera ms sencilla de definir qu es hipertexto es compararlo con la forma
tradicional del texto, con pueda ser un libro. El texto tradicional es secuencial, es decir
que hay una nica secuencia lineal que define el orden en que el texto debe ser ledo. Se
empieza por la pgina 1, luego la 2, y as sucesivamente hasta la ltima. La figura lo
muestra:
1
...
En cambio el hipertexto es fundamentalmente no secuencial. No existe un nico orden

en el que el texto debe ser ledo. En la figura se ve claramente:
A
Como se ve, no hay un nico camino para explorar, y por tanto ya no tiene sentido
enumerar las pginas, pues nunca se puede saber cul ser la segunda pgina, cul la
tercera, e incluso ni siquiera la ltima.
As, el hipertexto presenta diferentes opciones al lector y ser cada lector,
individualmente, el que determine cul de ellos seguir mientras lea el texto. Por tanto,
el autor no debe slo preparar una secuencia de lectura, sino numerosas.
En el segundo diagrama, cada una de las cuatro porciones de texto que vemos
representadas vemos representadas, reciben el nombre de nodos en la terminologa de
hipertexto. Estos nodos constituyen la unidad de informacin, la parte ms pequea con
sentido propio. Los nodos se interconectan, es decir se pasa de uno a otro, de una
porcin de texto a otra, mediante lo que se denominan enlaces (links en ingls). As, un
enlace conecta dos nodos, uno el origen, llamado ancla (anchor) y el otro denominado
destino (destination).
Pg. 10
I - Introduccin
Frecuentemente el enlace no est asociado a un nodo ancla en general, sino a una parte
de l en particular, como pueda ser un conjunto de caracteres. El mecanismo ms tpico
de enlace en hipertexto es el de pulsar sobre una palabra (ancla) e ir (navegar) hacia el
destino, que puede ser por ejemplo su definicin.
1.2.1.2. Multimedia
Con multimedia designamos a aquella aplicacin que presenta varios medios, en
contraposicin a las aplicaciones tradicionales que slo contienen uno, el texto.
As, una aplicacin multimedia puede contener, adems del texto, grficos, imgenes,
secuencias de audio y/o vdeo, animaciones en dos o tres dimensiones, ...
La interactuacin de los diferentes medios y la sincronizacin entre ellos suele ser uno
de los aspectos ms complejos en el desarrollo de aplicaciones multimedia.
1.2.1.3. Hipermedia
Como su propio nombre indica, hipermedia es la suma de hipertexto y multimedia. Es
un hipertexto multimedia.
La estructura de una aplicacin hipermedia es la misma que la de un hipertexto,
formado por nodos que se conectan mediante enlaces. La nica diferencia es que los
nodos contienen elementos de diferentes medios. Los anclas ya no slo son palabras
sino que pueden, por ejemplo, ser una imagen o un fragmento de ellas. El mayor
problema es establecer anclas en un medio que depende del tiempo, como el vdeo o el
audio. Es difcil hacer notar al usuario que si pulsa sobre un vdeo, el destino del enlace
ser diferente segn el momento del vdeo, y mucho ms complejo todava es definir
enlaces con el sonido, ya que ste no se puede pulsar.
Como claro y muy difundido ejemplo de hipermedia tenemos las pginas web. All,
podemos crear nodos incluyendo texto, y cualquier elemento multimedia, y crear los
enlaces, definiendo los anclas, ya sea en elementos de texto, en imgenes, e incluso ya
es posible en fragmentos concretos de una pelcula de vdeo.
1.2.1.4. Resumen
Hemos visto tres conceptos diferentes:
hipertexto: texto en formato no secuencial, compuesto de nodos y enlaces
que los interconectan
multimedia: unin de diferentes medias, como texto, grficos, vdeo, ...
hipermedia: hipertexto + hipermedia
A pesar de que la diferencia entre estas tres definiciones es clara, es frecuente utilizar
los trminos indistintamente. En concreto, hoy da son muy poco corrientes los
Pg. 11
I - Introduccin
hipertextos puros, ya que casi todos incluyen elementos multimedia, aunque slo sea
para hacerlos ms vistosos y atractivos. Por otro lado, no todas las aplicaciones
multimedia son hipermedia, ya que pueden ser una simple presentacin de pantallas en
orden secuencial. No obstante, a menudo se utilizan indistintamente los trminos
hipermedia y multimedia, ya que se entiende que una buena aplicacin multimedia debe
ser en realidad hipermedia, y sino no es ms que una simple presentacin, no una
aplicacin.
1.2.2. Ingeniera del software

En [PRE98], en su prlogo a la edicin espaola encontramos cuatro diferentes
definiciones de qu es la ingeniera del software, de sendos expertos en el tema. Creo
que todas ellas son de gran inters:
1. Ingeniera de Software es el estudio de los principios y metodologas para
desarrollo y mantenimiento de sistemas de software. (Zelkovitz, M.V., Shaw,
A.C. y Gannon, J.D.: Principles of Software Engineering and Design. PrenticeHall. 1979).
2. Ingeniera del Software es la aplicacin prctica del conocimiento en el diseo
y construccin de programas de computadora y la documentacin asociada
requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin
como desarrollo de software o produccin de software. (Boehm, B.W.:
Software Engineering. IEEE Transactions on Compueters, C.25, n 12,
diciembre, pp 1226-1241).
3. Ingeniera del Software trata del establecimiento de los principios y mtodos de
la ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje
en mquinas reales. (Bauer, F.L.: Software Engineering, Information
Processing, 71. North Holland Publishing Co., 1972).
4. La Ingeniera del Software hace referencia a la aplicacin de un enfoque
sistemtico, disciplinado y cuantificable al desarrollo, operacin
(funcionamiento) y mantenimiento del software. (IEEE: Standards Collection:
Software Engineering. IEEE Standard 610.12-1990, IEEE 1993).
Lo que parece claro despus de estas cuatro definiciones es que la Ingeniera del
Software pretende proveernos de unas metodologas, es decir unos conjuntos de
mtodos y de herramientas, con el objetivo de obtener un software fiable, de modo
rentable, fcil de mantener, a base de un desarrollo sistemtico.
Han sido numerossimas las metodologas que durante las ltimas dcadas han sido
utilizadas. Hay muchas diferencias entre ellas, pero casi todas tienen una base ms o
menos comn. La principal es la divisin del proceso en unas etapas bien diferenciadas
que componen lo que comnmente se denomina anlisis, diseo e implementacin y
pruebas. Cada una de ellas supone una visin, de ms a menos abstracta, del problema.
Pg. 12
I - Introduccin
Estas etapas confieren lo que tradicionalmente se denomina como el ciclo de vida de

una aplicacin, al que habra que aadirle una cuarta etapa muy importante que es la del
mantenimiento.
Las etapas de anlisis y diseo son la base para un obtener un buen sistema. Un mal
anlisis y diseo, por muy buenos que sean los programadores, acarrear un sistema
ineficiente, poco fiable, pero sobretodo muy costoso de ser mantenido. Estas etapas
utilizan unas herramientas diferentes para poder describir el sistema, a su nivel de
abstraccin correspondiente. Por herramientas aqu no se entiende herramientas
automticas, sino mtodos de modelado, es decir un conjunto de modelos y documentos,
que deben ir acompaados de unos principios claros para ser generados, y que pretenden
describir un aspecto de la aplicacin, como pueda ser, por ejemplo la estructura de los
datos.
A continuacin, veremos brevemente las principales caractersticas de las etapas de
anlisis y diseo, as como de los mtodos de modelado ms comnmente utilizados por
las ms famosas metodologas, en cada caso.
1.2.2.1. Anlisis
El anlisis ofrece una primera representacin del sistema. Su objetivo es hacer un
anlisis de los requisitos del sistema, desde un punto de vista funcional y obtener un
modelo, que aprobado por el usuario sirva de base para el diseo.
El anlisis, como hemos dicho, ofrece un modelo funcional del sistema, es decir de
cmo debe ser el sistema, qu informacin y funciones debe tener. En el diseo se
especificar en detalle cada una de esas funciones. As, aqu se define qu deber hacer
el sistema y en el diseo cmo lo debe hacer.
La revisin con el cliente de las especificaciones funcionales del software, resultado de
esta fase, es de vital importancia, y a menudo compleja debido a los lenguajes diferentes
que utilizan cliente y desarrollador. La creacin de prototipos suele ayudar a esta
comunicacin y a la deteccin de problemas y necesidades.
Mtodos de modelado del anlisis
Para especificar el anlisis del sistema se utilizan una serie de modelos. Generalmente el
modelado del anlisis se divide en dos partes fundamentales, el modelo de datos y el
modelo de flujos.
El modelo de datos se basa en el modelo entidad-relacin, donde se definen todas las
entidades que participan en el problema y las relaciones entre ellas. Un diccionario de
datos, donde se describen las entidades y sus atributos acompaa siempre a este modelo.
En cuanto al modelo de flujos, se utiliza el denominado modelo de flujo de datos, donde
se representa cmo los datos se transforman, definiendo las principales funcionalidades
del sistema. En determinados sistemas tambin se incluyen modelos de estado, donde se
describen las transiciones de estado que sufren las diferentes entidades.
Pg. 13
I - Introduccin
Las herramientas CASE permiten hacer un anlisis ms consistente y correcto,

utilizando la mayora de ellas todos los modelos anteriormente descritos.
1.2.2.2. Diseo
Durante el diseo se profundiza en los aspectos que ya fueron tratados en el anlisis. Si
en el anlisis nos detenamos en estudiar qu es lo que deber hacer el sistema, en el
diseo investigamos cmo debe hacerlo, definiendo en detalle todos los procesos del
sistema y datos que stos afectan. Se profundiza y completa la estructura de datos, por
un lado y la de programa, por otro. Esta divisin entre datos y programa (o procesos), da
lugar a lo que en algunas metodologas se denomina diseo de datos y diseo de
procesos, tambin llamado diseo arquitectnico. A estas dos divisiones, habra que
aadir una tercera correspondiente al diseo de la interfaz de usuario.
El resultado final del diseo es una representacin lo ms exacta posible de lo que ser
la aplicacin. A partir de esa representacin los programadores han de ser capaces de
codificar los modelo y convertirlos en la aplicacin.
Mtodos de modelado del diseo
Cada una de las partes del diseo cuenta con sus propios modelos.
El diseo de datos traduce el modelo entidad-relacin con su diccionario de datos en el
diseo de la base de datos, definiendo todas las tablas, ndices, atributos, ..., necesarios.
En cuanto al diseo de procesos, tambin se contina trabajando con los DFDs
(diagramas de flujos de datos). Se incluyen ya las tablas en vez de las entidades, y se
llega a una mayor profundidad en la jerarqua de procesos, hasta alcanzar el detalle de
definir los procedimientos que sern necesarios en pseudocdigo u organigramas.
Algunos autores denominan a esto ltimo diseo procedimental y lo consideran como
una cuarta etapa del diseo, diferente del diseo arquitectnico.
El diseo de la interfaz no est tan estandarizado como puedan estarlo los modelos de
las otras fases del diseo. Se basa bastante en la experiencia del diseador, y por
supuesto en los procesos donde intervenga el usuario que se hayan definido en el diseo
arquitectnico. A menudo se utilizan tcnicas de prototipado para comprobar la
aceptacin por parte de los usuarios de la interfaz propuesta.
Pg. 14
Una metodologa relacional hipermedia. Estudio en casos prcticos II - Los primeros modelos hipermedia
Captulo II
LOS PRIMEROS MODELOS HIPERMEDIA
El primer modelo que intent describir el hipermedia fue el de Dexter, que data de 1998.
Le sigui el de Amsterdam, que es una extensin al de Dexter aadiendo aspectos
temporales.
2.1. Modelo de Hipertexto de Dexter

El modelo de referencia de hipertexto de Dexter surge en 1988 durante unas reuniones,
la primera de las cuales tuvo lugar en la Dexter Inn (New Hampshire), de donde toma su
nombre, como un intento de respuesta a la pregunta: qu tienen en comn los distintos
sistemas de hipertexto en sus nociones de nodos y enlaces (links) entre dichos nodos?
As, se pretende que el modelo sirva como un estndar para comparar las caractersticas
y funcionalidades de varios sistemas de hipertexto. Tambin como una base sobre la
cual desarrollar estndares para interoperabilidad e intercambio entre sistemas de
hipertexto.
Otro punto importante de este trabajo es el de proveer de una terminologa comn al
campo del hipertexto.
Ntese que, a pesar de que a menudo se diferencia entre hipertexto e hipermedia, aqu
los autores no hacen tal distincin.
Las presentes notas estn basadas en el artculo [HAL94].
2.1.1. Breve descripcin del sistema

El modelo de Dexter divide el sistema hipertexto en tres capas diferentes. La primera, la
ms prxima al usuario es la denominada capa de tiempo de ejecucin (run-time
layer); la intermedia es la llamada capa de almacenamiento (storage layer), mientras
que la ltima recibe el nombre de capa del componente (within-component layer).
Pg. 15
capa de tiempo de ejecucin

(run-time layer)
Especificaciones de presentacin
capa de almacenamiento
(storage layer)
Anclaje (anchoring)
capa del componente
(within-component layer)
El modelo se centra en la capa de almacenamiento, que modela la estructura bsica de

nodos y enlaces. Vendra a ser como una base de datos donde se almacena una jerarqua
de componentes (contenedores de la informacin) interconectados por enlaces.
Los componentes es lo que conocemos tpicamente como nodos (por ejemplo una tarjeta
en Hypercard, o un frame en Director). Por tanto, un componente puede contener
fragmentos de texto, grficos, animaciones, ... Al estudiar la capa de almacenamiento
veremos que stos son lo que llamamos componentes atmicos, que al unirse forman
componentes compuestos, que es el equivalente a la nocin de nodo.
La capa de almacenamiento estudia los mecanismos por los cuales se unen dichos
componentes y enlaces.
Por contra, la capa del componente refleja los contenidos y estructura dentro de los
componentes. Debido a que hay un sin fin de posibles contenidos/estructuras que
pueden ser incluidos en un componente, el modelo de Dexter no profundiza el estudio
de esta capa, dando libertad en este nivel.
Una parte fundamental del modelo de Dexter es la interfaz entre las capa de
almacenamiento y la capa del componente. Se basa en el mecanismo de anclaje
(anchoring), que veremos ms adelante.
En cuanto a la capa de tiempo de ejecucin, sta provee al usuario de unas herramientas
para acceder, ver y manipular la estructura de la red de hipertexto. Al igual que en la
capa del componente, tambin existen un gran nmero de posibles herramientas para
acceder, ver y manipular un hipertexto. Por consiguiente, el modelo Dexter slo ofrece
unas ideas bsicas de cmo son esos mecanismos, pero no puede hacer referencia a los
detalles de cmo el usuario interacta con el hipertexto.
Un punto importante es la interfaz entre esta capa y la capa de almacenamiento, a la que
llama especificaciones de presentacin (presentation specifications). sta es un
mecanismo que permite que la forma en que un componente se presenta al usuario
pueda estar en funcin no slo de una herramienta de hipertexto especfica (es decir, de
una capa de tiempo de ejecucin especfica), sino que puede ser una propiedad del
componente por s mismo, del enlace tomado para llegar a tal componente o tambin de
las preferencias del usuario. Por ejemplo, un componente que contiene una animacin
Pg. 16
puede presentarse de dos maneras diferentes segn el usuario. Si el usuario es un

profesor, se le permitir editar el componente (la animacin), mientras que si el usuario
es un alumno, slo se le permite la visualizacin.
En la siguiente figura, vemos una representacin ms grfica de las tres capas del
modelo de Dexter. En la capa de tiempo de ejecucin, tenemos la presentacin del
hipertexto al usuario a travs de la pantalla. En la capa de almacenamiento, vemos una
base de datos donde se almacenan todos los componentes y enlaces entre ellos (los
enlaces tambin son componentes). Y por ltimo en la capa del componente, se guarda
la estructura interna del componente.
Comp. 55
Componente
24
Esto es
un texto
24
37
Componente
37
CAPA DE
TIEMPO DE
EJECUCIN
CAPA DE
ALMACENAMIENTO
CAPA DEL
COMPONENTE
2.1.2. Modelo simple de la capa de almacenamiento

La capa de almacenamiento describe la estructura de un conjunto finito de componentes,
junto con dos funciones, resolver y accessor, encargadas de recuperar componentes. Es
el componente el elemento fundamental de esta capa; ste puede ser un tomo, un enlace
entre componentes, o puede estar compuesto a partir de otros componentes (formando
un grafo acclico, ya que un ciclo implicara una recursividad). En el siguiente ejemplo
vemos dos casos prohibidos de componentes compuestos, debido a que crean
recursividad. Cada cuadro representa un componente compuesto; en la parte superior
aparece en nombre del componente y en la inferior los componentes (atmicos o
compuestos) que la forman.
Pg. 17
A
A
Ciclo: A no puede contener a

A
A
A
B
C
Ciclo: A no puede contener a

un componente que contiene a
A
Cada componente tiene un identificador nico (UID). La funcin accessor es la que

accede a un componente dado su UID, mientras que la funcin resolver permite, a partir
de unas especificaciones del componente recuperar los UID correspondientes. Despus
se podr acceder al componente mediante accessor. Por tanto, accessor constituye un
direccionamiento directo a las componentes, mientras que resolver se utiliza para un
direccionamiento indirecto, a dichos componentes a partir de las especificaciones.
2.1.2.1. Enlaces span-to-span

Los enlaces span-to-span son aquellos que van de una parte de una componente a otra
parte de otro componente.
Para conseguir los enlaces span-to-span
Dexter provee de una entidad de
direccionamiento indirecto llamada ancla (anchor). Un ancla tiene dos partes: un
identificador (id ancla - anchor id) y un valor (anchor value). El identificador es nico
dentro de cada componente. Por tanto, el par UID componente - id ancla es nico dentro
del hipertexto. El id ancla es manejado por la capa de almacenamiento para referenciar
al contenido del componente, y se mantiene siempre constante; mientras, el valor del
ancla es utilizado slo en la capa del componente, y cuando se edita y modifica el
componente. Por otro lado, el valor del ancla especifica de forma arbitraria alguna
localizacin, regin, tem o subestructura dentro de componentes. ste es slo
interpretable por las aplicaciones responsables de manejar el contenido/estructura del
componente.
Veamos cmo resulta la estructura de un componente atmico, teniendo en cuenta las
anclas:
Pg. 18
Especificacin
de presentacin
Atributos
Anclas
Contenidos
info. de esp. pres. del componente

info. semntica (incluido el UID)
id
valor
datos
Y en el caso de un componente compuesto, la nica diferencia es que se guardan

tambin los UIDs de los componentes hijos
Especificacin
de presentacin
Atributos
Anclas
Hijos
Contenidos
info. de esp. pres. del componente

info. semntica (incluido el UID)
id
valor
UID componente hijo
datos
A partir de aqu, para representar los extremos de un enlace, emplearemos el id ancla

combinado con la especificacin del componente, de cada extremo. Es lo que llamamos
un especificador (specifier). Adems de la especificacin de un componente y un id
ancla, son utilizados dos campos ms: una direccin y una especificacin de
presentacin de ese enlace. Como vemos, el especificador constituye, un extremo del
enlace, y por tanto, un enlace est formado por dos o incluso ms especificadores. En el
caso de tener ms de dos especificadores, tenemos lo que se denominan enlaces
mltiples (multiway links). El campo direccin puede tomar varios valores: TO, FROM,
BIDIRECT y NONE; el campo especificacin de presentacin se refiere a la interfaz
entre la capa de almacenamiento y la capa de tiempo de ejecucin, de la cual se hablar
posteriormente ms en detalle.
A continuacin se muestra un ejemplo de enlace entre los componentes atmicos 101 y
202. Cada uno de ellos tiene definido un ancla que apunta a un punto concreto del texto
(valor) y con un identificador. El componente 303 es un enlace entre los citados
componentes. Por tanto, tiene dos especificadores. Recordemos que los especificadores
se definen con una pareja UID componente - id ancla. Por tanto, el primero tiene el par
Pg. 19
(101,1) y el segundo (202,1). Adems, de esta pareja, el identificador debe definir el

sentido del enlace, en este caso del 101 (FROM) al 202 (TO).
Vemos primero un diagrama y despus la descripcin escrita del modelo.
Componente 101
tipo: texto
uid: 101
especif. pres.: ...
Anclas
valor id
1
Esto es un
texto...xxxxx ...
Componente 303
tipo: enlace
uid: 303
especif. pres.: ...
Especificador
uid componente: 101
id ancla: 1
direccin: FROM
especif. pres.: ...
Componente 202
tipo: texto
uid: 202
especif. pres.: ...
Anclas
valor id
2
Esto es otro
texto...yyyyyy ...
Especificador
uid componente: 202
id ancla: 2
direccin: TO
especif. pres.: ...
<hipertexto>
<componente>
<tipo>texto</tipo>
<uid>101</uid>
<especificacin de presentacin>...</especificacin de presentacin>
<datos>Esto es un texto ...</data>
<ancla>
<id>1</id>
<valor>22-26</valor>
(La posicin del ancla en el texto)
</ancla>
</componente>
<componente>
<tipo>texto</tipo>
<uid>202</uid>
<datos>Esto es otro texto ...</data>
<ancla>
<id>2</id>
<valor>35-46</valor>
</ancla>
</componente>
<componente>
<tipo>enlace</tipo>
<uid>303</uid>
<especificador>
<uid componente>101</id>
<id ancla>1</valor>
Pg. 20
<direccin>FROM</direccin>
</especificador>
<especificador>
<uid componente>202</id>
<id ancla>2</valor>
<direccin>TO</direccin>
</especificador>
</componente>
Una serie de funciones nos permiten acceder y modificar la capa de almacenamiento.

Estas funciones, sobre las que no profundizaremos, nos permiten, entre otras cosas,
crear un componente atmico, crear un componente compuesto, crear un enlace,
modificar o borrar los anteriores.
Por ltimo, no deben obviarse nunca estas cinco reglas:
La funcin accessor debe permitir que cada componente sea accesible desde
un UID.
La funcin resolver debe ser capaz de producir todos los posibles UIDs
vlidos.
No hay ciclos en las relaciones componente/subcomponente (un componente
no puede ser subcomponente de s mismo.
Los identificadores de anclas de un componente han de ser los mismos que
los identificadores de anclas del especificador de enlace, cuyo extremo es ese
componente.
El hipertexto debe ser lo que se denomina link-consistent, es decir, que al
borrar un componente se borren tambin los enlaces que lo tienen como
extremo.
2.1.3. Capa de tiempo de ejecucin

El concepto fundamental de la capa de tiempo de ejecucin es la instanciacin de un
componente. Una instanciacin es una presentacin de un componente al usuario.
El funcionamiento es similar al de una cache: una copia (instanciacin) de un
componente se pasa al usuario para que la visualice y/o edite. Esta copia ser despus
escrita de nuevo en la capa de almacenamiento. Ntese que puede haber ms de una
instanciacin de un componente a la vez. Por ello, a cada instanciacin se le asigna un
identificador nico (instantiation identifier - IID).
Pg. 21
C. tiempo
ejecucin
Capa
almacenam.
>
instancia del botn que se

presenta al usuario
componente 345 - botn
Recordemos que la manera en que el componente se presenta al usuario depender de

las preferencias que tenga definidas en las especificaciones de presentacin.
La instanciacin de un componente tambin conlleva la de sus anclas. A esto se le
llamar marcador de enlace (link marker), que es la manifestacin visible de un ancla
en un documento.
En resumen, una instanciacin contendr:
una instanciacin base (base instantiation), que es una primitiva del modelo
que representa algn tipo de presentacin de el componente al usuario.
una secuencia de marcadores de enlace junto con una funcin que haga
corresponder esos marcadores de enlaces a las anclas que instancian.
Como que en un momento dado un mismo usuario puede estar visualizando y/o
editando varias instanciaciones de componentes, se define una nueva entidad en el
modelo que es la sesin, que permite saber momento a momento la relacin entre los
componentes y sus instanciaciones. As, cuando un usuario pretende acceder a un
hipertexto, lo que hace es abrir una sesin. Y esto es lo que ser necesario para cada
sesin:
el hipertexto que es accedido
los IID de las instanciaciones a componentes de la capa de almacenamiento
que se utilizan en esta sesin
una historia, que contiene las operaciones que se han hecho desde que se abri
la sesin
una funcin run-time resolver, que es el equivalente a la funcin resolver de
la capa de almacenamiento
una funcin de instanciacin (instantiator), que devolver, a partir de un UID
y una especificacin de presentacin (otra primitiva del modela que define
cmo se presentar un componente), una instanciacin del componente
como parte de la sesin.
Pg. 22
una funcin realizer, que es la inversa de la funcin de presentacin. Es decir,

que a partir de una instancia, devuelve un componente que refleje el estado
actual de la instanciacin. Esto es usado para el mecanismo de writing-back
in cache, es decir, de crear o modificar el componente en la capa de
almacenamiento.
Al igual que tenamos un conjunto de funciones que permitan acceder y modificar la
capa de almacenamiento, tambin tenemos un conjunto de operaciones que nos lo
permiten sobre la capa de tiempo de ejecucin. Estas operaciones, sobre las que
tampoco profundizaremos, nos permiten, entre otras cosas, crear una sesin, crear una
instanciacin para un componente, actuar sobre el componente asociado con la
presentacin, seguir un enlace, ...
2.1.4. Conclusiones
Dexter fue el primer intento de modelar el hipertexto y de dar una terminologa comn
para este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de
1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que son
hoy.
De hecho, la principal carencia que se puede observar en este modelo es que, a pesar de
que los autores lo recomiendan para tanto hipertexto como hipermedia, no aborda en
ningn momento la complejidad de los distintos medios. En realidad, se podra decir
que el modelo est fundamentalmente destinado slo a hipertexto, y la aplicacin a la
hipermedia es muy difcil. Por ejemplo, el concepto de valor del ancla lo hace en
funcin de la posicin del ancla en el texto, pero esto en otro medio no tiene sentido.
En concreto, no tiene en cuenta los aspectos relacionados con el tiempo, algo
fundamental en el audio y el vdeo. Es por ello que posteriormente apareci el modelo
de Amsterdam, que basado en Dexter, aade el estudio del tiempo.
Pero, a pesar de eso (no hay que olvidar que estos elementos eran imposibles de utilizar
en 1988), el modelo especifica, por primera vez y muy detalladamente, cmo es la
estructura interna de un hipertexto. Incluso define unas estructuras que no haban sido
utilizadas hasta entonces como los enlaces mltiples, la posibilidad de hacer un enlace a
otro enlace (recordemos que los enlaces son componentes) o los componentes
compuestos, que por aquel entonces muchos sistemas de hipertexto no soportaban.
Pg. 23
2.2. Modelo de hipermedia de Amsterdam

Hipermedia es la suma de hipertexto y multimedia. El hipertexto nos provee de una
estructura de navegacin a travs de los datos, mientras que la multimedia nos ofrece
como punto fundamental una gran riqueza de tipos de datos.
Sin embargo, el modelo de Dexter, aunque segn sus autores est orientado a
hipermedia, la realidad es que se centra por completo en el hipertexto, dejando de lado
el estudio de la variedad de tipos posibles. Y entre esos tipos, no hay que olvidar que los
hay dependientes del tiempo. Por tanto, el modelo de Dexter comete un gran olvido: no
toma en consideracin el concepto del tiempo. Se hace necesario un nuevo modelo de
datos multimedia, en el que se van a ver reflejadas relaciones complejas en tiempo. Por
ejemplo, es necesario contemplar algo tan tpico en una aplicacin hipermedia como que
a los 4 seg. de que se active un vdeo, aparezca cierto texto (sincronizacin entre
componentes). Sobre estos conceptos surge el Modelo de Hipermedia de Amsterdam
(AHM).
En resumen, mientras que el modelo de Dexter permite la composicin de estructuras
jerrquicas, la especificacin de enlaces entre componentes y el uso de anclas, el modelo
de Amsterdam lo extiende aadiendo las nociones de tiempo, presentacin a alto nivel
de atributos y enlaces de contexto.
Hay cierto vocabulario ligeramente diferente al empleado en Dexter: un documento es
una coleccin completa de componentes, cada uno de los cuales puede estar compuesto
de otros componentes, o bien de componentes atmicos, llamados aqu elementos de
datos (data elements) o tambin entidades. Una presentacin es la forma activa de un
documento. A menudo, se habla indistintamente de documento o de presentacin.
Este apartado est basado en el artculo [HAR94].
2.2.1. Descripcin de los conceptos del AHM

2.2.1.1. Hipertexto, multimedia e hipermedia
Para hablar de un sistema multimedia o hipermedia no es suficiente con tener medios
dinmicos que dependan del tiempo. El concepto fundamental es la sincronizacin entre
ellos.
Pg. 24
tiempo
tiempo
(a)
(b)
Componentes (de varios medios)
(c)
Enlace
En la parte (a) de la figura, tenemos una red de hipertexto con enlaces entre
componentes. La visita a un componente termina bien por la finalizacin de la
aplicacin o bien por el paso a otro componente a travs de un enlace. Aqu el tiempo
apenas cuenta y tenemos bsicamente hipertexto.
En la parte (b) de la figura, tenemos una presentacin multimedia. El usuario controla
qu componente quiere visitar, pero ese componente puede ser dinmico, es decir que
vara sin la intervencin del usuario, segn una nocin temporal. Dos tipos de control
del usuario sobre las presentaciones se permiten aqu. La primera, la tpica similar al
panel de control de un cassette o vdeo-reproductor, con los controles stop/play/fast
forward/rewind. La segunda sera similar a un enlace hipertextual y nos llevara de un
punto temporal del componente a otro (sera similar a un fast forward pero parando en
un punto definido de antemano).
La parte (c) de la figura muestra la combinacin entre hipertexto y multimedia: cada
componente de la red hipertexto es una presentacin multimedia. As, hay dos aspectos
a tener en cuenta, que son la navegacin hiperestructurada dentro del documento y la
presentacin de la informacin multimedia. Esto sera hipermedia especficamente.
Pg. 25
2.2.1.2. Informacin temporal

En general, un modelo de hipermedia debera ser capaz de especificar cmo las partes
individuales se relacionan unas con otras. Una de esas relaciones es evidentemente la
temporal. De hecho, a menudo, estas relaciones temporales se han representado como un
simple enlace hipertextual. Esto es conceptualmente un error, ya que as se mezclan dos
aspectos separados de una presentacin como son las relaciones hipertextuales y las
temporales. La solucin que se propone en Amsterdam es la de particionar las relaciones
temporales entre datos en dos clases:
aquellas que se refieren a la identificacin de los componentes que estarn
presentes conjuntamente. A esta clase se la denomina coleccin.
aquellas que se refieren al orden relativo en el que estos componentes son
presentados. A esta clase se le da el nombre de sincronizacin.
Los componentes compuestos de Dexter pueden ser usados para recoger un conjunto
de componentes atmicos que van a ser presentados juntos. Pero esta definicin no nos
ofrece un mecanismo para especificar ninguna relacin temporal. El problema es la
sincronizacin entre esos componentes. As la sincronizacin puede estar basada bien en
informacin estructurada, o bien en el contenido de un componente.
Hay varias maneras de afrontar el problema de la coleccin y sincronizacin dentro de
un hipermedia. A continuacin mostramos tres diferentes estrategias:
tiempo
tiempo
(a)
tiempo
(b)
Componentes (de varios medios)
(c)
Enlace
Pg. 26
(a) Estructura oculta

La manera ms bsica y ms frecuente de manejar los datos dependientes del
tiempo consiste en poner todos estos datos dentro un nico componente. En el
diagrama vemos que tenemos cuatro media diferentes, y queda explicitado el
instante en que son activados cada uno de ellos. Esta solucin no requiere apenas
ningn cambio en relacin al modelo de Dexter. Todo queda definido en
trminos de la capa del componente y la sincronizacin usa tcnicas internas
(ocultas). Como contrapartida, no permite definir combinaciones de datos ms
complejas.
(b) Estructura separada
ste es el caso completamente opuesto. Aqu, cada parte de informacin
multimedia forma un bloque diferenciado. La coleccin queda representada
mediante un enlace multi-destino que apunte al inicio de todos los bloques
(mientras que en la solucin anterior nicamente era necesario un nico enlace
que apuntara al inicio del componente). Cruzar el enlace significar activar ese
componente. Mientras que la coleccin es fcilmente representable, la
sincronizacin no lo es tanto, ya que hace falta algn mecanismo para determinar
cundo un componente debe iniciarse en relacin a los otros.
Por tanto, los inconvenientes de este mtodo son que aaden una gran
complejidad dado el gran nmero de enlaces que son necesarios crear y
mantener. Cualquier herramienta tendr que ser compleja y con una difcil
interfaz de usuario.
(c) Estructura compuesta
sta es la solucin intermedia, compromiso entre coleccin y sincronizacin.
Aqu varios elementos son agrupados en componentes compuestas. Estas
componentes compuestas pueden agrupar uno o varios medias.
La coleccin es ms simple que en la segunda solucin y el problema de la
sincronizacin queda reducido a relaciones internas.
A menudo, la solucin no ser simplemente elegir entre uno de estos tres enfoques. De
hecho esto slo ocurrir con hipermedias pequeos. Lo habitual ser descomponer el
problema en pequeos sub-problemas, a cada uno de los cuales s que les aplicaremos
una de estas tres soluciones segn nos convenga.
2.2.1.3. Enlaces en hipermedia

Los enlaces influyen tanto en el orden de la presentacin, como en los componentes que
se visualizan simultneamente, pero no son stos sus aspectos fundamentales, ya que el
objetivo de un enlace debera ser definir un mecanismo de navegacin lgica en un
documento.
Pg. 27
Un enlace es aquello que define una transicin de un componente a otro. Sin embargo,
la nocin de enlace dentro de un componente es algo que no est considerado en Dexter.
En un sistema de hipertexto, es sencillo definir un enlace, ya que un componente puede
ser dividido en pequeas partes (captulos, secciones, ..., palabras y caracteres), y as
podemos utilizar el mecanismo de anclaje. Pero en un sistema multimedia, la asociacin
de un enlace con o dentro de un componente es mucho ms compleja, ya que los datos a
menudo no pueden ser fragmentados ni indexados.
Otro problema que no se trata en Dexter es el que se refiere a cunta informacin deja el
usuario al navegar a travs de un enlace. En un sistema de hipertexto, al cruzar un
enlace, o bien se abre una nueva ventana, o bien se sustituye lo que se estaba
visualizando por la informacin nueva. Esto es indicado aqu porque el usuario slo
puede leer una cosa a la vez. Pero en un entorno hipermedia, puede interesarle, por
ejemplo, seguir oyendo una explicacin, viendo el mismo vdeo, pero pasar a ver una
nueva imagen o texto, dependiendo del lugar en que se encuentre de la aplicacin. Para
tratar esto, se introduce la nocin de contexto del enlace, que ser tratado ms adelante.
2.2.1.4. Atributos de especificacin de la presentacin a alto nivel

En una aplicacin hipermedia tpica, cada pantalla contiene unos elementos de datos
propios; pero, adems, todas las pantallas tienen elementos que comparten un conjunto
comn de atributos para un tipo de datos en concreto. Por ejemplo, imaginemos un
audio que se utiliza a lo largo de una presentacin. En cada pantalla se usan diferentes
conjuntos de datos de audio, pero todas las pantallas compartirn unos atributos como el
volumen o la calidad del tono, los cuales no queremos que cambien cada vez que
pasemos de una pantalla a otra. Por tanto, estos atributos tienen una definicin global
para toda la presentacin y sern asociados no slo a un componente, sino a toda un tipo
de informacin (o medio).
Estos atributos globales, que no se consideraron en el modelo de Dexter, se manejan
utilizando el mecanismo de canales, que veremos ms adelante.
2.2.2. El modelo de hipermedia de Amsterdam

Este modelo se defini a partir de la combinacin del modelo de Dexter con los canales,
aadiendo extensiones para soportar ciertos requerimientos de la hipermedia que no
haban sido contemplados. ha sido empleado para desarrollar numerosas aplicaciones
hipermedia.
Veamos cul es la estructura de un componente, ya sea atmico o compuesto en el

modelo de Amsterdam y comparmoslo con el de Dexter, que ya vimos en el apartado
anterior.
Componente atmico:
Pg. 28
Especificacin
de presentacin
nombre del canal

duracin - explcita o implcita
info. de esp. pres. de otros
Atributos
Anclas
Contenidos
info. semntica (incluido el ID)

id
valor
datos
Componente compuesto:
Especificacin
de presentacin
Arcos de
sincronizacin
Atributos
Anclas
Tipo de
composicin
Arcos de
sincronizacin
info de esp. pres. del componente

id componente origen
id componente destino
relacin temporal
info. semntica (incluido el id)

id
lista de (id componente - id ancla)
Opcin o paralelo
id componente
tiempo de inicio
Vemos que un componente compuesto no contiene datos, sino que slo los datos slo
pueden ser referenciados a travs de los componentes atmicos.
Este enfoque tiene tres ventajas sobre Dexter:
Localiza la informacin temporal y de presentacin en las componentes
atmicas, mientras que la estructura de la presentacin se deja para las
componentes compuestas. En teora, esto facilita las tareas de mantenimiento.
Pg. 29
Promueve la reusabilidad de datos al forzar que todos los elementos se

mantengan por separado.
Modela de forma ms aproximada la forma en que la informacin multimedia
se almacena, esto es, en sistemas de ficheros o bases de datos.
As, los componentes atmicos contienen informacin sobre la presentacin, atributos,
informacin de anclas y campo de contenidos (datos). Lo nuevo respecto al modelo de
Dexter es el campo de presentacin, en el cual una se dedica a aspectos relacionados con
el tiempo.
En cuanto a los componentes compuestos, se aaden varios elementos nuevos, respecto
a Dexter. La diferencia principal es que ahora es usado para especificar la estructura de
una presentacin y no slo para unir componentes para la navegacin.
Los atributos temporales de la presentacin se obtienen de los componentes atmicos,
mientras que en la especificacin de la presentacin (componentes compuestos)
aparecen los arcos de sincronizacin, unas nuevas estructuras que nos dan una
informacin sobre el orden relativo de los componentes atmicos en la presentacin, y
que veremos posteriormente con ms detalle.
Tanto las anclas como el campo de atributos son similares a Dexter, con una pequea
diferencia: en los componentes compuestos se aade un tipo de composicin a la lista
de parejas <id componente, id ancla>. ste puede tomar dos valores:
paralelo: se visualizan todos a la vez
opcin (choice): slo se visualiza, como mximo, uno de los hijos
2.2.3. Relaciones temporales

Como ya hemos dicho, el principal mecanismo para representar las relaciones
temporales entre entidades son las componentes compuestas.
Hay dos tipos de sincronizacin entre componentes, una calificada como de grano
grueso y otra de grano fino. La primera es aquella que consiste en restricciones definidas
entre los hijos de una componente compuesta (que recordemos que pueden ser
componentes atmicas o compuestas), como por ejemplo el instante relativo de
comienzo de cada hijo dentro de la componente compuesta. Esta informacin est
explcita en la definicin de cada hijo. Por contra la sincronizacin de grano grueso
consiste en relaciones entre dos hijos (que pueden o no estar al mismo nivel, es decir
que pueden o no ser hermanos) explicitados mediante lo que llamamos un arco de
sincronizacin. Un arco de sincronizacin no se usa como un enlace navegacional, sino
que constituye un mecanismo flexible para establecer relaciones temporales dentro del
sistema hipermedia.
El modo de especificar las relaciones temporales en AHM tiene la ventaja de que hay
una clara separacin entre la coleccin de componentes que se muestran juntas, el orden
Pg. 30
relativo en el lo hacen y las relaciones temporales especficas que existen durante una
presentacin.
2.2.4. Otras contribuciones del modelo

2.2.4.1. Contexto de los enlaces
Los componentes compuestos no nos dan ninguna informacin de cmo se comporta
cada componente al navegar a travs de un enlace.
Para ello definimos el concepto de contexto de enlace, que ser un nuevo componente
(tpicamente compuesto) que contiene la coleccin de los componentes afectados por un
enlace. El mecanismo de contexto permite definir unas opciones de visualizacin
diferentes para cada enlace. En particular, puede ser que parte de la informacin
contine visible, mientras que otra deja de estarlo. La ventaja de esto es que, por un
lado, slo una parte de la estructura del documento se ve afectada al seguir un enlace, y
por otro, se nos ofrece una gran flexibilidad.
2.2.4.2. Canales
Terminaremos este apartado con el concepto de canales. stos son salidas abstractas
utilizadas para reproducir los contenidos de un componente. Asociado con cada canal
hay unas caractersticas de la presentacin. stas pueden ser dependientes de los tipos de
datos (media), como la fuente y estilo de un texto o el volumen de un sonido; pero
tambin pueden ser independientes, como por ejemplo los colores de background y
foreground.
Un uso tpico puede verse en una situacin en que deseamos una aplicacin hipermedia
en dos idiomas, por ejemplo castellano y cataln. Imaginemos que tenemos un vdeo
acompaados de un audio y un texto explicativos. Necesitaramos un canal de vdeo (el
mismo si estamos en cataln o castellano), y luego dos canales de audio y otros dos de
texto. As se consigue una independencia entre los datos y la presentacin, as como un
gran dinamismo en estas ltimas.
2.2.5. Conclusiones
Como ya hemos explicado el principal inters del modelo de Amsterdam estriba en el
intento de extender el modelo de Dexter para que contemple la complejidad de los tipos
multimedia, y muy en especial del problema del tiempo que stos conllevan.
Pg. 31
III - El modelo HDM
Captulo III
EL MODELO HDM
HDM (Hypertext Design Model) fue creado por los profesores Franca Garzotto y Paolo
Paolini del Politencnico di Milano y por Daniel Schwabe de la Pontificia Universidade
Catlica do Ro de Janeiro en 1991, en parte en el marco del proyecto de la Comunidad
Europea HYTEA. El objetivo es crear un modelo que sea de utilidad para realizar el
diseo de una aplicacin de hipertexto (o hipermedia).
Al desarrollar una aplicacin hipermedia se pueden identificar dos tipos principales de
trabajos: los globales, tales como definir las clases de elementos de informacin y
estructuras navegacionales de la aplicacin; por otro lado, los locales, tales como llenar
los contenidos de los nodos. Esto es similar a lo que ocurre en la ingeniera del software
tradicional al disear un sistema modular: por un lado estn las tareas de disear la
estructura y interconexiones entre mdulos, y por el otro, escribir el cdigo de los
mdulos en particular. A partir de ahora utilizaremos la siguiente terminologa:
authoring-in-the-large, para referirnos a la especificacin y diseo de los aspectos
globales, estructurales de la aplicacin, y authoring-in-the-small, para referirnos al
desarrollo del contenido de los nodos.
En este captulo, nos centraremos en el authoring-in-the-large, ya que como es evidente,
ste presenta caractersticas comunes en diferentes aplicaciones, mientras que el
authoring-in-the-small es especfico para cada rea de la aplicacin. De hecho, aunque
ambas estn siempre interrelacionadas, la segunda suele depender de las herramientas
que se utilicen, mientras que la primera es independiente.
El presente captulo est basado en los artculos [GAR93] y [GAR95].
3.1. Objetivos y motivaciones

Son varias las ventajas de hacer un diseo basado en un modelo. Vemos aqu un
resumen de ellas:
Mejora de la comunicacin: el modelo proporciona un lenguaje que permite
comunicar al analista y al usuario. Asimismo, tambin mejora la
comunicacin entre los distintos integrantes del equipo, a menudo formados
en campos muy diferentes y con un lenguaje muy diferente.
Reusabilidad: el hecho de tener representada la estructura, permite reutilizar
los esqueletos de esa estructura o sub-estructuras a la hora de desarrollar
nuevas aplicaciones.
Evitar inconsistencias estructurales: como consecuencia se obtendr una
navegacin predictible y consistente.
Pg. 32
III - El modelo HDM
Permite evaluar aplicaciones ya desarrolladas en base a su estructura: es lo

que los autores denominan evaluacin orientada al diseo.
Base para crear herramientas CASE que ayuden en el desarrollo.
Pg. 33
III - El modelo HDM
3.2. Primitivas
En esta metodologa tiene una base de terminologa ya utilizada en otras metodologas,
pero a su vez aade otra conjunto nuevo de trminos y conceptos.
La unidad bsica del modelo es la entidad. Una entidad es la ms pequea parte
autnoma de la informacin, es decir, que no necesita ninguna otra informacin para
tener un sentido total. Las entidades se agrupan en tipos de entidades. Una entidad es
una jerarqua de componentes, los cuales estn formados a su vez por unidades. El
concepto de unidad es similar al de nodo, mientras que un componente es un conjunto
de nodos que crean una unidad lgica.
Por ejemplo, pensemos en los cuadros de un pintor. Para cada cuadro hay varios nodos
(unidades). Cada cuadro, es decir, un conjunto de varios nodos, forma un componente.
A su vez, el conjunto de todos los componentes cuadros, y otro componente que muestre
la vida del pintor forma una entidad. Veamos grficamente la entidad del pintor Goya.
El conjunto de las entidades pintor, que tienen todas la misma estructura, es lo que
define el tipo de entidad.
Componente raz
(vida del pintor)
Entidad pintor
Goya
Componente
La Maja Desnuda
Unidades
Componente
La Maja Vestida
enlace estructural
enlace de componente
Las estructuras se interconectan por medio de enlaces. Hay tres tipos diferentes:
enlaces estructurales que conectan componentes de la misma entidad.
enlaces de componente (o de perspectiva), que conectan unidades dentro de
un componente.
enlaces de aplicacin, que conectan componentes y entidades de distinto
tipo. Por ejemplo imaginemos que tengamos un tipo de entidades que sea
Periodo histrico; as, habr una enlace entre la entidad Goya y la entidad
Siglos XVIII y XIX.
Pg. 34
III - El modelo HDM
Ntese que de estas primitivas, las hay que hacen referencia a la parte de in-the-large y
otras a la parte in-the-small. En concreto, las entidades y enlaces estructurales son inthe-large, mientras que las unidades, componentes y enlaces de componentes son in-thesmall.
Veamos con ms detalle todas estas primitivas, as como otras:
3.2.1. Entidades y tipos de entidades

Una entidad es una estructura (relativamente grande) de informacin que representa
algn objeto del mundo real en el dominio de la aplicacin. Por ejemplo, un pintor
(Goya), una ciudad (Palma), un ave (golondrina), ...
Las entidades se agrupan lgicamente en lo que llamamos tipos de entidades, que
corresponden a las clases de objetos del mundo real. Siguiendo los ejemplos anteriores,
los tipos de entidades seran pintor (que agrupa a todos los pintores), ciudad, ave.
Como es evidente, el concepto de entidad es diferente en HDM que en la terminologa
relacional. Por ejemplo, en HDM las entidades tienen complejas estructuras internas, ...
3.2.2. Componentes
Una entidad es una coleccin de componentes estructurados en forma de rbol
(jerrquicamente). Un componente es una abstraccin de un conjunto de unidades, que
son los contenedores de la informacin. Un componente dentro de la jerarqua de la
entidad, en general tiene un padre (excepto en el caso del componente raz), varios
hermanos, y un nmero de hijos (excepto en los componentes hoja -los ltimos de la
jerarqua-). Pero un componente slo puede existir como parte de una entidad, y no tiene
sentido por s mismo, es decir, no es autnomo. Por tal razn en el modelo HDM no se
permite que unas entidades sean componentes de otras entidades.
En cuanto a la jerarqua que estructura los componentes de una entidad, sta puede ser
segn muy diversos criterios semnticos. En particular, una de las ms utilizadas es la
de todo-parte.
3.2.3. Perspectivas
En HDM la nocin de tener diferentes presentaciones del mismo contenido se representa
mediante el concepto de perspectiva. Por ejemplo, una aplicacin multilinge, la misma
informacin se presenta de varias maneras diferentes (una en cada idioma). Pero esto,
lgicamente, no altera la estructura jerrquica de una entidad.
Las perspectivas son slo una construccin para organizar este tipo de informacin.
HDM deja a la libertad del usuario cundo y cmo debe utilizar perspectivas.
Pg. 35
III - El modelo HDM
3.2.4. Unidades
Una unidad es un conjunto de partes atmicas de informacin que se muestran
conjuntamente, como una unidad.
Una unidad corresponde a un componente asociado con una perspectiva especfica. Una
unidad se caracteriza por un nombre (su identificador) y un cuerpo. Los cuerpos de las
unidades son el lugar donde queda almacenada la informacin.
Por ejemplo, en la entidad que describimos anteriormente (Goya), el componente La
Maja Desnuda, puede tener las unidades Explicacin del cuadro (en castellano) y
Importancia en la obra del autor (en castellano), ambas asociadas a la perspectiva en
castellano, y por otro lado las asociadas a la perspectiva en cataln Explicacin del
cuadro (en cataln) y Importancia en la obra del autor (en cataln),
Vemos, por tanto, que el concepto de unidad es muy similar al concepto de hipertexto
tradicional de nodo.
Aunque los autores no lo recomiendan, diferentes unidades pueden compartir el mismo
cuerpo. Segn los autores, esto conlleva una desorientacin para el usuario, aunque por
otra parte, fomentara la reusabilidad.
3.2.4. Enlaces en general

Los enlaces en hipertexto tienen una doble funcin: por un lado representar las
relaciones entre elementos del dominio (entidades, componentes o unidades), y por otro,
una funcin de navegacin (representar los patrones navegacionales). A menudo, estas
dos funciones son consistentes entre s, aunque no siempre: puede ocurrir que las
relaciones de dominio no sean relevantes para la navegacin, o que un enlace
navegacional interesante no se tenga ningn contenido semntico.
Por tanto, la definicin de enlace debe reflejar ambas funciones. Para ello se identifican
tres tipos diferentes que estudiaremos a continuacin. stos son:
Enlaces de perspectiva o de componentes
Enlaces estructurales
Enlaces de aplicacin
3.2.5. Enlaces de perspectiva o de componentes

Interconectan unidades dentro del mismo componente. Por ejemplo, un enlace de este
tipo es el que conecta las unidades Explicacin del cuadro (en castellano) y
Importancia en la obra del autor (en castellano), dentro del componente La Maja
Desnuda, en la entidad Goya.
Pg. 36
III - El modelo HDM
Ntese que al cruzar un enlace de este tipo, el contexto sigue siendo el mismo.
Los enlaces de presentacin o de componente pueden ser de dos formas: enlaces de
ndice o enlaces de visita guiada.
3.2.6. Enlaces estructurales

Interconectan componentes dentro de la misma entidad. Navegacionalmente son algo
ms complejos que los de perspectiva, pero bastante simples. Hay varios tipos, como
por ejemplo: de un componente a su hermano, de un componente a su hijo o a su padre,
...
3.2.7. Enlaces de aplicacin y tipos de enlaces

Representan relaciones de dominio entre entidades o sus componentes. Estas relaciones
son las elegidas por el autor como navegacional y semnticamente relevantes.
Los enlaces de aplicacin se estructuran en tipos, llamados tipos de enlaces de
aplicacin, o ms brevemente, tipos de enlaces. El tipo viene definido por un nombre,
los tipos de entidades origen y destino, y por si es simtrico o no. Un tipo de enlace sera
el que unira el tipo de entidad Pintor con el tipo de entidad Periodo histrico, al
que podramos llamar Periodo del pintor.
Los enlaces de aplicacin pueden ser de dos tipos diferentes:
De esquema: pertenece a un determinado tipo de enlaces. Por ejemplo el que
se cit anteriormente entre las entidades Goya y Siglos XVIII y XIX, ya
que pertenece al tipo Periodo del pintor.
Genricos: no pertenece a ningn tipo de enlace. Son independientes de la
estructura, y por tanto menos estandarizados. Un ejemplo podra ser un enlace
entre Goya y otro pintor en el que influy posteriormente. Este enlace no
sigue un patrn, sino que el autor del hipertexto lo incluye para este caso
concreto.
3.2.8. Esquema HDM

Una especificacin de un hipertexto consta de una definicin de esquema y un conjunto
de definiciones de instancias. Un esquema especifica un conjunto de tipos de entidad y
tipos de enlace. Las instancias se introducen en el sistema slo si cumplen las
restricciones establecidas en el esquema.
El concepto de esquema en hipertexto es novedoso, pero ya ha sido ampliamente
utilizado en el campo de las bases de datos.
Pg. 37
III - El modelo HDM
Por ltimo, en una aplicacin tambin se puede distinguir entre dos conceptos:
La estructura, que es la organizacin de los contenidos de la aplicacin:
entidades, componentes, enlaces, ...
La dinmica (dynamics), que representa el comportamiento de la aplicacin.
Pg. 38
III - El modelo HDM
3.3. Evaluacin de una aplicacin usando HDM

Partiendo de este modelo, los profesores del Politecnico di Milano Franca Garzotto,
Luca Mainetti y Paolo Paolini proponen HDM como un mtodo ideal para evaluar
aplicaciones. Es lo que ellos denominan evaluacin orientada al diseo.
Las cuestiones que conviene analizar en una aplicacin hipermedia son:
Contenido: en funcin de los especialistas.
Estructura: la organizacin de los contenidos.
Presentacin: teniendo en cuenta los aspectos pasivos (visualizacin), ya sean
temporales o atemporales y los aspectos activos (interaccin).
Dinmica: cmo los usuarios interactan con el contenido y estructura.
Los criterios o cualidades a evaluar son:
Riqueza de contenidos y enlaces.
Facilidad con que el usuario capta las operaciones y accesibilidad de la
informacin.
Consistencia o regularidad.
Predictibilidad.
Auto-evidencia.
Legibilidad.
Reutilizacin.
Si la evaluacin se basa en un modelo de la aplicacin, sta resulta mucho ms fcil y
provechosa. El proceso consiste en realizar un modelo de la aplicacin utilizando HDM,
analizar los resultados buscando inconsistencias en la estructura y mecanismos de
navegacin.
En dicho artculo, los autores evalan una aplicacin de Microsoft, llamada Art
Gallery, un catlogo hipermedia en CD-ROM de la National Gallery de Londres. A
pesar de ser un producto comercial, los autores encontrarn no pocas inconsistencias.
Basan el anlisis en estos puntos:
Organizacin general: definicin de las entidades y componentes.
Navegacin de enlaces de perspectiva.
Pg. 39
III - El modelo HDM
Navegacin de enlaces estructurales.

Navegacin de enlaces de aplicacin de esquema.
Aplicacin in-the-small, es decir el anlisis de las unidades (nodos).
Ntese que los enlaces de aplicacin genricos, por su naturaleza son independientes de
la estructura, no estandarizados; por tanto no tiene sentido su anlisis, ya que el autor los
define con completa libertad.
Pg. 40
III - El modelo HDM
3.4. Conclusiones
HDM es ms que un intento de modelar la estructura del hipertexto-hipermedia, una
modelizacin de las estructuras de navegacin. Crear un modelo antes de desarrollar nos
ayudar a conseguir una navegacin ms consistente y rica. En HDM la estructura de
navegacin viene marcada por la estructura de datos.
Adems HDM puede resultar til tambin para estudiar aplicaciones ya desarrolladas,
con el fin de detectar errores en la estructura navegacional.
Sin embargo, nuestra experiencia nos ha demostrado que realizar un modelo siguiendo
las normas de HDM es extremadamente complicado cuando el nmero de entidades
involucradas crece. En particular, era imposible representar la estructura de MINTour
utilizando este modelo. Nosotros, por tanto, destacamos de esta propuesta la
importancia de modelizar antes de desarrollar y de la utilidad de un modelo a la hora de
analizar aplicaciones ya desarrolladas, si bien consideramos que HDM no es la
herramienta de modelado ms adecuada.
Pg. 41
IV - La metodologa RMM
Captulo IV
LA METODOLOGA RMM
La metodologa RMM (Relationship Management Methodology) ha sido ideada por
Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada para dominios con
estructuras regulares (es decir, con clases de objetos bien definidas, y con claras
relaciones entre esas clases). Por ejemplo, catlogos, front-ends de bases de datos
tradicionales. Segn sus autores, est orientada a problemas con datos voltiles, que
cambian con mucha frecuencia, ms que a entornos estticos.
En este captulo presentaremos en primer lugar la metodologa original, basada en
[ISA95], y en los sucesivos apartados, veremos tres opciones de mejora de la misma. El
primero es el basado en los llamados slices mnimos e hbridos y m-slices, adems de
una profundizacin en las etapas de la interfaz de usuario y construccin. En el segundo
veremos nuestras propuestas de nuevos patrones de navegacin como mejora al modelo.
4.1. La primera formulacin de la metodologa RMM

4.1.1. El modelo RMDM
La base de la metodologa es el modelo de datos RMDM (Relationship Management
Data Model), que se genera a partir de un diagrama entidad-relacin. Con l se
describir no slo la informacin referente a las clases de objetos, sino tambin a la
navegacin entre ellos.
As, hay definidas unas primitivas para modelar los dominios (clases de objetos) y otras
para el acceso a tales objetos. De entre las primeras, la ms tpica es la entidad. Como en
la teora relacional una entidad est compuesta por varios atributos. Adems, en RMDM
se incorpora una nueva primitiva muy importante denominada slice, que define
conjuntos de atributos de una entidad que se agrupan de forma lgica (volveremos a
hablar de ello).
Una entidad se representa mediante un recuadro y su nombre, mientras que un slice se
representa mediante a una figura similar a una gota de agua. Lo vemos a continuacin:
Pg. 42
nombre
Hotel
direccin
CP
fax
Entidad Hotel
telfono
email
...
Slice de la entidad Hotel
En cuanto a las primitivas de acceso, se definen tres tipos de acceso diferentes. Para ver
qu significa cada una veremos un ejemplo. Supongamos una entidad Hotel. Las
instancias de esta entidad se pueden visitar segn esos tres tipos de acceso:
ndice condicional (Conditional Index) : en una pantalla aparecer un ndice
alfabtico de los nombres de los hoteles, y pulsando sobre uno, iremos a ver
su informacin. Para ver los dems deberemos volver al ndice. En realidad el
ndice no es necesario que sea siempre una lista de las instancias como tal.
Por ejemplo un ndice para acceder a una entidad ciudad pudiera ser, por
ejemplo, un mapa, donde al pulsar sobre una ciudad, se visitase su
informacin.
Veamos cmo se representa:
Hotel
Visita guiada condicional (Conditional Guided Tour) : de la pantalla inicial se

nos enva al primer hotel, y de l se puede pasar al segundo, y as
sucesivamente, de forma que para llegar al ltimo hay que pasar por todos los
anteriores. Se permite volver a visitar al anterior hotel. En definitiva, es una
estructura de acceso secuencial.
sta es su representacin grfica:
Pg. 43
Hotel
Visita guiada indexada condicional (Conditional Indexed Guided Tour) : es

una solucin hbrida, donde tenemos un ndice para acceder puntualmente a
los elementos de la entidad, pero tambin se nos permite la navegacin
secuencial una vez seleccionado uno.
Y su representacin grfica es:
Hotel
Adems, tambin se define una primitiva de grupo (Grouping) mediante la cual se

representa un men. De una primitiva grupo colgarn tantas opciones como queremos
que haya en el men.
La primitiva de grupo, o a la que a veces tambin denominaremos de men, se
representa mediante un tringulo invertido
del que colgarn todas las opciones del men. Por ejemplo, veamos un men que
permite acceder a la entidad hotel de las tres maneras diferentes que antes hemos
estudiado:
Pg. 44
Hotel
Hotel
Hotel
Para terminar con esta Veamos una tabla resumen de todas las primitivas que hemos
visto:
Primitivas de datos
Entidad
Entidad
Atributo
Slice
Primitivas de acceso
atributo
ndice
Visita guiada
Visita guiada indexada
Grupo
Enlace
Pg. 45
4.1.2. Etapas de la metodologa

4.1.2.1. Etapa 0
Como toda metodologa debe comenzar con un estudio de factibilidad y un anlisis de
los requerimientos (tanto de la informacin como de la navegacin). Tambin debe
hacerse una seleccin del hardware y software que se necesitar.
Los autores no hacen ms referencias respecto de esta fase inicial, por lo que es
aplicable cualquier metodologa tpica de la ingeniera del software tradicional.
4.1.2.2. Etapa 1: Diseo Entidad-Relacin

En esta etapa se confecciona un diagrama entidad-relacin tpico, desglosando las
relaciones N:M en dos relaciones 1:N, como muestra el ejemplo:
Como vemos las relaciones se representan con el smbolo:
El objetivo de esta fase es explicitar todos los enlaces entre objetos. Ms tarde, las
relaciones darn lugar a la navegacin. As, una relacin especificar un camino en la
navegacin.
Veamos un ejemplo que despus continuaremos a lo largo de las siguientes fases. Se
trata de un sistema de los hoteles de una regin. Tenemos cinco entidades, que son:
Hotel, Ciudad, Servicio, Habitacin y Categora. En cuanto a las relaciones,
una ciudad tiene varios hoteles, mientras que un hotel slo pertenece a una ciudad
(relacin 1:N), un hotel tiene una categora, mientras que hay muchos hoteles de una
determinada categora (tambin relacin 1:N). Lo mismo ocurre entre hotel y sus
habitaciones (1:N) y por ltimo tenemos una relacin N:M entre hotel y servicio, ya que
un hotel tiene varios servicios y un servicio concreto se da en varios hoteles. Esta
relacin N:M, como explicamos antes la desglosaremos en dos relaciones 1:N.
Pg. 46
Ciudad
Categora
Hotel
Habitacin
Servicio
Dentro de esta fase habra tambin que especificar los atributos de cada entidad.
4.1.2.3. Etapa 2: Diseo de slices

Esta etapa consiste en dividir una entidad en fragmentos significativos y organizarlos en
la red de navegacin. Por ejemplo, toda la informacin de un hotel la podramos colocar
en una ventana con scroll o bien en varias diferentes. Esta divisin se hace segn la
semntica de los atributos. Por ejemplo podramos tener en un slice los datos generales
del hotel y en otro un vdeo que nos muestre tomas del hotel.
Cada slice agrupar uno o ms atributos de una entidad, de tipos muy diferentes. Cada
entidad tendr su head, o slice principal, que se marca con un asterisco y que es slice al
que, por defecto, se accede a travs de los mecanismos de navegacin.
Entre los diferentes slices estn los llamados enlaces estructurales, que nada tienen que
ver con las relaciones, ya que al atravesar un enlace estructural, no se produce ningn
cambio de contexto.
Veamos como podramos dividir la entidad hotel en slices. Para hacerlo no seguiremos
la notacin que los autores recomiendan ya que es muy engorrosa. Nosotros, no slo en
este ejemplo sino en todos los casos de estudio, utilizaremos una tabla donde se
especifican los slices de cada entidad y los atributos que corresponden a cada uno de
ellos.
General * (head)
Nombre
Direccin
Telfono
Fax
Mail
URL
Nmero de plantas
Ao construccin
Pg. 47
Nmero de habitaciones
Cmo llegar
Distancia a la playa
Distancia al aeropuerto
Distancia a la capital
Distancia a parada bus
Vdeo
Localizacin
Vdeo
Una vez determinados los slices hay que establecer los enlaces estructurales:
General
Localizacin
Vdeo
4.1.2.4. Etapa 3: Diseo navegacional

Como que cada relacin del diagrama entidad-relacin da lugar a un enlace de
navegacin, en esta fase sustituimos las relaciones por primitivas de acceso RMDM.
En general, preferiremos una visita guiada a un ndice cuando el nmero de instancias
sea pequeo (menor de 10) y no exista un campo ndice que pueda ayudar a los usuarios.
Por contra, si el nmero es grande, usaremos ndices. Las visitas guiadas indexadas son
un hbrido, usado frecuentemente cuando hay un ndice y se desea una navegacin entre
las instancias.
Adems en esta fase hay que elegir a qu slice se accede a travs de una primitiva de
acceso. Por defecto es el slice principal (head). En caso contrario, debe especificarse,
etiquetando el nombre de la estructura de acceso.
Por ltimo, en esta fase se establece una jerarqua de mens, utilizando la primitiva de
grupo o men. Como regla general, evitar grandes profundidades en la jerarqua, ya que
desorientan al usuario.
El resultado final de esta etapa es el diagrama RMDM.
Sigamos con nuestro ejemplo. Lo primero es decidir por qu primitiva de acceso
sustituimos cada una de las relaciones que nos han resultado en el diagrama entidadAntonio Navarrete Terrasa
Pg. 48
relacin de la primera etapa. En este caso hemos elegido un ndice en la relacin hotelservicio y categora-hotel, una visita guiada en la relacin hotel-habitacin y una visita
guiada indexada en la relacin ciudad-hotel.
Ciudad
Categora
Hotel
Habitacin
Servicio
Aunque siguiendo al pie de la letra se debera especificar un enlace de vuelta, si fuera

necesario, entre las entidades que tienen una primitiva de acceso -es decir que de un
hotel podamos ir a su categora directamente- nosotros consideramos que siempre este
enlace debe estar presente y por tanto no lo representamos en el diagrama, por
considerarlo redundante. As, al tener una estructura de acceso de categora a sus
hoteles, implcitamente queda representado un enlace entre hotel y su categora.
Para terminar con esta fase debemos introducir la jerarqua de mens en el diagrama,
utilizando la primitiva de grupo. En nuestro caso, consideramos que simplemente
tenemos un men principal donde podemos acceder a las ciudades o bien a las
categoras, para en ambos casos despus poder llegar a ver la informacin de los hoteles.
En el primer caso, desde el men se accede a un ndice de las categoras y en el segundo
a una visita guiada indexada de las ciudades. Se representa as:
Pg. 49
Categora
Ciudad
Hotel
Habitacin
Servicio
Y ste es el diagrama RMDM que nos especifica la navegacin de nuestro sistema.

Vemos como a lo largo de estas tres fases hemos determinado las pantallas que
necesitaremos (slices), y que luego el diseador grfico deber disear y hemos
determinado todos los enlaces navegacionales de nuestro sistema, que con esto queda
perfectamente modelado.
4.1.2.5. Etapas 4 a 7: Interfaz de usuario y construccin

Estas etapas se realizan a partir del diagrama RMDM. Slo se citan brevemente, ya que
el inters de la metodologa, as como el nuestro en particular, se centra en las tres
primeras etapas que nos conducen a obtener en modelo RMDM. Las siguientes ya no
son propias del anlisis, sino del diseo grfico y la programacin.
Etapa 4: Diseo de protocolos de conversin

En esta etapa se escriben unos protocolos por los cuales se transforma cada
elemento del RMDM en un objeto en la plataforma elegida.
Etapa 5: Diseo de la interfaz de usuario

Pg. 50
Diseo grfico de todas las pantallas correspondientes a cada uno de los slices
que hemos obtenido en la etapa 2.
Etapa 6: Diseo del comportamiento en tiempo de ejecucin

Se decide qu mecanismos se utilizarn para guardar la historia, hacer
backtrackings, permitir enlaces transversales,...
Etapa 7: Construccin y tests

Construccin de la aplicacin y pruebas, testeando cuidadosamente todos los
paths de la navegacin.
4.1.2.6. Relacin con las etapas tradicionales de la Ingeniera del Software

La divisin en siete fases de la metodologa nos lleva a planternos cul es la
equivalencia con las etapas tradicionales de una metodologa y que comentamos en el
captulo de introduccin. Recordemos que stas eran anlisis, diseo e implementacin
y pruebas.
Claramente corresponde al anlisis la primera etapa de anlisis entidad-relacin; de
hecho ya vimos que el modelo entidad-relacin es la herramienta tpica del anlisis. La
segunda fase, la podemos considerar a caballo entre anlisis y diseo, ya que cuenta con
una parte de anlisis de datos, pero tambin ya tiene en cuenta las pantallas de que
constar la interfaz de usuario. En cuanto a la tercera etapa, ya es claramente diseo.
Respecto de las ltimas fases, las de interfaz de usuario e construccin, es bastante claro
que las etapas cuarta a sexta perteneces tambin al diseo, mientras que la ltima es
obvio que se corresponde al cien por cien con lo que denominamos implementacin y
pruebas.
4.1.4. Conclusiones y discusin

Esta metodologa permite explicitar la navegacin al hacer el anlisis, con lo cual nos
permitir, en teora, obtener una navegacin ms estructurada y, por tanto, ms regular e
intuitiva. Lo hace de una forma sencilla, simplemente aadiendo unas primitivas a lo
que es un modelo entidad-relacin tradicional. Es de gran inters, bajo mi punto de
vista, el concepto de slice, que permite agrupar datos de una entidad en diferentes
pantallas, y es que, al estar hablando de diferentes medios, la informacin de una
entidad puede ser muy variada. Para dar una idea ms al respecto, podra ser interesante
que un vdeo sobre un hotel, mostrando sus interiores, aparezca en una pantalla diferente
de otro que muestre su piscina. Tambin es interesante la primitiva de grupo, que
permite explicitar la jerarqua de mens.
Pg. 51
Segn nuestro punto de vista RMM es de gran inters, ya que es el primer caso en el que
se crea una metodologa completa, con una definicin de fases, y no nicamente un
modelo de datos. Adems est basado en un modelo de datos relacional, lo cual se ajusta
perfectamente no slo a nuestros casos de estudio si no a la gran mayora de las
aplicaciones existentes.
Pero, a mi entender, los mecanismos de acceso a la informacin son excesivamente
simples. Pueden ser suficientes para un problema con pocas entidades, como el que los
autores incluyen en su artculo, donde slo tienen siete entidades, o el que nosotros
hemos utilizado como ejemplo, que contiene cinco.
Un importante problema es que no se permite hacer una consulta a partir de dos
entidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles est
relacionada con ciudad, N a 1, y sta a su vez con regin, tambin N a 1, no hay forma
de permitir ver todos los hoteles de una regin, sino es yendo de ciudad en ciudad y
despus, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que sera
necesario poder establecer un enlace navegacional no slo entre entidades relacionadas
directamente, sino tambin con las que estn relacionadas con ellas, y as sucesivamente
(evidentemente siempre que sean relaciones tambin N a 1).
An as, la navegacin tendra ms limitaciones. Y es que ya hemos visto que las
consultas han de ser tan simples como que dado una ciudad qu hoteles tiene, que
campings, que puertos y aeropuertos, etc. Pero, por ejemplo, sera imposible explicitar
una consulta del tipo qu hoteles de una cierta categora hay en una ciudad determinada.
Otro gran defecto es que en la explicacin de la primera etapa, que es el correspondiente
a la construccin del diagrama Entidad-Relacin, se nos dice que las relaciones N:M se
descompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologas
como, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad que
resulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artculo
y que trata de un sistema de cursos, en los que se reflejan los profesores, sus
publicaciones, ... En el artculo, los autores rompen la relacin N:M entre profesores y
cursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero se
olvidan de los datos que deben guardarse de la relacin original, como por ejemplo
cuntas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, con
una entidad en medio, no habra forma de saber los cursos que imparte cierto profesor, o
qu profesores imparten cierto curso ya que no estaran directamente relacionados.
Otro punto discutible es que los autores citan que esta metodologa es indicada slo para
problemas con datos que varen muy frecuentemente. Pero a pesar de eso no se refleja
de ninguna forma esa cmo se puede realizar tal modificacin de los datos. La realidad
es que no se refleja ningn tipo de proceso en esta metodologa, que se cie
estrictamente a la parte de datos. Se debera en prximos trabajos la conveniencia de
incluir la posibilidad de definir procesos sencillos tales como, por ejemplo, hacer una
reserva de una plaza de hotel. Mi idea es que la solucin pasara por crear una nueva
etapa que fuera de definicin de procesos, en la que se definieran mediante las tcnicas
tradicionales de DFDs (Diagramas de Flujo de Datos) y quizs tambin pseudo-cdigo o
diagramas de procesos. Ya que los procesos visualmente no son ms que pantallas, una
vez definidos stos, se podra crear una nueva primitiva que representara un proceso,
Pg. 52
con el fin de incluirse todos estos procesos en el modelo RMDM, preferentemente en la

navegacin estructural (interna a la entidad, junto a los slices) para reflejar cmo se
llega a ellos.
En todo caso, y ya que nuestros casos de estudio slo reflejan consultas a la
informacin, y no procesos de actualizacin no se profundizar en esta reflexin en el
marco de este proyecto final de carrera.
En el siguiente apartado veremos un estudio ms detallado de dos intentos de mejora de
la metodologa, dirigidos entre otros por uno de sus creadores, Toms Isakowitz,
mientras que en el tercer apartado del captulo veremos una propuesta propia de mejora
aadiendo una serie de nuevas estructuras navegacionales que nos pueden ser
especialmente tiles.
Pg. 53
4.2. Evoluciones de RMM

En este apartado presentamos una serie de mejoras que, a partir de [BAL96] e [ISO96]
se han intentado introducir en la metodologa. En primer lugar expondremos las que
tienen como objetivo mejorar la estructura de datos y navegacin. Posteriormente se
tratar sobre un estudio en mayor profundidad de las etapas de interfaz de usuario e
implementacin, que tan ligeramente fueron tratadas en la primera formulacin de
RMM.
4.2.1. Estructura de datos y navegacin

Aqu veremos dos intentos de mejora de las primeras etapas de la metodologa. En
ambos casos, se intenta suplir las carencias de RMM aadiendo nuevos tipos de slices,
con el fin de poder representar problemas ms complejos, que con la formulacin
original de RMM no era posible.
4.2.1.1. Slice mnimo y slice hbrido

En [BAL96], se presenta la aplicacin de la metodologa RMM a un caso prctico. Se
trata de una pequea aplicacin para la web, creada para la ACM, llamada LINKBase,
con la informacin hipertexto de eventos tales como conferencias, publicaciones,
escritores, organizaciones ... La aplicacin se desarroll para la web utilizando CGIs
(Common Gateway Interface), para acceder a la base de datos. Una CGI es un programa
que escribimos para que a partir de los datos que se recuperan de la base de datos, se
cree una pgina HTML dinmicamente, que es la que el usuario visualiza.
La conclusin ms importante de su trabajo fue la necesidad de extender el modelo
RMDM para hacerlo realmente utilizable. Su propuesta es la de aadir dos tipos nuevos
de slices:
El slice mnimo (minimal slice), que representa el conjunto de atributos de una entidad
que permite que el usuario pueda identificar claramente las diferentes instancias de tal
entidad. Este slice mnimo se utilizar como ancla a instancias concretas de una entidad.
Por ejemplo si accedemos a una entidad mediante una primitiva ndice, lo que deseamos
no es que el usuario vea la lista de los identificadores de los diferentes registros, ya que
muy probablemente esa informacin le sea del todo intil. Se utilizar el slice mnimo
para tal fin.
Los slices hbridos (hybrid slices) que permiten combinar atributos de diferentes
entidades y estructuras de acceso. En la definicin original de RMM, los slices estaban
formados nicamente por atributos de una misma entidad. Con este aadido se permite
que en una pantalla aparezcan informaciones de ms de una entidad. Por ejemplo si
accedemos de una autor a sus publicaciones, pudiera ser que estuviramos interesados
en mostrar en la misma pantalla la informacin de la editorial de cada publicacin (que
se encuentra en otra entidad).
Pg. 54
Con estos tipos de slices se consiguen unas estructuras ms dinmicas tanto de

navegacin como de organizacin de la pantalla.
4.2.1.2. Los m-slices

En [ISA96] se vuelven a analizar las carencias de la metodologa y a proponer nuevas
mejoras.
Segn los autores, tres son las principales limitaciones de la metodologa:
1. La imposibilidad de especificar qu informacin se debe mostrar como ancla,
es decir qu texto o imagen aparece como hiperenlace, por ejemplo en una
pgina web.
2. RMM slo permite agregar atributos de una nica entidad, es decir un slice no
puede contener atributos de varias entidades.
3. Por ltimo, no se permite que un slice contenga adems de atributos,
estructuras de acceso. Es decir, para llegar a una estructura de acceso (ndice o
visita guiada) uno debe de atravesar un enlace.
Lo que los autores proponen en el presente artculo es un nuevo tipo de slice, al que
denominan m-slice. Segn ellos la m viene de las muecas matrjeska, las tpicas
muecas rusas que se meten una dentro de la otra.
Por tanto, un m-slice es un nuevo tipo de slice que permite solventar los tres aspectos.
As un m-slice podr contener atributos de la entidad a la que pertenece, adems de otros
slices (m-slices posiblemente) formadas con atributos de otras entidades, unido todo ello
por primitivas de acceso.
Recordamos en la siguiente figura cmo segn la metodologa original se definen los
slices. Nota: Nosotros no hemos empleado esta notacin en nuestros casos de estudio
por ser muy engorrosa.
Slice HOTEL
nombr
direccin
CP
fax
telfono
email
...
Pg. 55
La estructura de los nuevos tipos de slices es la siguiente:
Hotel
Atributos la entidad hotel
Atributos la entidad habitacin

Habit.
4.2.1.3. Conclusiones
La introduccin de los slices mnimos e hbridos, se puede considerar como muy
provechosa, y ser ampliamente utilizada en los casos de estudio, ms en concreto en los
dos ltimos.
En cambio, los m-slices son de un provecho ms dudoso. Estudiando las tres
limitaciones que los autores apuntan, se puede cuestionar que la extensin cubra los
objetivos que pretende; la contrario, parece que introduce ms problemas que resuelve,
como veremos a continuacin:
1. En cuanto a la imposibilidad de especificar qu informacin se debe mostrar
como ancla, es cierta en la definicin inicial de RMM, pero se puede utilizar
el slice mnimo, cuya definicin vimos en el anterior artculo, para tal efecto.
As, tenemos que en cada entidad habr que definir el slice mnimo y ste, al
ser la menor parte de informacin que permite identificar al usuario a tal
objeto, ser el que se utilice como ancla.
2. Referente a la imposibilidad de agrupar atributos de varias entidades en un
slice, ya vimos tambin en el artculo anterior que la cuestin qued resuelta
con la definicin de los slices hbridos, que veremos en el siguiente apartado
como sern de gran utilidad.
3. Y llegamos al punto clave. Es cierto que en RMM no se permite englobar en
un slice, adems de los atributos, estructuras de acceso. Pero el hacerlo es un
gran error. La segunda fase de la metodologa tiene por objeto el identificar
Pg. 56
las partes de cada entidad que aparecen diferenciadas entre s. En la tercera

etapa, y a partir del diagrama entidad-relacin de la primera, obtenemos las
estructuras de acceso entre las entidades. Y lo que no olvidemos es que el
modelo se fundamenta en que la estructura de la navegacin se basar en la
estructura de los datos. Lo que aqu se propone sera hacer la estructura de la
navegacin no en base a las entidades sino a los slices, es decir a conjuntos de
atributos.
La idea de los autores suponemos que es el intentar representar que si estamos
en una pantalla correspondiente a la entidad Hotel y deseamos ver la
informacin de, por ejemplo sus habitaciones, esto se pueda hacer dentro de
la misma pantalla, definiendo un m-slice que contenga los atributos
correspondientes de ambas entidades, as como la estructura de acceso, por
ejemplo un ndice. Pero este caso es propio de la presentacin, es decir de las
etapa de diseo de la interfaz (etapa 5) y no de la estructura de la aplicacin.
Si el diseador, a partir del modelo RMDM ve que hay una navegacin entre
un hotel y sus habitaciones, puede ah definir que desea que el slice
correspondiente de la entidad hotel y el correspondiente de la entidad
habitacin aparezcan en la misma pantalla. Lo que no tiene sentido es hacer
esto en la etapa de anlisis.
As pues, los m-slices, por lo menos en su formulacin actual, no sern pues utilizados
en los casos de estudio que realizamos a continuacin.
4.2.2. Las etapas de interfaz de usuario

Asimismo en [BAL96] se profundiza en las fases de la metodologa posteriores a la de
diseo navegacional. Son las que se denominan de interfaz de usuario y construccin y
sobre las cuales en la descripcin original de la metodologa slo se daba una muy breve
gua.
Mientras que las tres primeras etapas cubren el diseo lgico de una aplicacin, estas se
corresponden con el diseo fsico.
4.2.2.1. Etapa 4: Diseo de protocolos de conversin

Recordemos que el objetivo de esta fase era el de transformar cada elemento del modelo
RMDM en un objeto en la plataforma elegida.
Lo que se debe hacer es producir una serie de reglas, ya sea mediante un programa
automtico de conversin o como una serie de instrucciones a los programadores, que
permitan convertir las entidades, atributos y estructuras de acceso.
En este caso de estudio, en el que hay una base de datos conectado al servidor web, las
entidades se convierten en tablas de la base de datos y los atributos en columnas de esas
tablas. En cuanto a las estructuras de acceso, los ndices se convierten en resultados de
consultas a la base de datos (son variables segn el contenido de la misma).
Pg. 57
4.2.2.2. Etapa 5: Diseo de la interfaz de usuario

Esta etapa hace referencia al diseo de cada una de las pantallas de la aplicacin.
Siguiendo la metodologa, tendremos una pantalla para cada uno de los objetos del
modelo RMDM. En concreto hay cuatro aspectos importantes sobre los que se centra:
la informacin de los slices encontrados en la segunda fase de la metodologa
las estructuras de acceso que identificamos en la tercera fase
herramientas de navegacin, como backtracking y similares
apariencia de los anclas, cmo han de aparecer los ndices y dnde deben situarse
las citadas herramientas de navegacin
Generalmente esta etapa se presta al prototipado, ya sea sobre papel (lo que los autores
denominan prototipos low-fidelity) o por ordenador (prototipos high-fidelity).
Recurdese que LINKBase, la aplicacin que trata como ejemplo en este artculo, est
basada en pginas web. Si bien la aplicacin final, como ya explicamos recupera los
datos de una base de datos, para esta fase es ideal hacer el diseo de todas las pginas
HTML. As, se crearn todas las pginas correspondientes a cada slice de cada entidad y
cada ndice, en HTML, con datos estticos. Esto nos ser de gran ayuda para el
prototipado y por tanto para que el cliente pueda ver cul ser el aspecto de la
aplicacin.
Como ya citamos en los cuatro puntos a tener en cuenta, un aspecto muy importante que
tambin hay que decidir es la representacin de los anclas de los enlaces. Puede ser una
buena solucin el identificar cada una de las entidades mediante un icono. As, si
estamos en la pantalla correspondiente a un escritor, tendremos un icono que represente
la entidad publicacin y que al pulsar en l nos enve al correspondiente ndice de
publicaciones de dicho escritor (o a la primera pantalla de la correspondiente visita
guiada si ste fuera el mtodo de acceso). No obstante en la aplicacin del LINKBase
los autores decidieron no utilizar elementos iconogrficos sino slo referencias textuales
para identificar los enlaces.
Otro aspecto a resaltar es la conveniencia de diferenciar los enlaces estructurales
(internos a una entidad: enlaces entre slices) y los enlaces entre diferentes entidades.
4.2.2.3. Etapa 6: Diseo del comportamiento en tiempo de ejecucin

En esta etapa hay que disear los algoritmos para los programas que generarn y
recuperarn la informacin de nuestra aplicacin, as como el control de la historia de
navegacin (backtracking), y otros mecanismos.
Pg. 58
En el caso de LINKBase, en esta fase hay que especificar el algoritmo para cada una de
las CGIs de la aplicacin (tanto para acceder a la base de datos como para el control de
los dems mecanismos), mientras que ser en la fase siguiente en la que se programe la
CGI en s.
4.2.2.4. Etapa 7: Construccin y tests

En esta fase se construye definitivamente la aplicacin, en base a la informacin
generada en todas las etapas anteriores. Se construye la base de datos fsica a partir del
modelo entidad-relacin de la etapa 1 y de los protocolos de conversin de la fase 4. Y
tambin se programan todos los algoritmos diseados en la etapa anterior. Como puede
apreciarse las dos ltimas etapas estn muy ligadas, y nosotros consideramos que
perfectamente se podran haber considerado como una nica.
Para acabar hay que testear la aplicacin, lo que conlleva comprobar todos los enlaces
posibles.
4.2.2.5. Conclusiones
Se han tratado las fases de la metodologa sobre las que apenas se haba hablado en la
primera formulacin de RMM. El aspecto ms destacado de este nuevo estudio, es bajo
nuestro punto de vista la etapa del diseo de la interfaz de usuario, donde se comentan
los aspectos ms importantes que se deben considerar durante esta fase.
Visto esto, consideramos que hay una organizacin de la pantalla que es especialmente
coherente con la estructura, y que, adems de ser clara, puede resultar muy til en todo
tipo de aplicaciones hipermedia. Posiblemente los autores no la tuvieron en cuenta,
quizs porque los navegadores de aquel entonces an no tenan soporte para ello. Se
trata del uso de marcos (frames) de HTML (aunque tambin se pueden utilizar tablas
con el mismo objetivo). As, podramos tener un marco principal la informacin del
objeto seleccionado. Y adems tres marcos ms, con otros colores para diferenciarlos, y
dispuestos como el diseador lo estime oportuno que contendran los elementos
navegacionales, respectivamente:
Enlaces a otras entidades
Enlaces a otros slices
Herramientas navegacionales (backtracking y otros)
De esta manera se obtiene una interfaz simple y significativa, til para la navegacin en
muchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo de
plataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de la
pantalla en varias reas.
Pg. 59
4.3. Mejoras en estructuras navegacionales para RMM

Como hemos visto en los apartados anteriores, RMM resulta un muy interesante intento
de establecer una metodologa para el desarrollo de aplicaciones multimedia, y que est
especialmente indicada para aplicaciones basadas en bases de datos relacionales. No
obstante, presenta una serie de carencias en las formas de navegacin, a pesar de los
intentos de mejoras que hemos analizado en los dos apartados anteriores, basados en la
introduccin de nuevos tipos de slices. El hecho es que en el modelo RMDM slo se
permite navegar entre entidades que estn directamente relacionadas.
Para mejorar la metodologa es fundamental encontrar nuevos patrones, nuevas formas
de navegar, nuevas primitivas de acceso que nos ayuden a identificar enlaces
navegacionales de una forma estructurada y regular.
A continuacin se exponen tres casos concretos que darn origen a tres nuevas formas
de acceso a la informacin y que harn de RMDM un modelo ms til, y que dar
origen a una navegacin ms rica.
4.3.1. Caso A: accesos jerrquicos

Este primer caso es el que se da cuando tenemos varias relaciones 1:N encadenadas. La
idea es permitir acceder jerrquicamente, es decir de una cualquier punto de la cadena
hacia abajo, con cualquiera de las primitivas de acceso.
Veamos un ejemplo que muestre la necesidad de este caso:
Nacin
Regin
Provincia
Ciudad
Camping
Aqu slo podemos navegar por los campings de una ciudad. Pero si cuando estamos
visualizando la informacin de una provincia, regin o nacin quisiramos acceder a sus
campings, slo podramos hacerlo consultando los campings de cada ciudad una a una,
pero sera imposible ver una lista con todos los de la provincia, regin o nacin.
Pg. 60
Por tanto, es imprescindible permitir acceder a los campings que hay en una provincia,
regin o nacin, directamente. En general, siempre que tengamos un encadenamiento de
relaciones 1:N, se debe permitir bajar a travs de la cadena.
Siguiendo con el mismo ejemplo, tambin es interesante poder acceder desde una
nacin a las ciudades sin pasar por las regiones o provincias. Tngase en cuenta que a
menudo se conoce la ciudad pero no a qu provincia pertenece. Adems, el poder
acceder directamente es de una importancia mayor en una aplicacin sobre Internet, ya
que todo lo que sea reducir el tiempo de conexin es reducir el coste para el usuario.
La solucin a este caso est en crear una nuevo tipo de acceso que permita inferir las
relaciones jerrquicas. Lo vemos en el siguiente diagrama, donde las lneas que aparecen
discontinuas indican que hay el enlace navegacional no parte directamente de una
relacin, sino que de una inferencia.
Nacin
Regin
Provincia
Ciudad
Camping
El siguiente ejemplo demuestra que esto no es slo aplicable dentro de la aplicacin

MINTour, sino que es un patrn general.
Pg. 61
Carrera
Asignatura
Profesor
Se observa aqu como tambin puede resultar interesante acceder a los profesores que
dan clases en una cierta carrera, sin necesidad de ir asignatura a asignatura. Veamos el
diagrama resultante:
Carrera
Asignatura
Profesor
4.3.2. Caso B: acceos en relaciones N:M

Un fallo que se puede encontrar en la especificacin de la etapa S1, diseo del diagrama
entidad-relacin, es el obligar a separar las relaciones N:M, directamente en dos
relaciones 1:N.
Pg. 62
Profesor
Asignatura
Profesor
Asignatura
En otras metodologas como, por ejemplo, SSADM, ya se hace algo similar, pero lo que
no se puede hacer es obviar la entidad que resulta en medio. En el artculo, los autores
rompen la relacin N:M entre profesores y cursos, creando dos relaciones nuevas, 1:N
de profesores a cursos y viceversa. Pero se olvidan de los datos que deben guardarse de
la relacin original, como por ejemplo podra ser cuntas horas imparte el profesor de
esa asignatura. Y no lo hacen porque entonces, con una entidad en medio, aplicando
RMM a raja tabla, no habra forma de saber los cursos que imparte cierto profesor, o
Veamos dos ejemplos ms, pero ya teniendo en cuenta que es necesaria una entidad
intermedia en la relacin:
Tipo de
camarote
Barco
Barco/
Camarote
Este ejemplo est extrado de MINTour. La entidad barco/camarote es la resultante de

la relacin N:M entre barco y tipo de camarote. Esta entidad es necesaria ya que hay
que guardar en ella los datos de la relacin, como por ejemplo, el precio.
Pero cuando estamos visualizando la informacin de un barco, lo que queremos es
acceder directamente a la informacin de los tipos de camarote que dicho barco tiene,
con el fin de elegir en cul viajaremos. Pero no queremos quedarnos en slo en la
entidad barco/camarote, donde slo tenemos los cdigos de barco y tipo de camarote y
el precio.
En general, en toda relacin N:M, aunque haya una entidad en medio, debe permitirse el
acceso de un extremo a otro de la relacin, aunque mostrando de alguna manera los
datos de la entidad intermedia.
Pg. 63
Para reflejarlo, crearemos una nueva primitiva de acceso que permita acceder de una
entidad a otra (ya sea con un ndice, una visita guiada o una visita guiada indexada),
pero teniendo en cuenta la intermedia. Para reflejarlo, simplemente, unimos la primitiva
de acceso seleccionada con la entidad intermedia.
Lo vemos en la figura:
Barco/Camarote
Tipo de
camarote
Barco
Barco/Camarote
La nueva primitiva de acceso indica que realmente s se accede mediante un ndice de

un extremo al otro de la relacin N:M, pero que se tiene en cuenta la entidad
Barco/Camarote en ese acceso. La manera en que es tenida en cuenta esa entidad es en
que no se accede al slice head, si no que se hace a un slice hbrido (al que, por defecto,
llamaremos igual que la entidad intermedia) donde hay atributos de ambas entidades.
El siguiente ejemplo, que ya no tiene que ver con MINTour, tambin es muy claro:
Alumno
Asignatura
Alumno/
Asignatura
Aqu tenemos un caso como el anterior, donde en la entidad alumno/asignatura se

deben guardar cosas como nmero de convocatoria, nota final, fecha de
matriculacin, etc. As, hay que, como antes, permitir el acceso de extremo a extremo.
El resultado es el siguiente diagrama:
Pg. 64
Alumno/Asignatura
Alumno
Asignatura
Alumno/Asignatura
Pero hay que notar que lo normal es que la entidad alumno/asignatura tome el nombre
de matrcula. Esto hace que, a la vista de un diagrama entidad relacin no siempre sea
fcil identificar las entidades provenientes de relaciones N:M, ya que si bien el primer
nombre lo indicaba con claridad, el segundo no.
Por tanto, lo que hay que hacer es buscar patrones de la forma:
y decidir despus si es necesaria la navegacin directa entre las entidades A y B; muchas

veces lo ser, aunque tambin muchas no.
4.3.3. Caso C: accesos mltiples

Este tercer caso es ciertamente ms complejo, tanto en la identificacin del patrn,
como en la introduccin en la metodologa, y se presta a una profunda discusin.
Hay relaciones que implican una pertenencia de una entidad a otra. Por ejemplo:
Provincia
Ciudad
Hotel
Categora
Aqu vemos dos relaciones del tipo parte de, es decir, que una ciudad forma parte de
una provincia, y que un hotel forma parte de una ciudad.
Pg. 65
Vemos que la relacin entre categora y hotel, en general, no tiene sentido que sea
navegable, pues suele ser poco til acceder a todos los hoteles de Europa de una
determinada categora. Pero s lo sera si no se cogen todos los hoteles de Europa sino
slo un subconjunto de ellos, como por ejemplo los que pertenecen a una ciudad o
provincia.
Esto, que a nivel de entidades no parece complejo (lo ms difcil ser identificar las
relaciones de tipo parte de), parece serlo ms a la hora de implementar la navegacin.
En el ejemplo, estaremos visualizando la informacin de una categora, y para acceder a
los hoteles tenemos que seleccionar una ciudad o provincia. Una vez seleccionada sta,
se mostrarn los hoteles de esa ciudad y esa categora.
Para ello hay que crear una nuevo grupo de primitivas de acceso que permitirn un
acceso mltiple, ya sea mediante un ndice, una visita guiada o una visita guiada
indexada.
Las nuevas primitivas son:
Visita guiada mltiple
ndice mltiple
Visita guiada indexada mltiple
Y la forma en que se representa un enlace mltiple:
Pg. 66
donde navegamos utilizando un ndice desde la entidad A hasta la entidad B pero

seleccionando un elemento de la entidad C.
Veamos cmo se aplica esto a nuestro ejemplo del hotel, la categora y la ciudad:
Provincia
Ciudad
Hotel
Categora
Hemos utilizado la primitiva ndice mltiple que permite navegar, en este caso concreto,
desde categora hasta hotel, pero tomando una ciudad, es decir, que al elegir una
categora se podr seleccionar una ciudad y ver los hoteles de esa categora en esa
ciudad.
Evidentemente a este diagrama tambin le podramos aplicar lo que vimos en el primer
caso, y permitir ver no slo los hoteles de cierta categora de una ciudad, sino tambin
los de una provincia. El resultado sera el siguiente diagrama:
Provincia
Ciudad
Hotel
Categora
No obstante, un anlisis tras la aplicacin a casos prcticos nos revela que la estructura
de relaciones que dar lugar a una primitiva de acceso mltiple, es similar a la de una
relacin N:M. Por ejemplo, en el caso anterior, uno podra haber supuesto que la entidad
hotel era el resultado de la relacin N:M entre Ciudad y Categora. No estara exento de
razn y de hecho, la entidad hotel necesita almacenar el cdigo de la categora y el
cdigo de la ciudad. Sin embargo, esta entidad tiene una gran importancia semntica por
Pg. 67
s misma, y en el proyecto MINTour es una de las ms importantes, sin duda mucho ms

que categora.
Adems el estudio en casos prcticos nos depar que en ciertas ocasiones tambin son
interesantes estas primitivas de acceso mltiples en situaciones en las que la estructura
todo-parte no se da. Veamos dos ejemplos:
El primero est extrado del Atles de les Illes Balears. En l, tenemos que cada parte de
la informacin fundamental del atlas es el cruce entre un tema y el rea geogrfica. Por
ejemplo, un punto de informacin ser Carreteras Secundarias en Menorca, otro
Carreteras Secundarias en Mallorca, ... En este caso, no est claro de que lo que
tengamos sea una estructura todo-parte o una relacin N:M, pero lo que est claro es que
lo que se desea es que elegido un tema (la navegacin temtica es la principal del atlas),
se elija el rea geogrfica sobre la que se desea la informacin.
Tema
Informacin
Tema
rea
Geogrfica
rea
Geogrfica
Informacin
Veamos otro ejemplo, extrado de MINTour. En este caso, tenemos que lo que se desea
es que, seleccionado un vuelo, ver lo que puede costar. Pero ese precio depende de la
tarifa que deseemos. Por tanto lo que nos interesa es seleccionar esa tarifa antes de ver el
precio. Sin duda este es el resultado de la relacin N:M entre Vuelo y Tipo Tarifa Area,
y muy difcilmente se puede observar una relacin todo-parte, pero la nica manera de
reflejar la navegacin que deseamos es mediante accesos mltiples.
Vuelo
Vuelo
Precio
Vuelo
Tipo Tarifa
Area
Tipo Tarifa
Area
Precio
Vuelo
Pg. 68
La conclusin a la que llegamos despus de stos y toda una serie de casos que se nos
han presentado es que los accesos mltiples no son nicamente el resultado de una
estructura todo-parte, sino ms bien de una relacin N:M (ms o menos encubierta,
segn el caso). Por tanto, no estamos ante un patrn de relaciones diferente al que vimos
en el anterior apartado, sino que ante una navegacin diferente dentro de esa estructura,
determinada por la semntica del caso concreto.
Por tanto ser el diseador quien deba decidir en cada caso qu tipo de acceso le interesa
ms en cada caso: si el que vimos en el apartado anterior, ste o, simplemente, el natural
que se refleja en RMM (navegando a la entidad intermedia). En concreto, en lo que hace
referencia a las estructuras todo-parte, podemos apreciar que prcticamente la solucin
idnea es la de los accesos mltiples, ya que lo que nos permitir es reducir el nmero
de los elementos, filtrar, a los que vamos a navegar.
4.3.4. Conclusiones
En este apartado hemos estudiado tres nuevos mtodos de acceso que a continuacin
resumimos:
navegacin jerrquica: al tener varias relaciones 1:N encadenadas, se permite
navegar desde cualquier entidad a otra que est por debajo de ella en la jerarqua.
Estos enlaces inferidos, no extrados directamente de una relacin 1:N, se
representarn con trazo discontinuo.
navegacin en relaciones N:M: se permite navegar de un extremo al otro de la
relacin, pero teniendo en cuenta la entidad intermedia, cuyos atributos debern
incluirse en un slice hbrido. Para representar un enlace de este tipo, uniremos la
primitiva de acceso (ndice, visita guiada, ...) con la entidad intermedia.
navegacin mltiple: se crean unas nuevas primitivas que permiten el acceso
mltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de
la que la entidad destino es parte. En el enlace quedar especificado qu entidad es la
origen, cul la destino y cul la tercera. Recordar que esta navegacin es
especialmente apropiada en estructuras todo-parte.
Despus de todo esto, la lista de las primitivas de acceso queda reflejada en la siguiente
tabla:
Hiperenlace
Hiperenlace jerrquico inferido
ndice
Visita guiada
Pg. 69

ndice mltiple
Entidad Rel. N:M
Ejemplo de acceso a partir de una relacin

N:M, en este caso utilizando un ndice
(podra ser cualquier otra primitiva de
acceso simple)
Pg. 70
V - CD-ROM de SAlbufera
Captulo V
1er CASO: CD-ROM DEL Parc Natural de Salbufera
En este captulo vamos a realizar un anlisis y evaluacin detallado de la organizacin
de la informacin y navegacin del CD-ROM del Parc Natural de SAlbufera, [UIB95].
Veremos como en producto que ha recibido varios premios de diseo y navegacin, se
llegan a perder interesantes posibilidades al no sacar todo el jugo posible a la
informacin de la que se dispone. Veremos como el uso de una metodologa ayuda a
detectar un mayor nmero de posibilidades navegacionales.
Para ello, utilizaremos la metodologa RMM para, por un lado modelar el sistema tal y
como se present, y por el otro, partiendo desde la primera fase, intentar detectar todas
esas posibles estructuras navegacionales.
El objetivo de este caso de estudio ser hacer un modelo de la aplicacin y compararlo
con un nuevo modelo, confeccionado desde cero, sin tener en cuenta cmo sta fue
estructurada. Para ello lo que haremos es comparar ambos modelos RMDM. No es
necesario analizar las posteriores fases de la metodologa, ya que aqu slo nos interesa
la estructura y enlaces navegacionales, y no la interfaz grfica.
En el primer apartado de este captulo se explicar qu es el CD-ROM del Parc Natural
de SAlbufera, y cmo est estructurado. En el segundo apartado se hace el modelado de
la aplicacin existente. Debido a que aqu ya tenemos presentes la estructura de mens y
los enlaces navegacionales, no es necesario seguir las dos primeras etapas de la
metodologa, y comenzaremos el estudio con el diseo navegacional (tercera etapa de
RMM). Por contra, en el tercer apartado s que haremos el anlisis desde cero, buscando
cules son las entidades y relaciones que intervienen en el problema y haciendo el
diseo de los slices. A partir de estas dos fases se confeccionar un nuevo modelo
RMDM que difiere en varios aspectos del obtenido en el apartado anterior a partir de la
aplicacin actual. Las diferencias entre ambos son tratadas en el captulo de
conclusiones.
5.1. Qu es el CD-ROM de Parc Natural de SAlbufera

5.1.1. Introduccin
El CD-ROM del Parc Natural de SAlbufera surge gracias a la colaboracin de tres
instituciones de las Islas Baleares. stas son la Conselleria de Cultura, Educaci i
Esports del Govern Balear, La Caixa de Balears Sa Nostra - en el marco de su
Proyecto Natura - y la Universitat de les Illes Balears, y ms concretamente su
Departament de Cincies Matemtiques i Informtica.
El CD-ROM se hizo llegar gratuitamente a todos los institutos de secundaria de las islas,
para que sus estudiantes puedan adentrarse en las excelencias naturales del Parque
Natural de S'Albufera. Pretende ser un complemento a la visita de campo que realizan
los escolares al parque, bien para ser utilizado previamente a la visita como herramienta
Pg. 71
de preparacin de dicha visita, bien para utilizarse posteriormente a la visita y permita

ampliar y complementar los conocimientos adquiridos durante la visita.
El proyecto fue llevado a cabo en 1995, y un hecho que aqu es de relevancia, referente a
su implementacin, es el de que no se utiliz ningn tipo de metodologa o modelo
durante su desarrollo.
5.1.2. Estructura de la aplicacin

Para situarnos, es conveniente ver las diferentes partes en que se estructur el CD-ROM.
Informacin general sobre S'Albufera
En este punto se ofrecen una serie de informaciones de inters general sobre el
parque. Consta de las partes siguientes:
- Informacin general: Incluye datos sobre su extensin, su descripcin
administrativa, horarios de funcionamiento, direccin y telfono.
- Rincones del Parque. A partir de un mapa del parque se ilustran fotografas de
algunos de los rincones ms significativos del parque acompaadas de una
pequea resea sobre cada uno de ellos.
- Consejos para su visita. En forma de animaciones 2D de nuestra mascota se dan
al visitante doce tiles consejos para facilitarle la visita.
- Importancia biolgica. Se explica la importancia que tiene el Parque Natural de
S'Albufera dentro de la red de espacios hmedos de las rutas que utilizan las aves
migratorias, as como su declaracin de reserva biolgica.
- El Parque por estaciones. A partir de la fotografa de un mismo lugar del parque
en las distintas estaciones del ao, se explican las diferencias de color, sonido,
vida animal o vegetal, etc. que ofrece el parque segn la poca del ao.
- Un Parque para la ciencia. Que incluye dos apartados:
- Proyectos cientficos. Muestra los principales proyectos de investigacin
cientfica que se llevan a cabo en el parque por parte del Institut de d'Estudis
Avanats de les Illes Balears, la UIB y Earthwatch Europe.
- Anillado de aves. Explica las tareas de anillado de aves migratorias que se llevan
a cabo anualmente en el parque.
El hombre y S'Albufera
En este punto se ofrece una visin de la interaccin que ha tenido el hombre con
SAlbufera a lo largo de la historia. Consta de las partes siguientes:
- La historia del parque. A travs de un juego muy sencillo se resean los hitos
ms importantes de la historia del parque desde la poca de dominacin romana
hasta nuestros das. Concretamente se incide en el uso y aspecto del parque
durante distintas etapas: Romanos; Arabes; La Marjal; Real Patrimonio; Proyectos
de desecado; Explotacin arrocera; Fbrica de papel; Salinas; Segregacin
urbanstica; Conferencia MAR; Campaa de concienciacin; Central del Murterar;
Compra de los terrenos; Declaracin de Parque Natural; Lista RAMSAR.
Pg. 72
- Usos. Combinando texto, vdeo , grficos y fotografas se ensea el uso que ha

hecho de SAlbufera el hombre. Recoge: Caza, pesca, agricultura, uso de
vegetales, agua, salinas y turismo.
- Cancionero popular. S'Albufera, y las actividades que en ella se han llevado a
cabo, est presente en la tradicin de los pueblos de Alcudia, Muro y Sa Pobla.
Esto se refleja en canciones populares como las que se escuchan en el CD-ROM.
Por una parte sa can des plantar arrs y por otra una glosa de SAlbufera.
- Gastronoma. La influencia de SAlbufera en la cocina tradicional de la comarca
es muy clara. Se utilizan ingrediente exclusivos de la zona como las anguilas o el
arroz bomba . En este apartado se repasa un poco esta relacin de la zona con la
cocina y se incluyen las recetas de la espinagada y del aguiat d'anguiles.
Itinerarios
Se muestran tres niveles de detalle diferentes. Desde un plano general del parque
hasta un plano de la zona de sa Roca. Para cada uno de los tres planos se marcan
recorridos para la visita. En estos recorridos aparecen puntos de inters de los que
podemos ver bien una fotografa o un vdeo panormico.
Fauna
La fauna y la flora son la base de un parque. Aparecen en este punto los animales
del parque, tanto los que pueden observarse a simple vista como los difcilmente
localizables. Se ha hecho una seleccin que incluye: 132 aves, 7 mamferos, 2
anfibios, 3 reptiles, 7 peces y 16 invertebrados. De cada especie hay una ficha que
incluye: nombre comn en cataln y castellano, nombre cientfico, forma de
identificacin, situacin en el parque y donde puede observarse en el Parque. Se
incluye tambin una fotografa, sonido para aves y anfibios, y un calendario con la
abundancia relativa de cada ave en el parque. Las aves pueden consultarse
alfabticamente, o por familias. Se incluye la definicin de cada una de las
familias.
Flora
El herbario oficial del parque consta de ms de 650 plantas censadas. Se ha hecho
una seleccin de 52 especies que representan la diversidad de hbitats del parque.
Para cada especie se tiene una ficha tcnica, que incluye nombre comn en cataln
y castellano, nombre cientfico, forma de identificacin, situacin en el parque y
donde puede observarse en el Parque. Para cada planta hay un calendario con la
poca de floracin. Puede hacerse una seleccin alfabtica a partir de su nombre
cientfico o por hbitats.
Informacin para los educadores
Informacin destinada especficamente a los educadores. Incluye los itinerarios
didcticos creados por los monitores del Parque. Es la documentacin que se
entrega, junto con otro material didctico, a los profesores para preparar la visita
de sus alumnos. Incluye: objetivos, destinatarios, metodologa, bloques de
contenido (paisaje, medio fsico, seres vivos, cambios y paisajes histricos, el
Pg. 73
Parque Natural de SAlbufera), temporalizacin y recursos disponibles. El texto

aparece combinado con fotografas y vdeo de visitas de escolares con los
monitores del parque.
Gestin del Parque Natural
El funcionamiento del Parque Natural de SAlbufera lo rige un documento: Pla
d's i Gesti del Parc. Se resean sus lneas bsicas:
- Introduccin.
- Funciones bsicas del Pla d's i Gesti.
- La gestin de biotopos.
- Uso pblico.
Todo ello acompaado de fotografas.
Otros parques
Adems de diferenciar un parque nacional de un parque natural, incluye dos
opciones. Por una parte nos sita sobre un mapa todos los parques nacionales
espaoles y por otra ofrece informacin sobre los parques de las Baleares.
Concretamente sobre el Parque Nacional de Cabrera, el Parque Natural de
Mondrag, el Parque Natural de Sa Dragonera y el Parque Natural de SAlbufera
des Grau. De cada uno de ellos se incluye:
- Informacin general (extensin, termino municipal al que petenece, altitud
mxima y fecha de declaracin).
- Sus valores naturales, incluyendo la flora y la fauna de los hbitats que
encontramos.
- Actividades a realizar, excursiones, exposiciones o lugares que visitar.
Juegos
Nos aparece una ruleta que de forma aleatoria selecciona uno de los juegos
siguientes:
- Relacionar animales con sus siluetas.
- Relacionar animales con sus cantos.
- Adivinar animales o plantas a partir de una fotografa.
- Puzles.
- Preguntas aleatorias sobre el parque.
- El juego de la vida.
En funcin de las respuestas que se den, van acumulndose puntos. Para ello se
dispone de 10 minutos. La finalidad global del juego es acumular el mayor
nmero de puntos posible.
Bibliografa
Ordenada alfabticamente por autores se incluye una relacin de toda la
bibliografa, incluyendo libros, artculos cientficos y de divulgacin, relacionada
de una u otra forma con el parque.
Pg. 74
5.1.3. Premios recibidos

Esta produccin fue presentada al II Premio Mbius Barcelona Multimedia. De las 42
aplicaciones presentadas fue seleccionada como una de las 15 finalistas, y seleccionada,
junto con otras 7 de estas aplicaciones finalistas, para optar al V Prix Mbius
Internacional, que se celebr en Pars en Septiembre del 96.
Adems fue finalista del Perseo de Oro del Festival Internacionalle della Opera
Multimediale, mediARTech, de Florencia, y mencin especial por su diseo grfico en
el mismo Festival.
Pg. 75
5.2. Modelado de la navegacin del CD

En este apartado nos centraremos en la tercera etapa de la metodologa RMM, es decir
en el modelo RMDM.
Como podemos ver al arrancar el programa, ste comienza con un men en el que se
integran diez opciones diferentes, aparte de opciones de crditos, que aqu no
trataremos.
Esas diez opciones diferentes, las cuales ya han sido explicadas en el apartado anterior
son:
1. Informacin general
2. Hombre y Albufera
3. Itinerarios
4. Flora
5. Fauna
6. Informacin para los educadores
7. Juegos
8. Otros parques
9. Gestin del parque
10. Bibliografa
Algunas estas opciones dan paso directamente a los contenidos finales. Tal es el caso de
Informacin para educadores (6), Juegos (7), Gestin del parque (9) y Bibliografa (10).
En estos casos, del men accederemos mediante un ndice a las entidades (en el caso de
Juegos, no tiene mucho sentido ya que slo hay un registro en esa entidad que sera el
juego entero). stas no son accesibles desde ningn otro punto, ni permiten acceder a
ningn otro lugar de la aplicacin.
INFO.
EDUCADORES
JUEGO
GESTION
BIBLIOGRAFIA
El caso de los Itinerarios (3) es slo ligeramente ms complejo. Se accede tambin

mediante un ndice a los tres itinerarios, y en cada uno se accede tambin con un ndice
a los lugares interesantes de dicho itinerario.
Pg. 76
ITINERARIO
LUGAR
No es muy diferente el apartado 8, Otros parques. En l se nos ofrecen dos

posibilidades, los parques nacionales de Espaa, o los parques naturales de Baleares.
Por tanto, tenemos un nuevo men que accede mediante un ndice a ambos. Adems, los
parques de Baleares, incluyen sus valores naturales y actividades que se realizan.
PARQUE
BALEARES
VALOR
PARQUE
ESPAOL
ACTIVIDAD
Similar a este ltimo caso son las dos primeras opciones, Informacin General y
Hombre y Albufera. En el primero, accedemos a un men:
- Informacin general (accederemos mediante un ndice)
- Rincones (dem)
Pg. 77
- Consejos (accedemos mediante una visita guiada)

- Estaciones (accedemos mediante un ndice)
- Ciencia, que se divide en dos partes:
- Proyectos cientficos (visita guiada)
- Anidaje de aves (slo tiene un registro)
- Importancia biolgica (slo tiene un registro)
RINCN
INFO.
GENERAL
ANIDAJE
DE AVES
ESTACIN
IMPORTANC.
BIOLGICA
PROYECTO
CIENTFICO
CONSEJO
En cuanto a la segunda opcin tambin accedemos a un men:

- Historia (ndice)
- Usos (ndice)
- Cancionero (ndice)
- Gastronoma (ndice)
MSICA
HISTORIA
USO
GASTRONOMIA
Pg. 78
Quedan por estudiar la parte ms importante y rica, que es la que trata la flora y la fauna.
HABITAT
PLANTAS
PLANTA
sta es la parte que hace referencia a la flora. Podemos acceder de dos maneras
diferentes a la informacin de una planta: por un ndice alfabtico (visita guiada
indexada), o segn su hbitat (ndice). La informacin que tenemos de una planta, es
muy variada: nombre comn (cataln), nombre cientfico, nombre castellano,
identificacin, la situacin en el parque (ubicacin), una foto, y por ltimo los meses de
floracin (ste ltimo aparece en un slice diferente). Tanto si se accede directamente,
como si hace a travs de la familia, se utiliza el nombre cientfico para el ndice que
permite acceder a la planta en cuestin.
Pg. 79
MAMIFERO
INVERTEBRA
DO
REPTIL
ANFIBIO
PEZ
FAMILIA
AVES
AVE
La fauna se divide en varios apartados:

- Aves
- Mamferos
- Anfibios
- Reptiles
- Peces
- Invertebrados
A excepcin de las aves, que es un caso similar al de las plantas, donde se permite
acceder por familias, se accede mediante una visita guiada indexada a la informacin.
sta contiene el nombre comn, cientfico, castellano, la identificacin y situacin en el
parque en todos los casos. En el caso de los mamferos y anfibios se utiliza un slice
adicional para mostrar el sonido que emite, mientras que para las aves se aaden dos
slices, uno para el sonido y otro que muestra la sedentariedad del ave (en qu espacios
de tiempo se encuentra presente en el parque).
Para acceder a la informacin se utiliza en todos los casos la foto del animal, excepto en
el caso de las aves, para lo cual se utiliza su nombre cientfico (tanto si se accede
directamente, como si se hace a travs de la familia).
El resultado de todo este anlisis queda reflejado en el diagrama RMDM:
Pg. 80
MEN PRINCIPAL
BIBLIOGRAFIA
INFO.
EDUCADORES
ITINERARIO
RINCN
INFO.
GENERAL
GESTION
JUEGO
ANIDAJE
DE AVES
ESTACION
IMPORTANC.
BIOLGICA
PROYECTO
CIENTFICO
LUGAR
CONSEJO
MAMIFERO
ANFIBIO
HISTORIA
HABITAT
PLANTAS
MSICA
INVERTEBRA
DO
REPTIL
PARQUE
BALEARES
PEZ
FAMILIA
AVES
PLANTA
USO
GASTRONOMIA
AVE
USO
Pg. 81
ACTIVIDAD
PARQUE
ESPAOL
5.3. Aplicacin de todas las fases de la metodologa

En este apartado lo que pretendemos es aplicar la metodologa desde el principio, como
si nada se hubiese ya sido implementado. Ello nos ayudar a reconocer nuevas
estructuras navegacionales que pasaron inadvertidas la primera vez.
5.3.1. Primera etapa: Diseo entidad-relacin

En esta etapa vamos a identificar las entidades y las relaciones entre ellas. Las primeras
apenas si variarn de las identificadas en el apartado anterior. Por contra, encontraremos
varias nuevas relaciones.
En realidad hay numerosas partes del diseo que no variarn respecto de la
implementacin actual, dada su simplicidad. Ello nos lleva a centrarnos en la parte ms
rica de la navegacin que es la que hace referencia a la flora y la fauna.
Estudiando el material, podemos estructurar toda la informacin en el siguiente conjunto
de entidades, ordenadas alfabticamente. El proceso para detectar estas entidades, no es
trivial y debe dedicrsele mucha atencin, si bien a menudo estar influenciado en buena
medida por la informacin de la que se disponga y por los deseos del cliente. En este
caso concreto nos basaremos en la estructura que se eligi para el CD-ROM, aunque con
ciertos cambios.
Actividades: conjunto de actividades que se desarrollan en los parques de las islas.
Anfibios: informacin textual del anfibio (entre ellas su ubicacin en el parque),
su foto y su sonido caracterstico.
Aves: informacin textual del ave (entre otras su ubicacin en el parque), su foto,
su sonido caracterstico y un grfico que muestra las pocas de presencia en el
parque.
Bibliografa: lista de publicaciones donde se puede encontrar ms informacin.
Consejos: conjunto de consejos para la visita al parque.
Estaciones: las cuatro estaciones del ao, y breve descripcin del parque en cada
estacin.
Familias de aves: las aves estn agrupadas por familias.
Gastronoma: platos tpicos de la zona, que utiliza los recursos del lugar.
Gestin del parque: conjunto de varios elementos importantes para la gestin del
parque.
Hbitats de plantas: las plantas estn agrupadas segn su hbitat.
Informacin general: tenemos la informacin geogrfica, meteorolgica y la
importancia biolgica..
Informacin importante para los educadores: conjunto de varios aspectos de
inters para los educadores
Invertebrados: informacin textual del invertebrado(entre ellas su ubicacin en el
parque) y su foto.
Itinerarios: un itinerario es un conjunto de lugares interesantes del parque. Hay
tres.
Juegos: consta de numerosas pruebas y preguntas y respuestas.
Pg. 82
Lugares: de un lugar tenemos un vdeo o una imagen. Tambin podramos tener

informacin textual describiendo el lugar o su importancia.
Mamferos: informacin textual del mamfero (entre ellas su ubicacin en el
parque), su foto y su sonido caracterstico.
Meses: los 12 meses del ao.
Momentos histricos: conjunto de varios momentos importantes en la historia de
SAlbufera.
Msica: canciones tpicas
Parques de Baleares: 5 parques naturales de Baleares, con una breve informacin
de ellos
Parques de Espaa: los parques nacionales de Espaa con su localizacin en el
mapa del pas.
Peces: informacin textual del pez (entre ellas su ubicacin en el parque) y su
foto.
Plantas: informacin textual de la planta (entre otras su ubicacin en el parque), su
foto y un grfico con sus pocas de floracin.
Proyectos cientficos: cuatro proyectos cientficos que se desarrollan en el parque.
Reptil: informacin textual del reptil (entre ellas su ubicacin en el parque) y su
foto.
Usos: el conjunto de los usos que el hombre hace del parque
Valores naturales: el conjunto de valores naturales con que cuentan los parques de
las islas.
Una vez que hemos identificado todas las entidades, hemos de proceder a identificar las
relaciones entre ellas. stas son las que hemos observado:
- Claramente hay una relacin 1:N entre el hbitat y las plantas.
- Lo mismo ocurre entre las aves y las familias de aves (relacin 1:N)
- Tambin es clara la relacin entre los itinerarios y los lugares que lo componen. En
este caso, puede haber lugares que estn en ms de un itinerario, con lo cual tenemos
una relacin N:M.
- Todo animal o planta tiene la informacin de los lugares donde puede encontrarse. Por
tanto hay una clara relacin entre los lugares y los animales o plantas. La relacin
tambin es N:M.
- Las aves tienen una informacin referente a los meses en los que se encuentran en el
parque. Esto nos induce a incluir una relacin entre los meses y las aves. Evidentemente
sta ser N:M.
- Lo mismo ocurre con las plantas: tenemos la informacin de en qu meses se
encuentran las plantas en flor. Por tanto, tambin hay una relacin N:M entre meses y
plantas.
- Evidentemente, cada estacin tiene unos meses. Para simplificar podemos incluir a un
mes slo en una estacin, con lo cual tenemos una relacin 1:N.
- Tambin se hace referencia a determinados lugares en cada algunos periodos
histricos. Por ejemplo, Sa Marjal es un lugar que se crea en el siglo XVII. Se trata,
pues, de una relacin 1:N, ya que podemos suponer que un lugar es de importancia en
un nico punto histrico.
- Igualmente, en cada lugar hay o ha habido unos determinados usos. Por ejemplo, en Sa
Marjal, el uso es el agrcola.
Pg. 83
- Tambin hay algunos animales que aparecen en los platos de cocina. Pero si se observa
la informacin de la que se dispone, este hecho slo ocurre en un caso, en el cual, la
anguila aparece en dos platos. Por tanto, decidimos no representarlo como una relacin.
Despus de esto ya podemos representar el diagrama entidad relacin de RMM:
FAMILIA
PLANTAS
ITINERARIO
PLANTA
MES
LUGAR
AVE
USO
ESTACION
MAMIFERO
MOMENTO
HISTRICO
FAMILIA
AVES
ANFIBIO
REPTIL
PARQUE
BALEARES
INVERTEBRA
DO
PEZ
USO
ACTIVIDAD
INFO.
GENERAL
CONSEJO
PROYECTO
CIENTFICO
MSICA
BIBLIOGRAF.
GASTRONO
MIA
INFO.
EDUCADOR.
JUEGO
GESTION
PARQUES
ESPAA
5.3.2. Segunda fase: Diseo de slices

En esta etapa detallaremos los atributos y slices que forman cada entidad. Realmente en
muchos casos las entidades son muy simples y constarn tan slo de uno o dos atributos,
y la mayora de las veces, nicamente utilizaremos un slice para cada entidad. sta es la
lista de las entidades con sus correspondientes atributos y slices, ordenada
alfabticamente.
Entidad
ACTIVIDAD
Slice
actividad 1 (head)
Atributo
nombre
foto
texto
Pg. 84

ANFIBIO
anfibio 1 (head)
AVE
anfibio 2
ave 1 (head)
BIBLIOGRAFA
CONSEJO
ESTACIN
ave 2
bibliografa 1 (head)
consejo 1 (head)
estacin 1 (head)
FAMILIA AVES
GESTIN
familia 1 (head)
gestin 1 (head)
GASTRONOMA
gastronoma 1 (head)
HBITAT PLANTAS
INFO. EDUCADORES
hbitat 1 (head)
educadores 1 (head)
INFO. GENERAL
general 1 (head)
INVERTEBRADO
invertebrado 1 (head)
ITINERARIO
itinerario 1 (head)
JUEGO
LUGAR
juego 1 (head)
lugar 1 (head)
MAMFERO
mamfero 1 (head)
MES
MOMENTO HISTRICO
mamfero 2
mes 1 (head)
momento 1 (head)
MSICA
msica 1 (head)
PARQUE BALEARES
baleares 1 (head)
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
sonido
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
sonido
texto
dibujo
nombre
foto
texto
nombre
nombre
foto
texto
nombre
foto
receta
nombre
nombre
foto
texto
nombre
foto
texto
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
nmero
mapa
juego
nombre
vdeo o imagen
texto
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
sonido
nombre
nombre
texto
imagen
sonido
nombre
letra
sonido
vdeo
nombre
Pg. 85
PARQUE ESPAOL
espaa 1 (head)
PEZ
pez 1 (head)
PLANTA
planta 1 (head)
PROYECTO CIENTFICO
proyecto 1 (head)
REPTIL
reptil 1 (head)
USO
uso 1 (head)
VALOR
valor 1 (head)
localizacin
foto
texto
nombre
localizacin
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
nombre
foto
texto
nombre cientfico
nombre cataln
nombre castellano
identificacin
foto
nombre
dibujo
vdeo o imagen
texto
nombre
foto
texto
5.3.3. Tercera fase: Diseo navegacional

En esta etapa nos queda decidir las estructuras de navegacin que utilizaremos para
acceder a la informacin y la estructura de mens. En cuanto a las estructuras de
navegacin hemos intentado seguir las ideas que utilizaron los diseadores del CDROM. Referente a la estructura de mens, sta es:
Informacin general
Informacin general
Consejos
Importancia biolgica
Proyectos cientficos
Informacin educadores
Juegos
Gestin del parque
Bibliografa
Flora
Hbitats
Plantas
Fauna
Aves
Familias de aves
Pg. 86
Aves
Mamferos
Anfibios
Reptiles
Peces
Invertebrados
Estaciones
Itinerarios
Otros parques
Parques de Baleares
Valores naturales
Actividades
Parques de Espaa
El hombre y SAlbufera
Momentos histricos
Usos
Gastronoma
Msica
A partir de aqu, podemos confeccionar el diagrama RMDM, resultado final de este
estudio:
Pg. 87
ESTACIN
ITINERARIO
MAMIFERO
HABITAT
PLANTAS
IMPORTANC.
BIOLGICA
CONSEJOS
REPTIL
ANFIBIO
MES
INVERTEBRA
DO
GASTRONO
MIA
PEZ
PARQUE
ESPAOL
MSICA
JUEGO
INFO.
EDUCADORES
PROYECTO
CIENTFICO
INFO.
GENERAL
PARQUES
BALEARES
FAMILIA
AVES
GESTION
USO
PLANTA
MOMENTO
HISTRICO
AVE
BIBLIOGRAFIA
LUGAR
VALOR
Pg. 88
ACTIVIDAD
5.4. Conclusiones
Como principal conclusin de este estudio se puede deducir la utilidad de utilizar una
metodologa y un modelo para evaluar detalladamente una aplicacin ya desarrollada, a
posteriori.
De esta manera se han detallado una serie de carencias en la estructura de la informacin
y la navegacin. Las exponemos detalladamente a continuacin:
Tanto animales (aves, mamferos, peces, reptiles e invertebrados) como
plantas tienen un lugar en el parque. En el sistema actual se desaprovecha la
informacin para permitir que navegar por todos, por ejemplo, mamferos de
un lugar concreto. Y tambin al contrario, no podemos ir a visitar el lugar que
se nos cita en la informacin del animal o planta.
El mismo caso ocurre con los usos del parque y con los momentos histricos,
que no fueron enlazados con su lugar.
Se pierde la posibilidad de navegar por estacin o mes. Tenemos la
informacin de la presencia de las aves por meses, as como una breve
descripcin del parque en cada estacin. Pero no podemos ver las aves que
estn en un mes concreto (interesante si queremos planificar una visita real al
parque). Lo mismo ocurre con el perodo de floracin de las plantas, que no se
puede navegar por las plantas que estn en flor en un mes concreto.
Pg. 89
VI - Proyecto MINTour
Captulo VI
2 CASO: PROYECTO EUROPEO MINTour
A la hora de hacer el anlisis nos hemos intentado ajustar lo mximo posible a las
especificaciones del proyecto europeo MINTour, [MIN96].
De hecho, nuestra idea inicial era utilizarlas al cien por cien. Sin embargo, esto no ha
sido posible debido a que se ha tardado alrededor de un ao y medio en tener la base de
datos diseada, y las especificaciones cambiaban tan frecuentemente, y con tantos
errores, que decidimos que era imposible seguir esa lnea. Incluso la definicin
definitiva de la base de datos de MINTour contiene varios fallos de normalizacin
incomprensibles.
As pues, nuestro diseo resulta ser muy diferente del utilizado finalmente para el
proyecto europeo, pero se ajusta a las primeras especificaciones que se hicieron para el
mismo, a nuestro entender las ms acertadas.
A partir de aqu comenzamos a analizar MINTour utilizando la metodologa RMM.
Ntese que en vez de crear diagramas globales, iremos generando diagramas para cada
categora. De lo contrario resultara completamente ilegible, dado el gran nmero de
entidades y relaciones.
El proyecto europeo estaba dividido en una serie de categoras, que son lo que en la
metodologa Coad-Yourdon se denomina temas, una agrupacin de entidades que tienen
una fuerte relacin entre s en el mundo real. Las categoras en que finalmente hemos
dividido este proyecto son las en las que se dividi el proyecto original (aunque en las
ltimas versiones algunas de ellas se agruparan). Sin embargo, tambin hemos
considerado interesante incluir alguna categora nueva como Naturaleza, que hace
referencia a reas naturales, que no fueron definidas en las primeras especificaciones del
proyecto europeo, pero s en las ltimas. sta es nuestra lista, en la que nos basaremos
para hacer el anlisis:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
reas geogrficas
Alojamientos
Playas
Deportes
Eventos culturales
Museos y monumentos
Naturaleza
Entretenimientos
Restaurantes
Rent-a-car
Tiendas
Transporte areo
Transporte martimo
Transporte terrestre
Transporte urbano
Pg. 90
16.
17.
18.
19.
20.
Taxi
Paquetes tursticos
Excursiones
Telfonos y direcciones de inters
Agencias de viaje
A continuacin, veremos en un primer apartado una introduccin describiendo qu es

MITNour. Despus en los aprtados 6.2., 6.3. y 6.4., respectivamente, se analizan las tres
primeras fases de la metodologa. Ntese que en el ltimo subapartado del punto 6.4.
(6.4.21.) se muestra la jerarqua de mens. Por otr parte, en el siguiente apartado, 6.5.,
se estudian las ltimas cuatro etapas, referentes a anlisis de interfaz e implementacin.
En el ltimo apartado se exponen las conclusiones y un resumen de las aportaciones que
se han hecho a la metodologa a partir de este anlisis.
Pg. 91
6.1. Qu es MINTour
La siguiente descripcin del proyecto MINTour ha sido extrada del folleto de
promocin del proyecto:
MINTour es el acrnimo de Multimedia Information Network for TOURism. MINTour
aspira a convertirse en el embrin de la futura red paneuropea de informacin turstica
gracias al firme apoyo de las administraciones pblicas y de los principales actores
dentro del sector turstico, utilizando y promocionando a la vez los estndares europeos
e internacionales. Dicha red debera ser utilizada por los ciudadanos en calidad de
usuarios finales, empresas y Administracin.
6.1.1. Por qu nace MINTour

La industria del turismo est sufriendo un giro y camina hacia un mercado cada vez
ms diversificado y con una mayor presencia de clientes potenciales que quieren obtener
informacin precisa y fiable sobre sus posibles viajes. Las administraciones pblicas son
las nicas entidades que realmente pueden ofrecer informacin de calidad en trminos
de fidelidad y fiabilidad mantenindola actualizada constantemente. Los productos con
contenido multimedia accesibles a travs de redes telemticas pueden satisfacer estas
necesidades que la nueva industria turstica demanda cada vez ms.
6.1.2. Objetivos
Proporcionar al usuario un punto de entrada a una amplia gama de
informacin y productos tursticos mediante un sistema de navegacin
amigable.
Promocionar el sector turstico europeo proporcionando al usuario una base
de informacin turstica multimedia y recursos derivados, alojamiento,
transporte, servicios pblicos e infraestructuras, actividades de placer,
deportes, ...
La informacin ser homognea, es decir, todos los pases involucrados
accedern de la misma manera a un mismo tipo de informacin y sta, a su
vez, ser descrita de manera similar.
La informacin ser fiable ya que sern las administraciones pblicas
relacionadas con el sector turstico de cada pas las encargadas de proveer
informacin.
Mejorar la calidad del servicio y contribuir a un nivel de satisfaccin mucho
ms elevado por parte de los viajeros.
Ofrecer un mejor servicio a los ciudadanos involucrando profundamente a las
administraciones pblicas con el soporte de la industria turstica.
Pg. 92
Todo el sistema est configurado como un servicio pblico, sin ninguna

orientacin comercial.
Pg. 93
6.2. 1 Etapa: Anlisis Entidad-Relacin

6.2.1. reas geogrficas
Comenzamos el anlisis por el corazn de MINTour, la estructura geogrfica. En
MINTour, todos los objetos que pertenecen a una categora estn asociados a una
ciudad. El trmino ciudad aqu toma una definicin particular, refirindose a aquellos
destinos tursticos que queremos tratar. Por ejemplo, en el municipio de Palma, no
tendremos una nica ciudad, sino que al menos habr dos: Palma y la Platja de Palma.
Por tanto, cuando a partir de ahora nos refiramos a ciudad, en realidad nos referimos a
destino turstico.
La provincia tambin toma un sentido particular, ya que se consideran tres provincias en
Baleares: Mallorca, Menorca y Eivissa i Formentera.
Cada una de estos niveles tiene asociados mapas. Es decir, que cada nacin, regin,
provincia y ciudad tienen un mapa. ste se utilizar para realizar bsquedas grficas.
Nacin
Nacin
Multimedia
Regin
Regin
Multimedia
Tipo
Multimedia
Provincia
Provincia
Multimedia
Ciudad
Ciudad
Multimedia
Veamos la descripcin de atributos de estas entidades:

Nacin
ID Nacin: texto (PK)
Nombre: texto
Descripcin: texto
Mapa: texto (indica la direccin del fichero que contiene el mapa)
Regin
ID Regin: texto (PK)
ID Nacin: texto (FK)
Nombre: texto
Descripcin: texto
Pg. 94

Posicin X: entero (indica la posicin en el eje X, dentro del mapa de nacin)
Posicin Y: entero (indica la posicin en el eje Y, dentro del mapa de nacin)
Provincia
ID Provinica: texto (PK)
ID Regin: texto (FK)
Nombre: texto
Descripcin: texto
Posicin X: entero (indica la posicin en el eje X, dentro del mapa de regin)
Posicin Y: entero (indica la posicin en el eje Y, dentro del mapa de regin)
Ciudad
ID Ciudad: texto (PK)
ID Provincia: texto (FK)
Nombre: texto
Descripcin: texto
Posicin X: entero (indica la posicin en el eje X, dentro del mapa de provincia)
Posicin Y: entero (indica la posicin en el eje Y, dentro del mapa de provincia)
Tipo Multimedia
ID Tipo MM: texto (PK)
Nombre: texto
Descripcin: texto
Plug-in: texto (Nombre y direccin del plug-in)
Nacin Multimedia
ID MM: texto (PK)
ID Nacin: texto (FK)
ID Tipo MM: texto (FK)
Direccin: texto (indica la direccin donde est la imagen, vdeo, sonido, ...)
Descripcin: texto
Copyright: texto
Regin Multimedia
ID MM: texto (PK)
ID Regin: texto (FK)
Descripcin: texto
Copyright: texto
Provincia Multimedia
ID MM: texto (PK)
ID Provincia: texto (FK)
Pg. 95
Descripcin: texto
Copyright: texto
Descripcin: texto
Copyright: texto
Ciudad Multimedia
ID MM: texto (PK)
ID Ciudad: texto (FK)
Descripcin: texto
Copyright: texto
Pg. 96
6.2.2. Alojamientos
Esta categora engloba tanto hoteles, apartamentos, campings, hostales, entre otros tipos
de alojamientos. Adems de por el tipo, los alojamientos se clasifican por la categora
(estrellas o llaves).
Un alojamiento tiene varias habitaciones de tipos diferentes. Es importante hacer notar
que la entidad Habitaciones es el resultado de la relacin N:M entre las entidades
Hotel y Tipo Habitacin. Cada habitacin tendr un precio en funcin de la
temporada (alta, media o baja) y del rgimen de estancia (pensin completa, media
pensin, ...). Es importante notar que las temporadas no las marca cada hotel sino que
estn marcadas por ley.
Un alojamiento puede pertenecer a una cadena.
Por ltimo, el alojamiento ofrece unos servicios, ya sean generales o de habitacin.
stos se incluyen en una entidad adicional, dada la gran diversidad existente y la
constante aparicin de nuevos servicios. Ntese que se podra relacionar tambin la
entidad Habitacin con los servicios, pero la informacin que se nos ofrece habla de
servicios en habitaciones en general, sin especificar para qu tipos.
Cadena
Alojamientos
Ciudad
Tipo
Alojamiento
Alojamiento
Alojamiento
Multimedia
Alojamiento
Servicio
Habitaciones
Categora
Alojamientos
Servicio
Alojamientos
Tipo
Multimedia
Tipo
Habitacin
Rgimen
Estancia
Temporada
Precio
Habitacin
Veamos la descripcin de los atributos de estas entidades:

Alojamiento
ID Alojamiento: texto (PK)
ID Tipo Alojamiento: texto (FK)
ID Cadena Alojamientos: texto (FK)
Pg. 97
ID Categora Alojamientos: texto (FK)

Nombre: texto
Descripcin: texto
Localizacin: texto (breve explicacin de la zona donde se halla y cmo llegar)
Posicin X: entero (indica la posicin en el eje X, dentro del mapa de ciudad)
Posicin Y: entero (indica la posicin en el eje Y, dentro del mapa de ciudad)
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Tipo Alojamiento
ID Tipo Alojamiento: texto (PK)
Nombre: texto
Descripcin: texto
Categora Alojamientos
ID Categora Alojamientos: texto (PK)
Nombre: texto
Descripcin: texto
Cadena Alojamientos
ID Cadena Alojamientos: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Alojamiento Multimedia
ID MM: texto (PK)
ID Alojamiento: texto (FK)
Descripcin: texto
Copyright: texto
Servicio Alojamientos
ID Servicio Alojamientos: texto (PK)
Nombre: texto
Descripcin: texto
Alojamiento Servicio
Pg. 98

ID Servicio Alojamientos: texto (PK)
Cantidad: entero (a veces un servicio slo tiene un valor booleano, pero a veces
un nmero - p.ej. nmero de pistas de tenis -. Este campo se utiliza para
el segundo caso)
Habitacin: booleano (indica si el servicio es de habitacin, o por contra,
general)
Habitaciones
ID Tipo Habitacin: texto (PK)
Nmero: entero (indica el nmero de habitaciones de ese tipo en el alojamiento)
Tipo de Habitacin
Nombre: texto
Descripcin: texto
Temporada
ID Temporada: texto (PK)
Nombre: texto
Descripcin: texto
Fecha inicio: fecha
Fecha fin: fecha
Rgimen Estancia
ID Rgimen Estancia: texto (PK)
Nombre: texto
Descripcin: texto
Precio Habitacin
ID Temporada: texto (PK)
Precio: entero
Pg. 99
6.2.3. Playas
La estructura de esta categora es sencilla. Una playa tiene un tipo de playas (arenosa,
grava, ...), y unos servicios. Al igual que con los alojamientos, los servicios se incluyen
en una entidad adicional, dada la gran diversidad existente y la constante aparicin de
nuevos servicios.
Ciudad
Tipo
Playa
Playa
Playa
Multimedia
Playa
Servicio
Servicio
Playas
Tipo
Multimedia

Playa
ID Playa: texto (PK)
ID Tipo Playa: texto (FK)
Nombre: texto
Descripcin: texto
Tipo Playa
ID Tipo Playa: texto (PK)
Nombre: texto
Descripcin: texto
Playa Multimedia
ID MM: texto (PK)
ID Playa: texto (FK)
Descripcin: texto
Copyright: texto
Servicio Playas
ID Servicio Playas: texto (PK)
Nombre: texto
Pg. 100
Descripcin: texto
Playa Servicio
ID Playa: texto (PK)
ID Servicio Playas: texto (PK)
Cantidad: entero
Pg. 101
6.2.4. Deportes
En esta categora se hace referencia a las instalaciones deportivas. La base de la
estructura de esta categora es la instalacin deportiva: una instalacin est asociada a
uno o varios deportes y tiene varios servicios. Tambin aqu incluimos una entidad
adicional para los servicios.
Es necesaria una entidad que refleje los horarios de la instalacin. Ntese que el horario
puede variar tanto segn la temporada como segn el da de la semana.
En cuanto al precio, a menudo no se trata de un precio nico, sino que depende de qu
servicios se utilicen, abonos, ... Por tal motivo, slo se indica si la instalacin es gratuita
o no. Tambin se indica si est abierta para la prctica del pblico (p.ej. un estadio de
ftbol no suele ser para el uso pblico, ya que el pblico no puede practicar deporte en
l).
Deporte
Deporte
Multimedia
Tipo
Multimedia
Ciudad
Deporte
Instalacin
Horario
Instalacin
Instalacin
deportiva
Instalacin
Multimedia
Instalacin
Servicio
Servicio
Deportes

Deporte
ID Deporte: texto (PK)
Nombre: texto
Descripcin: texto
Instalacin deportiva
ID Instalacin deportiva: texto (PK)
Nombre: texto
Descripcin: texto
Pg. 102
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Pblico: booleano (indica si es una instalacin para uso del pblico en general)
Gratuito: booleano
Deporte Instalacin
ID Deporte: texto (PK)
Nmero: entero (indica el nmero de pistas, piscinas, ...)
Deporte Multimedia
ID MM: texto (PK)
ID deporte: texto (FK)
Descripcin: texto
Copyright: texto
Instalacin Multimedia
ID MM: texto (PK)
ID Instalacin deportiva: texto (FK)
Descripcin: texto
Copyright: texto
Servicio Deportes
ID Servicio Deportes: texto (PK)
Nombre: texto
Descripcin: texto
Instalacin Servicio
ID Servicio Deportes: texto (PK)
Cantidad: entero
Horario Instalacin
Fecha inicio vigencia: fecha (PK)
Fecha fin vigencia: fecha
Da semana inicio: 1..7 (PK)
Da semana fin: 1..7
Hora apertura maana: hora
Hora cierre maana: hora
Hora apertura tarde: hora
Pg. 103
Hora cierre tarde: hora
Pg. 104
6.2.5. Eventos culturales

Los eventos culturales se refieren tanto a conciertos, actuaciones, ..., ya sean puntuales o
en el marco de un ciclo, as como a las fiestas populares, festivales, ... Por tanto, un
evento cultural puede estar contenido en otro. Por ejemplo un concierto de la banda
municipal puede estar incluido en las fiestas de una ciudad, o en el festival de bandas de
msica. Estos eventos pueden celebrarse en una o tambin en varias ciudades.
A su vez, un evento cultural puede tener varias representaciones (una, varias o tambin
ninguna si no tenemos informacin concreta de fechas, horas o lugares), como en el
caso de una obra de teatro o un concierto, que pueden repetirse varios das, con lo cual
tendremos otra entidad llamada Representacin donde introduciremos la hora concreta
de cada representacin, as como el precio. Esta representacin se realiza en lo que
denominamos un centro cultural, que puede ser un teatro, un auditorio, un cine, o
incluso un campo de ftbol.
Tipo
Evento
Ciudad
Evento
Ciudad
Evento
Cultural
Eventos
Multimedia
Centro
Cultural
Represent
acin
Tipo
Multimedia
Evento Cultural
ID Evento Cultural: texto (PK)
ID Tipo Evento: texto (FK)
Nombre: texto
Descripcin: texto
Fecha Inicio: fecha
Fecha Fin: fecha
Evento Ciudad
ID Evento Cultural: texto (PK)
Tipo Evento
ID Tipo Evento: texto (PK)
Nombre: texto
Descripcin: texto
Representacin
Pg. 105
ID Representacin: texto (PK)

ID Evento Cultural: texto (FK)
ID Centro Cultural: texto (FK)
Fecha: fecha
Hora Inicio: hora
Hora Fin: hora
Gratuito: booleano
Centro Cultural
ID Centro Cultural: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Eventos Multimedia
ID MM: texto (PK)
ID Evento Cultural: texto (FK)
Descripcin: texto
Copyright: texto
Pg. 106
6.2.6. Museos y monumentos

Ciertamente, museos y monumentos tienen unas caractersticas muy similares y, muy a
menudo, es difcil separar uno de otro. Es por eso que decidimos considerarlos como
una nica categora. Un museo o monumento tendr un tipo y un periodo histrico.
Aunque en un principio incluimos una entidad adicional para los servicios, finalmente
descartamos esta opcin, ya que la nica informacin disponible al respecto es si hay
visitas guiadas, auditorio o tienda, y parece difcil que un museo (y menos un
monumento sin museo) pueda ofrecer ms servicios.
Ciudad
Tipo
Monumento
Horario
Monumento
Monumento
Monumento
Multimedia
Monumento
Servicio
Servicio
Monumentos
Tipo
Multimedia
Periodo
Histrico
Monumento
ID Monumento: texto (PK)
ID Tipo Monumento: texto (FK)
ID Periodo Histrico: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Visitas guiadas: booleano
Sala de proyecciones: booleano
Tienda: booleano
Pblico: booleano
Gratuito: booleano
Tipo Monumento
ID Tipo Monumento: texto (PK)
Nombre: texto
Pg. 107
Descripcin: texto
Periodo Histrico
ID Periodo Histrico: texto (PK)
Nombre: texto
Descripcin: texto
Ao Inicio: entero
Ao Fin: entero
Monumento Multimedia
ID MM: texto (PK)
ID Monumento: texto (FK)
Descripcin: texto
Copyright: texto
Servicio Monumentos
ID Servicio Monumentos: texto (PK)
Nombre: texto
Descripcin: texto
Monumento Servicio
ID Servicio Monumentos: texto (PK)
Cantidad: entero
Horario Monumento
Da semana inicio: 1..7 (PK) (1: lunes, 7: domingo)
Da semana fin: 1..7
Pg. 108
6.2.7. Naturaleza
Los lugares naturales corresponden a montaas, lagos, parques naturales, ..., o incluso
dentro de las ciudades a parques o jardines. Aqu ya no tiene sentido el periodo
histrico. A menudo un rea natural corresponder a ms de una ciudad. Tambin aqu
hemos decidido incluir los servicios en una entidad aparte. Servicios naturales pueden
ser un rea de acampada, fuente, merendero, barbacoa, oficina de informacin, ...
Ciudad
Naturaleza
Ciudad
Tipo
Naturaleza
Naturaleza
Naturaleza
Multimedia
Naturaleza
Servicio
Servicio
Natural
Tipo
Multimedia
Naturaleza
ID Naturaleza: texto (PK)
ID Tipo Naturaleza: texto (FK)
Nombre: texto
Descripcin: texto
Pblico: booleano (indica si est abierta al pblico)
Gratuito: booleano
Naturaleza Ciudad
Tipo Naturaleza
ID Tipo Naturaleza: texto (PK)
Nombre: texto
Descripcin: texto
Naturaleza Multimedia
ID MM: texto (PK)
ID Naturaleza: texto (FK)
Descripcin: texto
Copyright: texto
Pg. 109
Servicio Natural
ID Servicio Natural: texto (PK)
Nombre: texto
Descripcin: texto
Naturaleza Servicio
ID Servicio Natural: texto (PK)
Cantidad: entero
Pg. 110
6.2.8. Entretenimientos
En esta categora englobamos bares, discotecas y dems lugares de ocio. La estructura
de la categora es simple: un tipo de entretenimiento (bar, discoteca, pub, ...) y unos
servicios.
Tipo
Entretenimiento
Ciudad
Horario
Entretenimiento
Entretenimiento
Entretenimiento
Multimedia
Tipo
Multimedia
Entretenimiento
ID Entretenimiento: texto (PK)
ID Tipo Entretenimiento: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Gratuito: booleano
Tipo Entretenimiento
ID Tipo Entretenimiento: texto (PK)
Nombre: texto
Descripcin: texto
Entretenimiento Multimedia
ID MM: texto (PK)
ID Entretenimiento: texto (FK)
Descripcin: texto
Copyright: texto
Pg. 111
Horario Entretenimiento
ID Entretenimiento: texto (PK)
Da semana fin: 1..7
Pg. 112
6.2.9. Restaurantes
Los restaurantes presentan una estructura muy similar a la anterior categora, si bien
incorporan una categora.
Tipo
Restaurantes
Ciudad
Horario
Restaurante
Restaurante
Restaurante
Multimedia
Tipo
Multimedia
Categora
Restaurante
Restaurante
ID Restaurante: texto (PK)
ID Tipo Restaurante: texto (FK)
ID Categora Restaurante: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Tipo Restaurante
ID Tipo Restaurante: texto (PK)
Nombre: texto
Descripcin: texto
Restaurante Multimedia
ID MM: texto (PK)
ID Restaurante: texto (FK)
Descripcin: texto
Copyright: texto
Categora Restaurante
Pg. 113
ID Categora Restaurante: texto (PK)

Nombre: texto
Descripcin: texto
Horario Restaurante
ID Restaurante: texto (PK)
Da semana fin: 1..7
Pg. 114
6.2.10. Rent-a-car
Esta categora es muy sencilla: un rent-a-car puede pertenecer a una cadena. Adems
tiene un horario de apertura.
Cadena
Rent-a-car
Ciudad
Horario
Rent-a-car
Rent-a-car
Rent-a-car
Multimedia
Tipo
Multimedia
Rent-a-car
ID Rent-a-car: texto (PK)
ID Cadena Rent-a-car: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Cadena Rent-a-car
ID Cadena Rent-a-car: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Rent-a-car Multimedia
ID MM: texto (PK)
ID Rent-a-car: texto (FK)
Pg. 115

Descripcin: texto
Copyright: texto
Horario Rent-a-car
ID Rent-a-car: texto (PK)
Da semana fin: 1..7
Pg. 116
6.2.11. Tienda
Una tienda pertenece a un tipo de tiendas (comestibles, souvenirs, grandes almacenes,
...) y puede pertenecer a una cadena. Adems tambin es importante el horario de la
tienda.
Ciudad
Horario
Tienda
Tienda
Tienda
Multimedia
Cadena
Tiendas
Tipo
Tienda
Tipo
Multimedia
Tienda
ID Tienda: texto (PK)
ID Tipo Tienda: texto (FK)
ID Cadena Tiendas: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Tipo Tienda
ID Tipo Tienda: texto (PK)
Nombre: texto
Descripcin: texto
Cadena Tiendas
ID Cadena Tiendas: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Pg. 117
Fax: texto
email: texto
URL: texto
Tienda Multimedia
ID MM: texto (PK)
ID Tienda: texto (FK)
Descripcin: texto
Copyright: texto
Horario Tienda
ID Tienda: texto (PK)
Da semana fin: 1..7
Pg. 118
6.2.12. Transporte areo

Un vuelo lgicamente une dos aeropuertos. Pero, siguiendo la terminologa propia de la
aviacin, un cdigo de vuelo corresponde a un par de aeropuertos, ms una compaa
area, ms una hora de salida. Por ejemplo, el vuelo IB3024 podra ser, por ejemplo, el
vuelo de Iberia que va de Palma a Ibiza y que sale a las 8:00 de la maana. El que sale a
las 15:00 y/o es de otra compaa recibir otro cdigo. Ntese que el IB3024 es muy
posible que no salga todos los das de la semana. En todo caso es necesario una entidad
adicional Horario Vuelo, ya que puede ser que el vuelo cambie su horario segn la
temporada y que en invierno salga a las 7:00 y en verano a las 8:00.
Ntese que la entidad Compaa de Transportes es comn a todos las categoras de
transportes. Esto es debido a que por ejemplo, una compaa de aviacin o de barcos
puede tener autocares propios, y no tendra sentido crear dos veces la compaa en dos
entidades diferentes.
Ciudad
Aeropuerto
Aeropuerto
Multimedia
Vuelo
Horario
Vuelo
Compaa
Transportes
Precio
Vuelo
Ciudad
Tipo
Multimedia
Tipo Tarifa
Area
Ca Transportes
Multimedia
Aeropuerto
ID Aeropuerto: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Pg. 119
Fax: texto
email: texto
URL: texto
Vuelo
ID Vuelo: texto (PK)
Descripcin: texto (descripcin del vuelo: compaa, origen, destino y escalas)
ID Aeropuerto salida: texto (FK)
ID Aeropuerto llegada: texto (FK)
ID Compaa Transportes: texto (FK)
Vuelo directo: booleano
Tipo Tarifa Area
ID Tipo Tarifa Area: texto (PK)
Nombre: texto
Descripcin: texto
Precio
ID Tipo Tarifa Area: texto (PK)
Precio: entero
Fecha inicio vigencia: fecha
Compaa Transportes
ID Compaa Transportes: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Horario Vuelo
Hora salida: hora
Hora llegada: hora
Lunes: booleano (indica si el vuelo sale los lunes)
Martes: booleano (indica si el vuelo sale los martes)
Mircoles: booleano (indica si el vuelo sale los mircoles)
Jueves: booleano (indica si el vuelo sale los jueves)
Viernes: booleano (indica si el vuelo sale los viernes)
Sbado: booleano (indica si el vuelo sale los sbados)
Domingo: booleano (indica si el vuelo sale los domingos)
Pg. 120
Aeropuerto Multimedia
ID MM: texto (PK)
ID Aeropuerto: texto (FK)
Descripcin: texto
Copyright: texto
Ca Transportes Multimedia
ID MM: texto (PK)
Descripcin: texto
Copyright: texto
Pg. 121
6.2.13. Transporte martimo

La estructura de esta entidad es muy similar a la de transporte martimo. La nica
diferencia es que aqu s que puede ocurrir que el trayecto Palma-Barcelona est cubierto
varias veces al da pero el cdigo es el mismo. Tambin su horarios puede variar segn
el da de la semana. Estas dos consideraciones nicamente conllevan un cambio en la
entidad Horario Trayecto respecto a la Horario Vuelo, pero no cambios en la estructura.
Ciudad
Puerto
Puerto
Multimedia
Trayecto
Horario
Trayecto
Compaa
Transportes
Ciudad
Precio
Pasaje
Tipo
Multimedia
Tipo
Pasaje
Ca Transportes
Multimedia
Puerto
ID Puerto: texto (PK)
Nombre: texto
Descripcin: texto
Longitud: texto (situacin exacta del puerto: longitud)
Latitud: texto (situacin exacta del puerto: latitud)
Profundidad mxima: entero
Profundidad mnima: entero
Estrechez: entero
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
Pg. 122
email: texto
URL: texto
Trayecto
ID Trayecto: texto (PK)
Descripcin: texto (descripcin del trayecto: compaa, origen, destino y escalas)
ID Puerto salida: texto (FK)
ID Puerto llegada: texto (FK)
Trayecto directo: booleano
Tipo Pasaje
ID Tipo Tipo Pasaje: texto (PK)
Nombre: texto
Descripcin: texto
Precio Pasaje
ID Tipo Pasaje: texto (PK)
Precio: entero
Compaa Transportes
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Horario Trayecto
Hora salida: hora (PK)
Hora llegada: hora
Da semana fin: 1..7
Vehculos: booleano (Indica si el barco permite llevar vehculos)
Nombre barco: texto
Puerto Multimedia
ID MM: texto (PK)
ID Puerto: texto (FK)
Pg. 123

Descripcin: texto
Copyright: texto
ID MM: texto (PK)
Descripcin: texto
Copyright: texto
Pg. 124
6.2.14. Transporte terrestre

Se engloban en esta categora las categoras originales Trenes y Autocares, ya que
ambas resultan ser idnticas y que hemos decidido que normalmente cuando alguien
busca el modo de ir de una ciudad a otra, en principio no desea hacer dos bsquedas
diferentes, una para los trenes y otra para los autocares. De todos modos, mediante la
entidad Medio de Transporte se diferencia entre uno y otro.
Ntese que tenemos la entidad Parada no es ms que el nombre que le hemos dado a
la entidad que surge de la relacin N:M entre Estacin y Lnea.
Ciudad
Estacin
Estacin
Multimedia
Parada
Lnea
Medio
Transporte
Horario
Tr. Terrestre
Compaa
Transportes
Ciudad
Ca Transportes
Multimedia
Estacin
ID Estacin: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Pg. 125
Lnea
ID Lnea: texto (PK)
ID Medio Transporte: texto (FK)
Nombre: texto
Descripcin: texto
Nmero paradas: entero
Medio Tranporte
ID Medio Transporte: texto (PK)
Nombre: texto
Parada
ID Estacin: texto (PK)
ID Lnea: texto (PK)
Nmero orden: entero (indica el nmero de orden de la parada en la lnea)
Compaa Transportes
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Horario Tr. Terrestre
ID Lnea: texto (PK)
Hora salida: hora (PK)
Hora llegada: hora
Da semana fin: 1..7
Precio: texto (lista de los precios segn las paradas)
Estacin Multimedia
ID MM: texto (PK)
ID Estacin: texto (FK)
Descripcin: texto
Copyright: texto
ID MM: texto (PK)
Pg. 126

Descripcin: texto
Copyright: texto
Pg. 127
6.2.15. Transporte Urbano

Esta categora incluye los transportes urbanos, ya sean autobuses, metros, tranvas, etc.
Como dato muy importante, la entidad parada urbana est relacionada con un gran
nmero de entidades de otras categoras, ya que para un usuario es de inters qu parada
es la que est ms prxima a un museo, una playa, un hotel, para as, poder saber qu
lnea necesita para llegar.
Ciudad
Compaa
Transportes
Lnea
Urbana
Parada
Lnea
Ca Transportes
Multimedia
Horario
Urbano
Parada
Urbana
Ciudad
Pg. 128
Ca Transportes
Multimedia
Ciudad
Compaa
Transportes
Lnea
Urbana
Horario
Urbano
Parada
Lnea
Parada
Urbana
Ciudad
Parada
Alojamiento
Alojamiento
Parada
Playa
Playa
Parada
Instalac.
Instalac.
Deportiva
Parada
Museo
Museo
Parada
Naturaleza
Naturaleza
Parada
Entretenim.
Entretenim.
Parada
Restaurante
Restaurante
Parada
Rent-a-car
Rent-a-car
Parada
Tienda
Tienda
Parada
Aeropuerto
Aeropuerto
Parada
Puerto
Puerto
Parada
Estacin
Estacin
Parada
Informacin
Informacin
Parada
Agencia
Agencia
Lnea Urbana
ID Lnea Urbana: texto (PK)
ID Compaa Urbana: texto (FK)
Nombre: texto
Descripcin: texto
Parada Urbana
ID Parada Urbana: texto
ID Ciudad: texto
Direccin: texto
Pg. 129

Parada Lnea
ID Lnea: texto (PK)
ID Parada Urbana: texto (PK)
Horario Urbano
Lnea Urbana ID: fecha (PK)
Primera salida origen: hora
ltima salida origen: hora
Primera salida destino: hora
ltima salida destino: hora
Frecuencia de paso: nmero
Precio billete ordinario: nmero
Precio bono 10 billetes: nmero
Compaa Transportes
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
ID MM: texto (PK)
Descripcin: texto
Copyright: texto
Parada Alojamiento
ID Parada: texto
ID Alojamiento: texto
Parada Playa
ID Parada: texto
ID Playa: texto
Parada Instalacin
Pg. 130
ID Deporte: texto
ID Playa: texto
Parada Museo
ID Museo: texto
ID Playa: texto
Parada Naturaleza
ID Naturaleza: texto
ID Playa: texto
Parada Entretenimiento
ID Entretenimiento: texto
ID Playa: texto
Parada Restaurante
ID Restaurante: texto
ID Playa: texto
Parada Rent-a-car
ID Rent-a-car: texto
ID Playa: texto
Parada Tienda
ID Tienda: texto
ID Playa: texto
Parada Aeropuerto
ID Aeropuerto: texto
ID Playa: texto
Parada Puerto
ID Puerto: texto
ID Playa: texto
Parada Estacin
ID Estacin: texto
ID Playa: texto
Parada Informacin
ID Informacin: texto
ID Playa: texto
Parada Agencia
ID Agencia: texto
ID Playa: texto
Pg. 131
6.2.16. Taxis
Esta categora se refiere a paradas de taxis. Su estructura es la ms simple: slo est
relacionada con la ciudad, ni siquiera tienen sentido objetos multimedia.
Ciudad
Taxi
Taxi
ID Taxi: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
Pg. 132
6.2.17. Paquete turstico

Un paquete turstico u oferta promocional, es ofrecido por una agencia de viajes, en una
ciudad y, generalmente, tambin un alojamiento concreto. El precio de un paquete
depende del rgimen de estancia.
Cadena
Ag. Viajes
Alojamiento
Oferta
Promocional
Rgimen
Estancia
Precio
Oferta
Ciudad
Oferta Promocional
ID Oferta: texto (PK)
ID Alojamiento: texto (FK)
ID Cadena Ag. Viajes: texto (FK)
Nombre: texto
Descripcin: texto
Excursiones: booleano
Coche de alquiler: booleano
Rgimen Estancia
Nombre: texto
Descripcin: texto
Precio Oferta
ID Oferta: texto (PK)
Precio: entero
Pg. 133
6.2.18. Excursiones
Esta categora describe excursiones, ya sea a pie, en bicicleta, en coche o en cualquier
medio de transporte. Una excursin puede incluir una o ms ciudades (recurdese que
en MINTour ciudad representaba a un municipio).
Medio
Transporte
Excursin
Excursin
Ciudad
Excursin
Multimedia
Ciudad
Excursin
ID Excursin: texto (PK)
ID Medio Transporte: texto (FK)
Nombre: texto
Descripcin: texto
Punto de partida: texto
Punto final: texto
Recorrido: texto
Duracin: texto
Dificultad: texto
Transportes: texto (descripcin de medios de transporte utilizados como soporte)
Valor historico-natural: texto
Mapa: texto (direccin con el mapa del recorrido)
Medio Tranporte
ID Medio Transporte: texto (PK)
Nombre: texto
Excursin Ciudad
ID Excursin: texto (PK)
Excursin Multimedia
ID MM: texto (PK)
ID Excursin: texto (FK)
Pg. 134
Descripcin: texto
Copyright: texto
Pg. 135
6.2.19. Telfonos y direcciones tiles

Se engloban aqu todas las oficinas de informacin turstica, as como otro tipo de
direcciones y telfonos que puedan resultar de inters para el turista, como por ejemplo,
un grupo ecologista, una federacin de un deporte determinado, ... Su estructura es
simplsima: slo est relacionada con la ciudad y con un horario, y ni siquiera tienen
sentido objetos multimedia.
Ciudad
Informacin
Horario
Informacin
Informacin
ID Informacin: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Gratuito: booleano
Horario Informacin
ID Informacin: texto (PK)
Da semana fin: 1..7
Pg. 136
6.2.20. Agencias de viaje

Esta categora hace referencia a las agencias de viaje. Cada una de ellas pertenece a una
cadena, de la cual podemos tener informacin multimedia (no de la agencia en
concreto). Por ltimo la agencia tiene un horario.
Ciudad
Cadena
Agencias
Cadena agencias
Multimedia
Agencia
Horario
Agencia
Tipo
Multimedia
Agencia
ID Agencia: texto (PK)
ID Cadena Agencias: texto (FK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Cadena Agencias
ID Cadena Agencias: texto (PK)
Nombre: texto
Descripcin: texto
Direccin: texto
CP: texto
Telfono: texto
Fax: texto
email: texto
URL: texto
Agencia Multimedia
ID MM: texto (PK)
ID Agencia: texto (FK)
Pg. 137
Descripcin: texto
Copyright: texto
Horario Agencia
ID Agencia: texto (PK)
Da semana fin: 1..7
Pg. 138
6.3. 2 Etapa: Diseo de slices

Nacin
Mnimo
Head (hbrido)
Regin
Mnimo
Head (hbrido)
Mapa Nacin (hbrido)
Provincia
Mnimo
Head (hbrido)
Mapa Regin
Ciudad
Mnimo
Head (hbrido)
Mapa Provincia (hbrido)
Tipo Multimedia
Mnimo
Head
Nombre
Nombre
Descripcin
Mapa
Nombre
Nacin.Nombre
Nombre
Descripcin
Mapa
Nacin.Mapa
Posicin X
Posicin Y
Nombre
Regin.Nombre
Nombre
Descripcin
Mapa
Regin.Mapa
Posicin X
Posicin Y
Nombre
Provincia.Nombre
Nombre
Descripcin
Mapa
Provincia.Mapa
Posicin X
Posicin Y
Nombre
Nombre
Pg. 139
Descripcin
Plug-in
Nacin Multimedia
Mnimo (hbrido)
Head (hbrido)
Regin Multimedia
Mnimo (hbrido)
Head (hbrido)
Provincia Multimedia
Mnimo (hbrido)
Head (hbrido)
Ciudad Multimedia
Mnimo (hbrido)
Head (hbrido)
Nacin.nombre
Descripcin
Descripcin
Copyright
Direccin
Nacin.Nombre
Tipo Multimedia.Nombre
Regin.nombre
Descripcin
Descripcin
Copyright
Direccin
Regin.Nombre
Provinica.nombre
Descripcin
Descripcin
Copyright
Direccin
Provincia.Nombre
Ciudad.nombre
Descripcin
Descripcin
Copyright
Direccin
Ciudad.Nombre
Pg. 140
6.3.2. Alojamientos
Alojamiento
Mnimo
Head (hbrido)
Mapa Ciudad (hbrido)
Tipo Alojamiento
Mnimo
Head
Categora Alojamientos
Mnimo
Head
Cadena Alojamientos
Mnimo
Head (hbrido)
Alojamiento Multimedia
Mnimo (hbrido)
Nombre
Nombre
Ciudad.Nombre
Tipo Alojamiento.Nombre
Cadena Alojamientos.Nombre
Categora Alojamientos.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Nombre
Nombre
Descripcin
Nombre
Nombre
Ciudad.Nombre
Descripcin
Direccin
CP
Telfono
Fax
email
URL
Alojamiento.Nombre
Descripcin
Pg. 141
Head (hbrido)
Servicio Alojamientos
Mnimo
Head
Mnimo (hbrido)
Head (hbrido)
Habitaciones
Mnimo (hbrido)
Head (hbrido)
Tipo de Habitacin
Mnimo
Head
Temporada
Mnimo
Head
Rgimen Estancia
Mnimo
Head
Descripcin
Copyright
Direccin
Alojamiento.Nombre
Nombre
Nombre
Descripcin
Alojamiento.Nombre
Servicio Alojamientos.Nombre
Alojamiento.Nombre
Servicio Alojamientos.Nombre
Nmero
Habitacin
Alojamiento.Nombre
Tipo Habitacin.Nombre
Alojamiento.Nombre
Nmero
Nombre
Nombre
Descripcin
Nombre
Nombre
Descripcin
Fecha inicio
Fecha fin
Nombre
Nombre
Descripcin
Pg. 142
Precio Habitacin
Mnimo (hbrido)
Head (hbrido)
Alojamiento.Nombre
Rgimen Estancia.Nombre
Temporada.Nombre
Alojamiento.Nombre
Temporada.Nombre
Precio
Pg. 143
6.3.3. Playas
Playa
Mnimo
Head (hbrido)
Tipo Playa
Mnimo
Head
Playa Multimedia
Mnimo (hbrido)
Head (hbrido)
Servicio Playas
Mnimo
Head
Playa Servicio
Mnimo (hbrido)
Head (hbrido)
Nombre
Ciudad.Nombre
Tipo Playa.Nombre
Nombre
Descripcin
Localizacin
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Playa.Nombre
Descripcin
Descripcin
Copyright
Direccin
Playa.Nombre
Nombre
Nombre
Descripcin
Playa.Nombre
Servicio Playas.Nombre
Playa.Nombre
Servicio Playas.Nombre
Cantidad
Pg. 144
6.3.4. Deportes
Deporte
Mnimo
Head
Instalacin deportiva
Mnimo
Head (hbrido)
Deporte Instalacin
Mnimo (hbrido)
Head (hbrido)
Deporte Multimedia
Mnimo (hbrido)
Head (hbrido)
Instalacin Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Descripcin
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Pblico
Gratuito
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Instalacin deportiva.Nombre
Deporte.Nombre
Deporte.Nombre
Cantidad
Deporte.Nombre
Descripcin
Descripcin
Copyright
Direccin
Deporte.Nombre
Descripcin
Descripcin
Pg. 145
Copyright
Direccin
Servicio Deportes
Mnimo
Head
Instalacin Servicio
Mnimo (hbrido)
Head (hbrido)
Horario Instalacin
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Descripcin
Servicio Deportes.Nombre
Servicio Deportes.Nombre
Cantidad
Fecha inicio vigencia
Fecha fin vigencia
Da semana inicio
Da semana fin
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 146

Evento Cultural
Mnimo
Head (hbrido)
Evento Ciudad
Mnimo (hbrido)
Head (hbrido)
Tipo Evento
Mnimo
Head
Representacin
Mnimo
Head (hbrido)
Centro Cultural
Mnimo
Head (hbrido)
Nombre
Nombre
Tipo Evento.Nombre
Descripcin
Fecha Inicio
Fecha Fin
Evento Cultural.Nombre
Ciudad.Nombre
Ciudad.Nombre
Nombre
Nombre
Descripcin
Nombre
Nombre
Centro Cultural.Nombre
Fecha
Hora Inicio
Hora Fin
Gratuito
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Pg. 147
Eventos Multimedia
Mnimo (hbrido)
Head (hbrido)
Descripcin
Descripcin
Copyright
Direccin
Pg. 148

Monumento
Mnimo
Head (hbrido)
Tipo Monumento
Mnimo
Head
Periodo Histrico
Mnimo
Head
Monumento Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Tipo Monumento.Nombre
Periodo Histrico.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Visitas guiadas
Sala de proyecciones
Tienda
Pblico
Gratuito
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Nombre
Nombre
Descripcin
Ao inicio
Ao fin
Monumento.Nombre
Descripcin
Descripcin
Copyright
Direccin
Monumento.Nombre
Pg. 149
Servicio Monumentos
Mnimo
Head
Monumento Servicio
Mnimo (hbrido)
Head (hbrido)
Horario Monumento
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Descripcin
Monumento.Nombre
Servicio Monumentos.Nombre
Monumento.Nombre
Servicio Monumentos.Nombre
Cantidad
Monumento.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Monumento.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 150
6.3.7. Naturaleza
Naturaleza
Mnimo
Head (hbrido)
Naturaleza Ciudad
Mnimo (hbrido)
Head (hbrido)
Tipo Naturaleza
Mnimo
Head
Naturaleza Multimedia
Mnimo (hbrido)
Head (hbrido)
Servicio Natural
Mnimo
Head
Naturaleza Servicio
Mnimo (hbrido)
Head (hbrido)
Nombre
Tipo Naturaleza.Nombre
Nombre
Descripcin
Localizacin
Pblico
Gratuito
Naturaleza.Nombre
Ciudad.Nombre
Naturaleza.Nombre
Ciudad.Nombre
Ciudad.Mapa
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Naturaleza.Nombre
Descripcin
Descripcin
Copyright
Direccin
Naturaleza.Nombre
Nombre
Nombre
Descripcin
Naturaleza.Nombre
Servicio Natural.Nombre
Naturaleza.Nombre
Pg. 151
Servicio Natural.Nombre
Cantidad
Pg. 152
Entretenimiento
Mnimo
Head (hbrido)
Tipo Entretenimiento
Mnimo
Head
Entretenimiento Multimedia
Mnimo (hbrido)
Head (hbrido)
Horario Entretenimiento
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Tipo Entretenimiento.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Gratuito
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Entretenimiento.Nombre
Descripcin
Descripcin
Copyright
Direccin
Fecha fin vigencia
Da semana inicio
Da semana fin
Fecha fin vigencia
Pg. 153
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 154
6.3.9. Restaurantes
Restaurante
Mnimo
Head (hbrido)
Tipo Restaurante
Mnimo
Head
Restaurante Multimedia
Mnimo (hbrido)
Head (hbrido)
Categora Restaurante
Mnimo
Head
Horario Restaurante
Mnimo (hbrido)
Nombre
Nombre
Ciudad.Nombre
Tipo Restaurante.Nombre
Categora Restaurante.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Restaurante.Nombre
Descripcin
Descripcin
Copyright
Direccin
Restaurante.Nombre
Nombre
Nombre
Descripcin
Restaurante.Nombre
Fecha fin vigencia
Pg. 155
Head (hbrido)
Da semana inicio
Da semana fin
Restaurante.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 156
6.3.10. Rent-a-car
Rent-a-car
Mnimo
Head (hbrido)
Cadena Rent-a-car
Mnimo
Head (hbrido)
Rent-a-car Multimedia
Mnimo (hbrido)
Head (hbrido)
Horario Rent-a-car
Mnimo (hbrido)
Nombre
Nombre
Ciudad.Nombre
Cadena Rent-a-car.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Monumento.Nombre
Descripcin
Descripcin
Copyright
Direccin
Monumento.Nombre
Rent-a-car.Nombre
Pg. 157
Head (hbrido)
Fecha fin vigencia

Da semana inicio
Da semana fin
Rent-a-car.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 158
6.3.11. Tienda
Tienda
Mnimo
Head (hbrido)
Tipo Tienda
Mnimo
Head
Cadena Tiendas
Mnimo
Head (hbrido)
Tienda Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Cadena Tiendas.Nombre
Tipo Tienda.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Tienda.Nombre
Descripcin
Descripcin
Copyright
Pg. 159
Direccin
Tienda.Nombre
Horario Tienda
Mnimo (hbrido)
Head (hbrido)
Tienda.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Tienda.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 160

Aeropuerto
Mnimo
Head (hbrido)
Vuelo
Mnimo
Head (hbrido)
Tipo Tarifa Area

Mnimo
Head
Precio
Mnimo (hbrido)
Head (hbrido)
ID Aeropuerto
Nombre
Ciudad.Nombre
ID Aeropuerto
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
ID Vuelo
Descripcin
ID Vuelo
Descripcin
Aeropuerto salida.Nombre
Aeropuerto llegada.Nombre
Compaa Transportes.Nombre
Vuelo directo
Nombre
Nombre
Descripcin
ID Vuelo
Vuelo.Descripcin
Tipo Tarifa Area.Nombre
Fecha fin vigencia
ID Vuelo
Vuelo.Descripcin
Pg. 161
Tipo Tarifa Area.Nombre

Precio
Fecha fin vigencia
Compaa Transportes
Mnimo
Head (hbrido)
Horario Vuelo
Mnimo (hbrido)
Head (hbrido)
Aeropuerto Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
ID Vuelo
Vuelo.Descripcin
Fecha fin vigencia
ID Vuelo
Vuelo.Descripcin
Fecha fin vigencia
Hora salida
Hora llegada
Lunes
Martes
Mircoles
Jueves
Viernes
Sbado
Domingo
Aeropuerto.Nombre
Descripcin
Descripcin
Copyright
Direccin
Aeropuerto.Nombre
Pg. 162
Mnimo (hbrido)
Head (hbrido)
Descripcin
Descripcin
Copyright
Direccin
Pg. 163

Puerto
Mnimo
Head (hbrido)
Trayecto
Mnimo
Head (hbrido)
Tipo Pasaje
Mnimo
Head
Precio Pasaje
Mnimo (hbrido)
Head (hbrido)
Nombre
Ciudad.Nombre
Nombre
Ciudad.Nombre
Longitud
Latitud
Profundidad mxima
Profundidad mnima
Estrechez
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Descripcin
Descripcin
Puerto salida.Nombre
Puerto llegada.Nombre
Trayecto directo
Nombre
Nombre
Descripcin
Trayecto.Descripcin
Tipo Pasaje.Nombre
Fecha fin vigencia
Trayecto.Descripcin
Tipo Pasaje.Nombre
Pg. 164
Precio
Fecha fin vigencia
Compaa Transportes
Mnimo
Head (hbrido)
Horario Trayecto
Mnimo (hbrido)
Head (hbrido)
Puerto Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Trayecto.Descripcin
Fecha fin vigencia
Da semana inicio
Da semana fin
Trayecto.Descripcin
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora salida
Hora llegada
Da semana inicio
Da semana fin
Vehculos
Nombre barco
Puerto.Nombre
Descripcin
Descripcin
Copyright
Direccin
Puerto.Nombre
Pg. 165
Mnimo (hbrido)
Head (hbrido)
Descripcin
Descripcin
Copyright
Direccin
Pg. 166

Estacin
Mnimo
Head (hbrido)
Lnea
Mnimo
Head (hbrido)
Medio Tranporte
Mnimo
Head
Parada
Mnimo (hbrido)
Head (hbrido)
Compaa Transportes
Mnimo
Head (hbrido)
Nombre
Ciudad.Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Descripcin
Medio Transporte.Nombre
Nmero paradas
Nombre
Nombre
Estacin.Nombre
Lnea.Nombre
Estacin.Nombre
Lnea.Nombre
Nmero orden
Nombre
Nombre
Ciudad.Nombre
Descripcin
Pg. 167
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Horario Tr. Terrestre

Mnimo (hbrido)
Head (hbrido)
Estacin Multimedia
Mnimo (hbrido)
Head (hbrido)
Mnimo (hbrido)
Head (hbrido)
Lnea.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora salida
Lnea.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora salida
Hora llegada
Precio
Estacin.Nombre
Descripcin
Descripcin
Copyright
Direccin
Estacin.Nombre
Descripcin
Descripcin
Copyright
Direccin
Pg. 168

Lnea Urbana
Mnimo (hbrido)
Head (hbrido)
Parada Urbana
Mnimo (hbrido)
Head (hbrido)
Parada Lnea
Mnimo (hbrido)
Head (hbrido)
Horario Urbano
Mnimo (hbrido)
Head (hbrido)
Nombre
Ciudad.Nombre
Compaa Urbana.Nombre
Nombre
Ciudad.Nombre
Compaa Urbana.Nombre
Descripcin
Direccin
Ciudad.Nombre
Direccin
Ciudad.Nombre
Localizacin
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Lnea.Nombre
Parada Urbana.Direccin
Lnea.Nombre
Lnea Urbana.Nombre
Fecha fin vigencia
Lnea Urbana.Nombre
Fecha fin vigencia
Primera salida origen
ltima salida origen
Primera salida destino
ltima salida destino
Frecuencia de paso
Precio billete ordinario
Precio bono 10 billetes
Pg. 169
Compaa Transportes
Mnimo
Head (hbrido)
Mnimo (hbrido)
Head (hbrido)
Parada Alojamiento
Mnimo (hbrido)
Head (hbrido)
Parada Playa
Mnimo (hbrido)
Head (hbrido)
Parada Instalacin
Mnimo (hbrido)
Head (hbrido)
Parada Museo
Mnimo (hbrido)
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Descripcin
Descripcin
Copyright
Direccin
Alojamiento.Nombre
Alojamiento.Nombre
Playa.Nombre
Playa.Nombre
Instalacin Deportiva.Nombre
Instalacin Deportiva.Nombre
Museo.Nombre
Pg. 170
Head (hbrido)
Parada Naturaleza
Mnimo (hbrido)
Head (hbrido)
Parada Entretenimiento
Mnimo (hbrido)
Head (hbrido)
Parada Restaurante
Mnimo (hbrido)
Head (hbrido)
Parada Rent-a-car
Mnimo (hbrido)
Head (hbrido)
Parada Tienda
Mnimo (hbrido)
Head (hbrido)
Parada Aeropuerto
Mnimo (hbrido)
Head (hbrido)
Museo.Nombre
Naturaleza.Nombre
Naturaleza.Nombre
Restaurante.Nombre
Restaurante.Nombre
Rent-a-car.Nombre
Rent-a-car.Nombre
Tienda.Nombre
Tienda.Nombre
Aeropuerto.Nombre
Aeropuerto.Nombre
Parada Puerto
Pg. 171
Mnimo (hbrido)
Head (hbrido)
Parada Estacin
Mnimo (hbrido)
Head (hbrido)
Parada Informacin
Mnimo (hbrido)
Head (hbrido)
Parada Agencia
Mnimo (hbrido)
Head (hbrido)
Puerto.Nombre
Puerto.Nombre
Estacin.Nombre
Estacin.Nombre
Informacin.Nombre
Informacin.Nombre
Agencia.Nombre
Agencia.Nombre
Pg. 172
6.3.16. Taxis
Taxi
Mnimo
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Pg. 173

Oferta Promocional
Mnimo (hbrido)
Head (hbrido)
Rgimen Estancia
Mnimo
Head
Precio Oferta
Mnimo (hbrido)
Head (hbrido)
Nombre
Ciudad.Nombre
Alojamiento.Nombre
Cadena Ag. Viajes.Nombre
Nombre
ID Ciudad
ID Alojamiento
ID Cadena Ag. Viajes
Descripcin
Excursiones
Coche de alquiler
Nombre
Nombre
Descripcin
Oferta.Nombre
Fecha fin vigencia
Oferta.Nombre
Fecha fin vigencia
Precio
Pg. 174
6.3.18. Excursiones
Excursin
Mnimo (hbrido)
Head (hbrido)
Medio Tranporte
Mnimo
Head
Excursin Ciudad
Mnimo
Head
Excursin Multimedia
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Descripcin
Punto de partida
Punto final
Recorrido
Duracin
Dificultad
Transportes
Valor historico-natural
Mapa
Nombre
Nombre
Excursin.Nombre
Ciudad.Nombre
Excursin.Nombre
Ciudad.Nombre
Excursin.Nombre
Descripcin
Descripcin
Copyright
Direccin
Excursin.Nombre
Pg. 175

Informacin
Mnimo
Head (hbrido)
Horario Informacin
Mnimo (hbrido)
Head (hbrido)
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Gratuito
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Informacin.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Informacin.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 176

Agencia
Mnimo
Head (hbrido)
Cadena Agencias
Mnimo
Head (hbrido)
Agencia Multimedia
Mnimo (hbrido)
Head (hbrido)
Horario Agencia
Mnimo (hbrido)
Nombre
Nombre
Ciudad.Nombre
Cadena Agencias.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Ciudad.Mapa
Localizacin
Posicin X
Posicin Y
Nombre
Nombre
Ciudad.Nombre
Descripcin
Localizacin
Direccin
CP
Telfono
Fax
email
URL
Agencia.Nombre
Descripcin
Descripcin
Copyright
Direccin
Agencia.Nombre
Agencia.Nombre
Pg. 177
Head (hbrido)

Fecha fin vigencia
Da semana inicio
Da semana fin
Agencia.Nombre
Fecha fin vigencia
Da semana inicio
Da semana fin
Hora apertura maana
Hora cierre maana
Hora apertura tarde
Hora cierre tarde
Pg. 178
6.4. 3 Etapa: Diseo navegacional

Notas:
Como enlaces unidireccionales slo marcamos los que no tienen ninguna
primitiva de acceso. En el caso de que s la haya, se sobre-entiende que hay un
camino de vuelta, y por tanto, no es necesario representarlo. En el primer caso s
es necesario reflejar explcitamente que habr un enlace entre ambas entidades.
Al hacer el estudio de las relaciones complejas, hemos etiquetado los tres tipos
diferentes con una letra que se les dio al definirlas en el apartado 4.3..
Recordemos:
A: accesos jerrquicos
B: accesos en relaciones N:M
C: accesos mltiples
Pg. 179

Etapa 3.1. Estudio de las relaciones complejas
Relacin
Nacin-Regin-Provincia
Nacin-Regin-ProvinciaCiudad
Regin-Provincia-Ciudad
Tipo Descripcin
A Es til poder acceder a las provincias de una
nacin, porque se puede dar el caso de que uno
conozca la provincia en la que est interesado,
pero no el nombre de la regin.
A dem
A
dem
No tienen inters las relaciones del tipo Nacin-Nacin Multimedia-Tipo Multimedia,

etc., porque lo que se desea es que de una nacin se puedan ver todos los objetos
multimedia, independientemente de si son vdeos, imgenes, ...
Tampoco tienen inters las relaciones del tipo Nacin-Regin-Regin Multimedia,
porque una nacin ya tiene asignados una serie de elementos multimedia y, por tanto, no
tiene sentido permitir ver todos los de sus regiones
Slices derivados de las relaciones complejas
En las relaciones de tipo A (accesos jerrquicos), no es necesario ningn cambio en la
definicin de los slices.
Etapa 3.2. Diagrama RMDM
Pg. 180
Nacin
Regin
Nacin
Multimedia
Regin
Multimedia
Provincia
Provincia
Multimedia
Ciudad
Ciudad
Multimedia
Tipo
Multimedia
Pg. 181
6.4.2. Alojamientos
A pesar de que una cadena de alojamientos est situada en una ciudad (su sede central),
esta informacin no tiene inters para el usuario, en el sentido de que no es til ver un
ndice de las cadenas de hotel afincadas en una ciudad. El motivo es que no se consider
que la cadena sea una informacin de inters turstico. A la informacin de cadena se
puede llegar (se supone que muy espordicamente) desde el hotel. Tampoco tiene
ninguna utilidad que desde una cadena se pase a visitar la ciudad en la que est afincada.
Relacin
Alojamiento-Alojamiento
Servicio-Servicio
Alojamientos
Tipo Descripcin
B Se trata de una relacin N:M y lo que interesa es
acceder de un alojamiento a sus servicios. En
particular deseamos ver todos los servicios a la
vez.
Alojamiento-Tipo
C Nos interesa acceder de un alojamiento a la
Habitacin-Habitaciones
informacin de sus habitaciones, seleccionando
qu tipo de habitacin
Habitaciones-TemporadaC En este caso nos interesa acceder desde una
Rgimen
Estancia-Precio
habitacin a su precio, eligiendo primero la
Habitacin
temporada y el rgimen de estancia.
No es necesario ningn cambio en ninguna de las tres relaciones. En la primera, ya que
la entidad Alojamiento Servicio no tiene ningn atributo propio (provienen de la
relacin N:M) y por tanto no es necesario que le ceda ningn atributo a la entidad
Servicio Alojamientos. En la segunda y tercera, los slices head de Precio Habitacin y
Habitaciones, ya fueron definidos como hbridos y contienen los atributos necesarios
que surgen de la relacin.

Nota: nos es necesaria una nueva primitiva para representar el acceso condicionado a
todos los elementos de una entidad a la vez. En este caso, si estamos en un alojamiento,
con esta primitiva accedemos a todos sus alojamientos simultneamente, todos a la vez,
y no mediante un ndice o uno tras otro en una visita guiada. Lo reflejaremos con la
siguiente primitiva y la llamaremos acceso simultneo:
Pg. 182
Cadena
Alojamientos
Ciudad
Tipo
Multimedia
Tipo
Alojamiento
Alojamiento
Multimedia
Alojamiento
Categora
Alojamientos
Tipo
Habitacin
Servicio
Alojamientos
Habitaciones
Rgimen
Estancia
Temporada
Precio
Habitacin
NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las
entidades Regin, Provincia y Nacin (los mismos que Ciudad)
Pg. 183
6.4.3. Playas
Relacin
Tipo Descripcin
Playa-Playa Servicio-Servicio B Se trata de una relacin N:M y lo que interesa es
Playas
acceder de una playa a los servicios de la
misma. En particular, deseamos ver todos los
servicios a la vez.
No es necesario ningn cambio, ya que la entidad Playa Servicio no tiene ningn
atributo propio (provienen de la relacin N:M).
Ciudad
Tipo
Playa
Playa
Multimedia
Playa
Playa Servicio
Tipo
Multimedia
Servicio
Playas

Pg. 184
6.4.4. Deportes
Relacin
Tipo Descripcin
Instalacin
deportiva- B Se trata de una relacin N:M y lo que interesa es
Instalacin Servicio-Servicio
acceder de una instalacin a los servicios de la
Deportes
misma
Instalacin
Deportiva- B Se trata de una relacin N:M y lo que interesa es
Deporte Instalacin- Deporte
acceder de una instalacin deportiva a los
deportes que en ella se practican
No es necesario ningn cambio en la segunda relacin, ya que la entidad Instalacin
Servicio no tiene ningn atributo propio (provienen de la relacin N:M).
En cambio s lo es en el caso de Deporte Instalacin, ya que es necesario ver la cantidad,
por ejemplo la cantidad de pistas de tenis que hay en un polideportivo determinado. Para
ello es necesario crear un nuevo slice en la entidad Deporte para que tenga en cuenta
esta cantidad, y el acceso no se har a travs del slice head, sino de este slice nuevo.
Pero como que la entidad Deporte slo es accedida a travs de este enlace, y no desde
ningn otro lugar, se puede eliminar el slice head anterior y sustituirlo directamente por
ste. Evidentemente, esto no sera conveniente si la entidad fuera accedida desde otro
lugar.
Deporte
Head (hbrido)
Nombre
Descripcin
Deporte Instalacin.Cantidad
Pg. 185
Deporte
Ciudad
Deporte
Multimedia
Deporte Instalacin
Tipo
Multimedia
Instalacin
deportiva
Instalacin
Multimedia
InstalacinServicio
Horario
Instalacin
Servicio
Deportes

Pg. 186

Relacin
Tipo Descripcin
Ciudad-Evento Ciudad-Evento B Se trata de una relacin N:M y lo que interesa
Cultural
es acceder de una ciudad a todos sus eventos
culturales.
Evento
Cultural-Evento B En este caso tambin nos interesa saber en qu
Ciudad- Ciudad
ciudades se da un evento cultural y poder
navegar a ellas.
Se podra haber incluido tambin un acceso jerrquico de ciudad a representacin, pero
se estim que no era conveniente.
No es necesario ningn cambio, ya que la entidad Evento Ciudad no tiene ningn

Tipo
Evento
Evento Ciudad
Evento
Cultural
Ciudad
Evento Ciudad
Eventos
Multimedia
Centro
Cultural
Represent
acin
Tipo
Multimedia

Pg. 187

Relacin
Tipo Descripcin
Monumento-Monumento
B Se trata de una relacin N:M y lo que interesa
Servicio-Servicio Monumentos
es acceder de un monumento a los servicios
del mismo. En este caso nos interesa acceder a
todos los servicios a la vez.
No es necesario ningn cambio, ya que la entidad Monumento Servicio no tiene ningn
Ciudad
Tipo
Multimedia
Tipo
Monumento
Monumento
Monumento
Multimedia
Periodo
Histrico
Monumento Servicio
Horario
Monumento
Servicio
Monumento
Pg. 188
6.4.7. Naturaleza
Relacin
Ciudad-Naturaleza
Naturaleza
Tipo Descripcin
Ciudad- B Se trata de una relacin N:M y lo que interesa
es acceder de una ciudad a todas sus reas
naturales.
Naturaleza -Naturaleza Ciudad- B En este caso tambin nos interesa saber a qu
Ciudad
ciudades pertenece un rea natural y poder
navegar a ellas.
Naturaleza-Naturaleza
B Se trata de una relacin N:M y lo que nos
Servicio-Servicio Natural
interesa es ver todos los servicios de un rea
natural
No es necesario ningn cambio, ya que tanto la entidad Naturaleza Ciudad como
Naturaleza Servicio no tiene ningn atributo propio (provienen en ambos casos de la
relacin N:M).
Ciudad
Naturaleza Ciudad
Tipo
Naturaleza
Naturaleza Ciudad
Naturaleza
Naturaleza Servicio
Naturaleza
Multimedia
Tipo
Multimedia
Servicio
Natural
Pg. 189
En esta categora no se observan nuevas estructuras navegacionales derivadas de
relaciones complejas.
Ciudad
Tipo
Entretenimiento
Entretenimiento
Entretenimiento
Multimedia
Tipo
Multimedia
Horario
Entretenimiento
Pg. 190
6.4.9. Restaurantes
Ciudad
Horario
Restaurante
Tipo
Restaurantes
Restaurante
Categora
Restaurante
Restaurante
Multimedia
Tipo
Multimedia
Pg. 191
6.4.10. Rent-a-car
Tampoco aqu, como en alojamientos, las cadenas de rent-a-cars tienen inters turstico.
Ciudad
Horario
Rent-a-car
Cadena
Rent-a-car
Rent-a-car
Rent-a-car
Multimedia
Tipo
Multimedia
Pg. 192
6.4.11. Tienda
Igualmente se consider que las cadenas de tiendas no tienen inters turstico y tampoco
mantendrn navegacin con la entidad ciudad.
Ciudad
Horario
Tienda
Cadena
Tiendas
Tienda
Tipo
Tienda
Tienda
Multimedia
Tipo
Multimedia
Pg. 193

Relacin
Vuelo-Tipo Tarifa
Precio Vuelo
Tipo Descripcin
Area- C Una vez seleccionado un vuelo lo que interesa
conocer es lo que nos va a costar segn el tipo
de tarifa que elijamos.
De nuevo se consider que las compaas de transporte, igual que ocurri con las
cadenas de tiendas o de rent-a-cars, no tienen inters turstico y tampoco mantendrn
navegacin con la entidad ciudad.
No es necesario ningn cambio, ya que el nombre del tipo de tarifa ya est incluido en el
slice head de Precio Vuelo, que ya fue definido como hbrido.
Pg. 194
Ciudad
Aeropuerto
Aeropuerto
Multimedia
Tipo
Multimedia
Tipo Tarifa
Area
Vuelo
Precio
Vuelo
Compaa
Transportes
Ciudad
Horario
Vuelo
Ca Transportes
Multimedia
Tipo
Multimedia

Pg. 195

Relacin
Tipo Descripcin
Trayecto-Tipo Pasaje-Precio C Una vez seleccionado un trayecto en barco lo
Pasaje
que interesa conocer es lo que nos va a costar
segn el tipo de pasaje que elijamos (camarote,
butaca, vehculo turismo, ...).
No es necesario ningn cambio, ya que el nombre del tipo de pasaje ya est incluido en
el slice head de Precio Pasaje, que ya fue definido como hbrido.

Ciudad
Puerto
Puerto
Multimedia
Tipo
Multimedia
Tipo
Pasaje
Trayecto
Precio
Pasaje
Compaa
Transportes
Ciudad
Horario
Trayecto
Ca Transportes
Multimedia
Tipo
Multimedia

Pg. 196

Relacin
Estacin-Parada-Lnea
Lnea-Parada-Estacin
Tipo Descripcin
B Se trata de una relacin N:M y lo que interesa
es acceder de una estacin a las lneas que
pasan por ella, con el fin de saber a donde se
puede llegar.
B En este caso tambin nos interesa saber por
qu estaciones pasa la lnea seleccionada.

No es necesario ningn cambio, ya que la entidad Parada no tiene ningn atributo propio
(provienen de la relacin N:M).
Pg. 197
Ciudad
Estacin
Multimedia
Estacin
Tipo
Multimedia
Parada
Parada
Horario
Tr. Terrestre
Lnea
Medio
Transporte
Compaa
Transportes
Ca Transportes
Multimedia
Ciudad
Tipo
Multimedia

Pg. 198

Relacin
Tipo Descripcin
Parada Urbana-Parada Lnea- B Se trata de una relacin N:M y lo que interesa
Lnea Urbana
es acceder de una parada urbana a las lneas
que pasan por ella, con el fin de saber a donde
se puede llegar.
Lnea Urbana-Parada Lnea- B En este caso tambin nos interesa saber por
Parada Urbana
qu paradas pasa la lnea seleccionada.
Parada
Urbana-Parada B Se trata de una relacin N:M y lo que interesa
Alojamiento-Alojamiento
es acceder de una parada urbana a los
alojamientos cercanos a ella.
Alojamiento-Parada
B En este caso tambin nos interesa saber qu
Alojamiento-Parada Urbana
paradas hay cercanas a un alojamiento
Parada Urbana-Parada Playa- B Se trata de una relacin N:M y lo que interesa
Playa
es acceder de una parada urbana las playas
cercanas a ella.
Playa-Parada
Playa-Parada B En este caso tambin nos interesa saber qu
Urbana
paradas hay cercanas a una playa
Parada
Instalacin-Instalacin
es acceder de una parada urbana a las
Deportiva
instalaciones deportivas cercanas a ella.
Instalacin Deportiva-Parada B En este caso tambin nos interesa saber qu
Instalacin-Parada Urbana
paradas hay cercanas a una instalacin
deportiva
Parada Urbana-Parada Museo- B Se trata de una relacin N:M y lo que interesa
Museo
es acceder de una parada urbana a los museos
cercanos a ella.
Museo-Parada Museo-Parada B En este caso tambin nos interesa saber qu
Urbana
paradas hay cercanas a un museo
Parada
Naturaleza- Naturaleza
es acceder de una parada urbana a las reas
naturales cercanas a ella.
Naturaleza-Parada Naturaleza- B En este caso tambin nos interesa saber qu
Parada Urbana
paradas hay cercanas a un rea natural
Parada
Entretenim.- Entretenim.
entretenimientos cercanos a ella.
Entretenim.-Parada
Entretenim.-Parada Urbana
paradas hay cercanas a un entretenimiento
Parada
Restaurante- Restaurante
restaurantes cercanos a ella.
Restaurante-Parada
Restaurante-Parada Urbana
paradas hay cercanas a un restaurante
Parada Urbana-Parada Rent-a- B Se trata de una relacin N:M y lo que interesa
Pg. 199
car- Rent-a-car
Rent-a-car-Parada Rent-a-carParada Urbana
Parada Urbana-Parada TiendaTienda
Tienda-Parada Tienda-Parada
Urbana
Parada
Urbana-Parada
Aeropuerto- Aeropuerto
Aeropuerto-Parada AeropuertoParada Urbana

Parada Urbana-Parada PuertoPuerto
Puerto-Parada Puerto-Parada
Urbana
Parada
Urbana-Parada
Estacin- Estacin
Estacin-Parada
EstacinParada Urbana
Parada
Urbana-Parada
Informacin- Informacin
Informacin-Parada
Informacin-Parada Urbana
Parada
Urbana-Parada
Agencia- Agencia
Agencia-Parada
Parada Urbana
Agencia-
es acceder de una parada urbana a los rent-acars cercanos a ella.

En este caso tambin nos interesa saber qu
paradas hay cercanas a un rent-a-car
Se trata de una relacin N:M y lo que interesa
es acceder de una parada urbana a las tiendas
cercanas a ella.
paradas hay cercanas a una tienda
aeropuertos (difcilmente habr ms de uno)
cercanos a ella.
paradas hay cercanas a un aeropuerto
es acceder de una parada urbana a los puertos
(difcilmente habr ms de uno) cercanos a
ella.
paradas hay cercanas a un puerto
es acceder de una parada urbana a las
estaciones cercanas a ella.
paradas hay cercanas a una estacin
es acceder de una parada urbana a los puntos
de informacin turstica cercanos a ella.
paradas hay cercanas a un punto de
informacin turstica
es acceder de una parada urbana a las agencias
cercanas a ella.
paradas hay cercanas a una agencia

No es necesario ningn cambio, ya que en todas las entidades intermedias de la
relaciones, ninguna de ellas tiene ningn atributo propio (todos provienen de la relacin
N:M).
Pg. 200

Tipo
Multimedia
Alojamiento
P. Alojamiento
P. Alojamiento
Compaa
Transportes
Ciudad
Ca Transportes
Multimedia
P. Playa
Playa
P. Playa
P. Instalac.
Lnea
Urbana
Horario
Urbano
Instalac.
Deportiva
P. Instalac.
P. Museo
Museo
P. Museo
ParadaLnea
P. Naturaleza
Naturaleza
ParadaLnea
P. Naturaleza
Entretenim.
P. Entertenim.
P. Entretenim.
P. Resturante
Restaurante
P. Resturante
P. Rent-a-car
Parada
Urbana
Rent-a-car
P. Rent-a-car
P. Tienda
Tienda
P. Tienda
P. Aeropuerto
Aeropuerto
Ciudad
P. Aeropuerto
P. Puerto
Puerto
P. Puerto
P. Estacin
Estacin
P. Estacin
P. Informacin
Informacin
P. Infromacin
P. Agencia
Agencia
P. Agencia

Pg. 201
6.4.16. Taxis
Esta categora se refiere a paradas de taxis. Su estructura es la ms simple: slo est
relacionada con la ciudad, ni siquiera tienen sentido objetos multimedia.
Ciudad
Taxi
Pg. 202

Relacin
Tipo Descripcin
Oferta Promocional-Rgimen C Una vez seleccionado una oferta lo que interesa
Estancia-Precio Oferta
conocer es lo que nos va a costar segn el tipo
de rgimen de estancia que elijamos.
No es necesario ningn cambio, ya que el slice head de Precio Oferta, ya fue definido
como hbrido y contiene la informacin necesaria de las otras entidades.

Cadena
Ag. Viajes
Alojamiento
Oferta
Promocional
Ciudad
Rgimen
Estancia
Precio
Oferta
Pg. 203
6.4.18. Excursiones
Relacin
Ciudad-Excursin
Excursin
Excursin-Excursin
Ciudad
Tipo Descripcin
Ciudad- B Se trata de una relacin N:M y lo que interesa
es acceder de una ciudad a todas excursiones.
Ciudad- B En este caso tambin nos interesa saber por
qu ciudades (municipios) discurre una
excursin y as poder navegar a ellas.

No es necesario ningn cambio, ya que la entidad Excursin Ciudad no tiene ningn

Medio
Transporte
Excursin
Excursin
Multimedia
Excursin Ciudad
Excursin Ciudad
Tipo
Multimedia
Ciudad
Pg. 204

Ciudad
Informacin
Horario
Informacin
Pg. 205


Cadena
Ag. Viajes
Cadena A.V.
Multimedia
Tipo
Multimedia
Agencia
Viajes
Ciudad
Horario
Agencia

Pg. 206
6.4.21. Jerarqua de mens

En el men principal se permite el acceso a los cuatro niveles de reas geogrficas.
Adems, una quinta opcin permite acceder a ndices por categoras. Esta opcin nos
lleva a un nuevo men donde se accede mediante ndice a cada una de las categoras del
sistema. Con ello se permite la bsqueda rpida a un elemento ya conocido, sin
necesidad de tener que ir a su rea geogrfica, con la consiguiente ganancia de tiempo.
Veamos el diagrama:
Pg. 207
Alojamiento
Playa
Nacin
Regin
Provincia
Ciudad
Instalacin
Deportiva
Evento
Cultural
Monumento
Naturaleza
Entretenimiento
Restaurante
Ren-a-car
Tienda
Aeropuerto
Puerto
Estacin
Lnea
Urbana
Taxi
Oferta
Promocional
Excursin
Informacin
Agencia
Viajes
Pg. 208
6.5. Etapas 4 a 7: Interfaz de usuario y construccin

A pesar de que nuestro modelo no lleg a ser implementado y el proyecto europeo tom
otras soluciones, presentamos aqu las ideas que tenamos par las posteriores etapas:
Etapa 4: Diseo de protocolos de conversin

MINTour utiliza la base de datos Oracle. Por tanto, los protocolos de conversin son
muy simples: cada entidad da lugar a una tabla. Cada slice se obtiene a partir de una
vista, y los mecanismos de acceso no son ms que sentencias de consulta a la base de
datos utilizando SQL (en concreto PL-SQL).
Etapa 5: Diseo de la interfaz de usuario

La idea del diseo de la interfaz era bastante simple, basada en la idea base que se dio al
comentar esta etapa en el apartado de mejoras a la metodologa RMM.
En concreto, la idea era la de utilizar frames (marcos) para dividir la pantalla en varias
reas. Una, la principal, es donde aparece la informacin correspondiente a un slice de
un elemento de una entidad. Otra, en un costado o abajo, contiene segn los accesos
obtenidos del modelo RMDM, los enlaces HTML a otras entidades. Cada uno de esos
enlaces est representado con un texto (por ejemplo: Alojamientos) o con un icono. En
un tercer frame, ms pequeo, aparecen los enlaces estructurales, es decir, cmo ir del
slice que est en pantalla a los otros slices de esa entidad. Por ltimo, es necesario un
ltimo frame para los mecanismos generales de navegacin, tales como volver al men,
volver a la ltima pantalla, ... Ntese que en vez de utilizar frames tambin pueden
emplearse tablas, segn las preferencias del diseador, ya que el objetivo de dividir la
pantalla en diferentes zonas se puede conseguir tambin con el uso de tablas.
Vemos un ejemplo en la siguiente imagen, tomada de un sencillo prototipo de la entidad
Museos y monumentos a partir de nuestro anlisis. En el frame principal, el que de
fondo blanco, aparece la informacin del elemento concreto al que se ha accedido.
Concretamente se trata de la Catedral de Palma y se ha llegado hasta aqu desde el
ndice de monumentos de dicha ciudad. Vemos que se ha accedido al slice head, y se
muestran todos sus atributos. En la parte superior de este frame, aparecen en un
recuadro negro los slices de la entidad, que es el de informacin (el head), que est
activo, y el de mapa. Al pulsar se ira a dicho slice. Ntese que tambin estn
representados los hiperenlaces a las entidades Ciudad, Provincia, Regin, Nacin, Tipo
de Monumento y Periodo Histrico, algunos enlaces directos y como el caso de
Provincia, Regin, Nacin inferidos de la relacin jerrquica.
En la parte izquierda tenemos dos frames diferentes, uno el de la navegacin a otras
entidades, que nos permite ir a ver los elementos multimedia, servicios, horarios y
parada de transporte urbano ms cercano. Por ltimo, en el frame inferior derecho
tenemos las herramientas de navegacin general, como son en este caso volver al ndice
de monumentos de Palma, volver atrs en la navegacin e ir a la home page.
Pg. 209
Etapa 6: Diseo del comportamiento en tiempo de ejecucin

En esta etapa se deban disear los algoritmos y programas para el control de la
navegacin, mecanismo de historia, etc. En MINTour se utilizan CGIs utilizando el
producto Oracle WebServer, que permite una conexin entre el servidor web y la base
de datos. Para ello se utiliza el lenguaje de programacin PL-SQL, que es una versin
procedimental, propia de Oracle, de SQL, el lenguaje estndar de acceso a bases de
datos.
Etapa 7: Construccin y tests

Dado que la aplicacin basada en nuestro modelo no ha llegado a implementarse, esta
etapa no merece ningn comentario.
Pg. 210
6.6. Conclusiones
Este anlisis, al tratarse de un proyecto tan grande, con tantas entidades y relaciones, nos
ha sido de gran utilidad a la hora de descubrir nuevos patrones de navegacin, y fue la
base para las mejoras a la metodologa RMM que propusimos en el apartado 4.3. Al
final de este apartado se resumen.
A pesar de que finalmente nuestras ideas no han sido utilizadas en el proyecto europeo,
el modelo final que hemos obtenido constituye un interesante modelo de navegacin,
ms consistente e intuitivo que el existente. De hecho, el proyecto europeo dej de lado
la lnea de un proyecto multimedia, para convertirse en un simple recuperador de
informacin de la base de datos, sin ninguna navegacin posible entre sus elementos. En
cambio nuestra solucin dara lugar a un sistema en el cual el usuario navegara, igual
que podra navegar virtualmente por Europa, en vez de hacer una consulta tras otra,
definiendo complicadas bsquedas a la base de datos. Desde nuestro punto de vista, sta
es la diferencia fundamental entre una aplicacin multimedia-hipermedia y una de
gestin: en la primera lo importante es la navegacin y en la segunda la recuperacin
exacta de los datos que el usuario desea. Pero, pensamos que la situacin es que el
usuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entrar
en el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas que
tienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de una
tienda y ofrecen visitas guiadas.
En cuanto a la estructura de los datos, las relaciones entre unas categoras y otras han
resultado ser bastante poco abundantes. El hecho de que las categoras no estn apenas
relacionadas entre s viene determinado por la estructura de la informacin de MINTour,
muy jerarquizada, donde prcticamente toda la informacin son diferentes elementos
tursticos de una ciudad. Es por ello que cada una de las categoras est relacionada con
las reas geogrficas, pero no entre s, salvo alguna excepcin como la de los transportes
urbanos. En el siguiente caso de estudio, el CD-ROM del Atles de les Illes Balears, la
estructura de la informacin es bien diferente, mucho ms rica, con muchas ms interrelaciones entre los datos, y se presta mejor a un anlisis navegacional.
Resumen de las nuevas aportaciones a la metodologa
El anlisis de MINTour nos ha servido para aadir una serie de mejoras a la
metodologa RMM, que ya fueron explicadas en el captulo IV.
Se trata de los accesos complejos, que recordemos del captulo IV, podan ser de tres
tipos:
navegacin jerrquica: permiten acceder desde una entidad directamente a otra
entidad que est relacionada con una entidad que est por debajo de la jerarqua
de la primera. Por ejemplo, permite acceder a los alojamientos de una provincia,
ya que alojamiento est relacionado con ciudad, y ste es jerrquicamente
inferior a provincia.
Pg. 211
navegacin en relaciones N:M: permite navegar de un extremo al otro de una

relacin N:M sin perder los datos de la entidad intermedia. Por ejemplo permite
acceder directamente de una playa a sus servicios.
navegacin mltiple: permite el acceso mltiple de una entidad a otra,
seleccionando un elemento de una tercera entidad de la que la entidad destino es
parte. Por ejemplo permite que dado un vuelo, podamos elegir un tipo de tarifa y
acceder a su precio.
Tambin se introdujo la primitiva de acceso simultneo, que permite acceder a todos los
elementos simultneamente de una entidad con la que se est relacionado. Por ejemplo,
si estamos en un alojamiento, con esta primitiva accedemos a todos sus alojamientos
simultneamente, todos a la vez, y no mediante un ndice o uno tras otro en una visita
guiada. Lo reflejaremos con la siguiente primitiva:
Y para terminar, hay que notar la novedad que supone dividir el problema en diferentes
categoras o temas, de manera que los modelos sean legibles. Al final, todo queda
interconectado desde la jerarqua de mens, as como a travs de algunos enlaces que
existen entre entidades de diferentes categoras, como pueda ser el caso de las paradas
de transportes urbanos. En este caso ha sido bastante simple, pero dividir un gran
problema en temas puede ser una tarea compleja.
Pg. 212
VII - Atles de les Illes Balears
Captulo VII
3er CASO: CD-ROM DEL Atles de les Illes Balears
En este caso de estudio trataremos el CD-ROM del Atles de les Illes Balears, [UIB98],
que se ha ido desarrollando entre 1997 y 1998 en la Universitat de les Illes Balears, y en
el cual el proyectista ha trabajado desde el inicio al final. El objetivo era el de crear un
atlas multimedia de las Islas, destinado a las escuelas de secundaria de Baleares. La gran
variedad y riqueza de la informacin contenida hacan imprescindible que antes de
comenzar la implementacin se llevase a cabo una etapa de anlisis de la estructura y la
navegacin. Para ello, una vez ms utilizamos la metodologa RMM, con las mejoras
que ya se han comentado, puesto que el modelo relacional, como veremos, se ajusta
perfectamente a nuestras necesidades.
En el primer apartado veremos la descripcin de qu es el CD-ROM del Atles de les
Illes Balears, en el segundo una primera aproximacin al caso de estudio, que fue la
base de un prototipo cuyas conclusiones dieron lugar al anlisis definitivo que se
presenta en el apartado tercero. Y como siempre, el captulo se cierra con el apartado de
conclusiones.
7.1. Qu es el Atles de les Illes Balears

Para una descripcin de lo que es y supone este proyecto, reproducimos ntegramente el
prlogo del mismo, escrito por la Doctora Joana Maria Segu, directora del proyecto:
El CD-ROM Atles de les Illes Balears es el primer atlas en formato multimedia
que se publica en nuestra comunidad autnoma.
Constituye una aportacin destacada al conocimiento geogrfico del territorio
insular i recoge parte del trabajo encargado por la Direcci General d'Educaci,
realizado en soporte tradicional y editado el 1995, bajo el mismo ttulo.
Este atlas es una contribucin importante i innovadora a la produccin
bibliogrfica y de materiales didcticos que se promueve desde la Conselleria
d'Educaci, Cultura i Esports del Govern Balear y desde Sa Nostra Caixa de
Balears, para construir un currculum propio sobre el medio y las ciencias
sociales en las Islas, una vez que se han conseguido totalmente las transferencias
educativas. En esta obra, de carcter geogrfico, se analizan las caractersticas
fsicas y humanas del territorio insular, es decir, tanto el medio como las
interrelaciones econmicas, sociales y culturales, entre otras, que se generan a
partir de la huella humana.
El CD-ROM Atles de les Illes Balears constituye una herramienta didctica
verstil que se utiliza en distintos niveles educativos. Puede ser plenamente
utilizado en la universidad, as como en distintos cursos de enseanza
secundaria, por parte del alumno o como material de trabajo para el profesor, ya
que a la mayora de temas se llega a un nivel de profundidad bastante elevado.
Pg. 213
Un trabajo como este ha requerido un equipo interdisciplinar que conjugase la

autora, con el tratamiento cartogrfico y la implementacin multimedia. La
realizacin ha ido a cargo de un conjunto de especialistas de la Universitat de les
Illes Balears que cuentan con experiencia, tanto en el trabajo de textos
didcticos, con mapas y sin, como en otros CD-ROM, entre los cuales hay que
citar los encargados por el Govern (ParcBIT, 1994) i tambin por Sa Nostra
Caixa de Balears (S'Albufera, 1995).
La utilizacin de materiales multimedia tales como este atlas permite a los
estudiantes y a los ciudadanos de las Baleares en general, no slo conocer mejor
nuestras islas, sino tambin contribuir al hecho de que sea mucho ms fcil
poderlo hacer. El CD-ROM Atles de les Illes Balears podr ayudar, sin duda, a
valorar y querer ms a nuestra tierra y nuestra cultura.
Pg. 214
7.2. Primer estudio del caso

En un primer estudio, nos centraremos en lo que nosotros consideramos como lo que
hubiera sido la situacin ideal. Un prototipo basado en esta situacin ideal fue
presentado a las otras dos partes que participaban en el proyecto, autores y cartografa
digital, y se extrajeron las conclusiones que dieron pie al segundo y definitivo anlisis.
Veamos a continuacin las tres primeras fases de la metodologa, adems de la etapa
previa de anlisis de requerimientos, clave en este proyecto.
7.2.1. Etapa 0: anlisis de requerimientos

En el proyecto, por el contrato firmado, se impuso un requerimiento, que el CD-ROM
deba poder utilizarse tanto en ordenadores PC con Microsoft Windows 95 como en
ordenadores Apple Macintosh. Se trata, sin embargo de un requerimiento que no
condiciona para nada el desarrollo del proyecto.
Sin embargo, desde un primer momento, el grupo de Multimedia del Dept. de
Matemtiques i Informtica, decidimos el utilizar una interfaz de tipo web. Las razones
fundamentales fueron tres:
Tras el estudio de varios atlas multimedia publicados por grandes compaas
comprendimos que la principal carencia que ofrecan era la imposibilidad de
comparar dos mapas. En realidad eso es fruto de trabajar con una nica
pantalla sobre la cual se ha de mostrar toda la informacin. Al mostrar otra
informacin, como un texto, una foto u otro mapa, se pierde la informacin
que estbamos visionando, y muy a menudo nuestro punto en la navegacin.
La decisin de utilizar un entorno web permite fcilmente trabajar con varias
ventanas de modo que es viable el ver varias informaciones simultneamente.
sta fue la principal razn que nos hizo decantarnos por esta opcin.
Tambin fue importante el hecho de que desarrollar un CD-ROM con una
interfaz web supona una novedad en aquel momento, y no se debe olvidar el
carcter de investigacin que debe tener una universidad. Nuevas
conclusiones respecto a interfaces y programacin se podran extraer de ello.
Mucha gente ya est habituada a la navegacin por Internet, lo cual incide
directamente en una mayor facilidad de aprendizaje del producto.
As pues, esta decisin conlleva una serie de restricciones:
La aplicacin, para su visualizacin, necesita de un navegador. La aplicacin
debe funcionar en los dos navegadores ms utilizados en el momento, que son
el Netscape Navigator y el Microsoft Explorer, ambos tanto para Macintosh
como para Windows 95. Se especific que la versin mnima de dichos
navegadores sera la 4, aunque finalmente se consigui tambin que la
aplicacin funcione en la versin 3 del Netscape Navigator (no as en la de
Microsoft Explorer debido a sus carencias propias).
Pg. 215
Los lenguajes de programacin que se debern utilizar son HTML y

JavaScript. Se desestim el uso generalizado de Java, ya que presenta
numerosos problemas de una interfaz muy inestable y dependiente de la
plataforma (el mismo applet se ve de forma diferente segn el navegador y la
mquina). Slo un applet para una aplicacin didctica muy concreta fue
utilizado, testeando que funcionase correctamente en todas las plataformas
requeridas.
Se decide que se deben incorporar modelos en tres dimensiones de las Islas.
Para ello se utilizar VRML versin 2.
El hecho que la aplicacin deba ir en un CD-ROM y no en un sitio web,
impide el trabajar con bases de datos, ya que stas no pueden ser atacadas si
no es desde un servidor web, lo cual no es posible desde un CD. Ello nos
obliga a trasladar toda la estructura relacional a una estructura de directorios,
si bien hace bastante ms compleja tanto la programacin como la
introduccin de datos, y en particular la confeccin de ndices (hay ndices de
todos los mapas, todos los textos, todos las tablas, ...) se deber hacer
manualmente.
7.2.2. Etapa 1: Diseo Entidad-Relacin

El entidad central del modelo es la entidad Nodo. Un nodo corresponde a un tema
concreto aplicado a un rea geogrfica concreta. Por ejemplo, transportes martimos en
Menorca. Tanto los temas, como las reas estn jerarquizadas.
Relacionado con ese nodo es donde hay una gran cantidad de informacin: entradas del
glosario, citas bibliogrficas, preguntas del tipo sabas que ... ?, mapas, grficos, textos,
tablas y elementos multimedia.
Cada mapa est compuesto de varias capas, extradas directamente del sistema de
informacin geogrfica (SIG o GIS en ingls). Y cada una de esas capas puede tener
unos topnimos asociados, unos elementos de leyenda (que a su vez pueden estar
asociados a una definicin, que tambin puede tener elementos multimedia), y se le
puede aplicar varios zooms. Igualmente un grfico tambin tiene una serie de elementos
de leyenda, con su posible definicin, y unos zooms.
Pg. 216
rea
Geogrfica
Nivel
Tema
Tema
Nivel
rea
Nodo/Sabas
Sabas que
Tipo
Multimedia
Nodo
Multimedia
Nodo/
Glosario
Nodo
Entrada
Glosario
Nodo/
Bibliografa
Cita
Bibliografa
Multimedia
Mapa
Grfico
Texto
Tabla
Topnimo
Multimedia
El. Leyenda
Grfico
Grfico
Zoom
Capa
Topnimo
Zoom
Topnimo
Capa
Distancia
Capa
Zoom
Elemento
Leyenda
Multimedia
Definicin
Definicin
Multimedia
7.2.3. Etapa 2: Diseo de slices

Dado que slo se trataba de un primer anlisis no profundizamos en exceso en el diseo
de los slices. En realidad cada entidad no tiene ms que un slice con toda la informacin
correspondiente.
Pg. 217
7.2.4. Etapa 3: Diseo navegacional

Relacin
Tipo Descripcin
Nodo-Nodo
Multimedia- B Lo que deseamos es poder acceder a los
Multimedia
elementos multimedia de un nodo determinado.
Multimedia-Nodo
B Puede ser til poder acceder a los nodos en los
Multimedia-Nodo
que aparece el elemento multimedia que
estamos viendo.
Nodo-Nodo
Sabas-Sabas B Lo que deseamos es poder acceder a las
que
preguntas tipo sabas que...? de un nodo
determinado.
Nodo-Nodo
Glosario- B Lo que deseamos es poder acceder a las palabras
Elemento Glosario
del glosario de un nodo determinado.
Nodo-Nodo Bibliografa-Cita B Lo que deseamos es poder acceder a las citas
Bibliografa
bibliogrficas de un nodo determinado.
Topnimo-Topnimo
B Lo que deseamos es poder acceder a los
Multimedia-Multimedia
elementos multimedia de un topnimo
determinado.
MultimediaTopnimo B Puede ser til poder acceder a los topnimos en
Multimedia- Topnimo
los que aparece el elemento multimedia que
estamos viendo.
Topnimo- Topnimo Capa- B Lo que deseamos es poder acceder a los
Capa
topnimos de una capa determinada.
CapaTopnimo
Capa- B Puede ser til poder acceder a las capas en las
Topnimo
que aparece el topnimo que estamos viendo.
DefinicinDefinicin B Lo que deseamos es poder acceder a los
Multimedia-Multimedia
elementos multimedia de una definicin
determinada.
MultimediaDefinicin B Puede ser til poder acceder a las Definiciones
Multimedia- Definicin
en los que aparece el elemento multimedia que
estamos viendo.
Capa-Zoom-Capa Zoom
C Lo que deseamos es que a partir de la capa que
estamos viendo, podamos elegir los zooms
disponibles y ver la capa a ese zoom (ver el
objeto correspondiente de la entidad Capa
Zoom)
Grfico-Zoom-Grfico Zoom
C dem
Topnimo-TopnimoC Queremos que, al ver un topnimo, podamos
Distancia
elegir otro y ver la distancia que los separa.
Pg. 218

rea
Geogrfica
Nivel
Tema
Nivel
rea
Tema
Sabas que
Tipo
Multimedia
Nodo/Sabas
Elemento
Glosario
Nodo
Nodo Multimedia
Nodo/Glosario
Nodo/Bibliografa
Cita
Bibliografa
Nodo Multimedia
Texto
Multimedia
Mapa
Topnimo Capa
Grfico
Tabla
Topnimo Capa
El. Leyenda
Grfico
Capa
Zoom
Topnimo Capa
Grfico
Zoom
Topnimo
Topnimo Capa
Capa
Zoom
Distancia
Elemento
Leyenda
Definicin
Def. Multimedia
Multimedia
Def. Multimedia
Pg. 219
7.3. Segundo (y definitivo) estudio del caso

Un prototipo basado en la estructura anterior fue discutido con el Departamento de
Geografa, y se tomaron una serie de decisiones, algunas marcadas por los aspectos
tecnolgicos de los sistemas de informacin geogrfica, que hicieron variar
drsticamente el modelo anterior. Aqu se detallan esos cambios, fruto de tales
discusiones:
Tanto los mapas como los grficos se tratan como imgenes simples, en formatos
bitmap como GIF o JPEG. Esto conlleva que ya no hay informacin de capas. La
decisin vino marcada, tras varias pruebas, por la imposibilidad de manejar imgenes
con formato vectorial en la plataforma en la que se deba ejecutar la aplicacin (un
navegador web).
Debido tambin a que los mapas y grficos se consideran como una imagen y ello
impide su fcil modificacin, se decide eliminar la informacin de zooms.
Los topnimos dejan de estar relacionados directamente con el mapa, y en realidad
desaparecen de la estructura. A pesar de que hay un ndice toponmico con cientos de
topnimos de las Islas, el Dept. de Geografa decidi que no se tomara en
consideracin los topnimos que aparecen en un nodo, mapa, ...
La informacin relacionada con glosario, bibliografa, sabas que, y elementos
multimedia diferentes de fotos (es decir, vdeos y panormicas) deja de estar
relacionada con el nodo y pasa a ser del tema entero de nivel 2. Esto tiene una
excepcin: se permite un enlace entre trminos importantes que aparezcan en el texto
de un nodo y su definicin (en la entidad Entrada Glosario). Mientras que los sabas
que son propios de un tema concreto, los dems pueden darse en varios.
En cuanto al material multimedia, se decidi hacer una distincin entre fotos por un
lado y vdeos y panormicas por el otro. Las fotos estn asociadas a un tema
concreto en una escala concreta, mientras que los vdeos y panormicas, al ser
mucho ms genricos, se asocian al tema de segundo nivel.
Se establece que la navegacin principal deber ser temtica y no de escala. Es decir,

que el usuario navegar por los temas, y una vez seleccionado ste, podr ver todos
los nodos referentes a cada una de las reas geogrficas disponibles para ese tema.
Estas reas geogrficas varan segn el tema, siendo lo ms corriente que aparezcan
los niveles de archipilago e isla, pero que en determinadas ocasiones alcanza hasta
nivel comarcal y municipal.
En cuanto a la estructura temtica, la direccin del proyecto, fija que se establecern

tres niveles diferentes de jerarqua:
1. El primer nivel: los tres grandes bloques geogrficos: geografa fsica, geografa
humana y por ltimo mapa topogrfico y tradicin cartogrfica. Si bien es
diferente, se decidi considerar como un cuarto bloque a la presentacin del
atlas.
Pg. 220
2. El segundo nivel establece los temas en que se subdividen los anteriores. Hay
tres temas para el bloque de mapa topogrfico y tradicin cartogrfica, y cinco
para los otros dos. Para cada uno de estos temas se confeccionar una visita
guiada, que es una secuencia de pantallas que muestran qu es lo ms importante
que el alumno se encontrar en dicho tema.
3. Por ltimo aparecen los subtemas de los anteriores, donde ya nos encontramos la
informacin propiamente dicha, con textos, mapas, tablas, grficos y fotos. La
informacin de este nivel de temas est a su vez estructurados en tantos niveles
como al autor estime oportuno (si bien se recomend slo llegar hasta un cuarto
nivel de profundidad, algunos autores utilizaron hasta un sexto).
7.3.1. Etapa 0: anlisis de requerimientos

Los requerimientos del sistema se mantienen y son los expuestos en el primer anlisis.
7.3.2. Etapa 1: Diseo Entidad-Relacin

ste es el modelo entidad-relacin que se confecciona a partir de las nuevas
especificaciones:
Pg. 221
Sabas que
Tema
Nivel 1
Tema
Nivel 2
Nodo
Visita Guiada
Tema/
Bibliografa
Cita
Bibliografa
Tema/
Glosario
Entrada
Glosario
Tema/
Multimedia
Elemento
Multimedia
Tema
Informacin
Tipo
Multimedia
rea
Geogrfica
Topnimo
Nodo
Informacin
Nivel
rea
Texto/Nodo
Mapa/Nodo
Grfico/Nodo
Tabla/Nodo
Foto/Nodo
Texto
Mapa
Grfico
Tabla
Foto
Leyenda/
Mapa
Elemento
Leyenda
Definicin
7.3.3. Etapa 2: Diseo de slices

Para mantener una navegacin ms sencilla se confirma que cada entidad tendr slo un
slice con toda su informacin.
Pg. 222
7.3.4. Etapa 3: Diseo navegacional

Relacin
Tema
Nivel
Informacin-Nodo
Informacin
Tipo Descripcin
2-Tema A En realidad aqu lo que nos interesa no es
acceder directamente al nodo desde el tema de
nivel 2, sino permitir que desde el nodo se
pueda volver al tema de nivel 2, ya que desde
ah se puede acceder a sabas que, glosario,
bibliografa y elementos multimedia.
Tema Nivel 2-Tema / B Lo que deseamos es poder acceder a las palabras
Glosario-Elemento Glosario
del glosario de un tema determinado.
Tema Nivel 2-Tema / B dem
Bibliografa-Cita Bibliografa
Tema Nivel 2-Tema / B dem.
Multimedia-Elemento
Multimedia
Nodo Informacin-Nodo / B Lo que deseamos es poder acceder a los textos
Texto-Texto
de un nodo de informacin determinado.
Nodo Informacin-Nodo / B dem
Mapa-Mapa
Grfico-Grfico
Tabla-Tabla
Foto-Foto
Mapa-Leyenda
Mapa- B Lo que interesa es acceder a los elementos de
Elemento Leyenda
leyenda de un mapa, para formar la leyenda.
Tema
Informacin-rea C La navegacin principal es la temtica. De tal
Geogrfica-Nodo
modo, lo que deseamos es que una vez en un
Informacin
tema, podamos ver la lista de reas geogrficas
en que ese tema es aplicable y ver tras
seleccionar uno, ver su informacin (el nodo).

Nota: nos es necesaria una nueva primitiva para representar el acceso a un elemento
aleatoriamente. En este caso concreto, dado un tema de nivel 2, accederemos a uno de
sus sabas que, de forma aleatoria, sin saber exactamente a cul. Lo haremos con la
siguiente primitiva y la llamaremos acceso aleatorio:
Pg. 223
Tema
Nivel 1
Sabas que
Tema/Bibliografa
Cita
Bibliografa
Tema/Glosario
Entrada
Glosario
Tema/Multimedia
Elemento
Multimedia
Tema
Nivel 2
Tema
Informacin
Nodo
Visita Guiada
Tipo
Multimedia
rea
Geogrfica
Nivel
rea
Topnimo
Nodo
Informacin
Texto/Nodo
Mapa/Nodo
Texto
Mapa
Grfico/Nodo
Grfico
Tabla/Nodo
Foto/Nodo
Tabla
Foto
Leyenda/Mapa
Elemento
Leyenda
Definicin
Estructura de mens
La estructura de mens se divide en dos ramas principales. Por un lado el acceso a temas
y por el otro el acceso a ndices. En cuanto al primero se accede mediante un ndice a la
entidad Tema Nivel 1. En el segundo caso se acceder a otro men donde se tendrn
las opciones de ndice de textos, de mapas, de grficos, de tablas, de fotos, de elementos
multimedia, glosario, bibliografa, ndice toponmico y ndice temtico (simplemente un
fichero donde se incluye todo el ndice completo).
Pg. 224
No lo integraremos en el diagrama anterior porque sera imposible de leer, ya que desde

el men de ndices se accede a un gran nmero de entidades, pero lo veremos as
representado:
Tema
Nivel 1
Tema
Nivel 2
Texto
Mapa
Elemento
Multimedia
Tabla
Grfico
Entrada
Glosario
Cita
Bibliografa
Foto
Topnimo
7.3.5. Etapa 4: Diseo de protocolos de conversin

Recordemos de la etapa 0, anlisis de requerimientos, que el hecho de ser una aplicacin
web que ha de ser ejecutada sobre CD-ROM impona la restriccin de la imposibilidad
de trabajar con bases de datos. Para sustituir la base de datos se tuvo que disear una
estructura de directorios con el fin de ordenar los aproximadamente dos mil archivos de
material. Exponemos a continuacin las reglas que se siguieron:
Cada tema tiene un directorio, estructurados jerrquicamente. Cada uno de los tres
temas de nivel 1, tiene un directorio, denominado 1, 2 y 3, respectivamente. Cada uno
de los temas de nivel 2 tendr su directorio dentro de su de tema de nivel 1. Por ejemplo
en el directorio 2 habr los subdirectorios 21, 22, 23, 24 y 25, para cada uno de los cinco
temas que existen. Y lo mismo ocurre con los temas de informacin (niveles 3 y 4).
La pertenencia de un texto, tabla, mapa, ..., a un tema es obvia: incluyndolo en el
directorio del tema correspondiente. Lo mismo ocurre con elementos de glosario, citas
bibliogrficas, sabas que y elementos multimedia, que sern todos incluidos en el
Pg. 225
directorio de segundo nivel. En el caso de los sabas que, se incluye un archivo para
cada uno, mientras que en el caso de los dems lo que se incluye en un nico archivo
con referencias. El mismo caso que los sabas que es el de los nodos de visita guiada de
un tema de nivel 2.
Cada elemento, adems de pertenecer a un directorio concreto de tema, est codificado
siguiendo una regla.
La primera letra indica el tipo de elemento de que se trata (se utilizan dos
letras para los elementos de nivel 2):
En el caso de elementos de nivel 2
Glosario
GL
Bibliografa
BG
Multimedia
MM
Sabas que
SQ
Visita guiada
VG
En el caso de elementos de informacin (niveles 3 y 4)

Texto
Mapa
Leyenda
Tabla
Grfico
Foto
A continuacin de esta letra, el tema (por ejemplo 2543).

A continuacin el rea geogrfica asociada (por ejemplo B de Baleares).
Por ltimo, si hay ms de un elemento de ese tipo, para ese nodo, se indica el
nmero de secuencia.
7.3.6. Etapa 5: Diseo de la interfaz de usuario

Si bien esta etapa es labor de un diseador grfico, en nuestro caso Antonio Fernndez
Coca, una buena estructura navegacional ser de gran utilidad para la confeccin de la
interfaz de usuario coherente e intuitiva. A continuacin se describe la interfaz y su
profunda relacin con la estructura:
Pg. 226
Al entrar en la aplicacin aparece una ventana a la izquierda, donde tenemos cinco

bloques en los que se estructura el atlas. Nosotros nicamente nos centramos en los dos
primeros (temas e ndices) que son los relacionados con la estructura. Los dems
bloques corresponden a aplicaciones didcticas (como por ejemplo, juegos), ayuda y
crditos. As pues, vemos en la imagen el men principal del modelo en el que se elega
entre ir al men de temas o al de ndices:
Al pulsar en el botn Temes (ms adelante veremos la opcin ndexs) entramos en

el men principal que vimos en el diagrama RMDM, donde accedemos mediante un
ndice condicionado a los temas de nivel 1. Lo vemos en la imagen:
Pg. 227
Al seleccionar uno, se despliega el ndice condicionado de los temas de nivel 2, como

vemos en la siguiente imagen:
Al elegir uno de ellos, ocurren dos cosas, en dos ventanas diferentes:

En la primera, aparece el primer elemento de la visita guiada de la entidad
Nodo de visita guiada. En esta pantalla aparece tambin la barra de
herramientas, sobre la que volveremos a hablar, y en la que se pueden apreciar
los botones + y - para avanzar y retroceder, respectivamente, dentro de la
visita guiada.
En la segunda, aparece el ndice condicionado de los temas de informacin.
Lo vemos en la imagen:
Pg. 228
Al elegir uno de esos temas de informacin, se accede al nodo de informacin, que se

cargar en la ventana central. Aparece no slo el ttulo del nodo, sino que toda la
informacin de textos, mapas, leyendas, grficos, tablas y fotos relacionada con dicho
nodo. Es un acceso del tipo todos a la vez. Lo apreciamos en la imagen. El diseador
decidi que se deba permitir visualizar inmediatamente estos elementos, sin necesidad
de tener que pulsar ningn otro botn . No obstante en la barra de herramientas se
permite acceder individualmente a cada una de las entidades mapa, leyenda, grficos,
tablas y mapas (tambin decidi que fotos no era necesario).
Pg. 229
En este punto es interesante estudiar la barra de herramientas. En la imagen se ve cmo

sta est dividida en tres secciones, claramente diferenciadas:
En la primera seccin, comenzando por la izquierda, botones 10 y 11,

tenemos la navegacin para la visita guiada que cada tema de nivel 2 tiene
(entidad nodo de visita guiada). En el momento en que se accede a los
nodos de informacin esta seccin queda inhabilitada.
Pg. 230
En la segunda tenemos la navegacin que nosotros denominamos global, en

contraposicin de la local, que veremos en la siguiente seccin. En la fila
superior tenemos opciones generales de navegacin como son la de volver
atrs en la historia (botn 9), copiar esta ventana a otra nueva (8), ver/ocultar
la venta de contenidos (temas de informacin) (7) y ver/ocultar ms
informacin si la hay (6). En las otras dos filas, adems de imprimir (12), se
permite acceder a la entidad tema de nivel 2 para poder acceder a sus sabas
que (13), elementos de glosario (16), multimedia (vdeos y panormicas) (17)
y bibliografa (15). Otro punto importante es que permite volver a seleccionar
el rea geogrfica para acceder mediante el acceso mltiple a otro nodo de
informacin, del mismo tema, pero de distinto lugar (men desplegable 18).
Por ltimo hay un enlace al ndice de topnimos (19) (no hay ninguna
relacin entre esos topnimos y el nodo; no se trata de un ndice condicional).
Mientras que en la segunda seccin los enlaces eran a entidades que estaban
por encima en la estructura, es decir que surgan de la inferencia de la relacin
jerrquica, en esta tercera seccin se accede a las entidades texto (botn 1),
mapa (2), leyenda(4), grfico(3) y tabla(3), utilizando acceso del tipo todos a
la vez. Es decir se utilizan accesos condicionados, no inferidos, o lo que es
lo mismo se acceden a elementos propios de este nodo, mientras que en el
caso anterior eran elementos propios del tema, y por tanto sern comunes en
todos los nodos del mismo.
Nos queda ver cmo es la otra parte del men principal, la que hace referencia a los
ndices. Al pulsar la opcin accedemos al siguiente men de la jerarqua, como vemos
en la imagen:
Pg. 231
Desde aqu, eligiendo una opcin se accede, mediante un ndice, a la entidad

correspondiente (mapa, texto, ...). Vemos en la imagen como aparece una nueva ventana
con el ndice de una de estas entidades, la de grficos concretamente, a la izquierda, y al
elegir uno de ellos aparece en la parte derecha.
7.3.6.1. Conclusiones de esta etapa

En una situacin ideal, todo el equipo que participa en el desarrollo debe conocer
perfectamente la metodologa, pero a menudo esto no ocurre, especialmente en el caso
del personal no informtico, que muchas veces es externo al grupo de desarrollo. ste
era nuestro caso, y en concreto el diseador grfico no conoca la metodologa.
En estos casos, se debe preparar cuidadosamente, a partir del modelo RMDM donde se
describen todas las pantallas que la aplicacin tendr, una lista de todos los iconos y
elementos grficos que sern necesarios. Para hacer esto, nuestra lnea de accin fue la
de preparar un prototipo para que el diseador viera la estructura de la aplicacin y los
significados de cada seccin. A partir de esto, el diseador propone la interfaz general,
como son colores o imgenes de fondo, colores del texto, ..., generalmente diferentes
para cada seccin. El siguiente paso es integrarlo en el prototipo y confeccionar la
anteriormente citada lista de elementos grficos que son necesarios. En concreto ya
explicamos en los comentarios a las mejoras de RMM que nuestra propuesta es la de
que por un lado haya un icono para cada uno de los accesos estructurales (internos a la
entidad) y por otro, tambin un icono para todos los accesos navegacionales, ya sean
directos o inferidos. Todos deben ir acompaados de su significado. As pues, a partir de
esa lista y con la ayuda del segundo prototipo, el diseador confecciona toda el conjunto
de elementos grficos de la aplicacin. Ntese que la lista que se le entrega al diseador
Pg. 232
debera ser completada con los iconos que l ha asignado; esta lista es til mantenerla
para posteriores mantenimientos.
Otro aspecto importante, es que si bien el modelo RMDM nos permite saber qu
elementos aparecern en cada pantalla de la aplicacin, la interfaz aplicada directamente
puede ser excesivamente rgida. Es por tanto que se debe, no slo permitir, sino
incentivar al diseador a que encuentre la mejor manera de presentar la informacin,
basndose en la estructura, es decir que defina cul ser la estructura definitiva de la
pantalla. Por ejemplo, el hecho de que unos elementos aparezcan en una ventana y otros
en otra, y otros en el frame principal, es en ltima instancia responsabilidad del
diseador. En este sentido, nuestro mtodo de comunicacin entre diseador y
desarrolladores era el de imgenes con el layout que el diseador proporcionaba. Quiz
para un futuro, y para aplicacin ms grandes con equipos de desarrollo mayores, pueda
ser necesario profundizar en este aspecto.
7.3.7. Etapa 6: Diseo del comportamiento en tiempo de ejecucin

En esta etapa se deban disear los algoritmos y programas para el control de la
navegacin, mecanismo de historia, control de ventanas, etc. Para ello su programacin
se utiliz el lenguaje JavaScript.
Para obtener mayores detalles sobre esta etapa, referirse al proyecto de Daniel Soto
lvarez, que se centra en la creacin de un esqueleto para la realizacin de
aplicaciones multimedia, especialmente centradas en el mbito de Internet.
7.3.8. Etapa 7: Construccin y tests

Evidentemente, esta etapa no merece ningn comentario. nicamente citar que la
construccin de la aplicacin corri a cargo de Daniel Soto, Francesc Mateu y el
proyectista, contando con la colaboracin de numerosos compaeros en la integracin
de material multimedia.
Pg. 233
7.4. Conclusiones
Como hemos podido observar, ste ha sido el caso de estudio en el que ms se ha
profundizado, sin duda porque ha sido en el que el proyectista ha tenido una mayor
participacin: en el primer caso, SAlbufera, slo se pretenda hacer un anlisis de una
aplicacin ya hecha, con el fin de evaluarla. En el segundo, MINTour, el objetivo ya era
el de hacer la aplicacin completa a partir del anlisis, pero por una serie de causas
internas al proyecto, la aplicacin tom otros derroteros. Pero en este tercer caso, s se
han podido seguir todas las fases de la metodologa hasta obtener la aplicacin final.
Precisamente, como principal conclusin de este caso de estudio, consideramos que
podemos citar que se ha demostrado que s es posible el hacer un desarrollo completo de
una aplicacin siguiendo la metodologa RMM, con una serie de mejoras que ya se han
comentado. No obstante, hay una serie de aspectos sobre los que se debera profundizar,
especialmente en las fases posteriores al modelo RMDM, y bsicamente en la fase
quinta, Diseo de la interfaz de usuario, donde se interacta directamente con el
diseador grfico, que a menudo no conoce nuestra metodologa. En concreto, nosotros
hemos incorporado a la metodologa, la lista de los elementos grficos as como un
conjunto de layouts para representar la estructura de la pantalla, que ya se han sido
citados en las conclusiones acerca de la quinta etapa.
Para terminar, recordar que se ha introducido una nueva primitiva de acceso, la de
acceso aleatorio, que permite acceder a los elementos de una entidad aleatoriamente. Lo
representamos as:
Un ejemplo de su utilizacin es que dado un tema de nivel 2, accederemos a uno de sus

sabas que, de forma aleatoria, sin saber exactamente a cul.
Pg. 234
VIII - Conclusiones
Captulo VIII
CONCLUSIONES
8.1. Resumen final y conclusiones
8.1.1. Modelo de Dexter
El modelo de Dexter se defini en 1998 con el objetivo de que sirva como un estndar
para comparar las caractersticas y funcionalidades de varios sistemas de hipertexto.
Tambin como una base sobre la cual desarrollar estndares para interoperabilidad e
intercambio entre sistemas de hipertexto. Otro punto importante es el de proveer de una
terminologa comn al campo del hipertexto.
El modelo divide el sistema hipertexto en tres capas diferentes, como lo muestra la
figura:
capa de tiempo de ejecucin
(run-time layer)
Especificaciones de presentacin
capa de almacenamiento
(storage layer)
Anclaje (anchoring)
capa del componente
(within-component layer)
Exponemos aqu, resumidos, los puntos clave del modelo:

El concepto fundamental del modelo es el de componente, que es lo que
conocemos tpicamente como nodos (componentes compuestos), que
contienen fragmentos de texto, grficos, animaciones, (componentes
atmicos).
La capa de almacenamiento se centra en estudiar los mecanismos por los
cuales se unen los componentes y los enlaces, formando una especie de base
de datos que almacena la jerarqua de componentes y los enlaces que los
interconectan.
La capa del componente refleja los contenidos y estructura dentro de los
componentes, y que al ser tan variados, Dexter no profundiza, dando libertad
en este nivel.
Una parte fundamental del modelo de Dexter es la interfaz entre las capa de
almacenamiento y la capa del componente. Se basa en el mecanismo de
anclaje (anchoring).
Pg. 235
VIII - Conclusiones
En cuanto a la capa de tiempo de ejecucin, sta provee al usuario de unas

herramientas para acceder, ver y manipular la estructura de la red de
hipertexto, sobre la cual Dexter apenas si ofrece unas ideas bsicas, debido al
gran nmero de posibles herramientas para acceder, ver y manipular un
hipertexto.
Un punto importante es la interfaz entre esta capa y la capa de
almacenamiento, a la que llama especificaciones de presentacin
(presentation specifications). sta es un mecanismo que permite que la forma
en que un componente se presenta al usuario pueda estar en funcin no slo
de una herramienta de hipertexto especfica (es decir, de una capa de tiempo
de ejecucin especfica), sino que puede ser una propiedad del componente
por s mismo, del enlace tomado para llegar a tal componente o tambin de las
preferencias del usuario.
Dexter fue el primer intento de modelar el hipertexto y de dar una terminologa comn
para este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de
1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que son
hoy. De hecho, la principal carencia que se puede observar en este modelo es que, a
pesar de que los autores lo recomiendan para tanto hipertexto como hipermedia, no
aborda en ningn momento la complejidad de los distintos medios. En realidad, se
podra decir que el modelo est fundamentalmente destinado a slo hipertexto, y la
aplicacin a la hipermedia es muy difcil. Por ejemplo, el concepto de valor del ancla lo
hace en funcin de la posicin del ancla en el texto, pero esto en otro medio no tiene
sentido. Ms en concreto, no tiene en cuenta los aspectos relacionados con el tiempo,
algo fundamental en el audio y el vdeo. Es por ello que posteriormente apareci el
modelo de Amsterdam, que basado en Dexter, aade el estudio del tiempo. Pero, a pesar
de eso (no hay que olvidar que estos elementos eran imposibles de utilizar en 1988), el
modelo especifica, por primera vez y muy detalladamente, cmo es la estructura interna
de un hipertexto. Incluso define unas estructuras que no haban sido utilizadas hasta
entonces como los enlaces mltiples, la posibilidad de hacer un enlace a otro enlace
(recordemos que los enlaces son componentes) o los componentes compuestos, que por
aquel entonces muchos sistemas de hipertexto no soportaban.
8.1.2. Modelo de Amsterdam

Mientras que el modelo de Dexter permite la composicin de estructuras jerrquicas, la
especificacin de enlaces entre componentes y el uso de anclas, el modelo de
Amsterdam lo extiende aadiendo las nociones de tiempo, presentacin a alto nivel de
atributos y enlaces de contexto.
Y se el precisamente el principal inters del modelo de Amsterdam, el que contemple
la complejidad de los tipos multimedia, y muy en especial la cuestin del tiempo que
stos conllevan. Tanto el audio como el vdeo presentan esta nueva componente que es
el tiempo, que no fue incluida en el modelo de Dexter.
Pg. 236
VIII - Conclusiones
8.1.3. Modelo HDM

En HDM se divide el proceso de diseo de una aplicacin en dos partes: authoring-inthe-large, para referirnos a la especificacin y diseo de los aspectos globales,
estructurales de la aplicacin, y authoring-in-the-small, para referirnos al desarrollo del
contenido de los nodos. El modelo, como es lgico se centra en la primera, en la
estructura de la aplicacin.
La terminologa base del HDM es bastante diferente a la de Dexter y se puede prestar a
confusin. El equivalente de nodo es lo que denominan unidad. Las unidades se
agrupan mediante una visita guiada o un ndice, formando componentes, que a su vez
se agrupan jerrquicamente en lo que denomina entidades. Asimismo hay varios tipos
de enlace; los ms importantes en la estructura son los que unen componentes dentro de
una entidad, y se denominan enlaces de componente o de perspectiva; los enlaces
estructurales conectan componentes de la misma entidad; por ltimo los enlaces de
aplicacin conectan componentes y entidades de distinto tipo, y son independies de la
estructura
La principal motivacin de HDM es crear un modelo basado en las anteriores primitivas
antes de comenzar a desarrollar que ayudar a conseguir una navegacin ms
consistente y rica. Adems HDM puede resultar til tambin para evaluar aplicaciones
ya desarrolladas, con el fin de detectar errores en la estructura navegacional.
Sin embargo, nuestra experiencia nos ha demostrado que realizar un modelo siguiendo
las normas de HDM es extremadamente complicado cuando el nmero de entidades
involucradas crece. En particular, era prcticamente imposible representar la estructura
de MINTour utilizando este modelo.
8.1.4. Metologa RMM

Esta metodologa permite explicitar la navegacin al hacer el anlisis, con lo cual nos
permitir, en teora, obtener una navegacin ms estructurada y, por tanto, ms regular e
intuitiva. Lo hace de una forma sencilla, simplemente aadiendo unas primitivas a lo
que es un modelo entidad-relacin tradicional. Es de gran inters, bajo mi punto de
vista, el concepto de slice, que permite agrupar datos de una entidad en diferentes
pantallas, y es que, al estar hablando de diferentes medios, la informacin de una
entidad puede ser muy variada. Para dar una idea ms al respecto, podra ser interesante
que un vdeo sobre un hotel, mostrando sus interiores, aparezca en una pantalla diferente
de otro que muestre su piscina. Tambin es interesante la primitiva de grupo, que
permite explicitar la jerarqua de mens.
Segn nuestro punto de vista RMM es de gran inters, ya que es el primer caso en el que
se crea una metodologa completa, con una definicin de fases, y no nicamente un
modelo de datos. Adems est basado en un modelo de datos relacional, lo cual se ajusta
perfectamente no slo a nuestros casos de estudio si no a la gran mayora de las
aplicaciones existentes.
Pg. 237
VIII - Conclusiones
Pero, a mi entender, los mecanismos de acceso a la informacin son excesivamente

simples. Pueden ser suficientes para un problema con pocas entidades, per no si el
nmero crece.
Un importante problema es que no se permite hacer una consulta a partir de dos
entidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles est
relacionada con ciudad, N a 1, y sta a su vez con regin, tambin N a 1, no hay forma
de permitir ver todos los hoteles de una regin, sino es yendo de ciudad en ciudad y
despus, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que sera
necesario poder establecer un enlace navegacional no slo entre entidades relacionadas
directamente, sino tambin con las que estn relacionadas con ellas, y as sucesivamente
(evidentemente siempre que sean relaciones tambin N a 1).
An as, la navegacin tendra ms limitaciones. Y es que ya hemos visto que las
consultas han de ser tan simples como que dado una ciudad qu hoteles tiene, que
campings, que puertos y aeropuertos, etc. Pero, por ejemplo, sera imposible explicitar
una consulta del tipo qu hoteles de una cierta categora hay en una ciudad determinada.
Otro gran defecto es que en la explicacin de la primera etapa, que es el correspondiente
a la construccin del diagrama Entidad-Relacin, se nos dice que las relaciones N:M se
descompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologas
como, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad que
resulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artculo
y que trata de un sistema de cursos, en los que se reflejan los profesores, sus
publicaciones, ... En el artculo, los autores rompen la relacin N:M entre profesores y
cursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero se
olvidan de los datos que deben guardarse de la relacin original, como por ejemplo
cuntas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, con
una entidad en medio, no habra forma de saber los cursos que imparte cierto profesor, o
Otro punto no tratado en la metodologa es el anlisis de los procesos, sobre el que no
hemos profundizado debido a que nuestros casos de estudio son nicamente
aplicaciones de consulta, sin actualizaciones por parte del usuario. Pero es obvio que se
debera incorporar un modelado del tipo de DFDs en la metodologa en caso contrario.
8.1.4.1. Evoluciones de RMM

Ante todas las limitaciones de RMM los autores intentaron ampliar el modelo,
fundamentalmente definiendo nuevos tipos de slices, como son los hbridos (con datos
de ms de una entidad), mnimos (la mnima parte de una entidad que es necesaria para
identificar uno de sus elementos) y los m-slices (permite combinan primitivas de acceso
con otros slices de otras entidades para crear un m-slice). Nuestra opinin al respecto es
positiva en los dos primeros casos y negativa con respecto a los m-slices, ya que lo que
propone es crear la estructura de la navegacin no en base a las entidades sino a los
slices, es decir a conjuntos de atributos. As, mientras los primeros han sido
ampliamente utilizados en nuestros casos de estudio, los ltimos no.
Pg. 238
VIII - Conclusiones
8.1.4.1. Mejoras en las estructuras de navegacin en RMM

A partir de las carencias de RMM e incoporando la novedad de los slices mnimos e
hbridos, no as lo m-slices, consideramos que la solucin para que RMM sea
aprovechable es la creacin de unas nuevas estructuras de navegacin que doten de una
mayor flexibilidad al modelo. A continuacin explicamos las nuevas estructuras
introducidas:
navegacin jerrquica: al tener varias relaciones 1:N encadenadas, se
permite navegar desde cualquier entidad a otra que est por debajo de ella en
la jerarqua. Estos enlaces inferidos, no extrados directamente de una
relacin 1:N, se representarn con trazo discontinuo.
navegacin en relaciones N:M: se permite navegar de un extremo al otro de
la relacin, pero teniendo en cuenta la entidad intermedia, cuyos atributos
debern incluirse en un slice hbrido. Para representar un enlace de este tipo,
uniremos la primitiva de acceso (ndice, visita guiada, ...) con la entidad
intermedia.
navegacin mltiple: se crean unas nuevas primitivas que permiten el acceso
mltiple de una entidad a otra, seleccionando un elemento de una tercera
entidad de la que la entidad destino es parte. En el enlace quedar
especificado qu entidad es la origen, cul la destino y cul la tercera.
Recordar que esta navegacin es especialmente apropiada en estructuras todoparte.
acceso aleatorio: permite acceder a un elemento aleatoriamente. Por ejemplo,
en el Atles, dado un tema de nivel 2, accederemos a uno de sus sabas que, de
forma aleatoria, sin saber exactamente a cul.
acceso simultneo: permite representar el acceso a todos los elementos de
una entidad a la vez. Por ejemplo, en MINTour, si estamos en un alojamiento,
con esta primitiva accedemos a todos sus alojamientos simultneamente,
todos a la vez, y no mediante un ndice o uno tras otro en una visita guiada
Despus de todo esto, la lista de las primitivas de acceso queda reflejada en la siguiente
tabla:
Pg. 239
VIII - Conclusiones
Hiperenlace
Hiperenlace jerrquico inferido
ndice
Visita guiada
Acceso aleatorio
Acceso simultneo
ndice mltiple
Entity Rel. N:M
Ejemplo de acceso a partir de una relacin

N:M, en este caso utilizando un ndice
(podra ser cualquier otra primitiva de
acceso simple)
Interfaz de usuario
Al hacer el estudio de las fases 4 a 7 de la metodologa RMM, y especialmente de la
etapa 5, diseo de interfaz de usuario, consideramos que hay una organizacin de la
pantalla que es especialmente coherente con la estructura, y que, adems de ser clara,
puede resultar muy til en todo tipo de aplicaciones hipermedia. Posiblemente los
autores no la tuvieron en cuenta, quizs porque los navegadores de aquel entonces an
no tenan soporte para ello. Se trata del uso de marcos (frames) de HTML (o si se
prefiere de tablas). As, podramos tener un marco principal la informacin del objeto
seleccionado. Y adems tres marcos ms, con otros colores para diferenciarlos, y
dispuestos como el diseador lo estime oportuno que contendran los elementos
navegacionales, respectivamente:
Enlaces a otras entidades
Enlaces a otros slices
Pg. 240
VIII - Conclusiones
Herramientas navegacionales (backtracking y otros)

De esta manera se obtiene una interfaz simple y significativa, til para la navegacin en
muchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo de
plataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de la
pantalla en varias reas.
8.1.5. Casos de estudio

Los ejemplos de los artculos siempre adolecen de ser muy sencillos, lo cual hace muy
fcil aplicar las tcnicas de modelo que los autores proponen. Nosotros decidimos
aplicar RMM a tres casos de estudio, que por su gran envergadura y riqueza de
estructura, nos ayudaran a detactar problemas y proponer soluciones a RMM. stos son
los nmeros de los tres casos de estudio:
CD-ROM del Parc Natural de SAlbufera
28 Entidades
91 Atributos
31 Slices
Proyecto MINTour
20 Categoras
129 Entidades
1016 Atributos de entidades
277 Slices
CD-ROM del Atles de les Illes Balears
28 Entidades
Elementos de informacin contenidos en el CD-ROM:
Textos
Mapas
Grficos
Tablas
Fotos
Vdeos
Imgenes panormicas
Total
960
686
283
148
288
72
23
2460
8.1.5.1. CD-ROM del Parc Natural de SAlbufera

Como principal conclusin de este estudio se puede deducir la utilidad de utilizar una
metodologa y un modelo para evaluar detalladamente una aplicacin ya desarrollada, a
posteriori.
De esta manera se han detallado una serie de carencias en la estructura de la informacin
y la navegacin. Las exponemos detalladamente a continuacin:
Pg. 241
VIII - Conclusiones
Tanto animales (aves, mamferos, peces, reptiles e invertebrados) como plantas tienen
un lugar en el parque. En el sistema actual se desaprovecha la informacin para permitir
que navegar por todos, por ejemplo, mamferos de un lugar concreto. Y tambin al
contrario, no podemos ir a visitar el lugar que se nos cita en la informacin del animal o
planta.
El mismo caso ocurre con los usos del parque y con los momentos histricos, que no
fueron enlazados con su lugar.
Se pierde la posibilidad de navegar por estacin o mes. Tenemos la informacin de la
presencia de las aves por meses, as como una breve descripcin del parque en cada
estacin. Pero no podemos ver las aves que estn en un mes concreto (interesante si
queremos planificar una visita real al parque). Lo mismo ocurre con el perodo de
floracin de las plantas, que no se puede navegar por las plantas que estn en flor en un
mes concreto.
8.1.5.2. Proyecto MINTour

A pesar de que finalmente nuestras ideas no han sido utilizadas en el proyecto europeo,
el modelo final que hemos obtenido constituye un interesante modelo de navegacin,
ms consistente e intuitivo que el existente. De hecho, el proyecto europeo dej de lado
la lnea de un proyecto multimedia, para convertirse en un simple recuperador de
informacin de la base de datos, sin ninguna navegacin posible entre sus elementos. En
cambio nuestra solucin dara lugar a un sistema en el cual el usuario navegara, igual
que podra navegar virtualmente por Europa, en vez de hacer una consulta tras otra,
definiendo complicadas bsquedas a la base de datos. Desde nuestro punto de vista, sta
es la diferencia fundamental entre una aplicacin multimedia-hipermedia y una de
gestin: en la primera lo importante es la navegacin y en la segunda la recuperacin
exacta de los datos que el usuario desea. Pero, pensamos que la situacin es que el
usuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entrar
en el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas que
tienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de una
tienda y ofrecen visitas guiadas.
El anlisis de MINTour, al tratarse de un proyecto tan grande con tantas y tan variadas
entidades, nos ha servido para descubrir gran parte de las mejoras a la metodologa
RMM que hemos propuesto:
Los accesos complejos, que pueden ser de tres tipos: navegacin jerrquica,
navegacin en relaciones N:M y navegacin mltiple.
Tambin se introdujo la nueva primitiva de acceso simultneo, que permite
acceder a todos los elementos simultneamente de una entidad con la que se
est relacionado.
Y para terminar, hay que notar la novedad que supone dividir el problema en
diferentes categoras o temas, de manera que los modelos sean legibles. Al
Pg. 242
VIII - Conclusiones
final, todo queda interconectado desde la jerarqua de mens, as como a

travs de algunos enlaces que existen entre entidades de diferentes categoras.
8.1.5.3. CD-ROM del Atles de les Illes Balears

ste ha sido el caso de estudio en el que ms se ha profundizado, sin duda porque ha
sido en el que el proyectista ha tenido una mayor participacin: en el primer caso,
SAlbufera, slo se pretenda hacer un anlisis de una aplicacin ya hecha, con el fin de
evaluarla. En el segundo, MINTour, el objetivo ya era el de hacer la aplicacin completa
a partir del anlisis, pero por una serie de causas internas al proyecto, la aplicacin tom
otros derroteros. Pero en este tercer caso, s se han podido seguir todas las fases de la
metodologa hasta obtener la aplicacin final.
Adems, la estructura de la informacin es bien diferente a MINTour, mucho ms rica,
con muchas ms inter-relaciones entre los datos, y se presta mejor a un anlisis
navegacional.
Como principal conclusin de este caso de estudio, consideramos que podemos citar que
se ha demostrado que s es posible el hacer un desarrollo completo de una aplicacin
siguiendo la metodologa RMM, con una serie de mejoras que ya se han comentado. No
obstante, hay una serie de aspectos sobre los que se debera profundizar, especialmente
en las fases posteriores al modelo RMDM, y bsicamente en la fase quinta, Diseo de la
interfaz de usuario, donde se interacta directamente con el diseador grfico, que a
menudo no conoce nuestra metodologa. En concreto, nosotros hemos incorporado a la
metodologa, la lista de los elementos grficos as como un conjunto de layouts para
representar la estructura de la pantalla, que ya se han sido citados en las conclusiones
acerca de la quinta etapa.
Para terminar, a partir de este caso de estudio se ha la nueva primitiva de acceso
aleatorio, que permite acceder a los elementos de una entidad aleatoriamente.
Pg. 243
VIII - Conclusiones
8.2. Lneas de futuro

ltimamente estn surgiendo nuevas metodologas, lo cual no es de extraar vista la
cierta inmadurez del tema de la ingeniera del software aplicada a la hipermedia. Entre
ellas destacaremos OOHDM, [SCH96], que es una extensin de HDM con orientacin a
objetos y que se est convirtiendo en una de las ms utilizadas. Otras interesantes
referencias pueden encontrarse en [GRE96] y [GRO96].
El continuar estudiando estas nuevas metodologas y aplicarlas a nuestros tres casos de
estudio, o a otros nuevos, podra ser objeto de nuevos proyectos finales de carrera.
La revisin a fondo de RMM (y otras metodologas), as como la posibilidad de
desarrollar una herramienta tipo CASE, pueden ser objeto de investigacin a partir del
trabajo que hemos desarrollado.
Pg. 244
IX - Bibliografa
Captulo IX
BIBLIOGRAFA
[BAL96]
V. Balasubramanian, M. Bieber, T. Isakowitz: Systematic

hypermedia
design.
Documento
pre-imprenta,
http://eies.njit.edu/~333/bala.html, CRIS Working Paper series
5/10/96 1996.
[BAR93]
M. Barcel, M. Costa, C. Quer: Anlisi daplicacions

informtiques. Edicions UPC. Barcelona.1993-1994.
[BRO91]
Diversos autores, editado por H. Brown: Hypermedia /

Hypertext and Object-oriented Databases. Chapman & Hall.
Londres. 1991
[GAR93]
F. Garzotto, P. Paolini, D. Schwabe: HDM - A model-based

approach to hypermedia applications design. ACM
Tranactions on Inforamtion Systems, vol. 11, pp. 1-23, 1993.
[GAR95]
F. Garzotto, L. Mainetti, P. Paolini: Hypermedia design,

analysis, and evaluation issues. Communications of the ACM,
vol. 38, pp. 74-86, 1995.
[GRE96]
T. R. G. Green, D. R. Benyon: The skull beneath the skin;

Entity-relationship modelling of Information Artefacts. Int J
Human-Computer Studies, 1996.
[GRO96]
K. Grnbk, R. H. Trigg: Toward a Dexter-based model for

open hypermedia: Unifying embedded references and link
objects. Presentado en The Seventh ACM Conference on
Hypertext, Washington DC, March 16-20, 1996, 1996.
[HAL94]
F. Halasz, M. Schwartz: The Dexter Hypertext reference

model. Communications of the ACM, vol. 37, pp. 30-39, 1994.
[HAR94]
L. Hardman, D.C.A. Bulterman, G. Van Rossum: The

Amsterdam Hypermedia Model. Communications of the ACM,
vol. 37, pp. 50-62, 1994.
[ISA95]
T. Isakowitz, E. A. Stohr, P. Balasubramanian: RMM: A

methodology
for
structured
Hypermedia
design.
Communications of the ACM, vol. 38, pp. 34-44, 1995.
[ISA96]
T. Isakowitz, A. Kamis, M. Koufakis: Extending the capabilities

of RMM: Russian dolls and Hypertext. Documento preimprenta, http://www.stern.nyu.edu/~tisakowi, 1996
[MAN94]
M. Manresa: Apuntes de la asignatura Disseny Lgic. Palma

de Mallorca. 1994-1995
[MIN96]
MINTour Project. TAP AD1009, 1996-98. El proyecto final est

en http://mintour.ibit.org:9000/
[NIE90]
J. Nielsen: Hypertext & Hypermedia. Academic Press Inc. San

Diego. 1990
Pg. 245
IX - Bibliografa
[PRE98]
R. S. Pressman: Ingeniera del software. Un enfoque prctico.

4 edicin. McGraw Hill. Madrid.1998
[SCH96]
D. Schwabe, G. Rossi, and S. D. J. Barbosa: Systematic

Hypermedia Application Design with OOHDM. Presentado en
The Seventh ACM Conference on Hypertext, Washington DC,
March 16-20, 1996, 1996.
[SOM96]
Ian Sommerville: Software Engineering. 5 edicin. AddisonWesley. EE.UU. 1996
[UIB95]
Parc Natural de SAlbufera . Universitat de les Illes Balears.

Palma de Mallorca. 1995.
[UIB98]
Atles de les Illes Balears. Universitat de les Illes Balears. Palma

de Mallorca. 1998.
Pg. 246

Metodologia de Hipermedia RMM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologia de Hipermedia RMM

Uploaded by

Copyright:

Available Formats

Una metodologa relacional hipermedia

Estudio en casos prcticos

Antonio Navarrete Terrasa

Este proyecto final de la carrera Ingeniera Superior en Informtica se ha desarrollado en

Una metodologa relacional hipermedia. Estudio en casos prcticos

1.2.2. Ingeniera del software ................................................................................................................12

CAPTULO II - LOS PRIMEROS MODELOS HIPERMEDIA .........................................................15

2.1.3. Capa de tiempo de ejecucin .......................................................................................................21

2.2.2. El modelo de hipermedia de Amsterdam......................................................................................28

2.2.5. Conclusiones ................................................................................................................................31

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

4.1.2.4. Etapa 3: Diseo navegacional............................................................................................................... 48

4.1.4. Conclusiones y discusin .............................................................................................................51

4.2.2. Las etapas de interfaz de usuario.................................................................................................57

4.3. MEJORAS EN ESTRUCTURAS NAVEGACIONALES PARA RMM.................................................................60

Una metodologa relacional hipermedia. Estudio en casos prcticos

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

7.3.7. Etapa 6: Diseo del comportamiento en tiempo de ejecucin ...................................................233

8.1.5. Casos de estudio.........................................................................................................................241

8.2. LNEAS DE FUTURO .............................................................................................................................244

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

1.1. Estructura del proyecto

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

la ingeniera del software, por otro, describiendo brevemente qu es una metodologa y

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

1.2. Conceptos fundamentales

En cambio el hipertexto es fundamentalmente no secuencial. No existe un nico orden

Antonio Navarrete Terrasa

Una metodologa relacional hipermedia. Estudio en casos prcticos

Una metodologa relacional hipermedia. Estudio en casos prcticos

1.2.2. Ingeniera del software

Una metodologa relacional hipermedia. Estudio en casos prcticos

Estas etapas confieren lo que tradicionalmente se denomina como el ciclo de vida de

Una metodologa relacional hipermedia. Estudio en casos prcticos

Las herramientas CASE permiten hacer un anlisis ms consistente y correcto,

Antonio Navarrete Terrasa

2.1. Modelo de Hipertexto de Dexter

2.1.1. Breve descripcin del sistema

Antonio Navarrete Terrasa

capa de tiempo de ejecucin

El modelo se centra en la capa de almacenamiento, que modela la estructura bsica de

puede presentarse de dos maneras diferentes segn el usuario. Si el usuario es un

2.1.2. Modelo simple de la capa de almacenamiento

Antonio Navarrete Terrasa

Ciclo: A no puede contener a

Ciclo: A no puede contener a

Cada componente tiene un identificador nico (UID). La funcin accessor es la que

2.1.2.1. Enlaces span-to-span

Antonio Navarrete Terrasa

info. de esp. pres. del componente

Y en el caso de un componente compuesto, la nica diferencia es que se guardan

info. de esp. pres. del componente

UID componente hijo

A partir de aqu, para representar los extremos de un enlace, emplearemos el id ancla

Antonio Navarrete Terrasa

(101,1) y el segundo (202,1). Adems, de esta pareja, el identificador debe definir el