Metodologia de hipermedia RMM

Una metodología relacional hipermediaEstudio en casos prácticos

Antonio Navarrete TerrasaProyecto final de carrera dirigido por Josep Blat Gimeno

Muchísimas gracias a:

Mi familia, por su apoyo constanteVirginia, por estar siempre a mi ladoMi director de proyecto, por haber confiado en míMis compañeros del Atlas y Mintour

Esto no habría sido posible sin vosotros.

Este proyecto final de la carrera Ingeniería Superior en Informática se ha desarrollado enPalma de Mallorca, durante los años 1996, 1997 y 1998, bajo la dirección del Doctor JosepBlat Gimeno.

Las ilustraciones que componen la imagen de la portada aparecen con el permiso de su autor,Antonio Fernández Coca.

Una metodología relacional hipermedia. Estudio en casos prácticos Contenidos generales

Antonio Navarrete Terrasa Pág. 3

CONTENIDOS

CONTENIDOS............................................................................................................................................3

CAPÍTULO I - INTRODUCCIÓN............................................................................................................7

1.1. ESTRUCTURA DEL PROYECTO..................................................................................................................71.2. CONCEPTOS FUNDAMENTALES..............................................................................................................10

1.2.1. Hipertexto, multimedia e hipermedia...........................................................................................101.2.1.1. Hipertexto............................................................................................................................................. 101.2.1.2. Multimedia ........................................................................................................................................... 111.2.1.3. Hipermedia ........................................................................................................................................... 111.2.1.4. Resumen ............................................................................................................................................... 11

1.2.2. Ingeniería del software ................................................................................................................121.2.2.1. Análisis................................................................................................................................................. 131.2.2.2. Diseño................................................................................................................................................... 14

CAPÍTULO II - LOS PRIMEROS MODELOS HIPERMEDIA .........................................................15

2.1. MODELO DE HIPERTEXTO DE DEXTER..................................................................................................152.1.1. Breve descripción del sistema ......................................................................................................152.1.2. Modelo simple de la capa de almacenamiento ............................................................................17

2.1.2.1. Enlaces span-to-span............................................................................................................................ 182.1.3. Capa de tiempo de ejecución .......................................................................................................212.1.4. Conclusiones ................................................................................................................................23

2.2. MODELO DE HIPERMEDIA DE AMSTERDAM ...........................................................................................242.2.1. Descripción de los conceptos del AHM .......................................................................................24

2.2.1.1. Hipertexto, multimedia e hipermedia.................................................................................................... 242.2.1.2. Información temporal ........................................................................................................................... 262.2.1.3. Enlaces en hipermedia .......................................................................................................................... 272.2.1.4. Atributos de especificación de la presentación a alto nivel .................................................................. 28

2.2.2. El modelo de hipermedia de Amsterdam......................................................................................282.2.3. Relaciones temporales .................................................................................................................302.2.4. Otras contribuciones del modelo .................................................................................................31

2.2.4.1. Contexto de los enlaces ........................................................................................................................ 312.2.4.2. Canales ................................................................................................................................................. 31

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

CAPÍTULO III - EL MODELO HDM ...................................................................................................32

3.1. OBJETIVOS Y MOTIVACIONES................................................................................................................323.2. PRIMITIVAS ...........................................................................................................................................34

3.2.1. Entidades y tipos de entidades .....................................................................................................353.2.2. Componentes................................................................................................................................353.2.3. Perspectivas .................................................................................................................................353.2.4. Unidades ......................................................................................................................................363.2.4. Enlaces en general .......................................................................................................................363.2.5. Enlaces de perspectiva o de componentes ...................................................................................363.2.6. Enlaces estructurales ...................................................................................................................373.2.7. Enlaces de aplicación y tipos de enlaces .....................................................................................373.2.8. Esquema HDM.............................................................................................................................37

3.3. EVALUACIÓN DE UNA APLICACIÓN USANDO HDM................................................................................393.4. CONCLUSIONES.....................................................................................................................................41

CAPÍTULO IV - LA METODOLOGÍA RMM......................................................................................42

4.1. LA PRIMERA FORMULACIÓN DE LA METODOLOGÍA RMM......................................................................424.1.1. El modelo RMDM ........................................................................................................................424.1.2. Etapas de la metodología.............................................................................................................46

4.1.2.1. Etapa 0.................................................................................................................................................. 464.1.2.2. Etapa 1: Diseño Entidad-Relación........................................................................................................ 464.1.2.3. Etapa 2: Diseño de slices...................................................................................................................... 47



4.1.2.4. Etapa 3: Diseño navegacional............................................................................................................... 484.1.2.5. Etapas 4 a 7: Interfaz de usuario y construcción................................................................................... 504.1.2.6. Relación con las etapas tradicionales de la Ingeniería del Software ..................................................... 51

4.1.4. Conclusiones y discusión .............................................................................................................514.2. EVOLUCIONES DE RMM .......................................................................................................................54

4.2.1. Estructura de datos y navegación ................................................................................................544.2.1.1. Slice mínimo y slice híbrido ................................................................................................................. 544.2.1.2. Los m-slices.......................................................................................................................................... 554.2.1.3. Conclusiones ........................................................................................................................................ 56

4.2.2. Las etapas de interfaz de usuario.................................................................................................574.2.2.1. Etapa 4: Diseño de protocolos de conversión....................................................................................... 574.2.2.2. Etapa 5: Diseño de la interfaz de usuario ............................................................................................. 584.2.2.3. Etapa 6: Diseño del comportamiento en tiempo de ejecución .............................................................. 584.2.2.4. Etapa 7: Construcción y tests................................................................................................................ 594.2.2.5. Conclusiones ........................................................................................................................................ 59

4.3. MEJORAS EN ESTRUCTURAS NAVEGACIONALES PARA RMM.................................................................604.3.1. Caso A: accesos jerárquicos ........................................................................................................604.3.2. Caso B: acceos en relaciones N:M ..............................................................................................624.3.3. Caso C: accesos múltiples............................................................................................................654.3.4. Conclusiones ................................................................................................................................69

CAPÍTULO V - 1ER CASO: CD-ROM DEL PARC NATURAL DE S’ALBUFERA..........................71

5.1. QUÉ ES EL CD-ROM DE PARC NATURAL DE S’ALBUFERA...................................................................715.1.1. Introducción.................................................................................................................................715.1.2. Estructura de la aplicación..........................................................................................................725.1.3. Premios recibidos.........................................................................................................................75

5.2. MODELADO DE LA NAVEGACIÓN DEL CD..............................................................................................765.3. APLICACIÓN DE TODAS LAS FASES DE LA METODOLOGÍA.......................................................................82

5.3.1. Primera etapa: Diseño entidad-relación .....................................................................................825.3.2. Segunda fase: Diseño de slices ....................................................................................................845.3.3. Tercera fase: Diseño navegacional..............................................................................................86

5.4. CONCLUSIONES.....................................................................................................................................89

CAPÍTULO VI - 2º CASO: PROYECTO EUROPEO MINTOUR .....................................................90

6.1. QUÉ ES MINT OUR................................................................................................................................926.1.1. Por qué nace MINTour ................................................................................................................926.1.2. Objetivos ......................................................................................................................................92

6.2. 1ª ETAPA: ANÁLISIS ENTIDAD-RELACIÓN .............................................................................................946.2.1. Áreas geográficas.........................................................................................................................946.2.2. Alojamientos.................................................................................................................................976.2.3. Playas.........................................................................................................................................1006.2.4. Deportes .....................................................................................................................................1026.2.5. Eventos culturales ......................................................................................................................1056.2.6. Museos y monumentos................................................................................................................1076.2.7. Naturaleza..................................................................................................................................1096.2.8. Entretenimientos ........................................................................................................................1116.2.9. Restaurantes...............................................................................................................................1136.2.10. Rent-a-car ................................................................................................................................1156.2.11. Tienda ......................................................................................................................................1176.2.12. Transporte aéreo......................................................................................................................1196.2.13. Transporte marítimo ................................................................................................................1226.2.14. Transporte terrestre .................................................................................................................1256.2.15. Transporte Urbano...................................................................................................................1286.2.16. Taxis.........................................................................................................................................1326.2.17. Paquete turístico ......................................................................................................................1336.2.18. Excursiones ..............................................................................................................................1346.2.19. Teléfonos y direcciones útiles ..................................................................................................1366.2.20. Agencias de viaje .....................................................................................................................137

6.3. 2ª ETAPA: DISEÑO DE SLICES..............................................................................................................1396.3.1. Áreas geográficas.......................................................................................................................139



6.3.2. Alojamientos...............................................................................................................................1416.3.3. Playas.........................................................................................................................................1446.3.4. Deportes .....................................................................................................................................1456.3.5. Eventos culturales ......................................................................................................................1476.3.6. Museos y monumentos................................................................................................................1496.3.7. Naturaleza..................................................................................................................................1516.3.8. Entretenimientos ........................................................................................................................1536.3.9. Restaurantes...............................................................................................................................1556.3.10. Rent-a-car ................................................................................................................................1576.3.11. Tienda ......................................................................................................................................1596.3.12. Transporte aéreo......................................................................................................................1616.3.13. Transporte marítimo ................................................................................................................1646.3.14. Transporte terrestre .................................................................................................................1676.3.15. Transporte Urbano...................................................................................................................1696.3.16. Taxis.........................................................................................................................................1736.3.17. Paquete turístico ......................................................................................................................1746.3.18. Excursiones ..............................................................................................................................1756.3.19. Teléfonos y direcciones útiles ..................................................................................................1766.3.20. Agencias de viaje .....................................................................................................................177

6.4. 3ª ETAPA: DISEÑO NAVEGACIONAL.....................................................................................................1796.4.1. Áreas geográficas.......................................................................................................................1806.4.2. Alojamientos...............................................................................................................................1826.4.3. Playas.........................................................................................................................................1846.4.4. Deportes .....................................................................................................................................1856.4.5. Eventos culturales ......................................................................................................................1876.4.6. Museos y monumentos................................................................................................................1886.4.7. Naturaleza..................................................................................................................................1896.4.8. Entretenimientos ........................................................................................................................1906.4.9. Restaurantes...............................................................................................................................1916.4.10. Rent-a-car ................................................................................................................................1926.4.11. Tienda ......................................................................................................................................1936.4.12. Transporte aéreo......................................................................................................................1946.4.13. Transporte marítimo ................................................................................................................1966.4.14. Transporte terrestre .................................................................................................................1976.4.15. Transporte Urbano...................................................................................................................1996.4.16. Taxis.........................................................................................................................................2026.4.17. Paquete turístico ......................................................................................................................2036.4.18. Excursiones ..............................................................................................................................2046.4.19. Teléfonos y direcciones útiles ..................................................................................................2056.4.20. Agencias de viaje .....................................................................................................................2066.4.21. Jerarquía de menús..................................................................................................................207

6.5. ETAPAS 4 A 7: INTERFAZ DE USUARIO Y CONSTRUCCIÓN....................................................................2096.6. CONCLUSIONES...................................................................................................................................211

CAPÍTULO VII - 3ER CASO: CD-ROM DEL ATLES DE LES ILLES BALEARS.........................213

7.1. QUÉ ES EL ATLES DE LES ILLES BALEARS..............................................................................................2137.2. PRIMER ESTUDIO DEL CASO.................................................................................................................215

7.2.1. Etapa 0: análisis de requerimientos...........................................................................................2157.2.2. Etapa 1: Diseño Entidad-Relación ............................................................................................2167.2.3. Etapa 2: Diseño de slices...........................................................................................................2177.2.4. Etapa 3: Diseño navegacional ...................................................................................................218

7.3. SEGUNDO (Y DEFINITIVO) ESTUDIO DEL CASO.....................................................................................2207.3.1. Etapa 0: análisis de requerimientos...........................................................................................2217.3.2. Etapa 1: Diseño Entidad-Relación ............................................................................................2217.3.3. Etapa 2: Diseño de slices...........................................................................................................2227.3.4. Etapa 3: Diseño navegacional ...................................................................................................2237.3.5. Etapa 4: Diseño de protocolos de conversión ...........................................................................2257.3.6. Etapa 5: Diseño de la interfaz de usuario..................................................................................226

7.3.6.1. Conclusiones de esta etapa ................................................................................................................. 232



7.3.7. Etapa 6: Diseño del comportamiento en tiempo de ejecución...................................................2337.3.8. Etapa 7: Construcción y tests.....................................................................................................233

7.4. CONCLUSIONES...................................................................................................................................234

CAPÍTULO VIII - CONCLUSIONES..................................................................................................235

8.1. RESUMEN FINAL Y CONCLUSIONES......................................................................................................2358.1.1. Modelo de Dexter.......................................................................................................................2358.1.2. Modelo de Amsterdam................................................................................................................2368.1.3. Modelo HDM .............................................................................................................................2378.1.4. Metología RMM .........................................................................................................................237

8.1.4.1. Evoluciones de RMM......................................................................................................................... 2388.1.4.1. Mejoras en las estructuras de navegación en RMM............................................................................ 239

8.1.5. Casos de estudio.........................................................................................................................2418.1.5.1. CD-ROM del Parc Natural de S’Albufera......................................................................................... 2418.1.5.2. Proyecto MINTour ............................................................................................................................. 2428.1.5.3. CD-ROM del Atles de les Illes Balears.............................................................................................. 243

8.2. LÍNEAS DE FUTURO.............................................................................................................................244

CAPÍTULO IX - BIBLIOGRAFÍA .......................................................................................................245

Una metodología relacional hipermedia. Estudio en casos prácticos I - Introducción


Capítulo IINTRODUCCIÓN

Las metodologías de Análisis y Diseño están orientadas a obtener un software fiable yeficiente, que cumpla los requerimientos preestablecidos.

Pero el desarrollo de una aplicación multimedia-hipermedia presenta dos aspectosespecíficos respecto al desarrollo del software tradicional:

• En el desarrollo de una aplicación multimedia pueden participar tipos degente muy diferentes, como, por ejemplo, informáticos, diseñadores, artistas,geógrafos, historiadores, filólogos, ..., cada uno de ellos con un lenguaje muydistinto, 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 seorientan al disfrute, a la consulta extensiva, ... frente al modelo transaccionalclásico. Es por ello que es frecuente la utilización del prototipado.

Varios intentos ha habido de crear modelos o metodologías orientados a este campo dela multimedia-hipermedia con el objetivo de dotar de un lenguaje común a los miembrosdel equipo y especialmente de mejorar las estructuras de navegación, haciéndola,sobretodo, más intuitiva al usuario final; y por supuesto que sin olvidar el propósito deconseguir que el producto resultante sea lo más fiable y eficiente posible.

El objetivo general es el de determinar una metodología que sea de utilidad para eldesarrollo de proyectos en el ámbito de la hipermedia. En nuestro proyecto se examinande forma relativamente breve algunas de las metodologías propuestas y los conceptosbásicos. Una de ellas, RMM, será aplicada y estudiada en gran detalle mediante trescasos prácticos que se corresponden a tres aplicaciones multimedia, en dos de los cualesel proyectista participa activamente. Ventajas, inconvenientes y posibles modificacionesa la metodología son propuestas.

Para ello la metodología será aplicada y estudiada mediante tres casos prácticos, que secorresponden a tres aplicaciones multimedia, en dos de los cuales el proyectistaparticipa activamente.

1.1. Estructura del proyecto

La estructura en que se presenta el proyecto no coincide exactamente con la evolucióntemporal que éste ha seguido, ya que los casos de estudio han determinado laspropuestas de mejora a la metodología, aunque en el presente documento éstas seexplican con anterioridad.

En este primer capítulo se definen los conceptos fundamentales entorno de los cuales vaa girar todos el proyecto, como son hipertexto, multimedia e hipermedia por un lado, y



la ingeniería del software, por otro, describiendo brevemente qué es una metodología yqué se entiende por análisis y diseño de software.

En el segundo capítulo, comenzaremos a centrarnos en las metodologías orientadas a lahipermedia. En primer lugar analizaremos el modelo de Dexter, el primer intento, quedata de finales de los 80, de investigar las características propias de la hipermedia,ofreciendo un modelo que describe su estructura. Dexter proporciona también unaterminología que a partir de entonces se consideraría estándar en este campo.Posteriormente se analiza el modelo de Amsterdam, fuertemente basado en el anterior,al que se añade el concepto de tiempo, que Dexter no consideró, principalmente debidoa que Dexter se ciñe fundamentalmente a hipertexto, y no considera la variedad demedios existentes y el principal problema que conllevan, que son las relacionestemporales.

En el tercer capítulo trataremos el modelo HDM (Hypertext Design Model). El objetivodel modelo HDM ya es, más que describir la estructura interna de una aplicaciónhipermedia como era el caso de Dexter y Amsterdam, crear un modelo que sea deutilidad para realizar el diseño de una aplicación, a partir de la estructura de datos. Es degran importancia este hecho de centrar en la estructura de datos un buen diseño de laaplicación. También el modelo basado en la estructura de datos es muy útil para elanálisis de aplicaciones ya existentes y comparaciones entre ellas.

Y en el cuarto capítulo nos centraremos en la metodología RMM (RelationshipManagement Methodology), que no sólo ofrece un modelo basado en la estructura dedatos, como el caso de HDM, sino que ya es una metodología completa. Se definen unaserie de etapas y modelos para cada una de ellas, desde el análisis inicial de requisitoshasta la implementación y pruebas. A continuación, explicaremos por qué elegimosRMM para nuestros casos de estudio y veremos, basados en la experiencia que éstos noshan deportado, los principales defectos y carencias que hemos encontrado en RMM y lasmejoras que nosotros hemos propuesto, fundamentalmente basadas en unos nuevospatrones de acceso a la información.

Los siguientes tres capítulos corresponden a los tres casos de estudio:

• Al realizar el análisis del CD-ROM del Parc Natural de S’Albufera fue laprimera vez que utilizamos la metodología RMM con un problemarelativamente grande. Se trata del análisis de una aplicación ya finalizada conel objetivo de encontrar enlaces de navegación que no se contemplaron aldesarrollarla.

• El segundo caso de estudio, el proyecto MINTour, es con mucho, el de mayorenvergadura. Se trata de un gran proyecto europeo sobre informaciónturística. Hemos realizado el análisis y diseño completo, si bien el modelofinal no fue implementado al alejarse el proyecto europeo de lasespecificaciones iniciales. Nos ha sido de gran ayuda para identificar losproblemas de RMM y los patrones de las estructuras navegacionales queproponemos como mejora.



• El tercer caso de estudio, el Atles de les Illes Balears, sí que ha dado lugar a laimplementación de la aplicación basada en el análisis y diseño utilizandoRMM. Es la confirmación de que RMM con nuestras mejoras es realmenteutilizable. Nos ha sido muy útil en los aspectos correspondientes a diseñarinterfaz gráfica estructurada, basada en el análisis.

Por último, en el capítulo final se ofrecen un resumen final, conclusiones y posiblelíneas de acción futuras.



1.2. Conceptos fundamentales

1.2.1. Hipertexto, multimedia e hipermedia

1.2.1.1. Hipertexto

La manera más sencilla de definir qué es hipertexto es compararlo con la formatradicional del texto, con pueda ser un libro. El texto tradicional es secuencial, es decirque hay una única secuencia lineal que define el orden en que el texto debe ser leído. Seempieza por la página 1, luego la 2, y así sucesivamente hasta la última. La figura lomuestra:

1 2 n...

En cambio el hipertexto es fundamentalmente no secuencial. No existe un único ordenen el que el texto debe ser leído. En la figura se ve claramente:

A B

C D

Como se ve, no hay un único camino para explorar, y por tanto ya no tiene sentidoenumerar las páginas, pues nunca se puede saber cuál será la segunda página, cuál latercera, e incluso ni siquiera la última.

Así, el hipertexto presenta diferentes opciones al lector y será cada lector,individualmente, el que determine cuál de ellos seguirá mientras lea el texto. Por tanto,el autor no debe sólo preparar una secuencia de lectura, sino numerosas.

En el segundo diagrama, cada una de las cuatro porciones de texto que vemosrepresentadas vemos representadas, reciben el nombre de nodos en la terminología dehipertexto. Estos nodos constituyen la unidad de información, la parte más pequeña consentido propio. Los nodos se interconectan, es decir se pasa de uno a otro, de unaporción de texto a otra, mediante lo que se denominan enlaces (links en inglés). Así, unenlace conecta dos nodos, uno el origen, llamado ancla (anchor) y el otro denominadodestino (destination).



Frecuentemente el enlace no está asociado a un nodo ancla en general, sino a una partede él en particular, como pueda ser un conjunto de caracteres. El mecanismo más típicode enlace en hipertexto es el de pulsar sobre una palabra (ancla) e ir (navegar) hacia eldestino, que puede ser por ejemplo su definición.

1.2.1.2. Multimedia

Con multimedia designamos a aquella aplicación que presenta varios medios, encontraposición a las aplicaciones tradicionales que sólo contienen uno, el texto.

Así, una aplicación multimedia puede contener, además del texto, gráficos, imágenes,secuencias de audio y/o vídeo, animaciones en dos o tres dimensiones, ...

La interactuación de los diferentes medios y la sincronización entre ellos suele ser unode los aspectos más 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. Esun hipertexto multimedia.

La estructura de una aplicación hipermedia es la misma que la de un hipertexto,formado por nodos que se conectan mediante enlaces. La única diferencia es que losnodos contienen elementos de diferentes medios. Los anclas ya no sólo son palabrassino que pueden, por ejemplo, ser una imagen o un fragmento de ellas. El mayorproblema es establecer anclas en un medio que depende del tiempo, como el vídeo o elaudio. Es difícil hacer notar al usuario que si pulsa sobre un vídeo, el destino del enlaceserá diferente según el momento del vídeo, y mucho más complejo todavía es definirenlaces con el sonido, ya que éste no se puede pulsar.

Como claro y muy difundido ejemplo de hipermedia tenemos las páginas web. Allá,podemos crear nodos incluyendo texto, y cualquier elemento multimedia, y crear losenlaces, definiendo los anclas, ya sea en elementos de texto, en imágenes, e incluso yaes posible en fragmentos concretos de una película de vídeo.

1.2.1.4. Resumen

Hemos visto tres conceptos diferentes:

• hipertexto: texto en formato no secuencial, compuesto de nodos y enlacesque los interconectan

• multimedia: unión de diferentes medias, como texto, gráficos, vídeo, ...• hipermedia: hipertexto + hipermedia

A pesar de que la diferencia entre estas tres definiciones es clara, es frecuente utilizarlos términos indistintamente. En concreto, hoy día son muy poco corrientes los



hipertextos puros, ya que casi todos incluyen elementos multimedia, aunque sólo seapara hacerlos más vistosos y atractivos. Por otro lado, no todas las aplicacionesmultimedia son hipermedia, ya que pueden ser una simple presentación de pantallas enorden secuencial. No obstante, a menudo se utilizan indistintamente los términoshipermedia y multimedia, ya que se entiende que una buena aplicación multimedia debeser en realidad hipermedia, y sino no es más que una simple presentación, no unaaplicación.

1.2.2. Ingeniería del software

En [PRE98], en su prólogo a la edición española encontramos cuatro diferentesdefiniciones de qué es la ingeniería del software, de sendos expertos en el tema. Creoque todas ellas son de gran interés:

1. «Ingeniería de Software es el estudio de los principios y metodologías paradesarrollo y mantenimiento de sistemas de software.» (Zelkovitz, M.V., Shaw,A.C. y Gannon, J.D.: Principles of Software Engineering and Design. Prentice-Hall. 1979).

2. «Ingeniería del Software es la aplicación práctica del conocimiento en el diseño

y construcción de programas de computadora y la documentación asociadarequerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambiéncomo desarrollo de software o producción de software.» (Boehm, B.W.:Software Engineering. IEEE Transactions on Compueters, C.25, nº 12,diciembre, pp 1226-1241).

3. «Ingeniería del Software trata del establecimiento de los principios y métodos de

la ingeniería a fin de obtener software de modo rentable que sea fiable y trabajeen máquinas reales.» (Bauer, F.L.: Software Engineering, InformationProcessing, 71. North Holland Publishing Co., 1972).

4. La Ingeniería del Software hace referencia a «la aplicación de un enfoque

sistemático, disciplinado y cuantificable al desarrollo, operación(funcionamiento) y mantenimiento del software.» (IEEE: Standards Collection:Software Engineering. IEEE Standard 610.12-1990, IEEE 1993).

Lo que parece claro después de estas cuatro definiciones es que la Ingeniería delSoftware pretende proveernos de unas metodologías, es decir unos conjuntos demétodos y de herramientas, con el objetivo de obtener un software fiable, de modorentable, fácil de mantener, a base de un desarrollo sistemático.

Han sido numerosísimas las metodologías que durante las últimas décadas han sidoutilizadas. Hay muchas diferencias entre ellas, pero casi todas tienen una base más omenos común. La principal es la división del proceso en unas etapas bien diferenciadasque componen lo que comúnmente se denomina análisis, diseño e implementación ypruebas. Cada una de ellas supone una visión, de más a menos abstracta, del problema.



Estas etapas confieren lo que tradicionalmente se denomina como el ciclo de vida deuna aplicación, al que habría que añadirle una cuarta etapa muy importante que es la delmantenimiento.

Las etapas de análisis y diseño son la base para un obtener un buen sistema. Un malanálisis y diseño, por muy buenos que sean los programadores, acarreará un sistemaineficiente, poco fiable, pero sobretodo muy costoso de ser mantenido. Estas etapasutilizan unas herramientas diferentes para poder describir el sistema, a su nivel deabstracción correspondiente. Por herramientas aquí no se entiende herramientasautomáticas, sino métodos de modelado, es decir un conjunto de modelos y documentos,que deben ir acompañados de unos principios claros para ser generados, y que pretendendescribir un aspecto de la aplicación, como pueda ser, por ejemplo la estructura de losdatos.

A continuación, veremos brevemente las principales características de las etapas deanálisis y diseño, así como de los métodos de modelado más comúnmente utilizados porlas más famosas metodologías, en cada caso.

1.2.2.1. Análisis

El análisis ofrece una primera representación del sistema. Su objetivo es hacer unanálisis de los requisitos del sistema, desde un punto de vista funcional y obtener unmodelo, que aprobado por el usuario sirva de base para el diseño.

El análisis, como hemos dicho, ofrece un modelo funcional del sistema, es decir decómo debe ser el sistema, qué información y funciones debe tener. En el diseño seespecificará en detalle cada una de esas funciones. Así, aquí se define qué deberá hacerel sistema y en el diseño cómo lo debe hacer.

La revisión con el cliente de las especificaciones funcionales del software, resultado deesta fase, es de vital importancia, y a menudo compleja debido a los lenguajes diferentesque utilizan cliente y desarrollador. La creación de prototipos suele ayudar a estacomunicación y a la detección de problemas y necesidades.

Métodos de modelado del análisis

Para especificar el análisis del sistema se utilizan una serie de modelos. Generalmente elmodelado del análisis se divide en dos partes fundamentales, el modelo de datos y elmodelo de flujos.

El modelo de datos se basa en el modelo entidad-relación, donde se definen todas lasentidades que participan en el problema y las relaciones entre ellas. Un diccionario dedatos, donde se describen las entidades y sus atributos acompaña siempre a este modelo.

En cuanto al modelo de flujos, se utiliza el denominado modelo de flujo de datos, dondese representa cómo los datos se transforman, definiendo las principales funcionalidadesdel sistema. En determinados sistemas también se incluyen modelos de estado, donde sedescriben las transiciones de estado que sufren las diferentes entidades.



Las herramientas CASE permiten hacer un análisis más consistente y correcto,utilizando la mayoría de ellas todos los modelos anteriormente descritos.

1.2.2.2. Diseño

Durante el diseño se profundiza en los aspectos que ya fueron tratados en el análisis. Sien el análisis nos deteníamos en estudiar qué es lo que deberá hacer el sistema, en eldiseño investigamos cómo debe hacerlo, definiendo en detalle todos los procesos delsistema y datos que éstos afectan. Se profundiza y completa la estructura de datos, porun lado y la de programa, por otro. Esta división entre datos y programa (o procesos), dalugar a lo que en algunas metodologías se denomina diseño de datos y diseño deprocesos, también llamado diseño arquitectónico. A estas dos divisiones, habría queañadir una tercera correspondiente al diseño de la interfaz de usuario.

El resultado final del diseño es una representación lo más exacta posible de lo que serála aplicación. A partir de esa representación los programadores han de ser capaces decodificar los modelo y convertirlos en la aplicación.

Métodos de modelado del diseño

Cada una de las partes del diseño cuenta con sus propios modelos.

El diseño de datos traduce el modelo entidad-relación con su diccionario de datos en eldiseño de la base de datos, definiendo todas las tablas, índices, atributos, ..., necesarios.

En cuanto al diseño de procesos, también se continúa trabajando con los DFDs(diagramas de flujos de datos). Se incluyen ya las tablas en vez de las entidades, y sellega a una mayor profundidad en la jerarquía de procesos, hasta alcanzar el detalle dedefinir los procedimientos que serán necesarios en pseudocódigo u organigramas.Algunos autores denominan a esto último diseño procedimental y lo consideran comouna cuarta etapa del diseño, diferente del diseño arquitectónico.

El diseño de la interfaz no está tan estandarizado como puedan estarlo los modelos delas otras fases del diseño. Se basa bastante en la experiencia del diseñador, y porsupuesto en los procesos donde intervenga el usuario que se hayan definido en el diseñoarquitectónico. A menudo se utilizan técnicas de prototipado para comprobar laaceptación por parte de los usuarios de la interfaz propuesta.

Una metodología relacional hipermedia. Estudio en casos prácticos II - Los primeros modelos hipermedia


Capítulo IILOS 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 extensión al de Dexter añadiendo aspectostemporales.

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 sunombre, como un intento de respuesta a la pregunta: ¿qué tienen en común los distintossistemas de hipertexto en sus nociones de nodos y enlaces (links) entre dichos nodos?

Así, se pretende que el modelo sirva como un estándar para comparar las característicasy funcionalidades de varios sistemas de hipertexto. También como una base sobre lacual desarrollar estándares para interoperabilidad e intercambio entre sistemas dehipertexto.

Otro punto importante de este trabajo es el de proveer de una terminología común alcampo del hipertexto.

Nótese que, a pesar de que a menudo se diferencia entre hipertexto e hipermedia, aquílos autores no hacen tal distinción.

Las presentes notas están basadas en el artículo [HAL94].

2.1.1. Breve descripción del sistema

El modelo de Dexter divide el sistema hipertexto en tres capas diferentes. La primera, lamás próxima al usuario es la denominada capa de tiempo de ejecución (run-timelayer); la intermedia es la llamada capa de almacenamiento (storage layer), mientrasque la última recibe el nombre de capa del componente (within-component layer).



El modelo se centra en la capa de almacenamiento, que modela la estructura básica denodos y enlaces. Vendría a ser como una base de datos donde se almacena una jerarquíade componentes (contenedores de la información) interconectados por enlaces.

Los componentes es lo que conocemos típicamente como nodos (por ejemplo una tarjetaen Hypercard, o un frame en Director). Por tanto, un componente puede contenerfragmentos de texto, gráficos, animaciones, ... Al estudiar la capa de almacenamientoveremos que éstos son lo que llamamos componentes atómicos, que al unirse formancomponentes compuestos, que es el equivalente a la noción de nodo.

La capa de almacenamiento estudia los mecanismos por los cuales se unen dichoscomponentes y enlaces.

Por contra, la capa del componente refleja los contenidos y estructura dentro de loscomponentes. Debido a que hay un sin fin de posibles contenidos/estructuras quepueden ser incluidos en un componente, el modelo de Dexter no profundiza el estudiode esta capa, dando libertad en este nivel.

Una parte fundamental del modelo de Dexter es la interfaz entre las capa dealmacenamiento y la capa del componente. Se basa en el mecanismo de anclaje(anchoring), que veremos más adelante.

En cuanto a la capa de tiempo de ejecución, ésta provee al usuario de unas herramientaspara acceder, ver y manipular la estructura de la red de hipertexto. Al igual que en lacapa del componente, también existen un gran número de posibles herramientas paraacceder, ver y manipular un hipertexto. Por consiguiente, el modelo Dexter sólo ofreceunas ideas básicas de cómo son esos mecanismos, pero no puede hacer referencia a losdetalles de cómo el usuario interactúa con el hipertexto.

