Metodologia de hipermedia RMM

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

Antonio Navarrete Terrasa Proyecto final de carrera dirigido por Josep Blat Gimeno

Muchísimas gracias a: Mi familia, por su apoyo constante Virginia, por estar siempre a mi lado Mi director de proyecto, por haber confiado en mí Mis 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 en Palma de Mallorca, durante los años 1996, 1997 y 1998, bajo la dirección del Doctor Josep Blat 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

CONTENIDOS CONTENIDOS............................................................................................................................................3 CAPÍTULO I - INTRODUCCIÓN............................................................................................................7 1.1. ESTRUCTURA DEL PROYECTO..................................................................................................................7 1.2. CONCEPTOS FUNDAMENTALES ..............................................................................................................10 1.2.1. Hipertexto, multimedia e hipermedia...........................................................................................10 1.2.1.1. Hipertexto............................................................................................................................................. 10 1.2.1.2. Multimedia ........................................................................................................................................... 11 1.2.1.3. Hipermedia ........................................................................................................................................... 11 1.2.1.4. Resumen ............................................................................................................................................... 11

1.2.2. Ingeniería del software ................................................................................................................12 1.2.2.1. Análisis................................................................................................................................................. 13 1.2.2.2. Diseño................................................................................................................................................... 14

CAPÍTULO II - LOS PRIMEROS MODELOS HIPERMEDIA .........................................................15 2.1. MODELO DE HIPERTEXTO DE DEXTER ..................................................................................................15 2.1.1. Breve descripción del sistema ......................................................................................................15 2.1.2. Modelo simple de la capa de almacenamiento ............................................................................17 2.1.2.1. Enlaces span-to-span............................................................................................................................ 18

2.1.3. Capa de tiempo de ejecución .......................................................................................................21 2.1.4. Conclusiones ................................................................................................................................23 2.2. MODELO DE HIPERMEDIA DE AMSTERDAM ...........................................................................................24 2.2.1. Descripción de los conceptos del AHM .......................................................................................24 2.2.1.1. Hipertexto, multimedia e hipermedia.................................................................................................... 24 2.2.1.2. Información temporal ........................................................................................................................... 26 2.2.1.3. Enlaces en hipermedia .......................................................................................................................... 27 2.2.1.4. Atributos de especificación de la presentación a alto nivel .................................................................. 28

2.2.2. El modelo de hipermedia de Amsterdam......................................................................................28 2.2.3. Relaciones temporales .................................................................................................................30 2.2.4. Otras contribuciones del modelo .................................................................................................31 2.2.4.1. Contexto de los enlaces ........................................................................................................................ 31 2.2.4.2. Canales ................................................................................................................................................. 31

2.2.5. Conclusiones ................................................................................................................................31 CAPÍTULO III - EL MODELO HDM ...................................................................................................32 3.1. OBJETIVOS Y MOTIVACIONES ................................................................................................................32 3.2. PRIMITIVAS ...........................................................................................................................................34 3.2.1. Entidades y tipos de entidades .....................................................................................................35 3.2.2. Componentes................................................................................................................................35 3.2.3. Perspectivas .................................................................................................................................35 3.2.4. Unidades ......................................................................................................................................36 3.2.4. Enlaces en general .......................................................................................................................36 3.2.5. Enlaces de perspectiva o de componentes ...................................................................................36 3.2.6. Enlaces estructurales ...................................................................................................................37 3.2.7. Enlaces de aplicación y tipos de enlaces .....................................................................................37 3.2.8. Esquema HDM .............................................................................................................................37 3.3. EVALUACIÓN DE UNA APLICACIÓN USANDO HDM ................................................................................39 3.4. CONCLUSIONES .....................................................................................................................................41 CAPÍTULO IV - LA METODOLOGÍA RMM......................................................................................42 4.1. LA PRIMERA FORMULACIÓN DE LA METODOLOGÍA RMM......................................................................42 4.1.1. El modelo RMDM ........................................................................................................................42 4.1.2. Etapas de la metodología.............................................................................................................46 4.1.2.1. Etapa 0.................................................................................................................................................. 46 4.1.2.2. Etapa 1: Diseño Entidad-Relación........................................................................................................ 46 4.1.2.3. Etapa 2: Diseño de slices ...................................................................................................................... 47

Antonio Navarrete Terrasa

Pág. 3



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

4.1.4. Conclusiones y discusión .............................................................................................................51 4.2. EVOLUCIONES DE RMM .......................................................................................................................54 4.2.1. Estructura de datos y navegación ................................................................................................54 4.2.1.1. Slice mínimo y slice híbrido ................................................................................................................. 54 4.2.1.2. Los m-slices .......................................................................................................................................... 55 4.2.1.3. Conclusiones ........................................................................................................................................ 56

4.2.2. Las etapas de interfaz de usuario.................................................................................................57 4.2.2.1. Etapa 4: Diseño de protocolos de conversión....................................................................................... 57 4.2.2.2. Etapa 5: Diseño de la interfaz de usuario ............................................................................................. 58 4.2.2.3. Etapa 6: Diseño del comportamiento en tiempo de ejecución .............................................................. 58 4.2.2.4. Etapa 7: Construcción y tests................................................................................................................ 59 4.2.2.5. Conclusiones ........................................................................................................................................ 59

4.3. MEJORAS EN ESTRUCTURAS NAVEGACIONALES PARA RMM.................................................................60 4.3.1. Caso A: accesos jerárquicos ........................................................................................................60 4.3.2. Caso B: acceos en relaciones N:M ..............................................................................................62 4.3.3. Caso C: accesos múltiples............................................................................................................65 4.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 ...................................................................71 5.1.1. Introducción .................................................................................................................................71 5.1.2. Estructura de la aplicación ..........................................................................................................72 5.1.3. Premios recibidos.........................................................................................................................75 5.2. MODELADO DE LA NAVEGACIÓN DEL CD..............................................................................................76 5.3. APLICACIÓN DE TODAS LAS FASES DE LA METODOLOGÍA.......................................................................82 5.3.1. Primera etapa: Diseño entidad-relación .....................................................................................82 5.3.2. Segunda fase: Diseño de slices ....................................................................................................84 5.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 MINTOUR ................................................................................................................................92 6.1.1. Por qué nace MINTour ................................................................................................................92 6.1.2. Objetivos ......................................................................................................................................92 6.2. 1ª ETAPA: ANÁLISIS ENTIDAD-RELACIÓN .............................................................................................94 6.2.1. Áreas geográficas.........................................................................................................................94 6.2.2. Alojamientos.................................................................................................................................97 6.2.3. Playas.........................................................................................................................................100 6.2.4. Deportes .....................................................................................................................................102 6.2.5. Eventos culturales ......................................................................................................................105 6.2.6. Museos y monumentos................................................................................................................107 6.2.7. Naturaleza ..................................................................................................................................109 6.2.8. Entretenimientos ........................................................................................................................111 6.2.9. Restaurantes...............................................................................................................................113 6.2.10. Rent-a-car ................................................................................................................................115 6.2.11. Tienda ......................................................................................................................................117 6.2.12. Transporte aéreo......................................................................................................................119 6.2.13. Transporte marítimo ................................................................................................................122 6.2.14. Transporte terrestre .................................................................................................................125 6.2.15. Transporte Urbano...................................................................................................................128 6.2.16. Taxis .........................................................................................................................................132 6.2.17. Paquete turístico ......................................................................................................................133 6.2.18. Excursiones ..............................................................................................................................134 6.2.19. Teléfonos y direcciones útiles ..................................................................................................136 6.2.20. Agencias de viaje .....................................................................................................................137 6.3. 2ª ETAPA: DISEÑO DE SLICES ..............................................................................................................139 6.3.1. Áreas geográficas.......................................................................................................................139 Antonio Navarrete Terrasa

Pág. 4



6.3.2. Alojamientos...............................................................................................................................141 6.3.3. Playas.........................................................................................................................................144 6.3.4. Deportes .....................................................................................................................................145 6.3.5. Eventos culturales ......................................................................................................................147 6.3.6. Museos y monumentos................................................................................................................149 6.3.7. Naturaleza ..................................................................................................................................151 6.3.8. Entretenimientos ........................................................................................................................153 6.3.9. Restaurantes...............................................................................................................................155 6.3.10. Rent-a-car ................................................................................................................................157 6.3.11. Tienda ......................................................................................................................................159 6.3.12. Transporte aéreo......................................................................................................................161 6.3.13. Transporte marítimo ................................................................................................................164 6.3.14. Transporte terrestre .................................................................................................................167 6.3.15. Transporte Urbano...................................................................................................................169 6.3.16. Taxis .........................................................................................................................................173 6.3.17. Paquete turístico ......................................................................................................................174 6.3.18. Excursiones ..............................................................................................................................175 6.3.19. Teléfonos y direcciones útiles ..................................................................................................176 6.3.20. Agencias de viaje .....................................................................................................................177 6.4. 3ª ETAPA: DISEÑO NAVEGACIONAL.....................................................................................................179 6.4.1. Áreas geográficas.......................................................................................................................180 6.4.2. Alojamientos...............................................................................................................................182 6.4.3. Playas.........................................................................................................................................184 6.4.4. Deportes .....................................................................................................................................185 6.4.5. Eventos culturales ......................................................................................................................187 6.4.6. Museos y monumentos................................................................................................................188 6.4.7. Naturaleza ..................................................................................................................................189 6.4.8. Entretenimientos ........................................................................................................................190 6.4.9. Restaurantes...............................................................................................................................191 6.4.10. Rent-a-car ................................................................................................................................192 6.4.11. Tienda ......................................................................................................................................193 6.4.12. Transporte aéreo......................................................................................................................194 6.4.13. Transporte marítimo ................................................................................................................196 6.4.14. Transporte terrestre .................................................................................................................197 6.4.15. Transporte Urbano...................................................................................................................199 6.4.16. Taxis .........................................................................................................................................202 6.4.17. Paquete turístico ......................................................................................................................203 6.4.18. Excursiones ..............................................................................................................................204 6.4.19. Teléfonos y direcciones útiles ..................................................................................................205 6.4.20. Agencias de viaje .....................................................................................................................206 6.4.21. Jerarquía de menús ..................................................................................................................207 6.5. ETAPAS 4 A 7: INTERFAZ DE USUARIO Y CONSTRUCCIÓN ....................................................................209 6.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 ..............................................................................................213 7.2. PRIMER ESTUDIO DEL CASO.................................................................................................................215 7.2.1. Etapa 0: análisis de requerimientos...........................................................................................215 7.2.2. Etapa 1: Diseño Entidad-Relación ............................................................................................216 7.2.3. Etapa 2: Diseño de slices...........................................................................................................217 7.2.4. Etapa 3: Diseño navegacional ...................................................................................................218 7.3. SEGUNDO (Y DEFINITIVO) ESTUDIO DEL CASO .....................................................................................220 7.3.1. Etapa 0: análisis de requerimientos...........................................................................................221 7.3.2. Etapa 1: Diseño Entidad-Relación ............................................................................................221 7.3.3. Etapa 2: Diseño de slices...........................................................................................................222 7.3.4. Etapa 3: Diseño navegacional ...................................................................................................223 7.3.5. Etapa 4: Diseño de protocolos de conversión ...........................................................................225 7.3.6. Etapa 5: Diseño de la interfaz de usuario..................................................................................226 7.3.6.1. Conclusiones de esta etapa ................................................................................................................. 232


Pág. 5



7.3.7. Etapa 6: Diseño del comportamiento en tiempo de ejecución ...................................................233 7.3.8. Etapa 7: Construcción y tests.....................................................................................................233 7.4. CONCLUSIONES ...................................................................................................................................234 CAPÍTULO VIII - CONCLUSIONES ..................................................................................................235 8.1. RESUMEN FINAL Y CONCLUSIONES ......................................................................................................235 8.1.1. Modelo de Dexter.......................................................................................................................235 8.1.2. Modelo de Amsterdam................................................................................................................236 8.1.3. Modelo HDM .............................................................................................................................237 8.1.4. Metología RMM .........................................................................................................................237 8.1.4.1. Evoluciones de RMM......................................................................................................................... 238 8.1.4.1. Mejoras en las estructuras de navegación en RMM............................................................................ 239

8.1.5. Casos de estudio.........................................................................................................................241 8.1.5.1. CD-ROM del Parc Natural de S’Albufera ......................................................................................... 241 8.1.5.2. Proyecto MINTour ............................................................................................................................. 242 8.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


Pág. 6


I - Introducción

Capítulo I INTRODUCCIÓN Las metodologías de Análisis y Diseño están orientadas a obtener un software fiable y eficiente, que cumpla los requerimientos preestablecidos. Pero el desarrollo de una aplicación multimedia-hipermedia presenta dos aspectos específicos respecto al desarrollo del software tradicional: • En el desarrollo de una aplicación multimedia pueden participar tipos de gente muy diferentes, como, por ejemplo, informáticos, diseñadores, artistas, geógrafos, historiadores, filólogos, ..., cada uno de ellos con un lenguaje muy distinto, en mayor medida y con diferente papel que en otras aplicaciones. • Se le da mayor importancia a la interfaz de usuario, ya que las aplicaciones se orientan al disfrute, a la consulta extensiva, ... frente al modelo transaccional clá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 de la multimedia-hipermedia con el objetivo de dotar de un lenguaje común a los miembros del 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 de conseguir 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 el desarrollo de proyectos en el ámbito de la hipermedia. En nuestro proyecto se examinan de forma relativamente breve algunas de las metodologías propuestas y los conceptos básicos. Una de ellas, RMM, será aplicada y estudiada en gran detalle mediante tres casos prácticos que se corresponden a tres aplicaciones multimedia, en dos de los cuales el proyectista participa activamente. Ventajas, inconvenientes y posibles modificaciones a la metodología son propuestas. Para ello la metodología será aplicada y estudiada mediante tres casos prácticos, que se corresponden a tres aplicaciones multimedia, en dos de los cuales el proyectista participa activamente.

1.1. Estructura del proyecto La estructura en que se presenta el proyecto no coincide exactamente con la evolución temporal que éste ha seguido, ya que los casos de estudio han determinado las propuestas de mejora a la metodología, aunque en el presente documento éstas se explican con anterioridad. En este primer capítulo se definen los conceptos fundamentales entorno de los cuales va a girar todos el proyecto, como son hipertexto, multimedia e hipermedia por un lado, y


Pág. 7


I - Introducción

la ingeniería del software, por otro, describiendo brevemente qué es una metodología y qué se entiende por análisis y diseño de software. En el segundo capítulo, comenzaremos a centrarnos en las metodologías orientadas a la hipermedia. En primer lugar analizaremos el modelo de Dexter, el primer intento, que data de finales de los 80, de investigar las características propias de la hipermedia, ofreciendo un modelo que describe su estructura. Dexter proporciona también una terminologí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 debido a que Dexter se ciñe fundamentalmente a hipertexto, y no considera la variedad de medios existentes y el principal problema que conllevan, que son las relaciones temporales. En el tercer capítulo trataremos el modelo HDM (Hypertext Design Model). El objetivo del modelo HDM ya es, más que describir la estructura interna de una aplicación hipermedia como era el caso de Dexter y Amsterdam, crear un modelo que sea de utilidad para realizar el diseño de una aplicación, a partir de la estructura de datos. Es de gran importancia este hecho de centrar en la estructura de datos un buen diseño de la aplicación. También el modelo basado en la estructura de datos es muy útil para el análisis de aplicaciones ya existentes y comparaciones entre ellas. Y en el cuarto capítulo nos centraremos en la metodología RMM (Relationship Management Methodology), que no sólo ofrece un modelo basado en la estructura de datos, como el caso de HDM, sino que ya es una metodología completa. Se definen una serie de etapas y modelos para cada una de ellas, desde el análisis inicial de requisitos hasta la implementación y pruebas. A continuación, explicaremos por qué elegimos RMM para nuestros casos de estudio y veremos, basados en la experiencia que éstos nos han deportado, los principales defectos y carencias que hemos encontrado en RMM y las mejoras que nosotros hemos propuesto, fundamentalmente basadas en unos nuevos patrones de acceso a la 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 la primera vez que utilizamos la metodología RMM con un problema relativamente grande. Se trata del análisis de una aplicación ya finalizada con el objetivo de encontrar enlaces de navegación que no se contemplaron al desarrollarla. • El segundo caso de estudio, el proyecto MINTour, es con mucho, el de mayor envergadura. Se trata de un gran proyecto europeo sobre información turística. Hemos realizado el análisis y diseño completo, si bien el modelo final no fue implementado al alejarse el proyecto europeo de las especificaciones iniciales. Nos ha sido de gran ayuda para identificar los problemas de RMM y los patrones de las estructuras navegacionales que proponemos como mejora.


Pág. 8


I - Introducción

• El tercer caso de estudio, el Atles de les Illes Balears, sí que ha dado lugar a la implementación de la aplicación basada en el análisis y diseño utilizando RMM. Es la confirmación de que RMM con nuestras mejoras es realmente utilizable. Nos ha sido muy útil en los aspectos correspondientes a diseñar interfaz gráfica estructurada, basada en el análisis. Por último, en el capítulo final se ofrecen un resumen final, conclusiones y posible líneas de acción futuras.


Pág. 9


I - Introducción

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 forma tradicional del texto, con pueda ser un libro. El texto tradicional es secuencial, es decir que hay una única secuencia lineal que define el orden en que el texto debe ser leído. Se empieza por la página 1, luego la 2, y así sucesivamente hasta la última. La figura lo muestra: 1

2

...

n

En cambio el hipertexto es fundamentalmente no secuencial. No existe un único orden en 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 sentido enumerar las páginas, pues nunca se puede saber cuál será la segunda página, cuál la tercera, 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 vemos representadas vemos representadas, reciben el nombre de nodos en la terminología de hipertexto. Estos nodos constituyen la unidad de información, la parte más pequeña con sentido propio. Los nodos se interconectan, es decir se pasa de uno a otro, de una porción de texto a otra, mediante lo que se denominan enlaces (links en inglés). Así, un enlace conecta dos nodos, uno el origen, llamado ancla (anchor) y el otro denominado destino (destination).


Pág. 10


I - Introducción

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

1.2.1.2. Multimedia Con multimedia designamos a aquella aplicación que presenta varios medios, en contraposició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 uno de 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. Es un 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 los nodos contienen elementos de diferentes medios. Los anclas ya no sólo son palabras sino que pueden, por ejemplo, ser una imagen o un fragmento de ellas. El mayor problema es establecer anclas en un medio que depende del tiempo, como el vídeo o el audio. Es difícil hacer notar al usuario que si pulsa sobre un vídeo, el destino del enlace será diferente según el momento del vídeo, y mucho más complejo todavía es definir enlaces 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 los enlaces, definiendo los anclas, ya sea en elementos de texto, en imágenes, e incluso ya es 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 enlaces que 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 utilizar los términos indistintamente. En concreto, hoy día son muy poco corrientes los Antonio Navarrete Terrasa

Pág. 11


I - Introducción

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

