Desarrollo de una aplicación web para la gestión de rutas en sistemas georreferenciados

Proyecto Fin de Carrera Desarrollo de una Aplicaci´on Web para la Gesti´on de Rutas en Sistemas Georreferenciados Sa´ul Rodr´ıguez Rodr´ıguez Las Palmas de Gran Canaria Septiembre de 2013 ii iii iv v Universidad de Las Palmas de Gran Canaria Escuela de Ingenier´ıa Inform´atica Proyecto Fin de Carrera Proyecto: Desarrollo de una Aplicaci´on Web para la Gesti´on de Rutas en Sistemas Georreferenciados Alumno: Sa´ul Rodr´ıguez Rodr´ıguez Tutor: Javier S´anchez P´erez vi vii “Un viaje es una nueva vida, con un nacimiento, un crecimiento y una muerte, que nos es ofrecida en el interior de la otra. Aprovech´emoslo.” Paul Morand viii ix A mi familia xvi ´ INDICE GENERAL B. Glosario 247 ´ Indice de figuras 254 ´ Indice de cuadros 255 Bibliograf´ıa 258 Prefacio La georreferenciaci´on es un campo que a d´ıa de hoy forma parte de nuestra vida diaria. Hemos pasado de usar mapas y globos terr´aqueos representando la superficie del planeta a representaciones virtuales en tres dimensiones del ´area que queremos visualizar con un grado de detalle nunca visto. Este progreso se ha completado en el transcurso de unas pocas d´ecadas. El objetivo de la georreferenciaci´on, as´ı como de las herramientas que utilizan este concepto, es informar y visualizar el terreno de la mejor forma posible de cara al usuario, facilit´andole la toma de decisiones para que ´este pueda tomar la m´as acertada. Ello ha hecho que nos convirtamos en usuarios que hacen un gran uso de este tipo de sistemas. No s´olo los usuarios individuales usan este tipo de sistemas; empresas, organizaciones y gobiernos tambi´en utilizan sistemas de informaci´on geogr´afica con el prop´osito de extraer patrones de distribuci´on sobre el terreno. De esta forma, su toma de decisiones es m´as simple y proporcionar´a un mejor resultado en el futuro. La evoluci´on de los Sistemas de Informaci´on Geogr´afica (SIG) se ha debido a la mejora de las herramientas y programas asociados a ´estos. Los ´ultimos ahora son capaces de trabajar usando informaci´on geogr´afica de manera equivalente a la que emplean los usuarios: nombres de calles, lugares y similares. Sin embargo, tambi´en emplean la representaci´on formal a trav´es de coordenadas como latitud y longitud. Ambas representaciones se combinan usando diccionarios (denominados nomencl´atores) que enlazan los nombres con sus coordenadas correspondientes. Junto con los sistemas de informaci´on geogr´afica han aparecido una serie de est´andares con el objetivo de facilitar la interoperabilidad entre los mismos. Estos est´andares cubren varios aspectos propios de estos sistemas, desde la representaci´on del terreno al almacenamiento de la informaci´on. Algunos de los est´andares establecidos son abiertos, generalmente creados por el Open Geospatial Consortium (OGC), y otros propietarios, usualmente por parte de empresas. Algunos de los est´andares actuales son: 1. Conversores de datos (DLG, MOSS, GIRAS) 2. Formatos de intercambio est´andar (SDTS, DXF, GML) 3. Formatos de fichero abiertos (VPF, shapefiles, KML) 4. Interfaces de Programaci´on de Aplicaciones (APIs) (ArcSDE API, CAD Reader, ArcSDE CAD Client) 5. Caracter´ısticas comunes en Sistemas de Gesti´on de Bases de Datos (SGBD) (OGC Simple Feature Specification for SQL) xvii xviii PREFACIO 6. Integraci´on de servicios web SIG estandarizados (WMS, WFS, ArcIMS) Muchas de las aplicaciones que emplean t´ecnicas SIG que se utilizan actualmente est´an disponibles v´ıa web. Ello facilita su uso debido a que el usuario puede acceder desde diferentes puntos a la aplicaci´on manteniendo su informaci´on centralizada y siempre disponible. Algunas de estas aplicaciones han incorporado aspectos de la denominada “Web 2.0” como la facilidad a la hora de compartir informaci´on, la interoperabilidad, el dise˜no centrado en el usuario y la colaboraci´on. En las aplicaciones Web 2.0 no s´olo se ofrece un contenido est´atico dispuesto para que los usuarios lo visualicen, sino que ´estos ´ultimos participan del contenido existente, ya sea mejor´andolo o ampli´andolo colaborando y comunic´andose entre s´ı. Para ello fue necesario que aparecieran tecnolog´ıas software que permitieran hacer todo esto posible como AJAX o XML. El siguiente paso dentro de la evoluci´on tecnol´ogica que ha tra´ıdo el uso de los sistemas SIG es el poder hacer uso de los mismos desde los nuevos tel´efonos m´oviles o smartphones. La potencia de procesamiento que poseen estos dispositivos, junto con la capacidad de poder conectarse a Internet, ha dado cabida a la aparici´on de aplicaciones SIG en este nuevo nicho de mercado. Su principal cualidad, el poder acceder a un sistema SIG desde cualquier punto, ha supuesto una revoluci´on dentro de este campo. Varios de los conceptos indicados anteriormente se han tenido en cuenta a la hora de conceptuar, dar forma e implementar este proyecto. El trabajo expuesto en este documento refleja la realizaci´on de un proyecto de Ingenier´ıa de Software con el objetivo de desarrollar una aplicaci´on web de gesti´on de rutas y que ´estas se visualicen en un sistema georreferenciado como Google Earth. Un sistema georreferenciado permite obtener la posici´on de un objeto presente en un entorno de dos o tres dimensiones. La aplicaci´on tiene soporte de usuarios permitiendo que ´estos puedan crear, almacenar y visualizar las rutas de manera c´omoda y sencilla. Dichas rutas pueden incorporar otros elementos multimedia, como fotos y v´ıdeos, que permiten una mejor comprensi´on de las mismas por parte del usuario a˜nadiendo conocimiento. Se ilustrar´a la metodolog´ıa de desarrollo empleada, que en este caso es la del Proceso Unificado de Desarrollo de Software (PUD) y se presentar´an los productos generados seg´un indica la misma, utilizando t´ecnicas y herramientas como UML entre otras. Es una metodolog´ıa iterativa e incremental, dirigida por casos de uso, centrada en la arquitectura y enfocada en detectar los posibles riesgos dentro del ciclo de vida del proyecto. La aplicaci´on resultante hace uso de un framework en PHP denominado CakePHP encargado de operar con la base de datos MySQL, adem´as de proporcionar otras utilidades que permiten un desarrollo de la aplicaci´on m´as r´apido y f´acil. Para la interfaz de usuario se ha empleado la librer´ıa MochaUI que permite construir aplicaciones web con apariencia de escritorio de forma sencilla. Tambi´en se ha utilizado JavaScript y JQuery de cara a proporcionar al usuario una aplicaci´on m´as accesible de utilizar. Por ´ultimo se especificar´an las conclusiones obtenidas tras realizar este trabajo, tanto a la hora de hablar sobre las herramientas utilizadas como por las decisiones y tareas realizadas por mi parte. Cap´ıtulo 1 Introducci´on Un sistema georreferenciado es aquel que es capaz de recoger, manipular y mostrar informaci´on sobre la posici´on geogr´afica de un objeto. Este tipo de sistemas se cre´o con el prop´osito inicial de resolver problemas de planificaci´on y gesti´on geogr´afica. El nivel de detalle que proporcionan ha ido evolucionando desde peque˜nas zonas de terreno hasta el planeta entero a d´ıa de hoy. Actualmente, los sistemas m´as modernos de georreferenciaci´on recogen toda la informaci´on a trav´es de la digitalizaci´on de im´agenes provenientes de sat´elites y fotograf´ıas a´ereas por parte de programas de CAD (Dise˜no Asistido por Computador). La informaci´on obtenida puede visualizarse posteriormente usando programas inform´aticos que la muestran usando mapas virtuales en dos o tres dimensiones. Para representar el mapa se hace uso de diversos modelos matem´aticos que emplean un sistema de referencia. La aparici´on de los sistemas georreferenciados ha supuesto un impulso de gran magnitud para la sociedad actual, ya sea de manera individual o colectiva. Las m´ultiples ventajas que ofrecen estos sistemas ha permitido un progreso evidente a varios niveles en cuanto a comodidad, facilidad y utilidad para much´ısimas personas y grupos. Ya sea desde poder observar zonas del planeta sin tener que estar all´ı f´ısicamente, o poder conocer c´omo llegar a un sitio gracias a las herramientas inform´aticas asociadas a estos sistemas; sirven como ejemplos de la potencialidad que han alcanzado estos sistemas. Por ejemplo, en el caso de Google, el 30 % de las b´usquedas realizadas en su buscador contienen un componente geogr´afico. Este porcentaje se ve incrementado hasta el 40 % en las b´usquedas realizadas desde dispositivos m´oviles, ya que la gente quiere saber lo que le rodea1. Esto permite a Google redirigir la b´usqueda hacia Google Maps, uno de sus sistemas de informaci´on geogr´afica. Como se indicaba anteriormente, para que se produjese este auge repentino de los sistemas georreferenciados, ´estos han debido de apoyarse en aplicaciones y programas software que han sabido explotar las caracter´ısticas de estos sistemas, facilitando su uso a los usuarios generalistas. Antes estas herramientas s´olo estaban al alcance de los usuarios especializados o profesionales, dependiendo del enfoque que se le hubiera dado a la aplicaci´on que usase el sistema georreferenciado. Las aplicaciones de georreferenciaci´on m´as conocidas en la actualidad, de cara al usuario 1http://www.scienceomega.com/article/1033/uncharted-territory-google-map-maker-reaches-uk-shores 1 2CAP´ ITULO 1. INTRODUCCI ´ ON general, son Google Maps y Google Earth. El primero es un sistema de dos dimensiones y el segundo de tres dimensiones. Un equivalente a Google Maps proviene de la mano de Microsoft con Bing Maps (aunque ya dispone tambi´en de versi´on en tres dimensiones). Las posibles alternativas para Google Earth ser´ıan Nasa World Wind o ArcGIS. Todos estas aplicaciones son propietarias, excepto la realizada por la NASA que es c´odigo abierto, y est´an pensadas para ser explotadas comercialmente promocionando servicios y negocios de terceros. Nasa World Wind est´a m´as enfocado a la investigaci´on debido a su motor de simulaci´on atmosf´erica y la posibilidad de visualizar otros planetas. En general, estas aplicaciones no est´an cerradas a su funci´on principal, sino que disponen de alg´un SDK o API que permite a los desarrolladores ampliar las caracter´ısticas del sistema. Entre ellas est´an manipular el contenido que se muestra en el mapa u ofrecer nuevo contenido al usuario en funci´on de sus gustos. Muchas aplicaciones del mercado actualmente est´an construidas siguiendo este esquema. 1.1. Motivaci´on y Objetivos En esta secci´on se describir´a la raz´on de realizar este proyecto y se resumir´an los objetivos que se pretenden alcanzar con la realizaci´on del mismo. 1.1.1. ´ Ambito El marco de trabajo designado para el proyecto es la gesti´on de rutas independientemente de su tipolog´ıa (terrestres, a´ereas o mar´ıtimas) u otro tipo de caracter´ısticas. El usuario de la aplicaci´on desarrollada tras la finalizaci´on de este proyecto podr´a crear rutas, modificarlas o eliminarlas. Para su visualizaci´on se optar´a por un entorno 3D que mostrar´a el globo terr´aqueo de manera realista. Adem´as, se tendr´an en cuenta aspectos de la denominada Web 2.0 para el desarrollo de la aplicaci´on del proyecto. La Web 2.0 nace con el objetivo de permitir que los usuarios de los sitios web tengan una mayor participaci´on en los contenidos de los mismos. Para ello fue necesario una evoluci´on en diversos aspectos tecnol´ogicos, como nuevas interfaces de usuario y tecnolog´ıas que permiten mostrar el nuevo contenido creado de manera din´amica. La Web 2.0 ha permitido crear aplicaciones Web, redes sociales, servicios de alojamiento de v´ıdeos, wikis, blogs o mashups entre otros ejemplos. Por lo tanto, se desarrollar´a una aplicaci´on Web 2.0 donde los usuarios podr´an crear y visualizar sus rutas. Asimismo, dichas rutas podr´an ser compartidas con otros usuarios a fin de que estos tambi´en dispongan de ellas, o que puedan verlas y comentarlas. Como se indic´o previamente, la tipolog´ıa de las rutas puede ser muy variada, como por ejemplo: las etapas de la Vuelta Ciclista a Espa˜na, la traves´ıa de una competici´on n´autica, el recorrido que sigui´o Col´on en su primer viaje a Am´erica o los caminos reales de Canarias. As´ı, con el objetivo de poder registrar y gestionar todos estos ejemplos, adem´as de facilitar su difusi´on, se requiere desarrollar un sistema inform´atico donde la aplicaci´on a implementar estar´a enmarcada dentro de la gesti´on de rutas. La aplicaci´on poseer´a un enfoque general, que ser´a v´alido para todos los ejemplos mencionados previamente. 1.1. MOTIVACI ´ ON Y OBJETIVOS 3 En este proyecto de fin de carrera se presentar´a de forma pormenorizada las diversas fases por las que debe pasar la construcci´on de una aplicaci´on software haciendo uso de t´ecnicas, herramientas y metodolog´ıas propias de la ingenier´ıa del software. 1.1.2. Objetivos Prop´osito principal: Realizar una aplicaci´on web que permita al usuario de la misma gestionar rutas y visualizarlas en 3D haciendo uso de elementos de la Web 2.0 como la interoperabilidad y la facilidad de uso. Objetivos principales del proyecto: 1. Gesti´on de rutas del usuario de manera eficiente. La aplicaci´on permitir´a al usuario crear rutas desde la propia representaci´on del terreno, as´ı como modificar y eliminar rutas de manera sencilla. 2. Gesti´on de sitios de inter´es del usuario de forma c´omoda. El usuario podr´a incorporar localizaciones de diversa ´ındole a su biblioteca de elementos para tener una mejor informaci´on de sus lugares predilectos. 3. Visualizaci´on de elementos 3D durante la visualizaci´on de las rutas. Cuando el usuario seleccione mostrar una ruta creada previamente a la que le ha a˜nadido un elemento 3D, ´este se visualizar´a en el navegador. 4. Administraci´on de usuarios. Permitir que m´ultiples usuarios puedan utilizar la aplicaci´on al mismo tiempo, adem´as de que los usuarios puedan modificar su informaci´on personal. Objetivos secundarios: 1. Compartici´on de rutas y otros elementos entre los usuarios de la aplicaci´on. Un usuario podr´a enviar a otro un elemento del globo (ruta, sitio de inter´es, etc.) propio para que el segundo tambi´en disponga de ´el. 2. Comunicaci´on entre s´ı de los usuarios de la aplicaci´on. Los usuarios de la aplicaci´on podr´an crear grupos donde podr´an intercambiar comentarios y opiniones sobre rutas u otros temas de inter´es. Con el fin de cumplir los objetivos descritos previamente, se realizar´a en la medida que sea posible, una aplicaci´on rigurosa de la metodolog´ıa PUD. Adem´as se realizar´a un estudio general del estado del arte con el fin de representarlo en la memoria del proyecto. Dicha memoria de proyecto se estructurar´a y documentar´a de manera conveniente para ilustrar el proyecto de manera fidedigna. 4CAP´ ITULO 1. INTRODUCCI ´ ON 1.2. Estructura del Documento A lo largo del contenido de este documento se describir´a todo el proceso necesario para acometer el desarrollo de la aplicaci´on resultante, desde las etapas iniciales de investigaci´on y an´alisis de requisitos hasta las etapas finales de dise˜no e implementaci´on. Para cada una de las etapas se especificar´an las tareas involucradas y a continuaci´on se desglosar´a el contenido correspondiente. El documento est´a dividido en seis cap´ıtulos centrados en el trabajo realizado en el proyecto y un conjunto de ap´endices encargados de la informaci´on m´as t´ecnica y espec´ıfica. El primer cap´ıtulo est´a dedicado a dar una introducci´on al tema de los sistemas georreferenciados y las aplicaciones asociadas a los mismos. Tambi´en se describir´a el problema a resolver = la gesti´on de rutas = y se indicar´an los objetivos que se buscan con la realizaci´on del proyecto. El segundo cap´ıtulo, centrado en el estado actual del tema, har´a un recorrido por los diferentes sistemas de informaci´on geogr´afica existentes a d´ıa de hoy, as´ı como se describir´an algunas de las aplicaciones m´as utilizadas en la gesti´on de rutas. Posteriormente, en el tercer cap´ıtulo se detallar´an los recursos empleados para llevar a cabo este proyecto. Se indicar´an los recursos hardware y software empleados a lo largo de la vida del mismo. El cap´ıtulo n´umero cuatro, centrado en la planificaci´on del proyecto, englobar´a el plan de trabajo y el presupuesto necesario para construir la aplicaci´on. Se expondr´a y se explicar´a la metodolog´ıa de desarrollo empleada en este proyecto para posteriormente realizar una descomposici´on temporal de las actividades que componen la planificaci´on. Por ´ultimo, se har´a una estimaci´on econ´omica del coste de desarrollar la aplicaci´on, teniendo en cuenta los diversos factores que hay que aglutinar para obtener el coste total. El cap´ıtulo cinco, el m´as largo de todos los que componen este documento, descompone todas las etapas del desarrollo del proyecto siguiendo la metodolog´ıa descrita en el cap´ıtulo anterior. Dar´a comienzo con los requisitos del sistema, se seguir´a con las fases de an´alisis y dise˜no y concluir´a con la fase de implementaci´on, que estar´a dedicado a comentar algunos aspectos concretos de la implementaci´on adoptada para dar forma a la aplicaci´on web construida. Tambi´en se har´a hincapi´e en algunos problemas que surgieron durante esta fase de desarrollo y c´omo se resolvieron. En cada etapa se mostrar´an los productos generados de acuerdo a la metodolog´ıa. Para finalizar, el ´ultimo cap´ıtulo contendr´a las conclusiones obtenidas tras finalizar este proyecto, ya sea en cuanto al trabajo realizado como a nivel personal. Adem´as, se har´a un inciso acerca de posibles l´ıneas de actuaci´on de cara a posibles ampliaciones en versiones posteriores de la aplicaci´on. El documento se cierra con los ap´endices t´ecnicos y con la bibliograf´ıa empleada en este proyecto a modo de ayuda para llevarlo a cabo. Cap´ıtulo 2 Estado actual del arte Dado el ´ambito en el que se encuadra este proyecto, este cap´ıtulo debe enfocarse desde dos partes bien diferenciadas. Por un lado se hablar´a de la georreferenciaci´on y de los Sistemas de Informaci´on Geogr´afica (SIG), y por el otro, de las aplicaciones de gesti´on de rutas existentes. En el primer caso se definir´a el concepto de georreferenciaci´on y se har´a un recorrido por los distintos programas y aplicaciones web que hacen uso de este concepto. Por ´ultimo, en el segundo apartado se listar´a un peque˜no abanico de las principales aplicaciones de gesti´on de rutas, realizando una breve sinopsis de cada una de ellas. 2.1. Georreferenciaci´on Por georreferenciaci´on se entiende definir la existencia de algo en un espacio f´ısico. Es decir, el establecimiento de su ubicaci´on en t´erminos de proyecciones cartogr´aficas o sistemas de coordenadas. El t´ermino se utiliza tanto la hora de establecer la relaci´on entre im´agenes r´aster o vectoriales y las coordenadas; o para determinar la localizaci´on espacial entre otras caracter´ısticas geogr´aficas. Como ejemplos se pueden indicar el establecimiento de la posici´on correcta de una fotograf´ıa a´erea en un mapa, encontrar las coordenadas geogr´aficas de una ciudad o la direcci´on de una calle. Este procedimiento es pues, imprescindible para el modelado de datos en el campo de los Sistemas de Informaci´on Geogr´afica (SIG) y otros m´etodos cartogr´aficos. Cuando los datos provienen de diferentes fuentes deben ser combinados y deben de disponer de un sistema de referencia com´un para ser usados posteriormente en una aplicaci´on SIG. Esto se logra mediante el uso de diversas t´ecnicas de georreferenciaci´on. La mayor´ıa de las tareas de georreferenciaci´on se llevan a cabo ya sea porque el usuario desea crear un nuevo mapa o porque quiere enlazar dos o m´as diferentes conjuntos de datos entre s´ı debido a que comparten a las mismas ubicaciones geogr´aficas. 2.1.1. Caracter´ısticas y utilidades La georreferenciaci´on es muy importante para la toma de im´agenes a´ereas y de sat´elite, por lo general en forma de im´agenes r´aster. Ello es muy ´util para la cartograf´ıa, ya que explica c´omo otros datos, como los anteriores puntos GPS, se refieren a las im´agenes. 5 12 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE Algoritmo 2.2 Estructura de un fichero Collada <?xml version=” 1 .0 ” encoding=” utf −8”?> <COLLADA xmlns=” ht tp: //www. c ol lad a . org /2005/11/COLLADASchema” version=” 1 . 4 . 1 ”> <asset>. . .</ as se t> <library animations>. . .</library animations> <library physics scenes>. . .</library physics scenes> <l i b r a r y l i g h t s>. . .</ l i b r a r y l i g h t s> <li br ary i ma ges>. . .</ li br ary i mag es> <library materials>. . .</ l i b r a r y m a t e r i a l s> <library effects>. . .</library effects> <l i b r a r y g e o m e t r i e s>. . .</ l i b r a r y g e o m e t r i e s> <l i b r a r y c o n t r o l l e r s>. . .</ l i b r a r y c o n t r o l l e r s> <library visual scenes>. . .</ l i b r a r y v i s u a l s c e n e s> <scene>. . .</ scene> </COLLADA> <source id=” v e r t i c e s s o u r c e ” name=” Ver ti ce s ”> <f l o a t a r r a y id=” values ” count=”6”>0.3 0.5 0.7 0.2 0.4 0.6 </ float array> <technique common> <ac ce sso r source=”#values ” count=”2” s t r i d e=”3”> <param name=”X” type=” f l o a t ”/> <param name=”Y” type=” f l o a t ”/> <param name=”Z” type=” f l o a t ”/> </accessor> </technique common> </source> <mesh> <sou rce id=” p o s i t i o n ”/> <source id=”normal”/> <source id=” textureCoords ”/> <v e r t i c e s id=” v ert s ”> <input semantic=”POSITION” sou rce=”#p o s i t i o n ”/> </vertices> <t r i a n g l e s count=”2” material=” Bricks ”> <input semantic=”VERTEX” source=”#ve rt s ” o f f s e t=”0”/> <input semantic=”NORMAL” source=”#normal” o f f s e t=”1”/> <input semantic=”TEXCOORD” source=”#textureCoords ” o f f s e t=”2” s et=”1 ” /> <p> 001321 002132 </p> </triangles> </mesh> 2.2.1.4. Google Maps Google Maps9es un servidor de aplicaciones de mapas en la web. Ofrece im´agenes de mapas desplazables, as´ı como fotograf´ıas por sat´elite del mundo e incluso la ruta entre diferentes ubicaciones o im´agenes a pie de calle con Google Street View. 9https://www.google.com/maps 2.2. SISTEMAS DE INFORMACI ´ ON GEOGR ´ AFICA 13 Google Maps ofrece la posibilidad de que cualquier usuario poseedor de una p´agina Web pueda integrarlo a la hora de hablar de cualquier tema donde exista una localizaci´on. Ello se consigue mediante la opci´on de Google Maps “enlace a esta p´agina”, se inserta una cadena larga de URL la cual contiene la latitud y la longitud del punto del mapa seleccionado. El usuario puede controlar el mapa para moverse a la ubicaci´on que desee, introducir una direcci´on, una intersecci´on o un ´area en general para buscar en el mapa. Al igual que otros servicios de mapas, Google Maps permite la creaci´on de pasos para llegar a alguna direcci´on. Esto permite al usuario crear una lista paso a paso para saber c´omo llegar a su destino, calculando el tiempo necesario y la distancia recorrida entre las ubicaciones. Tanto Google Maps como Google Earth ofrecen APIs para permitir a los desarrolladores realizar aplicaciones aprovechando la potencialidad de estas herramientas pudiendo ampliar sus funcionalidades. Figura 2.4: Google Maps 2.2.1.5. SkylineGlobe La plataforma de software SkylineGlobe proporciona a los usuarios un acceso r´apido a los datos geoespaciales 3D a trav´es de streaming. Est´a implementado en ASP.NET y usa bases de datos Oracle o MS SQL Server. Posee una arquitectura abierta y una API que ofrece a los desarrolladores un conjunto de funcionalidades para utilizar en una amplia gama de aplicaciones web 3D. El paquete web SkylineGlobe contiene la aplicaci´on principal SkylineGlobe 3D y todas las herramientas asociadas, como Administrador de Capas, herramienta de dibujo y una herramienta de medici´on. El paquete web SkylineGlobe tambi´en incluye las herramientas 14 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE avanzadas disponibles para los usuarios de SkylineGlobe Pro. Los usuarios del sitio web pueden navegar a trav´es de un entorno intuitivo virtual donde ver, analizar y anotar los datos en su contexto geogr´afico. Dispone de herramientas potentes capaces de publicar en l´ınea, promover la colaboraci´on y el intercambio de datos. Entre otras capacidades se encuentran el soporte de capas, potentes herramientas de dibujo, herramientas de an´alisis avanzadas y funcionalidad de b´usqueda. Figura 2.5: SkylineGlobe 2.2.2. Sistemas de c´odigo abierto A continuaci´on se expone una peque˜na selecci´on de sistemas de informaci´on geogr´afica de c´odigo abierto. La diferencia con los sistemas propietarios es que estos se pueden utilizar y modificar de forma gratuita para cualquier fin. 2.2.2.1. Capaware Capaware10 es una iniciativa del Gobierno de Canarias junto con la Universidad de Las Palmas de Gran Canaria (ULPGC) para su uso como visor 3D propio en temas de gesti´on de emergencias. Este proyecto ha sido liberado con el prop´osito de fomentar el desarrollo del software libre en Canarias. Capaware permite la interacci´on con terrenos virtuales 3D con precisi´on cartogr´afica y se distribuye bajo licencia GNU GPL. Permite acceder a informaci´on que cumpla las especificaciones del OGC. Est´a desarrollado en lenguaje de programaci´on C++, con lo que la suavidad en el movimiento es incre´ıblemente realista mejorando a otras implementaciones en lenguajes de m´as alto nivel pero m´as “lentos”. En la actualidad funciona en Microsoft Windows, aunque est´a planificada la capacidad de que sea multiplataforma (de momento hay una versi´on beta para Linux). Capaware utiliza OpenSceneGraph como motor gr´afico, otra iniciativa de software libre logrando tasas de frames por segundo elevadas. Capaware posee adem´as una 10http://www.capaware.org/ 2.2. SISTEMAS DE INFORMACI ´ ON GEOGR ´ AFICA 15 arquitectura de plugins que le permite crecer en funcionalidades a medida que se le a˜nadan nuevos plugins. Figura 2.6: Capaware 2.2.2.2. GeoPista GeoPista11 es un Sistema de Informaci´on Territorial para entidades locales en Espa˜na (diputaciones, mancomunidades, ayuntamientos, etc.) que facilita realizar la gesti´on municipal de forma georreferenciada y ofrecer servicios de informaci´on online a los ciudadanos utilizando la cartograf´ıa del municipio. GeoPista es una iniciativa del Ministerio de Industria, Turismo y Comercio que cuenta con el respaldo de importantes organismos a nivel nacional, como la FEMP -Federaci´on Espa˜nola de Municipios y Provincias-, el Ministerio de Administraciones P´ublicas, Catastro, INE -Instituto Nacional de Estad´ıstica-, IGN -Instituto Geogr´afico Nacional-, etc. Se basa en tecnolog´ıas SIG que permiten acceder y gestionar el alto volumen de datos asociado a la gesti´on municipal mediante una interfaz muy intuitiva: un mapa. GeoPista es un sistema multiplataforma, Open Source, libre, escalable y que cumple con los est´andares internacionales m´as relevantes relativos a la gesti´on de la informaci´on geogr´afica, como son la utilizaci´on de una base de datos compatible Simple Features, servidor de mapas compatible WMS, formato de intercambio GML, metadatos seg´un la norma ISO 19115, directiva europea Inspire, etc. GeoPista cubre las necesidades de las entidades locales de disponer de un software libre de gesti´on cartogr´afica que favorece la accesibilidad r´apida y efectiva a la informaci´on a un coste menor, aumentando por lo tanto la eficiencia municipal, tanto en aspectos relativos a la gesti´on interna como de cara a los servicios que se van a poder ofrecer a los ciudadanos. 11http://www.geopista.com/ 16 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE Figura 2.7: GeoPista 2.2.2.3. Grass GIS GRASS12 (acr´onimo ingl´es de Geographic Resources Analysis Support System) es un software SIG (Sistema de Informaci´on Geogr´afica) bajo licencia GPL (software libre). Puede soportar informaci´on tanto r´aster como vectorial y posee herramientas de procesado digital de im´agenes. En sus inicios, en 1982, el software fue desarrollado por el Cuerpo de Ingenieros del Laboratorio de Investigaci´on de Ingenier´ıa de la Construcci´on del Ej´ercito de los Estados Unidos (USA-CERL) como herramienta para la supervisi´on y gesti´on medioambiental de los territorios bajo administraci´on del Departamento de Defensa al no encontrar ning´un SIG en el mercado que cubriera estas necesidades. En 1991 se pone a disposici´on p´ublica a trav´es de Internet. Su popularidad se incrementa en universidades, empresas y agencias gubernamentales. En 1997, ante el anuncio de USA-CERL de que dejar´ıa de dar soporte al programa, la Universidad de Baylor se hace cargo de su desarrollo. A partir de esta fecha aumenta su aceptaci´on dentro del mundo acad´emico. El 26 de octubre de 1999 con la versi´on 5.0 se libera el c´odigo del programa bajo licencia GNU GPL. GRASS era uno de los primeros ocho proyectos de la Fundaci´on OSGeo. En 2008 finalmente se traslad´o toda la infraestructura de Grass bajo el mando de la fundaci´on. GRASS est´a disponible principalmente para plataformas *NIX (GNU/Linux), aunque existe un proyecto paralelo denominado winGRASS GIS que ha portado el programa a 12http://grass.itc.it/ 2.2. SISTEMAS DE INFORMACI ´ ON GEOGR ´ AFICA 17 versiones basadas en la tecnolog´ıa NT del Sistema Operativo Microsoft Windows (Windows NT, Windows 2000, Windows XP, etc.) usando las librer´ıas Cygwin. Todo ello con un c´odigo id´entico al de la versi´on UNIX y GNU/Linux. La versi´on 6.x ha mejorado sensiblemente la experiencia del usuario respecto a la versi´on 5.x, ya que ofrece un entorno gr´afico m´as amigable. Existen tutoriales y datos de ejemplo para la versi´on 6.x con los cuales es posible dar los primeros pasos con GRASS. Figura 2.8: Grass SIG 2.2.2.4. GvSIG y SEXTANTE gvSIG13 es un proyecto de desarrollo de Sistemas de Informaci´on Geogr´afica usando software libre, que incluye principalmente las aplicaciones gvSIG Desktop y gvSIG Mobile. La aplicaci´on gvSIG Desktop fue la primera que se desarroll´o dentro del proyecto gvSIG, por lo que tambi´en se conoce abreviadamente como gvSIG. Este proyecto fue desarrollado por el gobierno local de la Comunidad Valenciana (Generalidad Valenciana) de Espa˜na, con el objetivo inicial de realizar la gesti´on de datos geogr´aficos de esa colectividad; precisamente la sigla gvSIG abrevia la denominaci´on Generalitat Valenciana Sistema de Informaci´on Geogr´afica. gvSIG Desktop es un programa inform´atico para el manejo de informaci´on geogr´afica con precisi´on cartogr´afica que se distribuye bajo licencia GNU GPL v2. Permite acceder a informaci´on vectorial y rasterizada as´ı como a servidores de mapas que cumplan la especificaciones del OGC. Esta es una de las principales caracter´ısticas de gvSIG respecto a otros Sistema de Informaci´on Geogr´afica, la importante implementaci´on de servicios OGC: WMS (Web Map Service), WFS (Web Feature Service), WCS (Web Coverage Service), Servicio de Cat´alogo y Servicio de Nomencl´ator. Est´a desarrollado en el lenguaje de programaci´on Java y funciona con los sistemas operativos Microsoft Windows, Linux y Mac OS X. Utiliza bibliotecas est´andar de SIG reco13http://www.gvsig.org/ 18 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE nocidas, como Geotools o Java Topology Suite (JTS). Asimismo, gvSIG posee un lenguaje de scripting basado en Jython y tambi´en se pueden crear extensiones en Java utilizando las clases de gvSIG. Entre los formatos gr´aficos de fichero m´as habituales cuenta entre otros con acceso a formatos vectoriales GML, SHP, DXF, DWG, DGN, KML y formatos de imagen rasterizada como MrSID, GeoTIFF, ENVI o ECW. Iniciado en el a˜no 2004, es un proyecto de desarrollo inform´atico impulsado inicialmente por la Conselleria de Infraestructuras y Transportes de la Generalidad Valenciana y la Uni´on Europea mediante el Fondo Europeo de Desarrollo Regional (FEDER). Actualmente est´a impulsado por un conjunto de entidades (empresas, administraciones, universidades) englobadas bajo la Asociaci´on gvSIG. Figura 2.9: gvSIG El Sistema EXTreme˜no de AN´alisis TErritorial (SEXTANTE14) es una biblioteca de algoritmos de an´alisis espacial de c´odigo libre disponible para varios softwares de Sistemas de Informaci´on Geogr´afica. Su objetivo principal es crear una plataforma que facilite tanto el uso como la implementaci´on de estos algoritmos. Actualmente SEXTANTE contiene m´as de 240 herramientas de an´alisis geogr´afico. En un principio SEXTANTE estaba basado en el SIG SAGA, para posteriormente pasarse a gvSIG. Inicialmente se centraba principalmente en el modelado y an´alisis de la informaci´on mediante im´agenes r´aster aunque en la actualidad son m´as de 240 extensiones tanto r´aster como vectorial. Tras el desarrollo de una gran colecci´on de algoritmos de an´alisis geoespacial desarrollados para gvSIG, los desarrolladores entendieron que muchos otros proyectos requer´ıan de an´alisis geoespacial, pero no exist´ıa una biblioteca que pudiera proporcionarles los algorit14http://www.sextantegis.com/ 2.2. SISTEMAS DE INFORMACI ´ ON GEOGR ´ AFICA 19 mos correspondientes. Ante este hecho, en el a˜no 2008 tomaron la decisi´on de independizar SEXTANTE de cualquier software SIG, creando una biblioteca de tal manera que otros programas diferentes de procesamiento de informaci´on geogr´afica pudieran hacer uso de sus algoritmos de forma igual de sencilla que se ven´ıa haciendo hasta ahora. A partir de la versi´on 0.6 SEXTANTE abandon´o la licencia GNU GPL y pas´o a utilizar una licencia MIT. La raz´on principal del cambio fue evitar posibles problemas de licencia de software que no permitiesen integrar SEXTANTE en otras aplicaciones. Figura 2.10: SEXTANTE 2.2.2.5. Marble Marble15 es una aplicaci´on geogr´afica a modo de globo virtual, desarrollada por KDE y licenciado bajo los t´erminos de la licencia GNU LGPL 2, siendo software libre. Se puede ejecutar en cualquier PC que tenga un sistema operativo compatible con Qt 4, tales como Linux, Windows o Mac OS X, entre otros. La propuesta de Marble es ser flexible. Por ello puede funcionar sin necesidad de aceleraci´on por hardware, comenzando r´apidamente y viene ya con unos m´ınimos datos (5-10 MB) que lo hacen funcional sin necesidad de conexi´on a Internet. Se puede usar con OpenGL para dibujar los mapas y ´estos se pueden obtener de fuentes online como OpenStreetMap. Marble puede asimismo emplear los archivos KML que actualmente usan Google Earth /Google Maps. Actualmente permite escoger entre mapas de la Tierra, Marte, Venus y mapas hist´oricos. 15http://marble-globe.org/ 20 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE Figura 2.11: Marble 2.2.2.6. NASA World Wind El NASA World Wind16 es un programa que act´ua como un globo terr´aqueo virtual, o globo virtual desarrollado por la NASA para ser usado en ordenadores personales con Microsoft Windows, MacOS y Linux. Superpone im´agenes de sat´elites de la NASA y fotograf´ıas a´ereas del United States Geological Survey (USGS) sobre modelos tridimensionales de la Tierra, y en las ´ultimas versiones, Marte y la Luna. El usuario puede interactuar con el planeta seleccionado, rot´andolo y ampliando zonas. Adem´as se pueden superponer top´onimos y fronteras, entre otros datos, a las im´agenes. El programa tambi´en contiene un m´odulo para visualizar im´agenes de otras fuentes en Internet que usen el protocolo del Open Geospatial Consortium Web Map Service. Adicionalmente, existen multitud de extensiones para World Wind que aumentan su funcionalidad, como por ejemplo, poder medir distancias u obtener datos de posici´on desde un GPS, gracias a que est´a desarrollado en Java y ha evolucionado hasta tener un SDK que permite ampliar su funcionalidad con trabajos de terceros escritos en otros lenguajes de programaci´on. 16http://worldwind.arc.nasa.gov/ 2.2. SISTEMAS DE INFORMACI ´ ON GEOGR ´ AFICA 21 Figura 2.12: NASA World Wind 2.2.2.7. OpenJUMP OpenJUMP17 es una aplicaci´on SIG modular de c´odigo libre que permite la consulta y la creaci´on o modificaci´on de datos geogr´aficos vectoriales almacenados bajo distintos formatos incluidos como GML, DXF o ESRI SHP. El programa permite tambi´en la explotaci´on de servicios WMS. Inicialmente su nombre era JUMP. Este Sistema de Informaci´on Geogr´afica est´a programado en Java y es multiplataforma. Su arquitectura modular facilita la creaci´on de numeroso plugins que a˜naden funcionalidades espec´ıficas tales como: comprobaci´on de topolog´ıa, generaci´on de Modelos Digitales del Terreno, lectura de formatos r´aster, m´etodos de interpolaci´on (kriging, triangulaci´on de Delaunay, pol´ıgonos de Voronoi), tracing, creaci´on de metadatos, etc. JUMP fue desarrollada inicialmente en 2002 por la empresa Vivid Solutions a ra´ız de un concurso p´ublico convocado por el Ministerio de Recursos Naturales de la Columbia Brit´anica (Canad´a). Actualmente el desarrollo regular de este SIG por parte de la empresa que lo cre´o es discontinuo. Debido a ello y al constante crecimiento de la comunidad de usuarios en torno a JUMP surgieron diferentes grupos independientes de desarrolladores que han ido ampliando las capacidades de este Sistema de Informaci´on Geogr´afica lo que 17http://openjump.org/ 28 CAP´ ITULO 2. ESTADO ACTUAL DEL ARTE Cap´ıtulo 3 Recursos necesarios En este cap´ıtulo se indicar´an los recursos hardware y software que han sido necesarios para la realizaci´on de este proyecto. Para cada uno de ellos se realizar´a una descripci´on somera donde se indicar´a el porqu´e de su inclusi´on en este trabajo, as´ı como sus principales caracter´ısticas. 3.1. Recursos software Los principales recursos software utilizados para la consecuci´on de este proyecto son: Microsoft Windows Ha sido el sistema operativo en el que se ha desarrollado el proyecto. Concretamente las versiones Vista y 7. Apache Es un servidor web HTTP de c´odigo abierto y multiplataforma que implementa el protocolo HTTP 1.1. Est´a bastante extendido en Internet debido a su soporte y a la cantidad de m´odulos disponibles que presenta. MySQL Es el SGBD (Sistema Gestor de Bases de Datos) encargado de otorgar la capa de persistencia a la aplicaci´on. Su amplia difusi´on y su soporte para funciones SIG1 siguiendo la especificaci´on OpenGIS2lo hacen adecuado para este proyecto. Tambi´en posee una estrecha colaboraci´on con el lenguaje PHP facilitando el desarrollo de aplicaciones web. Mercury Es un servidor de correo compatible con los est´andares actuales en cuanto a correo electr´onico, tales como SMTP, POP3 e IMAP. Es altamente modular y no es excesivamente complejo de configurar. StarUML Es una herramienta CASE (Computer-aided Software Engineering) para UML (Unified Modeling Language). Se integra f´acilmente con la metodolog´ıa PUD permitiendo un desarrollo m´as ´agil e integrado a lo largo de todas las fases del desarrollo del proyecto. 1http://www.opengeospatial.org/standards/sfs 2http://www.opengeospatial.org/standards 29 30 CAP´ ITULO 3. RECURSOS NECESARIOS Complemento Google Earth El complemento de Google Earth permite al usuario visualizar y explorar datos geogr´aficos sobre un globo terr´aqueo en 3D desde un navegador web. Proporciona herramientas que permiten ampliar su funcionalidad b´asica. CakePHP Es un framework para el desarrollo de aplicaciones web en PHP. Es c´odigo abierto y se basa fundamentalmente en el patr´on de dise˜no MVC. Permite que las aplicaciones se puedan traducir de manera sencilla, proporciona acceso a bases de datos y proporciona caching, validaci´on y autentificaci´on entre otras caracter´ısticas. Adem´as posee una baja barrera de entrada para empezar a trabajar con ´el. MochaUI Es una biblioteca en JavaScript dise˜nada para crear interfaces de usuario en aplicaciones web basada en el framework de JavaScript MooTools. Proporciona herramientas gr´aficas como ventanas, paneles y listas para crear aplicaciones que tengan un “look & feel” parecido al de aplicaciones de escritorio. JQuery Es una biblioteca en JavaScript creada para simplificar la realizaci´on de ciertas operaciones en p´aginas web. Entre sus funcionalidades se encuentran: operar con el ´arbol DOM del documento web, crear animaciones, manejar eventos y facilitar el desarrollo de aplicaciones AJAX. Opera DragonFly Depurador de c´odigo JavaScript integrado dentro del propio navegador web Opera. Permite visualizar la estructura del documento web, monitorizar el tr´afico de red; seleccionar un fichero JavaScript y poder ejecutarlo paso a paso, viendo los valores de las variables, entre otras caracter´ısticas. 3.1.1. Edici´on y documentaci´on Komodo Edit Es un editor de texto gratuito especializado en la escritura de c´odigo para diferentes lenguajes de programaci´on. Entre ellos est´an HTML, CSS, JavaScript y PHP permitiendo el desarrollo de la aplicaci´on desde una sola herramienta pudiendo trabajar en paralelo con varios lenguajes al mismo tiempo. Posee un explorador de ficheros y permite pesta˜nas simplificando el poder trabajar con m´ultiples archivos al mismo tiempo. Tambi´en permite autocompletado y la posibilidad de usar snippets de c´odigo. Notepad++ Es otro editor de texto con herramientas espec´ıficas para la escritura de c´odigo. Se us´o como editor secundario para modificaciones peque˜nas y puntuales. Tambi´en la opci´on de poder buscar texto en varios ficheros al mismo tiempo fue de utilidad en ocasiones. L YXEs el procesador de textos utilizado para la redacci´on de esta memoria. Es un editor visual para el lenguaje de edici´on Latex. ´ Este hace que el usuario se centre en el contenido del documento, no en la apariencia final del mismo, tarea encargada para el sistema Latex, que maqueta el documento para dar el resultado final. 3.1. RECURSOS SOFTWARE 31 Cuadro 3.1: Herramientas Software Producto Descripci´on Evoluci´on Costes Est´andares Adaptaci´on Windows Sistema Operativo En Desarrollo <100 ¿ - Media Apache Servidor Web En Desarrollo 0 HTTP Sencilla MySQL Sistema Gestor de Bases de Datos En Desarrollo 0 SQL Sencilla Mercury Servidor de Correo En Desarrollo 0 / 75-695 ¿ SMTP Media StarUML Herramienta CASE Parado 0 UML Media CakePHP Framework Web En Desarrollo 0 PHP Sencilla MySQL Workbench Herramienta para crear Bases de Datos En Desarrollo 0 SQL Sencilla MochaUI Librer´ıa UI Parado 0 JavaScript Media JQuery Librer´ıa UI En Desarrollo 0 JavaScript Media Komodo Edit Editor de C´odigo Web En Desarrollo 0 HTML, JavaScript CSS Sencilla Lyx Editor de Latex En Desarrollo 0 Latex Media 3.1.2. Lenguajes empleados para el desarrollo HTML HyperText Markup Language (Lenguaje de Marcado de HiperTexto). Es un lenguaje de marcado utilizado para la realizaci´on de p´aginas web y que ´estas se muestren en un navegador. Permite estructurar el contenido del documento web, el formateado de textos, as´ı como incluir im´agenes y otros tipos de objetos. CSS Cascading Style Sheets (Hojas de Estilo en Cascada). Es un lenguaje creado para describir la sem´antica de la presentaci´on del documento web. En la pr´actica se utiliza para dar formato a los elementos del documento web, dejando la estructura para el HTML o XHTML. En general, se trata de uno o varios ficheros que indican mediante una serie de reglas el formato de los diversos elementos que componen el documento web. JavaScript Es un lenguaje interpretado que implementan los navegadores web y que permite realizar un cierto conjunto de operaciones en las p´aginas web desde el lado del cliente tales como: interacci´on con el usuario, control del navegador, comunicaci´on as´ıncrona y posibilidad de modificar el documento web una vez mostrado. Se define por ser basado en prototipos, imperativo, d´ebilmente tipado y din´amico. 32 CAP´ ITULO 3. RECURSOS NECESARIOS PHP PHP Hypertext Pre-processor (PHP Preprocesador de Hipertexto). Es un lenguaje de programaci´on de prop´osito general que trabaja en el lado del servidor. Fue dise˜nado para el desarrollo web de contenido din´amico. Se puede incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que procese los datos. El c´odigo es interpretado por un servidor web con un m´odulo de procesador de PHP que genera la p´agina Web resultante. 3.2. Recursos hardware El proyecto se ha realizado con un ordenador port´atil Dell XPS M1530 con las siguientes caracter´ısticas: Procesador Intel Core 2 Duo T8100 a 2,1 Ghz. Memoria RAM 4 GB DDR2 Tarjeta Gr´afica NVIDIA GeForce 8600M GT Pantalla de 15,4 pulgadas Conexi´on a Internet v´ıa Wi-Fi Adem´as se utiliz´o almacenamiento secundario (en forma de discos duros externos) para copias de seguridad, adem´as de servicios a trav´es de Internet que tambi´en permit´ıan la realizaci´on de copias de respaldo para una mayor protecci´on ante imprevistos. Para poder ejecutar la aplicaci´on realizada los requisitos necesarios son los siguientes: Hardware Cliente  Sistema operativo: Windows XP, Windows Vista o Windows 7 / Apple Mac OS X 10.5 ´o superior (Intel)  CPU: Pentium 4, 2,4 GHz o versiones posteriores o AMD 2400 xp o versiones posteriores  Memoria del sistema (RAM): 512 MB  Disco duro: 2 GB de espacio libre  Velocidad de red: 768 Kbps  Tarjeta gr´afica: DirectX9 compatible con 3D con 256 MB de RAM de v´ıdeo  Pantalla: 1.280 x 1.024 p´ıxeles en color real de 32 bits Hardware Servidor  Procesador: Pentium IV o compatible  Memoria RAM: 1 Gb  Disco Duro: 2 Gb libres  Placa de Red: Ethernet compatible 3.2. RECURSOS HARDWARE 33  Otros: Tarjeta Gr´afica, Monitor recomendable Configuraci´on de la Red  Red LAN que soporte TCP/IP (en general, Internet) 34 CAP´ ITULO 3. RECURSOS NECESARIOS Cap´ıtulo 4 Planificaci´on del proyecto En este cap´ıtulo se describir´a la metodolog´ıa aplicada para la realizaci´on de este proyecto, se desglosar´an las tareas a realizar y se elaborar´a una estimaci´on temporal del desarrollo del mismo. Tambi´en se proceder´a a hacer una estimaci´on de los costes de mano de obra y material necesarios para realizar este trabajo. 4.1. Metodolog´ıa de desarrollo Para la realizaci´on del proyecto se ha optado por la metodolog´ıa PUD (Proceso Unificado de Desarrollo de Software). El proceso de desarrollo de software puede definirse como el conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Sin embargo, PUD no es una ´unica metodolog´ıa, es un marco gen´erico que puede especializarse para una variedad de tipos de sistemas, diferentes ´areas de aplicaci´on, tipos de organizaciones, niveles de aptitud y diferentes tama˜nos de proyectos. El Proceso Unificado de Software est´a basado en componentes, haciendo que el software resultante est´e formado por componentes software interconectados a trav´es de interfaces bien definidas. El Proceso Unificado de Desarrollo utiliza el Lenguaje Unificado de Modelado (UML) para definir y especificar las diversas partes de un sistema. Es un lenguaje con un fuerte bagaje debido a su amplio uso. De hecho, en esta metodolog´ıa, el uso de UML est´a entroncado a lo largo de todo el proceso. Esta metodolog´ıa est´a encuadrada dentro de un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, adem´as de ser iterativo e incremental. La utilizaci´on de esta metodolog´ıa permite realizar software de calidad cumpliendo con los objetivos propuestos. El ciclo de vida del proceso unificado consta de cuatro fases: 1. Inicio 2. Elaboraci´on 3. Construcci´on 4. Transici´on 35 36 CAP´ ITULO 4. PLANIFICACI ´ ON DEL PROYECTO Cada fase se subdivide en iteraciones. En cada iteraci´on se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos. Las m´as importantes son: Requisitos, An´alisis, Dise˜no, Codificaci´on, y Prueba. Estas disciplinas se realizan para cada una de las cuatro fases. Cada ciclo constituye una versi´on del sistema. 4.1.1. Dirigido por casos de uso Un sistema software ve la luz para dar servicio a sus usuarios. Por lo tanto, para construir un sistema con ´exito debemos conocer lo que sus futuros usuarios necesitan y desean. El t´ermino usuario no s´olo referencia a usuarios humanos sino tambi´en a otros sistemas, es decir, todo aquello que interact´ue con el sistema que estamos desarrollando. A esta interacci´on la llamamos caso de uso. Un caso de uso es un grafo de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema. Una especificaci´on funcional define lo que debe hacer el sistema y al a˜nadir los casos de uso nos fuerza a pensar en t´erminos para el usuario. Sin embargo, los casos de uso no son s´olo una herramienta para especificar los requisitos de un sistema. Tambi´en gu´ıan su dise˜no, implementaci´on y prueba; esto es, gu´ıan el proceso de desarrollo. Bas´andose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de dise˜no e implementaci´on que llevan a cabo los casos de uso. Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. Los ingenieros de prueba testean la implementaci´on para garantizar que los componentes del modelo de implementaci´on implementan correctamente los casos de uso. De este modo, los casos de uso no s´olo inician el proceso de desarrollo sino que le proporcionan un hilo conductor. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo, es decir, avanza a trav´es de una serie de flujos de trabajo que parten de los caso de uso. Los casos de uso se especifican, dise˜nan, y los casos de uso finales son las fuentes a partir de la cual los ingenieros de prueba construyen sus casos de prueba. Aunque es cierto que los casos de uso gu´ıan el proceso, no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso gu´ıan la arquitectura del sistema y ´este influye en la selecci´on de los casos de uso. Por lo cual, tanto la arquitectura del sistema como los casos de uso maduran seg´un avanza el ciclo de desarrollo. 4.1.2. Centrado en la arquitectura La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcci´on. El concepto de arquitectura software incluye los aspectos est´aticos y din´amicos m´as significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las que perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambi´en se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcci´on reutilizables de que se dispone, 4.1. METODOLOG´ IA DE DESARROLLO 37 consideraciones de implantaci´on, sistemas heredados, y requisitos no funcionales. La arquitectura es una vista del dise˜no completo con las caracter´ısticas m´as importantes resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende en parte de una valoraci´on, que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de las personas que se hayan responsabilizado de su creaci´on. No obstante, el proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidad de adaptaci´on al cambio y la reutilizaci´on. Debe existir interacci´on entre los casos de uso y la arquitectura. Por un lado, los casos de uso deben encajar en la arquitectura cuando se lleva a cabo y por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro. En realidad, tanto la arquitectura como los casos de uso deben evolucionar en paralelo. Por lo tanto, los arquitectos modelan el sistema para darle forma. Es esta forma, la arquitectura, la que debe dise˜narse para permitir que el sistema evolucione, no s´olo en su desarrollo inicial, sino tambi´en a lo largo de futuras generaciones. Este dise˜no se esboza a partir de la comprensi´on general de las operaciones b´asicas del sistema, es decir, se debe trabajar sobre los casos de uso claves del sistema. Estos casos de uso clave pueden suponer solamente entre el cinco y el diez por ciento de todos los casos de uso, pero son los significativos, los que constituyen las funciones fundamentales del sistema. 4.1.3. Iterativo e incremental El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses y hasta posiblemente un a˜no o m´as. Es pr´actico dividir el trabajo en partes m´as peque˜nas o miniproyectos. Cada miniproyecto es una iteraci´on que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad m´axima, las iteraciones deben estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada. Es por esto por lo que son miniproyectos. Los desarrolladores basan la selecci´on de lo que se implementar´a en una iteraci´on en dos factores. En primer lugar, la iteraci´on trata de un grupo de casos de uso que juntos ampl´ıan la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteraci´on trata los riesgos m´as importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ´ultima iteraci´on. Al ser miniproyectos, comienzan con los casos de uso y contin´uan a trav´es del trabajo de desarrollo subsiguiente –an´alisis, dise˜no, implementaci´on y prueba-, que termina convirtiendo en c´odigo ejecutable los casos de uso que se desarrollaban en la iteraci´on. Por supuesto, un incremento no necesariamente es aditivo. Especialmente en las primeras fases del ciclo de vida, los desarrolladores pueden tener que reemplazar un dise˜no superficial por uno m´as detallado o sofisticado. En fases posteriores, los incrementos son t´ıpicamente aditivos. En cada iteraci´on, los desarrolladores identifican y especifican los casos de uso relevantes, crean un dise˜no utilizando la arquitectura seleccionada como gu´ıa, implementan el dise˜no mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una iteraci´on cumple con sus objetivos, el desarrollo contin´ua con la siguiente iteraci´on. Cuando una iteraci´on no cumple sus objetivos, 44 CAP´ ITULO 4. PLANIFICACI ´ ON DEL PROYECTO Cuadro 4.4: Desarrollo del PFC DESARROLLO DEL PFC Horas M´odulos de la aplicaci´on: Gesti´on de Usuarios Gesti´on de Elementos del Globo Aspectos Web 2.0 Interfaz de la aplicaci´on web Inicio Requerimientos 25 An´alisis 15 Dise˜no 5 Codificaci´on 5 Prueba 5 SUBTOTAL 55 Elaboraci´on Requerimientos 50 An´alisis 40 Dise˜no 50 Codificaci´on 50 Prueba 10 SUBTOTAL 200 Construcci´on Requerimientos 20 An´alisis 40 Dise˜no 60 Codificaci´on 130 Prueba 50 SUBTOTAL 300 Transici´on Requerimientos 0 An´alisis 5 Dise˜no 10 Codificaci´on 10 Prueba 20 SUBTOTAL 45 TOTAL 600 4.2. PLANIFICACI ´ ON Y TEMPORIZACI ´ ON 45 Cuadro 4.5: Validaci´on y publicidad VALIDACI´ ON Y PUBLICIDAD DEL PFC Horas Definici´on de los test de validaci´on 14 Construcci´on de los test de validaci´on 3 Aplicaci´on de los test de validaci´on 5 An´alisis de resultados de los test de validaci´on 4 Generaci´on de documentaci´on de los test de validaci´on 2 Actualizar la bibliograf´ıa de los test de validaci´on 1 Consulta al tutor sobre los test de validaci´on 2 Confecci´on de manuales de usuario 15 TOTAL 46 Cuadro 4.6: Presentaci´on y defensa PRESENTACI´ ON Y DEFENSA DEL PFC Horas Memoria del PFC 53 Supervisi´on del tutor sobre la memoria 4 Realizaci´on de copias de la memoria encuadernadas 1 Preparaci´on de la presentaci´on oral del PFC 10 Defensa oral del PFC 1 TOTAL 69 Cuadro 4.7: Resumen de la planificaci´on Concepto Horas GESTI´ ON DEL PFC 21 REALIZACI´ ON Y TRAMITACI´ ON DE LA PROPUESTA DEL PFC 17 CUESTIONES PREVIAS A LA REALIZACI´ ON DEL PFC 47 DESARROLLO DEL PFC 600 VALIDACI´ ON Y PUBLICIDAD DEL PFC 46 PRESENTACI´ ON Y DEFENSA DEL PFC 69 TOTAL 800 46 CAP´ ITULO 4. PLANIFICACI ´ ON DEL PROYECTO A continuaci´on se muestra la planificaci´on temporal por secciones del proyecto: Figura 4.2: Planificaci´on temporal La planificaci´on temporal desglosada queda como sigue: 4.3. PRESUPUESTO 47 Figura 4.3: Planificaci´on desglosada 4.3. Presupuesto El presupuesto necesario para la realizaci´on de este proyecto se descompone en cuatro partes. Para cada una se detalla por separado el coste de la misma y al final se expone el coste completo de la realizaci´on del proyecto. 4.3.1. Costes de personal Para calcular los costes laborales lo primero ser´ıa determinar el coste por hora trabajada. En este caso se han determinado 16 euros cada hora trabajada por el alumno (suponiendo unos ingresos de 1280 euros brutos mensuales) y 30 euros cada hora trabajada por el profesor (2504 euros brutos mensuales). El reparto de horas dedicadas al proyecto por los distintos participantes quedar´ıa de la siguiente manera: Tutor 15 horas Alumno 800 horas 48 CAP´ ITULO 4. PLANIFICACI ´ ON DEL PROYECTO Teniendo en cuenta los datos anteriores, tendr´ıamos los siguientes costes laborales por participante: Total Tutor: 15 horas * 30 euros = 450 euros Total Alumno: 800 horas * 16 euros = 12.800 euros Cuadro 4.8: Costes de personal Concepto Cantidad Precio por Unidad Precio Total Coste Laboral Tutor 15 30 450 Coste Laboral Alumno 800 16 12.800 4.3.2. Costes inventariables El material necesario para el proyecto ser´a de un ordenador port´atil y un disco duro externo. El software necesario para la elaboraci´on del proyecto no supondr´a ning´un coste debido al uso de software libre y licencias de estudiante. Para el port´atil su coste es de 1.000 ¿ y para el disco duro 120 ¿ . El coste total asciende a 1.120 ¿ . Teniendo en cuenta que el tiempo de amortizaci´on es de 48 meses, y que el equipo se usar´a durante 7 meses, el coste para ese periodo es de 1.120 * 7 / 48 = 163,33 ¿ . Cuadro 4.9: Costes inventariables Concepto Cantidad Precio por Unidad Precio Total Ordenador Port´atil 1 1.000 1000 Disco Duro Externo 1 120 120 4.3.3. Costes fungibles Para la entrega del proyecto es necesario realizar una copia de la memoria del mismo, debidamente encuadernada, la cual habr´a que entregar en la administraci´on. Adem´as, hay que a˜nadir dos copias digitales de la misma en CD que tambi´en han de entregarse. Por lo tanto el coste es: Tomo: 0.04 euros/p´agina * 2 (ambas caras) * 278 p´aginas + 6 euros (encuadernaci´on) = 28,24 euros CDs: 0,30 euros * 2 discos = 0,60 euros Cuadro 4.10: Costes fungibles Concepto Cantidad Precio por Unidad Precio Total Tomo de la Memoria 1 28,24 28,24 CD 2 0,30 0,60 4.3. PRESUPUESTO 49 4.3.4. Costes indirectos Son aquellos que no dependen directamente de la realizaci´on del proyecto, esto es: trabajo del personal de la administraci´on, gastos en los servicios de alumbrado y de red del edificio de la EII, etc. Estos costes son dif´ıciles de calcular por su complejidad y variedad, as´ı que para simplificar se ha presupuestado un 5 % del total del presupuesto. (Coste de personal + Costes inventariables + Costes fungibles) * 5 %= 14.398,84 * 5 % = 719,94 ¿ Cuadro 4.11: Costes indirectos Concepto Total Porcentaje Precio Total C.P. + C.I. + C.F. 14.398,84 5 % 719,94 4.3.5. Total del presupuesto A continuaci´on se muestra una tabla resumen con los costes asociados al proyecto: Cuadro 4.12: Coste total Concepto Coste Costes laborales del alumno 12.800 ¿ Costes laborales del tutor 450 ¿ Costes materiales 1.120 ¿ Costes de documentaci´on 28,84 ¿ Costes indirectos 719,94 ¿ PRESUPUESTO TOTAL 15.118,78 ¿ El presupuesto total del proyecto es de 15.118,78 euros. 50 CAP´ ITULO 4. PLANIFICACI ´ ON DEL PROYECTO Cap´ıtulo 5 Desarrollo del proyecto En este cap´ıtulo se ilustrar´an varios de los diferentes artefactos que se han realizado hasta llegar a obtener el producto final, desde la recopilaci´on de requisitos hasta la etapa de dise˜no del software. La primera parte del desarrollo del proyecto consistir´a en identificar los requisitos del sistema y los requisitos del software. Este estudio servir´a como base para definir y delimitar el ´ambito del proyecto, y para utilizarlo como gu´ıa de desarrollo. Las herramientas que se utilizar´an ser´an el modelo del dominio, la lista de caracter´ısticas y los casos de uso. La segunda permite definir cualquier caracter´ıstica que fuese deseable incluir en la aplicaci´on y la ´ultima perfila de forma algo m´as concreta las funciones que se esperan del mismo. 5.1. Requisitos del sistema En este apartado se describir´an dos artefactos muy importantes a la hora de establecer el ´ambito en el que se mover´a la aplicaci´on: el modelo del dominio y la lista de caracter´ısticas. Tambi´en ayudan a los desarrolladores a comprender el contexto del sistema, adem´as de poder recopilar requisitos funcionales y no funcionales. 5.1.1. Modelo del dominio 5.1.1.1. Introducci´on Un modelo del dominio captura los tipos m´as importantes de objetos en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos del dominio o clases (para emplear una terminolog´ıa m´as precisa) pueden obtenerse de una especificaci´on de requisitos o mediante una entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas t´ıpicas: Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas y contratos. Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviaci´on enemiga, misiles y trayectorias. 51 52 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Sucesos que ocurrir´an o han ocurrido, como la llegada de un avi´on, su salida y la hora de la comida. El modelo del dominio se describe mediante diagramas de UML (especialmente diagramas de clases). Estos diagramas muestran a los clientes, usuarios, revisores y a otros desarrolladores las clases del dominio y c´omo se relacionan unas con otras mediante asociaciones. 5.1.1.2. Desarrollo de un modelo del dominio El modelado del dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para formar un equipo eficaz, estas reuniones deber´ıan incluir tanto a expertos del dominio como a gente con experiencia en modelado. El objetivo del modelado del dominio es comprender y describir las clases m´as importantes dentro del contexto del sistema. Los dominios de tama˜no moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios m´as grandes pueden requerir muchas m´as. Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de t´erminos; de otra manera, el modelo del dominio se har´ıa demasiado grande y requerir´ıa m´as esfuerzo del necesario para esta parte del proceso. Algunas veces, como en los dominios de negocio muy peque˜nos, no es necesario desarrollar un modelo de objetos para el dominio; en su lugar puede ser suficiente un glosario de t´erminos. El glosario y el modelo del dominio ayudan a los usuarios, clientes, desarrolladores y otros interesados a utilizar un vocabulario com´un. La terminolog´ıa com´un es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusi´on, el proceso de ingenier´ıa se hace dif´ıcil, si no imposible. Para construir un sistema software de cualquier tama˜no, los ingenieros de hoy en d´ıa deben “fundir” el lenguaje de todos los participantes en uno solo consistente. Por ´ultimo, es necesaria una llamada de atenci´on sobre el modelado del dominio. Puede ser bastante f´acil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo, algunos objetos del dominio podr´ıan tener una representaci´on inmediata en el sistema, y algunos analistas del dominio podr´ıan a su vez caer en la trampa de especificar los detalles relativos a esa representaci´on. En casos como ´estos, es muy importante recordar que el objetivo del modelado del dominio es contribuir a la comprensi´on del contexto del sistema, y por lo tanto tambi´en contribuir a la comprensi´on de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el modelado del dominio deber´ıa contribuir a una comprensi´on del problema que se supone que el sistema resuelve en relaci´on a su contexto. El modo interno por el cual el sistema resuelve este problema se tratar´a en los flujos de trabajo de an´alisis, dise˜no, e implementaci´on. 5.1. REQUISITOS DEL SISTEMA 53 Uso del modelo del dominio Las clases del dominio y el glosario de t´erminos se utilizan en el desarrollo de los modelos de casos de uso y de an´alisis. Se utilizan: Al describir los casos de uso y al dise˜nar la interfaz de usuario. Para sugerir clases internas al sistema en desarrollo durante el an´alisis. 5.1.1.3. Diagramas A continuaci´on se presenta el modelo del dominio para el contexto en el que se engloba la aplicaci´on. Debido a las dimensiones del modelo, ´este se ha dividido en varias partes para facilitar su comprensi´on y dar mayor claridad al mismo. El modelo del dominio se desglosa en tres diagramas principalmente: el principal, otro dedicado a las rutas y un tercero para la parte social de la aplicaci´on. Hay otros auxiliares que se detallar´an m´as adelante. La identificaci´on de los elementos o clases que componen los diversos diagramas del modelo de dominio se ha conseguido mediante varias iteraciones al proceso de recoger aquellos objetos u aspectos pertenecientes al mundo real asociado al contexto de la aplicaci´on. En este caso el contexto de la aplicaci´on es el de las rutas y su gesti´on por parte del usuario de la aplicaci´on. 60 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Figura 5.18: Modelo del dominio - Accidentes geogr´aficos (volc´anicos) 5.1.2. Enumeraci´on de requisitos candidatos 5.1.2.1. Introducci´on La lista de caracter´ısticas es un artefacto que se obtiene despu´es de aplicar la tarea de “Enumerar los requisitos candidatos” que se propone en la metodolog´ıa PUD (Proceso Unificado de Desarrollo), para la captura de requisitos. Por lo tanto, se encuentra englobada dentro de la fase de inicio. Esta lista sirve para contener las ideas de clientes, usuarios, analistas y desarrolladores a modo de fichas sobre los posibles aspectos que se podr´ıan incluir en la aplicaci´on, y que, posteriormente, se podr´an traducir en requisitos del software. Estas ideas se consideran requisitos candidatos que se podr´an desarrollar en la versi´on actual del sistema o se podr´an postergar a versiones futuras. Este artefacto sirve para gestionar el proyecto y s´olo se utiliza para la planificaci´on del trabajo. Podr´a ir variando a medida que avance el proyecto, pudi´endose a˜nadir y modificar las caracter´ısticas que se crean oportunas, en cualquier momento del desarrollo.[JBR99] 5.1.2.2. Leyenda Cada ficha que representa a una caracter´ıstica se compone de diversos campos que pasamos a describir: C´odigo: Es el identificador de la caracter´ıstica. Su formato es el siguiente: “LC-Categor´ıa.N´umero”. Nombre: Nombre de la caracter´ıstica. Descripci´on: Se describe la funcionalidad de la caracter´ıstica a trav´es de un texto explicativo. Coste: Coste de desarrollar la caracter´ıstica. Prioridad: Indica el orden a la hora de desarrollar dicha caracter´ıstica. Estado: Indica como va evolucionando el desarrollo de la caracter´ıstica. Sus posibles valores son: Propuesto, Aprobado, Incluido, En desarrollo, Finalizado. Nivel de riesgo: Especifica la complejidad para conseguir realizar la caracter´ıstica de manera correcta. Sus posibles valores son: Cr´ıtico, Significativo, Rutinario. 5.1. REQUISITOS DEL SISTEMA 61 Estos valores se utilizan para estimar el tama˜no del proyecto y decidir c´omo dividirlo en una secuencia de iteraciones. La prioridad y nivel de riesgo asociados, por ejemplo, se emplea para decidir en qu´e iteraci´on se implementar´a la caracter´ıstica. 5.1.2.3. Aspectos involucrados con las Rutas LC-A.1 Gesti´on de rutas Descripci´on: Los usuarios de la aplicaci´on podr´an crear, guardar, visualizar, renombrar, modificar y eliminar las rutas creadas de manera c´omoda y sencilla a trav´es de la aplicaci´on. La creaci´on de las rutas se har´a marcando con el rat´on los puntos en el globo terr´aqueo. Para modificar la ruta se arrastrar´an dichos puntos usando tambi´en el rat´on. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.2 Ver Tour Descripci´on: Cuando el usuario seleccione la visualizaci´on de un tour para una ruta determinada, la c´amara comenzar´a un recorrido virtual empezando desde el punto inicial y siguiendo por el resto de puntos de la ruta hasta llegar al ´ultimo. El recorrido se har´a usando una perspectiva cenital. Si hay puntos de inter´es en la ruta, la c´amara se detendr´a en ellos y se mostrar´a informaci´on asociada al punto de inter´es (de manera opcional). El recorrido utilizar´a controles de reproducci´on para iniciar, parar y salir del mismo. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 62 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-A.3 Ver sitios de inter´es Descripci´on: El usuario durante la visualizaci´on de una ruta debe poder ver aquellos lugares de inter´es que posea la misma. Al hacer clic en uno de ellos con el rat´on se mostrar´a informaci´on asociada y contextual sobre el sitio de inter´es seleccionado. Dicha informaci´on tambi´en podr´a ocultarse una vez mostrada. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.4 Gestionar tipos de sitios de inter´es Descripci´on: El usuario deber´a poder crear, modificar y borrar tipos de sitios de inter´es (p.e. geogr´aficos, tur´ısticos, poblaciones, etc.) que desee visualizar durante el recorrido de las rutas. Cada tipo de sitio de inter´es tendr´a sus propias propiedades en funci´on del tipo al que pertenezca. El usuario tambi´en podr´a clasificarlos en diversas categor´ıas de su elecci´on. Coste: Prioridad: Estado: Aprobado Nivel de riego: Rutinario LC-A.5 Propiedades de un sitio de inter´es Descripci´on: El usuario durante la visualizaci´on de una ruta que contenga sitios de inter´es podr´a visualizar informaci´on caracter´ıstica de un sitio de inter´es concreto haciendo clic con el rat´on en el mismo. Dichas propiedades variar´an seg´un la tipolog´ıa del sitio de inter´es seleccionado. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario 5.1. REQUISITOS DEL SISTEMA 63 LC-A.6 Ver modelos 3D Descripci´on: El usuario durante la visualizaci´on de una ruta podr´a ver elementos caracter´ısticos de la misma en 3D como estatuas u otros de diversa ´ındole (monumentos, efigies, etc.). Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.7 Obtener informaci´on de un punto 3D Descripci´on: El usuario durante la visualizaci´on de una ruta puede hacer que la aplicaci´on le muestre, para un punto determinado de dicha ruta, diversa informaci´on geogr´afica, como las coordenadas (longitud y latitud) del punto y su altitud, entre otras. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.8 Obtener informaci´on de una ruta Descripci´on: El usuario durante la visualizaci´on de una ruta puede hacer que la aplicaci´on le muestre, para dicha ruta, informaci´on geogr´afica como la altura m´ınima, m´axima, desnivel, distancia total, etc. Dicha informaci´on se mostrar´a mediante un cuadro contextual. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Significativo LC-A.9 Medidor de distancias Descripci´on: El usuario durante la visualizaci´on de una ruta podr´a medir distancias entre diversos puntos de la misma. El usuario har´a clic con el rat´on en el primer punto y en el segundo. Tras ello, el sistema le mostrar´a la distancia entre ellos. La medici´on puede ser en l´ınea recta o siguiendo la orograf´ıa del terreno. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 64 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-A.10 Visualizar objetos 3D Descripci´on: El usuario podr´a elegir diversas texturas con las que se podr´an reconstruir algunos objetos 3D como edificios, carreteras, plazas, etc. a la hora de mostrar el globo terr´aqueo. Esta elecci´on puede ser cambiada en cualquier momento por parte del usuario. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.11 Insertar elemento 3D Descripci´on: El usuario puede a˜nadir modelos 3D de elementos caracter´ısticos de rutas a los existentes en la aplicaci´on para documentar mejor las mismas. La aplicaci´on lo almacenar´a dentro de su almac´en de elementos 3D. Tras ello, el usuario puede usarlo para colocarlo donde crea m´as conveniente durante la visualizaci´on de una ruta. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.12 Almac´en de elementos 3D Descripci´on: La aplicaci´on mantendr´a un almac´en de elementos 3D gen´ericos para ser utilizado por todos los usuarios en la creaci´on de sus rutas. Adem´as el usuario podr´a a˜nadir m´as elementos 3D a su propio almac´en si as´ı lo quisiera. Dichos elementos incorporados podr´an ser borrados por el usuario si no los necesita. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.1. REQUISITOS DEL SISTEMA 65 LC-A.13 Visualizar Br´ujula Descripci´on: El usuario podr´a activar o desactivar una br´ujula en el navegador que indicar´a el norte geogr´afico. Esta opci´on puede ser cambiada por parte del usuario en cualquier momento. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.14 Visualizar localizaci´on global Descripci´on: Existir´a un panel en el que se mostrar´a la posici´on global del usuario en t´erminos de longitud, latitud y altura. El usuario podr´a habilitar o deshabilitar este panel. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.15 Indicar localizaci´on Descripci´on: El usuario podr´a introducir el nombre de un lugar y la aplicaci´on mostrar´a el lugar en el globo a partir de la direcci´on dada. Para ello, desplazar´a la c´amara desde el punto actual hasta la nueva localizaci´on. Adem´as se mostrar´a informaci´on adicional sobre la localizaci´on especificada. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.16 Gesti´on de eventos Descripci´on: La aplicaci´on permitir´a crear, borrar y modificar eventos. Los eventos son sucesos que ocurren cuando el usuario est´a visualizando una ruta, y durante su recorrido se cumplen ciertas condiciones (p.e. se aproxima a un sitio, sale de los l´ımites de una regi´on), o asociados a modelos 3D existentes en la ruta. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo 66 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-A.17 Buscar informaci´on Descripci´on: La aplicaci´on permitir´a a los usuarios buscar informaci´on sobre lugares de inter´es: ya sea a trav´es de un buscador de Internet o Wikipedia. Durante la visualizaci´on de una ruta, cuando el usuario haga clic en un sitio de inter´es, podr´a buscar la informaci´on directamente de manera c´omoda. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-A.18 Crear ruta ´optima Descripci´on: La aplicaci´on permitir´a a los usuarios mostrarle la ruta ´optima entre dos puntos dados tras calcularla. Para ello, el usuario elegir´a los dos puntos usando el rat´on y el sistema calcular´a dicha ruta en funci´on de diversos par´ametros: medio de transporte, tiempo necesario para recorrer la ruta, etc. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo LC-A.19 Term´ometro Descripci´on: La aplicaci´on permitir´a mostrar la temperatura del lugar donde se encuentre situado el usuario en ese momento. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.20 Bar´ometro Descripci´on: La aplicaci´on permitir´a mostrar la presi´on atmosf´erica del lugar donde se encuentre situado el usuario en ese momento. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.1. REQUISITOS DEL SISTEMA 67 LC-A.21 Gu´ıa Descripci´on: La aplicaci´on mostrar´a gu´ıas sobre rutas (ya sean en audio o v´ıdeo). Por ejemplo, durante la visualizaci´on de un tour, el usuario puede estar escuchando al mismo tiempo una pista de audio describiendo la ruta que se est´a visualizando. El usuario puede controlar la reproducci´on de la guia. Por otro lado, el usuario tambi´en podr´ıa ver guias en formato v´ıdeo describiendo las caracter´ısticas de la ruta seleccionada. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.22 Importar rutas Descripci´on: La aplicaci´on permitir´a importar al usuario rutas en otros formatos creadas con otras aplicaciones. Tras importarlas, se a˜nadir´an a las rutas ya existentes que tuviera el usuario. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.23 Exportar rutas Descripci´on: La aplicaci´on permitir´a exportar al usuario sus rutas en otros formatos para que pueda usarlas en otras aplicaciones. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-A.24 Cambiar unidad de distancia Descripci´on: La aplicaci´on permitir´a mostrar las distancias entre puntos usando el sistema m´etrico o anglosaj´on. Esta opci´on podr´a ser cambiada por el usuario en cualquier momento. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 68 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-A.25 Alquiler de coches Descripci´on: La aplicaci´on permitir´a al usuario realizar la gesti´on de alquilar un coche (usando otros servicios). Para ello, deber´ıa indicar la ruta que desea realizar de entre las que disponga y el sistema le mostrar´ıa una lista de empresas que trabajen en la zona. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo LC-A.26 Reservas de hotel Descripci´on: La aplicaci´on permitir´a realizar la gesti´on de reservas de hotel al usuario (usando otros servicios). Para ello, deber´ıa indicar el sitio al que desea ir y el sistema le mostrar´ıa una lista de hoteles que est´en situados en dicha localizaci´on. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo LC-A.27 Planificaci´on temporal Descripci´on: La aplicaci´on permitir´a al usuario a trav´es de un calendario especificar fechas para eventos concretos a realizar en la ruta. Adem´as de crear eventos, podr´a modificarlos o eliminarlos. Tambi´en podr´a indicar la hora concreta de los mismos. Asimismo, el usuario podr´a a˜nadir tareas por realizar a la planificaci´on. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.1. REQUISITOS DEL SISTEMA 69 LC-A.28 Permitir m´ultiples instancias del plugin Descripci´on: La aplicaci´on mostrar´a al usuario si lo desea varios globos para visualizar diferentes contenidos en paralelo. Se podr´ıa usar por ejemplo para mostrar diferentes rutas, una en cada instancia del plugin, para comparar diversas caracter´ısticas de las rutas. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.1.2.4. Rasgos ligados a los Usuarios LC-B.1 Gesti´on de usuarios Descripci´on: La aplicaci´on permitir´a dar de alta a usuarios, as´ı como que ´estos se den de baja de la misma y permitir´a modificar sus perfiles. En principio, el usuario no tendr´a por qu´e dar todos sus datos para registrarse, bastar´a con una informaci´on m´ınima que permita el alta y la posibilidad de recuperar sus datos. Posteriormente podr´a rellenar el resto de la informaci´on si as´ı lo desea. Tambi´en podr´a desactivar su perfil y eliminar sus datos de la aplicaci´on. Habr´a un usuario gestor de la aplicaci´on que act´ue como administrador de la misma y ser´a el encargado de las tareas propias del mantenimiento de la aplicaci´on. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-B.2 Avatares Descripci´on: Los usuarios podr´an usar avatares en sus perfiles a modo de imagen personal. ´ Esta ser´a usada cuando varios usuarios est´en conectados entre s´ı siendo lo que visualizar´an en los navegadores el resto de los usuarios. Cuando un usuario se registre en la aplicaci´on, su perfil dispondr´a de un avatar por defecto, que podr´a modificar a voluntad. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario 76 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-E.5 Actualizar las texturas Descripci´on: La aplicaci´on permitir´a actualizar las texturas con nuevas versiones de las mismas. En el navegador deben aparecer las texturas m´as actuales posibles, sin obligar al usuario a reinstalar o sincronizar su navegador. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-E.6 Actualizaci´on autom´atica Descripci´on: La aplicaci´on se podr´a actualizar, de forma autom´atica, con los nuevos cambios que hayan ocurrido en la API. Esto se realizar´a de forma transparente al usuario. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-E.7 Carga continua de datos remotos Descripci´on: Se ir´an visualizando en el terreno los datos que vayan llegando a trav´es de Internet de forma continua durante la visualizaci´on del terreno por parte del usuario. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-E.8 Hist´orico de operaciones Descripci´on: La aplicaci´on puede guardar un fichero de registro con todas las operaciones que haya realizado el usuario, o con s´olo aquellas que ´el elija. El usuario puede ver dicho fichero, as´ı como borrarlo. La opci´on de crear el fichero es opcional y es el usuario qui´en decide si crearlo o no. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.1. REQUISITOS DEL SISTEMA 77 LC-E.9 Visualizar gran n´umero de texturas en tiempo real Descripci´on: A medida que se navega se debe ir cargando las texturas, a distintas resoluciones, del terreno que se est´a visualizando. En funci´on de la distancia a la que se encuentre el usuario como observador variar´a la calidad de las texturas para optimizar la visualizaci´on. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo LC-E.10 Multinavegador Descripci´on: La aplicaci´on deber´a soportar est´andares que hagan que se pueda ejecutar en varios navegadores sin modificar la experiencia del usuario independientemente del navegador que est´e usando el usuario en cualquier momento. El conjunto de est´andares debe abarcar desde la interfaz gr´afica hasta los aspectos internos de la aplicaci´on. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-E.11 Multiplataforma Descripci´on: La aplicaci´on debe poder compilarse y ejecutarse en distintos sistemas operativos como Windows, Linux y Mac. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo 78 CAP´ ITULO 5. DESARROLLO DEL PROYECTO LC-E.12 Interfaz de usuario simple Descripci´on: La interfaz de la aplicaci´on ser´a muy sencilla e intuitiva, evitando ocultar demasiada informaci´on en men´us anidados y formularios demasiado complicados. La funcionalidad principal estar´a disponible en la propia pantalla del navegador. Coste: Prioridad: Estado: Aprobado Nivel de riesgo: Rutinario LC-E.13 Atajos de teclado Descripci´on: La interfaz de la aplicaci´on permitir´a al usuario activar las funciones m´as comunes usando su teclado a trav´es de pulsaciones de teclas o con combinaciones de las mismas. Seguir´an un patr´on est´andar y coherente. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-E.14 Software libre Descripci´on: Para la construcci´on de la aplicaci´on, tanto las herramientas internas como la interfaz gr´afica, se utilizar´an herramientas de software libre. Se realizar´a un estudio de cuales son las mejores opciones indicando los pros y contras de cada una y se tomar´a una decisi´on en consecuencia. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario 5.2. REQUISITOS DEL SOFTWARE 79 5.1.2.8. Propiedades de la versi´on para m´oviles (PDA) LC-F.1 Uso PDA Descripci´on: Los usuarios se podr´an conectar a la aplicaci´on a trav´es de PDAs y tel´efonos m´oviles. La informaci´on del usuario estar´a sincronizada entre la versi´on de escritorio y la de PDA, y cualquier cambio se ver´a reflejado en ambas versiones. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Rutinario LC-F.2 Interfaz para m´oviles Descripci´on: La interfaz de la aplicaci´on se adaptar´a para mostrarse de la mejor manera posible en m´oviles y PDAs. Tendr´a que tener en cuenta las limitaciones de espacio en cuanto a la pantalla y de capacidad de c´omputo para ofrecer el mejor resultado posible de cara al usuario. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Significativo LC-F.3 Gesti´on del tr´afico Descripci´on: La aplicaci´on permitir´a mostrar la informaci´on del tr´afico para las rutas en coche al usuario. Dada la ruta seleccionada por el usuario, la aplicaci´on le indicar´a al usuario qu´e carreteras est´an congestionadas y le ofrecer´a alternativas (si las hubiera) para llegar al destino. Coste: Prioridad: Estado: Propuesto Nivel de riesgo: Cr´ıtico 5.2. Requisitos del software La especificaci´on de requisitos del software es una descripci´on completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendr´an los usuarios con el software, deducidos a partir de la 80 CAP´ ITULO 5. DESARROLLO DEL PROYECTO informaci´on obtenida con el modelo de dominio y la lista de caracter´ısticas. Los casos de uso tambi´en son conocidos como requisitos funcionales. Para cada usuario se crean “Casos de uso”, los cuales detallan y describen las operaciones que podr´a realizar cada uno, en un lenguaje de alto nivel, en t´erminos m´as coloquiales que t´ecnicos. A partir de los casos de uso se refinan las operaciones, definiendo los pasos concretos que incluye cada una. Estos pasos se describen mediante las “Tablas de flujo de sucesos”. En general se realiza una tabla por cada caso de uso que exista. Adem´as de los casos de uso, tambi´en contiene requisitos no funcionales, que son aquellos que realiza el sistema sin la interacci´on con un usuario de forma directa y que son necesarios para poder llevar a cabo acciones solicitadas por los mismos. Todo este trabajo servir´a como base para desarrollar la etapa de an´alisis, la cual se explicar´a m´as adelante. 5.2.1. Jerarqu´ıa de actores Los actores son una parte relevante del modelado del sistema, pues forman parte del entorno del mismo. Normalmente, un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa por un actor. Los actores utilizan el sistema interactuando con los casos de uso. Podemos encontrar y especificar todos los actores examinando a los usuarios que utilizar´an el sistema y a otros sistemas que deben interactuar con ´el. Cada categor´ıa de usuarios o sistemas que interact´uan se representan por tanto como actores. Partiendo del modelo del dominio, el analista del sistema, junto con el cliente, identifican los usuarios e intentan organizarlos en categor´ıas representadas por actores. Debemos identificar los actores que representan sistemas externos y los actores para el mantenimiento y operaci´on del sistema. Para el caso particular de nuestro sistema se han detectado cuatro actores b´asicos: Administrador, Usuario Registrado, Usuario No Registrado y Empresa. A continuaci´on describiremos brevemente las particularidades de cada uno de ellos: Administrador Es el actor encargado del buen funcionamiento del sistema. Por lo tanto es el encargado de realizar las tareas de mantenimiento que hagan que el sistema se mantenga operativo. Usuario No Registrado Es el actor que no est´a identificado en el sistema. Ello implica que no puede acceder a la totalidad de casos de uso que el sistema presenta. Para ello el usuario debe cambiar de rol y pasar a ser otro actor. Usuario Registrado Es el actor principal del sistema. La mayor´ıa de usuarios se corresponder´an con este actor. La mayor parte de la funcionalidad del sistema se concentra en los casos de uso para este actor. Empresa Es una especializaci´on del actor Usuario Registrado. Sus posibles particularidades con respecto a ´este ´ultimo nos recomienda que le asignemos un actor espec´ıfico para 5.2. REQUISITOS DEL SOFTWARE 81 ´el. Se diferencia con respecto al actor Usuario Registrado en la interacci´on con el resto de usuarios del sistema y en la posibilidad de dar soporte a la publicidad. La jerarqu´ıa de actores se muestra en la figura que se presenta a continuaci´on. Como ra´ız del ´arbol est´a el actor Usuario, que sin embargo no es un actor real del sistema, es abstracto. El resto de actores heredan de ´el todas sus propiedades. Del actor Usuario nacen tres actores: Administrador, Usuario Registrado y Usuario No Registrado. Estos tres actores fueron descritos anteriormente. Del actor Usuario Registrado aparece el actor Empresa, para diferenciar las particularidades de los actores. Figura 5.19: Actores del sistema 5.2.2. Casos de uso 5.2.2.1. Gesti´on de Usuarios La gesti´on de Usuarios engloba los casos de uso correspondientes a dos actores: Usuario No Registrado y Usuario Registrado. Los casos de uso para ambos actores est´an separados en dos secciones que pasan a describirse a continuaci´on: El Usuario No Registrado no puede acceder al sistema, luego debe pasar primero por un registro para poder ser Usuario Registrado. Por lo tanto, dispone de un primer caso de uso llamado Registrarse, que permite a la aplicaci´on identificarle. Al completar este caso de uso, autom´aticamente se ejecuta el de Iniciar Sesi´on, que le autentifica en el sistema. Este caso se puede realizar por separado, una vez el usuario est´e registrado, que s´olo es necesario hacerlo una vez. Por ´ultimo, est´a el caso de uso Recordar Contrase˜na, que permite a un usuario existente en el sistema realizar el ingreso, pero que no puede identificarse en el sistema por no recordar los datos para realizarlo. En resumen, el actor Usuario No Registrado es el paso 82 CAP´ ITULO 5. DESARROLLO DEL PROYECTO previo del Usuario Registrado. Figura 5.20: Usuario No Registrado El Usuario Registrado puede ejecutar el caso de uso Cerrar Sesi´on que concluye la actividad del usuario en el sistema. Tras ello, el usuario toma el rol del actor Usuario No Registrado. Tambi´en puede Darse de Baja lo que elimina la cuenta del usuario y los datos existentes del mismo en el sistema. Como en el caso anterior, su papel se ve modificado, pues se convierte tambi´en en Usuario No Registrado. Adem´as puede modificar sus datos personales para actualizar la informaci´on propia en la aplicaci´on, as´ı como cambiar la contrase˜na de acceso al sistema, caso de uso que est´a incluido en el anterior. Estos dos casos de uso no alteran el actor implicado. Figura 5.21: Usuario Registrado 5.2. REQUISITOS DEL SOFTWARE 83 5.2.2.2. Gesti´on de Elementos del Globo En este apartado se describir´an los casos de uso relativos a los diferentes componentes con los que puede interactuar el actor Usuario Registrado y que pueden ser visualizados en el globo terr´aqueo de la aplicaci´on. Est´an divididos por categor´ıas, las cuales se describen en las secciones siguientes. Las categor´ıas son: Capas, Rutas, Sitios de Inter´es y Tours. Cada categor´ıa se compone de los casos de uso correspondientes siguiendo una filosof´ıa CRUD (Create-Read-Update-Delete), a˜nadiendo algunos particulares para cada caso, que se detallar´an con m´as profundidad en las secciones correspondientes. La gesti´on de capas que puede realizar el actor Usuario Registrado a trav´es de la aplicaci´on se compone de los siguientes casos de uso: Crear Capa, Visualizar Capa, Modificar Capa, Renombrar Capa y Eliminar Capa. Visualizar Capa se descompone en Visualizar Informaci´on, Desplegar Capa, Activar Capa e Ir a. Sintetizan las diferentes formas de ver el contenido de una capa. Para poder modificar una capa, es necesario que la capa se est´e visualizando en ese momento. Figura 5.22: Gesti´on de Capas El actor Usuario Registrado puede realizar los siguientes casos de uso: Ver Ruta, Ver Tour, Ver Sitios de Inter´es y Seleccionar Capas. Las diferentes opciones que cambie el usuario en el caso de uso Seleccionar Capas tendr´an influencia en el caso de uso Ver Sitios de Inter´es. 84 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Figura 5.23: Visualizar Ruta El actor Usuario Registrado dispone de los siguientes casos de uso para gestionar sus rutas: Crear Ruta, Guardar Ruta, Visualizar Ruta, Modificar Ruta, Renombrar Ruta y Eliminar Ruta. En el caso de Guardar Ruta es obligatorio haber utilizado el caso de uso Crear Ruta y para ejecutar el caso de uso Modificar Ruta es necesario haber ejecutado previamente el caso de uso Visualizar Ruta. El caso de uso Crear Ruta se divide en dos casos de uso m´as: Insertar Puntos e Insertar Elementos. El primero es elemental y no se puede descomponer m´as; pero el segundo es una abstracci´on de otros cuatro casos de uso m´as: Insertar Modelo 3D, Insertar Foto, Insertar V´ıdeo e Insertar Documento, que est´an agrupados bajo Insertar Elementos. Figura 5.24: Gestionar Rutas 5.2. REQUISITOS DEL SOFTWARE 85 La gesti´on de sitios de inter´es por parte del actor Usuario Registrado se resume en los siguientes casos de uso: A˜nadir Sitio de Inter´es, Visualizar Sitio de Inter´es, Modificar Sitio de Inter´es, Renombrar Sitio de Inter´es y Eliminar Sitio de Inter´es. Recordar que los sitios de inter´es pueden presentar una gran diversidad, por lo que los casos de uso deben adecuarse a tal situaci´on. En general, todos los casos de uso interactuar´an con el usuario de manera contextual debido a la tipolog´ıa de estos elementos a la hora de disponerlos sobre el globo terr´aqueo. Figura 5.25: Gestionar Sitios de Inter´es La gesti´on de los tours o recorridos por parte del actor Usuario Registrado se concentra en los siguientes seis casos de uso: Crear Tour Autom´atico, Crear Tour Manual, Visualizar Tour, Modificar Tour, Renombrar Tour y Eliminar Tour. Se ha optado por poner dos casos de uso diferentes para crear un tour para otorgar mayor autonom´ıa al usuario. En el caso autom´atico la aplicaci´on generar´a los tours, lo cual es m´as c´omodo para el usuario, pero no es tan flexible. Al permitir el caso manual, el usuario es libre de crear el tour de la forma que desee. 92 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Iniciar Sesi´on Descripci´on: Un usuario registrado de la aplicaci´on para entrar en la misma debe autentificarse en el sistema para obtener sus datos y acceder a la pantalla inicial. Si no est´a autentificado y desea acceder a un recurso propio de la aplicaci´on, ´esta deber´a cancelar la petici´on del usuario y llevarlo hasta la pantalla de identificaci´on. Precondici´on: Usuario no autentificado Par´ametros: Nombre Contrase˜na Flujo de Ejecuci´on: 1. El usuario accede al formulario de registrar usuario 2. El usuario proporciona sus datos personales: El usuario introduce su nombre El usuario introduce la contrase˜na 3. El usuario hace clic en el bot´on de identificarse del formulario 4. El sistema realiza una serie de verificaciones: El sistema comprueba que el nombre existe en la base de datos El sistema comprueba que la contrase˜na es correcta 5. Si todas las comprobaciones tienen ´exito el usuario queda autentificado en el sistema 6. El sistema muestra la pantalla inicial al usuario Caminos Alternativos: Usuario no existente (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Contrase˜na incorrecta (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: El usuario habr´a iniciado sesi´on en la aplicaci´on. 5.2. REQUISITOS DEL SOFTWARE 93 Nombre: Recordar Contrase˜na Descripci´on: Si un usuario de la aplicaci´on no puede iniciar sesi´on por no recordar sus datos de acceso, puede solicitar a la aplicaci´on especificando su correo electr´onico los datos de acceso. La aplicaci´on enviar´a un correo a la direcci´on indicada con los datos de acceso. Recordar tambi´en que cuando el usuario se registra, la aplicaci´on envi´o en su momento al usuario otro correo con los datos de acceso. Precondici´on: Usuario no autentificado Par´ametros: E-Mail Flujo de Ejecuci´on: 1. El usuario hace clic en Recordar Contrase˜na 2. El usuario introduce su direcci´on de correo 3. El sistema verifica si la direcci´on de correo est´a registrada en la base de datos del mismo 4. Si se encuentra la contrase˜na, se env´ıa un correo electr´onico a dicha direcci´on indicando la contrase˜na 5. Se informa al usuario de que su solicitud se ha completado y se le solicita que mire su correo Caminos Alternativos: E-Mail incorrecto (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: Se habr´a enviado un e-mail al correo del usuario con la contrase˜na del usuario. 94 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Cerrar Sesi´on Descripci´on: El usuario cuando haya finalizado con todas las tareas que necesite hacer en la aplicaci´on, puede ejecutar el caso de uso Cerrar Sesi´on para abandonar la aplicaci´on. ´ Esta devolver´a al usuario a la pantalla inicial y deber´a volver a iniciar sesi´on para acceder. Precondici´on: Usuario autentificado Par´ametros: Flujo de Ejecuci´on: 1. El usuario hace clic en el bot´on de cerrar sesi´on 2. El sistema cierra la sesi´on del usuario 3. El sistema devuelve al usuario a la pantalla inicial de la aplicaci´on Caminos Alternativos: Postcondici´on: El usuario habr´a cerrado sesi´on en la aplicaci´on. 5.2. REQUISITOS DEL SOFTWARE 95 Nombre: Darse de baja Descripci´on: El usuario que no desee continuar haciendo uso de la aplicaci´on, puede darse de baja de la misma. El usuario que lo haga pierde todos los datos que haya subido a la aplicaci´on. Se podr´ıa a˜nadir alg´un formulario para que el usuario expresara que le ha parecido la aplicaci´on y qu´e cosas mejorar´ıa. Precondici´on: Usuario autentificado Par´ametros: Contrase˜na Flujo de Ejecuci´on: 1. El usuario accede al formulario de darse de baja 2. El usuario introduce su contrase˜na 3. La aplicaci´on solicita al usuario confirmar la operaci´on 4. Si el usuario acepta: El sistema cierra la sesi´on del usuario El sistema elimina la cuenta del usuario y todos sus datos asociados El sistema devuelve al usuario a la pantalla inicial de la aplicaci´on Caminos Alternativos: Contrase˜na incorrecta (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Operaci´on cancelada (3) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El usuario se habr´a borrado de la aplicaci´on. 96 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Modificar Datos Personales Descripci´on: El usuario puede completar o cambiar ciertos aspectos de su perfil personal. Cuando un usuario se da de alta solamente tiene el nombre y el correo electr´onico como datos personales. Con este caso de uso el usuario puede a˜nadir otros elementos tales como: foto personal, descripci´on, estudios, etc. Precondici´on: Usuario autentificado Par´ametros: Datos del usuario nuevos Flujo de Ejecuci´on: 1. El usuario accede al formulario de modificar datos 2. El usuario cambia los datos de su perfil 3. El sistema verifica los datos 4. El sistema actualiza la informaci´on del usuario Caminos Alternativos: Datos incorrectos (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: Los datos del usuario se habr´an actualizado en la aplicaci´on. 5.2. REQUISITOS DEL SOFTWARE 97 Nombre: Cambiar Contrase˜na Descripci´on: Si el usuario quiere cambiar la contrase˜na que usa, puedo hacerlo desde la aplicaci´on. Simplemente por seguridad debe teclear la contrase˜na actual y dos veces la nueva contrase˜na. La nueva contrase˜na debe seguir el mismo formato que la antigua para asegurarse de que sea segura. Precondici´on: Usuario autentificado Par´ametros: Contrase˜na Actual Contrase˜na Nueva Flujo de Ejecuci´on: 1. El usuario accede al formulario de cambiar contrase˜na 2. El usuario proporciona sus datos personales: El usuario introduce su contrase˜na actual El usuario introduce la nueva contrase˜na El usuario introduce otra vez la nueva contrase˜na 3. El sistema realiza una serie de verificaciones: El sistema comprueba que la contrase˜na es correcta El sistema comprueba que las contrase˜nas nuevas coinciden 4. Si todas las comprobaciones tienen ´exito la contrase˜na del usuario quedar´a actualizada Caminos Alternativos: Contrase˜na incorrecta (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Contrase˜nas diferentes (2) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: La contrase˜na del usuario se habr´a actualizado en la aplicaci´on. 98 CAP´ ITULO 5. DESARROLLO DEL PROYECTO 5.2.3.2. Gesti´on de Elementos del Globo Nombre: Crear Capa Descripci´on: El usuario puede crear una capa en la aplicaci´on para gestionar de manera m´as eficiente el conjunto de elementos que puede visualizar en el globo terr´aqueo. Una capa es un contenedor que puede almacenar rutas, sitios de inter´es e incluso otras capas. Precondici´on: Usuario autentificado Par´ametros: Nombre Padre Flujo de Ejecuci´on: 1. El usuario hace clic en Crear Capa 2. El usuario introduce un nombre para la capa 3. El usuario elige una capa padre para la nueva capa a crear 4. La capa se habr´a creado (sin elementos) Caminos Alternativos: Postcondici´on: El usuario dispondr´a de una capa m´as en su lista de elementos. 5.2. REQUISITOS DEL SOFTWARE 99 Nombre: Visualizar Capa Descripci´on: Cuando el usuario seleccione una capa, todo el contenido de la misma se mostrar´a en el globo: rutas y sitios de inter´es. Si la capa tuviera otras capas dentro, tambi´en se mostrar´ıa su contenido. Posiblemente si los elementos son muchos, la carga de los elementos ser´ıa muy lenta, lo que obligar´ıa a utilizar un sistema que los filtre usando alg´un criterio (altura, zona que se est´a viendo en ese momento, etc.) Precondici´on: Usuario autentificado Par´ametros: Capa seleccionada Flujo de Ejecuci´on: 1. El usuario hace clic en una capa 2. La aplicaci´on carga desde la base de datos la informaci´on de la capa a partir del identificador 3. La aplicaci´on mostrar´a en el globo terr´aqueo todos los elementos de la capa: Las rutas almacenadas Los sitios de inter´es guardados Si los hubiera, tambi´en se mostrar´an el resto de elementos descriptivos de la ruta (modelos 3D, im´agenes, v´ıdeos, etc.) Caminos Alternativos: Postcondici´on: La capa seleccionada y sus elementos se mostrar´an en el globo de la aplicaci´on. 100 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Modificar Capa Descripci´on: El usuario puede cambiar el contenido de las capas usando el rat´on para arrastrar elementos de la lista incorpor´andolos o elimin´andolos a la capa seleccionada por ejemplo. El contenido de la capa se ver´a siguiendo una estructura de ´arbol. Precondici´on: Usuario autentificado Par´ametros: Capa seleccionada Flujo de Ejecuci´on: 1. El usuario hace clic en una capa 2. El usuario puede alterar el contenido de la capa de diversas formas: Puede a˜nadir, modificar o quitar rutas Puede a˜nadir, modificar o quitar sitios de inter´es Puede a˜nadir, modificar o quitar otras subcapas 3. Una vez hecha la operaci´on, la capa quedar´a actualizada con los cambios realizados Caminos Alternativos: Postcondici´on: La capa habr´a visto como el n´umero de sus elementos ha sido alterado o alguna de las propiedades de la misma ha cambiado. 5.2. REQUISITOS DEL SOFTWARE 101 Nombre: Renombrar Capa Descripci´on: El usuario puede cambiar el nombre de la capa en cualquier momento. Con pulsar en el bot´on correspondiente la aplicaci´on deja que el usuario puede escribir un nuevo nombre. La aplicaci´on seleccionar´a completamente el viejo nombre para que el usuario puede escribirlo directamente. Precondici´on: Usuario autentificado Par´ametros: Capa seleccionada Nuevo nombre Flujo de Ejecuci´on: 1. El usuario hace clic en una capa 2. El usuario hace clic en el bot´on de Renombrar Capa 3. El sistema queda en estado de espera hasta que el usuario introduce el nuevo nombre 4. Tras introducir el nombre, el sistema comprueba si no existe otra capa del usuario con el mismo nombre 5. Si el nombre es correcto se actualiza la capa en la base de datos del sistema Caminos Alternativos: Nombre en uso (4) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: La capa se habr´a actualizado con el nuevo nombre. 108 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Ver Tour Descripci´on: El usuario puede visualizar una ruta de manera autom´atica con la opci´on de ver tour. La c´amara seguir´a la trayectoria de la ruta de principio a fin simulando una perspectiva a´erea y deteni´endose en los sitios de inter´es de la ruta si los hubiera. Precondici´on: El usuario debe estar identificado Ruta visualizada Par´ametros: ID de la Ruta Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El usuario hace clic en Ver Tour 3. El sistema activar´a la opci´on de Ver Tour 4. El sistema mostrar´a los controles de reproducci´on del Tour (Play, Pause, Stop) 5. El usuario hace clic en Iniciar Tour 6. El sistema comienza con la reproducci´on del Tour Caminos Alternativos: Postcondici´on: La ruta seleccionada se mostrar´a en el globo. 5.2. REQUISITOS DEL SOFTWARE 109 Nombre: Ver Sitios de Inter´es Descripci´on: Cuando una ruta tenga sitios de inter´es y el usuario est´e visualizando una ruta, ´este podr´a hacer clic en los sitios de inter´es que desee y la aplicaci´on le mostrar´a al usuario informaci´on relevante sobre el sitio de inter´es seleccionado. Precondici´on: El usuario debe estar identificado Ruta mostrada Par´ametros: ID de la Ruta IDs de los tipos de sitios de inter´es Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El sistema muestra la ruta seleccionada en el globo 3. El usuario elige de entre las diversas capas disponibles (monumentos, restaurantes, etc.) cuales quiere ver 4. El sistema mostrar´a los sitios de inter´es correspondientes a las capas elegidas m´as cercanos a la ruta seleccionada Caminos Alternativos: Postcondici´on: Los sitios de inter´es de la ruta se mostrar´an en el globo siguiendo el recorrido. Nombre: Seleccionar Capas Descripci´on: El usuario puede cambiar qu´e tipos de sitios de inter´es quiere visualizar en cada momento. Ello hace que var´ıe cuales se muestran durante la visualizaci´on de las rutas. Precondici´on: El usuario debe estar identificado Par´ametros: Flujo de Ejecuci´on: 1. El sistema muestra al usuario una lista con las capas disponibles 2. El usuario elige una o varias de entre las que se muestran Caminos Alternativos: Postcondici´on: Las capas seleccionadas quedan asignadas en el sistema. 110 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Crear Ruta Descripci´on: El usuario puede crear una ruta usando el rat´on para dibujar una l´ınea sobre el globo terr´aqueo de la aplicaci´on. El estilo de la l´ınea puede cambiarse. Cuando el usuario desee terminar de crear la l´ınea, har´a doble clic en globo terr´aqueo para indicar el punto final de la ruta. La forma de crear la l´ınea con el rat´on puede variar. Precondici´on: El usuario debe estar identificado Debe haber una capa seleccionada (si no, se usar´a la capa por defecto) Par´ametros: Flujo de Ejecuci´on: El usuario a trav´es del rat´on ir´a usando el rat´on en el globo para ir dibujando la ruta que desee. 1. El usuario hace clic en Crear Ruta 2. El usuario a trav´es del rat´on ir´a creando la ruta sobre el globo Haciendo clics sobre el globo generando segmentos de recta Manteniendo el bot´on del rat´on pulsado 3. Para finalizar la ruta har´a doble clic en el punto final de la misma 4. La ruta creada se a˜nadir´a a la capa seleccionada Caminos Alternativos: Postcondici´on: La ruta creada se muestra en el globo terr´aqueo. 5.2. REQUISITOS DEL SOFTWARE 111 Nombre: Guardar Ruta Descripci´on: Cuando el usuario haya terminado de crear la ruta, la aplicaci´on mostrar´a al usuario un cuadro para que especifique el nombre de la ruta y otros datos asociados. Precondici´on: El usuario debe estar identificado Ruta creada Par´ametros: Nombre de la Ruta Puntos de la Ruta Capa Descripci´on Flujo de Ejecuci´on: 1. Tras crear la ruta, el sistema mostrar´a al usuario un formulario donde deber´a introducir los datos necesarios para almacenar la ruta: Nombre Capa Descripci´on 2. El usuario har´a clic en el bot´on de Guardar Ruta 3. Si los datos son correctos, la ruta creada se almacenar´a en el sistema Caminos Alternativos: Nombre en uso (1) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: La ruta se habr´a a˜nadido a la lista de rutas del usuario. 112 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Visualizar Ruta Descripci´on: Cuando el usuario seleccione una ruta de las que posee, ´esta se mostrara en el globo terr´aqueo a trav´es de una l´ınea dibujada sobre el mismo. El usuario podr´a cambiar la apariencia de la l´ınea a trav´es de varias caracter´ısticas: color, grosor y modo de altura. Precondici´on: El usuario debe estar identificado Par´ametros: Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El sistema carga desde la base de datos los datos de la ruta a partir del identificador 3. El sistema muestra las coordenadas de la ruta en el globo junto al resto de la informaci´on en los paneles correspondientes 4. Si los hubiera, tambi´en se mostrar´an el resto de elementos descriptivos de la ruta (modelos 3D, im´agenes, v´ıdeos, etc.) Caminos Alternativos: Postcondici´on: La ruta seleccionada se mostrar´a en el globo. 5.2. REQUISITOS DEL SOFTWARE 113 Nombre: Modificar Ruta Descripci´on: Si el usuario desea poder cambiar el recorrido de una ruta lo puede hacer arrastrando con el rat´on los puntos de la ruta. La aplicaci´on actualizar´a el conjunto de puntos de la ruta. Tambi´en pueden modificarse otros metadatos de la ruta como la descripci´on, el tipo de altura, etc. Precondici´on: El usuario debe estar identificado Par´ametros: Ruta seleccionada Puntos de la Ruta Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El sistema carga desde la base de datos los datos de la ruta a partir del identificador 3. El sistema muestra las coordenadas de la ruta en el globo junto al resto de la informaci´on en los paneles correspondientes 4. Si los hubiera, tambi´en se mostrar´an el resto de elementos descriptivos de la ruta (modelos 3D, im´agenes, v´ıdeos, etc.) 5. El usuario puede ahora cambiar diferentes aspectos de la ruta: El usuario puede ahora con el rat´on arrastrar los puntos que forman la ruta para modificarla El usuario puede a˜nadir o eliminar los elementos que documentan la ruta 6. En cualquiera de los casos el sistema guardar´a en la base de datos la ruta actualizada Caminos Alternativos: Postcondici´on: Los datos de la ruta se habr´an actualizado. 114 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Renombrar Ruta Descripci´on: El usuario puede cambiar el nombre de la ruta en cualquier momento. Con pulsar en el bot´on correspondiente, la aplicaci´on deja que el usuario pueda escribir un nuevo nombre. La aplicaci´on seleccionar´a completamente el viejo nombre para que el usuario puede escribirlo directamente. Precondici´on: El usuario debe estar identificado Par´ametros: Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El usuario hace clic en el bot´on de Renombrar Ruta 3. El sistema queda en estado de espera hasta que el usuario introduce el nuevo nombre 4. Tras introducir el nombre, el sistema comprueba si no existe otra ruta del usuario con el mismo nombre 5. Si el nombre es correcto se actualiza la ruta en la base de datos del sistema Caminos Alternativos: Nombre en uso (4) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: La ruta estar´a actualizada con el nuevo nombre. 5.2. REQUISITOS DEL SOFTWARE 115 Nombre: Eliminar Ruta Descripci´on: Cuando el usuario no desee utilizar m´as una ruta puede borrarla de la aplicaci´on desde la opci´on destinada a tal efecto. La aplicaci´on le solicitar´a al usuario confirmar la operaci´on. La ruta ser´a eliminada de la base de datos y no aparecer´a m´as en la lista de rutas del usuario. Precondici´on: El usuario debe estar identificado Par´ametros: Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El usuario hace clic en el bot´on de Eliminar Ruta 3. El sistema emite un mensaje preguntando al usuario si quiere continuar En caso de respuesta afirmativa, el sistema eliminar´a dicha ruta de la base de datos Se informa al usuario de que la ruta se ha eliminado Caminos Alternativos: Operaci´on cancelada (3) Se interrumpe la operaci´on Postcondici´on: La ruta se habr´a borrado de la lista de rutas del usuario. 116 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Insertar Puntos Descripci´on: La inserci´on de puntos de a la hora de crear una ruta se har´a con el rat´on haciendo clic sobre el globo terr´aqueo. Con cada clic la aplicaci´on ir´a pintando segmentos de recta simulando la ruta. Tambi´en podr´an a˜nadirse puntos arrastrando el rat´on sobre el globo terr´aqueo. Hay que seleccionar el m´etodo a usar o incluso usar los dos al mismo tiempo. Precondici´on: El usuario debe estar identificado El sistema debe estar en Crear Ruta Par´ametros: Flujo de Ejecuci´on: 1. El usuario haciendo uso del rat´on ir´a haciendo clic sobre el globo para indicar los puntos que conforman la ruta 2. A medida que el usuario va clicando sobre el globo, el sistema va guardando los puntos en una estructura de datos 3. Cuando el usuario haga doble clic sobre el globo terminar´a la edici´on de la ruta Caminos Alternativos: Postcondici´on: Los puntos se habr´an a˜nadido a la ruta que se est´a creando. 5.2. REQUISITOS DEL SOFTWARE 117 Nombre: Insertar Elementos Descripci´on: El usuario podr´a a˜nadir elementos con los que documentar las rutas de manera que se muestren a lo largo de la ruta por parte de la aplicaci´on. El usuario hace clic en el bot´on correspondiente para insertar el elemento que desea y luego indica con el rat´on donde colocarlo. Tras ello, la aplicaci´on mostrar´a un cuadro para el usuario rellene los datos del elemento. Una vez hecho, el elemento se mostrar´a en el globo terr´aqueo. Precondici´on: El usuario debe estar identificado Par´ametros: Ruta seleccionada Punto de la ruta Flujo de Ejecuci´on: 1. El usuario hace clic en Insertar Elemento 2. El usuario hace clic con el rat´on en el punto donde quiere colocar el elemento 3. El sistema muestra un formulario para insertar el elemento 4. Se solicitar´a que indique la direcci´on del mismo Ya sea a trav´es de un fichero local O est´e almacenado en otro servicio web 5. El elemento se mostrar´a en el globo 6. El sistema actualizar´a la ruta en la base de datos con el elemento reci´en a˜nadido Caminos Alternativos: Ruta Inv´alida (4) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: El elemento se habr´a a˜nadido a la ruta seleccionada. 124 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Eliminar Sitio de Inter´es Descripci´on: Si el usuario considera que un sitio de inter´es ya no es ´util, puede eliminarlo de la aplicaci´on seleccion´andolo en la lista de elementos y haciendo clic en Eliminar Sitio de Inter´es. La aplicaci´on le solicitar´a al usuario confirmar la operaci´on. Tras ello, el sitio de inter´es se habr´a borrado de la aplicaci´on. Precondici´on: Usuario autentificado Par´ametros: Sitio de inter´es seleccionado Flujo de Ejecuci´on: 1. El usuario selecciona un sitio de inter´es de entre los disponibles para la capa seleccionada 2. El usuario hace clic en el bot´on de Eliminar Sitio de Inter´es 3. El sistema emite un mensaje preguntando al usuario si quiere continuar En caso de respuesta afirmativa, el sistema eliminar´a dicho sitio de inter´es de la base de datos y de la capa seleccionada Se informa al usuario de que el sitio de inter´es se ha eliminado Caminos Alternativos: Operaci´on cancelada (3) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El sitio de inter´es se habr´a borrado de la lista de elementos de la capa seleccionada del usuario. 5.2. REQUISITOS DEL SOFTWARE 125 Nombre: Crear Tour Autom´atico Descripci´on: El usuario puede dejar que la aplicaci´on cree un tour de manera autom´atica para la ruta seleccionada. Tras pulsar en Crear Tour Autom´atico, la aplicaci´on mover´ıa la c´amara hasta el punto inicial de la ruta e ir´ıa pasando por el resto de puntos y sitios de inter´es hasta llegar hasta el final. Precondici´on: Usuario autentificado Par´ametros: Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario selecciona una ruta de entre las disponibles 2. El usuario hace clic en Crear Tour Autom´atico 3. La aplicaci´on comienza a recorrer el tour de manera autom´atica: Hace que la c´amara pase por todos los puntos de la ruta desde el comienzo hasta el final Detiene la c´amara en los sitios de inter´es durante un intervalo corto de tiempo y continua con el recorrido Caminos Alternativos: Postcondici´on: La ruta se muestra sobre el globo terr´aqueo. 126 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Crear Tour Manual Descripci´on: Si el usuario decide crear un tour de forma manual, tras pulsar el bot´on para ello, la aplicaci´on le mostrar´a los controles para ello. Uno de los botones dar´a comienzo a la grabaci´on del tour, momento en el cual el usuario realizar´a las acciones que desee: movimientos de c´amara o visualizaci´on de sitios de inter´es por ejemplo. La aplicaci´on almacenar´a todos los movimientos realizados para dar forma al tour. Precondici´on: Usuario autentificado Par´ametros: Movimientos de c´amara Flujo de Ejecuci´on: 1. El usuario hace clic en Crear Tour Manual 2. La aplicaci´on muestra los controles dedicados para ello 3. El usuario hace clic en Iniciar Grabaci´on 4. Mientras el usuario recorre el globo de manera manual, la aplicaci´on ir´a recogiendo todas las operaciones realizadas 5. Cuando el usuario termine el tour har´a clic en Finalizar Grabaci´on, donde la aplicaci´on pedir´a al usuario un nombre para guardar el tour 6. Tras especificar el nombre y aceptar, el tour creado se a˜nade a la lista de tours del usuario Caminos Alternativos: Operaci´on cancelada (4) Se interrumpe la operaci´on y se vuelve al punto de partida Operaci´on cancelada (6) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El tour creado se a˜nadir´a a la lista de tours del usuario. 5.2. REQUISITOS DEL SOFTWARE 127 Nombre: Visualizar Tour Descripci´on: Cuando el usuario haya seleccionado uno de los tours disponibles, y pulse en el bot´on de visualizaci´on de tour, la aplicaci´on le mostrar´a los controles de reproducci´on dedicados para ello. El usuario har´a clic en “Play” y empezar´a a verse el tour. Adem´as hay controles de “Pause”, “Rewind”, “Forward” y “Stop” que dar´a por finalizado al tour. Precondici´on: Usuario autentificado Par´ametros: Tour seleccionado Flujo de Ejecuci´on: 1. El usuario selecciona un tour de los que tiene disponibles en su lista 2. El usuario hace clic en Visualizar Tour 3. La aplicaci´on muestra los controles de reproducci´on del tour 4. El usuario hace clic en Iniciar Reproducci´on 5. La aplicaci´on comenzar´a a desplazar la c´amara por los puntos del tour hasta llegar al ´ultimo a) Opcionalmente, y si el tour dispone de dicha funcionalidad, empezar´a a sonar una gu´ıa describiendo las caracter´ısticas del tour 6. La aplicaci´on sale del modo de Reproducir Tour Caminos Alternativos: Reproducci´on cancelada (5) El usuario hace clic en Detener Reproducci´on y se vuelve al punto de partida Postcondici´on: La reproducci´on del tour habr´a finalizado, y la aplicaci´on estar´a disponible para otras operaciones. 128 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Modificar Tour Descripci´on: La modificaci´on del tour permite modificar los metadatos asociados al tour seleccionado. Para ello, el usuario debe hacer clic en el bot´on Modificar Tour. La aplicaci´on mostrar´a un cuadro donde el usuario puede cambiar diversos aspectos del tour. Sin embargo, no puede cambiar el recorrido del tour, para ello deber´ıa crear uno nuevo. Precondici´on: Usuario autentificado Par´ametros: Tour seleccionado Flujo de Ejecuci´on: 1. El usuario selecciona un tour de los que tiene disponibles en su lista 2. El usuario hace clic en Modificar Tour 3. La aplicaci´on muestra un formulario donde el usuario puede a˜nadir diversa informaci´on sobre el tour: descripci´on, audiogu´ıa, etc. 4. El usuario hace clic en Aceptar y el sistema guardar´a en la base de datos el tour actualizado Caminos Alternativos: Postcondici´on: El tour se habr´a actualizado con los nuevos datos a˜nadidos de la aplicaci´on. 5.2. REQUISITOS DEL SOFTWARE 129 Nombre: Renombrar Tour Descripci´on: El usuario puede cambiar el nombre del tour en cualquier momento. Con pulsar en el bot´on correspondiente la aplicaci´on deja que el usuario puede escribir un nuevo nombre. La aplicaci´on seleccionar´a completamente el viejo nombre para que el usuario puede escribirlo directamente. Precondici´on: Usuario autentificado Par´ametros: Tour seleccionado Flujo de Ejecuci´on: 1. El usuario hace clic en un tour 2. El usuario hace clic en el bot´on de Renombrar Tour 3. El sistema queda en estado de espera hasta que el usuario introduce el nuevo nombre 4. Tras introducir el nombre, el sistema comprueba si no existe otro tour del usuario con el mismo nombre 5. Si el nombre es correcto se actualiza el tour en la base de datos del sistema Caminos Alternativos: Nombre en uso (4) Se emite un mensaje informando al usuario y se vuelve al punto de partida Postcondici´on: El tour se habr´a actualizado con el nuevo nombre. 130 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Eliminar Tour Descripci´on: Si un usuario no desea utilizar un tour creado con anterioridad, puede eliminarlo de la aplicaci´on usando el bot´on destinado para ello tras seleccionar el tour deseado. La aplicaci´on le solicitar´a al usuario confirmar la operaci´on. Tras ello, el tour eliminado no aparecer´a en la lista de tours del usuario. Precondici´on: Usuario autentificado Par´ametros: Tour seleccionado Flujo de Ejecuci´on: 1. El usuario selecciona un tour de entre los disponibles 2. El usuario hace clic en el bot´on de Eliminar Tour 3. El sistema emite un mensaje preguntando al usuario si quiere continuar En caso de respuesta afirmativa, el sistema eliminar´a dicho tour de la base de datos Se informa al usuario de que el tour se ha eliminado Caminos Alternativos: Operaci´on cancelada (3) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El tour se habr´a borrado de la lista de tours del usuario. 5.2. REQUISITOS DEL SOFTWARE 131 5.2.3.3. Web 2.0 Nombre: Compartir Rutas Descripci´on: El usuario puede compartir las rutas que posea con otros usuarios que tenga agregados a trav´es de la aplicaci´on. Para ello, el usuario debe seleccionar la ruta que desee y pulsar en el bot´on Compartir Ruta. La aplicaci´on le pedir´a al usuario el destinatario de la ruta. Una vez elegido, la ruta se enviar´a al usuario de destino. Precondici´on: Usuario autentificado Que el usuario tenga al menos un usuario agregado Que el usuario tenga al menos una ruta guardada Par´ametros: Usuario de destino Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario hace clic en el nombre de una las rutas que posee 2. El usuario hace clic en Compartir Ruta 3. La aplicaci´on muestra al usuario la lista de usuarios disponibles 4. El usuario selecciona uno de la lista y hace clic en Enviar 5. La ruta seleccionada aparecer´a en la lista de rutas compartidas del otro usuario Caminos Alternativos: Operaci´on cancelada (4) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El usuario de destino habr´a recibido la ruta enviada por el usuario de la aplicaci´on. 132 CAP´ ITULO 5. DESARROLLO DEL PROYECTO Nombre: Compartir Archivos Descripci´on: De forma similar al caso de uso anterior, el usuario puede enviar archivos a otros usuarios que tenga agregados. Para conseguirlo debe seleccionar el fichero que quiere compartir –fotos, v´ıdeos, modelos 3D o documentos– y pulsar en Compartir Archivo. La aplicaci´on le pedir´a al usuario el destinatario del archivo. Una vez elegido, el archivo se enviar´a al usuario de destino. Precondici´on: Usuario autentificado Que el usuario tenga al menos un usuario agregado Que el usuario tenga al menos un archivo guardado Par´ametros: Usuario de destino Archivo seleccionado Flujo de Ejecuci´on: 1. El usuario hace clic en alguno de los archivos que posee: fotos, v´ıdeos, modelos 3D o documentos; dentro de sus listas respectivas 2. El usuario hace clic en Compartir 3. La aplicaci´on muestra al usuario la lista de usuarios disponibles 4. El usuario selecciona uno de la lista y hace clic en Enviar 5. El archivo seleccionado aparecer´a en la lista de rutas compartidas del otro usuario Caminos Alternativos: Operaci´on cancelada (4) Se interrumpe la operaci´on y se vuelve al punto de partida Postcondici´on: El usuario de destino habr´a recibido el archivo enviado por el usuario de la aplicaci´on. 5.2. REQUISITOS DEL SOFTWARE 133 Nombre: Rutas Favoritas Descripci´on: El usuario puede categorizar las rutas que posea, ya sean propias o compartidas, utilizando una marca de “Ruta Favorita”. Ello le permite acceder de manera m´as r´apida y accesible a las rutas que use con m´as frecuencia. Estas rutas aparecer´an en una lista aparte. Precondici´on: Usuario autentificado Par´ametros: Ruta seleccionada Flujo de Ejecuci´on: 1. El usuario selecciona una de las rutas de las que tiene disponibles, ya sean propias o compartidas por parte de otros usuarios 2. El hace clic en Marcar como Ruta Favorita 3. La ruta seleccionada se a˜nadir´a a la lista de rutas favoritas Caminos Alternativos: Postcondici´on: La ruta seleccionada se habr´a a˜nadido a la lista de rutas favoritas. 236 CAP´ ITULO 6. CONCLUSIONES Y TRABAJO FUTURO Ap´endice A Frameworks de desarrollo En este ap´endice se har´a un barrido por los diferentes frameworks de desarrollo para aplicaciones web en PHP. Debido a la gran cantidad de frameworks existentes se har´a una descripci´on de aquellos m´as importantes y extendidos. Al final de este ap´endice se ilustrar´an mediante un cuadro una gran bater´ıa de frameworks existentes en PHP. A.1. CakePHP CakePHP1es un marco de desarrollo r´apido para PHP, libre y de c´odigo abierto. Se trata de una estructura que sirve de base a los programadores para que ´estos puedan crear aplicaciones Web. Permite al desarrollador que pueda trabajar de forma estructurada y r´apida, sin p´erdida de flexibilidad. CakePHP naci´o originalmente como un intento de portar la arquitectura y funcionalidad de Ruby on Rails a PHP, algo que otros frameworks han intentado de varias formas. Aunque CakePHP tiene muchas similaridades con el popular framework de Ruby, ha evolucionado de manera independiente de acuerdo a las particularidades del lenguaje PHP. Con CakePHP el desarrollo web se simplifica pues ofrece las herramientas para que el desarrollador empiece a escribir el c´odigo que realmente necesita: la l´ogica espec´ıfica de la aplicaci´on. Con una copia de CakePHP, ya se dispone de un importante conjunto de herramientas que hacen que el desarrollador no tenga que comenzar de cero. CakePHP tiene un equipo de desarrolladores y una comunidad activos, lo que a˜nade valor al proyecto. Con CakePHP, adem´as de no tener que reinventar la rueda, el n´ucleo de la aplicaci´on se mejora constantemente y est´a bien probado. Esta es una lista breve con las caracter´ısticas que posee CakePHP: Comunidad amigable. Licencia flexible. Compatible con las versiones de PHP 5.2.6 y superiores. CRUD integrado para la interacci´on con la base de datos. 1http://www.cakephp.org/ 237 238 AP´ ENDICE A. FRAMEWORKS DE DESARROLLO Andamiaje de c´odigo (scaffolding). Generaci´on autom´atica de c´odigo. Arquitectura Modelo Vista Controlador (MVC). Despachador de peticiones (dispatcher), con URLs y rutas personalizadas. Validaci´on integrada. Plantillas r´apidas y flexibles (sintaxis de PHP, con ayudantes -helpers-). Ayudantes para AJAX, JavaScript, formularios HTML y m´as. Componentes de Email, Cookies, Seguridad, Sesi´on y Manejo de solicitudes. Listas de Control de Acceso (ACL) flexibles. Limpieza de datos. Cach´e flexible. Localizaci´on. Funciona en cualquier subdirectorio del sitio web, con poca o ninguna configuraci´on del servidor web (normalmente Apache). A.2. CodeIgniter CodeIgniter2es un framework para aplicaciones web de c´odigo abierto para crear sitios web din´amicos con PHP. Su objetivo es permitir que los desarrolladores puedan realizar proyectos mucho m´as r´apido que creando toda la estructura desde cero, brindando un conjunto de bibliotecas para tareas comunes, as´ı como una interfaz simple y una estructura l´ogica para acceder esas bibliotecas. CodeIgniter est´a basado ligeramente en el popular patr´on de desarrollo Modelo Vista Controlador (MVC). Aunque las clases de vista y el controlador son una parte necesaria del desarrollo en CodeIgniter, los modelos son opcionales. Suele destacarse que CodeIgniter es m´as r´apido que muchos otros entornos, la mayor´ıa de los m´odulos o clases que ofrece se pueden cargar de manera opcional, s´olo cuando se van a utilizar realmente. Estas son las principales caracter´ısticas de CodeIgniter: Sistema basado en Modelo Vista Controlador (MVC). Es extremadamente ligero. Clases completas para bases de datos con soporte para varias plataformas. Bases de datos con soporte Active Record. 2http://ellislab.com/codeigniter A.2. CODEIGNITER 239 Validaci´on de formularios y datos. Seguridad y Filtrado XSS. Manejo de sesiones. Clases para el env´ıo de Emails: adjuntos, HTML/Texto, soporte de m´ultiples protocolos. Biblioteca para la manipulaci´on de im´agenes (recorte, cambio de tama˜no, etc.). Soporta GD, ImageMagick y NetPBM. Clase para la subida de ficheros. Clase para FTP. Localizaci´on. Paginaci´on. Cifrado de Datos. Benchmarking. Full Page Caching. Registro de errores. Profiling de la aplicaci´on. Clase Calendario. Clase “User Agent”. Clase Codificaci´on. Clase Motor de Plantillas. Clase Trackback. Librer´ıa XML-RPC. Clase de pruebas unitarias. URLs amistosas para los motores de b´usqueda. Enrutado de URIs flexible. Gran biblioteca de funciones “auxiliares”. 240 AP´ ENDICE A. FRAMEWORKS DE DESARROLLO A.3. Prado PRADO3es un framework basado en componentes y con una programaci´on dirigida por eventos, para desarrollos de aplicaciones Web en PHP5. Las siglas de PRADO se corresponden con PHP Rapid Application Development Object-oriented. El principal objetivo de PRADO es utilizar al m´aximo la reutilizaci´on en la programaci´on Web. Entendiendo por reutilizaci´on, no solamente reutilizar el c´odigo propio, sino el de otros programadores de una manera f´acil. Evita el esfuerzo de reinventar nuevamente la rueda y adem´as posibilita disminuir notablemente los tiempos de desarrollo. La introducci´on del concepto de componentes tiene este prop´osito. Para alcanzar el prop´osito mencionado, PRADO estipula un protocolo para escribir y usar componentes para construir una aplicaci´on Web. Un componente es una pieza de programa autocontenida y que puede ser reutilizado con una m´ınima personalizaci´on del mismo. Nuevos componentes pueden ser creados por una simple composici´on de componentes existentes. Para facilitar la interacci´on con los componentes, PRADO implementa el paradigma de la programaci´on dirigida por eventos (event-driven) que permite la delegaci´on de comportamientos extensibles a los componentes. Las actividades de los usuarios finales, tales como hacer clic en un bot´on de un formulario, son capturados como eventos en el lado del servidor. Los m´etodos o funciones deben ser enlazados a dichos eventos de tal manera que cuando los eventos sucedan, estos son invocados autom´aticamente para responder a dicho evento. Comparado con la programaci´on Web tradicional en la cual los desarrolladores tienen que tratar directamente con las variables POST y GET, la programaci´on dirigida por eventos ayuda a los desarrolladores enfocarse mejor en las necesidades l´ogicas y reducir significativamente el c´odigo de bajo nivel repetitivo. En resumen, desarrollar aplicaciones Web con PRADO principalmente involucra instant´aneamente tipos de componentes predesarrollados, configurarlos mediante sus propiedades, responder a sus eventos escribiendo funciones manipuladoras de los mismos, y agrup´andolos dentro de paginas para la aplicaci´on. Es muy similar al kit de herramientas RAD de Borland Delphi y Microsoft Visual Basic, que son utilizadas para desarrollar aplicaciones (Interfaces Gr´aficas de Usuario, GUI) de escritorio. Estas son las principales caracter´ısticas de PRADO: Reutilizaci´on: Los c´odigos que se rigen por el protocolo basado en componentes de PRADO son altamente reutilizables. Esto beneficia a los equipos de desarrollo a largo plazo, ya que pueden reutilizar sus trabajos anteriores e integrar otras partes de trabajo con facilidad. Programaci´on dirigida por eventos: Las actividades del usuario final, tales como como hacer clic en un bot´on de enviar, son capturadas como eventos del servidor permitiendo que los desarrolladores tengan un mejor enfoque en las interacciones del usuario. Integraci´on de equipo: La capa de presentaci´on y la capa l´ogica son almacenados por 3http://www.pradosoft.com/ A.4. SYMFONY 241 separado. Las aplicaciones en PRADO pueden ser personalizadas con temas. Controles web potentes: PRADO viene con un conjunto de componentes que se ocupan de las interfaces de usuario Web. Se puede crear p´aginas web altamente interactivas con unas pocas l´ıneas de c´odigo. Fuerte soporte de bases de datos: Desde la versi´on 3.1, PRADO ha sido equipada con soporte total de bases de datos escrito de forma nativa y, por tanto, encaja con el resto del framework PRADO. De acuerdo a la complejidad de los objetos de negocio, se puede optar por utilizar la PDO simple, basada en el acceso a los datos, el ampliamente conocido Active Record o el mapa completo de los objetos del negocio SqlMap. Soporte de AJAX sin fisuras: El uso de AJAX en PRADO se ha facilitado gracias a los Active Controls, introducidos desde la versi´on 3.1. Se puede escribir una aplicaci´on AJAX sin escribir una sola l´ınea de c´odigo JavaScript. De hecho, la utilizaci´on de los Active Controls no es muy diferente a la utilizaci´on de componentes no AJAX. Soporte de I18N y L10N: PRADO incluye soporte completo para crear aplicaciones con m´ultiples idiomas. Compatibilidad XHTML: Las p´aginas Web generadas por PRADO son compatibles con XHTML. Albergar trabajos ya existentes: PRADO es un framework gen´erico, con especial atenci´on a la capa de presentaci´on. No excluye a desarrolladores que hacen uso de la mayor´ıa de las actuales bibliotecas de clase o kits de herramientas. Por ejemplo, uno puede usar ADOdb o Creole para tratar con base de datos en su aplicaci´on PRADO. Otras caracter´ısticas: Potente gesti´on de errores y/o excepciones, registro de mensajes; cach´e gen´erico y memoria cach´e de salida selectiva, manejo de errores personalizable y localizable, autentificaci´on y autorizaci´on extensibles, prevenci´on de medidas de seguridad tales como Cross-Site Script (XSS), protecci´on de cookies, etc. A.4. Symfony Symfony4es un completo framework dise˜nado para optimizar el desarrollo de las aplicaciones web basado en el patr´on Modelo Vista Controlador (MVC). Para empezar, separa la l´ogica de negocio, la l´ogica de servidor y la presentaci´on de la aplicaci´on web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicaci´on web compleja. Adem´as, automatiza las tareas m´as comunes, permitiendo al desarrollador dedicarse por completo a los aspectos espec´ıficos de cada aplicaci´on. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicaci´on web. Symfony est´a desarrollado completamente en PHP 5.3. Symfony es compatible con la mayor´ıa de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y Microsoft SQL 4http://symfony.com/ 242 AP´ ENDICE A. FRAMEWORKS DE DESARROLLO Server. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows. Las principales caracter´ısticas de Symfony son: F´acil de instalar y configurar en la mayor´ıa de plataformas (y con la garant´ıa de que funciona correctamente en los sistemas Windows y *nix est´andares). Independiente del sistema gestor de bases de datos. Su capa de abstracci´on y el uso de Propel, permiten cambiar con facilidad de SGBD en cualquier fase del proyecto. Utiliza programaci´on orientada a objetos, de ah´ı que sea imprescindible PHP 5. Sencillo de usar en la mayor´ıa de casos, aunque es preferible para el desarrollo de grandes aplicaciones Web que para peque˜nos proyectos. Aunque utiliza MVC, tiene su propia forma de trabajar en este aspecto, con variantes del MVC cl´asico como la capa de abstracci´on de base de datos, el controlador frontal y las acciones. Basado en la premisa de “convenir en vez de configurar”, en la que el desarrollador s´olo debe configurar aquello que no es convencional. Sigue la mayor´ıa de mejores pr´acticas y patrones de dise˜no para la web. Preparado para aplicaciones empresariales y adaptable a las pol´ıticas y arquitecturas propias de cada empresa, adem´as de ser lo suficientemente estable como para desarrollar aplicaciones a largo plazo. C´odigo f´acil de leer que incluye comentarios de phpDocumentor y que permite un mantenimiento muy sencillo. F´acil de extender, lo que permite su integraci´on con las bibliotecas de otros fabricantes. Una potente l´ınea de comandos que facilitan generaci´on de c´odigo, lo cual contribuye a ahorrar tiempo de trabajo. Permite la internacionalizaci´on para la traducci´on del texto de la interfaz, los datos y el contenido de localizaci´on. La presentaci´on usa templates ylayouts que pueden ser construidos por dise˜nadores de HTML que no posean conocimientos del framework. Los formularios soportan la validaci´on autom´atica, lo cual asegura mejor calidad de los datos en las base de datos y una mejor experiencia para el usuario. El manejo de cache reduce el uso de banda ancha y la carga del servidor. La facilidad de soportar autenticaci´on y credenciales facilita la creaci´on de ´areas restringidas y manejo de seguridad de los usuarios. A.5. YII 243 El enrutamiento y las URLs inteligentes hacen amigable las direcciones de las p´aginas de la aplicaci´on. Las listas son m´as amigables, ya que permite la paginaci´on, clasificaci´on y filtrado autom´aticos. Los plugins proveen un alto nivel de extensibilidad. La interacci´on con AJAX es mucho m´as sencilla. A.5. Yii Yii5es un framework PHP basado en componentes de alto rendimiento para desarrollar aplicaciones Web a gran escala. Permite la m´axima reutilizaci´on en la programaci´on web y puede acelerar el proceso de desarrollo. Est´a escrito en PHP5 y es software libre liberado bajo una licencia BSD. Tiene la concepci´on de hacer las cosas de manera sencilla, elegante y r´apidas, ayudando con esto a construir aplicaciones eficientes, que pueden ser mantenidas f´acilmente y escalables. Sigue el patr´on MVC, lo que garantiza una clara separaci´on de la l´ogica del negocio y la presentaci´on. Fomenta la sinergia en equipos de desarrollo y promueve m´etodos de trabajo que son ideales para combinar con metodolog´ıas ´agiles. Algunas caracter´ısticas de Yii incluyen: Patr´on de dise˜no Modelo Vista Controlador (MVC). Database Access Objects (DAO), query builder, Active Record y migraci´on de base de datos. Integraci´on con jQuery. Entradas de Formulario y validaci´on. Widgets de AJAX, como autocompletado de campos de texto y dem´as. Soporte de Autenticaci´on incorporado. Adem´as soporta autorizaci´on v´ıa “Role-Based Access Control” (RBAC) jer´arquico. Personalizaci´on de aspectos y temas. Generaci´on compleja autom´atica de WSDL, especificaciones y administraci´on de peticiones Web service. Internacionalizaci´on y localizaci´on (I18N y L10N). Soporta traducciones, formato de fecha y hora, formato de n´umeros y localizaci´on de la vista. Esquema de caching por capas. Soporta el cache de datos, cache de p´aginas, cache por fragmentos y contenido din´amico. El medio de almacenamiento del cache puede ser cambiado. 5http://www.yiiframework.com/ 244 AP´ ENDICE A. FRAMEWORKS DE DESARROLLO Manejo de errores y logging. Los errores son manejados y personalizados, y los registros de mensajes pueden ser categorizados, filtrados y movidos a diferentes destinos. Las medidas de seguridad incluyen la prevenci´on Cross-Site Scripting (XSS), prevenci´on Cross-Site Request Forgery (CSRF), prevenci´on de la manipulaci´on de cookies, etc. Herramientas para pruebas unitarias y funcionales basados en PHPUnit y Selenium. Generaci´on autom´atica de c´odigo para el esqueleto de la aplicaci´on, aplicaciones CRUD, etc. Generaci´on de c´odigo por componentes de Yii y la herramienta por linea de comandos cumple con los est´andares de XHTML. Cuidadosamente dise˜nado para trabajar bien con c´odigo de terceros. Por ejemplo, es posible usar el c´odigo de PHP o Zend Framework en una aplicaci´on Yii. A.6. Zend Zend6Framework (ZF) es un framework de c´odigo abierto para desarrollar aplicaciones web y servicios web con PHP5. ZF es una implementaci´on que usa c´odigo 100 % orientado a objetos. La estructura de los componentes de ZF es algo ´unico, cada componente est´a construido con una baja dependencia de otros componentes. Esta arquitectura d´ebilmente acoplada permite a los desarrolladores utilizar los componentes por separado. Aunque se pueden utilizar de forma individual, los componentes de la biblioteca est´andar de Zend Framework conforman un potente y extensible framework de aplicaciones web al combinarse. ZF ofrece un gran rendimiento y una implementaci´on del patr´on MVC, una abstracci´on de base de datos f´acil de usar, un componente de formularios que implementa la prestaci´on de formularios HTML, validaci´on y filtrado para que los desarrolladores puedan consolidar todas las operaciones usando de una manera sencilla la interfaz orientada a objetos. Otros componentes proporcionan autentificaci´on de usuarios y autorizaci´on. Tambi´en existen componentes que implementan bibliotecas de cliente para acceder de forma sencilla a los servicios web m´as populares. Otras caracter´ısticas a destacar son: Cuenta con m´odulos para manejar archivos PDF, canales RSS, Web Services (Amazon, Flickr, Yahoo), etc. El framework tambi´en incluye objetos para las diferentes bases de datos, por lo que es extremadamente simple para consultar bases de datos, sin tener que escribir ninguna consulta SQL. Una soluci´on para el acceso a base de datos que balancea el ORM con eficiencia y simplicidad. 6http://www.framework.zend.com/ A.7. LISTADO DE FRAMEWORKS PHP 245 Completa documentaci´on y tests de alta calidad. Soporte avanzado para i18n (internacionalizaci´on). Un buscador compatible con Lucene. Robustas clases para autenticaci´on y filtrado de entrada. Clientes para servicios web, incluidos Google Data APIs y StrikeIron. Muchas otras clases ´utiles para hacerlo tan productivo como sea posible. A.7. Listado de frameworks PHP A continuaci´on se muestra una recopilaci´on de la mayor´ıa de frameworks en PHP para aplicaciones web existentes en el mercado, tanto libres como comerciales. Cada uno de ellos presenta una diversa lista de funcionalidades, desde las m´as b´asicas hasta las m´as avanzadas que poseen algunos frameworks. Resaltar que el grado de madurez de todos los frameworks aqu´ı listados var´ıa, lo que hace necesario un trabajo previo de an´alisis a la hora de seleccionar alguno de ellos cuando se vaya a realizar una aplicaci´on. En conclusi´on, la tabla resultante, obtenida a partir de diversas fuentes7 8 entre otras, es la siguiente: Cuadro A.1: Listado de frameworks PHP Akelos ash.MVC CakePHP CodeIgniter DIY Fat-Free Framework (F3) FuelPHP Fusebox Hazaar MVC Horde HTML5 Builder KumbiaPHP Lithium Osezno PHP Framework PHP on TRAX PHPDevShell PHPixie PhpOpenbiz PHPWork Prado Seagull Symfony TYPO3 Flow WACT WASP Yii Zend Zeta Components 7http://www.phpframeworks.com/ 8http://en.wikipedia.org/wiki/Category:PHP frameworks 252 ´ INDICE DE FIGURAS 5.96. Interacci´on de Objetos: Recordar Contrase˜na ..................178 5.97. Diagrama de clases: Recordar Contrase˜na ....................178 5.98. Interacci´on de Objetos: Modificar Datos Personales ..............179 5.99. Diagrama de clases: Modificar Datos Personales ................179 5.100. Interacci´on de Objetos: Cambiar Contrase˜na ..................180 5.101. Diagrama de clases: Cambiar Contrase˜na ....................180 5.102. Interacci´on de Objetos: Darse de Baja ......................181 5.103. Diagrama de clases: Darse de Baja ........................181 5.104. Interacci´on de Objetos: Cerrar Sesi´on ......................182 5.105. Diagrama de clases: Cerrar Sesi´on ........................182 5.106. Interacci´on de Objetos: A˜nadir Usuario .....................183 5.107. Diagrama de clases: A˜nadir Usuario .......................183 5.108. Interacci´on de Objetos: Eliminar Usuario ....................184 5.109. Diagrama de clases: Eliminar Usuario ......................184 5.110. Interacci´on de Objetos: Ver Usuario .......................185 5.111. Diagrama de clases: Ver Usuario .........................185 5.112. Interacci´on de Objetos: Modificar Usuario ...................186 5.113. Diagrama de clases: Modificar Usuario .....................186 5.114. Interacci´on de Objetos: Crear Capa .......................187 5.115. Diagrama de clases: Crear Capa .........................187 5.116. Interacci´on de Objetos: Modificar Capa .....................188 5.117. Diagrama de clases: Modificar Capa .......................188 5.118. Interacci´on de Objetos: Renombrar Capa ....................189 5.119. Diagrama de clases: Renombrar Capa ......................189 5.120. Interacci´on de Objetos: Eliminar Capa .....................190 5.121. Diagrama de clases: Eliminar Capa .......................190 5.122. Interacci´on de Objetos: Insertar Puntos .....................191 5.123. Diagrama de clases: Insertar Puntos .......................191 5.124. Interacci´on de Objetos: Insertar Insertar Elemento Audiovisual ........192 5.125. Diagrama de clases: Insertar Insertar Elemento Audiovisual ..........192 5.126. Interacci´on de Objetos: Guardar Ruta ......................193 5.127. Diagrama de clases: Guardar Ruta ........................193 5.128. Interacci´on de Objetos: Modificar Ruta .....................194 5.129. Diagrama de clases: Modificar Ruta .......................194 5.130. Interacci´on de Objetos: Visualizar Ruta (contenedor) .............195 5.131. Diagrama de clases: Visualizar Ruta (contenedor) ...............195 5.132. Interacci´on de Objetos: Eliminar Ruta .....................196 5.133. Diagrama de clases: Eliminar Ruta .......................196 5.134. Interacci´on de Objetos: Renombrar Ruta ....................197 5.135. Diagrama de clases: Renombrar Ruta ......................197 5.136. Interacci´on de Objetos: A˜nadir Sitio de Inter´es .................198 5.137. Diagrama de clases: A˜nadir Sitio de Inter´es ...................198 ´ INDICE DE FIGURAS 253 5.138. Interacci´on de Objetos: Visualizar Sitio de Inter´es ...............199 5.139. Diagrama de clases: Visualizar Sitio de Inter´es .................199 5.140. Interacci´on de Objetos: Eliminar Sitio de Inter´es ................200 5.141. Diagrama de clases: Eliminar Sitio de Inter´es ..................200 5.142. Interacci´on de Objetos: Modificar Sitio de Inter´es ...............201 5.143. Diagrama de clases: Modificar Sitio de Inter´es .................201 5.144. Interacci´on de Objetos: Renombrar Sitio de Inter´es ..............202 5.145. Diagrama de clases: Renombrar Sitio de Inter´es ................202 5.146. Tipos de Tours ...................................203 5.147. Interacci´on de Objetos: Crear Tour Autom´atico ................204 5.148. Diagrama de clases: Crear Tour Autom´atico ..................204 5.149. Interacci´on de Objetos: Visualizar Tour .....................205 5.150. Diagrama de clases: Visualizar Tour .......................205 5.151. Interacci´on de Objetos: Eliminar Tour ......................206 5.152. Diagrama de clases: Eliminar Tour ........................206 5.153. Interacci´on de Objetos: Modificar Tour .....................207 5.154. Diagrama de clases: Modificar Tour .......................207 5.155. Interacci´on de Objetos: Renombrar Tour ....................208 5.156. Diagrama de clases: Renombrar Tour ......................208 5.157. Interacci´on de Objetos: Crear Tour Manual ...................209 5.158. Diagrama de clases: Crear Tour Manual .....................209 5.159. Interacci´on de Objetos: Activar Capa (Crear) .................210 5.160. Diagrama de clases: Activar Capa (Crear) ...................210 5.161. Interacci´on de Objetos: Desplegar Capa .....................211 5.162. Diagrama de clases: Desplegar Capa .......................211 5.163. Interacci´on de Objetos: Visualizar Informaci´on .................212 5.164. Diagrama de clases: Visualizar Informaci´on ...................212 5.165. Interacci´on de Objetos: Ir a ............................213 5.166. Diagrama de clases: Ir a .............................213 5.167. Interacci´on de Objetos: Ver Ruta ........................214 5.168. Diagrama de clases: Ver Ruta ..........................214 5.169. Interacci´on de Objetos: Ver Tour .........................215 5.170. Diagrama de clases: Ver Tour ..........................215 5.171. Interacci´on de Objetos: Ver Sitios de Inter´es ..................216 5.172. Diagrama de clases: Ver Sitios de Inter´es ....................216 5.173. Interacci´on de Objetos: Seleccionar Capas ...................217 5.174. Diagrama de clases: Seleccionar Capas .....................217 5.175. Interacci´on de Objetos: Compartir Rutas ....................218 5.176. Diagrama de clases: Compartir Rutas ......................218 5.177. Interacci´on de Objetos: Compartir Archivos ..................219 5.178. Diagrama de clases: Compartir Archivos ....................219 5.179. Interacci´on de Objetos: Rutas Favoritas .....................220 254 ´ INDICE DE FIGURAS 5.180. Diagrama de clases: Rutas Favoritas .......................220 5.181. Interacci´on de Objetos: Presentar Otras Rutas .................221 5.182. Diagrama de clases: Presentar Otras Rutas ...................221 5.183. Interacci´on de Objetos: Comunicarse con otras Redes Sociales ........222 5.184. Diagrama de clases: Comunicarse con otras Redes Sociales ..........222 5.185. Interacci´on de Objetos: Escribir Comentarios ..................223 5.186. Diagrama de clases: Escribir Comentarios ....................223 5.187. Interacci´on de Objetos: Chatear .........................224 5.188. Diagrama de clases: Chatear ...........................224 5.189. Interacci´on de Objetos: Enviar Email ......................225 5.190. Diagrama de clases: Enviar Email ........................225 5.191. Interacci´on de Objetos: Crear Comunidades ..................226 5.192. Diagrama de clases: Crear Comunidades ....................226 5.193. Pantalla Inicial ...................................230 5.194. Registro de usuarios ................................231 5.195. Pantalla Principal .................................231 ´ Indice de cuadros 3.1. Herramientas Software ............................... 31 4.1. Gesti´on del PFC .................................. 42 4.2. Realizaci´on y tramitaci´on de la propuesta .................... 43 4.3. Cuestiones previas ................................. 43 4.4. Desarrollo del PFC ................................. 44 4.5. Validaci´on y publicidad .............................. 45 4.6. Presentaci´on y defensa ............................... 45 4.7. Resumen de la planificaci´on ............................ 45 4.8. Costes de personal ................................. 48 4.9. Costes inventariables ................................ 48 4.10. Costes fungibles ................................... 48 4.11. Costes indirectos .................................. 49 4.12. Coste total ..................................... 49 A.1. Listado de frameworks PHP ............................245 255 256 ´ INDICE DE CUADROS Bibliograf´ıa [BRJ99] Grady Booch, James Rumbaugh y Ivar Jacobson, UML: El Lenguaje Unificado de Modelado, Addison Wesley, 1999. [DM02] C. W. Dawson y G. Mart´ın, El Proyecto de Fin de Carrera en Ingenier´ıa Inform´atica. Una Gu´ıa para el Estudiante, Prentince Hall, 2002. [Fou13] The CakeSoftware Foundation, The CakePHP Cookbook,http://book. cakephp.org/2.0/en/index.html, 2013. [GHJV03] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, Patrones de Dise˜no: Elementos de Software Orientado a Objetos Reutilizable, Addison Wesley, 2003. [Goo12] Google, Google Earth API,https://developers.google.com/earth/, 2012. [Gro13] The PHP Group, Documentaci´on de PHP,http://www.php.net/manual/es/, 2013. [Hil06] Linda L. Hill, Georeferencing: The Geographic Associations of Information, 2006. [JBR99] Ivar Jacobson, Grady Booch y James Rumbaugh, El Proceso Unificado de Desarrollo Software, Addison Wesley, 1999. [jF13] The jQuery Foundation, JQuery API,http://api.jquery.com/, 2013. [KK03] Per Kroll y Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP, Addison-Wesley Educational Publishers, 2003. [Lar03] Craig Larman, UML y Patrones: Una Introducci´on al An´alisis y Dise˜no Orientado a Objetos y al Proceso Unificado, Prentice Hall, 2003. [MR04] Juan Mendez-Rodr´ıguez, Notas sobre Producci´on Documental Cient´ıfica y T´ecnica, Instituto Universitario de Sistemas Inteligentes y Aplicaciones Num´ericas en Ingenier´ıa, ULPGC, 2004. [Ora11] Oracle, MySQL 5.5 Reference Manual, 2011. [Pre06] Roger S. Pressman, Ingenier´ıa del Software: Un Enfoque Pr´actico, McGraw-Hill, 2006. 257 258 BIBLIOGRAF´ IA [RS07] Doug Rosenberg y Matt Stephens, Use Case Driven Object Modeling with UML: Theory and Practice., Apress, 2007. [SKS06] Abraham Silverschatz, Henry F. Korth y S. Sudarshan, Fundamentos de Bases de Datos, McGraw-Hill, 2006. [Var13] Varios, Utility Libraries for the Google Earth API,http://code.google.com/ p/earth-api-utility-library/, 2013. [W3s13a] W3schools, Manual de CSS,http://www.w3schools.com/css/, 2013. [W3s13b] , Manual de HTML,http://www.w3schools.com/html/, 2013. [Wik13] Fundaci´on Wikimedia, Wikipedia: The Free Encyclopedia,http://www. wikipedia.org/, 2013. [WM07] Paul Wilton y Jeremy McPeak, Beginning Javascript, Wiley Publishing, Inc., 2007.