Un punto importante es la interfaz entre esta capa y la capa de almacenamiento, a la quellama especificaciones de presentación (presentation specifications). Ésta es unmecanismo que permite que la forma en que un componente se presenta al usuariopueda estar en función no sólo de una herramienta de hipertexto específica (es decir, deuna capa de tiempo de ejecución específica), sino que puede ser una propiedad delcomponente por sí mismo, del enlace tomado para llegar a tal componente o también delas preferencias del usuario. Por ejemplo, un componente que contiene una animación

capa de tiempo de ejecución(run-time layer)

capa de almacenamiento(storage layer)

capa del componente(within-component layer)

Especificaciones de presentación

Anclaje (anchoring)



puede presentarse de dos maneras diferentes según el usuario. Si el usuario es unprofesor, se le permitirá editar el componente (la animación), mientras que si el usuarioes un alumno, sólo se le permite la visualización.

En la siguiente figura, vemos una representación más gráfica de las tres capas delmodelo de Dexter. En la capa de tiempo de ejecución, tenemos la presentación delhipertexto al usuario a través de la pantalla. En la capa de almacenamiento, vemos unabase de datos donde se almacenan todos los componentes y enlaces entre ellos (losenlaces también son componentes). Y por último en la capa del componente, se guardala estructura interna del componente.

Componente 24

Componente 37

Comp. 55

2437

Esto es un texto

CAPA DETIEMPO DE

EJECUCIÓN

CAPA DEALMACENAMIENTO

CAPA DELCOMPONENTE

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. Esel componente el elemento fundamental de esta capa; éste puede ser un átomo, un enlaceentre componentes, o puede estar compuesto a partir de otros componentes (formandoun grafo acíclico, ya que un ciclo implicaría una recursividad). En el siguiente ejemplovemos dos casos prohibidos de componentes compuestos, debido a que creanrecursividad. Cada cuadro representa un componente compuesto; en la parte superioraparece en nombre del componente y en la inferior los componentes (atómicos ocompuestos) que la forman.



Cada componente tiene un identificador único (UID). La función accessor es la queaccede a un componente dado su UID, mientras que la función resolver permite, a partirde unas especificaciones del componente recuperar los UID correspondientes. Despuésse podrá acceder al componente mediante accessor. Por tanto, accessor constituye undireccionamiento directo a las componentes, mientras que resolver se utiliza para undireccionamiento 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 otraparte de otro componente.

Para conseguir los enlaces span-to-span Dexter provee de una entidad dedireccionamiento indirecto llamada ancla (anchor). Un ancla tiene dos partes: unidentificador (id ancla - anchor id) y un valor (anchor value). El identificador es únicodentro de cada componente. Por tanto, el par UID componente - id ancla es único dentrodel hipertexto. El id ancla es manejado por la capa de almacenamiento para referenciaral contenido del componente, y se mantiene siempre constante; mientras, el valor delancla es utilizado sólo en la capa del componente, y cuando se edita y modifica elcomponente. Por otro lado, el valor del ancla especifica de forma arbitraria algunalocalización, región, ítem o subestructura dentro de componentes. Éste es sólointerpretable por las aplicaciones responsables de manejar el contenido/estructura delcomponente.

Veamos cómo resulta la estructura de un componente atómico, teniendo en cuenta lasanclas:

A C

A

A C

A

A C

BCiclo: A no puede contener aun componente que contiene aA

Ciclo: A no puede contener aA



Y en el caso de un componente compuesto, la única diferencia es que se guardantambién los UIDs de los componentes hijos

A partir de aquí, para representar los extremos de un enlace, emplearemos el id anclacombinado con la especificación del componente, de cada extremo. Es lo que llamamosun especificador (specifier). Además de la especificación de un componente y un idancla, son utilizados dos campos más: una dirección y una especificación depresentación de ese enlace. Como vemos, el especificador constituye, un extremo delenlace, y por tanto, un enlace está formado por dos o incluso más especificadores. En elcaso de tener más de dos especificadores, tenemos lo que se denominan enlacesmúltiples (multiway links). El campo dirección puede tomar varios valores: TO, FROM,BIDIRECT y NONE; el campo especificación de presentación se refiere a la interfazentre la capa de almacenamiento y la capa de tiempo de ejecución, de la cual se hablaráposteriormente más en detalle.

A continuación se muestra un ejemplo de enlace entre los componentes atómicos 101 y202. 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 citadoscomponentes. Por tanto, tiene dos especificadores. Recordemos que los especificadoresse definen con una pareja UID componente - id ancla. Por tanto, el primero tiene el par

Anclas

Especificaciónde presentación

info. de esp. pres. del componente

Atributosinfo. semántica (incluido el UID)


info. de esp. pres. del componente

id

Atributos

valor

info. semántica (incluido el UID)

Hijos

Anclas

Contenidosdatos

id

valor

UID componente hijo

Contenidosdatos



(101,1) y el segundo (202,1). Además, de esta pareja, el identificador debe definir elsentido del enlace, en este caso del 101 (FROM) al 202 (TO).

Vemos primero un diagrama y después la descripción escrita del modelo.

<hipertexto><componente>

<tipo>texto</tipo><uid>101</uid><especificación de presentación>...</especificación de presentación><datos>Esto es un texto ...</data><ancla>