1.2.2. Ingeniería del software En [PRE98], en su prólogo a la edición española encontramos cuatro diferentes definiciones de qué es la ingeniería del software, de sendos expertos en el tema. Creo que todas ellas son de gran interés: 1. «Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software.» (Zelkovitz, M.V., Shaw, A.C. y Gannon, J.D.: Principles of Software Engineering and Design. PrenticeHall. 1979). 2. «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 asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como 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 trabaje en máquinas reales.» (Bauer, F.L.: Software Engineering, Information Processing, 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 del Software pretende proveernos de unas metodologías, es decir unos conjuntos de métodos y de herramientas, con el objetivo de obtener un software fiable, de modo rentable, 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 sido utilizadas. Hay muchas diferencias entre ellas, pero casi todas tienen una base más o menos común. La principal es la división del proceso en unas etapas bien diferenciadas que componen lo que comúnmente se denomina análisis, diseño e implementación y pruebas. Cada una de ellas supone una visión, de más a menos abstracta, del problema. Antonio Navarrete Terrasa

Pág. 12


I - Introducción

Estas etapas confieren lo que tradicionalmente se denomina como el ciclo de vida de una aplicación, al que habría que añadirle una cuarta etapa muy importante que es la del mantenimiento. Las etapas de análisis y diseño son la base para un obtener un buen sistema. Un mal análisis y diseño, por muy buenos que sean los programadores, acarreará un sistema ineficiente, poco fiable, pero sobretodo muy costoso de ser mantenido. Estas etapas utilizan unas herramientas diferentes para poder describir el sistema, a su nivel de abstracción correspondiente. Por herramientas aquí no se entiende herramientas automá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 pretenden describir un aspecto de la aplicación, como pueda ser, por ejemplo la estructura de los datos. A continuación, veremos brevemente las principales características de las etapas de análisis y diseño, así como de los métodos de modelado más comúnmente utilizados por las 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 un análisis de los requisitos del sistema, desde un punto de vista funcional y obtener un modelo, que aprobado por el usuario sirva de base para el diseño. El análisis, como hemos dicho, ofrece un modelo funcional del sistema, es decir de cómo debe ser el sistema, qué información y funciones debe tener. En el diseño se especificará en detalle cada una de esas funciones. Así, aquí se define qué deberá hacer el sistema y en el diseño cómo lo debe hacer. La revisión con el cliente de las especificaciones funcionales del software, resultado de esta fase, es de vital importancia, y a menudo compleja debido a los lenguajes diferentes que utilizan cliente y desarrollador. La creación de prototipos suele ayudar a esta comunicació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 el modelado del análisis se divide en dos partes fundamentales, el modelo de datos y el modelo de flujos. El modelo de datos se basa en el modelo entidad-relación, donde se definen todas las entidades que participan en el problema y las relaciones entre ellas. Un diccionario de datos, donde se describen las entidades y sus atributos acompaña siempre a este modelo. En cuanto al modelo de flujos, se utiliza el denominado modelo de flujo de datos, donde se representa cómo los datos se transforman, definiendo las principales funcionalidades del sistema. En determinados sistemas también se incluyen modelos de estado, donde se describen las transiciones de estado que sufren las diferentes entidades. Antonio Navarrete Terrasa

Pág. 13


I - Introducción

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. Si en el análisis nos deteníamos en estudiar qué es lo que deberá hacer el sistema, en el diseño investigamos cómo debe hacerlo, definiendo en detalle todos los procesos del sistema y datos que éstos afectan. Se profundiza y completa la estructura de datos, por un lado y la de programa, por otro. Esta división entre datos y programa (o procesos), da lugar a lo que en algunas metodologías se denomina diseño de datos y diseño de procesos, también llamado diseño arquitectónico. A estas dos divisiones, habría que añ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 de codificar 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 el diseñ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 se llega a una mayor profundidad en la jerarquía de procesos, hasta alcanzar el detalle de definir los procedimientos que serán necesarios en pseudocódigo u organigramas. Algunos autores denominan a esto último diseño procedimental y lo consideran como una 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 de las otras fases del diseño. Se basa bastante en la experiencia del diseñador, y por supuesto en los procesos donde intervenga el usuario que se hayan definido en el diseño arquitectónico. A menudo se utilizan técnicas de prototipado para comprobar la aceptación por parte de los usuarios de la interfaz propuesta.


Pág. 14

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

Capítulo II LOS PRIMEROS MODELOS HIPERMEDIA El primer modelo que intentó describir el hipermedia fue el de Dexter, que data de 1998. Le siguió el de Amsterdam, que es una extensión al de Dexter añadiendo aspectos temporales.

2.1. Modelo de Hipertexto de Dexter El modelo de referencia de hipertexto de Dexter surge en 1988 durante unas reuniones, la primera de las cuales tuvo lugar en la Dexter Inn (New Hampshire), de donde toma su nombre, como un intento de respuesta a la pregunta: ¿qué tienen en común los distintos sistemas de hipertexto en sus nociones de nodos y enlaces (links) entre dichos nodos? Así, se pretende que el modelo sirva como un estándar para comparar las características y funcionalidades de varios sistemas de hipertexto. También como una base sobre la cual desarrollar estándares para interoperabilidad e intercambio entre sistemas de hipertexto. Otro punto importante de este trabajo es el de proveer de una terminología común al campo 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, la más próxima al usuario es la denominada capa de tiempo de ejecución (run-time layer); la intermedia es la llamada capa de almacenamiento (storage layer), mientras que la última recibe el nombre de capa del componente (within-component layer).


Pág. 15


capa de tiempo de ejecución (run-time layer) Especificaciones de presentación capa de almacenamiento (storage layer) Anclaje (anchoring) capa del componente (within-component layer)

El modelo se centra en la capa de almacenamiento, que modela la estructura básica de nodos y enlaces. Vendría a ser como una base de datos donde se almacena una jerarquía de componentes (contenedores de la información) interconectados por enlaces. Los componentes es lo que conocemos típicamente como nodos (por ejemplo una tarjeta en Hypercard, o un frame en Director). Por tanto, un componente puede contener fragmentos de texto, gráficos, animaciones, ... Al estudiar la capa de almacenamiento veremos que éstos son lo que llamamos componentes atómicos, que al unirse forman componentes compuestos, que es el equivalente a la noción de nodo. La capa de almacenamiento estudia los mecanismos por los cuales se unen dichos componentes y enlaces. Por contra, la capa del componente refleja los contenidos y estructura dentro de los componentes. Debido a que hay un sin fin de posibles contenidos/estructuras que pueden ser incluidos en un componente, el modelo de Dexter no profundiza el estudio de esta capa, dando libertad en este nivel. Una parte fundamental del modelo de Dexter es la interfaz entre las capa de almacenamiento y la capa del componente. Se basa en el mecanismo de anclaje (anchoring), que veremos más adelante. En cuanto a la capa de tiempo de ejecución, ésta provee al usuario de unas herramientas para acceder, ver y manipular la estructura de la red de hipertexto. Al igual que en la capa del componente, también existen un gran número de posibles herramientas para acceder, ver y manipular un hipertexto. Por consiguiente, el modelo Dexter sólo ofrece unas ideas básicas de cómo son esos mecanismos, pero no puede hacer referencia a los detalles 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 que llama especificaciones de presentación (presentation specifications). Ésta es un mecanismo que permite que la forma en que un componente se presenta al usuario pueda estar en función no sólo de una herramienta de hipertexto específica (es decir, de una capa de tiempo de ejecución específica), sino que puede ser una propiedad del componente por sí mismo, del enlace tomado para llegar a tal componente o también de las preferencias del usuario. Por ejemplo, un componente que contiene una animación Antonio Navarrete Terrasa

Pág. 16


puede presentarse de dos maneras diferentes según el usuario. Si el usuario es un profesor, se le permitirá editar el componente (la animación), mientras que si el usuario es 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 del modelo de Dexter. En la capa de tiempo de ejecución, tenemos la presentación del hipertexto al usuario a través de la pantalla. En la capa de almacenamiento, vemos una base de datos donde se almacenan todos los componentes y enlaces entre ellos (los enlaces también son componentes). Y por último en la capa del componente, se guarda la estructura interna del componente.

Comp. 55

Componente 24

Esto es un texto

24 37

Componente 37

CAPA DE TIEMPO DE EJECUCIÓN

CAPA DE ALMACENAMIENTO

CAPA DEL COMPONENTE

2.1.2. Modelo simple de la capa de almacenamiento La capa de almacenamiento describe la estructura de un conjunto finito de componentes, junto con dos funciones, resolver y accessor, encargadas de recuperar componentes. Es el componente el elemento fundamental de esta capa; éste puede ser un átomo, un enlace entre componentes, o puede estar compuesto a partir de otros componentes (formando un grafo acíclico, ya que un ciclo implicaría una recursividad). En el siguiente ejemplo vemos dos casos prohibidos de componentes compuestos, debido a que crean recursividad. Cada cuadro representa un componente compuesto; en la parte superior aparece en nombre del componente y en la inferior los componentes (atómicos o compuestos) que la forman.


Pág. 17


A A

Ciclo: A no puede contener a A

C

A A

B C

A

C

Ciclo: A no puede contener a un componente que contiene a A

Cada componente tiene un identificador único (UID). La función accessor es la que accede a un componente dado su UID, mientras que la función resolver permite, a partir de unas especificaciones del componente recuperar los UID correspondientes. Después se podrá acceder al componente mediante accessor. Por tanto, accessor constituye un direccionamiento directo a las componentes, mientras que resolver se utiliza para un direccionamiento indirecto, a dichos componentes a partir de las especificaciones.

2.1.2.1. Enlaces span-to-span Los enlaces span-to-span son aquellos que van de una parte de una componente a otra parte de otro componente. Para conseguir los enlaces span-to-span Dexter provee de una entidad de direccionamiento indirecto llamada ancla (anchor). Un ancla tiene dos partes: un identificador (id ancla - anchor id) y un valor (anchor value). El identificador es único dentro de cada componente. Por tanto, el par UID componente - id ancla es único dentro del hipertexto. El id ancla es manejado por la capa de almacenamiento para referenciar al contenido del componente, y se mantiene siempre constante; mientras, el valor del ancla es utilizado sólo en la capa del componente, y cuando se edita y modifica el componente. Por otro lado, el valor del ancla especifica de forma arbitraria alguna localización, región, ítem o subestructura dentro de componentes. Éste es sólo interpretable por las aplicaciones responsables de manejar el contenido/estructura del componente. Veamos cómo resulta la estructura de un componente atómico, teniendo en cuenta las anclas:


Pág. 18


Especificación de presentación Atributos Anclas

Contenidos

info. de esp. pres. del componente info. semántica (incluido el UID) id valor

datos

Y en el caso de un componente compuesto, la única diferencia es que se guardan también los UIDs de los componentes hijos Especificación de presentación Atributos Anclas

Hijos

Contenidos

info. de esp. pres. del componente info. semántica (incluido el UID) id valor

UID componente hijo

datos

A partir de aquí, para representar los extremos de un enlace, emplearemos el id ancla combinado con la especificación del componente, de cada extremo. Es lo que llamamos un especificador (specifier). Además de la especificación de un componente y un id ancla, son utilizados dos campos más: una dirección y una especificación de presentación de ese enlace. Como vemos, el especificador constituye, un extremo del enlace, y por tanto, un enlace está formado por dos o incluso más especificadores. En el caso de tener más de dos especificadores, tenemos lo que se denominan enlaces mú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 interfaz entre 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 y 202. Cada uno de ellos tiene definido un ancla que apunta a un punto concreto del texto (valor) y con un identificador. El componente 303 es un enlace entre los citados componentes. Por tanto, tiene dos especificadores. Recordemos que los especificadores se definen con una pareja UID componente - id ancla. Por tanto, el primero tiene el par


Pág. 19


(101,1) y el segundo (202,1). Además, de esta pareja, el identificador debe definir el sentido del enlace, en este caso del 101 (FROM) al 202 (TO). Vemos primero un diagrama y después la descripción escrita del modelo.

Componente 101 tipo: texto uid: 101 especif. pres.: ... Anclas valor id 1 Esto es un texto...xxxxx ...

Componente 303 tipo: enlace uid: 303 especif. pres.: ... Especificador uid componente: 101 id ancla: 1 dirección: FROM especif. pres.: ...

Componente 202 tipo: texto uid: 202 especif. pres.: ... Anclas valor id 2 Esto es otro texto...yyyyyy ...

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

texto 101 ... Esto es un texto ... 1 22-26 (La posición del ancla en el texto) texto 202 Esto es otro texto ... 2 35-46 enlace 303 ... 101 1 Antonio Navarrete Terrasa

Pág. 20


FROM ... 202 2 TO ...

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 desde un UID. • La función resolver debe ser capaz de producir todos los posibles UIDs válidos. • No hay ciclos en las relaciones componente/subcomponente (un componente no puede ser subcomponente de sí mismo. • Los identificadores de anclas de un componente han de ser los mismos que los identificadores de anclas del especificador de enlace, cuyo extremo es ese componente. • El hipertexto debe ser lo que se denomina link-consistent, es decir, que al borrar un componente se borren también los enlaces que lo tienen como extremo.

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 un componente. 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 un componente se pasa al usuario para que la visualice y/o edite. Esta copia será después escrita de nuevo en la capa de almacenamiento. Nótese que puede haber más de una instanciación de un componente a la vez. Por ello, a cada instanciación se le asigna un identificador único (instantiation identifier - IID).


Pág. 21


C. tiempo ejecución Capa almacenam.

>

instancia del botón que se presenta al usuario componente 345 - botón

Recordemos que la manera en que el componente se presenta al usuario dependerá de las 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 le llamará marcador de enlace (link marker), que es la manifestación visible de un ancla en un documento. En resumen, una instanciación contendrá: • una instanciación base (base instantiation), que es una primitiva del modelo que representa algún tipo de presentación de el componente al usuario. • una secuencia de marcadores de enlace junto con una función que haga corresponder esos marcadores de enlaces a las anclas que instancian. Como que en un momento dado un mismo usuario puede estar visualizando y/o editando varias instanciaciones de componentes, se define una nueva entidad en el modelo que es la sesión, que permite saber momento a momento la relación entre los componentes y sus instanciaciones. Así, cuando un usuario pretende acceder a un hipertexto, lo que hace es abrir una sesión. Y esto es lo que será necesario para cada sesión: • el hipertexto que es accedido • los IID de las instanciaciones a componentes de la capa de almacenamiento que 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 de la capa de almacenamiento • una función de instanciación (instantiator), que devolverá, a partir de un UID y una especificación de presentación (otra primitiva del modela que define cómo se “presentará” un componente), una instanciación del componente como parte de la sesión.


Pág. 22


• 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 estado actual de la instanciación. Esto es usado para el mecanismo de “writing-back in cache”, es decir, de crear o modificar el componente en la capa de almacenamiento. Al igual que teníamos un conjunto de funciones que permitían acceder y modificar la capa de almacenamiento, también tenemos un conjunto de operaciones que nos lo permiten sobre la capa de tiempo de ejecución. Estas operaciones, sobre las que tampoco profundizaremos, nos permiten, entre otras cosas, crear una sesión, crear una instanciación para un componente, actuar sobre el componente asociado con la presentación, seguir un enlace, ...

2.1.4. Conclusiones Dexter fue el primer intento de modelar el hipertexto y de dar una terminología común para este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de 1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que son hoy. De hecho, la principal carencia que se puede observar en este modelo es que, a pesar de que los autores lo recomiendan para tanto hipertexto como hipermedia, no aborda en ningún momento la complejidad de los distintos medios. En realidad, se podría decir que el modelo está fundamentalmente destinado sólo a hipertexto, y la aplicación a la hipermedia es muy difícil. Por ejemplo, el concepto de valor del ancla lo hace en funció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, algo fundamental en el audio y el vídeo. Es por ello que posteriormente apareció el modelo de 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 utilizar en 1988), el modelo especifica, por primera vez y muy detalladamente, cómo es la estructura interna de un hipertexto. Incluso define unas estructuras que no habían sido utilizadas hasta entonces 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 por aquel entonces muchos sistemas de hipertexto no soportaban.


Pág. 23


2.2. Modelo de hipermedia de Amsterdam Hipermedia es la suma de hipertexto y multimedia. El hipertexto nos provee de una estructura de navegación a través de los datos, mientras que la multimedia nos ofrece como punto fundamental una gran riqueza de tipos de datos. Sin embargo, el modelo de Dexter, aunque según sus autores está orientado a hipermedia, la realidad es que se centra por completo en el hipertexto, dejando de lado el estudio de la variedad de tipos posibles. Y entre esos tipos, no hay que olvidar que los hay dependientes del tiempo. Por tanto, el modelo de Dexter comete un gran olvido: no toma en consideración el concepto del tiempo. Se hace necesario un nuevo modelo de datos multimedia, en el que se van a ver reflejadas relaciones complejas en tiempo. Por ejemplo, es necesario contemplar algo tan típico en una aplicación hipermedia como que a los 4 seg. de que se active un vídeo, aparezca cierto texto (sincronización entre componentes). Sobre estos conceptos surge el Modelo de Hipermedia de Amsterdam (AHM). En resumen, mientras que el modelo de Dexter permite la composición de estructuras jerárquicas, la especificación de enlaces entre componentes y el uso de anclas, el modelo de Amsterdam lo extiende añadiendo las nociones de tiempo, presentación a alto nivel de atributos y enlaces de contexto. Hay cierto vocabulario ligeramente diferente al empleado en Dexter: un documento es una colección completa de componentes, cada uno de los cuales puede estar compuesto de otros componentes, o bien de componentes atómicos, llamados aquí elementos de datos (data elements) o también entidades. Una presentación es la forma activa de un documento. 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 medios dinámicos que dependan del tiempo. El concepto fundamental es la sincronización entre ellos.


Pág. 24


tiempo

tiempo

(a)

(b)

Componentes (de varios medios)

(c)

Enlace

En la parte (a) de la figura, tenemos una red de hipertexto con enlaces entre componentes. La visita a un componente termina bien por la finalización de la aplicación o bien por el paso a otro componente a través de un enlace. Aquí el tiempo apenas cuenta y tenemos básicamente hipertexto. En la parte (b) de la figura, tenemos una presentación multimedia. El usuario controla qué componente quiere visitar, pero ese componente puede ser dinámico, es decir que varía sin la intervención del usuario, según una noción temporal. Dos tipos de control del usuario sobre las presentaciones se permiten aquí. La primera, la típica similar al panel de control de un cassette o vídeo-reproductor, con los controles stop/play/fast forward/rewind. La segunda sería similar a un enlace hipertextual y nos llevaría de un punto temporal del componente a otro (sería similar a un fast forward pero parando en un punto definido de antemano). La parte (c) de la figura muestra la combinación entre hipertexto y multimedia: cada componente de la red hipertexto es una presentación multimedia. Así, hay dos aspectos a tener en cuenta, que son la navegación hiperestructurada dentro del documento y la presentación de la información multimedia. Esto sería hipermedia específicamente.


Pág. 25


2.2.1.2. Información temporal En general, un modelo de hipermedia debería ser capaz de especificar cómo las partes individuales se relacionan unas con otras. Una de esas relaciones es evidentemente la temporal. De hecho, a menudo, estas relaciones temporales se han representado como un simple enlace hipertextual. Esto es conceptualmente un error, ya que así se mezclan dos aspectos separados de una presentación como son las relaciones hipertextuales y las temporales. La solución que se propone en Amsterdam es la de particionar las relaciones temporales entre datos en dos clases: • aquellas que se refieren a la identificación de los componentes que estarán presentes conjuntamente. A esta clase se la denomina colección. • aquellas que se refieren al orden relativo en el que estos componentes son presentados. A esta clase se le da el nombre de sincronización. Los componentes compuestos de Dexter pueden ser usados para “recoger” un conjunto de componentes atómicos que van a ser presentados juntos. Pero esta definición no nos ofrece un mecanismo para especificar ninguna relación temporal. El problema es la sincronización entre esos componentes. Así la sincronización puede estar basada bien en informació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 de un hipermedia. A continuación mostramos tres diferentes estrategias:

tiempo

tiempo

(a)

tiempo

(b)

Componentes (de varios medios)


(c)

Enlace

Pág. 26


(a) Estructura oculta La manera más básica y más frecuente de manejar los datos dependientes del tiempo consiste en poner todos estos datos dentro un único componente. En el diagrama vemos que tenemos cuatro media diferentes, y queda explicitado el instante en que son activados cada uno de ellos. Esta solución no requiere apenas ningún cambio en relación al modelo de Dexter. Todo queda definido en términos de la capa del componente y la sincronización usa técnicas internas (ocultas). Como contrapartida, no permite definir combinaciones de datos más complejas. (b) Estructura separada Éste es el caso completamente opuesto. Aquí, cada parte de información multimedia forma un bloque diferenciado. La colección queda representada mediante un enlace multi-destino que apunte al inicio de todos los bloques (mientras que en la solución anterior únicamente era necesario un único enlace que apuntara al inicio del componente). Cruzar el enlace significará activar ese componente. Mientras que la colección es fácilmente representable, la sincronización no lo es tanto, ya que hace falta algún mecanismo para determinar cuándo un componente debe iniciarse en relación a los otros. Por tanto, los inconvenientes de este método son que añaden una gran complejidad dado el gran número de enlaces que son necesarios crear y mantener. Cualquier herramienta tendrá que ser compleja y con una difícil interfaz 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. Estas componentes compuestas pueden agrupar uno o varios medias. La colección es más simple que en la segunda solución y el problema de la sincronización queda reducido a relaciones internas. A menudo, la solución no será simplemente elegir entre uno de estos tres enfoques. De hecho esto sólo ocurrirá con hipermedias pequeños. Lo habitual será descomponer el problema en pequeños sub-problemas, a cada uno de los cuales sí que les aplicaremos una 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 que se visualizan simultáneamente, pero no son éstos sus aspectos fundamentales, ya que el objetivo de un enlace debería ser definir un mecanismo de navegación lógica en un documento.


Pág. 27


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 puede ser 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ón de un enlace con o dentro de un componente es mucho más compleja, ya que los datos a menudo no pueden ser fragmentados ni indexados. Otro problema que no se trata en Dexter es el que se refiere a cuánta información deja el usuario al navegar a través de un enlace. En un sistema de hipertexto, al cruzar un enlace, o bien se abre una nueva ventana, o bien se sustituye lo que se estaba visualizando por la información nueva. Esto es indicado aquí porque el usuario sólo puede leer una cosa a la vez. Pero en un entorno hipermedia, puede interesarle, por ejemplo, seguir oyendo una explicación, viendo el mismo vídeo, pero pasar a ver una nueva imagen o texto, dependiendo del lugar en que se encuentre de la aplicación. Para tratar 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 datos propios; pero, además, todas las pantallas tienen elementos que comparten un conjunto común de atributos para un tipo de datos en concreto. Por ejemplo, imaginemos un audio que se utiliza a lo largo de una presentación. En cada pantalla se usan diferentes conjuntos de datos de audio, pero todas las pantallas compartirán unos atributos como el volumen o la calidad del tono, los cuales no queremos que cambien cada vez que pasemos de una pantalla a otra. Por tanto, estos atributos tienen una definición global para toda la presentación y serán asociados no sólo a un componente, sino a toda un tipo de información (o medio). Estos atributos globales, que no se consideraron en el modelo de Dexter, se manejan utilizando 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 no habían sido contemplados. ha sido empleado para desarrollar numerosas aplicaciones hipermedia.

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


Pág. 28


Especificación de presentación

nombre del canal duración - explícita o implícita info. de esp. pres. de otros

Atributos Anclas

Contenidos

info. semántica (incluido el ID) id valor

datos

Componente compuesto: Especificación de presentación Arcos de sincronización

Atributos Anclas

Tipo de composición Arcos de sincronización

info de esp. pres. del componente id componente origen id componente destino relación temporal

info. semántica (incluido el id) id lista de (id componente - id ancla)

Opción o paralelo id componente tiempo de inicio

Vemos que un componente compuesto no contiene datos, sino que sólo los datos sólo pueden 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 componentes atómicas, mientras que la estructura de la presentación se deja para las componentes compuestas. En teoría, esto facilita las tareas de mantenimiento.


Pág. 29


• Promueve la reusabilidad de datos al forzar que todos los elementos se mantengan por separado. • Modela de forma más aproximada la forma en que la información multimedia se 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 de Dexter es el campo de presentación, en el cual una se dedica a aspectos relacionados con el tiempo. En cuanto a los componentes compuestos, se añaden varios elementos nuevos, respecto a Dexter. La diferencia principal es que ahora es usado para especificar la estructura de una 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 una información sobre el orden relativo de los componentes atómicos en la presentación, y que veremos posteriormente con más detalle. Tanto las anclas como el campo de atributos son similares a Dexter, con una pequeña diferencia: en los componentes compuestos se añade un tipo de composición a la lista de parejas . É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 relaciones temporales entre entidades son las componentes compuestas. Hay dos tipos de sincronización entre componentes, una calificada como de grano grueso y otra de grano fino. La primera es aquella que consiste en restricciones definidas entre los hijos de una componente compuesta (que recordemos que pueden ser componentes atómicas o compuestas), como por ejemplo el instante relativo de comienzo 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 grueso consiste en relaciones entre dos hijos (que pueden o no estar al mismo nivel, es decir que pueden o no ser hermanos) explicitados mediante lo que llamamos un arco de sincronización. Un arco de sincronización no se usa como un enlace navegacional, sino que constituye un mecanismo flexible para establecer relaciones temporales dentro del sistema hipermedia. El modo de especificar las relaciones temporales en AHM tiene la ventaja de que hay una clara separación entre la colección de componentes que se muestran juntas, el orden Antonio Navarrete Terrasa

Pág. 30


relativo en el lo hacen y las relaciones temporales específicas que existen durante una presentació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 comporta cada 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 un enlace. El mecanismo de contexto permite definir unas opciones de visualización diferentes para cada enlace. En particular, puede ser que parte de la información continúe visible, mientras que otra deja de estarlo. La ventaja de esto es que, por un lado, sólo una parte de la estructura del documento se ve afectada al seguir un enlace, y por otro, se nos ofrece una gran flexibilidad.

2.2.4.2. Canales Terminaremos este apartado con el concepto de canales. Éstos son salidas abstractas utilizadas para reproducir los contenidos de un componente. Asociado con cada canal hay unas características de la presentación. Éstas pueden ser dependientes de los tipos de datos (media), como la fuente y estilo de un texto o el volumen de un sonido; pero también pueden ser independientes, como por ejemplo los colores de background y foreground. Un uso típico puede verse en una situación en que deseamos una aplicación hipermedia en dos idiomas, por ejemplo castellano y catalán. Imaginemos que tenemos un vídeo acompañados de un audio y un texto explicativos. Necesitaríamos un canal de vídeo (el mismo si estamos en catalán o castellano), y luego dos canales de audio y otros dos de texto. Así se consigue una independencia entre los datos y la presentación, así como un gran dinamismo en estas últimas.

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


Pág. 31


III - El modelo HDM

Capítulo III EL MODELO HDM HDM (Hypertext Design Model) fue creado por los profesores Franca Garzotto y Paolo Paolini del Politencnico di Milano y por Daniel Schwabe de la Pontificia Universidade Católica do Río de Janeiro en 1991, en parte en el marco del proyecto de la Comunidad Europea HYTEA. El objetivo es crear un modelo que sea de utilidad para realizar el diseño de una aplicación de hipertexto (o hipermedia). Al desarrollar una aplicación hipermedia se pueden identificar dos tipos principales de trabajos: los globales, tales como definir las clases de elementos de información y estructuras navegacionales de la aplicación; por otro lado, los locales, tales como llenar los contenidos de los nodos. Esto es similar a lo que ocurre en la ingeniería del software tradicional al diseñar un sistema modular: por un lado están las tareas de diseñar la estructura y interconexiones entre módulos, y por el otro, escribir el código de los mó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 aspectos globales, estructurales de la aplicación, y authoring-in-the-small, para referirnos al desarrollo 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 el authoring-in-the-small es específico para cada área de la aplicación. De hecho, aunque ambas están siempre interrelacionadas, la segunda suele depender de las herramientas que 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í un resumen de ellas: • Mejora de la comunicación: el modelo proporciona un lenguaje que permite comunicar al analista y al usuario. Asimismo, también mejora la comunicación entre los distintos integrantes del equipo, a menudo formados en campos muy diferentes y con un lenguaje muy diferente. • Reusabilidad: el hecho de tener representada la estructura, permite reutilizar los esqueletos de esa estructura o sub-estructuras a la hora de desarrollar nuevas aplicaciones. • Evitar inconsistencias estructurales: como consecuencia se obtendrá una navegación predictible y consistente.


Pág. 32


III - El modelo HDM

• Permite evaluar aplicaciones ya desarrolladas en base a su estructura: es lo que los autores denominan evaluación orientada al diseño. • Base para crear herramientas CASE que ayuden en el desarrollo.


Pág. 33


III - El modelo HDM

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 parte autónoma de la información, es decir, que no necesita ninguna otra información para tener un sentido total. Las entidades se agrupan en tipos de entidades. Una entidad es una jerarquía de componentes, los cuales están formados a su vez por unidades. El concepto de unidad es similar al de nodo, mientras que un componente es un conjunto de nodos que crean una unidad 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 muestre la 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 que define el tipo de entidad. Componente raíz (vida del pintor)

Entidad pintor Goya

Componente La Maja Desnuda

Unidades

Componente La Maja Vestida enlace estructural enlace de componente

Las estructuras se interconectan por medio de enlaces. Hay tres tipos diferentes: • enlaces estructurales que conectan componentes de la misma entidad. • enlaces de componente (o de perspectiva), que conectan unidades dentro de un componente. • enlaces de aplicación, que conectan componentes y entidades de distinto tipo. 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”. Antonio Navarrete Terrasa

Pág. 34


III - El modelo HDM

Nótese que de estas primitivas, las hay que hacen referencia a la parte de in-the-large y otras a la parte in-the-small. En concreto, las entidades y enlaces estructurales son inthe-large, mientras que las unidades, componentes y enlaces de componentes son in-thesmall. Veamos con 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 representa algú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, que corresponden 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ía relacional. 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, que son los contenedores de la información. Un componente dentro de la jerarquía de la entidad, en general tiene un padre (excepto en el caso del componente raíz), varios hermanos, y un número de hijos (excepto en los componentes hoja -los últimos de la jerarquía-). Pero un componente sólo puede existir como parte de una entidad, y no tiene sentido por sí mismo, es decir, no es autónomo. Por tal razón en el modelo HDM no se permite que unas entidades sean componentes de otras entidades. En cuanto a la jerarquía que estructura los componentes de una entidad, ésta puede ser según muy diversos criterios semánticos. En particular, una de las más utilizadas es la de “todo-parte”.

3.2.3. Perspectivas En HDM la noción de tener diferentes presentaciones del mismo contenido se representa mediante el concepto de perspectiva. Por ejemplo, una aplicación multilingüe, la misma informació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.


Pág. 35


III - El modelo HDM

3.2.4. Unidades Una unidad es un conjunto de partes atómicas de información que se muestran conjuntamente, como una unidad. Una unidad corresponde a un componente asociado con una perspectiva específica. Una unidad se caracteriza por un nombre (su identificador) y un cuerpo. Los cuerpos de las unidades son el lugar donde queda almacenada la información. Por ejemplo, en la entidad que describimos anteriormente (Goya), el componente “La Maja 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 en castellano, y por otro lado las asociadas a la perspectiva en catalán “Explicación del cuadro (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 hipertexto tradicional de “nodo”. Aunque los autores no lo recomiendan, diferentes unidades pueden compartir el mismo cuerpo. Según los autores, esto conlleva una desorientación para el usuario, aunque por otra parte, fomentaría la reusabilidad.

3.2.4. Enlaces en general Los enlaces en hipertexto tienen una doble función: por un lado representar las relaciones entre elementos del dominio (entidades, componentes o unidades), y por otro, una función de navegación (representar los patrones navegacionales). A menudo, estas dos funciones son consistentes entre sí, aunque no siempre: puede ocurrir que las relaciones de dominio no sean relevantes para la navegación, o que un enlace navegacional interesante no se tenga ningún contenido semántico. Por tanto, la definición de enlace debe reflejar ambas funciones. Para ello se identifican tres 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 este tipo 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 Maja Desnuda”, en la entidad “Goya”. Antonio Navarrete Terrasa

Pág. 36


III - El modelo HDM

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 algo más complejos que los de perspectiva, pero bastante simples. Hay varios tipos, como por ejemplo: de un componente a su hermano, de un componente a su hijo o a su padre, ...

3.2.7. Enlaces de aplicación y tipos de enlaces Representan relaciones de dominio entre entidades o sus componentes. Estas relaciones son las elegidas por el autor como navegacional y semánticamente relevantes. Los enlaces de aplicación se estructuran en tipos, llamados tipos de enlaces de aplicació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ía el que uniría el tipo de entidad “Pintor” con el tipo de entidad “Periodo histórico”, al que 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 que se citó anteriormente entre las entidades “Goya” y “Siglos XVIII y XIX”, ya que pertenece al tipo “Periodo del pintor”. • Genéricos: no pertenece a ningún tipo de enlace. Son independientes de la estructura, y por tanto menos estandarizados. Un ejemplo podría ser un enlace entre “Goya” y otro pintor en el que influyó posteriormente. Este enlace no sigue un patrón, sino que el autor del hipertexto lo incluye para este caso concreto.

3.2.8. Esquema HDM Una especificación de un hipertexto consta de una definición de esquema y un conjunto de definiciones de instancias. Un esquema especifica un conjunto de tipos de entidad y tipos de enlace. Las instancias se introducen en el sistema sólo si cumplen las restricciones establecidas en el esquema. El concepto de esquema en hipertexto es novedoso, pero ya ha sido ampliamente utilizado en el campo de las bases de datos.


Pág. 37


III - El modelo HDM

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.


Pág. 38


III - El modelo HDM

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 evaluar aplicaciones. 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 sean temporales 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 la informació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 y provechosa. El proceso consiste en realizar un modelo de la aplicación utilizando HDM, analizar los resultados buscando inconsistencias en la estructura y mecanismos de navegación. En dicho artículo, los autores evalúan una aplicación de Microsoft, llamada “Art Gallery”, un catálogo hipermedia en CD-ROM de la National Gallery de Londres. A pesar 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. Antonio Navarrete Terrasa

Pág. 39


III - El modelo HDM

• 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 de la estructura, no estandarizados; por tanto no tiene sentido su análisis, ya que el autor los define con completa libertad.


Pág. 40


III - El modelo HDM

3.4. Conclusiones HDM es más que un intento de modelar la estructura del hipertexto-hipermedia, una modelización de las estructuras de navegación. Crear un modelo antes de desarrollar nos ayudará a conseguir una navegación más consistente y rica. En HDM la estructura de navegació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 siguiendo las normas de HDM es extremadamente complicado cuando el número de entidades involucradas crece. En particular, era imposible representar la estructura de MINTour utilizando este modelo. Nosotros, por tanto, destacamos de esta propuesta la importancia de modelizar antes de desarrollar y de la utilidad de un modelo a la hora de analizar aplicaciones ya desarrolladas, si bien consideramos que HDM no es la herramienta de modelado más adecuada.


Pág. 41


IV - La metodología RMM

Capítulo IV LA METODOLOGÍA RMM La metodología RMM (Relationship Management Methodology) ha sido ideada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catálogos, front-ends de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos volátiles, que cambian 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. El primero es el basado en los llamados slices mínimos e híbridos y m-slices, además de una profundización en las etapas de la interfaz de usuario y construcción. En el segundo veremos 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 Management Data Model), que se genera a partir de un diagrama entidad-relación. Con él se describirá no sólo la información referente a las clases de objetos, sino también a la navegación entre ellos. Así, hay definidas unas primitivas para modelar los dominios (clases de objetos) y otras para el acceso a tales objetos. De entre las primeras, la más típica es la entidad. Como en la teoría relacional una entidad está compuesta por varios atributos. Además, en RMDM se incorpora una nueva primitiva muy importante denominada slice, que define conjuntos de atributos de una entidad que se agrupan de forma lógica (volveremos a hablar de ello). Una entidad se representa mediante un recuadro y su nombre, mientras que un slice se representa mediante a una figura similar a una gota de agua. Lo vemos a continuación:


Pág. 42



nombre

Hotel

dirección CP fax

Entidad Hotel

teléfono email ...

Slice de la entidad Hotel

En cuanto a las primitivas de acceso, se definen tres tipos de acceso diferentes. Para ver qué significa cada una veremos un ejemplo. Supongamos una entidad “Hotel”. Las instancias de esta entidad se pueden visitar según esos tres tipos de acceso: • Índice condicional (Conditional Index) : en una pantalla aparecerá un índice alfabético de los nombres de los hoteles, y pulsando sobre uno, iremos a ver su 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, por ejemplo, un mapa, donde al pulsar sobre una ciudad, se visitase su información. Veamos cómo se representa:

Hotel

• Visita guiada condicional (Conditional Guided Tour) : de la pantalla inicial se nos 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 los anteriores. Se permite volver a visitar al anterior hotel. En definitiva, es una estructura de acceso secuencial. Ésta es su representación gráfica: Antonio Navarrete Terrasa

Pág. 43



Hotel

• Visita guiada indexada condicional (Conditional Indexed Guided Tour) : es una solución híbrida, donde tenemos un índice para acceder puntualmente a los elementos de la entidad, pero también se nos permite la navegación secuencial 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 se representa un menú. De una primitiva grupo colgarán tantas opciones como queremos que haya en el menú. La primitiva de grupo, o a la que a veces también denominaremos de menú, se representa mediante un triángulo invertido

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


Pág. 44


Hotel

Hotel


Hotel

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

Primitivas de datos

Entidad Entidad

Atributo Slice

Primitivas de acceso

atributo

Índice

Visita guiada

Visita guiada indexada

Grupo

Enlace


Pág. 45



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 de los requerimientos (tanto de la información como de la navegación). También debe hacerse 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 es aplicable 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 las relaciones N:M en dos relaciones 1:N, como muestra el ejemplo:

A

B

A

B

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, las relaciones darán lugar a la navegación. Así, una relación especificará un camino en la navegación. Veamos un ejemplo que después continuaremos a lo largo de las siguientes fases. Se trata 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 una determinada categoría (también relación 1:N). Lo mismo ocurre entre hotel y sus habitaciones (1:N) y por último tenemos una relación N:M entre hotel y servicio, ya que un hotel tiene varios servicios y un servicio concreto se da en varios hoteles. Esta relación N:M, como explicamos antes la desglosaremos en dos relaciones 1:N.


Pág. 46



Ciudad

Categoría

Hotel

Habitación

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 en la red de navegación. Por ejemplo, toda la información de un hotel la podríamos colocar en una ventana con scroll o bien en varias diferentes. Esta división se hace según la semántica de los atributos. Por ejemplo podríamos tener en un slice los datos generales del 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. Cada entidad tendrá su head, o slice principal, que se marca con un asterisco y que es slice al que, por defecto, se accede a través de los mecanismos de navegación. Entre los diferentes slices están los llamados enlaces estructurales, que nada tienen que ver con las relaciones, ya que al atravesar un enlace estructural, no se produce ningún cambio de contexto. Veamos como podríamos dividir la entidad hotel en slices. Para hacerlo no seguiremos la notación que los autores recomiendan ya que es muy engorrosa. Nosotros, no sólo en este ejemplo sino en todos los casos de estudio, utilizaremos una tabla donde se especifican los slices de cada entidad y los atributos que corresponden a cada uno de ellos. General * (head)


Nombre Dirección Teléfono Fax Mail URL Número de plantas Año construcción Pág. 47



Número de habitaciones Cómo llegar Distancia a la playa Distancia al aeropuerto Distancia a la capital Distancia a parada bus Vídeo

Localización

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 de navegació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 instancias sea 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 son un híbrido, usado frecuentemente cuando hay un índice y se desea una navegación entre las instancias. Además en esta fase hay que elegir a qué slice se accede a través de una primitiva de acceso. Por defecto es el slice principal (head). En caso contrario, debe especificarse, etiquetando el nombre de la estructura de acceso. Por último, en esta fase se establece una jerarquía de menús, utilizando la primitiva de grupo o menú. Como regla general, evitar grandes profundidades en la jerarquía, ya que desorientan al usuario. El resultado final de esta etapa es el diagrama RMDM. Sigamos con nuestro ejemplo. Lo primero es decidir por qué primitiva de acceso sustituimos cada una de las relaciones que nos han resultado en el diagrama entidadAntonio Navarrete Terrasa

Pág. 48



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

Ciudad

Categoría

Hotel

Habitación

Servicio

Aunque siguiendo al pie de la letra se debería especificar un enlace “de vuelta”, si fuera necesario, entre las entidades que tienen una primitiva de acceso -es decir que de un hotel podamos ir a su categoría directamente- nosotros consideramos que siempre este enlace debe estar presente y por tanto no lo representamos en el diagrama, por considerarlo redundante. Así, al tener una estructura de acceso de categoría a sus hoteles, 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 simplemente tenemos un menú principal donde podemos acceder a las ciudades o bien a las categorí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 segundo a una visita guiada indexada de las ciudades. Se representa así:


Pág. 49


Categoría


Ciudad

Hotel

Habitación

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 que necesitaremos (slices), y que luego el diseñador gráfico deberá diseñar y hemos determinado todos los enlaces navegacionales de nuestro sistema, que con esto queda perfectamente modelado.

4.1.2.5. Etapas 4 a 7: Interfaz de usuario y construcción Estas etapas se realizan a partir del diagrama RMDM. Sólo se citan brevemente, ya que el interés de la metodología, así como el nuestro en particular, se centra en las tres primeras etapas que nos conducen a obtener en modelo RMDM. Las siguientes ya no son propias del 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 cada elemento del RMDM en un objeto en la plataforma elegida.

Etapa 5: Diseño de la interfaz de usuario Antonio Navarrete Terrasa

Pág. 50



Diseño gráfico de todas las pantallas correspondientes a cada uno de los slices que 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, hacer backtrackings, permitir enlaces transversales,...

Etapa 7: Construcción y tests Construcción de la aplicación y pruebas, testeando cuidadosamente todos los paths 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 la equivalencia con las etapas tradicionales de una metodología y que comentamos en el capítulo de introducción. Recordemos que éstas eran análisis, diseño e implementación y pruebas. Claramente corresponde al análisis la primera etapa de análisis entidad-relación; de hecho ya vimos que el modelo entidad-relación es la herramienta típica del análisis. La segunda fase, la podemos considerar a caballo entre análisis y diseño, ya que cuenta con una parte de análisis de datos, pero también ya tiene en cuenta las pantallas de que constará 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 claro que las etapas cuarta a sexta perteneces también al diseño, mientras que la última es obvio que se corresponde al cien por cien con lo que denominamos implementación y pruebas.

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


Pág. 51



Según nuestro punto de vista RMM es de gran interés, ya que es el primer caso en el que se crea una metodología completa, con una definición de fases, y no únicamente un modelo de datos. Además está basado en un modelo de datos relacional, lo cual se ajusta perfectamente no sólo a nuestros casos de estudio si no a la gran mayoría de las aplicaciones existentes. Pero, a mi entender, los mecanismos de acceso a la información son excesivamente simples. Pueden ser suficientes para un problema con pocas entidades, como el que los autores incluyen en su artículo, donde sólo tienen siete entidades, o el que nosotros hemos utilizado como ejemplo, que contiene cinco. Un importante problema es que no se permite hacer una consulta a partir de dos entidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles está relacionada con ciudad, N a 1, y ésta a su vez con región, también N a 1, no hay forma de permitir ver todos los hoteles de una región, sino es yendo de ciudad en ciudad y después, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que sería necesario poder establecer un enlace navegacional no sólo entre entidades relacionadas directamente, 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 las consultas han de ser tan simples como que dado una ciudad qué hoteles tiene, que campings, que puertos y aeropuertos, etc. Pero, por ejemplo, sería imposible explicitar una 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 correspondiente a la construcción del diagrama Entidad-Relación, se nos dice que las relaciones N:M se descompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologías como, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad que resulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artículo y que trata de un sistema de cursos, en los que se reflejan los profesores, sus publicaciones, ... En el artículo, los autores rompen la relación N:M entre profesores y cursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero se olvidan de los datos que deben guardarse de la relación original, como por ejemplo cuántas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, con una entidad en medio, no habría forma de saber los cursos que imparte cierto profesor, o qué 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 para problemas con datos que varíen muy frecuentemente. Pero a pesar de eso no se refleja de ninguna forma esa cómo se puede realizar tal modificación de los datos. La realidad es que no se refleja ningún tipo de proceso en esta metodología, que se ciñe estrictamente a la parte de datos. Se debería en próximos trabajos la conveniencia de incluir la posibilidad de definir procesos sencillos tales como, por ejemplo, hacer una reserva de una plaza de hotel. Mi idea es que la solución pasaría por crear una nueva etapa que fuera de definición de procesos, en la que se definieran mediante las técnicas tradicionales de DFDs (Diagramas de Flujo de Datos) y quizás también pseudo-código o diagramas de procesos. Ya que los procesos visualmente no son más que pantallas, una vez definidos éstos, se podría crear una nueva primitiva que representara un proceso, Antonio Navarrete Terrasa

Pág. 52



con el fin de incluirse todos estos procesos en el modelo RMDM, preferentemente en la navegación estructural (interna a la entidad, junto a los slices) para reflejar cómo se llega a ellos. En todo caso, y ya que nuestros casos de estudio sólo reflejan consultas a la información, y no procesos de actualización no se profundizará en esta reflexión en el marco de este proyecto final de carrera. En el siguiente apartado veremos un estudio más detallado de dos intentos de mejora de la 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 mejora añadiendo una serie de nuevas estructuras navegacionales que nos pueden ser especialmente útiles.


Pág. 53



4.2. Evoluciones de RMM En este apartado presentamos una serie de mejoras que, a partir de [BAL96] e [ISO96] se han intentado introducir en la metodología. En primer lugar expondremos las que tienen como objetivo mejorar la estructura de datos y navegación. Posteriormente se tratará sobre un estudio en mayor profundidad de las etapas de interfaz de usuario e implementación, que tan ligeramente fueron tratadas en la primera formulación de RMM.

4.2.1. Estructura de datos y navegación Aquí veremos dos intentos de mejora de las primeras etapas de la metodología. En ambos 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ón original 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. Se trata 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 programa que escribimos para que a partir de los datos que se recuperan de la base de datos, se cree 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 modelo RMDM para hacerlo realmente utilizable. Su propuesta es la de añadir dos tipos nuevos de slices: El slice mínimo (minimal slice), que representa el conjunto de atributos de una entidad que permite que el usuario pueda identificar claramente las diferentes instancias de tal entidad. Este slice 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 deseamos no es que el usuario vea la lista de los identificadores de los diferentes registros, ya que muy probablemente esa información le sea del todo inútil. Se utilizará el slice mínimo para tal fin. Los slices híbridos (hybrid slices) que permiten combinar atributos de diferentes entidades y estructuras de acceso. En la definición original de RMM, los slices estaban formados únicamente por atributos de una misma entidad. Con este añadido se permite que en una pantalla aparezcan informaciones de más de una entidad. Por ejemplo si accedemos de una autor a sus publicaciones, pudiera ser que estuviéramos interesados en mostrar en la misma pantalla la información de la editorial de cada publicación (que se encuentra en otra entidad).


Pág. 54



Con estos tipos de slices se consiguen unas estructuras más dinámicas tanto de navegació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 nuevas mejoras. 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 una pá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 o visita guiada) uno debe de atravesar un enlace. Lo que los autores proponen en el presente artículo es un nuevo tipo de slice, al que denominan m-slice. Según ellos la m viene de las muñecas matrjeska, las típicas muñ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 otros slices (m-slices posiblemente) formadas con atributos de otras entidades, unido todo ello por primitivas de acceso. Recordamos en la siguiente figura cómo según la metodología original se definen los slices. Nota: Nosotros no hemos empleado esta notación en nuestros casos de estudio por ser muy engorrosa.

