3DO

3DO: 3D Observatory, un observatorio marino virtual Proyecto Fin de Carrera Sebastián Pérez Pérez Las Palmas de Gran Canaria Julio 2014 Proyecto fin de carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria presentado por el alumno: SEBASTIÁN PÉREZ PÉREZ Título del Proyecto : 3DO: 3D Observatory, un observatorio marino virtual Tutor : Javier Sánchez Pérez DEDICATORIA A mi familia AGRADECIMIENTOS Quiero dar las gracias a todas las personas que han hecho posible este proyecto. En primer lugar, a mis padres Agustín y Luisa y a mi novia Zaida, por haberme apoyado a lo largo de todo este tiempo, por haberme ayudado en todo lo que ha estado en sus manos y más, por haber estado a mi lado, tanto en los momentos buenos como en los malos, por haberme soportado cuando el estrés y el agobio hacía mella en mí y haberme oxigenado para seguir adelante cuando más lo he necesitado. También tengo que hacer mención a mi abuelo Juan, una persona que me ha acompañado durante todo mi proceso formativo desde bien pequeño siendo en gran medida el despertador y la cafeína que me ha mantenido despierto en las madrugadas de estudio. Y por supuesto al resto de mi familia. A mi tutor Javier Sánchez Pérez, la persona que ha hecho posible este proyecto. Gracias por toda la ayuda que me has brindado y por haberme ofrecido siempre total disponibilidad cuando lo he necesitado independientemente del trabajo que tuvieras. A la Plataforma Oceánica de Canarias, y en especial a Eduardo Quevedo, David Horat y Eric Delory, por el tiempo que han invertido en solucionarme las dudas que me iban surgiendo, por su implicación en el proyecto desde el primer día y por haberme dado la posibilidad de disfrutar de una beca para conocer PLOCAN desde dentro y sus actividades. Y por último, a las personas con las que he compartido esta bonita etapa, en especial a Aridane Rosario, mi compañero de batallas a lo largo de esta guerra. Índice de contenido Capítulo 1: Introducción....................................................................................................................1 1.1. La Plataforma Oceánica de Canarias........................................................................................2 1.1.1. Motivación........................................................................................................................2 1.1.2. Proceso de Formación.......................................................................................................3 1.1.3. Estructura Organizativa.....................................................................................................4 1.1.4. Estructura Física................................................................................................................5 1.1.5. Estructura Funcional.........................................................................................................5 1.2. Objetivos...................................................................................................................................7 1.3. Estructura del Documento........................................................................................................7 Capítulo 2: Estado Actual del Arte...................................................................................................9 2.1. Divulgación de Datos Oceanográficos.....................................................................................9 2.1.1. National Data Buoy Center (NDBC)..............................................................................10 2.1.2. Integrated Ocean Observing System (IOOS)..................................................................11 2.1.3. SeaDataNet CDI..............................................................................................................12 2.1.4. Observing System Monitoring Center (OSMC).............................................................13 2.1.5. Red Marino Marítima Macaronésica (R3M)...................................................................14 2.2. Sistemas de Información Geográfica (GIS)............................................................................15 2.2.1. Google Earth...................................................................................................................16 2.2.2. Here.................................................................................................................................17 2.2.3. Google Maps...................................................................................................................18 2.2.4. Bing Maps.......................................................................................................................19 2.2.5. ArcGIS............................................................................................................................20 2.2.6. OpenStreetMap...............................................................................................................21 2.2.7. OpenLayers.....................................................................................................................22 Capítulo 3: Planificación del Proyecto............................................................................................23 3.1. Metodología de Desarrollo.....................................................................................................23 3.1.1. Proceso Unificado de Desarrollo....................................................................................23 3.1.2. Fases del Proceso Unificado de Desarrollo.....................................................................24 3.1.3. Ventajas y Desventajas del Proceso Unificado de Desarrollo.........................................26 1.1.3. Estructura Organizativa La estructura organizativa de PLOCAN esta dividida en varios órganos de gobierno y de asesoramiento. Cada uno de ellos con sus diferentes funciones. El Consejo Rector es el máximo órgano de gobierno y esta compuesto por representantes del Ministerio de Economía y Competitividad y del Gobierno de Canarias. Las funciones de este órgano son las de fijar las directrices del proyecto, las reglas, el funcionamiento del Consorcio,la estrategia de gestión y por último aprobar el presupuesto y las cuentas anuales de la institución. La Comisión Ejecutiva es el órgano encargado del seguimiento y ejecución de las actividades desarrolladas por PLOCAN y por lo tanto los responsables de proponer el presupuesto anual y la línea de actuación del siguiente año. Su composición también está formada por el Ministerio y el Gobierno de Canarias. La Presidencia de ambos órganos es rotatoria entre el MEC y el Gobierno de Canarias donde una institución presidirá el Consejo Rector y la otra la Comisión Ejecutiva, ello en ciclos de dos años alternándose un órgano y otro. Por último, en el ámbito del Gobierno de PLOCAN, el siguiente nivel, ya internamente, está compuesto en primera instancia por el Director como máximo responsable, seguidamente del Gerente. Además del aparato de gobierno existen dos órganos consultivos de asesoramiento formados por expertos en la materia. Por un lado, el Comité Asesor de Actividades Socioeconómicas, encargado de asesorar sobre oportunidades y estrategias a seguir. Por otro lado, el Comité Asesor Científico y Técnico, se centra en el asesoramiento de actividades científico-tecnológicas y de aceptación de personal técnico y científico externo a la institución. 4 Consejo Rector Director Gerente Administración Técnicos Comisión Ejecutiva Comité Asesor de Actividades Socioeconómicas Comité Asesor Científico y Técnico 1.1.4. Estructura Física Como se ha comentado en los subapartados previos, la instalación principal de PLOCAN será una plataforma situada al borde de la plataforma continental y con acceso cercano a altas profundidades. Lógicamente, por los costes que una infraestructura de este tipo conlleva, es un espacio limitado y por lo tanto el número de personas que podrá hacer uso de ella al mismo tiempo es reducido. Debido a ésto surge la necesidad de unas instalaciones mas extensas en tierra firme donde el resto de personas que no puedan estar en la plataforma puedan desarrollar su trabajo. Por lo tanto, PLOCAN estará estructurada en dos espacios, una plataforma oceánica y unas instalaciones terrestres, además de las pertinentes comunicaciones necesarias para el correcto funcionamiento de sus actividades. La plataforma oceánica Es una estructura autónoma fija en medio del océano al Este de Gran Canaria donde pueden haber 40 personas trabajando a la vez. Está será la infraestructura principal que servirá como base para los vehículos y herramientas submarinas, como soporte principal para el banco de ensayos y experimentación en materia científica y tecnológica en océano profundo y de aprovechamiento de energías renovables. La plataforma debe permitir el acceso y la evacuación tanto por vía marítima como en helicóptero. Es primordial además un buen sistema de comunicación para permitir el acceso a los datos al personal de tierra. La base en tierra El edificio en tierra firme situado en Taliarte será el centro administrativo y además dispondrá de laboratorios y despachos para el trabajo del personal que no puede estar en la plataforma. Esta instalación está equipada con todo el material de oficina necesario además de taller y laboratorios para la investigación y el desarrollo. 1.1.5. Estructura Funcional Desde el punto de vista funcional, la Plataforma Oceánica de Canarias está organizada en cinco importantes módulos individuales esenciales para la institución, y que pretenden cubrir las distintas necesidades captadas en el mundo científico, académico, tecnológico y socioeconómico de la sociedad internacionalmente. A continuación se detallan cada uno de estos módulos funcionales. 5 El observatorio oceánico Se basa en un extenso sistema de dispositivos y sensores que permiten la observación y medición de magnitudes atmosféricas y oceánicas que son de vital utilidad para infinidad de aplicaciones científicas y medioambientales. En esta parte de PLOCAN es donde se centra el actual Proyecto 3DO, que tiene la misión de hacer llegar al máximo posible de personas toda esta información de la manera más sencilla y cómoda para el receptor. El banco de ensayos Ofrece una infraestructura donde sea muy fácil hacer experimentos y pruebas a altas profundidades o en condiciones de océano profundo, que de no ser por la plataforma sería muy dificultoso y caro. La base de vehículos Facilita el despliegue y recogida de vehículos submarinos. Sin la plataforma, cada vez que se quiere desplegar un dispositivo para una misión es necesario salir desde puerto en una embarcación y navegar durante millas para alcanzar las condiciones y profundidades necesarias. Y esto conlleva un coste económico además de estar sujeto a las condiciones meteorológica y estado del mar. Por lo tanto, con ello se pretende proveer de un puerto en alta mar donde realizar este tipo de actividades de forma sencilla, con las herramientas necesarias disponibles y sin limitaciones meteorológicas. El centro de formación PLOCAN tiene las herramientas, los profesionales y los dispositivos necesarios para ofrecer la mejor formación en el ámbito oceánico. Dado que está formado por profesionales altamente cualificados, que dispone de las últimas tecnologías en cuanto a observación oceanográfica se refiere y dispone de instalaciones preparadas para actividades formativas, aprovecha esta coyuntura para ejecutar programas formativos internacionales de alta especialización. El centro de innovación Haciendo uso de las posibilidades que ofrece la plataforma, su personal especialista, las herramientas y la financiación PLOCAN centra muchos esfuerzos en la innovación científica y tecnológica en el ámbito de las ciencias del mar. 6 1.2. Objetivos El objetivo fundamental del proyecto es desarrollar un portal web que funcionará como observatorio 3D multimedia para las actividades de divulgación del observatorio oceánico de La Plataforma Oceánica de Canarias (PLOCAN). Las tareas que se van a abordar para realizar dicha gestión son las siguientes: a) Visualización de vehículos, plataformas de observación y dispositivos de adquisición de datos, fijos o móviles, situadas en el medio marino, a través de un globo terráqueo virtual en el que el usuario pueda navegar. b) Gestión de los elementos del observatorio tales como la propia plataforma y dispositivos de instrumentación, tanto conjuntamente en forma de plataformas de observación como individualmente en forma de sensores. c) Gestión de los usuarios y perfiles de permisos y controlar el acceso a partes de la aplicación en base a estos permisos. d) Importación y muestra de datos oceánicos y atmosféricos recabados por las plataformas de observación usando estándares OGC. Además, como valor añadido, se pretende usar como base de desarrollo todo el software libre que sea posible, investigando y buscando alternativas al software propietario con herramientas similares bajo licencias abiertas para conseguir así una disminución del costo y por lo tanto un mayor atractivo desde el punto de vista comercial. 1.3. Estructura del Documento A lo largo del presente documento se dará una visión clara de cada una de las etapas que se han ido llevando a cabo durante el desarrollo del proyecto. Mediante gráficos, diagramas y textos explicativos se intentará plasmar detalladamente el proceso de creación del software desde las primeras fases hasta la obtención final del producto. Se recomienda al lector que siga el flujo normal del documento, ya que en la mayoría de los casos cada apartado depende del anterior, sobre todo en el capítulo 5 sobre el desarrollo del proyecto. La organización del documento es la siguiente: •Estado actual del arte. En este capítulo se hace un estudio dando a conocer las diferentes aplicaciones que guardan relación con el problema que se pretende resolver con el proyecto. Se intentará explicar sus características y qué partes del problema consigue solucionar, o por el contrario, cuáles no son resueltas. •Planificación del proyecto. Este capítulo explica la planificación que se ha llevado a cabo para el desarrollo del proyecto, así como la metodología de desarrollo que se ha usado. También incluye el plan de trabajo y el presupuesto detallado del coste total del proyecto. 7 •Herramientas y tecnologías. En el presente capítulo se explican cada una de las tecnologías o herramientas que han sido necesarias para desarrollar el proyecto. Además se enumeran tanto los recursos software como hardware participantes en la implementación del proyecto. •Desarrollo del proyecto. Este capítulo concentra toda información propia del desarrollo completo de la aplicación. Está estructurado en grandes apartados que se corresponden con las fases clásicas de un proyecto software (requisitos, análisis, diseño, implementación y pruebas). Coincide con el flujo de trabajo llevado a cabo desde la lista de características, conocimiento del dominio de la aplicación, obtención de los casos de uso e identificación de los actores del sistema, el análisis y posterior diseño, implementación y pruebas del producto final. •Conclusiones y trabajo futuro. Se detallan las conclusiones obtenidas tras la finalización del proyecto y se hace una reflexión sobre posibles ampliaciones en sucesivas versiones de la aplicación. •Anexos. Se complementa con información que puede resultar útil al lector como un manual de usuario de la aplicación. 8 Capítulo 2: Estado Actual del Arte En este segundo capítulo se pretende dar a conocer al lector una muestra representativa de distintas aplicaciones que podrían tener aspectos en común con este proyecto. Debido a que no se ha encontrado ninguna aplicación que ofrezca las mismas funcionalidades que cubre 3DO, se abordará dividiéndolo en secciones basadas en la funcionalidad que ofrecen. Por lo tanto, el presente capítulo estará organizado de la siguiente manera: 1. Se hará un muestreo de aplicaciones cuyo objetivo sea promover la divulgación científica y publicar datos científicos recabados por expediciones o proyectos en el ámbito de la oceanografía. 2. Se introducirán los sistemas de información geográfica o GIS. En esta categoría se incluyen tanto las aplicaciones de mapas planos como de globos terráqueos virtuales. Estos sistemas están basados en la georreferenciación. 2.1. Divulgación de Datos Oceanográficos En este apartado se mostrarán cinco aplicaciones web cuyo objetivo es la divulgación de datos oceanográficos obtenidos a partir de una red de plataformas de observación. Cada una de estas herramientas comparten la geolocalización de dispositivos en mapas y la obtención de datos y metadatos. Por otro lado, se diferencian en formatos y formas de presentar dichos datos al usuario final. Entre las herramientas contamos con algunas gestionadas por organizaciones norteamericanas, otra por europeas e incluso una en la que participa la Plataforma Oceánica de Canarias, organización para la cuál se esta desarrollando este proyecto. 9 2.1.1. National Data Buoy Center (NDBC) El Centro Nacional de Datos de Boyas (NDBC), parte de la Administración Nacional Oceanográfica y Atmosférica Americana (NOAA), opera y controla datos de más de 100 boyas fondeadas, 39 en océano profundo. NDBC controla y distribuye datos medioambientales a más de 570 estaciones asociadas para la preparación de alertas meteorológicas principalmente. Estas boyas hacen mediciones de las siguientes magnitudes: presión atmosférica, dirección del viento, velocidad y ráfaga, temperatura del aire y el agua, espectro de energía de las olas (no direccional y direccional), altura de la columna de agua (detección de tsunamis), humedad relativa, velocidad de corrientes marinas, precipitación, salinidad, radiación solar, visibilidad, nivel y calidad del agua, etc. Todas estas mediciones están accesibles desde una herramienta web, donde cada una de estas boyas están geolocalizadas en un mapa. Cuando un usuario selecciona alguna de estas boyas se obtiene la información y las mediciones mediante gráficas estáticas. Figura 2.1. NDBC 10 2.1.2. Integrated Ocean Observing System (IOOS) El Sistema Integrado de Observación del Océano (IOOS) conecta los datos de las miles de herramientas, desde los satélites a los sensores submarinos, que los recogen del océano y de las costas. IOOS ha ido ampliando las fuentes de datos y aumentando el acceso a los datos existentes. La información está disponible en tiempo real, así como retrospectivamente. Este catálogo de datos ofrece un fácil acceso a esta información mediante un mapa de plataformas de observación que da acceso a los datos recabados y a la descripción formal de sus sensores en formato SensorML. Figura 2.2. IOOS 11 2.1.3. SeaDataNet CDI Las infraestructuras de SeaDataNet conectan 90 centros nacionales de datos oceanográficos y centros de datos marinos de 35 países ribereños para todos los mares europeos. Los centros de datos manejan grandes conjuntos de datos marinos y oceánicos. El objetivo principal es proporcionar un sistema integrado que ofrezca una visión general y permita el acceso a estos recursos de datos utilizando un enfoque de red distribuida. Ésto se logra mediante el servicio Common Data Index (CDI) que permite recuperar datos (temperatura, oxígeno, salinidad, nutrientes , ...) a partir de toda su red de plataformas de observación. La interfaz de consulta CDI permite realizar búsquedas por un conjunto de criterios. Entonces se muestra los resultados y se ubican en un mapa. Al hacer clic en el icono de la pantalla recupera los metadatos del conjunto de datos dando la información sobre el qué, dónde, cuándo, cómo y quién del conjunto de datos. La interfaz cuenta con un mecanismo de compras. Todos los usuarios pueden consultar libremente y navegar en el CDI; Sin embargo la presentación de las solicitudes de acceso a datos a través de la cesta de la compra requiere que los usuarios se registren en SeaDataNet. Figura 2.3. SeaDataNet CDI 12 2.1.4. Observing System Monitoring Center (OSMC) La OSMC reúne las plataformas de observación oceanográfica (barcos, boyas, mareógrafos, etc) en un único sistema integrado. Esta herramienta proporciona monitoreo en tiempo real de los activos del sistema de observación integrados, que hace que los datos estén accesibles de forma fácil de usar y a la vez los unifica. Los datos son servidos utilizando una serie de webservices como OPENDAP y SOS y formatos de archivo descargable, por lo que se puede acceder en los navegadores web y herramientas de análisis de escritorio. Figura 2.4. OSMC 13 2.2.5. ArcGIS ArcGIS es el nombre de un conjunto de productos de software en el campo de los Sistemas de Información Geográfica producido y comercializado por ESRI. Se agrupan varias aplicaciones para la captura, edición, análisis, tratamiento, diseño, publicación e impresión de información geográfica. Como sistema de información, ArcGIS es accesible desde clientes de escritorio, navegadores web, y terminales móviles que se conectan a servidores de departamento, corporativos o con arquitecturas de Cloud Computing. Para los desarrolladores, ArcGIS proporciona herramientas que les permitirán crear sus propias aplicaciones. Figura 2.10. ArcGIS 20 2.2.6. OpenStreetMap OpenStreetMap, también conocido como OSM, es un proyecto colaborativo para crear mapas libres y editables. Los mapas se crean utilizando información geográfica capturada con dispositivos GPS móviles, ortofotografías y otras fuentes libres. Esta cartografía, tanto las imágenes creadas como los datos vectoriales almacenados en su base de datos, se distribuye bajo licencia abierta Open Database License. Los usuarios registrados pueden subir sus trazas desde el GPS y crear y corregir datos vectoriales mediante herramientas de edición creadas por la comunidad. OpenStreetMap facilita los datos en bruto para su descarga desde su propia página web. Éstos pueden ser modificados para cada proyecto así como presentados con estilos de renderizado personalizados. A partir de los datos del proyecto OpenStreetMap no sólo se pueden producir mapas de carreteras, sino también para la creación de mapas de senderismo, mapas de rutas ciclistas, mapas náuticos, mapas de estaciones de esquí, etc. También se usan en aplicaciones para el cálculo de las rutas óptimas para vehículos y peatones. Gracias a su licencia abierta los datos brutos son de libre acceso para el desarrollo de otras aplicaciones. Figura 2.11. OpenStreetMap 21 2.2.7. OpenLayers OpenLayers es una biblioteca de JavaScript de código abierto bajo una derivación de la licencia BSD para mostrar mapas interactivos en los navegadores web. OpenLayers ofrece un API para acceder a diferentes fuentes de información cartográfica en la red: Web Map Services, Mapas comerciales, Web Features Services, distintos formatos vectoriales, mapas de OpenStreetMap, etc. Inicialmente fue desarrollado por MetaCarta en junio del 2006. Desde noviembre del 2007 este proyecto forma parte de los proyectos de Open Source Geospatial Foundation. Actualmente el desarrollo y el soporte corre a cargo de la comunidad de colaboradores. Figura 2.12. OpenLayers Existe otra herramienta llamada ReadyMap, que es un nuevo conjunto de herramientas de código abierto en JavaScript para la presentación de mapas 3D basada OpenLayers. ReadyMap utiliza WebGL y el elemento Canvas de HTML5. 22 Capítulo 3: Planificación del Proyecto En este capítulo se explica la planificación del proyecto. En él se detalla la metodología de desarrollo que se ha usado y porqué, el plan de trabajo llevado a cabo y su temporización y por último un presupuesto detallado del coste del proyecto. 3.1. Metodología de Desarrollo Respecto a la metodología a utilizar se utilizarán las técnicas de desarrollo software propias del Proceso Unificado de Desarrollo (PUD). 3.1.1. Proceso Unificado de Desarrollo El Proceso Unificado de Desarrollo dota de un marco de trabajo genérico que puede especificarse para una gran abanico de sistemas software con diferentes áreas de aplicación, para distintas configuraciones de organización y para cualquier tamaño de proyecto. El Proceso Unificado de Desarrollo utiliza el Lenguaje Unificado de Modelado (UML) como parte esencial para el modelado del producto software en cada una de sus etapas. El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en producción. En caso de que fuese necesario publicar otra versión, deberían repetirse los mismos pasos a lo largo de otro ciclo. El mantra del Proceso Unificado de Desarrollo se basa en cuatro ideas claves: 23 •Iterativo e incremental. Está compuesto por cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases están compuestas por una serie de iteraciones que resulta en un incremento del producto al que va añadiendo funcionalidades en cada una de las iteraciones. Cada una de estas iteraciones pasa por cada etapa del ciclo de vida clásico del software (requisitos, análisis, diseño, implementación y pruebas) con lo que al final de cada iteración se tiene un producto usable y testado que será ampliado en iteraciones posteriores. •Dirigido por casos de uso. Los casos de uso son una representación de los requisitos funcionales del software. El conjunto de todos ellos constituyen el modelo de casos de uso con el que se define la funcionalidad completa del sistema. Con ello se consigue definir lo que debe hacer el sistema y lo que un usuario puede hacer con él. Esta herramienta guía el proceso de desarrollo donde en cada iteración se toman un numero de casos de usos limitados y se van transformando en especificaciones de análisis y posteriormente de diseño para finalmente convertirse en código fuente dando lugar a una aplicación con tantas funcionalidades como casos de uso se hayan implementado hasta el momento. •Centrado en la arquitectura. La arquitectura de un software comprenden un conjunto de diferentes vistas del sistema en construcción. Esta surge del problema que se pretende solucionar, de la plataforma donde debe funcionar el software, de los recursos reutilizables desarrollados anteriormente, de los sistemas heredados y de los requisitos no funcionales. Todo esto sirve de ayuda al arquitecto para fijar los objetivos como la capacidad de adaptación al cambio y la reutilización. La arquitectura y los casos de uso deben evolucionar en paralelo habiendo interacción entre ambos para que los casos de uso encajen en la arquitectura y sea posible la implementación de todos y cada uno de ellos. •Enfocado en los riesgos. Se requiere que se identifiquen los riegos críticos del proyecto lo antes posible, durante las primeras etapas del ciclo de vida, para que en caso de que alguno comprometa el éxito del proyecto lo haga cuando la inversión sea mínima. 3.1.2. Fases del Proceso Unificado de Desarrollo Como se ha comentado en el apartado anterior, cada ciclo se compone de varias fases, y dentro de cada una de ellas, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones, con sus incrementos resultantes. Cada fase termina con un hito, determinado por la disponibilidad de un conjunto de artefactos, modelos o documentos. Las iteraciones de cada fase se desarrollan a través de las actividades de identificación de requisitos, análisis, diseño, implementación, pruebas e integración. 24 Fase de Inicio Suele ser la fase más corta del desarrollo. En esta fase se realizan las siguientes tareas: •Desarrollar una descripción del producto final y presentar el análisis de negocio. •Realizar una identificación inicial de riesgos. •Establecer las principales funciones del sistema para los usuarios más importantes, la arquitectura a grandes rasgos y un plan de proyecto. La fase de inicio termina con el hito de los objetivos del desarrollo. Fase de Elaboración Durante esta fase deberían capturarse la mayoría de requisitos del sistema, aunque los objetivos principales son tratar los riesgos ya identificados y establecer y validar la base de la arquitectura del sistema. Esta base se llevará a cabo a través de varias iteraciones, y servirá de punto de partida para la fase de construcción. La fase de elaboración termina, por tanto, al alcanzar el hito de la arquitectura del sistema. Fase de Construcción Es la fase más larga del proyecto, y completa la implementación del sistema tomando como base la arquitectura obtenida durante la fase de elaboración. A partir de ella, las distintas funcionalidades son incluidas en distintas iteraciones, al final de cada una de las cuales se obtendrá una nueva versión ejecutable del producto. Por tanto, esta fase concluye con el hito de obtención de una funcionalidad completa, que capacite al producto para funcionar en un entorno de producción. Fase de Transición En la fase final del proyecto se lleva a cabo el despliegue del producto en el entorno de los usuarios, lo que incluye la formación de éstos. Durante esta fase se evoluciona desde la fase beta a una versión final, se resuelven incidencias en la implantación e integración, y si existen, se clasifican aquéllas que podrían justificar una nueva versión del producto. Esta fase concluye con el hito de publicación del producto. 25 Figura 3.1. Fases del Proceso Unificado de Desarrollo. 3.1.3. Ventajas y Desventajas del Proceso Unificado de Desarrollo Ventajas •Se obtiene productos funcionales y testados en tiempos razonables. •Se identifican los riesgos críticos pronto, evitando fracasos en fases tardías del proyecto. •Es muy tolerante a cambios. •Fácil adición de funcionalidades posteriores. •Alta reutilización de componentes Desventajas •La evaluación de riesgos es compleja. •El cliente debe ser capaz de describir a un gran nivel de detalle. •Excesiva flexibilidad para algunos proyectos 26 3.2. Planificación Temporal A continuación se explicará el plan de trabajo llevado a cabo durante el proyecto así como el desglose de las tareas realizadas en cada fase e iteración con el número de horas estimadas que se debían invertir en ellas. 3.2.1. Plan de Trabajo Tal y como se define en el Proceso Unificado de Desarrollo, y explicado en el apartado anterior, el desarrollo del proyecto se dividirá en 4 fases. Cada una estas fases, a su vez se dividen en iteraciones de aproximadamente el mismo tiempo (alrededor de 100 horas/iteración). Al final de cada una de estas iteraciones se planifica una reunión en la que participamos por parte de PLOCAN: el responsable de proyectos, Eduardo Quevedo, el responsable del Departamento de Informática y Telecomunicaciones, David Horat y el responsable del Observatorio, Eric Delory; y por parte de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria: el profesor y tutor del proyecto, Javier Sánchez y yo. En cada una de estas reuniones se tratan y validan los hitos de la iteración que se acaba de finalizar y se establecen los siguientes para la próxima iteración. La fase inicial está compuesta por dos iteraciones en las que en una primera se estudian las herramientas a utilizar en el proyecto. Y una segunda en la que se hace la mayor parte de recabado de información a través de entrevistas y cuestionarios, se define y negocia la lista de características y se redactan los documentos que establecerán las bases del proyecto. La fase de elaboración se centrará en el análisis y el diseño de cada uno de los tres módulos por lo que está compuesta la aplicación. Se invertirá una iteración por cada módulo. La fase de construcción también estará compuesta por tres iteraciones en donde se llevarán a cabo la implementación y prueba de cada uno de los tres módulos. Al final de esta fase se obtiene una versión beta de la aplicación. Finalmente la fase de transición consta de una única iteración en donde se montará un entorno de pruebas y sobre el cuál se realizarán todas las pruebas beta por parte de la organización. En el siguiente subapartado se detalla cada una de las actividades por iteración y fase. 27 3.2.2. Temporización Fases/Actividades Horas Fase Inicial Iteración 1: Puesta en marcha del PFC •Valoración de las herramientas IVS-3D, Google Sketch-Up y Google Earth 20 •Estudio de KML y la API de Google Earth 40 •Estudio Python y Django 40 Iteración 2: •Redacción de cuestionario de entrevista 4 •Redacción del informe sobre el estado de ejecución del PFC 4 •Redacción del documento de descripción de los entregables del PFC 4 •Redacción del documento de requisitos y criterios de éxito del PFC 4 •Redacción del plan de gestión de calidad del PFC 4 •Redacción del plan de gestión de riesgos 4 •Redacción del plan de gestión de rr.hh. y comunicaciones 4 •Redacción del presupuesto 4 •Generar la lista de características inicial 8 •Generar el modelo de dominio inicial 8 •Generar el modelo de casos de uso inicial 16 •Desarrollo de un prototipo inicial 36 Fase de Elaboración Iteración 3: Módulo Cliente •Refinado del modelo de dominio 4 •Refinado de lista de características 4 28 •Refinado de casos de uso del Módulo Cliente 4 •Prototipo Cliente 8 •Diagramas de paquetes del modelo de análisis 15 •Diagrama de clases del Módulo Cliente - Análisis 15 •Diseño de la BD del Módulo Cliente 15 •Diagrama de despliegue 15 •Documentación 20 Iteración 4: Módulo Dispositivos •Refinado del modelo de dominio 4 •Refinado de lista de características 4 •Refinado de casos de uso del Módulo Dispositivos 4 •Prototipo Dispositivos 8 •Diagrama de Clases del Módulo Dispositivos - Análisis 20 •Diseño de la BD del Módulo Dispositivos 20 •Diagrama de paquetes del modelo de diseño 20 •Documentación 20 Iteración 5: Módulo Usuarios •Refinado del modelo de dominio 4 •Refinado de lista de características 4 •Refinado de casos de uso del Módulo Usuarios 4 •Prototipo Usuarios 8 •Diagrama de Clases del Módulo Usuarios - Análisis 20 •Diseño de la BD del Módulo Usuarios 20 •Diagrama de diseño arquitectónico 20 •Documentación 20 29 4.1.2. Frameworks de Desarrollo Django es un framework web de código abierto escrito en Python que permite el desarrollo rápido y el diseño limpio y pragmático. Se basa en el paradigma MVC (Model View Controller), aunque con alguna pequeña particularidad adoptando el nombre de MTV (Model Template View) pero que a fin de cuentas se basa en el mismo principio. Django pone énfasis en la reusabilidad, conectividad y extensibilidad de componentes, el desarrollo rápido y el principio “No te repitas” (DRY, del inglés Don't Repeat Yourself) jQuery es un framework de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con AJAX a páginas web. Sus principales características son: Selección de elementos DOM, interactividad y modificaciones del árbol DOM, soporte a eventos, manipulación de la hoja de estilos CSS, efectos y animaciones, animaciones personalizadas, soporte AJAX y existe un gran número de extensiones basadas en él. 4.1.3. Lenguajes de Visualización y Maquetado HTML, siglas de HyperText Markup Language («lenguaje de marcado de hipertexto»), es el lenguaje con el que se escribe la estructura y la semántica del contenido de un documento Web. Permite describir la estructura y el contenido en forma de texto, además de complementar el texto con objetos tales como imágenes. CSS es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML. La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un documento de su presentación. 4.1.4. Sistema de Gestión de Bases de Datos MySQL es un sistema de gestión de bases de datos relacional, multihilo y multiusuario. MySQL ofrece un amplio subconjunto de SQL, transacciones y claves foráneas, conectividad segura, replicación y búsqueda e indexación de campos de texto. 36 4.1.5. Formatos Estándar de Datos El formato NetCDF (Network Common Data Format) fue creado por UNIDATA como formato estándar para que sea usado en algunos de sus softwares que ofrece a la comunidad científica. La característica de este formato es que contiene la suficiente información para poder saber qué clase de data se encuentra en el archivo (tipo de variable, unidades, dimensiones, institución que la creo, etc) a diferencia de otros formatos que necesitan de un archivo adicional para su correcta interpretación. SensorML especifica los modelos y la codificación XML que proporcionan un marco dentro del cual pueden ser definidas las características geométricas y dinámicas, y observación de los sensores y sistemas de sensores. KML es un lenguaje XML centrado en la visualización geográfica, incluyendo la anotación de mapas e imágenes. La visualización geográfica incluye no sólo la presentación de los datos gráficos en el mundo, sino también el control de la navegación del usuario. 4.1.6. Sistema de Información Geográfica El plugin de Google Earth es un complemento para navegadores web similar a un Sistema de Información Geográfica (SIG). Permite visualizar imágenes en 3D del planeta, combinando imágenes de satélite, mapas y el motor de búsqueda de Google que permite ver imágenes a escala de un lugar específico del planeta sobre un globo terráqueo en 3D desde un navegador web. 4.1.7. Gráficas Google Chart es una herramienta por la cual se nos permite crear, vía petición http a la API, unas gráficas que podemos insertar en un documento web. Para ello se debe generar una URL pasando una serie de parámetros en la misma y que como respuesta se obtiene una gráfica. Estas gráficas pueden ser de diferentes tipos y además se le puede añadir control, dinamismo y un amplio conjunto de configuraciones. 37 4.2. Herramientas En los siguientes subapartados se enumeran las herramientas que han sido necesarias para la realización del proyecto, tanto hardware como software. 4.2.1. Hardware Como equipo de trabajo para llevar a cabo el proyecto se ha utilizado un ordenador portátil y para una mayor comodidad se le ha añadido un segundo monitor, teclado y ratón externos. La características de cada uno ellos son las siguientes: •Ordenador portátil Dell Vostro 3500 - Procesador: Intel Core i5 M460 2,53GHz - Memoria RAM: 4 GB DDR3 - Gráficos: NVIDIA GeForce 310M - Disco Duro: Toshiba SATA 320GB •Monitor Acer X243HQ de 24'' •Teclado y ratón Logitech 4.2.2. Software Con un soporte físico como el citado en el subapartado anterior, pero sin un software que lo complemente no se podría haber hecho nada relativo al proyecto que nos atañe. Se ha usado software muy variado y de diferentes índoles. A continuación se enumeran: •Sistema Operativo: Windows 7 Professional y Ubuntu 12.10 •Editor de Código: Sublime Text 2 •Procesador de Texto: Libre Office •Editor de Imágenes: Gimp •Modelado UML: StartUML •Control de Versiones: SVN y TortoiseSVN •Editor Modelos 3D : Google SketchUp •Administración BD: MySQL Workbench 38 Capítulo 5: Desarrollo del Proyecto En el desarrollo de software, la primera decisión que se ha de tomar es la metodología de desarrollo que se va a utilizar para llevar a cabo un proyecto. Esta metodología será la que marcará los pasos a seguir durante la construcción del proyecto. El presente capítulo documenta todo el proceso de creación del software desde la captura de los requisitos hasta las pruebas finales de la aplicación. El capítulo está organizado por apartados donde cada apartado coincide con cada uno de los pasos marcados por la metodología elegida (requisitos del sistema, requisitos del software, análisis, diseño, implementación y pruebas). Cada uno de los apartados estará documentado a través de diagramas, imágenes y textos explicativos. 5.1. Requisitos del Sistemas La primera etapa de un proyecto es ser capaz de entender las necesidades y problemas que se pretenden resolver con la aplicación. Para ello es necesario conocer también el dominio en el que será aplicada. Esto es lo que se obtiene con los requisitos del sistema. Esta información queda representada por una lista de características y modelo del dominio. La lista de características enumeran los requisitos candidatos. La misión principal de los requisitos es guiar el desarrollo hacia un sistema correcto en el que se hayan ya identificado y priorizado las funcionalidades deseadas y se hayan detectado los riesgos de manera que no comprometa el proyecto en fases posteriores. Por otro lado, el modelo de dominio ayuda a comprender el contexto del sistema. Describe los conceptos importantes del contexto como los objetos del dominio y las interrelaciones existentes entre ellos. 39 5.1.1. Lista de características A continuación se detalla una lista de características donde se definirán las distintas operaciones que debe permitir la aplicación. En ella se definen tanto las que se van a implementar en esta versión del software como las que se pueden implementar en versiones posteriores. La tabla de característica ha sido subdividida en los siguientes campos: •Código. Es el identificador de la característica. Se especifica como: LC-[Grupo]-[Número], donde LC hace referencia a lista de características. •Nombre de la característica. •Descripción. Pequeña explicación de la característica. •Prioridad. Se asigna una prioridad para resaltar las características más importantes para determinar que características se implementarán primero. Las prioridades que se van a utilizar son: alta, media, baja. •Estado. Cada característica tiene un estado asociado. Los posibles estados son: - Aceptado. La característica se desarrollará en esta versión del producto. - Propuesto. La característica está planteada pero se planificará para una futura versión del producto. •Riesgo. Cada característica puede tener asociado un riesgo que representa la dificultad para conseguir implementarla correctamente. Utilizamos tres niveles de riesgo: crítico, significativo, rutinario . •Coste. Representa al coste que conllevaría realizar dicha característica. Los costes que se utilizarán son: alto, medio, bajo. Para que la lista de características quede mejor estructurada y así facilitar su lectura y comprensión se clasifican las operaciones que se requieren en el sistema en cinco grandes grupos: •Cliente (A). En esta categoría irán agrupadas todas las operaciones pertenecientes al cliente de la aplicación. •Gestión de usuarios (B). Las funciones contenidas en esta categoría son todas las correspondientes a la gestión de usuarios. •Gestión de dispositivos (C). Categoría donde se incluyen todas las funciones de administración de dispositivos científicos. Las operaciones son las de creación, edición, asignación de modelos, altas y bajas, etc. •Obtención de datos (D). Son las operaciones relacionadas con la obtención y extracción de datos científicos recabados por los distintos dispositivos de toma de datos. En ella se incluyen todas las conexiones mediante los distintos protocolos con las fuentes de datos. •Animación gráfica (E). Operaciones orientadas a las funciones lúdicas de la aplicación como creación de entornos multimedia de conocimiento del medio. 40 5.1.1.1. Cliente LC-A-1 Ver mapa 3D Descripción Parte pública de la aplicación donde se mostrará un mapa 3D tipo Google Earth en un entorno web Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio LC-A-2 Mover en mapa 3D Descripción Desplazarse en el mapa 3D de forma que se pueda girar el globo terrestre virtual hacia la izquierda, hacia la derecha, hacia arriba y hacia abajo. Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-A-3 Hacer zoom en mapa 3D Descripción Acercarse o alejarse a una posición el mapa 3D Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-A-4 Ver mundo submarino en mapa 3D Descripción Poder mostrar no sólo la superficie terrestre sino además poder mostrar el fondo marino y los elementos que se encuentren bajo el nivel del mar Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio 41 LC-A-5 Ver dispositivos activos Descripción Presentar un menú tipo lista jerárquica donde se muestren todo los dispositivos que se encuentren activos en el momento y por lo tanto se puedan localizar en el mapa 3D Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio LC-A-6 Ver dispositivos en mapa 3D Descripción Visualización del dispositivo en su posición actual en el mapa 3D Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio LC-A-7 Localizar en mapa 3D el dispositivo seleccionado en la lista Descripción Al seleccionar un dispositivo de la lista de dispositivos que el mapa 3D se sitúe en una vista donde se vea claramente el dispositivo colocado en su ubicación actual. Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio LC-A-8 Ver información del dispositivo Descripción Al seleccionar el dispositivo se mostrará la información asociada a este dispositivo en forma de burbuja o similar. Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo 42 LC-A-9 Ver lectura de datos del dispositivo Descripción Parte de la información mostrada del dispositivo en la burbuja son los datos capturados por éste mediante tablas de datos o gráficas asociadas a éstas. Estado Aprobado Prioridad Media Riesgo Significativo Coste Alto LC-A-10 Ver vídeo tomado por el dispositivo Descripción En la información mostrada en la burbuja se mostrará vídeos capturados por el dispositivo Estado Propuesto Prioridad Baja Riesgo Ordinario Coste Alto LC-A-11 Insertar imágenes reales captadas por dispositivos en el fondo marino del mapa 3D Descripción Superponer imágenes reales captadas por el dispositivo al fondo marino virtual Estado Propuesto Prioridad Baja Riesgo Crítico Coste Alto 5.1.1.2. Usuarios LC-B-1 Crear usuario Descripción Zona privada de la aplicación donde el administrador crea un nuevo usuario y le añade la información asociada a éste Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo 43 LC-B-2 Editar usuario Descripción Zona privada de la aplicación donde el administrador modifica parte de la información de un usuario Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-B-3 Eliminar usuario Descripción Zona privada de la aplicación donde el administrador elimina un usuario del sistema Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-B-4 Asignar permisos Descripción Zona privada de la aplicación donde el administrador le asigna los permisos de uso a un usuario Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-B-5 Cambiar contraseña Descripción Zona privada de la aplicación donde un usuario modifica su antigua contraseña por una nueva Estado Aprobado Prioridad Media Riesgo Ordinario Coste Bajo 44 LC-B-6 Recordar contraseña Descripción Zona pública de la aplicación donde un usuario solicita que se le reenvíe su contraseña al correo electrónico asociado a su cuenta de usuario. Estado Aprobado Prioridad Media Riesgo Ordinario Coste Bajo LC-B-7 Login Descripción Zona pública de la aplicación donde un usuario registrado introduce sus credenciales de acceso para poder acceder a la parte privada para la que tiene permisos mediante una sesión de usuario Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-B-8 Logout Descripción Zona privada de la aplicación donde el usuario solicita el cierre de su sesión de usuario Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Bajo LC-B-9 Controlar acceso a usuarios anónimos Descripción Zona privada de la aplicación donde el administrador hace que la parte pública de la aplicación sea o deje de ser visible para usuarios no registrados Estado Aprobado Prioridad Alta Riesgo Ordinario Coste Medio 45 LC-D-10 Visualización de eventos Descripción Muestra de una alarma informando que las condiciones de un evento se están cumpliendo en ese momento Estado Propuesto Prioridad Baja Riesgo Significativo Coste Alto 5.1.1.5. Animación Gráfica LC-E-1 Integración de contenidos lúdicos basados en Infinity 3D Descripción Enlazar aplicación con contenidos lúdicos basados en Infinity 3D Estado Propuesto Prioridad Bajo Riesgo Crítico Coste Alto LC-E-2 Muestra de mundo virtual mediante Unity 3D Descripción Enlazar aplicación con mundo virtual usando Unity 3D Estado Propuesto Prioridad Bajo Riesgo Crítico Coste Alto 52 5.1.2. Modelo del dominio Mediante el modelo del dominio se pretende modelar el contexto en el que se va a introducir el sistema. En él se describe mediante diagramas de clases el funcionamiento actual de las actividades de PLOCAN a las que se quiere dar apoyo tecnológico con el sistema a desarrollar. 5.1.2.1. Instrumentación Oceanográfica y Atmosférica PLOCAN cuenta con una serie de dispositivos de diferentes tipos, los cuales son capaces de capturar datos de tipo oceanográficos y atmosféricos tanto del mundo submarino como de la superficie marina. Estos dispositivos, dependiendo del tipo, pueden estar equipados con varios tipos de sensores y cámaras, tanto fotográficas como de vídeo. Todos estos datos, incluyendo imágenes, son almacenadas en bases de datos administradas por el administrador. Estos datos son de especial interés para personal científico tanto de PLOCAN como del resto del mundo. Los datos pueden ser mostrados en tablas o incluso en gráficas navegables en el tiempo. La forma de acceso a estos datos por parte de los científicos son vía dos protocolos: •OPENDAP-NetCDF •OGC-SOS-O&M Figura 5.1. Instrumentación Oceanográfica 53 Dispositivo Sensor Tipo_Dispositivo Tipo Sensor Tabla de datos Dato Oceanográfico Científico Gráfica de datos Base de datos OPENDAP-NetCDF OGC-SOS-O&M Cámara Vídeo Fotografía Administrador de Sistemas 1 * * Captura * 1 Estudia * * Utiliza * * Visualiza ** Captura * 1 Graba * 1 Mantiene * * 5.1.2.2. Tipos de dispositivos Actualmente PLOCAN trabaja con varios tipos de dispositivos de captura de datos. Los gliders son vehículos submarinos autónomos no tripulados desarrollados para llevar a cabo mediciones de parámetros físico-químicos de la columna de agua tanto en zonas costeras como oceánicas hasta profundidades de 1000 m. Tanto los vehículos submarinos ROVs (remote operated vehicle) como los gliders son dirigidos por un operador desde tierra mediante control remoto. Aparte cuentan con dos tipos de boyas: las boyas de deriva, que son boyas libres que se mueven a través del impulso del viento, las olas y las corrientes marinas y van tomando medidas por cualquier punto por el que van pasando; y las boyas ancladas, que como su propio nombre indica se encuentran ancladas al fondo marino de forma de que toma medidas en un mismo punto del océano de forma continua y a diferentes profundidades gracias a los sensores instalados en el anclaje de la boya. Y por último cuentan, aunque no es un dispositivo como tal, con las tortugas marinas. A las tortugas se les equipa con unos transmisores de forma de que se pueden estudiar sus movimientos migratorios y su relación con los parámetros ambientales marinos. Figura 5.2. Plataformas de observación 54 Glider ROV Boya Tortuga marina Operador Boya de deriva Boya anclada Tipo de Dispositivo Dirige 1 1..* Dirige 1 1..* 5.1.2.3. Equipamiento de dispositivos Como se ha explicado anteriormente, los dispositivos pueden ser de diferentes tipos, y dependiendo de sus funciones pueden estar equipados con distintas herramientas. En el siguiente gráfico se muestra la posible instrumentación de un dispositivo. Figura 5.3. Equipamiento de dispositivos 5.2. Requisitos del Software La especificación de requisitos del software es una descripción intensiva del comportamiento del sistema. A partir de la lista de características del apartado anterior, se obtiene una representación en forma de casos de uso. El modelo de casos de uso define la interacción entre los distintos usuarios, o actores a partir de ahora, y el sistema. Los casos de uso son pequeñas unidades de la funcionalidad completa del sistema. Con los casos de uso se representarán los requisitos funcionales del sistema. Cada caso de uso es definido en detalle con la especificación del caso de uso. Esta especificación es una secuencia precisa de acciones necesarias para realizar un caso de uso. Por lo tanto, a lo largo de este apartado se habrá que definir los actores del sistema, el modelo de casos de uso para cada paquete o módulo del sistema y la especificación de cada uno de ellos. 55 Dispositivo Cámara * Sensor Metereológico Sensor Oceanográfico Radio Frecuencia Transmisor ARGOS GPS **0..1 0..1 0..1 5.2.1. Actores del Sistema El siguiente diagrama muestra la jerarquía de usuarios o actores que interactuarán con el sistema. Existe un usuario genérico del cual heredan todos los usuarios representando la funcionalidad común a todos ellos. Figura 5.4. Actores del sistema •Usuario anónimo. Será el usuario no registrado en el sistema. Este usuario tendrá acceso únicamente a la parte del cliente, y siempre que el administrador no cierre el acceso para este tipo de usuario. •Usuario registrado. Son los usuarios que están registrados en el sistema y que inician su sesión para hacer uso de la aplicación. Estos usuarios tienen acceso a la misma parte de la aplicación que el usuario anónimo, con la diferencia de que el usuario registrado sí puede acceder al cliente cuando el administrador declara privada a la aplicación. •Editor. Este tipo de usuario es el encargado de administrar la información científica de la aplicación. Tiene acceso a la interfaz de administración donde se mantienen dispositivos, modelos y cualquier otro artefacto científico integrado en la aplicación. Además hereda la funcionalidad disponible para el usuario registrado. •Administrador. El perfil del súper usuario. Es el usuario que tiene acceso total a todas las partes de la aplicación. Tiene acceso al sistema de administración donde puede acceder a todas las secciones de administración. Además de las funciones del editor, también es el encargado de la gestión de usuarios y de sus permisos, y de limitar el acceso a la aplicación haciéndola privada en los momentos puntuales que se deseen. 56 Usuario Genérico Usuario Anónimo Usuario Registrado Editor Administrador 5.2.2. Modelo de Casos de Uso Los casos de uso han sido clasificados en subsistemas lógicos de forma que los casos de uso quedan organizados por la naturaleza de su funcionalidad. Se han divido en tres paquetes siguiendo la lógica llevada a cabo al organizar la lista de características. Un primer subsistema lógico es el del “Cliente” donde se agrupan todos los casos de uso correspondientes al funcionamiento del cliente de la aplicación. Este paquete tiene dependencia con el resto de paquetes ya que hace uso de todos los demás para su correcto funcionamiento. El paquete “Usuarios” engloba los casos de uso relacionados con las cuentas de usuarios. En él se describen las tareas de administración sobre las cuentas de usuario y la creación y cierres de sesiones de usuarios. El paquete “Dispositivos” agrupa las funcionalidades sobre dispositivos, tipos de dispositivos y modelos. Con él se satisfacen las necesidades sobre la administración de dichos artefactos. Figura 5.5. Paquetes de casos de uso. A continuación se definen los casos de uso que se van a implementar. Los casos de uso estarán divididos en las categorías que se han definido anteriormente. En cada categoría se mostrarán los casos de uso mediante diagramas de casos de uso y posteriormente se especificará cada caso de uso mediante una tabla descriptiva. 57 Cliente <<useCasePackage>> Usuarios <<useCasePackage>> Dispositivos <<useCasePackage>> 5.2.2.1. Cliente Este subsistema lógico engloba los casos de uso del cliente de la aplicación. Todos los usuarios del sistema tienen acceso a esta sección del software. El cliente representa la zona, a priori, “pública” de la aplicación. En ella estará contenido el mapa 3D, los menús, y la visualización de todos los dispositivos y los datos capturados por sus sensores. Figura 5.6. Casos de uso cliente. 58 Cliente <<useCasePackage>> Usuario Genérico Ver mapa 3D Mover mapa 3D Hacer zoom en mapa 3D Ver mundo submarino en mapa 3D Ver dispositivos en menú Ver dispositivos en mapa 3D Ver información del dispositivo Ver lectura de datos del dispositivo - NetCDF <<extend>> <<extend>> <<extend>> <<include>> <<include>> Ver descripcion de sensores - SensorML <<extend>> 5.2.2.2. Usuarios El subsistema lógico Usuarios engloba los casos de uso relacionados con la gestión de usuarios. El usuario con perfil de administrador tendrá las tareas de crear, modificar y eliminar usuarios, además de asignarle los permisos a éstos. También el administrador tendrá la posibilidad de cerrar el acceso a la aplicación a los usuarios anónimos, con lo que cuando esta opción esté activada, sólo los usuarios registrados podrán hacer uso del cliente de la aplicación. En este subsistema también se incluyen el uso de estas cuentas de usuarios dando la posibilidad a los usuarios registrados de iniciar una sesión de usuario, finalizarla y cambiar su contraseña. Figura 5.7. Casos de uso usuario 59 Usuarios <<useCasePackage>> Administrador Usuario Registrado Crear usuario Editar usuario Eliminar usuario Asignar permisos Control acceso a usuarios anónimos Iniciar sesión Cerrar sesión Cambiar contraseña <<include>> <<include>> 5.2.2.3. Dispositivos El subsistema lógico “Dispositivos” engloba todos los casos de uso relacionado con la gestión y administración de los dispositivos y todos los demás artefactos asociados a éstos. El actor que está directamente relacionado con este subsistema la figura del editor. El editor es el encargado de crear un dispositivo, editarlo, eliminarlo, añadirle sensores, asignarle modelo 3D, asignarle un tipo y darle de alta o de baja en la aplicación. Figura 5.8. Casos de uso dispositivos. 60 Dispositivos <<useCasePackage>> Editor Crear tipo de dispositivo Editar tipo de dispositivo Eliminar tipo de dispositivo Introducir modelo Editar Modelo Eliminar modelo Crear dispositivo Editar dispositivo Eliminar dispositivo Dar de alta a dispositivo Dar de baja a dispositivo Asignar tipo a dispositivo Asignar modelo a dispositivo <<include>> <<include>> <<include>> <<include>> 5.2.3. Especificación de Casos de Uso Con los diagramas de casos de uso se puede obtener una idea global de las operaciones que cada usuario puede realizar pero no nos da una información completa de en qué condiciones se pueden ejecutar o el flujo de acciones que se tienen que llevar a cabo. Para solventar ésto, se hace uso de las tablas de especificación de casos de uso donde se recoge la siguiente información: •Código. Es el identificador del caso de uso. Se especifica como: CU-[Grupo]-[Número], donde CU hace referencia a caso de uso. •Nombre del caso de uso. •Descripción. Pequeña explicación del caso de uso. •Subsistema. Subsistema al que pertenece. •Actor principal. Tipo de usuario que ejecuta la acción. Es uno de los actores del sistema. •Precondiciones. Condiciones que deben cumplirse para poder iniciar la realización. •Flujo de ejecución. Flujo de acciones que deben ejecutarse durante la realización. •Camino alternativo. Flujo de acciones que se llevan a cabo si no se cumple la precondición. •Postcondiciones. Condiciones cumplidas tras finalizar la realización. 5.2.3.1. Cliente CU-A-1 Ver mapa 3D Descripción Acción mediante la cual cualquier usuario obtiene el mapa 3D de la tierra en la vista por defecto Subsistema Cliente Actor principal Usuario genérico Precondiciones Flujo de ejecución 1. El usuario accede a la dirección de la aplicación. 2. Se muestra en la ventana del navegador el mapa 3D Camino alternativo Postcondiciones Mapa 3D activo 61 CU-C-2 Editar dispositivo Descripción Acción mediante la cual el editor modifica parte o toda la información de un dispositivo Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Acceder a editar dispositivo 2. Modificar los datos del dispositivo, tipo y/o modelo 3D 3. Se actualiza la información del dispositivo en el sistema Camino alternativo Postcondiciones CU-C-3 Eliminar dispositivo Descripción Acción mediante la cual el editor elimina un dispositivo del sistema Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Seleccionar el dispositivo que se quiere eliminar 2. Ordenar eliminar 3. Se elimina el dispositivo del sistema Camino alternativo Postcondiciones CU-C-4 Crear tipo de dispositivo Descripción Acción mediante la cual el editor crea un tipo de dispositivo que pasa a identificarse como familia de dispositivo Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Acceder a crear tipo de dispositivo 2. Introducir los datos del dispositivo 3. Se da de alta al tipo de dispositivo en el sistema Camino alternativo 2.1. Si no se introducen todos los datos requeridos se muestra un error al usuario Postcondiciones 68 CU-C-5 Editar tipo de dispositivo Descripción Acción mediante la cual el editor modifica parte o toda la información de un dispositivo Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Acceder a editar tipo dispositivo 2. Modificar los datos del tipo de dispositivo 3. Se actualiza la información del tipo de dispositivo en el sistema Camino alternativo Postcondiciones CU-C-6 Eliminar tipo de dispositivo Descripción Acción mediante la cual el editor elimina un tipo de dispositivo del sistema Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Seleccionar el tipo de dispositivo que se quiere eliminar 2. Ordenar eliminar 3. Se elimina el tipo de dispositivo del sistema Camino alternativo 3.1. Mientras exista algún dispositivo con el tipo de dispositivo que se quiere eliminar, no se podrá eliminar el tipo avisando al usuario de ello. Postcondiciones CU-C-7 Introducir modelo Descripción Acción mediante la cual un editor añade al sistema un modelo 3D Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Acceder a insertar modelo 2. Introducir los datos del modelo 3. Se selecciona el fichero .collada 4. Se da de alta al modelo en el sistema Camino alternativo 2.1. Si no se introducen todos los datos requeridos se muestra un error al usuario Postcondiciones 69 CU-C-8 Editar modelo Descripción Acción mediante la cual el editor modifica parte o toda la información de un modelo 3D Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Acceder a editar modelo 2. Modificar los datos del modelo 3. Se actualiza la información del modelo en el sistema Camino alternativo Postcondiciones CU-C-9 Eliminar modelo Descripción Acción mediante la cual el editor elimina un tipo de dispositivo del sistema Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa Flujo de ejecución 1. Seleccionar el modelo que se quiere eliminar 2. Ordenar eliminar 3. Se elimina el modelo del sistema Camino alternativo 3.1. Mientras exista algún dispositivo con el modelo que se quiere eliminar, no se podrá eliminar el modelo avisando al usuario de ello. Postcondiciones CU-C-10 Dar de alta/ baja a dispositivo Descripción Acción mediante la cual el editor decide que un dispositivo existente sea visible en la aplicación Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa, dispositivo no visible Flujo de ejecución 1. Acceder a dar de alta a dispositivo 2. El dispositivo es visible en la aplicación Camino alternativo Postcondiciones Dispositivo visible 70 CU-C-11 Dar de baja a dispositivo Descripción Acción mediante la cual un usuario registrado cambia su contraseña de acceso Subsistema Dispositivos Actor principal Editor Precondiciones Sesión de editor activa, dispositivo visible Flujo de ejecución 1. Acceder a dar de baja a dispositivo 2. El dispositivo no es visible en la aplicación Camino alternativo Postcondiciones Dispositivo no visible 5.3. Análisis El objetivo principal del presente apartado es comprender el problema y comenzar a definir un modelo de lo que se pretende construir independientemente de la tecnología y lenguaje de programación que se vaya a utilizar. Con el análisis se pasará del modelo de casos de uso al modelo de análisis a través de las trazas y seguidamente se documentará con diagramas de colaboración, en el que queda definido como interaccionan las distintas entidades. El modelo de análisis ayuda a refinar los requisitos y reflexionar sobre los aspectos internos del sistema. En esta etapa se identifican los paquetes de análisis y las clases que los componen. Según se va avanzando en el modelo de análisis estos paquetes se van refinando y manteniendo. A diferencia con el modelo de casos de uso, que servía para capturar la funcionalidad del sistema, el modelo de análisis sirve para dar forma a la arquitectura para soportar dichas funcionalidades y a su vez ayuda a identificar las clases de análisis que posteriormente se convertirán en clases de diseño. Por lo tanto, el apartado estará formado por el subapartado de arquitectura de paquetes de análisis, donde estarán definidos los paquetes y las relaciones entre ellos, y el subapartado de realización de casos de uso donde se expresará mediante diagramas de colaboración y diagramas de clases las relaciones y acciones necesarias para la realización de cada caso de uso. 71 5.3.1. Arquitectura de paquetes La siguiente figura representa la organización lógica de los paquetes de análisis que forman el sistema. En ella se muestran los distintos paquetes que componen el modelo de análisis y la relación entre ellos. El paquete Cliente contiene todas las operaciones relacionadas con el cliente de la aplicación y depende del resto de paquetes. Además contiene las funciones de interrelación y comunicación, mediante los distintos protocolos del cliente con los dispositivos para obtener los datos o lecturas realizados por éstos y ser mostrados. El paquete Usuarios engloba todas las acciones de administración y gestión de cuentas de usuario. El paquete Dispositivos es el encargado de la administración y gestión de dispositivos, sensores, modelos y tipos de dispositivos. Figura 5.9. Paquetes de análisis. 5.3.2. Realización de Casos Uso A continuación se hará el análisis de cada caso de uso. Con ello se obtiene cada realización “caso de uso - análisis” con lo que a partir de cada caso de uso se genera su realización en el modelo de análisis. 72 Cliente <<analysisPackage>> Usuarios <<analysisPackage>> Dispositivos <<analysisPackage>> 5.3.2.1. Cliente La siguiente imagen representa el paquete de análisis Cliente que contiene todas las realizaciones de casos de uso del cliente de la aplicación. Figura 5.10. Realización casos de uso cliente A continuación se define el diagrama de clases del paquete de análisis Cliente, donde se muestra la relación entre los actores del sistema y la interconexión entre cada una de las clases. Las clases las podemos englobar en tres grandes grupos: clases de control, interfaces y entidades. •Las clases de control se encargan de la gestión y manipulación de los datos. •Las interfaces proporcionan las funciones de relación entre un usuario y el sistema. •Las entidades contienen la información. El paquete cliente hace uso de las siguientes clases agrupadas en base a la definición anterior. Control •Controlador Mapa 3D. Gestiona todas las acciones que se realizan sobre el mapa 3D de la aplicación. •Controlador Dispositivos. Gestiona la información y realiza las acciones sobre dispositivos, sensores, modelos o tipos. •Controlador Menú. Lleva a cabo las acciones sobre el menú desplegable. 73 Cliente <<analysisPackage>> Mover mapa 3D Ver mapa 3D Hacer zoom en mapa 3D Ver mundo submarino en mapa 3D Ver dispositivos en mapa 3D Ver dispositivos en menu Ver lectura de datos del dispositivo - NetCDF Ver información del dispositivo Ver descripción de sensores - SensorML Interfaz •IU Mapa 3D. Representa al mapa 3D en sí mismo y permite al usuario interactuar con él. •IU Dispositivo. Permite al usuario obtener información y datos de los distintos dispositivos que contiene el sistema. •IU Menú. Representa al menú desplegable. Entidad •Dispositivo. Contiene los dispositivos presentes en el sistema. Figura 5.11. Diagrama colaboración cliente. 74 Usuario Genérico Controlador Mapa 3D IU Mapa 3D Dispositivo Controlador Menú IU Menú Controlador Dispositivo IU Dispositivo Ver mapa 3D Como se ha comentado anteriormente, cada caso de uso tendrá su representación en el modelo de análisis a través de una relación de traza. Clases participantes Control Interfaz Entidad Controlador Mapa 3D IU Mapa 3D Figura 5.12. Traza (Caso de uso – Análisis) ver mapa 3D. Este caso de uso se inicia al acceder a la URL del cliente de la aplicación. El controlador recoge esa petición y genera la interfaz con el mapa en el que se muestra al usuario. Cualquier usuario tiene permisos para esta acción y por lo tanto se representa mediante el usuario genérico. Figura 5.13. Diagrama colaboración Ver Mapa 3D. 75 Ver mapa 3D Ver mapa 3D IU Mapa 3D <<trace>> Modelo de Casos de Uso Modelo de Análisis Controlador Mapa 3D : Usuario Genérico : IU Mapa 3D : Controlador Mapa 3D 1 : generarMapa()2 : mapa() Ver mundo submarino en mapa 3D Este caso de uso es una particularidad del anterior, y lo que hace es permitir a un usuario situarse en el mapa 3D en un nivel negativo o bajo el agua. Clases participantes Control Interfaz Entidad Controlador Mapa 3D IU Mapa 3D Figura 5.14. Traza (Caso de uso – Análisis) ver mundo submarino en mapa 3D. Una vez un usuario genérico tiene acceso al mapa 3D, usa la interfaz de usuario para colocarse en un punto submarino. El controlador recibe la nueva posición y genera la vista del mapa 3D en ese punto mostrando el fondo marino correspondiente. Figura 5.15. Diagrama colaboración ver mundo submarino en mapa 3D. 76 Ver mundo submarino en mapa 3D Ver mundo submarino en mapa 3D IU Mapa 3D Controlador Mapa 3D <<trace>> Modelo de Casos de Uso Modelo de Análisis : Usuario Genérico : IU Mapa 3D : Controlador Mapa 3D 1 : irPosSubmarina() 2 : Coordenadas() 3 : generaVistaMapa() 4 : mapa() Mover mapa 3D Clases participantes Control Interfaz Entidad Controlador Mapa 3D IU Mapa 3D Figura 5.16. Traza (Caso de uso – Análisis) mover mapa 3D. El caso de uso es iniciado por un usuario genérico. El usuario interactúa con la interfaz de usuario para que se muestre una nueva localización en el mapa 3D. Para ello especifica unas nuevas coordenadas implícitamente. El controlador recibe esa petición, la procesa y genera una nueva vista del mapa centrada en esa posición a través de la interfaz de usuario. Figura 5.17. Diagrama colaboración mover mapa 3D. 77 Mover mapa 3D Mover mapa 3D <<trace>> Modelo de Casos de Uso Modelo de Análisis IU Mapa 3D Controlador Mapa 3D : Usuario Genérico : IU Mapa 3D : Controlador Mapa 3D 1 : irNuevaPosicion() 2 : Coordenadas() 3 : generaVistaMapa() 4 : mapa() 5.3.2.2. Usuarios La siguiente imagen muestra cada una de las colaboraciones que contiene el paquete de análisis Usuarios. Este paquete tiene una relación de traza con el paquete de casos de uso con el mismo nombre. Figura 5.30. Realización casos de uso usuarios. A continuación se muestra el diagrama de clases donde se identifican las clases que participan en dicho paquete y las relaciones entre ellas. Además también se muestran los perfiles de usuarios que harán uso de ellas. En este caso se diferencian dos de los perfiles de usuarios que ya se ha explicado en el capítulo “Captura de requisitos”. Un primero será el perfil de administrador, y es quien tendrá acceso a las secciones de administración de cuentas de usuarios. Y por otro lado está el perfil de usuario registrado que hará uso de las sesiones y de su propia cuenta de usuario. Control •Controlador Acceso. Gestiona el grado de privacidad del cliente de la aplicación. •Controlador Usuario. Gestiona la información y realiza las acciones oportunas sobre las cuentas de usuario. •Controlador Sesion. Crea y destruye sesiones de usuario. 84 Usuarios <<analysisPackage>> Crear usuario Controlar acceso a usuarios anónimos Editar usuario Eliminar usuario Iniciar sesión Cerrar sesión Cambiar contraseña Interfaz •IU Administración. Interfaz de usuario de la parte administrativa de la aplicación. •IU Usuario. Permite al usuario introducir o editar la información referente a las cuentas de usuario. •IU Cambio Contraseña. Permite a un usuario registrado modificar su contraseña. •IU Sesion. Zona de la interfaz donde el usuario introduce sus credenciales de acceso para acceder al sistema como usuario registrado. Entidad •Acceso. Contiene el estado actual de la privacidad de la aplicación. •Usuario. Contiene la información referente a las cuentas de usuario. •Sesion. Contiene la información de las sesiones de usuario. Figura 5.31. Diagrama de colaboración de usuarios. 85 Administrador Usuario Registrado IU Cambio Contraseña Controlador Sesion IU Administración Usuario IU Usuario Controlador Usuario Controlador Acceso Acceso IU Sesion Sesion Crear usuario Clases participantes Control Interfaz Entidad Controlador Usuario IU Administración Usuario IU Usuario Figura 5.32. Traza (Caso de uso – Análisis) crear usuario. Este caso de uso comienza cuando el administrador solicita crear una nueva cuenta de usuario a través de la interfaz de administración. El Controlador Usuario genera un formulario donde el propio administrador introduce los datos de la cuenta de usuario. Estos datos llegan al controlador que lo almacena en Usuario. Figura 5.33. Diagrama colaboración crear usuario. 86 Crear usuario Crear usuario Modelo de Casos de Uso Modelo de Análisis <<trace>> IU Administración Controlador Usuario Usuario IU Usuario : Administrador : IU Administración : Controlador Usuario : IU Usuario : Usuario 1 : crearUsuario() 2 : crearUsuario() 3 : generarFormulario() 4 : rellenarDatosUsuario() 5 : datosUsuario() 6 : guardarUsuario() Editar usuario Clases participantes Control Interfaz Entidad Controlador Usuario IU Administración Usuario IU Usuario Figura 5.34. Traza (Caso de uso – Análisis) editar usuario. Este caso de uso es muy similar al anterior, con la diferencia de que los datos de la cuenta de usuario son insertados en el formulario. Se inicia cuando el administrador selecciona un usuario para editarlo en la interfaz de administración. En ese momento el controlador recupera los datos de la cuenta de la entidad Usuario. Con los datos genera un formulario que le es mostrado al administrador. Éste modifica los datos que considera oportuno y le da a guardar. El controlador recibe los datos y los almacena nuevamente en Usuario. Figura 5.35. Diagrama colaboración editar usuario. 87 : Administrador : IU Administración : Controlador Usuario : IU Usuario : Usuario 1 : editarUsuario() 2 : editarUsuario() 5 : generarFormulario() 6 : modificarDatosUsuario() 7 : datosUsuario() 8 : guardarUsuario() 3 : recuperarDatos() 4 : datos() Modelo de Casos de Uso Modelo de Análisis IU Administración Controlador Usuario Usuario IU Usuario Editar usuario Editar usuario <<trace>> Eliminar usuario Clases participantes Control Interfaz Entidad Controlador Usuario IU Usuario Usuario Figura 5.36. Traza (Caso de uso – Análisis) eliminar usuario. El administrador selecciona un usuario que desea eliminar. Cuando la petición le llega al controlador éste ejecuta la acción y elimina la cuenta de usuario de la entidad Usuario. Figura 5.37. Diagrama colaboración eliminar usuario. 88 Modelo de Casos de Uso Modelo de Análisis Controlador Usuario Usuario IU Usuario Eliminar usuario Eliminar usuario <<trace>> : Administrador : Controlador Usuario : IU Usuario : Usuario 3 : eliminarUsuario() 1 : eliminarUsuario() 2 : eliminarUsuario() Controlar acceso a usuarios anónimos Clases participantes Control Interfaz Entidad Controlador Acceso IU Administración Acceso Figura 5.38. Traza (Caso de uso – Análisis) controlar acceso a usuarios anónimos. Este caso de uso se da cuando el administrador quiere modificar el grado de privacidad de la aplicación. Con ello se pretende controlar que en ciertos momentos, sólo usuarios registrados puedan acceder al cliente de la aplicación. El caso de uso comienza cuando el administrador modifica el valor del acceso en la interfaz de administración. En ese momento el controlador recibe el valor y lo almacena en la entidad Acceso. Figura 5.39. Diagrama colaboración controlar acceso a usuarios anónimos. 89 Modelo de Casos de Uso Modelo de Análisis IU Administración Controlador Acceso Acceso Controlar acceso a usuarios anónimos Control acceso a usuarios anónimos <<trace>> : Administrador : IU Administración : Controlador Acceso : Acceso 1 : abrir/cerrarAcceso() 2 : abrir/cerrarAcceso() 3 : abierto/cerrado() Iniciar sesión Clases participantes Control Interfaz Entidad Controlador Usuario IU Sesion Usuario Controlador Sesion Sesion Figura 5.40. Traza (Caso de uso – Análisis) iniciar sesión. El caso de uso se inicia cuando un usuario registrado intenta acceder al sistema con su cuenta de usuario. El usuario introduce los credenciales de acceso en la interfaz de usuario. El controlador Sesion recibe los credenciales y solicita a Controlador Usuario la contraseña codificada perteneciente al usuario recibido. Éste los recupera desde Usuario y se los devuelve a Controlador Sesión. En ese momento compara si coinciden las dos contraseñas codificadas y si es así crea una sesión de usuario. Figura 5.41. Diagrama colaboración iniciar sesión. 90 Modelo de Casos de Uso Modelo de Análisis Iniciar sesión Iniciar sesión IU Sesion Sesion Controlador Sesion Controlador Usuario Usuario <<trace>> : Usuario Registrado : IU Sesion : Controlador Sesion : Sesion : Controlador Usuario : Usuario 1 : introducirCredenciales() 2 : credenciales() 3 : comprobarCredenciales() 4 : recuperarUsuario() 5 : usuario&pass() 6 : comparaCredenciales() 7 : crearSesion() Cerrar sesión Clases participantes Control Interfaz Entidad Controlador Sesion IU Sesion Sesion Figura 5.42. Traza (Caso de uso – Análisis) cerrar sesión. Cuando un usuario registrado desea abandonar el sistema se inicia este caso de uso. En ese momento el usuario solicita cerrar la sesión. Entonces el controlador elimina la sesión de la entidad Sesion. A partir de ese momento el usuario se convierte en un usuario anónimo. Figura 5.43. Diagrama colaboración cerrar sesión. 91 Modelo de Casos de Uso Modelo de Análisis IU Sesion Sesion Controlador Sesion Cerrar sesión Cerrar sesión <<trace>> : Usuario Registrado : IU Sesion : Controlador Sesion : Sesion 1 : cerrarSesion() 2 : cierraSesion() 3 : eliminarSesion() Cambiar contraseña Clases participantes Control Interfaz Entidad Controlador Usuario IU Cambio Contraseña Usuario IU Usuario Figura 5.44. Traza (Caso de uso – Análisis) cambiar contraseña. Un usuario registrado y que ha accedido al sistema solicita cambiar su contraseña. El controlador genera un formulario para que el usuario introduzca la nueva contraseña y la contraseña anterior. El usuario rellena el formulario y el controlador lo recibe. Cuando comprueba que la nueva contraseña es válida la almacena en Usuario. Figura 5.45. Diagrama colaboración cambiar contraseña. 92 Modelo de Casos de Uso Modelo de Análisis Controlador Usuario Usuario Cambiar contraseña Cambiar contraseña <<trace>> IU Cambio Contraseña IU Usuario : Usuario Registrado : IU Usuario : Controlador Usuario : Usuario : IU Cambio Contraseña 1 : cambiarContraseña() 2 : cambiarContraseña() 3 : generaFormulario() 4 : rellenaCampos() 5 : datos() 6 : modificaContraseña() 5.3.2.3. Dispositivos La siguiente imagen se corresponde con el paquete de análisis Dispositivos que mantiene una relación de traza con el paquete de casos de uso con el mismo nombre. En él se incluyen las colaboraciones de casos de uso que se muestran a continuación. Figura 5.46. Realización casos de uso dispositivos. En el siguiente diagrama de clases, al igual que se ha hecho en los apartados anteriores, se muestra las clases participantes en estos casos de uso y la relación entre ellas. Principalmente, el actor que interviene en estos casos de uso es el perfil de usuario Editor. Él es el encargado de gestionar y mantener la información relativa a los dispositivos presentes en el sistema. Control •Controlador Dispositivo. Se encarga de gestionar la información relativa a los dispositivos y ejecutar las acciones sobre ella. •Controlador ModeloDispositivo. Es el encargado de gestionar la información relativa a la representación gráfica de un dispositivo en el mapa 3D. •Controlador TipoDispositivo. Se encarga de la gestión de los diferentes tipos de dispositivos y de las acciones sobre ellos. 93 Dispositivos <<analysisPackage>> Crear dispositivo Editar dispositivo Eliminar dispositivo Crear tipo de dispositivo Editar tipo de dispositivo Eliminar tipo de dispositivo Introducir modelo Editar modelo Eliminar modelo Dar de alta a dispositivo Dar de baja a dispositivo Eliminar tipo de dispositivo Clases participantes Control Interfaz Entidad Controlador TipoDispositivo IU TipoDispositivo TipoDispositivo Figura 5.58. Traza (Caso de uso – Análisis) eliminar tipo de dispositivo. El editor selecciona un dispositivo para ser eliminado. El controlador recibe esa petición. Entonces, Controlador TipoDispositivo accede a la entidad Tipo Dispositivo y elimina el dispositivo seleccionado. Figura 5.59. Diagrama colaboración eliminar tipo de dispositivo. 100 Modelo de Casos de Uso Modelo de Análisis Controlador TipoDispositivo TipoDispositivo IU TipoDispositivo Eliminar tipo de dispositivo Eliminar tipo de dispositivo <<trace>> : Editor : IU TipoDispositivo : TipoDispositivo : Controlador TipoDispositivo 1 : eliminarTipo() 2 : Tipo() 3 : eliminar() Introducir modelo Clases participantes Control Interfaz Entidad Controlador ModeloDispositivo IU ModeloDispositivo ModeloDispositivo IU Administración Figura 5.60. Traza (Caso de uso – Análisis) introducir modelo. El editor, mediante la interfaz de administración, solicita introducir un modelo 3D de dispositivo en el sistema. El controlador recibe la solicitud y genera un formulario donde el editor insertará la información y la representación del dispositivo. Una vez llega esa información a Controlador ModeloDispositivo, éste lo almacena en la entidad ModeloDispositivo. Figura 5.61. Diagrama colaboración introducir modelo. 101 Modelo de Casos de Uso Modelo de Análisis IU Administración Introducir modelo Introducir modelo ModeloDispositivoControlador ModeloDispositivo IU ModeloDispositivo <<trace>> : Editor : IU Administración : IU ModeloDispositivo : ModeloDispositivo : Controlador ModeloDispositivo 1 : introducirModelo() 2 : introducirModelo() 3 : formulario() 4 : rellenarFormulario() 5 : datos() 6 : guardar() Editar modelo Clases participantes Control Interfaz Entidad Controlador ModeloDispositivo IU ModeloDispositivo ModeloDispositivo IU Administración Figura 5.62. Traza (Caso de uso – Análisis) editar modelo. Cuando un editor quiere modificar un modelo 3D de dispositivo del sistema lo selecciona y esta petición le llega a Controlador ModeloDispositivo. El controlador recupera la información del modelo seleccionado en la entidad ModeloDispositivo, genera un formulario incluyendo los datos recuperados y se le muestra al usuario. El usuario modifica la información necesaria y se envía de nuevo los datos al controlador, que a su vez lo almacena nuevamente en la entidad contenedora. Figura 5.63. Diagrama colaboración editar modelo. 102 Modelo de Casos de Uso Modelo de Análisis IU Administración ModeloDispositivoControlador ModeloDispositivo IU ModeloDispositivo Editar modelo Editar Modelo <<trace>> : Editor : IU Administración : IU ModeloDispositivo : ModeloDispositivo : Controlador ModeloDispositivo 1 : editarModelo() 2 : editarModelo() 5 : formulario() 6 : rellenarFormulario() 7 : datos() 8 : guardar() 3 : recuperarDatos() 4 : datos() Eliminar modelo Clases participantes Control Interfaz Entidad Controlador ModeloDispositivo IU ModeloDispositivo ModeloDispositivo Figura 5.64. Traza (Caso de uso – Análisis) eliminar modelo. El caso de uso comienza cuando un editor solicita eliminar un Modelo de representación 3D de dispositivo. En ese momento, Controlador ModeloDispositivo accede a la entidad ModeloDispositivo y ejecuta la petición eliminándolo del sistema. Figura 5.65. Diagrama colaboración eliminar modelo. 103 Modelo de Casos de Uso Modelo de Análisis ModeloDispositivoControlador ModeloDispositivo IU ModeloDispositivo Eliminar modelo Eliminar modelo <<trace>> : Editor : IU ModeloDispositivo : ModeloDispositivo : Controlador ModeloDispositivo 1 : eliminarModelo() 2 : modelo() 3 : eliminar() Dar de alta a dispositivo Clases participantes Control Interfaz Entidad Controlador Dispositivo IU Dispositivo Dispositivo Figura 5.66. Traza (Caso de uso – Análisis) dar de alta dispositivo. Aunque un dispositivo exista en el sistema puede darse el caso en el que a los editores de la aplicación les interese que no sea visible para los usuarios. Este caso de uso representa el momento en que el editor decide hacer visible un dispositivo que no lo era. Para ello, el editor selecciona un dispositivo y lo marca como activo. En ese momento el controlador accede a la entidad Dispositivo y actualiza esa información para ese dispositivo. Figura 5.67. Diagrama colaboración dar de alta dispositivo. 104 Modelo de Casos de Uso Modelo de Análisis IU Dispositivo Dispositivo Controlador Dispositivo Dar de alta a dispositivo Dar de alta a dispositivo <<trace>> : Editor : IU Dispositivo : Controlador Dispositivo : Dispositivo 1 : altaDispositivo() 2 : Dispositivo() 3 : guardar() Dar de baja a dispositivo Clases participantes Control Interfaz Entidad Controlador Dispositivo IU Dispositivo Dispositivo Figura 5.68. Traza (Caso de uso – Análisis) dar de baja dispositivo. Este es el caso de uso inverso al anterior. En esta ocasión, el caso de uso se inicia cuando un editor decide que un dispositivo del sistema deje de ser visible. Una razón de esto puede ser que el dispositivo se haya extraído de su posición para ser reparado, que el dispositivo se haya roto, se haya perdido la comunicación con él, o simplemente no interesa que sea visible en un momento dado. Entonces el caso de uso comienza con el editor marcando el dispositivo como inactivo. En ese momento el controlador accede a la entidad Dispositivo y actualiza el valor de estado a inactivo para el dispositivo seleccionado. Figura 5.69. Diagrama colaboración dar de baja dispositivo. 105 Modelo de Casos de Uso Modelo de Análisis IU Dispositivo Dispositivo Controlador Dispositivo Dar de baja a dispositivo Dar de baja a dispositivo <<trace>> : Editor : IU Dispositivo : Controlador Dispositivo : Dispositivo 1 : bajaDispositivo() 2 : Dispositivo() 3 : guardar() 5.4. Diseño A continuación se desarrolla el modelo diseño de proyecto. En este apartado se pasará del modelo de análisis, que proporciona una comprensión detallada de los requisitos, al modelo de diseño, que ofrece una representación coherente y detallada del programa donde se ha tenido en cuenta aspectos técnicos de la construcción del proyecto. En el diseño se requiere de una comprensión profunda de las restricciones ligadas a los lenguajes de programación, librerías o tecnologías de interfaz de usuario. El presente apartado estará divido en los siguientes subapartados: •Diseño arquitectónico. Se definirá la arquitectura del software desde la capa de más bajo nivel a la más específica. •Diagramas de clases y diagramas de secuencia. Se documentará mediante diagramas de clases la composición de cada uno de los módulos a implementar y se documentará cada realización de casos de uso mediante diagramas de secuencia. •Diseño de despliegue. Define el modelo de despliegue de la aplicación dentro de la organización. •Diseño de base de datos. Mediante diagramas de Entidad-Relación se modela la base de datos sobre la que actuará la aplicación. •Diseño de prototipo de interfaz de usuario. 5.4.1. Diseño Arquitectónico. El diseño arquitectónico de la aplicación se va a basar en una arquitectura por capas, disminuyendo en generalidad según vamos subiendo en las capas. Van a existir cuatro capas bien diferenciadas: la capa del sistema, la capa middleware, la capa genérica y la capa específica. La capa del sistema es la que se encuentra en el más bajo nivel e incluye operaciones de sistemas operativos y comunicaciones de red. En ella aparece el paquete TCP/IP. La siguiente capa es la capa Middleware y en ella están incluidos todo tipo de servicios y paquetes de terceros que son necesarios para el correcto funcionamiento de la aplicación. Esta capa está formada por el sistema de gestión de bases de datos, que en nuestro caso será MySQL. También la forma Python como intérprete del lenguaje Python y MySQL-Python para permitir la conexión con la base datos. Como framework de aplicación web se hace uso de Django. En esta capa se incluye también la API de Google Earth y el paquete Scientific.IO.NETCDF para poder conectar la aplicación a servicios NetCDF para la obtención de los datos leídos por los sensores de los dispositivos. Por último se incluye también en este nivel los servidores web y los navegadores. En las dos capas superiores estarán los propios módulos de esta aplicación. Si subimos un nivel en la arquitectura del sistema nos encontramos con la capa genérica. Esta capa la forman los paquetes mas genéricos de 3DO. Son paquetes que pueden ser reutilizados fácilmente en otra 106 aplicación, ya que son elementos comunes en muchas aplicaciones. Por lo tanto, en esta capa está contenido el paquete de gestión de usuarios. Por último, nos encontramos con la capa específica que contiene los paquetes que han sido diseñados específicamente para esta aplicación y que muy difícilmente podrán ser reutilizados en otra aplicación. Estos son los paquetes Cliente y Dispositivos, que se adaptan perfectamente a la estructura de datos que se usa en la organización. Figura 5.69. Diagrama Diseño Arquitectónico. 107 Cliente <<designSubsystem>> Usuarios <<designSubsystem>> Dispositivos <<designSubsystem>> Capa Específica Capa Genérica Middleware Capa de sistema Python Django TCP/IP GoogleEarthAPI MySQLNavegadorWeb Nginx Gunicorn MySQL-Python Scientific.IO.NETCDF 5.4.2. Diagramas de Clases y Secuencias En este subapartado se definirá el funcionamiento de las distintas partes de la aplicación haciendo uso de diagramas de clases y diagramas de secuencias. Con los diagramas de clase se pretende documentar las relaciones entre las distintas clases que conforman el sistema. Por otro lado, con los diagramas de secuencia se consigue definir el intercambio de mensajes e información entre las clases. Siguiendo la metodología usada hasta el momento, por facilidad se irán agrupando las realizaciones de caso de uso por paquetes funcionales, tal y como se ha venido haciendo a lo largo del presente documento. 5.4.2.1. Cliente El paquete de diseño Cliente tiene una relación de traza con el paquete de análisis con el mismo nombre, y éste a su vez con el paquete de casos de uso. Al igual que toda la aplicación, se hace uso del patrón de diseño MVC (modelo – vista – controlador). Con ello se consigue separar el negocio de la aplicación, de la interfaz de usuario y del modelo de datos. En base a ésto, los controladores se encargan de la parte funcional, mientras que los modelos son los encargados de interactuar con la base de datos. La página principal del cliente está compuesta por una serie de vistas que incluye un mapa 3D o globo terráqueo virtual, un menú y una sección para las sesiones de usuario. El controlador del mapa 3D hereda directamente de la API de Google Earth. Además éste está relacionado con los controladores de los usuarios y los dispositivos para obtener la información desde la base de datos a través de los modelos respectivos, sobre todo a nivel de permisos. 108 Figura 5.70. Diagrama de clases del cliente. 109 Home <<client page>> AreaLogin <<form>> Mapa3D <<client page>> Menu <<client page>> Controlador Dispositivo <<server page>> Modelo Dispositivo GoogleEarthPlugin <<plugin>> Controlador Usuario <<server page>> BBDD Modelo Usuario executeQuery Controlador Cliente <<server page>> Controlador Sesión <<server page>> Sesion Ver información del dispositivo Figura 5.83. Traza (Caso de uso - Análisis - Diseño) ver información de dispositivo. El controlador del cliente le solicita al controlador de dispositivos la información relativa al dispositivo seleccionado. Controlador Dispositivo la obtiene de la base de datos a través del modelo y se la envía a Controlador Cliente. Cuando el controlador del cliente tiene la información, la formatea y la incluye en una burbuja sobre el mapa 3D que será mostrada al usuario. Figura 5.84. Diagrama de secuencia ver información de dispositivo. 116 Ver información del dispositivo Ver información del dispositivo <<trace>> Modelo de Casos de Uso Modelo Análisis Ver información del dispositivo Modelo Diseño Controlador Cliente <<server page>> Modelo Dispositivo Controlador Dispositivo <<server page>> Mapa3D <<client page>> <<trace>> / : Controlador Cliente / : Controlador Dispositivo/ : Mapa3D / : Modelo Dispositivo / : executeQuery 1 : obtenerInfoDispositivo() 2 : recuperarInfoDispositivo() 3 : Query() 4 : QueryResponse() 5 : informaciónDispositivo() 6 : Información() 7 : render() Ver lectura de datos del dispositivo Figura 5.85. Traza (Caso de uso - Análisis - Diseño) ver datos de dispositivo. Un caso particular del anterior es, una vez mostrada la información, el usuario solicita ver los datos capturados por los sensores del dispositivo. En ese momento el controlador de cliente recibe la petición, se la traslada al controlador de dispositivos y éste la obtiene de la base de datos usando a Modelo Dispositivo. Al igual que en el caso anterior, Controlador Cliente recibe los datos, los formatea y los muestra en la misma burbuja sobre mapa 3D. Figura 5.86. Diagrama de secuencia ver datos de dispositivo. 117 Ver lectura de datos del dispositivo - NetCDF Ver lectura de datos del dispositivo - NetCDF <<trace>> Modelo de Casos de Uso Modelo de Análisis Ver lectura de datos del dispositivo - NetCDF Modelo de Diseño Controlador Cliente <<server page>> Modelo Dispositivo Controlador Dispositivo <<server page>> Mapa3D <<client page>> <<trace>> / : Controlador Cliente / : Controlador Dispositivo/ : Mapa3D / : Modelo Dispositivo / : executeQuery 1 : obtenerDatosDispositivo() 2 : recuperarDatosDispositivo() 3 : Query() 4 : QueryResponse() 5 : DatosDispositivo() 6 : Datos() 7 : render() Ver descripción de sensores - SensorML Figura 5.87. Traza (Caso de uso - Análisis - Diseño) ver sensores de dispositivo. Un caso particular del anterior es, una vez mostrada la información, el usuario solicita ver los datos capturados por los sensores del dispositivo. En ese momento el controlador de cliente recibe la petición, se la traslada al controlador de dispositivos y éste la obtiene de la base de datos usando a Modelo Dispositivo. Al igual que en el caso anterior, Controlador Cliente recibe los datos, los formatea y los muestra en la misma burbuja sobre mapa 3D. Figura 5.88. Diagrama de secuencia ver sensores de dispositivo. 118 Modelo de Casos de Uso Modelo de Análisis Modelo de Diseño Controlador Cliente <<server page>> Modelo Dispositivo Controlador Dispositivo <<server page>> Mapa3D <<client page>> Ver descripcion de sensores - SensorML Ver descripción de sensores - SensorML Ver descripción de sensores - SensorML <<trace>> <<trace>> / : Controlador Cliente / : Controlador Dispositivo/ : Mapa3D / : Modelo Dispositivo / : executeQuery 1 : verDescripcionSensor() 2 : recuperarDescripcionSensor() 3 : Query() 4 : QueryResponse() 5 : DescripcionSensor() 6 : Datos() 7 : render() 5.4.2.2. Usuarios El paquete de diseño Usuarios tiene una relación de traza con el paquete de análisis con el mismo nombre, y éste a su vez con el paquete de casos de uso. Este paquete pertenece a los paquetes de administración, los cuales tienen una vista común llamada Vista Administración, que da acceso a todas las funciones administrativas del sistema. El paquete Usuarios implementa todas las funcionalidades relacionadas con la gestión de cuentas de usuario y el control de sesiones. El diseño también sigue el patrón MVC en el que en el siguiente diagrama de clases queda perfectamente reflejado. Figura 5.89. Diagrama de clases de usuarios. 119 Vista Administración <<client page>> Controlador Usuario <<server page>> Vista Usuario <<form>> executeQuery BBDD Modelo Usuario Crear usuario Figura 5.90. Traza (Caso de uso - Análisis - Diseño) crear usuario. El controlador genera el formulario para la introducción de los datos de usuario. Una vez, recibe los datos se los pasa al modelo para que valide dichos datos, y si todo es correcto lo almacene en la base de datos. Figura 5.91. Diagrama de secuencia crear usuario. 120 Crear usuario Crear usuario Modelo de Casos de Uso Modelo de Análisis <<trace>> Crear usuario Modelo de Diseño Vista Usuario <<form>> Controlador Usuario <<server page>> Modelo Usuario <<trace>> / : Controlador Usuario/ : Vista Usuario / : Modelo Usuario / : executeQuery 1 : render() 2 : datosUsuarios() 3 : guardar() 4 : executeQuery() Editar usuario Figura 5.92. Traza (Caso de uso - Análisis - Diseño) editar usuario. La edición de usuarios es muy parecida a la creación de los mismos. La diferencia es que en la edición el controlador lo primero que hace es obtener los datos del usuario desde la base de datos a través del modelo y generar la vista a partir de ellos. Una vez se modifican los datos y van de vuelta el controlador, este los envía al modelo para que los valide y los almacene en la base de datos. Figura 5.93. Diagrama de secuencia editar usuario. 121 Modelo de Casos de Uso Modelo de Análisis Editar usuario Modelo de Diseño Editar usuario Editar usuario Vista Usuario <<form>> Controlador Usuario <<server page>> Modelo Usuario <<trace>> <<trace>> / : Controlador Usuario/ : Vista Usuario / : Modelo Usuario / : executeQuery 1 : recuperarDatosUsuario() 2 : executeQuery() 3 : queryResponse() 4 : datosUsuario() 5 : render() 6 : datosUsuario() 7 : guardar() 8 : executeQuery() Eliminar usuario Figura 5.94. Traza (Caso de uso - Análisis - Diseño) eliminar usuario. Cuando al controlador le llega una petición de eliminar una cuenta de usuario, éste ordena al modelo que lo elimine. Modelo Usuario accede a la base de datos y elimina el usuario con el identificador dado. Figura 5.95. Diagrama de secuencia eliminar usuario. 122 / : Controlador Usuario / : Modelo Usuario / : executeQuery 1 : eliminar() 2 : executeQuery() Modelo de Casos de Uso Modelo de Análisis Eliminar usuario Eliminar usuario <<trace>> Modelo de Diseño Eliminar usuario Controlador Usuario <<server page>> Modelo Usuario <<trace>> Controlar acceso a usuarios anónimos Figura 5.96. Traza (Caso de uso - Análisis - Diseño) acceso anónimos. Cuando el administrador modifica el grado de privacidad de la aplicación, el controlador de usuarios actualiza el valor en la base de datos a través del modelo. El controlador del cliente cuando se llama por primera vez comprueba este valor, y si el estado es cerrado, solo permite cargar el globo terráqueo a usuarios que se encuentren identificados en el sistema. Figura 5.97. Diagrama de secuencia acceso anónimos. 123 Modelo de Casos de Uso Modelo de Análisis Controlar acceso a usuarios anónimos Control acceso a usuarios anónimos <<trace>> Modelo de Diseño Controlar acceso a usuarios anónimos Controlador Usuario <<server page>> Modelo Usuario <<trace>> / : Controlador Usuario / : Modelo Usuario / : executeQuery 1 : abrir/cerrarAcceso() 2 : executeQuery() Iniciar sesión Figura 5.98. Traza (Caso de uso - Análisis - Diseño) iniciar sesión. El usuario introduce los credenciales de acceso a través del formulario AreaLogin. Estos datos le llegan al Controlador Sesion que necesita la contraseña cifrada del usuario que intenta identificarse para cotejarla. Para ello, se la solicita al controlador de usuarios que la obtiene de la base de datos a través del modelo y se la envía al controlador de sesiones. Éste comprueba que la contraseña introducida tras cifrarla y la contraseña cifrada almacenada en la base de datos son la misma. Si es así crea una sesión de usuario. Figura 5.99. Diagrama de secuencia iniciar sesión. 124 Modelo de Casos de Uso Modelo de Análisis Iniciar sesión Iniciar sesión <<trace>> Modelo de Diseño Iniciar sesión AreaLogin <<form>> Controlador Sesión <<server page>> Sesion Controlador Usuario <<server page>> Modelo Usuario <<trace>> / : AreaLogin / : Controlador Sesión/ : Sesion / : Controlador Usuario / : Modelo Usuario / : executeQuery 1 : credencialesUsuario() 2 : usuario() 3 : recuperarDatosUsuario() 4 : executeQuery() 5 : queryResponse() 6 : datosUsuario() 7 : comparaCredenciales() 8 : nuevaSesion() Cerrar sesión Figura 5.100. Traza (Caso de uso - Análisis - Diseño) cerrar sesión. El proceso para cerrar una sesión de usuario abierta es bastante más simple. Basta con que el usuario se lo manifieste al controlador de sesión y que destruya el objeto sesión. Figura 5.101. Diagrama de secuencia cerrar sesión. 125 Modelo de Casos de Uso Modelo de Análisis Cerrar sesión Cerrar sesión <<trace>> Modelo de Diseño Cerrar sesión Controlador Sesión <<server page>> Sesion <<trace>> / : Controlador Sesión / : Sesion 1 : eliminarSesion() Editar tipo de dispositivo Figura 5.113. Traza (Caso de uso - Análisis - Diseño) editar tipo dispositivo. Para editar un tipo de dispositivo el controlador recupera los datos del tipo desde la base de datos haciendo uso del modelo. Una vez recuperados los datos muestra la vista donde se encuentra el formulario con los datos preinsertados. Una vez el usuario los modifica e intenta guardarlos el controlador captura la petición, valida los datos y el modelo los actualiza en la base de datos. Figura 5.114. Diagrama de secuencia editar tipo dispositivo. 132 Modelo de Casos de Uso Modelo de Análisis Editar tipo de dispositivo Editar tipo de dispositivo <<trace>> Modelo de Diseño Editar tipo de dispositivo Vista TipoDispositivo <<form>> Modelo TipoDispositivo Controlador TipoDispositivo <<server page>> <<trace>> / : Controlador TipoDispositivo / : Modelo TipoDispositivo/ : Vista TipoDispositivo / : executeQuery 1 : recuperardatos() 2 : executeQuery() 3 : queryResponse() 4 : datos() 5 : render() 6 : datos() 7 : guardar() 8 : executeQuery() Eliminar tipo de dispositivo Figura 5.115. Traza (Caso de uso - Análisis - Diseño) eliminar tipo dispositivo. Para eliminar un tipo de dispositivo el controlador de tipos de dispositivo recibe la petición y se la traslada al modelo que es el encargado de llevar a cabo la eliminación en la base de datos borrando así el registro perteneciente al identificador seleccionado. Figura 5.116. Diagrama de secuencia eliminar tipo dispositivo. 133 Modelo de Casos de Uso Modelo de Análisis Eliminar tipo de dispositivo Eliminar tipo de dispositivo <<trace>> Modelo de Diseño Eliminar tipo de dispositivo Modelo TipoDispositivo Controlador TipoDispositivo <<server page>> <<trace>> / : Controlador TipoDispositivo / : Modelo TipoDispositivo / : executeQuery 1 : eliminarTipo() 2 : executeQuery() Introducir modelo Figura 5.117. Traza (Caso de uso - Análisis - Diseño) introducir modelo 3D. El controlador modelo3D genera la vista con el formulario para la inserción de los datos del modelo 3D y el fichero en formato collada que se desea insertar. Una vez el usuario introduce los datos y el modelo, el controlador los recibe y los guarda en la base de datos mediante el modelo correspondiente. Figura 5.118. Diagrama de secuencia introducir modelo 3D. 134 Modelo de Casos de Uso Modelo de Análisis Introducir modelo Introducir modelo <<trace>> Modelo de Diseño Introducir modelo Controlador Modelo3D <<server page>> Modelo Modelo3D Vista Modelo3D <<form>> <<trace>> / : Controlador Modelo3D / : Vista Modelo3D / : Modelo Modelo3D / : executeQuery 1 : render() 2 : datos() 3 : guardar() 4 : executeQuery() Editar modelo Figura 5.119. Traza (Caso de uso - Análisis - Diseño) editar modelo 3D. Cuando se va a editar un modelo 3D el controlador recupera los datos de la base de datos haciendo uso de su correspondiente modelo. Una vez hecho, inserta esos datos en el formulario y renderiza la vista. Cuando los datos son modificados y se recibe la petición de guardado el controlador valida los datos y se los pasa al modelo que es el encargado de almacenarlo en la base de datos. Figura 5.120. Diagrama de secuencia editar modelo 3D. 135 Modelo de Casos de Uso Modelo de Análisis Editar modelo Editar Modelo <<trace>> Modelo de Diseño Editar modelo Controlador Modelo3D <<server page>> Modelo Modelo3D Vista Modelo3D <<form>> <<trace>> / : Controlador Modelo3D / : Vista Modelo3D / : Modelo Modelo3D / : executeQuery 1 : recuperarDatos() 2 : executeQuery() 3 : queryResponse() 4 : datos() 5 : render() 6 : datos() 7 : guardar() 8 : executeQuery() Eliminar modelo Figura 5.121. Traza (Caso de uso - Análisis - Diseño) eliminar modelo 3D. Cuando un usuario desea eliminar un modelo 3D el controlador captura la petición y el identificador del elemento seleccionado. Ésto se le pasa al modelo y él lo elimina de la base de datos. Figura 5.122. Diagrama de secuencia eliminar modelo 3D. 136 Modelo de Casos de Uso Modelo de Análisis Eliminar modelo Eliminar modelo <<trace>> Modelo de Diseño Eliminar modelo Controlador Modelo3D <<server page>> Modelo Modelo3D <<trace>> / : Modelo Modelo3D/ : Controlador Modelo3D / : executeQuery 1 : eliminarModelo() 2 : executeQuery() 5.4.3. Modelo de despliegue. El gráfico siguiente representa el despliegue de la aplicación tanto en los dominios de la organización como en el ámbito externo a ésta. Como se observa, hay dos partes claramente diferenciadas: la parte superior representa a las máquinas presentes en la organización y la parte inferior de la imagen son los PCs desde los cuales los usuarios pueden conectarse vía internet y acceder a los contenidos del portal. Tanto las bases de datos como el servidor web se encuentran dentro de la intranet de PLOCAN pero son accesibles desde Internet. Sin embargo, los servidores de datos oceanográficos se encuentran de forma remota. Figura 5.123. Diagrama del modelo de despliegue de la aplicación. 137 TCP/IP TCP/IP PC1 Plocan PC2 Plocan PCn Plocan intranet <<artifact>> TCP/IP TCP/IP TCP/IP . . . ServidorWeb 80 TCP/IP Pasarela TCP/IP Intranet PLOCAN internet <<artifact>> Sistema de Copias de Seguridad UserPC UserPC UserPC UserPC UserPC UserPC TCP/IP TCP/IP TCP/IP TCP/IP TCP/IP TCP/IP Servidor Datos Oceanográficos Servidor Datos Oceanográficos TCP/IP TCP/IP Internet SGBD 5.4.4. Diseño de la base de datos A continuación se presentará el diseño de la base de datos mediante diagramas de EntidadRelación. Se usa esta metodología ya que el proceso de creación de las tablas y sus relaciones es un paso directo entre el diagrama y su correspondiente sentencia SQL. Además de ello la documentación es totalmente clara y precisa. Figura 5.123. Diagrama Entidad-Relación de la base de datos. 138 5.4.5. Prototipo de Interfaz de Usuario 3DO es una aplicación web y por lo tanto su interfaz de usuario es basada en páginas web. La interfaz tiene dos partes perfectamente diferenciadas. Primero tiene una interfaz pública que es visible a todo el mundo y que se corresponde con el cliente de la aplicación. Y en segundo lugar hay una interfaz privada y restringida a los usuarios con los permisos pertinentes y se corresponde con la interfaz de administración de la aplicación. 5.4.5.1. Cliente La interfaz del cliente está formada por una cabecera principal, un menú, un área de login y el elemento mas importante que es el mapa 3D. Cabecera Principal Menú Principal Área de sesión de usuario Menú Secundario Mapa 3D El menú es un menú desplegable donde se listan los dispositivos que son accesibles, sus sensores y la plataforma oceánica. Al hacer click sobre un ítem del menú, el mapa entrará en acción y mostrará la localización del dispositivo seleccionado mostrando una vista general de la zona. Al hacer click sobre un dispositivo en el mapa se abrirá una burbuja con la información de interés del dispositivo. 139 5.4.5.2. Administración La interfaz de administración es de uso privado a usuarios con los permisos necesarios. Se divide en 4 bloques: una cabecera, una zona de mensajes al usuario y acciones sobre esa cuenta de usuario, un bloque de administración de usuarios y un bloque de administración de dispositivos. Cabecera Principal Bienvenida – Fecha:hora Acciones sobre usuario actual Área de administración de usuarios Área de administración de dispositivos El área de administración de usuarios solo será visible para los usuarios con permisos de administrador. En él se podrá acceder a la creación, modificación y eliminación de usuarios. Por otro lado, el área de administración de dispositivos será visible tanto para usuarios con permisos de editor como de administrador. En este área estarán las herramientas para creación, edición y eliminación de dispositivos, tipos, modelos y sensores. Una vez se accede a cualquiera de estos apartados de administración, todos tienen el mismo aspecto con la diferencia de los campos que aparecen en cada uno, pero siguiendo un mismo estilo. 140 5.5. Implementación El presente epígrafe se centrará en la fase de implementación del producto. Durante esta etapa se construye el producto software a partir de los documentos y artefactos obtenidos hasta el momento en la fase de diseño. La fase de implementación está marcada principalmente por la generación del código fuente de la aplicación, y por lo tanto, la mayor parte de la documentación va introducida en el propio código a forma de comentarios. Por esta razón la documentación de esta fase, en cuanto a este documento se refiere, estará estructurada de la siguiente manera: 1. Instalación y configuración de Django. Se enumeran los pasos llevados a cabo para la instalación y configuración del framework y librerías adicionales en cada uno de los entornos existentes. 2. Control de versiones. Se explica el sistema de control de versiones que se ha seleccionado y la manera de ejecutarlo con los recursos que se tenían disponibles. 3. Organización del código. Se define cómo está organizado el código y se muestran algunas partes relevantes donde se hayan implementado partes destacables o que sirvan de ejemplo para entender de forma global el proyecto. 5.5.1. Instalación y Configuración de Django En el presente subapartado se explicará paso a paso la forma de instalar y configurar el framework de desarrollo Django y el resto de librerías Python utilizadas en el proyecto, además de otras herramientas como puede ser el propio interprete de Python, el sistema de gestión de base de datos MySQL o los diferentes servidores web para el despliegue de la aplicación. La configuración es un poco diferente en el servidor de desarrollo y en los servidores de calidad y de producción, ya que el propósito de cada uno es distinto. En el servidor de desarrollo se estará escribiendo código y haciendo pruebas continuas y el estado y la configuración puede estar cambiando cada momento. Sin embargo, en el servidor de calidad o el servidor de producción, el estado es bastante mas estático y se espera una mayor estabilidad y disponibilidad. La principal diferencia radica en que para el servidor de desarrollo basta con el servidor web ligero que proporciona Django, mientras que para el servidor de calidad, donde se realizarán las pruebas beta, y para el servidor de producción, hacen falta servidores web robustos separados para la aplicación y los datos estáticos (ficheros CSS, JS, imágenes, etc). 141