<id>1</id><valor>22-26</valor> (La posición 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><especificación de presentación>...</especificación de presentación><especificador>

<uid componente>101</id><id ancla>1</valor>

Componente 202

Componente 303

Componente 101

tipo: textouid: 101especif. pres.: ...Anclas

Esto es untexto...xxxxx ...

valor id1

tipo: textouid: 202especif. pres.: ...Anclas

Esto es otrotexto...yyyyyy ...

valor id2

Especificador uid componente: 101 id ancla: 1 dirección: FROM especif. pres.: ...

Especificador uid componente: 202 id ancla: 2 dirección: TO especif. pres.: ...

tipo: enlaceuid: 303especif. pres.: ...



<dirección>FROM</dirección><especificación de presentación>...</especificación de presentación>

</especificador><especificador>

<uid componente>202</id><id ancla>2</valor><dirección>TO</dirección><especificación de presentación>...</especificación de presentación>

</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 atómico, crear un componente compuesto, crear un enlace,modificar o borrar los anteriores.

Por último, no deben obviarse nunca estas cinco reglas:

• La función accessor debe permitir que cada componente sea accesible desdeun UID.

• La función resolver debe ser capaz de producir todos los posibles UIDsválidos.

• No hay ciclos en las relaciones componente/subcomponente (un componenteno puede ser subcomponente de sí mismo.

• Los identificadores de anclas de un componente han de ser los mismos quelos identificadores de anclas del especificador de enlace, cuyo extremo es esecomponente.

• El hipertexto debe ser lo que se denomina link-consistent, es decir, que alborrar un componente se borren también los enlaces que lo tienen comoextremo.

2.1.3. Capa de tiempo de ejecución

El concepto fundamental de la capa de tiempo de ejecución es la instanciación de uncomponente. Una instanciación es una presentación de un componente al usuario.

El funcionamiento es similar al de una cache: una copia (instanciación) de uncomponente se pasa al usuario para que la visualice y/o edite. Esta copia será despuésescrita de nuevo en la capa de almacenamiento. Nótese que puede haber más de unainstanciación de un componente a la vez. Por ello, a cada instanciación se le asigna unidentificador único (instantiation identifier - IID ).



Recordemos que la manera en que el componente se presenta al usuario dependerá delas preferencias que tenga definidas en las especificaciones de presentación.

La instanciación de un componente también conlleva la de sus anclas. A esto se lellamará marcador de enlace (link marker), que es la manifestación visible de un anclaen un documento.

En resumen, una instanciación contendrá:

• una instanciación base (base instantiation), que es una primitiva del modeloque representa algún tipo de presentación de el componente al usuario.

• una secuencia de marcadores de enlace junto con una función que hagacorresponder esos marcadores de enlaces a las anclas que instancian.

Como que en un momento dado un mismo usuario puede estar visualizando y/oeditando varias instanciaciones de componentes, se define una nueva entidad en elmodelo que es la sesión, que permite saber momento a momento la relación entre loscomponentes y sus instanciaciones. Así, cuando un usuario pretende acceder a unhipertexto, lo que hace es abrir una sesión. Y esto es lo que será necesario para cadasesión:

• el hipertexto que es accedido

• los IID de las instanciaciones a componentes de la capa de almacenamientoque se utilizan en esta sesión

• una historia, que contiene las operaciones que se han hecho desde que se abrióla sesión

• una función run-time resolver, que es el equivalente a la función resolver dela capa de almacenamiento

• una función de instanciación (instantiator), que devolverá, a partir de un UIDy una especificación de presentación (otra primitiva del modela que definecómo se “presentará” un componente), una instanciación del componentecomo parte de la sesión.

C. tiempoejecución

Capaalmacenam. componente 345 - botón

instancia del botón que sepresenta al usuario

>



• una función realizer, que es la inversa de la función de presentación. Es decir,que a partir de una instancia, devuelve un componente que “refleje” el estadoactual de la instanciación. Esto es usado para el mecanismo de “writing-backin cache”, es decir, de crear o modificar el componente en la capa dealmacenamiento.

Al igual que teníamos un conjunto de funciones que permitían acceder y modificar lacapa de almacenamiento, también tenemos un conjunto de operaciones que nos lopermiten sobre la capa de tiempo de ejecución. Estas operaciones, sobre las quetampoco profundizaremos, nos permiten, entre otras cosas, crear una sesión, crear unainstanciación para un componente, actuar sobre el componente asociado con lapresentación, seguir un enlace, ...

2.1.4. Conclusiones

Dexter fue el primer intento de modelar el hipertexto y de dar una terminología comúnpara este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que sonhoy.

De hecho, la principal carencia que se puede observar en este modelo es que, a pesar deque los autores lo recomiendan para tanto hipertexto como hipermedia, no aborda enningún momento la complejidad de los distintos medios. En realidad, se podría decirque el modelo está fundamentalmente destinado sólo a hipertexto, y la aplicación a lahipermedia es muy difícil. Por ejemplo, el concepto de valor del ancla lo hace enfunción de la posición 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, algofundamental en el audio y el vídeo. Es por ello que posteriormente apareció el modelode Amsterdam, que basado en Dexter, añade el estudio del tiempo.

Pero, a pesar de eso (no hay que olvidar que estos elementos eran imposibles de utilizaren 1988), el modelo especifica, por primera vez y muy detalladamente, cómo es laestructura interna de un hipertexto. Incluso define unas estructuras que no habían sidoutilizadas hasta entonces como los enlaces múltiples, la posibilidad de hacer un enlace aotro enlace (recordemos que los enlaces son componentes) o los componentescompuestos, que por aquel entonces muchos sistemas de hipertexto no soportaban.



2.2. Modelo de hipermedia de Amsterdam

Hipermedia es la suma de hipertexto y multimedia. El hipertexto nos provee de unaestructura de navegación a través de los datos, mientras que la multimedia nos ofrececomo punto fundamental una gran riqueza de tipos de datos.

Sin embargo, el modelo de Dexter, aunque según sus autores está orientado ahipermedia, la realidad es que se centra por completo en el hipertexto, dejando de ladoel estudio de la variedad de tipos posibles. Y entre esos tipos, no hay que olvidar que loshay dependientes del tiempo. Por tanto, el modelo de Dexter comete un gran olvido: notoma en consideración el concepto del tiempo. Se hace necesario un nuevo modelo dedatos multimedia, en el que se van a ver reflejadas relaciones complejas en tiempo. Porejemplo, es necesario contemplar algo tan típico en una aplicación hipermedia como quea los 4 seg. de que se active un vídeo, aparezca cierto texto (sincronización entrecomponentes). Sobre estos conceptos surge el Modelo de Hipermedia de Amsterdam(AHM).

En resumen, mientras que el modelo de Dexter permite la composición de estructurasjerárquicas, la especificación de enlaces entre componentes y el uso de anclas, el modelode Amsterdam lo extiende añadiendo las nociones de tiempo, presentación a alto nivelde atributos y enlaces de contexto.

Hay cierto vocabulario ligeramente diferente al empleado en Dexter: un documento esuna colección completa de componentes, cada uno de los cuales puede estar compuestode otros componentes, o bien de componentes atómicos, llamados aquí elementos dedatos (data elements) o también entidades. Una presentación es la forma activa de undocumento. A menudo, se habla indistintamente de documento o de presentación.

Este apartado está basado en el artículo [HAR94].

2.2.1. Descripción 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 mediosdinámicos que dependan del tiempo. El concepto fundamental es la sincronización entreellos.



tiempo

tiempo

(c)(b)(a)

Componentes (de varios medios) Enlace

En la parte (a) de la figura, tenemos una red de hipertexto con enlaces entrecomponentes. La visita a un componente termina bien por la finalización de laaplicación o bien por el paso a otro componente a través de un enlace. Aquí el tiempoapenas cuenta y tenemos básicamente hipertexto.

En la parte (b) de la figura, tenemos una presentación multimedia. El usuario controlaqué componente quiere visitar, pero ese componente puede ser dinámico, es decir quevaría sin la intervención del usuario, según una noción temporal. Dos tipos de controldel usuario sobre las presentaciones se permiten aquí. La primera, la típica similar alpanel de control de un cassette o vídeo-reproductor, con los controles stop/play/fastforward/rewind. La segunda sería similar a un enlace hipertextual y nos llevaría de unpunto temporal del componente a otro (sería similar a un fast forward pero parando enun punto definido de antemano).

La parte (c) de la figura muestra la combinación entre hipertexto y multimedia: cadacomponente de la red hipertexto es una presentación multimedia. Así, hay dos aspectosa tener en cuenta, que son la navegación hiperestructurada dentro del documento y lapresentación de la información multimedia. Esto sería hipermedia específicamente.



2.2.1.2. Información temporal

En general, un modelo de hipermedia debería ser capaz de especificar cómo las partesindividuales se relacionan unas con otras. Una de esas relaciones es evidentemente latemporal. De hecho, a menudo, estas relaciones temporales se han representado como unsimple enlace hipertextual. Esto es conceptualmente un error, ya que así se mezclan dosaspectos separados de una presentación como son las relaciones hipertextuales y lastemporales. La solución que se propone en Amsterdam es la de particionar las relacionestemporales entre datos en dos clases:

• aquellas que se refieren a la identificación de los componentes que estaránpresentes conjuntamente. A esta clase se la denomina colección.

• aquellas que se refieren al orden relativo en el que estos componentes sonpresentados. A esta clase se le da el nombre de sincronización.

Los componentes compuestos de Dexter pueden ser usados para “recoger” un conjuntode componentes atómicos que van a ser presentados juntos. Pero esta definición no nosofrece un mecanismo para especificar ninguna relación temporal. El problema es lasincronización entre esos componentes. Así la sincronización puede estar basada bien eninformación estructurada, o bien en el contenido de un componente.

Hay varias maneras de afrontar el problema de la colección y sincronización dentro deun hipermedia. A continuación mostramos tres diferentes estrategias:

Componentes (de varios medios) Enlace

(a) (b) (c)

tiempo tiempo tiempo



(a) Estructura oculta

La manera más básica y más frecuente de manejar los datos dependientes deltiempo consiste en poner todos estos datos dentro un único componente. En eldiagrama vemos que tenemos cuatro media diferentes, y queda explicitado elinstante en que son activados cada uno de ellos. Esta solución no requiere apenasningún cambio en relación al modelo de Dexter. Todo queda definido entérminos de la capa del componente y la sincronización usa técnicas internas(ocultas). Como contrapartida, no permite definir combinaciones de datos máscomplejas.

(b) Estructura separada

Éste es el caso completamente opuesto. Aquí, cada parte de informaciónmultimedia forma un bloque diferenciado. La colección queda representadamediante un enlace multi-destino que apunte al inicio de todos los bloques(mientras que en la solución anterior únicamente era necesario un único enlaceque apuntara al inicio del componente). Cruzar el enlace significará activar esecomponente. Mientras que la colección es fácilmente representable, lasincronización no lo es tanto, ya que hace falta algún mecanismo para determinarcuándo un componente debe iniciarse en relación a los otros.

Por tanto, los inconvenientes de este método son que añaden una grancomplejidad dado el gran número de enlaces que son necesarios crear ymantener. Cualquier herramienta tendrá que ser compleja y con una difícilinterfaz de usuario.

(c) Estructura compuesta

Ésta es la solución intermedia, compromiso entre colección y sincronización.Aquí varios elementos son agrupados en componentes compuestas. Estascomponentes compuestas pueden agrupar uno o varios medias.

La colección es más simple que en la segunda solución y el problema de lasincronización queda reducido a relaciones internas.

A menudo, la solución no será simplemente elegir entre uno de estos tres enfoques. Dehecho esto sólo ocurrirá con hipermedias pequeños. Lo habitual será descomponer elproblema en pequeños sub-problemas, a cada uno de los cuales sí que les aplicaremosuna de estas tres soluciones según nos convenga.

2.2.1.3. Enlaces en hipermedia

Los enlaces influyen tanto en el orden de la presentación, como en los componentes quese visualizan simultáneamente, pero no son éstos sus aspectos fundamentales, ya que elobjetivo de un enlace debería ser definir un mecanismo de navegación lógica en undocumento.



Un enlace es aquello que define una transición de un componente a otro. Sin embargo,la noción 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 puedeser dividido en pequeñas partes (capítulos, secciones, ..., palabras y caracteres), y asípodemos utilizar el mecanismo de anclaje. Pero en un sistema multimedia, la asociaciónde un enlace con o dentro de un componente es mucho más compleja, ya que los datos amenudo no pueden ser fragmentados ni indexados.

Otro problema que no se trata en Dexter es el que se refiere a cuánta información deja elusuario al navegar a través de un enlace. En un sistema de hipertexto, al cruzar unenlace, o bien se abre una nueva ventana, o bien se sustituye lo que se estabavisualizando por la información nueva. Esto es indicado aquí porque el usuario sólopuede leer una cosa a la vez. Pero en un entorno hipermedia, puede interesarle, porejemplo, seguir oyendo una explicación, viendo el mismo vídeo, pero pasar a ver unanueva imagen o texto, dependiendo del lugar en que se encuentre de la aplicación. Paratratar esto, se introduce la noción de contexto del enlace, que será tratado más adelante.

2.2.1.4. Atributos de especificación de la presentación a alto nivel

En una aplicación hipermedia típica, cada pantalla contiene unos elementos de datospropios; pero, además, todas las pantallas tienen elementos que comparten un conjuntocomún de atributos para un tipo de datos en concreto. Por ejemplo, imaginemos unaudio que se utiliza a lo largo de una presentación. En cada pantalla se usan diferentesconjuntos de datos de audio, pero todas las pantallas compartirán unos atributos como elvolumen o la calidad del tono, los cuales no queremos que cambien cada vez quepasemos de una pantalla a otra. Por tanto, estos atributos tienen una definición globalpara toda la presentación y serán asociados no sólo a un componente, sino a toda un tipode información (o medio).

Estos atributos globales, que no se consideraron en el modelo de Dexter, se manejanutilizando el mecanismo de canales, que veremos más adelante.

2.2.2. El modelo de hipermedia de Amsterdam

Este modelo se definió a partir de la combinación del modelo de Dexter con los canales,añadiendo extensiones para soportar ciertos requerimientos de la hipermedia que nohabían sido contemplados. ha sido empleado para desarrollar numerosas aplicacioneshipermedia.

Veamos cuál es la estructura de un componente, ya sea atómico o compuesto en elmodelo de Amsterdam y comparémoslo con el de Dexter, que ya vimos en el apartadoanterior.

Componente atómico:



Componente compuesto:

Vemos que un componente compuesto no contiene datos, sino que sólo los datos sólopueden ser referenciados a través de los componentes atómicos.

Este enfoque tiene tres ventajas sobre Dexter:

• Localiza la información temporal y de presentación en las componentesatómicas, mientras que la estructura de la presentación se deja para lascomponentes compuestas. En teoría, esto facilita las tareas de mantenimiento.

Anclas


id componente destino


nombre del canal

Atributosinfo. semántica (incluido el ID)

Anclasid

valor

Contenidos

id

lista de (id componente - id ancla)

Tipo decomposición

datos

duración - explícita o implícita

info. de esp. pres. de otros

info de esp. pres. del componente

id componente origen

relación temporal

Arcos desincronización

Atributosinfo. semántica (incluido el id)

Opción o paralelo

Arcos desincronización

id componente

tiempo de inicio



• Promueve la reusabilidad de datos al forzar que todos los elementos semantengan por separado.

• Modela de forma más aproximada la forma en que la información multimediase almacena, esto es, en sistemas de ficheros o bases de datos.

Así, los componentes atómicos contienen información sobre la presentación, atributos,información de anclas y campo de contenidos (datos). Lo nuevo respecto al modelo deDexter es el campo de presentación, en el cual una se dedica a aspectos relacionados conel tiempo.

En cuanto a los componentes compuestos, se añaden varios elementos nuevos, respectoa Dexter. La diferencia principal es que ahora es usado para especificar la estructura deuna presentación y no sólo para unir componentes para la navegación.

Los atributos temporales de la presentación se obtienen de los componentes atómicos,mientras que en la especificación de la presentación (componentes compuestos)aparecen los arcos de sincronización, unas nuevas estructuras que nos dan unainformación sobre el orden relativo de los componentes atómicos en la presentación, yque veremos posteriormente con más detalle.

Tanto las anclas como el campo de atributos son similares a Dexter, con una pequeñadiferencia: en los componentes compuestos se añade un tipo de composición a la listade parejas <id componente, id ancla>. Éste puede tomar dos valores:

• paralelo: se visualizan todos a la vez

• opción (choice): sólo se visualiza, como máximo, uno de los hijos

2.2.3. Relaciones temporales

Como ya hemos dicho, el principal mecanismo para representar las relacionestemporales entre entidades son las componentes compuestas.

Hay dos tipos de sincronización entre componentes, una calificada como de granogrueso y otra de grano fino. La primera es aquella que consiste en restricciones definidasentre los hijos de una componente compuesta (que recordemos que pueden sercomponentes atómicas o compuestas), como por ejemplo el instante relativo decomienzo de cada hijo dentro de la componente compuesta. Esta información estáexplícita en la definición de cada hijo. Por contra la sincronización de grano gruesoconsiste en relaciones entre dos hijos (que pueden o no estar al mismo nivel, es decirque pueden o no ser hermanos) explicitados mediante lo que llamamos un arco desincronización. Un arco de sincronización no se usa como un enlace navegacional, sinoque constituye un mecanismo flexible para establecer relaciones temporales dentro delsistema hipermedia.

El modo de especificar las relaciones temporales en AHM tiene la ventaja de que hayuna clara separación entre la colección de componentes que se muestran juntas, el orden



relativo en el lo hacen y las relaciones temporales específicas que existen durante unapresentación.

2.2.4. Otras contribuciones del modelo

2.2.4.1. Contexto de los enlaces

Los componentes compuestos no nos dan ninguna información de cómo se comportacada componente al navegar a través de un enlace.

Para ello definimos el concepto de contexto de enlace, que será un nuevo componente(típicamente compuesto) que contiene la colección de los componentes afectados por unenlace. El mecanismo de contexto permite definir unas opciones de visualizacióndiferentes para cada enlace. En particular, puede ser que parte de la informacióncontinúe visible, mientras que otra deja de estarlo. La ventaja de esto es que, por unlado, sólo una parte de la estructura del documento se ve afectada al seguir un enlace, ypor otro, se nos ofrece una gran flexibilidad.

2.2.4.2. Canales

Terminaremos este apartado con el concepto de canales. Éstos son salidas abstractasutilizadas para reproducir los contenidos de un componente. Asociado con cada canalhay unas características de la presentación. Éstas pueden ser dependientes de los tipos dedatos (media), como la fuente y estilo de un texto o el volumen de un sonido; perotambién pueden ser independientes, como por ejemplo los colores de background yforeground.

Un uso típico puede verse en una situación en que deseamos una aplicación hipermediaen dos idiomas, por ejemplo castellano y catalán. Imaginemos que tenemos un vídeoacompañados de un audio y un texto explicativos. Necesitaríamos un canal de vídeo (elmismo si estamos en catalán o castellano), y luego dos canales de audio y otros dos detexto. Así se consigue una independencia entre los datos y la presentación, así como ungran dinamismo en estas últimas.

2.2.5. Conclusiones

Como ya hemos explicado el principal interés del modelo de Amsterdam estriba en elintento de extender el modelo de Dexter para que contemple la complejidad de los tiposmultimedia, y muy en especial del problema del tiempo que éstos conllevan.

Una metodología relacional hipermedia. Estudio en casos prácticos III - El modelo HDM


Capítulo IIIEL MODELO HDM

HDM (Hypertext Design Model) fue creado por los profesores Franca Garzotto y PaoloPaolini del Politencnico di Milano y por Daniel Schwabe de la Pontificia UniversidadeCatólica do Río de Janeiro en 1991, en parte en el marco del proyecto de la ComunidadEuropea HYTEA. El objetivo es crear un modelo que sea de utilidad para realizar eldiseño de una aplicación de hipertexto (o hipermedia).

Al desarrollar una aplicación hipermedia se pueden identificar dos tipos principales detrabajos: los globales, tales como definir las clases de elementos de información yestructuras navegacionales de la aplicación; por otro lado, los locales, tales como llenarlos contenidos de los nodos. Esto es similar a lo que ocurre en la ingeniería del softwaretradicional al diseñar un sistema modular: por un lado están las tareas de diseñar laestructura y interconexiones entre módulos, y por el otro, escribir el código de losmódulos en particular. A partir de ahora utilizaremos la siguiente terminología:authoring-in-the-large, para referirnos a la especificación y diseño de los aspectosglobales, estructurales de la aplicación, y authoring-in-the-small, para referirnos aldesarrollo del contenido de los nodos.

En este capítulo, nos centraremos en el authoring-in-the-large, ya que como es evidente,éste presenta características comunes en diferentes aplicaciones, mientras que elauthoring-in-the-small es específico para cada área de la aplicación. De hecho, aunqueambas están siempre interrelacionadas, la segunda suele depender de las herramientasque se utilicen, mientras que la primera es independiente.

El presente capítulo está basado en los artículos [GAR93] y [GAR95].

3.1. Objetivos y motivaciones

Son varias las ventajas de hacer un diseño basado en un modelo. Vemos aquí unresumen de ellas:

• Mejora de la comunicación: el modelo proporciona un lenguaje que permitecomunicar al analista y al usuario. Asimismo, también mejora lacomunicación entre los distintos integrantes del equipo, a menudo formadosen campos muy diferentes y con un lenguaje muy diferente.

• Reusabilidad: el hecho de tener representada la estructura, permite reutilizarlos esqueletos de esa estructura o sub-estructuras a la hora de desarrollarnuevas aplicaciones.

• Evitar inconsistencias estructurales: como consecuencia se obtendrá unanavegación predictible y consistente.



• Permite evaluar aplicaciones ya desarrolladas en base a su estructura: es loque los autores denominan evaluación orientada al diseño.

• Base para crear herramientas CASE que ayuden en el desarrollo.



3.2. Primitivas

En esta metodología tiene una base de terminología ya utilizada en otras metodologías,pero a su vez añade otra conjunto nuevo de términos y conceptos.

La unidad básica del modelo es la entidad. Una entidad es la más pequeña parteautónoma de la información, es decir, que no necesita ninguna otra información paratener un sentido total. Las entidades se agrupan en tipos de entidades. Una entidad esuna jerarquía de componentes, los cuales están formados a su vez por unidades. Elconcepto de unidad es similar al de nodo, mientras que un componente es un conjuntode nodos que crean una unidad lógica.

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 muestrela vida del pintor forma una entidad. Veamos gráficamente la entidad del pintor Goya.El conjunto de las entidades pintor, que tienen todas la misma estructura, es lo quedefine el tipo de entidad.

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 deun componente.

• enlaces de aplicación, que conectan componentes y entidades de distintotipo. Por ejemplo imaginemos que tengamos un tipo de entidades que sea“Periodo histórico”; así, habrá una enlace entre la entidad “Goya” y la entidad“Siglos XVIII y XIX”.

Entidad pintorGoyaComponente

La Maja Desnuda

Unidades

Componente raíz(vida del pintor )

ComponenteLa Maja Vestida

enlace estructuralenlace de componente



Nótese que de estas primitivas, las hay que hacen referencia a la parte de in-the-large yotras a la parte in-the-small. En concreto, las entidades y enlaces estructurales son in-the-large, mientras que las unidades, componentes y enlaces de componentes son in-the-small.

Veamos con más detalle todas estas primitivas, así como otras:

3.2.1. Entidades y tipos de entidades

Una entidad es una estructura (relativamente grande) de información que representaalgún objeto del mundo real en el dominio de la aplicación. Por ejemplo, un pintor(Goya), una ciudad (Palma), un ave (golondrina), ...

Las entidades se agrupan lógicamente en lo que llamamos tipos de entidades, quecorresponden a las clases de objetos del mundo real. Siguiendo los ejemplos anteriores,los tipos de entidades serían “pintor” (que agrupa a todos los pintores), “ciudad”, “ave”.

Como es evidente, el concepto de entidad es diferente en HDM que en la terminologíarelacional. Por ejemplo, en HDM las entidades tienen complejas estructuras internas, ...

3.2.2. Componentes

Una entidad es una colección de componentes estructurados en forma de árbol(jerárquicamente). Un componente es una abstracción de un conjunto de unidades, queson los contenedores de la información. Un componente dentro de la jerarquía de laentidad, en general tiene un padre (excepto en el caso del componente raíz), varioshermanos, y un número de hijos (excepto en los componentes hoja -los últimos de lajerarquía-). Pero un componente sólo puede existir como parte de una entidad, y no tienesentido por sí mismo, es decir, no es autónomo. Por tal razón en el modelo HDM no sepermite que unas entidades sean componentes de otras entidades.

En cuanto a la jerarquía que estructura los componentes de una entidad, ésta puede sersegún muy diversos criterios semánticos. En particular, una de las más utilizadas es lade “todo-parte”.

3.2.3. Perspectivas

En HDM la noción de tener diferentes presentaciones del mismo contenido se representamediante el concepto de perspectiva. Por ejemplo, una aplicación multilingüe, la mismainformación se presenta de varias maneras diferentes (una en cada idioma). Pero esto,lógicamente, no altera la estructura jerárquica de una entidad.

Las perspectivas son sólo una construcción para organizar este tipo de información.HDM deja a la libertad del usuario cuándo y cómo debe utilizar perspectivas.



3.2.4. Unidades

Una unidad es un conjunto de partes atómicas de información que se muestranconjuntamente, como una unidad.

Una unidad corresponde a un componente asociado con una perspectiva específica. Unaunidad se caracteriza por un nombre (su identificador) y un cuerpo. Los cuerpos de lasunidades son el lugar donde queda almacenada la información.

Por ejemplo, en la entidad que describimos anteriormente (Goya), el componente “LaMaja Desnuda”, puede tener las unidades “Explicación del cuadro (en castellano)” y“Importancia en la obra del autor (en castellano)”, ambas asociadas a la perspectiva encastellano, y por otro lado las asociadas a la perspectiva en catalán “Explicación delcuadro (en catalán)” y “Importancia en la obra del autor (en catalán)”,

Vemos, por tanto, que el concepto de unidad es muy similar al concepto de hipertextotradicional de “nodo”.

Aunque los autores no lo recomiendan, diferentes unidades pueden compartir el mismocuerpo. Según los autores, esto conlleva una desorientación para el usuario, aunque porotra parte, fomentaría la reusabilidad.

3.2.4. Enlaces en general

Los enlaces en hipertexto tienen una doble función: por un lado representar lasrelaciones entre elementos del dominio (entidades, componentes o unidades), y por otro,una función de navegación (representar los patrones navegacionales). A menudo, estasdos funciones son consistentes entre sí, aunque no siempre: puede ocurrir que lasrelaciones de dominio no sean relevantes para la navegación, o que un enlacenavegacional interesante no se tenga ningún contenido semántico.

Por tanto, la definición de enlace debe reflejar ambas funciones. Para ello se identificantres tipos diferentes que estudiaremos a continuación. Éstos son:

• Enlaces de perspectiva o de componentes

• Enlaces estructurales

• Enlaces de aplicación

3.2.5. Enlaces de perspectiva o de componentes

Interconectan unidades dentro del mismo componente. Por ejemplo, un enlace de estetipo es el que conecta las unidades “Explicación del cuadro (en castellano)” y“Importancia en la obra del autor (en castellano)”, dentro del componente “La MajaDesnuda”, en la entidad “Goya”.



Nótese que al cruzar un enlace de este tipo, el contexto sigue siendo el mismo.

Los enlaces de presentación 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 algomás complejos que los de perspectiva, pero bastante simples. Hay varios tipos, comopor ejemplo: de un componente a su hermano, de un componente a su hijo o a su padre,...

3.2.7. Enlaces de aplicación y tipos de enlaces

Representan relaciones de dominio entre entidades o sus componentes. Estas relacionesson las elegidas por el autor como navegacional y semánticamente relevantes.

Los enlaces de aplicación se estructuran en tipos, llamados tipos de enlaces deaplicación, o más brevemente, tipos de enlaces. El tipo viene definido por un nombre,los tipos de entidades origen y destino, y por si es simétrico o no. Un tipo de enlace seríael que uniría el tipo de entidad “Pintor” con el tipo de entidad “Periodo histórico”, alque podríamos llamar “Periodo del pintor”.

Los enlaces de aplicación pueden ser de dos tipos diferentes:

• De esquema: pertenece a un determinado tipo de enlaces. Por ejemplo el quese citó anteriormente entre las entidades “Goya” y “Siglos XVIII y XIX”, yaque pertenece al tipo “Periodo del pintor”.

• Genéricos: no pertenece a ningún tipo de enlace. Son independientes de laestructura, y por tanto menos estandarizados. Un ejemplo podría ser un enlaceentre “Goya” y otro pintor en el que influyó posteriormente. Este enlace nosigue un patrón, sino que el autor del hipertexto lo incluye para este casoconcreto.

3.2.8. Esquema HDM

Una especificación de un hipertexto consta de una definición de esquema y un conjuntode definiciones de instancias. Un esquema especifica un conjunto de tipos de entidad ytipos de enlace. Las instancias se introducen en el sistema sólo si cumplen lasrestricciones establecidas en el esquema.

El concepto de esquema en hipertexto es novedoso, pero ya ha sido ampliamenteutilizado en el campo de las bases de datos.



Por último, en una aplicación también se puede distinguir entre dos conceptos:

• La estructura, que es la organización de los contenidos de la aplicación:entidades, componentes, enlaces, ...

• La dinámica (dynamics), que representa el comportamiento de la aplicación.



3.3. Evaluación de una aplicación usando HDM

Partiendo de este modelo, los profesores del Politecnico di Milano Franca Garzotto,Luca Mainetti y Paolo Paolini proponen HDM como un método ideal para evaluaraplicaciones. Es lo que ellos denominan evaluación orientada al diseño.

Las cuestiones que conviene analizar en una aplicación hipermedia son:

• Contenido: en función de los especialistas.

• Estructura: la organización de los contenidos.

• Presentación: teniendo en cuenta los aspectos pasivos (visualización), ya seantemporales o atemporales y los aspectos activos (interacción).

• Dinámica: cómo los usuarios interactúan 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 lainformación.

• Consistencia o regularidad.

• Predictibilidad.

• Auto-evidencia.

• Legibilidad.

• Reutilización.

Si la evaluación se basa en un modelo de la aplicación, ésta resulta mucho más fácil yprovechosa. El proceso consiste en realizar un modelo de la aplicación utilizando HDM,analizar los resultados buscando inconsistencias en la estructura y mecanismos denavegación.

En dicho artículo, los autores evalúan una aplicación de Microsoft, llamada “ArtGallery”, un catálogo hipermedia en CD-ROM de la National Gallery de Londres. Apesar de ser un producto comercial, los autores encontrarán no pocas inconsistencias.

Basan el análisis en estos puntos:

• Organización general: definición de las entidades y componentes.

• Navegación de enlaces de perspectiva.



• Navegación de enlaces estructurales.

• Navegación de enlaces de aplicación de esquema.

• Aplicación in-the-small, es decir el análisis de las unidades (“nodos”).

Nótese que los enlaces de aplicación genéricos, por su naturaleza son independientes dela estructura, no estandarizados; por tanto no tiene sentido su análisis, ya que el autor losdefine con completa libertad.



3.4. Conclusiones

HDM es más que un intento de modelar la estructura del hipertexto-hipermedia, unamodelización de las estructuras de navegación. Crear un modelo antes de desarrollar nosayudará a conseguir una navegación más consistente y rica. En HDM la estructura denavegación viene marcada por la estructura de datos.

Además HDM puede resultar útil también 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 siguiendolas normas de HDM es extremadamente complicado cuando el número de entidadesinvolucradas crece. En particular, era imposible representar la estructura de MINTourutilizando este modelo. Nosotros, por tanto, destacamos de esta propuesta laimportancia de modelizar antes de desarrollar y de la utilidad de un modelo a la hora deanalizar aplicaciones ya desarrolladas, si bien consideramos que HDM no es laherramienta de modelado más adecuada.

Una metodología relacional hipermedia. Estudio en casos prácticos IV - La metodología RMM


Capítulo IVLA METODOLOGÍA RMM

La metodología RMM (Relationship Management Methodology) ha sido ideada porIsakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios conestructuras regulares (es decir, con clases de objetos bien definidas, y con clarasrelaciones entre esas clases). Por ejemplo, catálogos, front-ends de bases de datostradicionales. Según sus autores, está orientada a problemas con datos volátiles, quecambian con mucha frecuencia, más que a entornos estáticos.

En este capítulo presentaremos en primer lugar la metodología original, basada en[ISA95], y en los sucesivos apartados, veremos tres opciones de mejora de la misma. Elprimero es el basado en los llamados slices mínimos e híbridos y m-slices, además deuna profundización en las etapas de la interfaz de usuario y construcción. En el segundoveremos nuestras propuestas de nuevos patrones de navegación como mejora al modelo.

4.1. La primera formulación de la metodología RMM

4.1.1. El modelo RMDM

La base de la metodología es el modelo de datos RMDM (Relationship ManagementData Model), que se genera a partir de un diagrama entidad-relación. Con él sedescribirá no sólo la información referente a las clases de objetos, sino también a lanavegación entre ellos.

Así, hay definidas unas primitivas para modelar los dominios (clases de objetos) y otraspara el acceso a tales objetos. De entre las primeras, la más típica es la entidad. Como enla teoría relacional una entidad está compuesta por varios atributos. Además, en RMDMse incorpora una nueva primitiva muy importante denominada slice, que defineconjuntos de atributos de una entidad que se agrupan de forma lógica (volveremos ahablar de ello).

Una entidad se representa mediante un recuadro y su nombre, mientras que un slice serepresenta mediante a una figura similar a una gota de agua. Lo vemos a continuación:



dirección

nombre

email

fax

CP

teléfono

...

Slice de la entidad Hotel

Hotel

Entidad Hotel

En cuanto a las primitivas de acceso, se definen tres tipos de acceso diferentes. Para verqué significa cada una veremos un ejemplo. Supongamos una entidad “Hotel”. Lasinstancias de esta entidad se pueden visitar según esos tres tipos de acceso:

• Índice condicional (Conditional Index) : en una pantalla aparecerá un índicealfabético de los nombres de los hoteles, y pulsando sobre uno, iremos a versu información. Para ver los demás 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, porejemplo, un mapa, donde al pulsar sobre una ciudad, se visitase suinformación.

Veamos cómo se representa:

Hotel

• Visita guiada condicional (Conditional Guided Tour) : de la pantalla inicial senos envía 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 losanteriores. Se permite volver a visitar al anterior hotel. En definitiva, es unaestructura de acceso secuencial.

Ésta es su representación gráfica:



Hotel

• Visita guiada indexada condicional (Conditional Indexed Guided Tour) : esuna solución híbrida, donde tenemos un índice para acceder puntualmente alos elementos de la entidad, pero también se nos permite la navegaciónsecuencial una vez seleccionado uno.

Y su representación gráfica es:

Hotel

Además, también se define una primitiva de grupo (Grouping) mediante la cual serepresenta un menú. De una primitiva grupo colgarán tantas opciones como queremosque haya en el menú.

La primitiva de grupo, o a la que a veces también denominaremos de menú, serepresenta mediante un triángulo invertido

del que colgarán todas las opciones del menú. Por ejemplo, veamos un menú quepermite acceder a la entidad hotel de las tres maneras diferentes que antes hemosestudiado:



Hotel HotelHotel

Para terminar con esta Veamos una tabla resumen de todas las primitivas que hemosvisto:

Primitivas de datos EntidadEntidad

Atributo atributo

Slice

Primitivas de acceso Índice

Visita guiada

Visita guiada indexada

Grupo

Enlace



4.1.2. Etapas de la metodología

4.1.2.1. Etapa 0

Como toda metodología debe comenzar con un estudio de factibilidad y un análisis delos requerimientos (tanto de la información como de la navegación). También debehacerse una selección del hardware y software que se necesitará.

Los autores no hacen más referencias respecto de esta fase inicial, por lo que esaplicable cualquier metodología típica de la ingeniería del software tradicional.

4.1.2.2. Etapa 1: Diseño Entidad-Relación

En esta etapa se confecciona un diagrama entidad-relación típico, desglosando lasrelaciones N:M en dos relaciones 1:N, como muestra el ejemplo:

BA

BA

Como vemos las relaciones se representan con el símbolo:

El objetivo de esta fase es explicitar todos los enlaces entre objetos. Más tarde, lasrelaciones darán lugar a la navegación. Así, una relación especificará un camino en lanavegación.

Veamos un ejemplo que después continuaremos a lo largo de las siguientes fases. Setrata de un sistema de los hoteles de una región. Tenemos cinco entidades, que son:“Hotel”, “Ciudad”, “Servicio”, “Habitación” y “Categoría”. En cuanto a las relaciones,una ciudad tiene varios hoteles, mientras que un hotel sólo pertenece a una ciudad(relación 1:N), un hotel tiene una categoría, mientras que hay muchos hoteles de unadeterminada categoría (también relación 1:N). Lo mismo ocurre entre hotel y sushabitaciones (1:N) y por último tenemos una relación N:M entre hotel y servicio, ya queun hotel tiene varios servicios y un servicio concreto se da en varios hoteles. Estarelación N:M, como explicamos antes la desglosaremos en dos relaciones 1:N.



Ciudad

Hotel HabitaciónCategoría

Servicio

Dentro de esta fase habría también que especificar los atributos de cada entidad.

4.1.2.3. Etapa 2: Diseño de slices

Esta etapa consiste en dividir una entidad en fragmentos significativos y organizarlos enla red de navegación. Por ejemplo, toda la información de un hotel la podríamos colocaren una ventana con scroll o bien en varias diferentes. Esta división se hace según lasemántica de los atributos. Por ejemplo podríamos tener en un slice los datos generalesdel hotel y en otro un vídeo que nos muestre tomas del hotel.

Cada slice agrupará uno o más atributos de una entidad, de tipos muy diferentes. Cadaentidad tendrá su head, o slice principal, que se marca con un asterisco y que es slice alque, por defecto, se accede a través de los mecanismos de navegación.

Entre los diferentes slices están los llamados enlaces estructurales, que nada tienen quever con las relaciones, ya que al atravesar un enlace estructural, no se produce ningúncambio de contexto.

Veamos como podríamos dividir la entidad hotel en slices. Para hacerlo no seguiremosla notación que los autores recomiendan ya que es muy engorrosa. Nosotros, no sólo eneste ejemplo sino en todos los casos de estudio, utilizaremos una tabla donde seespecifican los slices de cada entidad y los atributos que corresponden a cada uno deellos.

General * (head) NombreDirecciónTeléfonoFaxMailURLNúmero de plantasAño construcción



Número de habitacionesLocalización Cómo llegar

Distancia a la playaDistancia al aeropuertoDistancia a la capitalDistancia a parada bus

Vídeo Vídeo

Una vez determinados los slices hay que establecer los enlaces estructurales:

General

Localización Vídeo

4.1.2.4. Etapa 3: Diseño navegacional

Como que cada relación del diagrama entidad-relación da lugar a un enlace denavegación, en esta fase sustituimos las relaciones por primitivas de acceso RMDM.

En general, preferiremos una visita guiada a un índice cuando el número de instanciassea pequeño (menor de 10) y no exista un campo índice que pueda ayudar a los usuarios.

Por contra, si el número es grande, usaremos índices. Las visitas guiadas indexadas sonun híbrido, usado frecuentemente cuando hay un índice y se desea una navegación entrelas instancias.

Además en esta fase hay que elegir a qué slice se accede a través de una primitiva deacceso. 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 jerarquía de menús, utilizando la primitiva degrupo o menú. Como regla general, evitar grandes profundidades en la jerarquía, ya quedesorientan al usuario.

El resultado final de esta etapa es el diagrama RMDM.

Sigamos con nuestro ejemplo. Lo primero es decidir por qué primitiva de accesosustituimos cada una de las relaciones que nos han resultado en el diagrama entidad-



relación de la primera etapa. En este caso hemos elegido un índice en la relación hotel-servicio y categoría-hotel, una visita guiada en la relación hotel-habitación y una visitaguiada indexada en la relación ciudad-hotel.

Ciudad

Hotel HabitaciónCategoría

Servicio

Aunque siguiendo al pie de la letra se debería especificar un enlace “de vuelta”, si fueranecesario, entre las entidades que tienen una primitiva de acceso -es decir que de unhotel podamos ir a su categoría directamente- nosotros consideramos que siempre esteenlace debe estar presente y por tanto no lo representamos en el diagrama, porconsiderarlo redundante. Así, al tener una estructura de acceso de categoría a sushoteles, implícitamente queda representado un enlace entre hotel y su categoría.

Para terminar con esta fase debemos introducir la jerarquía de menús en el diagrama,utilizando la primitiva de grupo. En nuestro caso, consideramos que simplementetenemos un menú principal donde podemos acceder a las ciudades o bien a lascategorías, para en ambos casos después poder llegar a ver la información de los hoteles.En el primer caso, desde el menú se accede a un índice de las categorías y en el segundoa una visita guiada indexada de las ciudades. Se representa así:



Ciudad

Hotel Habitación

Categoría

Servicio

Y éste es el diagrama RMDM que nos especifica la navegación de nuestro sistema.Vemos como a lo largo de estas tres fases hemos determinado las pantallas quenecesitaremos (slices), y que luego el diseñador gráfico deberá diseñar y hemosdeterminado todos los enlaces navegacionales de nuestro sistema, que con esto quedaperfectamente modelado.

4.1.2.5. Etapas 4 a 7: Interfaz de usuario y construcción

Estas etapas se realizan a partir del diagrama RMDM. Sólo se citan brevemente, ya queel interés de la metodología, así como el nuestro en particular, se centra en las tresprimeras etapas que nos conducen a obtener en modelo RMDM. Las siguientes ya noson propias del análisis, sino del diseño gráfico y la programación.

Etapa 4: Diseño de protocolos de conversión

En esta etapa se escriben unos protocolos por los cuales se transforma cadaelemento del RMDM en un objeto en la plataforma elegida.

Etapa 5: Diseño de la interfaz de usuario



Diseño gráfico de todas las pantallas correspondientes a cada uno de los slicesque hemos obtenido en la etapa 2.

Etapa 6: Diseño del comportamiento en tiempo de ejecución

Se decide qué mecanismos se utilizarán para guardar la historia, hacerbacktrackings, permitir enlaces transversales,...

Etapa 7: Construcción y tests

Construcción de la aplicación y pruebas, testeando cuidadosamente todos lospaths de la navegación.

4.1.2.6. Relación con las etapas tradicionales de la Ingeniería del Software

La división en siete fases de la metodología nos lleva a planternos cuál es laequivalencia con las etapas tradicionales de una metodología y que comentamos en elcapítulo de introducción. Recordemos que éstas eran análisis, diseño e implementacióny pruebas.

Claramente corresponde al análisis la primera etapa de análisis entidad-relación; dehecho ya vimos que el modelo entidad-relación es la herramienta típica del análisis. Lasegunda fase, la podemos considerar a caballo entre análisis y diseño, ya que cuenta conuna parte de análisis de datos, pero también ya tiene en cuenta las pantallas de queconstará la interfaz de usuario. En cuanto a la tercera etapa, ya es claramente diseño.Respecto de las últimas fases, las de interfaz de usuario e construcción, es bastante claroque las etapas cuarta a sexta perteneces también al diseño, mientras que la última esobvio que se corresponde al cien por cien con lo que denominamos implementación ypruebas.

4.1.4. Conclusiones y discusión

Esta metodología permite explicitar la navegación al hacer el análisis, con lo cual nospermitirá, en teoría, obtener una navegación más estructurada y, por tanto, más regular eintuitiva. Lo hace de una forma sencilla, simplemente añadiendo unas primitivas a loque es un modelo entidad-relación tradicional. Es de gran interés, bajo mi punto devista, el concepto de slice, que permite agrupar datos de una entidad en diferentespantallas, y es que, al estar hablando de diferentes medios, la información de unaentidad puede ser muy variada. Para dar una idea más al respecto, podría ser interesanteque un vídeo sobre un hotel, mostrando sus interiores, aparezca en una pantalla diferentede otro que muestre su piscina. También es interesante la primitiva de grupo, quepermite explicitar la jerarquía de menús.



Según nuestro punto de vista RMM es de gran interés, ya que es el primer caso en el quese crea una metodología completa, con una definición de fases, y no únicamente unmodelo de datos. Además está basado en un modelo de datos relacional, lo cual se ajustaperfectamente no sólo a nuestros casos de estudio si no a la gran mayoría de lasaplicaciones existentes.

Pero, a mi entender, los mecanismos de acceso a la información son excesivamentesimples. Pueden ser suficientes para un problema con pocas entidades, como el que losautores incluyen en su artículo, donde sólo tienen siete entidades, o el que nosotroshemos utilizado como ejemplo, que contiene cinco.

Un importante problema es que no se permite hacer una consulta a partir de dosentidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles estárelacionada con ciudad, N a 1, y ésta a su vez con región, también N a 1, no hay formade permitir ver todos los hoteles de una región, sino es yendo de ciudad en ciudad ydespués, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que seríanecesario poder establecer un enlace navegacional no sólo entre entidades relacionadasdirectamente, sino también con las que estén relacionadas con ellas, y así sucesivamente(evidentemente siempre que sean relaciones también N a 1).

Aún así, la navegación tendría más limitaciones. Y es que ya hemos visto que lasconsultas han de ser tan simples como que dado una ciudad qué hoteles tiene, quecampings, que puertos y aeropuertos, etc. Pero, por ejemplo, sería imposible explicitaruna consulta del tipo qué hoteles de una cierta categoría hay en una ciudad determinada.

Otro gran defecto es que en la explicación de la primera etapa, que es el correspondientea la construcción del diagrama Entidad-Relación, se nos dice que las relaciones N:M sedescompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologíascomo, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad queresulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artículoy que trata de un sistema de cursos, en los que se reflejan los profesores, suspublicaciones, ... En el artículo, los autores rompen la relación N:M entre profesores ycursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero seolvidan de los datos que deben guardarse de la relación original, como por ejemplocuántas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, conuna entidad en medio, no habría forma de saber los cursos que imparte cierto profesor, oqué profesores imparten cierto curso ya que no estarían directamente relacionados.

Otro punto discutible es que los autores citan que esta metodología es indicada sólo paraproblemas con datos que varíen muy frecuentemente. Pero a pesar de eso no se reflejade ninguna forma esa cómo se puede realizar tal modificación de los datos. La realidades que no se refleja ningún tipo de proceso en esta metodología, que se ciñeestrictamente a la parte de datos. Se debería en próximos trabajos la conveniencia deincluir la posibilidad de definir procesos sencillos tales como, por ejemplo, hacer unareserva de una plaza de hotel. Mi idea es que la solución pasaría por crear una nuevaetapa que fuera de definición de procesos, en la que se definieran mediante las técnicastradicionales de DFDs (Diagramas de Flujo de Datos) y quizás también pseudo-código odiagramas de procesos. Ya que los procesos visualmente no son más que pantallas, unavez definidos éstos, se podría crear una nueva primitiva que representara un proceso,



con el fin de incluirse todos estos procesos en el modelo RMDM, preferentemente en lanavegación estructural (interna a la entidad, junto a los slices) para reflejar cómo sellega a ellos.

En todo caso, y ya que nuestros casos de estudio sólo reflejan consultas a lainformación, y no procesos de actualización no se profundizará en esta reflexión en elmarco de este proyecto final de carrera.

En el siguiente apartado veremos un estudio más detallado de dos intentos de mejora dela metodología, dirigidos entre otros por uno de sus creadores, Tomás Isakowitz,mientras que en el tercer apartado del capítulo veremos una propuesta propia de mejoraañadiendo una serie de nuevas estructuras navegacionales que nos pueden serespecialmente útiles.



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 metodología. En primer lugar expondremos las quetienen como objetivo mejorar la estructura de datos y navegación. Posteriormente setratará sobre un estudio en mayor profundidad de las etapas de interfaz de usuario eimplementación, que tan ligeramente fueron tratadas en la primera formulación deRMM.

4.2.1. Estructura de datos y navegación

Aquí veremos dos intentos de mejora de las primeras etapas de la metodología. Enambos casos, se intenta suplir las carencias de RMM añadiendo nuevos tipos de slices,con el fin de poder representar problemas más complejos, que con la formulaciónoriginal de RMM no era posible.

4.2.1.1. Slice mínimo y slice híbrido

En [BAL96], se presenta la aplicación de la metodología RMM a un caso práctico. Setrata de una pequeña aplicación para la web, creada para la ACM, llamada LINKBase,con la información hipertexto de eventos tales como conferencias, publicaciones,escritores, organizaciones ... La aplicación se desarrolló para la web utilizando CGIs(Common Gateway Interface), para acceder a la base de datos. Una CGI es un programaque escribimos para que a partir de los datos que se recuperan de la base de datos, secree una página HTML dinámicamente, que es la que el usuario visualiza.

La conclusión más importante de su trabajo fue la necesidad de extender el modeloRMDM para hacerlo realmente utilizable. Su propuesta es la de añadir dos tipos nuevosde slices:

El slice mínimo (minimal slice), que representa el conjunto de atributos de una entidadque permite que el usuario pueda identificar claramente las diferentes instancias de talentidad. Este slice mínimo se utilizará como ancla a instancias concretas de una entidad.Por ejemplo si accedemos a una entidad mediante una primitiva índice, lo que deseamosno es que el usuario vea la lista de los identificadores de los diferentes registros, ya quemuy probablemente esa información le sea del todo inútil. Se utilizará el slice mínimopara tal fin.

Los slices híbridos (hybrid slices) que permiten combinar atributos de diferentesentidades y estructuras de acceso. En la definición original de RMM, los slices estabanformados únicamente por atributos de una misma entidad. Con este añadido se permiteque en una pantalla aparezcan informaciones de más de una entidad. Por ejemplo siaccedemos de una autor a sus publicaciones, pudiera ser que estuviéramos interesadosen mostrar en la misma pantalla la información de la editorial de cada publicación (quese encuentra en otra entidad).



Con estos tipos de slices se consiguen unas estructuras más dinámicas tanto denavegación como de organización de la pantalla.

4.2.1.2. Los m-slices

En [ISA96] se vuelven a analizar las carencias de la metodología y a proponer nuevasmejoras.

Según los autores, tres son las principales limitaciones de la metodología:

1. La imposibilidad de especificar qué información se debe mostrar como ancla,es decir qué texto o imagen aparece como hiperenlace, por ejemplo en unapágina web.

2. RMM sólo 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 además de atributos,

estructuras de acceso. Es decir, para llegar a una estructura de acceso (índice ovisita guiada) uno debe de atravesar un enlace.

Lo que los autores proponen en el presente artículo es un nuevo tipo de slice, al quedenominan m-slice. Según ellos la m viene de las muñecas matrjeska, las típicasmuñecas 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, además de otrosslices (m-slices posiblemente) formadas con atributos de otras entidades, unido todo ellopor primitivas de acceso.

Recordamos en la siguiente figura cómo según la metodología original se definen losslices. Nota: Nosotros no hemos empleado esta notación en nuestros casos de estudiopor ser muy engorrosa.

dirección

nombr

email

fax

CP

teléfono

...

Slice HOTEL



La estructura de los nuevos tipos de slices es la siguiente:

Hotel

Habit.

Atributos la entidad hotel

Atributos la entidad habitación

4.2.1.3. Conclusiones

La introducción de los slices mínimos e híbridos, se puede considerar como muyprovechosa, y será ampliamente utilizada en los casos de estudio, más en concreto en losdos últimos.

En cambio, los m-slices son de un provecho más dudoso. Estudiando las treslimitaciones que los autores apuntan, se puede cuestionar que la extensión cubra losobjetivos que pretende; la contrario, parece que introduce más problemas que resuelve,como veremos a continuación:

1. En cuanto a la imposibilidad de especificar qué información se debe mostrarcomo ancla, es cierta en la definición inicial de RMM, pero se puede utilizarel slice mínimo, cuya definición vimos en el anterior artículo, para tal efecto.Así, tenemos que en cada entidad habrá que definir el slice mínimo y éste, alser la menor parte de información que permite identificar al usuario a talobjeto, será el que se utilice como ancla.

2. Referente a la imposibilidad de agrupar atributos de varias entidades en un

slice, ya vimos también en el artículo anterior que la cuestión quedó resueltacon la definición de los slices híbridos, que veremos en el siguiente apartadocomo serán de gran utilidad.

3. Y llegamos al punto clave. Es cierto que en RMM no se permite englobar en

un slice, además de los atributos, estructuras de acceso. Pero el hacerlo es ungran error. La segunda fase de la metodología tiene por objeto el identificar



las partes de cada entidad que aparecen diferenciadas entre sí. En la terceraetapa, y a partir del diagrama entidad-relación de la primera, obtenemos lasestructuras de acceso entre las entidades. Y lo que no olvidemos es que elmodelo se fundamenta en que la estructura de la navegación se basará en laestructura de los datos. Lo que aquí se propone sería hacer la estructura de lanavegación no en base a las entidades sino a los slices, es decir a conjuntos deatributos.

La idea de los autores suponemos que es el intentar representar que si estamosen una pantalla correspondiente a la entidad “Hotel” y deseamos ver lainformación de, por ejemplo sus habitaciones, esto se pueda hacer dentro dela misma pantalla, definiendo un m-slice que contenga los atributoscorrespondientes de ambas entidades, así como la estructura de acceso, porejemplo un índice. Pero este caso es propio de la presentación, es decir de lasetapa de diseño de la interfaz (etapa 5) y no de la estructura de la aplicación.Si el diseñador, a partir del modelo RMDM ve que hay una navegación entreun hotel y sus habitaciones, puede ahí definir que desea que el slicecorrespondiente de la entidad hotel y el correspondiente de la entidadhabitación aparezcan en la misma pantalla. Lo que no tiene sentido es haceresto en la etapa de análisis.

Así pues, los m-slices, por lo menos en su formulación actual, no serán pues utilizadosen los casos de estudio que realizamos a continuación.

4.2.2. Las etapas de interfaz de usuario

Asimismo en [BAL96] se profundiza en las fases de la metodología posteriores a la dediseño navegacional. Son las que se denominan de interfaz de usuario y construcción ysobre las cuales en la descripción original de la metodología sólo se daba una muy breveguía.

Mientras que las tres primeras etapas cubren el diseño lógico de una aplicación, estas secorresponden con el diseño físico.

4.2.2.1. Etapa 4: Diseño de protocolos de conversión

Recordemos que el objetivo de esta fase era el de transformar cada elemento del modeloRMDM en un objeto en la plataforma elegida.

Lo que se debe hacer es producir una serie de reglas, ya sea mediante un programaautomático de conversión o como una serie de instrucciones a los programadores, quepermitan 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, lasentidades se convierten en tablas de la base de datos y los atributos en columnas de esastablas. En cuanto a las estructuras de acceso, los índices se convierten en resultados deconsultas a la base de datos (son variables según el contenido de la misma).



4.2.2.2. Etapa 5: Diseño de la interfaz de usuario

Esta etapa hace referencia al diseño de cada una de las pantallas de la aplicación.Siguiendo la metodología, tendremos una pantalla para cada uno de los objetos delmodelo RMDM. En concreto hay cuatro aspectos importantes sobre los que se centra:

• la información de los slices encontrados en la segunda fase de la metodología

• las estructuras de acceso que identificamos en la tercera fase

• herramientas de navegación, como backtracking y similares

• apariencia de los anclas, cómo han de aparecer los índices y dónde deben situarselas citadas herramientas de navegación

Generalmente esta etapa se presta al prototipado, ya sea sobre papel (lo que los autoresdenominan prototipos low-fidelity) o por ordenador (prototipos high-fidelity).

Recuérdese que LINKBase, la aplicación que trata como ejemplo en este artículo, estábasada en páginas web. Si bien la aplicación final, como ya explicamos recupera losdatos de una base de datos, para esta fase es ideal hacer el diseño de todas las páginasHTML. Así, se crearán todas las páginas correspondientes a cada slice de cada entidad ycada índice, en HTML, con datos estáticos. Esto nos será de gran ayuda para elprototipado y por tanto para que el cliente pueda ver cuál será el aspecto de laaplicación.

Como ya citamos en los cuatro puntos a tener en cuenta, un aspecto muy importante quetambién hay que decidir es la representación de los anclas de los enlaces. Puede ser unabuena solución el identificar cada una de las entidades mediante un icono. Así, siestamos en la pantalla correspondiente a un escritor, tendremos un icono que representela entidad publicación y que al pulsar en él nos envíe al correspondiente índice depublicaciones de dicho escritor (o a la primera pantalla de la correspondiente visitaguiada si éste fuera el método de acceso). No obstante en la aplicación del LINKBaselos autores decidieron no utilizar elementos iconográficos sino sólo referencias textualespara 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: Diseño del comportamiento en tiempo de ejecución

En esta etapa hay que diseñar los algoritmos para los programas que generarán yrecuperarán la información de nuestra aplicación, así como el control de la historia denavegación (backtracking), y otros mecanismos.



En el caso de LINKBase, en esta fase hay que especificar el algoritmo para cada una delas CGIs de la aplicación (tanto para acceder a la base de datos como para el control delos demás mecanismos), mientras que será en la fase siguiente en la que se programe laCGI en sí.

4.2.2.4. Etapa 7: Construcción y tests

En esta fase se construye definitivamente la aplicación, en base a la informacióngenerada en todas las etapas anteriores. Se construye la base de datos física a partir delmodelo entidad-relación de la etapa 1 y de los protocolos de conversión de la fase 4. Ytambién se programan todos los algoritmos diseñados en la etapa anterior. Como puedeapreciarse las dos últimas etapas están muy ligadas, y nosotros consideramos queperfectamente se podrían haber considerado como una única.

Para acabar hay que testear la aplicación, lo que conlleva comprobar todos los enlacesposibles.

4.2.2.5. Conclusiones

Se han tratado las fases de la metodología sobre las que apenas se había hablado en laprimera formulación de RMM. El aspecto más destacado de este nuevo estudio, es bajonuestro punto de vista la etapa del diseño de la interfaz de usuario, donde se comentanlos aspectos más importantes que se deben considerar durante esta fase.

Visto esto, consideramos que hay una organización de la pantalla que es especialmentecoherente con la estructura, y que, además de ser clara, puede resultar muy útil en todotipo de aplicaciones hipermedia. Posiblemente los autores no la tuvieron en cuenta,quizás porque los navegadores de aquel entonces aún no tenían soporte para ello. Setrata del uso de marcos (frames) de HTML (aunque también se pueden utilizar tablascon el mismo objetivo). Así, podríamos tener un marco principal la información delobjeto seleccionado. Y además tres marcos más, con otros colores para diferenciarlos, ydispuestos como el diseñador lo estime oportuno que contendrían los elementosnavegacionales, 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 navegación enmuchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo deplataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de lapantalla en varias áreas.



4.3. Mejoras en estructuras navegacionales para RMM

Como hemos visto en los apartados anteriores, RMM resulta un muy interesante intentode establecer una metodología para el desarrollo de aplicaciones multimedia, y que estáespecialmente indicada para aplicaciones basadas en bases de datos relacionales. Noobstante, presenta una serie de carencias en las formas de navegación, a pesar de losintentos de mejoras que hemos analizado en los dos apartados anteriores, basados en laintroducción de nuevos tipos de slices. El hecho es que en el modelo RMDM sólo sepermite navegar entre entidades que estén directamente relacionadas.

Para mejorar la metodología es fundamental encontrar nuevos patrones, nuevas formasde navegar, nuevas primitivas de acceso que nos ayuden a identificar enlacesnavegacionales de una forma estructurada y regular.

A continuación se exponen tres casos concretos que darán origen a tres nuevas formasde acceso a la información y que harán de RMDM un modelo más útil, y que daráorigen a una navegación más rica.

4.3.1. Caso A: accesos jerárquicos

Este primer caso es el que se da cuando tenemos varias relaciones 1:N encadenadas. Laidea es permitir acceder jerárquicamente, es decir de una cualquier punto de la cadenahacia abajo, con cualquiera de las primitivas de acceso.

Veamos un ejemplo que muestre la necesidad de este caso:

Ciudad

Provincia

Región

Nación

Camping

Aquí sólo podemos navegar por los campings de una ciudad. Pero si cuando estamosvisualizando la información de una provincia, región o nación quisiéramos acceder a suscampings, sólo podríamos hacerlo consultando los campings de cada ciudad una a una,pero sería imposible ver una lista con todos los de la provincia, región o nación.



Por tanto, es imprescindible permitir acceder a los campings que hay en una provincia,región o nación, directamente. En general, siempre que tengamos un encadenamiento derelaciones 1:N, se debe permitir bajar a través de la cadena.

Siguiendo con el mismo ejemplo, también es interesante poder acceder desde unanación a las ciudades sin pasar por las regiones o provincias. Téngase en cuenta que amenudo se conoce la ciudad pero no a qué provincia pertenece. Además, el poderacceder directamente es de una importancia mayor en una aplicación sobre Internet, yaque todo lo que sea reducir el tiempo de conexión es reducir el coste para el usuario.

La solución a este caso está en crear una nuevo tipo de acceso que permita inferir lasrelaciones jerárquicas. Lo vemos en el siguiente diagrama, donde las líneas que aparecendiscontinuas indican que hay el enlace navegacional no parte directamente de unarelación, sino que de una inferencia.

Región

Nación

Camping

Provincia

Ciudad

El siguiente ejemplo demuestra que esto no es sólo aplicable dentro de la aplicaciónMINTour, sino que es un patrón general.



Profesor

Asignatura

Carrera

Se observa aquí como también puede resultar interesante acceder a los profesores quedan clases en una cierta carrera, sin necesidad de ir asignatura a asignatura. Veamos eldiagrama resultante:

Asignatura

Carrera

Profesor

4.3.2. Caso B: acceos en relaciones N:M

Un fallo que se puede encontrar en la especificación de la etapa S1, diseño del diagramaentidad-relación, es el obligar a separar las relaciones N:M, directamente en dosrelaciones 1:N.



AsignaturaProfesor

AsignaturaProfesor

En otras metodologías como, por ejemplo, SSADM, ya se hace algo similar, pero lo queno se puede hacer es obviar la entidad que resulta en medio. En el artículo, los autoresrompen la relación N:M entre profesores y cursos, creando dos relaciones nuevas, 1:Nde profesores a cursos y viceversa. Pero se olvidan de los datos que deben guardarse dela relación original, como por ejemplo podría ser cuántas horas imparte el profesor deesa asignatura. Y no lo hacen porque entonces, con una entidad en medio, aplicandoRMM a raja tabla, no habría forma de saber los cursos que imparte cierto profesor, oqué profesores imparten cierto curso ya que no estarían directamente relacionados.

Veamos dos ejemplos más, pero ya teniendo en cuenta que es necesaria una entidadintermedia en la relación:

Tipo decamarote

Barco/Camarote

Barco

Este ejemplo está extraído de MINTour. La entidad “barco/camarote” es la resultante dela relación N:M entre “barco” y “tipo de camarote”. Esta entidad es necesaria ya que hayque guardar en ella los datos de la relación, como por ejemplo, el precio.

Pero cuando estamos visualizando la información de un barco, lo que queremos esacceder directamente a la información de los tipos de camarote que dicho barco tiene,con el fin de elegir en cuál viajaremos. Pero no queremos quedarnos en sólo en laentidad “barco/camarote”, donde sólo tenemos los códigos de barco y tipo de camarote yel precio.

En general, en toda relación N:M, aunque haya una entidad en medio, debe permitirse elacceso de un extremo a otro de la relación, aunque mostrando de alguna manera losdatos de la entidad intermedia.



Para reflejarlo, crearemos una nueva primitiva de acceso que permita acceder de unaentidad 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 primitivade acceso seleccionada con la entidad intermedia.

Lo vemos en la figura:

Barco/CamaroteTipo de

camaroteBarco

Barco/Camarote

La nueva primitiva de acceso indica que realmente sí se accede mediante un índice deun extremo al otro de la relación N:M, pero que se tiene en cuenta la entidadBarco/Camarote en ese acceso. La manera en que es tenida en cuenta esa entidad es enque no se accede al slice head, si no que se hace a un slice híbrido (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, también es muy claro:

AsignaturaAlumno

Alumno/Asignatura

Aquí tenemos un caso como el anterior, donde en la entidad “alumno/asignatura” sedeben guardar cosas como “número de convocatoria”, “nota final”, “fecha dematriculación”, etc. Así, hay que, como antes, permitir el acceso de extremo a extremo.

El resultado es el siguiente diagrama:



Alumno/Asignatura

Alumno/Asignatura

AsignaturaAlumno

Pero hay que notar que lo normal es que la entidad “alumno/asignatura” tome el nombrede “matrícula”. Esto hace que, a la vista de un diagrama entidad relación no siempre seafácil identificar las entidades provenientes de relaciones N:M, ya que si bien el primernombre lo indicaba con claridad, el segundo no.

Por tanto, lo que hay que hacer es buscar patrones de la forma:

CA B

y decidir después si es necesaria la navegación directa entre las entidades A y B; muchasveces lo será, aunque también muchas no.

4.3.3. Caso C: accesos múltiples

Este tercer caso es ciertamente más complejo, tanto en la identificación del patrón,como en la introducción en la metodología, y se presta a una profunda discusión.

Hay relaciones que implican una pertenencia de una entidad a otra. Por ejemplo:

Ciudad

Provincia

Hotel Categoría

Aquí vemos dos relaciones del tipo “parte de”, es decir, que una ciudad forma parte deuna provincia, y que un hotel forma parte de una ciudad.



Vemos que la relación entre “categoría” y “hotel”, en general, no tiene sentido que seanavegable, pues suele ser poco útil acceder a todos los hoteles de Europa de unadeterminada categoría. Pero sí lo sería si no se cogen todos los hoteles de Europa sinosólo un subconjunto de ellos, como por ejemplo los que pertenecen a una ciudad oprovincia.

Esto, que a nivel de entidades no parece complejo (lo más difícil será identificar lasrelaciones de tipo “parte de”), parece serlo más a la hora de implementar la navegación.En el ejemplo, estaremos visualizando la información de una categoría, y para acceder alos hoteles tenemos que seleccionar una ciudad o provincia. Una vez seleccionada ésta,se mostrarán los hoteles de esa ciudad y esa categoría.

Para ello hay que crear una nuevo grupo de primitivas de acceso que permitirán unacceso múltiple, ya sea mediante un índice, una visita guiada o una visita guiadaindexada.

Las nuevas primitivas son:

Índice múltiple

Visita guiada indexada múltiple

Visita guiada múltiple

Y la forma en que se representa un enlace múltiple:

B

C

A



donde navegamos utilizando un índice desde la entidad A hasta la entidad B peroseleccionando un elemento de la entidad C.

Veamos cómo se aplica esto a nuestro ejemplo del hotel, la categoría y la ciudad:

Hotel

Provincia

Ciudad Categoría

Hemos utilizado la primitiva índice múltiple que permite navegar, en este caso concreto,desde categoría hasta hotel, pero tomando una ciudad, es decir, que al elegir unacategoría se podrá seleccionar una ciudad y ver los hoteles de esa categoría en esaciudad.

Evidentemente a este diagrama también le podríamos aplicar lo que vimos en el primercaso, y permitir ver no sólo los hoteles de cierta categoría de una ciudad, sino tambiénlos de una provincia. El resultado sería el siguiente diagrama:

Hotel

Provincia

Ciudad Categoría

No obstante, un análisis tras la aplicación a casos prácticos nos revela que la estructurade relaciones que dará lugar a una primitiva de acceso múltiple, es similar a la de unarelación N:M. Por ejemplo, en el caso anterior, uno podría haber supuesto que la entidadhotel era el resultado de la relación N:M entre Ciudad y Categoría. No estaría exento derazón y de hecho, la entidad hotel necesita almacenar el código de la categoría y elcódigo de la ciudad. Sin embargo, esta entidad tiene una gran importancia semántica por



sí misma, y en el proyecto MINTour es una de las más importantes, sin duda mucho másque categoría.

Además el estudio en casos prácticos nos deparó que en ciertas ocasiones también soninteresantes estas primitivas de acceso múltiples en situaciones en las que la estructuratodo-parte no se da. Veamos dos ejemplos:

El primero está extraído del Atles de les Illes Balears. En él, tenemos que cada parte dela información fundamental del atlas es el cruce entre un tema y el área geográfica. Porejemplo, un punto de información será Carreteras Secundarias en Menorca, otroCarreteras Secundarias en Mallorca, ... En este caso, no está claro de que lo quetengamos sea una estructura todo-parte o una relación N:M, pero lo que está claro es quelo que se desea es que elegido un tema (la navegación temática es la principal del atlas),se elija el área geográfica sobre la que se desea la información.

Tema

ÁreaGeográfica

Información

Tema

ÁreaGeográfica

Información

Veamos otro ejemplo, extraído de MINTour. En este caso, tenemos que lo que se deseaes que, seleccionado un vuelo, ver lo que puede costar. Pero ese precio depende de latarifa que deseemos. Por tanto lo que nos interesa es seleccionar esa tarifa antes de ver elprecio. Sin duda este es el resultado de la relación N:M entre Vuelo y Tipo Tarifa Aérea,y muy difícilmente se puede observar una relación todo-parte, pero la única manera dereflejar la navegación que deseamos es mediante accesos múltiples.

Vuelo

Tipo TarifaAérea

PrecioVuelo

Vuelo

PrecioVuelo

Tipo TarifaAérea



La conclusión a la que llegamos después de éstos y toda una serie de casos que se noshan presentado es que los accesos múltiples no son únicamente el resultado de unaestructura todo-parte, sino más bien de una relación N:M (más o menos encubierta,según el caso). Por tanto, no estamos ante un patrón de relaciones diferente al que vimosen el anterior apartado, sino que ante una navegación diferente dentro de esa estructura,determinada por la semántica del caso concreto.

Por tanto será el diseñador quien deba decidir en cada caso qué tipo de acceso le interesamás en cada caso: si el que vimos en el apartado anterior, éste o, simplemente, el naturalque se refleja en RMM (navegando a la entidad intermedia). En concreto, en lo que hacereferencia a las estructuras todo-parte, podemos apreciar que prácticamente la soluciónidónea es la de los accesos múltiples, ya que lo que nos permitirá es reducir el númerode los elementos, filtrar, a los que vamos a navegar.

4.3.4. Conclusiones

En este apartado hemos estudiado tres nuevos métodos de acceso que a continuaciónresumimos:

• navegación jerárquica: al tener varias relaciones 1:N encadenadas, se permitenavegar desde cualquier entidad a otra que esté por debajo de ella en la jerarquía.Estos enlaces inferidos, no extraídos directamente de una relación 1:N, serepresentarán con trazo discontinuo.

• navegación en relaciones N:M: se permite navegar de un extremo al otro de larelación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberánincluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos laprimitiva de acceso (índice, visita guiada, ...) con la entidad intermedia.

• navegación múltiple: se crean unas nuevas primitivas que permiten el accesomúltiple de una entidad a otra, seleccionando un elemento de una tercera entidad dela que la entidad destino es parte. En el enlace quedará especificado qué entidad es laorigen, cuál la destino y cuál la tercera. Recordar que esta navegación esespecialmente apropiada en estructuras todo-parte.

Después de todo esto, la lista de las primitivas de acceso queda reflejada en la siguientetabla:

Hiperenlace

Hiperenlace jerárquico inferido

Índice

Visita guiada




Índice múltiple



Entidad Rel. N:M

Ejemplo de acceso a partir de una relaciónN:M, en este caso utilizando un índice(podría ser cualquier otra primitiva deacceso simple)

Una metodología relacional hipermedia. Estudio en casos prácticos V - CD-ROM de S’Albufera


Capítulo V1er CASO: CD-ROM DEL Parc Natural de S’albufera

En este capítulo vamos a realizar un análisis y evaluación detallado de la organizaciónde la información y navegación del CD-ROM del Parc Natural de S’Albufera, [UIB95].Veremos como en producto que ha recibido varios premios de diseño y navegación, sellegan a perder interesantes posibilidades al no sacar todo el jugo posible a lainformación de la que se dispone. Veremos como el uso de una metodología ayuda adetectar un mayor número de posibilidades navegacionales.

Para ello, utilizaremos la metodología RMM para, por un lado modelar el sistema tal ycomo se presentó, y por el otro, partiendo desde la primera fase, intentar detectar todasesas posibles estructuras navegacionales.

El objetivo de este caso de estudio será hacer un modelo de la aplicación y compararlocon un nuevo modelo, confeccionado desde cero, sin tener en cuenta cómo ésta fueestructurada. Para ello lo que haremos es comparar ambos modelos RMDM. No esnecesario analizar las posteriores fases de la metodología, ya que aquí sólo nos interesala estructura y enlaces navegacionales, y no la interfaz gráfica.

En el primer apartado de este capítulo se explicará qué es el CD-ROM del Parc Naturalde S’Albufera, y cómo está estructurado. En el segundo apartado se hace el modelado dela aplicación existente. Debido a que aquí ya tenemos presentes la estructura de menús ylos enlaces navegacionales, no es necesario seguir las dos primeras etapas de lametodología, y comenzaremos el estudio con el diseño navegacional (tercera etapa deRMM). Por contra, en el tercer apartado sí que haremos el análisis desde cero, buscandocuáles son las entidades y relaciones que intervienen en el problema y haciendo eldiseño de los slices. A partir de estas dos fases se confeccionará un nuevo modeloRMDM que difiere en varios aspectos del obtenido en el apartado anterior a partir de laaplicación actual. Las diferencias entre ambos son tratadas en el capítulo deconclusiones.

5.1. Qué es el CD-ROM de Parc Natural de S’Albufera

5.1.1. Introducción

El CD-ROM del Parc Natural de S’Albufera surge gracias a la colaboración de tresinstituciones de las Islas Baleares. Éstas son la Conselleria de Cultura, Educació iEsports del Govern Balear, La Caixa de Balears “Sa Nostra” - en el marco de suProyecto Natura - y la Universitat de les Illes Balears, y más concretamente suDepartament de Ciències Matemàtiques i Informàtica.

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 ParqueNatural de S'Albufera. Pretende ser un complemento a la visita de campo que realizanlos escolares al parque, bien para ser utilizado previamente a la visita como herramienta



de preparación de dicha visita, bien para utilizarse posteriormente a la visita y permitaampliar 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 asu implementación, es el de que no se utilizó ningún tipo de metodología o modelodurante su desarrollo.

5.1.2. Estructura de la aplicación

Para situarnos, es conveniente ver las diferentes partes en que se estructuró el CD-ROM.

Información general sobre S'Albufera

En este punto se ofrecen una serie de informaciones de interés general sobre elparque. Consta de las partes siguientes:- Información general: Incluye datos sobre su extensión, su descripciónadministrativa, horarios de funcionamiento, dirección y teléfono.- Rincones del Parque. A partir de un mapa del parque se ilustran fotografías dealgunos de los rincones más significativos del parque acompañadas de unapequeña reseña sobre cada uno de ellos.- Consejos para su visita. En forma de animaciones 2D de nuestra mascota se danal visitante doce útiles consejos para facilitarle la visita.- Importancia biológica. Se explica la importancia que tiene el Parque Natural deS'Albufera dentro de la red de espacios húmedos de las rutas que utilizan las avesmigratorias, así como su declaración de reserva biológica.- El Parque por estaciones. A partir de la fotografía de un mismo lugar del parqueen las distintas estaciones del año, se explican las diferencias de color, sonido,vida animal o vegetal, etc. que ofrece el parque según la época del año.- Un Parque para la ciencia. Que incluye dos apartados:- Proyectos científicos. Muestra los principales proyectos de investigacióncientífica que se llevan a cabo en el parque por parte del Institut de d'EstudisAvançats de les Illes Balears, la UIB y Earthwatch Europe.- Anillado de aves. Explica las tareas de anillado de aves migratorias que se llevana cabo anualmente en el parque.

El hombre y S'Albufera

En este punto se ofrece una visión de la interacción que ha tenido el hombre conS’Albufera a lo largo de la historia. Consta de las partes siguientes:

- La historia del parque. A través de un juego muy sencillo se reseñan los hitosmás importantes de la historia del parque desde la época de dominación romanahasta nuestros días. Concretamente se incide en el uso y aspecto del parquedurante distintas etapas: Romanos; Arabes; La Marjal; Real Patrimonio; Proyectosde desecado; Explotación arrocera; Fábrica de papel; Salinas; Segregaciónurbanística; Conferencia MAR; Campaña de concienciación; Central del Murterar;Compra de los terrenos; Declaración de Parque Natural; Lista RAMSAR.



- Usos. Combinando texto, vídeo , gráficos y fotografías se enseña el uso que hahecho de S’Albufera el hombre. Recoge: Caza, pesca, agricultura, uso devegetales, agua, salinas y turismo.- Cancionero popular. S'Albufera, y las actividades que en ella se han llevado acabo, está presente en la tradición 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 arròs y por otra una glosa de S’Albufera.- Gastronomía. La influencia de S’Albufera en la cocina tradicional de la comarcaes muy clara. Se utilizan ingrediente exclusivos de la zona como las anguilas o elarroz bomba . En este apartado se repasa un poco esta relación de la zona con lacocina 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 parquehasta un plano de la zona de sa Roca. Para cada uno de los tres planos se marcanrecorridos para la visita. En estos recorridos aparecen puntos de interés de los quepodemos ver bien una fotografía o un vídeo panorámico.

Fauna

La fauna y la flora son la base de un parque. Aparecen en este punto los animalesdel parque, tanto los que pueden observarse a simple vista como los difícilmentelocalizables. Se ha hecho una selección que incluye: 132 aves, 7 mamíferos, 2anfibios, 3 reptiles, 7 peces y 16 invertebrados. De cada especie hay una ficha queincluye: nombre común en catalán y castellano, nombre científico, forma deidentificación, situación en el parque y donde puede observarse en el Parque. Seincluye también una fotografía, sonido para aves y anfibios, y un calendario con laabundancia relativa de cada ave en el parque. Las aves pueden consultarsealfabéticamente, o por familias. Se incluye la definición de cada una de lasfamilias.

Flora

El herbario oficial del parque consta de más de 650 plantas censadas. Se ha hechouna selección de 52 especies que representan la diversidad de hábitats del parque.Para cada especie se tiene una ficha técnica, que incluye nombre común en catalány castellano, nombre científico, forma de identificación, situación en el parque ydonde puede observarse en el Parque. Para cada planta hay un calendario con laépoca de floración. Puede hacerse una selección alfabética a partir de su nombrecientífico o por hábitats.

Información para los educadores

Información destinada específicamente a los educadores. Incluye los itinerariosdidácticos creados por los monitores del Parque. Es la documentación que seentrega, junto con otro material didáctico, a los profesores para preparar la visitade sus alumnos. Incluye: objetivos, destinatarios, metodología, bloques decontenido (paisaje, medio físico, seres vivos, cambios y paisajes históricos, el



Parque Natural de S’Albufera), temporalización y recursos disponibles. El textoaparece combinado con fotografías y vídeo de visitas de escolares con losmonitores del parque.

Gestión del Parque Natural

El funcionamiento del Parque Natural de S’Albufera lo rige un documento: Plad'Ús i Gestió del Parc. Se reseñan sus líneas básicas:- Introducción.- Funciones básicas del Pla d'Ús i Gestió.- La gestión de biotopos.- Uso público.Todo ello acompañado de fotografías.

Otros parques

Además de diferenciar un parque nacional de un parque natural, incluye dosopciones. Por una parte nos sitúa sobre un mapa todos los parques nacionalesespañoles y por otra ofrece información sobre los parques de las Baleares.Concretamente sobre el Parque Nacional de Cabrera, el Parque Natural deMondragó, el Parque Natural de Sa Dragonera y el Parque Natural de S’Albuferades Grau. De cada uno de ellos se incluye:- Información general (extensión, termino municipal al que petenece, altitudmáxima y fecha de declaración).- Sus valores naturales, incluyendo la flora y la fauna de los hábitats queencontramos.- Actividades a realizar, excursiones, exposiciones o lugares que visitar.

Juegos

Nos aparece una ruleta que de forma aleatoria selecciona uno de los juegossiguientes:- Relacionar animales con sus siluetas.- Relacionar animales con sus cantos.- Adivinar animales o plantas a partir de una fotografía.- Puzles.- Preguntas aleatorias sobre el parque.- El juego de la vida.En función de las respuestas que se den, van acumulándose puntos. Para ello sedispone de 10 minutos. La finalidad global del juego es acumular el mayornúmero de puntos posible.

Bibliografía

Ordenada alfabéticamente por autores se incluye una relación de toda labibliografía, incluyendo libros, artículos científicos y de divulgación, relacionadade una u otra forma con el parque.



5.1.3. Premios recibidos

Esta producción fue presentada al II Premio Möbius Barcelona Multimedia. De las 42aplicaciones presentadas fue seleccionada como una de las 15 finalistas, y seleccionada,junto con otras 7 de estas aplicaciones finalistas, para optar al V Prix MöbiusInternacional, que se celebró en París en Septiembre del 96.

Además fue finalista del Perseo de Oro del Festival Internacionalle della OperaMultimediale, mediARTech, de Florencia, y mención especial por su diseño gráfico enel mismo Festival.



5.2. Modelado de la navegación del CD

En este apartado nos centraremos en la tercera etapa de la metodología RMM, es deciren el modelo RMDM.

Como podemos ver al arrancar el programa, éste comienza con un menú en el que seintegran diez opciones diferentes, aparte de opciones de créditos, que aquí notrataremos.

Esas diez opciones diferentes, las cuales ya han sido explicadas en el apartado anteriorson:

1. Información general2. Hombre y Albufera3. Itinerarios4. Flora5. Fauna6. Información para los educadores7. Juegos8. Otros parques9. Gestión del parque10. Bibliografía

Algunas estas opciones dan paso directamente a los contenidos finales. Tal es el caso deInformación para educadores (6), Juegos (7), Gestión del parque (9) y Bibliografía (10).En estos casos, del menú accederemos mediante un índice a las entidades (en el caso deJuegos, no tiene mucho sentido ya que sólo hay un registro en esa entidad que sería eljuego entero). Éstas no son accesibles desde ningún otro punto, ni permiten acceder aningún otro lugar de la aplicación.

INFO.EDUCADORES

BIBLIOGRAFIAGESTIONJUEGO

El caso de los Itinerarios (3) es sólo ligeramente más complejo. Se accede tambiénmediante un índice a los tres itinerarios, y en cada uno se accede también con un índicea los lugares interesantes de dicho itinerario.



ITINERARIO

LUGAR

No es muy diferente el apartado 8, Otros parques. En él se nos ofrecen dosposibilidades, los parques nacionales de España, o los parques naturales de Baleares.Por tanto, tenemos un nuevo menú que accede mediante un índice a ambos. Además, losparques de Baleares, incluyen sus valores naturales y actividades que se realizan.

PARQUEBALEARES

PARQUEESPAÑOL

ACTIVIDADVALOR

Similar a este último caso son las dos primeras opciones, Información General yHombre y Albufera. En el primero, accedemos a un menú:

- Información general (accederemos mediante un índice)- Rincones (ídem)



- Consejos (accedemos mediante una visita guiada)- Estaciones (accedemos mediante un índice)- Ciencia, que se divide en dos partes:

- Proyectos científicos (visita guiada)- Anidaje de aves (sólo tiene un registro)

- Importancia biológica (sólo tiene un registro)

INFO.GENERAL IMPORTANC.

BIOLÓGICA

ESTACIÓN

CONSEJO

RINCÓN

PROYECTOCIENTÍFICO

ANIDAJEDE AVES

En cuanto a la segunda opción también accedemos a un menú:

- Historia (índice)- Usos (índice)- Cancionero (índice)- Gastronomía (índice)

GASTRONOMIA

MÚSICA

USO

HISTORIA



Quedan por estudiar la parte más importante y rica, que es la que trata la flora y la fauna.

PLANTA

HABITATPLANTAS

Ésta es la parte que hace referencia a la flora. Podemos acceder de dos manerasdiferentes a la información de una planta: por un índice alfabético (visita guiadaindexada), o según su hábitat (índice). La información que tenemos de una planta, esmuy variada: nombre común (catalán), nombre científico, nombre castellano,identificación, la situación en el parque (ubicación), una foto, y por último los meses defloración (éste último aparece en un slice diferente). Tanto si se accede directamente,como si hace a través de la familia, se utiliza el nombre científico para el índice quepermite acceder a la planta en cuestión.



AVE

FAMILIAAVES

MAMIFERO

ANFIBIO

REPTIL

PEZ

INVERTEBRADO

La fauna se divide en varios apartados:

- Aves- Mamíferos- Anfibios- Reptiles- Peces- Invertebrados

A excepción de las aves, que es un caso similar al de las plantas, donde se permiteacceder por familias, se accede mediante una visita guiada indexada a la información.Ésta contiene el nombre común, científico, castellano, la identificación y situación en elparque en todos los casos. En el caso de los mamíferos y anfibios se utiliza un sliceadicional para mostrar el sonido que emite, mientras que para las aves se añaden dosslices, uno para el sonido y otro que muestra la sedentariedad del ave (en qué espaciosde tiempo se encuentra presente en el parque).

Para acceder a la información se utiliza en todos los casos la foto del animal, excepto enel caso de las aves, para lo cual se utiliza su nombre científico (tanto si se accededirectamente, como si se hace a través de la familia).

El resultado de todo este análisis queda reflejado en el diagrama RMDM:



ITINERARIO

AVE

FAMILIAAVES

MAMIFERO

ANFIBIO

REPTIL

PEZ

INVERTEBRADO

INFO.EDUCADORES

BIBLIOGRAFIA

GESTIONJUEGO

LUGAR

MENÚ PRINCIPAL

PLANTA

HABITATPLANTAS

INFO.GENERAL IMPORTANC.

BIOLÓGICA

ESTACION

CONSEJO

RINCÓN

PROYECTOCIENTÍFICO

GASTRONOMIA

MÚSICA

USO

HISTORIA

PARQUEBALEARES

PARQUEESPAÑOL

ANIDAJEDE AVES

ACTIVIDADUSO



5.3. Aplicación de todas las fases de la metodología

En este apartado lo que pretendemos es aplicar la metodología desde el principio, comosi nada se hubiese ya sido implementado. Ello nos ayudará a reconocer nuevasestructuras navegacionales que pasaron inadvertidas la primera vez.

5.3.1. Primera etapa: Diseño entidad-relación

En esta etapa vamos a identificar las entidades y las relaciones entre ellas. Las primerasapenas si variarán de las identificadas en el apartado anterior. Por contra, encontraremosvarias nuevas relaciones.

En realidad hay numerosas partes del diseño que no variarán respecto de laimplementación actual, dada su simplicidad. Ello nos lleva a centrarnos en la parte másrica de la navegación que es la que hace referencia a la flora y la fauna.

Estudiando el material, podemos estructurar toda la información en el siguiente conjuntode entidades, ordenadas alfabéticamente. El proceso para detectar estas entidades, no estrivial y debe dedicársele mucha atención, si bien a menudo estará influenciado en buenamedida por la información de la que se disponga y por los deseos del cliente. En estecaso concreto nos basaremos en la estructura que se eligió para el CD-ROM, aunque conciertos cambios.

Actividades: conjunto de actividades que se desarrollan en los parques de las islas.Anfibios: información textual del anfibio (entre ellas su ubicación en el parque),

su foto y su sonido característico.Aves: información textual del ave (entre otras su ubicación en el parque), su foto,

su sonido característico y un gráfico que muestra las épocas de presencia en elparque.

Bibliografía: lista de publicaciones donde se puede encontrar más información.Consejos: conjunto de consejos para la visita al parque.Estaciones: las cuatro estaciones del año, y breve descripción del parque en cada

estación.Familias de aves: las aves están agrupadas por familias.Gastronomía: platos típicos de la zona, que utiliza los recursos del lugar.Gestión del parque: conjunto de varios elementos importantes para la gestión del

parque.Hábitats de plantas: las plantas están agrupadas según su hábitat.Información general: tenemos la información geográfica, meteorológica y la

importancia biológica..Información importante para los educadores: conjunto de varios aspectos de

interés para los educadoresInvertebrados: información textual del invertebrado(entre ellas su ubicación 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.



Lugares: de un lugar tenemos un vídeo o una imagen. También podríamos tenerinformación textual describiendo el lugar o su importancia.

Mamíferos: información textual del mamífero (entre ellas su ubicación en elparque), su foto y su sonido característico.

Meses: los 12 meses del año.Momentos históricos: conjunto de varios momentos importantes en la historia de

S’Albufera.Música: canciones típicasParques de Baleares: 5 parques naturales de Baleares, con una breve información

de ellosParques de España: los parques nacionales de España con su localización en el

mapa del país.Peces: información textual del pez (entre ellas su ubicación en el parque) y su

foto.Plantas: información textual de la planta (entre otras su ubicación en el parque), su

foto y un gráfico con sus épocas de floración.Proyectos científicos: cuatro proyectos científicos que se desarrollan en el parque.Reptil: información textual del reptil (entre ellas su ubicación en el parque) y su

foto.Usos: el conjunto de los usos que el hombre hace del parqueValores 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 lasrelaciones entre ellas. Éstas son las que hemos observado:

- Claramente hay una relación 1:N entre el hábitat y las plantas.- Lo mismo ocurre entre las aves y las familias de aves (relación 1:N)- También es clara la relación entre los itinerarios y los lugares que lo componen. Eneste caso, puede haber lugares que estén en más de un itinerario, con lo cual tenemosuna relación N:M.- Todo animal o planta tiene la información de los lugares donde puede encontrarse. Portanto hay una clara relación entre los lugares y los animales o plantas. La relacióntambién es N:M.- Las aves tienen una información referente a los meses en los que se encuentran en elparque. Esto nos induce a incluir una relación entre los meses y las aves. Evidentementeésta será N:M.- Lo mismo ocurre con las plantas: tenemos la información de en qué meses seencuentran las plantas en flor. Por tanto, también hay una relación N:M entre meses yplantas.- Evidentemente, cada estación tiene unos meses. Para simplificar podemos incluir a unmes sólo en una estación, con lo cual tenemos una relación 1:N.- También se hace referencia a determinados lugares en cada algunos periodoshistóricos. Por ejemplo, Sa Marjal es un lugar que se crea en el siglo XVII. Se trata,pues, de una relación 1:N, ya que podemos suponer que un lugar es de importancia enun único punto histórico.- Igualmente, en cada lugar hay o ha habido unos determinados usos. Por ejemplo, en SaMarjal, el uso es el agrícola.



- También hay algunos animales que aparecen en los platos de cocina. Pero si se observala información de la que se dispone, este hecho sólo ocurre en un caso, en el cual, laanguila aparece en dos platos. Por tanto, decidimos no representarlo como una relación.

Después de esto ya podemos representar el diagrama entidad relación de RMM:

ITINERARIO

AVE

MES

PLANTA

FAMILIAPLANTAS

FAMILIAAVES

MAMIFERO

LUGAR

ANFIBIO

REPTIL

INVERTEBRADO

PEZ

GESTION

CONSEJOINFO.GENERAL

JUEGO

ESTACION

MOMENTOHISTÓRICO

USO

PROYECTOCIENTÍFICO

MÚSICA

GASTRONOMIA

INFO.EDUCADOR.

BIBLIOGRAF.

PARQUEBALEARES

PARQUESESPAÑA

ACTIVIDADUSO

5.3.2. Segunda fase: Diseño de slices

En esta etapa detallaremos los atributos y slices que forman cada entidad. Realmente enmuchos casos las entidades son muy simples y constarán tan sólo de uno o dos atributos,y la mayoría de las veces, únicamente utilizaremos un slice para cada entidad. Ésta es lalista de las entidades con sus correspondientes atributos y slices, ordenadaalfabéticamente.

Entidad Slice AtributoACTIVIDAD actividad 1 (head) nombre

fototexto



ANFIBIO anfibio 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

anfibio 2 sonidoAVE ave 1 (head) nombre científico

nombre catalánnombre castellanoidentificaciónfoto

ave 2 sonidoBIBLIOGRAFÍA bibliografía 1 (head) textoCONSEJO consejo 1 (head) dibujoESTACIÓN estación 1 (head) nombre

fototexto

FAMILIA AVES familia 1 (head) nombreGESTIÓN gestión 1 (head) nombre

fototexto

GASTRONOMÍA gastronomía 1 (head) nombrefotoreceta

HÁBITAT PLANTAS hábitat 1 (head) nombreINFO. EDUCADORES educadores 1 (head) nombre

fototexto

INFO. GENERAL general 1 (head) nombrefototexto

INVERTEBRADO invertebrado 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

ITINERARIO itinerario 1 (head) númeromapa

JUEGO juego 1 (head) juegoLUGAR lugar 1 (head) nombre

vídeo o imagentexto

MAMÍFERO mamífero 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

mamífero 2 sonidoMES mes 1 (head) nombreMOMENTO HISTÓRICO momento 1 (head) nombre

texto imagensonido

MÚSICA música 1 (head) nombreletrasonidovídeo

PARQUE BALEARES baleares 1 (head) nombre



localizaciónfototexto

PARQUE ESPAÑOL españa 1 (head) nombrelocalización

PEZ pez 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

PLANTA planta 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

PROYECTO CIENTÍFICO proyecto 1 (head) nombrefototexto

REPTIL reptil 1 (head) nombre científiconombre catalánnombre castellanoidentificaciónfoto

USO uso 1 (head) nombredibujovídeo o imagentexto

VALOR valor 1 (head) nombrefototexto

5.3.3. Tercera fase: Diseño navegacional

En esta etapa nos queda decidir las estructuras de navegación que utilizaremos paraacceder a la información y la estructura de menús. En cuanto a las estructuras denavegación hemos intentado seguir las ideas que utilizaron los diseñadores del CD-ROM. Referente a la estructura de menús, ésta es:

Información generalInformación generalConsejosImportancia biológicaProyectos científicosInformación educadoresJuegosGestión del parqueBibliografía

FloraHábitatsPlantas

FaunaAves

Familias de aves



AvesMamíferosAnfibiosReptilesPecesInvertebrados

EstacionesItinerariosOtros parques

Parques de BalearesValores naturalesActividades

Parques de EspañaEl hombre y S’Albufera

Momentos históricosUsosGastronomíaMúsica

A partir de aquí, podemos confeccionar el diagrama RMDM, resultado final de esteestudio:



INFO.GENERAL

INFO.EDUCADORES

PROYECTOCIENTÍFICO

IMPORTANC.BIOLÓGICA

CONSEJOS

BIBLIOGRAFIA

GESTION

JUEGO

PLANTA

HABITATPLANTAS

AVE

FAMILIAAVES

MAMIFERO

ANFIBIO

REPTIL

PEZ

INVERTEBRADO

ITINERARIO

LUGAR

ESTACIÓN

MES

LUGAR

MOMENTOHISTÓRICO

MÚSICA

USO

GASTRONOMIA

PARQUESBALEARES

PARQUEESPAÑOL

ACTIVIDADVALOR



5.4. Conclusiones

Como principal conclusión de este estudio se puede deducir la utilidad de utilizar unametodología y un modelo para evaluar detalladamente una aplicación ya desarrollada, aposteriori.

De esta manera se han detallado una serie de carencias en la estructura de la informacióny la navegación. Las exponemos detalladamente a continuación:

• Tanto animales (aves, mamíferos, peces, reptiles e invertebrados) comoplantas tienen un lugar en el parque. En el sistema actual se desaprovecha lainformación para permitir que navegar por todos, por ejemplo, mamíferos deun lugar concreto. Y también al contrario, no podemos ir a visitar el lugar quese nos cita en la información del animal o planta.

• El mismo caso ocurre con los usos del parque y con los momentos históricos,que no fueron enlazados con su lugar.

• Se pierde la posibilidad de navegar por estación o mes. Tenemos lainformación de la presencia de las aves por meses, así como una brevedescripción del parque en cada estación. Pero no podemos ver las aves queestán en un mes concreto (interesante si queremos planificar una visita real alparque). Lo mismo ocurre con el período de floración de las plantas, que no sepuede navegar por las plantas que están en flor en un mes concreto.

Una metodología relacional hipermedia. Estudio en casos prácticos VI - Proyecto MINTour


Capítulo VI2º CASO: PROYECTO EUROPEO MINTour

A la hora de hacer el análisis nos hemos intentado ajustar lo máximo posible a lasespecificaciones del proyecto europeo MINTour, [MIN96].

De hecho, nuestra idea inicial era utilizarlas al cien por cien. Sin embargo, esto no hasido posible debido a que se ha tardado alrededor de un año y medio en tener la base dedatos diseñada, y las especificaciones cambiaban tan frecuentemente, y con tantoserrores, que decidimos que era imposible seguir esa línea. Incluso la definicióndefinitiva de la base de datos de MINTour contiene varios fallos de normalizaciónincomprensibles.

Así pues, nuestro diseño resulta ser muy diferente del utilizado finalmente para elproyecto europeo, pero se ajusta a las primeras especificaciones que se hicieron para elmismo, a nuestro entender las más acertadas.

A partir de aquí comenzamos a analizar MINTour utilizando la metodología RMM.Nótese que en vez de crear diagramas globales, iremos generando diagramas para cadacategoría. De lo contrario resultaría completamente ilegible, dado el gran número deentidades y relaciones.

El proyecto europeo estaba dividido en una serie de categorías, que son lo que en lametodología Coad-Yourdon se denomina temas, una agrupación de entidades que tienenuna fuerte relación entre sí en el mundo real. Las categorías en que finalmente hemosdividido este proyecto son las en las que se dividió el proyecto original (aunque en lasúltimas versiones algunas de ellas se agruparan). Sin embargo, también hemosconsiderado interesante incluir alguna categoría nueva como Naturaleza, que hacereferencia a áreas naturales, que no fueron definidas en las primeras especificaciones delproyecto europeo, pero sí en las últimas. Ésta es nuestra lista, en la que nos basaremospara hacer el análisis:

1. Áreas geográficas2. Alojamientos3. Playas4. Deportes5. Eventos culturales6. Museos y monumentos7. Naturaleza8. Entretenimientos9. Restaurantes10. Rent-a-car11. Tiendas12. Transporte aéreo13. Transporte marítimo14. Transporte terrestre15. Transporte urbano



16. Taxi17. Paquetes turísticos18. Excursiones19. Teléfonos y direcciones de interés20. Agencias de viaje

A continuación, veremos en un primer apartado una introducción describiendo qué esMITNour. Después en los aprtados 6.2., 6.3. y 6.4., respectivamente, se analizan las tresprimeras fases de la metodología. Nótese que en el último subapartado del punto 6.4.(6.4.21.) se muestra la jerarquía de menús. Por otr parte, en el siguiente apartado, 6.5.,se estudian las últimas cuatro etapas, referentes a análisis de interfaz e implementación.En el último apartado se exponen las conclusiones y un resumen de las aportaciones quese han hecho a la metodología a partir de este análisis.



6.1. Qué es MINTour

La siguiente descripción del proyecto MINTour ha sido extraída del folleto depromoción del proyecto:

« MINTour es el acrónimo de Multimedia Information Network for TOURism. MINTouraspira a convertirse en el embrión de la futura red paneuropea de información turísticagracias al firme apoyo de las administraciones públicas y de los principales actoresdentro del sector turístico, utilizando y promocionando a la vez los estándares europeose internacionales. Dicha red debería ser utilizada por los ciudadanos en calidad deusuarios finales, empresas y Administración. »

6.1.1. Por qué nace MINTour

« La industria del turismo está sufriendo un giro y camina hacia un mercado cada vezmás diversificado y con una mayor presencia de clientes potenciales que quieren obtenerinformación precisa y fiable sobre sus posibles viajes. Las administraciones públicas sonlas únicas entidades que realmente pueden ofrecer información de calidad en términosde fidelidad y fiabilidad manteniéndola actualizada constantemente. Los productos concontenido multimedia accesibles a través de redes telemáticas pueden satisfacer estasnecesidades que la nueva industria turística demanda cada vez más. »

6.1.2. Objetivos

• Proporcionar al usuario « un punto de entrada a una amplia gama deinformación y productos turísticos mediante un sistema de navegaciónamigable. »

• « Promocionar el sector turístico europeo proporcionando al usuario una basede información turística multimedia y recursos derivados, alojamiento,transporte, servicios públicos e infraestructuras, actividades de placer,deportes, ...

• La información será homogénea, es decir, todos los países involucradosaccederán de la misma manera a un mismo tipo de información y ésta, a suvez, será descrita de manera similar.

• La información será fiable ya que serán las administraciones públicasrelacionadas con el sector turístico de cada país las encargadas de proveerinformación.

• Mejorar la calidad del servicio y contribuir a un nivel de satisfacción muchomás elevado por parte de los viajeros.

• Ofrecer un mejor servicio a los ciudadanos involucrando profundamente a lasadministraciones públicas con el soporte de la industria turística.



• Todo el sistema está configurado como un servicio público, sin ningunaorientación comercial. »



6.2. 1ª Etapa: Análisis Entidad-Relación

6.2.1. Áreas geográficas

Comenzamos el análisis por el corazón de MINTour, la estructura geográfica. EnMINTour, todos los objetos que pertenecen a una categoría están asociados a unaciudad. El término ciudad aquí toma una definición particular, refiriéndose a aquellosdestinos turísticos que queremos tratar. Por ejemplo, en el municipio de Palma, notendremos 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 adestino turístico.

La provincia también toma un sentido particular, ya que se consideran tres provincias enBaleares: Mallorca, Menorca y Eivissa i Formentera.

Cada una de estos niveles tiene asociados mapas. Es decir, que cada nación, región,provincia y ciudad tienen un mapa. Éste se utilizará para realizar búsquedas gráficas.

Ciudad

Provincia

Región

CiudadMultimedia

ProvinciaMultimedia

RegiónMultimedia

NaciónNación

Multimedia

TipoMultimedia

Veamos la descripción de atributos de estas entidades:

NaciónID Nación: texto (PK)Nombre: textoDescripción: textoMapa: texto (indica la dirección del fichero que contiene el mapa)

RegiónID Región: texto (PK)ID Nación: texto (FK)Nombre: textoDescripción: texto



Mapa: texto (indica la dirección del fichero que contiene el mapa)Posición X: entero (indica la posición en el eje X, dentro del mapa de nación)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de nación)

ProvinciaID Provinica: texto (PK)ID Región: texto (FK)Nombre: textoDescripción: textoMapa: texto (indica la dirección del fichero que contiene el mapa)Posición X: entero (indica la posición en el eje X, dentro del mapa de región)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de región)

CiudadID Ciudad: texto (PK)ID Provincia: texto (FK)Nombre: textoDescripción: textoMapa: texto (indica la dirección del fichero que contiene el mapa)Posición X: entero (indica la posición en el eje X, dentro del mapa de provincia)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de provincia)

Tipo MultimediaID Tipo MM: texto (PK)Nombre: textoDescripción: textoPlug-in: texto (Nombre y dirección del plug-in)

Nación MultimediaID MM: texto (PK)ID Nación: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Región MultimediaID MM: texto (PK)ID Región: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Provincia MultimediaID MM: texto (PK)ID Provincia: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)



