FACULTADE DE INFORMÁTICA

Transcripción

1 Departamento de Computación con la colaboración de ENXENIO S.L. FACULTADE DE INFORMÁTICA PROYECTO FIN DE MÁSTER EN INFORMÁTICA Especialidad en tecnologías de la información Herramienta Web genérica de publicación de cartografía municipal Autor: Miguel Álvarez Úbeda Director: David Trillo Pérez Tutor: Miguel Ángel Rodríguez Luaces Fecha: A Coruña, 18 de Septiembre de 2009

2

3 Información general Título del Proyecto: Herramienta Web genérica de publicación de cartografía municipal Clase del Proyecto: Proyecto Clásico de Ingeniería Autor: Miguel Álvarez Úbeda Director: David Trillo Pérez Tutor: Miguel Ángel Rodríguez Luaces Fecha: A Coruña, 18 de Septiembre de 2009 Tribunal Miembros del tribunal: Calificación:

4

5 Autorización de entrega D. Miguel Ángel Rodríguez Luaces y D. David Trillo Pérez CERTIFICAN Que la memoria titulada Herramienta Web genérica de publicación de cartografía municipal ha sido realizada por D. Miguel Álvarez Úbeda, con D.N.I P bajo la dirección de D. David Trillo Pérez y la tutela de D. Miguel Ángel Rodríguez Luaces. Esta memoria constituye la documentación que, con mi autorización, entrega el alumno para optar al título de Máster en informática en Informática especialidad en tecnologías de la información. Firmado: Firmado: D. Miguel Ángel Rodríguez Luaces D. David Trillo Pérez A Coruña, a 18 de Septiembre de 2009

6 iv

7 A todas las personas gente que me ha apoyado en los momentos difíciles, sin ellos este proyecto no hubiera sido posible. Gracias por todo.

8 vi

9 RESUMEN En el contexto actual de globalización, la información es un factor en auge, que cobra una especial relevancia para actividades lúdicas, festivas, económicas e informativas. Internet es la carta de presentación de un lugar al resto del mundo y un factor determinante y potenciador del turismo, el cual genera múltiples necesidades de información. Por citar algunos ejemplos: la consulta previa de los horarios del medio de transporte elegido, la compra de billetes de avión, ver la previsión meteorológica en las fechas estimadas del viaje, las opiniones acerca el alojamiento elegido, etc. El objetivo de este proyecto ha sido desarrollar una web genérica para su uso en los ayuntamientos municipales que aproveche la tecnología libre y gratuita existente y que deberá ser capaz de centralizar toda la información municipal. Tendrá capacidad suficiente para auto-gestionarse sin apenas conocimientos informáticos por un administrador y únicamente el mantenimiento consistirá en el despliegue inicial de la plataforma, la actualización de los contenidos y configuración de las peculiaridades concretas del municipio. Los usuarios finales serán los principales beneficiarios de esta iniciativa pues tendrán una mayor información y de más calidad, pudiendo acceder a secciones genéricas como pueden ser: noticias, turismo, foros, patrimonio, fiestas, direcciones de contacto y callejero. Este proyecto fin de máster, ha sido realizado in situ en la empresa Enxenio S.L., con un grupo de expertos encargados de la gestión y mantenimiento de la información cartográfica de la diputación de la Coruña. La empresa está realizando proyectos de gran envergadura en el campo de sistemas de información geográfica financiados por organismos públicos y empresas privadas. Otra de las tareas que desempeñan consiste en la realización de software a medida para ayuntamientos. vii

10 viii Por la temática empresarial se ha realizado un especial hincapié en el soporte de Sistemas de Información Geográfica (SIG), construyendo para ello una compleja infraestructura, con la que dar soporte via web a la información municipal geográfica del territorio disponible. Para cumplir las expectativas se ha adaptado inicialmente un sistema de gestión de contenidos libre a las necesidades de los casos de uso (Liferay), se ha internacionalizado al idioma gallego (ES gl). Sobre dicha plataforma se han desarrollado completamente dos portlets (componentes modulares de interfaz de usuario gestionadas y visualizadas en un portal web) e implementados mediante la especificación Java Specification Request v 2.0 (JSR 286) y lenguaje de programación JavaServer Pages (JSP). El objetivo del primer portlet consiste es desempeñar labores de georreferenciación cartográfica (callejero) para obtener a partir de una dirección las coordenadas latitud y longitud y el del segundo será un visor cartográfico con soporte de mapas con diversas fuentes tanto internas, obteniendo la fuente de la base de datos de la EIEL, como externas (Google Maps GM, Yahoo Maps, OpenStreetMap, SigPac, Catastro...). Ambos portlets se relacionan entre si mediante el paso de eventos, lo que permite usarlos tanto independientemente como juntos, complicando el diseño en beneficio de futuras mejoras georreferenciando cualquier tipo de contenido geoespacial. Partiendo de este sistema genérico se ha personalizado el caso concreto del municipio de A Coruña. Se hizo un especial énfasis en que la aplicación sea fácil de usar (por medio de un instalador y un manual con el que resolver todo tipo de dudas), rápido, manejable y cuidando otros aspectos relevantes como la calidad de la interfaz de usuario. Sobre la tecnología empleada en este proyecto, ha sido Eclipse y Java para el desarrollo, PostgreSQL como motor de base de datos sobre la cual se emplea un módulo PostGIS que añade soporte para objetos geográficos y WinEdt y L A TEX para la redacción de la memoria. Además se han empleado OpenLayers como librería Javascript para programar el visor; Ant y maven2 como gestores y constructores de proyectos java, Tomcat como contenedor de servlets, Geoserver como servicio para compartir información geoespacial y como gestor de contenidos se emplearon tanto Liferay como JBoss Portal para probar la portabilidad.

11 PALABRAS CLAVE Sistemas de información Geográfica (SIG) Web Municipal Callejero OpenLayers Liferay Cartografía Portlets ix

12 x

13 AGRADECIMIENTOS A mi padres, por proporcionarme los medios, animarme cuando no podía y darme la vida. A Anita por aguantar a un novio zombie sin tiempo para nada. A toda la gente del laboratorio, especialmente a Jose, Óscar, Javi, Sergio, Sandra e Yvan por ayudarme a resolver dudas y darte un toque humano al trabajo. A mi tutor Miguel Ángel Rodríguez Luaces y David Trillo Pérez, director de este proyecto, por darme esta oportunidad. A Héctor mi amigo de frikismo, maratones y de juerga. A mis compañeros de prácticas de Integración de Sistemas Pegerto y Santi por ser tan eficientes y divertidos. A D. Alberto Valderruten, decano de esta facultad, por no permitir las injusticias. xi

14 xii

15 ÍNDICE GENERAL ÍNDICE GENERAL ÍNDICE DE FIGURAS ÍNDICE DE TABLAS XIII XV XVII 1 Introducción Motivación Objetivos Estructura de la memoria Conceptos previos y herramientas Sistemas de información geográfica (SIG) Modelos de representación Flujo de trabajo en un SIG Fuentes de error en los SIG Proyecciones geográficas Aplicaciones generales de los SIG Bases de datos en un SIG PostgreSQL PostGIS Paradigma de la orientación a objetos Proyecto EIEL Protocolos Web Map Service (WMS) xiii

16 xiv ÍNDICE GENERAL Web Feature Service (WFS) Geography Markup Language (GML) Styled Layer Descriptor (SLD) Tomcat Liferay Java Server Pages (JSP) Portlet Almacenamiento persistente para las preferencias Procesamiento de solicitudes Modos de los Portlets Estado de la ventana Información de Usuario Especificación JSR Especificación JSR Geoserver OpenLayers Herramientas de desarrollo Aplicaciones similares Aplicaciones de gestión de contenidos JBoss Portal Plone Drupal OpenCMS Joomla exoplatform Proyecto Web municipal de Castellón Proyectos concretos Web del municipio de Arañuel Web del municipio de Abegondo

17 ÍNDICE GENERAL xv Web del municipio de Corcubión Web del municipio de Valga Planificación y evaluación de costes Consideraciones previas Planificación inicial Estimación de costes Estimación previa Seguimiento Metodología Definición de MPR Representación gráfica de MPR Descripción detallada de las fases Paradigma del Prototipado Análisis Captura de requisitos Prototipado Perfiles de usuario Definición de especificaciones Casos de uso Diseño Contexto Diseño portlets genéricos Especificación de portlets Java JSR-168 y JSR El contenedor de portlets Aplicación Web del portal API de Portlet Estructura de la aplicación GisScriptMun

18 xvi ÍNDICE GENERAL GisMapPorlets Implementación Eclipse GisScriptMun Datos de entrada Despliegue de infraestructura municipal Traducción Liferay GisMapPortlets Proyecto maven GisSearcherPortlet GisPointVO GisViewerPortlet Pruebas Pruebas unitarias Pruebas de integración Pruebas de rendimiento Pruebas de compatibilidad Pruebas de stress Pruebas de aceptación Resultados y rendimiento GisScriptMun Desplegar infraestructura municipal Consultas SQL Configuración Creación Vistas GisMapPortlets Resultados obtenidos Rendimiento

19 ÍNDICE GENERAL xvii 11 Síntesis del trabajo Conclusiones Experiencia en la empresa Líneas de trabajo futuras BIBLIOGRAFÍA 167 A Manual de usuario 171 A.1 Requisitos del sistema A.2 Instalación y despliegue A.2.1 Carga de datos A.2.2 PostgresSQL & PostGis A.3 Configuración A.3.1 Configuración inicial A.3.2 Tomcat A.3.3 Geoserver A.4 Liferay A.4.1 Principal A.4.2 Novedades A.4.3 Turismo A.4.4 Foros A.4.5 Patrimonio A.4.6 Fiestas A.4.7 Contactos A.4.8 Callejero A.4.9 Configuración A.5 Dudas frecuentes (FAQ) A.5.1 Cambio datasource datos A.5.2 Instalar Liferay servicio A.5.3 Iniciar Parar y Reiniciar servicios A.5.4 No encuentra la tabla de municipios

20 xviii ÍNDICE GENERAL A.5.5 Modo desarrollo B Patrones de Diseño 193 B.1 Patrón Model-View-Controller B.2 DAO (Data Access Object) B.3 Patrón VO (Value Object) B.4 Patrón Factory B.5 Patrón Strategy B.6 Patrón Template Method B.7 Patrón Singleton C The GNU General Public License 203 D Contenido del DVD 211

21 ÍNDICE DE FIGURAS 1.1 MGiacomo Cantelli da Vignola, Il Regno di Galicia. (1696) Mapa GIS 3D Definición SIG SIG como sistema Diferencias entre raster y vectorial Flujo de trabajo Aplicaciones de un GIS Tipos de geometrías OGC giseiel: Entorno de trabajo Estándares OpenGIS Diferencias entre WFS y WMS operaciones Gestor de Aplicaciones Web de Tomcat Pantalla inicial de Liferay Diagrama de clases del modelo interno de Liferay Pantalla inicial de Geoserver Visor OpenLayers Protocolos soportados por OpenLayers Interfaz Web Drupal Extension de Drupal con Openlayers Extensión WISroGIS sobre Joomla Proyecto Web Municiapl Castellón xix

22 xx ÍNDICE DE FIGURAS 3.5 Municipio de Arañuel Municipio de Abegondo Municipio de Corcubión Municipio de Valga Diagrama de Gantt: Estimación inicial Diagrama de Gantt: Estimación real Metodología Prototipado Rápido El paradigma de construcción de prototipos Prototipo Portlet menú vista Prototipo Portlet menú ayuda Arquitectura del sistema Diagrama de casos de uso Arquitectura servidor de portales genérico Diagrama de clases: API GenericPortlet Diagrama de clases: API PortletRequest Diagrama de clases: API PortletResponse Diagrama de secuencia: Procesamiento de peticiones de renderización Diagrama de secuencia: Procesamiento de peticiones de acción Diagrama de secuencia: Procesamiento de peticiones de acción que devuelve un evento Diagrama de classes GisScriptMun & Estructura interna Diagrama de clases: GeometriaFactory Diagrama de clases: Valor Diseño de interfaz: Ejemplo edición con Visual Editor Diagrama de classes Portlets GisMapPortlets Estructura interna objeto GisPointVO Estructura interna portlet GisSearcherPortlet Estructura interna portlet GisViewerPortlet

23 ÍNDICE DE FIGURAS xxi 8.1 Entorno de desarrollo Eclipse Diagrama de paquetes, estructura interna GisSearcherPortlet.war Diagrama de paquetes, estructura interna GisPointVO.jar Diagrama de paquetes: estructura interna GisViewerPortlet.war Pruebas de integración con JBoss Portal GisScriptMun: Principal GisScriptMun: Consultas SQL GisScriptMun: Creacción de vistas GisMapPortlets: Liferay menú modo GisMapPortlets: Liferay menú vista evento GisMapPortlets: Liferay menú configuración GisMapPortlets: Liferay menú ayuda A.1 GisScriptMun: Principal A.2 PgAdmin III A.3 Liferay municipal: menú Principal A.4 Liferay municipal: menú Novedades A.5 Liferay municipal: menú Turismo A.6 Liferay municipal: menú Foros A.7 Liferay municipal: menú Patrimonio A.8 Liferay municipal: menú Fiestas A.9 Liferay municipal: menú Contactos A.10 Liferay municipal: menú portlets A.11 Liferay municipal: Vista A.12 Liferay municipal: Apariencia A.13 Liferay municipal: Configuración Roles A.14 Liferay municipal: Preferencias A.15 Liferay municipal: Vista A.16 Liferay municipal: Agregar un nuevo portlet

24 xxii ÍNDICE DE FIGURAS A.17 Liferay municipal: Panel de control A.18 Liferay municipal: Cambio logo municipal A.19 Liferay municipal: Configuración de páginas A.20 Liferay municipal: Plantilla de página B.1 Patrón MVC B.2 Patrón Factory B.3 Patrón Strategy B.4 Patrón template B.5 Patrón Singleton

25 ÍNDICE DE TABLAS 2.1 Ventajas e inconvenientes entre vectorial y raster Diferencias entre WFS y WMS sintácticas Tabla Herramientas Comparativa CMS Tabla coste y capacidad máxima de recursos humanos planificados Tabla resumen planificación inicial Calendario seguimiento planificación Tabla resumen planificación final Tabla costes finales desglosados por perfil A.1 Tabla configuraciones iniciales xxiii

26 xxiv ÍNDICE DE TABLAS

27 CAPÍTULO 1 INTRODUCCIÓN 1.1 Motivación Un mapa es una representación gráfica y métrica de una porción de territorio sobre una superficie bidimensional, generalmente plana, pero que puede ser también esférica como ocurre en los globos terráqueos. El que el mapa tenga propiedades métricas significa que ha de ser posible tomar medidas de distancias, ángulos o superficies sobre él y obtener un resultado lo más exacto posible. Iniciados por el hombre con el propósito de conocer su mundo, y apoyados primero sobre teorías filosóficas, los mapas constituyen hoy una fuente importantísima de información, y una gran parte de la actividad humana está relacionada de una u otra forma con la cartografía. 1

28 2 Capítulo 1 La historia de la cartografía abarca desde los primeros trazos en la arena o nieve hasta el uso de técnicas geodésicas, fotogramétricas y de fotointerpretación. Los errores geométricos de un mapa suelen mantenerse por debajo de lo que el ojo humano puede percibir. Actualmente se tiene la inquietud y la necesidad de proseguir con la nunca acabada labor cartográfica. El Universo en general y el Sistema Solar en particular ofrecerá, sin duda, nuevos terrenos para esta labor que tiene orígenes inmemoriales. El uso de las técnicas basadas en la fotografía por satélite ha hecho posible no sólo conocer el contorno exacto de un país, de un continente o del mundo, sino también aspectos etnológicos, históricos, estadísticos, hidrográficos, orográficos, geomorfológicos, geológicos y económicos que llevan al hombre a un conocimiento más amplio de su medio, del planeta en el que vive. La cuestión esencial en la elaboración de un mapa es que la expresión gráfica debe ser clara, sin sacrificar por ello la precisión. El mapa es un documento que tiene que ser entendido según los propósitos que intervinieron en su preparación. Todo mapa tiene un orden jerárquico de valores y los primarios deben destacarse por encima de los secundarios. Para poder cumplir con estas exigencias, el cartógrafo debe crear varios planos de lectura. En todo momento debe tener presentes las técnicas de simplificación, a base de colores o simbología, sin perder de vista que en un plano de lectura más profundo se pueden obtener elementos informativos detallados. La cantidad de información debe estar relacionada en forma proporcional a la escala. Cuanto mayor sea el espacio dedicado a una región, mayor será también el número de elementos informativos que se puedan aportar acerca de ellos. En definitiva, todo mapa tiene que incluir una síntesis de conjunto al igual que un detalle analítico que permita una lectura más profunda. El nivel en que se cumplan estas condiciones será igualmente el nivel de calidad cartográfica de un determinado mapa.

29 Introducción 3 Figura 1.1: MGiacomo Cantelli da Vignola, Il Regno di Galicia. (1696). En el siglo XX, la cartografía ha experimentado una serie de importantes innovaciones técnicas. La fotografía área, denominada también ortofotomapa, se desarrolló durante la I Guerra Mundial y se utilizó, de forma más generalizada, en la elaboración de mapas durante la II Guerra Mundial. Era de vital importancia puesto que la supervivencia dependía en gran medida de la estrategia 1 y la topografía del terreno adoptadas pudiendo decantar la victoria hacia uno u otro bando. 1 estrategia: proveniente de la etimología del griego strategos, se fundamenta en el estudio del planeamiento, dirección, movimiento y dispersión de tropas de una forma coordinada.

30 4 Capítulo 1 Hacia el año 1966 se lanzan los primeros satélites (Pageous y Landsat) para hacer estudios geodésicos completos de la superficie terrestre por medio de equipos de alta resolución. Para la fotogrametría moderna se emplean instrumentos de alta precisión que permiten relacionar las fotografías aéreas y de satélite con las medidas reales del terreno. De ello resulta una información gráfica que hace posible conocer las distancias y los desniveles de una región determinada. La fotointerpretación, a través de la visión estereoscópica de la fotogrametría o aerotopografía, da un elevado nivel de detalle, que hace posible llegar a conclusiones verdaderas acerca de las condiciones de los suelos, sus usos actuales y potenciales. Por otra parte, la aparición de los Sistemas de Información Geográfica (GIS) en los años 70 y su popularización en los 90 han revolucionado la forma de crear y manejar cartografía a través de estas herramientas informáticas que asocian elementos espaciales con bases de datos. Los GIS permiten el análisis y la gestión del territorio a través de cartografía digital de una manera rápida y efectiva y sus fines son muy diversos. Un ejemplo cotidiano de este avance son los GPS. En la actualidad la elaboración de mapas es una operación compleja en la que participan grupos de más de 50 diferentes disciplinas: fotonavegantes, mecánicos, químicos de laboratorio, geodestas, matemáticos, topógrafos, geólogos, biólogos, geógrafos, físicos, agrónomos, edafólogos, ingenieros civiles, economistas y arquitectos, entre otros. En el futuro existen planes serios de hacer mapas de los planetas vecinos del Sistema Solar, de manera que los mapas, que fueron la forma inicial de conocer la Tierra, muy pronto servirán para llevar las fronteras del conocimiento más allá del planeta en el que vivimos, incluso en 3 dimensiones.

31 Introducción 5 Figura 1.2: Mapa GIS 3D Con el auge de las tecnologías de la información la tendencia actual es la centralización de cantidades ingentes de información, permitiendo el acceso remoto a la información de los técnicos municipales y los ciudadanos. La consecuencia más evidente es la reducción de costes y mejor empleo de recursos burocráticos (por ejemplo la canalización de los avisos para la reparación de desperfectos viarios). Se estima que el 90 % de la información de los ayuntamientos es georreferenciable, (un ejemplo concreto es la información catastral del municipio como puede ser el alumbrado, canalizaciones de agua o eléctricas por citar algunos de ellos). La existencia de información pública es un elemento claramente potenciador del turismo por lo que supone una gran diferencia entre municipios con limitados recursos tecnológicos comúnmente conocido el problema como brecha digital. Por los motivos antes mencionados se propone hacer realizar una web genérica con la que poder acceder remotamente a todo tipo de información, mejorando el soporte cartográfico del municipio.