Slice HOTEL nombr

dirección CP fax teléfono email ...


Pág. 55



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

Hotel Atributos la entidad hotel

Atributos la entidad habitación Habit.

4.2.1.3. Conclusiones La introducción de los slices mínimos e híbridos, se puede considerar como muy provechosa, y será ampliamente utilizada en los casos de estudio, más en concreto en los dos últimos. En cambio, los m-slices son de un provecho más dudoso. Estudiando las tres limitaciones que los autores apuntan, se puede cuestionar que la extensión cubra los objetivos 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 mostrar como ancla, es cierta en la definición inicial de RMM, pero se puede utilizar el 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, al ser la menor parte de información que permite identificar al usuario a tal objeto, será el que se utilice como ancla. 2. Referente a la imposibilidad de agrupar atributos de varias entidades en un slice, ya vimos también en el artículo anterior que la cuestión quedó resuelta con la definición de los slices híbridos, que veremos en el siguiente apartado como 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 un gran error. La segunda fase de la metodología tiene por objeto el identificar Antonio Navarrete Terrasa

Pág. 56



las partes de cada entidad que aparecen diferenciadas entre sí. En la tercera etapa, y a partir del diagrama entidad-relación de la primera, obtenemos las estructuras de acceso entre las entidades. Y lo que no olvidemos es que el modelo se fundamenta en que la estructura de la navegación se basará en la estructura de los datos. Lo que aquí se propone sería hacer la estructura de la navegación no en base a las entidades sino a los slices, es decir a conjuntos de atributos. La idea de los autores suponemos que es el intentar representar que si estamos en una pantalla correspondiente a la entidad “Hotel” y deseamos ver la información de, por ejemplo sus habitaciones, esto se pueda hacer dentro de la misma pantalla, definiendo un m-slice que contenga los atributos correspondientes de ambas entidades, así como la estructura de acceso, por ejemplo un índice. Pero este caso es propio de la presentación, es decir de las etapa 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 entre un hotel y sus habitaciones, puede ahí definir que desea que el slice correspondiente de la entidad hotel y el correspondiente de la entidad habitación aparezcan en la misma pantalla. Lo que no tiene sentido es hacer esto en la etapa de análisis. Así pues, los m-slices, por lo menos en su formulación actual, no serán pues utilizados en 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 de diseño navegacional. Son las que se denominan de interfaz de usuario y construcción y sobre las cuales en la descripción original de la metodología sólo se daba una muy breve guía. Mientras que las tres primeras etapas cubren el diseño lógico de una aplicación, estas se corresponden 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 modelo RMDM en un objeto en la plataforma elegida. Lo que se debe hacer es producir una serie de reglas, ya sea mediante un programa automático de conversión o como una serie de instrucciones a los programadores, que permitan convertir las entidades, atributos y estructuras de acceso. En este caso de estudio, en el que hay una base de datos conectado al servidor web, las entidades se convierten en tablas de la base de datos y los atributos en columnas de esas tablas. En cuanto a las estructuras de acceso, los índices se convierten en resultados de consultas a la base de datos (son variables según el contenido de la misma). Antonio Navarrete Terrasa

Pág. 57



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 del modelo 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 situarse las citadas herramientas de navegación Generalmente esta etapa se presta al prototipado, ya sea sobre papel (lo que los autores denominan prototipos low-fidelity) o por ordenador (prototipos high-fidelity). 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 los datos de una base de datos, para esta fase es ideal hacer el diseño de todas las páginas HTML. Así, se crearán todas las páginas correspondientes a cada slice de cada entidad y cada índice, en HTML, con datos estáticos. Esto nos será de gran ayuda para el prototipado y por tanto para que el cliente pueda ver cuál será el aspecto de la aplicación. Como ya citamos en los cuatro puntos a tener en cuenta, un aspecto muy importante que también hay que decidir es la representación de los anclas de los enlaces. Puede ser una buena solución el identificar cada una de las entidades mediante un icono. Así, si estamos en la pantalla correspondiente a un escritor, tendremos un icono que represente la entidad publicación y que al pulsar en él nos envíe al correspondiente índice de publicaciones de dicho escritor (o a la primera pantalla de la correspondiente visita guiada si éste fuera el método de acceso). No obstante en la aplicación del LINKBase los autores decidieron no utilizar elementos iconográficos sino sólo referencias textuales para identificar los enlaces. Otro aspecto a resaltar es la conveniencia de diferenciar los enlaces estructurales (internos a una entidad: enlaces entre slices) y los enlaces entre diferentes entidades.

4.2.2.3. Etapa 6: Diseño del comportamiento en tiempo de ejecución En esta etapa hay que diseñar los algoritmos para los programas que generarán y recuperarán la información de nuestra aplicación, así como el control de la historia de navegación (backtracking), y otros mecanismos.


Pág. 58



En el caso de LINKBase, en esta fase hay que especificar el algoritmo para cada una de las CGIs de la aplicación (tanto para acceder a la base de datos como para el control de los demás mecanismos), mientras que será en la fase siguiente en la que se programe la CGI 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ón generada en todas las etapas anteriores. Se construye la base de datos física a partir del modelo entidad-relación de la etapa 1 y de los protocolos de conversión de la fase 4. Y también se programan todos los algoritmos diseñados en la etapa anterior. Como puede apreciarse las dos últimas etapas están muy ligadas, y nosotros consideramos que perfectamente se podrían haber considerado como una única. Para acabar hay que testear la aplicación, lo que conlleva comprobar todos los enlaces posibles.

4.2.2.5. Conclusiones Se han tratado las fases de la metodología sobre las que apenas se había hablado en la primera formulación de RMM. El aspecto más destacado de este nuevo estudio, es bajo nuestro punto de vista la etapa del diseño de la interfaz de usuario, donde se comentan los aspectos más importantes que se deben considerar durante esta fase. Visto esto, consideramos que hay una organización de la pantalla 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 los autores no la tuvieron en cuenta, quizás porque los navegadores de aquel entonces aún no tenían soporte para ello. Se trata del uso de marcos (frames) de HTML (aunque también se pueden utilizar tablas con el mismo objetivo). Así, podríamos tener un marco principal la información del objeto seleccionado. Y además tres marcos más, con otros colores para diferenciarlos, y dispuestos como el diseñador lo estime oportuno que contendrían los elementos navegacionales, respectivamente: • Enlaces a otras entidades • Enlaces a otros slices • Herramientas navegacionales (backtracking y otros) De esta manera se obtiene una interfaz simple y significativa, útil para la navegación en muchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo de plataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de la pantalla en varias áreas.


Pág. 59



4.3. Mejoras en estructuras navegacionales para RMM Como hemos visto en los apartados anteriores, RMM resulta un muy interesante intento de establecer una metodología para el desarrollo de aplicaciones multimedia, y que está especialmente indicada para aplicaciones basadas en bases de datos relacionales. No obstante, presenta una serie de carencias en las formas de navegación, a pesar de los intentos de mejoras que hemos analizado en los dos apartados anteriores, basados en la introducción de nuevos tipos de slices. El hecho es que en el modelo RMDM sólo se permite navegar entre entidades que estén directamente relacionadas. Para mejorar la metodología es fundamental encontrar nuevos patrones, nuevas formas de navegar, nuevas primitivas de acceso que nos ayuden a identificar enlaces navegacionales de una forma estructurada y regular. A continuación se exponen tres casos concretos que darán origen a tres nuevas formas de 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. La idea es permitir acceder jerárquicamente, es decir de una cualquier punto de la cadena hacia abajo, con cualquiera de las primitivas de acceso. Veamos un ejemplo que muestre la necesidad de este caso:

Nación

Región

Provincia

Ciudad

Camping

Aquí sólo podemos navegar por los campings de una ciudad. Pero si cuando estamos visualizando la información de una provincia, región o nación quisiéramos acceder a sus campings, 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. Antonio Navarrete Terrasa

Pág. 60



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 de relaciones 1:N, se debe permitir bajar a través de la cadena. Siguiendo con el mismo ejemplo, también es interesante poder acceder desde una nación a las ciudades sin pasar por las regiones o provincias. Téngase en cuenta que a menudo se conoce la ciudad pero no a qué provincia pertenece. Además, el poder acceder directamente es de una importancia mayor en una aplicación sobre Internet, ya que 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 las relaciones jerárquicas. Lo vemos en el siguiente diagrama, donde las líneas que aparecen discontinuas indican que hay el enlace navegacional no parte directamente de una relación, sino que de una inferencia.

Nación

Región

Provincia

Ciudad

Camping

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


Pág. 61



Carrera

Asignatura

Profesor

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

Carrera

Asignatura

Profesor

4.3.2. Caso B: acceos en relaciones N:M Un fallo que se puede encontrar en la especificación de la etapa S1, diseño del diagrama entidad-relación, es el obligar a separar las relaciones N:M, directamente en dos relaciones 1:N.


Pág. 62



Profesor

Asignatura

Profesor

Asignatura

En otras metodologías como, por ejemplo, SSADM, ya se hace algo similar, pero lo que no se puede hacer es obviar la entidad que resulta en medio. En el artículo, los autores rompen la relación N:M entre profesores y cursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero se olvidan de los datos que deben guardarse de la relación original, como por ejemplo podría ser cuántas horas imparte el profesor de esa asignatura. Y no lo hacen porque entonces, con una entidad en medio, aplicando RMM a raja tabla, no habría forma de saber los cursos que imparte cierto profesor, o qué 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 entidad intermedia en la relación: Tipo de camarote

Barco

Barco/ Camarote

Este ejemplo está extraído de MINTour. La entidad “barco/camarote” es la resultante de la relación N:M entre “barco” y “tipo de camarote”. Esta entidad es necesaria ya que hay que 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 es acceder 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 la entidad “barco/camarote”, donde sólo tenemos los códigos de barco y tipo de camarote y el precio. En general, en toda relación N:M, aunque haya una entidad en medio, debe permitirse el acceso de un extremo a otro de la relación, aunque mostrando de alguna manera los datos de la entidad intermedia. Antonio Navarrete Terrasa

Pág. 63



Para reflejarlo, crearemos una nueva primitiva de acceso que permita acceder de una entidad a otra (ya sea con un índice, una visita guiada o una visita guiada indexada), pero teniendo en cuenta la intermedia. Para reflejarlo, simplemente, unimos la primitiva de acceso seleccionada con la entidad intermedia. Lo vemos en la figura:

Barco/Camarote

Tipo de camarote

Barco

Barco/Camarote

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

Alumno

Asignatura

Alumno/ Asignatura

Aquí tenemos un caso como el anterior, donde en la entidad “alumno/asignatura” se deben guardar cosas como “número de convocatoria”, “nota final”, “fecha de matriculación”, etc. Así, hay que, como antes, permitir el acceso de extremo a extremo. El resultado es el siguiente diagrama:


Pág. 64



Alumno/Asignatura

Alumno

Asignatura

Alumno/Asignatura

Pero hay que notar que lo normal es que la entidad “alumno/asignatura” tome el nombre de “matrícula”. Esto hace que, a la vista de un diagrama entidad relación no siempre sea fácil identificar las entidades provenientes de relaciones N:M, ya que si bien el primer nombre lo indicaba con claridad, el segundo no. Por tanto, lo que hay que hacer es buscar patrones de la forma:

A

C

B

y decidir después si es necesaria la navegación directa entre las entidades A y B; muchas veces 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:

Provincia

Ciudad

Hotel

Categoría

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


Pág. 65