Descripción: textoCopyright: textoDescripción: textoCopyright: texto

Ciudad MultimediaID MM: texto (PK)ID Ciudad: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



6.2.2. Alojamientos

Esta categoría engloba tanto hoteles, apartamentos, campings, hostales, entre otros tiposde alojamientos. Además de por el tipo, los alojamientos se clasifican por la categoría(estrellas o llaves).

Un alojamiento tiene varias habitaciones de tipos diferentes. Es importante hacer notarque la entidad “Habitaciones” es el resultado de la relación N:M entre las entidades“Hotel” y “Tipo Habitación”. Cada habitación tendrá un precio en función de latemporada (alta, media o baja) y del régimen de estancia (pensión completa, mediapensión, ...). Es importante notar que las temporadas no las marca cada hotel sino queestán marcadas por ley.

Un alojamiento puede pertenecer a una cadena.

Por último, el alojamiento ofrece unos servicios, ya sean generales o de habitación.Éstos se incluyen en una entidad adicional, dada la gran diversidad existente y laconstante aparición de nuevos servicios. Nótese que se podría relacionar también laentidad Habitación con los servicios, pero la información que se nos ofrece habla deservicios en habitaciones en general, sin especificar para qué tipos.

Ciudad

Alojamiento

TipoAlojamiento