32 6 Capítulo Objetivos El objetivo primordial es demostrar las competencias y conocimientos adquiridos en diversas áreas de las tecnologías de la información durante el máster en informática, para lo que el trabajo diario será realizado casi en su totalidad desde un contexto empresarial in situ dentro de la organización Enxenio S.L. [1]. El objetivo del presente proyecto consiste en realizar una web genérica para la publicación en web de cartografía municipal (Ej. Callejero, planeamiento urbanístico, patrimonio, turismo, etc.) empleando para ello exclusivamente tecnología con licencia libre y gratuita, en concreto usará tecnología de sistemas de información geográfica y de sistemas de gestión de contenidos web. El proyecto consistirá en analizar, planificar, diseñar, programar y probar un conjunto de aplicaciones interrelacionados para integrar diferentes tecnologías y que funcionen y se comuniquen armónicamente entre si. La web resultante genérica soportará diversa información cartográfica, obtenida de la base de datos de la EIEL de la Diputación de A Coruña. Esta comunicación utilizará un servicio Web Map Service (WMS) intermedio con el fin de aplicar unos ciertos estilos a la cartografía (color del trazo, grosor, relleno, etc.). Idealmente se plantea la posibilidad de automatizar tareas muy tediosas como la generación manual de dichos estilos siendo accesible vía web la nueva cartografía automáticamente. Adicionalmente soportará otro tipo de cartografía propietarias como pueden ser Google Maps, Yahoo Maps. El proyecto tendrá varias aplicaciones que se desplegarán por medio de un único instalador que realice la configuración inicial y genere una plantilla genérica que implemente diversas secciones típicas propias de la utilidad que va desempeñar (Novedades, fiestas, foro, alojamientos) que cubra la mayoría de las necesidades similares. La información particular al municipio o municipios (nombre completo y logotipo municipal, mapa dinámico centrado en el municipio deberá ser configurada manual-

33 Introducción 7 mente fácilmente o si fuera posible durante la instalación automatizada. Se habilitará un modo avanzado para que la empresa pueda disponer opcionalmente de más funcionalidades si fuera preciso prestaciones más complejas, contemplando futuras mejoras o extensiones. 1.3 Estructura de la memoria La memoria se estructura en varios capítulos que se detallan a continuación 1. Introducción: Capítulo en el que se explica la motivación y los objetivos que persigue el proyecto, además de definir la estructura de la memoria. 2. Conceptos previos y herramientas utilizadas: Este capítulo hace referencia a todo lo que debe conocerse, terminología básica, especificaciones utilizadas, así como todo lo que concierne a la elección de las herramientas utilizadas para afrontar la realización del proyecto. 3. Aplicaciones similares: En este capítulo se hará un pequeño repaso de otras aplicaciones similares que están disponibles en Internet, haciendo un breve análisis del estado del arte y de la funcionalidad que proporcionan. 4. Planificación: En este capítulo se verá la planificación llevada a cabo para la realización del proyecto, así como una evaluación de los costes. 5. Metodología: Trata de las distintas técnicas utilizadas para el desarrollo del proyecto, con sus correspondientes diagramas. 6. Análisis: En este capítulo se habla de qué se va a construir, y cómo se obtuvieron las especificaciones hasta la obtención de la especificación de requisitos. 7. Diseño: Aquí es donde se describe el cómo se construyó y los diferentes patrones empleados, documentando la arquitectura interna. 8. Implementación: Se explican aspectos relevantes de implementación, el entorno de desarrollo y las peculiaridades técnicas de programación.

34 8 Capítulo 1 9. Pruebas: Este capítulo pretende reflejar las distintas pruebas que se han realizado a la hora de validar la aplicación. 10. Resultados y rendimiento: Se trata cómo funciona la aplicación por dentro, las funcionalidades que proporciona y los resultados obtenidos en detalle. 11. Síntesis del trabajo: Se dará una exposición de las conclusiones que se alcanzaron después de la realización del proyecto, comentando brevemente la experiencia en el ámbito empresarial. Además se citarán interesantes mejoras futuras, pero que de alguna forma quedaron fuera de los objetivos marcados. Bibliografía: En este capítulo se hace referencia a las fuentes consultadas más relevantes para la obtención de información para la ejecución del proyecto. Apéndice A - Manual de usuario: Describe la instalación de los elementos necesarios para el funcionamiento, instalación, configuración y puesta a punto intentando evitar resolver las dudas típicas que pueden surgir en su utilización basándose en capturas de pantalla autoexplicativas. Apéndice B - Patrones de diseño: Estructuras arquitéctonicas teóricas aplicadas en el diseño. Apéndice C - Licencia: Normas GPL v2.0 2 por las cuales puede ser distribuida la aplicación realizada al ser publicada. Apéndice D - Contenido del DVD: Explicación de la estructura y el contenido de las carpetas incluidas en el medio digital anexo. 2 GPL: General Public License

35 CAPÍTULO 2 CONCEPTOS PREVIOS Y HERRAMIENTAS 2.1 Sistemas de información geográfica (SIG) La cartografía tiene como objetivo la producción de mapas y su interpretación. En la última década, con el avance tecnológico y su incorporación a esta ciencia, ha pasado a ser un elemento fundamental en la sociedad de la información. Desde el punto de vista de la ingeniería cartográfica, es el soporte básico para la planificación y diseño de obras, infraestructuras, análisis físico del territorio, económico o ambiental. Las herramientas que se han establecido para el análisis de la cartografía son los denominados Sistemas de Información Geográfica (SIG). Los SIG se definen como sistemas compuestos por hardware, software y procedimientos para capturar, manipular, analizar, modelar y representar datos georrefe- 9

36 10 Capítulo 2 renciados 1, con el objetivo de resolver problemas de gestión y planificación. Ante todo son herramientas de ayuda a la resolución de problemas; el concepto de herramienta indica que los SIG no son el fin, sino el medio. Figura 2.1: Definición SIG Los SIG tienen las siguientes características: Son sistemas diseñados para la visualización de información geográfica expresada en forma de mapas. El eje central de su funcionamiento se encuentra en la posición de un elemento geográfico representado por elementos gráficos (como puntos, líneas, polígonos) y su información temática asociada. Disponen de un gran número de funciones de análisis y consulta para explotar la información geográfica enfocada a resolver un problema o necesidad. Son el resultado de la aportación de múltiples disciplinas (geográfica, matemática, cartográfica) de las que se han extraído capacidades para el manejo de información geográfica. Almacenan las relaciones espaciales entre los distintos elementos, lo que permite interrogar al sistema sobre estas relaciones. 1 georreferenciación: establecimiento de relaciones entre las imágenes de raster o vector sobre una proyección geográfica o sistema de coordenadas.

37 Conceptos previos y herramientas 11 Figura 2.2: SIG como sistema Un sistema de información geográfica, por ser sistema, tiene una serie de elementos relacionados entre sí. Elementos que interrelaciona Hardware: Equipos informáticos formados por ordenadores y sus periféricos; monitor, escáner, dispositivos de almacenamiento, impresoras, etc. Software: Programas informáticos con funciones para visualizar, consultar y analizar los datos geográficos. Liveware: Es el componente vivo del sistema. Comprende a los usuarios del sistema y a los datos que han de recogerse y mantenerse vivos (actualizados). Las principales funciones de un SIG son: Captura de la información: Funciones que permiten adquirir y depurar errores tanto de información geográfica espacial como temática. Funciones de gestión: Funciones de estructuración de la información original en diferentes capas de información coherente. Funciones de análisis: Son las que confieren a un SIG su mayor potencialidad. Permiten extraer información no presente a simple vista, generar nuevos

38 12 Capítulo 2 datos y realizar simulaciones de comportamientos basados en modelos de territorio. Funciones de salida: Permiten mostrar al usuario tanto los propios datos incluidos en el sistema como el resultado de las consultas y análisis sobre ellos Modelos de representación Los SIG deben ser capaces de representar y almacenar las entidades geográficas reales mediante la representación y almacenamiento de las entidades gráficas. Existen básicamente dos formas en los que se puede representar la información en los sistemas informáticos; son el modelo raster y el modelo vectorial. La diferencia de los modelos está en el modo en el que guardan la información. El modelo raster guarda una matriz de posiciones donde cada posición representa una fracción del objeto a representar y tomará el valor que tenga ese objeto real en ese punto. El modelo vectorial almacena las coordenadas de la geometría. Un ejemplo de utilización de ambos modelos son las aplicaciones CAD que usan el modelo vectorial, y las aplicaciones de retoque fotográfico que usan el modelo raster. Figura 2.3: Diferencias entre raster y vectorial

39 Conceptos previos y herramientas 13 Cada modelo se usará en un contexto determinado, ya que dependiendo de la situación puede ser mejor usar un modelo que el otro. Modelo vectorial Modelo raster VENTAJAS Ocupa menos espacio de memoria Facilidad de captura Precisión elevada en la definición de Estructura de datos simple entidades geométricas Representación adecuada de las relaciones topológicas tión de la información Sencillez en la manipulación y ges- Mejores salidas gráficas INCONVENIENTES Captura de datos más costosa Menor precisión en el cálculo de áreas y longitudes Estructura de datos más compleja Ocupan mayor espacio de memoria Mayor dificultad a la hora de realizar ciertas operaciones (Comparalaciones topológicas Dificultad de representar ciertas reción de mapas) Tabla 2.1: Ventajas e inconvenientes entre vectorial y raster De forma general diremos que recomendaremos el trabajo con información raster cuando: Trabajemos con grandes extensiones de terreno y a pequeñas escalas. No requiramos precisiones muy altas para nuestros cálculos. Requiramos análisis rápidos de estudios de variabilidad temporal. Estas condiciones se pueden dar en casos de estudios sobre recursos naturales, impacto medioambiental, estudios regionales y globales sobre climatología, cálculo de superficies afectadas por incendios, etc. Por el contrario, se recomendará trabajar con información vectorial cuando: Trabajemos con extensiones pequeñas y a medianas o grandes escalas.

40 14 Capítulo 2 Necesitemos altas precisiones en cálculos y definición de entidades. Necesitemos tener reflejadas complejas relaciones topológicas. Estos criterios se dan en casos como la gestión catastral, planificación urbana local, arqueología, etc Flujo de trabajo en un SIG Para entender y obtener el máximo beneficio de un SIG, el usuario debe saber cuál es la secuencia de fases que ha de aplicar para llegar a solucionar un problema que se le ha planteado. Las fases que se deben seguir son las siguientes: Captura de la información: la información necesaria será función del problema planteado. La calidad de los datos originales influirá en la bondad del resultado final. Los métodos de captura de la información espacial son múltiples y variados: tableta digitalizadora, escáner, levantamiento topográfico o fotogramétrico, plataformas de satélite, etc. Así mismo los datos temáticos serán capturados a partir de bases de datos existentes, fichas, encuestas, entrevistas, trabajos de campo, etc. Preparación de la información: es necesario que la información esté limpia de errores (cometidos en la captura) y dotada de una estructura que permita una consulta y un análisis eficiente por parte del sistema. En el caso de información vectorial, hacer que los polígonos estén cerrados o que las líneas conecten entre sí permitirá estructurar la información guardando sus relaciones topológicas. Esto hará que el sistema pueda contestar a preguntas como qué es lo más cercano a...?, cuál es el mejor camino para...?, cuántos elementos hay dentro de...?, etc. En el caso de la información raster, será necesario georreferenciar la información y corregirla de posibles deformaciones y valores erróneos debidos al proceso de adquisición. Fusión de la información espacial y temática: es el proceso por el cual se asocia a cada elemento geográfico información temática externa de naturaleza

41 Conceptos previos y herramientas 15 diferente a la espacial. Cada elemento geográfico tiene un enlace biunívoco con su información temática asociada de forma que es posible interrogar a un elemento espacial y obtener el resultado en forma de información temática y viceversa, interrogar a la información temática y obtener como resultado un elemento espacial. Análisis de la información: una vez fusionados los datos, se los puede someter a operaciones de análisis que sigan los criterios de resolución del problema. Los análisis pueden ser sobre datos de una única naturaleza (datos espaciales o temáticos por separado) o analizar ambos tipos de datos a la vez. Figura 2.4: Flujo de trabajo Fuentes de error en los SIG Cuando trabajamos con SIG, el coste más alto, en tiempo y dinero, recae sobre la captura y el mantenimiento (actualización) de la información geográfica. Los datos son materia viva y deben ser mantenidos en estado de óptima calidad, tanto desde el punto de vista geométrico (adecuada exactitud posicional, exentos de errores topológicos, etc.), temático (fiabilidad de la información temática, asociación adecuada con los datos gráficos, etc.) como temporal (los datos han de ser lo más recientes posible).

42 16 Capítulo 2 Por lo tanto, debemos ser capaces de conocer de qué tecnologías y metodologías disponemos para capturar la información geográfica y qué errores podemos cometer en este proceso. Esto será un indicador fundamental de la calidad de nuestros datos y, por extensión, de la calidad de nuestros análisis y resultados al trabajar sobre el SIG. Los tipos de errores que podemos encontrarnos al trabajar con información geográfica dentro del entorno de los SIG pueden ser de dos tipos: Los errores propios debidos al método de captura de los datos. Errores debidos a la manipulación de la información original por aplicación de sucesivos procesos de análisis y transformación dentro del propio SIG. Ambos tipos de errores pueden aplicarse tanto a la información gráfica como a la información temática e influir directamente sobre la calidad final de los datos Proyecciones geográficas La proyección cartográfica o proyección geográfica es un sistema de representación gráfico que establece una relación ordenada entre los puntos de la superficie curva de la Tierra y los de una superficie plana (mapa). Estos puntos se localizan auxiliándose en una red de meridianos y paralelos, en forma de malla. La única forma de evitar las distorsiones de esta proyección sería usando un mapa esférico pero, en la mayoría de los casos, sería demasiado grande para que resultase útil. Una buena proyección debe tener tres características, que conserve las áreas (equivalencia), que conserve los ángulos (conformidad) y que conserve las distancias de los objetos de distancia equivalente.

43 Conceptos previos y herramientas 17 Desgraciadamente no es posible tener todas las características simultaneamente, sería como hallar la cuadratura del círculo, por lo que hay que buscar soluciones intermedias. Cuando una proyección conserva los ángulos de los contornos se dice que es ortomórfica o conforme, pero estas proyecciones no conservan las áreas. Dependiendo de cuál sea el punto que se considere como centro del mapa, se distingue entre proyecciones polares, cuyo centro es uno de los polos; ecuatoriales, cuyo centro es la intersección entre la línea del Ecuador y un meridiano; y oblicuas o inclinadas, cuyo centro es cualquier otro punto. Existen múltiples combinaciones de proyecciones y variantes pero podemos agruparlas en función de proyecciones básicas: Cilíndricas: es la que se ejecuta sobre un cilindro que luego se extiende hasta formar un rectángulo. En ella los meridianos y paralelos se cruzan en ángulo recto. La distorsión es mínima donde el cilindro es tangente. Permite mostrar toda la Tierra, aunque los polos están muy distorsionados. La distorsión en los bordes es muy elevada.

44 18 Capítulo 2 Cónicas: es la que se realiza sobre un cono cuyo centro es el Polo Norte o el Polo Sur. Tiende a exagerar las superficies hacia el ecuador. En ella los meridianos son rectas que convergen hacia el Polo y los meridianos son semicírculos con centro en dicho Polo. La distorsión es mínima donde el cono es tangente. La distorsión es menor que en las proyecciones cilíndricas. No permite mostrar toda la Tierra. Azimutales o cenital: es la que se plasma sobre un plano tangente a un punto de la superficie de la Tierra. No permite representar toda la Tierra, por lo que según sea la tangente puede ser: polar, ecuatorial u oblicua. Simula la visión desde el espacio Distorsiona las formas pero mantiene las proporciones Las distancias más cortas son líneas rectas Los bordes del mapa están muy distorsionados

45 Conceptos previos y herramientas 19 La European Petroleum Survey Group más conocida por las siglas EPSG ( ) fue una organización científica vinculada a la industria del petróleo europea, que trabajaban en el campo de la geodesia, la topografía y la cartografía aplicadas en relación con la exploraración petrolífera definieron generaron y difundieron un conjunto de parámetros geodéticos EPSG, una base de datos ampliamente usada que contiene elipsoides, datums, sistemas de coordenadas, proyecciones cartográficas, etc. Las tareas previamente desempeñadas por la EPSG son retomadas en 2005 por la OGP (International Association of Oil and Gas Producers Surveying and Positioning Committee). Las proyecciones que en la práctica emplearemos: La proyección Mercator es un tipo de proyección geográfica cilíndrica. Una versión propietaria empleada Google Maps para representar el globo terráqueo. El código que utiliza es el EPSG: EPSG:4326 es un sistema de coordenadas de referencia que se refiere a WGS84 como (latitud, longitud) pares de coordenadas en grados de Greenwich como el meridiano central. Cualquier grado de representación (por ejemplo, decimal o DMSH: grados, minutos y segundos hemisferio) pueden ser utilizados. Grado de representación que se emplee deberá ser declarada por el usuario por el proveedor de datos. La proyección más empleado para el caso concreto de España es la EPSG:23029 NOTA: Para poder solapar de varias fuentes con diferentes proyecciones es preciso realizar transformaciones para que coincidan puesto que pueden producir errores de cientos de kilómetros de distancia dependiendo de las fuentes origen.

46 20 Capítulo Aplicaciones generales de los SIG Varios factores hacen posible que los SIG sean aplicables a casi cualquier actividad humana. Son aptos para resolver cualquier problema que dependa de una variable espacial (que sea o esté asociada a una posición de un elemento geográfico). La popularización de la información visual en general y de los mapas en particular en los últimos años hace que cada vez más personas apoyen sus argumentos con documentos cartográficos y sean estos usados como instrumentos de comunicación cotidianos. La entrada en el mundo laboral y personal de la informática hace que los usuarios se encuentren cómodos usando herramientas de este tipo. El intercambio masivo y libre de información geográfica a través de Internet hace que nos habituemos a referenciar cualquier tipo de idea a una posición en el planeta. La gestión y planificación del territorio y la explotación de los recursos naturales se han convertido en una necesidad imperante para el hombre. Estas factores nos dan una idea de la importancia que tiene para nosotros no sólo saber cómo es nuestro territorio y dónde estamos (función que ya cumple desde muy antiguo el mapa), sino saber explotar la información implícita que podemos extraer de ese territorio en nuestro propio beneficio. A continuación, se citan algunos campos de aplicación usuales dentro de los SIG: Planificación urbana y regional: En la planificación de usos del suelo o espacios protegidos, licencias de obras, registros de la propiedad, catastro de rústica y urbana, etc. Ingeniería de transportes: En la gestión del tráfico rodado o aéreo, el análisis de rutas óptimas para distribución de mercancías, gestión de transporte público, etc. Explotación de recursos: En la evaluación de zonas de yacimientos minerales, la gestión de redes de alcantarillado, gas y electricidad, etc. Análisis de nuevos mercados: En la ubicación de nuevos centros comerciales, análisis demográficos para nuevos productos, mejora de las redes de distribución, gestión inmobiliaria, etc.

47 Conceptos previos y herramientas 21 Aplicaciones de seguridad pública: En aplicaciones para el control de la criminalidad por parte de la policía, aplicaciones militares para el control de armamento, etc. Aplicaciones de salud pública: En la mejora de la rapidez en la atención de las ambulancias, gestión de emergencias sanitarias, lucha contra epidemias, etc. Turismo: En el desarrollo turístico de zonas deprimidas, la generación de callejeros interactivos vía Internet, medio ambiente. En análisis de impactos ambientales, inventarios de recursos medioambientales, ubicación de nuevas plantas de procesado de residuos y vertederos, etc. Prevención de riesgos naturales: En la lucha contra incendios, desertización, inundaciones, terremotos, deslizamientos de terreno, etc. Figura 2.5: Aplicaciones de un GIS

48 22 Capítulo Bases de datos en un SIG Una base de datos (abreviado como BD) es una colección de archivos interrelacionados, son creados con un sistema gestor de bases de datos. El contenido de una base de datos engloba la información concerniente (almacenada en archivos) a una organización, de tal manera que los datos estén disponibles para los usuarios; una finalidad de la base de datos es eliminar la redundancia o al menos minimizarla. Tabla de datos: La tabla es la unidad lógica de almacenamiento de información en una base de datos. Una tabla está formada por muchas filas (también llamadas registros o tuplas) con el mismo patrón de información. Cada registro está formado por una o varias columnas -también llamados campos o atributos-, que son los datos que nos interesan conocer. Así pues, de manera resumida podemos decir que una base de datos está formada por una o varias tablas que representan las ideas lógicas de las cuales queremos obtener información. En cada una de estas tablas habrá cero o muchas filas con información diferente. Por cada fila tendremos un detalle de sus datos más relevantes que nos interesan representar, es decir, los campos de la tabla. El sistema gestor de bases de datos es la porción más importante del software de un sistema de base de datos. Es una colección de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea específica. El objetivo primordial de un sistema gestor de base de datos es proporcionar un contorno que sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular la información de la base de datos. Todas las peticiones de acceso a la base se manejan centralizadamente por medio del sistema, por lo que este paquete funciona como interfaz entre los usuarios y la base de datos. Las funciones principales de un sistema gestor de base de datos son: Crear y organizar la base de datos. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que el acceso a los datos sea rápido. Manejar los datos de acuerdo a las peticiones de los usuarios.

49 Conceptos previos y herramientas 23 Registrar el uso de las bases de datos. Interacción con el manejador de archivos. Respaldo y recuperación. Consiste en contar con mecanismos implantados que permitan la recuperación fácilmente de los datos en caso de ocurrir fallos en el sistema de base de datos. Control de concurrencia. Consiste en controlar la interacción entre los usuarios concurrentes para no afectar a la inconsistencia de los datos. Seguridad e integridad. Consiste en contar con mecanismos que permitan el control de la consistencia de los datos evitando que estos se vean perjudicados por cambios no autorizados o previstos. Una base de datos espacial es una colección de datos espacialmente referenciados que actúan como modelo de la realidad. Las bases de datos espaciales son sistemas donde se almacena la información espacial. Estos sistemas necesitan representar información de dos tipos: espacial y nominal (sin representación espacial). Los datos espaciales serán referentes a las dimensiones, posición, forma,... y los nominales son datos que puedan ser de interés como nombre, habitantes... El método de representación digital varía con la escala, por ejemplo una ciudad puede representarse geográficamente como un punto considerando una escala continental, en cambio, en escalas más locales se representa como una superficie. Por esta razón la representación digital de los diferentes tipos de entidades en una base de datos espacial requiere una previa elección de los apropiados objetos espaciales. También se debe tener en cuenta para esta elección las operaciones de análisis y consultas posteriores, así como la información geográfica de partida. Por ejemplo, las vías de comunicación pueden ser representadas como elementos lineales o superficiales. La información espacial se guardará de una de las siguientes formas: Datos puntuales: Es el tipo de objeto espacial más simple. En la tabla de la base de datos, cada punto será una fila, toda la información sobre el punto

50 24 Capítulo 2 estará en esa fila. Cada columna será un atributo. Cada punto es independiente de cualquier otro punto. Datos lineales: Algunas entidades representables mediante objetos lineales son las redes de infraestructuras, vías de comunicación, redes de recursos ó redes de transporte. Datos superficiales: Los objetos espaciales superficiales representan áreas. Pueden representar fenómenos naturales como lagos o fenómenos artificiales como zonas de censo, ajardinadas, etc. Figura 2.6: Tipos de geometrías OGC

51 Conceptos previos y herramientas 25 Hay varios tipos de superficies que pueden ser representadas: Zonas de recursos naturales o medioambientales. Por ejemplo: datos geológicos (tipos de material), usos del suelo (bosques, urbano), tipos de suelo (industrial, urbanizable). Zonas socio-económicas. Por ejemplo: códigos postales, distritos, barrios. Zonas con carácter tributario. Por ejemplo: parcelas, uso del suelo, información de tasas. En los objetos espaciales que representan superficies pueden aparecer huecos o islas o áreas de diferentes atributos encerradas íntegramente dentro de ellas. La utilización de una base de datos para almacenar la información cartográfica se vuelve casi imprescindible para acceder a un inmenso volumen de información de forma eficiente. En este sentido la restricción proveniente de los requisitos fué PostgreSQL con la extensión PostGIS que de forma estandarizada proporciona funciones típicas para manejarla de la que se hablará a continuación. La librería OpenLayers, no es un sistema de información geográfica por sí sola, ya que según la definición de SIG deben capturar, manipular, analizar, modelar y representar datos georreferenciados y le falta el almacenamiento de los datos que le aporta una base de datos como PostgreSQL.

52 26 Capítulo PostgreSQL PostgreSQL [2][3] es un motor de base de datos liberado bajo licencia BSD 2, significa que el autor permite su modificación y distribución, pero se reserva el derecho de atribución sobre posibles modificaciones. Aparte de los típicos datos de una base de datos como INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL y TIMESTAMP también soporta el almacenamiento de grandes ficheros binarios incluyendo sonidos, imágenes, o video e incluye interfaces nativas para C/C++, Java,.Net, Perl, Python, Ruby, Tcl, ODBC y otros lenguajes PostGIS PostGIS [4] es un módulo para PostgreSQL que añade soporte para objetos geográficos. Las bases de datos espaciales permiten el almacenamiento y manipulación de datos geográficos usando SQL extendido. PostGIS implementa metadatos y funciones geométricas y topológicas para el tratamiento de los datos espaciales basándose en el estándar Open Geospatial Consortium a partir de ahora abreviado como OGC [5], pero con la ventaja de ser de distribución libre por lo que es ampliamente usado en todo el mundo. Algunas de las funciones más importantes son: AsText: Muestra una geometría en su representación textual. GeomFromText: Traduce una geometría de su formato binario a su representación textual. 2 BSD: Berkeley Software Distribution

53 Conceptos previos y herramientas 27 GeometryFromText: convierte un objeto de la representación textual a un objeto geometría. AddGeometryColumn: Añade una columna a una tabla de la base de datos que contendrá los datos espaciales. Contains: Establece si una geometría dada contiene en su interior otra geometría dada. Difference: Devuelve la diferencia geométrica entre dos geometrías. Intersects: Establece si dos geometrías se intersecan. Buffer: Devuelve una geometría que representa el buffer de una geometría dada. Perimeter: Devuelve el perímetro de una geometría POLYGON dada. Area: Devuelve el área de una geometría POLIGON dada. Length: Devuelve la longitud de una geometría LINESTRING dada. Within: Establece si una geometría se encuentra en el interior de otra dada. Distance: Devuelve la distancia mínima entre dos geometrías dadas. Touches: Establece si dos geometrías dadas son adyacentes. Intersection: Devuelve una geometría resultante de la intersección de dos geometrías dadas. PostGis tiene una API 3 muy bien documentada en su página web, consultar la bibliografía para más información (página 167). 3 API: Interfaz de Programación de Aplicaciones

54 28 Capítulo Paradigma de la orientación a objetos La Programación Orientada a Objetos (a partir de ahora abreviado con el acrónimo POO) es un paradigma de programación que define los programas en términos de clases de objetos, objetos que son entidades que combinan estado (es decir, datos), comportamiento (esto es, procedimientos o métodos) e identidad (propiedad del objeto que lo diferencia del resto). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. De esta forma, un objeto contiene toda la información, (los denominados atributos) que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos). A su vez, dispone de mecanismos de interacción -los llamados métodos- que favorecen la comunicación entre objetos -de una misma clase o de distintas-, y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan -ni deben separarse- información (datos) y procesamiento (métodos). Dada esta propiedad de conjunto de una clase de objetos, que al contar con una serie de atributos definitorios requiere de unos métodos para poder tratarlos (lo que hace que ambos conceptos están íntimamente entrelazados), el programador debe pensar indistintamente en ambos términos, ya que no debe nunca separar o dar mayor importancia a los atributos en favor de los métodos, ni viceversa. Esto difiere de los lenguajes imperativos tradicionales, en los que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. Los programadores que emplean lenguajes orientados a objetos definen objetos con datos y métodos y después envían mensajes a los objetos diciendo que realicen

55 Conceptos previos y herramientas 29 esos métodos en sí mismos. Como conceptos importantes podemos destacar los siguientes: Objeto: entidad provista de un conjunto de propiedades o atributos ( datos ) y de comportamiento o funcionalidad ( métodos ). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas. Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un mensaje. Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un evento con un nuevo mensaje para otro objeto del sistema. Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto, y cuyo valor puede ser alterado por la ejecución de algún método. Estado interno: es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos).

56 30 Capítulo 2 Características de la POO Las características siguientes son las más importantes: Abstracción: Cada objeto en el sistema sirve como modelo de un agente abstracto que puede realizar trabajo, informar y cambiar su estado, y comunicarse con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y, cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. Encapsulamiento: también llamado ocultación de la información. Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. Dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en tiempo de ejecución, esta última característica se llama ligadura dinámica. Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el

57 Conceptos previos y herramientas 31 comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto pertenece a más de una clase se dice que hay herencia múltiple. Esta característica no está soportada por algunos lenguajes (como Java). Para la realización de este proyecto es fundamental tener conocimientos respecto a este paradigma y sus características. Un gran libro de cabecera en este ámbito es Piensa En Java [6]. Teniendo en cuenta las características mencionadas podemos introducir el concepto de patrón, que no es más que una solución a un problema conocido que por su asidua repetición ha sido resuelto de forma óptima. Se hablará de manera más extensa sobre ello en el tema de Patrones de diseño que se encuentra en el capítulo B (página 193). 2.4 Proyecto EIEL El Ministerio de Administraciones Públicas, M.A.P., pide cada cinco años a cada Diputación Provincial, un inventario de los equipamientos e infraestructuras de los municipios de la provincia, junto con sus características, estado, etc. Para proveer al M.A.P. con esta información cada Diputación Provincial debe llevar a cabo la Encuesta de Infraestructuras y Equipamientos Locales (E.I.E.L.) [7]. Para desarrollar dicha encuesta es necesario enviar a todos los municipios de la provincia, un gran equipo de expertos especializados encargados de recabar todos los datos necesarios.

58 32 Capítulo 2 El conjunto de datos requeridos por el M.A.P. incluye una enorme cantidad de datos alfanuméricos y algunos mapas temáticos predefinidos, en los que el estado de las infraestructuras y equipamientos pueda ser reconocido visualmente. Para alcanzar un resultado homogéneo para todas las provincias, el M.A.P. provee a cada Diputación Provincial con un conjunto de cuestionarios que serán rellenados con los resultados de la encuesta, junto con instrucciones para guiar su proceso de rellenado. Es responsabilidad de cada Diputación Provincial el reunir los datos de los cuestionarios, y almacenarlos en una BD con un esquema dado por el M.A.P. La Diputación Provincial de A Coruña decidió hacer frente al problema de realización de la E.I.E.L. del año 2000 mediante un proyecto de dos años firmado con la Universidad de A Coruña, y con unos objetivos más ambiciosos; en concreto: extender la cantidad de información alfanumérica a recabar para los elementos de cada municipio y almacenar también referencias gráficas de los mismos. Con el objetivo de recoger los datos, se formaron tres grupos diferentes de expertos especializados en tres áreas bien diferenciadas. Cada uno de estos tres grupos está actualmente visitando los diferentes municipios, recogiendo los datos reales mediante entrevistas a su respectivo personal responsable en cada municipio, o bien mediante observación directa. Teniendo en cuenta estos grupos de expertos, el conjunto de datos a ser adquirido puede ser clasificado entre los siguientes tres tipos: Información del ciclo del agua, información acerca de infraestructuras (viarios, alumbrado, plan urbanístico, etc) y equipamientos (hospitales, parques, etc). Un cuarto grupo de expertos en cartografía se encarga de tratar la cartografía digital.

59 Conceptos previos y herramientas 33 Figura 2.7: giseiel: Entorno de trabajo El objetivo del proyecto E.I.E.L., es la creacio n de una enorme base de datos (BD) con informacio n tanto alfanume rica como geogra fica asociada a las infraestructuras y equipamientos de la provincia. Las tareas incluidas en este proyecto son, por tanto, el disen o y desarrollo de las aplicaciones necesarias tanto para la creacio n de dicha BD, como para el mantenimiento y explotacio n de la informacio n almacenada. El objetivo de la EIEL es recoger una amplio espectro de informacio n de cada uno de los municipios de menos de habitantes en cada provincia: abastecimiento de agua, saneamiento, servicio de recogida y tratamiento de residuos, alumbrado, acceso a redes de telecomunicaciones, equipamientos, planes de ordenacio n urbanı stica, y red viaria. Todos estos datos se almacenan en tablas alfanume ricas y desde hace ya varios an os se usan herramientas SIG para gestionar y actualizar toda la informacio n.

60 34 Capítulo 2 Si bien el objetivo final del MAP es ajustar el reparto de fondos de cooperación local en función de las necesidades detectadas en dicha encuesta, la magnitud de la misma permite mucho más, especialmente si empleamos tecnología SIG. Una buena estrategia es usar la EIEL de sustrato para la construcción de toda una Base de Datos Territorial provincial, y una Infraestructura de Datos Espaciales. La relación que tiene el presente proyecto con el de la EIEL es que la fuente de datos es la misma, empleando para ello de una copia de seguridad actual de la base de datos, y de particiones municipales en forma de scripts SQL que segmentan la información en función del municipio al que pertenecen. 2.5 Protocolos Figura 2.8: Estándares OpenGIS

61 Conceptos previos y herramientas Web Map Service (WMS) El servicio Web Map Service (WMS) definido por el OGC (Open Geospatial Consortium) produce mapas de datos referenciados espacialmente, de forma dinámica a partir de información geográfica, a través de peticiones HTTP permite indicarle los siguientes información de entrada: Capas a visualizar Estilos a utilizar Sistema de proyección a utilizar Área del mapa deseada Formato de imagen Color de fondo, y si el fondo es transparente. Resolución de la imagen Formato de las excepciones. Existen dos tipos de servicios: WMS Básico: los estilos están predefinidos y no se pueden cambiar. WMS con SLD: los estilos se definen utilizando el estándar SLD. El estándar define tres operaciones: 1. GetCapabilities: Devolver metadatos del nivel de servicio. 2. GetMap: Devuelve un mapa cuyos parámetros geográficos y dimensionales han sido bien definidos. 3. GetFeatureInfo: devuelve información de características particulares mostradas en el mapa (opcionales)