Vemos que la relación entre “categoría” y “hotel”, en general, no tiene sentido que sea navegable, pues suele ser poco útil acceder a todos los hoteles de Europa de una determinada categoría. Pero sí lo sería si no se cogen todos los hoteles de Europa sino sólo un subconjunto de ellos, como por ejemplo los que pertenecen a una ciudad o provincia. Esto, que a nivel de entidades no parece complejo (lo más difícil será identificar las relaciones 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 a los 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 un acceso múltiple, ya sea mediante un índice, una visita guiada o una visita guiada indexada. Las nuevas primitivas son:

Visita guiada múltiple

Índice múltiple

Visita guiada indexada múltiple

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

A

C

B


Pág. 66



donde navegamos utilizando un índice desde la entidad A hasta la entidad B pero seleccionando un elemento de la entidad C. Veamos cómo se aplica esto a nuestro ejemplo del hotel, la categoría y la ciudad:

Provincia

Ciudad

Hotel

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 una categoría se podrá seleccionar una ciudad y ver los hoteles de esa categoría en esa ciudad. Evidentemente a este diagrama también le podríamos aplicar lo que vimos en el primer caso, y permitir ver no sólo los hoteles de cierta categoría de una ciudad, sino también los de una provincia. El resultado sería el siguiente diagrama:

Provincia

Ciudad

Hotel

Categoría

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

Pág. 67



sí misma, y en el proyecto MINTour es una de las más importantes, sin duda mucho más que categoría. Además el estudio en casos prácticos nos deparó que en ciertas ocasiones también son interesantes estas primitivas de acceso múltiples en situaciones en las que la estructura todo-parte no se da. Veamos dos ejemplos: El primero está extraído del Atles de les Illes Balears. En él, tenemos que cada parte de la información fundamental del atlas es el cruce entre un tema y el área geográfica. Por ejemplo, un punto de información será Carreteras Secundarias en Menorca, otro Carreteras Secundarias en Mallorca, ... En este caso, no está claro de que lo que tengamos sea una estructura todo-parte o una relación N:M, pero lo que está claro es que lo 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

Información

Tema

Área Geográfica

Área Geográfica

Información

Veamos otro ejemplo, extraído de MINTour. En este caso, tenemos que lo que se desea es que, seleccionado un vuelo, ver lo que puede costar. Pero ese precio depende de la tarifa que deseemos. Por tanto lo que nos interesa es seleccionar esa tarifa antes de ver el precio. Sin duda este es el resultado de la 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 de reflejar la navegación que deseamos es mediante accesos múltiples.

Vuelo

Vuelo

Precio Vuelo

Tipo Tarifa Aérea

Tipo Tarifa Aérea Precio Vuelo


Pág. 68



La conclusión a la que llegamos después de éstos y toda una serie de casos que se nos han presentado es que los accesos múltiples no son únicamente el resultado de una estructura 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 vimos en 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 interesa más en cada caso: si el que vimos en el apartado anterior, éste o, simplemente, el natural que se refleja en RMM (navegando a la entidad intermedia). En concreto, en lo que hace referencia a las estructuras todo-parte, podemos apreciar que prácticamente la solución idónea es la de los accesos múltiples, ya que lo que nos permitirá es reducir el número de 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ón resumimos: • navegación jerárquica: al tener varias relaciones 1:N encadenadas, se permite navegar 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, se representarán con trazo discontinuo. • navegación en relaciones N:M: se permite navegar de un extremo al otro de la relación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberán incluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidad intermedia. • navegación múltiple: se crean unas nuevas primitivas que permiten el acceso múltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de la que la entidad destino es parte. En el enlace quedará especificado qué entidad es la origen, cuál la destino y cuál la tercera. Recordar que esta navegación es especialmente apropiada en estructuras todo-parte. Después de todo esto, la lista de las primitivas de acceso queda reflejada en la siguiente tabla: Hiperenlace Hiperenlace jerárquico inferido Índice Visita guiada


Pág. 69



Visita guiada indexada Índice múltiple



Entidad Rel. N:M


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

Pág. 70


V - CD-ROM de S’Albufera

Capítulo V 1er 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ón de 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, se llegan a perder interesantes posibilidades al no sacar todo el jugo posible a la información de la que se dispone. Veremos como el uso de una metodología ayuda a detectar un mayor número de posibilidades navegacionales. Para ello, utilizaremos la metodología RMM para, por un lado modelar el sistema tal y como se presentó, y por el otro, partiendo desde la primera fase, intentar detectar todas esas posibles estructuras navegacionales. El objetivo de este caso de estudio será hacer un modelo de la aplicación y compararlo con un nuevo modelo, confeccionado desde cero, sin tener en cuenta cómo ésta fue estructurada. Para ello lo que haremos es comparar ambos modelos RMDM. No es necesario analizar las posteriores fases de la metodología, ya que aquí sólo nos interesa la 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 Natural de S’Albufera, y cómo está estructurado. En el segundo apartado se hace el modelado de la aplicación existente. Debido a que aquí ya tenemos presentes la estructura de menús y los enlaces navegacionales, no es necesario seguir las dos primeras etapas de la metodología, y comenzaremos el estudio con el diseño navegacional (tercera etapa de RMM). Por contra, en el tercer apartado sí que haremos el análisis desde cero, buscando cuáles son las entidades y relaciones que intervienen en el problema y haciendo el diseño de los slices. A partir de estas dos fases se confeccionará un nuevo modelo RMDM que difiere en varios aspectos del obtenido en el apartado anterior a partir de la aplicación actual. Las diferencias entre ambos son tratadas en el capítulo de conclusiones.

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 tres instituciones de las Islas Baleares. Éstas son la Conselleria de Cultura, Educació i Esports del Govern Balear, La Caixa de Balears “Sa Nostra” - en el marco de su Proyecto Natura - y la Universitat de les Illes Balears, y más concretamente su Departament 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 Parque Natural de S'Albufera. Pretende ser un complemento a la visita de campo que realizan los escolares al parque, bien para ser utilizado previamente a la visita como herramienta Antonio Navarrete Terrasa

Pág. 71



de preparación de dicha visita, bien para utilizarse posteriormente a la visita y permita ampliar y complementar los conocimientos adquiridos durante la visita. El proyecto fue llevado a cabo en 1995, y un hecho que aquí es de relevancia, referente a su implementación, es el de que no se utilizó ningún tipo de metodología o modelo durante 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 el parque. Consta de las partes siguientes: - Información general: Incluye datos sobre su extensión, su descripción administrativa, horarios de funcionamiento, dirección y teléfono. - Rincones del Parque. A partir de un mapa del parque se ilustran fotografías de algunos de los rincones más significativos del parque acompañadas de una pequeña reseña sobre cada uno de ellos. - Consejos para su visita. En forma de animaciones 2D de nuestra mascota se dan al visitante doce útiles consejos para facilitarle la visita. - Importancia biológica. Se explica la importancia que tiene el Parque Natural de S'Albufera dentro de la red de espacios húmedos de las rutas que utilizan las aves migratorias, así como su declaración de reserva biológica. - El Parque por estaciones. A partir de la fotografía de un mismo lugar del parque en 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ón científica que se llevan a cabo en el parque por parte del Institut de d'Estudis Avançats de les Illes Balears, la UIB y Earthwatch Europe. - Anillado de aves. Explica las tareas de anillado de aves migratorias que se llevan a cabo anualmente en el parque. El hombre y S'Albufera En este punto se ofrece una visión de la interacción que ha tenido el hombre con S’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 hitos más importantes de la historia del parque desde la época de dominación romana hasta nuestros días. Concretamente se incide en el uso y aspecto del parque durante distintas etapas: Romanos; Arabes; La Marjal; Real Patrimonio; Proyectos de desecado; Explotación arrocera; Fábrica de papel; Salinas; Segregación urbanística; Conferencia MAR; Campaña de concienciación; Central del Murterar; Compra de los terrenos; Declaración de Parque Natural; Lista RAMSAR.


Pág. 72



- Usos. Combinando texto, vídeo , gráficos y fotografías se enseña el uso que ha hecho de S’Albufera el hombre. Recoge: Caza, pesca, agricultura, uso de vegetales, agua, salinas y turismo. - Cancionero popular. S'Albufera, y las actividades que en ella se han llevado a cabo, está presente en la 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 comarca es muy clara. Se utilizan ingrediente exclusivos de la zona como las anguilas o el arroz bomba . En este apartado se repasa un poco esta relación de la zona con la cocina y se incluyen las recetas de la espinagada y del aguiat d'anguiles. Itinerarios Se muestran tres niveles de detalle diferentes. Desde un plano general del parque hasta un plano de la zona de sa Roca. Para cada uno de los tres planos se marcan recorridos para la visita. En estos recorridos aparecen puntos de interés de los que podemos 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 animales del parque, tanto los que pueden observarse a simple vista como los difícilmente localizables. Se ha hecho una selección que incluye: 132 aves, 7 mamíferos, 2 anfibios, 3 reptiles, 7 peces y 16 invertebrados. De cada especie hay una ficha que incluye: nombre común en catalán y castellano, nombre científico, forma de identificación, situación en el parque y donde puede observarse en el Parque. Se incluye también una fotografía, sonido para aves y anfibios, y un calendario con la abundancia relativa de cada ave en el parque. Las aves pueden consultarse alfabéticamente, o por familias. Se incluye la definición de cada una de las familias. Flora El herbario oficial del parque consta de más de 650 plantas censadas. Se ha hecho una 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án y castellano, nombre científico, forma de identificación, situación en el parque y donde 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 nombre científico o por hábitats. Información para los educadores Información destinada específicamente a los educadores. Incluye los itinerarios didácticos creados por los monitores del Parque. Es la documentación que se entrega, junto con otro material didáctico, a los profesores para preparar la visita de sus alumnos. Incluye: objetivos, destinatarios, metodología, bloques de contenido (paisaje, medio físico, seres vivos, cambios y paisajes históricos, el Antonio Navarrete Terrasa

Pág. 73



Parque Natural de S’Albufera), temporalización y recursos disponibles. El texto aparece combinado con fotografías y vídeo de visitas de escolares con los monitores del parque. Gestión del Parque Natural El funcionamiento del Parque Natural de S’Albufera lo rige un documento: Pla d'Ú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 dos opciones. Por una parte nos sitúa sobre un mapa todos los parques nacionales españoles y por otra ofrece información sobre los parques de las Baleares. Concretamente sobre el Parque Nacional de Cabrera, el Parque Natural de Mondragó, el Parque Natural de Sa Dragonera y el Parque Natural de S’Albufera des Grau. De cada uno de ellos se incluye: - Información general (extensión, termino municipal al que petenece, altitud máxima y fecha de declaración). - Sus valores naturales, incluyendo la flora y la fauna de los hábitats que encontramos. - Actividades a realizar, excursiones, exposiciones o lugares que visitar. Juegos Nos aparece una ruleta que de forma aleatoria selecciona uno de los juegos siguientes: - Relacionar animales con sus siluetas. - Relacionar animales con sus cantos. - Adivinar animales o plantas a partir de una 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 se dispone de 10 minutos. La finalidad global del juego es acumular el mayor número de puntos posible. Bibliografía Ordenada alfabéticamente por autores se incluye una relación de toda la bibliografía, incluyendo libros, artículos científicos y de divulgación, relacionada de una u otra forma con el parque.


Pág. 74



5.1.3. Premios recibidos Esta producción fue presentada al II Premio Möbius Barcelona Multimedia. De las 42 aplicaciones presentadas fue seleccionada como una de las 15 finalistas, y seleccionada, junto con otras 7 de estas aplicaciones finalistas, para optar al V Prix Möbius Internacional, que se celebró en París en Septiembre del 96. Además fue finalista del Perseo de Oro del Festival Internacionalle della Opera Multimediale, mediARTech, de Florencia, y mención especial por su diseño gráfico en el mismo Festival.


Pág. 75



5.2. Modelado de la navegación del CD En este apartado nos centraremos en la tercera etapa de la metodología RMM, es decir en el modelo RMDM. Como podemos ver al arrancar el programa, éste comienza con un menú en el que se integran diez opciones diferentes, aparte de opciones de créditos, que aquí no trataremos. Esas diez opciones diferentes, las cuales ya han sido explicadas en el apartado anterior son: 1. Información general 2. Hombre y Albufera 3. Itinerarios 4. Flora 5. Fauna 6. Información para los educadores 7. Juegos 8. Otros parques 9. Gestión del parque 10. Bibliografía Algunas estas opciones dan paso directamente a los contenidos finales. Tal es el caso de Informació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 de Juegos, no tiene mucho sentido ya que sólo hay un registro en esa entidad que sería el juego entero). Éstas no son accesibles desde ningún otro punto, ni permiten acceder a ningún otro lugar de la aplicación.

INFO. EDUCADORES

JUEGO

GESTION

BIBLIOGRAFIA

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


Pág. 76



ITINERARIO

LUGAR

No es muy diferente el apartado 8, Otros parques. En él se nos ofrecen dos posibilidades, 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, los parques de Baleares, incluyen sus valores naturales y actividades que se realizan.

PARQUE BALEARES

VALOR

PARQUE ESPAÑOL

ACTIVIDAD

Similar a este último caso son las dos primeras opciones, Información General y Hombre y Albufera. En el primero, accedemos a un menú: - Información general (accederemos mediante un índice) - Rincones (ídem) Antonio Navarrete Terrasa

Pág. 77



- 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)

RINCÓN INFO. GENERAL

ANIDAJE DE AVES

ESTACIÓN

IMPORTANC. BIOLÓGICA

PROYECTO CIENTÍFICO

CONSEJO

En cuanto a la segunda opción también accedemos a un menú: - Historia (índice) - Usos (índice) - Cancionero (índice) - Gastronomía (índice)

MÚSICA

HISTORIA

USO


GASTRONOMIA

Pág. 78



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

HABITAT PLANTAS PLANTA

Ésta es la parte que hace referencia a la flora. Podemos acceder de dos maneras diferentes a la información de una planta: por un índice alfabético (visita guiada indexada), o según su hábitat (índice). La información que tenemos de una planta, es muy 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 de floració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 que permite acceder a la planta en cuestión.


Pág. 79


MAMIFERO


INVERTEBRA DO

REPTIL

ANFIBIO

PEZ

FAMILIA AVES

AVE

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 permite acceder 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 el parque en todos los casos. En el caso de los mamíferos y anfibios se utiliza un slice adicional para mostrar el sonido que emite, mientras que para las aves se añaden dos slices, uno para el sonido y otro que muestra la sedentariedad del ave (en qué espacios de tiempo se encuentra presente en el parque). Para acceder a la información se utiliza en todos los casos la foto del animal, excepto en el caso de las aves, para lo cual se utiliza su nombre científico (tanto si se accede directamente, como si se hace a través de la familia).

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


Pág. 80



MENÚ PRINCIPAL

BIBLIOGRAFIA INFO. EDUCADORES

ITINERARIO

RINCÓN INFO. GENERAL

GESTION

JUEGO

ANIDAJE DE AVES

ESTACION



LUGAR

CONSEJO

MAMIFERO

ANFIBIO

HISTORIA

HABITAT PLANTAS

MÚSICA

INVERTEBRA DO

REPTIL

PARQUE BALEARES

PEZ

FAMILIA AVES

PLANTA

USO


GASTRONOMIA

AVE

USO

Pág. 81

ACTIVIDAD

PARQUE ESPAÑOL



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, como si nada se hubiese ya sido implementado. Ello nos ayudará a reconocer nuevas estructuras navegacionales que pasaron inadvertidas la primera vez.

5.3.1. Primera etapa: Diseño entidad-relación En esta etapa vamos a identificar las entidades y las relaciones entre ellas. Las primeras apenas si variarán de las identificadas en el apartado anterior. Por contra, encontraremos varias nuevas relaciones. En realidad hay numerosas partes del diseño que no variarán respecto de la implementación actual, dada su simplicidad. Ello nos lleva a centrarnos en la parte más rica 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 conjunto de entidades, ordenadas alfabéticamente. El proceso para detectar estas entidades, no es trivial y debe dedicársele mucha atención, si bien a menudo estará influenciado en buena medida por la información de la que se disponga y por los deseos del cliente. En este caso concreto nos basaremos en la estructura que se eligió para el CD-ROM, aunque con ciertos cambios. Actividades: conjunto de actividades que se desarrollan en los parques de las islas. Anfibios: 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 el parque. 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 educadores Invertebrados: 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.


Pág. 82



Lugares: de un lugar tenemos un vídeo o una imagen. También podríamos tener información textual describiendo el lugar o su importancia. Mamíferos: información textual del mamífero (entre ellas su ubicación en el parque), 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ípicas Parques de Baleares: 5 parques naturales de Baleares, con una breve información de ellos Parques 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 parque Valores naturales: el conjunto de valores naturales con que cuentan los parques de las islas. Una vez que hemos identificado todas las entidades, hemos de proceder a identificar las relaciones entre ellas. Éstas son las que hemos observado: - Claramente hay una 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. En este caso, puede haber lugares que estén en más de un itinerario, con lo cual tenemos una relación N:M. - Todo animal o planta tiene la información de los lugares donde puede encontrarse. Por tanto hay una clara relación entre los lugares y los animales o plantas. La relación también es N:M. - Las aves tienen una información referente a los meses en los que se encuentran en el parque. 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 se encuentran las plantas en flor. Por tanto, también hay una relación N:M entre meses y plantas. - Evidentemente, cada estación tiene unos meses. Para simplificar podemos incluir a un mes 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 periodos histó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 en un único punto histórico. - Igualmente, en cada lugar hay o ha habido unos determinados usos. Por ejemplo, en Sa Marjal, el uso es el agrícola.


Pág. 83



- También hay algunos animales que aparecen en los platos de cocina. Pero si se observa la información de la que se dispone, este hecho sólo ocurre en un caso, en el cual, la anguila 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:

FAMILIA PLANTAS

ITINERARIO PLANTA

MES LUGAR AVE USO ESTACION MAMIFERO MOMENTO HISTÓRICO

FAMILIA AVES

ANFIBIO

REPTIL PARQUE BALEARES

INVERTEBRA DO

PEZ USO

ACTIVIDAD

INFO. GENERAL

CONSEJO


MÚSICA

BIBLIOGRAF.

GASTRONO MIA

INFO. EDUCADOR.

JUEGO

GESTION

PARQUES ESPAÑA

5.3.2. Segunda fase: Diseño de slices En esta etapa detallaremos los atributos y slices que forman cada entidad. Realmente en muchos 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 la lista de las entidades con sus correspondientes atributos y slices, ordenada alfabéticamente. Entidad ACTIVIDAD


Slice actividad 1 (head)

Atributo nombre foto texto Pág. 84

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

anfibio 1 (head)

AVE

anfibio 2 ave 1 (head)

BIBLIOGRAFÍA CONSEJO ESTACIÓN

ave 2 bibliografía 1 (head) consejo 1 (head) estación 1 (head)

FAMILIA AVES GESTIÓN

familia 1 (head) gestión 1 (head)

GASTRONOMÍA

gastronomía 1 (head)

HÁBITAT PLANTAS INFO. EDUCADORES

hábitat 1 (head) educadores 1 (head)

INFO. GENERAL

general 1 (head)

INVERTEBRADO

invertebrado 1 (head)

ITINERARIO

itinerario 1 (head)

JUEGO LUGAR

juego 1 (head) lugar 1 (head)

MAMÍFERO

mamífero 1 (head)

MES MOMENTO HISTÓRICO

mamífero 2 mes 1 (head) momento 1 (head)

MÚSICA

música 1 (head)

PARQUE BALEARES Antonio Navarrete Terrasa

baleares 1 (head)

V - CD-ROM de S’Albufera nombre científico nombre catalán nombre castellano identificación foto sonido nombre científico nombre catalán nombre castellano identificación foto sonido texto dibujo nombre foto texto nombre nombre foto texto nombre foto receta nombre nombre foto texto nombre foto texto nombre científico nombre catalán nombre castellano identificación foto número mapa juego nombre vídeo o imagen texto nombre científico nombre catalán nombre castellano identificación foto sonido nombre nombre texto imagen sonido nombre letra sonido vídeo nombre Pág. 85


PARQUE ESPAÑOL

españa 1 (head)

PEZ

pez 1 (head)

PLANTA

planta 1 (head)


proyecto 1 (head)

REPTIL

reptil 1 (head)

USO

uso 1 (head)

VALOR

valor 1 (head)

V - CD-ROM de S’Albufera localización foto texto nombre localización nombre científico nombre catalán nombre castellano identificación foto nombre científico nombre catalán nombre castellano identificación foto nombre foto texto nombre científico nombre catalán nombre castellano identificación foto nombre dibujo vídeo o imagen texto nombre foto texto

5.3.3. Tercera fase: Diseño navegacional En esta etapa nos queda decidir las estructuras de navegación que utilizaremos para acceder a la información y la estructura de menús. En cuanto a las estructuras de navegación hemos intentado seguir las ideas que utilizaron los diseñadores del CDROM. Referente a la estructura de menús, ésta es: Información general Información general Consejos Importancia biológica Proyectos científicos Información educadores Juegos Gestión del parque Bibliografía Flora Hábitats Plantas Fauna Aves Familias de aves Antonio Navarrete Terrasa

Pág. 86



Aves Mamíferos Anfibios Reptiles Peces Invertebrados Estaciones Itinerarios Otros parques Parques de Baleares Valores naturales Actividades Parques de España El hombre y S’Albufera Momentos históricos Usos Gastronomía Música A partir de aquí, podemos confeccionar el diagrama RMDM, resultado final de este estudio:


Pág. 87



ESTACIÓN ITINERARIO MAMIFERO HABITAT PLANTAS


CONSEJOS

REPTIL ANFIBIO

MES

INVERTEBRA DO GASTRONO MIA

PEZ

PARQUE ESPAÑOL

MÚSICA

JUEGO

INFO. EDUCADORES PROYECTO CIENTÍFICO

INFO. GENERAL

PARQUES BALEARES

FAMILIA AVES

GESTION

USO PLANTA

MOMENTO HISTÓRICO

AVE

BIBLIOGRAFIA

LUGAR VALOR


Pág. 88

ACTIVIDAD



5.4. Conclusiones Como principal conclusión de este estudio se puede deducir la utilidad de utilizar una metodología y un modelo para evaluar detalladamente una aplicación ya desarrollada, a posteriori. De esta manera se han detallado una serie de carencias en la estructura de la información y la navegación. Las exponemos detalladamente a continuación: • Tanto animales (aves, mamíferos, peces, reptiles e invertebrados) como plantas tienen un lugar en el parque. En el sistema actual se desaprovecha la información para permitir que navegar por todos, por ejemplo, mamíferos de un lugar concreto. Y también al contrario, no podemos ir a visitar el lugar que se 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 la información de la presencia de las aves por meses, así como una breve descripción del parque en cada estación. Pero no podemos ver las aves que están en un mes concreto (interesante si queremos planificar una visita real al parque). Lo mismo ocurre con el período de floración de las plantas, que no se puede navegar por las plantas que están en flor en un mes concreto.


Pág. 89


VI - Proyecto MINTour

Capítulo VI 2º CASO: PROYECTO EUROPEO MINTour A la hora de hacer el análisis nos hemos intentado ajustar lo máximo posible a las especificaciones del proyecto europeo MINTour, [MIN96]. De hecho, nuestra idea inicial era utilizarlas al cien por cien. Sin embargo, esto no ha sido posible debido a que se ha tardado alrededor de un año y medio en tener la base de datos diseñada, y las especificaciones cambiaban tan frecuentemente, y con tantos errores, que decidimos que era imposible seguir esa línea. Incluso la definición definitiva de la base de datos de MINTour contiene varios fallos de normalización incomprensibles. Así pues, nuestro diseño resulta ser muy diferente del utilizado finalmente para el proyecto europeo, pero se ajusta a las primeras especificaciones que se hicieron para el mismo, a nuestro entender las 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 cada categoría. De lo contrario resultaría completamente ilegible, dado el gran número de entidades y relaciones. El proyecto europeo estaba dividido en una serie de categorías, que son lo que en la metodología Coad-Yourdon se denomina temas, una agrupación de entidades que tienen una fuerte relación entre sí en el mundo real. Las categorías en que finalmente hemos dividido este proyecto son las en las que se dividió el proyecto original (aunque en las últimas versiones algunas de ellas se agruparan). Sin embargo, también hemos considerado interesante incluir alguna categoría nueva como Naturaleza, que hace referencia a áreas naturales, que no fueron definidas en las primeras especificaciones del proyecto europeo, pero sí en las últimas. Ésta es nuestra lista, en la que nos basaremos para hacer el análisis: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Áreas geográficas Alojamientos Playas Deportes Eventos culturales Museos y monumentos Naturaleza Entretenimientos Restaurantes Rent-a-car Tiendas Transporte aéreo Transporte marítimo Transporte terrestre Transporte urbano


Pág. 90


16. 17. 18. 19. 20.


Taxi Paquetes turísticos Excursiones Teléfonos y direcciones de interés Agencias de viaje

A continuación, veremos en un primer apartado una introducción describiendo qué es MITNour. Después en los aprtados 6.2., 6.3. y 6.4., respectivamente, se analizan las tres primeras 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 que se han hecho a la metodología a partir de este análisis.


Pág. 91



6.1. Qué es MINTour La siguiente descripción del proyecto MINTour ha sido extraída del folleto de promoción del proyecto: « MINTour es el acrónimo de Multimedia Information Network for TOURism. MINTour aspira a convertirse en el embrión de la futura red paneuropea de información turística gracias al firme apoyo de las administraciones públicas y de los principales actores dentro del sector turístico, utilizando y promocionando a la vez los estándares europeos e internacionales. Dicha red debería ser utilizada por los ciudadanos en calidad de usuarios 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 vez más diversificado y con una mayor presencia de clientes potenciales que quieren obtener información precisa y fiable sobre sus posibles viajes. Las administraciones públicas son las únicas entidades que realmente pueden ofrecer información de calidad en términos de fidelidad y fiabilidad manteniéndola actualizada constantemente. Los productos con contenido multimedia accesibles a través de redes telemáticas pueden satisfacer estas necesidades 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 de información y productos turísticos mediante un sistema de navegación amigable. » • « Promocionar el sector turístico europeo proporcionando al usuario una base de 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 involucrados accederán de la misma manera a un mismo tipo de información y ésta, a su vez, será descrita de manera similar. • La información será fiable ya que serán las administraciones públicas relacionadas con el sector turístico de cada país las encargadas de proveer información. • Mejorar la calidad del servicio y contribuir a un nivel de satisfacción mucho más elevado por parte de los viajeros. • Ofrecer un mejor servicio a los ciudadanos involucrando profundamente a las administraciones públicas con el soporte de la industria turística. Antonio Navarrete Terrasa

Pág. 92



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


Pág. 93



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. En MINTour, todos los objetos que pertenecen a una categoría están asociados a una ciudad. El término ciudad aquí toma una definición particular, refiriéndose a aquellos destinos turísticos que queremos tratar. Por ejemplo, en el municipio de Palma, no tendremos una única ciudad, sino que al menos habrá dos: Palma y la Platja de Palma. Por tanto, cuando a partir de ahora nos refiramos a ciudad, en realidad nos referimos a destino turístico. La provincia también toma un sentido particular, ya que se consideran tres provincias en Baleares: Mallorca, Menorca y Eivissa i Formentera. Cada una de estos niveles tiene asociados mapas. Es decir, que cada nación, región, provincia y ciudad tienen un mapa. Éste se utilizará para realizar búsquedas gráficas.

Nación

Nación Multimedia

Región

Región Multimedia Tipo Multimedia

Provincia

Provincia Multimedia

Ciudad

Ciudad Multimedia

Veamos la descripción de atributos de estas entidades: Nación ID Nación: texto (PK) Nombre: texto Descripción: texto Mapa: texto (indica la dirección del fichero que contiene el mapa) Región ID Región: texto (PK) ID Nación: texto (FK) Nombre: texto Descripción: texto Antonio Navarrete Terrasa

Pág. 94



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) Provincia ID Provinica: texto (PK) ID Región: texto (FK) Nombre: texto Descripció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 región) Posición Y: entero (indica la posición en el eje Y, dentro del mapa de región) Ciudad ID Ciudad: texto (PK) ID Provincia: texto (FK) Nombre: texto Descripció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 provincia) Posición Y: entero (indica la posición en el eje Y, dentro del mapa de provincia) Tipo Multimedia ID Tipo MM: texto (PK) Nombre: texto Descripción: texto Plug-in: texto (Nombre y dirección del plug-in) Nación Multimedia ID 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: texto Copyright: texto Región Multimedia ID 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: texto Copyright: texto Provincia Multimedia ID 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, ...) Antonio Navarrete Terrasa

Pág. 95



Descripción: texto Copyright: texto Descripción: texto Copyright: texto Ciudad Multimedia ID 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: texto Copyright: texto


Pág. 96



6.2.2. Alojamientos Esta categoría engloba tanto hoteles, apartamentos, campings, hostales, entre otros tipos de 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 notar que 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 la temporada (alta, media o baja) y del régimen de estancia (pensión completa, media pensión, ...). Es importante notar que las temporadas no las marca cada hotel sino que está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 la constante aparición de nuevos servicios. Nótese que se podría relacionar también la entidad Habitación con los servicios, pero la información que se nos ofrece habla de servicios en habitaciones en general, sin especificar para qué tipos. Cadena Alojamientos

Ciudad

Tipo Alojamiento Alojamiento

Alojamiento Multimedia

Alojamiento Servicio

Habitaciones

Categoría Alojamientos Servicio Alojamientos

Tipo Multimedia

Tipo Habitación Régimen Estancia

Temporada

Precio Habitación