HabitacionesTipo

Habitación

PrecioHabitación

RégimenEstancia

ServicioAlojamientos

AlojamientoServicio

Temporada

CategoríaAlojamientos

CadenaAlojamientos

AlojamientoMultimedia

TipoMultimedia

Veamos la descripción de los atributos de estas entidades:

AlojamientoID Alojamiento: texto (PK)ID Ciudad: texto (FK)ID Tipo Alojamiento: texto (FK)ID Cadena Alojamientos: texto (FK)



ID Categoría Alojamientos: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Tipo AlojamientoID Tipo Alojamiento: texto (PK)Nombre: textoDescripción: texto

Categoría AlojamientosID Categoría Alojamientos: texto (PK)Nombre: textoDescripción: texto

Cadena AlojamientosID Cadena Alojamientos: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoDirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Alojamiento MultimediaID MM: texto (PK)ID Alojamiento: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Servicio AlojamientosID Servicio Alojamientos: texto (PK)Nombre: textoDescripción: texto

Alojamiento Servicio



ID Alojamiento: texto (PK)ID Servicio Alojamientos: texto (PK)Cantidad: entero (a veces un servicio sólo tiene un valor booleano, pero a veces

un número - p.ej. número de pistas de tenis -. Este campo se utiliza parael segundo caso)

Habitación: booleano (indica si el servicio es de habitación, o por contra,general)

HabitacionesID Alojamiento: texto (PK)ID Tipo Habitación: texto (PK)Número: entero (indica el número de habitaciones de ese tipo en el alojamiento)

Tipo de HabitaciónID Tipo Habitación: texto (PK)Nombre: textoDescripción: texto

TemporadaID Temporada: texto (PK)Nombre: textoDescripción: textoFecha inicio: fechaFecha fin: fecha

Régimen EstanciaID Régimen Estancia: texto (PK)Nombre: textoDescripción: texto

Precio HabitaciónID Alojamiento: texto (PK)ID Tipo Habitación: texto (PK)ID Régimen Estancia: texto (PK)ID Temporada: texto (PK)Precio: entero



6.2.3. Playas

La estructura de esta categoría es sencilla. Una playa tiene un tipo de playas (arenosa,grava, ...), y unos servicios. Al igual que con los alojamientos, los servicios se incluyenen una entidad adicional, dada la gran diversidad existente y la constante aparición denuevos servicios.

Ciudad

Playa PlayaMultimedia

TipoPlaya

ServicioPlayas

PlayaServicio

TipoMultimedia


PlayaID Playa: texto (PK)ID Ciudad: texto (FK)ID Tipo Playa: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)

Tipo PlayaID Tipo Playa: texto (PK)Nombre: textoDescripción: texto

Playa MultimediaID MM: texto (PK)ID Playa: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Servicio PlayasID Servicio Playas: texto (PK)Nombre: texto



Descripción: texto

Playa ServicioID Playa: texto (PK)ID Servicio Playas: texto (PK)Cantidad: entero



6.2.4. Deportes

En esta categoría se hace referencia a las instalaciones deportivas. La base de laestructura de esta categoría es la instalación deportiva: una instalación está asociada auno o varios deportes y tiene varios servicios. También aquí incluimos una entidadadicional para los servicios.

Es necesaria una entidad que refleje los horarios de la instalación. Nótese que el horariopuede variar tanto según la temporada como según el día 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, sólo se indica si la instalación es gratuitao no. También se indica si está abierta para la práctica del público (p.ej. un estadio defútbol no suele ser para el uso público, ya que el público no puede practicar deporte enél).

Ciudad

Instalacióndeportiva

InstalaciónMultimedia

DeporteInstalación

ServicioDeportes

InstalaciónServicio

Deporte

HorarioInstalación

DeporteMultimedia

TipoMultimedia


DeporteID Deporte: texto (PK)Nombre: textoDescripción: texto

Instalación deportivaID Instalación deportiva: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)



Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: textoPúblico: booleano (indica si es una instalación para uso del público en general)Gratuito: booleano

Deporte InstalaciónID Deporte: texto (PK)ID Instalación deportiva: texto (PK)Número: entero (indica el número de pistas, piscinas, ...)

Deporte MultimediaID MM: texto (PK)ID deporte: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Instalación MultimediaID MM: texto (PK)ID Instalación deportiva: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Servicio DeportesID Servicio Deportes: texto (PK)Nombre: textoDescripción: texto

Instalación ServicioID Instalación deportiva: texto (PK)ID Servicio Deportes: texto (PK)Cantidad: entero

Horario InstalaciónID Instalación deportiva: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: hora



Hora cierre tarde: hora



6.2.5. Eventos culturales

Los eventos culturales se refieren tanto a conciertos, actuaciones, ..., ya sean puntuales oen el marco de un ciclo, así como a las fiestas populares, festivales, ... Por tanto, unevento cultural puede estar contenido en otro. Por ejemplo un concierto de la bandamunicipal puede estar incluido en las fiestas de una ciudad, o en el festival de bandas demúsica. Estos eventos pueden celebrarse en una o también en varias ciudades.

A su vez, un evento cultural puede tener varias representaciones (una, varias o tambiénninguna si no tenemos información concreta de fechas, horas o lugares), como en elcaso de una obra de teatro o un concierto, que pueden repetirse varios días, con lo cualtendremos otra entidad llamada Representación donde introduciremos la hora concretade cada representación, así como el precio. Esta representación se realiza en lo quedenominamos un centro cultural, que puede ser un teatro, un auditorio, un cine, oincluso un campo de fútbol.

TipoEvento

CentroCultural

Ciudad EventoCultural

Representación

EventosMultimedia

TipoMultimedia

EventoCiudad

Evento CulturalID Evento Cultural: texto (PK)ID Tipo Evento: texto (FK)Nombre: textoDescripción: textoFecha Inicio: fechaFecha Fin: fecha

Evento CiudadID Evento Cultural: texto (PK)ID Ciudad: texto (FK)

Tipo EventoID Tipo Evento: texto (PK)Nombre: textoDescripción: texto

Representación



ID Representación: texto (PK)ID Evento Cultural: texto (FK)ID Centro Cultural: texto (FK)Fecha: fechaHora Inicio: horaHora Fin: horaGratuito: booleano

Centro CulturalID Centro Cultural: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Eventos MultimediaID MM: texto (PK)ID Evento Cultural: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



6.2.6. Museos y monumentos

Ciertamente, museos y monumentos tienen unas características muy similares y, muy amenudo, es difícil separar uno de otro. Es por eso que decidimos considerarlos comouna única categoría. Un museo o monumento tendrá un tipo y un periodo histórico.

Aunque en un principio incluimos una entidad adicional para los servicios, finalmentedescartamos esta opción, ya que la única información disponible al respecto es si hayvisitas guiadas, auditorio o tienda, y parece difícil que un museo (y menos unmonumento sin museo) pueda ofrecer más servicios.

Ciudad

Monumento MonumentoMultimedia

TipoMonumento

ServicioMonumentos

MonumentoServicio

PeriodoHistórico

HorarioMonumento

TipoMultimedia

MonumentoID Monumento: texto (PK)ID Ciudad: texto (FK)ID Tipo Monumento: texto (FK)ID Periodo Histórico: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: textoVisitas guiadas: booleanoSala de proyecciones: booleanoTienda: booleanoPúblico: booleanoGratuito: booleano

Tipo MonumentoID Tipo Monumento: texto (PK)Nombre: texto



Descripción: texto

Periodo HistóricoID Periodo Histórico: texto (PK)Nombre: textoDescripción: textoAño Inicio: enteroAño Fin: entero

Monumento MultimediaID MM: texto (PK)ID Monumento: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Servicio MonumentosID Servicio Monumentos: texto (PK)Nombre: textoDescripción: texto

Monumento ServicioID Monumento: texto (PK)ID Servicio Monumentos: texto (PK)Cantidad: entero

Horario MonumentoID Monumento: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.7. Naturaleza

Los lugares naturales corresponden a montañas, lagos, parques naturales, ..., o inclusodentro de las ciudades a parques o jardines. Aquí ya no tiene sentido el periodohistórico. A menudo un área natural corresponderá a más de una ciudad. También aquíhemos decidido incluir los servicios en una entidad aparte. Servicios naturales puedenser un área de acampada, fuente, merendero, barbacoa, oficina de información, ...

NaturalezaCiudad

NaturalezaNaturalezaMultimedia

TipoNaturaleza

ServicioNatural

NaturalezaServicio

Ciudad

TipoMultimedia

NaturalezaID Naturaleza: texto (PK)ID Tipo Naturaleza: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Público: booleano (indica si está abierta al público)Gratuito: booleano

Naturaleza CiudadID Naturaleza: texto (PK)ID Ciudad: texto (PK)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)

Tipo NaturalezaID Tipo Naturaleza: texto (PK)Nombre: textoDescripción: texto

Naturaleza MultimediaID MM: texto (PK)ID Naturaleza: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



Servicio NaturalID Servicio Natural: texto (PK)Nombre: textoDescripción: texto

Naturaleza ServicioID Naturaleza: texto (PK)ID Servicio Natural: texto (PK)Cantidad: entero



6.2.8. Entretenimientos

En esta categoría englobamos bares, discotecas y demás lugares de ocio. La estructurade la categoría es simple: un tipo de entretenimiento (bar, discoteca, pub, ...) y unosservicios.

Ciudad

Entretenimiento EntretenimientoMultimedia

TipoEntretenimiento

HorarioEntretenimiento

TipoMultimedia

EntretenimientoID Entretenimiento: texto (PK)ID Ciudad: texto (FK)ID Tipo Entretenimiento: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: textoGratuito: booleano

Tipo EntretenimientoID Tipo Entretenimiento: texto (PK)Nombre: textoDescripción: texto

Entretenimiento MultimediaID MM: texto (PK)ID Entretenimiento: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



Horario EntretenimientoID Entretenimiento: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.9. Restaurantes

Los restaurantes presentan una estructura muy similar a la anterior categoría, si bienincorporan una categoría.

Ciudad

Restaurante RestauranteMultimedia

TipoRestaurantes

CategoríaRestaurante

HorarioRestaurante

TipoMultimedia

RestauranteID Restaurante: texto (PK)ID Ciudad: texto (FK)ID Tipo Restaurante: texto (FK)ID Categoría Restaurante: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Tipo RestauranteID Tipo Restaurante: texto (PK)Nombre: textoDescripción: texto

Restaurante MultimediaID MM: texto (PK)ID Restaurante: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Categoría Restaurante



ID Categoría Restaurante: texto (PK)Nombre: textoDescripción: texto

Horario RestauranteID Restaurante: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.10. Rent-a-car

Esta categoría es muy sencilla: un rent-a-car puede pertenecer a una cadena. Ademástiene un horario de apertura.

Ciudad

Rent-a-carCadenaRent-a-car

Rent-a-carMultimedia

HorarioRent-a-car

TipoMultimedia

Rent-a-carID Rent-a-car: texto (PK)ID Ciudad: texto (FK)ID Cadena Rent-a-car: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Cadena Rent-a-carID Cadena Rent-a-car: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoDirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Rent-a-car MultimediaID MM: texto (PK)ID Rent-a-car: texto (FK)



ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Horario Rent-a-carID Rent-a-car: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.11. Tienda

Una tienda pertenece a un tipo de tiendas (comestibles, souvenirs, grandes almacenes,...) y puede pertenecer a una cadena. Además también es importante el horario de latienda.

Ciudad

Tienda

TipoTienda

TiendaMultimedia

HorarioTienda

CadenaTiendas

TipoMultimedia

TiendaID Tienda: texto (PK)ID Ciudad: texto (FK)ID Tipo Tienda: texto (FK)ID Cadena Tiendas: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Tipo TiendaID Tipo Tienda: texto (PK)Nombre: textoDescripción: texto

Cadena TiendasID Cadena Tiendas: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoDirección: textoCP: textoTeléfono: texto



Fax: textoemail: textoURL: texto

Tienda MultimediaID MM: texto (PK)ID Tienda: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Horario TiendaID Tienda: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.12. Transporte aéreo

Un vuelo lógicamente une dos aeropuertos. Pero, siguiendo la terminología propia de laaviación, un código de vuelo corresponde a un par de aeropuertos, más una compañíaaérea, más una hora de salida. Por ejemplo, el vuelo IB3024 podría ser, por ejemplo, elvuelo de Iberia que va de Palma a Ibiza y que sale a las 8:00 de la mañana. El que sale alas 15:00 y/o es de otra compañía recibirá otro código. Nótese que el IB3024 es muyposible que no salga todos los días de la semana. En todo caso es necesario una entidadadicional Horario Vuelo, ya que puede ser que el vuelo cambie su horario según latemporada y que en invierno salga a las 7:00 y en verano a las 8:00.

Nótese que la entidad Compañía de Transportes es común a todos las categorías detransportes. Esto es debido a que por ejemplo, una compañía de aviación o de barcospuede tener autocares propios, y no tendría sentido crear dos veces la compañía en dosentidades diferentes.

Ciudad

AeropuertoAeropuertoMultimedia

HorarioVuelo

CompañíaTransportes

Vuelo

Tipo TarifaAérea

PrecioVuelo

Cía TransportesMultimedia

Ciudad

TipoMultimedia

AeropuertoID Aeropuerto: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: texto



Fax: textoemail: textoURL: texto

VueloID Vuelo: texto (PK)Descripción: texto (descripción del vuelo: compañía, origen, destino y escalas)ID Aeropuerto salida: texto (FK)ID Aeropuerto llegada: texto (FK)ID Compañía Transportes: texto (FK)Vuelo directo: booleano

Tipo Tarifa AéreaID Tipo Tarifa Aérea: texto (PK)Nombre: textoDescripción: texto

PrecioID Vuelo: texto (PK)ID Tipo Tarifa Aérea: texto (PK)Precio: enteroFecha inicio vigencia: fechaFecha fin vigencia: fecha

Compañía TransportesID Compañía Transportes: texto (PK)ID Ciudad: texto (PK)Nombre: textoDescripción: textoDirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Horario VueloID Vuelo: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaHora salida: horaHora llegada: horaLunes: booleano (indica si el vuelo sale los lunes)Martes: booleano (indica si el vuelo sale los martes)Miércoles: booleano (indica si el vuelo sale los miércoles)Jueves: booleano (indica si el vuelo sale los jueves)Viernes: booleano (indica si el vuelo sale los viernes)Sábado: booleano (indica si el vuelo sale los sábados)Domingo: booleano (indica si el vuelo sale los domingos)



Aeropuerto MultimediaID MM: texto (PK)ID Aeropuerto: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Cía Transportes MultimediaID MM: texto (PK)ID Compañía Transportes: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



6.2.13. Transporte marítimo

La estructura de esta entidad es muy similar a la de transporte marítimo. La únicadiferencia es que aquí sí que puede ocurrir que el trayecto Palma-Barcelona esté cubiertovarias veces al día pero el código es el mismo. También su horarios puede variar segúnel día de la semana. Estas dos consideraciones únicamente conllevan un cambio en laentidad Horario Trayecto respecto a la Horario Vuelo, pero no cambios en la estructura.

Ciudad

PuertoPuerto

Multimedia

HorarioTrayecto


Trayecto

PrecioPasaje

TipoPasaje


Ciudad

TipoMultimedia

PuertoID Puerto: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLongitud: texto (situación exacta del puerto: longitud)Latitud: texto (situación exacta del puerto: latitud)Profundidad máxima: enteroProfundidad mínima: enteroEstrechez: enteroLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: texto



email: textoURL: texto

TrayectoID Trayecto: texto (PK)Descripción: texto (descripción del trayecto: compañía, origen, destino y escalas)ID Puerto salida: texto (FK)ID Puerto llegada: texto (FK)ID Compañía Transportes: texto (FK)Trayecto directo: booleano

Tipo PasajeID Tipo Tipo Pasaje: texto (PK)Nombre: textoDescripción: texto

Precio PasajeID Trayecto: texto (PK)ID Tipo Pasaje: texto (PK)Precio: enteroFecha inicio vigencia: fechaFecha fin vigencia: fecha


Horario TrayectoID Trayecto: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaHora salida: hora (PK)Hora llegada: horaDía semana inicio: 1..7 (PK)Día semana fin: 1..7Vehículos: booleano (Indica si el barco permite llevar vehículos)Nombre barco: texto

Puerto MultimediaID MM: texto (PK)ID Puerto: texto (FK)



ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto




6.2.14. Transporte terrestre

Se engloban en esta categoría las categorías originales “Trenes” y “Autocares”, ya queambas resultan ser idénticas y que hemos decidido que normalmente cuando alguienbusca el modo de ir de una ciudad a otra, en principio no desea hacer dos búsquedasdiferentes, una para los trenes y otra para los autocares. De todos modos, mediante laentidad Medio de Transporte se diferencia entre uno y otro.

Nótese que tenemos la entidad “Parada” no es más que el nombre que le hemos dado ala entidad que surge de la relación N:M entre “Estación” y “Línea”.

Ciudad

EstaciónEstación

Multimedia

LíneaHorario

Tr. Terrestre


Parada

MedioTransporte


Ciudad

EstaciónID Estación: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto



LíneaID Línea: texto (PK)ID Compañía Transportes: texto (FK)ID Medio Transporte: texto (FK)Nombre: textoDescripción: textoNúmero paradas: entero

Medio TranporteID Medio Transporte: texto (PK)Nombre: texto

ParadaID Estación: texto (PK)ID Línea: texto (PK)Número orden: entero (indica el número de orden de la parada en la línea)


Horario Tr. TerrestreID Línea: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaHora salida: hora (PK)Hora llegada: horaDía semana inicio: 1..7 (PK)Día semana fin: 1..7Precio: texto (lista de los precios según las paradas)

Estación MultimediaID MM: texto (PK)ID Estación: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto

Cía Transportes MultimediaID MM: texto (PK)



ID Compañía Transportes: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)Descripción: textoCopyright: texto



6.2.15. Transporte Urbano

Esta categoría incluye los transportes urbanos, ya sean autobuses, metros, tranvías, etc.Como dato muy importante, la entidad parada urbana está relacionada con un grannúmero de entidades de otras categorías, ya que para un usuario es de interés qué paradaes la que está más próxima a un museo, una playa, un hotel, para así, poder saber quélínea necesita para llegar.

Ciudad

LíneaUrbana

ParadaUrbana

HorarioUrbano


ParadaLínea


Ciudad



Ciudad

LíneaUrbana Horario

Urbano


ParadaLínea


Ciudad

ParadaUrbana

AlojamientoParadaAlojamiento

PlayaParadaPlaya

Instalac.Deportiva

ParadaInstalac.

MuseoParadaMuseo

NaturalezaParadaNaturaleza

Entretenim.Parada

Entretenim.

RestauranteParadaRestaurante

Rent-a-carParadaRent-a-car

TiendaParadaTienda

AeropuertoParadaAeropuerto

PuertoParadaPuerto

EstaciónParadaEstación

InformaciónParadaInformación

AgenciaParadaAgencia

Línea UrbanaID Línea Urbana: texto (PK)ID Ciudad: texto (FK)ID Compañía Urbana: texto (FK)Nombre: textoDescripción: texto

Parada UrbanaID Parada Urbana: textoID Ciudad: textoDirección: texto



Localización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)

Parada LíneaID Línea: texto (PK)ID Parada Urbana: texto (PK)