62 36 Capítulo 2 Producen como resultado un mapa en formato de imagen como PNG, GIF o JPEG, y ocasionalmente como gráficos vectoriales en formato SVG (Scalable Vector Graphics) o WebCGM (Web Computer Graphics Metafile). El servicio WMS permite la creación de una red de servidores distribuidos de mapas, a partir de los cuales los clientes pueden construir mapas a medida Web Feature Service (WFS) El objetivo del estándar Web Feature Service (WFS) definido por Open Geospatial Consortium (OGC) es ofrecer servicios web usando el protocolo HTTP para la consulta o modificación de información geográfica desde cualquier fuente que implemente la especificación, pudiendo ser utilizado como mediador. Se distinguen dos tipos diferentes de WFS: WFS Básico: implementa la funcionalidad de consulta y funcionalidades de solo lectura. WFS Transaccional: implementa la funcionalidad de modificación de datos (inserción, actualización o borrado). Además la transacción WFS puede también puede ser serializable si esta es soportado por el servidor e intermediarios mediante las operaciones de LockFeaturey GetFeatureWithLock. Las operaciones que proporciona se pueden resumir los siguientes tipos: Funcionalidad de descubrimiento: Cualquier WFS debe ser capaz de describir las capacidades del propio servicio, la información que puede ser consultada y manipulada por el servicio. Se realizan mediante peticiones HTTP Get y la respuesta obtenida es un fichero XML. La operación GetCapabilities devuelve información del servicio: Nombre, información de contacto, keywords, SRS, Bounding Box.

63 Conceptos previos y herramientas 37 Operaciones soportadas Lenguajes soportados La operación DescribeFeatureType obtiene metadatos de la información: Lista de feature types disponibles Sistemas de coordenadas de cada uno Operaciones soportadas Recuperación de información: Esta es al característica más importante de funcionalidad del servicio y es implementada por la operación GetFeature que como entrada recibe una petición por HTTP Post adjuntando un fichero de entrada que contiene: Nombre del feature type que queremos Propiedades del feature type en el resultado Un filtro (expresado usando Filter Encoding) El formato del resultado: todos los tipos del WFS deben estar soportados por el Geography Markup Language (GML). El WFS y el WMS se suelen confundir debido a la similitud de acrónimos, abuso del lenguaje o desconocimiento: las diferencias entre ambos servicios son notables, la más evidente es en el formato de salida: el WFS proporciona información en formato XML, el WMS proporciona mapas en formato imagen. La sintaxis del XML utilizado para las peticiones del servicio también difiere como se puede ver en la siguiente tabla a nivel sintáctico:

64 38 Capítulo 2 Tabla 2.2: Diferencias entre WFS y WMS sintácticas También varia el nombre de las operaciones en versiones posteriores del WFS 1.X.X por evolución de las espeficaciones de la OGC: Figura 2.9: Diferencias entre WFS y WMS operaciones Geography Markup Language (GML) Geography Markup Language(GML) es una codificación XML para el transporte y el almacenamiento de la información geográfica, incluyendo las propiedades tanto espaciales como no espaciales de los elementos geográficos. A grandes rasgos, un documento GML es un tipo de documento XML que representa información geográfica. GML se diseñó a partir de la especificación abstracta producida por el grupo OpenGIS, y de la serie de documentos ISO

65 Conceptos previos y herramientas 39 GML no contiene información específica sobre como se debe hacer la visualización de los datos representados. Para ello se utilizan estilos que se relacionan a GML y se describen en otros sublenguajes de XML, alguno de los cuales comentaremos a continuación. Los conceptos básicos que utiliza son: Un objeto geográfico se representa mediante una Feature Un conjunto de objetos geográficos se representa mediante una Feature Collection, que también es una feature Las propiedades de los objetos geográficos se representan con Properties Algunas de las propiedades pueden ser geométricas, por lo que su valor es de un tipo de Geometría. La especificación de GML define el esquema XML de la sintaxis, los mecanismos, y las convenciones que: Proveen un marco abierto e independiente del proveedor para la definición de objetivos y esquemas de las aplicaciones geoespaciales. Permiten perfiles que soporten subconjuntos adecuados de capacidades descriptivas en un entorno GML. Ofrecen soporte para la descripción de esquemas de aplicaciones geoespaciales para dominios especializados y comunidades de información. Permiten la creación y mantenimiento de puntos de conexión entre conjuntos de datos y esquemas de aplicaciones geográficas. Ofrecen soporte de almacenamiento y transporte entre aplicaciones y conjuntos de datos. Incrementan la capacidad de las organizaciones para compartir los esquemas de las aplicaciones geográficas y la información que estos describen.

66 40 Capítulo Styled Layer Descriptor (SLD) Styled Layer Descriptor(SLD) es una especificación de implementación de OGC que define un lenguaje XML para representar la definición de estilos de visualización, tanto las capas y origen de los datos, como la apariencia gráfica de los estilos. Implementa numerosas funcionalidades de visualización entre las que destacamos: Mostrar un objeto cartográfico en función de la escala utilizando el rango de escalas de las reglas del estilo. Mostrar objetos de distinta resolución en función de la escala empleando además de las reglas de estilos, los atributos geográficos. Mostrar objetos de distinto tipo en función de la escala. Mostrar mapas temáticos, usando para ello las reglas y filtros. El elemento principal es la etiqueta StyledLayerDescriptor, que contiene una secuencia de definiciones de estilos para las capas o para las entidades. Una capa puede ser predefinida (NamedLayer) o definida por el usuario (UserLayer) y para cada capa se pueden definir filtros: LayerFeatureConstraints y FeatureTypeConstrain. Incluso una capa puede provenir de una fuente de datos remota (RemoteOWS), tener un estilo predefinido (NamedStyle) o definido por el usuario (UserStyle). Un estilo definido por el usuario está compuesto por estilos definidos para cada feature type (FeatureTypeStyle). Para cada uno de estos estilos se pueden definir reglas (Rule) que determinan las condiciones en las que se usa el estilo, como la escala máxima y mínima de visualización. Asociado a cada regla hay un simbolizador (Symbolizer) que determina como se pintan los objetos. Existen diferentes tipos de simbolizadores, dependiendo del tipo de geometría que represente.

67 Conceptos previos y herramientas 41 Destacan: LineSymbolizer: Permite representar los bordes de los objetos PolygonSymbolizer: Se utiliza para dibujar un polígono formado por un relleno interior y una línea de contorno. En primer lugar se dibuja el relleno (Fill) y luego el borde (Stroke). PointSymbolizer: Se utiliza para dibujar elementos puntuales mediante símbolos. TextSymbolizer: Permite colocar etiquetas en los objetos. RasterSymbolizer: Describe como rellenar una cobertura de datos tipo raster. El SLD es necesario para poder aplicar estilos y personalizarlos sobre la cartografía resultante y tener plantillas para la confección de mapas a medida, mientras que el GML se centra en la información geográfica y en su transporte entre servicios. 2.6 Tomcat Tomcat [8] (también llamado Jakarta Tomcat o Apache Tomcat) funciona como un contenedor de servlets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat implementa las especificaciones de los servlets y de JavaServer Pages (JSP) de Sun Microsystems.

68 42 Capítulo 2 Tomcat maneja varios tipos de contenedores, los podemos dividir en: Contenedores de Servlets Stand-alone (Independientes): Estos son una parte integral del servidorweb. Este es el caso cuando usando un servidor web basado en Java. Este es el modo por defecto usado por Tomcat. Contenedores de servlets dentro-de-proceso: El contenedor servlet es una combinación de un plugin para el servidor web y una implementación de contenedor Java. El plugin del servidor web abre una JVM(Máquina Virtual Java) dentro del espacio de direcciones del servidorweb y permite que el contenedor Java se ejecute en él. Si una cierta petición tuviese que ejecutar un servlet, el plugin toma el control sobre la petición y lo pasa al contenedor Java (usando JNI). Un contenedor de este tipo es adecuado para servidores multi-thread de un sólo proceso y proporciona un buen rendimiento pero está limitado en escalabilidad Contenedores de servlets fuera-de-proceso: El contenedor servlet es una combinación de un plugin para el servidor web yuna implementación de contenedor Java que se ejecuta en una JVM fuera del servidor web. El plugin del servidor web y el JVM del contenedor Java se comunican usando algún mecanismo IPC (normalmente sockets TCP/IP). Si una cierta petición debería ejecutar un servlet, el plugin toma el control sobre la petición y lo pasa al contenedor Java (usando IPCs). El tiempo de respuesta en este tipo de contenedores no es tan bueno como el anterior, pero obtiene otras propiedades deseables como son la escabilidad y la estabilidad. La jerarquía de directorios de instalación de Tomcat incluye: bin: arranque, cierre, y otros scripts y ejecutables common: clases comunes que pueden utilizar Catalina y las aplicaciones web conf : ficheros XML y los correspondientes DTD para la configuración de Tomcat logs: logs de Catalina y de las aplicaciones

69 Conceptos previos y herramientas 43 server: clases utilizadas solamente por Catalina shared: clases compartidas por todas las aplicaciones web webapps: directorio que contiene las aplicaciones web work: almacenamiento temporal de ficheros y directorios Figura 2.10: Gestor de Aplicaciones Web de Tomcat Nuestra herramienta se sirve de Tomcat para manejar el GeoServer y contenedor del gestor de contenidos Liferay y el portlet realizado que contiene el visor hecho en JSP que accede a la base de datos en la que se han almacenado las páginas.

70 44 Capítulo Liferay Liferay [9] es un portal de gestión de contenidos de código abierto escrito en Java desarrollado por la empresa Liferay, Inc. Se creó en 2000 en principio como solución para las organizaciones sin ánimo de lucro. Liferay es un servidor de aplicaciones J2EE EJB que ha sido internacionalizado a más de 20 idiomas. Emplea las siguientes tecnologías: Apache ServiceMix, ehcache, Hibernate, Java J2EE/JEE, jbpm, ICEfaces, jquery, JavaScript Framework, Lucene, MuleSource ESB, PHP, Ruby, Seam, Spring & AOP, Struts & Tiles, Tapestry, Velocity. Soporta los siguientes estándares: AJAX y JSON, icalendar y Microformat, JSR- 286, JSR-127, JSR-170, Portlet 2.0, JSF-314, JSF 2.0, OpenSearch, Web Services, Hessian, Burlap, REST, RMI, WSRP y WebDAV. Este portal está dividido en tres productos principales: 1. Liferay Portal: JSR-286 Enterprise Portal Platform 2. Liferay CMS: Content Management System (Gestión de contenidos) 3. Liferay Collaboration Suite: el software de colaboración (blogs, mensajería instantánea, tablones de mensajes, etc)

71 Conceptos previos y herramientas 45 Figura 2.11: Pantalla inicial de Liferay Liferay Portal está disponible en dos versiones, pudiendo contratar en ambas versiones servicios de consultoría y formación: 1. Liferay Portal Enterprise Edition: la oferta comercial que incluye soporte completo. Suele ser una version más estable que la SE con aspectos personalizados. 2. Liferay Portal Standard Edition: la versión gratuita con las últimas características y el apoyo a través de la activa de la comunidad. Internamente Liferay es un sistema muy complejo en el que participan personas, por lo que es vital para el mantenimiento que la aplicación esté muy bien estructurado. Aquí podemos ver la estructura interna del modelo que mantiene:

72 46 Capítulo 2 Figura 2.12: Diagrama de clases del modelo interno de Liferay 2.8 Java Server Pages (JSP) JavaServer Pages (JSP) es una tecnología Java, desarrollado por la compañía Sun Microsystems, que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. Las JSP s permiten la utilización de código Java mediante scripts. Además, es posible utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden ser enriquecidas mediante la utilización de Librerías de Etiquetas (TagLibs o Tag Libraries) externas e incluso personalizables. Una página JSP es un tipo especial de servlet orientado a generar el texto de la

73 Conceptos previos y herramientas 47 interfaz gráfica. Este tipo de páginas necesitan de un programa que las contenga, envíe efectivamente páginas web al servidor, y reciba las peticiones, las distribuya entre los servlets y lleve a cabo todas las tareas de gestión propias de un servidor web. La primera vez que se accede a una página JSP el servidor de aplicaciones genera un servlet a partir de la página JSP, lo compila y lo carga en memoria. Si no es la primera vez, le pasa la petición al servlet anteriormente generado. Una página JSP es también una página web por lo que permite la inclusión de código HTML, pero además también permite añadir código Java, aunque no es una buena práctica porque no permite una separación clara de roles. Para solucionarlo se hace uso de librerías de tags JSP que permiten realizar diversas acciones sobre los elementos de una página web, tales como iteración sobre colecciones, internacionalización de mensajes, acceso a documentos XML, etc. 2.9 Portlet Los portlets [10] [11] [12] son componentes modulares de interfaz de usuario gestionadas y visualizadas en un portal web. Los portlets producen fragmentos de código de marcado que se agregan en una página de un portal. Típicamente, siguiendo la metáfora de escritorio, una página de un portal se visualiza como una colección de ventanas de portlet que no se solapan, donde cada una de estas muestra un portlet. Por lo tanto un portlet (o colección de portlets) se asemeja a una aplicación web que está hospedada en un portal. Como por ejemplo, un portlet de aplicación puede ser para el correo, el parte meteorológico, un foro, noticias, etc. Se pretende que los estándares de los portlets permitan al desarrollador de software crear portlets que puedan ser utilizados en cualquier portal que soporte estos estándares.

74 48 Capítulo 2 Los portlets son similares a los servlets en que: Los portlets son manejados por un contenedor especializado Los portlets generan contenido dinámicamente El ciclo de vida de los portlets es controlado por el contenedor Los portlets interactúan con el cliente web mediante el uso del paradigma request-response Los portlets son diferentes a los servlets en que: Los portlets son únicamente generados como fragmento de etiquetado y no como documentos completos. Los portlets no están asociados directamente a una URL. Los portlets no pueden generar contenido arbitrario, ya que el contenido de los portlets va a estar incluido en la página del portal. Si un servidor de un portal esta solicitando text/html, entonces todos los portlets deben ser generados en text/html. Por otro lado si el servidor del portal esta solicitando por WML, entonces cada portlet deberá ser generado en contenido WML Almacenamiento persistente para las preferencias Los portlets proporcionan un objeto PortletPreferences para almacenar las preferencias de usuario. Estas preferencias son almacenadas en una base de datos persistente, así se encontrarán disponibles cada vez que el contenedor de portlets se reinicie. Como desarrollador no es necesario preocuparse por la implementación del almacenamiento Procesamiento de solicitudes Los portlets disponen de una manipulación de peticiones más refinada. Un portlet puede obtener su solicitud cuando el usuario hace alguna acción sobre éste. (Un estado llamado Action phase (Fase de acción)), o porque el usuario adoptó medidas sobre otro portlet y la página necesita ser actualizada. Un portal dispone de diferentes métodos callback para el manejo de ambas situaciones.

75 Conceptos previos y herramientas Modos de los Portlets Los portlets usan el concepto de mode para indicar qué está haciendo el usuario. Cuando usamos una aplicación de correo electrónico, puede ser usada para leer, escribir o revisar los mensajes del correo Estas se esperan que sean las funcionalidades que posee una aplicación de correo electrónico. Los portlets normalmente proporcionan esto en un modo Vista (VIEW). Pero hay otras actividades, como especificar el tiempo de actualización o la (re-)configuración de datos como el nombre de usuario y la contraseña. Estas actividades permiten al usuario configurar el comportamiento de la aplicación, por lo que se encuentran bajo el modo EDITAR (EDIT). La funcionalidad de ayuda de una aplicación de correo se enmarca sobre el modo de AYUDA (HELP). De esta manera para la lógica de negocio es necesario relacionar lógicamente un método doview() para el modo de vista, de igual manera doedit() para la configuración de la aplicación y otro método dohelp() para lo relacionado con la ayuda. Esto hace sencillo para el administrador controlar el acceso al portlet, porque todo lo que se tiene que hacer es cambiar los derechos de acceso del portlet y de esta manera establecer qué cosas se permite hacer al usuario Estado de la ventana El estado de una ventana determina la cantidad de espacio que podría asignársele al contenido generado por un portlet sobre el portal. Si se pulsa en el botón maximizar, el portlet utiliza todo el espacio disponible en la pantalla; de igual forma, si éste pasa a estado minimizado, únicamente se mostrará la barra de título asociada al portlet Información de Usuario Comúnmente, los portlets proporcionan contenido personalizado de acuerdo a los requerimientos del mismo. Para hacer esto efectivamente, es necesario contar con atributos como nombre, correo electrónico, teléfono, etc. El API de portlet dispone para esto el concepto de atributos de usuario (user attributes). Estándares de portlets

76 50 Capítulo 2 El propósito del protocolo WSRP [13] (Web Services for Remote Portlets) es suministrar un estándar de servicios web que permita el plug-and-play de portlets en ejecución remotos desde fuentes dispares. Muchos sites permiten a los usuarios registrados personalizar su vista del sitio web activando o desactivando porciones de la página web, o añadiendo o eliminando características. Esto normalmente se realiza por parte de un conjunto de portlets que juntos forman el portal Especificación JSR-168 La Java Specification Request V1.0 (JSR-168) [14] fue desarrollada bajo el Java Community Process (JCP) es un etándar que permite la interoperabilidad de los portlets entre portales web diferentes. Esta especificación define un conjunto de API para interacción entre el contenedor portlet y el portlet que direcciona áreas de personalización, presentación y seguridad. Esta versión de la especificación introduce el modelo básico de programación de portlets con los siguientes elementos: Dos fases de procesamiento y renderización, a fin de soportar el patrón de diseño Modelo Vista Controlador. Modalidades de portlet, habilitando el portal para notificar al portlet que una tarea se debería ejecutar y el contenido que debería generar. Estados de las ventanas, indicando la cantidad de espacio de la página que deberá ser asignado a el contenido generado por el portlet. Modelo de datos del portlet, permitiendo al portlet almacenar información vista en los parámetros de renderización, información relacionada con la sesión en la sesión del portlet y por datos persistentes de usuario en las preferencias del portlet. Un paquete de formato, con el fin de agrupar diferentes portlets y otros artefactos J2EE requeridos por esos portlets en una aplicación portlet la cual puede ser utilizada en el servidor del portal.

77 Conceptos previos y herramientas 51 Existen multiples implementaciones basadas en estándares tanto comerciales como OpenSource. Ejemplo de vendedores vendedores comerciales líderes son IBM, Oracle y BEA Systems. Ejemplos de soluciones de portales open-source que soportan JSR168, son Apache Jetspeed-2 Enterprise Portal, JBoss Portal, Liferay Portal y Stringbeans Portal Especificación JSR-286 Java Portlet specification v2.0 (JSR-286) [15] [16] fué desarrollado para mejorar las deficiencias de la versión 1.0 creada en alineación con la versión precedentes de Servicios Web para Portlets Remotos (en inglés Web Services for Remote Portlets WSRP). Algunas de las caraterísticas más importantes son: Comunicación entre Portlets a través de eventos y renderización de parámetros públicos. Sirviendo recursos generados dinámicamente de forma directa mediante los portlets. Sirviendo datos de AJAX o JSON de forma directa mendiante los portlets. Introducción de filtros y escuchas de portlets Geoserver GeoServer [17] es un servidor de código abierto escrito en Java que permite a los usuarios compartir y editar los datos geoespaciales. Diseñado para la interoperabilidad, que publica los datos de cualquier fuente importante de datos espaciales usando estándares abiertos. GeoServer ha evolucionado hasta convertirse en un método fácil de conectar la información existente para mundos virtuales como Google Earth y NASA World Wind [18], así como mapas basados en web como Google Maps y Windows Live Local.

78 52 Capítulo 2 GeoServer es la implementación de referencia del Open Geospatial Consortium estándar Web Feature Service, y también implementa el servicio Web Map Service y Web Coverage especificaciones de servicio. GeoServer lee una variedad de formatos de datos, incluyendo PostGIS, Oracle Spatial, ArcSDE, DB2, MySQL, Shapefiles, GeoTIFF, GTOPO30, ECW, MrSID y JPEG2000. A través de protocolos estándar que produce KML, GML, Shapefile, GeoRSS, PDF, Geo JSON, JPEG, GIF, SVG, PNG y más. Además, se puede editar los datos a través del perfil de la CMA transaccionales (WFS-T). GeoServer incluye un cliente integrado OpenLayers para la previsualización de las capas de datos. GeoServer, además, apoya la publicación eficiente de los datos geoespaciales de Google Earth a través de la utilización de enlaces de red, utilizando KML. Las funciones avanzadas de Google Earth incluye plantillas de salida de pop-ups personalizada, el tiempo y las visualizaciones de altura, y super-overlays. GeoServer se basa en GeoTools, un sistema de información geográfica de la colección. Figura 2.13: Pantalla inicial de Geoserver

79 Conceptos previos y herramientas OpenLayers OpenLayers [19][20]es una biblioteca JavaScript libre (con licencia BSD) que nos permite mostrar mapas de datos en los navegadores Web, sin dependencias del lado de servidor. OpenLayers implementa un API JavaScript para la construcción de aplicaciones Web de contenidos geográficos, similares a los APIs de Google Maps y Yahoo Maps. Proporciona una interfaz agradable con facilidad de uso para la navegación por ratón y teclado, controlando, posibilidad añadir marcadores y seleccionar las capas visibles etc. Figura 2.14: Visor OpenLayers Como un marco de trabajo, OpenLayers emplea métodos estándar de industria para el acceso de datos geográficos separando las herramientas para el manejo de mapas de los datos representados en él del origen de los datos.

80 54 Capítulo 2 Figura 2.15: Protocolos soportados por OpenLayers

81 Conceptos previos y herramientas Herramientas de desarrollo Software Descripción Versión Base de datos GisEIEL Información cartográfica 1/10/2009 PostgreSQL Gestor de base de datos 8.1 PostGis Plugin para soporte de cartografía 1.3 pgadmin III PostGreSQL Tools Entorno de trabajo Eclipse Entorno de desarrollo Visual Editor Plugin eclipse para la edición para la creación de interfaces Java 1.4 m2eclipse Integración con maven Ant Herramienta de software para la gestión y construcción de proyectos Java Maven Herramienta de software para la gestión y construcción de proyectos Java UltraStudio Editor de texto muy potente 9.10 Adobe Acrobat Professional Visor y editor de PDF s 9.0 Compiladores Java JRE+JDK Lenguaje programación multiplataforma de Sun JSP JavaScript Server Pages 2.0 JSTL JavaServer Pages Standard Tag Library 1.1 MiKTeX Compilador LaTeX 2.8 Navegadores Web Mozilla Firefox Navegador multiplataforma y libre Firebug Extensión de Firefox para la depuración javascript Google Chrome Navegador libre basado en el motor Chromium Gestores de contenidos (CMS) Liferay Gestor de contenidos para despliegue JBoss Portal Gestor de contenidos para pruebas Contenedor de Servlets Apache Tomcat Servidor aplicaciones Web Servicios Geoserver Servicios WMS, WFS Librería Javascript OpenLayers Visor de datos geográfico en Web 2.8 Memoria WinEdt Entorno LaTeX 5.6 LaTeX Compilador MiKTeX 2.7 Planificadores Microsoft Project Planificación 2003 Gráficos MagicDraw Personal Edition Creación de Diagramas UML 12.5 Dia Realización de objetos vectoriales 0.96 Adobe Photoshop Editor de imágenes avanzada CS3 AcdSee Editor / visor de imágenes 9.0 Sistemas Operativos Windows XP Professional SP3 Sistema operativo de Microsoft Presentación Microsoft PowerPoint Transparencias para la presentación 2003 Tabla 2.3: Tabla Herramientas

82 56 Capítulo 2

83 CAPÍTULO 3 APLICACIONES SIMILARES 3.1 Aplicaciones de gestión de contenidos Existen infinidad de alternativas existentes con el que publicar en internet contenidos municipales de forma sencilla, motivo por el cual se citarán las características más relevantes consideras como alternativas viables, que han sido probadas con la configuración similar al del proyecto. Existe una web CMSMatrix [21] que recopila y analiza exhaustivamente cada aspecto de cada uno de ellos, con búsqueda según criterios e información técnica detallada. En el capítulo de análisis (93) se explicará en detalle los criterios y los motivos de la elección final ha sido Liferay. 57

84 58 Capítulo 3 Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Última Actualización 08/10/ /08/2007 6/19/ /06/ /11/ /26/2007 2/26/2009 Requisitos del sistema Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Application Server J2EE Zope J2EE J2EE CGI J2EE Apache Costo aproximado Gratuita / Profesional Gratuita Gratuita Gratuita Gratuita Gratuita Gratuita Base de datos DB2 Otra Oracle Otra MySQL Otra MySQL Licencia MIT Open Source Open Source Open Source Open Source Open Source Open Source Sistema Operativo Plataforma Plataforma Plataforma Plataforma Plataforma Plataforma Plataforma Lenguaje de programación Java Python Java Java PHP Java PHP Acceso de root Si No No Si No No No Acceso Shell Si Si No Si No Si No Servidor Web Otra Apache Apache Apache Apache Otra Apache Seguridad Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Auditoria de prueba Si Si Si Si No Si Si Captcha Si Extensión gratuita Si Si Extensión gratuita No Extensión gratuita La aprobación de contenido Si Si Si Si Si Si Si Verificación de correo electrónico Extensión gratuita Si No Si Si No Si Granular de privilegios Si Si Si Si No Si Si La autenticación Kerberos Si Extensión gratuita No Si No No No Autenticación LDAP Si Si Costes extras Si Si Si Extensión gratuita Historia Login Si Extensión gratuita Si Si Si No Si NIS Authentication No Extensión gratuita No Si No No No La autenticación NTLM Si Extensión gratuita No Si No No Extensión gratuita Pluggable Authentication Si Si Costes extras Si Si Si Si Notificación de problemas No Extensión gratuita Si Si No No No Sandbox Si Si Si Si No No No Gestión de Sesiones Si Extensión gratuita Si Si Si No Si La autenticación SMB No Extensión gratuita No No No No No SSL Compatible Si Si Si Si Si Si Si Inicios de sesión SSL Si Extensión gratuita Si Si Si No No Páginas de SSL Si No Si Si Si Si No Control de versiones Si Si Si Si Extensión gratuita Si Si Soporte Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Programa de Certificación Si No Limitada Si No Si No Código de esqueletos Si Si Si Si No No Si Manuales comerciales Si Si Si Si Si Si Si Soporte Comercial Si Si Si Si Si Si Si Formación Comercial Si Si Si Si Si Si Si Comunidad de Desarrolladores Si Si Si Si Si Si Si Ayuda en línea Si Si Si No Si Si Si Pluggable API Si Si Si Si Si Si Si Hosting Profesional Si Si Limitada Si Si No Si Servicios profesionales Si Si Si Si Si Si Si Foro Público Si Si Si Si Si Si Si Lista de correo pública Si Si Si Si No Si Si Test Framework Limitada Si Si Si Si No Extensión gratuita Terceros desarrolladores Si Si Si Si Si Si Si Conferencia de Usuarios Si Si Si Si Si Si Si Facilidad de uso Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Drag-N-Drop Contenido Si Si Limitada Si No Si Extensión gratuita Enviar a un debate Si Extensión gratuita No Si Extensión gratuita No Extensión gratuita URLs amistora Si Si Si Si Si Si Si Cambiar el tamaño de la imagen Si Si Si Si Si No Extensión gratuita Macro Lenguaje Si Si No Si Si Si Extensión gratuita Cargars masivas Si Si Si Si Si Si Extensión gratuita Prototipos Si Si No Si Si No Limitada Servidor de páginas Idioma Si Si Si Si Si Si Si Asistente para la instalación de la web Limitada No No Si No No Limitada Corrector ortográfico Si Extensión gratuita Extensión gratuita Extensión gratuita No No Extensión gratuita Del estilo del mago Limitada Extensión gratuita Extensión gratuita Si No No Limitada Suscripciones Si Si Extensión gratuita Si Costes extras No Extensión gratuita Lenguaje de plantilla Si Si Si Si Si Si Limitada Los niveles de la interfaz de usuario Si Si Si Si Si Si No Deshacer Limitada Si Si Si No Si Limitada Editor WYSIWYG Si Si Si Si Si Si Extensión gratuita Archivos Zip Si Extensión gratuita Limitada Si No No No Rendimiento Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Caché avanzada Si Si Si Si Si Si Si Base de datos de replicación Si Si Costes extras Si No No Limitada Equilibrio de carga Si Si Costes extras Si Si Si Si Página en Caché Si Si Si Si Si Si Si Exportación de contenido estático Si Extensión gratuita Si Si No No No

