Virtual Museum sobre plataforma Java EE

Universidad de Valladolid E. T. S. DE INGENIERÍA INFORMÁTICA Ingeniero en Informática Virtual Museum sobre plataforma Java EE Alumno: Francisco José Pascual Martínez Tutores: Jesús Vegas Hernández Pablo de la Fuente Redondo Virtual Museum sobre plataforma Java EE Página 2 ÍNDICE DE CONTENIDOS PARTE I INTRODUCCIÓN Y ESTUDIO PREVIO 1 1. Marco general del proyecto 5 1.1. Justificacióninicial ................................... 5 1.2. Objetivosdelproyecto ................................. 6 1.3. Contenidodelamemoria................................ 6 2. Panorámica de Museos Virtuales en Internet 9 2.1. Situación de los museos en España . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Museos Virtuales en la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Louvre ..................................... 11 2.2.2. Instituto Valenciano de Arte Moderno . . . . . . . . . . . . . . . . . . . . . 12 2.2.3. Museo Patio Herreriano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4. Fundación Colección Thyssen-Bornemisza . . . . . . . . . . . . . . . . . . 14 2.2.5. Museo de arte metropolitano . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.6. CasadelasCiencias .............................. 15 2.2.7. Fundación del Patrimonio Histórico de Castilla y León . . . . . . . . . . . . 16 2.2.8. Museo Nacional de Escultura . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.9. Ciudad de las Artes y las Ciencias . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.10.MuseodelaCiencia .............................. 17 2.2.11. Museo de la Universidad de Valladolid . . . . . . . . . . . . . . . . . . . . 18 I Virtual Museum sobre plataforma Java EE 2.2.12.Art.Blogging.LA................................ 19 2.2.13.Cocinalia.eu .................................. 19 2.3. Requisitos de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. Web Semántica y Museos Virtuales: Dublin Core 21 3.1. Introducción....................................... 22 3.2. WorldWideWeb .................................... 22 3.3. Websemántica ..................................... 24 3.4. Conceptos básicos de la Web Semántica . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1. Indexado y Recuperación de la información . . . . . . . . . . . . . . . . . . 26 3.4.2. Metadatos.................................... 26 3.4.3. Anotaciones................................... 27 3.4.4. Una base datos interoperable . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.5. Recuperación automática de datos . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.6. Servicios .................................... 27 3.4.7. Descubrimiento................................. 28 3.4.8. Agentes inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Capas de la Web Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6. Web como Biblioteca digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7. Metadatos y Bibliotecas Digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.8. Recursos en las Bibliotecas Digitales . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.9. Esquema de Metadatos para el proyecto Virtual Museum . . . . . . . . . . . . . . . 36 3.10. Origen de la Iniciativa Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.11. Conjunto de Elementos de Metadatos . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.11.1. Descripción de los elementos . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.11.2. Elementos cualitativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.12.Principios........................................ 42 Página II ÍNDICE DE CONTENIDOS 3.13. Modelo Abstracto Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.14. Sintaxis de codificación Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.14.1.XML ...................................... 45 3.14.2.RDF....................................... 47 3.14.3.HTML/XHTML ................................ 48 3.14.4. Microformato Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 PARTE II DESARROLLO DEL SISTEMA 51 4. Plan de desarrollo del proyecto 53 4.1. Introducción....................................... 54 4.2. Perspectiva general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.1. Metodología .................................. 54 4.2.2. Referencias................................... 54 4.2.3. Elementos a entregar del proyecto . . . . . . . . . . . . . . . . . . . . . . . 55 4.3. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.1. Estructura organizativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.2. Interfacesexternas ............................... 57 4.3.3. Responsabibilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4. Gestióndelproyecto .................................. 58 4.4.1. Gestiónderiesgos ............................... 58 4.4.2. Mecanismos de supervisión y control . . . . . . . . . . . . . . . . . . . . . 59 4.4.3. Estimaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.4. Plandelpersonal................................ 60 4.5. Procesotécnico..................................... 60 4.5.1. Herramientas.................................. 60 4.5.2. Documentación del software . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Página III Virtual Museum sobre plataforma Java EE 4.6. Planificación ...................................... 61 5. Especificación de requisitos 65 5.1. Introducción....................................... 66 5.1.1. Propósito.................................... 66 5.1.2. Alcance..................................... 66 5.1.3. Referencias................................... 66 5.1.4. Perspectivageneral............................... 66 5.2. Descripcióngeneral................................... 66 5.2.1. Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.2. Funciones del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2.3. Descripción del modelo de negocio . . . . . . . . . . . . . . . . . . . . . . 69 5.2.4. Características del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2.5. Restricciones.................................. 70 5.3. Requisitos específicos de la aplicación del administrador . . . . . . . . . . . . . . . 70 5.3.1. Funcionalidad de la aplicación del administrador . . . . . . . . . . . . . . . 70 5.3.2. Requisitos adicionales de la aplicación del administrador . . . . . . . . . . . 71 5.4. Requisitos específicos de la aplicación del director de museo . . . . . . . . . . . . . 71 5.4.1. Funcionalidad de la aplicación del director de museo . . . . . . . . . . . . . 71 5.4.2. Requisitos adicionales de la aplicación del responsable del museo . . . . . . 72 5.5. Requisitos específicos de la aplicación del visitante . . . . . . . . . . . . . . . . . . 72 5.5.1. Funcionalidad de la aplicación del visitante . . . . . . . . . . . . . . . . . . 72 6. Descripción de Casos de Uso 75 6.1. Introducción....................................... 75 6.2. Casos de Uso para el Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3. Casos de Uso para el Director de museo . . . . . . . . . . . . . . . . . . . . . . . . 80 6.4. Casos de Uso para el Visitante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Página IV ÍNDICE DE CONTENIDOS 7. Análisis 91 7.1. Introducción....................................... 91 7.2. Diagrama de Clases de Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.2.1. Administrador ................................. 92 7.2.2. Director..................................... 93 7.3. Realización de casos de uso-análisis . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8. Descripción de la Arquitectura 95 8.1. Introducción....................................... 96 8.2. ArquitecturaJavaEE .................................. 96 8.3. Patrón MVC (Modelo-Vista-Controlador) . . . . . . . . . . . . . . . . . . . . . . . 101 8.4. Arquitectura empleada en Virtual Museum . . . . . . . . . . . . . . . . . . . . . . . 102 8.5. CapadeCliente.....................................103 8.6. Capa de Vista de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.1. HTML, CSS y Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.2. Internacionalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.6.3. StrutsTiles ...................................105 8.6.4. Velocity.....................................105 8.7. Capa de Lógica de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 8.7.1. FrameworkStruts................................106 8.7.2. Framework Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 8.8. Capa de Lógica de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.8.1. FrameworkSpring ...............................109 8.9. CapadeServicios....................................114 8.10.Capadeintegración...................................115 8.10.1.Hibernate....................................115 8.11. Capa de sistemas de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Página V Virtual Museum sobre plataforma Java EE 8.12. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9. Diseño 119 9.1. Introducción.......................................120 9.2. Diagrama de Clases de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.2.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.2.2. Modelo.....................................122 9.2.3. Accesoadatos .................................125 9.2.4. Negocio.....................................127 9.2.5. ServiciosWeb .................................129 9.2.6. AccionesVisitante ...............................130 9.2.7. AccionesDirector ...............................131 9.2.8. Acciones Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 9.2.9. VistaMóvil...................................133 9.2.10.TaglibBandera.................................134 9.3. Realización de casos de uso-diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.4. Descripción de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.5. Diagrama Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.5.1. Elementos Dublin core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.5.2. Diccionario de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.5.3. Modelorelacional ...............................138 9.6. Diseño de Temas/Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.6.1. Descriptor XML de la Plantilla . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.7. Macrosdeplantilla ...................................140 10.Implementación 141 10.1.Introducción.......................................142 10.2. Componentes y Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Página VI ÍNDICE DE CONTENIDOS 10.2.1. Búsqueda de multimedia en textos . . . . . . . . . . . . . . . . . . . . . . . 142 10.2.2. Marshalling XML: Castor . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 10.2.3. Generación de la vista móvil: StringTemplate . . . . . . . . . . . . . . . . . 144 10.2.4.Flickr......................................145 10.2.5.Picasa......................................146 10.3. Configuración del núcleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.3.1. Integración Struts/Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.4.Velocity.........................................147 10.5. Construcción y Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.5.1.ApacheyTomcat................................148 10.5.2. Documentación del código . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 10.5.3.SistemadeTrazas................................148 10.5.4.Compilación ..................................148 10.5.5.Métricas.....................................150 10.6.Pruebas .........................................150 11.Conclusiones 151 11.1.Introducción.......................................151 11.2.Diseño..........................................151 11.3.Servicios ........................................152 11.4.DublinCore.......................................152 11.5.Arquitectura.......................................152 11.6.Vistamóvil .......................................153 12.Líneas futuras de Trabajo 155 12.1.Introducción.......................................155 12.2. Bibliotecas digitales y Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 12.3.VirtualMuseum.....................................156 Página VII Virtual Museum sobre plataforma Java EE A.25.Responsable del museo - Configuración de los elementos del menú . . . . . . . . . . 181 A.26.Responsable del museo - Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 A.27.Responsable del museo - Localizacion física para Google Maps . . . . . . . . . . . . 182 A.28.Responsable del museo - Mapa interactivo . . . . . . . . . . . . . . . . . . . . . . . 183 A.29.Responsable del museo - Mapa como imagen . . . . . . . . . . . . . . . . . . . . . 183 A.30.Responsable del museo - Publicidad . . . . . . . . . . . . . . . . . . . . . . . . . . 184 A.31.Responsable del museo - Configuración RSS . . . . . . . . . . . . . . . . . . . . . 184 A.32.Responsable del museo - Enviar mensaje al administrador . . . . . . . . . . . . . . 185 B.1. Paso 1: Bienvenida a la instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 B.2. Paso 2: Búsqueda de la máquina virtual Java . . . . . . . . . . . . . . . . . . . . . . 189 B.3. Paso 3: Búsqueda del contenedor web Tomcat . . . . . . . . . . . . . . . . . . . . . 189 B.4. Paso 4: Configuración de la conexión MySQL para la creación e inicialización de tablas189 B.5. Paso 5: Confirmación de la ejecución correcta de los scripts SQL . . . . . . . . . . . 190 B.6. Paso 6: Configuración de la conexión MySQL para la aplicación Virtual Museum . . 190 B.7. Paso 7: Reinicio de la aplicación Virtual Museum, para cargar la configuración MySQL190 B.8. Paso 8: Finalización de la instalación . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Página XIV Lista de Tablas 2.1. Estadísticas Museos y Colecciones Museográficas . . . . . . . . . . . . . . . . . . . 10 2.2. Estadísticas de Museos y Colecciones Museográficas por Comunidad Autónoma . . 11 2.3. Estadísticas de Museos y Colecciones Museográficas por Tipología . . . . . . . . . . 12 4.1. Tareas de la fase de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2. Tareas de la fase de elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.3. Tareas de la fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4. Tareas de la fase de transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.1. CU.A01 - Gestionar Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.2. CU.A02 - Gestionar Museos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.3. CU.A03 - Enviar Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.4. CU.A04 - Ver Estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.5. CU.A05 - Gestionar Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.6. CU.A06 - Importar plantilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.7. CU.A07 - Gestionar Idiomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.8. CU.A08 - Cambiar Mi Clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.9. CU.A09-CambiarIdioma ............................... 79 6.10. CU.D01 - Actualizar información Museo . . . . . . . . . . . . . . . . . . . . . . . 81 6.11. CU.D02 - Publicar Museo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.12. CU.D03 - Generar Vista Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 XV Virtual Museum sobre plataforma Java EE 6.13. CU.D04 - Configurar Idiomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.14. CU.D05 - Dejar Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.15. CU.D06 - Seleccionar Idioma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.16. CU.D07 - Gestionar Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.17.CU.D08-Subirarchivo................................. 83 6.18. CU.D09 - Fijar página inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.19. CU.D10 - Configurar Menús . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.20.CU.D11-AñadirMenú................................. 83 6.21.CU.D12-AñadirItem ................................. 84 6.22. CU.D13 - Seleccionar Plantilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.23. CU.D14 - Configurar Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.24.CU.D15-ConfigurarRSS ............................... 84 6.25. CU.D16 - Gestionar Contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.26. CU.D17 - Publicar Picasa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.27. CU.D18 - Publicar Flickr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.28. CU.D19 - Visualizar GoogleMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.29. CU.V01 - Descargar Vista Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.30.CU.V02-VistaXML.................................. 88 6.31.CU.V03-VistaRSS .................................. 88 6.32. CU.V04 - Ver metas Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.33. CU.V05 - Usar servicios web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.34.CU.V06-VerContenido ................................ 89 6.35.CU.V07-VerCategoría ................................ 89 Página XVI PARTE I INTRODUCCIÓN Y ESTUDIO PREVIO 1 PREFACIO El trabajo que comienza aquí tiene su eje central en el concepto de Museo Virtual. Al parecer, los museos virtuales existen gracias a dos ideas provocadoras lanzadas en el siglo pasado por dos franceses. Por una parte, la idea de Marcel Duchamp respecto a la creación de un museo transportable (boîte-en-valise 1 - un maletín con reproducciones de sus obras en miniatura). Y por otra, la idea de un museo imaginario de André Malraux. Museo transportable (movilidad, acceso remoto) y museo imaginario (inmaterialidad, virtualidad física) presentan hoy una clara relación con el actual término de Museo Virtual. Tradicionalmente el concepto de museo ha denotado un espacio arquitectónico con unas fronteras físicas bien definidas en cuyo interior se accede a sus colecciones, pero en la actualidad un museo expande su presencia y trasciende las barreras físicas gracias al desarrollo de las tecnologías de la información, crecimiento de Internet y el deseo de concebir nuevos espacios para la difusión, creación de arte, y comunicación bidireccional con el público en general y otros sistemas. Gracias a esta expansión, podemos encontrar museos virtuales no sólo de entidades emblemáticas o que gozan de gran reconocimiento, sino de personas desconocidas que montan su galería con reproducciones de sus obras, hasta museos en el ciberespacio que exhiben obras digitales que no tienen correspondencia con una obra física. Figura 1: Boîte-en-valise de Marcel Duchamp 3 Virtual Museum sobre plataforma Java EE Página 4 Capítulo 1 MARCO GENERAL DEL PROYECTO Gracias al telégrafo, todos los habitantes de la Tierra podrán convivir en un solo vecindario intelectual. General Alonzo Jackman Índice del Capítulo 1.1. Justificacióninicial................................. 5 1.2. Objetivosdelproyecto ............................... 6 1.3. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Justificación inicial Uno de los fenómenos más interesantes de los últimos años en el mundo del arte ha sido la extensión de la red de museos de arte en el mundo y sobre todo en el Norte de Europa, España y América del Norte, también en Asia. El creciente deseo de acceder a la cultura (y en concreto al conocimiento del arte) por parte del público medio de la sociedad actual es una realidad palpable que ha provocado la creación y apertura de decenas de nuevos museos en los últimos años. Las nuevas tecnologías de la información ofrecen a los museos una oportunidad hasta ahora desconocida para responder a los requerimientos de la sociedad. Desde el momento en que fue posible almacenar, procesar y recuperar texto, sonido e imágenes fijas y en movimiento, situarlas en redes y enviarlas a cualquier punto del globo a cualquier hora del día, el acceso a los museos empezó a tomar una dimensión diferente. Además de la utilización tradicional, el arte en Internet ofrece nuevas posibilidades como la interactividad y la desaparición de las barreras físicas. Dado el auge de los museos virtuales, parece interesante el planteamiento de un sistema informático que asista en la creación y difusión de museos virtuales, basándose en diversos criterios como el uso, contenido, diseño de interfaz, interoperabilidad con otros sistemas, etc. 5 Virtual Museum sobre plataforma Java EE 1.2. Objetivos del proyecto El presente proyecto tiene su motivación original en la evolución de otro proyecto fin de carrera previo ([Pér03]). En él, el objetivo principal era desarrollar un sistema de configuración de museos virtuales de arte, que pudiesen ser visualizados tanto en un navegador web como a través de un dispositivo móvil (PDA, teléfono, etc). Siguiendo esta línea original, el proyecto que nos ocupa va a establecer sus objetivos como una evolución de las premisas iniciales del proyecto anterior e incorporación de otras nuevas relacionadas principalmente con los nuevos enfoques, técnicas y conceptos de la Web. A partir de las funcionalidades que ofrecía el proyecto anterior, el presente pretende añadir ciertas características que se perfilan a continuación: Dar soporte para agregar metadatos a los recursos que presenta cada museo virtual. Como se verá, el estándar de metadatos a seguir es Dublin Core. El sistema resultante debe producir tres subsistemas diferenciados para cada uno de los tres roles generales del sistema: administrador del sistema global, responsable del museo y visitante de los museos virtuales generados por el responsable . Brindar un sistema de publicación de contenidos en general flexible para que el responsable pueda componer un sitio completo, en la línea de los habituales gestores de contenidos o CMS (Content Management Systems). Permitir la personalización de la apariencia de los sitios web generados para cada museo virtual, mediante la elección de temas o plantillas que produzcan una composición diferente en cuanto a contenidos y forma a gusto de cada usuario. Producir un sistema muy escalable en cuanto a tecnologías de desarrollo, de forma que a partir de la arquitectura seleccionada cada capa sea independiente del resto, de cara a futuras modificaciones y/o ampliaciones. Esta escalabilidad debería permitir un amplio abanico de cambios entre los que podemos contar: base de datos, contenedor web de la aplicación, gestor de persistencia, lógica de negocio, internacionalización de mensajes, composición y forma visual de las aplicaciones, formato de los museos virtuales generados, etc. Orientar los sistemas resultantes a las ideas propuestas por la Web 2.0. En este sentido, se ofrecerán distinas vías de acceso a la información de los recursos para el público en general u otros sistemas entre los que podemos encontrar, además del propio sitio web: Google Maps, Flickr, Picasa, RSS, vista para móviles, RDF o acceso por servicios web. 1.3. Contenido de la memoria La memoria del proyecto fin de carrera que viene a continuación se ha dividido en las siguientes partes: Página 6 Capítulo 1. Marco general del proyecto Introducción y estudio previo: se hace una introducción a los museos virtuales a través de su situación actual en Internet (capítulo 2), y a continuación (capítulo 3) se describe el estándar de metadatos seguido en Virtual Museum, partiendo de la Web y Web Semántica, hasta llegar al estándar Dublin Core, pasando por conceptos importantes como museo virtual, biblioteca digital, metadatos, etc. Desarrollo del sistema: una vez visto dónde se enmarca el proyecto y los fundamentos subyacentes, se pasa a describir el proceso software seguido a través de sus flujos de trabajo fundamentales. De ahí que en una serie de capítulos sucesivos (a partir del capítulo 4) se reúnan los artefactos resultantes de las etapas de requisitos, análisis, diseño, implementación y pruebas. Conclusiones y trabajo futuro: en los dos últimos capítulos, con el sistema construido se comentan diversas reflexiones del producto desarrollado y se evaluan ciertos aspectos del mismo. Además, se ofrece al lector posibles líneas de trabajo futuro que podrían ser interesantes como continuación y ampliación del presente proyecto. Apéndices: la última parte de la memoria reúne la información de referencia que pueden servir de consulta adicional respecto de los capítulos anteriores. Hay que hacer notar que también se incluye documentación de apoyo en el CD anexo que por sus características no se han incorporado a la memoria impresa. Una vez demarcado el ámbito general del proyecto a partir del siguiente capítulo se irán describiendo las ideas principales que han llevado al proyecto desde su planteamiento hasta la puesta en marcha del sistema. Página 7 Virtual Museum sobre plataforma Java EE 2.2.4. Fundación Colección Thyssen-Bornemisza www.museothyssen.org (Madrid) Figura 2.4: Fundación Colección Thyssen-Bornemisza Organización de contenidos: colección, exposiciones, actividades, información, quiénes somos, colaboradores, tienda. Disponibilidad de canales RSS para ciertos contenidos. Selección de idioma (castellano e inglés) Utilización de recursos multimedia en ocasiones puntuales aunque de diversa índole: audios mp3, presentaciones flash, applets java, etc. Existencia de una sección de obras maestras que permite al usuario visualizar las obras más importantes del museo de una forma rápida y sencilla. 2.2.5. Museo de arte metropolitano www.metmuseum.org (Nueva York) Organización de contenidos: obras, tienda, miembros, donaciones, planear visita, calendario, claustros, auditorios y ponencias, recursos educativos, eventos, personalización por usuario (My Met Museum), sala de presa y podcast. Organización destinada a un amplio conjunto de visitantes con diversos fines. Información textual y gráfica muy rica y extensa. Página 14 Capítulo 2. Panorámica de Museos Virtuales en Internet Figura 2.5: Museo de arte metropolitano de Nueva York Aunque la apariencia de todo el sitio es uniforme, ciertas zonas o contenidos presentan un estilo particular. 2.2.6. Casa de las Ciencias casadelasciencias.logro-o.org (Logroño) Figura 2.6: Casa de las Ciencias de Logroño Organización de contenidos: historia, programación, galería de fotos, espacios, normativa, foros de debate, suscripción, información general, centros docentes y publicaciones. Presentación clara y sencilla de rápido acceso a sus contenidos. Poca profundidad del árbol del mapa web del sitio. Página 15 Virtual Museum sobre plataforma Java EE 2.2.7. Fundación del Patrimonio Histórico de Castilla y León www.fundacionpatrimoniocyl.es (Castilla y León) Figura 2.7: Fundación del Patrimonio Histórico de Castilla y León Organización de contenidos: presentación, información general, restauración, arqueología e historia, rutas de turismo cultural, formación y cursos, publicaciones, difusión cultural, prensa, galería de imágenes, enlaces y concursos. Estilo uniforme a lo largo de todo el sitio, aunque el contenido de la portada se enfoca en presentar sus últimas novedades. Selección de idioma (castellano, inglés y francés). 2.2.8. Museo Nacional de Escultura museoescultura.mcu.es (Valladolid) Organización de contenidos: información general, colección, edificios, atención al público, actividades, publicaciones, servicios, enlaces y mapa. Selección de idioma (castellano, inglés y francés). Estilo uniforme a lo largo de todo el sitio. 2.2.9. Ciudad de las Artes y las Ciencias www.cac.es (Valencia) Página 16 Capítulo 2. Panorámica de Museos Virtuales en Internet Figura 2.8: Museo Nacional de Escultura Figura 2.9: Ciudad de las Artes y las Ciencias de Valencia Organización de contenidos: prensa, cómo llegar, horarios, tarifas, enlaces, programación, actividades, servicios, visita, galería de imágenes y microsites. Selección de idioma (castellano, inglés y valenciano). Abundante información distribuida por los distintos públicos, espacios propios y actividades. 2.2.10. Museo de la Ciencia www.museocienciavalladolid.es (Valladolid) Organización de contenidos: museo, información y servicios, exposición permanente, la casa del río, exposiciones temporales, educación, planetario, otras actividades y noticias. Página 17 Virtual Museum sobre plataforma Java EE Figura 2.10: Museo de la Ciencia de Valladolid Galerías de imágenes directas que presentan el conjuntos de miniaturas (thumbnails) pudiendo ampliarla en una ventana popup. Las colecciones o exposiciones se presentan frecuentemente con un enlace dentro del sitio que redirecciona a otro fuera del museo. 2.2.11. Museo de la Universidad de Valladolid www3.uva.es/muva (Valladolid) Figura 2.11: MUva Organización de contenidos: Información general, exposición, actividades, museo, publicaciones, podcast. Página 18 Capítulo 2. Panorámica de Museos Virtuales en Internet Presentación diáfana y directa de contenidos. Cuenta con la posibilidad de descarga de recursos multimedia bien directamente o bien por suscripción RSS. 2.2.12. Art.Blogging.LA art.blogging.la (Los Angeles) Figura 2.12: Art.Blogging.LA Organización de contenidos: Enlaces, fotos, editorial, eventos, exhibiciones, imágenes, entrevistas, noticias, avances (preestrenos), críticas. Está basado en WordPress por lo que su apariencia, colocación de contenidos e interfaz es la propia de un blog: se basa en contenidos como si fueran posts y se pueden presentar agrupados por categorías o por fecha de publicación. 2.2.13. Cocinalia.eu cocinalia.eu (—–) Organización de contenidos: categorías, comer en, enlaces, archivos, meta Como el caso anterior, está basado en WordPress por lo que comparte la orientación de contenidos a posts. No está asociado a una empresa pública ni privada (al menos no aparentemente). Permite añadir comentarios a los contenidos con lo que favorece la comunicación con el visitante, haciendo que éste sea parte activa del mismo. Página 19 Virtual Museum sobre plataforma Java EE Figura 2.13: Cocinalia 2.3. Requisitos de interacción Teniendo en cuenta estos museos, en el presente proyecto se van a tener en cuenta los siguienes aspectos de diseño y de experiencia visual para los museos virtuales que va a ser capaz de generar el sistema: Organización de contenidos: Información del museo, información general, localización física (ubicación), obras, autores, recorridos, novedades y eventos. Como hemos visto, esta clasificación puede resultar insuficiente para algunos casos, por lo que sería deseable contar un contenido genérico que no pertenezca a ninguna de las categorías planteadas. Podría tenerse en cuenta una configuración libre de categorías por parte del responsable del museo pero uno de los objetivos primordiales será buscar un manejo fácil e intuitivo de la aplicación diseñada para él. Esta organización de contenidos presentada aunque podría llevar a que fuese un reflejo del menú principal del sitio, se observa que el menú principal de cada sitio es lo suficientemente particular y centrado en los propios intereses del museo, que no se puede plantear un menú único y general para los museos virtuales generados. Inclusión de múltiples tipos de contenidos multimedia. Personalización de la apariencia del sitio publicado; cada museo presenta un diseño diferente ya que forma parte de su propia identidad. La selección de idioma no es un servicio disponible generalizado en los museos. Y teniendo en cuenta sólo aquéllos que sí lo ofrecen, el conjunto de idiomas varía de un museo a otro. Página 20 Capítulo 3 WEB SEMÁNTICA Y MUSEOS VIRTUALES: DUBLIN CORE Invertir en conocimientos produce siempre los mejores beneficios. Benjamin Franklin Índice del Capítulo 3.1. Introducción .................................... 22 3.2. WorldWideWeb.................................. 22 3.3. Websemántica................................... 24 3.4. Conceptos básicos de la Web Semántica . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1. Indexado y Recuperación de la información . . . . . . . . . . . . . . . 26 3.4.2. Metadatos................................. 26 3.4.3. Anotaciones................................ 27 3.4.4. Una base datos interoperable . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.5. Recuperación automática de datos . . . . . . . . . . . . . . . . . . . . 27 3.4.6. Servicios ................................. 27 3.4.7. Descubrimiento.............................. 28 3.4.8. Agentes inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Capas de la Web Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6. Web como Biblioteca digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7. Metadatos y Bibliotecas Digitales . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.8. Recursos en las Bibliotecas Digitales . . . . . . . . . . . . . . . . . . . . . . . . 36 3.9. Esquema de Metadatos para el proyecto Virtual Museum . . . . . . . . . . . . . 36 3.10. Origen de la Iniciativa Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 37 3.11. Conjunto de Elementos de Metadatos . . . . . . . . . . . . . . . . . . . . . . . 39 21 Virtual Museum sobre plataforma Java EE 3.11.1. Descripción de los elementos . . . . . . . . . . . . . . . . . . . . . . . 40 3.11.2. Elementos cualitativos . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.12.Principios...................................... 42 3.13. Modelo Abstracto Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.14. Sintaxis de codificación Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 44 3.14.1. XML ................................... 45 3.14.2. RDF.................................... 47 3.14.3. HTML/XHTML.............................. 48 3.14.4. Microformato Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1. Introducción Una cuestión importante a la hora de desarrollar un sistema gestor de museos virtuales es que tiene que englobar dos conjuntos de servicios principales. Por una parte como biblioteca digital debe permitir conservar, catalogar, acceder y gestionar el material digitalizado; y por otra parte como museo virtual propiamente dicho debe ofrecer a los usuarios exposiciones de dicho material, y otros contenidos interesantes para el visitante por lo que de cara al responsable del museo virtual se debe ofrecer un sistema de gestión de contenidos en la línea de los habituales gestores de contenidos (CMS -Content Management Systems) para la creación de sitios web genéricos. En este capítulo nos centraremos en la idea de biblioteca digital partiendo de conceptos generales como web semántica, metadatos, ontologías, agregación de contenidos, interoperabilidad, etc., llegando a una iniciativa en particular ampliamente usada denominada Dublin Core. 3.2. World Wide Web Aunque la existencia de la Web puede parecer datar de los principios de la historia de los computadores1comenzó como un concepto de Tim Berners-Lee ayudado por Robert Cailliau, mientras trabajaban para el CERN (Centre Européene pour la Recherche Nucléaire), en Ginebra (Suiza). A Berners-Lee se le ocurrió que podía adaptar un programa que había creado para su uso particular, el ENQUIRE, a las necesidades del CERN de disponer de un sistema para acceder a la enorme y diversa cantidad de información que había en sus sistemas informáticos. Se trataba de un sistema de hipertexto para compartir información basado en Internet. Dicho sistema permitía incoporar multimedia e hipertextos en Internet, almacenando piezas de información y enlazándolas entre ellas. Enquire se ejecutaba en un entorno multiusuario y permitía acceder a varias personas a los mismos datos. En 1989 Berners-Lee entregó su propuesta a varios científicos del CERN pero no obtuvo respuesta. Fue Robert Cailliau quien acudió en su ayuda. Reescribió la propuesta de Berners-Lee en términos que a él le pareció que tendrían más efecto y buscó ayudantes estudiantes y becarios, dinero, máquinas 1La idea subyacente de la Web se remonta a la propuesta de Vannevar Bush en los años 40 sobre un sistema similar y posteriormente a Ted Nelson en los años 50 que realiza la primera referencia a un sistema de hipertexto, pero no es hasta 1980, donde cobrará un soporte operativo tecnológico real para la distribución de información en redes. Página 22 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core y espacio en oficinas para poder trabajar. Así, en septiembre de 1990 recibieron el visto bueno y los dos comenzaron a escribir el nuevo sistema de hipertexto, dando origen a la Web como hoy la conocemos. El concepto, subyacente y crucial, del hipertexto tiene sus orígenes en viejos proyectos de la década de los 60, como el Proyecto Xanadu de Ted Nelson y el sistema on-line NLS de Douglas Engelbart. Los dos, Nelson y Engelbart, estaban a su vez inspirados por el proyecto nunca materializado MEMEX, de Vannevar Bush. El gran avance de Berners-Lee fue unir hipertexto e Internet. En su libro Weaving the Web, explica que él había sugerido repetidamente que la unión entre las dos tecnologías era posible para miembros de las dos comunidades tecnológicas, pero como nadie aceptó su invitación, decidió, finalmente, hacer frente al proyecto él mismo. En el proceso, desarrolló un sistema de identificadores únicos globales para los recursos web: el Uniform Resource Identifier (URI). World Wide Web tenía algunas diferencias de los otros sistemas de hipertexto que estaban disponibles en aquel momento: WWW sólo requería enlaces unidireccionales en vez de los bidireccionales. Esto hacía posible que una persona enlazara a otro recurso sin necesidad de ninguna acción del propietario de ese recurso. Con ello se reducía significativamente la dificultad de implementar servidores web y navegadores (en comparación con los sistemas anteriores), pero en cambio presentaba el problema crónico de los enlaces rotos. A diferencia de sus predecesores, como HyperCard, World Wide Web era no-propietario, haciendo posible desarrollar servidores y clientes independientemente y añadir extensiones sin restricciones de licencia. Su diseño tenía una base técnica relativamente sencilla, lo que ayudó a que esta tecnología ganará en popularidad por las masas. Berners-Lee quería que cualquiera pudiera colocar información en un ordenador y hacer esta información accesible a cualquier otra persona, en cualquier parte. Esperaba que eventualmente, las máquinas pudieran ser capaces de usar esta información en la Web. Y en último término, pensaba que esto permitiría una colaboración potente y efectiva humano-máquinahumano: ”Siempre he imaginado el espacio de la información como algo a lo que cualquiera tiene un acceso inmediato e intuitivo, y no sólo navengando sino creando... Las maquinas llegarán a ser capaces de analizar toda la información en la Web (el contenido, enlaces y las transacciones entre las personas y máquinas. ... cuando [la Web Semántica] emerja, los mecanismos del día a día del trato, burocracia y nuestras vidas diarias serán asistidas por máquinas que hablen con otras máquinas, dejando a las personas que provean la inspiración y la intuición” (Tim Berners-Lee, 2000) De forma gradual, otros hackers se sumaron a su esfuerzo proporcionando realimentación, estímulo, aportaciones de código fuente y apoyo moral. A medida que el grupo fue ampliándose, Berners-Lee organizó una comunidad similar a la Internet Society de Vinton Cerf, el World Wide Web Consortium, en un esfuerzo por impedir y prevenir la absorción comercial de la red mundial de Página 23 Virtual Museum sobre plataforma Java EE Básicamente, se han utilizado y mezclado tres conceptos que, pese a tener connotaciones diferentes, muchas veces han pretendido definir lo mismo: biblioteca electrónica, biblioteca digital y biblioteca virtual. Varias son las definiciones que se han aplicado a las bibliotecas digitales. Algunas defienden que las bibliotecas digitales son meramente bibliotecas electrónicas. La biblioteca electrónica sería aquella que permite acceder a bancos de información en formato electrónico. Este tipo de bibliotecas incluiría también los catálogos automatizados de bibliotecas tradicionales. Según esta definición. la biblioteca electrónica intentaría reproducir la producción impresa pero utilizando un medio diferente del soporte papel. Partiendo de esta realidad la biblioteca digital seguiría los pasos de la biblioteca electrónica, pero evolucionando hacia la introducción de otros tipos de materiales, es decir, introduciendo elementos digitales. Otras definiciones proponen un enfoque más tecnológico, e incluyen servicios que se ofrecen aprovechando los sistemas de distribución de las redes, los cuales permiten acceder a dichos servicios desde cualquier lugar, a cualquier hora, cualquiera persona e incluso, en algunos casos, sin gastos. En la web del Digital Library Project, hay una definición de biblioteca digital, que proviene del Santa Fe Workshop on Distributed Knowledge Work Environments [DA97] y que en opinión de esta misma web es una de las mejores definiciones. Dice así: "El concepto de biblioteca digital no es únicamente el equivalente de repertorios digitalizados con métodos de gestión de la información. Es más bien, un entorno donde se reúnen colecciones, servicios, y personal que favorece el ciclo completo de la creación, difusión, uso y preservación de los datos, para la información y el conocimiento". La mayoría de los expertos en biblioteconomía y documentación definen las bibliotecas digitales como repertorios de objetos digitales, más o menos organizados, que sirven a una comunidad de usuarios definida, los cuales tienen los derechos de autor presentes y gestionados, y disponen de mecanismos de preservación y conservación. Esta definición tiene en cuenta que estos repertorios constan de datos (el contenido) y metadatos (la información que describe los datos) e incorporan técnicas de búsqueda y recuperación de la información. Hay otras definiciones que hacen hincapié tanto en la interacción de los ordenadores y las personas como en las interfaces que permiten acceder a la información mediante ciertos mecanismos: búsqueda, navegación, enlaces hipertextuales, etc. Asimismo, estas definiciones enfatizan que en estas bibliotecas se tratan los datos teniendo en cuenta el ciclo de la gestión del conocimiento: organización, comunicación/difusión, almacenaje, búsqueda, filtrado/selección, y reutilización. Por lo general, las bibliotecas digitales son implementadas por instituciones culturales cuyo objetivo es hacer accesibles sus fondos a los usuarios. El concepto de biblioteca digital lleva implícito un proceso de innovación tecnológica que modifica la producción, la organización y la difusión de la información. Las bibliotecas digitales incluyen una enorme gama de tipologías. No ofrecen únicamente producción impresa, sino que incluyen imágenes, vídeos, sonido, reproducción de elementos en 3D, datos, mapas, etc. Los campos que cubren son multidisciplinares y van desde la literatura y el arte hasta la música, la medicina, etc.. La biblioteca digital no intenta ”copiar” la realidad impresa , sino que genera una nueva estructura de la información que hace que ésta evolucione desde el concepto lineal del libro y los documentos Página 30 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core tradicionales al concepto hipertextual, donde la información llega al usuario de formas muy variadas y provista de todo tipo de vínculos, los cuales permiten ampliar, concretar o explicar los contenidos de forma simultánea y diferente. El hipertexto incluye mucha más información no textual que el impreso, ya que incorpora elementos multidimensionales: voz, sonido, imagen, 3D, etc.. Con todas estas definiciones podríamos hacer el siguiente esquema: Biblioteca clásica: contenidos en soportes físicos, acceso mediante referencias bibliográficas consignadas en los catálogos. Biblioteca electrónica: contenidos en soporte electrónico, acceso por medios físicos (CDROM), o electrónicos (acceso en línea). Biblioteca digital: contenidos en soportes electrónicos y digitales, y acceso en línea a través de redes telemáticas. Biblioteca virtual: contenidos en soporte electrónico y digital, y acceso en línea a través de redes telemáticas (como en las bibliotecas digitales). Sin embargo, no todo es fácil ni simple a la hora de pensar en la biblioteca digital, existen una serie de problemáticas que ponen freno su rápida expansión, mencionaremos algunas de ellas: Disponibilidad: todo lo que existe registrado (impreso, fotografiado, filmado, pintado, dibujado, etc.) tendría que convertirse a formato digital para que éste disponible a todos los usuarios con un terminal de trabajo. Recuperación y adecuación: cada usuario de este hipotético terminal de trabajo (que permitiría el acceso a la biblioteca digital) tendría que poder acceder a todos los documentos electrónicos relevantes de este universo digital, de una manera rápida y fácil. Autenticidad: cada usuario debería tener la seguridad de que el documento que encuentra en la red es el documento auténtico y original. Utilización: cada uno de los documentos recuperados mediante el terminal de trabajo tendría que ser recuperado de forma que todo usuario pudiera utilizarlo. Protección de la propiedad intelectual: la protección de los derechos de autor debería estar garantizada en todo documento recuperado. La propiedad intelectual de un recurso es un tema candente actualmente en sí mismo y que incluyen líneas de discusión desde las licencias o condiciones bajo las cuales se permite el uso, copia, distribución, etc. hasta el sujeto mismo al que afecta la propiedad intelectual (la obra en sí, el objeto digitializado, cada una de las instancias digitales del recurso, etc). Asequibilidad: los costes de acceso y recuperación de los diversos documentos tendrían que ser razonables y no superar los costes de sus equivalentes tradicionales. La ARL (Association of Research Libraries) señala unos elementos comunes a los diversos términos con los que se designan las bibliotecas digitales (bibliotecas electrónicas, bibliotecas virtuales, etc.). Algunos de estos elementos son: Página 31 Virtual Museum sobre plataforma Java EE La biblioteca digital no debe ser una entidad individual. La biblioteca digital requiere que haya medios tecnológicos para enlazar recursos. Los enlaces entre un gran número de bibliotecas digitales y los servicios de información deben ser transparentes para los usuarios. El acceso universal a las bibliotecas digitales y a los servicios de información debe ser un objetivo principal. Las bibliotecas digitales no deben limitarse a suplir documentos, sino que deben ofrecer otros elementos digitales que no pueden suministrarse en formato impreso. Una de las características de las bibliotecas digitales es que la información que contienen ha sido creada por gente diversa, utilizando medios diversos, dándole formas y formatos diferentes, almacenada en diferentes lugares del mundo (servidores) y de manera creciente e interconectada por medio de redes. Es decir, en estas bibliotecas conviven materiales en diferentes formatos, en distintas versiones, ubicados en diferentes lugares, y accesibles a un gran número y diversidad de personas. Los proyectos de bibliotecas digitales y la investigación en estos temas deben permitir el cambio continuo, debido al aumento del ancho de banda de las redes de comunicaciones, las cuales permiten gestionar y dar coherencia, utilizar y posibilitan el acceso a gran cantidad de datos distribuidos y transformados en información y conocimiento. La existencia de las bibliotecas digitales hace cada vez más necesario que haya sistemas de recuperación de la información que sean capaces de procesar el lenguaje natural. Estos sistemas recuperan y seleccionan frases lingüísticas como unidades de información y además recuperan y seleccionan términos controlados que forman parte de tesauro, o términos incluidos en una estructura de árbol del conocimiento. Estos sistemas de recuperación tienen que ser: Flexibles: capaces de procesar diferentes tipos de información Precisos: capaces de seleccionar información pertinente y desestimar el ruido". Rápidos: tiene que poder tratar simultáneamente cantidades ingentes de información y documentación Automáticos: capaces de seleccionar la información sin que tenga que estructurarse antes Fáciles: su utilización no tiene que suponer un problema para el usuario Paralelamente al gran desarrollo de las bibliotecas digitales ha surgido la necesidad de procesar los contenidos de estos repertorios para facilitar la búsqueda y la recuperación de la información de una forma eficaz. La biblioteca digital tiene que cumplir una serie de características que le den el valor que necesita para difundir estos contenidos. Tienen que ser recuperables mediante metadatos que proporcionen valor añadido a la mera acumulación de información. Los metadatos tienen una gran importancia en la composición de las bibliotecas digitales, ya que permiten una búsqueda efectiva y precisa. Página 32 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core 3.7. Metadatos y Bibliotecas Digitales De la misma forma que en general la asignación de metadatos a los contenidos de la Web es fundamental para un mejor aprovechamiento de la misma, particularmente, las bibliotecas digitales componen un vasto campo en el que la aplicación de estándares de metadatos es clave para la gestión y recuperación de sus recursos. Entre los beneficios potenciales de las bibliotecas digitales, encontramos que la biblioteca digital trae la biblioteca al usuario, se aprovecha la potencia del computador para la búsqueda, la información puede compartirse, es más fácil mantener la información actualizada, no atiende a horarios y siempre está disponible, permite nuevas formas de distribución y suele tener un coste menor que el equivalente de una biblioteca tradicional. Casi cualquier biblioteca tiene un catálogo con registros de los materiales que componen sus colecciones. El catálogo ayuda a los usuarios a encontrar materiales en la biblioteca, provee información bibliográfica, y además es una herramienta considerable a la hora de mantener y gestionar las colecciones. El catalogado es un área en el que las bibliotecas usan una terminología precisa, algunas de las cuales pueden resultar desconocidas para personas que no pertenecen al campo. Mientras la palabra catálogo puede resultar un término genérico, en el contexto de una biblioteca tiene un significado muy concreto: una colección de registros bibliográficos creados según una serie de reglas estrictas. Más que la palabra libro, los bibliotecarios suelen usar el término monografía. Así, a lo largo de los años, la información de un registro del catálogo de monografías ha sido codificado mediante reglas de catalogado, como por ejemplo AACR (Anglo-American Cataloging Rules) en los países de habla inglesa. La tarea de catalogar cada monografía suele costar un tiempo considerable y requiere bastante experiencia. Para ahorrar costes y no duplicar información, las bibliotecas comparten sus registros de catálogos. Así se tiene que la Biblioteca del Congreso y las mayores bibliotecas de universidades disponen sus catálogos entre sí sin coste alguno. Los primeros intentos de almacenar información bibliotecaria en computadores, a finales de 1960, se encontró con serias barreras técnicas, entre las que se incluyen el alto costo de los propios computadores, interfaces de usuarios rígidas y la carencia de redes para el intercambio. Como el almacenamiento era costoso, las primeras aplicaciones tuvieron lugar en áreas donde los beneficios financieros pudieran ser más rentables que almacenar la información en volúmenes de bibliotecas tradicionales. Uno de los primeros éxitos fue el desarrollo de la Biblioteca del Congreso llamado MARC, un formato para el catalogado legible por máquinas (MAchine-Readable Cataloging). El uso de MARC por parte del OCLC (Online Computer Library Center) para compartir registros de catálogo entre numerosas bibliotecas resultó en importantes ahorros para las bibliotecas. MARC fue desarrollado por Henriette Avram y sus colegas en la Biblioteca del Congreso, inicialmente como un formato para distribuir registros del catálogo en cintas magnéticas. En la práctica, el término de catalogado MARC se usa a menudo con un sentido general para cubrir tanto los registros MARC como el formato electrónico con el que se almacenan. El desarrollo de MARC llevó a dos importantes tipos de sistemas computacionales. El primero fue el catalogado compartido, con Fred Kilgour como pionero, y fundador del OCLC en 1967. EL OCLC tiene un gran sistema de computadores con varias decenas de millones de registros de catálogo en formato MARC, de forma que cualquier miembro del mismo puede ir registrando nuevas monografías de forma que cada item se almacena una única vez, y así el esfuerzo intelectual se comparte entre las distintas bibliotecas. Por otra parte, la disponibilidad de Página 33 Virtual Museum sobre plataforma Java EE los registros MARC estimuló un segundo desarrollo: las bibliotecas empezaron a crear catálogos online de forma individual (OPAC - online public access catalog). Para conectar estos catálogos online que empezaban a emerger a finales de los 70, comenzó un proyecto conocido como Linked Systems Project, que desarrolló un protocolo conocido ahora por el nombre Z39.50. Este protocolo permite a una computadora buscar información en otras. Primariamente se usa como medio para buscar en registros MARC, pero el protocolo es flexible y no está restringido a MARC. Técnicamente, el protocolo Z39.50 especifica un conjunto de reglas que permiten a una computadora buscar en la base de datos de otra y recuperar los registros que encuentre. En la figura 3.2 puede verse la distribución de servidores Z39.40 en España. Figura 3.2: Servidores Z39.50 en España MARC fue un formato realmente innovador en un tiempo en el que la mayoría de los sistemas de computadores representaba el texto como campos de longitud fija en mayúsculas exclusivamente. Todavía se mantiene hoy en día como un formato vital para las bibliotecas, pero ya se va notando su edad. Sin embargo, cualquiera que sea su futuro, MARC representó el logro pionero tanto en la historia de los computadores como en la de las bibliotecas. De ahí que que este formato haya evolucionado hacia el MARC 2.0, que es MARC21. En los países europeos Marc es algo innegociable, porque está totalmente aceptado. Ahora se deben construir las interacciones entre la biblioteca convencional y la biblioteca digital y lo ideal es conciliar estas cuestiones. Desde el punto de vista de organismos federales, las bibliotecas digitales no fueron una materia Página 34 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core explícita de investigación hasta los 90. En 1992, DARPA fundó el proyecto Computer Science Technical Reports, que estaba coordinado por la CNRI (Corporation for National Research Iniatives), y que involucraba a cinco universidades: Carnegie Mellon, Cornell, MIT, Stanford y la Universidad de California en Berkeley. A pesar de todo, la iniciativa que realmente estableció a las bibliotecas digitales como un campo distinto de investigación se dio en 1994, cuando las divisiones de ciencias de la computación de la NSF, DARPA y NASA crearon la Iniciativa de Bibliotecas digitales (DLI - Digital Libraries Iniative). Se hizo inversión para seis proyectos de cuatro años con el objetivo de implementar un banco de pruebas sobre bibliotecas digitales: La Universidad de California en Berkeley construyó una gran colección de documentos del entorno de California, incluyendo mapas, imágenes e informes del gobierno. Además, se hizo una notable investigación y trabajo con documentos multivalentes, Chesire II (un sistema de búsqueda que combinaba la potencia de los formatos SGML con la información de registros MARC), y reconocimiento de imágenes. La Universidad de California en Santa Bárbara se concentró en mapas y otros tipos de información geoespacial. Su colección se llama Alexandria Digital Library. En esta línea su trabajo consistió en la inclusión de metadatos para información geoespacial, wavelets para la compresión y transmisión de imágenes, y nuevos métodos para analizar cómo usa la gente las bibliotecas. La Universidad Carnegie Mellon construyó una biblioteca de segmentos de vídeo, llamada Informedia. Este trabajo hizo énfasis en el procesado automático para el descubrimiento de información, búsqueda multimodal, reconcimiento de voz, reconocimiento de imágenes y skimming de vídeo. La Universidad de Illinois trabajó con publicadores para construir una biblioteca federal de periódicos y revistas de ciencia e ingeniería. La mayor parte de su trabajo se concentró en la manipulación de documentos SGML. Además, este proyecto también usaba supercomputación para estudiar los problemas de la información semántica en colecciones muy grandes de documentos. La Universidad de Michigan desarrolló un proyecto sobre las colecciones de las bibliotecas digitales de las universidades. Además, los investigadores llevaron a cabo diversos experimentos con modelos económicos y con un enfoque basado en agentes para la intereoperabilidad. La Universidad de Stanford se centró en un proyecto llamado InfoBus, que se basaba en un método de combinar servicios de diversos orígenes en un conjunto coherente de servicios de bibliotecas digitales. La Iniciativa de Bibliotecas Digitales más allá del trabajo específico que propició, dió forma a una disciplina emergente. La investigación en este campo no era un tema nuevo, pero hasta entonces se había llevado a cabo de una forma fragmentada. Incluso el nombre ”Biblioteca digital” era un término incierto. El establecimiento de este nuevo campo fue importante ya que creó la suficiente confianza necesaria para que el trabajo tanto en investigacación como en aplicaciones prácticas continuara a largo plazo. Además, la Iniciativa de Bibliotecas digital aclaró la distinción entre investigación e implementación. Los proyectos que estaban proponiendo eran trabajos de verdadera investigación; algunos de Página 35 Virtual Museum sobre plataforma Java EE ellos ya se han migrado a aplicaciones prácticas; otros anticipan desarrollos software y hardware, mientras que otros son meramente experimentales. La emergencia de las bibliotecas digitales como una disciplina de investigación podría correr el riesgo de que los investigadores se centraran en problemas demasiado teóricos, pero se contaba con que los fundadores de esta iniciativa eran tres organizaciones federales. De esta manera, la primera fase de la investigacación enfatizó sobre todo en los aspectos pertinentes de ciencias de la computación relativos a este nuevo campo. Sin embargo, las agencias fundadoras (DARPA, NASA y NSF) sabían que esta disciplina era más que una rama de las ciencias de computación. En 1998, cuando se pasó a la segunda fase, incorporó otros grupos de trabajo provenientes de otras disciplinas. Con ello, la orientación del programa se mantenía eminentemente práctica y aplicada, ya que los criterios de concesión de ayudas potenciaron los proyectos de colaboración que presentaban un uso innovador de la tecnología y que tuvieran un carácter práctico con mucha proximidad al mercado. 3.8. Recursos en las Bibliotecas Digitales Dentro del concepto de biblioteca digital un concepto importante es cómo entender los objetos que la conforman. Las bibliotecas digitales pueden contener tipo de información que se pueda codificar como secuencias de bits, o llamados de forma general, recursos. Según la definición que da W3C/IETF un recurso es cualquier cosa que tenga una identidad. Ejemplos cotidianos de recursos incluyen un documento electrónico, una imagen, un servicio de partes climatológicos, y una colección de otros recursos. No todos los recursos son recuperables via red, como son las personas, empresas, libros ”físicos” sujetos a una biblioteca, etc. Esta definición nos lleva a considerar un recurso como cualquier cosa, ya tenga una naturaleza física (libros, coches, personas), digital (páginas web, obras electrónicas) o conceptual (colores, ideas). La adopción de estándares es clave para poder compartir de una forma efectiva los recursos digitales y permitir una interoperabilidad entre instituciones. Ya durante la pasada década han venido emergiendo nuevos enfoques y estándares para la descripción de recursos digitales, como pueden ser, entre otros, Machine Readable Cataloging (MARC), Anglo-American Cataloging Rules, second edition (AACR2), Visual Resources Association Core Schemas (VRA), Categories for the descriptions of works of art (CDWA) o Dublin Core (DC), que veremos a continuación. Estos esquemas de metadatos, junto a la codificación sintáctica XML/RDF, normas de descripción de contenido -ontologías, topic maps, tesauros, etc.- y toda una serie de protocolos para el intercambio de información, protagonizarán la segunda generación de la web, donde las bibliotecas digitales ganarán mayor terreno al brindar la información sistematizada y estructurada dentro del entramado complejísimo en que se nos presenta Internet. 3.9. Esquema de Metadatos para el proyecto Virtual Museum Después de esta descripción a grandes rasgos de la web semántica y metadatos, parece razonable la necesidad de adopción de un estándar de metadatos para el caso particular de museos virtuales y por tanto del presente proyecto. Aquí, se hará uso de Dublin Core. Aunque se describirán las características que lo hacen apropiado en nuestro contexto, se pueden adelantar algunas como son: Página 36 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core Versatilidad Independencia sintáctica Interoperabilidad semántica Simplicidad Normalización formal Evolución a través de una institución consorciada: DCMI Modularidad y arquitectura de metadatos 3.10. Origen de la Iniciativa Dublin Core La Iniciativa de Metadatos Dublín Core (DCMI), (http://dublincore.org), es una organización cuyos fines son la promoción y difusión de normas interoperables sobre metadatos, así como el desarrollo de vocabularios especializados controlados para representar recursos que permitan el desarrollo de sistemas de recuperación más inteligentes. Se podría decir que Dublin Core proviene de dos circunstancias principales: Por un lado, en un hecho real, una necesidad y una coyuntura informativa. En este caso, la imposibilidad de catalogar la Web a través del formato MARC, que habían evidenciado, ya en 1995, proyectos como Intercat de OCLC12 o CATRIONA en el Reino Unido. Y por otro, un cúmulo de casualidades y buenas intenciones de un grupo humano. Dublin Core tiene sus orígenes en Chicago durante la segunda Conferencia Internacional World Wide Web, en octubre de 1994. Yuri Rubinsky de SoftQuad junto a Stuart Weibel y Eric Miller de OCLC, tuvieron una conversación con Joe Hardin, director del Centro Nacional para Aplicaciones de Supercomputación (National Center for Supercomputing Applications - NCSA) que les llevó a una discusión sobre semántica y la web. La confrontación inicial de ideas llevó al NCSA y OCLC a formar un taller de trabajo para discutir la semántica de los metadatos en Dublín, Ohio, en marzo de 1995. En este evento, llamado simplemente "Taller de Metadatos OCLC/NCSA", más de 50 personas discutieron cómo un conjunto de recursos semánticos serían muy útiles para facilitar la búsqueda y la recuperación en la web. Al resultado le denominaron "Metadatos Dublín Core", por el lugar donde se realizó el taller. Desde entonces, se han realizado un total de ocho talleres en Inglaterra, Australia, Finlandia, Alemania, Canadá y los Estados Unidos, a los que han seguido una serie de conferencias internacionales que de momento tienen una frecuencia anual lo que da una idea del estado actual de este proyecto. La DCMI es la iniciativa internacional de metadatos más sólida e importante para la organización y recuperación de información en Internet en forma normalizada, eficaz y con un propósito general. Es hoy un esquema maduro de metainformación cuyo conjunto de elementos (DCMES - Dublin Core Elements Metadata Set) se ha formalizado, primero como norma ANSI/NISO Z39.85 en octubre de Página 37 Virtual Museum sobre plataforma Java EE 2001, y posteriormente, como estándar internacional ISO 15836-2003, desde el 8 de abril de 2003, con independencia de que, en cada ámbito de información, se desarrollen esquemas propios de metainformación para mejorar la recuperación en la red. Este nivel de normalización formal constituye una de las razones de su éxito; uno de los problemas habituales de los estándares para la Web es que se desarrollan y utilizan en un nivel de facto o de especificaciones de dominio público, siendo muy pocos los que alcanzan en nivel de reconocimiento como estándar formal (de iure) ISO. Desde su proclamación como estándar ISO, distintos países han mostrado su credibilidad en este esquema de metadatos, reconociéndolo como estándar nacional, por ejemplo en España, se ha convertido en la norma UNE-ISO 15836:2007. En general, las principales características de Dublin Core, y que lo hacen particularmente apropiado en este proyecto son: Simplicidad: La simplicidad reduce considerablemente los costos y promueve la interoperatividad. La simplicidad no significa acomodar o desechar la semántica y las funciones enriquecidas, soportadas por otros sistemas complejos de metadatos. De hecho, Dublín Core estimula el uso de formatos de metadatos enriquecidos en combinación con Dublín Core y, a menudo, es también, el punto de partida para la creación de descripciones más complejas. Interoperatividad semántica: Las diferencias en la terminología y en las prácticas descriptivas entre un campo del conocimiento y otro impiden la localización/recuperación de información a través de la amplitud del espacio de Internet. El Dublin Core puede ayudar al ”turista digital” –alguien no especializado que busca información– a encontrar su camino a través de un conjunto de elementos común, cuya semántica es universalmente entendida y soportada. Por ejemplo, los científicos preocupados por localizar artículos por un autor particular, y alumnos de arte interesados en trabajos de un artista particular, pueden estar de acuerdo en la importancia del elemento ”creator”. Tal convergencia en un conjunto de elementos común, a pesar de que sea ligeramente más genérica, aumenta la visibilidad y la accesibilidad de todos los recursos, tanto dentro de una disciplina determinada, como más allá de ésta. Flexibilidad: Nada en el Dublín Core es obligatorio, todos los elementos son opcionales y repetibles, así el usuario elige la profundidad de su descripción. El formato además, permite incorporar desde estructuras simples hasta aquellas más elaboradas semánticamente. Extensibilidad: Propiedad que deriva, en parte, de la flexibilidad y, en parte, de la definición de elementos estructurados con distintos grados de complejidad y requerimientos. También, se relaciona con su capacidad de convertirse fácilmente a otros formatos, entre ellos y a pesar de su complejidad, al propio formato MARC. Alcance Internacional: El Conjunto de Elementos Dublin Core se desarrolló originalmente en inglés, pero se han creado versiones en otras muchas lenguas, como por ejemplo finlandés, noruego, tailandés, japonés, francés, portugués, alemán, griego, indonesio y español. El Grupo de Interés especial en localización e internacionalización está coordinando esfuerzos para aunar estas versiones en un registro distribuido. Aunque los retos técnicos de internacionalización de la World Wide Web no se dirigen directamente por la comunidad de desarrollo del Dublin Core, la participación de representantes de prácticamente todos los continentes, ha asegurado que el desarrollo del estándar considere la naturaleza, multilingüe y multicultural, del universo de información electrónica. Página 38 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core El éxito del Dublin Core y de la utilización y adopción de sus elementos se debe a varias razones: Define una semántica precisa pero es independiente sintácticamente; es decir, no depende de una sintaxis de codificación particular, ni HTML, ni XML, ni RDF, sino todas ellas. Se ha adoptado internacionalmente y sus elementos y semántica asociada están traducidos a más de 20 idiomas. Es un estándar de propósito general, no depende de ningún dominio informativo, pero se adapta a las distintas comunidades de información Web y se lleva muy bien con otros esquemas de metadatos de propósito específico, sirviendo de piedra rosetta para la representación de las relaciones entre elementos. Es el modelo de metadatos clave en sistemas y servicios de información digital, como por ejemplo para la iniciativa de archivos abiertos (OAI), o servicios comerciales como Connexion de OCLC. También ha sido adoptado por distintos gobiernos en sus proyectos de e-Gov, por ejemplo en: Australia, Canadá, Dinamarca, Finlandia, Irlanda, Nueva Zelanda y Reino Unido), y por los más emblemáticos proyectos de bibliotecas digitales y gestión del patrimonio digital. Tiene una gran validez como estándar porque es simple, extensible e interoperable. El hecho de ser una norma ISO, lo convierte en un estándar apto para la industria y así lo demuestra su uso en contextos corporativos y el protagonismo que ha adquirido en algunos sistemas gestores de contenidos empresariales (ECMS) como Libertas Solutions CMS oCONTENS. Incluso está presente como plugins en sistemas de gestión de blogs como WordPress o navegadores como Mozilla Firefox. Voluntad de que una Web mejor es posible y al espíritu abierto, global e independiente de la DCMI que hace que sea una iniciativa viva que se adapta a las necesidades de distintos tipos de usuarios o distintos tipos de información, creando más términos de metadatos, más perfiles de aplicación, o simplemente adaptando el uso de los elementos a un fin particular. 3.11. Conjunto de Elementos de Metadatos La estructura de Dublin Core está basada en dos niveles: simple y cualificado. El nivel simple está formado por 15 elementos, mientras que el nivel cualificado incluye dos elementos más así como un conjunto de nuevos elementos cualitativos llamados cualificadores, dedicados a la descripción más en detalle de los elementos simples. Se puede ver a los elementos como nombres, y a los elementos cualitativos como adjetivos, cuya misión es concretar más el significado del nombre, pero nunca extenderlo. Además, los elementos cualitativos deben cumplir el principio de mutismo (Dumb-Down), en virtud del cual los elementos cualitativos pueden llegar a ser mudos; es decir, todo elemento debe ser entendido sin necesidad de los elementos cualitativos, de tal forma que un usuario siempre podrá usar un metadato sin necesidad de ellos. Finalmente, cada elemento es opcional y se puede repetir. El estándar de Dublin Core es un conjunto de elementos, sencillo pero efectivo, para describir un amplio abanico de recursos en red. El estándar de Dublin Core consta de 15 elementos, cuya semántica ha sido establecida mediante consenso por un grupo internacional de profesionales de Página 39 Virtual Museum sobre plataforma Java EE Por otra parte, hay que hacer notar que, como documento XML bien formado, debería tener una raíz que actúe de contenedor de los elementos codificados. La recomendación no hace referencia al nombre de este elemento contenedor ni el espacio de nombres del que se podría sacar. Sin embargo, como posibles candidatos podríamos tener las etiquetas: dc, dublinCore, record o metadata. Como describe el modelo abstracto de Dublin Core simple, podemos tener las siguientes entidades: Un registro DC simple está compuesto por una o más propiedades y sus valores asociados. Cada propiedad es un atributo del recurso que se está describiendo. Cada propiedad debe se una de las dadas por el conjunto de elementos de metadatos Dublin Core. Las propiedades se pueden repetir. Cada valor es un literal (string). Cada valor puede tener un idioma asociado. Formalmente hablando, no hay conexión entre el registro DC simple y el recurso que se está describiendo. Para ello, la conexión se podría dar (aunque no obligatorio) codificando la URI del recurso como valor del elemento DC. Identifier. Siguiendo con las recomendaciones, como dice DCMI, las propiedades se deberían codificar como elementos XML (en minúsculas) y los valores como el contenido de estos elementos. El nombre del elemento XML debe ser un nombre XML cualificado que asocia un nombre de elemento con el apropiado del espacio de nombres DCMI, como muestra el siguiente ejemplo: <dc:title>Dublin Core en XML</dc:title> en vez de: <dc:title value="Dublin Core en XML" /> Para codificar múltiples valores para una propiedad dada, simplemente hay que repetir el elemento XMl para esa propiedad: <dc:title>Mi primer titulo</dc:title> <dc:title>Mi segundo titulo</dc:title> En caso de que se vaya a especificar el idioma usado en el valor para una propiedad, se debe usar el atributo xml:lang: <dc:subject xml:lang="es">marisco</dc:subject> <dc:subject xml:lang="fr">fruits de mer</dc:subject> Página 46 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core 3.14.2. RDF La plataforma para la descripción de recursos (RDF - Resource Description Framework) es hoy en día uno de los pilares principales, junto con el lenguaje XML, de la Web Semántica. RDF tiene en sus orígenes a Cyc: un proyecto para crear crear inteligencia artificial con un ”sentido común” básico. Consta de una gran base de datos que contiene definiciones tales como por ejemplo ”un árbol es una especie de planta, un sauce es una especie de árbol, etc”. Cyc puede por lo tanto deducir de estas definiciones que un sauce es una planta. RDF es un lenguaje general de representación de información. Por decirlo de otro modo es lo que podríamos denominar un lenguaje de metadatos. Es un estándar del W3C por lo que tiene un potencial inmenso, aunque es más común encontrar ejemplos de RDF Site Summary que de RDF propiamente dicho y además, en general un fichero RDF no se muestra a personas. RDF se puede ver como la respuesta de la informática a la necesidad de disponer de sistemas altamente homogéneos para describir recursos digitales en particular y recursos de cualquier tipo en general. RDF no es un conjunto de metadatos predefinidos, como Dublin Core, sino un conjunto de especificaciones para crear cualquier tipo conjunto de metadatos siguiendo un conjunto de normas pre-establecidas que hacen posible el intercambio de descripciones creadas por agentes distintos y sin necesidad de que se hayan puesto previamente de acuerdo entre ellos. Para embeber los elementos de Dublin Core en XML usando RDF, se debe proporcionar una DTD o un XML Schema con el cual poder validar los documentos generados. Cualquier documento XML bien formado debe incluir una sentencia acerca de la versión usada de XML. Actualmente, la única versión válida de XML (dada en la recomendación W3C) es 1.0. Por tanto, el documento deberá empezar por: <?xml version="1.0"?> Seguidamente la DTD usada se referencia mediante: <!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN" "http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd"> Es necesario declarar que se está usando RDF, para que las aplicaciones puedan reconocerlo como un documento RDF/XML. La siguiente sentencia declararía la etiqueta de apertura con su espacio de nombres XML y el espacio de nombres usado para los elementos DC: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> La codificación permite describir múltiples recursos en un único documento. Cada recurso descrito viene encerrado en un elemento contenedor etiquetado como rdf:Description. Dentro de esta etiqueta, se coloca cada elemento precedido por el espacio de nombres dc:. Por ejemplo, el elemento Title produce la etiqueta (completamente en minúsculas) dc:title dentro del contenedor de la descripción como sigue: <rdf:Description rdf:about="http://www.virtualmuseum.com/"> <dc:title>Virtual Museum</dc:title> </rdf:Description> Si el valor de algún elemento DC es un recurso que tiene una URI en vez de texto plano, se debería describir el valor del atributo rdf:resource en la etiqueta, con un contenido vacío: Página 47 Virtual Museum sobre plataforma Java EE <rdf:Description rdf:about="http://www.virtualmuseum.com/"> <dc:source rdf:resource="http://www.virtualmuseum.com/otradireccion/"/> </rdf:Description> De esta forma, se puede repetir esta estructura para otros elementos del conjunto DC. Hay que hacer notar que el conjunto de elementos dentro de la descripción, como conjunto, no presenta orden alguno y que por tanto las aplicaciones que consuman el documento no tienen porqué preservar el orden de los elementos dentro del contenedor de la descripción. Para describir el idioma usado para el contenido del elemento, XML provee el atributo xml:lang en el cual se puede embeber dicho idioma. <rdf:Description rdf:about="http://dublincore.org/"> <dc:title xml:lang="fr">L’Initiative de métadonnées du Dublin Core</dc:title> <dc:title xml:lang="de">der Dublin-Core Metadata-Diskussionen</dc:title> </rdf:Description> <head> <link rel="meta" href="nombre_pagina.rdf" /> </head> 3.14.3. HTML/XHTML Otra forma de especificar registros de metadatos es embeberlos en páginas HTML/XHTML. Como hemos visto anteriormente, se puede crear un archivo RDF o XML separado y enlazarlo usando etiquetas HTML/XHTML <link>. En este apartado veremos cómo embeber información DC a través de etiquetas <meta> y<link>. Como indica la recomendación, sólo es posible describir un recurso único usando este método. Para describir múltiples recursos se puede cualquiera de los dos métodos anteriores. Entre sus ventajas se tiene que la utilización de etiquetas <meta> aparecieron en las primeras especificaciones de HTML, son ampliamente conocidas y tienen un uso extendido. Sin embargo, debido a su extensión es frecuente ver su excesivo uso con propósitos no correctos, y además, no son interpretables directamente por un usuario. Los metadatos DC a través de este método se embeben dentro de la sección <head> de una página XHTML. Para codificar un elemento DC, se usa el atributo name ycontent dentro de las etiquetas XHTML meta: <meta name="DC.element" content="Value" /> <meta name="DCTERMS.element" content="Value" /> De forma general, los nombres de elementos pueden contener tanto mayúsculas como minúsculas pero deberían presentar siempre la primera letra como minúscula. El valor del atributo content se define como CDATA; es decir, una secuencia de caracteres dado por el conjunto de caracteres dado por el documento. Para indicar el esquema de codificación se usa el atributo scheme dentro de la etiqueta <meta>. El esquema de codificación usado debería seguir los nombres especificados por la recomendación de términos DCMI, y pueden presentar mayúsculas y minúsculas empezando por mayúscula, aunque a menudo se especifican escribiendo la palabra en mayúsculas completamente. Página 48 Capítulo 3. Web Semántica y Museos Virtuales: Dublin Core <meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2006-10-26" /> <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" /> Cuando el valor de una propiedad es la URI de otro recurso (como se podría dar en el caso de un elemento DC.relation), se prefiere una forma alternativa de codificación dada la etiqueta XHTML <link>: <link rel="propiedad" href="URIdelRecurso" /> En los documentos donde se indique el idioma usada para completar un elemento, se debería usar el atributo xml:lang de la etiqueta XHTML <meta> y/o el atributo hreflang de la etiqueta link. Por ejemplo: <meta name="DC.subject" xml:lang="en-GB" content="seafood" /> <meta name="DC.subject" xml:lang="fr" content="fruits de mer" /> <link rel="DC.relation" hreflang="en" href="http://www.virtualmuseum.com/en/" /> <link rel="DC.relation" hreflang="de" href="http://www.virtualmuseum.com/de/" /> Los prefijos DC yDCTERMS usados en los nombres de las propiedades durante este apartado se usan para indicar el espacio de nombres del que se considera la propiedad. La URI del namespace se debería codificar mediante la etiqueta <link>, usando el siguiente patrón: <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> 3.14.4. Microformato Dublin Core Los microformatos aprovechan características de HTML/XHTML para añadir información semántica, e intentan ser útiles principalmente a las personas, y en segundo lugar a los agentes de software (por ejemplo, los buscadores y otros más avanzados). Aunque esta sintaxis está destinada principalemente a las personas, en contra tiene que son menos potentes que las otras ya que por ejemplo no permiten definir formalmente relaciones complejas que puedan servir para que los agentes de software realicen inferencias o deducciones. En general, los microformatos consisten en soluciones estándar de marcado HTML/XHTML que utilizan las características semánticas que ofrecen las propiedades class de cada elemento para casos de uso concretos. Hay estructuras de marcado HTML que son rápidamente aceptadas como ”buena práctica” y recomendadas y adoptadas de forma general, tales como lista desordenadas para construir menús o listas de definición para fichas de elementos de algún tipo. Una vez que se abstraen estos patrones comunes, se pueden formalizar e identificar, por ejemplo, por medio del atributo class. Particularizando para el caso de Dublin Core, el esquema de codificación mediante microformatos vendría dada a través de lista de definición, como muestra la siguiente porción de código HTML: <dl class="dublincore"> <dt>Título:</dt> <dt>Título</dt> <dd class="title">El ingenioso hidalgo Don Quijote de la Mancha</dd> <dt>Autor:</dt> <dd class="creator">Miguel de Cervantes Saavedra</dd> <dt>Fecha de creación:</dt> <dd class="date">1604</dd> </dl> Página 49 Virtual Museum sobre plataforma Java EE En este caso, los metadatos Dublin Core se embeben en un a lista de definición dl. Este elemento tiene una clase dublincore, que podría tener asociado diversas propiedades para su representación por medio de hojas de estilo CSS, por ejemplo. Sin embargo, donde radica la idea de los microformatos es que además de forma, puede tener contenido semántico. Dentro de la etiqueta, se encuentra la clase title que es uno de los elementos Dublin Core. De forma similar, se podría embeber la información oportuna dentro del resto de elementos de la lista de definición. La principal ventaja que presenta esta sintaxis de codificación respecto a las anteriores, es que son visibles directamente por personas. De hecho, con los microformatos se pretende facilitar el acceso a la información contenida en los metadatos para las personas, por encima de los agentes de usuario. Como desventaja de este esquema de codificación nos encontramos con que su uso todavía no ha sido adoptado ni por desarrolladores de aplicaciones, ni por buscadores y de momento, está lejos de convertirse en un estándar de facto. Si los microformatos de Dublin Core fuesen un estándar el código anterior podría ser recogido por los navegadores e indexado siguiendo el conjunto de elementos Dublin Core para su posterior consulta. Página 50 PARTE II DESARROLLO DEL SISTEMA 51 Capítulo 4 PLAN DE DESARROLLO DEL PROYECTO No basta tener buen ingenio; lo principal es aplicarlo bien. René Descartes Índice del Capítulo 4.1. Introducción .................................... 54 4.2. Perspectiva general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2.1. Metodología................................ 54 4.2.2. Referencias ................................ 54 4.2.3. Elementos a entregar del proyecto . . . . . . . . . . . . . . . . . . . . 55 4.3. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.1. Estructura organizativa . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.2. Interfaces externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.3. Responsabibilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4. Gestióndelproyecto................................ 58 4.4.1. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.4.2. Mecanismos de supervisión y control . . . . . . . . . . . . . . . . . . . 59 4.4.3. Estimaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.4. Plan del personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.5. Procesotécnico................................... 60 4.5.1. Herramientas ............................... 60 4.5.2. Documentación del software . . . . . . . . . . . . . . . . . . . . . . . 61 4.6. Planificación .................................... 61 53 Virtual Museum sobre plataforma Java EE 4.1. Introducción Este documento describe el plan de desarrollo general que se seguirá para el desarrollo del proyecto Sistema de generación de Museos Virtuales. El motivo de realizar este plan de desarrollo se debe a que la calidad en el ámbito del desarrollo software no sólo se debe enfocar en el producto terminado, sino también en el proceso que se sigue hasta llegar al resultado final. Este plan del proyecto tiene entre sus objetivos definir las actividades necesarias para la construcción del proyecto Sistema de generación de Museos Virtuales. Los planes trazados en este documento están basados en los requisitos del proyecto. 4.2. Perspectiva general del proyecto 4.2.1. Metodología Inicialmente la metodología usada ha seguido las pautas del Proceso Unificado. El Proceso Unificado es un proceso de desarrollo software iterativo e incremental, dirigido por los casos de uso y centrado en la arquitectura, que plantea un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Además de ello, el Proceso Unificado puede verse como un marco de trabajo que debe ser adaptado en una serie de variables: tamaño del sistema, dominio en el que va a trabajar, complejidad y nivel de proceso de la organización del proyecto. Adicionalmente a las guías demarcadas por el Proceso Unificado y dadas las circunstancias en las que se iba desarrollando el proyecto, se optó por introducir los principios propuestos por el Modelado Ágil (Agile Modeling) de Scott Ambler. El punto clave en el Modelado Ágil se basa en sus prácticas y principios culturales, que animan a los desarrolladores a producir suficientes modelos de forma que soporten los problemas de diseño y documentación de forma adecuada. Un concepto importante del Modelo Ágil es que no se trata de un proceso de software completo, por lo que se necesitará concretar el proceso con otras metodologías como XP, DSDM, SCRUM o en nuestro caso: el Proceso Unificado. Sumando estos dos enfoques se podría decir que la metodología seguida para el desarrollo del proyecto se basa en el Proceso Unificado como marco de trabajo, y adaptado minimizando los artefactos a desarrollar y la cantidad de documentos a mantener, según los principios de mantener la documentación simple, aceptar los cambios, modelar con un propósito, y agilizar los flujos de trabajo manteniendo un viaje ligero a lo largo del desarrollo del producto. 4.2.2. Referencias Principalmente, las fuentes de información adicionales a este documento vienen dadas por la metodología usada, por lo que se propone seguir las referencias bibliográficas [JR00b] y [Amb02], así como las normas IEEE para la especificación de requisitos software 830 y planificación de proyectos 1058.1. Página 54 Capítulo 4. Plan de desarrollo del proyecto 4.2.3. Elementos a entregar del proyecto A continuación se indican y describen cada uno de los artefactos que serán generados a través de las diferentes fases e iteraciones y utilizados por el proyecto y que constituyen los entregables. Es preciso destacar que debido a la naturaleza iterativa e incremental del proceso, todos los artefactos son objeto de modificaciones a lo largo del desarrollo, con lo cual los presentados en esta memoria serán la versión definitiva y completa de cada uno de ellos: Requisitos: aúna al documento de especificación y descripción de requisitos software, así como el modelo de casos de uso. Análisis: abarca al diagrama de clases de análisis, y realizaciones de casos de uso en colaboraciones. Diseño: comprende al diagrama de clases de diseño, realizaciones de casos de uso, diagramas de actividad de operaciones, diseño relacional del esquema de la base de datos, diccionario de datos. Implementación: la jerarquía de ficheros de código fuente cuya compilación producen el sistema ejecutable. Despliegue: el conjunto de componentes software junto con la documentación necesaria para desplegarlo en producción, así como el conjunto de rutinas para instalar, inicializar y usar el sistema en explotación. Plan de iteraciones: planificación temporal y de actividades, así como los hitos a alcanzar en cada una de las iteraciones. Documento de métricas: informes de diversas métricas obtenidas a partir del código fuente. Principalmente se elaborarán las métricas mediante PMD (http://pmd.sourceforge.net), CPD (http://pmd.sourceforge.net/cpd.html), y FindBugs (http://findbugs.sourceforge.net) 4.3. Organización del proyecto 4.3.1. Estructura organizativa Esta sección describe la estructura organizativa de roles desempeñados, junto con sus actividades asociadas, a lo largo del desarrollo del proyecto, y se muestra gráficamente en la figura 4.1: 1. Jefe de Proyecto Planificar el proyecto. Supervisar el desarrollo del mismo y gestionar los tiempos de cada iteración, evaluando los hitos alcanzados. 2. Ingeniero de Casos de Uso Página 55 Virtual Museum sobre plataforma Java EE Fase de Elaboración Iteración Descripción Hito asociado Estimación 1 Definir y elaborar los casos de uso Desarrollar el modelo de análisis (clases principales del dominio) Plantear bocetos de pantallas como medio de captura de requisitos preliminar Análisis conceptual preliminar Bocetos de pantallas principales 2 semanas 2 Construir spikes con aspectos funcionales que aclaren el uso de nuevas tecnologías Colaboraciones de clases de análisis Especificaciones suplementarias Planteamiento de la arquitectura Modelo de análisis Modelo de diseño preliminar 2 semanas 3 Elaborar el modelo de diseño Especificaciones suplementarias Diseño de la arquitectura Realizaciones de casos de uso como diagramas de secuencia y colaboración Prototipo de arquitectura Modelo de diseño Diagramas de interacción para la realización de casos de uso en diseño 2 semanas Cuadro 4.2: Tareas de la fase de elaboración Página 62 Capítulo 4. Plan de desarrollo del proyecto Fase de Construcción Iteración Descripción Hito asociado Estimación 1 Elaborar navegación entre pantallas aplicación administrador Pantallas enlazadas de aplicación administrador 1 semana 2 Modelado de objetos y relacional de las entidades del sistema Mapeos Hibernate Autenticación y autorización de accciones Pruebas y correcciones Capa de acceso a datos inicial 3 semanas 3 Implementación Pruebas y correcciones Diagramas de actividad Aplicación administrador navegable 2 semanas 4 Implementación Pruebas y correcciones Aplicación responsable del museo navegable Capa de lógica de negocio para administrador 3 semanas 5 Implementación Pruebas y correcciones Capa de acceso a datos Capa de lógica de negocio para responsable del museo 5 semanas 6 Implementación Pruebas y correcciones Vista web para visitante 2 semanas 7 Construcción de spikes para explorar las dificultades del uso de servicios de terceros Implementación Pruebas y correcciones Servicios Web 2.0 3 semanas 8 Implementación Pruebas y correcciones Capa de servicios Vista móvil para visitante 2 semanas Cuadro 4.3: Tareas de la fase de construcción Página 63 Virtual Museum sobre plataforma Java EE Fase de Transición Iteración Descripción Hito asociado Estimación 1 Puesta en marcha del producto en ambiente de desarrollo Elaboración de manual de instalación Elaboración de manuales de usuarios Producto final en ambiente de desarrollo 2 semanas 2 Implantar producto en ambiente de explotación Asegurar funcionamiento global Producto final en ambiente de explotación 1 semana Cuadro 4.4: Tareas de la fase de transición Página 64 Capítulo 5 ESPECIFICACIÓN DE REQUISITOS Si tu intención es describir la verdad, hazlo con sencillez y la elegancia déjasela al sastre. Albert Einstein Índice del Capítulo 5.1. Introducción .................................... 66 5.1.1. Propósito ................................. 66 5.1.2. Alcance.................................. 66 5.1.3. Referencias ................................ 66 5.1.4. Perspectiva general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2. Descripcióngeneral ................................ 66 5.2.1. Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.2. Funciones del producto . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2.3. Descripción del modelo de negocio . . . . . . . . . . . . . . . . . . . . 69 5.2.4. Características del usuario . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2.5. Restricciones ............................... 70 5.3. Requisitos específicos de la aplicación del administrador . . . . . . . . . . . . . 70 5.3.1. Funcionalidad de la aplicación del administrador . . . . . . . . . . . . . 70 5.3.2. Requisitos adicionales de la aplicación del administrador . . . . . . . . . 71 5.4. Requisitos específicos de la aplicación del director de museo . . . . . . . . . . . 71 5.4.1. Funcionalidad de la aplicación del director de museo . . . . . . . . . . . 71 5.4.2. Requisitos adicionales de la aplicación del responsable del museo . . . . 72 5.5. Requisitos específicos de la aplicación del visitante . . . . . . . . . . . . . . . . 72 5.5.1. Funcionalidad de la aplicación del visitante . . . . . . . . . . . . . . . . 72 65 Virtual Museum sobre plataforma Java EE 5.1. Introducción 5.1.1. Propósito El propósito de este capítulo consiste en especificar los requisitos de un sistema gestor de museos virtuales. El público objetivo del mismo incluye principalmente al analista de sistemas, arquitecto y al cliente. 5.1.2. Alcance La motivación principal para el desarrollo de este sistema es proporcionar una herramienta a los responsables de pequeños y medianos museos que les permita la publicación on-line de información relativa de los objetos que exponen. Esta herramienta permitirá que los responsables de museos puedan gestionar los contenidos que deseen publicar de una manera sencilla y que no les obligue a mantener un servidor dedicado. 5.1.3. Referencias La principal referencia de este documento se basa en la norma IEEE 830 para la especificación de requisitos software. 5.1.4. Perspectiva general El resto del capítulo se divide en dos partes principalmente: una primera sección que contiene una descripción general y de alto nivel del sistema a desarrollar, y una segunda sección que comprende los requisitos específicos divididos por rol. 5.2. Descripción general 5.2.1. Perspectiva del producto Las nuevas tecnologías introducen un nuevo mecanismo de publicación de contenidos a través de Internet. Esto favorece que los pequeños y medianos museos puedan dar a conocer a una comunidad de usuarios mucho más grande información acerca de los objetos que exponen. Un sistema gestor de museos virtuales, como el que se va a construir, permite la creación, modificación, hosting, administración, comunicación y visualización de museos virtuales. Aunque puede enmarcarse dentro de los sistemas gestores de contenidos (CMS) genéricos, está orientado a la gestión de sitios web para pequeños y medianos museos de arte. Página 66 Capítulo 5. Especificación de requisitos Si bien el usuario puede crear un sitio web genérico, encontrará más facilidades y funcionalidades para publicar sus obras, u objetos expuestos en general. Asimismo, siguiendo esta orientación hacia la gestión de colecciones de obras artísticas, el proyecto permitirá seguir el estándar de metadatos Dublin Core. Aunque el proyecto pretende producir un sistema gestor de contenidos especializado, la visualización de los museos virtuales generados no se limita a su forma web clásica, sino que se dispondrá de una visualización para dispositivos móviles de ciertos contenidos elegidos por el usuario. Además de esa vía alternativa de visualización, el museo virtual generado puede permitir exponer o acceder a ciertos servicios con los que interoperar tanto desde el punto de vista de lo que expone el museo virtual a terceros como las aplicaciones con las que puede comunicarse. El sistema desarrollado producirá un producto autónomo: no se integrará ni dependerá de otros sistemas, a excepción de los componentes de ejecución básicos requeridos por la tecnología empleada (sistema operativo, máquina virtual java, contenedor servlet, etc). El sistema contempla tres tipos de roles distintos: administrador, responsable del museo y visitante. Para cada rol el sistema debe aportar las interfaces adecuadas pudiéndose ver como un sistema dividido en cuatro aplicaciones diferentes que acceden a la misma información con unos privilegios determinados por el tipo de rol: Administración (rol administrador): Tiene los privilegios máximos del sistema pudiendo supervisar o modificar cualquier acción ejecutada por el resto de usuarios. La aplicación en sí misma dará acceso a la gestión de las entidades maestras del sistema completo. Gestión de Museos Virtuales (rol responsable del museo o director): Compone el núcleo del sistema permitiendo crear, modificar y mantener el museo virtual. Sitio web del museo virtual generado (rol visitante): Como resultado principal del trabajo del responsable del museo, se podrá publicar un sitio web para el visitante o público en general en Internet. Vista para dispositivos móviles (rol visitante): Además de la vista web, la oferta de contenidos para el visitante permitirá la visualización de ciertas secciones del museo virtual como una aplicación independiente al resto en un dispositivo móvil. Interfaces de sistema El sistema que se está realizando sigue una arquitectura extensible tipo Cliente-Servidor. Interfaces de usuario Todas las aplicaciones que producirá el sistema deberán estar disponibles a través de un navegador de uso común, por lo que se deberá fomentar la compatibilidad y seguimiento de los estándares comúnmente aceptados como buenas prácticas. La aplicación que genera una vista para móviles deberá poder ejecutable en un dispositivo móvil con soporte Java, y especificamente, compatible con MIDP. Página 67 Virtual Museum sobre plataforma Java EE Interfaces de hardware Las aplicaciones de las que consta el sistema deben poder ser visualizadas al menos en un ordenador personal, a excepción de la vista móvil, que está destinada a ejecutarse en un dispostivo móvil. Interfaces de software El proyecto debe implementarse bajo la plataforma Java EE y la elección de componentes para armar la arquitectura debe basarse, entre otros factores, en su disponibilidad como software de libre distribución. Operaciones Las operaciones que se pueden realizar con este sistema deberán ser intuitivas para los usuarios. Por ello, este sistema debe estar creado buscando la facilidad de uso, de forma que no se necesite una formación adicional exhaustiva para su manejo o mantenimiento, teniendo en cuenta que sería deseable que el encargado del mantenimiento del sistema fuera una persona con conocimientos en redes y administración de sistemas Linux, tanto a nivel de servidores web como de base de datos. Se deberán tener en cuenta además los requisitos de interacción comentados en el apartado 2.3. 5.2.2. Funciones del producto En este apartado delimitaremos a grandes rasgos las funciones del sistema software a construir: Administración de usuarios Administración de museos virtuales Obtención de estadísticas Gestión de contenidos on-line del museo virtual Comunicación entre los tres roles del sistema Publicación y visualización de museos virtuales via web Publicación y visualización de museos virtuales en móviles o PDA’s Hosting de museos virtuales Soporte para la inclusión de metadatos Dublin Core en los contenidos Intercambio de información entre el museo virtual y otros sistemas externos o servicios (Google Maps, Flickr, Picasa, RSS, XML y servicios web) Página 68 Capítulo 5. Especificación de requisitos Personalización de la apariencia de los museos virtuales generados Soporte de idiomas 5.2.3. Descripción del modelo de negocio Aunque se describirá con mayor detalle, la figura 5.1 presenta una aproximación al modelo de negocio del proyecto. En la misma, se muestra en primer lugar al actor Administrador que controla y supervisa las operaciones que se realizan en el sistema de forma general. A partir de ahí, tenemos al rol de Responsable del museo que compone y configura el sitio web que posteriormente será accesible al público general de Internet, mediante un dispositivo móvil o incluso a otras aplicaciones (desarrolladas en otros lenguajes de forma ajena al sistema) mediante servicios web, RSS o XML. Figura 5.1: Modelo de negocio La aplicación del Responsable del museo presentará diversas funcionalidades en cuanto a contenidos, idiomas, personalización de apariencia, y además, aportará funciones de comunicación con otros sistemas de Internet como Flickr, Picasa o Google Maps. En resumen, el proyecto a desarrollar cuenta con diversas funciones y servicios que lo hará útil a los usuarios que deseen abrir a Internet las colecciones de obras u objetos en general. Página 69 Virtual Museum sobre plataforma Java EE 5.2.4. Características del usuario Los usuarios de este sistema serán personas familiarizadas al menos con la tecnología web. Estos usuarios tienen conocimientos sobre los sistemas gestores de contenidos y la necesidad del uso de estándares de metadatos para el catalogado de los recursos de una colección. 5.2.5. Restricciones Para las aplicaciones del administrador y responsable del museo, el sistema debe proporcionar una forma segura de autenticación de usuarios, y autorización de las acciones para las que tienen permiso. Las vistas tanto web como móvil del museo virtual de cara al visitante serán de acceso público, desde el momento en que el responsable del museo las publique. 5.3. Requisitos específicos de la aplicación del administrador 5.3.1. Funcionalidad de la aplicación del administrador 1. La entrada a la aplicación para el administrador deberá ser permitida únicamente a los usuarios que posean una cuenta de administrador. Al menos existirá una cuenta de administrador en el sistema. Un administrador puede cambiar su clave en cualquier momento. 2. El administrador puede crear nuevas cuentas de Responsable del museo o borrar cuentas ya existentes. Asimismo, también será capaz de borrar el museo virtual creado por un usuario responsable del museo. La creación de cuentas puede incluir un mecanismo de generación aleatoria de contraseñas. El borrado de una cuenta de responsable del museo conlleva el borrado del museo virtual que hubiera creado. A la inversa, el borrado de un museo virtual no implica el borrado de la cuenta de responsable del museo. 3. Las cuentas de responsable del museo constan de un identificador de cuenta (login) y contraseña que se suministran en la aplicación para permitir el acceso. Además, como información adicional, en la creación de una cuenta de director se debe suministrar al menos su nombre, dni, dirección de correo electrónico, el nombre del museo para el cual se va a crear un museo virtual y su dirección física. 4. Como la cuenta de administrador tiene más privilegios con las cuentas de responsable del museo, un administrador puede modificar un museo virtual desde su aplicación de la misma forma en que lo haría el responsable del museo. De la misma forma, el administrador puede cambiar la contraseña de un responsable del museo lo que serviría por ejemplo, para evitar el acceso a la aplicación para el director del museo para ese responsable del museo en particular. 5. El administrador puede importar nuevas plantillas al sistema, ofreciendo así un mecanismo de personalización de la apariencia para los museos generados. 6. El sistema puede recoger estadísticas acerca del uso de las cuentas de responsable del museo, museos virtuales creados, espacio en disco del servidor ocupado, etc. que servirán para dar información al administrador. Página 70 Capítulo 5. Especificación de requisitos 5.3.2. Requisitos adicionales de la aplicación del administrador Además de estas funcionalidades el sistema debe proporcionar al administrador un soporte de ayuda que pueda ser consultado en cualquier momento. Sería deseable por otra parte que el sistema permitiese una vía de comunicación con el responsable del museo para que éste pueda aportar comentarios. El sistema debe ofrecer un mecanismo para soportar múltiples idiomas en la visualización de la aplicación. 5.4. Requisitos específicos de la aplicación del director de museo 5.4.1. Funcionalidad de la aplicación del director de museo 1. Un responsable del museo tiene una cuenta en el sistema que le permite la entrada a la creación, modificación y mantenimiento de su museo virtual. Referente a su cuenta, un responsable del museo no podrá cambiar su identificador de cuenta. Esto no implica que en la creación del museo virtual se establezca un título y una ubicación física distinta de la especificada inicialmente. Inicialmente en el sistema no existirá ninguna cuenta de responsable del museo; la creación de estas cuentas es labor del administrador, aunque adicionalmente se podrá habilitar una zona de registro por parte del usuario (teniendo en cuenta algún criterio para evitar spam y registros automáticos) 2. A cada cuenta de responsable del museo se le permite la creación de un museo virtual. El responsable del museo introduce los datos relativos a su museo y los contenidos que en él se exponen (objetos digitales) por medio de formularios en la aplicación. 3. Cada museo virtual generado puede ser configurado para visualizarse en varios idiomas, aunque será labor del responsable del museo editar los textos de los contenidos para cada uno de los idiomas que configure. 4. El esquema de toda la información introducida se ajustará a un estándar de metadatos preestablecido, con el fin de proporcionar interoperabilidad con otros sistemas existentes. Al seguir un estándar de metadatos, el sistema podrá exportar datos de su museo en parte o en su totalidad a petición del responsable del museo o de otro sistema ajeno. 5. Una vez introducido un conjunto mínimo de datos el responsable del museo puede solicitar un vista previa o publicar su museo virtual. El conjunto mínimo de datos necesarios para publicar o solicitar una vista previa son el nombre del museo, información acerca de un objeto digital y un recorrido conteniendo al menos un objeto digital. 6. Al hacer público un museo virtual el sistema pone a disposición de los visitantes la vista web del museo virtual recién creado. El responsable del museo cuenta con la posibilidad de generar además una vista para móviles y PDA’s del museo virtual. Como mínimo, la publicación de un museo virtual debería contar con el nombre del museo, su ubicación física e información acerca de al menos uno de sus objetos. Página 71 Virtual Museum sobre plataforma Java EE CU.A05 - Gestionar Plantillas Descripción Reúne la funcionalidad para dar de alta, eliminar y modificar plantillas Secuencia normal Pasos Acción 1 El sistema ofrece una lista de todas las plantillas 2 El administrador elige una para editar sus detalles 3 El sistema presenta los detalles de la plantilla junto con su vista previa y el árbol de archivos/directorios que componen la plantilla 4 El administrador puede modificar el contenido de aquellos archivos que sean texto plano y visualizar el resto Excepciones Paso Acción 2 El administrador escoge una o más plantillas para eliminarlos, previa confirmación Cuadro 6.5: CU.A05 - Gestionar Plantillas CU.A06 - Importar plantilla Descripción Permite importar un empaquetado de la plantilla conteniendo todos los archivos necesarios para su visualización Secuencia normal Pasos Acción 1 El sistema muestra un diálogo de examinar archivo para seleccionar la plantilla (el archivo empaquetado) de su árbol de directorios local 2 El administrador selecciona el archivo adecuado 3 El sistema desempaqueta el archivo ya subido al servidor 4 El sistema procesa el archivo desempaquetado registrándolo como nueva plantilla para su uso Excepciones Paso Acción 4 Si al procesar el archivo subido resulta que no presenta la estructura fijado por las plantillas en Virtual Museum, se desecha como plantilla informando al usuario Cuadro 6.6: CU.A06 - Importar plantilla CU.A07 - Gestionar Idiomas Descripción Reúne la funcionalidad para dar de alta, eliminar y modificar idiomas soportados por el sistema global Secuencia normal Pasos Acción 1 El sistema ofrece una lista de todos los idiomas 2 El administrador elige un idioma para editar su información 3 El sistema muestra la información del idioma permitiendo la modificación de los campos 4 Al guardar se vuelve al listado de idiomas Excepciones Paso Acción 2 El administrador selecciona crear un idioma; como no hay idioma seleccionado, el sistema mostrará la información del idioma para guardar incluyendo el código del idioma que se está creando. 2 El administrador escoge uno o más idiomas para eliminarlos, previa confirmación Cuadro 6.7: CU.A07 - Gestionar Idiomas CU.A08 - Cambiar Mi Clave Descripción Cambio de la clave del usuario administrador que ha usado para entrar a su aplicación Secuencia normal Pasos Acción 1 El sistema muestra un diálogo para escribir la nueva clave dos veces para evitar confusiones 2 El administrador introduce su clave por duplicado 3 El sistema valida la clave introducida 4 El sistema almacena la clave del usuario administrador para futuras entradas al sistema Excepciones Paso Acción 2 El administrador puede solicitar generar una clave aleatoria de forma automática por el sistema 3 Si al validar la clave por duplicado se han especificado claves distintas, o directamente no se especifica, la operación se cancela Cuadro 6.8: CU.A08 - Cambiar Mi Clave Página 78 Capítulo 6. Descripción de Casos de Uso CU.A09 - Cambiar Idioma Descripción Cambio del idioma en el que se está presentando la aplicación, afectando a todos los mensajes de la misma Secuencia normal Pasos Acción 1 El sistema muestra un selector de los idiomas que soporta su aplicación 2 El administrador selecciona uno de los idiomas 3 El sistema cambia el idioma actual al elegido por el administrador redireccionando a la primera página que ve según entra a la aplicación Cuadro 6.9: CU.A09 - Cambiar Idioma Página 79 Virtual Museum sobre plataforma Java EE 6.3. Casos de Uso para el Director de museo Figura 6.2: Diagrama de Casos de Uso para el responsable del museo Página 80 Capítulo 6. Descripción de Casos de Uso CU.D01 - Actualizar información Museo Descripción Acceso a la información interna del museo, que se usó para crear el museo virtual. Secuencia normal Pasos Acción 1 El sistema muestra la información actual del museo permitiendo al usuario la modificación de cualquiera de sus campos 2 El responsable del museo actualiza la información 3 El sistema guarda la información editada, teniendo en cuenta que, como se incluye el propio nombre del museo, hará falta recargar el nombre mostrado Cuadro 6.10: CU.D01 - Actualizar información Museo CU.D02 - Publicar Museo Descripción Publicación/despublicación del museo para hacerlo visible vía web al visitante Secuencia normal Pasos Acción 1 El sistema muestra el estado actual del museo: publicado o no publicado (”despublicado”) 2 El responsable del museo elige si desea publicar o no el museo 3 El sistema actualiza en consonancia el estado del museo Cuadro 6.11: CU.D02 - Publicar Museo CU.D03 - Generar Vista Móvil Descripción Generación de una vista para dispositivos móviles a partir de un recorrido existente y uno de los idiomas del museo Secuencia normal Pasos Acción 1 El sistema muestra la lista de recorridos para el móvil existentes y la lista de idiomas en las que está configurado el museo virtual. Además, muestra la lista de vistas móviles que se han generado previamente 2 El responsable del museo elige el recorrido y el idioma para los que desea generar la vista móvil 3 El sistema genera la vista como un archivo jar, actualizando su fecha de generación y su ruta 4 El sistema le informa al responsable del museo de la generación de la vista permitiendo su descarga de la misma forma que para las vistas ya generadas anteriormente Cuadro 6.12: CU.D03 - Generar Vista Móvil Página 81 Virtual Museum sobre plataforma Java EE CU.D04 - Configurar Idiomas Descripción Configuración del idioma principal y complementarios para los que que estará disponible el museo virtual generado y se editarán sus contenidos Secuencia normal Pasos Acción 1 El sistema muestra los idiomas configurados actualmente, resaltando el idioma principal o predeterminado 2 El sistema muestra la lista de idiomas disponibles globalmente 3 El responsable del museo selecciona un idioma de entre los disponibles para añadirlo a su museo 4 El sistema guarda el nuevo idioma añadido, mostrándolo en la lista de idiomas configurados actualmente como uno complementario Excepciones Paso Acción 3 El responsable del museo cambia el idioma predeterminado a otro de los configurados actualmente 3 El responsable del museo escoge uno o más idiomas para eliminarlos, previa confirmación. El idioma predeterminado no se puede eliminar 4 Si el museo todavía no tenía configurado ningún idioma, el idioma recién añadido aparece como idioma predeterminado Cuadro 6.13: CU.D04 - Configurar Idiomas CU.D05 - Dejar Comentarios Descripción Brinda una vía de comunicación entre el visitante y el responsable del museo para transmitirle comentarios acerca del museo virtual Secuencia normal Pasos Acción 1 El sistema muestra los comentarios enviados con anterioridad 2 El visitante aporta una opinión o sugerencia sobre aquellos aspectos y servicios del museo virtual que podría contemplar 3 El sistema guarda el comentario para que lo pueda consultar posteriormente el responsable del museo Cuadro 6.14: CU.D05 - Dejar Comentarios CU.D06 - Seleccionar Idioma Descripción Cambio del idioma en el que se está presentando la aplicación, afectando a todos los mensajes de la misma Secuencia normal Pasos Acción 1 El sistema muestra un selector de los idiomas que soporta su aplicación 2 El responsable del museo selecciona uno de los idiomas 3 El sistema cambia el idioma actual al elegido por el responsable del museo redireccionando a la primera página que ve según entra a la aplicación Cuadro 6.15: CU.D06 - Seleccionar Idioma CU.D07 - Gestionar Multimedia Descripción Reúne la funcionalidad que permite al responsable del museo administrar sus objetos multimedia Secuencia normal Pasos Acción 1 El sistema muestra la lista de objetos multimedia pertenecientes al responsable del museo. Aquellos ficheros que presenten el tipo MIME css se pueden editar, y el resto únicamente visualizar 2 Si el responsable del museo desea subir un archivo nuevo se realiza el caso de uso CU.D08 3 Si el responsable del museo desea publicar una imagen existente en Picasa se realiza el caso de uso CU.D17 4 Si el responsable del museo desea publicar una imagen existente en Flickr se realiza el caso de uso CU.D18 5 El responsable del museo puede escoger uno o más archivos para eliminarlos, previa confirmación. Cuadro 6.16: CU.D07 - Gestionar Multimedia Página 82 Capítulo 6. Descripción de Casos de Uso CU.D08 - Subir archivo Descripción Permite subir nuevos archivos al gestor multimedia Secuencia normal Pasos Acción 1 El sistema muestra un diálogo de examinar archivo para seleccionar el objeto multimedia a subir de su árbol de directorios local 2 El responsable del museo selecciona un archivo 3 El sistema sube el archivo al servidor 4 El sistema procesa el archivo registrándolo como un nuevo objeto multimedia analizando su tipo MIME para permitir diferentes operaciones con él posteriormente Cuadro 6.17: CU.D08 - Subir archivo CU.D09 - Fijar página inicial Descripción Fija la página inicial que se mostrará por defecto al comenzar la visita a un museo virtual Secuencia normal Pasos Acción 1 El sistema muestra la lista de contenidos existentes para el museo virtual 2 El responsable del museo selecciona uno de los contenidos para que sea el primero que se muestra cuando un visitante entra a un museo 3 El sistema actualiza la selección como contenido para la página inicial Secuencia normal Pasos Acción 1 Si el museo todavía no tiene contenidos, el sistema informe del hecho y no permite fijar nada Cuadro 6.18: CU.D09 - Fijar página inicial CU.D10 - Configurar Menús Descripción Reúne la funcionalidad de la configuración de menús que se visualizarán en el sitio web para el museo virtual generado Secuencia normal Pasos Acción 1 El sistema muestra la lista de menús configurados previamente para el museo virtual 2 Si el responsable del museo desea añadir un menú nuevo, se realiza el caso de uso CU.D11 3 El responsable del museo escoge un menú existente para ver sus detalles 4 El sistema muestra la lista de items para el menú seleccionado, y los detalles del menú permitiendo su modificación 5 Si el responsable del museo desea añadir un item nuevo al menú, se realiza el caso de uso CU.D12 6 El responsable del museo puede reordenar los items para que el sitio web del museo los muestre en el orden especificado 7 El sistema actualiza toda la información del menú y vuelve a la lista de menús configurados Secuencia normal Pasos Acción 2 El responsable del museo escoge uno o más menús para eliminarlos, previa confirmación 4 El responsable del museo escoge uno o más items del menú para eliminarlos, previa confirmación Cuadro 6.19: CU.D10 - Configurar Menús CU.D11 - Añadir Menú Descripción Permite añadir un menú nuevo Secuencia normal Pasos Acción 1 El responsable del museo indica el título del menú a añadir, así como su estilo CSS y el título del menú para hacerlo corresponder con el de la plantilla 2 El sistema almacena el menú Cuadro 6.20: CU.D11 - Añadir Menú Página 83 Virtual Museum sobre plataforma Java EE CU.D12 - Añadir Item Descripción Permite añadir un nuevo item a un menú existente Secuencia normal Pasos Acción 1 El sistema muestra la lista de todos los contenidos y las categorías para el museo virtual 1 El responsable del museo selecciona o un contenido o una de las categorías para añadirlo como un nuevo item al menú 2 El sistema almacena el nuevo item, ocupando la última posición dentro del menú Cuadro 6.21: CU.D12 - Añadir Item CU.D13 - Seleccionar Plantilla Descripción Permite al responsable del museo escoger una plantilla para personalizar la apariencia del sitio web para el museo virtual generado Secuencia normal Pasos Acción 1 El sistema muestra la lista de todas las plantillas disponibles globalmente, así como la plantilla que tiene el museo actualmente 1 El responsable del museo selecciona una de las plantillas para cambiarla por la actual 2 El sistema almacena la plantilla seleccionada, de forma que las posteriores visitas al sitio web del museo virtual generado se mostrarán usando dicha plantilla Cuadro 6.22: CU.D13 - Seleccionar Plantilla CU.D14 - Configurar Dublin Core Descripción Permite configurar las opciones relacionadas con Dublin Core: incrustar metadatos DC en el sitio web para el museo virtual generado y publicar servicio web de comunicación con otras aplicaciones Secuencia normal Pasos Acción 1 El sistema muestra si están activos el servicio de publicación del servicio web y la inclusión de metadatos Dublin Core en el sitio web para el museo virtual 2 El responsable del museo activa o desactiva dichos servicios a voluntad 3 El sistema actualiza la nueva configuración Cuadro 6.23: CU.D14 - Configurar Dublin Core CU.D15 - Configurar RSS Descripción Permite configurar la activación del servicio de publicación de feeds RSS con los contenidos actualizados durante el último mes Secuencia normal Pasos Acción 1 El sistema muestra si está activo o no el servicio de publicación de feeds RSS para el museo virtual 2 El sistema muestra una vista previa con la lista de los contenidos que se van a incluir en el feed, a saber, contenidos que se han actualizado durante el último mes 3 El responsable del museo activa o desactiva dicho servicio a voluntad 4 El sistema actualiza la nueva configuración Cuadro 6.24: CU.D15 - Configurar RSS CU.D16 - Gestionar Contenidos Descripción Reúne la funcionalidad para dar de alta, eliminar y modificar los contenidos del museo virtual Secuencia normal Pasos Acción 1 El sistema ofrece una lista de todos los contenidos 2 El administrador elige un contenido para editar su título y texto, y los campos adicionales de cada tipo de contenido, permitiendo la modificación de los campos 3 Al guardar se vuelve al listado de contenidos Excepciones Paso Acción 2 Si el museo virtual está configurado en varios idiomas, se presenta el par título/texto para cada idioma 2 El responsable del museo escoge uno o más contenidos para eliminarlos, previa confirmación Cuadro 6.25: CU.D16 - Gestionar Contenidos Página 84 Capítulo 6. Descripción de Casos de Uso CU.D17 - Publicar Picasa Descripción Permite subir imágenes propias el museo virtual a Picasa Secuencia normal Pasos Acción 1 El sistema muestra desde el listado de archivos multimedia un enlace para publicar imágenes a Picasa 2 El responsable del museo selecciona una imagen para publicar 3 El sistema se conecta con Picasa para enviar la imagen 4 Como la imágenes también se podrían eliminar desde Picasa, se puede refrescar el estado de imágenes para comprobar las imágenes que se tienen actualmente publicadas en Picasa Cuadro 6.26: CU.D17 - Publicar Picasa CU.D18 - Publicar Flickr Descripción Permite subir imágenes propias el museo virtual a Flickr Secuencia normal Pasos Acción 1 El sistema muestra desde el listado de archivos multimedia un enlace para publicar imágenes a Flickr 2 El responsable del museo selecciona una imagen para publicar 3 El sistema envía un correo a Flickr adjuntando la imagen que se desea publicar 4 El responsable del museo puede refrescar el estado de imágenes enviadas a Flickr, para verificar si ya está subida 5 Como la imágenes también se podrían eliminar desde Flickr, se puede refrescar el estado de imágenes para comprobar las imágenes que se tienen actualmente publicadas en Flickr Cuadro 6.27: CU.D18 - Publicar Flickr Página 85 Virtual Museum sobre plataforma Java EE CU.D19 - Visualizar GoogleMaps Descripción Permite visualizar la información geográfica del museo especificada mediante GoogleMaps Secuencia normal Pasos Acción 1 El sistema ofrece un formulario para completar la información geográfica asociada al museo virtual 2 El responsable del museo rellena dicha información (longitud, latitud, altura) 3 El sistema la actualiza y ofrece una visualización de dicha posición mediante GoogleMaps (bien como Javascript o como una imagen simple) Cuadro 6.28: CU.D19 - Visualizar GoogleMaps Página 86 Capítulo 6. Descripción de Casos de Uso 6.4. Casos de Uso para el Visitante El apartado de casos de uso para el visitante se plantea de forma genérica para las funcionalidades de la vista del museo virtual generado ya que la interacción estará condicionada por el diseño de la plantilla en el caso de la vista web y el esquema de pantallas de la aplicación base de la vista móvil. Figura 6.3: Diagrama de Casos de Uso para el visitante Página 87 Virtual Museum sobre plataforma Java EE 7.3. Realización de casos de uso-análisis Las realizaciones de casos de uso-análisis se presentan en forma de diagramas de interacción, y más concretamente como diagramas de colaboración. Para su visualización puede dirigirse al CD anexo y abrir el modelo de análisis dentro del directorio ”together”. Página 94 Capítulo 8 DESCRIPCIÓN DE LA ARQUITECTURA He hecho esta carta más larga de lo usual porque no tengo tiempo para hacer una más corta. Blaise Pascal Índice del Capítulo 8.1. Introducción .................................... 96 8.2. ArquitecturaJavaEE................................ 96 8.3. Patrón MVC (Modelo-Vista-Controlador) . . . . . . . . . . . . . . . . . . . . . 101 8.4. Arquitectura empleada en Virtual Museum . . . . . . . . . . . . . . . . . . . . . 102 8.5. CapadeCliente...................................103 8.6. Capa de Vista de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.1. HTML, CSS y Javascript . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.6.2. Internacionalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.6.3. StrutsTiles ................................105 8.6.4. Velocity..................................105 8.7. Capa de Lógica de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . 106 8.7.1. Framework Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 8.7.2. Framework Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . 107 8.8. Capa de Lógica de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.8.1. Framework Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.9. CapadeServicios..................................114 8.10.Capadeintegración.................................115 8.10.1. Hibernate .................................115 8.11. Capa de sistemas de información . . . . . . . . . . . . . . . . . . . . . . . . . . 116 8.12. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 95 Virtual Museum sobre plataforma Java EE 8.1. Introducción A grandes rasgos, uno de los objetivos del diseño es adquirir una comprensión en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, tecnologías de distribución, etc. En el diseño se modela el sistema y se encuentra su forma y arquitectura para que soporte todos los requisitos. Entre el conjunto de requisitos obtenidos se incluyen las siguientes restricciones de diseño de las que parte el proyecto: Desarrollo del sistema siguiendo la plataforma Java EE, que sea escalable en cuanto a tecnologías empleadas. Las aplicaciones fruto del desarrollo son web, accesibles vía internet en general. Uso de soluciones software de libre distribución. A lo largo de este capítulo se presentarán las distintas tecnologías elegidas para el desarrollo del sistema y cómo se relacionan para la elaboración de la arquitectura del sistema. Una vez expuesta la arquitectura compuesta por los distintos subsistemas, interfaces y dependencias, en el siguiente capítulo se describirá el modelo de clases de diseño que se utilizará como punto de partida fundamental para la fase de implementación. 8.2. Arquitectura Java EE Java 2 Platform Enterprise Edition o Java EE es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java con arquitectura distribuida de n niveles, basándose ampliamente en componentes de software modulares ejecutándose típicamente sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación, similar a otras especificaciones del JCP (Java Community Process); Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; no obstante sin un estándar de ISO o ECMA. La plataforma Java EE se podría ver como la agregación de un conjunto de especificaciones, un test de compatibilidad (Java EE Compatibility Test Suite - CTS), la implementación de referencia y un conjunto de guías de desarrollo y de prácticas aconsejadas denominadas Java EE BluePrints. En cuanto a las tecnologías que soportan este desarrollo basado en varias capas podemos hacer una división en tres categorias: tecnologías de componentes, servicios y comunición. Las tecnologías de componentes son aquéllas usadas por los desarrolladores para crear las partes esenciales de la aplicación, a saber, la interfaz de usuario y la lógica de negocio. Un componente es una unidad software a nivel de la aplicación. Además de los componentes JavaBeans que son parte de la plataforma J2SE, la plataforma Java EE soporte otros tipos de componentes: applets, clientes de aplicación, EJBs, componentes web y adaptadores de recursos. Todos los componentes Java EE necesitan soporte en tiempo de ejecución de una entidad a nivel de sistema llamada contenedor. Un servidor de Página 96 Capítulo 8. Descripción de la Arquitectura aplicaciones Java EE proporciona contenedores para EJBs y para componentes web. Los applets y los clientes de aplicación se ejecutan del lado del cliente, mientras que los EJBs, los componentes web y adaptadores de recursos se ejecutan del lado del servidor. Excepto los adaptadores de recursos, los desarrolladores, frecuentemente, diseñan e implementan los componentes de la aplicación Java EE. Por su parte, los proveedores de los sistemas de información son los que normalmente nos darán los adaptores de recursos. Los contenedores son entornos de ejecución estandarizados que proveen servicios especificos a los componentes. Los componentes de una aplicación esperarán por tanto que estos servicios estén disponibles en cualquer plataforma Java EE de cualquier distribución. Por ejemplo, todos los contenedores web Java EE proveen soporte en tiempo de ejecución para responder a una petición de cliente (request), realizar algún tipo de procesamiento en tiempo de la petición (como la invocación de páginas JSP o de algún servlet), y devolver los resultados al cliente. Además, brindan APIs para dar soporte a la gestión de sesiones. Todos los contenedores EJB dan soporte automático para la gestión de transacciones y el ciclo de vida de los EJBs, así como la búsqueda de beans. Los contenedores también proveen de acceso estandarizado a los sistemas de información; por ejemplo, la API JDBC da acceso a bases de datos relacionales. Los componentes web están alojados en un contenedor web. Dicho contenedor tiene entre sus funciones dar los servicios de red (soportando el protocolo HTTP y a veces HTTPS) a través de los cuales las peticiones y respuestas son enviadas, decodifica las peticiones y formatea las respuestas. Un contenedor EJB por su parte, suministra servicios de transacciones, persistencia y acceso a los servicios Java EE y APIs de comunicación. En la figura 8.1 puede verse la organización y relaciones entre componentes y contenedores. Adicionalmente, los contenedores facilitan un mecanismo para elegir el comportamiento de la aplicación en tiempo de ensamblado o despliegue. A través del uso de descriptores de despliegue (ficheros XML que especifican el comportamiento del componente o contenedor), se pueden configurar los componentes en función del entorno del contenedor específico en el que se van a desplegar, más que hacerlo en el propio código del componente. Este comportamiento configurable abarca características entre las que se incluyen seguridad, control de transacciones y otras responsabilidades de gestión. Dentro de las prácticas recomendadas o Java EE BluePrints, la plataforma Java EE define un modelo de desarrollo encaminado a la creación de aplicaciones basadas en n capas. Las capas se suelen organizar para que unas se apoyen en otras. Esta separación por capas en un sistema presenta ventajas muy importantes. La primera de ellas es que existe poco acoplamiento entre las mismas, de modo que es mucho más fácil hacer modificaciones en ellas sin que interfieran con las demás. Todo esto redunda en la obtención de mejoras en cuanto a mantenibilidad, escalabilidad y reutilización de componentes. Otra de las ventajas que se obtienen es la posibilidad de intercambio de los componentes usados en las distintas capas, sin que ello interfiera al resto de las capas. Las prácticas recomendadas de Java EE proponen una arquitectura basada en una capa de interfaz de usuario, una o más capas intermedias que proveen de servicios al usuario y lógica de negocio para la aplicación, y una capa de acceso a los sistemas de información. La figura 8.2 muestra lo que sería una posible arquitectura Java EE. El modelo que aparece en la figura está dividido en varias capas, con una separación clara entre presentación, lógica de negocio y sistemas de información. En este caso además, podemos ver como se trata de un modelo mixto. En la parte de arriba tenemos que se recorre un camino por una estructura de tres capas (aplicación - lógica Página 97 Virtual Museum sobre plataforma Java EE Figura 8.1: Componentes y contenedores en la plataforma Java EE de negocio - sistemas deinformación), mientras que por el segundo camino recorremos una estructura de cuatro capas (aplicación - lógica de presentación - lógica de negocio - sistemas de información). Por otra parte, la capa Java EE de cliente soporta diversos tipos de clientes que interactúan con los componentes del lado del servidor. Entre ellos podemos encontrar los navegadores web (que usan páginas HTML estáticas, páginas HTML generadas dinámicamente por JSPs, o Java applets), aplicaciones Java de escritorio (standalone), clientes ricos basados en Java Web Start, o clientes wireless basados en MIDP (Mobile Information Device Profile) que dan un entorno J2ME completo para los dispositivos móviles. El modelo de la figura 8.2 es sólo un ejemplo, en muchos casos hasta puede que sea demasiado complejo y nos conformemos con utilizar únicamente la capa de Servlets/JSP para acceder a nuestros sistemas de información, en otros casos prescindiremos de la capa web, y en otros utilizaremos servicios web para acceder a la lógica de negocio, o crearemos capas de persistencia intermedia con patrones de acceso a datos. Las combinaciones son prácticamente ilimitadas. Las espcificaciones y tecnologías Java EE animan la diversidad arquitectónica haciendo pocas suposiciones acerca de los detalles de las implementaciones de las APIs. Las decisiones y elecciones a nivel de aplicación son, en última instancia, un compromiso entre la complejidad y riqueza funcional. Un escenario típico, donde aparecen todas las capas, es el escenario desde un navegador web. La generación de contenidos dinámicos se realiza normalmente en páginas JSP. La capa de EJBs nos Página 98 Capítulo 8. Descripción de la Arquitectura Figura 8.2: Esquema de modelo mixto de 3 y 4 capas permite desacoplar el acceso a datos EIS de la interacción final con el usuario que se produce en las páginas HTML y JSP, como muestra la figura 8.3. Figura 8.3: Escenario desde un navegador La plataforma Java EE no obliga a usar en un sistema todas las capas. Lo esencial es escoger el mecanismo adecuado para cada problema. En este sentido, en ocasiones no existe la complejidad como para requerir una capa EJB como el de la figura 8.3. Se denomina escenario centrado en la capa web (figura 8.4) porque el contenedor web es el que realiza gran parte del trabajo del sistema. En una aplicación centrada en la capa Web sigue existiendo, aunque sea ligeramente, un modelo, que contiene entidades y reglas de negocio; es decir, el que no sean necesarios los EJB no implica no modularizar, mezclarlo todo y eliminar los componentes del modelo. Aunque no entraremos a describir cada capa de una arquitectura Java EE en general, sí que nos vamos a detener en la capa web por su importancia en el presente proyecto. En esta capa el contenedor web proporciona servicios relacionados con las peticiones web, como muestra la figura 8.5. La plataforma Java EE se ejecuta encima de la plataforma J2SE, que a su vez viene soportada por el Página 99 Virtual Museum sobre plataforma Java EE Figura 8.4: Escenario basado en web sistema operativo. El código específico de la aplicación suele escribirse en términos de la capa de algún framework, que suministrará funcionalidades generales tales como despachar peticiones, invocar métodos del modelo o seleccionar y componer vistas, por ejemplo. Figura 8.5: Estructura de la capa web Dentro de las mejores prácticas recomendadas en las BluePrints, se nos dice que optemos por un framework existente (y probado), mejor que diseñar y construir el nuestro directamente. Entre las ventajas que supone este enfoque tenemos que: desacopla la presentación y su lógica, separa los roles de los desarrolladores, da un un punto central de control, facilita las pruebas unitarias y su mantenimiento, suele reducir los tiempos y costes, simplifica algunas tareas (como la internacionalización, validación, etc), puede ser compatible con otras herramientas lo que facilita su integración, etc. Página 100 Capítulo 8. Descripción de la Arquitectura 8.3. Patrón MVC (Modelo-Vista-Controlador) Además de proponer usar un framework existente, las BluePrints también recomiendan usar el patrón de diseño MVC (Modelo-Vista-Controlador) en aplicaciones interactivas. El seguimiento del paradigma MVC facilita la construcción y mantenimiento de aplicaciones web, y permitirá el uso de determinados componentes de una forma sencilla y flexible. El patrón MVC organiza la aplicación en tres módulos bien separados: El modelo de la aplicación con su representación del dominio y lógica de negocio, Las vistas que procuran la presentación de datos y la captura de datos por parte del usuario, Y el controlador que despacha las peticiones y mantiene el flujo del control. Figura 8.6: Patrón MVC: ciclo de servicio en la capa web A partir de estos módulos el flujo que sigue a cualquier petición, ilustrado en la figura 8.6, suele ser el siguiente: El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace) El controlador recibe (por parte de los objetos de la vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos (bien a través del modelo o dejando que el controlador envíe los datos Página 101 Virtual Museum sobre plataforma Java EE del modelo a la vista) para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. 8.4. Arquitectura empleada en Virtual Museum A lo largo de las sucesivas iteraciones del desarrollo del proyecto, la arquitectura se ha ido evolucionando en cuanto al conjunto de componentes usados y sus relaciones. Haber escogido la plataforma Java EE frente a otras nos ha traído diversas ventajas: Soporte de múltiples sistemas operativos: Al ser una plataforma basada en el lenguaje Java, es posible desarrollar arquitecturas basadas en Java EE utilizando cualquier sistema operativo donde se pueda ejecutar una máquina virtual Java. Organismo de control: La plataforma Java EE está contolada por el JCP, un organismo formado por más de 500 empresas. Entre las empresas que lo forman estan todas las más importantes del mundo informático (SUN, IBM, Oracle, SAP, HP, AOL, etc.) lo que garantiza la evolución de la misma. Madurez: Creada en el año 1997 como respuesta a la tecnología MTS de Microsoft, Java EE tiene ya más de diez años de vida y una gran cantidad de proyectos importantes a sus espaldas. Soluciones libres: En la plataforma J2EE es posible crear arquitecturas completas basadas única y exclusivamente en productos de software libre. No sólo eso, sino que los arquitectos normalmentedisponen de variassoluciones libres para cadaunade las partes de suarquitectura. La arquitectura general, resultante de varios refinamientos y evoluciones, planteada para el desarrollo del proyecto se puede ver como un sistema en seis capas, reflejada en la figura 8.7, a saber: Capa de cliente: representa el interfaz de usuario que maneja el cliente. Capa de presentación web (vista y acciones): representa el conjunto de componentes que generan la información que se representará en el interfaz de usuario del cliente. Capa de servicios: provee los mecanismos necesarios para permitir la comunicación de Virtual Museum con otros sistemas externos mediante servicios web. Capa de lógica de negocio: contiene nuestros componentes de negocio reutilizables. Capa de acceso a datos o integración: aquí se encuentran componentes que nos permiten hacer más transparente el acceso a la capa de sistemas de información. Capa de sistemas de información: esta capa engloba a nuestros sistemas de información, tanto desde un punto de vista relacional (dada la naturaleza de la base de datos), como orientado a objetos. Página 102 Capítulo 8. Descripción de la Arquitectura Figura 8.7: Arquitectura de capas en Virtual Museum A continuación veremos más en detalle las funciones de cada una de las capas y las decisiones de diseño arquitectónico que se han adoptado. 8.5. Capa de Cliente Nuestro sistema se va a componer de tres aplicaciones desde el punto de vista web, una por rol del sistema. Las aplicaciones para el responsable del museo y el administrador son web por lo que usarán un navegador y su interacción con el sistema empezará a partir de la capa de vista web. El sistema desde el punto del visitante cuenta con tres interfaces bien diferenciadas: Público general: la forma habitual de acceso sería mediante navegador ya que el museo virtual generado crea un sitio web. Aplicaciones externas: se ofrece el acceso a recursos a aplicaciones de terceros mediante servicios web por lo que la comunicación con el sistema general comenzará por la capa de servicios web. Dispositivos móviles: el responsable del museo puede generar vistas personalizadas para el visitante en forma de aplicación Java standalone para dispositivos móviles. Página 103 Virtual Museum sobre plataforma Java EE sistema (como la auditoría o la gestión de transacciones). Así, los objetos de la aplicaciones hacen lo que se suponen que deben hacer (la lógica de negocio para la que han sido diseñados) y nada más. Contenedor: Spring es un contenedor en el sentido de que contiene y gestiona el ciclo de vida y la configuración de los objetos de la aplicación. A pesar de ello, no debe confundirse con los contenedores de EJB’s que suelen ser mucho más pesados en términos de tamaño y carga. Framework: Una aplicación Spring se puede ir configurando y construyendo a partir de componentes más simples. En Spring, los objetos se pueden componer de una forma declarativa, típicamente a través de un archivo XML. Además de esto Spring ofrece soporte para una variedad de subframeworks y conexión a otros frameworks que amplían la potencia de Spring. La arquitectura de Spring se compone de siete módulos bien definidos. Aunque estos siete módulos en conjunto nos ofrece lo que necesitamos para desarrollar aplicaciones empresariales, no es necesario basar nuestra aplicación completamente en los siete módulos de Spring. Como se puede ver en la figura todos los módulos Spring se apoyan en el núcleo contenedor. Figura 8.10: Framework Spring Núcleo contenedor: El contenedor es la parte esencial de Spring; define cómo se crean, configuran y gestionan los beans; implícitamente, se usan las clases de este módulo cuando se está configurando la aplicación, como por ejemplo BeanFactory, el corazón de un sistema Spring. Un BeanFactory es una implementación del patrón factory que aplica IoC para separar la configuración de la aplicación de las dependencias generadas entre los distintos bloques de código. Contexto de Aplicación: El BeanFactory del núcleo convierte a Spring en un contenedor, pero el módulo de Contexto es el que le hace ser un framework. Este módulo extiende el concepto de un BeanFactory añadiendo soporte para la internacionalización (i18n), eventos en el ciclo de vida de la aplicación, y validación. Además, ofrece servicios como email, JNDI, integración con EJB, remoting, etc. y en otro ámbito incluye soporte para la integración con frameworks de plantillas como FreeMarker o Velocity. Página 110 Capítulo 8. Descripción de la Arquitectura Programación orientada a Aspectos (AOP): Spring ofrece un amplio soporte para la programación orientada a aspectos. Para asegurar la interoperabilidad entre Spring y otras plataformas AOP, este módulo se basa en la API definida por AOP Alliance (proyecto de código abierto que promueve la adopción de AOP y la compatibilidad entre las diversas plataformas AOP). Este módulo también introduce la programación de metadatos, mediante la cual se pueden añadir anotaciones a nuestro código fuente que indiquen a Spring cómo y dónde aplicar aspectos. Abstracción JDBC y DAO: El trabajo con JDBC suele resultar a menudo en un conjunto de líneas de código que se repiten a lo largo de toda la aplicación (abrir conexión, sentencia, resultado, cerrar conexión). Spring abstrae este conjunto de líneas repetitivo para que el código de acceso a base de datos sea más limpio y simple. Además, envuelve los errores de los SGBD en una capa de excepciones que procuran dar más significado que los propios SGBD. Por otra parte, este módulo usa el de AOP para proveer servicios de gestión de transacciones. Mapeador Objeto/Relacional (ORM): Este módulo de Spring no implementa su propia solución ORM, sino que brinda atajos para varios ORMs populares entre los se incluyen Hibernate, JDO o iBatis. La gestión de transacciones de Spring soporta cada una de estas soluciones ORM así como JDBC. Contexto Web: El módulo de contexto web se apoya en el módulo de Contexto de la aplicación, dando un contexto apropiado para las aplicaciones web. Además, soporta diversas tareas orientadas a web, como peticiones para transferencias de archivos (multipart requests), enlaces de los parámetros pasados por Request con objetos de negocio, y más específicamente integración con Struts. Plataforma MVC: Aunque se puede integrar fácilmente con otros frameworks MVC como Struts, Spring trae consigo su propia solución, que usa IoC para dar una separación entre la lógica del controlador y los objetos de negocio. Inversión de control De entre las características que posee Spring la inversión de control es particularmente importante dentro de este contenedor. Ya se ha mencionado la conveniencia de evitar que el código de la aplicación dependa del propio contenedor. Sin embargo, lograrlo no es una tarea trivial a priori: la mayor parte de los objetos tienen dependecias (objetos de negocio, acceso a datos, recursos, etc), que deben ser resueltas para su ejecución. Para satisfacer las dependencias de los objetos sin introducir nuevas con el contenedor, Spring incorpora una solución denominada inversión de control. La inversión de control (IoC - Inversion of Control) es un concepto junto a unas técnicas de programación en las que el flujo de ejecución de un programa se invierte respecto a los métodos de programación tradicionales, en los que la interacción se expresa de forma imperativa haciendo llamadas a procedimientos o funciones. Tradicionalmente el programador especifica la secuencia de decisiones y procedimientos que pueden darse durante el ciclo de vida de un programa mediante llamadas a funciones. En su lugar, en la inversión de control se especifican respuestas deseadas a sucesos o solicitudes de datos concretas, dejando que algún tipo de entidad o arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y para el conjunto de sucesos que tengan que ocurrir. Generalmente, Página 111 Virtual Museum sobre plataforma Java EE la inversión de control es un concepto importante en los frameworks y a veces se puede entender mejor a través del principio de Hollywood: ”No nos llames, ya te llamaremos nosotros a ti”. El concepto de la IoC es un término bastante amplio y que puede ser implementado de diferentes formas; principalmente hay dos tipos: Búsqueda de dependencias: el contenedor provee métodos a los componentes y un contexto de búsqueda. Éste es el enfoque dado por EJB y Apache Avalon. Deja la responsabilidad a cada componente de usar la API del contenedor para buscar sus recursos y colaboraciones. Aquí la inversión de control está limitada al contenedor y los métodos que la aplicación puede invocar para obtener sus dependencias. Inyección de dependencias:los componentes no buscan, y en vez de ello, proveen métodos Java planos para permitir que el contenedor resuelva por ellos sus dependencias. En ese caso, es el contenedor el responsable de conectar los componentes, resolviendo los objetos y pasándolos a las propiedades del JavaBean o constructores. Cuando se usan las propiedades de un JavaBean se habla de inyección de setter, y cuando se emplean los argumentos del propio constructor, se habla de inyección de constructor. En el caso de Spring la forma de inversión de control usada es la inyección de dependencias a través de setters. Este tipo de inversión presenta algunas ventajas al eliminar el código de búsqueda de la aplicación, evitar la dependencia con APIs del contenedor, y que no se necesita implementar interfaces especiales. Veamos un ejemplo: public class ContenidoManagerImp implements ContenidoManager { private MuseoManager museoManager; public void setMuseoManager(MuseoManager museoManager) {this.museoManager = museoManager; } private ContenidoDAO contenidoDAO; public void setContenidoDAO(ContenidoDAO dao) {this.contenidoDAO = dao; } [...] } Los métodos setter son invocados inmediatamente después de que el objeto sea instanciado por el contenedor, antes de que trate cualquier método de negocio, evitando problemas de carrera relacionados con estas propiedades. De esta forma, el objeto ContenidoManager tendrá disponibles sus propiedades museoManager ycontenidoDAO sin necesidad de escribir el código relativo a la búsqueda de estos objetos. Además, el aspecto que tiene esta porción de la clase es como un JavaBean ordinario, y no presenta llamadas específicas a APIs de Spring. Desde el punto de vista de Spring, la configuración y conexión de los objetos del sistema suele expresarse en términos de XML, aunque también es posible implementar un bean propio que lea las definiciones de configuración. El formato puede considerarse bastante intuitivo, como muestra la siguiente porción del archivo de configuración: <bean id="contenidoManagerTarget" class="com.museum4j.negocio.ContenidoManagerImp"> Página 112 Capítulo 8. Descripción de la Arquitectura <property name="museoManager"><ref local="museoManager"/></property> <property name="contenidoDAO"><ref local="contenidoDAO"/></property> </bean> En el ejemplo, nótese el uso del elemento property para fijar la propiedad correspondiente del JavaBean, y el elemento ref para resolver las dependencias a otros beans. Así, los beans museoManager ycontenidoDAO estarán definidos de una forma similar en el mismo contenedor o incluso en otro relacionado. Programación orientada a aspectos Mientras que la inversión de control hace posible desacoplar componentes evitando dependencias, la programación orientada a aspectos permite capturar la funcionalidad que se usa a lo largo de la aplicación en los distintos componentes. La programación orientada a aspectos se suele definir como una técnica de programación que promueve la separación de intereses dentro de un sistema software. Los sistemas están compuestos por diversos componentes en los que cada uno se hace cargo de una parte específica de la funcionalidad global. A pesar de ello, a menudo estos componentes también conllevan alguna responsabilidad más allá de sus funciones básicas, como servicios de logging, gestión de transacciones o seguridad. Estos servicios del sistema presentes a lo largo de los distintos componentes introducen dos niveles de complejidad al código: El código que implementa estas funcionalidades está duplicado por múltiples componentes. Incluso si se abstrae la funcionalidad en un módulo separado para que el impacto sea una sóla llamada en el componente, dicha llamada sigue estando duplicada por múltiples puntos en el código. Los componentes se cubren con código que no se enmarca dentro del núcleo de su funcionalidad. La figura 8.11 ilustra esta complejidad añadida: los objetos de la capa de lógica de negocio están envueltos íntimamente con el servicio de gestión de transacciones. No sólo cada objeto ”sabe” que sus transacciones están siendo gestionadas sino que cada objeto es responsable de llevar a cabo estas funciones por él mismo. La programación orientada a aspectos permite modularizar estos servicios y aplicarlos a los componentes que deban afectar de forma declarativa. Esto produce una mayor cohesión entre componentes y que cada uno de ellos se centre en su propia funcionalidad, ignorando los servicios del sistema en los que está envuelto. Se puede pensar en los aspectos como si fueran capas que cubren los componentes de la aplicación, de forma que pueden ser aplicadas de una forma flexible sin que el núcleo de la aplicación sepa de su existencia. Se puede ver un ejemplo de esta característica en el siguiente fragmento de código. En él se muestra cómo la aplicación tiene un método generarMuseoMovil que realizará diversas operaciones. Sería interesante que si, por la razón que sea, se produce una excepción toda la operación se rechazara globalmente para que que no se quede en un estado incoherente. Es decir, sería deseable que la operación se ejecutara atómicamente como si fuera una transacción. En Spring, indicar este aspecto se puede hacer de forma declarativa sin tener que incluir en el objeto de negocio código adicional. Página 113 Virtual Museum sobre plataforma Java EE Figura 8.11: Gestión de transacciones <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory"><ref local="sessionFactory"/></property> </bean> <bean id="contenidoManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"><ref local="transactionManager"/></property> <property name="target"><ref local="contenidoManagerTarget"/></property> <property name="transactionAttributes"> <props> <prop key="guardar*">PROPAGATION_REQUIRED</prop> <prop key="actualizar*">PROPAGATION_REQUIRED</prop> <prop key="borrar*">PROPAGATION_REQUIRED</prop> <prop key="visitar*">PROPAGATION_REQUIRED</prop> <prop key="reordenar*">PROPAGATION_REQUIRED</prop> <prop key="quitarParada*">PROPAGATION_REQUIRED</prop> <prop key="setContenidoDePortada">PROPAGATION_REQUIRED</prop> <prop key="generarMuseoMovil">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> </props> </property> </bean> En el ejemplo se hace uso del objeto de Spring TransactionProxyFactoryBean, que se trata de un proxy que permite interceptar llamadas a métodos de una clase y aplicar un contexto de transacciones. Además, en este caso se está haciendo uso de la clase HibernateTransactionManager; una implementación del gestor de transacciones frecuente si la capa de persistencia se basa en Hibernate. 8.9. Capa de Servicios Además de las funcionalidades que va a presentar el sistema, se hace necesario publicar una serie de servicios accesibles por otras aplicaciones independientemente del lenguaje que se usó para Página 114 Capítulo 8. Descripción de la Arquitectura desarrollarlas. Es por eso por lo que el sistema expondrá un servicio web con una serie de operaciones para la interacción con otras aplicaciones. En sistemas Java EE existen numerosos frameworks para el desarrollo de servicios web. Entre ellos se pueden citar: Axis1 y 2, XFire, Celtix, ActiveSOAP, GlassFish, Glue, XINS, etc. Aunque no existe una solución óptima, hemos optado por usar XFire. El framework XFire es una librería SOAP ligera de alto rendimiento que se basa en la filosofía de POJO’s y no se centra en XML como tienden otras (es por eso por lo que XFire se anuncia como una plataforma para el desarrollo de servicios de próxima generación). En el desarrollo con XFire lo que hay que hacer es simplemente escribir los POJO’s que van a actuar como servicios, marcar anotaciones según la especificación JSR-181, y configurar los servicios que se van a exponer en un archivo adjunto (services.xml). XFire hace el resto: introspecciona la interfaz del servicio y genera el WSDL a partir de él. Además de las propias ventajas de XFire por sí sólo, también hay que hacer notar que se puede integrar con Spring fácilmente. De esta forma, podemos hacer uso de las características de inyección de dependencia en los propios servicios, para, por ejemplo, hacer que un servicio se apoye en un bean de la capa de lógica de negocio. 8.10. Capa de integración Nuestra capa de lógica de negocio se basa en el manejo de entidades del modelo como objetos. La orientación a objetos en esta capa nos da mayor flexibilidad y comodidad a la hora de trabajar con nuestro modelo. Sin embargo, de cara a la capa de sistemas de información, las bases de de datos relacionales siguen siendo más utilizadas que las objetuales, por lo que necesitamos una capa de integración que lleve a cabo la transformación objeto-relacional o motor de persistencia (ORM -object relation mapping). Un motor de persistencia por tanto será una capa software cuya misión se centra en realizar de manera automática y transparente la traducción en ambos sentidos entre los objetos que modelan la lógica de negocio de la aplicación y las bases de datos relacionales donde se almacena aquella información que se desee perdurar. 8.10.1. Hibernate Entre los motores de persistencia de código abierto podemos destacar Hibernate, Castor, Torque, OJB y Cayenne. De ellos, hemos elegido Hibernate como herramienta ORM ya que actualmente mantiene una reputación excelente en la comunidad de desarrollo gracias a sus prestaciones, buena documentación y estabilidad. Una característica de su filosofía de diseño es que no realiza una intrusión en la manera en la que se definen las clases de manera que tendrán el mismo aspecto que los utilizados en las aplicaciones normales. Hibernate utiliza un mecanismo proporcionado por Java que es la reflexión; gracias a ella es capaz de descubrir información sobre los atributos, métodos y constructores de las clases. De esta forma, Hibernate puede trabajar con los objetos comunes de Java, o también llamados POJOs (Plain Old Java Objects). Hibernate se apoyará en múltiples APIs conocidas en la actualidad. De esta forma, usará el API de JDBC internamente para conectarse a los distintos tipos de servidores de bases de datos datos relacionales. Hibernate es una solución completa en sí misma, y aunque puede funcionar dentro de un contePágina 115 Virtual Museum sobre plataforma Java EE nedor Web, no depende de él para llevar a cabo su labor persistente, ya que de hecho se puede utilizar en aplicaciones standalone. Para indicar a Hibernate cómo se deben almacenar nuestros objetos en la base de datos se emplean archivos de mapeo XML. En un archivo de mapeo se especifican las propiedades del objeto ya sean propiedades del objeto o asociaciones con otros objetos. Podemos ver un ejemplo de cómo se configuraría una clase: <class name="com.museum4j.modelo.Contenido" table="contenidos"> <id name="idContenido" column="idContenido" type="java.lang.Integer"> <generator class="increment" /> </id> <many-to-one name="museo" column="museo" /> <property name="fechaCreacion" column="fechaCreacion" type="java.util.Date"/> <set name="textos" table="textos" cascade="all" inverse="true" lazy="false"> <key column="idContenido" /> <one-to-many class="com.museum4j.modelo.Texto" /> </set> <property name="hits" column="nVisitas" type="java.lang.Integer"/> [...] </class> Aunque la declaración de propiedades y asociaciones de cada objeto del modelo en ocasiones puede no ser tarea fácil, en el ejemplo anterior vemos cómo se pueden modelar propiedades simples (número de visitas), el propio identificador de la clase o clave primaria (idContenido), e incluso se pueden modelar relaciones N:1 (un contenido está asociado con un museo), y relaciones 1:N (un contenido presenta un conjunto de textos), entre otras. En este ejemplo, se muestra una parte de una declaración de mapeos de propiedades y asociaciones para una clase a modo de introducción, aunque en Hibernate (y así se ha necesitado para el presente proyecto) se pueden modelar otras relaciones más elaboradas como herencia, asociaciones ternarias, colecciones ordenadas, etc. Aunque la capa de datos se implementa a través de Hibernate, su acceso desde la capa de lógica de negocio se hace a través de interfaces, desacoplando así la lógica del código que implementa la persistencia. Así, en cualquier momento se podría cambiar Hibernate por otro componente que maneje la persistencia de nuestro modelo hacia la base de datos. 8.11. Capa de sistemas de información La última capa que da soporte a nuestro sistema es la que nos da la persistencia de la información que maneja. En este caso, los gestores de bases de datos relacionales se han consolidado de momento como las dominadoras del mercado, por lo que optamos por utilizar un gestor de este tipo. Entre los gestores de bases de datos relacionales open source existentes nos vamos a decantar por MySQL, frente a otros como Firebird, PostgreSQL, MaxDB o Ingres. Fundamentalmente, se usa MySQL debido a las siguientes características que presenta: Portabilidad: MySQL está soportado en la mayoría de los distintos "sabores"de Unix/Linux, así como Windows y MacOS X. Velocidad: Usa técnicas como mecanismos eficientes de indexado, tablas temporales en memoria y algoritmos optimizados para operaciones join, lo que le da una eficiencia y velocidad superior a otros sistemas de base de datos. Página 116 Capítulo 8. Descripción de la Arquitectura Escalabilidad: Debido a su modularidad y su flexibilidad en su configuración, se puede ejecutar en un amplio abanico de máquinas desde ambientes embebidos hasta sistemas multiprocesador. Esta escalabilidad permite desarrollar nuestros sistemas sobre una configuración de desarrollo y luego portar la misma base de datos a otra máquina en producción. Además, al ser multihilo, MySQL aprovecha los recursos eficientemente para dar servicio concurrente a múltiples usuarios. Flexibilidad: Se permite elegir el tipo necesario de nuestras tablas para ajustarse a nuestros requisitos software. Facilidad de uso: Es relativamente fácil de instalar y administrar, comparado con otros sistemas de gestión de bases de datos. Seguridad: Se pueden restringir los permisos de acceso a los distintos usuarios pudiendo establecer derechos a distintos nivels: desde la base de datos completa hasta columnas. Accesodesdeotros lenguajes/sistemas: Existen numerosas librerías y APIs paraconectarMySQL con Java, C/C++, Perl, PHP, ODBC, etc. Licencia: Aunque en algunos casos se debe obtener una licencia comercial, MySQL se distribuye bajo licencia GPL, lo que en la mayoría de los casos permite usarse sin coste alguno. 8.12. Diagrama de Componentes El patrón de diseño fundamental del sistema es MVC por lo que Struts representa el componente fundamental, dándonos el pilar principal sobre el que que conectar el modelo de datos con la vista. Sin embargo la inyección de dependencia que nos da Spring resulta muy atractiva por lo que se ha optado por hacer que coexistan los dos, a través del proxy DelegatingActionProxy. Aunque Spring también nos da un framework MVC, Struts sigue resultando mejor aproximación para las aplicaciones del administrador y responsable del museo. Las ventajas de integrar un sistema Struts en la plataforma Spring son diversas. La primera de todas es que Spring se diseñó de forma explícita para resolver algunos de los problemas de la ”vida real JEE”, como la complejidad, baja eficiencia, testabilidad, etc. Por otra parte, para la aplicación del visitante esta solución no resultaba totalmente apropiada por lo que en este caso, pasamos a usar otra combinación de componentes. En esta aplicación nos desligamos de Struts ya que desde el punto de vista de acciones, en este caso vamos a contar con un conjunto más reducido de acciones y Spring MVC nos ofrece mayor flexibilidad para nuestros objetivos. Sin embargo, sí que seguimos interesados en acceder a los beans de la lógica de negocio y que éstos accedan los objetos del modelo de la misma forma en que lo hacían las otras dos apliaciones. Por eso, aunque esta aplicación no comparte Struts como despachador de peticiones, y se deja únicamente en manos de Spring, sí que se siguen compartiendo los componentes de las capas inferiores. Página 117 Virtual Museum sobre plataforma Java EE Figura 8.12: Diagrama de Componentes del sistema Página 118 Capítulo 9 DISEÑO Los grandes conocimientos engendran las grandes dudas. Aristóteles Índice del Capítulo 9.1. Introducción ....................................120 9.2. Diagrama de Clases de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.2.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.2.2. Modelo ..................................122 9.2.3. Accesoadatos ..............................125 9.2.4. Negocio..................................127 9.2.5. ServiciosWeb...............................129 9.2.6. Acciones Visitante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 9.2.7. Acciones Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.2.8. Acciones Administrador . . . . . . . . . . . . . . . . . . . . . . . . . 132 9.2.9. VistaMóvil ................................133 9.2.10. TaglibBandera ..............................134 9.3. Realización de casos de uso-diseño . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.4. Descripción de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.5. Diagrama Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.5.1. Elementos Dublin core . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.5.2. Diccionario de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.5.3. Modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 9.6. Diseño de Temas/Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.6.1. Descriptor XML de la Plantilla . . . . . . . . . . . . . . . . . . . . . . 140 9.7. Macrosdeplantilla.................................140 119 Capítulo 9. Diseño 9.2.4. Negocio La capa de lógica de negocio se ha diseñado planteando, como en la capa de acceso a datos, como la composición de dos capas, partiendo de una primera capa de interfaces de forma que se desacopla la especificación de la clase de su implementación: Figura 9.4: Diagrama de Clases de Diseño - Paquete Negocio I Página 127 Virtual Museum sobre plataforma Java EE Figura 9.5: Diagrama de Clases de Diseño - Paquete Negocio II Página 128 Capítulo 9. Diseño 9.2.5. Servicios Web Figura 9.6: Diagrama de Clases de Diseño - Paquete Servicios Web Página 129 Virtual Museum sobre plataforma Java EE 9.2.6. Acciones Visitante Figura 9.7: Diagrama de Clases de Diseño - Paquete Acciones Spring Visitante Página 130 Capítulo 9. Diseño 9.2.7. Acciones Director Figura 9.8: Diagrama de Clases de Diseño - Paquete Acciones Struts Director Página 131 Virtual Museum sobre plataforma Java EE 9.2.8. Acciones Administrador Figura 9.9: Diagrama de Clases de Diseño - Paquete Acciones Struts Administrador Página 132 Capítulo 9. Diseño 9.2.9. Vista Móvil Conjunto de clases y plantillas para la generación de la vista móvil. Figura 9.10: Diagrama de Clases de Diseño - Paquete VistaMovil Página 133 Virtual Museum sobre plataforma Java EE 9.2.10. Taglib Bandera Usado para los jsp de contenidos Figura 9.11: Diagrama de Clases de Diseño - Paquete Taglib Página 134 Capítulo 9. Diseño 9.3. Realización de casos de uso-diseño Las realizaciones de casos de uso-diseño se presentan en forma de diagramas de interacción, y más concretamente como diagramas de secuencia. Para su visualización puede dirigirse al CD anexo y abrir el modelo de diseño dentro del directorio ”together”. 9.4. Descripción de operaciones Hay ciertas operaciones o métodos de las clases de diseño que se han descrito durante la fase de diseño, mientras que el resto se han dejado como labor del propio Ingeniero de Componentes pero dentro de la fase implementación. 9.5. Diagrama Entidad-Relación El diagrama entidad-relación que se usará para persistir las clases del paquete del modelo se presenta en la siguiente página, dadas sus dimensiones. Página 135 Figura 12: Diagrama Entidad-Relación general 1