Horario UrbanoLínea Urbana ID: fecha (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaPrimera salida origen: horaÚltima salida origen: horaPrimera salida destino: horaÚltima salida destino: horaFrecuencia de paso: númeroPrecio billete ordinario: númeroPrecio bono 10 billetes: número



Parada AlojamientoID Parada: textoID Alojamiento: texto

Parada PlayaID Parada: textoID Playa: texto

Parada Instalación



ID Deporte: textoID Playa: texto

Parada MuseoID Museo: textoID Playa: texto

Parada NaturalezaID Naturaleza: textoID Playa: texto

Parada EntretenimientoID Entretenimiento: textoID Playa: texto

Parada RestauranteID Restaurante: textoID Playa: texto

Parada Rent-a-carID Rent-a-car: textoID Playa: texto

Parada TiendaID Tienda: textoID Playa: texto

Parada AeropuertoID Aeropuerto: textoID Playa: texto

Parada PuertoID Puerto: textoID Playa: texto

Parada EstaciónID Estación: textoID Playa: texto

Parada InformaciónID Información: textoID Playa: texto

Parada AgenciaID Agencia: textoID Playa: texto



6.2.16. Taxis

Esta categoría se refiere a paradas de taxis. Su estructura es la más simple: sólo estárelacionada con la ciudad, ni siquiera tienen sentido objetos multimedia.

Ciudad

Taxi

TaxiID Taxi: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoDirección: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)



6.2.17. Paquete turístico

Un paquete turístico u oferta promocional, es ofrecido por una agencia de viajes, en unaciudad y, generalmente, también un alojamiento concreto. El precio de un paquetedepende del régimen de estancia.

OfertaPromocional

CadenaAg. Viajes

Alojamiento

RégimenEstancia

PrecioOferta

Ciudad

Oferta PromocionalID Oferta: texto (PK)ID Ciudad: texto (FK)ID Alojamiento: texto (FK)ID Cadena Ag. Viajes: texto (FK)Nombre: textoDescripción: textoExcursiones: booleanoCoche de alquiler: booleano

Régimen EstanciaID Régimen Estancia: texto (PK)Nombre: textoDescripción: texto

Precio OfertaID Oferta: texto (PK)ID Régimen Estancia: texto (PK)Fecha inicio vigencia: fechaFecha fin vigencia: fechaPrecio: entero



6.2.18. Excursiones

Esta categoría describe excursiones, ya sea a pie, en bicicleta, en coche o en cualquiermedio de transporte. Una excursión puede incluir una o más ciudades (recuérdese queen MINTour ciudad representaba a un municipio).

MedioTransporte

Excursión

ExcursiónMultimedia

Ciudad

ExcursiónCiudad

ExcursiónID Excursión: texto (PK)ID Medio Transporte: texto (FK)Nombre: textoDescripción: textoPunto de partida: textoPunto final: textoRecorrido: textoDuración: textoDificultad: textoTransportes: texto (descripción de medios de transporte utilizados como soporte)Valor historico-natural: textoMapa: texto (dirección con el mapa del recorrido)

Medio TranporteID Medio Transporte: texto (PK)Nombre: texto

Excursión CiudadID Excursión: texto (PK)ID Ciudad: texto (PK)

Excursión MultimediaID MM: texto (PK)ID Excursión: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)



Descripción: textoCopyright: texto



6.2.19. Teléfonos y direcciones útiles

Se engloban aquí todas las oficinas de información turística, así como otro tipo dedirecciones y teléfonos que puedan resultar de interés para el turista, como por ejemplo,un grupo ecologista, una federación de un deporte determinado, ... Su estructura essimplísima: sólo está relacionada con la ciudad y con un horario, y ni siquiera tienensentido objetos multimedia.

Ciudad

Información

HorarioInformación

InformaciónID Información: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: textoGratuito: booleano

Horario InformaciónID Información: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.2.20. Agencias de viaje

Esta categoría hace referencia a las agencias de viaje. Cada una de ellas pertenece a unacadena, de la cual podemos tener información multimedia (no de la agencia enconcreto). Por último la agencia tiene un horario.

Agencia

CadenaAgencias

Ciudad

Cadena agencias Multimedia

HorarioAgencia

TipoMultimedia

AgenciaID Agencia: texto (PK)ID Ciudad: texto (FK)ID Cadena Agencias: texto (FK)Nombre: textoDescripción: textoLocalización: texto (breve explicación de la zona donde se halla y cómo llegar)Posición X: entero (indica la posición en el eje X, dentro del mapa de ciudad)Posición Y: entero (indica la posición en el eje Y, dentro del mapa de ciudad)Dirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Cadena AgenciasID Cadena Agencias: texto (PK)ID Ciudad: texto (FK)Nombre: textoDescripción: textoDirección: textoCP: textoTeléfono: textoFax: textoemail: textoURL: texto

Agencia MultimediaID MM: texto (PK)ID Agencia: texto (FK)ID Tipo MM: texto (FK)Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...)



Descripción: textoCopyright: texto

Horario AgenciaID Agencia: texto (PK)Fecha inicio vigencia: fecha (PK)Fecha fin vigencia: fechaDía semana inicio: 1..7 (PK) (1: lunes, 7: domingo)Día semana fin: 1..7Hora apertura mañana: horaHora cierre mañana: horaHora apertura tarde: horaHora cierre tarde: hora



6.3. 2ª Etapa: Diseño de slices


NaciónMínimo NombreHead (híbrido) Nombre

DescripciónMapa

RegiónMínimo NombreHead (híbrido) Nación.Nombre

NombreDescripciónMapa

Mapa Nación (híbrido) Nación.MapaPosición XPosición Y

ProvinciaMínimo NombreHead (híbrido) Región.Nombre


Mapa Región Región.MapaPosición XPosición Y

CiudadMínimo NombreHead (híbrido) Provincia.Nombre


Mapa Provincia (híbrido) Provincia.MapaPosición XPosición Y

Tipo MultimediaMínimo NombreHead Nombre



DescripciónPlug-in

Nación MultimediaMínimo (híbrido) Nación.nombre

DescripciónHead (híbrido) Descripción

CopyrightDirecciónNación.NombreTipo Multimedia.Nombre

Región MultimediaMínimo (híbrido) Región.nombre


CopyrightDirecciónRegión.NombreTipo Multimedia.Nombre

Provincia MultimediaMínimo (híbrido) Provinica.nombre


CopyrightDirecciónProvincia.NombreTipo Multimedia.Nombre

Ciudad MultimediaMínimo (híbrido) Ciudad.nombre


CopyrightDirecciónCiudad.NombreTipo Multimedia.Nombre



6.3.2. Alojamientos

AlojamientoMínimo NombreHead (híbrido) Nombre

Ciudad.NombreTipo Alojamiento.NombreCadena Alojamientos.NombreCategoría Alojamientos.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemail

Mapa Ciudad (híbrido) Ciudad.MapaLocalizaciónPosición XPosición Y

Tipo AlojamientoMínimo NombreHead Nombre

Descripción

Categoría AlojamientosMínimo NombreHead Nombre

Descripción

Cadena AlojamientosMínimo NombreHead (híbrido) Nombre

Ciudad.NombreDescripciónDirecciónCPTeléfonoFaxemailURL

Alojamiento MultimediaMínimo (híbrido) Alojamiento.Nombre

Descripción



Head (híbrido) DescripciónCopyrightDirecciónAlojamiento.NombreTipo Multimedia.Nombre

Servicio AlojamientosMínimo NombreHead Nombre

Descripción

Alojamiento ServicioMínimo (híbrido) Alojamiento.Nombre

Servicio Alojamientos.NombreHead (híbrido) Alojamiento.Nombre

Servicio Alojamientos.NombreNúmeroHabitación

HabitacionesMínimo (híbrido) Alojamiento.Nombre

Tipo Habitación.NombreHead (híbrido) Alojamiento.Nombre

Tipo Habitación.NombreNúmero

Tipo de HabitaciónMínimo NombreHead Nombre

Descripción

TemporadaMínimo NombreHead Nombre

DescripciónFecha inicioFecha fin

Régimen EstanciaMínimo NombreHead Nombre

Descripción



Precio HabitaciónMínimo (híbrido) Alojamiento.Nombre

Tipo Habitación.NombreRégimen Estancia.NombreTemporada.Nombre

Head (híbrido) Alojamiento.NombreTipo Habitación.NombreRégimen Estancia.NombreTemporada.NombrePrecio



6.3.3. Playas

PlayaMínimo NombreHead (híbrido) Ciudad.Nombre

Tipo Playa.NombreNombreDescripciónLocalización


Tipo PlayaMínimo NombreHead Nombre

Descripción

Playa MultimediaMínimo (híbrido) Playa.Nombre


CopyrightDirecciónPlaya.NombreTipo Multimedia.Nombre

Servicio PlayasMínimo NombreHead Nombre

Descripción

Playa ServicioMínimo (híbrido) Playa.Nombre

Servicio Playas.NombreHead (híbrido) Playa.Nombre

Servicio Playas.NombreCantidad



6.3.4. Deportes

DeporteMínimo NombreHead Nombre

Descripción

Instalación deportivaMínimo NombreHead (híbrido) Nombre

Ciudad.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURLPúblicoGratuito


Deporte InstalaciónMínimo (híbrido) Instalación deportiva.Nombre

Deporte.NombreHead (híbrido) Instalación deportiva.Nombre

Deporte.NombreCantidad

Deporte MultimediaMínimo (híbrido) Deporte.Nombre


CopyrightDirecciónDeporte.NombreTipo Multimedia.Nombre

Instalación MultimediaMínimo (híbrido) Instalación deportiva.Nombre




CopyrightDirecciónInstalación deportiva.NombreTipo Multimedia.Nombre

Servicio DeportesMínimo NombreHead Nombre

Descripción

Instalación ServicioMínimo (híbrido) Instalación deportiva.Nombre

Servicio Deportes.NombreHead (híbrido) Instalación deportiva.Nombre

Servicio Deportes.NombreCantidad

Horario InstalaciónMínimo (híbrido) Instalación deportiva.Nombre

Fecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana fin

Head (híbrido) Instalación deportiva.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde




Evento CulturalMínimo NombreHead (híbrido) Nombre

Tipo Evento.NombreDescripciónFecha InicioFecha Fin

Evento CiudadMínimo (híbrido) Evento Cultural.Nombre

Ciudad.NombreHead (híbrido) Evento Cultural.Nombre

Ciudad.Nombre

Tipo EventoMínimo NombreHead Nombre

Descripción

RepresentaciónMínimo NombreHead (híbrido) Nombre

Evento Cultural.NombreCentro Cultural.NombreFechaHora InicioHora FinGratuito

Centro CulturalMínimo NombreHead (híbrido) Nombre

Ciudad.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL




Eventos MultimediaMínimo (híbrido) Evento Cultural.Nombre


CopyrightDirecciónEvento Cultural.NombreTipo Multimedia.Nombre




MonumentoMínimo NombreHead (híbrido) Nombre

Ciudad.NombreTipo Monumento.NombrePeriodo Histórico.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURLVisitas guiadasSala de proyeccionesTiendaPúblicoGratuito


Tipo MonumentoMínimo NombreHead Nombre

Descripción

Periodo HistóricoMínimo NombreHead Nombre

DescripciónAño inicioAño fin

Monumento MultimediaMínimo (híbrido) Monumento.Nombre


CopyrightDirecciónMonumento.NombreTipo Multimedia.Nombre



Servicio MonumentosMínimo NombreHead Nombre

Descripción

Monumento ServicioMínimo (híbrido) Monumento.Nombre

Servicio Monumentos.NombreHead (híbrido) Monumento.Nombre

Servicio Monumentos.NombreCantidad

Horario MonumentoMínimo (híbrido) Monumento.Nombre


Head (híbrido) Monumento.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde



6.3.7. Naturaleza

NaturalezaMínimo NombreHead (híbrido) Tipo Naturaleza.Nombre

NombreDescripciónLocalizaciónPúblicoGratuito

Naturaleza CiudadMínimo (híbrido) Naturaleza.Nombre

Ciudad.NombreHead (híbrido) Naturaleza.Nombre

Ciudad.NombreCiudad.MapaPosición XPosición Y

Tipo NaturalezaMínimo NombreHead Nombre

Descripción

Naturaleza MultimediaMínimo (híbrido) Naturaleza.Nombre


CopyrightDirecciónNaturaleza.NombreTipo Multimedia.Nombre

Servicio NaturalMínimo NombreHead Nombre

Descripción

Naturaleza ServicioMínimo (híbrido) Naturaleza.Nombre

Servicio Natural.NombreHead (híbrido) Naturaleza.Nombre



Servicio Natural.NombreCantidad




EntretenimientoMínimo NombreHead (híbrido) Nombre

Ciudad.NombreTipo Entretenimiento.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURLGratuito


Tipo EntretenimientoMínimo NombreHead Nombre

Descripción

Entretenimiento MultimediaMínimo (híbrido) Entretenimiento.Nombre


CopyrightDirecciónEntretenimiento.NombreTipo Multimedia.Nombre

Horario EntretenimientoMínimo (híbrido) Entretenimiento.Nombre


Head (híbrido) Entretenimiento.NombreFecha inicio vigenciaFecha fin vigencia



Día semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde



6.3.9. Restaurantes

RestauranteMínimo NombreHead (híbrido) Nombre

Ciudad.NombreTipo Restaurante.NombreCategoría Restaurante.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


Tipo RestauranteMínimo NombreHead Nombre

Descripción

Restaurante MultimediaMínimo (híbrido) Restaurante.Nombre


CopyrightDirecciónRestaurante.NombreTipo Multimedia.Nombre

Categoría RestauranteMínimo NombreHead Nombre

Descripción

Horario RestauranteMínimo (híbrido) Restaurante.Nombre

Fecha inicio vigenciaFecha fin vigencia



Día semana inicioDía semana fin

Head (híbrido) Restaurante.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde



6.3.10. Rent-a-car

Rent-a-carMínimo NombreHead (híbrido) Nombre

Ciudad.NombreCadena Rent-a-car.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


Cadena Rent-a-carMínimo NombreHead (híbrido) Nombre


Rent-a-car MultimediaMínimo (híbrido) Monumento.Nombre


CopyrightDirecciónMonumento.NombreTipo Multimedia.Nombre

Horario Rent-a-carMínimo (híbrido) Rent-a-car.Nombre

Fecha inicio vigencia



Fecha fin vigenciaDía semana inicioDía semana fin

Head (híbrido) Rent-a-car.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde



6.3.11. Tienda

TiendaMínimo NombreHead (híbrido) Nombre

Ciudad.NombreCadena Tiendas.NombreTipo Tienda.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


Tipo TiendaMínimo NombreHead Nombre

Descripción

Cadena TiendasMínimo NombreHead (híbrido) Nombre


Tienda MultimediaMínimo (híbrido) Tienda.Nombre


Copyright



DirecciónTienda.NombreTipo Multimedia.Nombre

Horario TiendaMínimo (híbrido) Tienda.Nombre


Head (híbrido) Tienda.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde




AeropuertoMínimo ID Aeropuerto

NombreCiudad.Nombre

Head (híbrido) ID AeropuertoNombreCiudad.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


VueloMínimo ID Vuelo

DescripciónHead (híbrido) ID Vuelo

DescripciónAeropuerto salida.NombreAeropuerto llegada.NombreCompañía Transportes.NombreVuelo directo

Tipo Tarifa AéreaMínimo NombreHead Nombre

Descripción

PrecioMínimo (híbrido) ID Vuelo

Vuelo.DescripciónTipo Tarifa Aérea.NombreFecha inicio vigenciaFecha fin vigencia

Head (híbrido) ID VueloVuelo.Descripción



Tipo Tarifa Aérea.NombrePrecioFecha inicio vigenciaFecha fin vigencia

Compañía TransportesMínimo NombreHead (híbrido) Nombre


Horario VueloMínimo (híbrido) ID Vuelo

Vuelo.DescripciónFecha inicio vigenciaFecha fin vigencia

Head (híbrido) ID VueloVuelo.DescripciónFecha inicio vigenciaFecha fin vigenciaHora salidaHora llegadaLunesMartesMiércolesJuevesViernesSábadoDomingo

Aeropuerto MultimediaMínimo (híbrido) Aeropuerto.Nombre


CopyrightDirecciónAeropuerto.NombreTipo Multimedia.Nombre



Cía Transportes MultimediaMínimo (híbrido) Compañía Transportes.Nombre


CopyrightDirecciónCompañía Transportes.NombreTipo Multimedia.Nombre




PuertoMínimo Nombre

Ciudad.NombreHead (híbrido) Nombre

Ciudad.NombreLongitudLatitudProfundidad máximaProfundidad mínimaEstrechezDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


TrayectoMínimo DescripciónHead (híbrido) Descripción

Puerto salida.NombrePuerto llegada.NombreCompañía Transportes.NombreTrayecto directo

Tipo PasajeMínimo NombreHead Nombre

Descripción

Precio PasajeMínimo (híbrido) Trayecto.Descripción

Tipo Pasaje.NombreFecha inicio vigenciaFecha fin vigencia

Head (híbrido) Trayecto.DescripciónTipo Pasaje.Nombre



PrecioFecha inicio vigenciaFecha fin vigencia



Horario TrayectoMínimo (híbrido) Trayecto.Descripción


Head (híbrido) Trayecto.DescripciónFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora salidaHora llegadaDía semana inicioDía semana finVehículosNombre barco

Puerto MultimediaMínimo (híbrido) Puerto.Nombre


CopyrightDirecciónPuerto.NombreTipo Multimedia.Nombre









EstaciónMínimo Nombre

Ciudad.NombreHead (híbrido) Nombre



LíneaMínimo NombreHead (híbrido) Nombre

DescripciónCompañía Transportes.NombreMedio Transporte.NombreNúmero paradas

Medio TranporteMínimo NombreHead Nombre

ParadaMínimo (híbrido) Estación.Nombre

Línea.NombreHead (híbrido) Estación.Nombre

Línea.NombreNúmero orden


Ciudad.NombreDescripción



LocalizaciónDirecciónCPTeléfonoFaxemailURL

Horario Tr. TerrestreMínimo (híbrido) Línea.Nombre

Fecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora salida

Head (híbrido) Línea.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora salidaHora llegadaPrecio

Estación MultimediaMínimo (híbrido) Estación.Nombre


CopyrightDirecciónEstación.NombreTipo Multimedia.Nombre







Línea UrbanaMínimo (híbrido) Nombre

Ciudad.NombreCompañía Urbana.Nombre

Head (híbrido) NombreCiudad.NombreCompañía Urbana.NombreDescripción

Parada UrbanaMínimo (híbrido) Dirección

Ciudad.NombreHead (híbrido) Dirección

Ciudad.NombreLocalización


Parada LíneaMínimo (híbrido) Línea.Nombre

Parada Urbana.DirecciónHead (híbrido) Línea.Nombre

Parada Urbana.Dirección

Horario UrbanoMínimo (híbrido) Línea Urbana.Nombre

Fecha inicio vigenciaFecha fin vigencia

Head (híbrido) Línea Urbana.NombreFecha inicio vigenciaFecha fin vigenciaPrimera salida origenÚltima salida origenPrimera salida destinoÚltima salida destinoFrecuencia de pasoPrecio billete ordinarioPrecio bono 10 billetes








Parada AlojamientoMínimo (híbrido) Parada Urbana.Dirección

Alojamiento.NombreHead (híbrido) Parada Urbana.Dirección

Alojamiento.Nombre

Parada PlayaMínimo (híbrido) Parada Urbana.Dirección

Playa.NombreHead (híbrido) Parada Urbana.Dirección

Playa.Nombre

Parada InstalaciónMínimo (híbrido) Parada Urbana.Dirección

Instalación Deportiva.NombreHead (híbrido) Parada Urbana.Dirección

Instalación Deportiva.Nombre

Parada MuseoMínimo (híbrido) Parada Urbana.Dirección

Museo.Nombre



Head (híbrido) Parada Urbana.DirecciónMuseo.Nombre

Parada NaturalezaMínimo (híbrido) Parada Urbana.Dirección

Naturaleza.NombreHead (híbrido) Parada Urbana.Dirección

Naturaleza.Nombre

Parada EntretenimientoMínimo (híbrido) Parada Urbana.Dirección

Entretenimiento.NombreHead (híbrido) Parada Urbana.Dirección

Entretenimiento.Nombre

Parada RestauranteMínimo (híbrido) Parada Urbana.Dirección

Restaurante.NombreHead (híbrido) Parada Urbana.Dirección

Restaurante.Nombre

Parada Rent-a-carMínimo (híbrido) Parada Urbana.Dirección

Rent-a-car.NombreHead (híbrido) Parada Urbana.Dirección

Rent-a-car.Nombre

Parada TiendaMínimo (híbrido) Parada Urbana.Dirección

Tienda.NombreHead (híbrido) Parada Urbana.Dirección

Tienda.Nombre

Parada AeropuertoMínimo (híbrido) Parada Urbana.Dirección

Aeropuerto.NombreHead (híbrido) Parada Urbana.Dirección

Aeropuerto.Nombre

Parada Puerto



Mínimo (híbrido) Parada Urbana.DirecciónPuerto.Nombre

Head (híbrido) Parada Urbana.DirecciónPuerto.Nombre

Parada EstaciónMínimo (híbrido) Parada Urbana.Dirección

Estación.NombreHead (híbrido) Parada Urbana.Dirección

Estación.Nombre

Parada InformaciónMínimo (híbrido) Parada Urbana.Dirección

Información.NombreHead (híbrido) Parada Urbana.Dirección

Información.Nombre

Parada AgenciaMínimo (híbrido) Parada Urbana.Dirección

Agencia.NombreHead (híbrido) Parada Urbana.Dirección

Agencia.Nombre



6.3.16. Taxis

TaxiMínimo NombreHead (híbrido) Nombre

Ciudad.NombreDescripciónLocalizaciónDirección





Oferta PromocionalMínimo (híbrido) Nombre

Ciudad.NombreAlojamiento.NombreCadena Ag. Viajes.Nombre

Head (híbrido) NombreID CiudadID AlojamientoID Cadena Ag. ViajesDescripciónExcursionesCoche de alquiler

Régimen EstanciaMínimo NombreHead Nombre

Descripción

Precio OfertaMínimo (híbrido) Oferta.Nombre

Régimen Estancia.NombreFecha inicio vigenciaFecha fin vigencia

Head (híbrido) Oferta.NombreRégimen Estancia.NombreFecha inicio vigenciaFecha fin vigenciaPrecio



6.3.18. Excursiones

ExcursiónMínimo (híbrido) Nombre

Medio Transporte.NombreHead (híbrido) Nombre

Medio Transporte.NombreDescripciónPunto de partidaPunto finalRecorridoDuraciónDificultadTransportesValor historico-naturalMapa

Medio TranporteMínimo NombreHead Nombre

Excursión CiudadMínimo Excursión.Nombre

Ciudad.NombreHead Excursión.Nombre

Ciudad.Nombre

Excursión MultimediaMínimo (híbrido) Excursión.Nombre


CopyrightDirecciónExcursión.NombreTipo Multimedia.Nombre




InformaciónMínimo NombreHead (híbrido) Nombre

Ciudad.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURLGratuito


Horario InformaciónMínimo (híbrido) Información.Nombre


Head (híbrido) Información.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde




AgenciaMínimo NombreHead (híbrido) Nombre

Ciudad.NombreCadena Agencias.NombreDescripciónLocalizaciónDirecciónCPTeléfonoFaxemailURL


Cadena AgenciasMínimo NombreHead (híbrido) Nombre


Agencia MultimediaMínimo (híbrido) Agencia.Nombre


CopyrightDirecciónAgencia.NombreTipo Multimedia.Nombre

Horario AgenciaMínimo (híbrido) Agencia.Nombre




Head (híbrido) Agencia.NombreFecha inicio vigenciaFecha fin vigenciaDía semana inicioDía semana finHora apertura mañanaHora cierre mañanaHora apertura tardeHora cierre tarde



6.4. 3ª Etapa: Diseño navegacional

Notas:

• Como enlaces unidireccionales sólo marcamos los que no tienen ningunaprimitiva de acceso. En el caso de que sí la haya, se sobre-entiende que hay uncamino de vuelta, y por tanto, no es necesario representarlo. En el primer caso síes necesario reflejar explícitamente que habrá un enlace entre ambas entidades.

• Al hacer el estudio de las relaciones complejas, hemos etiquetado los tres tiposdiferentes con una letra que se les dio al definirlas en el apartado 4.3..Recordemos:

A: accesos jerárquicosB: accesos en relaciones N:MC: accesos múltiples




Etapa 3.1. Estudio de las relaciones complejas

Relación Tipo DescripciónNación-Región-Provincia A Es útil poder acceder a las provincias de una

nación, porque se puede dar el caso de que unoconozca la provincia en la que está interesado,pero no el nombre de la región.

Nación-Región-Provincia-Ciudad

A ídem

Región-Provincia-Ciudad A ídem

No tienen interés las relaciones del tipo Nación-Nación Multimedia-Tipo Multimedia,etc., porque lo que se desea es que de una nación se puedan ver todos los objetosmultimedia, independientemente de si son vídeos, imágenes, ...

Tampoco tienen interés las relaciones del tipo Nación-Región-Región Multimedia,porque una nación ya tiene asignados una serie de elementos multimedia y, por tanto, notiene sentido permitir ver todos los de sus regiones

Slices derivados de las relaciones complejasEn las relaciones de tipo A (accesos jerárquicos), no es necesario ningún cambio en ladefinición de los slices.

Etapa 3.2. Diagrama RMDM



Ciudad

Provincia

Región

CiudadMultimedia

ProvinciaMultimedia

RegiónMultimedia

NaciónNación

Multimedia

TipoMultimedia



6.4.2. Alojamientos


A pesar de que una cadena de alojamientos está situada en una ciudad (su sede central),esta información no tiene interés 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 información de interés turístico. A la información de cadena sepuede llegar (se supone que muy esporádicamente) desde el hotel. Tampoco tieneninguna utilidad que desde una cadena se pase a visitar la ciudad en la que está afincada.

Relación Tipo DescripciónAlojamiento-AlojamientoServicio-ServicioAlojamientos

B Se trata de una relación N:M y lo que interesa esacceder de un alojamiento a sus servicios. Enparticular deseamos ver todos los servicios a lavez.

Alojamiento-TipoHabitación-Habitaciones

C Nos interesa acceder de un alojamiento a lainformación de sus habitaciones, seleccionandoqué tipo de habitación

Habitaciones-Temporada-Régimen Estancia-PrecioHabitación

C En este caso nos interesa acceder desde unahabitación a su precio, eligiendo primero latemporada y el régimen de estancia.

Slices derivados de las relaciones complejasNo es necesario ningún cambio en ninguna de las tres relaciones. En la primera, ya quela entidad Alojamiento Servicio no tiene ningún atributo propio (provienen de larelación N:M) y por tanto no es necesario que le ceda ningún atributo a la entidadServicio Alojamientos. En la segunda y tercera, los slices head de Precio Habitación yHabitaciones, ya fueron definidos como híbridos y contienen los atributos necesariosque surgen de la relación.


Nota: nos es necesaria una nueva primitiva para representar el acceso condicionado atodos los elementos de una entidad a la vez. En este caso, si estamos en un alojamiento,con esta primitiva accedemos a todos sus alojamientos simultáneamente, todos a la vez,y no mediante un índice o uno tras otro en una visita guiada. Lo reflejaremos con lasiguiente primitiva y la llamaremos acceso simultáneo:



Ciudad

Alojamiento

TipoAlojamiento

Habitaciones

TipoHabitación

PrecioHabitación

RégimenEstancia

ServicioAlojamientos

Temporada

CategoríaAlojamientos

CadenaAlojamientos

AlojamientoMultimedia

TipoMultimedia

Alojamiento Servicio

NOTA: Para simplificar el diagrama, no se incluyen los accesos desde lasentidades Región, Provincia y Nación (los mismos que Ciudad)



6.4.3. Playas


Relación Tipo DescripciónPlaya-Playa Servicio-ServicioPlayas

B Se trata de una relación N:M y lo que interesa esacceder de una playa a los servicios de lamisma. En particular, deseamos ver todos losservicios a la vez.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que la entidad Playa Servicio no tiene ningúnatributo propio (provienen de la relación N:M).


Ciudad

Playa PlayaMultimedia

TipoPlaya

ServicioPlayas

Playa ServicioTipo

Multimedia




6.4.4. Deportes


Relación Tipo DescripciónInstalación deportiva-Instalación Servicio-ServicioDeportes

B Se trata de una relación N:M y lo que interesa esacceder de una instalación a los servicios de lamisma

Instalación Deportiva-Deporte Instalación- Deporte

B Se trata de una relación N:M y lo que interesa esacceder de una instalación deportiva a losdeportes que en ella se practican

Slices derivados de las relaciones complejasNo es necesario ningún cambio en la segunda relación, ya que la entidad InstalaciónServicio no tiene ningún atributo propio (provienen de la relación N:M).

En cambio sí lo es en el caso de Deporte Instalación, ya que es necesario ver la cantidad,por ejemplo la cantidad de pistas de tenis que hay en un polideportivo determinado. Paraello es necesario crear un nuevo slice en la entidad Deporte para que tenga en cuentaesta cantidad, y el acceso no se hará a través del slice head, sino de este slice nuevo.Pero como que la entidad Deporte sólo es accedida a través de este enlace, y no desdeningún otro lugar, se puede eliminar el slice head anterior y sustituirlo directamente poréste. Evidentemente, esto no sería conveniente si la entidad fuera accedida desde otrolugar.

DeporteHead (híbrido) Nombre

DescripciónDeporte Instalación.Cantidad




Ciudad

Instalacióndeportiva

InstalaciónMultimedia

Deporte Instalación

ServicioDeportes

InstalaciónServicio

Deporte

HorarioInstalación

DeporteMultimedia

TipoMultimedia






Relación Tipo DescripciónCiudad-Evento Ciudad-EventoCultural

B Se trata de una relación N:M y lo que interesaes acceder de una ciudad a todos sus eventosculturales.

Evento Cultural-EventoCiudad- Ciudad

B En este caso también nos interesa saber en quéciudades se da un evento cultural y podernavegar a ellas.

Se podría haber incluido también un acceso jerárquico de ciudad a representación, perose estimó que no era conveniente.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que la entidad Evento Ciudad no tiene ningúnatributo propio (provienen de la relación N:M).


TipoEvento

CentroCultural

Ciudad EventoCultural

Representación

EventosMultimedia

TipoMultimedia

Evento Ciudad

Evento Ciudad






Relación Tipo DescripciónMonumento-MonumentoServicio-Servicio Monumentos

B Se trata de una relación N:M y lo que interesaes acceder de un monumento a los serviciosdel mismo. En este caso nos interesa acceder atodos los servicios a la vez.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que la entidad Monumento Servicio no tiene ningúnatributo propio (provienen de la relación N:M).


Ciudad

Monumento

TipoMonumento

PeriodoHistórico

HorarioMonumento

ServicioMonumento

Monumento Servicio

MonumentoMultimedia

TipoMultimedia




6.4.7. Naturaleza


Relación Tipo DescripciónCiudad-Naturaleza Ciudad-Naturaleza

B Se trata de una relación N:M y lo que interesaes acceder de una ciudad a todas sus áreasnaturales.

Naturaleza -Naturaleza Ciudad-Ciudad

B En este caso también nos interesa saber a quéciudades pertenece un área natural y podernavegar a ellas.

Naturaleza-NaturalezaServicio-Servicio Natural

B Se trata de una relación N:M y lo que nosinteresa es ver todos los servicios de un áreanatural

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que tanto la entidad Naturaleza Ciudad comoNaturaleza Servicio no tiene ningún atributo propio (provienen en ambos casos de larelación N:M).


NaturalezaNaturalezaMultimedia

TipoNaturaleza

ServicioNatural

Ciudad

TipoMultimedia

Naturaleza Servicio

Naturaleza Ciudad Naturaleza Ciudad






En esta categoría no se observan nuevas estructuras navegacionales derivadas derelaciones complejas.


Ciudad

Entretenimiento EntretenimientoMultimedia

TipoEntretenimiento

HorarioEntretenimiento

TipoMultimedia




6.4.9. Restaurantes




Ciudad

Restaurante

RestauranteMultimedia

TipoRestaurantes

CategoríaRestaurante

HorarioRestaurante

TipoMultimedia




6.4.10. Rent-a-car



Tampoco aquí, como en alojamientos, las cadenas de rent-a-cars tienen interés turístico.


Ciudad

Rent-a-carCadenaRent-a-car

Rent-a-carMultimedia

HorarioRent-a-car

TipoMultimedia




6.4.11. Tienda



Igualmente se consideró que las cadenas de tiendas no tienen interés turístico y tampocomantendrán navegación con la entidad ciudad.


Ciudad

Tienda

TipoTienda

TiendaMultimedia

HorarioTienda

CadenaTiendas

TipoMultimedia






Relación Tipo DescripciónVuelo-Tipo Tarifa Aérea-Precio Vuelo