85 Aplicaciones similares 59 Gestión Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Gestión Publicitaria Si Extensión gratuita No No Si No Extensión gratuita Gestión de Activos Si Si Si Si Si No Si Portapapeles No Si No Si No No No Contenido de Programación de Si Si Si Si Si Si Extensión gratuita Contenido de ensayo Si Extensión gratuita Si Si No No Extensión gratuita Administración en línea Si Si Si Si Si No Si Administración en línea Si Si Si Si Si Si Si Implementación de paquetes Si Si Limitada Si No Si No Sub-sitios / Roots Si Si Si Si Si Si Si Temas / Skins Si Si No Si Si Si Si Papelera No Extensión gratuita Si No Si No No Estadísticas Web Limitada Extensión gratuita No Extensión gratuita Si No Si Gestión de Plantillas Si Si Si Si Si Si Si Gestión de Traducción Si Si Limitada Si Extensión gratuita Si Si Motor de flujo de trabajo Limitada Si Extensión gratuita Si No Si Limitada Interoperabilidad Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Sindicacion de contenidos (RSS) Si Si Extensión gratuita Si Si Si Si Soporte FTP Limitada Si No Si Si Si Limitada ical Si Extensión gratuita No Limitada No Si Extensión gratuita UTF-8 Si Si Si Si Si Si Si WAI Compliant Limitada Si Limitada Si No No Limitada Soporte WebDAV Si Si Si Si No Si No XHTML Compliant Si Si Si Si No Limitada Si Flexibilidad Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 CGI-mode Support No Si No Si Si No Si Reutilización de contenido Si Si Si Si Si Si Limitada Extensible de perfiles de usuario Limitada Si Si Si Si Si Si Interfaz de localización Si Si Si Si Si Si Si Metadatos Si Si Si Si Si Si Si Contenido multilingüe Si Si Si Si Extensión gratuita Si Si Contenido integración multilingüe Si Si Si Si Extensión gratuita Si Extensión gratuita Multi-sitios de implementación Si Si Si Si Extensión gratuita Si Si Reescritura de URL Si Si Si Si Si No Si Aplicaciones integradas Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 Blog Si Si No No Si No Si Chat Si Extensión gratuita No No Extensión gratuita No Extensión gratuita Anuncios No Extensión gratuita No No Extensión gratuita No Extensión gratuita Gestión de Contactos Si Extensión gratuita No Si Si Si Extensión gratuita Entrada de datos No Extensión gratuita No Si Extensión gratuita Extensión gratuita Extensión gratuita Informes de base de datos No Si Costes extras No Extensión gratuita No No Discusión / Foro Si Extensión gratuita No Si Extensión gratuita Si Si Gestión de documentos Si Si No Si Extensión gratuita Si Limitada Calendario de Eventos Si Si Extensión gratuita Si Extensión gratuita Si Extensión gratuita Gestión de Eventos Limitada Si Si Costes extras Extensión gratuita No Extensión gratuita Informes de gastos Limitada Extensión gratuita No No Extensión gratuita No No FAQ de administración Limitada Extensión gratuita Extensión gratuita Si Si No Si Distribución de archivos Si Si Extensión gratuita Si Extensión gratuita Si Extensión gratuita Gráficos y tablas Extensión gratuita Extensión gratuita No No Extensión gratuita No No Groupware Si Extensión gratuita No No Extensión gratuita Si Extensión gratuita Guest Book Si Extensión gratuita No Extensión gratuita Extensión gratuita No Extensión gratuita Help Desk / Bug informes Costes extras Extensión gratuita No No Extensión gratuita No Extensión gratuita Proxy HTTP Si Extensión gratuita No No No No No In / Out Board No Extensión gratuita No No No No No Anuncios de Trabajo No Extensión gratuita Costes extras No Extensión gratuita No Extensión gratuita Vincular la gestión de Si Si Si Limitada Si No Extensión gratuita Formulario de correo Si Extensión gratuita Si Si Si Extensión gratuita Extensión gratuita Matrix No No No No No No No My Page / Dashboard Si Si No No No Si Extensión gratuita Boletín Limitada Extensión gratuita Extensión gratuita Si Extensión gratuita No Extensión gratuita Galería de fotos Si Si Si Si Extensión gratuita No Extensión gratuita Encuestas Si Extensión gratuita Extensión gratuita Si Si No Si Gestión de Producto Limitada Si Costes extras Si Si Si Extensión gratuita Control de proyectos Limitada Extensión gratuita No No Extensión gratuita No Extensión gratuita Motor de búsqueda Si Si Si Si Si Si Si Mapa del sitio Si Si Si Si Extensión gratuita Si Extensión gratuita Las cotizaciones de acciones Si Extensión gratuita No No Extensión gratuita No Extensión gratuita Encuestas Si Extensión gratuita Extensión gratuita No Extensión gratuita No Extensión gratuita Sindicado de contenidos (RSS) Si Si Extensión gratuita Si Si Si Si Pruebas / Tests No Extensión gratuita No No Extensión gratuita No Extensión gratuita El tiempo de seguimiento Costes extras Extensión gratuita No No No No Extensión gratuita Contribuciones del usuario Si Si Extensión gratuita Si Si Si Si Tiempo Si Extensión gratuita No No Extensión gratuita No Extensión gratuita Web Services Front End Si No No No Si Si Limitada Wiki Si Extensión gratuita No Limitada Extensión gratuita Extensión gratuita Extensión gratuita Comercio Liferay Portal 5.2 Plone 3.0 OpenCms 7.5 JBoss Portal Joomla! exo Platform 1.0 Drupal 6.10 De seguimiento del afiliado No No No No Extensión gratuita No Extensión gratuita Gestión de inventario Si Extensión gratuita No No Extensión gratuita No Extensión gratuita Pagos Limitada Extensión gratuita No No Extensión gratuita No Extensión gratuita Compras Limitada Extensión gratuita No No Extensión gratuita No Extensión gratuita Tasas Limitada Extensión gratuita No No Extensión gratuita No Extensión gratuita Punto de Venta Si Extensión gratuita No No Extensión gratuita No No Cesta de compra Si Extensión gratuita Extensión gratuita Costes extras Extensión gratuita No Extensión gratuita Suscripciones No Extensión gratuita No No Extensión gratuita No Extensión gratuita Listas de deseos No No No No Extensión gratuita No Extensión gratuita Tabla 3.1: Comparativa CMS

86 60 Capítulo JBoss Portal Principales características: Producto de licencia de código abierto sin coste adicional. Cumple los estándares. Confiable a nivel de empresa Incrustable, orientado a arquitectura de servicios. Flexibilidad consistente Servicios del middleware para cualquier objeto de Java Ayuda profesional 24x7 de la fuente Soporte completo para JMX Carece de soporte de mapas geográficos de serie, no obstante se pueden encontrar portlets genéricos para integrarlo únicamente con Google Maps. Igualmente los portlets implementados en este proyecto son totalmente funcionales sobre este gestor (probado y verificado). Para más información consultar la web de la bibliografia [22] Plone Plone [23] es un Sistema de Gestión de Contenidos o CMS por sus siglas en inglés (Content Management System), basado en Zope (que tiene miles de desarrolladores en todo el mundo) y programado en Python. Es un desarrollo basado en código abierto. Plone puede utilizarse para construir portales, sitios webs corporativos, sitios de noticias, servidor de extranet o intranet, como sistema de publicación, repositorio de documentos, herramienta colaborativa (Groupware), comercio en

87 Aplicaciones similares 61 línea (E-commerce). Principales características: Producción muy rápida Enfocado en los contenidos/documentos La utilización adecuada de carpetas virtuales y flujos de trabajo le permiten adaptarse a múltiples funciones. Entorno gráfico tipo web. Gestión de contenido deslocalizado Edición de las páginas en tiempo real Colaboración fácil Localización de la interfaz en modo nativo Documentación en español Existe una extensión denominada Pleides [24] con capacidades de geolocalización y de visualización de cartografía de Google Maps o mapas de Openlayers. No obstante es una versión muy inestable que nunca llegó a funcionar, además de estar escriba en Python, que por los requisitos del proyecto quedó descartada. PrimaGis [25] es otra extensión de Plone para visualizar mapas (año 2006). Además de los mismos problemas que el anterior, solo esta soportado MapServer, siendo totalmente obsoleta para versiones actuales de GeoServer.

88 62 Capítulo Drupal Drupal [26] es un sistema de gestión de contenido para sitios Web. Permite publicar artículos, imágenes, u otros archivos y servicios añadidos como foros, encuestas, votaciones, blogs y administración de usuarios y permisos. Drupal es un sistema dinámico: en lugar de almacenar sus contenidos en archivos estáticos en el sistema de ficheros del servidor de forma fija, el contenido textual de las páginas y otras configuraciones son almacenados en una base de datos y se editan utilizando un entorno Web incluido en el producto. Principales características: Multiplataforma Independencia de gestor de bases de datos Lenguaje PHP Multi-idioma Administración web Generación de estadísticas y reporting Cacheo avanzado Gran cantidad de módulos: foros, blogs, votaciones, encuestas Control de versiones Plantillas predefinidas Sistema de permisos basado en roles/grupos Ayuda online

89 Aplicaciones similares 63 Figura 3.1: Interfaz Web Drupal Desde el 21 de agosto de 2009 existe un un proyecto Drupal OpenLayers [27] con implementación funcional para extender la funcionalidad de Drupal con OpenLayer, es decir, cuando el presente proyecto estaba en las fases finales de implementación fue oficialmente liberado. De todos modos no hubiera sido válido ya que está no está implementado siguiendo el estándar JSR-286.

90 64 Capítulo 3 Figura 3.2: Extension de Drupal con Openlayers Tiene otros plugins útiles geográficos para su integración con Google Maps (Gmap) [28] [29] y otros para la Geolocalización en local Geo [30] usando PostGis OpenCMS OpenCms [31] es un sistema de gestión de contenido de fuentes abiertas basado en Java y en tecnología XML. Es distribuido por la empresa Alkacon Software bajo licencia LGPL. Se trata de una aplicación CMS con características tales como Entorno de trabajo basado en navegador web, Gestión de activos, Sistemas de gestión de usuarios y permisos integrados, Publicación de contenidos basada en proyectos, Gestión de Workflow y tareas, Editor WYSIWYG, Soporte a la internacionalización, Versionado del contenido, Mecanismos de plantillas JSP y XML, Soporte Multi-idioma, Sistema de Ayuda Online, Publicación dinámica y estática de contenidos, Personalización, Sistemas de cacheo integrados, Mecanismo modular para las extensiones, Sistema de programación de trabajos, Mecanismo de Sincronización, Importación y Exportación de Contenidos, Integración con el servidor de aplicaciones, soporte para EJB y muchos más...

91 Aplicaciones similares 65 Principales características: Multiplataforma Lenguaje Java Multi-idioma (UTF-8) Soporte de tecnología AJAX Función deshacer (Undo) Motor de búsqueda Lucene Edición directamente en producción (Direct Edit) Previsualización de los cambios Posibilidad de programar la puesta en producción de un cambio (time warp) Cacheo avanzado No dispone de ninguna extensión con soporte cartográfica actualmente, el mayor inconveniente para su implementación es que toda la documentación disponible está en idioma inglesa y no soportaba una base de datos Postgres Joomla Principales características de Joomla [32]: Multiplataforma Lenguaje PHP Administración web Generación de estadísticas y reporting Cacheo avanzado URLs amigables

92 66 Capítulo 3 Gran cantidad de extensiones/módulos: foros, encuestas, blogs Administración web Dispone tanto extensiones para soporte de mapas en Google maps y otra extensión WISroGIS [33] de pago en varias versiones disponibles Visitor, Weather o PowerPack que varian en la funcionalidad incluída (el precio oscila desde los 29.90e hasta los 88.90e por unidad). Incluye la versión más completa algunos detalles interesantes como es la personalización de mapas, información de tiempo, localización de visitantes web. Excepto en algunos detalles interesantes como es el cálculo de rutas, la extensión desarrollada es equivalente, siendo otra opción viable si el precio y la licencia no fueran un impedimento. Soporta todo tipo de fuentes (Google Maps, Yahoo! Maps, Microsoft Virtual Earth, MultiMap, Map24, OpenStreetMap, MapServer CGI, WMS, WFS). Figura 3.3: Extensión WISroGIS sobre Joomla

93 Aplicaciones similares exoplatform exo Platform es un portal de código abierto que emplea estándares abiertos y multiplataforma empleando tecnología Java. El proyecto de Plataforma de exo se inició en 2003 como una aplicación del portlet primera API (JSR168). Gran parte del esfuerzo invertido de la plataforma se basa en la innovación tecnológica y en el diseño de la misma. Tiene una gran cantidad de variedades del portal en función de las necesidades finales a la que va ser destinada: 1. exo Portal: plataforma portal que soporta los siguientes estándares: JSR-168, JSR-286, WSRP (v1.0 y v2.0), y JSR exo Enterprise Content Management (ECM): Sistema de gestión de Contenidos (CMS). 3. exo Collaboration Suite (CS): Software de colaboración (blogs, instant messaging, mensajería instantánea, etc.) 4. exo WebOS: Interfaz Web interface que permite al usuario manipular cualquier aplicación Web inluídos portlets y gadgets en exo Portal. 5. exo Portler Container (PC): Implementación de la API de los portlets (JSR-168, JSR-286) y WSRP (v1.0 y v2.0) usadas en exo Portal 6. exo Java Content Repository (JCR) - Implementación del estándar JSR- 170 que es usando en varios lugares de exo Platform 7. exo Social: Solución para implementar una red social en la empresa usando Google Gadgets y OpenSocial.

94 68 Capítulo 3 Principales características: Multiplataforma Atractiva interfaz de usuario Independencia de gestor de bases de datos Lenguaje Java Wizards para la creación rápida de páginas JSR 168 y JSR 286 Lenguaje Java Soporte de tecnología AJAX Single-Sign-On (SSO) Interfaz de usuario Web 2.0 Contenido en función del rol Sistema de permisos basado en roles/grupos Por su integración con los Google Gadgets permitiría únicamente su integración con Google Maps. Al soportar la API JSR 286 igualmente que en algunos de los casos anteriores puede ser los portlets desarrollados en el presente proyecto e instalables en este portal. 3.2 Proyecto Web municipal de Castellón Este proyecto trata la creación de un portal web oficial desarrollado dentro de los planes de asistencia técnica de la Diputación de Castellón [34] con las Entidades Locales de la provincia de Castellón. El proyecto está desarrollado al 100 % en Software Libre, incluyendo un gestor de contenidos y el almacenamiento en los servidores de la Diputación de Castellón.

95 Aplicaciones similares 69 El objetivo principal es garantizar la presencia en internet de todas las Entidades Locales de la provincia por pequeñas que estas sean e impulsar el acceso electrónico de los ciudadanos de la provincia a la administración local. Figura 3.4: Proyecto Web Municiapl Castellón Como experiencia anterior, ha tiene cerca de 100 ayuntamientos adheridos al proyecto. Gran parte de su éxito es la realización de cursos de formación periódicos, concursos, documentación de gran calidad y la obligatoriedad desde la administración de la publicación información urbanística en internet para acreditar fehacientemente la transparencia a los ciudadanos. La iniciativa con respecto al presente proyecto es idéntica, con pequeñas diferencias tecnológicas como por ejemplo que en este caso el gestor de contenidos elegido fué Drupal.

96 70 Capítulo Proyectos concretos Web del municipio de Arañuel Es un caso concreto de la iniciativa de la diputación de Castellón [35]. Figura 3.5: Municipio de Arañuel Aunque carece de soporte de mapas del municipio, dispone de información básica: 1. Ayuntamiento: mensaje del alcalde de bienvenida 2. Tablón de anuncios: avisos de eventos. 3. Directorio: direcciones de contacto básicas 4. El municipio: contiene fotos del patrimonio histórico del municipio.

97 Aplicaciones similares Web del municipio de Abegondo El municipio de Abegondo [36] dispone de un visor geográfico muy completo desarrollado por Enxenio S.L., desarollada con tecnología javascript, que dispone de gran capacidad de navegabilidad, impresión de mapas, búsqueda de información, utiliza información propia (permitiendo activar y desactivar capas, incluso personalization de la opacidad) y emplea ortofotos de PNOA y SigPac, permitiendo a mayores solapar información de Catastro. El único problema que tiene es que es una web estática y personalizada a un caso concreto no permitiendo configuración dinámica y que los costes pueden ser elevados. Figura 3.6: Municipio de Abegondo

98 72 Capítulo Web del municipio de Corcubión El visor del municipio de Corcubión [37] ha sido desarrollado por la empresa Sixtema, es muy parecido en operabilidad al caso de Abegondo, con los mismos problemas por falta de personalización dinámicamente y los posibles costes prohibitivos para un municipio pequeño. Figura 3.7: Municipio de Corcubión

99 Aplicaciones similares Web del municipio de Valga El municipio de Valga [38] dispone de un visor de mapas integrado, desarrollado por Enxenio S.L. también con tecnología javascript y con la cartografía propia. La capacidad operativa es similar a los dos anteriores, no obstante la calidad de la interfaz y manejabilidad de usuario es más pobre (no soporta zoom con los movimientos del scroll de ratón) y carece de ortofotos, siendo estos aspectos a ser mejorados. Figura 3.8: Municipio de Valga

100 74 Capítulo 3

101 CAPÍTULO 4 PLANIFICACIÓN Y EVALUACIÓN DE COSTES Este capítulo hace referencia a cómo se ha planificado la realización del proyecto, y cómo el coste asociado a su elaboración. 4.1 Consideraciones previas En todo proyecto real en el que participen varias personas o que sea crítico hay tres variables que siempre se deben controlar: Tiempo Coste Esfuerzo 75

102 76 Capítulo 4 Un buen analista e ingeniero debe controlarlos, ajustarlos y minimizarlos. Una buena planificación es una condición sine qua non, es decir, para poder tener éxito es imprescindible realizarla correctamente. Además permite ganar en eficiencia, calidad, y saber en todo momento el estado del proyecto y adelantarse a los sucesos en caso de problemas minimizando sus consecuencias (un ejemplo sería los cortes de luz). La planificación de un proyecto muestra sus mejores frutos al coordinar a un grupo significativo de personas paralelizando el trabajo. Este proyecto fin de máster consta de 3 recursos humanos que, como es el caso del autor, pueden desempeñar múltiples roles: programador, analista, diseñador, etc. El tutor y el director interpretan tanto el rol de usuario como el de consultor, solicitando funcionalidades y asesorando en su elaboración. La escala temporal de los diagrama de Gantt está en días. Y se supone que el calendario de trabajo es el estándar, es decir, 5 días lectivos trabajando 8 horas diarias, aunque en la práctica no necesariamente la carga de trabajo es una constante. 4.2 Planificación inicial La fecha de comienzo es el día , con la primera reunión en la que el tutor explicó a grandes rasgos como iba a ser el desarrollo de la aplicación, de qué constaba, la tecnología implicada y la arquitectura inicial a desplegar. Para ser más precisos en la planificación y el cálculo de horas se llevó un registro en forma de diario o log (en forma de fichero plano txt en la que se apuntaban: día, tiempo dedicado en ese día, qué tareas se habían realizado), con el que una vez concluído poder comparar las posibles desviaciones de las tres variables previstas con las reales. El proyecto fin de máster consta aproximadamente de 300 horas hábiles, 50 de ellas para la redactar la memoria, aunque en base a experiencias pasadas se estimó en exceso como si fuera de 1200 horas útiles dado que dicha cantidad inicial no

103 Planificación y evaluación de costes 77 era realista. La fecha de finalización concreta del proyecto era inicialmente indeterminada aunque se estimaba a finales de Septiembre de Como primer punto salientable y diferenciador, destaca el cambio de comienzo de fecha inicial, habitualmente el comienzo del proyecto era efectivo con la entrada del segundo cuatrimestre del calendario lectivo (hacia el mes de Marzo de 2009), es decir, se comenzó 5 meses antes de lo habitual con el fin de: 1. Alcanzar mayor cantidad de objetivos optativos posibles. 2. Evitar solapamientos de carga de trabajo con el resto de cursos del máster, especialmente en el 2 o cuatrimestre. 3. Obtener mejores resultados. 4. Evitar enormes picos de carga de trabajo. Se hizo un estudio previo con el que alcanzar la consecución de los objetivos marcados, consistente en realizar las siguientes etapas: Identificar los núcleos básicos del proceso: Análisis, Diseño, Programación, Pruebas... Desgranar los núcleos en actividades: Dividir los núcleos de proceso básicos en tareas independientes de tamaño manejable. Cuantificar cada actividad: Consiste en asignar un valor numérico (tiempo o esfuerzo) para que sea realizado. Relacionar las tareas: Cuáles son las dependencias entre las tareas. Identificar Recursos: Hay de dos tipos, recursos humanos y recursos materiales. Son actores o roles de los que disponemos (una misma persona puede desempeñar varios roles) donde se debe fijar el horario en el que trabajarán y materiales que disponemos para la consecución de los objetivos.

104 78 Capítulo 4 Asignar recursos a las tareas: En qué tarea es preciso cada recurso. Balancear la carga de trabajo: Evitar cargas de trabajo simultaneas organizando las tareas en el tiempo. Sin lugar a dudas, lo más complicado de una planificación en proyectos de este tipo es la estimación, ya que la variación está sujeta a múltiples factores. Existen métricas que intentan valorar cuánto tiempo, coste y esfuerzo supone un proyecto e incluso estimar cuántas miles de líneas de código (KLOC) o como de complejo será (Puntos Función) el proyecto antes de implementarlo. Todos ellos se basan en estudios estadísticos interpolando historiales de proyectos similares. Como cabe esperar, las planificaciones iniciales suelen ser un poco utópicas, por lo que se han dejado holguras de sobra para intentar neutralizar posibles eventualidades imprevistas Estimación de costes Los costes han valorado a precio de mercado, reflejado en la siguiente tabla: Nombre Recurso Capacidad Máxima Coste Recurso Director 25 % 25 e/h Tutor 10 % 25 e/h Analista 60 % 25 e/h Diseñador 100 % 20 e/h Programador 100 % 15 e/h Tabla 4.1: Tabla coste y capacidad máxima de recursos humanos planificados Los costes de los recursos materiales, comparativamente con los humanos, se pueden despreciar: los gastos del ordenador están amortizados y los gastos eléctricos son pagados conjuntamente por la empresa.

105 Planificación y evaluación de costes Estimación previa El resultado de la planificación inicial, después de identificar los núcleos básicos del proceso, dividirlo en un número de tareas, cuantificar cada actividad, asignar los recursos a las tareas implicadas, calcular las dependencias y balancear la carga, es el siguiente: La primera estimación es de 1.249,35 horas de trabajo, 1262 horas de duración y un coste asociado de ,68e, y que aunque el recurso Programador está sobreasignado son picos de trabajo asumibles en días muy puntuales. Se dejó apropósito el mes de Agosto inicialmente libre para en caso de necesidad emplearlo como holgura extra. Figura 4.1: Diagrama de Gantt: Estimación inicial

106 Planificacion PFC FIC 80 desde mié 01/10/08 Capítulo 4 Fechas Comienzo: mié 01/10/08 Fin: vie 18/09/09 Comienzo previsto: mié 01/10/08 Fin previsto: vie 18/09/09 Comienzo real: NA Fin real: NA Variación de comienzo: 0 horas Variación de fin: 0 horas Duración Programada: 1262 horas Restante: 1262 horas Prevista: 1262 horas Real: 0 horas Variación: 0 horas Porcentaje completado: 0% Trabajo Programado: 1.249,35 horas Restante: 1.249,35 horas Previsto: 1.249,35 horas Real: 0 horas Variación: 0 horas Porcentaje completado: 0% Costos Programados: ,68 Restantes: ,68 Previstos: ,68 Reales: 0,00 Variación: 0,00 Estado de las tareas Estado de los recursos Tareas aún no comenzadas: 58 Recursos de trabajo: 4 Tareas en curso: 0 Recursos de trabajo sobreasignados: 1 Tareas finalizadas: 0 Recursos materiales: 0 Total de tareas: 58 Total de recursos: 5 Tabla 4.2: Tabla resumen planificación inicial 4.3 Seguimiento El objetivo del seguimiento final es comparar la previsión inicial y contrastarla con la real para aprender de la experiencia, buscando las desviaciones e interpretando el suceso que las originó. Con el fin de clarificar lo que ha consistido temporalmente el proyecto se representa sobre el calendario los 130 dias registrados trabajados, con una media unas 8 horas por día:

107 Planificación y evaluación de costes 81 OCTUBRE 2008 NOVIEMBRE 2008 DICIEMBRE 2008 L M M J V S D L M M J V S D L M M J V S D ENERO 2009 FEBRERO 2009 MARZO 2009 L M M J V S D L M M J V S D L M M J V S D LEYENDA Análisis / Estudio viabilidad Documentación informe de requisitos Despliegue plataforma Prototipos Diseño Implementación Redación de la Memoria Presentación Defensa º ABRIL 2009 MAYO 2009 JUNIO 2009 L M M J V S D L M M J V S D L M M J V S D JULIO 2009 AGOSTO 2009 SEPTIEMBRE 2009 L M M J V S D L M M J V S D L M M J V S D Tabla 4.3: Calendario seguimiento planificación Se ha producido una serie de sucesos que han variado la primera estimación, causados principalmente por: Los meses de de Marzo, Abril y Junio se produjeron sobrecargas por entregas finales y/o exámenes de asignaturas del máster, lo que ha propiciado dejar temporalmente el proyecto. Incompatibilidad de horarios. Aumento de requisitos (realizando a mayores el portlet callejero no considerado inicialmente en los requisitos), análisis, diseño y pruebas para añadir

108 82 Capítulo 4 más valor al software. Problemas con la configuración del GeoServer y la carga de los scripts municipales de la EIEL. Alguna dependencia no planificada. Se han paliado los efectos empleando para ello el mes vacacional de Agosto para conseguir mantener la fecha de entrega. Este ha sido el resultado final, después de una minuciosa reconstrucción a partir del registro, que a fecha de proporciona la siguiente información: Figura 4.2: Diagrama de Gantt: Estimación real

109 Planificacion PFC FIC Planificación y evaluación de costes 83 desde vie 18/09/09 Fechas Comienzo: mié 01/10/08 Fin: vie 18/09/09 Comienzo previsto: mié 01/10/08 Fin previsto: vie 18/09/09 Comienzo real: NA Fin real: NA Variación de comienzo: 0 horas Variación de fin: 0 horas Duración Programada: 1262 horas Restante: 1262 horas Prevista: 1262 horas Real: 0 horas Variación: 0 horas Porcentaje completado: 0% Trabajo Programado: 1.042,97 horas Restante: 1.042,97 horas Previsto: 1.249,35 horas Real: 0 horas Variación: -206,38 horas Porcentaje completado: 0% Costos Programados: ,90 Restantes: ,90 Previstos: ,68 Reales: 0,00 Variación: ,78 Estado de las tareas Estado de los recursos Tareas aún no comenzadas: 14 Recursos de trabajo: 4 Tareas en curso: 0 Recursos de trabajo sobreasignados: 1 Tareas finalizadas: 44 Recursos materiales: 0 Total de tareas: 58 Total de recursos: 5 Tabla 4.4: Tabla resumen planificación final El coste total real del proyecto asciende a ,90e, la duración se mantiene en 1262 horas reales, y el trabajo real total a 1.042,97 horas. Si lo comparamos con respecto a la línea base supone aproximadamente un ahorro de 206,38 horas de trabajo inferior (-16,52 %), y 3.859,78e de coste ahorrado (-16,04 %), sin variación en la duración prevista ya que la fecha de entrega se mantiene. Puede parecer una paradoja que se reduzcan los costes, el trabajo a pesar de aumentar requisitos, esto es debido como se matizó inicialmente fué calculado con una previsión pesimista.