Veamos la descripción de los atributos de estas entidades: Alojamiento ID Alojamiento: texto (PK) ID Ciudad: texto (FK) ID Tipo Alojamiento: texto (FK) ID Cadena Alojamientos: texto (FK) Antonio Navarrete Terrasa

Pág. 97



ID Categoría Alojamientos: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Tipo Alojamiento ID Tipo Alojamiento: texto (PK) Nombre: texto Descripción: texto Categoría Alojamientos ID Categoría Alojamientos: texto (PK) Nombre: texto Descripción: texto Cadena Alojamientos ID Cadena Alojamientos: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Alojamiento Multimedia ID 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: texto Copyright: texto Servicio Alojamientos ID Servicio Alojamientos: texto (PK) Nombre: texto Descripción: texto Alojamiento Servicio Antonio Navarrete Terrasa

Pág. 98



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 para el segundo caso) Habitación: booleano (indica si el servicio es de habitación, o por contra, general) Habitaciones ID 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ón ID Tipo Habitación: texto (PK) Nombre: texto Descripción: texto Temporada ID Temporada: texto (PK) Nombre: texto Descripción: texto Fecha inicio: fecha Fecha fin: fecha Régimen Estancia ID Régimen Estancia: texto (PK) Nombre: texto Descripción: texto Precio Habitación ID Alojamiento: texto (PK) ID Tipo Habitación: texto (PK) ID Régimen Estancia: texto (PK) ID Temporada: texto (PK) Precio: entero


Pág. 99



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 incluyen en una entidad adicional, dada la gran diversidad existente y la constante aparición de nuevos servicios.

Ciudad

Tipo Playa

Playa

Playa Multimedia

Playa Servicio

Servicio Playas

Tipo Multimedia

Veamos la descripción de los atributos de estas entidades: Playa ID Playa: texto (PK) ID Ciudad: texto (FK) ID Tipo Playa: texto (FK) Nombre: texto Descripció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) Tipo Playa ID Tipo Playa: texto (PK) Nombre: texto Descripción: texto Playa Multimedia ID 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: texto Copyright: texto Servicio Playas ID Servicio Playas: texto (PK) Nombre: texto Antonio Navarrete Terrasa

Pág. 100



Descripción: texto Playa Servicio ID Playa: texto (PK) ID Servicio Playas: texto (PK) Cantidad: entero


Pág. 101



6.2.4. Deportes En esta categoría se hace referencia a las instalaciones deportivas. La base de la estructura de esta categoría es la instalación deportiva: una instalación está asociada a uno o varios deportes y tiene varios servicios. También aquí incluimos una entidad adicional para los servicios. Es necesaria una entidad que refleje los horarios de la instalación. Nótese que el horario puede 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 gratuita o no. También se indica si está abierta para la práctica del público (p.ej. un estadio de fútbol no suele ser para el uso público, ya que el público no puede practicar deporte en él).

Deporte

Deporte Multimedia

Tipo Multimedia

Ciudad

Deporte Instalación

Horario Instalación

Instalación deportiva

Instalación Multimedia

Instalación Servicio

Servicio Deportes

Veamos la descripción de los atributos de estas entidades: Deporte ID Deporte: texto (PK) Nombre: texto Descripción: texto Instalación deportiva ID Instalación deportiva: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripció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) Antonio Navarrete Terrasa

Pág. 102



Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Público: booleano (indica si es una instalación para uso del público en general) Gratuito: booleano Deporte Instalación ID Deporte: texto (PK) ID Instalación deportiva: texto (PK) Número: entero (indica el número de pistas, piscinas, ...) Deporte Multimedia ID 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: texto Copyright: texto Instalación Multimedia ID 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: texto Copyright: texto Servicio Deportes ID Servicio Deportes: texto (PK) Nombre: texto Descripción: texto Instalación Servicio ID Instalación deportiva: texto (PK) ID Servicio Deportes: texto (PK) Cantidad: entero Horario Instalación ID Instalación deportiva: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Antonio Navarrete Terrasa

Pág. 103



Hora cierre tarde: hora


Pág. 104



6.2.5. Eventos culturales Los eventos culturales se refieren tanto a conciertos, actuaciones, ..., ya sean puntuales o en el marco de un ciclo, así como a las fiestas populares, festivales, ... Por tanto, un evento cultural puede estar contenido en otro. Por ejemplo un concierto de la banda municipal puede estar incluido en las fiestas de una ciudad, o en el festival de bandas de mú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én ninguna si no tenemos información concreta de fechas, horas o lugares), como en el caso de una obra de teatro o un concierto, que pueden repetirse varios días, con lo cual tendremos otra entidad llamada Representación donde introduciremos la hora concreta de cada representación, así como el precio. Esta representación se realiza en lo que denominamos un centro cultural, que puede ser un teatro, un auditorio, un cine, o incluso un campo de fútbol. Tipo Evento

Ciudad

Evento Ciudad

Evento Cultural Eventos Multimedia

Centro Cultural

Represent ación

Tipo Multimedia

Evento Cultural ID Evento Cultural: texto (PK) ID Tipo Evento: texto (FK) Nombre: texto Descripción: texto Fecha Inicio: fecha Fecha Fin: fecha Evento Ciudad ID Evento Cultural: texto (PK) ID Ciudad: texto (FK) Tipo Evento ID Tipo Evento: texto (PK) Nombre: texto Descripción: texto Representación Antonio Navarrete Terrasa

Pág. 105



ID Representación: texto (PK) ID Evento Cultural: texto (FK) ID Centro Cultural: texto (FK) Fecha: fecha Hora Inicio: hora Hora Fin: hora Gratuito: booleano Centro Cultural ID Centro Cultural: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Eventos Multimedia ID 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: texto Copyright: texto


Pág. 106



6.2.6. Museos y monumentos Ciertamente, museos y monumentos tienen unas características muy similares y, muy a menudo, es difícil separar uno de otro. Es por eso que decidimos considerarlos como una ú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, finalmente descartamos esta opción, ya que la única información disponible al respecto es si hay visitas guiadas, auditorio o tienda, y parece difícil que un museo (y menos un monumento sin museo) pueda ofrecer más servicios.

Ciudad

Tipo Monumento

Horario Monumento

Monumento

Monumento Multimedia

Monumento Servicio

Servicio Monumentos

Tipo Multimedia

Periodo Histórico

Monumento ID Monumento: texto (PK) ID Ciudad: texto (FK) ID Tipo Monumento: texto (FK) ID Periodo Histórico: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Visitas guiadas: booleano Sala de proyecciones: booleano Tienda: booleano Público: booleano Gratuito: booleano Tipo Monumento ID Tipo Monumento: texto (PK) Nombre: texto Antonio Navarrete Terrasa

Pág. 107



Descripción: texto Periodo Histórico ID Periodo Histórico: texto (PK) Nombre: texto Descripción: texto Año Inicio: entero Año Fin: entero Monumento Multimedia ID 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: texto Copyright: texto Servicio Monumentos ID Servicio Monumentos: texto (PK) Nombre: texto Descripción: texto Monumento Servicio ID Monumento: texto (PK) ID Servicio Monumentos: texto (PK) Cantidad: entero Horario Monumento ID Monumento: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 108



6.2.7. Naturaleza Los lugares naturales corresponden a montañas, lagos, parques naturales, ..., o incluso dentro de las ciudades a parques o jardines. Aquí ya no tiene sentido el periodo histó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 pueden ser un área de acampada, fuente, merendero, barbacoa, oficina de información, ...

Ciudad

Naturaleza Ciudad

Tipo Naturaleza

Naturaleza

Naturaleza Multimedia

Naturaleza Servicio

Servicio Natural

Tipo Multimedia

Naturaleza ID Naturaleza: texto (PK) ID Tipo Naturaleza: texto (FK) Nombre: texto Descripción: texto Localizació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 Ciudad ID 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 Naturaleza ID Tipo Naturaleza: texto (PK) Nombre: texto Descripción: texto Naturaleza Multimedia ID 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: texto Copyright: texto Antonio Navarrete Terrasa

Pág. 109



Servicio Natural ID Servicio Natural: texto (PK) Nombre: texto Descripción: texto Naturaleza Servicio ID Naturaleza: texto (PK) ID Servicio Natural: texto (PK) Cantidad: entero


Pág. 110



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

Tipo Entretenimiento

Ciudad

Horario Entretenimiento

Entretenimiento

Entretenimiento Multimedia

Tipo Multimedia

Entretenimiento ID Entretenimiento: texto (PK) ID Ciudad: texto (FK) ID Tipo Entretenimiento: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Gratuito: booleano Tipo Entretenimiento ID Tipo Entretenimiento: texto (PK) Nombre: texto Descripción: texto Entretenimiento Multimedia ID 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: texto Copyright: texto


Pág. 111



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


Pág. 112



6.2.9. Restaurantes Los restaurantes presentan una estructura muy similar a la anterior categoría, si bien incorporan una categoría.

Tipo Restaurantes

Ciudad

Horario Restaurante

Restaurante

Restaurante Multimedia

Tipo Multimedia

Categoría Restaurante

Restaurante ID Restaurante: texto (PK) ID Ciudad: texto (FK) ID Tipo Restaurante: texto (FK) ID Categoría Restaurante: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Tipo Restaurante ID Tipo Restaurante: texto (PK) Nombre: texto Descripción: texto Restaurante Multimedia ID 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: texto Copyright: texto Categoría Restaurante Antonio Navarrete Terrasa

Pág. 113



ID Categoría Restaurante: texto (PK) Nombre: texto Descripción: texto Horario Restaurante ID Restaurante: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 114



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

Cadena Rent-a-car

Ciudad

Horario Rent-a-car

Rent-a-car

Rent-a-car Multimedia

Tipo Multimedia

Rent-a-car ID Rent-a-car: texto (PK) ID Ciudad: texto (FK) ID Cadena Rent-a-car: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Cadena Rent-a-car ID Cadena Rent-a-car: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Rent-a-car Multimedia ID MM: texto (PK) ID Rent-a-car: texto (FK) Antonio Navarrete Terrasa

Pág. 115



ID Tipo MM: texto (FK) Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...) Descripción: texto Copyright: texto Horario Rent-a-car ID Rent-a-car: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 116



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 la tienda.

Ciudad

Horario Tienda

Tienda

Tienda Multimedia

Cadena Tiendas

Tipo Tienda Tipo Multimedia

Tienda ID Tienda: texto (PK) ID Ciudad: texto (FK) ID Tipo Tienda: texto (FK) ID Cadena Tiendas: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Tipo Tienda ID Tipo Tienda: texto (PK) Nombre: texto Descripción: texto Cadena Tiendas ID Cadena Tiendas: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Antonio Navarrete Terrasa

Pág. 117



Fax: texto email: texto URL: texto Tienda Multimedia ID 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: texto Copyright: texto Horario Tienda ID Tienda: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 118



6.2.12. Transporte aéreo Un vuelo lógicamente une dos aeropuertos. Pero, siguiendo la terminología propia de la aviación, un código de vuelo corresponde a un par de aeropuertos, más una compañía aérea, más una hora de salida. Por ejemplo, el vuelo IB3024 podría ser, por ejemplo, el vuelo de Iberia que va de Palma a Ibiza y que sale a las 8:00 de la mañana. El que sale a las 15:00 y/o es de otra compañía recibirá otro código. Nótese que el IB3024 es muy posible que no salga todos los días de la semana. En todo caso es necesario una entidad adicional Horario Vuelo, ya que puede ser que el vuelo cambie su horario según la temporada 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 de transportes. Esto es debido a que por ejemplo, una compañía de aviación o de barcos puede tener autocares propios, y no tendría sentido crear dos veces la compañía en dos entidades diferentes.

Ciudad

Aeropuerto

Aeropuerto Multimedia

Vuelo

Horario Vuelo

Compañía Transportes

Precio Vuelo

Ciudad

Tipo Multimedia

Tipo Tarifa Aérea

Cía Transportes Multimedia

Aeropuerto ID Aeropuerto: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Antonio Navarrete Terrasa

Pág. 119



Fax: texto email: texto URL: texto Vuelo ID 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érea ID Tipo Tarifa Aérea: texto (PK) Nombre: texto Descripción: texto Precio ID Vuelo: texto (PK) ID Tipo Tarifa Aérea: texto (PK) Precio: entero Fecha inicio vigencia: fecha Fecha fin vigencia: fecha Compañía Transportes ID Compañía Transportes: texto (PK) ID Ciudad: texto (PK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Horario Vuelo ID Vuelo: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Hora salida: hora Hora llegada: hora Lunes: 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) Antonio Navarrete Terrasa

Pág. 120



Aeropuerto Multimedia ID 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: texto Copyright: texto Cía Transportes Multimedia ID 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: texto Copyright: texto


Pág. 121



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

Ciudad

Puerto

Puerto Multimedia

Trayecto

Horario Trayecto


Ciudad

Precio Pasaje

Tipo Multimedia

Tipo Pasaje


Puerto ID Puerto: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Longitud: texto (situación exacta del puerto: longitud) Latitud: texto (situación exacta del puerto: latitud) Profundidad máxima: entero Profundidad mínima: entero Estrechez: entero 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) Dirección: texto CP: texto Teléfono: texto Fax: texto Antonio Navarrete Terrasa

Pág. 122



email: texto URL: texto Trayecto ID 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 Pasaje ID Tipo Tipo Pasaje: texto (PK) Nombre: texto Descripción: texto Precio Pasaje ID Trayecto: texto (PK) ID Tipo Pasaje: texto (PK) Precio: entero Fecha inicio vigencia: fecha Fecha fin vigencia: fecha Compañía Transportes ID Compañía Transportes: texto (PK) ID Ciudad: texto (PK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Horario Trayecto ID Trayecto: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Hora salida: hora (PK) Hora llegada: hora Día semana inicio: 1..7 (PK) Día semana fin: 1..7 Vehículos: booleano (Indica si el barco permite llevar vehículos) Nombre barco: texto Puerto Multimedia ID MM: texto (PK) ID Puerto: texto (FK) Antonio Navarrete Terrasa

Pág. 123



ID Tipo MM: texto (FK) Dirección: texto (indica la dirección donde está la imagen, vídeo, sonido, ...) Descripción: texto Copyright: texto Cía Transportes Multimedia ID 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: texto Copyright: texto


Pág. 124



6.2.14. Transporte terrestre Se engloban en esta categoría las categorías originales “Trenes” y “Autocares”, ya que ambas resultan ser idénticas y que hemos decidido que normalmente cuando alguien busca el modo de ir de una ciudad a otra, en principio no desea hacer dos búsquedas diferentes, una para los trenes y otra para los autocares. De todos modos, mediante la entidad Medio de Transporte se diferencia entre uno y otro. Nótese que tenemos la entidad “Parada” no es más que el nombre que le hemos dado a la entidad que surge de la relación N:M entre “Estación” y “Línea”.

Ciudad

Estación

Estación Multimedia

Parada

Línea

Medio Transporte

Horario Tr. Terrestre


Ciudad


Estación ID Estación: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto


Pág. 125



Línea ID Línea: texto (PK) ID Compañía Transportes: texto (FK) ID Medio Transporte: texto (FK) Nombre: texto Descripción: texto Número paradas: entero Medio Tranporte ID Medio Transporte: texto (PK) Nombre: texto Parada ID 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) Compañía Transportes ID Compañía Transportes: texto (PK) ID Ciudad: texto (PK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Horario Tr. Terrestre ID Línea: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Hora salida: hora (PK) Hora llegada: hora Día semana inicio: 1..7 (PK) Día semana fin: 1..7 Precio: texto (lista de los precios según las paradas) Estación Multimedia ID 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: texto Copyright: texto Cía Transportes Multimedia ID MM: texto (PK) Antonio Navarrete Terrasa

Pág. 126



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: texto Copyright: texto


Pág. 127



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 gran número de entidades de otras categorías, ya que para un usuario es de interés qué parada es 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 Compañía Transportes Línea Urbana

Parada Línea



Horario Urbano Parada Urbana

Ciudad

Pág. 128



Cía Transportes Multimedia Ciudad Compañía Transportes Línea Urbana

Horario Urbano

Parada Línea

Parada Urbana

Ciudad

Parada Alojamiento

Alojamiento

Parada Playa

Playa

Parada Instalac.

Instalac. Deportiva

Parada Museo

Museo

Parada Naturaleza

Naturaleza

Parada Entretenim.

Entretenim.

Parada Restaurante

Restaurante

Parada Rent-a-car

Rent-a-car

Parada Tienda

Tienda

Parada Aeropuerto

Aeropuerto

Parada Puerto

Puerto

Parada Estación

Estación

Parada Información

Información

Parada Agencia

Agencia

Línea Urbana ID Línea Urbana: texto (PK) ID Ciudad: texto (FK) ID Compañía Urbana: texto (FK) Nombre: texto Descripción: texto Parada Urbana ID Parada Urbana: texto ID Ciudad: texto Dirección: texto Antonio Navarrete Terrasa

Pág. 129



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ínea ID Línea: texto (PK) ID Parada Urbana: texto (PK) Horario Urbano Línea Urbana ID: fecha (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Primera salida origen: hora Última salida origen: hora Primera salida destino: hora Última salida destino: hora Frecuencia de paso: número Precio billete ordinario: número Precio bono 10 billetes: número Compañía Transportes ID Compañía Transportes: texto (PK) ID Ciudad: texto (PK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Cía Transportes Multimedia ID 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: texto Copyright: texto Parada Alojamiento ID Parada: texto ID Alojamiento: texto Parada Playa ID Parada: texto ID Playa: texto Parada Instalación Antonio Navarrete Terrasa

Pág. 130



ID Deporte: texto ID Playa: texto Parada Museo ID Museo: texto ID Playa: texto Parada Naturaleza ID Naturaleza: texto ID Playa: texto Parada Entretenimiento ID Entretenimiento: texto ID Playa: texto Parada Restaurante ID Restaurante: texto ID Playa: texto Parada Rent-a-car ID Rent-a-car: texto ID Playa: texto Parada Tienda ID Tienda: texto ID Playa: texto Parada Aeropuerto ID Aeropuerto: texto ID Playa: texto Parada Puerto ID Puerto: texto ID Playa: texto Parada Estación ID Estación: texto ID Playa: texto Parada Información ID Información: texto ID Playa: texto Parada Agencia ID Agencia: texto ID Playa: texto


Pág. 131



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

Taxi ID Taxi: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Direcció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)


Pág. 132



6.2.17. Paquete turístico Un paquete turístico u oferta promocional, es ofrecido por una agencia de viajes, en una ciudad y, generalmente, también un alojamiento concreto. El precio de un paquete depende del régimen de estancia. Cadena Ag. Viajes

Alojamiento

Oferta Promocional

Régimen Estancia

Precio Oferta

Ciudad

Oferta Promocional ID Oferta: texto (PK) ID Ciudad: texto (FK) ID Alojamiento: texto (FK) ID Cadena Ag. Viajes: texto (FK) Nombre: texto Descripción: texto Excursiones: booleano Coche de alquiler: booleano Régimen Estancia ID Régimen Estancia: texto (PK) Nombre: texto Descripción: texto Precio Oferta ID Oferta: texto (PK) ID Régimen Estancia: texto (PK) Fecha inicio vigencia: fecha Fecha fin vigencia: fecha Precio: entero


Pág. 133



6.2.18. Excursiones Esta categoría describe excursiones, ya sea a pie, en bicicleta, en coche o en cualquier medio de transporte. Una excursión puede incluir una o más ciudades (recuérdese que en MINTour ciudad representaba a un municipio). Medio Transporte Excursión

Excursión Ciudad

Excursión Multimedia

Ciudad

Excursión ID Excursión: texto (PK) ID Medio Transporte: texto (FK) Nombre: texto Descripción: texto Punto de partida: texto Punto final: texto Recorrido: texto Duración: texto Dificultad: texto Transportes: texto (descripción de medios de transporte utilizados como soporte) Valor historico-natural: texto Mapa: texto (dirección con el mapa del recorrido) Medio Tranporte ID Medio Transporte: texto (PK) Nombre: texto Excursión Ciudad ID Excursión: texto (PK) ID Ciudad: texto (PK) Excursión Multimedia ID 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, ...) Antonio Navarrete Terrasa

Pág. 134



Descripción: texto Copyright: texto


Pág. 135



6.2.19. Teléfonos y direcciones útiles Se engloban aquí todas las oficinas de información turística, así como otro tipo de direcciones 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 es simplísima: sólo está relacionada con la ciudad y con un horario, y ni siquiera tienen sentido objetos multimedia.

Ciudad

Información

Horario Información

Información ID Información: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Gratuito: booleano Horario Información ID Información: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 136



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

Ciudad

Cadena Agencias

Cadena agencias Multimedia

Agencia

Horario Agencia

Tipo Multimedia

Agencia ID Agencia: texto (PK) ID Ciudad: texto (FK) ID Cadena Agencias: texto (FK) Nombre: texto Descripció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) Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Cadena Agencias ID Cadena Agencias: texto (PK) ID Ciudad: texto (FK) Nombre: texto Descripción: texto Dirección: texto CP: texto Teléfono: texto Fax: texto email: texto URL: texto Agencia Multimedia ID 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, ...) Antonio Navarrete Terrasa

Pág. 137



Descripción: texto Copyright: texto Horario Agencia ID Agencia: texto (PK) Fecha inicio vigencia: fecha (PK) Fecha fin vigencia: fecha Día semana inicio: 1..7 (PK) (1: lunes, 7: domingo) Día semana fin: 1..7 Hora apertura mañana: hora Hora cierre mañana: hora Hora apertura tarde: hora Hora cierre tarde: hora


Pág. 138



6.3. 2ª Etapa: Diseño de slices 6.3.1. Áreas geográficas Nación Mínimo Head (híbrido)

Región Mínimo Head (híbrido)

Mapa Nación (híbrido)

Provincia Mínimo Head (híbrido)

Mapa Región

Ciudad Mínimo Head (híbrido)

Mapa Provincia (híbrido)

Tipo Multimedia Mínimo Head Antonio Navarrete Terrasa

Nombre Nombre Descripción Mapa

Nombre Nación.Nombre Nombre Descripción Mapa Nación.Mapa Posición X Posición Y

Nombre Región.Nombre Nombre Descripción Mapa Región.Mapa Posición X Posición Y

Nombre Provincia.Nombre Nombre Descripción Mapa Provincia.Mapa Posición X Posición Y

Nombre Nombre Pág. 139



Descripción Plug-in

Nación Multimedia Mínimo (híbrido) Head (híbrido)

Región Multimedia Mínimo (híbrido) Head (híbrido)

Provincia Multimedia Mínimo (híbrido) Head (híbrido)

Ciudad Multimedia Mínimo (híbrido) Head (híbrido)


Nación.nombre Descripción Descripción Copyright Dirección Nación.Nombre Tipo Multimedia.Nombre

Región.nombre Descripción Descripción Copyright Dirección Región.Nombre Tipo Multimedia.Nombre

Provinica.nombre Descripción Descripción Copyright Dirección Provincia.Nombre Tipo Multimedia.Nombre

Ciudad.nombre Descripción Descripción Copyright Dirección Ciudad.Nombre Tipo Multimedia.Nombre

Pág. 140



6.3.2. Alojamientos Alojamiento Mínimo Head (híbrido)

Mapa Ciudad (híbrido)

Tipo Alojamiento Mínimo Head

Categoría Alojamientos Mínimo Head

Cadena Alojamientos Mínimo Head (híbrido)

Alojamiento Multimedia Mínimo (híbrido)


Nombre Nombre Ciudad.Nombre Tipo Alojamiento.Nombre Cadena Alojamientos.Nombre Categoría Alojamientos.Nombre Descripción Localización Dirección CP Teléfono Fax email Ciudad.Mapa Localización Posición X Posición Y

Nombre Nombre Descripción


Nombre Nombre Ciudad.Nombre Descripción Dirección CP Teléfono Fax email URL

Alojamiento.Nombre Descripción Pág. 141


Head (híbrido)

Servicio Alojamientos Mínimo Head

Alojamiento Servicio Mínimo (híbrido) Head (híbrido)

Habitaciones Mínimo (híbrido) Head (híbrido)

Tipo de Habitación Mínimo Head

Temporada Mínimo Head

Régimen Estancia Mínimo Head



Descripción Copyright Dirección Alojamiento.Nombre Tipo Multimedia.Nombre


Alojamiento.Nombre Servicio Alojamientos.Nombre Alojamiento.Nombre Servicio Alojamientos.Nombre Número Habitación

Alojamiento.Nombre Tipo Habitación.Nombre Alojamiento.Nombre Tipo Habitación.Nombre Número


Nombre Nombre Descripción Fecha inicio Fecha fin

Nombre Nombre Descripción Pág. 142


Precio Habitación Mínimo (híbrido)

Head (híbrido)



Alojamiento.Nombre Tipo Habitación.Nombre Régimen Estancia.Nombre Temporada.Nombre Alojamiento.Nombre Tipo Habitación.Nombre Régimen Estancia.Nombre Temporada.Nombre Precio

Pág. 143



6.3.3. Playas Playa Mínimo Head (híbrido)


Tipo Playa Mínimo Head

Playa Multimedia Mínimo (híbrido) Head (híbrido)

Servicio Playas Mínimo Head

Playa Servicio Mínimo (híbrido) Head (híbrido)


Nombre Ciudad.Nombre Tipo Playa.Nombre Nombre Descripción Localización Ciudad.Mapa Localización Posición X Posición Y


Playa.Nombre Descripción Descripción Copyright Dirección Playa.Nombre Tipo Multimedia.Nombre


Playa.Nombre Servicio Playas.Nombre Playa.Nombre Servicio Playas.Nombre Cantidad

Pág. 144



6.3.4. Deportes Deporte Mínimo Head

Instalación deportiva Mínimo Head (híbrido)


Deporte Instalación Mínimo (híbrido) Head (híbrido)

Deporte Multimedia Mínimo (híbrido) Head (híbrido)

Instalación Multimedia Mínimo (híbrido) Head (híbrido) Antonio Navarrete Terrasa


Nombre Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Público Gratuito Ciudad.Mapa Localización Posición X Posición Y

Instalación deportiva.Nombre Deporte.Nombre Instalación deportiva.Nombre Deporte.Nombre Cantidad

Deporte.Nombre Descripción Descripción Copyright Dirección Deporte.Nombre Tipo Multimedia.Nombre

Instalación deportiva.Nombre Descripción Descripción Pág. 145



Copyright Dirección Instalación deportiva.Nombre Tipo Multimedia.Nombre Servicio Deportes Mínimo Head

Instalación Servicio Mínimo (híbrido) Head (híbrido)

Horario Instalación Mínimo (híbrido)

Head (híbrido)



Instalación deportiva.Nombre Servicio Deportes.Nombre Instalación deportiva.Nombre Servicio Deportes.Nombre Cantidad

Instalación deportiva.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Instalación deportiva.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 146



6.3.5. Eventos culturales Evento Cultural Mínimo Head (híbrido)

Evento Ciudad Mínimo (híbrido) Head (híbrido)

Tipo Evento Mínimo Head

Representación Mínimo Head (híbrido)