C Una vez seleccionado un vuelo lo que interesaconocer es lo que nos va a costar según el tipode tarifa que elijamos.

De nuevo se consideró que las compañías de transporte, igual que ocurrió con lascadenas de tiendas o de rent-a-cars, no tienen interés turístico y tampoco mantendránnavegación con la entidad ciudad.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que el nombre del tipo de tarifa ya está incluido en elslice head de Precio Vuelo, que ya fue definido como híbrido.




Ciudad

AeropuertoAeropuertoMultimedia

HorarioVueloCompañía

Transportes

Vuelo

Tipo TarifaAérea

PrecioVuelo


Ciudad

TipoMultimedia

TipoMultimedia






Relación Tipo DescripciónTrayecto-Tipo Pasaje-PrecioPasaje

C Una vez seleccionado un trayecto en barco loque interesa conocer es lo que nos va a costarsegún el tipo de pasaje que elijamos (camarote,butaca, vehículo turismo, ...).

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que el nombre del tipo de pasaje ya está incluido enel slice head de Precio Pasaje, que ya fue definido como híbrido.


Ciudad

PuertoPuerto

Multimedia

HorarioTrayecto


Trayecto

PrecioPasaje

TipoPasaje

Ciudad

TipoMultimedia


TipoMultimedia






Relación Tipo DescripciónEstación-Parada-Línea B Se trata de una relación N:M y lo que interesa

es acceder de una estación a las líneas quepasan por ella, con el fin de saber a donde sepuede llegar.

Línea-Parada-Estación B En este caso también nos interesa saber porqué estaciones pasa la línea seleccionada.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que la entidad Parada no tiene ningún atributo propio(provienen de la relación N:M).




Ciudad

EstaciónEstación

Multimedia

LíneaHorario

Tr. Terrestre


MedioTransporte

Ciudad


TipoMultimedia

TipoMultimedia

Parada

Parada






Relación Tipo DescripciónParada Urbana-Parada Línea-Línea Urbana

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a las líneasque pasan por ella, con el fin de saber a dondese puede llegar.

Línea Urbana-Parada Línea-Parada Urbana

B En este caso también nos interesa saber porqué paradas pasa la línea seleccionada.

Parada Urbana-ParadaAlojamiento-Alojamiento

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a losalojamientos cercanos a ella.

Alojamiento-ParadaAlojamiento-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un alojamiento

Parada Urbana-Parada Playa-Playa

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana las playascercanas a ella.

Playa-Parada Playa-ParadaUrbana

B En este caso también nos interesa saber quéparadas hay cercanas a una playa

Parada Urbana-ParadaInstalación-InstalaciónDeportiva

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a lasinstalaciones deportivas cercanas a ella.

Instalación Deportiva-ParadaInstalación-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a una instalacióndeportiva

Parada Urbana-Parada Museo-Museo

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a los museoscercanos a ella.

Museo-Parada Museo-ParadaUrbana

B En este caso también nos interesa saber quéparadas hay cercanas a un museo

Parada Urbana-ParadaNaturaleza- Naturaleza

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a las áreasnaturales cercanas a ella.

Naturaleza-Parada Naturaleza-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un área natural

Parada Urbana-ParadaEntretenim.- Entretenim.

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a losentretenimientos cercanos a ella.

Entretenim.-ParadaEntretenim.-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un entretenimiento

Parada Urbana-ParadaRestaurante- Restaurante

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a losrestaurantes cercanos a ella.

Restaurante-ParadaRestaurante-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un restaurante

Parada Urbana-Parada Rent-a- B Se trata de una relación N:M y lo que interesa



car- Rent-a-car es acceder de una parada urbana a los rent-a-cars cercanos a ella.

Rent-a-car-Parada Rent-a-car-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un rent-a-car

Parada Urbana-Parada Tienda-Tienda

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a las tiendascercanas a ella.

Tienda-Parada Tienda-ParadaUrbana

B En este caso también nos interesa saber quéparadas hay cercanas a una tienda

Parada Urbana-ParadaAeropuerto- Aeropuerto

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a losaeropuertos (difícilmente habrá más de uno)cercanos a ella.

Aeropuerto-Parada Aeropuerto-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un aeropuerto

Parada Urbana-Parada Puerto-Puerto

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a los puertos(difícilmente habrá más de uno) cercanos aella.

Puerto-Parada Puerto-ParadaUrbana

B En este caso también nos interesa saber quéparadas hay cercanas a un puerto

Parada Urbana-ParadaEstación- Estación

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a lasestaciones cercanas a ella.

Estación-Parada Estación-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a una estación

Parada Urbana-ParadaInformación- Información

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a los puntosde información turística cercanos a ella.

Información-ParadaInformación-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a un punto deinformación turística

Parada Urbana-ParadaAgencia- Agencia

B Se trata de una relación N:M y lo que interesaes acceder de una parada urbana a las agenciascercanas a ella.

Agencia-Parada Agencia-Parada Urbana

B En este caso también nos interesa saber quéparadas hay cercanas a una agencia

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que en todas las entidades intermedias de larelaciones, ninguna de ellas tiene ningún atributo propio (todos provienen de la relaciónN:M).




Ciudad

LíneaUrbana

HorarioUrbano



ParadaLínea

ParadaLínea

TipoMultimedia

Ciudad

AlojamientoP. Alojamiento

Playa

Instalac.Deportiva

Museo

Naturaleza

P. Alojamiento

ParadaUrbana

P. Playa

P. Playa

P. Instalac.

P. Instalac.

P. Museo

P. Museo

P. Naturaleza

P. Naturaleza

Entretenim.P. Entertenim.

Restaurante

Rent-a-car

Tienda

Aeropuerto

P. Entretenim.

P. Resturante

P. Resturante

P. Rent-a-car

P. Rent-a-car

P. Tienda

P. Tienda

P. Aeropuerto

P. Aeropuerto

Puerto

Estación

Información

Agencia

P. Puerto

P. Puerto

P. Estación

P. Estación

P. Información

P. Infromación

P. Agencia

P. Agencia




6.4.16. Taxis


Esta categoría se refiere a paradas de taxis. Su estructura es la más simple: sólo estárelacionada con la ciudad, ni siquiera tienen sentido objetos multimedia.


Ciudad

Taxi






Relación Tipo DescripciónOferta Promocional-RégimenEstancia-Precio Oferta

C Una vez seleccionado una oferta lo que interesaconocer es lo que nos va a costar según el tipode régimen de estancia que elijamos.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que el slice head de Precio Oferta, ya fue definidocomo híbrido y contiene la información necesaria de las otras entidades.


OfertaPromocional

CadenaAg. Viajes

Alojamiento

RégimenEstancia

PrecioOferta

Ciudad




6.4.18. Excursiones


Relación Tipo DescripciónCiudad-Excursión Ciudad-Excursión

B Se trata de una relación N:M y lo que interesaes acceder de una ciudad a todas excursiones.

Excursión-Excursión Ciudad-Ciudad

B En este caso también nos interesa saber porqué ciudades (municipios) discurre unaexcursión y así poder navegar a ellas.

Slices derivados de las relaciones complejasNo es necesario ningún cambio, ya que la entidad Excursión Ciudad no tiene ningúnatributo propio (provienen de la relación N:M).


MedioTransporte

Excursión

ExcursiónMultimedia

Ciudad

Excursión Ciudad Excursión Ciudad

TipoMultimedia








Ciudad

Información

HorarioInformación








AgenciaViajes

CadenaAg. Viajes

Ciudad

Cadena A.V.Multimedia

HorarioAgencia

TipoMultimedia




6.4.21. Jerarquía de menús

En el menú principal se permite el acceso a los cuatro niveles de áreas geográficas.Además, una quinta opción permite acceder a índices por categorías. Esta opción noslleva a un nuevo menú donde se accede mediante índice a cada una de las categorías delsistema. Con ello se permite la búsqueda rápida a un elemento ya conocido, sinnecesidad de tener que ir a su área geográfica, con la consiguiente ganancia de tiempo.

Veamos el diagrama:



Entretenimiento

Monumento

InstalaciónDeportiva

Alojamiento

Restaurante

Ren-a-car

Naturaleza

EventoCultural

Playa

Taxi

Estación

Aeropuerto

OfertaPromocional

Excursión

LíneaUrbana

Puerto

Tienda

Información

AgenciaViajes

Nación Región Provincia Ciudad



6.5. Etapas 4 a 7: Interfaz de usuario y construcción

A pesar de que nuestro modelo no llegó a ser implementado y el proyecto europeo tomóotras soluciones, presentamos aquí las ideas que teníamos par las posteriores etapas:

Etapa 4: Diseño de protocolos de conversión

MINTour utiliza la base de datos Oracle. Por tanto, los protocolos de conversión sonmuy simples: cada entidad da lugar a una tabla. Cada slice se obtiene a partir de unavista, y los mecanismos de acceso no son más que sentencias de consulta a la base dedatos utilizando SQL (en concreto PL-SQL).

Etapa 5: Diseño de la interfaz de usuario

La idea del diseño de la interfaz era bastante simple, basada en la idea base que se dio alcomentar esta etapa en el apartado de mejoras a la metodología 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 información correspondiente a un slice deun elemento de una entidad. Otra, en un costado o abajo, contiene según los accesosobtenidos del modelo RMDM, los enlaces HTML a otras entidades. Cada uno de esosenlaces está representado con un texto (por ejemplo: Alojamientos) o con un icono. Enun tercer frame, más pequeño, aparecen los enlaces estructurales, es decir, cómo ir delslice que está en pantalla a los otros slices de esa entidad. Por último, es necesario unúltimo frame para los mecanismos generales de navegación, tales como volver al menú,volver a la última pantalla, ... Nótese que en vez de utilizar frames también puedenemplearse tablas, según las preferencias del diseñador, ya que el objetivo de dividir lapantalla en diferentes zonas se puede conseguir también 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 análisis. En el frame principal, el que defondo blanco, aparece la información 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 semuestran todos sus atributos. En la parte superior de este frame, aparecen en unrecuadro negro los slices de la entidad, que es el de información (el head), que estáactivo, y el de mapa. Al pulsar se iría a dicho slice. Nótese que también estánrepresentados los hiperenlaces a las entidades Ciudad, Provincia, Región, Nación, Tipode Monumento y Periodo Histórico, algunos enlaces directos y como el caso deProvincia, Región, Nación inferidos de la relación jerárquica.

En la parte izquierda tenemos dos frames diferentes, uno el de la navegación a otrasentidades, que nos permite ir a ver los elementos multimedia, servicios, horarios yparada de transporte urbano más cercano. Por último, en el frame inferior derechotenemos las herramientas de navegación general, como son en este caso volver al índicede monumentos de Palma, volver atrás en la navegación e ir a la home page.



Etapa 6: Diseño del comportamiento en tiempo de ejecución

En esta etapa se debían diseñar los algoritmos y programas para el control de lanavegación, mecanismo de historia, etc. En MINTour se utilizan CGIs utilizando elproducto Oracle WebServer, que permite una conexión entre el servidor web y la basede datos. Para ello se utiliza el lenguaje de programación PL-SQL, que es una versiónprocedimental, propia de Oracle, de SQL, el lenguaje estándar de acceso a bases dedatos.

Etapa 7: Construcción y tests

Dado que la aplicación basada en nuestro modelo no ha llegado a implementarse, estaetapa no merece ningún comentario.



6.6. Conclusiones

Este análisis, al tratarse de un proyecto tan grande, con tantas entidades y relaciones, nosha sido de gran utilidad a la hora de descubrir nuevos patrones de navegación, y fue labase para las mejoras a la metodología RMM que propusimos en el apartado 4.3. Alfinal 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 navegación,más consistente e intuitivo que el existente. De hecho, el proyecto europeo dejó de ladola línea de un proyecto multimedia, para convertirse en un simple recuperador deinformación de la base de datos, sin ninguna navegación posible entre sus elementos. Encambio nuestra solución daría lugar a un sistema en el cual el usuario navegaría, igualque podría navegar virtualmente por Europa, en vez de hacer una consulta tras otra,definiendo complicadas búsquedas a la base de datos. Desde nuestro punto de vista, éstaes la diferencia fundamental entre una aplicación multimedia-hipermedia y una degestión: en la primera lo importante es la navegación y en la segunda la recuperaciónexacta de los datos que el usuario desea. Pero, pensamos que la situación es que elusuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entraren el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas quetienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de unatienda y ofrecen visitas guiadas.

En cuanto a la estructura de los datos, las relaciones entre unas categorías y otras hanresultado ser bastante poco abundantes. El hecho de que las categorías no estén apenasrelacionadas entre sí viene determinado por la estructura de la información de MINTour,muy jerarquizada, donde prácticamente toda la información son diferentes elementosturísticos de una ciudad. Es por ello que cada una de las categorías está relacionada conlas áreas geográficas, pero no entre sí, salvo alguna excepción como la de los transportesurbanos. En el siguiente caso de estudio, el CD-ROM del Atles de les Illes Balears, laestructura de la información es bien diferente, mucho más rica, con muchas más inter-relaciones entre los datos, y se presta mejor a un análisis navegacional.

Resumen de las nuevas aportaciones a la metodología

El análisis de MINTour nos ha servido para añadir una serie de mejoras a lametodología RMM, que ya fueron explicadas en el capítulo IV.

Se trata de los accesos complejos, que recordemos del capítulo IV, podían ser de trestipos:

• navegación jerárquica: permiten acceder desde una entidad directamente a otraentidad que está relacionada con una entidad que está por debajo de la jerarquíade la primera. Por ejemplo, permite acceder a los alojamientos de una provincia,ya que alojamiento está relacionado con ciudad, y éste es jerárquicamenteinferior a provincia.



• navegación en relaciones N:M: permite navegar de un extremo al otro de unarelación N:M sin perder los datos de la entidad intermedia. Por ejemplo permiteacceder directamente de una playa a sus servicios.

• navegación múltiple: permite el acceso múltiple de una entidad a otra,seleccionando un elemento de una tercera entidad de la que la entidad destino esparte. Por ejemplo permite que dado un vuelo, podamos elegir un tipo de tarifa yacceder a su precio.

También se introdujo la primitiva de acceso simultáneo, que permite acceder a todos loselementos simultáneamente de una entidad con la que se está relacionado. Por ejemplo,si estamos en un alojamiento, con esta primitiva accedemos a todos sus alojamientossimultáneamente, todos a la vez, y no mediante un índice o uno tras otro en una visitaguiada. Lo reflejaremos con la siguiente primitiva:

Y para terminar, hay que notar la novedad que supone dividir el problema en diferentescategorías o temas, de manera que los modelos sean legibles. Al final, todo quedainterconectado desde la jerarquía de menús, así como a través de algunos enlaces queexisten entre entidades de diferentes categorías, como pueda ser el caso de las paradasde transportes urbanos. En este caso ha sido bastante simple, pero dividir un granproblema en temas puede ser una tarea compleja.

Una metodología relacional hipermedia. Estudio en casos prácticos VII - Atles de les Illes Balears


Capítulo VII3er 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 enel cual el proyectista ha trabajado desde el inicio al final. El objetivo era el de crear unatlas multimedia de las Islas, destinado a las escuelas de secundaria de Baleares. La granvariedad y riqueza de la información contenida hacían imprescindible que antes decomenzar la implementación se llevase a cabo una etapa de análisis de la estructura y lanavegación. Para ello, una vez más utilizamos la metodología RMM, con las mejorasque ya se han comentado, puesto que el modelo relacional, como veremos, se ajustaperfectamente a nuestras necesidades.

En el primer apartado veremos la descripción de qué es el CD-ROM del Atles de lesIlles Balears, en el segundo una primera aproximación al caso de estudio, que fue labase de un prototipo cuyas conclusiones dieron lugar al análisis definitivo que sepresenta en el apartado tercero. Y como siempre, el capítulo se cierra con el apartado deconclusiones.

7.1. Qué es el Atles de les Illes Balears

Para una descripción de lo que es y supone este proyecto, reproducimos íntegramente elprólogo 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 multimediaque se publica en nuestra comunidad autónoma.

Constituye una aportación destacada al conocimiento geográfico del territorioinsular i recoge parte del trabajo encargado por la Direcció General d'Educació,realizado en soporte tradicional y editado el 1995, bajo el mismo título.

Este atlas es una contribución importante i innovadora a la producciónbibliográfica y de materiales didácticos que se promueve desde la Conselleriad'Educació, Cultura i Esports del Govern Balear y desde «Sa Nostra» Caixa deBalears, para construir un currículum propio sobre el medio y las cienciassociales en las Islas, una vez que se han conseguido totalmente las transferenciaseducativas. En esta obra, de carácter geográfico, se analizan las característicasfísicas y humanas del territorio insular, es decir, tanto el medio como lasinterrelaciones económicas, sociales y culturales, entre otras, que se generan apartir de la huella humana.

El CD-ROM Atles de les Illes Balears constituye una herramienta didácticaversátil que se utiliza en distintos niveles educativos. Puede ser plenamenteutilizado en la universidad, así como en distintos cursos de enseñanzasecundaria, por parte del alumno o como material de trabajo para el profesor, yaque a la mayoría de temas se llega a un nivel de profundidad bastante elevado.