110 84 Capítulo 4 Ahora veamos lo que le correspondería el desglose de horas y coste por perfil: Nombre Recurso Trabajo Real Coste Recurso Coste Real Director 12 horas 25 e/h 300 e Tutor 16 horas 25 e/h 400 e Analista 279 horas 25 e/h e Diseñador 296 horas 20 e/h e Programador 441 horas 15 e/h e TOTAL horas e Tabla 4.5: Tabla costes finales desglosados por perfil

111 CAPÍTULO 5 METODOLOGÍA La metodología empleada para la realización de este proyecto es una Metodología de Prototipado Rápido (MPR). 5.1 Definición de MPR La Metodología de Prototipado Rápido, MPR, está orientada al desarrollo de prototipos y fuertemente apoyada en tecnología de Bases de Datos y herramientas visuales para Desarrollo Orientado a Objetos. En MPR se concentra un gran esfuerzo en la involucración del Usuario en dos fases fundamentales: la definición del problema que se va a abordar y en la ejecución de las pruebas, donde además se potencia el uso de lenguajes de cuarta generación utilizados como lenguajes de consulta para verificar la estructura y funcionalidad del prototipo desarrollado, asegurándose de que su diseño responde a las definiciones especificadas. 85

112 86 Capítulo 5 Como se ha expuesto, la idea fundamental de MPR es el desarrollo de prototipos. Un prototipo es un modelo inicial de lo que al final se corresponderá con la Base de Datos definitiva y sus procedimientos asociados. Este prototipo se someterá a pruebas para comprobar su funcionalidad, de las que surgirán modificaciones que darán origen a un segundo prototipo, versión mejorada y posiblemente ampliada del primero, el cual se volverá a probar, repitiéndose sucesivamente el proceso hasta alcanzar el prototipo definitivo. La responsabilidad y ejecución de estas pruebas fundamentalmente recae, como ya se ha mencionado, en el propio usuario, quien deberá de comprobar que el prototipo resultante es capaz de resolver todos los problemas planteados en el momento de la definición de las especificaciones del proyecto. 5.2 Representación gráfica de MPR Para representar MPR en su mayor grado de abstracción, se hace uso de un diagrama SADT 1 en el que se muestran las seis fases de las que se compone. La simbología empleada en el diagrama es la siguiente: cada una de las cajas representa algo que hay que hacer, en este caso una fase de la Metodología. A una caja pueden llegar flechas por su lado izquierdo (entradas necesarias para ejecutar la fase), por su parte superior (causas por las que se realiza una fase) y por su parte inferior (herramientas y técnicas con las que se hace lo indicado en la fase). Asimismo, por su parte derecha salen flechas que muestran algo que se ha obtenido en la fase y que pasa normalmente a la fase siguiente o sale directamente fuera del sistema, indicando un producto ya terminado y que no necesita más procesos. Desde cada fase de la Metodología se puede volver a cualquiera de las fases anteriores. En el diagrama SADT se han omitido voluntariamente estas conexiones para facilitar su estudio. 1 SADT: Structured Analysis And Design Technique

113 Metodología 87 Planes de trabajo Aplicaciones existentes Definición de Especificaciones Macromodelo de actividades Especificaciones detalladas y documentación Detalle de las especificaciones Diseño Conceptual Descripción de Entradas / salidas Herramientas de modelado Modelo de datos Desarrollo del Prototipo Prototipo normalizado Prototipo normalizado Lenguajes de desarrollo Pruebas del Usuario Datos resultantes Lenguajes no procedimentales y de consultas Implantación Resultados analizados Resultados analizados Auditoría y Seguimiento Informes Figura 5.1: Metodología Prototipado Rápido 5.3 Descripción detallada de las fases [Fase 1] Definición de especificaciones: Esta primera fase tiene por objeto auditar la información relativa al problema, con el fin de recabar todos los datos necesarios para su resolución. Como primera tarea podrá ser necesario realizar un estudio de la viabilidad del proyecto, para determinar y justificar la necesidad del mismo. A continuación se hará un análisis previo con el fin de establecer la amplitud y el calendario del proyecto, estimándose el esfuerzo necesario y el tiempo de desarrollo, e identificando los procesos involucrados en el mismo.

114 88 Capítulo 5 A continuación se construirá un prototipo inicial, no necesariamente operativo, construyéndose macromodelos de actividad para cada uno de los procesos identificados en la actividad anterior. La intención es disponer de la información necesaria para recabar la aprobación necesaria para comenzar el desarrollo. Se trata, en suma, de obtener la mayor cantidad de información posible sobre el problema que se intenta resolver, para obtener un tiempo estimado de desarrollo del proyecto y sus costes asociados, con el fin de obtener la aprobación necesaria para llevarlo a cabo. Como final de esta fase, y de todas las demás fases, se emitirá un informe para la Dirección del Proyecto. [Fase 2] Diseño conceptual: El objetivo de esta fase es construir un modelo de información que refleje el esquema conceptual del prototipo. Es muy importante que este modelo esté lo más ajustado posible a la realidad para que el diseño posterior de la Base de Datos pueda cumplir con sus objetivos. Se realizarán entrevistas a los Usuarios y se estudiará y diseñará el primer prototipo operativo, determinando sus puntos fuertes y sus puntos débiles, y se documentarán todas sus funcionalidades. También en esta fase se prepararán los planes de implantación, formación y pruebas, y se desarrollará el Manual del Usuario y el Manual Técnico. [Fase 3] Desarrollo del prototipo: Como su nombre indica, esta fase tiene por objeto la construcción del primer prototipo operativo de la Aplicación. Esta fase consta de dos actividades principales, una de desarrollo técnico propiamente dicho y otra para desarrollar la documentación asociada. Al finalizar esta fase se dispondrá de un prototipo totalmente funcional y operativo, que será sometido a múltiples pruebas en la siguiente fase para comprobar su validez. [Fase 4] Pruebas del Usuario: En esta fase se realizarán todas las pruebas necesarias para validar el prototipo desarrollado en la fase anterior. Si como resultado de estas pruebas se

115 Metodología 89 detectara la necesidad de modificar el prototipo, para corregir defectos o para añadirle funcionalidad, se volverá a la fase anterior y se realizarán todas las iteraciones necesarias hasta que el Usuario se sienta satisfecho con el prototipo y compruebe que responde a las especificaciones que se habían alcanzado inicialmente. Las pruebas en esta fase pueden ser de dos tipos: pruebas dirigidas, donde los desarrolladores guían y asesoran al usuario durante las mismas, y pruebas no dirigidas, donde el Usuario actúa libremente y sin la presencia del desarrollador/es. [Fase 5] Implantación: En esta fase se ejecutará el Plan de Formación de los Usuarios y se llevará a cabo el proceso de migración al entorno de ejecución real de la aplicación. Una vez completada la migración, se realizarán las pruebas finales y se llevarán a cabo las actividades correctoras finales, revisándose de paso toda la documentación del proyecto. Como final de esta fase se deberá de obtener la aceptación del Usuario y se emitirá un informe para la Dirección del Proyecto. [Fase 6] Auditoría y Seguimiento: La última de las fases de MPR consiste en realizar una Auditoría del rendimiento y la calidad de la Aplicación, y de determinar y canalizar los mecanismos necesarios para realizar peticiones de modificación y para que estas sean llevadas a cabo por los Equipos de Mantenimiento. Se deberán de identificar parámetros de rendimiento, compromisos de uso / respuesta, verificar la calidad global de la aplicación y efectuar las medidas correctoras oportunas. Como fin de fase, se comprobará que toda la documentación es la adecuada, y se obtendrá la aprobación definitiva del Usuario.

116 90 Capítulo Paradigma del Prototipado Un prototipo consiste según Pressman [39] en una aproximación hecha con chicles y alambres adecuado cuando no se sabe exactamente lo que se quiere construir, generalmente debido a que: El cliente/usuario no sabe exactamente lo que quiere. El analista no está seguro de la eficiencia de una aproximación o tiene dudas del dominio. Existen dudas en la interfaz hombre-máquina, etc. Figura 5.2: El paradigma de construcción de prototipos El paradigma de construcción de requisitos comienza escuchando al usuario/- cliente: se corresponde con la recolección de requisitos. se definen los objetivos globales del sistema. se identifican los requisitos conocidos y las áreas donde se precisa una mayor definición.

117 Metodología 91 Esto lleva a construir y revisar el prototipo: se realiza un desarrollo rápido centrado en los aspectos del software visibles para el usuario/cliente: formatos de entrada, formatos de salida, pantallas, etc. este desarrollo rápido conforma el prototipo elaborado en este ciclo. Una vez construido, el usuario/cliente prueba el prototipo: el prototipo es evaluado por el cliente/usuario. esta evaluación permite refinar los requisitos del software. este refinamiento es la entrada al siguiente ciclo del modelo de prototipado. En la mayoría de los casos el prototipo será demasiado lento, demasiado grande o demasiado torpe en su uso o las tres a la vez. Idealmente, se debe desechar el prototipo y empezar de nuevo. El prototipo sólo debe servir para identificar los requisitos del software cuando estos no estén claros.

118 92 Capítulo 5

119 CAPÍTULO 6 ANÁLISIS 6.1 Captura de requisitos La captura de requisitos es un proceso crítico para la elaboración de software, porque la gran mayoría de problemas del desarrollo software son causados por pobre la comprensión de lo que realmente quiere el usuario. Partimos de la siguiente descripción inicial del proyecto: Se realizará una web genérica para la publicación en web de cartografía municipal (Ej. Callejero, planeamiento urbanístico, patrimonio, turismo, etc.) empleando para ello exclusivamente tecnología con licencia libre y gratuita, en concreto usará tecnología de sistemas de información geográfica y de sistemas de gestión de contenidos web. 93

120 94 Capítulo 6 La web resultante genérica soportará diversa información cartográfica, extraída de la base de datos (BD) real de la provincia de la Coruña (EIEL). Esta comunicación utilizará un servicio Web Map Service (WMS) intermedio con el fin de aplicar unos ciertos estilos a la cartografía (color del trazo, grosor, relleno, etc.). Idealmente se plantea la posibilidad de automatizar tareas muy tediosas como la generación manual de dichos estilos siendo accesible vía web la nueva cartografía automáticamente. Adicionalmente soportará otro tipo de cartografía propietarias como pueden ser Google Maps, Yahoo Maps. El proyecto tendrá varias aplicaciones que se desplegarán por medio de un único instalador que realice la configuración inicial y genere una plantilla genérica que implemente diversas secciones típicas propias de la utilidad que va desempeñar (Novedades, fiestas, foro, alojamientos...) que cubra la mayoría de las necesidades similares. La información particular al municipio o municipios (nombre completo y logotipo municipal, mapa dinámico centrado en el municipio deberá ser configurada manualmente fácilmente o si fuera posible durante la instalación automatizada. Se habilitará un modo avanzado para que la empresa pueda disponer opcionalmente de más funcionalidades si fuera preciso prestaciones más complejas, contemplando futuras mejoras o extensiones.

121 Análisis Prototipado Para este proyecto se realizaron tres prototipos para extraer requisitos : 1. En el primero de ellos su único cometido era el desarrollo de una aplicación Java con la que conectarse a la Base de Datos y poder realizar las operaciones básicas para la creación (CREATE), consulta (SELECT), actualización (UPDATE) y borrado (DROP) de tablas, vistas e incluso base de datos enteras. Una vez logrado, quedó claro la necesidad de usar patrones para interaccionar con la BD para que fuera fácilmente adaptable a otros gestores. 2. El segundo de ellos fué un simple HTML con el que probar la API de Open- Layers con el que clarificar las ideas. 3. El tercero y último prototipo en desarrollar dos portlets completos y un objeto que encapsula la información a ser enviada mediante el paso de eventos siguiendo la especificación JSR-286. El objetivo del mismo era entender la estructura de un portlet genérico, el orden de compilación, como funcionaban, como se almacenaban las configuraciones permanentemente y emplearlo como esqueleto resultante para la realización de los portlets cartográficos. Como curiosidad este prototipo consistía en un buscador de productos ProductFinderPortlet que era un productor de objetos ficticios Mock y que al pulsar el nombre generaba un evento eventos permitía agregarlo a un carrito de compra ShoppingCartPortlet, que es un consumidor de eventos del otro. El objeto enviado era un ProductVO que contiene toda la información a ser mostrada (identificador, nombre de producto, y precio del mismo).

122 96 Capítulo 6 Figura 6.1: Prototipo Portlet menú vista Figura 6.2: Prototipo Portlet menú ayuda 6.3 Perfiles de usuario Existen tres perfiles de usuarios primarios claramente definidos: Los técnicos serán los empleados de la empresa Enxenio S.L. especializados en Sistemas de Información Geográfica (GIS) encargados de desplegar el servicio y configurarlo inicialmente. Los administradores serán empleados municipales que sin necesidad de conocimientos técnicos, se encargarán de mantener el servidor que proporcione acceso y actualizar los contenidos, el diseño y las prestaciones acordes a las necesidades particulares. Los usuarios web finales, que serán los beneficiarios de los nuevos servicios.

123 Análisis Definición de especificaciones Después de varias reuniones y los prototipos mencionados, se modificaron levemente las especificaciones iniciales para agregar mejoras o concretar las ya existentes. Se trata de evaluar un gestor de contenidos con los siguientes criterios de búsqueda: 1. que funcione sobre Tomcat 2. que sea de Licencia OpenSource y gratuito 3. con soporte para Portlets genéricos JSR con soporte de JSP como lenguaje para implementar los portlets. Tras realizar un estudio de viabilidad que se puede ver en el capítulo de aplicaciones similares y probar una decena que reunían las citadas características se optó por emplear como gestor de contenidos Liferay por los siguientes motivos: 1. facilidad de uso 2. fiabilidad 3. gran documentación en español 4. gran cantidad de plantillas 5. gran comunidad y foros con el que resolver todo tipo de dudas 6. fácilmente ampliable, de serie una gran cantidad de plugins oficiales y extraoficiales para adaptarse a todas las necesidades que pudieran surgir en un futuro. Como requisito implícito a los usuarios aunque no expuesto en el enunciado, es interesante que interfaz web esté internacionalizada, siendo la lengua gallega un caso concreto a contemplar debido a la mayoría de los usuarios finales pertenecen a municipios gallegos además del idioma español y el inglés (y que inicialmente

124 98 Capítulo 6 no estaba soportado el idioma Gallego por Liferay ni por ningún otro gestor de contenidos de los probados). Sobre esta plataforma elegida: Se diseñarán una serie de secciones típicas: Novedades, Destacados, Foro... Se implementará un visor cartográfico configurable basado en OpenLayers. Se instalará como servidor WMS e WFS GeoServer sobre el mismo tomcat Se cargara los datos propios de la base de datos municipal de la EIEL (preferiblemente en la instalación). Se creará un manual de usuario con el que resolver todo tipo de dudas. Sería deseable que la aplicación resultante dispusiera de las siguientes funcionalidades extras, se citan ordenadas de mayor a menor prioridad de implementación: 1. Visualización del mapa GIS a pantalla completa. 2. Permitir acceso a otros servicios externos WMS simultáneos, para su posterior empleo de servidor de ortofotos de fondo. Por ejemplo IDEE [40], Catastro [41], PNOA [42], CartoCiudad [43], Google Maps [44], Yahoo Maps [45], SigPac [46], OpenStreetMaps [47] Configurar la extensión desde el propio entorno web. 4. Un conjunto de plantillas típicas. 5. Utilización del idioma gallego en la interfaz. (idealmente traducir toda la interfaz) 6. Exportación del mapa GIS a formato PDF. 7. La publicación automática de nuevas capas y estilos en el WMS de nuevas vistas creadas, para que sean inmediatamente visibles desde la interfaz. 8. Callejero con cálculo de rutas.

125 Análisis 99 Aquí podemos ver la arquitectura global del sistema: package Data[ Arquitectura sistema ] Técnico Administrador Usuario Web <<component>> tomcat Web Municipal <<use>> <<component>> GisViewerPortlet <<component>> OpenLayers <<component>> GisSearcherPortlet <<use>> <<Internet>> <<Internet>> <<component>> GisScriptMun GeoServer <<component>> WMS LifeRay (Gestor de Contenidos) <<component>> WFS <<Database>> Hipersonic <<component>> PostGIS <<component>> PostGreSQL Los datos municipales en producción se guardan en la BD "lportal", para desarrollo Liferay trae una base de datos integrada denominada "Hipersonic" <<Database>> EIEL <<Database>> lportal Figura 6.3: Arquitectura del sistema

126 100 Capítulo Casos de uso package Data[ Requisitos funcionales ] Cargar Datos <<extend>> <<extend>> Generar Vistas Municipales Técnico Desplegar Servicio <<extend>> <<extend>> Configurar WMS Consultas SQL Modificar diseño <<extend>> <<extend>> Modificar escructura web Gestionar contenidos <<extend>> <<extend>> Añadir componentes <<extend>> Eliminar componentes Configurar componentes Administrador Configurar mapa <<extend>> <<extend>> <<extend>> Configurar capas disponibles Configurar controles interfaz Crear página con mapa Configurar Geolocalizador <<extend>> <<extend>> <<extend>> Elegir servicio de geolocalización Configurar el número máximo de resultados Crear Geolocalizador de direcciones Buscar Geolocalización de direcciones <<extend>> <<extend>> Ver posición geográfica sobre el mapa Usuario Web Ver sitio web <<extend>> <<extend>> Maximizar mapa Ver Mapa <<extend>> Elegir capas a visualizar Figura 6.4: Diagrama de casos de uso

127 Análisis 101 Desplegar servicio: El técnico podrá desplegar toda la arquitectura necesaria (Postgres, PostGis, GeoServer, Liferay) mayormente con instalación desatendida, permitiendo configurar algunos parámetros básicos, como por ejemplo los puertos de los servicios. Cargar Datos: El sistema permitirá opcionalmente cargar una copia de una base de datos o bien la carga mediante la selección de un fichero que contenga unos scripts de creación en un formato determinado, que se comentará en capítulos sucesivos. Generar Vistas Municipales: El sistema permite crear vistas de la base de datos completa de la EIEL previamente restaurada filtrando por cero o más municipios, consiguiendo efecto similar a la otra opción de carga de datos por medio de scripts municipales. Configurar WMS: El usuario para emplear la cartografía del servidor deberá configurar GeoServer para que sea accesible aplicándola un estilo SLD determinado, ver manual 175. Consulta SQL: Se proporciona de serie una interfaz para poder realizar consultas directamente sobre la base de datos, para que el técnico pueda verificar la conexión correcta con la base de datos instalada, visualizar los datos de las tablas etc. Gestionar contenidos: Permite la personalizacion de la web municipal, son casos de uso proporcionados por el gestor de contenido (si dispone de los permisos necesarios), entre los más importantes están: Modificar diseño: Permite la elección de la interfaz de usuario, y la organización de los portlets en cada página de la web. Modificar estructura web: Mediante personalización de las secciones y las subsecciones. Añadir componentes: Permite añadir nuevas aplicaciones a la web. Eliminar componentes: Permite eliminar aplicaciones existentes. Configurar componentes: Permite modificar el comportamiento de una aplicación.

128 102 Capítulo 6 Crear página con mapa: Permite añadir el visor cartográfico desarrollado. Configurar mapa: Permite modificar el comportamiento del vistor cartográfico, entre las opciones disponibles: Configurar capas disponibles: Permite añadir/quitar capas cartográficas. Configurar controles interfaz: Permite personalizar el tamaño del mapa, operaciones de centrado sobre unas coordenadas con un zoom determinado, y todo tipo de operaciones adicionales proporcionadas por OpenLayers. Crear Geolocalizador de direcciones: Permite añadir el georreferenciador que convierte direcciones a coordenadas geoespaciales (latitud, longitud) que pueden ser capturadas por el visor. Configurar Geolocalizador: Permite configurar los siguientes opciones: Elegir servicio de geolocalización: Permite seleccionar el servicio de georeferenciación: Google Maps, Yahoo Maps... Configurar el número de resultados máximos: Permite elegir cuántos resultados máximos se deben mostrar como respuesta a una consulta concreta. Ver sitio web: Permite navegar por las secciones y subsecciones de la web. Buscar Geolocalización de direcciones: Permite buscar de una dirección al servicio de geolocalización de la fuente configurada. Ver posición geográfica sobre el mapa: Si está el visor en la misma sección web, crea un marcador, que centra el la posición del mapa sobre esa región. Ver mapa: muestra las capas cartográficas sobre el visor. Maximizar mapa: Permite mostrar el visor a pantalla completa. Elegir capas a visualizar: Permite elegir que capas base o sobreespuestas desean visualizarse dependiendo de la configuración.

129 CAPÍTULO 7 DISEÑO 7.1 Contexto Se diseñaron las siguientes aplicaciones, que se desglosarán en detalle posteriormente: GisScriptMun: Aplicación de escritorio, empaquetado como JAR, que aglutina todo lo referente a la instalación/despliegue de la arquitectura del sistema inicial, carga de datos, creación de vistas, conexión con la base de datos GisMapPorlets: Compuesto por los siguientes proyectos: GisViewerPortlet: Portlet visor cartográfico. Empaquetado como WAR. GeoPointVO: Objeto que encapsula los datos enviados entre los eventos de los portlets. Empaquetado como JAR. 103

130 104 Capítulo 7 GisSearcherPortlet: Portlet georeferenciador de direcciones. Empaquetado como fichero WAR) 7.2 Diseño portlets genéricos Especificación de portlets Java JSR-168 y JSR-286 Estandariza Arquitectura el APIde que un ofrece servidor el contenedor de portales ajava los portlets. basado en [48] estándares (1) El diseño del API tiene cierto parecido con el API de servlets. Apl. portlet Navegador Otros portales Aplicación Web del portal Productor WSRP Contenedor de portlets Java [...] Apl. portlet Portlet consum. WSRP Internet/Intranet Productor WSRP Servidor de portales Figura 7.1: Arquitectura servidor de portales genérico El contenedor de portlets Al igual que los servlets, los portlets se ejecutan dentro de un contenedor. Es una extension de un contenedor de servlets. De hecho, un servidor de portales Java suele ser una extensión de un servidor de aplicaciones Java Pero un portlet no es un tipo especial de servlet.

131 Diseño 105 Debe implementar la especificación Servlets 2.3 Soporta aplicaciones portlet Extension de aplicaciones Web J2EE (ficheros.war) Adicionalmente cada aplicación portlet contiene Uno o más portlets Un descriptor de sus portlets (WEB-INF/portlet.xml) Dado que el contenedor solo esta obligado a soportar la especificación Servlets 2.3, para lograr maxima portabilidad la aplicación portlet debería usar: JSP 1.2 (JSP 2.0 requiere Servlets 2.4 ): No soporta lenguaje de expresiones JSTL 1.0 [49][50] (JSTL 1.1 depende de JSP 2.0) : Implementa lenguaje de expresiones (para sus tags) Aplicación Web del portal Implementa los casos de uso del portal (registro y autenticación de usuarios, selección de portlets y layout en las páginas, creación y destrucción de páginas, agregación de las respuestas de los portlets en la página actual, etc.) Interactúa con el contenedor de portlets mediante un API específica Arquitectónicamente, en algunos servidores de portales la separación entre la aplicación Web del portal y el contenedor de portlets puede no ser tan clara. En cualquier caso, la especificación de portlets Java estandariza el API del que disponen los portlets API de Portlet Interfaz En la interfaz todo portlet tiene que implementar la interfaz javax.portlet.portlet aunque normalmente se implementan extendiendo de javax.portlet.genericportlet.

132 106 Capítulo 7 Visión global del API de portlets (1) <<interface>> javax.portlet.portlet + init(portletconfig : PortletConfig) : void + destroy() : void + processaction(request : ActionRequest, response : ActionResponse) : void + render(request : RenderRequest, response : RenderResponse) : void javax.portlet.genericportlet + init(portletconfig : PortletConfig) : void + destroy() : void + processaction(request : ActionRequest, response : ActionResponse) : void + render(request : RenderRequest, response : RenderResponse) # dodispatch(request : RenderRequest, response : RenderResponse) : void # doview(request : RenderRequest, response : RenderResponse) : void # doedit(request : RenderRequest, response : RenderResponse) : void # dohelp(request : RenderRequest, response : RenderResponse) : void Figura 7.2: Diagrama de clases: API GenericPortlet Ciclo de vida El número de instancias de la clase portlet (similar a un Servlet) Entorno no distribuido: una (por cada definición de portlet) Entorno distribuido (<distributabie/> en web.xml): una (por cada definición de portlet) por cada máquina virtual. Cuando el contenedor crea una instancia del portlet realiza la operación init() Cuando el contenedor decide destruirla ejecuta destroy() Modos PortletMode.VIEW (view) PortletMode.EDIT (edit) PortletMode.HELP (help) El vendedor del portal puede definir modos a medida

133 Diseño 107 Estados de ventana Windows.state.NORMAL (normal) Windows.state.MAXIMIZED (maximized) Windows.state.MINIMIZED (minimized) El vendedor del portal puede definir estados de ventana a medida Tipos de peticiones Petición de acción ( action request ) Peticiones que modifican el estado del portlet o causan una redirection No son idempotentes Se procesan redefiniendo processaction <<interface>> javax.portlet.portletrequest PortletPreferences representa las preferencias de personalización de una instancia del portlet (un mapa que asocia entradas <nombre, valor (String o String[])>). + getparameter(name : String) : String + getparametervalues(name : String) : String[] + getportletmode() : PortletMode + getwindowstate() : WindowState + getportletsession(boolean create) : PortletSession + getpreferences() : PortletPreferences + getattribute(name : String) : String + setattribute(name : String, o : Object) : void + removeattribute(name : String) : void <<interface>> javax.portlet.actionrequest <<interface>> javax.portlet.renderrequest + getportletinputstream() : java.io.inputstream + getreader() : java.io.bufferedreader Figura 7.3: Diagrama de clases: API PortletRequest Petición de renderización ( render request ) Peticiones para solicitar el markup del portlet

134 108 Capítulo 7 Son idempotentes El contenedor invoca a render: GenericPortlet lo implementa como un método plantilla, que entre otras cosas, invoca a dodispatch, quien a su vez delega en doview, doedit o dohelp, dependiendo del modo seleccionado. El método dodispatch proporcionado por GenericPortlet no invoca a ningún método de renderización cuando windowstate=minimized <<interface>> javax.portlet.portletresponse <<interface>> javax.portlet.actionresponse + sendredirect(location : String) : void + setportletmode(portletmode : PortletMode) : void + setwindowstate(windowstate : WindowState) : void + setrenderparameter(key : String, value : String) : void + setrenderparameter(key : String, values : String[]) : void + setrenderparameters(parameters : java.util.map) : void createactionurl y createrenderurl permiten crear URLs que provocan peticiones de acción y peticiones de renderización. El API de portlets proporciona librería de tags JSP para facilitar la creación de URLs desde páginas JSP <<interface>> javax.portlet.renderresponse + createactionurl() : ActionURL + createrenderurl() : ActionURL + setcontenttype(type : String) : void + settitle(title : String) : void + getportletoutputstream() : java.io.outputstream + getwriter() : java.io.printwriter Figura 7.4: Diagrama de clases: API PortletResponse Los métodos de renderización son los únicos que pueden generar markup mediante RenderResponse Una petición de acción sobre un portlet siempre va seguida de una petición de renderización sobre ese portlet, y sobre el resto de portlets de esa página cuyo contenido no esté cacheado (para regenerar la página). Una petición de renderización sobre un portlet provoca una petición de renderización sobre todos los portlets de esa página cuyo contenido no esté cacheado (para regenerar la página). Los métodos de renderización pueden delegar la generación de markup en una página JSP (lo más normal) o un servlet de la aplicación portlet