Centro Cultural Mínimo Head (híbrido)



Nombre Nombre Tipo Evento.Nombre Descripción Fecha Inicio Fecha Fin

Evento Cultural.Nombre Ciudad.Nombre Evento Cultural.Nombre Ciudad.Nombre


Nombre Nombre Evento Cultural.Nombre Centro Cultural.Nombre Fecha Hora Inicio Hora Fin Gratuito

Nombre Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y Pág. 147


Eventos Multimedia Mínimo (híbrido) Head (híbrido)



Evento Cultural.Nombre Descripción Descripción Copyright Dirección Evento Cultural.Nombre Tipo Multimedia.Nombre

Pág. 148



6.3.6. Museos y monumentos Monumento Mínimo Head (híbrido)


Tipo Monumento Mínimo Head

Periodo Histórico Mínimo Head

Monumento Multimedia Mínimo (híbrido) Head (híbrido)


Nombre Nombre Ciudad.Nombre Tipo Monumento.Nombre Periodo Histórico.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Visitas guiadas Sala de proyecciones Tienda Público Gratuito Ciudad.Mapa Localización Posición X Posición Y


Nombre Nombre Descripción Año inicio Año fin

Monumento.Nombre Descripción Descripción Copyright Dirección Monumento.Nombre Tipo Multimedia.Nombre Pág. 149


Servicio Monumentos Mínimo Head

Monumento Servicio Mínimo (híbrido) Head (híbrido)

Horario Monumento Mínimo (híbrido)

Head (híbrido)




Monumento.Nombre Servicio Monumentos.Nombre Monumento.Nombre Servicio Monumentos.Nombre Cantidad

Monumento.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Monumento.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 150



6.3.7. Naturaleza Naturaleza Mínimo Head (híbrido)

Naturaleza Ciudad Mínimo (híbrido) Head (híbrido)

Tipo Naturaleza Mínimo Head

Naturaleza Multimedia Mínimo (híbrido) Head (híbrido)

Servicio Natural Mínimo Head

Naturaleza Servicio Mínimo (híbrido) Head (híbrido) Antonio Navarrete Terrasa

Nombre Tipo Naturaleza.Nombre Nombre Descripción Localización Público Gratuito

Naturaleza.Nombre Ciudad.Nombre Naturaleza.Nombre Ciudad.Nombre Ciudad.Mapa Posición X Posición Y


Naturaleza.Nombre Descripción Descripción Copyright Dirección Naturaleza.Nombre Tipo Multimedia.Nombre


Naturaleza.Nombre Servicio Natural.Nombre Naturaleza.Nombre Pág. 151



Servicio Natural.Nombre Cantidad


Pág. 152



6.3.8. Entretenimientos Entretenimiento Mínimo Head (híbrido)


Tipo Entretenimiento Mínimo Head

Entretenimiento Multimedia Mínimo (híbrido) Head (híbrido)

Horario Entretenimiento Mínimo (híbrido)

Head (híbrido)


Nombre Nombre Ciudad.Nombre Tipo Entretenimiento.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Gratuito Ciudad.Mapa Localización Posición X Posición Y


Entretenimiento.Nombre Descripción Descripción Copyright Dirección Entretenimiento.Nombre Tipo Multimedia.Nombre

Entretenimiento.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Entretenimiento.Nombre Fecha inicio vigencia Fecha fin vigencia Pág. 153



Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde


Pág. 154



6.3.9. Restaurantes Restaurante Mínimo Head (híbrido)


Tipo Restaurante Mínimo Head

Restaurante Multimedia Mínimo (híbrido) Head (híbrido)

Categoría Restaurante Mínimo Head

Horario Restaurante Mínimo (híbrido)


Nombre Nombre Ciudad.Nombre Tipo Restaurante.Nombre Categoría Restaurante.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y


Restaurante.Nombre Descripción Descripción Copyright Dirección Restaurante.Nombre Tipo Multimedia.Nombre


Restaurante.Nombre Fecha inicio vigencia Fecha fin vigencia Pág. 155


Head (híbrido)



Día semana inicio Día semana fin Restaurante.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 156



6.3.10. Rent-a-car Rent-a-car Mínimo Head (híbrido)


Cadena Rent-a-car Mínimo Head (híbrido)

Rent-a-car Multimedia Mínimo (híbrido) Head (híbrido)

Horario Rent-a-car Mínimo (híbrido)


Nombre Nombre Ciudad.Nombre Cadena Rent-a-car.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y

Nombre Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL

Monumento.Nombre Descripción Descripción Copyright Dirección Monumento.Nombre Tipo Multimedia.Nombre

Rent-a-car.Nombre Fecha inicio vigencia Pág. 157


Head (híbrido)



Fecha fin vigencia Día semana inicio Día semana fin Rent-a-car.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 158



6.3.11. Tienda Tienda Mínimo Head (híbrido)


Tipo Tienda Mínimo Head

Cadena Tiendas Mínimo Head (híbrido)

Tienda Multimedia Mínimo (híbrido) Head (híbrido)


Nombre Nombre Ciudad.Nombre Cadena Tiendas.Nombre Tipo Tienda.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y



Tienda.Nombre Descripción Descripción Copyright Pág. 159



Dirección Tienda.Nombre Tipo Multimedia.Nombre

Horario Tienda Mínimo (híbrido)

Head (híbrido)


Tienda.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Tienda.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 160



6.3.12. Transporte aéreo Aeropuerto Mínimo

Head (híbrido)


Vuelo Mínimo Head (híbrido)

Tipo Tarifa Aérea Mínimo Head

Precio Mínimo (híbrido)

Head (híbrido)


ID Aeropuerto Nombre Ciudad.Nombre ID Aeropuerto Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y

ID Vuelo Descripción ID Vuelo Descripción Aeropuerto salida.Nombre Aeropuerto llegada.Nombre Compañía Transportes.Nombre Vuelo directo


ID Vuelo Vuelo.Descripción Tipo Tarifa Aérea.Nombre Fecha inicio vigencia Fecha fin vigencia ID Vuelo Vuelo.Descripción Pág. 161



Tipo Tarifa Aérea.Nombre Precio Fecha inicio vigencia Fecha fin vigencia

Compañía Transportes Mínimo Head (híbrido)

Horario Vuelo Mínimo (híbrido)

Head (híbrido)

Aeropuerto Multimedia Mínimo (híbrido) Head (híbrido)



ID Vuelo Vuelo.Descripción Fecha inicio vigencia Fecha fin vigencia ID Vuelo Vuelo.Descripción Fecha inicio vigencia Fecha fin vigencia Hora salida Hora llegada Lunes Martes Miércoles Jueves Viernes Sábado Domingo

Aeropuerto.Nombre Descripción Descripción Copyright Dirección Aeropuerto.Nombre Tipo Multimedia.Nombre Pág. 162


Cía Transportes Multimedia Mínimo (híbrido) Head (híbrido)



Compañía Transportes.Nombre Descripción Descripción Copyright Dirección Compañía Transportes.Nombre Tipo Multimedia.Nombre

Pág. 163



6.3.13. Transporte marítimo Puerto Mínimo Head (híbrido)


Trayecto Mínimo Head (híbrido)

Tipo Pasaje Mínimo Head

Precio Pasaje Mínimo (híbrido)

Head (híbrido)


Nombre Ciudad.Nombre Nombre Ciudad.Nombre Longitud Latitud Profundidad máxima Profundidad mínima Estrechez Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y

Descripción Descripción Puerto salida.Nombre Puerto llegada.Nombre Compañía Transportes.Nombre Trayecto directo


Trayecto.Descripción Tipo Pasaje.Nombre Fecha inicio vigencia Fecha fin vigencia Trayecto.Descripción Tipo Pasaje.Nombre Pág. 164



Precio Fecha inicio vigencia Fecha fin vigencia


Horario Trayecto Mínimo (híbrido)

Head (híbrido)

Puerto Multimedia Mínimo (híbrido) Head (híbrido)



Trayecto.Descripción Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Trayecto.Descripción Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora salida Hora llegada Día semana inicio Día semana fin Vehículos Nombre barco

Puerto.Nombre Descripción Descripción Copyright Dirección Puerto.Nombre Tipo Multimedia.Nombre

Pág. 165






Pág. 166



6.3.14. Transporte terrestre Estación Mínimo Head (híbrido)


Línea Mínimo Head (híbrido)

Medio Tranporte Mínimo Head

Parada Mínimo (híbrido) Head (híbrido)



Nombre Ciudad.Nombre Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y

Nombre Nombre Descripción Compañía Transportes.Nombre Medio Transporte.Nombre Número paradas

Nombre Nombre

Estación.Nombre Línea.Nombre Estación.Nombre Línea.Nombre Número orden

Nombre Nombre Ciudad.Nombre Descripción Pág. 167



Localización Dirección CP Teléfono Fax email URL

Horario Tr. Terrestre Mínimo (híbrido)

Head (híbrido)

Estación Multimedia Mínimo (híbrido) Head (híbrido)



Línea.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora salida Línea.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora salida Hora llegada Precio

Estación.Nombre Descripción Descripción Copyright Dirección Estación.Nombre Tipo Multimedia.Nombre


Pág. 168



6.3.15. Transporte Urbano Línea Urbana Mínimo (híbrido)

Head (híbrido)

Parada Urbana Mínimo (híbrido) Head (híbrido)


Parada Línea Mínimo (híbrido) Head (híbrido)

Horario Urbano Mínimo (híbrido)

Head (híbrido)


Nombre Ciudad.Nombre Compañía Urbana.Nombre Nombre Ciudad.Nombre Compañía Urbana.Nombre Descripción

Dirección Ciudad.Nombre Dirección Ciudad.Nombre Localización Ciudad.Mapa Localización Posición X Posición Y

Línea.Nombre Parada Urbana.Dirección Línea.Nombre Parada Urbana.Dirección

Línea Urbana.Nombre Fecha inicio vigencia Fecha fin vigencia Línea Urbana.Nombre Fecha inicio vigencia Fecha fin vigencia Primera salida origen Última salida origen Primera salida destino Última salida destino Frecuencia de paso Precio billete ordinario Precio bono 10 billetes

Pág. 169




Parada Alojamiento Mínimo (híbrido) Head (híbrido)

Parada Playa Mínimo (híbrido) Head (híbrido)

Parada Instalación Mínimo (híbrido) Head (híbrido)

Parada Museo Mínimo (híbrido)





Parada Urbana.Dirección Alojamiento.Nombre Parada Urbana.Dirección Alojamiento.Nombre

Parada Urbana.Dirección Playa.Nombre Parada Urbana.Dirección Playa.Nombre

Parada Urbana.Dirección Instalación Deportiva.Nombre Parada Urbana.Dirección Instalación Deportiva.Nombre

Parada Urbana.Dirección Museo.Nombre Pág. 170


Head (híbrido)

Parada Naturaleza Mínimo (híbrido) Head (híbrido)

Parada Entretenimiento Mínimo (híbrido) Head (híbrido)

Parada Restaurante Mínimo (híbrido) Head (híbrido)

Parada Rent-a-car Mínimo (híbrido) Head (híbrido)

Parada Tienda Mínimo (híbrido) Head (híbrido)

Parada Aeropuerto Mínimo (híbrido) Head (híbrido)


Parada Urbana.Dirección Museo.Nombre

Parada Urbana.Dirección Naturaleza.Nombre Parada Urbana.Dirección Naturaleza.Nombre

Parada Urbana.Dirección Entretenimiento.Nombre Parada Urbana.Dirección Entretenimiento.Nombre

Parada Urbana.Dirección Restaurante.Nombre Parada Urbana.Dirección Restaurante.Nombre

Parada Urbana.Dirección Rent-a-car.Nombre Parada Urbana.Dirección Rent-a-car.Nombre

Parada Urbana.Dirección Tienda.Nombre Parada Urbana.Dirección Tienda.Nombre

Parada Urbana.Dirección Aeropuerto.Nombre Parada Urbana.Dirección Aeropuerto.Nombre

Parada Puerto Antonio Navarrete Terrasa

Pág. 171


Mínimo (híbrido) Head (híbrido)

Parada Estación Mínimo (híbrido) Head (híbrido)

Parada Información Mínimo (híbrido) Head (híbrido)

Parada Agencia Mínimo (híbrido) Head (híbrido)



Parada Urbana.Dirección Puerto.Nombre Parada Urbana.Dirección Puerto.Nombre

Parada Urbana.Dirección Estación.Nombre Parada Urbana.Dirección Estación.Nombre

Parada Urbana.Dirección Información.Nombre Parada Urbana.Dirección Información.Nombre

Parada Urbana.Dirección Agencia.Nombre Parada Urbana.Dirección Agencia.Nombre

Pág. 172



6.3.16. Taxis Taxi Mínimo Head (híbrido)



Nombre Nombre Ciudad.Nombre Descripción Localización Dirección Ciudad.Mapa Localización Posición X Posición Y

Pág. 173



6.3.17. Paquete turístico Oferta Promocional Mínimo (híbrido)

Head (híbrido)

Régimen Estancia Mínimo Head

Precio Oferta Mínimo (híbrido)

Head (híbrido)


Nombre Ciudad.Nombre Alojamiento.Nombre Cadena Ag. Viajes.Nombre Nombre ID Ciudad ID Alojamiento ID Cadena Ag. Viajes Descripción Excursiones Coche de alquiler


Oferta.Nombre Régimen Estancia.Nombre Fecha inicio vigencia Fecha fin vigencia Oferta.Nombre Régimen Estancia.Nombre Fecha inicio vigencia Fecha fin vigencia Precio

Pág. 174



6.3.18. Excursiones Excursión Mínimo (híbrido) Head (híbrido)

Medio Tranporte Mínimo Head Excursión Ciudad Mínimo Head

Excursión Multimedia Mínimo (híbrido) Head (híbrido)


Nombre Medio Transporte.Nombre Nombre Medio Transporte.Nombre Descripción Punto de partida Punto final Recorrido Duración Dificultad Transportes Valor historico-natural Mapa

Nombre Nombre

Excursión.Nombre Ciudad.Nombre Excursión.Nombre Ciudad.Nombre

Excursión.Nombre Descripción Descripción Copyright Dirección Excursión.Nombre Tipo Multimedia.Nombre

Pág. 175



6.3.19. Teléfonos y direcciones útiles Información Mínimo Head (híbrido)


Horario Información Mínimo (híbrido)

Head (híbrido)


Nombre Nombre Ciudad.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Gratuito Ciudad.Mapa Localización Posición X Posición Y

Información.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Información.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 176



6.3.20. Agencias de viaje Agencia Mínimo Head (híbrido)


Cadena Agencias Mínimo Head (híbrido)

Agencia Multimedia Mínimo (híbrido) Head (híbrido)

Horario Agencia Mínimo (híbrido) Antonio Navarrete Terrasa

Nombre Nombre Ciudad.Nombre Cadena Agencias.Nombre Descripción Localización Dirección CP Teléfono Fax email URL Ciudad.Mapa Localización Posición X Posición Y


Agencia.Nombre Descripción Descripción Copyright Dirección Agencia.Nombre Tipo Multimedia.Nombre

Agencia.Nombre Pág. 177


Head (híbrido)



Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Agencia.Nombre Fecha inicio vigencia Fecha fin vigencia Día semana inicio Día semana fin Hora apertura mañana Hora cierre mañana Hora apertura tarde Hora cierre tarde

Pág. 178



6.4. 3ª Etapa: Diseño navegacional Notas: • Como enlaces unidireccionales sólo marcamos los que no tienen ninguna primitiva de acceso. En el caso de que sí la haya, se sobre-entiende que hay un camino de vuelta, y por tanto, no es necesario representarlo. En el primer caso sí es necesario reflejar explícitamente que habrá un enlace entre ambas entidades. • Al hacer el estudio de las relaciones complejas, hemos etiquetado los tres tipos diferentes con una letra que se les dio al definirlas en el apartado 4.3.. Recordemos: A: accesos jerárquicos B: accesos en relaciones N:M C: accesos múltiples


Pág. 179



6.4.1. Áreas geográficas Etapa 3.1. Estudio de las relaciones complejas Relación Nación-Región-Provincia

Nación-Región-ProvinciaCiudad Región-Provincia-Ciudad

Tipo Descripción A Es útil poder acceder a las provincias de una nación, porque se puede dar el caso de que uno conozca la provincia en la que está interesado, pero no el nombre de la región. A ídem 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 objetos multimedia, 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, no tiene sentido permitir ver todos los de sus regiones Slices derivados de las relaciones complejas En las relaciones de tipo A (accesos jerárquicos), no es necesario ningún cambio en la definición de los slices.

Etapa 3.2. Diagrama RMDM


Pág. 180


Nación

Región

Nación Multimedia

Región Multimedia

Provincia

Provincia Multimedia

Ciudad

Ciudad Multimedia



Tipo Multimedia

Pág. 181



6.4.2. Alojamientos Etapa 3.1. Estudio de las relaciones complejas 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 se puede llegar (se supone que muy esporádicamente) desde el hotel. Tampoco tiene ninguna utilidad que desde una cadena se pase a visitar la ciudad en la que está afincada. Relación Alojamiento-Alojamiento Servicio-Servicio Alojamientos

Tipo Descripción B Se trata de una relación N:M y lo que interesa es acceder de un alojamiento a sus servicios. En particular deseamos ver todos los servicios a la vez. Alojamiento-Tipo C Nos interesa acceder de un alojamiento a la Habitación-Habitaciones información de sus habitaciones, seleccionando qué tipo de habitación Habitaciones-TemporadaC En este caso nos interesa acceder desde una Régimen Estancia-Precio habitación a su precio, eligiendo primero la Habitación temporada y el régimen de estancia. Slices derivados de las relaciones complejas No es necesario ningún cambio en ninguna de las tres relaciones. En la primera, ya que la entidad Alojamiento Servicio no tiene ningún atributo propio (provienen de la relación N:M) y por tanto no es necesario que le ceda ningún atributo a la entidad Servicio Alojamientos. En la segunda y tercera, los slices head de Precio Habitación y Habitaciones, ya fueron definidos como híbridos y contienen los atributos necesarios que surgen de la relación.

Etapa 3.2. Diagrama RMDM Nota: nos es necesaria una nueva primitiva para representar el acceso condicionado a todos los elementos de una entidad a la vez. En este caso, si estamos en un alojamiento, con esta primitiva accedemos a todos sus alojamientos simultáneamente, todos a la vez, y no mediante un índice o uno tras otro en una visita guiada. Lo reflejaremos con la siguiente primitiva y la llamaremos acceso simultáneo:


Pág. 182



Cadena Alojamientos

Ciudad

Tipo Multimedia Tipo Alojamiento Alojamiento Multimedia

Alojamiento Categoría Alojamientos

Tipo Habitación

Alojamiento Servicio

Servicio Alojamientos

Habitaciones

Régimen Estancia

Temporada

Precio Habitación NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 183



6.4.3. Playas Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Playa-Playa Servicio-Servicio B Se trata de una relación N:M y lo que interesa es Playas acceder de una playa a los servicios de la misma. En particular, deseamos ver todos los servicios a la vez. Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que la entidad Playa Servicio no tiene ningún atributo propio (provienen de la relación N:M).


Ciudad

Tipo Playa

Playa Multimedia

Playa

Playa Servicio

Tipo Multimedia Servicio Playas

NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 184



6.4.4. Deportes Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Instalación deportiva- B Se trata de una relación N:M y lo que interesa es Instalación Servicio-Servicio acceder de una instalación a los servicios de la Deportes misma Instalación Deportiva- B Se trata de una relación N:M y lo que interesa es Deporte Instalación- Deporte acceder de una instalación deportiva a los deportes que en ella se practican Slices derivados de las relaciones complejas No es necesario ningún cambio en la segunda relación, ya que la entidad Instalación Servicio 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. Para ello es necesario crear un nuevo slice en la entidad Deporte para que tenga en cuenta esta cantidad, y el acceso no se hará a 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 desde ningú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 otro lugar. Deporte Head (híbrido)

Nombre Descripción Deporte Instalación.Cantidad



Pág. 185



Deporte

Ciudad

Deporte Multimedia

Deporte Instalación

Tipo Multimedia

Instalación deportiva

Instalación Multimedia

InstalaciónServicio

Horario Instalación

Servicio Deportes



Pág. 186



6.4.5. Eventos culturales Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Ciudad-Evento Ciudad-Evento B Se trata de una relación N:M y lo que interesa Cultural es acceder de una ciudad a todos sus eventos culturales. Evento Cultural-Evento B En este caso también nos interesa saber en qué Ciudad- Ciudad ciudades se da un evento cultural y poder navegar a ellas. Se podría haber incluido también un acceso jerárquico de ciudad a representación, pero se estimó que no era conveniente. Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que la entidad Evento Ciudad no tiene ningún atributo propio (provienen de la relación N:M).

Etapa 3.2. Diagrama RMDM Tipo Evento Evento Ciudad

Evento Cultural

Ciudad Evento Ciudad

Eventos Multimedia Centro Cultural

Represent ación

Tipo Multimedia



Pág. 187



6.4.6. Museos y monumentos Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Monumento-Monumento B Se trata de una relación N:M y lo que interesa Servicio-Servicio Monumentos es acceder de un monumento a los servicios del mismo. En este caso nos interesa acceder a todos los servicios a la vez. Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que la entidad Monumento Servicio no tiene ningún atributo propio (provienen de la relación N:M).


Ciudad Tipo Multimedia Tipo Monumento

Monumento

Monumento Multimedia

Periodo Histórico Monumento Servicio

Horario Monumento Servicio Monumento NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 188



6.4.7. Naturaleza Etapa 3.1. Estudio de las relaciones complejas Relación Ciudad-Naturaleza Naturaleza

Tipo Descripción Ciudad- B Se trata de una relación N:M y lo que interesa es acceder de una ciudad a todas sus áreas naturales. Naturaleza -Naturaleza Ciudad- B En este caso también nos interesa saber a qué Ciudad ciudades pertenece un área natural y poder navegar a ellas. Naturaleza-Naturaleza B Se trata de una relación N:M y lo que nos Servicio-Servicio Natural interesa es ver todos los servicios de un área natural Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que tanto la entidad Naturaleza Ciudad como Naturaleza Servicio no tiene ningún atributo propio (provienen en ambos casos de la relación N:M).


Ciudad

Naturaleza Ciudad

Tipo Naturaleza

Naturaleza Ciudad

Naturaleza

Naturaleza Servicio

Naturaleza Multimedia

Tipo Multimedia

Servicio Natural NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 189



6.4.8. Entretenimientos Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas.


Ciudad

Tipo Entretenimiento

Entretenimiento

Entretenimiento Multimedia

Tipo Multimedia Horario Entretenimiento NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 190



6.4.9. Restaurantes Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas.


Ciudad

Horario Restaurante Tipo Restaurantes

Restaurante

Categoría Restaurante

Restaurante Multimedia

Tipo Multimedia NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 191



6.4.10. Rent-a-car Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas. Tampoco aquí, como en alojamientos, las cadenas de rent-a-cars tienen interés turístico.


Ciudad

Horario Rent-a-car Cadena Rent-a-car

Rent-a-car

Rent-a-car Multimedia



Pág. 192



6.4.11. Tienda Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas. Igualmente se consideró que las cadenas de tiendas no tienen interés turístico y tampoco mantendrán navegación con la entidad ciudad.


Ciudad

Horario Tienda

Cadena Tiendas Tienda

Tipo Tienda

Tienda Multimedia



Pág. 193



6.4.12. Transporte aéreo Etapa 3.1. Estudio de las relaciones complejas Relación Vuelo-Tipo Tarifa Precio Vuelo

Tipo Descripción Aérea- C Una vez seleccionado un vuelo lo que interesa conocer es lo que nos va a costar según el tipo de tarifa que elijamos.

De nuevo se consideró que las compañías de transporte, igual que ocurrió con las cadenas de tiendas o de rent-a-cars, no tienen interés turístico y tampoco mantendrán navegación con la entidad ciudad. Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que el nombre del tipo de tarifa ya está incluido en el slice head de Precio Vuelo, que ya fue definido como híbrido.



Pág. 194



Ciudad

Aeropuerto

Aeropuerto Multimedia

Tipo Multimedia

Tipo Tarifa Aérea

Vuelo Precio Vuelo


Ciudad

Horario Vuelo


Tipo Multimedia



Pág. 195



6.4.13. Transporte marítimo Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Trayecto-Tipo Pasaje-Precio C Una vez seleccionado un trayecto en barco lo Pasaje que interesa conocer es lo que nos va a costar según el tipo de pasaje que elijamos (camarote, butaca, vehículo turismo, ...). Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que el nombre del tipo de pasaje ya está incluido en el slice head de Precio Pasaje, que ya fue definido como híbrido.

Etapa 3.2. Diagrama RMDM Ciudad

Puerto

Puerto Multimedia

Tipo Multimedia

Tipo Pasaje Trayecto Precio Pasaje


Ciudad

Horario Trayecto


Tipo Multimedia



Pág. 196



6.4.14. Transporte terrestre Etapa 3.1. Estudio de las relaciones complejas Relación Estación-Parada-Línea

Línea-Parada-Estación

Tipo Descripción B Se trata de una relación N:M y lo que interesa es acceder de una estación a las líneas que pasan por ella, con el fin de saber a donde se puede llegar. B En este caso también nos interesa saber por qué estaciones pasa la línea seleccionada.

Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que la entidad Parada no tiene ningún atributo propio (provienen de la relación N:M).



Pág. 197



Ciudad

Estación Multimedia

Estación

Tipo Multimedia

Parada Parada

Horario Tr. Terrestre

Línea

Medio Transporte

Compañía Transportes Cía Transportes Multimedia Ciudad Tipo Multimedia



Pág. 198



6.4.15. Transporte Urbano Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Parada Urbana-Parada Línea- B Se trata de una relación N:M y lo que interesa Línea Urbana es acceder de una parada urbana a las líneas que pasan por ella, con el fin de saber a donde se puede llegar. Línea Urbana-Parada Línea- B En este caso también nos interesa saber por Parada Urbana qué paradas pasa la línea seleccionada. Parada Urbana-Parada B Se trata de una relación N:M y lo que interesa Alojamiento-Alojamiento es acceder de una parada urbana a los alojamientos cercanos a ella. Alojamiento-Parada B En este caso también nos interesa saber qué Alojamiento-Parada Urbana paradas hay cercanas a un alojamiento Parada Urbana-Parada Playa- B Se trata de una relación N:M y lo que interesa Playa es acceder de una parada urbana las playas cercanas a ella. Playa-Parada Playa-Parada B En este caso también nos interesa saber qué Urbana paradas hay cercanas a una playa Parada Urbana-Parada B Se trata de una relación N:M y lo que interesa Instalación-Instalación es acceder de una parada urbana a las Deportiva instalaciones deportivas cercanas a ella. Instalación Deportiva-Parada B En este caso también nos interesa saber qué Instalación-Parada Urbana paradas hay cercanas a una instalación deportiva Parada Urbana-Parada Museo- B Se trata de una relación N:M y lo que interesa Museo es acceder de una parada urbana a los museos cercanos a ella. Museo-Parada Museo-Parada B En este caso también nos interesa saber qué Urbana paradas hay cercanas a un museo Parada Urbana-Parada B Se trata de una relación N:M y lo que interesa Naturaleza- Naturaleza es acceder de una parada urbana a las áreas naturales cercanas a ella. Naturaleza-Parada Naturaleza- B En este caso también nos interesa saber qué Parada Urbana paradas hay cercanas a un área natural Parada Urbana-Parada B Se trata de una relación N:M y lo que interesa Entretenim.- Entretenim. es acceder de una parada urbana a los entretenimientos cercanos a ella. Entretenim.-Parada B En este caso también nos interesa saber qué Entretenim.-Parada Urbana paradas hay cercanas a un entretenimiento Parada Urbana-Parada B Se trata de una relación N:M y lo que interesa Restaurante- Restaurante es acceder de una parada urbana a los restaurantes cercanos a ella. Restaurante-Parada B En este caso también nos interesa saber qué Restaurante-Parada Urbana paradas hay cercanas a un restaurante Parada Urbana-Parada Rent-a- B Se trata de una relación N:M y lo que interesa Antonio Navarrete Terrasa