Un trabajo como este ha requerido un equipo interdisciplinar que conjugase laautora, con el tratamiento cartográfico y la implementación multimedia. Larealización ha ido a cargo de un conjunto de especialistas de la Universitat de lesIlles Balears que cuentan con experiencia, tanto en el trabajo de textosdidácticos, con mapas y sin, como en otros CD-ROM, entre los cuales hay quecitar los encargados por el Govern (ParcBIT, 1994) i también por «Sa Nostra»Caixa de Balears (S'Albufera, 1995).

La utilización de materiales multimedia tales como este atlas permite a losestudiantes y a los ciudadanos de las Baleares en general, no sólo conocer mejornuestras islas, sino también contribuir al hecho de que sea mucho más fácilpoderlo hacer. El CD-ROM Atles de les Illes Balears podrá ayudar, sin duda, avalorar y querer más a nuestra tierra y nuestra cultura. »



7.2. Primer estudio del caso

En un primer estudio, nos centraremos en lo que nosotros consideramos como lo quehubiera sido la situación ideal. Un prototipo basado en esta situación ideal fuepresentado a las otras dos partes que participaban en el proyecto, autores y cartografíadigital, y se extrajeron las conclusiones que dieron pie al segundo y definitivo análisis.Veamos a continuación las tres primeras fases de la metodología, además de la etapaprevia de análisis de requerimientos, clave en este proyecto.

7.2.1. Etapa 0: análisis de requerimientos

En el proyecto, por el contrato firmado, se impuso un requerimiento, que el CD-ROMdebía poder utilizarse tanto en ordenadores PC con Microsoft Windows 95 como enordenadores Apple Macintosh. Se trata, sin embargo de un requerimiento que nocondiciona para nada el desarrollo del proyecto.

Sin embargo, desde un primer momento, el grupo de Multimedia del Dept. deMatemàtiques i Informàtica, decidimos el utilizar una interfaz de tipo web. Las razonesfundamentales fueron tres:

• Tras el estudio de varios atlas multimedia publicados por grandes compañíascomprendimos que la principal carencia que ofrecían era la imposibilidad decomparar dos mapas. En realidad eso es fruto de trabajar con una únicapantalla sobre la cual se ha de mostrar toda la información. Al mostrar otrainformación, como un texto, una foto u otro mapa, se pierde la informaciónque estábamos visionando, y muy a menudo nuestro punto en la navegación.La decisión de utilizar un entorno web permite fácilmente trabajar con variasventanas de modo que es viable el ver varias informaciones simultáneamente.Ésta fue la principal razón que nos hizo decantarnos por esta opción.

• También fue importante el hecho de que desarrollar un CD-ROM con unainterfaz web suponía una novedad en aquel momento, y no se debe olvidar elcarácter de investigación que debe tener una universidad. Nuevasconclusiones respecto a interfaces y programación se podrían extraer de ello.

• Mucha gente ya está habituada a la navegación por Internet, lo cual incidedirectamente en una mayor facilidad de aprendizaje del producto.

Así pues, esta decisión conlleva una serie de restricciones:

• La aplicación, para su visualización, necesita de un navegador. La aplicacióndebe funcionar en los dos navegadores más utilizados en el momento, que sonel Netscape Navigator y el Microsoft Explorer, ambos tanto para Macintoshcomo para Windows 95. Se especificó que la versión mínima de dichosnavegadores sería la 4, aunque finalmente se consiguió también que laaplicación funcione en la versión 3 del Netscape Navigator (no así en la deMicrosoft Explorer debido a sus carencias propias).



• Los lenguajes de programación que se deberán utilizar son HTML yJavaScript. Se desestimó el uso generalizado de Java, ya que presentanumerosos problemas de una interfaz muy inestable y dependiente de laplataforma (el mismo applet se ve de forma diferente según el navegador y lamáquina). Sólo un applet para una aplicación didáctica muy concreta fueutilizado, testeando que funcionase correctamente en todas las plataformasrequeridas.

• Se decide que se deben incorporar modelos en tres dimensiones de las Islas.Para ello se utilizará VRML versión 2.

• El hecho que la aplicación 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 sino es desde un servidor web, lo cual no es posible desde un CD. Ello nosobliga a trasladar toda la estructura relacional a una estructura de directorios,si bien hace bastante más compleja tanto la programación como laintroducción de datos, y en particular la confección de índices (hay índices detodos los mapas, todos los textos, todos las tablas, ...) se deberá hacermanualmente.

7.2.2. Etapa 1: Diseño Entidad-Relación

El entidad central del modelo es la entidad “Nodo”. Un nodo corresponde a un temaconcreto aplicado a un área geográfica concreta. Por ejemplo, transportes marítimos enMenorca. Tanto los temas, como las áreas están jerarquizadas.

Relacionado con ese nodo es donde hay una gran cantidad de información: entradas delglosario, citas bibliográficas, preguntas del tipo sabías que ... ?, mapas, gráficos, textos,tablas y elementos multimedia.

Cada mapa está compuesto de varias capas, extraídas directamente del sistema deinformación geográfica (SIG o GIS en inglés). Y cada una de esas capas puede tenerunos topónimos asociados, unos elementos de leyenda (que a su vez pueden estarasociados a una definición, que también puede tener elementos multimedia), y se lepuede aplicar varios zooms. Igualmente un gráfico también tiene una serie de elementosde leyenda, con su posible definición, y unos zooms.



ÁreaGeográfica

Nodo

Tema

NivelTema

NodoMultimedia

Sabías que

Multimedia

Zoom

TablaGráfico

El. Leyenda Gráfico

Mapa

Capa

Texto

TipoMultimedia

NivelÁrea

GráficoZoom

ElementoLeyenda

CapaZoom

Definición

TopónimoMultimedia

TopónimoCapa

Topónimo

Distancia

DefiniciónMultimedia

Multimedia

EntradaGlosario

Cita Bibliografía

Nodo/Glosario

Nodo/Bibliografía

Nodo/Sabías

7.2.3. Etapa 2: Diseño de slices

Dado que sólo se trataba de un primer análisis no profundizamos en exceso en el diseñode los slices. En realidad cada entidad no tiene más que un slice con toda la informacióncorrespondiente.



7.2.4. Etapa 3: Diseño navegacional


Relación Tipo DescripciónNodo-Nodo Multimedia-Multimedia

B Lo que deseamos es poder acceder a loselementos multimedia de un nodo determinado.

Multimedia-NodoMultimedia-Nodo

B Puede ser útil poder acceder a los nodos en losque aparece el elemento multimedia queestamos viendo.

Nodo-Nodo Sabías-Sabíasque

B Lo que deseamos es poder acceder a laspreguntas tipo sabías que...? de un nododeterminado.

Nodo-Nodo Glosario-Elemento Glosario

B Lo que deseamos es poder acceder a las palabrasdel glosario de un nodo determinado.

Nodo-Nodo Bibliografía-CitaBibliografía

B Lo que deseamos es poder acceder a las citasbibliográficas de un nodo determinado.

Topónimo-TopónimoMultimedia-Multimedia

B Lo que deseamos es poder acceder a loselementos multimedia de un topónimodeterminado.

Multimedia- TopónimoMultimedia- Topónimo

B Puede ser útil poder acceder a los topónimos enlos que aparece el elemento multimedia queestamos viendo.

Topónimo- Topónimo Capa-Capa

B Lo que deseamos es poder acceder a lostopónimos de una capa determinada.

Capa- Topónimo Capa-Topónimo

B Puede ser útil poder acceder a las capas en lasque aparece el topónimo que estamos viendo.

Definición- DefiniciónMultimedia-Multimedia

B Lo que deseamos es poder acceder a loselementos multimedia de una definicióndeterminada.

Multimedia- DefiniciónMultimedia- Definición

B Puede ser útil poder acceder a las Definicionesen los que aparece el elemento multimedia queestamos viendo.

Capa-Zoom-Capa Zoom C Lo que deseamos es que a partir de la capa queestamos viendo, podamos elegir los zoomsdisponibles y ver la capa a ese zoom (ver elobjeto correspondiente de la entidad CapaZoom)

Gráfico-Zoom-Gráfico Zoom C ídemTopónimo-Topónimo-Distancia

C Queremos que, al ver un topónimo, podamoselegir otro y ver la distancia que los separa.




ÁreaGeográfica

Nodo

Tema

NivelTema

Sabías que

Multimedia

Zoom

TablaGráfico

El. Leyenda Gráfico

Mapa

Capa

Texto

TipoMultimedia

NivelÁrea

GráficoZoom

ElementoLeyenda

Definición

Topónimo

Distancia

Multimedia

Nodo Multimedia

Nodo Multimedia

Def. Multimedia

Def. Multimedia

CapaZoom

Topónimo Capa

Topónimo Capa

Topónimo Capa Topónimo Capa

Nodo/Sabías

Nodo/Glosario

Nodo/Bibliografía

ElementoGlosario

CitaBibliografía



7.3. Segundo (y definitivo) estudio del caso

Un prototipo basado en la estructura anterior fue discutido con el Departamento deGeografía, y se tomaron una serie de decisiones, algunas marcadas por los aspectostecnológicos de los sistemas de información geográfica, que hicieron variardrásticamente el modelo anterior. Aquí se detallan esos cambios, fruto de talesdiscusiones:

• Tanto los mapas como los gráficos se tratan como imágenes simples, en formatosbitmap como GIF o JPEG. Esto conlleva que ya no hay información de capas. Ladecisión vino marcada, tras varias pruebas, por la imposibilidad de manejar imágenescon formato vectorial en la plataforma en la que se debía ejecutar la aplicación (unnavegador web).

• Debido también a que los mapas y gráficos se consideran como una imagen y elloimpide su fácil modificación, se decide eliminar la información de zooms.

• Los topónimos dejan de estar relacionados directamente con el mapa, y en realidaddesaparecen de la estructura. A pesar de que hay un índice toponímico con cientos detopónimos de las Islas, el Dept. de Geografía decidió que no se tomaría enconsideración los topónimos que aparecen en un nodo, mapa, ...

• La información relacionada con glosario, bibliografía, sabías que, y elementosmultimedia diferentes de fotos (es decir, vídeos y panorámicas) deja de estarrelacionada con el nodo y pasa a ser del tema entero de nivel 2. Esto tiene unaexcepción: se permite un enlace entre términos importantes que aparezcan en el textode un nodo y su definición (en la entidad Entrada Glosario). Mientras que los sabíasque son propios de un tema concreto, los demás pueden darse en varios.

• En cuanto al material multimedia, se decidió hacer una distinción entre fotos por unlado y vídeos y panorámicas por el otro. Las fotos están asociadas a un temaconcreto en una escala concreta, mientras que los vídeos y panorámicas, al sermucho más genéricos, se asocian al tema de segundo nivel.

• Se establece que la navegación principal deberá ser temática y no de escala. Es decir,que el usuario navegará por los temas, y una vez seleccionado éste, podrá ver todoslos nodos referentes a cada una de las áreas geográficas disponibles para ese tema.Estas áreas geográficas varían según el tema, siendo lo más corriente que aparezcanlos niveles de archipiélago e isla, pero que en determinadas ocasiones alcanza hastanivel comarcal y municipal.

• En cuanto a la estructura temática, la dirección del proyecto, fija que se establecerántres niveles diferentes de jerarquía:

1. El primer nivel: los tres grandes bloques geográficos: geografía física, geografía

humana y por último mapa topográfico y tradición cartográfica. Si bien esdiferente, se decidió considerar como un cuarto bloque a la presentación delatlas.



2. El segundo nivel establece los temas en que se subdividen los anteriores. Hay

tres temas para el bloque de mapa topográfico y tradición cartográfica, y cincopara los otros dos. Para cada uno de estos temas se confeccionará una visitaguiada, que es una secuencia de pantallas que muestran qué es lo más importanteque el alumno se encontrará en dicho tema.

3. Por último aparecen los subtemas de los anteriores, donde ya nos encontramos la

información propiamente dicha, con textos, mapas, tablas, gráficos y fotos. Lainformación de este nivel de temas está a su vez estructurados en tantos nivelescomo al autor estime oportuno (si bien se recomendó sólo llegar hasta un cuartonivel de profundidad, algunos autores utilizaron hasta un sexto).

7.3.1. Etapa 0: análisis de requerimientos

Los requerimientos del sistema se mantienen y son los expuestos en el primer análisis.

7.3.2. Etapa 1: Diseño Entidad-Relación

Éste es el modelo entidad-relación que se confecciona a partir de las nuevasespecificaciones:



Sabías que

CitaBibliografía

TablaGráficoMapaTexto

Topónimo

TemaNivel 1

TemaInformación

EntradaGlosario

ElementoMultimedia

Tema/Bibliografía

Tema/Glosario

Tema/Multimedia

TemaNivel 2

TipoMultimedia

NodoVisita Guiada

ÁreaGeográfica

NivelÁrea

Foto

Tabla/NodoGráfico/NodoMapa/NodoTexto/Nodo Foto/Nodo

NodoInformación

ElementoLeyenda

Leyenda/Mapa

Definición

7.3.3. Etapa 2: Diseño de slices

Para mantener una navegación más sencilla se confirma que cada entidad tendrá sólo unslice con toda su información.



7.3.4. Etapa 3: Diseño navegacional


Relación Tipo DescripciónTema Nivel 2-TemaInformación-NodoInformación

A En realidad aquí lo que nos interesa no esacceder directamente al nodo desde el tema denivel 2, sino permitir que desde el nodo sepueda volver al tema de nivel 2, ya que desdeahí se puede acceder a sabías que, glosario,bibliografía y elementos multimedia.

Tema Nivel 2-Tema /Glosario-Elemento Glosario

B Lo que deseamos es poder acceder a las palabrasdel glosario de un tema determinado.

Tema Nivel 2-Tema /Bibliografía-Cita Bibliografía

B ídem

Tema Nivel 2-Tema /Multimedia-ElementoMultimedia

B ídem.

Nodo Información-Nodo /Texto-Texto

B Lo que deseamos es poder acceder a los textosde un nodo de información determinado.

Nodo Información-Nodo /Mapa-Mapa

B ídem

Nodo Información-Nodo /Gráfico-Gráfico

B ídem

Nodo Información-Nodo /Tabla-Tabla

B ídem

Nodo Información-Nodo /Foto-Foto

B ídem

Mapa-Leyenda Mapa-Elemento Leyenda

B Lo que interesa es acceder a los elementos deleyenda de un mapa, para formar la leyenda.

Tema Información-ÁreaGeográfica-NodoInformación

C La navegación principal es la temática. De talmodo, lo que deseamos es que una vez en untema, podamos ver la lista de áreas geográficasen que ese tema es aplicable y ver trasseleccionar uno, ver su información (el nodo).


Nota: nos es necesaria una nueva primitiva para representar el acceso a un elementoaleatoriamente. En este caso concreto, dado un tema de nivel 2, accederemos a uno desus sabías que, de forma aleatoria, sin saber exactamente a cuál. Lo haremos con lasiguiente primitiva y la llamaremos acceso aleatorio:



Sabías que

CitaBibliografía


Topónimo

TemaNivel 1

TemaInformación

EntradaGlosario

ElementoMultimedia

TemaNivel 2

TipoMultimedia

NodoVisita Guiada

ÁreaGeográfica

NivelÁrea

Foto

NodoInformación

ElementoLeyenda

Definición

Tema/Bibliografía

Tema/Glosario

Tema/Multimedia

Texto/Nodo Mapa/Nodo Gráfico/Nodo Tabla/Nodo Foto/Nodo

Leyenda/Mapa

Estructura de menús

La estructura de menús se divide en dos ramas principales. Por un lado el acceso a temasy por el otro el acceso a índices. En cuanto al primero se accede mediante un índice a laentidad “Tema Nivel 1”. En el segundo caso se accederá a otro menú donde se tendránlas opciones de índice de textos, de mapas, de gráficos, de tablas, de fotos, de elementosmultimedia, glosario, bibliografía, índice toponímico y índice temático (simplemente unfichero donde se incluye todo el índice completo).



No lo integraremos en el diagrama anterior porque sería imposible de leer, ya que desdeel menú de índices se accede a un gran número de entidades, pero lo veremos asírepresentado:


Topónimo

TemaNivel 1

Foto

CitaBibliografía

EntradaGlosario

ElementoMultimedia

TemaNivel 2

7.3.5. Etapa 4: Diseño de protocolos de conversión

Recordemos de la etapa 0, análisis de requerimientos, que el hecho de ser una aplicaciónweb que ha de ser ejecutada sobre CD-ROM imponía la restricción de la imposibilidadde trabajar con bases de datos. Para sustituir la base de datos se tuvo que diseñar unaestructura de directorios con el fin de ordenar los aproximadamente dos mil archivos dematerial. Exponemos a continuación las reglas que se siguieron:

Cada tema tiene un directorio, estructurados jerárquicamente. Cada uno de los trestemas de nivel 1, tiene un directorio, denominado 1, 2 y 3, respectivamente. Cada unode los temas de nivel 2 tendrá su directorio dentro de su de tema de nivel 1. Por ejemploen el directorio 2 habrá los subdirectorios 21, 22, 23, 24 y 25, para cada uno de los cincotemas que existen. Y lo mismo ocurre con los temas de información (niveles 3 y 4).

La pertenencia de un texto, tabla, mapa, ..., a un tema es obvia: incluyéndolo en eldirectorio del tema correspondiente. Lo mismo ocurre con elementos de glosario, citasbibliográficas, sabías que y elementos multimedia, que serán todos incluidos en el



directorio de segundo nivel. En el caso de los sabías que, se incluye un archivo paracada uno, mientras que en el caso de los demás lo que se incluye en un único archivocon referencias. El mismo caso que los sabías que es el de los nodos de visita guiada deun tema de nivel 2.

Cada elemento, además de pertenecer a un directorio concreto de tema, está codificadosiguiendo una regla.

• La primera letra indica el tipo de elemento de que se trata (se utilizan dosletras para los elementos de nivel 2):

En el caso de elementos de nivel 2Glosario GL

Bibliografía BG

Multimedia MM

Sabías que SQ

Visita guiada VG

En el caso de elementos de información (niveles 3 y 4)

Texto T

Mapa M

Leyenda L

Tabla U

Gráfico G

Foto F

• A continuación de esta letra, el tema (por ejemplo 2543).

• A continuación el área geográfica asociada (por ejemplo B de Baleares).

• Por último, si hay más de un elemento de ese tipo, para ese nodo, se indica el

número de secuencia.

7.3.6. Etapa 5: Diseño de la interfaz de usuario

Si bien esta etapa es labor de un diseñador gráfico, en nuestro caso Antonio FernándezCoca, una buena estructura navegacional será de gran utilidad para la confección de lainterfaz de usuario coherente e intuitiva. A continuación se describe la interfaz y suprofunda relación con la estructura:



Al entrar en la aplicación aparece una ventana a la izquierda, donde tenemos cincobloques en los que se estructura el atlas. Nosotros únicamente nos centramos en los dosprimeros (temas e índices) que son los relacionados con la estructura. Los demásbloques corresponden a aplicaciones didácticas (como por ejemplo, juegos), ayuda ycréditos. Así pues, vemos en la imagen el menú principal del modelo en el que se elegíaentre ir al menú de temas o al de índices:

Al pulsar en el botón “Temes” (más adelante veremos la opción “Índexs”) entramos enel 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:



Al seleccionar uno, se despliega el índice condicionado de los temas de nivel 2, comovemos 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 también la barra deherramientas, sobre la que volveremos a hablar, y en la que se pueden apreciarlos botones “+” y “-” para avanzar y retroceder, respectivamente, dentro de lavisita guiada.

• En la segunda, aparece el índice condicionado de los temas de información.

Lo vemos en la imagen:



Al elegir uno de esos temas de información, se accede al “nodo de información”, que secargará en la ventana central. Aparece no sólo el título del nodo, sino que toda lainformación de textos, mapas, leyendas, gráficos, tablas y fotos relacionada con dichonodo. Es un acceso del tipo “todos a la vez”. Lo apreciamos en la imagen. El diseñadordecidió que se debía permitir visualizar inmediatamente estos elementos, sin necesidadde tener que pulsar ningún otro botón . No obstante en la barra de herramientas sepermite acceder individualmente a cada una de las entidades mapa, leyenda, gráficos,tablas y mapas (también decidió que fotos no era necesario).



En este punto es interesante estudiar la barra de herramientas. En la imagen se ve cómoésta está dividida en tres secciones, claramente diferenciadas:

• En la primera sección, comenzando por la izquierda, botones 10 y 11,tenemos la navegación para la visita guiada que cada tema de nivel 2 tiene(entidad “nodo de visita guiada”). En el momento en que se accede a losnodos de información esta sección queda inhabilitada.



• En la segunda tenemos la navegación que nosotros denominamos global, encontraposición de la local, que veremos en la siguiente sección. En la filasuperior tenemos opciones generales de navegación como son la de volveratrás en la historia (botón 9), copiar esta ventana a otra nueva (8), ver/ocultarla venta de contenidos (temas de información) (7) y ver/ocultar másinformación si la hay (6). En las otras dos filas, además de imprimir (12), sepermite acceder a la entidad “tema de nivel 2” para poder acceder a sus sabíasque (13), elementos de glosario (16), multimedia (vídeos y panorámicas) (17)y bibliografía (15). Otro punto importante es que permite volver a seleccionarel área geográfica para acceder mediante el acceso múltiple a otro nodo deinformación, del mismo tema, pero de distinto lugar (menú desplegable 18).Por último hay un enlace al índice de topónimos (19) (no hay ningunarelación entre esos topónimos y el nodo; no se trata de un índice condicional).

• Mientras que en la segunda sección los enlaces eran a entidades que estabanpor encima en la estructura, es decir que surgían de la inferencia de la relaciónjerárquica, en esta tercera sección se accede a las entidades texto (botón 1),mapa (2), leyenda(4), gráfico(3) y tabla(3), utilizando acceso del tipo “todos ala vez”. Es decir se utilizan accesos condicionados, no inferidos, o lo que eslo mismo se acceden a elementos propios de este nodo, mientras que en elcaso anterior eran elementos propios del tema, y por tanto serán comunes entodos los nodos del mismo.

Nos queda ver cómo es la otra parte del menú principal, la que hace referencia a losíndices. Al pulsar la opción accedemos al siguiente menú de la jerarquía, como vemosen la imagen:



Desde aquí, eligiendo una opción se accede, mediante un índice, a la entidadcorrespondiente (mapa, texto, ...). Vemos en la imagen como aparece una nueva ventanacon el índice de una de estas entidades, la de gráficos concretamente, a la izquierda, y alelegir uno de ellos aparece en la parte derecha.

7.3.6.1. Conclusiones de esta etapa

En una situación ideal, todo el equipo que participa en el desarrollo debe conocerperfectamente la metodología, pero a menudo esto no ocurre, especialmente en el casodel personal no informático, que muchas veces es externo al grupo de desarrollo. Ésteera nuestro caso, y en concreto el diseñador gráfico no conocía la metodología.

En estos casos, se debe preparar cuidadosamente, a partir del modelo RMDM donde sedescriben todas las pantallas que la aplicación tendrá, una lista de todos los iconos yelementos gráficos que serán necesarios. Para hacer esto, nuestra línea de acción fue lade preparar un prototipo para que el diseñador viera la estructura de la aplicación y lossignificados de cada sección. A partir de esto, el diseñador propone la interfaz general,como son colores o imágenes de fondo, colores del texto, ..., generalmente diferentespara cada sección. El siguiente paso es integrarlo en el prototipo y confeccionar laanteriormente citada lista de elementos gráficos que son necesarios. En concreto yaexplicamos en los comentarios a las mejoras de RMM que nuestra propuesta es la deque por un lado haya un icono para cada uno de los accesos estructurales (internos a laentidad) y por otro, también un icono para todos los accesos navegacionales, ya seandirectos o inferidos. Todos deben ir acompañados de su significado. Así pues, a partir deesa lista y con la ayuda del segundo prototipo, el diseñador confecciona toda el conjuntode elementos gráficos de la aplicación. Nótese que la lista que se le entrega al diseñador



debería ser completada con los iconos que él ha asignado; esta lista es útil mantenerlapara posteriores mantenimientos.

Otro aspecto importante, es que si bien el modelo RMDM nos permite saber quéelementos aparecerán en cada pantalla de la aplicación, la interfaz aplicada directamentepuede ser excesivamente rígida. Es por tanto que se debe, no sólo permitir, sinoincentivar al diseñador a que encuentre la mejor manera de presentar la información,basándose en la estructura, es decir que defina cuál será la estructura definitiva de lapantalla. Por ejemplo, el hecho de que unos elementos aparezcan en una ventana y otrosen otra, y otros en el frame principal, es en última instancia responsabilidad deldiseñador. En este sentido, nuestro método de comunicación entre diseñador ydesarrolladores era el de imágenes con el layout que el diseñador proporcionaba. Quizápara un futuro, y para aplicación más grandes con equipos de desarrollo mayores, puedaser necesario profundizar en este aspecto.

7.3.7. Etapa 6: Diseño del comportamiento en tiempo de ejecución

En esta etapa se debían diseñar los algoritmos y programas para el control de lanavegación, mecanismo de historia, control de ventanas, etc. Para ello su programaciónse utilizó el lenguaje JavaScript.

Para obtener mayores detalles sobre esta etapa, referirse al proyecto de Daniel SotoÁlvarez, que se centra en la creación de un “esqueleto” para la realización deaplicaciones multimedia, especialmente centradas en el ámbito de Internet.

7.3.8. Etapa 7: Construcción y tests

Evidentemente, esta etapa no merece ningún comentario. Únicamente citar que laconstrucción de la aplicación corrió a cargo de Daniel Soto, Francesc Mateu y elproyectista, contando con la colaboración de numerosos compañeros en la integraciónde material multimedia.



7.4. Conclusiones

Como hemos podido observar, éste ha sido el caso de estudio en el que más se haprofundizado, sin duda porque ha sido en el que el proyectista ha tenido una mayorparticipación: en el primer caso, S’Albufera, sólo se pretendía hacer un análisis de unaaplicación ya hecha, con el fin de evaluarla. En el segundo, MINTour, el objetivo ya erael de hacer la aplicación completa a partir del análisis, pero por una serie de causasinternas al proyecto, la aplicación tomó otros derroteros. Pero en este tercer caso, sí sehan podido seguir todas las fases de la metodología hasta obtener la aplicación final.

Precisamente, como principal conclusión de este caso de estudio, consideramos quepodemos citar que se ha demostrado que sí es posible el hacer un desarrollo completo deuna aplicación siguiendo la metodología RMM, con una serie de mejoras que ya se hancomentado. No obstante, hay una serie de aspectos sobre los que se debería profundizar,especialmente en las fases posteriores al modelo RMDM, y básicamente en la fasequinta, Diseño de la interfaz de usuario, donde se interactúa directamente con eldiseñador gráfico, que a menudo no conoce nuestra metodología. En concreto, nosotroshemos incorporado a la metodología, la lista de los elementos gráficos así como unconjunto de layouts para representar la estructura de la pantalla, que ya se han sidocitados en las conclusiones acerca de la quinta etapa.

Para terminar, recordar que se ha introducido una nueva primitiva de acceso, la deacceso aleatorio, que permite acceder a los elementos de una entidad aleatoriamente. Lorepresentamos así:

Un ejemplo de su utilización es que dado un tema de nivel 2, accederemos a uno de sussabías que, de forma aleatoria, sin saber exactamente a cuál.

Una metodología relacional hipermedia. Estudio en casos prácticos VIII - Conclusiones


Capítulo VIIICONCLUSIONES

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 estándarpara comparar las características y funcionalidades de varios sistemas de hipertexto.También como una base sobre la cual desarrollar estándares para interoperabilidad eintercambio entre sistemas de hipertexto. Otro punto importante es el de proveer de unaterminología común al campo del hipertexto.

El modelo divide el sistema hipertexto en tres capas diferentes, como lo muestra lafigura:

Exponemos aquí, resumidos, los puntos clave del modelo:

• El concepto fundamental del modelo es el de componente, que es lo queconocemos típicamente como nodos (componentes compuestos), quecontienen fragmentos de texto, gráficos, animaciones, (componentesatómicos).

• La capa de almacenamiento se centra en estudiar los mecanismos por loscuales se unen los componentes y los enlaces, formando una especie de basede datos que almacena la jerarquía de componentes y los enlaces que losinterconectan.

• La capa del componente refleja los contenidos y estructura dentro de loscomponentes, y que al ser tan variados, Dexter no profundiza, dando libertaden este nivel.

• Una parte fundamental del modelo de Dexter es la interfaz entre las capa dealmacenamiento y la capa del componente. Se basa en el mecanismo deanclaje (anchoring).

capa de tiempo de ejecución(run-time layer)

capa de almacenamiento(storage layer)

capa del componente(within-component layer)

Especificaciones de presentación

Anclaje (anchoring)



• En cuanto a la capa de tiempo de ejecución, ésta provee al usuario de unasherramientas para acceder, ver y manipular la estructura de la red dehipertexto, sobre la cual Dexter apenas si ofrece unas ideas básicas, debido algran número de posibles herramientas para acceder, ver y manipular unhipertexto.

• Un punto importante es la interfaz entre esta capa y la capa dealmacenamiento, a la que llama especificaciones de presentación(presentation specifications). Ésta es un mecanismo que permite que la formaen que un componente se presenta al usuario pueda estar en función no sólode una herramienta de hipertexto específica (es decir, de una capa de tiempode ejecución específica), sino que puede ser una propiedad del componentepor sí mismo, del enlace tomado para llegar a tal componente o también de laspreferencias del usuario.

Dexter fue el primer intento de modelar el hipertexto y de dar una terminología comúnpara este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que sonhoy. De hecho, la principal carencia que se puede observar en este modelo es que, apesar de que los autores lo recomiendan para tanto hipertexto como hipermedia, noaborda en ningún momento la complejidad de los distintos medios. En realidad, sepodría decir que el modelo está fundamentalmente destinado a sólo hipertexto, y laaplicación a la hipermedia es muy difícil. Por ejemplo, el concepto de valor del ancla lohace en función de la posición del ancla en el texto, pero esto en otro medio no tienesentido. Más en concreto, no tiene en cuenta los aspectos relacionados con el tiempo,algo fundamental en el audio y el vídeo. Es por ello que posteriormente apareció elmodelo de Amsterdam, que basado en Dexter, añade el estudio del tiempo. Pero, a pesarde eso (no hay que olvidar que estos elementos eran imposibles de utilizar en 1988), elmodelo especifica, por primera vez y muy detalladamente, cómo es la estructura internade un hipertexto. Incluso define unas estructuras que no habían sido utilizadas hastaentonces como los enlaces múltiples, la posibilidad de hacer un enlace a otro enlace(recordemos que los enlaces son componentes) o los componentes compuestos, que poraquel entonces muchos sistemas de hipertexto no soportaban.

8.1.2. Modelo de Amsterdam

Mientras que el modelo de Dexter permite la composición de estructuras jerárquicas, laespecificación de enlaces entre componentes y el uso de anclas, el modelo deAmsterdam lo extiende añadiendo las nociones de tiempo, presentación a alto nivel deatributos y enlaces de contexto.

Y ése el precisamente el principal interés del modelo de Amsterdam, el que contemplela complejidad de los tipos multimedia, y muy en especial la cuestión del tiempo queéstos conllevan. Tanto el audio como el vídeo presentan esta nueva componente que esel tiempo, que no fue incluida en el modelo de Dexter.



8.1.3. Modelo HDM

En HDM se divide el proceso de diseño de una aplicación en dos partes: authoring-in-the-large, para referirnos a la especificación y diseño de los aspectos globales,estructurales de la aplicación, y authoring-in-the-small, para referirnos al desarrollo delcontenido de los nodos. El modelo, como es lógico se centra en la primera, en laestructura de la aplicación.

La terminología base del HDM es bastante diferente a la de Dexter y se puede prestar aconfusión. El equivalente de nodo es lo que denominan unidad. Las unidades seagrupan mediante una visita guiada o un índice, formando componentes, que a su vezse agrupan jerárquicamente en lo que denomina entidades. Asimismo hay varios tiposde enlace; los más importantes en la estructura son los que unen componentes dentro deuna entidad, y se denominan enlaces de componente o de perspectiva; los enlacesestructurales conectan componentes de la misma entidad; por último los enlaces deaplicación conectan componentes y entidades de distinto tipo, y son independies de laestructura

La principal motivación de HDM es crear un modelo basado en las anteriores primitivasantes de comenzar a desarrollar que ayudará a conseguir una navegación másconsistente y rica. Además HDM puede resultar útil también para evaluar aplicacionesya desarrolladas, con el fin de detectar errores en la estructura navegacional.

Sin embargo, nuestra experiencia nos ha demostrado que realizar un modelo siguiendolas normas de HDM es extremadamente complicado cuando el número de entidadesinvolucradas crece. En particular, era prácticamente imposible representar la estructurade MINTour utilizando este modelo.

8.1.4. Metología RMM

Esta metodología permite explicitar la navegación al hacer el análisis, con lo cual nospermitirá, en teoría, obtener una navegación más estructurada y, por tanto, más regular eintuitiva. Lo hace de una forma sencilla, simplemente añadiendo unas primitivas a loque es un modelo entidad-relación tradicional. Es de gran interés, bajo mi punto devista, el concepto de slice, que permite agrupar datos de una entidad en diferentespantallas, y es que, al estar hablando de diferentes medios, la información de unaentidad puede ser muy variada. Para dar una idea más al respecto, podría ser interesanteque un vídeo sobre un hotel, mostrando sus interiores, aparezca en una pantalla diferentede otro que muestre su piscina. También es interesante la primitiva de grupo, quepermite explicitar la jerarquía de menús.

Según nuestro punto de vista RMM es de gran interés, ya que es el primer caso en el quese crea una metodología completa, con una definición de fases, y no únicamente unmodelo de datos. Además está basado en un modelo de datos relacional, lo cual se ajustaperfectamente no sólo a nuestros casos de estudio si no a la gran mayoría de lasaplicaciones existentes.



Pero, a mi entender, los mecanismos de acceso a la información son excesivamentesimples. Pueden ser suficientes para un problema con pocas entidades, per no si elnúmero crece.

Un importante problema es que no se permite hacer una consulta a partir de dosentidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles estárelacionada con ciudad, N a 1, y ésta a su vez con región, también N a 1, no hay formade permitir ver todos los hoteles de una región, sino es yendo de ciudad en ciudad ydespués, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que seríanecesario poder establecer un enlace navegacional no sólo entre entidades relacionadasdirectamente, sino también con las que estén relacionadas con ellas, y así sucesivamente(evidentemente siempre que sean relaciones también N a 1).

Aún así, la navegación tendría más limitaciones. Y es que ya hemos visto que lasconsultas han de ser tan simples como que dado una ciudad qué hoteles tiene, quecampings, que puertos y aeropuertos, etc. Pero, por ejemplo, sería imposible explicitaruna consulta del tipo qué hoteles de una cierta categoría hay en una ciudad determinada.

Otro gran defecto es que en la explicación de la primera etapa, que es el correspondientea la construcción del diagrama Entidad-Relación, se nos dice que las relaciones N:M sedescompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologíascomo, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad queresulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artículoy que trata de un sistema de cursos, en los que se reflejan los profesores, suspublicaciones, ... En el artículo, los autores rompen la relación N:M entre profesores ycursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero seolvidan de los datos que deben guardarse de la relación original, como por ejemplocuántas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, conuna entidad en medio, no habría forma de saber los cursos que imparte cierto profesor, oqué profesores imparten cierto curso ya que no estarían directamente relacionados.

Otro punto no tratado en la metodología es el análisis de los procesos, sobre el que nohemos profundizado debido a que nuestros casos de estudio son únicamenteaplicaciones de consulta, sin actualizaciones por parte del usuario. Pero es obvio que sedebería incorporar un modelado del tipo de DFDs en la metodología 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 híbridos (con datosde más de una entidad), mínimos (la mínima parte de una entidad que es necesaria paraidentificar uno de sus elementos) y los m-slices (permite combinan primitivas de accesocon otros slices de otras entidades para crear un m-slice). Nuestra opinión al respecto espositiva en los dos primeros casos y negativa con respecto a los m-slices, ya que lo quepropone es crear la estructura de la navegación no en base a las entidades sino a losslices, es decir a conjuntos de atributos. Así, mientras los primeros han sidoampliamente utilizados en nuestros casos de estudio, los últimos no.



8.1.4.1. Mejoras en las estructuras de navegación en RMM

A partir de las carencias de RMM e incoporando la novedad de los slices mínimos ehíbridos, no así lo m-slices, consideramos que la solución para que RMM seaaprovechable es la creación de unas nuevas estructuras de navegación que doten de unamayor flexibilidad al modelo. A continuación explicamos las nuevas estructurasintroducidas:

• navegación jerárquica: al tener varias relaciones 1:N encadenadas, sepermite navegar desde cualquier entidad a otra que esté por debajo de ella enla jerarquía. Estos enlaces inferidos, no extraídos directamente de unarelación 1:N, se representarán con trazo discontinuo.

• navegación en relaciones N:M: se permite navegar de un extremo al otro dela relación, pero teniendo en cuenta la entidad intermedia, cuyos atributosdeberán incluirse en un slice híbrido. Para representar un enlace de este tipo,uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidadintermedia.

• navegación múltiple: se crean unas nuevas primitivas que permiten el accesomúltiple de una entidad a otra, seleccionando un elemento de una terceraentidad de la que la entidad destino es parte. En el enlace quedaráespecificado qué entidad es la origen, cuál la destino y cuál la tercera.Recordar que esta navegación es especialmente apropiada en estructuras todo-parte.

• acceso aleatorio: permite acceder a un elemento aleatoriamente. Por ejemplo,en el Atles, dado un tema de nivel 2, accederemos a uno de sus sabías que, deforma aleatoria, sin saber exactamente a cuál.

• acceso simultáneo: permite representar el acceso a todos los elementos deuna entidad a la vez. Por ejemplo, en MINTour, si estamos en un alojamiento,con esta primitiva accedemos a todos sus alojamientos simultáneamente,todos a la vez, y no mediante un índice o uno tras otro en una visita guiada

Después de todo esto, la lista de las primitivas de acceso queda reflejada en la siguientetabla:



Hiperenlace

Hiperenlace jerárquico inferido

Índice

Visita guiada


Acceso aleatorio

Acceso simultáneo

Índice múltiple



Entity Rel. N:M

Ejemplo de acceso a partir de una relaciónN:M, en este caso utilizando un índice(podría ser cualquier otra primitiva deacceso simple)

Interfaz de usuario

Al hacer el estudio de las fases 4 a 7 de la metodología RMM, y especialmente de laetapa 5, diseño de interfaz de usuario, consideramos que hay una organización de lapantalla que es especialmente coherente con la estructura, y que, además de ser clara,puede resultar muy útil en todo tipo de aplicaciones hipermedia. Posiblemente losautores no la tuvieron en cuenta, quizás porque los navegadores de aquel entonces aúnno tenían soporte para ello. Se trata del uso de marcos (frames) de HTML (o si seprefiere de tablas). Así, podríamos tener un marco principal la información del objetoseleccionado. Y además tres marcos más, con otros colores para diferenciarlos, ydispuestos como el diseñador lo estime oportuno que contendrían los elementosnavegacionales, 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 navegación enmuchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo deplataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de lapantalla en varias áreas.

8.1.5. Casos de estudio

Los ejemplos de los artículos siempre adolecen de ser muy sencillos, lo cual hace muyfácil aplicar las técnicas de modelo que los autores proponen. Nosotros decidimosaplicar RMM a tres casos de estudio, que por su gran envergadura y riqueza deestructura, nos ayudaran a detactar problemas y proponer soluciones a RMM. Éstos sonlos números de los tres casos de estudio:

CD-ROM del Parc Natural de S’Albufera28 Entidades91 Atributos31 Slices

Proyecto MINTour20 Categorías129 Entidades1016 Atributos de entidades277 Slices

CD-ROM del Atles de les Illes Balears28 EntidadesElementos de información contenidos en el CD-ROM:

Textos 960Mapas 686Gráficos 283Tablas 148Fotos 288Vídeos 72Imágenes panorámicas 23Total 2460

8.1.5.1. CD-ROM del Parc Natural de S’Albufera

Como principal conclusión de este estudio se puede deducir la utilidad de utilizar unametodología y un modelo para evaluar detalladamente una aplicación ya desarrollada, aposteriori.

De esta manera se han detallado una serie de carencias en la estructura de la informacióny la navegación. Las exponemos detalladamente a continuación:



Tanto animales (aves, mamíferos, peces, reptiles e invertebrados) como plantas tienenun lugar en el parque. En el sistema actual se desaprovecha la información para permitirque navegar por todos, por ejemplo, mamíferos de un lugar concreto. Y también alcontrario, no podemos ir a visitar el lugar que se nos cita en la información del animal oplanta.

El mismo caso ocurre con los usos del parque y con los momentos históricos, que nofueron enlazados con su lugar.

Se pierde la posibilidad de navegar por estación o mes. Tenemos la información de lapresencia de las aves por meses, así como una breve descripción del parque en cadaestación. Pero no podemos ver las aves que están en un mes concreto (interesante siqueremos planificar una visita real al parque). Lo mismo ocurre con el período defloración de las plantas, que no se puede navegar por las plantas que están en flor en unmes 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 navegación,más consistente e intuitivo que el existente. De hecho, el proyecto europeo dejó de ladola línea de un proyecto multimedia, para convertirse en un simple recuperador deinformación de la base de datos, sin ninguna navegación posible entre sus elementos. Encambio nuestra solución daría lugar a un sistema en el cual el usuario navegaría, igualque podría navegar virtualmente por Europa, en vez de hacer una consulta tras otra,definiendo complicadas búsquedas a la base de datos. Desde nuestro punto de vista, éstaes la diferencia fundamental entre una aplicación multimedia-hipermedia y una degestión: en la primera lo importante es la navegación y en la segunda la recuperaciónexacta de los datos que el usuario desea. Pero, pensamos que la situación es que elusuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entraren el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas quetienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de unatienda y ofrecen visitas guiadas.

El análisis de MINTour, al tratarse de un proyecto tan grande con tantas y tan variadasentidades, nos ha servido para descubrir gran parte de las mejoras a la metodologíaRMM que hemos propuesto:

• Los accesos complejos, que pueden ser de tres tipos: navegación jerárquica,navegación en relaciones N:M y navegación múltiple.

• También se introdujo la nueva primitiva de acceso simultáneo, que permiteacceder a todos los elementos simultáneamente de una entidad con la que seestá relacionado.

• Y para terminar, hay que notar la novedad que supone dividir el problema endiferentes categorías o temas, de manera que los modelos sean legibles. Al



final, todo queda interconectado desde la jerarquía de menús, así como através de algunos enlaces que existen entre entidades de diferentes categorías.

8.1.5.3. CD-ROM del Atles de les Illes Balears

Éste ha sido el caso de estudio en el que más se ha profundizado, sin duda porque hasido en el que el proyectista ha tenido una mayor participación: en el primer caso,S’Albufera, sólo se pretendía hacer un análisis de una aplicación ya hecha, con el fin deevaluarla. En el segundo, MINTour, el objetivo ya era el de hacer la aplicación completaa partir del análisis, pero por una serie de causas internas al proyecto, la aplicación tomóotros derroteros. Pero en este tercer caso, sí se han podido seguir todas las fases de lametodología hasta obtener la aplicación final.

Además, la estructura de la información es bien diferente a MINTour, mucho más rica,con muchas más inter-relaciones entre los datos, y se presta mejor a un análisisnavegacional.

Como principal conclusión de este caso de estudio, consideramos que podemos citar quese ha demostrado que sí es posible el hacer un desarrollo completo de una aplicaciónsiguiendo la metodología RMM, con una serie de mejoras que ya se han comentado. Noobstante, hay una serie de aspectos sobre los que se debería profundizar, especialmenteen las fases posteriores al modelo RMDM, y básicamente en la fase quinta, Diseño de lainterfaz de usuario, donde se interactúa directamente con el diseñador gráfico, que amenudo no conoce nuestra metodología. En concreto, nosotros hemos incorporado a lametodología, la lista de los elementos gráficos así como un conjunto de layouts pararepresentar la estructura de la pantalla, que ya se han sido citados en las conclusionesacerca de la quinta etapa.

Para terminar, a partir de este caso de estudio se ha la nueva primitiva de accesoaleatorio, que permite acceder a los elementos de una entidad aleatoriamente.



8.2. Líneas de futuro

Últimamente están surgiendo nuevas metodologías, lo cual no es de extrañar vista lacierta inmadurez del tema de la ingeniería del software aplicada a la hipermedia. Entreellas destacaremos OOHDM, [SCH96], que es una extensión de HDM con orientación aobjetos y que se está convirtiendo en una de las más utilizadas. Otras interesantesreferencias pueden encontrarse en [GRE96] y [GRO96].

El continuar estudiando estas nuevas metodologías y aplicarlas a nuestros tres casos deestudio, o a otros nuevos, podría ser objeto de nuevos proyectos finales de carrera.

La revisión a fondo de RMM (y otras metodologías), así como la posibilidad dedesarrollar una herramienta tipo CASE, pueden ser objeto de investigación a partir deltrabajo que hemos desarrollado.

Una metodología relacional hipermedia. Estudio en casos prácticos IX - Bibliografía


Capítulo IXBIBLIOGRAFÍA

[BAL96] V. Balasubramanian, M. Bieber, T. Isakowitz: Systematichypermedia design. Documento pre-imprenta,http://eies.njit.edu/~333/bala.html, CRIS Working Paper series5/10/96 1996.

[BAR93] M. Barceló, M. Costa, C. Quer: Anàlisi d’aplicacionsinformàtiques. 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-basedapproach to hypermedia applications design. ACMTranactions 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 JHuman-Computer Studies, 1996.

[GRO96] K. Grønbœk, R. H. Trigg: Toward a Dexter-based model foropen hypermedia: Unifying embedded references and linkobjects. Presentado en The Seventh ACM Conference onHypertext, Washington DC, March 16-20, 1996, 1996.

[HAL94] F. Halasz, M. Schwartz: The Dexter Hypertext referencemodel. Communications of the ACM, vol. 37, pp. 30-39, 1994.

[HAR94] L. Hardman, D.C.A. Bulterman, G. Van Rossum: TheAmsterdam Hypermedia Model. Communications of the ACM,vol. 37, pp. 50-62, 1994.

[ISA95] T. Isakowitz, E. A. Stohr, P. Balasubramanian: RMM: Amethodology for structured Hypermedia design.Communications of the ACM, vol. 38, pp. 34-44, 1995.

[ISA96] T. Isakowitz, A. Kamis, M. Koufakis: Extending the capabilitiesof RMM: Russian dolls and Hypertext. Documento pre-imprenta, http://www.stern.nyu.edu/~tisakowi, 1996

[MAN94] M. Manresa: Apuntes de la asignatura “Disseny Lògic”. Palmade 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. SanDiego. 1990

Una metodología relacional hipermedia. Estudio en casos prácticos IX - Bibliografía


[PRE98] R. S. Pressman: Ingeniería del software. Un enfoque práctico.4ª edición. McGraw Hill. Madrid.1998

[SCH96] D. Schwabe, G. Rossi, and S. D. J. Barbosa: SystematicHypermedia Application Design with OOHDM. Presentado enThe Seventh ACM Conference on Hypertext, Washington DC,March 16-20, 1996, 1996.

[SOM96] Ian Sommerville: Software Engineering. 5ª edición. Addison-Wesley. EE.UU. 1996

[UIB95] Parc Natural de S’Albufera . Universitat de les Illes Balears.Palma de Mallorca. 1995.

[UIB98] Atles de les Illes Balears. Universitat de les Illes Balears. Palmade Mallorca. 1998.

Documents

Metodologia de hipermedia RMM