135 Diseño 109 Portal Contenedor Portlet 1 Portlet 2... Portlet N 1: Interacción (renderización) sobre el portlet 1 El usuario está actuando sobre una página que contiene los portlets 1, 2,... N 1.1: render [respuesta no en caché] 1.2: render... [respuesta no en caché] 1.N: render Figura 7.5: Diagrama de secuencia: Procesamiento de peticiones de renderización Portal Contenedor Portlet 1 Portlet 2... Portlet N 1: Interacción (acción) sobre el portlet 1 1.1: processaction El usuario está actuando sobre una página que contiene los portlets 1, 2,... N 1.2: render [respuesta no en caché] 1.3: render... [respuesta no en caché] 1.N+1: render Figura 7.6: Diagrama de secuencia: Procesamiento de peticiones de acción URL s RenderResponse permite crear URLs que causan peticiones de acción (createactionurl) o renderización (createrenderurl) El API de portlets proporciona librería de tags JSP para facilitar la creación

136 110 Capítulo 7 de URLs desde páginas JSP El desarollador no especifica la ruta de la URL. Sólo puede especificar: parámetros, cambio de estado de ventana, cambio de modo y si la URL debe llevar asociada una conexión segura. El portal genera la URL real (la que ve el navegador) apunta al portal y lleva codificada la información especifica por el desarrollador. La URL asociada al campo action de un formulario debe ser de acción, aunque conceptualmente la petición sea de renderización Parámetros en peticiones Cuando el usuario realiza una petición de acción/renderización sobre un portlet el contenedor debe invocar processaction/render sobre ese portlet con los parámetros asociados a la petición En principio, la petición de renderización que sigue a una petición de acción sobre un portlet no debe propagar los parámetros de la petición de acción Si el portlet quiere establecer parámetros (durante el procesamiento de la petición de acción) para la petición de renderización, tiene que hacerlo mediante los métodos ActionResponse.setRenderParameter(-s) Siempre que el portal invoca una petición de renderización sobre un portlet (e.g. porque su respuesta no estaba cacheada) como consecuencia de una petición de acción/renderización dirigida a otro portlet de la misma página, el portal debe usar los mismos parámetros que en la anterior invocación de renderización, de esta manera, cada vez que se realiza una interacción sobre un portlet, la página generada por el portal mostrará el resto de portlets en el estado anterior. Cada portlet sólo ve los parámetros de la petición dirigida hacia él Las URLs asociadas a los botones de cambio de modo y estado de ventana causan peticiones de renderización, y el portal debe conservar los parámetros de renderización asociados a cada portlet de la página En algunos servidores, los parámetros no se conservan

137 Diseño 111 Sesiones Al igual que las aplicaciones Web, las aplicaciones portlet disponen del concepto de sesión (PortletSession). Métodos PortletRequest.getPortletSession. Método PortletSession.setAttribute( name, value, scope) scope: PortletSession.application scope (atributo disponible para cualquier portlet de la aplicación portlet en la misma sesión) o PortletSession.portlet scope (atributo disponible a las peticiones dirigidas a esa instancia del portlet en la misma sesión) Metodo PortletSession.getAttribute( name, scope) Los atributos de la sesión del portlet se guardan en atributos de la sesión javax.servlet.http.httpsession Los atributos con scope=portletsession.application SCOPE, se guardan con el mismo nombre Los atributos con scope=portletsession.portlet SCOPE, se guardan con nombre codificado Comunicación entre portlets El mecanismos de eventos: Es un mecanismo general de comunicación. En respuesta a un evento, el portlet puede modificar estado (e.g. cambiar preferencias, actualizar una base de datos, realizar una operación no idempotente, etc.), establecer parámetros de renderización o enviar un nuevo evento. El dato del evento puede ser un tipo complejo. Si una petición de acción devuelve un evento, el contenedor: Invoca processevent sobre todos los portlets consumidores de dicho evento. Idem si processevent también devuelve un evento. Invoca render sobre el portlet receptor de la petición de acción y sobre todos los portlets cuyo contenido no este cacheado o sean receptores del evento

138 112 Capítulo 7 Portal 1: Interacción (acción) sobre el portlet 1 Contenedor 1.1: processaction Portlet 1... Portlet N El usuario está actuando sobre una página que contiene los portlets 1, 2,... N [consumidor del evento] 1.2: processevent [consumidor del evento] 1.N+1: processevent 1.N+2: render... [consumidor del evento respuesta no en caché] 1.2N+1: render Figura 7.7: Diagrama de secuencia: Procesamiento de peticiones de acción que devuelve un evento El mecanismo de parámetros públicos de renderización: Es un mecanismo cómodo y eficiente para el caso particular de portlets que comparten un conjunto de parámetros de renderización.

139 Diseño Estructura de la aplicación GisScriptMun package Data[ GisScriptMun] gis.script.* gis.script.controller <<use>> <<use>> Librerias externas gis.script.model DAO gis.script.view <<import>> org.postgresql.* org.postgis.* com.vividsolutions.jts.* org.geotools.* org.cresques.* DTO <<use>> FACHADAS Figura 7.8: Diagrama de classes GisScriptMun & Estructura interna Controlador La capa de control esta formada por un único paquete que contiene la clase Controller que lleva a cabo la función de comunicar vista y modelo. Almacena información global del estado de la aplicación imprescindible para el funcionamiento. Gestiona los grandes núcleos de información relevante como es la la conexión con la Base de datos, la información de la configuración, centraliza todo tipo de mensajes. Modelo El Modelo es la parte más compleja de la aplicación, que está subdividido en varios paquetes según sea su cometido:

140 114 Capítulo 7 action: Están las clases encargas de realizar acciones de las interfaces. capa: Contiene las CapaFactory para crear las capas vectoriales. exception: Están los nuevos tipos de excepciones. geometria: Se encuentra la GeometriaFactory usada para obtener los campos vectoriales geométricos. GeometriaFactory +Geometria creargeometria( IGeometry ) +Geometria creargeometria( Geometry ) Shape Fabrica * IGeometry 1 1 Geometria +int NULL +int PUNTO +int LINEA +int POLIGONO int MULTIPUNTO... +int gettipo() +int elementos() +Geometria[] getgeometrias() GeometriaNula GeometriaMulti GeometriaPunto GeometriaLinea GeometriaPoligono * GeometriaMultipuntos GeometriaMultiLinea GeometriaMultiPoligono * 1 CapaPunto CapaRed 1 CapaPoligonos FLyrVect CapaVectorial +GeometriaCapaVectorial gettabla() +Geometria[] getgeometria() +Valor[] getfila( long fila ) +Atributo[] getcabecera()... * * Atributo Valor Figura 7.9: Diagrama de clases: GeometriaFactory

141 Diseño 115 sql: Incluye los DAO s y las clases necesarias para conectarse y desconectarse de la base de datos y realizar consultas, inserciones, crear nuevas tablas o alterar las existentes. valor: Contiene las clases de nuevos tipos empleados y también las clases que puede crear el ValorFactory si es preciso. Valor * 1 ValorFactory ValorBooleano ValorNumero ValorCadena ValorNulo ValorNumeroEntero ValorNumeroDefault ValorInfinito ValorPorcentaje ValorDistanciaKm ValorSuperficieKm2 Figura 7.10: Diagrama de clases: Valor util: Paquete común a toda la aplicación. Vista En este aspecto se ha realizado un especial hincapié, puesto que es la parte visible de un programa. Incluye un único paquete fachadas que contiene todas las interfaces de la aplicación. Primeramente se han diseñado las interfaces realizado por simplicidad un boceto en papel, para luego utilizar un plugin de Eclipse denominado Visual Editor cuando era posible para confeccionarlas de manera visual agregando los componentes de Java disponibles (JPanel, JCombobox, JCheckBox, etc) arrastrando desde una Paleta a su ubicación con el ratón.

142 116 Capítulo 7 Figura 7.11: Diseño de interfaz: Ejemplo edición con Visual Editor