Pág. 199


car- Rent-a-car Rent-a-car-Parada Rent-a-carParada Urbana Parada Urbana-Parada TiendaTienda

B

Tienda-Parada Tienda-Parada Urbana Parada Urbana-Parada Aeropuerto- Aeropuerto

B

Aeropuerto-Parada AeropuertoParada Urbana Parada Urbana-Parada PuertoPuerto

B

Puerto-Parada Puerto-Parada Urbana Parada Urbana-Parada Estación- Estación

B

Estación-Parada EstaciónParada Urbana Parada Urbana-Parada Información- Información

B

Información-Parada Información-Parada Urbana

B

Parada Urbana-Parada Agencia- Agencia

B

Agencia-Parada Parada Urbana

B

Agencia-

B

B

B

B

B


es acceder de una parada urbana a los rent-acars cercanos a ella. En este caso también nos interesa saber qué paradas hay cercanas a un rent-a-car Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a las tiendas cercanas a ella. En este caso también nos interesa saber qué paradas hay cercanas a una tienda Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a los aeropuertos (difícilmente habrá más de uno) cercanos a ella. En este caso también nos interesa saber qué paradas hay cercanas a un aeropuerto Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a los puertos (difícilmente habrá más de uno) cercanos a ella. En este caso también nos interesa saber qué paradas hay cercanas a un puerto Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a las estaciones cercanas a ella. En este caso también nos interesa saber qué paradas hay cercanas a una estación Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a los puntos de información turística cercanos a ella. En este caso también nos interesa saber qué paradas hay cercanas a un punto de información turística Se trata de una relación N:M y lo que interesa es acceder de una parada urbana a las agencias cercanas a ella. En este caso también nos interesa saber qué paradas hay cercanas a una agencia

Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que en todas las entidades intermedias de la relaciones, ninguna de ellas tiene ningún atributo propio (todos provienen de la relación N:M).


Pág. 200



Etapa 3.2. Diagrama RMDM Tipo Multimedia

Alojamiento P. Alojamiento P. Alojamiento


Ciudad

Cía Transportes Multimedia P. Playa

Playa P. Playa

P. Instalac.

Línea Urbana

Horario Urbano

Instalac. Deportiva

P. Instalac.

P. Museo

Museo

P. Museo

ParadaLínea

P. Naturaleza

Naturaleza

ParadaLínea P. Naturaleza

Entretenim. P. Entertenim. P. Entretenim.

P. Resturante

Restaurante P. Resturante

P. Rent-a-car

Parada Urbana

Rent-a-car

P. Rent-a-car

P. Tienda

Tienda

P. Tienda

P. Aeropuerto

Aeropuerto

Ciudad P. Aeropuerto

P. Puerto

Puerto P. Puerto

P. Estación

Estación

P. Estación

P. Información

Información

P. Infromación

P. Agencia

Agencia

P. Agencia



Pág. 201



6.4.16. Taxis Etapa 3.1. Estudio de las relaciones complejas 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 NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 202



6.4.17. Paquete turístico Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Oferta Promocional-Régimen C Una vez seleccionado una oferta lo que interesa Estancia-Precio Oferta conocer es lo que nos va a costar según el tipo de régimen de estancia que elijamos. Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que el slice head de Precio Oferta, ya fue definido como híbrido y contiene la información necesaria de las otras entidades.

Etapa 3.2. Diagrama RMDM Cadena Ag. Viajes

Alojamiento

Oferta Promocional

Ciudad

Régimen Estancia

Precio Oferta NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 203



6.4.18. Excursiones Etapa 3.1. Estudio de las relaciones complejas Relación Ciudad-Excursión Excursión Excursión-Excursión Ciudad

Tipo Descripción Ciudad- B Se trata de una relación N:M y lo que interesa es acceder de una ciudad a todas excursiones. Ciudad- B En este caso también nos interesa saber por qué ciudades (municipios) discurre una excursión y así poder navegar a ellas.

Slices derivados de las relaciones complejas No es necesario ningún cambio, ya que la entidad Excursión Ciudad no tiene ningún atributo propio (provienen de la relación N:M).

Etapa 3.2. Diagrama RMDM Medio Transporte Excursión Excursión Multimedia Excursión Ciudad

Excursión Ciudad

Tipo Multimedia Ciudad NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 204



6.4.19. Teléfonos y direcciones útiles Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas.


Ciudad

Información

Horario Información NOTA: Para simplificar el diagrama, no se incluyen los accesos desde las entidades Región, Provincia y Nación (los mismos que Ciudad)


Pág. 205



6.4.20. Agencias de viaje Etapa 3.1. Estudio de las relaciones complejas En esta categoría no se observan nuevas estructuras navegacionales derivadas de relaciones complejas.

Etapa 3.2. Diagrama RMDM Cadena Ag. Viajes

Cadena A.V. Multimedia

Tipo Multimedia

Agencia Viajes

Ciudad

Horario Agencia



Pág. 206



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 nos lleva a un nuevo menú donde se accede mediante índice a cada una de las categorías del sistema. Con ello se permite la búsqueda rápida a un elemento ya conocido, sin necesidad de tener que ir a su área geográfica, con la consiguiente ganancia de tiempo. Veamos el diagrama:


Pág. 207



Alojamiento

Playa

Nación

Región

Provincia

Ciudad

Instalación Deportiva Evento Cultural

Monumento

Naturaleza

Entretenimiento

Restaurante

Ren-a-car

Tienda

Aeropuerto

Puerto

Estación

Línea Urbana

Taxi

Oferta Promocional

Excursión

Información

Agencia Viajes


Pág. 208



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 son muy simples: cada entidad da lugar a una tabla. Cada slice se obtiene a partir de una vista, y los mecanismos de acceso no son más que sentencias de consulta a la base de datos 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 al comentar 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 de un elemento de una entidad. Otra, en un costado o abajo, contiene según los accesos obtenidos del modelo RMDM, los enlaces HTML a otras entidades. Cada uno de esos enlaces está representado con un texto (por ejemplo: Alojamientos) o con un icono. En un tercer frame, más pequeño, aparecen los enlaces estructurales, es decir, cómo ir del slice que está en pantalla a los otros slices de esa entidad. Por último, es necesario un último frame para los mecanismos generales de navegación, tales como volver al menú, volver a la última pantalla, ... Nótese que en vez de utilizar frames también pueden emplearse tablas, según las preferencias del diseñador, ya que el objetivo de dividir la pantalla 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 de fondo 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 se muestran todos sus atributos. En la parte superior de este frame, aparecen en un recuadro negro los slices de la entidad, que es el de 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án representados los hiperenlaces a las entidades Ciudad, Provincia, Región, Nación, Tipo de Monumento y Periodo Histórico, algunos enlaces directos y como el caso de Provincia, 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 otras entidades, que nos permite ir a ver los elementos multimedia, servicios, horarios y parada de transporte urbano más cercano. Por último, en el frame inferior derecho tenemos las herramientas de navegación general, como son en este caso volver al índice de monumentos de Palma, volver atrás en la navegación e ir a la home page. Antonio Navarrete Terrasa

Pág. 209



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 la navegación, mecanismo de historia, etc. En MINTour se utilizan CGIs utilizando el producto Oracle WebServer, que permite una conexión entre el servidor web y la base de datos. Para ello se utiliza el lenguaje de programación PL-SQL, que es una versión procedimental, propia de Oracle, de SQL, el lenguaje estándar de acceso a bases de datos.

Etapa 7: Construcción y tests Dado que la aplicación basada en nuestro modelo no ha llegado a implementarse, esta etapa no merece ningún comentario.


Pág. 210



6.6. Conclusiones Este análisis, al tratarse de un proyecto tan grande, con tantas entidades y relaciones, nos ha sido de gran utilidad a la hora de descubrir nuevos patrones de navegación, y fue la base para las mejoras a la metodología RMM que propusimos en el apartado 4.3. Al final de este apartado se resumen. A pesar de que finalmente nuestras ideas no han sido utilizadas en el proyecto europeo, el modelo final que hemos obtenido constituye un interesante modelo de navegación, más consistente e intuitivo que el existente. De hecho, el proyecto europeo dejó de lado la línea de un proyecto multimedia, para convertirse en un simple recuperador de información de la base de datos, sin ninguna navegación posible entre sus elementos. En cambio nuestra solución daría lugar a un sistema en el cual el usuario navegaría, igual que 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, ésta es la diferencia fundamental entre una aplicación multimedia-hipermedia y una de gestión: en la primera lo importante es la navegación y en la segunda la recuperación exacta de los datos que el usuario desea. Pero, pensamos que la situación es que el usuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entrar en el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas que tienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de una tienda y ofrecen visitas guiadas. En cuanto a la estructura de los datos, las relaciones entre unas categorías y otras han resultado ser bastante poco abundantes. El hecho de que las categorías no estén apenas relacionadas entre sí viene determinado por la estructura de la información de MINTour, muy jerarquizada, donde prácticamente toda la información son diferentes elementos turísticos de una ciudad. Es por ello que cada una de las categorías está relacionada con las áreas geográficas, pero no entre sí, salvo alguna excepción como la de los transportes urbanos. En el siguiente caso de estudio, el CD-ROM del Atles de les Illes Balears, la estructura de la información es bien diferente, mucho más rica, con muchas más interrelaciones 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 la metodologí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 tres tipos: • navegación jerárquica: permiten acceder desde una entidad directamente a otra entidad que está relacionada con una entidad que está por debajo de la jerarquía de la primera. Por ejemplo, permite acceder a los alojamientos de una provincia, ya que alojamiento está relacionado con ciudad, y éste es jerárquicamente inferior a provincia.


Pág. 211



• navegación en relaciones N:M: permite navegar de un extremo al otro de una relación N:M sin perder los datos de la entidad intermedia. Por ejemplo permite acceder 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 es parte. Por ejemplo permite que dado un vuelo, podamos elegir un tipo de tarifa y acceder a su precio. También se introdujo la primitiva de acceso simultáneo, que permite acceder a todos los elementos 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 alojamientos simultáneamente, todos a la vez, y no mediante un índice o uno tras otro en una visita guiada. Lo reflejaremos con la siguiente primitiva:

Y para terminar, hay que notar la novedad que supone dividir el problema en diferentes 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 a través de algunos enlaces que existen entre entidades de diferentes categorías, como pueda ser el caso de las paradas de transportes urbanos. En este caso ha sido bastante simple, pero dividir un gran problema en temas puede ser una tarea compleja.


Pág. 212


VII - Atles de les Illes Balears

Capítulo VII 3er CASO: CD-ROM DEL Atles de les Illes Balears En este caso de estudio trataremos el CD-ROM del Atles de les Illes Balears, [UIB98], que se ha ido desarrollando entre 1997 y 1998 en la Universitat de les Illes Balears, y en el cual el proyectista ha trabajado desde el inicio al final. El objetivo era el de crear un atlas multimedia de las Islas, destinado a las escuelas de secundaria de Baleares. La gran variedad y riqueza de la información contenida hacían imprescindible que antes de comenzar la implementación se llevase a cabo una etapa de análisis de la estructura y la navegación. Para ello, una vez más utilizamos la metodología RMM, con las mejoras que ya se han comentado, puesto que el modelo relacional, como veremos, se ajusta perfectamente a nuestras necesidades. En el primer apartado veremos la descripción de qué es el CD-ROM del Atles de les Illes Balears, en el segundo una primera aproximación al caso de estudio, que fue la base de un prototipo cuyas conclusiones dieron lugar al análisis definitivo que se presenta en el apartado tercero. Y como siempre, el capítulo se cierra con el apartado de conclusiones.

7.1. Qué es el Atles de les Illes Balears Para una descripción de lo que es y supone este proyecto, reproducimos íntegramente el pró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 multimedia que se publica en nuestra comunidad autónoma. Constituye una aportación destacada al conocimiento geográfico del territorio insular i recoge parte del trabajo encargado por la Direcció General d'Educació, realizado en soporte tradicional y editado el 1995, bajo el mismo título. Este atlas es una contribución importante i innovadora a la producción bibliográfica y de materiales didácticos que se promueve desde la Conselleria d'Educació, Cultura i Esports del Govern Balear y desde «Sa Nostra» Caixa de Balears, para construir un currículum propio sobre el medio y las ciencias sociales en las Islas, una vez que se han conseguido totalmente las transferencias educativas. En esta obra, de carácter geográfico, se analizan las características físicas y humanas del territorio insular, es decir, tanto el medio como las interrelaciones económicas, sociales y culturales, entre otras, que se generan a partir de la huella humana. El CD-ROM Atles de les Illes Balears constituye una herramienta didáctica versátil que se utiliza en distintos niveles educativos. Puede ser plenamente utilizado en la universidad, así como en distintos cursos de enseñanza secundaria, por parte del alumno o como material de trabajo para el profesor, ya que a la mayoría de temas se llega a un nivel de profundidad bastante elevado. Antonio Navarrete Terrasa

Pág. 213



Un trabajo como este ha requerido un equipo interdisciplinar que conjugase la autora, con el tratamiento cartográfico y la implementación multimedia. La realización ha ido a cargo de un conjunto de especialistas de la Universitat de les Illes Balears que cuentan con experiencia, tanto en el trabajo de textos didácticos, con mapas y sin, como en otros CD-ROM, entre los cuales hay que citar 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 los estudiantes y a los ciudadanos de las Baleares en general, no sólo conocer mejor nuestras islas, sino también contribuir al hecho de que sea mucho más fácil poderlo hacer. El CD-ROM Atles de les Illes Balears podrá ayudar, sin duda, a valorar y querer más a nuestra tierra y nuestra cultura. »


Pág. 214



7.2. Primer estudio del caso En un primer estudio, nos centraremos en lo que nosotros consideramos como lo que hubiera sido la situación ideal. Un prototipo basado en esta situación ideal fue presentado a las otras dos partes que participaban en el proyecto, autores y cartografía digital, 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 etapa previa 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-ROM debía poder utilizarse tanto en ordenadores PC con Microsoft Windows 95 como en ordenadores Apple Macintosh. Se trata, sin embargo de un requerimiento que no condiciona para nada el desarrollo del proyecto. Sin embargo, desde un primer momento, el grupo de Multimedia del Dept. de Matemàtiques i Informàtica, decidimos el utilizar una interfaz de tipo web. Las razones fundamentales fueron tres: • Tras el estudio de varios atlas multimedia publicados por grandes compañías comprendimos que la principal carencia que ofrecían era la imposibilidad de comparar dos mapas. En realidad eso es fruto de trabajar con una única pantalla sobre la cual se ha de mostrar toda la información. Al mostrar otra información, como un texto, una foto u otro mapa, se pierde la información que 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 varias ventanas 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 una interfaz web suponía una novedad en aquel momento, y no se debe olvidar el carácter de investigación que debe tener una universidad. Nuevas conclusiones 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 incide directamente 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ón debe funcionar en los dos navegadores más utilizados en el momento, que son el Netscape Navigator y el Microsoft Explorer, ambos tanto para Macintosh como para Windows 95. Se especificó que la versión mínima de dichos navegadores sería la 4, aunque finalmente se consiguió también que la aplicación funcione en la versión 3 del Netscape Navigator (no así en la de Microsoft Explorer debido a sus carencias propias). Antonio Navarrete Terrasa

Pág. 215



• Los lenguajes de programación que se deberán utilizar son HTML y JavaScript. Se desestimó el uso generalizado de Java, ya que presenta numerosos problemas de una interfaz muy inestable y dependiente de la plataforma (el mismo applet se ve de forma diferente según el navegador y la máquina). Sólo un applet para una aplicación didáctica muy concreta fue utilizado, testeando que funcionase correctamente en todas las plataformas requeridas. • Se decide que se deben incorporar modelos en tres dimensiones de las Islas. Para ello se utilizará VRML 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 si no es desde un servidor web, lo cual no es posible desde un CD. Ello nos obliga a trasladar toda la estructura relacional a una estructura de directorios, si bien hace bastante más compleja tanto la programación como la introducción de datos, y en particular la confección de índices (hay índices de todos los mapas, todos los textos, todos las tablas, ...) se deberá hacer manualmente.

7.2.2. Etapa 1: Diseño Entidad-Relación El entidad central del modelo es la entidad “Nodo”. Un nodo corresponde a un tema concreto aplicado a un área geográfica concreta. Por ejemplo, transportes marítimos en Menorca. Tanto los temas, como las áreas están jerarquizadas. Relacionado con ese nodo es donde hay una gran cantidad de información: entradas del glosario, 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 de información geográfica (SIG o GIS en inglés). Y cada una de esas capas puede tener unos topónimos asociados, unos elementos de leyenda (que a su vez pueden estar asociados a una definición, que también puede tener elementos multimedia), y se le puede aplicar varios zooms. Igualmente un gráfico también tiene una serie de elementos de leyenda, con su posible definición, y unos zooms.


Pág. 216



Área Geográfica

Nivel Tema Tema

Nivel Área

Nodo/Sabías

Sabías que

Tipo Multimedia Nodo Multimedia

Nodo/ Glosario

Nodo

Entrada Glosario

Nodo/ Bibliografía Cita Bibliografía

Multimedia Mapa

Gráfico

Texto

Tabla

Topónimo Multimedia El. Leyenda Gráfico

Gráfico Zoom

Capa

Topónimo Zoom Topónimo Capa

Distancia

Capa Zoom

Elemento Leyenda

Multimedia

Definición

Definición Multimedia

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ño de los slices. En realidad cada entidad no tiene más que un slice con toda la información correspondiente.


Pág. 217



7.2.4. Etapa 3: Diseño navegacional Etapa 3.1. Estudio de las relaciones complejas Relación Tipo Descripción Nodo-Nodo Multimedia- B Lo que deseamos es poder acceder a los Multimedia elementos multimedia de un nodo determinado. Multimedia-Nodo B Puede ser útil poder acceder a los nodos en los Multimedia-Nodo que aparece el elemento multimedia que estamos viendo. Nodo-Nodo Sabías-Sabías B Lo que deseamos es poder acceder a las que preguntas tipo sabías que...? de un nodo determinado. Nodo-Nodo Glosario- B Lo que deseamos es poder acceder a las palabras Elemento Glosario del glosario de un nodo determinado. Nodo-Nodo Bibliografía-Cita B Lo que deseamos es poder acceder a las citas Bibliografía bibliográficas de un nodo determinado. Topónimo-Topónimo B Lo que deseamos es poder acceder a los Multimedia-Multimedia elementos multimedia de un topónimo determinado. MultimediaTopónimo B Puede ser útil poder acceder a los topónimos en Multimedia- Topónimo los que aparece el elemento multimedia que estamos viendo. Topónimo- Topónimo Capa- B Lo que deseamos es poder acceder a los Capa topónimos de una capa determinada. CapaTopónimo Capa- B Puede ser útil poder acceder a las capas en las Topónimo que aparece el topónimo que estamos viendo. DefiniciónDefinición B Lo que deseamos es poder acceder a los Multimedia-Multimedia elementos multimedia de una definición determinada. MultimediaDefinición B Puede ser útil poder acceder a las Definiciones Multimedia- Definición en los que aparece el elemento multimedia que estamos viendo. Capa-Zoom-Capa Zoom C Lo que deseamos es que a partir de la capa que estamos viendo, podamos elegir los zooms disponibles y ver la capa a ese zoom (ver el objeto correspondiente de la entidad Capa Zoom) Gráfico-Zoom-Gráfico Zoom C ídem Topónimo-TopónimoC Queremos que, al ver un topónimo, podamos Distancia elegir otro y ver la distancia que los separa.


Pág. 218



Etapa 3.2. Diagrama RMDM Área Geográfica

Nivel Tema

Nivel Área

Tema Sabías que

Tipo Multimedia Nodo/Sabías

Elemento Glosario

Nodo Nodo Multimedia

Nodo/Glosario

Nodo/Bibliografía

Cita Bibliografía

Nodo Multimedia

Texto

Multimedia Mapa Topónimo Capa

Gráfico

Tabla

Topónimo Capa

El. Leyenda Gráfico

Capa Zoom

Topónimo Capa

Gráfico Zoom

Topónimo

Topónimo Capa

Capa Zoom Distancia

Elemento Leyenda

Definición

Def. Multimedia

Multimedia Def. Multimedia


Pág. 219



7.3. Segundo (y definitivo) estudio del caso Un prototipo basado en la estructura anterior fue discutido con el Departamento de Geografía, y se tomaron una serie de decisiones, algunas marcadas por los aspectos tecnológicos de los sistemas de información geográfica, que hicieron variar drásticamente el modelo anterior. Aquí se detallan esos cambios, fruto de tales discusiones: • Tanto los mapas como los gráficos se tratan como imágenes simples, en formatos bitmap como GIF o JPEG. Esto conlleva que ya no hay información de capas. La decisión vino marcada, tras varias pruebas, por la imposibilidad de manejar imágenes con formato vectorial en la plataforma en la que se debía ejecutar la aplicación (un navegador web). • Debido también a que los mapas y gráficos se consideran como una imagen y ello impide 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 realidad desaparecen de la estructura. A pesar de que hay un índice toponímico con cientos de topónimos de las Islas, el Dept. de Geografía decidió que no se tomaría en consideración los topónimos que aparecen en un nodo, mapa, ... • La información relacionada con glosario, bibliografía, sabías que, y elementos multimedia diferentes de fotos (es decir, vídeos y panorámicas) deja de estar relacionada con el nodo y pasa a ser del tema entero de nivel 2. Esto tiene una excepción: se permite un enlace entre términos importantes que aparezcan en el texto de un nodo y su definición (en la entidad Entrada Glosario). Mientras que los sabías que 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 un lado y vídeos y panorámicas por el otro. Las fotos están asociadas a un tema concreto en una escala concreta, mientras que los vídeos y panorámicas, al ser mucho 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 todos los 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 aparezcan los niveles de archipiélago e isla, pero que en determinadas ocasiones alcanza hasta nivel comarcal y municipal.

•

En cuanto a la estructura temática, la dirección del proyecto, fija que se establecerán tres 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 es diferente, se decidió considerar como un cuarto bloque a la presentación del atlas.