143 Diseño GisMapPorlets package Data[ GisMapPortlets] GisSearcherPortlet GisPointVO Modelo Exceptions -id : int -address : String -latitude : double -longitude : double GeographicPointTO RuntimeException Exception InstanceException +GeographicPointTO() +GeographicPointTO( id : int, address : String, latitude : double, longitude : double ) +getid() : int +setid( id : int ) : void +getaddress() : String +setaddress( address : String ) : void +getlatitude() : double +setlatitude( latitude : double ) : void +getlongitude() : double +setlongitude( longitude : double ) : void +tostring() : String ParsingException ServiceException InstanceNotFoundException <<throws>> <<throws>> GoogleGeocodeService YahooGeocodeService MockGeocodeService GisViewerPortlet Modelo GeocodeService <<throws>> +getgeographicpoint( direccion : String, maxsize : int ) : List<GeographicPointTO> +getservicename() : String Controlador Controlador javax.portlet.genericportlet geocodeservicefacade javax.portlet.genericportlet GisViewerPortlet GisSearcherPortlet -ADD_GEOPOINT_TO_VIEWER_EVENT : QName = new QName(" +init() : void +processviewmode( request : RenderRequest, response : RenderResponse ) : void -getgeocodeservicefacadeinstances() : GeocodeService +processeditmode( request : RenderRequest, response : RenderResponse ) : void +processhelpmode( request : RenderRequest, response : RenderResponse ) : void +firesearchproducts( request : ActionRequest, response : ActionResponse ) : void +sendaddgeopointtoviewerevent( request : ActionRequest, response : ActionResponse ) : void +save( request : ActionRequest, response : ActionResponse ) : void -includehtmlresponse( request : RenderRequest, response : RenderResponse, path : String ) : void +init() : void +processviewmode( request : RenderRequest, response : RenderResponse ) : void +processeditmode( request : RenderRequest, response : RenderResponse ) : void +processhelpmode( request : RenderRequest, response : RenderResponse ) : void +save( request : ActionRequest, response : ActionResponse ) : void +removegeomarker( request : ActionRequest, response : ActionResponse ) : void +addlayer( request : ActionRequest, response : ActionResponse ) : void +removelayer( request : ActionRequest, response : ActionResponse ) : void +processaddgeopointmarkertoviewerevent( request : EventRequest, response : EventResponse ) : void -gettexttobreaklines( text : String ) : String -addtoarray( currentvalues : String"[]", value : String ) : String"[]" -removefromarray( currentvalues : String"[]", value : String ) : String"[]" -includehtmlresponse( request : RenderRequest, response : RenderResponse, path : String ) : void Vista Vista view.jsp edit.jsp help.jsp view.jsp edit.jsp help.jsp commonheader.jsp commonheader.jsp Figura 7.12: Diagrama de classes Portlets GisMapPortlets

144 118 Capítulo 7 GisPointVO El proyecto GisPointVO es empaquetado como librería externa jar el objeto común GeograficPointTO que es empleado por los Portlets para el envio de eventos. Figura 7.13: Estructura interna objeto GisPointVO GisSearcherPortlet En el controlador del GisSearcherPortlet existen tres métodos de Renderización: process- ViewMode, processeditmode, processhelpmode y tres métodos de Acción: firesearchproducts (busqueda direcciones), sendaddgeopointtoviewerevent (enviar evento marcador), save (guardar configuración). El modelo contiene la interfaz de geolocalización GeocodeService y las implementaciones correspondientes GoogleGeocodeService(servicio de Google) [51], YahooGeocodeService (servicio de Yahoo) [52], MockGeocodeService (servicio para pruebas). También contiene las clases que definen los diferentes tipos de excepciones posibles. La vista está compuesta por cuatro JSP: commonheader.jsp que están declaradas las librerías comúnes a view.jsp (busqueda de direcciones), edit.jsp (configuración), help.jsp (ayuda) que se corresponden uno a uno a cada modo del Portlet. Figura 7.14: Estructura interna portlet GisSearcherPortlet

145 Diseño 119 GisViewerPortlet En el controlador del GisViewerPortlet existen tres métodos de Renderización: processviewmode processeditmode processhelpmode y cinco métodos de Acción: addlayer (añadir capa) removelayer (eliminar capa) processaddgeopointmarkertoviewerevent (recepción evento marcador) removegeomarker (eliminación de marcador) save (guardar configuración) Figura 7.15: Estructura interna portlet GisViewerPortlet Puede chocar a primera vista que el modelo carezca de clases, la explicación consiste es que no es necesario realizar procesamiento de la información, simplemente almacenarla y mostrarla. La vista está compuesta por cuatro JSP: commonheader.jsp que están declaradas las librerías comúnes a view.jsp (utiliza las librerías javascript de OpenLayers), edit.jsp, help.jsp que se corresponden uno a uno a cada modo del Portlet.

146 120 Capítulo 7

147 CAPÍTULO 8 IMPLEMENTACIÓN 8.1 Eclipse Eclipse [53] es una plataforma de software de código abierto independiente de plataforma pensada, desarrollada originalmente por IBM como sucesor de su familia de herramientas para VisualAge y ahora por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios y servicios. La definición que da el proyecto Eclipse acerca de su software es: una especie de herramienta universal - un IDE 1 abierto y extensible para todo y nada en particular 1 IDE: entorno de desarrollo integrado 121

148 122 Capítulo 8 En cuanto a las aplicaciones clientes, Eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework - Framework para la edición gráfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto WYSIWYG hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. Dado que los editores realizados con GEF viven dentro de Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz gráfica personalizable y profesional. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadatos en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. Figura 8.1: Entorno de desarrollo Eclipse

149 Implementación 123 Eclipse es la plataforma elegida para el desarrollo del código fuente, decisión condicionada por conocimiento previo del entorno, y aun existiendo otras alternativas similares (como puede ser NetBeans) su velocidad y su agradable interfaz, una vez más, inclinó la decisión a su favor. En nuestro caso, además, se empleó el plugin de Edición Visual (VE) que es una plataforma para crear constructores de interfaces gráficas (GUI s), y el de integración con maven (m2eclipse). 8.2 GisScriptMun Datos de entrada En este apartado se pretende analizar cómo se guardan las configuraciones en el fichero properties ubicado por defecto en la ruta conf.properties. Para más información consultar el manual de usuario adjuntado en este documento en el capítulo A, página 171. Las clases que las manejan son ConfigurationFunction y ConfigurationManager.

150 124 Capítulo 8 1 ######################################################################################### < 2 # # 3 # PROYECTO FIN DE MASTER # 4 # Autor: Miguel Álvarez Úbeda # CABECERA 5 # # FICHERO 6 # Herramienta Web genérica de publicación de cartografía municipal # PROPERTIES 7 # # 8 # # 9 # configuracion.properties: Fichero de configuracion # 10 # # 11 ######################################################################################### < 12 #Mon Sep 13 19:00:44 CEST 2009 < Ultima actualización 13 configurar_password=wgq+6r7ivsm/= < Contraseña cifrada < 14 configurar_fichero_log=gisscriptmun.log < Fichero LOG 15 configurar_id_vista_municipio=mun_ < Prefijo municipios 16 configurar_schema_index=gis_web_municipios < Schema Municipal CONFIGURACIÓN 17 configurar_usuario=postgres < Usuario BD BASE DE DATOS 18 configurar_gestor_bd=jdbc/:postgresql < Gestor de Base de Datos: Postgresql 19 configurar_bd=gis_eiel_2007 < Nombre Base de Datos 20 configurar_host= < Host Conexión 21 configurar_tabla_index=index < Tabla índice municipios 22 configurar_id_vista=vista_ < Prefijos vistas 23 configurar_puerto=5432 < Puerto Conexión < consultasql_informe_checkbox = true < Crear informe de las consultas SQL < CONSULTAS SQL tomcatpathbin =./liferay-portal-5.2.3/tomcat /bin/ < Path relativo tomcat 28 appcontrolservices = C:/WINDOWS/system32/net.exe < App. Control Servicios postgresdir = C:/Archivos de programa/postgresql/8.1 < Directorio instala Postgres < 31 postgrestinstaller =./instaladores/postgresql-8.1-int.msi < Path instalador Postgres POSTGRESQL 32 postgrestfileconfig =./instaladores/postgresql.conf < Fichero config Postgres 33 bdservice = pgsql-8.1 < Nombre del servicio Postgres-8.1 < ficheromunicipal = true < Cargar Modo script Municipal < SCRIPTS 36 municipalfilezip =./instaladores/coruna.zip < Scrips Municipales ZIP MUNICIPALES 37 unzipoutfolder =./temp < Ubicación temporal de los scripts municipales < restoreeielbd = false < Restore EIEL backup < 40 eieldbfilebackup =./instaladores/gis_eiel_2007_urbanserv_mar.backup < Backup EIEL EIEL 41 templateeiel = template0 < Plantilla EIEL 42 codificacioneiel = LATIN1 < Codificación EIEL < liferaybd = lportal < nombre BD Liferay < 45 liferayzip =./instaladores/liferay-portal zip < Ubicación Liferay comprimido 46 lportalfilebackup =./instaladores/lportal.backup < Backup BD Liferay inicial LIFERAY 47 encodingliferaybd = UTF-8 < Codificación BD liferay 48 templateliferaybd = template0 < Plantilla BD liferay 49 unzipoutliferayfolder =. < Ubicación descomprimir liferay < Despliegue de infraestructura municipal El despliegue de la arquitectura realiza estos pasos de manera desatendida: Recupera datos del fichero properties Elimina Postgres (pregunta confirmación previamente antes de borrar) Instala Postgres desatendido

151 Implementación 125 Copia fichero postgresql a la seccion data de instalacion (para permitir acceso al schema que contiene la información municipal) Reinicia sercicio Postgres (para cargar el nuevo fichero de configuración) Elimina y vuelve a crear la base de datos de liferay Restaura el backup de la base de datos de Liferay Descomprime el ZIP de Liferay Si (ficheromunicipal == true) carga los scrips municipales: Descomprime sucesivamente el fichero ZIP que empaqueta los SQL municipales Asigna mediante funciones regex scripts municipal (lo que está en negrita es por lo que lo detecta la ubicación exacta) 1. BD GIS EIEL RolesGrupo.sql 2. BD GIS EIEL Esquema WIN.sql 3. BD GIS EIEL Esquema LIN.sql (No se usa en este caso) 4. BD GIS EIEL AuxDelete.sql 5. BD GIS EIEL DatosComunes.sql 6. BD GIS EIEL Prov 15 Mun 001 CB.sql 7. BD GIS EIEL Prov 15 Mun 001 FV.sql 8. BD GIS EIEL AuxCreate.sql Los ejecuta en ese orden citado cargándolos en la base de datos Si (restoreeielbd == true) restaura base de datos EIEL Envia mensaje Proceso realizado Abre directorio binarios Tomcat para ejecutar startup.bat

152 126 Capítulo Traducción Liferay Se ha traducido toda la aplicación al idioma gallego (gl ES) empleando de base el fichero diccionario de mensajes del idioma Español. El proceso de traducción automatizada consintió en el uso de expresiones regulares y el empleo del traductor libre web Opentrad [54] con resultados bastante buenos y fiables. Posteriormente se revisó minuciosamente para localizar errores. Como resultado del proceso se obtuvo el fichero diccionario Language gl ES.properties. Para la integración en Liferay: Buscamos el fichero: /liferay-portal-5.2.3/tomcat /webapps/root/web-inf/lib/portal-impl.jar Abrimos el fichero portal-impl.jar (con WinRAR por ejemplo) Modificamos el fichero portal-ext.properties en la línea locales añadimos gl ES: locales=ar SA,ca AD,zh CN,zh TW,cs CZ,nl NL,en US,fi FI,fr FR,de DE,el GR, hu HU,it IT,ja JP,ko KR,pt BR,ru RU,es ES,tr TR,vi VN,gl ES En el mismo fichero portal-impl.jar copiamos el fichero antes creado Language gl ES.properties en la ruta portal-impl.jar/content junto al resto de diccionarios. Si se desea además tener el icono de galicia, se debe copiar en la carpeta themes en el tema activo. En nuestro caso si la plantilla es sevencogs-theme la ruta seria: /liferay-portal-5.2.3/tomcat /webapps/sevencogs-theme/images/language

153 Implementación GisMapPortlets Proyecto maven2 Los dos portlets disponen de un fichero pom.xml que definen las dependencias con las librerías necesarias y dependencias. Para la compilación del proyecto se deben realizar los siguientes pasos: Eliminar restos anteriores (Script a.bat) : 1. rm -rf../liferay-portal-5.2.3/tomcat /webapps/gisviewerportlet 2. rm -rf../liferay-portal-5.2.3/tomcat /webapps/gissearcherportlet 3. mvn clean Primero el proyecto común gispointvo : compilación, almacenamiento en el repositorio de maven (solo preciso si se modifica o por primera vez) y copia en la carpeta lib de tomcat que contiene liferay. Script instala gispoint.bat: 1. cd./gispointvo 2. maven package 3. mvn clean package 4. cd.. 5. cp./gispointvo/target/gispointvo.jar../liferay-portal-5.2.3/tomcat /lib 6. mvn install:install-file -DgroupId=gispointvo -DartifactId=gispointvo -Dversion=0.1 -Dpackaging=jar -Dfile=./gisPointVO/target/gisPointVO.jar Compilamos el resto de los portlets y copiamos al directorio deploy de liferay (Script copia wars.bat): 1. maven clean package 2. cp./gissearcherportlet/target/gissearcherportlet.war../liferay-portal-5.2.3/deploy 3. cp./gisviewerportlet/target/gisviewerportlet.war../liferay-portal-5.2.3/deploy NOTA: Para facilitar la compilación y empaquetamiento y deploy en liferay, el desarrollador puede usar desde una consola los scripts *.bat que contiene los comandos antes descritos.

154 128 Capítulo GisSearcherPortlet gissearcherportlet.war img META-INF maven es.udc.portlets.gissearcherportlet gissearcherportlet WEB-INF classes es.udc.portlets.gissearcherportlet controller model exceptions facade impl google mock yahoo view messages lib Figura 8.2: Diagrama de paquetes, estructura interna GisSearcherPortlet.war

155 Implementación 129 Datos de entrada Fichero WEB-INF/web.xml 1 2 <?xml version= 1.0 encoding= UTF 8?> 3 4 <web app version= xmlns= 6 xmlns:xsi= instance 7 xsi:schemalocation= app 2 4.xsd > 8 9 <display name>gissearcherportlet</display name> 10 <description>it contains a portlet allowing to search the coordinates from addresses </description> 11 <! Disabled by default, since some versions of JBoss Portal server do not support clustering. 12 <distributable/> 13 > <! ======================= Standard TagLibs configuration ============== > <context param> 18 <param name>javax.servlet.jsp.jstl.fmt.localizationcontext</param name> 19 <param value>es.udc.portlets.gissearcherportlet.view.messages.messages</param value> 20 </context param> <context param> 23 <param name>javax.servlet.jsp.jstl.fmt.fallbacklocale</param name> 24 <param value>en</param value> 25 </context param> 26 </web app> Especifica detalles relativos a los recursos de la aplicación portlet que no son portlets (e.g. servlets y páginas JSP), que deben tener por lo menos: description display-name security-role (no lo utilizamos) Configuración de internacionalización en JSTL: Se especifica la ruta de los ficheros de mensajes Se especifica el Locale que se usara por defecto cuando no es posible usar el elegido por el usuario

156 130 Capítulo 8 Fichero WEB-INF/portlet.xml 1 <?xml version= 1.0 encoding= utf 8?> 2 <portlet app xmlns= app 2 0.xsd 3 xmlns:xsi= instance 4 xsi:schemalocation= app 2 0.xsd 5 version= 2.0 > 6 <portlet> 7 <description>a portlet allowing to search addresses</description> 8 9 <portlet name>gissearcherportlet</portlet name> 10 <display name>gissearcherportlet</display name> 11 <portlet class>es.udc.portlets. gissearcherportlet. controller.gissearcherportlet</portlet class> <init param> 14 <name>yahoo Maps</name> 15 <value>es.udc.portlets. gissearcherportlet.model.impl.yahoo.yahoogeocodeservice</value> 16 </init param> 17 <init param> 18 <name>google Maps</name> 19 <value>es.udc.portlets. gissearcherportlet.model.impl.google.googlegeocodeservice</value> 20 </init param> 21 <init param> 22 <name>mock</name> 23 <value>es.udc.portlets. gissearcherportlet.model.impl.mock.mockgeocodeservice</value> 24 </init param> <expiration cache>1200</expiration cache> <supports> 29 <mime type>text/html</mime type> 30 <portlet mode>view</portlet mode> 31 <portlet mode>edit</portlet mode> 32 <portlet mode>help</portlet mode> 33 </supports> <supported locale>en</supported locale> 36 <supported locale>gl</supported locale> 37 <supported locale>es</supported locale> <resource bundle>es.udc.portlets.gissearcherporlet.view.messages.messages</resource bundle> <portlet info> 42 <title>callejero</title> 43 <short title>callejero</short title> 44 <keywords>gis, callejero</keywords> 45 </portlet info> <portlet preferences> 48 <preference> 49 <name>yahoolicense</name> 50 <value>nupugofv34fks7hduu8k0vvxqgkf47t5dd7rdra58wtx cumbbnvj0omecymm4zfwa </value> 51 </preference> 52 <preference> 53 <name>googlelicense</name> <value>abcdef</value> 54 </preference> 55 <preference> 56 <name>geocodeservicename</name> <value>google Maps</value> 57 </preference> 58 <preference> 59 <name>maxnumresultados</name> <value>5</value> 60 </preference> 61 <preference> 62 <name>useproxy</name> <value>false</value> 63 </preference> 64 <preference> 65 <name>hostproxy</name> <value>proxy</value> 66 </preference>

157 Implementación <preference> 68 <name>portproxy</name> <value>3128</value> 69 </preference> 70 </portlet preferences> <supported publishing event> 73 <qname xmlns:x= >x:addgeopointtoviewer</qname> 74 </supported publishing event> 75 </portlet> <event definition> 78 <qname xmlns:x= >x:addgeopointtoviewer</qname> 79 <value type>es.udc.portlets.gispoint.model.facade.geographicpointto</value type> 80 </event definition> </portlet app> Especifica todos los portlet que componen la aplicación Web: portlet-class Clase controlador que implementa la API de portlets. init-param Declaraciones de inicialización de parámetros expiration-cache Número de segundos que el contenedor cacheará el markup del portlet supports especifica los modos soportados por el portlet para ese markup supported-locale Permite declarar los Locales soportados por el portlet resource-bundle Necesario si se quiere internacionalizar la información que aparece en portiet-info. Especifica el recurso (fichero.properties o clase) que contiene los mensajes. Tiene que contener las claves javax.portlet.title, javax.portlet.short-title y javax.portlet.keywords. Recursos de mensajes Contienen los mensajes de la aplicación, los de la aplicación contiene tantos como idiomas soportados, en nuestro caso tres: Messages en, Messages es, Messages gl.properties portlet-info Información básica del portlet title Título que aparece por defecto (GenericPortiet.getTitle) en la ventana del portlet. portlet-preferences Especifica las preferencias iniciales que tendrá la instancia recién creada de un portlet. supported-publishing-event Definición del nombre de los eventos que publica para la comunicación entre portlets

158 132 Capítulo 8 supported-processing-event Definición del nombre de los eventos que desea recibir. event-definition Definición del evento al objeto esperado de tipo valido JAXB [55] primitivo esperando (String, double, integer o objeto compuesto a su vez de estos). JAXB es un estándar Java para convertir el estado de instancias de clases Java a XML y viceversa. Java SE 6.0 incluye el API de JAXB y una implementación por defecto. Controlador El esqueleto básico de este portlet es el el siguiente: view ) 2 public void processviewmode (RenderRequest request, RenderResponse response throws PortletException, IOException 3 { 4 //... MODO VISTA 5 } 6 edit ) 8 public void processeditmode (RenderRequest request, RenderResponse response throws PortletException, IOException 9 { 10 //... MODO CONFIGURACION 11 } 12 help ) 14 public void processhelpmode (RenderRequest request, RenderResponse response throws PortletException, IOException 15 { 16 //... MODO AYUDA 17 } 18 searchproducts ) 20 public void firesearchproducts(actionrequest request, ActionResponse response) throws PortletException, IOException 21 { 22 //... OPERACIÓN BUSCAR 23 } 24 addgeopointtoviewer ) 26 public void sendaddgeopointtoviewerevent(actionrequest request, ActionResponse response) throws PortletException, IOException 27 { 28 //... OPERACIÓN ENVIAR EVENTO MARCADOR 29 } 30 save ) 32 public void save(actionrequest request, ActionResponse response) throws PortletException, IOException 33 { 34 //... OPERACIÓN GUARDAR CONFIGURACIÓN 35 } El Controlador detecta un cierto número de posibles errores de configuración, parámetros validos o búsquedas vacías.

159 Implementación 133 Anotaciones: El procesamiento de las peticiones de acción se podría haber implementado al estilo de la version 1.0 creando un método que redefina processaction y una serie de if s anidados para tomar la decisión. En la version 2.0, la implementación de processaction en GenericPortlet intenta delegar el procesamiento de la petición de acción en un método anotado con ProcessAction, cuyo elemento name especifique el valor del parámetro javax.portlet.action: Evita tener que redefinir processaction como una coleccion de if s. Los métodos anotados con ProcessAction se deben declarar como: void <methodname>(actionrequest, ActionResponse) throws PortletException, java.io.ioexception; Envio de eventos: Un evento se puede enviar durante el procesamiento de una petición de acción o una petición de evento. Las interfaces ActionResponse y EventResponse extienden a la interfaz StateAwareResponse, que incluye el método: void setevent(qname name, Serializable value) El evento no se envia en este momento, sino que se añade a la respuesta (Action- Response o EventResponse, dependiendo del tipo de petición). Para especificar el nombre del evento se utiliza javax.xml.qname que representa un nombre cualificado que forma parte del API de Java SE.

160 134 Capítulo 8 Modelo Servicios geolocalización Los Servicios de geolocalización implementan todos la interfaz GeocodeService que tiene dos métodos, uno para consultar el nombre del servicio getservicename() y otro para resolver posiciones geográficas getgeographicpoint(string direccion, int maxsize) donde dirección puede ser un domicilio, un pais, un estado etc. a consultar la posición y maxsize el numero máximo de soluciones candidatas que permita devolver. 1. Suponemos que consultamos desde la interfaz Web la posición de Coruña y que el servicio concreto es Google maps (puede variar ligeramente de un servicio a otro). 2. Componemos la URL según la especificación de la API de la forma: xml&gl=es 3. En este caso recibimos un XML: 1 2 <?xml version= 1.0 encoding= UTF 8?> 3 <kml xmlns= ><Response> 4 5 <name>coruña</name> 6 7 <Status> 8 <code>200</code> 9 <request>geocode</request> 10 </Status> <Placemark id= p1 > 13 <address>a Coruña, España</address> <AddressDetails Accuracy= 4 > <Country> 18 <CountryNameCode>ES</CountryNameCode> 19 <CountryName>España</CountryName> <AdministrativeArea> 22 <AdministrativeAreaName>GA</AdministrativeAreaName> <SubAdministrativeArea> 25 <SubAdministrativeAreaName>La Coruña</SubAdministrativeAreaName> <Locality> 28 <LocalityName>A Coruña</LocalityName> 29 </Locality> 30 </SubAdministrativeArea>

161 Implementación </AdministrativeArea> 32 </Country> 33 </AddressDetails> <ExtendedData> 36 <LatLonBox north= south= east= west= /> 37 </ExtendedData> <Point> 40 <coordinates> , ,0</coordinates> 41 </Point> 42 </Placemark> 43 </Response> 44 </kml> 4. Parseamos con JDOM el XML recorriendo el Path, para quedarnos únicamente con los datos que nos interesan: dirección, latitud y longitud. 5. Encapsulamos los datos obtenidos en un objeto GeograficPointTO. 6. El método devuelve al controlador una lista de GeograficPointTO s. 7. Cuando llega al controlador se lo envia a la vista para que muestre los resultados obtenidos al usuario. Vista Fichero WEB-INF/view.jsp 1 < % Search form %> 2 <portlet:actionurl var= searchproductsurl /> 3 4 <form action= ${searchproductsurl} method= post > 5 <input type= hidden name= javax.portlet.action value= searchproducts > 6 <table width= 100 % > 7 <tr> 8 <td align= left > <b><fmt:message key= view.info /> </b> </td> 9 <td align= right > <b>[${geocodeservicename}]</b><td> 10 </tr> 11 </table> <input type= text style= width:100 % name= keywords value= ${keywords} class= portlet form input field maxlength= 500 > 14 <input type= submit class= portlet form button value= <fmt:message key= view.search /> > <c:if test= ${!empty keywordserror} > 17 <span class= portlet msg error > 18 <fmt:message key= ${keywordserror} /> 19 </span> 20 </c:if> 21 </form> 22 <br> < % Search result %> 25 <c:if test= ${!empty showsearchresult} > <c:choose> 28 < % gispoint not found %>

162 136 Capítulo 8 29 <c:when test= ${empty gispoints} > 30 <span class= portlet msg alert > 31 <fmt:message key= view.noresultsfound /> 32 </span> 33 </c:when> 34 <c:otherwise> < % Print gispoints %> 37 <table width= 100 % border= 1 cellspacing= 1 rules= rows frame= hsides > 38 < % Table header %> 39 <tr class= portlet section header style= border bottom: groove > 40 <th background: lightgrey bgcolor= lightgrey > <fmt:message key= view.gispoint.id /> </th> 41 <th background: lightgrey bgcolor= lightgrey > <fmt:message key= view.gispoint.address /> </th> 42 <th background: lightgrey bgcolor= lightgrey > <fmt:message key= view.gispoint.latitude /> </th> 43 <th background: lightgrey bgcolor= lightgrey > <fmt:message key= view.gispoint.longitude /> </th> 44 </tr> < % gispoints %> 47 <c:foreach var= gispoint items= ${gispoints} varstatus= status > <portlet:actionurl var= addgeopointtoviewerurl > 50 <portlet:param name= javax.portlet.action value= addgeopointtoviewer /> 51 <portlet:param name= id value= ${gispoint.id} /> 52 <portlet:param name= address value= ${gispoint.address} /> 53 <portlet:param name= latitude value= ${gispoint.latitude} /> 54 <portlet:param name= longitude value= ${gispoint.longitude} /> 55 <portlet:param name= keywords value= ${keywords} /> 56 </portlet:actionurl> <c:choose> 59 <c:when test= ${status.index % 2== 0} > 60 <tr class= portlet section body > 61 </c:when> 62 <c:otherwise> 63 <tr class= portlet section alternate > 64 </c:otherwise> 65 </c:choose> <td width=5>${gispoint.id}</td> 68 <td><a href= ${addgeopointtoviewerurl} > ${gispoint.address}</a></td> 69 <td width=65>${gispoint.latitude}</td> 70 <td width=65>${gispoint.longitude}</td> 71 </tr> 72 </c:foreach> 73 </table> 74 </c:otherwise> 75 </c:choose> 76 </c:if> Como parte del API de portlets, se proporciona una librería de tags JSP: defineobjects: Define las variables renderrequest, renderresponse y portlet- Config renderurl: Genera una URL que provoca una petición de renderización actionurl: Genera una URL que provoca una petición de acción param: Para añadir parámetros a renderurl y actionurl namespace: Devuelve un nombre único para el portlet actual. Útil para evitar

163 Implementación 137 conflictos de nombres Estilos CSS estándar: Para lograr un look-n-feel consistente entre los portlets de una misma página y para independizarlo de un portal particular, la especificación de Portlets Java utiliza los estilos definidos en WSRP. Impresión de URLs: En el ejemplo, las URLs se imprimen especificando escapexml= false en <c:out> Internacionalización: En commonheader.jsp se fija (fmt:setlocale) el valor del Locale para JSTL en base al valor elegido por el portal (PortletRequest.getLocale) El portal puede elegir el Locale en base a la cabecera Accept-Language (lista de idiomas preferidos en el navegador) y/o en base a los datos de perfil de usuario- Los mensajes son pares clave-valor de la forma: Fichero WEB-INF/view.jsp 1 2 view.info=dirección: 3 view.search=buscar 4 view.noresultsfound=no se encontró ningún resultado 5...

164 138 Capítulo GisPointVO gispointvo.jar es.udc.portlets.gispoint model facade META-INF maven es.udc.portlets.gissearcherportlet gispointvo Figura 8.3: Diagrama de paquetes, estructura interna GisPointVO.jar GisPointVO es un encapsulamiento de una única clase GeographicPointTO.java compilado y empaquetado como jar que contiene dentro el binario.class correspondiente. Se emplea como librería común para el paso de eventos, que debe ser almacenado en la librería común del tomcat para que no existan conflictos de Des/- Serialización.

165 Implementación 139 Debe cumplir la especificación JAXB para que sea válida: Los tipos primitivos y sus contrapartidas objetuales son: java.math.biginteger, java.math.bigdecimal, java.lang.string, java.util.calendar, java.util.date, clases Java a medida de tipos validos JAXB, java.util.collection (y subtipos) de tipos validos JAXB, java.util.map (y subtipos) de tipos validos JAXB y arrays ([]) de tipos validos JAXB. Tienen que implementar java.io.serializable Tienen que anotarse con javax.xml.bind.annotation.xmlrootelement Tener un constructor sin argumentos Tener métodos get/set para sus propiedades En otros sistemas como JBoss Portal se debe incluir dentro de la carpeta lib de los WARS de los portlets para que funcione. Una forma es copiarlo manualmente empleando WinRAR y otra es modificando el fichero pom.xml comentando/borrando la linea provided librería: 1 <dependency> 2 <groupid>gispointvo</groupid> 3 <artifactid>gispointvo</artifactid> 4 <version>0.1</version> 5 <scope>provided</scope> 6 </dependency>

166 140 Capítulo GisViewerPortlet gissearcherportlet.war img META-INF maven es.udc.portlets.gissearcherportlet gissearcherportlet WEB-INF classes es.udc.portlets.gissearcherportlet controller model exceptions facade impl google mock yahoo view messages lib Figura 8.4: Diagrama de paquetes: estructura interna GisViewerPortlet.war

167 Implementación 141 Datos de entrada Fichero WEB-INF/web.xml 1 <?xml version= 1.0 encoding= UTF 8?> 2 3 <web app version= xmlns= 5 xmlns:xsi= instance 6 xsi:schemalocation= app 2 4.xsd > 7 8 <display name>gisportlet</display name> 9 <description>it contains a portlet allowing to use a View Maps</description> 10 <! Disabled by default, since some versions of JBoss Portal server do not support clustering. 11 <distributable/> 12 > 13 <! ======================= Standard TagLibs configuration ============== > <context param> 16 <param name>javax.servlet.jsp.jstl.fmt.localizationcontext</param name> 17 <param value>es.udc.portlets.gisviewerportlet.view.messages</param value> 18 </context param> <context param> 21 <param name>javax.servlet.jsp.jstl.fmt.fallbacklocale</param name> 22 <param value>en</param value> 23 </context param> 24 </web app> Fichero WEB-INF/portlet.xml 1 <?xml version= 1.0 encoding= utf 8?> 2 <portlet app xmlns= app 2 0.xsd 3 xmlns:xsi= instance 4 xsi:schemalocation= app 2 0.xsd portlet app 2 0.xsd 5 version= 2.0 > 6 <portlet> 7 <description>gis Openlayers Map Portlet</description> 8 <portlet name>gisviewerportlet</portlet name> 9 <display name>gisviewerportlet</display name> 10 <portlet class>es.udc.portlets.gisviewerportlet. controller.gisviewerportlet</portlet class> <expiration cache>1200</expiration cache> <supports> 15 <mime type>text/html</mime type> 16 <portlet mode>view</portlet mode> 17 <portlet mode>edit</portlet mode> 18 <portlet mode>help</portlet mode> 19 </supports> <supported locale>en</supported locale> 22 <supported locale>gl</supported locale> 23 <supported locale>es</supported locale> <resource bundle> es.udc.portlets.gisviewerportlet.view.messages.messages</resource bundle> <! Needed for some portal servers (e.g. exo and Pluto), despite these values are defined in the resource bundle. > <portlet info>

168 142 Capítulo 8 30 <title>gis Map Portlet</title> 31 <short title>gis Portlet</short title> 32 <keywords>gis, map</keywords> 33 </portlet info> <portlet preferences> 36 <preference> 37 <name>layers</name> 38 <value>google( Google Hybrid, {type: G HYBRID MAP, sphericalmercator : true});</value> 39 <value>google( Google Streets, { sphericalmercator : true});</value> 40 <value>google( Google Satellite,{type: G SATELLITE MAP, sphericalmercator : true, numzoomlevels: 22});</ value> 41 <value>google( Google Physical, {type: G PHYSICAL MAP, sphericalmercator : true} );</value> 42 <value>yahoo( Yahoo Hybrid,{ type : YAHOO MAP HYB, sphericalmercator : true});</value> 43 <value>yahoo( Yahoo Street, { sphericalmercator : true});</value> 44 <value>yahoo( Yahoo Satellite, { type : YAHOO MAP SAT, sphericalmercator : true});</value> 45 <value>virtualearth( Virtual Earth Roads, { type : VEMapStyle.Road, sphericalmercator : true});</value> 46 <value>virtualearth( Virtual Earth Aerial,{ type : VEMapStyle.Aerial, sphericalmercator : true});</value> 47 <value>virtualearth( Virtual Earth Hybrid, { type : VEMapStyle.Hybrid, sphericalmercator : true});</value> 48 <value>osm.mapnik( Mapnik );</value> 49 <value>osm.osmarender( Osmarender );</value> 50 <value>osm.cyclemap( CycleMap );</value> 51 <! 52 <value>wms( Comarcas Coruña, {layers: municipal:comarcas, transparent: true, format: image/png, projection: new OpenLayers.Projection( EPSG:23029 ) }, { isbaselayer :true});</value> 53 <value>wms( Praias, {layers: galicia:praias, transparent: true, format: image/png, projection: new OpenLayers.Projection( EPSG:23029 ) }, { isbaselayer :false}); layer. visibility = false ; </value> 54 <value>wms( Estradas, {layers: gis galicia:estradas, transparent: true, format: image/png, projection: new OpenLayers.Projection( EPSG:23029 ) }, { isbaselayer :false}); layer. visibility = false ; </value> 55 <value>wms( Viario, {layers: eiel cartografia base:municipio viario, transparent: true, format: image/png, projection: new OpenLayers.Projection( EPSG:23029 ) }, { isbaselayer :false}); layer. visibility = false ;</value> 56 <value>wms( Hidrografia, {layers: eiel cartografia base:municipio hidrografia, transparent: true, format: image/png, projection: new OpenLayers.Projection( EPSG:23029 ) }, { isbaselayer :false}); layer. visibility = false ;</value> 57 > 58 </preference> <preference> 61 <name>bounds</name> 62 <value>bounds( , , , );</value> 63 </preference> <preference> 66 <name>map</name> 67 <value>map ( map, { $ 68 >> controls: [ $ 69 >> >> new OpenLayers.Control.Navigation(), $ 70 >> >> new OpenLayers.Control.PanZoomBar(), $ 71 >> >> new OpenLayers.Control.LayerSwitcher(), $ 72 >> >> new OpenLayers.Control.Attribution()], $ 73 >> maxextent: bounds, $ 74 >> maxresolution: auto, $ 75 >> numzoomlevels: 25, $ 76 >> units: m, $ 77 >> projection: new OpenLayers.Projection( EPSG: ), $ 78 >> displayprojection: new OpenLayers.Projection( EPSG:4326 ) $ 79 >>}); $ 80 </value> 81 </preference> <preference> 84 <name>other</name> 85 <value>var loninit = ; $ 86 var latinit = ; $

169 Implementación var lonlatinit = new OpenLayers.LonLat(lonInit,latInit).transform(new OpenLayers.Projection( EPSG:4326 ), map.getprojectionobject()); $ 88 var zoominit = 12; $ 89 map.setcenter(lonlatinit, zoominit); $ 90 $ 91 var zoommarker = 13; $ 92 </value> 93 </preference> <preference> 96 <name>sizemap</name> 97 <value>430</value> 98 </preference> </portlet preferences> <supported processing event> 103 <qname xmlns:x= >x:addgeopointtoviewer</qname> 104 </supported processing event> 105 </portlet> <event definition> 108 <qname xmlns:x= >x:addgeopointtoviewer</qname> 109 <value type>es.udc.portlets.gispoint.model.facade.geographicpointto</value type> 110 </event definition> </portlet app> Controlador: Los principios básicos son los mismos que el portlet GisSearcherPortlet, difiere ligeramente como la existencia del método consumidor del evento que ya se explicó anteriormente. El esqueleto básico de este portlet es el el siguiente: view ) 2 public void processviewmode (RenderRequest request, RenderResponse response throws PortletException, IOException { 3 //... MODO VISTA 4 } 5 edit ) 7 public void processeditmode (RenderRequest request, RenderResponse response throws PortletException, IOException { 8 //... MODO CONFIGURACION 9 } 10 help ) 12 public void processhelpmode (RenderRequest request, RenderResponse response throws PortletException, IOException { 13 //... MODO AYUDA 14 } 15 removegeomarker ) 17 public void removegeomarker(actionrequest request, ActionResponse response) throws PortletException, IOException 18 { 19 //... ELIMINAR MARCADOR 20 }

170 144 Capítulo 8 21 removelayer ) 23 public void removelayer(actionrequest request, ActionResponse response) throws PortletException, IOException 24 { 25 //... ELIMINAR CAPA GEOGRAFICA 26 } addlayer ) 30 public void addlayer(actionrequest request, ActionResponse response) throws PortletException, IOException 31 { 32 //... AÑADIR CAPA GEOGRAFICA 33 } 34 { ) 36 public void processaddgeopointmarkertoviewerevent(eventrequest request, EventResponse response) throws PortletException, IOException { 37 //... RECIBIR EVENTO 38 } 39 save ) 41 public void save(actionrequest request, ActionResponse response) throws PortletException, IOException 42 { 43 //... OPERACIÓN GUARDAR CONFIGURACIÓN 44 } Vista: La Vista emplea la librería de OpenLayers está contenido en el propio fichero WAR. Cuando recibe un evento de otro portlet centra el visor a las coordenadas recibidas con un zoom configurable. Como información relevante al respecto comentar que como los portlets reciben un evento se resetea el estado, se optó por una solución sencilla y eficiente como es la creación de una cookie temporal que almacene en el navegador la capa base geográfica seleccionada. NOTA: El código introducido en la vista del modo edición no valida previamente la sintaxis por lo que debe ser verificada manualmente.

171 CAPÍTULO 9 PRUEBAS 9.1 Pruebas unitarias En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos: Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua. Completas: deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. 145

172 146 Capítulo 9 Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc. Aunque estos requisitos no tienen que ser cumplidos a rajatabla, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función. El objetivo de las pruebas unitarias es aislar, cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas: 1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores. 2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración. 3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo. 4. Separación de la interfaz y la implementación. 5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software. Existe software dedicado a automatizar estas pruebas unitarias, el más conocido

173 Pruebas 147 en el entorno Java es JUnit que se puede automatizar mediante el uso de maven2. Al ser muy bien definidas las acciones posibles desde la vista se optó por hacer pequeñas funciones informal que comprobara las clases implicadas probando los casos extraños. Ejemplo de ello es la clase GeocodeServiceFactory que ejecuta desde consola las implementaciones concretas de los servicios de geolocalización e imprime los resultados obtenidos por consola. 9.2 Pruebas de integración Las pruebas de integración (algunas veces llamadas Integración y Testeo I&t) son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos y a su vez con la plataforma. 9.3 Pruebas de rendimiento Liferay en modo producción, por defecto cachea partes para obtener mejor rendimiento, la fluidez se basa en la utilización de AJAX se asemeja mucho a una aplicación de escritorio. El rendimiento de Geoserver depende del número de peticiones simultaneas, para proveer de mapas intensivamente se recomienda una máquina bastante potente o dedicada. El rendimiento en de los portlets es muy fluida, en el caso del georeferenciador la respuesta es casi instantánea y en el caso del Visor determina el tiempo de respuesta el número de capas que deba cargar y el ancho de banda (si accede a internet.

174 148 Capítulo Pruebas de compatibilidad Se comprobó que cumplía el estándar perfectamente los Portlets realizados ejecutándolo sobre JBoss Portal además de la de producción Liferay. Figura 9.1: Pruebas de integración con JBoss Portal 9.5 Pruebas de stress Las pruebas de stress consiste en realizar miles de accesos simultáneos para comprobar la capacidad de respuesta con multitud de usuarios concurrentes. La capacidad viene dada por la que soporte Tomcat junto con Liferay y GeoServer (y como esté configurada) y está avalada por su uso intensivo y cotidiano en Internet. La cantidad de memoria RAM y de cómputo del servidor que soporte la infraestructura desarrollada influye decisivamente en este aspecto.

175 Pruebas Pruebas de aceptación Consisten en que el usuario, en este caso tanto son mi tutor y director (Miguel Ángel Rodríguez Luaces y David Trillo Pérez) que desempeñaban ese rol dieran su visto bueno con resultados de la aplicación desarrollada, documentación, en definitiva que todos sus requisitos han sido satisfechos. Como se comentó en el capítulo 5 de Metodología el seguimiento continuado junto con el prototipado, hacen que las desviaciones en este sentido se minimicen.

176 150 Capítulo 9

177 CAPÍTULO 10 RESULTADOS Y RENDIMIENTO 10.1 GisScriptMun Desplegar infraestructura municipal Desde una interfaz muy sencilla permite desplegar toda la infraestructura configurada simplemente marcando el checkbox y Aceptar. De modo análogo da acceso al resto de funcionalidades avanzadas. 151

178 152 Capítulo 10 Figura 10.1: GisScriptMun: Principal Consultas SQL Las consultas de SQL, permiten interactuar con la base de datos por medio del protocolo JDBC 1 que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java, independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice. El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de manejadores de conexión hacia cada modelo específico de base de datos. Un manejador de conexiones hacia un modelo de base de datos en particular es un conjunto de clases que implementan las interfaces Java y que utilizan los métodos de registro para declarar los tipos de localizadores de base de datos (URL) que pueden manejar. 1 JDBC: Java Database Connectivity

179 Resultados y rendimiento 153 Figura 10.2: GisScriptMun: Consultas SQL Para utilizar una base de datos particular, el usuario ejecuta su programa junto con la librería de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión; para ello provee el localizador a la base de datos y los parámetros de conexión específicos Configuración Desde el menú de configuración permite: Configurar Base de datos: Permite configurar los parámetros necesarios para acceder a una base de datos, la información contenida es la siguiente: Host: determina donde está la base de datos normalmente es en la propia máquina por lo que es localhost = a no ser que la base de datos sea distribuida entonces sería la IP 2 que de la máquina donde se encuentra la base de datos. Usuario: login del propietario y/o usuario con permisos para acceder a la base de datos. Password: clave correspondiente al Usuario antes mencionado. Añadir que esta clave se mantiene cifrada por lo que no habría problemas en ese sentido de seguridad. 2 IP: Internet Protocol

180 154 Capítulo 10 BD: nombre de la Base de Datos que contiene las tablas con geometrías. Puerto: dirección del puerto asignado a la base de datos desde la que acceder. Parámetros: Permite configurar otros parámetros relativos a diferentes aspectos de la aplicación. Tabla Index: Nombre de la tabla que almacena lso indices. Schema: Schema origen de los datos ID vista: coletilla que antece al nombre de la tabla de las vistas creadas. ID municipio: coletilla que antece al municipio. fichero LOG: nombre de fichero donde almacena la traza de comandos realizados por la aplicación Creación Vistas La creación de vistas de la EIEL completa, permite agregar de una lista de municipios por los que se desea filtrarse, posteriormente al pulsar el botón Aplicar generara un Informe en la que permite seleccionar las tablas que se desean generar las vistas. Finalmente pulsar el botón Continuar para generarlos.

181 Resultados y rendimiento 155 Figura 10.3: GisScriptMun: Creacción de vistas 10.2 GisMapPortlets Todos los porlets disponen de una interfaz común, desde el menú superior -si dispone de los permisos adecuados- permite elegir el modo (por defecto vista) y los botones al lado se corresponden con las opciones de minimizarlo, maximizarlo o cerrarlo, pueden variar ligeramente en función del diseño elegido. A la izquierda de la imagen está situado el Callejero y a derecha el Visor cartográfico. El callejero su funcionamiento es muy simple, consiste en escribir la dirección y pulsar a Buscar. El visor inicialmente muestra la información sobre la que esté configurado (las coordenadas del municipio del menú configuración del portlet).

182 156 Capítulo 10 Figura 10.4: GisMapPortlets: Liferay menú modo Al pulsar sobre los resultados obtenidos, genera un evento, que obliga al visor a centrarse sobre ese punto geográfico obtenido (latitud y longitud). Figura 10.5: GisMapPortlets: Liferay menú vista evento

183 Resultados y rendimiento 157 El modo configuración permite múltiples combinaciones para dar cabida a todo tipo de posibilidades. En el callejero se puede ver sobre la imagen el servicio de geolocalización, en este caso seleccionado Google Maps y el poder elegir un número máximo de resultados (si se maximiza ignora este límite y muestra todos los resultados). En el visor se ve a simple vista las capas disponibles configuradas y otros parámetros relevantes como es la altitud del portlet (en anchura se ajusta al tamaño disponible). Figura 10.6: GisMapPortlets: Liferay menú configuración

184 158 Capítulo 10 El menú ayuda muestra información acerca del proyecto con un texto explicativo que, a grosso modo, explica su funcionalidad. Figura 10.7: GisMapPortlets: Liferay menú ayuda Para más información acerca de los portlets consultar el manual correctamente en la página Resultados obtenidos Se han desarrollado dos portlets: el primero de ellos para proporcionarle de capacidad de georeferenciación cartográfica GisSearcherPortlet y el segundo de visor de cartográfico personalizable GisViewerPortlet con el que poder publicar información geográfica de múltiples fuentes, tanto locales (empleando protocolos estándar WMS y WFS) como externas: Google Maps, Yahoo Maps, OpenStreetMap, SigPac, Catastro...

185 Resultados y rendimiento 159 Pensando en los administradores inexpertos se ha desarrollado interfaces amigables, realizado un instalador GisScriptMun que además proporciona funcionalidades avanzadas para la carga de mapas que pueden ser de dos formas posibles: mediante scripts municipales de la EIEL, o bien, mediante la restauración de un backup completo. También permite la creación automatizada de vistas municipales para poder filtrar por municipio/s la información Rendimiento Su rendimiento es muy eficiente, en el caso del callejero simplemente actúa de intermediario de los servicios disponibles por lo que no consume recursos, en el caso del visor el esfuerzo de carga lo realiza el cliente por lo que depende simplemente de las fuentes que en el momento muestre que determina la velocidad. En el caso del servicio geoserver, para servir múltiples peticiones simultáneas precisa de elevados recursos (como puede ser de CPU y memoria) que determinan el tiempo de respuesta.

186 160 Capítulo 10

187 CAPÍTULO 11 SÍNTESIS DEL TRABAJO En este capítulo se explican las conclusiones obtenidas una vez finalizado el proyecto, así como posibles mejoras que puedan realizarse Conclusiones En este proyecto se han alcanzado todos los objetivos marcados: sobre una plataforma libre elegida Liferay, se han desarrollado dos portlets: el primero de ellos para proporcionarle de capacidad de georeferenciación cartográfica GisSearcherPortlet y el segundo de visor de cartográfico personalizable GisViewerPortlet con el que poder publicar información geográfica de múltiples fuentes, tanto locales (empleando protocolos estándar WMS y WFS) como externas: Google Maps, Yahoo Maps, OpenStreetMap, Catastro... En el análisis se desarrollaron una serie de prototipos con el fin de comprender los requisitos del usuario, del dominio y los implícitos, y familiarizarse con el entorno de desarrollo. 161

188 162 Capítulo 11 Se llevó a cabo un estudio exhaustivo comparativo de plataformas gestores de contenidos (CMS) para tomar la elección más idónea que se adecuara al cometido que debe desempeñar: Realización de una Web genérica municipal. Se tradujo la plataforma seleccionada para soportar el idioma gallego (gl ES), se personalizó con el logotipo municipal, se configuró y se agregaron las secciones típicas: Principal, Novedades, Foros, Patrimonio, Fiesta, Contactos y Callejero. Pensando en los administradores inexpertos se ha desarrollado interfaces amigables, realizado un instalador GisScriptMun con el que desplegar la plataforma inicialmente además de un manual de usuario con el que resolver todo tipo de dudas (anexado en el apéndice A en la página 171). La misma aplicación GisScriptMun proporciona funcionalidades avanzadas para la carga de mapas que pueden ser de dos formas posibles: mediante scripts municipales de la EIEL, o bien, mediante la restauración de un backup completo. También permite la creación automatizada de vistas municipales para poder filtrar por municipio/s la información. Todas las aplicaciones realizadas se han diseño usando patrones y estándares (documentados completamente con el uso de diagramas UML [56]), destaca en dificultad el diseño e implementación del estándar JSR-286 para la creación de los portlets genéricos, con soporte de comunicación empleando la técnica del paso eventos. El principal ventaja es la capacidad de portabilizar a todo tipo de plataformas que den soporte a dicho estándar y no restringiéndose por lo tanto a la elección tomada. En el proceso de desarrollo se han tenido diversos problemas, pero se han buscado soluciones, o bien alternativas, preguntando a personas más experimentadas en el dominio del problema, que en definitiva es lo que considero que se persigue: la habilidad de resolver problemas no estructurados.

189 Síntesis del trabajo 163 Se ha empleado múltiple tecnología, por citar los más relevantes Eclipse me han facilitado el trabajo de desarrollo y la potencia de Photoshop es inigualable para la edición de imágenes; OpenLayers está muy bien estructurado y dispone de buena documentación con múltiples ejemplos algo poco habitual en el mundillo informático, aunque la curva de aprendizaje es bastante pronunciada para un principiante. El servidor de mapas Geoserver se echa de menos capacidad de publicación automática de tablas o al menos de carga por lotes de estilos SLD de manera sencilla puesto que es muy tedioso realizarlo uno a uno. Sobre la redacción de la memoria, L A TEX [57][58][59] proporciona resultados muy profesionales. De los resultados obtenidos concluir que el conjunto de las dos extensiones realizadas es igual o superior a callejeros convencionales, puesto que proporciona capacidad de configuración dinámica (si dispone de permisos) y la implementación de multiples detalles que facilitan la vida a los usuarios (maximización del mapa, uso de marcadores, múltiples fuentes origen, etc.) Se ha realizado una planificación casi perfecta: se comenzó el proyecto 5 meses antes de lo habitual para evitar sobrecargas de trabajo, se realizó una planificación pesimista para tener holgura de sobra, evitar desagradables sorpresas y poder alcanzar las mayores cotas de perfección posible. Se llevo a cabo un seguimiento informal marcándose unos hitos y realizando revisiones continuas para saber en todo momento cómo va el proyecto además de la realización de informes para que la dirección tuviera constancia escrita del estado del proyecto. Aunque pueda resultar paradójico, se consiguió aumentar requisitos iniciales y reducir los costes y el trabajo reales aproximadamente en un 16 % con respecto a lo previsto. Los datos númericos reales que resumen el proyecto son horas de trabajo, horas de duración y e de coste. Con el fin de favorecer a la comunidad y con la autorización de la empresa, siguiendo la filosofía Open Source el presente trabajo será publicado íntegramente en Internet con licencia GNU General Public Licence v2.0.

190 164 Capítulo Experiencia en la empresa Se han obtenido resultados muy satisfactorios, tanto de rendimiento académico como de experiencia profesional en la empresa Enxenio SL. de la cual solo tengo buenas palabras. Se ha adquirido, mejorado o potenciado habilidades tanto de planificación, análisis, diseño como programación sobre todo en el ámbito de los Sistemas de información geográfica y especialmente con tecnologías web. Considero que gran parte del éxito es debido por los grupos de trabajo envidiable que componen la empresa, que además de impregnarte de sus conocimientos se ve el lado más humano, siendo en definitiva un elemento motivador que determina y fomenta el trabajo bien hecho Líneas de trabajo futuras Toda aplicación siempre es mejorable, algunas de las posibles mejoras opcionales que se han quedado fuera de los objetivos y por falta de tiempo no han sido implementadas han sido: Aunque se investigó la posibilidad de integrar en GisScriptMun comunicación con GeoServer con el fin de automatizar la tediosa tarea de publicación de tablas y generación automática de estilos, fue inviable puesto que no se encontró ningún software libre en lenguaje java con dicha funcionalidad. Se descartó la posibilidad de implementarla desde cero ya que en si mismo se correspondería con un nuevo proyecto. Sería interesante aprovechar los portlets callejero y visor con el uso de eventos estándares para poder georeferenciar cualquier tipo de contenido o incluso la detección y georeferenciación automática de direcciones. Por ejemplo si se dispone de un calendario con eventos municipales poder crear fácilmente links manuales fácilmente para visualizarlo. Otra posible mejora consistiría en aplicar novedosas técnicas que fusionan dos

191 Síntesis del trabajo 165 ámbitos en plena investigación: Geographic Information System (GIS) y Information Retrieval (IR) forman la Geographic Information Retrieval (GIR), con el fin de realizar un nuevo servicio de geolocalización para su uso con información geográfica local (extendiendo de la interfaz GeocodeService) y empleando indexación eficiente de la información almacenada en la Base de Datos de la EIEL.

192 166

193 BIBLIOGRAFÍA [1] Enxenio S.L. [2] PostgreSQL. [3] Geschwinde, Ewald. Postgresql developer s handbook. Indianapolis, Indiana: Sam s [4] PostGIS. [5] OGC Open Geospatial Consortium. [6] Bruce Eckel. Piensa en java (Segunda edición). Pearson Education. ISBN: Madrid, [7] Proyecto EIEL. [8] Apache Tomcat. [9] Liferay. [10] Portlet definición. [11] Portlet especificación. [12] Portlet guía implementación. [13] Especificación WSRP. [14] Especificación JSR-168 (Version 1.0). [15] Especificación JSR-286 (Version 2.0). [16] Stefan Hepper, Oliver Koth, What s new in the Java Portlet Specification V2.0 (JSR 286). techarticles/0803_hepper/0803_hepper.html [17] GeoServer. [18] NASA

194 168 Capítulo [19] OpenLayers. [20] OpenLayers API desarrollo. [21] Comparativa Gestores de contenidos. [22] JBoss Portal. [23] Plone. [24] Pleides. [25] PrimaGis. [26] Drupal. [27] Drupal OpenLayers. [28] Drupal Gmap. [29] Drupal Gmaps. [30] Drupal Geo. [31] OpenCMS. [32] Joomla!. [33] WISroGIS. Joomla-Extensions/View-all-products.html [34] Proyecto Web municipal de Castellón. [35] Municipio de Arañuel. [36] Municipio de Abegondo Visor. [37] Municipio de Corcubion Visor. [38] Municipio de Valga. [39] Pressman, Roger S. Ingeniería del software. Un enfoque práctico. McGraw-Hill. 6 a edición [40] Listado de servicios WMS España. [41] Catastro. [42] PNOA. [43] Cartociudad. [44] Google maps.

195 BIBLIOGRAFÍA 169 [45] Yahoo maps. [46] Cartociudad. [47] OpenStreetMap. [48] Teoría de Portales. Dr. Fernando Bellas Permuy. fbellas/teaching/tp/index.html [49] Especificación JSTL. [50] Documentación JSTL (javadoc). [51] Google maps API. [52] Yahoo maps API. [53] Eclipse. [54] Traductor Español-Gallego. [55] Especificacón JAXB. Especificacion: [56] G. Booch, J. Rumbaugh, I. Jacobson. El lenguaje unificado de modelado. Addison Westley Iberoamericana. Madrid, [57] Documentación LaTeX 1. [58] Documentación LaTeX 2. [59] Mittelbach, Frank. The LaTeX companion. (2nd edition). Pearson Education. ISBN Boston, [60] PostgreSQL. Instalación desatendida 1. [61] PostgreSQL. Instalación desatendida 2. [62] Larman, C. UML y patrones. Una introducción a objetos y al proceso unificado. (Segunda edición) Pearson educación S.A. Matrid, [63] Definiciones glosario GIS.

196 170 Capítulo [64] Álvarez Úbeda, Miguel. Proyecto Fin de Carrera. Universidade da Coruña (2008). Herramienta de análisis de redes en un sistema de información geográfica.

197 APÉNDICE A MANUAL DE USUARIO A.1 Requisitos del sistema Para la ejecución de GisScriptMun debe estar instalado un entorno de ejecución Java (JRE) que implemente la versión 1.4 o superior de las APIs de Java 2 Standard Edition (J2SE) siendo bastante recomendable usar 5.x o 6.x. Sistema operativo Windows XP para poder realizar el despliegue por medio del instalador. El servidor en desarrollo requiere de una CPU potente, tipo Pentium 4 y un mínimo de memoria RAM de 2Gb, siendo muy recomendable de 4Gb de RAM para poder proporcionar tiempos de respuesta aceptables. Si se desea desarrollar o modificar la aplicación, es recomendable usar Eclipse y para mayor comodidad tener instalado el sistema de construcción Ant y maven2, que permitirá compilar fácilmente usando el fichero build.xml y pom.xml respectivamente. 171

198 172 Apéndice A A.2 Instalación y despliegue Copiar el instalador del DVD a un soporte que disponga permisos de lectura y escritura, como por ejemplo una carpeta en el Escritorio. Arrancar GisScriptMun ejecutando run.bat Figura A.1: GisScriptMun: Principal Seleccionar el primer checkbox y Aceptar. Puede tardar un tiempo elevado, aproximadamente 20 minutos, puesto que que debe insstalar Postres, Postgis de manera desatendida [60][61] y cargar todos la información cartográfica. A.2.1. Carga de datos Extrae toda la información del fichero Configuration.properties, siendo necesario modificarlo para elegir los datos municipales de otro municipio. 1 ficheromunicipal = true < Cargar Modo script Municipal < SCRIPTS 2 municipalfilezip =./instaladores/coruna.zip < Scrips Municipales ZIP MUNICIPALES 3 unzipoutfolder =./temp < Ubicación temporal de los scripts municipales < 4 5 restoreeielbd = false < Restore EIEL backup < 6 eieldbfilebackup =./instaladores/gis_eiel_2007_urbanserv_mar.backup < Backup EIEL EIEL 7 templateeiel = template0 < Plantilla EIEL 8 codificacioneiel = LATIN1 < Codificación EIEL < La carga puede ser de dos formas posibles en función de de los parámetros activos:

199 Manual de usuario 173 Método 1: carga mediante uso de scripts municipales activo ficheromunicipal = true Método 2: para cargar mediante vistas municipales EIEL modificar restoreeielbd = true NOTA: los métodos no son exclusivos, es posible cargar de las dos fuentes. A.2.2. PostgresSQL & PostGis La instalación por defecto instala la utilidad PgAdmin III, accesible desde el menú Inicio de Windows, para gestionar la información en la base de datos Figura A.2: PgAdmin III

200 174 Apéndice A A.3 Configuración A.3.1. Configuración inicial Servicio URL USUARIO CONTRASEÑA Tomcat admin admin Liferay admin@enxenio.es admin Geoserver admin geoserver Postgres Host: Puerto: 5432 postgres root Tabla A.1: Tabla configuraciones iniciales IMPORTANTE: Se recomienda con énfasis el cambio inicial de contraseñas para evitar accesos no permitidos. A.3.2. Tomcat Securización Para el cambio de contraseñas / roles de administración editar el fichero: liferay-portal-5.2.3/tomcat /conf/tomcat-users.xml 1 <?xml version= 1.0 encoding= utf 8?> 2 <tomcat users> 3 <role rolename= manager /> 4 <role rolename= admin /> 5 <user username= admin password= admin roles= admin,manager /> 6 </tomcat users> Cambio de puerto Hay varios servidores que usar por defecto el puerto 80 por lo qué puede ser necesario ubicarlo en otro puerto deseado, para ello simplemente hay que editar el fichero: liferay-portal-5.2.3/tomcat /conf/server.xml 1 <Connector port= 8080 protocol= HTTP/1.1 2 connectiontimeout= redirectport= 8443 URIEncoding= UTF 8 />

201 Manual de usuario 175 A.3.3. Geoserver Para la publicación de cartografía realizar los siguientes pasos: 1. Cambiar la información del servidor y la información de contacto: Entrar en la opción Configuración Servidor. Cambiar la información de contacto. Pulsar en enviar Guardar y aplicar los cambios. 2. Crear un nuevo espacio de nombres para las capas: Entrar en la opción Configuración Datos Espacio de Nombres Nuevo Introducir el prefijo gis municipal y pulsar en Nuevo. Introducir una URI válida como puede ser y pulsar en Enviar. Guardar y aplicar los cambios. 3. Configurar un nuevo almacén: Entrar en la opción Configuración Datos Almacenes Nuevo En la opción Descripción del Almacén de Datos seleccionar Postgis En la opción Identificador el Almacén de Datos escribir municipal almacen Rellenamos los datos del almacén escribiendo el nombre Database: municipal y el espacio de nombres previamente creado gis municipal, el Usuario con permisos sobre la BD postgres y su contraseña root ; el resto de los campos dejamos los configurados por defecto. Pulsar enviar Guardar y aplicar los cambios. 4. Configurar entidades: Entrar en la opción Configuración Datos Entidades Nuevo Crear las siguientes entidades asignándole a cada entidad el estilo creado correspondiente y dándole en encuadre a Generar para que calcular el bounding box y Enviar para salvar los cambios efectuados.

202 176 Apéndice A Por ejemplo: municipal almacen : viarios municipal almacen : hidrografía municipal almacen : comarcas Pulsamos Aplicar, Guardar y Cargar para que los cambios efectuados se apliquen. 5. Configurar WMS Entrar en la opción Configuración WMS Descripción Modificar la descripción del servicio Pulsar Enviar Entrar en la opción Configuración WMS Contenidos Crear un nuevo Layer Group Name (si se desea agrupar capas) con nombre gis municipal mapa base que incluya las siguientes capas antes creadas introduciendo en Base Map Layers, por si desea 6. Comprobar su funcionamiento Entrar en la opción Demostración Vista Preliminar de Mapas gis municipal mapa base

203 Manual de usuario 177 A.4 Liferay Existe información muy detallada en los manuales y foros con el que resolver las dudas en la web oficial de Liferay, también almacenados en el DVD. A.4.1. Principal Este es el menú principal nada más arrancar el servicio, en la parte superior están los controles y por defecto esta instalador una agenda de eventos, un publicador contenidos (que mostraría los cambios recientes efectuados en la aplicación) y a la derecha el visor desarrollado. Figura A.3: Liferay municipal: menú Principal

204 178 Apéndice A A.4.2. Novedades En la sección Novedades es un blog donde se pueden publicar contenidos mediante la inclusion de un editor de texto web incluído. Figura A.4: Liferay municipal: menú Novedades A.4.3. Turismo Aquí están situados una Wiki para poder añadir información de hoteles, rutas turísticas... También está un portlet para gestionar los enlaces web. Figura A.5: Liferay municipal: menú Turismo

205 Manual de usuario 179 A.4.4. Foros También incluye foros, para que los usuarios comenten, hagan propuestas etc. Figura A.6: Liferay municipal: menú Foros A.4.5. Patrimonio En la sección patrimonio inicialmente está configurada para subir documentos informativos, legislativos etc Figura A.7: Liferay municipal: menú Patrimonio

206 180 Apéndice A A.4.6. Fiestas En la sección fiestas está un gestor de imágenes para poder publicar fotos de los eventos culturales del municipio. Figura A.8: Liferay municipal: menú Fiestas A.4.7. Contactos Con el fin de facilitar la información telefónica del ayuntamiento se habilitó un directorio: Figura A.9: Liferay municipal: menú Contactos

207 Manual de usuario 181 A.4.8. Callejero Vista general de los portlets implementados. Figura A.10: Liferay municipal: menú portlets Su utilización es muy simple, se buscan direcciones y se pulsa el botón buscar, en el caso del Visor se usar los movimientos del ratón, pudiendo seleccionar la capa base y activar/desactivar capas. Sobre los resultados se pulsa la url obtenida fuerza al visor a posesionarse en esas coordenadas. Si en el visor se pulsa a Borrar vuelve a su estado normal. TRUCO: En el visor si se sostiene la tecla shift mientras selecciona una zona aplica zoom a dicha zona.

208 182 Apéndice A Su funcionamiento es muy simple, simplemente hay que buscar una dirección y hacer click en Buscar y al pulsar sobre los resultados obtenidos, genera un evento, que obliga al visor a centrarse sobre ese punto geográfico obtenido (latitud y longitud). Figura A.11: Liferay municipal: Vista

209 Manual de usuario 183 En el menú apariencia permite cambiar los estilos del portlets, tipo de texto etc. Figura A.12: Liferay municipal: Apariencia

210 184 Apéndice A En la sección configuración permite seleccionar los permisos a los roles. Figura A.13: Liferay municipal: Configuración Roles

211 Manual de usuario 185 En el menú Preferencias Figura A.14: Liferay municipal: Preferencias

212 186 Apéndice A En el caso del Callejero permite: Elegir el servicio de geolocalización: Google Maps, Yahoo Maps, Mock Dependiendo de la opción seleccionada requiere una licencia de uso correspondiente. Elegir el número de resultados posibles. en caso de estar maximizado ignora este límite para poder ver todos. Botón Guardar, para salvar los cambios efectuados. En el caso del Visor permite: Introducir nuevas capas de información geográfica. Utiliza la API de OpenLayers La forma más simple de agregar una nueva capa es viendo el código fuente del menú demostración de geoserver, buscar la linea correspondiente que lo define, copiar dicha instrucción y dar a Añadir. La instrucción NO debe tener el prefijo de la función new OpenLayers.Layer. empezando directamente por el tipo de capa. Se debe tener cuidado con que todas las capas deben usar el mismo tipo de proyección. Para el encuadre se usa la definición de Bounds de OpenLayers.Bounds. Para la definición del tipo de mapa OpenLayers.Map. de igual forma que las anteriores En otras configuraciones se puede cambiar la posición central, zooms iniciales, agregar controles etc. Es preciso declarar las líneas de código completas (en contraposición de los casos anteriores), toda la información esta disponible en Definir la altura del portlet, la anchura se ajusta al tamaño disponible de la sección.

213 Manual de usuario 187 En el menú ayuda muestra información a grosso modo de su funcionamiento. Figura A.15: Liferay municipal: Vista A.4.9. Configuración Desde el menu de añadir aplicaciones se pueden crear fácilmente arrastrándolo a la ventana modo plug-and-play. Figura A.16: Liferay municipal: Agregar un nuevo portlet

214 188 Apéndice A Desde el Panel de Control de Liferay se puede configurar todos los aspectos del servicio, contenidos, permisos, gestion de usuarios etc. Figura A.17: Liferay municipal: Panel de control Se puede personalizar el logo municipal desde este menú entre otras posibilidades: Figura A.18: Liferay municipal: Cambio logo municipal

215 Manual de usuario 189 Para la gestión de páginas también se dispone un menú en el que definen todos los aspectos referentes a las páginas diseño, idioma etc. Figura A.19: Liferay municipal: Configuración de páginas Desde el menú de diseño se puede elegir que plantilla utilizará una página en concreto. Figura A.20: Liferay municipal: Plantilla de página

216 190 Apéndice A A.5 Dudas frecuentes (FAQ) A.5.1. Cambio datasource datos Este paso por defecto ya está configurado, pero es preciso realizarlo si se cambia la base de datos que almacena la infraestructura (o se cambia a otra base de datos). Para configurar la base de datos de producción (PostgreSQL) o de desarrollo (Hypersonic) abrir el fichero liferay-portal-5.2.3/tomcat /webapps/root/web-inf/lib/portal-impl.jar y editar portal.properties comentando las líneas correspondientes: 1 # 2 # Hypersonic 3 # 4 #jdbc.default.driverclassname=org.hsqldb.jdbcdriver 5 #jdbc.default.url=jdbc:hsqldb:${liferay.home}/data/hsql/lportal 6 #jdbc.default.username=sa 7 #jdbc.default.password= 8 9 # 10 # PostgreSQL 11 # 12 jdbc.default.driverclassname=org.postgresql.driver 13 jdbc.default. url=jdbc:postgresql://localhost:5432/lportal 14 jdbc.default.username=postgres 15 jdbc.default.password=root Para el modo producción debe estar creada la siguiente base de datos lportal y que sea coherente con la configuración (tarea que lo realiza ya GisScripMun al instalarlo). 1 CREATE database lportal with encoding= UTF 8 template = template0 A.5.2. Instalar Liferay servicio A.5.3. Iniciar Parar y Reiniciar servicios Desde Mi PC botón secundario Administrar Servicios y aplicaciones Elegir el servicio y ejecutar la acción deseada.

217 Manual de usuario 191 A.5.4. No encuentra la tabla de municipios Si se produce un error de ERROR: relation municipios does not exist es por no disponer acceso a un schema distinto al public por defecto. Se soluciona editando el fichero de configuración postgresql.conf la línea search path, quedaría algo similar a: 1 search path = $user,public, EIEL2005 MUNICIPAL # schema names Y reiniciar el servicio para que los cambios sean activos. A.5.5. Modo desarrollo para facilitar el desarrollo y poder refrescos en tiempo de ejecución sin uso de cachés modificar el fichero del tomcat setenv.bat añadiendo al final del comando lo siguiente: 1 Dexternal properties=portal developer.properties

218 192 Apéndice A

219 APÉNDICE B PATRONES DE DISEÑO El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución [62]. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado. La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. Al tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajarán independientemente en distintos subsistemas. Los Patrones de Diseño (Design Patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Los patrones del diseño tratan los problemas 193

220 194 Apéndice B del diseño que se repiten y que se presentan en situaciones particulares del diseño, con el fin de proponer soluciones a ellas. Por lo tanto, los patrones de diseño son soluciones exitosas a problemas comunes. Existen muchas formas de implementar patrones de diseño. Los detalles de las implementaciones son llamados estrategias. Un patrón de diseño es una solución a un problema de diseño no trivial que es efectiva (ya se resolvió el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes problemas de diseño en distintas circunstancias). Durante el análisis hemos analizado el dominio del problema para construir un modelo del mundo real utilizando objetos. Hemos investigado para llegar a conseguir una descripción del problema y obtención de los requerimientos. El diseño consiste en el refinamiento de los modelos de análisis para crear especificaciones adicionales que enriquecen el modelo de análisis con detalles próximos a la implementación. Una solución lógica, de forma que se cumplan los requerimientos (asignación de responsabilidades, interacciones entre objetos, etc.) Para nuestra fase de diseño hemos empleado una serie de patrones. El patrón arquitectónico MVC(Model View Controller), y los patrones de datos: DAO (Data Access Object), VO (Value Object), Factory, Strategy y el Patrón Singleton. B.1 Patrón Model-View-Controller En el patrón Model-View-Controller (Modelo-Vista-Controlador, en adelante MVC), el flujo de la aplicación está dirigido por un Controlador central. El Controlador delega solicitudes a un manejador apropiado. Los manejadores están unidos a un Modelo, y cada manejador actúa como un adaptador entre la solicitud y el Modelo. El Modelo representa, o encapsula, un estado o lógica de negocio de la aplicación. Luego el control normalmente es devuelto a través del Controlador hacia la Vista apropiada. El reenvío puede determinarse consultando los conjuntos de mapeos,

221 Patrones de Diseño 195 normalmente cargados desde una base de datos o un fichero de configuración. Esto proporciona un acoplamiento cercano entre la Vista y el Modelo, que puede hacer las aplicaciones significativamente más fáciles de crear y de mantener. MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones: Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada. Vista (View): Muestra la información al usuario. Obtiene los datos del modelo. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador. Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ( service request en el texto original) para el modelo o la vista. El usuario interactúa con el sistema a través de los controladores. Las Vistas y los Controladores conforman la interfaz de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz y el modelo. La separación del modelo de los componentes vista y del controlador permite tener múltiples vistas del mismo modelo. Si el usuario cambia el modelo a través del controlador de una vista, todas las otras vistas dependientes deben reflejar los cambios. Por lo tanto, el modelo notifica a todas las vistas siempre que sus datos cambien. Las vistas, en cambio, recuperan los nuevos datos del modelo y actualizan la información que muestran al usuario. El MVC es un patrón ampliamente utilizado en múltiples plataformas y lenguajes. Algunos de sus principales beneficios son: Menor acoplamiento - Desacopla las vistas de los modelos. - Desacopla los modelos de la forma en que se muestran e ingresan los datos. Mayor cohesión - Cada elemento del patrón esta altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio)

222 196 Apéndice B Las vistas proveen mayor flexibilidad y agilidad - Se puede crear múltiples vistas de un modelo. - Se puede crear, añadir, modificar y eliminar nuevas vistas dinámicamente. - Las vistas pueden anidarse. - Se puede cambiar el modo en que una vista responde al usuario sin cambiar su representación visual. - Se puede sincronizar las vistas. - Las vistas pueden concentrarse en diferentes aspectos del modelo. Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales - Una vista para cada dispositivo que puede variar según sus capacidades. Más claridad de diseño Facilita el mantenimiento Mayor escalabilidad Un patrón de arquitectura puede contener varios patrones de diseño. Vamos a citar para el patrón arquitectónico Model-View-Controller qué patrones de diseño contiene contiene en nuestro caso. Figura B.1: Patrón MVC B.2 DAO (Data Access Object) El acceso a datos varía dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, como una base de datos, varía en gran medida dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc.)