Pág. 220



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 cinco para los otros dos. Para cada uno de estos temas se confeccionará una visita guiada, que es una secuencia de pantallas que muestran qué es lo más importante que 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. La información de este nivel de temas está a su vez estructurados en tantos niveles como al autor estime oportuno (si bien se recomendó sólo llegar hasta un cuarto nivel 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 nuevas especificaciones:


Pág. 221



Sabías que Tema Nivel 1

Tema Nivel 2

Nodo Visita Guiada

Tema/ Bibliografía

Cita Bibliografía

Tema/ Glosario

Entrada Glosario

Tema/ Multimedia

Elemento Multimedia

Tema Información

Tipo Multimedia Área Geográfica

Topónimo Nodo Información

Nivel Área

Texto/Nodo

Mapa/Nodo

Gráfico/Nodo

Tabla/Nodo

Foto/Nodo

Texto

Mapa

Gráfico

Tabla

Foto

Leyenda/ Mapa

Elemento Leyenda

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 un slice con toda su información.


Pág. 222



7.3.4. Etapa 3: Diseño navegacional Etapa 3.1. Estudio de las relaciones complejas Relación Tema Nivel Información-Nodo Información

Tipo Descripción 2-Tema A En realidad aquí lo que nos interesa no es acceder directamente al nodo desde el tema de nivel 2, sino permitir que desde el nodo se pueda volver al tema de nivel 2, ya que desde ahí se puede acceder a sabías que, glosario, bibliografía y elementos multimedia. Tema Nivel 2-Tema / B Lo que deseamos es poder acceder a las palabras Glosario-Elemento Glosario del glosario de un tema determinado. Tema Nivel 2-Tema / B ídem Bibliografía-Cita Bibliografía Tema Nivel 2-Tema / B ídem. Multimedia-Elemento Multimedia Nodo Información-Nodo / B Lo que deseamos es poder acceder a los textos Texto-Texto de un nodo de información determinado. Nodo Información-Nodo / B ídem Mapa-Mapa Nodo Información-Nodo / B ídem Gráfico-Gráfico Nodo Información-Nodo / B ídem Tabla-Tabla Nodo Información-Nodo / B ídem Foto-Foto Mapa-Leyenda Mapa- B Lo que interesa es acceder a los elementos de Elemento Leyenda leyenda de un mapa, para formar la leyenda. Tema Información-Área C La navegación principal es la temática. De tal Geográfica-Nodo modo, lo que deseamos es que una vez en un Información tema, podamos ver la lista de áreas geográficas en que ese tema es aplicable y ver tras seleccionar uno, ver su información (el nodo).

Etapa 3.2. Diagrama RMDM Nota: nos es necesaria una nueva primitiva para representar el acceso a un elemento aleatoriamente. En este caso concreto, dado un tema de nivel 2, accederemos a uno de sus sabías que, de forma aleatoria, sin saber exactamente a cuál. Lo haremos con la siguiente primitiva y la llamaremos acceso aleatorio:


Pág. 223


Tema Nivel 1


Sabías que

Tema/Bibliografía

Cita Bibliografía

Tema/Glosario

Entrada Glosario

Tema/Multimedia

Elemento Multimedia

Tema Nivel 2

Tema Información

Nodo Visita Guiada

Tipo Multimedia Área Geográfica Nivel Área

Topónimo Nodo Información

Texto/Nodo

Mapa/Nodo

Texto

Mapa

Gráfico/Nodo

Gráfico

Tabla/Nodo

Foto/Nodo

Tabla

Foto

Leyenda/Mapa

Elemento Leyenda

Definición

Estructura de menús La estructura de menús se divide en dos ramas principales. Por un lado el acceso a temas y por el otro el acceso a índices. En cuanto al primero se accede mediante un índice a la entidad “Tema Nivel 1”. En el segundo caso se accederá a otro menú donde se tendrán las opciones de índice de textos, de mapas, de gráficos, de tablas, de fotos, de elementos multimedia, glosario, bibliografía, índice toponímico y índice temático (simplemente un fichero donde se incluye todo el índice completo). Antonio Navarrete Terrasa

Pág. 224



No lo integraremos en el diagrama anterior porque sería imposible de leer, ya que desde el menú de índices se accede a un gran número de entidades, pero lo veremos así representado:

Tema Nivel 1

Tema Nivel 2

Texto

Mapa

Elemento Multimedia

Tabla

Gráfico

Entrada Glosario

Cita Bibliografía

Foto

Topónimo

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ón web que ha de ser ejecutada sobre CD-ROM imponía la restricción de la imposibilidad de trabajar con bases de datos. Para sustituir la base de datos se tuvo que diseñar una estructura de directorios con el fin de ordenar los aproximadamente dos mil archivos de material. Exponemos a continuación las reglas que se siguieron: Cada tema tiene un directorio, estructurados jerárquicamente. Cada uno de los tres temas de nivel 1, tiene un directorio, denominado 1, 2 y 3, respectivamente. Cada uno de los temas de nivel 2 tendrá su directorio dentro de su de tema de nivel 1. Por ejemplo en el directorio 2 habrá los subdirectorios 21, 22, 23, 24 y 25, para cada uno de los cinco temas que existen. Y lo mismo ocurre con los temas de información (niveles 3 y 4). La pertenencia de un texto, tabla, mapa, ..., a un tema es obvia: incluyéndolo en el directorio del tema correspondiente. Lo mismo ocurre con elementos de glosario, citas bibliográficas, sabías que y elementos multimedia, que serán todos incluidos en el Antonio Navarrete Terrasa

Pág. 225



directorio de segundo nivel. En el caso de los sabías que, se incluye un archivo para cada uno, mientras que en el caso de los demás lo que se incluye en un único archivo con referencias. El mismo caso que los sabías que es el de los nodos de visita guiada de un tema de nivel 2. Cada elemento, además de pertenecer a un directorio concreto de tema, está codificado siguiendo una regla. • La primera letra indica el tipo de elemento de que se trata (se utilizan dos letras para los elementos de nivel 2): En el caso de elementos de nivel 2 Glosario GL 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ández Coca, una buena estructura navegacional será de gran utilidad para la confección de la interfaz de usuario coherente e intuitiva. A continuación se describe la interfaz y su profunda relación con la estructura:


Pág. 226



Al entrar en la aplicación aparece una ventana a la izquierda, donde tenemos cinco bloques en los que se estructura el atlas. Nosotros únicamente nos centramos en los dos primeros (temas e índices) que son los relacionados con la estructura. Los demás bloques corresponden a aplicaciones didácticas (como por ejemplo, juegos), ayuda y créditos. Así pues, vemos en la imagen el menú principal del modelo en el que se elegía entre 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 en el menú principal que vimos en el diagrama RMDM, donde accedemos mediante un índice condicionado a los temas de nivel 1. Lo vemos en la imagen:


Pág. 227



Al seleccionar uno, se despliega el índice condicionado de los temas de nivel 2, como vemos en la siguiente imagen:

Al elegir uno de ellos, ocurren dos cosas, en dos ventanas diferentes: • En la primera, aparece el primer elemento de la visita guiada de la entidad “Nodo de visita guiada”. En esta pantalla aparece también la barra de herramientas, sobre la que volveremos a hablar, y en la que se pueden apreciar los botones “+” y “-” para avanzar y retroceder, respectivamente, dentro de la visita guiada. • En la segunda, aparece el índice condicionado de los temas de información. Lo vemos en la imagen:


Pág. 228



Al elegir uno de esos temas de información, se accede al “nodo de información”, que se cargará en la ventana central. Aparece no sólo el título del nodo, sino que toda la información de textos, mapas, leyendas, gráficos, tablas y fotos relacionada con dicho nodo. Es un acceso del tipo “todos a la vez”. Lo apreciamos en la imagen. El diseñador decidió que se debía permitir visualizar inmediatamente estos elementos, sin necesidad de tener que pulsar ningún otro botón . No obstante en la barra de herramientas se permite acceder individualmente a cada una de las entidades mapa, leyenda, gráficos, tablas y mapas (también decidió que fotos no era necesario).


Pág. 229



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 los nodos de información esta sección queda inhabilitada.


Pág. 230



• En la segunda tenemos la navegación que nosotros denominamos global, en contraposición de la local, que veremos en la siguiente sección. En la fila superior tenemos opciones generales de navegación como son la de volver atrás en la historia (botón 9), copiar esta ventana a otra nueva (8), ver/ocultar la venta de contenidos (temas de información) (7) y ver/ocultar más información si la hay (6). En las otras dos filas, además de imprimir (12), se permite acceder a la entidad “tema de nivel 2” para poder acceder a sus sabías que (13), elementos de glosario (16), multimedia (vídeos y panorámicas) (17) y bibliografía (15). Otro punto importante es que permite volver a seleccionar el área geográfica para acceder mediante el acceso múltiple a otro nodo de información, del mismo tema, pero de distinto lugar (menú desplegable 18). Por último hay un enlace al índice de topónimos (19) (no hay ninguna relació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 estaban por encima en la estructura, es decir que surgían de la inferencia de la relación jerá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 a la vez”. Es decir se utilizan accesos condicionados, no inferidos, o lo que es lo mismo se acceden a elementos propios de este nodo, mientras que en el caso anterior eran elementos propios del tema, y por tanto serán comunes en todos 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 vemos en la imagen:


Pág. 231



Desde aquí, eligiendo una opción se accede, mediante un índice, a la entidad correspondiente (mapa, texto, ...). Vemos en la imagen como aparece una nueva ventana con el índice de una de estas entidades, la de gráficos concretamente, a la izquierda, y al elegir uno de ellos aparece en la parte derecha.

7.3.6.1. Conclusiones de esta etapa En una situación ideal, todo el equipo que participa en el desarrollo debe conocer perfectamente la metodología, pero a menudo esto no ocurre, especialmente en el caso del personal no informático, que muchas veces es externo al grupo de desarrollo. Éste era 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 se describen todas las pantallas que la aplicación tendrá, una lista de todos los iconos y elementos gráficos que serán necesarios. Para hacer esto, nuestra línea de acción fue la de preparar un prototipo para que el diseñador viera la estructura de la aplicación y los significados 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 diferentes para cada sección. El siguiente paso es integrarlo en el prototipo y confeccionar la anteriormente citada lista de elementos gráficos que son necesarios. En concreto ya explicamos en los comentarios a las mejoras de RMM que nuestra propuesta es la de que por un lado haya un icono para cada uno de los accesos estructurales (internos a la entidad) y por otro, también un icono para todos los accesos navegacionales, ya sean directos o inferidos. Todos deben ir acompañados de su significado. Así pues, a partir de esa lista y con la ayuda del segundo prototipo, el diseñador confecciona toda el conjunto de elementos gráficos de la aplicación. Nótese que la lista que se le entrega al diseñador Antonio Navarrete Terrasa

Pág. 232



debería ser completada con los iconos que él ha asignado; esta lista es útil mantenerla para posteriores mantenimientos. Otro aspecto importante, es que si bien el modelo RMDM nos permite saber qué elementos aparecerán en cada pantalla de la aplicación, la interfaz aplicada directamente puede ser excesivamente rígida. Es por tanto que se debe, no sólo permitir, sino incentivar 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 la pantalla. Por ejemplo, el hecho de que unos elementos aparezcan en una ventana y otros en otra, y otros en el frame principal, es en última instancia responsabilidad del diseñador. En este sentido, nuestro método de comunicación entre diseñador y desarrolladores 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, pueda ser 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 la navegación, mecanismo de historia, control de ventanas, etc. Para ello su programación se 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 de aplicaciones 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 la construcción de la aplicación corrió a cargo de Daniel Soto, Francesc Mateu y el proyectista, contando con la colaboración de numerosos compañeros en la integración de material multimedia.


Pág. 233



7.4. Conclusiones Como hemos podido observar, éste ha sido el caso de estudio en el que más se ha profundizado, sin duda porque ha sido 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 de evaluarla. En el segundo, MINTour, el objetivo ya era el de hacer la aplicación completa a 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 la metodología hasta obtener la aplicación final. Precisamente, como principal conclusión de este caso de estudio, consideramos que podemos citar que se ha demostrado que sí es posible el hacer un desarrollo completo de una aplicación siguiendo la metodología RMM, con una serie de mejoras que ya se han comentado. 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 fase quinta, Diseño de la interfaz de usuario, donde se interactúa directamente con el diseñador gráfico, que a menudo no conoce nuestra metodología. En concreto, nosotros hemos incorporado a la metodología, la lista de los elementos gráficos así como un conjunto de layouts para representar la estructura de la pantalla, que ya se han sido citados en las conclusiones acerca de la quinta etapa. Para terminar, recordar que se ha introducido una nueva primitiva de acceso, la de acceso aleatorio, que permite acceder a los elementos de una entidad aleatoriamente. Lo representamos así:

Un ejemplo de su utilización es que dado un tema de nivel 2, accederemos a uno de sus sabías que, de forma aleatoria, sin saber exactamente a cuál.


Pág. 234


VIII - Conclusiones

Capítulo VIII CONCLUSIONES 8.1. Resumen final y conclusiones 8.1.1. Modelo de Dexter El modelo de Dexter se definió en 1998 con el objetivo de que sirva como un estándar para comparar las características y funcionalidades de varios sistemas de hipertexto. También como una base sobre la cual desarrollar estándares para interoperabilidad e intercambio entre sistemas de hipertexto. Otro punto importante es el de proveer de una terminología común al campo del hipertexto. El modelo divide el sistema hipertexto en tres capas diferentes, como lo muestra la figura: capa de tiempo de ejecución (run-time layer) Especificaciones de presentación capa de almacenamiento (storage layer) Anclaje (anchoring) capa del componente (within-component layer)

Exponemos aquí, resumidos, los puntos clave del modelo: • El concepto fundamental del modelo es el de componente, que es lo que conocemos típicamente como nodos (componentes compuestos), que contienen fragmentos de texto, gráficos, animaciones, (componentes atómicos). • La capa de almacenamiento se centra en estudiar los mecanismos por los cuales se unen los componentes y los enlaces, formando una especie de base de datos que almacena la jerarquía de componentes y los enlaces que los interconectan. • La capa del componente refleja los contenidos y estructura dentro de los componentes, y que al ser tan variados, Dexter no profundiza, dando libertad en este nivel. • Una parte fundamental del modelo de Dexter es la interfaz entre las capa de almacenamiento y la capa del componente. Se basa en el mecanismo de anclaje (anchoring). Antonio Navarrete Terrasa

Pág. 235


VIII - Conclusiones

• En cuanto a la capa de tiempo de ejecución, ésta provee al usuario de unas herramientas para acceder, ver y manipular la estructura de la red de hipertexto, sobre la cual Dexter apenas si ofrece unas ideas básicas, debido al gran número de posibles herramientas para acceder, ver y manipular un hipertexto. • Un punto importante es la interfaz entre esta capa y la capa de almacenamiento, a la que llama especificaciones de presentación (presentation specifications). Ésta es un mecanismo que permite que la forma en que un componente se presenta al usuario pueda estar en función no sólo de una herramienta de hipertexto específica (es decir, de una capa de tiempo de ejecución específica), sino que puede ser una propiedad del componente por sí mismo, del enlace tomado para llegar a tal componente o también de las preferencias del usuario. Dexter fue el primer intento de modelar el hipertexto y de dar una terminología común para este, por entonces, nuevo campo. No hay que olvidar que sus comienzos datan de 1988, cuando los sistemas de hipertexto-hipermedia estaban muy lejos de lo que son hoy. De hecho, la principal carencia que se puede observar en este modelo es que, a pesar de que los autores lo recomiendan para tanto hipertexto como hipermedia, no aborda en ningún momento la complejidad de los distintos medios. En realidad, se podría decir que el modelo está fundamentalmente destinado a sólo hipertexto, y la aplicación a la hipermedia es muy difícil. Por ejemplo, el concepto de valor del ancla lo hace en función de la posición del ancla en el texto, pero esto en otro medio no tiene sentido. 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ó el modelo de 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 utilizar en 1988), el modelo especifica, por primera vez y muy detalladamente, cómo es la estructura interna de un hipertexto. Incluso define unas estructuras que no habían sido utilizadas hasta entonces 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 por aquel 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, la especificación de enlaces entre componentes y el uso de anclas, el modelo de Amsterdam lo extiende añadiendo las nociones de tiempo, presentación a alto nivel de atributos y enlaces de contexto. Y ése el precisamente el principal interés del modelo de Amsterdam, el que contemple la 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 es el tiempo, que no fue incluida en el modelo de Dexter.


Pág. 236


VIII - Conclusiones

8.1.3. Modelo HDM En HDM se divide el proceso de diseño de una aplicación en dos partes: authoring-inthe-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 del contenido de los nodos. El modelo, como es lógico se centra en la primera, en la estructura de la aplicación. La terminología base del HDM es bastante diferente a la de Dexter y se puede prestar a confusión. El equivalente de nodo es lo que denominan unidad. Las unidades se agrupan mediante una visita guiada o un índice, formando componentes, que a su vez se agrupan jerárquicamente en lo que denomina entidades. Asimismo hay varios tipos de enlace; los más importantes en la estructura son los que unen componentes dentro de una entidad, y se denominan enlaces de componente o de perspectiva; los enlaces estructurales conectan componentes de la misma entidad; por último los enlaces de aplicación conectan componentes y entidades de distinto tipo, y son independies de la estructura La principal motivación de HDM es crear un modelo basado en las anteriores primitivas antes de comenzar a desarrollar que ayudará a conseguir una navegación más consistente y rica. Además HDM puede resultar útil también para evaluar aplicaciones ya desarrolladas, con el fin de detectar errores en la estructura navegacional. Sin embargo, nuestra experiencia nos ha demostrado que realizar un modelo siguiendo las normas de HDM es extremadamente complicado cuando el número de entidades involucradas crece. En particular, era prácticamente imposible representar la estructura de 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 nos permitirá, en teoría, obtener una navegación más estructurada y, por tanto, más regular e intuitiva. Lo hace de una forma sencilla, simplemente añadiendo unas primitivas a lo que es un modelo entidad-relación tradicional. Es de gran interés, bajo mi punto de vista, el concepto de slice, que permite agrupar datos de una entidad en diferentes pantallas, y es que, al estar hablando de diferentes medios, la información de una entidad puede ser muy variada. Para dar una idea más al respecto, podría ser interesante que un vídeo sobre un hotel, mostrando sus interiores, aparezca en una pantalla diferente de otro que muestre su piscina. También es interesante la primitiva de grupo, que permite 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 que se crea una metodología completa, con una definición de fases, y no únicamente un modelo de datos. Además está basado en un modelo de datos relacional, lo cual se ajusta perfectamente no sólo a nuestros casos de estudio si no a la gran mayoría de las aplicaciones existentes.


Pág. 237


VIII - Conclusiones

Pero, a mi entender, los mecanismos de acceso a la información son excesivamente simples. Pueden ser suficientes para un problema con pocas entidades, per no si el número crece. Un importante problema es que no se permite hacer una consulta a partir de dos entidades. Veamos un ejemplo: en el proyecto MINTour, si la entidad Hoteles está relacionada con ciudad, N a 1, y ésta a su vez con región, también N a 1, no hay forma de permitir ver todos los hoteles de una región, sino es yendo de ciudad en ciudad y después, en cada una de ellas, visualizando sus hoteles. Vemos por tanto, que sería necesario poder establecer un enlace navegacional no sólo entre entidades relacionadas directamente, 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 las consultas han de ser tan simples como que dado una ciudad qué hoteles tiene, que campings, que puertos y aeropuertos, etc. Pero, por ejemplo, sería imposible explicitar una 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 correspondiente a la construcción del diagrama Entidad-Relación, se nos dice que las relaciones N:M se descompongan en dos relaciones 1:N. Esto es algo que se hace en otras metodologías como, por ejemplo, SSADM. Pero lo que no se puede hacer es obviar la entidad que resulta en medio. Lo veremos claro con el ejemplo que utilizan los autores en el artículo y que trata de un sistema de cursos, en los que se reflejan los profesores, sus publicaciones, ... En el artículo, los autores rompen la relación N:M entre profesores y cursos, creando dos relaciones nuevas, 1:N de profesores a cursos y viceversa. Pero se olvidan de los datos que deben guardarse de la relación original, como por ejemplo cuántas horas imparte el profesor de dicho curso. Y no lo hacen porque entonces, con una entidad en medio, no habría forma de saber los cursos que imparte cierto profesor, o qué 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 no hemos profundizado debido a que nuestros casos de estudio son únicamente aplicaciones de consulta, sin actualizaciones por parte del usuario. Pero es obvio que se deberí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 datos de más de una entidad), mínimos (la mínima parte de una entidad que es necesaria para identificar uno de sus elementos) y los m-slices (permite combinan primitivas de acceso con otros slices de otras entidades para crear un m-slice). Nuestra opinión al respecto es positiva en los dos primeros casos y negativa con respecto a los m-slices, ya que lo que propone es crear la estructura de la navegación no en base a las entidades sino a los slices, es decir a conjuntos de atributos. Así, mientras los primeros han sido ampliamente utilizados en nuestros casos de estudio, los últimos no.


Pág. 238


VIII - Conclusiones

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 e híbridos, no así lo m-slices, consideramos que la solución para que RMM sea aprovechable es la creación de unas nuevas estructuras de navegación que doten de una mayor flexibilidad al modelo. A continuación explicamos las nuevas estructuras introducidas: • navegación jerárquica: al tener varias relaciones 1:N encadenadas, se permite navegar 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, se representarán con trazo discontinuo. • navegación en relaciones N:M: se permite navegar de un extremo al otro de la relación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberán incluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidad intermedia. • navegación múltiple: se crean unas nuevas primitivas que permiten el acceso múltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de la que la entidad destino es parte. En el enlace quedará especificado qué entidad es la origen, cuál la destino y cuál la tercera. Recordar que esta navegación es especialmente apropiada en estructuras todoparte. • acceso aleatorio: permite acceder a un elemento aleatoriamente. Por ejemplo, en el Atles, dado un tema de nivel 2, accederemos a uno de sus sabías que, de forma aleatoria, sin saber exactamente a cuál. • acceso simultáneo: permite representar el acceso a todos los elementos de una entidad a la vez. Por ejemplo, en MINTour, si estamos en un alojamiento, con esta primitiva accedemos a todos sus alojamientos 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 siguiente tabla:


Pág. 239


VIII - Conclusiones

Hiperenlace Hiperenlace jerárquico inferido Índice Visita guiada Visita guiada indexada Acceso aleatorio Acceso simultáneo Índice múltiple



Entity Rel. N:M

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

Interfaz de usuario Al hacer el estudio de las fases 4 a 7 de la metodología RMM, y especialmente de la etapa 5, diseño de interfaz de usuario, consideramos que hay una organización de la pantalla 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 los autores no la tuvieron en cuenta, quizás porque los navegadores de aquel entonces aún no tenían soporte para ello. Se trata del uso de marcos (frames) de HTML (o si se prefiere de tablas). Así, podríamos tener un marco principal la información del objeto seleccionado. Y además tres marcos más, con otros colores para diferenciarlos, y dispuestos como el diseñador lo estime oportuno que contendrían los elementos navegacionales, respectivamente: • Enlaces a otras entidades • Enlaces a otros slices Antonio Navarrete Terrasa

Pág. 240


VIII - Conclusiones

• Herramientas navegacionales (backtracking y otros) De esta manera se obtiene una interfaz simple y significativa, útil para la navegación en muchas aplicaciones multimedia, ya sea tanto en la web, como en otro tipo de plataformas, donde en vez de tener marcos HTML, tendremos simples divisiones de la pantalla en varias áreas.

8.1.5. Casos de estudio Los ejemplos de los artículos siempre adolecen de ser muy sencillos, lo cual hace muy fácil aplicar las técnicas de modelo que los autores proponen. Nosotros decidimos aplicar RMM a tres casos de estudio, que por su gran envergadura y riqueza de estructura, nos ayudaran a detactar problemas y proponer soluciones a RMM. Éstos son los números de los tres casos de estudio: CD-ROM del Parc Natural de S’Albufera 28 Entidades 91 Atributos 31 Slices Proyecto MINTour 20 Categorías 129 Entidades 1016 Atributos de entidades 277 Slices CD-ROM del Atles de les Illes Balears 28 Entidades Elementos de información contenidos en el CD-ROM: Textos Mapas Gráficos Tablas Fotos Vídeos Imágenes panorámicas Total

960 686 283 148 288 72 23 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 una metodología y un modelo para evaluar detalladamente una aplicación ya desarrollada, a posteriori. De esta manera se han detallado una serie de carencias en la estructura de la información y la navegación. Las exponemos detalladamente a continuación:


Pág. 241


VIII - Conclusiones

Tanto animales (aves, mamíferos, peces, reptiles e invertebrados) como plantas tienen un lugar en el parque. En el sistema actual se desaprovecha la información para permitir que navegar por todos, por ejemplo, mamíferos de un lugar concreto. Y también al contrario, no podemos ir a visitar el lugar que se 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 la información de la presencia de las aves por meses, así como una breve descripción del parque en cada estación. Pero no podemos ver las aves que están en un mes concreto (interesante si queremos planificar una visita real al parque). Lo mismo ocurre con el período de floración de las plantas, que no se puede navegar por las plantas que están en flor en un mes concreto.

8.1.5.2. Proyecto MINTour A pesar de que finalmente nuestras ideas no han sido utilizadas en el proyecto europeo, el modelo final que hemos obtenido constituye un interesante modelo de navegación, más consistente e intuitivo que el existente. De hecho, el proyecto europeo dejó de lado la línea de un proyecto multimedia, para convertirse en un simple recuperador de información de la base de datos, sin ninguna navegación posible entre sus elementos. En cambio nuestra solución daría lugar a un sistema en el cual el usuario navegaría, igual que 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, ésta es la diferencia fundamental entre una aplicación multimedia-hipermedia y una de gestión: en la primera lo importante es la navegación y en la segunda la recuperación exacta de los datos que el usuario desea. Pero, pensamos que la situación es que el usuario, el turista, generalmente no sabe lo que exactamente quiere ver antes de entrar en el sistema, y lo que le interesa no es buscar la lista de hoteles de tres estrellas que tienen gimnasio o yacuzi, por poner un ejemplo, o los museos que disponen de una tienda y ofrecen visitas guiadas. El análisis de MINTour, al tratarse de un proyecto tan grande con tantas y tan variadas entidades, nos ha servido para descubrir gran parte de las mejoras a la metodología RMM 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 permite acceder a todos los elementos simultáneamente de una entidad con la que se está relacionado. • Y para terminar, hay que notar la novedad que supone dividir el problema en diferentes categorías o temas, de manera que los modelos sean legibles. Al


Pág. 242


VIII - Conclusiones

final, todo queda interconectado desde la jerarquía de menús, así como a travé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 ha sido 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 de evaluarla. En el segundo, MINTour, el objetivo ya era el de hacer la aplicación completa a 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 la metodologí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álisis navegacional. Como principal conclusión de este caso de estudio, consideramos que podemos citar que se ha demostrado que sí es posible el hacer un desarrollo completo de una aplicación siguiendo la metodología RMM, con una serie de mejoras que ya se han comentado. 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 fase quinta, Diseño de la interfaz de usuario, donde se interactúa directamente con el diseñador gráfico, que a menudo no conoce nuestra metodología. En concreto, nosotros hemos incorporado a la metodología, la lista de los elementos gráficos así como un conjunto de layouts para representar la estructura de la pantalla, que ya se han sido citados en las conclusiones acerca de la quinta etapa. Para terminar, a partir de este caso de estudio se ha la nueva primitiva de acceso aleatorio, que permite acceder a los elementos de una entidad aleatoriamente.


Pág. 243


VIII - Conclusiones

8.2. Líneas de futuro Últimamente están surgiendo nuevas metodologías, lo cual no es de extrañar vista la cierta inmadurez del tema de la ingeniería del software aplicada a la hipermedia. Entre ellas destacaremos OOHDM, [SCH96], que es una extensión de HDM con orientación a objetos y que se está convirtiendo en una de las más utilizadas. Otras interesantes referencias pueden encontrarse en [GRE96] y [GRO96]. El continuar estudiando estas nuevas metodologías y aplicarlas a nuestros tres casos de estudio, 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 de desarrollar una herramienta tipo CASE, pueden ser objeto de investigación a partir del trabajo que hemos desarrollado.


Pág. 244


IX - Bibliografía

Capítulo IX BIBLIOGRAFÍA [BAL96]

V. Balasubramanian, M. Bieber, T. Isakowitz: Systematic hypermedia design. Documento pre-imprenta, http://eies.njit.edu/~333/bala.html, CRIS Working Paper series 5/10/96 1996.

[BAR93]

M. Barceló, M. Costa, C. Quer: Anàlisi d’aplicacions informà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-based approach to hypermedia applications design. ACM Tranactions on Inforamtion Systems, vol. 11, pp. 1-23, 1993.

[GAR95]

F. Garzotto, L. Mainetti, P. Paolini: Hypermedia design, analysis, and evaluation issues. Communications of the ACM, vol. 38, pp. 74-86, 1995.

[GRE96]

T. R. G. Green, D. R. Benyon: The skull beneath the skin; Entity-relationship modelling of Information Artefacts. Int J Human-Computer Studies, 1996.

[GRO96]

K. Grønbœk, R. H. Trigg: Toward a Dexter-based model for open hypermedia: Unifying embedded references and link objects. Presentado en The Seventh ACM Conference on Hypertext, Washington DC, March 16-20, 1996, 1996.

[HAL94]

F. Halasz, M. Schwartz: The Dexter Hypertext reference model. Communications of the ACM, vol. 37, pp. 30-39, 1994.

[HAR94]

L. Hardman, D.C.A. Bulterman, G. Van Rossum: The Amsterdam Hypermedia Model. Communications of the ACM, vol. 37, pp. 50-62, 1994.

[ISA95]

T. Isakowitz, E. A. Stohr, P. Balasubramanian: RMM: A methodology for structured Hypermedia design. Communications of the ACM, vol. 38, pp. 34-44, 1995.

[ISA96]

T. Isakowitz, A. Kamis, M. Koufakis: Extending the capabilities of RMM: Russian dolls and Hypertext. Documento preimprenta, http://www.stern.nyu.edu/~tisakowi, 1996

[MAN94]

M. Manresa: Apuntes de la asignatura “Disseny Lògic”. Palma de Mallorca. 1994-1995

[MIN96]

MINTour Project. TAP AD1009, 1996-98. El proyecto final está en http://mintour.ibit.org:9000/

[NIE90]

J. Nielsen: Hypertext & Hypermedia. Academic Press Inc. San Diego. 1990


Pág. 245


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: Systematic Hypermedia Application Design with OOHDM. Presentado en The Seventh ACM Conference on Hypertext, Washington DC, March 16-20, 1996, 1996.

[SOM96]

Ian Sommerville: Software Engineering. 5ª edición. AddisonWesley. 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. Palma de Mallorca. 1998.


Pág. 246

Metodologia de hipermedia RMM

Recommend Documents