1
Portal-Viaje 2.0
Proyecto de Grado Juan Salvador Mendoza
Historial de versiones del documento
Versión
Fecha
Cambio
1.0
27/12/2013
Primera
entrega
documento final.
2.0
23/01/2015
Se adicionan cambios
sobre el nuevo trabajo y
se hacen correcciones
generales.
2
1
C
ONTENIDO
2 índice de imágenes y tablas ... 5
2.1 Índice tablas ... 5
2.2 índice imágenes ... 5
3 Introducción ... 6
3.1 Objetivos del proyecto ... 7
3.2 Tareas planteadas ... 7
3.3 Objetivos adicionales ... 8
3.4 Glosario ... 9
4 Metodología de trabajo ... 11
5 Análisis de tecnologías ... 12
5.1 Tecnologías utilizadas ... 12
5.1.1 Hibernate ... 12
5.1.2 Postgre y PostGis ... 12
5.1.3 Spring Framework ... 12
5.1.4 Optimizador Gurobi ... 12
5.1.5 Liferay ... 13
5.1.6 Vaadin ... 13
5.1.7 Esri y Arcgis ... 13
5.2 Análisis requerimientos no funcionales ... 13
Escalabilidad ... 13
5.3 Análisis del uso de las tecnologías ... 14
5.3.1 Portal de contenidos LifeRay ... 14
5.3.2 Hibernate y JPA ... 14
5.3.3 Vaadin ... 14
5.3.4 Esri y Arcgis ... 15
5.3.5 Otras tecnologías ... 15
6 Arquitectura del Portal Viaje “AS-IS” ... 16
6.1 Vistas analizadas ... 16
6.2 Punto de vista funcional ... 17
6.3 Punto de vista de desarrollo ... 20
3
6.5 Diagrama de dependencias tecnológicas (Por portlet) ... 23
6.6 Punto de vista de información ... 25
6.7 Modelo de ciclo de vida de la información ... 27
7 Pruebas de carga ... 28
8 Conclusiones sobre el estado del Portal“AS-IS”... 29
9 Lineamientos de la arquitectura “to-be” ... 30
9.1 Mejora en desempeño del tiempo de respuesta del portal web ... 30
9.2 Depurar dependencias y librerías no utilizadas ... 30
9.3 Dejar lista la arquitectura para una versión móvil del Portal ... 31
9.4 Crear una versión responsive del portal web de la aplicación ... 31
9.5 Generar una arquitectura documentada ... 31
9.6 Generar una arquitectura que permita migrar a otro servidor ... 32
10 Arquitectura resultado y proceso ... 32
10.1 Resultados ciclos ... 32
10.2 Objetivos logrados ... 33
10.2.1 Objetivos generales ... 33
10.2.2 Objetivos específicos... 34
10.3 Cambios en la arquitectura ... 34
10.3.1 Punto de vista Funcional ... 35
10.3.2 Punto de vista de desarrollo ... 36
10.3.3 Vista de despliegue ... 36
10.3.4 Diagrama de dependencias tecnológicas ... 36
10.3.5 Información y punto de vista de la información ... 37
10.4 Cambios en tecnologías ... 37
10.4.1 De Vaadin a JSP ... 37
11 Evaluación resultado y trabajo futuro ... 38
11.1 estado del Portal después del proyecto ... 38
11.2 Trabajo por realizar ... 38
11.2.1 Modificar el sistema de creación de rutas y ubicaciones para mejorar su usabilidad ... 38
11.2.2 Integrar el Portal Viaje con Facebook ... 38
11.2.3 Crear una aplicación móvil del Portal Viaje ... 38
11.2.4 Realizar la migración hacia un Portal de aplicaciones distinto ... 39
4
12 Trabajo adicional 2014 y nueva versión... 39
12.1 Objetivos planteados nueva etapa ... 39
13 Diseño de interfaz y usabilidad ... 40
13.1 Aspectos de usabilidad y diseño ... 40
13.2 Nuevas funcionalidades ... 40
13.3 Creador automático de rutas ... 41
13.4 Imágenes versión web ... 41
13.5 Imágenes versión móvil ... 47
14 Nueva arquitectura y tecnologías usadas ... 49
14.1 Requerimientos no funcionales adicionales ... 49
14.2 Tecnologías utilizadas ... 49
14.3 Punto de vista funcional ... 50
14.4 Punto de vista de desarrollo ... 52
14.5 Vista de despliegue ... 53
14.6 Vista de desarrollo de arquitectura móvil ... 54
15 Pruebas de carga nueva versión ... 54
16 Conclusiones finales y trabajo futuro ... 56
5
2
ÍNDICE DE IMÁGENES Y TABLAS
2.1
Í
NDICE TABLASTabla 1 Dependencias tecnológicas AS-IS ... 24
Tabla 2 Pruebas de carga pasajero sin cambios... 29
Tabla 3 Pruebas de carga conductor sin cambios ... 29
Tabla 4 Librerías eliminadas ... 37
Tabla 5 Pruebas de carga pasajero etapa final ... 55
Tabla 6 Pruebas de carga conductor etapa final... 56
2.2
ÍNDICE IMÁGENES Ilustración 1 Punto de vista Funcional AS-IS ... 17Ilustración 2 Punto de vista de desarrollo AS-IS ... 20
Ilustración 3 Punto de vista de despliegue AS-IS ... 22
Ilustración 4 Punto de vista de información AS-IS ... 26
Ilustración 5 Modelo ciclo de vida de la información ... 28
Ilustración 6 Primeros cambios puntos de vista funcional ... 35
Ilustración 7 Primeros cambios punto de vista de desarrollo ... 36
Ilustración 8 Página de login ... 42
Ilustración 9 Página principal ... 43
Ilustración 10 Página buscar viaje ... 44
Ilustración 11 Página crear ruta ... 45
Ilustración 12 Página resultado busqueda ... 46
Ilustración 13 Vista móvil inicio y viajes disponibles ... 47
Ilustración 14 Vista móvil ofertas ... 48
Ilustración 15 Punto de vista funcional etapa final... 50
Ilustración 16 Punto de vista de desarollo etapa final ... 52
Ilustración 17 Punto de vista de despliegue etapa final ... 53
6
3
I
NTRODUCCIÓN
En este documento se realiza un análisis de la arquitectura y dependencias tecnológicas del Portal Viaje 2.0 (http://viaje.uniandes.edu.co) y su relación con aspectos de usabilidad y desempeño que afectan al usuario final. Por otro lado, se plantean objetivos de mejora de los aspectos analizados, se presenta una arquitectura TO-BE del Portal y se concluye con los objetivos concretados para la mejora de la aplicación. El objetivo general del proyecto de grado es el de mejorar el Portal Viaje para que pueda ser aprovechado por los estudiantes de la universidad y por todos aquellos quienes tienen algún tipo de interés en este (por ejemplo, el SUR para hacer análisis de movilidad y tráfico). En particular, se busca corregir los errores que existen en la aplicación y estructurar la arquitectura para que ésta pueda evolucionar a una versión compatible con dispositivos móviles. El documento finaliza exponiendo el estado del Portal Viaje tras el desarrollo adicional realizado en pro de los objetivos planteados por el presente documento.
Antecedentes: El Portal Viaje fue una iniciativa que surgió de un grupo de estudiantes y profesores de la Universidad de los Andes como respuesta a los crecientes problemas de movilidad en la ciudad y al hecho de que la mayoría de bogotanos no comparte su carro. En octubre de 2010 se lanzó la primera versión del Portal (Universidad de los Andes, 2010), que permite a cualquier persona vinculada al campus (profesores, planta administrativa o estudiantes) compartir su vehículo o buscar alguien que lo lleve desde y hacia la universidad.
Aproximadamente año y medio después de su lanzamiento los desarrolladores del portal web decidieron lanzar una versión 2.0 del mismo. En realidad, esta versión, más que traer cambios profundos sobre la interfaz e interacción del usuario, trajo cambios sobre las tecnologías que utiliza el “back-end” del Portal para su funcionamiento, y es esta segunda versión la cual se analiza y trata en el documento.
7
Desde el lanzamiento de esta versión, el Portal Viaje se ha mantenido estático en su funcionamiento y no se han hecho cambios sustanciales sobre el código.
Por otro lado, en el año 2013 la diseñadora Natalia Ardila Torres realizó su tesis de grado en el tema de viajes compartidos. En dicha tesis se hace un planteamiento acerca de las razones por las cuales los estudiantes de la Universidad de Los Andes utilizarían un servicio de carro compartido (como el Portal Viaje) y se concluye con resultados y recomendaciones concretas para fomentar esta cultura en la universidad. La tesis también aborda el tema de la creación de una aplicación móvil con características específicas para materializar los hallazgos encontrados. Algunos de los lineamientos planteados para dicha aplicación móvil se tienen en cuenta en el desarrollo de los objetivos específicos de este proyecto de grado.
3.1
O
BJETIVOS DEL PROYECTOCon el fin de cumplir el objetivo general, se plantean los siguientes objetivos específicos:
O1.Dejar funcionando el Portal viaje para el inicio del semestre 2013-20
O2.Tener una versión mejorada del Portal Viaje para el inicio del semestre 2014-10, teniendo en cuenta los objetivos subsiguientes.
O3.Contar con una documentación actualizada y completa del Portal Viaje.
O4.Realizar los ajustes necesarios a la arquitectura del Portal Viaje para que su mantenimiento y modificación por parte de otros interesados en el futuro sea más sencilla.
O5.Realizar los ajustes necesarios a la arquitectura del Portal Viaje para que en el corto plazo sea viable y sencillo realizar una aplicación móvil.
3.2
T
AREAS PLANTEADASPara lograr dichos objetivos se plantearon las siguientes tareas concretas:
1. Corregir cualquier error que esté afectando actualmente al Portal Viaje y realizar las configuraciones necesarias para que el Portal quede funcionando sin cambios sustanciales en el código.
8
2. Habilitar algún tipo de medidor de tráfico de visitas sobre el Portal (si no lo hay) con el fin de medir la cantidad de usuarios que tiene la aplicación a lo largo de todo el semestre y de esa manera poder definir correctamente los escenarios de calidad que debe cumplir la nueva versión (tanto web como móvil).
3. Documentar la arquitectura tal y como está hoy.
4. Establecer una lista de requerimientos (nuevos o controles de cambio) para una versión nueva del Portal Viaje. Estos requerimientos son de dos tipos: (1) usabilidad que permitiría facilitar la interacción de los usuarios con el Portal; y (2) técnicos (por ejemplo cambios de tecnologías) con algunas justificaciones que permitan comprender la decisión.
5. Construir un mapa de ruta priorizado basado en ciclos que permita cumplir estos nuevos requerimientos. Cada ciclo debe tener un alcance definido en términos de requerimientos y debe ser complementado con un mapa de ruta global de los ciclos.
6. Actualizar la documentación de la arquitectura (ciclo a ciclo) que permita documentar cada uno de los cambios que se van a realizar. Al final, debe estar la versión final de la arquitectura que cumple con los requerimientos del caso.
7. Diseñar e implementar pruebas sobre los requerimientos no funcionales que validen en todo momento el cumplimiento de los escenarios de calidad. En particular, se tiene un requerimiento de desempeño y concurrencia que se definirá a partir de la medición de tráfico que se haga durante el semestre.
8. Montar y configurar un sistema de documentación y seguimiento de bugs a lo largo de todo el semestre y de aquí en adelante. Es importante que los usuarios puedan reportar errores de funcionalidad.
3.3
O
BJETIVOS ADICIONALESAdicionalmente se plantearon los siguientes objetivos específicos dentro del proyecto:
9
Descripción: El Portal Viaje debe tener integración con Facebook, las interacciones concretas se modelaran con ayuda de la diseñadora. En caso tal de que no se alcance a integrar este punto se debe dejar el código del Portal listo para integrarlo con las funcionalidades del API de Facebook.
Justificación: Se quiere aumentar la cantidad de usuarios que usen el Portal, al integrar con Facebook las personas pueden buscar amigos que realicen viajes y adicionalmente pueden negociar la ruta e intercambiar información de manera fácil. Una tesis de grado (Ardila Torres, 2013) demostró que estos factores le dan confianza al usuario al usar el Portal y promueve el uso del carpooling dentro de la comunidad.
Rediseñar la interfaz web de escritorio para hacer su uso más amigable:
Descripción: Se debe rediseñar el ordenamiento y la interfaz web para hacerla más amigable al usuario. Justificación: La interfaz web actual tiene problemas de usabilidad y es poco amigable con el usuario, alejando potenciales usuarios del Portal.
Crear una aplicación móvil de la página web del Portal:
Descripción: Se debe adaptar y diseñar una versión amigable a los teléfonos inteligentes de la página web del Portal, que incluya todas las funcionalidades del Portal (o la mayoría de ellas) sin necesidad de modificar la lógica de negocios.
Justificación: Con el auge de uso de los teléfonos inteligentes al crear una versión móvil de la página atraeremos más usuarios al Portal y adicionalmente se facilitará el intercambio entre pasajeros y conductores ya que no se necesita un pc de escritorio para usar el Portal.
Rediseñar e implementar un sistema de creación de rutas más amigable con el usuario:
Descripción: Se debe diseñar e implementar una forma más fácil y rápida que le permita al usuario crear una ruta.
Justificación: El sistema de creación de rutas actual es lento y complicado a la hora de usarse, adicionalmente sólo funciona correctamente en Firefox. Este hecho causa que muchos usuarios no usen el Portal Viaje por la complicación que este paso presenta.
3.4
G
LOSARIO10
portlet: Un portlet es una aplicación que utiliza un Portal de contenidos para enviar y recibir información de un cliente, en el caso concreto del Portal Viaje cada portlet representa una página de la interfaz web donde el usuario realiza una tarea específica. Usualmente un portlet se instala sobre un Portal de contenidos (en el caso específico del Portal Viaje es LifeRay) y tiene un ciclo de vida específico definido por el programador. Existen distintos estándares para programar un portlet, Liferay soporta los más populares (Vaadin, JSR-168, JSR-268, SpringMVC) y es decisión del programador seleccionar el adecuado para sus necesidades
Portal de contenidos: Un Portal de contenidos es un sistema que permite el manejo y reutilización de componentes de software para la administración de contenido web.
Liferay: Liferay es un Portal de contenidos que utiliza Java para la creación de componentes web, existen dos versiones del Portal: una que es mantenida por la comunidad y es gratuita y otra que tiene un costo pero cuyo mantenimiento y soporte técnico es ofrecido por los creadores de Liferay. El Portal Viaje corre sobre la versión gratuita del Liferay
Responsive: Responsive o diseño responsive se refiere a la característica que tiene una página web para ajustar sus elementos de manera dinámica de acuerdo al tamaño de la pantalla de donde se visualice la misma. Se utiliza el diseño responsive para crear páginas web que se desplieguen correctamente en un computador de mesa, cuya pantalla es de gran tamaño, y en dispositivos móviles cuyo espacio de visualización es limitado.
Gurobi: Gurobi es una solución comercial que actúa como optimizador con distintos parámetros. En el caso del Portal Viaje se utiliza una licencia educativa para optimizar las búsquedas del usuario.
Arcgis: Arcgis en un sistema de información geográfica que sirve para crear mapas, analizar información geográfica, entre otros.
Esri: Esri es un proveedor de sistemas de información geográfica a nivel mundial.
Glassfish: Glassfish es un contenedor de aplicaciones web Java EE. Existen dos versiones del contenedor una que es mantenida por la comunidad y es gratuita y otra que tiene un costo pero cuyo mantenimiento y soporte técnico es ofrecido por Oracle.
Bootstrap: Framework responsive (ver definición) para Front-END HTML, CSS que incorpora elementos importantes del estándar HTML5 .
11
4
M
ETODOLOGÍA DE TRABAJO
Una vez planteados los objetivos se obtuvo una copia del código fuente y cualquier documentación respecto al sistema y se planteó una metodología de trabajo basada en ciclos iterativos de corta duración (1 a 2 semanas) con objetivos específicos. Los objetivos de los ciclos se plantearon teniendo en cuenta la ausencia de documentación sobre el Portal Viaje y las tecnologías en las cuales está desarrollado. Adicionalmente, después de cada ciclo se realizó una reunión con el asesor del proyecto para mostrar los resultados del ciclo y por otro lado plantear cambios al ciclo siguiente.
Los ciclos fueron planeados de la siguiente manera:
Ciclo 1: Poner en funcionamiento el Portal Viaje para el inicio del semestre 2013-2.
Ciclo 2: Análisis de la arquitectura actual del Portal Viaje, creación de modelos pertinentes para la comprensión de la arquitectura.
Ciclo 3: Creación de botón de login de Facebook e integración preliminar del Portal Viaje con Facebook. Creación de portlet mock-up con el propósito de comprender el funcionamiento del mismo.
Ciclo 4: Migración de la página “¿Quién me lleva?” de “Yo pasajero” hacia un portlet creado usando HTML, CSS y Javascript. Crear un documento donde quede consignado dicho proceso.
Ciclo 5: Migración de las páginas subsiguientes de “Yo pasajero” usando portlets creados usando HTML, CSS y Javascript.
Ciclo 6: Migración de las páginas subsiguientes de “Yo conductor” usando portlets creados usando HTML, CSS y Javascript. Generación de requerimientos de la aplicación móvil del Portal.
Ciclo 7: Lograr que todas las páginas del Portal Viaje sean responsive y amigables con los teléfonos inteligentes.
Ciclo 8: Generar documento de arquitectura TO-BE del Portal Viaje donde queden consignados los lineamientos de la arquitectura sobre la cual debe estar hecho el aplicativo web.
12
5
A
NÁLISIS DE TECNOLOGÍAS
La siguiente sección describe brevemente cuales son las tecnologías más importantes que utiliza el Portal Viaje y el rol que cumple cada una dentro de la arquitectura planteada.
5.1
T
ECNOLOGÍAS UTILIZADAS5.1.1 Hibernate
El nivel de persistencia utiliza a Hibernate con anotaciones JPA para acceder a una base de datos PostgreSQL. Hibernate permite acceder a la base de datos por medio de llamados a métodos en Java y adicionalmente las consultas retornan objetos en Java (Red Hat, 2014).
5.1.2 Postgre y PostGis
La base de datos utilizada para almacenar los datos del Portal Viaje se basa en PostgreSQL, con la extensión PostGIS. PostGIS permite guardar geometrías de los usuarios (en el caso del Portal rutas y ubicaciones) en la base de datos, sobre la cual se pueden hacer consultas (Postgis, 2014). Adicionalmente, PostGIS es compatible con el optimizador Gurobi lo que permite trasladar estas geometrías al optimizador de manera trivial.
5.1.3 Spring Framework
El Portal Viaje utiliza Spring framework para la inyección de dependencias y actúa como mediador entre la lógica de negocio y la interfaz, enviando una instancia de la lógica de negocios a la capa de presentación cuando esta lo requiere (Pivotal Software, 2014).
5.1.4 Optimizador Gurobi
Para la optimización de la búsqueda de los viajes se utiliza el optimizador Gurobi. El optimizador permite hacer optimizaciones complejas sobre las preferencias de un usuario al buscar un viaje que usualmente no se podrían programar de manera trivial en Java (Gurobi, 2014).
13
5.1.5 Liferay
Todos los componentes del Portal corren sobre el Portal de contenidos LifeRay (edición comunitaria). El uso LifeRay simplifica tareas como manejos de permisos, despliegue de componentes independientes, manejo de usuarios, manejo de contenidos y estilos css del Portal (LifeRay Inc., 2014).
5.1.6 Vaadin
Todos los componentes gráficos del Portal Viaje se encuentran programados sobre Vaadin. Vaadin es un framework que permite construir el front end de aplicaciones web programando en Java. Vaadin posteriormente se encarga de convertir el código Java a HTML con sus estilos y llamados Ajax (Vaadin Ltd., 2014).
5.1.7 Esri y Arcgis
El Portal Viaje utiliza el servicio de mapas Esri junto con un servidor ArcGis para la creación y visualización de rutas y ubicaciones.
5.2
A
NÁLISIS REQUERIMIENTOS NO FUNCIONALESEsta sección describe el análisis de los requerimientos no funcionales que posiblemente fueron tenidos en cuenta a la hora de crear la aplicación del Portal Viaje. Debido a que no hay documentación oficial del aplicativo los requerimientos aquí mencionados surgen de un análisis posterior de la arquitectura de la aplicación y no de una intención previa al desarrollo del Portal Viaje:
Escalabilidad
Debido a un potencial de usuarios cercana a los 10,000 (aproximadamente 70% de la población universitaria sin incluir profesores) el Portal Viaje debe ser capaz de soportar una carga de concurrencia cercana a los 1000 accesos concurrentes.
Confiabilidad
El sistema debe gestionar consistencia de los datos al realizar las transacciones, cualquier inconsistencia sobre la información podría generar grandes afectaciones a las agendas de los estudiantes ya que implicaría la imposibilidad de transportarse a la universidad a una hora estipulada.
Extensibilidad
En el contexto académico universitario es de esperarse que estudiantes y profesores utilicen la aplicación dentro de sus investigaciones, asimismo estudiantes pueden proponer mejoras a la aplicación y esto requiere implementación de nuevas funcionalidades. Por consiguiente, el sistema debe permitir añadir nuevas funcionalidades fácilmente sin afectar el funcionamiento de la aplicación.
Seguridad
Para garantizar la seguridad de los viajes realizados por medio de la aplicación, es necesario garantizar que sólo los miembros de la comunidad universitaria puedan usar la aplicación. Para garantizar este requerimiento la aplicación exige el ingreso del nombre de usuario y contraseña institucional antes de que el usuario pueda realizar cualquier acción.
14
Disponibilidad
No se pudo establecer el requerimiento de disponibilidad ya que no existe documentación clara al respecto y la arquitectura física de los servidores donde se aloja el Portal Viaje no está bajo el control de los desarrolladores y/o administradores de la aplicación
5.3
A
NÁLISIS DEL USO DE LAS TECNOLOGÍASBasado en los datos de la sección anterior, los desarrolladores del Portal Viaje hicieron una selección de tecnologías particular con efectos sobre el funcionamiento de la aplicación web y que se basan parcialmente en los requerimientos no funcionales descritos. Dentro del análisis de tecnologías se pone en negrilla y en paréntesis los requerimientos no funcionales que se ven afectados de acuerdo a la descripción de las tecnologías usadas.
5.3.1 Portal de contenidos LifeRay
El uso del Portal de contenidos Liferay está diseñado para facilitarle al programador tareas triviales que se vuelven complejas cuando se manejan grandes cantidades de usuarios con distintos roles (escalabilidad) y que acceden a contenidos disimiles sobre una interfaz web (LifeRay Inc., 2014). Sin embargo, debido a la naturaleza del Portal Viaje donde se manejan contenidos homogéneos y muy pocos roles de usuario, la utilización de estas funcionalidades es limitada. El Portal Liferay también permite la creación de módulos independientes de software que pueden ser modificados sin afectar a los demás (extensibilidad). Adicionalmente, todas estas funcionalidades tienen una penalidad sobre el desempeño del Portal Viaje que es percibida por el usuario final (revisar pruebas de desempeño). Por esta razón el uso de LifeRay para alojar el Portal Viaje es una decisión que no se encuentra plenamente justificada.
5.3.2 Hibernate y JPA
El uso de JPA e Hibernate para la capa de persistencia trae numerosas ventajas para el programador, esto a costa del desempeño de los accesos a la base de datos. Pero en cualquier caso, el uso de Hibernate permite adicionar o modificar nuevas funcionalidades sin preocuparse por la capa de persistencia (extensibilidad) y con la posibilidad de tener un crecimiento importante sin tener que realizar grandes cambios a la capa de persistencia (escalabilidad) (Red Hat, 2014). Por otro lado, el uso de estas tecnologías le permite al desarrollador desacoplarse de las consultas sobre la base de datos, por todas estas razones y teniendo en cuenta que a futuro los requerimientos funcionales del Portal Viaje han de cambiar, la decisión de usar estas tecnologías no es solo adecuada sino necesaria.
5.3.3 Vaadin
Al permitirle a un usuario la posibilidad de programar el front end de una aplicación web sin tener conocimiento profundo en HTML, CSS o JavaScript Vaadin es un framework sumamente útil. Al mismo tiempo, Vaadin permite hacer una integración más profunda con algunos componentes de Liferay, para
15
realizar este tipo de integraciones se cuenta con documentación oficial de parte de los desarrolladores Vaadin y LifeRay (LifeRay Inc., 2014) (Vaadin Ltd., 2014). Esto pudo influir en la selección de estás dos tecnologías a la hora de programar el Portal Viaje.
Sin embargo, para poder programar sobre Vaadin, aparte de tener conocimientos previos de Java, es necesario superar una curva de aprendizaje importante. Teniendo en cuenta que Vaadin es un Framework exclusivo para Java y con un porcentaje de uso cercano al 15% en esta plataforma (RebelLabs, 2014) es probable que un programador novato no conozca de esta tecnología. Por el contrario, el uso de programación sobre HTML, CSS y JavaScript es transversal a muchos otros frameworks y lenguajes de programación (Java, PHP, Ruby on Rails). Debido a que el Portal Viaje es un proyecto ligado estrechamente a la universidad, es previsible que a futuro otros estudiantes deseen aportar al mismo, en dicho contexto el uso de tecnologías más populares y transversales a distintos lenguajes y frameworks es claramente una ventaja. El uso de HTML, CSS y JavaScript hacen más probable que un estudiante que vaya a trabajar sobre la aplicación entienda el código a la vez le que interactúa con tecnologías que muy probablemente utilizará en un futuro si se dedica al desarrollo web. En este escenario los argumentos a favor de Vaadin pierden peso, aunque las ventajas siguen existiendo, el tamaño del proyecto, que en front end no tiene más de 5 páginas y muchas iguales, y el contexto educativo donde se desarrolla la aplicación sugiere que el uso de Vaadin para el Portal Viaje no es lo ideal.
5.3.4 Esri y Arcgis
El uso del sistema de mapas Esri y un servidor de optimización de rutas Arcgis es una decisión que permitió que los desarrolladores del Portal Viaje accedieran a un sistema de mapas robusto de manera rápida y eficiente aprovechando una infraestructura existente dentro de la universidad. Debido a que uno de los pilares del Portal Viaje es su sistema de ubicaciones y rutas, la selección de un sistema de mapas adecuado era una decisión crucial. Sin embargo, la implementación específica usando este sistema de mapas en presenta los siguientes retos:
•Requiere el pago de unas licencias propietarias para su uso. Esto no es un inconveniente para la implementación dentro de la Universidad de los Andes ya que la institución posee estas licencias. Sin embargo, a la hora de implementar el producto en otra empresa o universidad esto podría generar un costo adicional.
•El generador de rutas presenta problemas al crear una ruta ya que en ocasiones toma desvíos innecesarios al generarla. Adicionalmente, las rutas sólo se pueden crear sobre el navegador Firefox. •La creación de rutas depende de un servidor ajeno al Portal Viaje.
5.3.5 Otras tecnologías
Adicional a las tecnologías antes mencionadas, el Portal Viaje utiliza Gurobi como optimizador de búsquedas y Spring como framework de aplicaciones. Por un lado, Gurobi se encarga de optimizar todas las búsquedas de viajes realizadas por los pasajeros de la aplicación, su implementación le permite al usuario obtener resultados de búsqueda acertados basado en una combinación de factores previamente definidos (hora del viaje, distancia hasta mi ubicación, costo del viaje, rating). La implementación
16
concreta del optimizador no fue analizada a fondo debido a que su funcionamiento es adecuado y el tema de optimización se sale del enfoque del proyecto.
Con respecto a Spring, esta tecnología facilita algunas tareas como inyección de dependencias y comunicación entre la lógica y la interfaz. Debido a que el uso de Spring ya está altamente acoplado con la lógica de negocios y realiza tareas importantes, reemplazarlo o removerlo sería una decisión inadecuada.
6
A
RQUITECTURA DEL
P
ORTAL
V
IAJE
“AS-IS”
Cuando se realizó el análisis inicial del código fuente del Portal Viaje no se encontró ninguna documentación referente a la arquitectura del sistema, dificultando la tarea de análisis y compresión del funcionamiento del Portal. Por ende, esta sección del documento le presenta al lector las vistas de arquitectura más útiles de los distintos componentes del sistema analizado, esto con el fin de que a futuro las partes interesadas en realizar cambios sobre la aplicación tengan toda la información disponible a su disposición.
6.1
V
ISTAS ANALIZADASPara este documento se decidieron analizar las vistas de:
a) Punto de vista funcional: Modelo de estructura funcional (Rozanski & Woods, 2005) donde se documenten los principales módulos de software (o componentes) que componen la arquitectura, dependencias que existen entre estos y las interfaces mediante las cuales se comunican.
b) Punto de vista de desarrollo: Modelo de estructura modular (Rozanski & Woods, 2005) donde se documenten los proyectos de código fuente que componen el proyecto y cómo estos se relacionan con los módulos de software descritos en el punto de vista funcional.
c) Punto de vista de despliegue: Modelo de nodos de ejecución (Rozanski & Woods, 2005) donde se muestre la manera en la que se despliega actualmente la aplicación en los diferentes nodos de la infraestructura computacional.
d) Modelo de dependencias tecnológicas: modelo de dependencias tecnológicas (Rozanski & Woods, 2005) donde se aclaren cuáles son las librerías componentes que se requieren para el correcto despliegue de la aplicación así como las versiones de cada uno.
e) Punto de vista de información: Modelo de estructura estática de la información (modelo entidad-relación) con las principales entidades del sistema y las relaciones entre éstas (Rozanski & Woods, 2005).
f) Modelo de ciclo de vida de la información: Modelo del ciclo de vida de la información para las entidades que se consideren más relevantes dentro del sistema (Rozanski & Woods, 2005).
17
6.2
P
UNTO DE VISTA FUNCIONALIlustración 1 Punto de vista Funcional AS-IS
En el diagrama se puede observar que el sistema está dividido en tres partes: Presentación, lógica de negocios y persistencia. Este esquema tradicional tiene la ventaja de ser altamente desacoplado y permite realizar cambios sobre cualquiera de las tres partes sin afectar a las demás, lo que promueve la extensibilidad. Asimismo, la lógica de negocios se encuentra subdivida en clases independientes y desacopladas que cumplen distintas funciones dentro de la aplicación. Por último, se encuentra el servicio de mapas que está alojado externamente y su llamado se hace desde la capa de presentación
18
(ver diagrama de despliegue). Esto presenta una clara desventaja ya que el servicio no está bajo control de los desarrolladores del Portal Viaje y realizar modificaciones sobre este componente es mucho más difícil.
Descripción de los elementos:
Navegador Usuario: Se refiere al navegador (Chrome, Firefox o Safari) de donde accede el usuario al Portal Viaje.
Navegador Administrador: Se refiere al navegador (Chrome, Firefox o safari) de donde accede el administrador al Portal Viaje
Portlet Vaadin: Es el conjunto de clases de Java, archivos Javascript, CSS y demás que se encargan de desplegar la interfaz de los distintos componentes del Portal y llamar los métodos de la lógica de negocios.
Mapas: Es el servicio de mapas externo que permite calcular las rutas y geometrías que ingresa el usuario sobre el navegador. Está compuesto de un servidor de rutas que está en la universidad y un servidor de mapas que provee ArcGis.
Admin Usuarios: Una clase en Java que provee servicios de consulta y modificación de toda la información pertinente al usuario (Vehículos, Viajes, Calificaciones, Preferencias, Rutas y ubicaciones). Admin Viaje: Una clase en Java que provee todos los servicios de búsqueda y modificación de viajes por parte del pasajero y conductor (buscar viaje, aceptar viaje, rechazar viaje, crear viaje, cancelar viaje, etc.)
Mail: Es el conjunto de clases en Java que envía los correos correspondientes de acuerdo a las preferencias del usuario.
Administrador parámetros: Es un conjunto de clases en Java que permite modificar los parámetros internos del Portal Viaje: cupo máximo de un vehículo y cupos viaje SD.
Administrador Scores: Es un conjunto de clases en Java que permite modificar y visualizar información acerca de puntajes de uso de los usuarios del Portal Viaje.
Optimizador: Un conjunto de clases en Java que se utilizan el motor optimizador de “Gurobi” para optimizar y presentar de una manera organizada los viajes que resultan de las búsquedas hechas por un usuario.
Entity manager: Una clase en Java que se encarga de conectarse con la base de datos para hacer las consultas y modificaciones necesarias de manera transparente para el programador.
Por otro lado, la capa de la lógica de negocios le presta los siguientes servicios a la capa de presentación (estos servicios son prestados exclusivamente por las clases de AdminViajes y AdminUsuarios), las demás clases son para el manejo de los servicios expuestos a la capa de presentación. Existe una excepción en el caso de los administradores del Portal Viaje los cuales tienen a su disposición una interfaz web exclusiva para el manejo de los parámetros del Portal y para revisión de scores de los usuarios que utilizan la aplicación.
19 Servicios:
AdminUsuario:
1. Crear, borrar y mostrar rutas de un usuario. 2. Crear, borrar y mostrar ubicaciones de un usuario. 3. Crear, borrar y mostrar vehículos de un usuario. 4. Calificar a un usuario.
5. Mostrar las calificaciones de un usuario.
6. Mostrar y editar las preferencias de búsqueda y notificación de un usuario.
AdminViajes:
1. Crear, borrar y validar un viaje.
2. Buscar Viajes (se apoya en el optimizador Gurobi). 3. Crear, borrar y visualizar ofertas para un viaje.
20
6.3
P
UNTO DE VISTA DE DESARROLLOIlustración 2 Punto de vista de desarrollo AS-IS
Los componentes se encuentran claramente diferenciados en los paquetes de código del sistema. Por otra parte, debido a que la persistencia es manejada por JPA, la clase aquí representada como entity
manager no es visible directamente para el programador. Sin embargo, las clases que pertenecen a la
capa de presentación no se encuentran ordenadas en un solo paquete, y debido a su gran número generan desorden en la interfaz del ambiente de programación a la hora de analizar el código. Es importante aclarar que cada elemento de la presentación (portlet) tiene su propia instancia de la lógica de negocios y persistencia, que es importada por medio de un jar.
Adicionalmente, dentro de cada portlet (elemento de la presentación) se encuentra la siguiente estructura (sólo se especifican las más importantes):
21
/Css: En esta carpeta se encuentra cualquier archivo CSS específico al portlet.
/Images: En esta carpeta se encuentra cualquier imagen que vaya a ser desplegada dentro del portlet. /js: En esta carpeta se encuentran los archivos JS (JavaScript) específicos para el correcto funcionamiento del portlet.
Init.jsp o view.jsp: Este archivo JSP representa el archivo por donde el portlet iniciará su ejecución al momento de ser cargado por el Portal de contenidos.
/Docroot/WebINF
/Lib: En esta carpeta están todos los archivos jar que necesitan para la correcta ejecución del portlet Adicionalmente se encuentran tres archivos xml encargados de la configuración del portlet (portlet.xml, Liferay-portlet.xml y Web.xml) este último está encargado de conectar la capa de presentación con el contexto de Spring.
22
6.4
P
UNTO DE VISTA DE DESPLIEGUEIlustración 3 Punto de vista de despliegue AS-IS
Se puede observar que todos los componentes (exceptuando el servicio de mapas) se encuentran desplegados en el mismo servidor. El hecho de que el servicio de mapas se encuentre en un servidor ajeno presenta un riesgo para el funcionamiento del sistema, ya que es imposible garantizar un nivel de disponibilidad especifico. Sin embargo, el servidor de Arcgis, que pertenece a una empresa multinacional dedicada al servicio de mapas, es mucho más confiable que el servidor alojado en una máquina virtual perteneciente a un profesor del departamento de sistemas. Aparte de eso, es importante aclarar que el servicio de mapas es consultado por medio del navegador del usuario, el cual posteriormente envía los resultados de las consultas (búsqueda de rutas) a la lógica de negocios donde
23
se almacenan en un formato específico, y sobre el cual se hacen las optimizaciones cuando un usuario busca un viaje.
6.5
D
IAGRAMA DE DEPENDENCIAS TECNOLÓGICAS(P
OR PORTLET)
Las librerías que se encuentran en negrilla son necesarias para el correcto despliegue del portlet en el IDE.
Externas
antlr-2.7.6 aopalliance-1.0 aspectjrt-1.6.11 aspectjweaver-1.6.11 cglib-nodep-2.2 commons-collections-3.1 commons-dbcp-1.3 commons-lang3-3.1 commons-logging-1.1.1 commons-pool-1.5.4 dom4j-1.6.1 flexjson-2.1 hibernate-commons-annotations-3.2.0.Final hibernate-core-3.6.4.Final hibernate-entitymanager-3.6.4.Final hibernate-jpa-2.0-api-1.0.0.Final hibernate-spatial-1.1 hibernate-spatial-postgis-1.1 hibernate-validator-4.1.0.Final hsqldb-1.8.0.10 javassist-3.12.0.GA java-json jcl-over-slf4j-1.6.1 jstl-api jstl-impl jta-1.1 jts-1.11 log4j-1.2.1624 postgis-jdbc-1.3.3 postgis-stubs-1.3.3 postgresql-9.0-801.jdbc4 ratingstars-1.4 slf4j-api-1.6.1 slf4j-log4j12-1.6.1 spring-aop-3.0.5.RELEASE spring-asm-3.0.5.RELEASE spring-aspects-3.0.5.RELEASE spring-beans-3.0.5.RELEASE spring-context-3.0.5.RELEASE spring-context-support-3.0.5.RELEASE spring-core-3.0.5.RELEASE spring-expression-3.0.5.RELEASE spring-jdbc-3.0.5.RELEASE spring-orm-3.0.5.RELEASE spring-test-3.0.5.RELEASE spring-tx-3.0.5.RELEASE spring-web-3.0.5.RELEASE spring-webmvc-3.0.5.RELEASE spring-webmvc-portlet-3.0.5.RELEASE vaadin validation-api-1.0.0.GA viaje-core xercesImpl-2.4.0
Liferay(incluidas en el portlet)
jsp-apiPortal-service portlet servlet-api
Tabla 1 Dependencias tecnológicas AS-IS
Ya que se seleccionó Spring Framework como tecnología encargada para la inyección de dependencias (explicado en la siguiente sección) la cantidad de librerías para la correcta compilación de los elementos de la capa presentación del sistema es sustancial. Por otro lado, debido a que cada instancia individual de la interfaz debe tener una instancia de la lógica de negocio y persistencia es necesario incluir todas estas librerías dentro de las dependencias tecnológicas de cada portlet.
25
6.6
P
UNTO DE VISTA DE INFORMACIÓN26
Ilustración 4 Punto de vista de información AS-IS
Este punto de vista refleja el modelo planteado en la lógica de negocio para el manejo de la información del sistema. Debido a que se usa JPA e Hibernate para el manejo de la persistencia, las tablas que se visualizan directamente sobre la base de datos difieren ligeramente del modelo presentado. Es importante resaltar que para guardar la información de el atributo “geometría_ruta” de la entidad “ruta” se utiliza la extensión PostGIS dentro del contexto de la base de datos PostgreSQL, esta extensión permite guardar las geometrías de las rutas de los usuarios para posteriormente ser utilizadas por el optimizador cuando un usuario va a realizar la búsqueda de un viaje.
Por otro lado, dentro de la base de datos existen más de 50 tablas que no son utilizadas por el Portal Viaje pero son creadas por Liferay automáticamente al desplegar el Portal. No se realizó un análisis profundo de estas tablas.
27
6.7
M
ODELO DE CICLO DE VIDA DE LA INFORMACIÓN28
Ilustración 5 Modelo ciclo de vida de la información
En el modelo se evidencia que algunas entidades, como la de Viaje, se persisten y no se borran, esto se hace con el propósito de mantener un record estadístico de la actividad realizada sobre el Portal
7
P
RUEBAS DE CARGA
Las siguientes pruebas de carga se realizaron sobre la versión inicial del Portal Viaje corriendo en un servidor con las siguientes características:
Procesador: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, 1 cores Memoria Ram: 2GB
Disco duro: 40GB
Debido a inconvenientes técnicos con la página web la prueba se realizó usando 1 hilo 300 veces, (100 por pasada) usando una sola cuenta de usuario para ingresar al sistema. Los tiempos en milisegundos reflejan el tiempo de respuesta en ingresar a las páginas específicas de cada rol de usuario, sin tener en cuenta la carga de imágenes o archivos auxiliares (js, css etc). Debido a que las pruebas se realizaron desde un cliente conectado a una red distinta a la del servidor se realizó una prueba de ping de 3 minutos sobre la máquina donde se encontraba el Portal Viaje y el valor se le restó a los resultados encontrados.
Pruebas pasajero
promedio max min Promedio sin
ping Pass 1
Mis ubicaciones
616
2710
418
519
Buscar viajes
383
1868
255
286
Quien me lleva
361
4223
208
264
ping 97 111 88
Pass 2
Mis ubicaciones
582
1120
407
489
Buscar viajes
399
3130
218
306
Quien me lleva
348
1263
188
255
ping 93 116 87
Pass 3
Mis ubicaciones
638
1944
387
547
Buscar viajes
400
1258
217
309
29
ping
91
99
86
Tabla 2 Pruebas de carga pasajero sin cambios
Prueba Conductor
promedio max min Promedio sin
ping Pass 1
Mis rutas
360
544
246
267
Publicar Viaje
314
1046
230
221
A quién llevo
273
212
558
180
ping
93
103
88
Pass 2
Mis rutas
283
470
233
182
Publicar Viaje
317
850
235
216
A quién llevo
340
716
208
239
ping
101
260
87
Pass 3
Mis rutas
330
923
237
236
Publicar Viaje
348
2639
226
254
A quién llevo
317
1245
209
223
ping
94
119
87
Tabla 3 Pruebas de carga conductor sin cambios
8
C
ONCLUSIONES SOBRE EL ESTADO DEL
P
ORTAL
“AS-IS”
Teniendo en cuenta lo mencionado anteriormente, se puede afirmar que el Portal Viaje se encuentra programado sobre una serie de tecnologías robustas y se basa en una arquitectura tradicional de tres capas que es altamente desacoplada. Sin embargo, durante el análisis del estado actual del aplicativo uno de los mayores retos a superar fue la total falta de documentación sobre el sistema, este hecho implicó una curva de aprendizaje importante sobre las tecnologías usadas para después entrar a detallar la implementación específica. Por otro lado, el sistema actualmente no cuenta con ningún tutorial para poder crear nuevos elementos de la interfaz o para acceder a la lógica de negocios, tampoco están documentadas las herramientas y tecnologías específicas utilizadas para crear partes puntuales del código fuente.
Aun así, una vez superado este impasse inicial, la visión global de la aplicación nos muestra que el Portal Viaje es una aplicación robusta, bien diseñada y realizada bajo buenas prácticas. Cuando se realizó su lanzamiento en octubre del año 2010 la aplicación web fue un éxito entre la comunidad Uniandina, pero como es usual en el mundo de la tecnología, en tres años ha habido grandes avances tecnológicos que
30
presentan un escenario distinto para el uso del portal web. La aparición de teléfonos inteligentes y grupos en Facebook como “Wheels Uniandes” requieren de una respuesta de cambio por parte del Portal Viaje, respuesta que no se ha dado, pues en estos tres años su interfaz web y funcionalidad se ha mantenido estática. Por consiguiente, las propuestas de cambio a realizar implican, más que un cambio de fondo, una actualización que le permite al Portal mantenerse vigente, todo esto construido sobre la aplicación ya existente.
9
L
INEAMIENTOS DE LA ARQUITECTURA
“
TO
-
BE
”
Teniendo en cuenta el análisis presentado anteriormente de la arquitectura AS-IS se plantearon los siguientes lineamientos para la arquitectura TO-BE del Portal Viaje.
9.1
M
EJORA EN DESEMPEÑO DEL TIEMPO DE RESPUESTA DEL PORTAL WEBBasado en la experiencia de los usuarios del Portal Viaje y las pruebas de carga uno de los lineamientos más importantes para la nueva arquitectura de la aplicación web es mejorar el tiempo de respuesta del portal web. Con esto se busca mejorar la experiencia de usuario del Portal cuando esté navegando por la página, los tiempos de respuesta demasiados altos pueden desesperar al usuario y hacerlo desistir de usar el Portal Viaje. Para lograr esto se plantea tener el Portal Viaje corriendo en un servidor distinto a Liferay y se recomienda quitar Vaadin como framework en la interfaz ya que este requiere una conversión adicional de Java a HTML para mostrar los archivos en el navegador.
9.2
D
EPURAR DEPENDENCIAS Y LIBRERÍAS NO UTILIZADASTeniendo en cuenta el análisis realizado en la sección anterior sobre las tecnologías utilizadas en el Portal Viaje, es importante deshacerse de algunas de ellas para lograr los objetivos planteados inicialmente. Una de estas tecnologías que dificulta la capacidad de modificar el Portal fácilmente a futuro es Vaadin en la capa de presentación. Por esta razón, se desea prescindir de Vaadin para la capa de presentación y se recomienda programar los portlets en un framework que no sea dependiente de ninguna tecnología específica, exceptuando las de la capa de lógica de negocios los cuales se mantendrán con la tecnología actual.
Esto implica, además de reprogramar los portlets, la necesidad de depurar las librerías no utilizadas por estos componentes y la lógica de negocio, para así aligerar el tamaño y el tiempo de carga de la capa de presentación del Portal.
Por otro lado, para desacoplar al Portal de Liferay es necesario reemplazar o suprimir las librerías exclusivas a Liferay que en caso de una migración a otro servidor serían un obstáculo para la correcta ejecución del Portal.
31
9.3
D
EJAR LISTA LA ARQUITECTURA PARA UNA VERSIÓN MÓVIL DELP
ORTALDebido al auge de teléfonos inteligentes en los últimos años es imprescindible crear una aplicación móvil del Portal Viaje. Esto requiere de unos cambios en la arquitectura para exponer los servicios básicos que utilizará la aplicación móvil una vez esté programada, estos servicios serán:
1. Crear, borrar y mostrar rutas de un usuario. 2. Crear, borrar y mostrar ubicaciones de un usuario. 3. Crear, borrar y mostrar vehículos de un usuario. 4. Calificar a un usuario.
5. Mostrar las calificaciones de un usuario.
6. Mostrar y editar las preferencias de búsqueda y notificación de un usuario. 7. Crear, borrar y validar un viaje.
8. Buscar Viajes (se apoya en el optimizador Gurobi). 9. Crear, borrar y visualizar ofertas para un viaje.
La forma en que el Portal Viaje exponga los servicios será definida posteriormente.
9.4
C
REAR UNA VERSIÓN RESPONSIVE DEL PORTAL WEB DE LA APLICACIÓNActualmente la interfaz Web del Portal Viaje no se despliega correctamente en los dispositivos móviles de resoluciones limitadas, el despliegue de la página se realiza como si fuera un navegador convencional de computador de escritorio, esto implica que los objetos se tornan difíciles de leer y presionar cuando el dispositivo es muy pequeño. Por esta razón, surge la necesidad de modificar la versión actual de la interfaz web del Portal Viaje para que esté optimizada para dispositivos móviles. Debido a que sería inconveniente por razones de mantenimiento hacer una versión específica para móviles y otra para pc, la solución es modificar los portlets del Portal Viaje para que sean responsive y ajusten sus elementos al tamaño del dispositivo donde se encuentran desplegados. Todo esto manteniendo la funcionalidad actual y mejorando la experiencia de usuario.
9.5
G
ENERAR UNA ARQUITECTURA DOCUMENTADAComo se describe en la sección de análisis, una de las mayores dificultades a la hora de entrar a modificar y comprender el Portal Viaje fue la falta de documentación respecto al mismo. Por consiguiente es de suma importancia que la arquitectura “TO-BE” este correcta y completamente documentada. Esto con el fin de que futuros interesados puedan hacer cambios y tomar decisiones sobre la aplicación de manera informada.
Esta documentación no debe estar limitada a diagramas sobre la arquitectura si no que debe incluir tutoriales pertinentes para la correcta configuración del ambiente de ejecución. Por otro lado, es recomendable, más no necesario, comentar todo el código programado para su fácil entendimiento por parte de otros programadores.
32
9.6
G
ENERAR UNA ARQUITECTURA QUE PERMITA MIGRAR A OTRO SERVIDORPor las razones expuestas en la etapa de análisis el uso de Liferay es cuestionable, por consiguiente es necesario que la arquitectura y código del “TO-BE” del Portal Viaje estén preparados para su migración hacia otro servidor de aplicaciones sin mayores complicaciones. Esto permite que el Portal Viaje se encuentre completamente desacoplado de Liferay y se encuentre ejecutando en un servidor más apropiado para los requerimientos de calidad de la aplicación (como por ejemplo darle prioridad al desempeño vs la capacidad de hacer modificaciones).
Estos lineamientos base, junto con los objetivos planteados para el proyecto de grado, fueron tenidos en cuenta a la hora de trabajar y modificar el Portal Viaje. Los resultados logrados se muestran a continuación.
10
A
RQUITECTURA RESULTADO Y PROCESO
10.1
R
ESULTADOS CICLOSLos ciclos efectivamente realizados fueron los siguientes:
Ciclo 1 (2 semanas): Durante este ciclo se puso en funcionamiento el Portal Viaje y se corrigió el problema de creación de rutas que no permitía su uso. Lamentablemente y debido a que el daño de un servidor ajeno al Portal fue el que causo este inconveniente el tiempo para completar este ciclo fue de una semana más de lo previsto.
Ciclo 2 (1 semana): En este ciclo se logró documentar desde un alto nivel la arquitectura actual del Portal Viaje con los diagramas pertinentes. Se logró un entendimiento básico del funcionamiento de la aplicación sin conocer profundamente el código. No se hicieron modificaciones al código.
Ciclo 3(3 semanas): Durante este ciclo se logró crear un portlet básico que no dependiese de Vaadin y que se conectara con la lógica de negocios del Portal Viaje. Este ciclo tomó una cantidad de tiempo excesiva debido a que la curva de aprendizaje sobre las tecnologías que utiliza el Portal Viaje fue más extensa de lo previsto.
Ciclo 4(1 semana y media): Durante este ciclo se programó el portlet correspondiente a “¿Quién Me lleva?” de la sección “Yo pasajero” del Portal viaje. Este portlet se realizó sin el uso de Vaadin ni librerías específicas de Liferay. La ejecución de este ciclo fue mucho más corta debido a que ya se había superado la curva de aprendizaje inicial de las tecnologías del Portal Viaje durante el ciclo anterior.
Ciclo 5(1 semana): Durante este ciclo se programaron todos los portlets restantes de la sección “Yo pasajero” del Portal Viaje. Estos portlets, al igual que en el ciclo pasado, se crearon sin el uso de Vaadin y librerías propietarias de Liferay. Adicionalmente, se agregó en la lógica de negocios la posibilidad de asignarle a la ruta de un conductor una breve descripción para su fácil identificación por parte del pasajero.
33
Ciclo 6 (1 semana y media): Durante este ciclo se convirtieron todos los portlets restantes del Portal teniendo en cuenta los lineamientos del ciclo pasado. También se corrigieron algunas vulnerabilidades de seguridad encontradas durante los ciclos pasados que afectaban a la capa de presentación
Ciclo 7(1 semana): Durante este ciclo se modificó la interfaz web de “Yo pasajero” para que fuese responsive y se desplegara correctamente en los dispositivos móviles.
Ciclo 8 (1 semana): Durante este ciclo se modificó la interfaz web de “Yo conductor” para que fuese responsive y se desplegara correctamente en los dispositivos móviles. Por otro lado, se hicieron pruebas de carga sobre el Portal y se implementó un sistema de medición de tráfico en el mismo.
Es importante recalcar que durante todos los ciclos se fue modificando el documento de proyecto de grado de acorde a los avances y hallazgos encontrados durante los ciclos anteriores.
10.2
O
BJETIVOS LOGRADOS10.2.1 Objetivos generales
O1.Dejar funcionando el Portal Viaje para el inicio del semestre 2013-20: El objetivo se logró aunque una semana tarde, esto ocurrió debido a que el problema principal que no permitía el funcionamiento del Portal (la imposibilidad de crear rutas) se debía a un inconveniente en un servidor ajeno al de la aplicación. Esto implicó la reconfiguración de un servidor sobre el cual no se tenía control directo.
O2.Tener una versión mejorada del Portal Viaje para el inicio del semestre 2014-10, teniendo en cuenta los objetivos subsiguientes: El objetivo se logró parcialmente, se tendrá una nueva versión para el inicio del semestre, con la mayoría de objetivos cumplidos.
O3.Contar con una documentación actualizada y completa del Portal Viaje: El objetivo se logró, tras un análisis y como lo demuestra este documento existe una documentación completa y actualizada de Portal Viaje.
O4.Realizar los ajustes necesarios a la arquitectura del Portal Viaje para que su mantenimiento y modificación y mantenimiento por parte de otros interesados en el futuro sea más sencilla: El objetivo se logró parcialmente, después de un proceso de programación y modificación del código existente se logró prescindir de Vaadin como tecnología en la interfaz y se reemplazó por JSR. Sin embargo, existen otras dependencias, como el Portal Liferay, que dificultan el mantenimiento del Portal y que todavía faltan por reemplazar. No se lograron quitar algunas dependencias debido a la falta de tiempo durante la ejecución del proyecto.
34
O5.Realizar los ajustes necesarios a la arquitectura del Portal Viaje para que en el corto plazo sea viable y sencillo realizar una aplicación móvil: El objetivo se logró parcialmente, se dejaron planteados los servicios que debe ofrecer el Portal Viaje para la posterior creación de la aplicación móvil. Este objetivo no se logró cumplir plenamente debido a la falta de tiempo y la complejidad que implicaba una modificación mayor a la arquitectura del Portal
Los objetivos no mencionados no fueron logrados o tenidos en cuenta durante la ejecución del proyecto de grado por cuestiones de tiempo y/o dificultad.
10.2.2 Objetivos específicos
Habilitar o dejar listo el Portal para su integración con Facebook: Este objetivo no se cumplió, debido a la falta de tiempo se le dieron prioridad a otros objetivos (como el rediseño de la página web y la depuración de dependencias) y este se dejó a un lado. Sin embargo, la compleción de algunos objetivos que favorecen la capacidad de mantenimiento y facilidad de modificación del Portal preparan el camino para la integración del Portal con Facebook en el corto plazo
Rediseñar la interfaz web de escritorio para hacer su uso más amigable: El objetivo se cumplió, con la ayuda de la diseñadora Natalia Torres se hizo un rediseño del portal web teniendo como prioridad la facilidad de uso del mismo. Esta nueva interfaz web no se realizó con Vaadin si no que se realizó con la tecnología estándar de JSR.
Crear una aplicación móvil de la página web del Portal: Este objetivo no se cumplió, tras un análisis de los resultados se puede afirmar que incluir este objetivo dentro del proyecto de grado fue demasiado ambicioso y su lograr su compleción es extremadamente difícil en el lapso de 6 meses.
Rediseñar e implementar un sistema de creación de rutas más amigable con el usuario: Este objetivo no se cumplió, se priorizaron otros objetivos sobre este debido a la complejidad del mismo. La modificación del sistema de rutas no solo requiere un profundo conocimiento sobre la aplicación del Portal Viaje ya que se necesita conocimiento sobre los sistemas de mapas y su manejo de coordenadas, conocimiento que no pudo ser alcanzado dentro del lapso de tiempo del proyecto de grado.
10.3 C
AMBIOS EN LA ARQUITECTURATeniendo en cuenta los ciclos planteados y los objetivos logrados se concretaron algunos cambios importantes en la arquitectura.
35
10.3.1 Punto de vista Funcional
En el punto de vista funcional no hay cambios sustanciales, simplemente se reemplazan los portlets Vaadin por portlets basados en JSR. También se eliminan los portlets asociados a la configuración de parámetros y visualización de scores.
36
10.3.2 Punto de vista de desarrollo
Se condensaron paquetes dentro de la capa de presentación, reduciendo a 6 la cantidad de paquetes referentes a los portlets de la interfaz del Portal Viaje. No hubo cambios en la lógica de negocios o persistencia en esta vista.
Ilustración 7 Primeros cambios punto de vista de desarrollo 10.3.3 Vista de despliegue
No hubo cambios en la arquitectura de despliegue.
10.3.4 Diagrama de dependencias tecnológicas
Se eliminaron las siguientes librerías de los portlets de la capa de presentación (que incluyen una copia de la lógica de negocios y persistencia):
Nombre Descripción
aspectjweaver-1.6.11
Librería para uso de load time weaving.
commons-lang3-3.1
Provee una serie de métodos adicionales a los de Java para el manejo de Strings, fechas, números y seralización
37 commons-logging-1.1.1
Funciona como un "puente “entre distintas
implementaciones de sistemas de log
hibernate-validator-4.1.0.Final
Sirve para validar y expresar limitaciones de una aplicación.
hsqldb-1.8.0.10
Sistema de manejo de
base de datos
relacionales
spring-webmvc-3.0.5.RELEASE
Parte del framework de spring que entre otras cosas permite la creación de portlets basado en el estándar JSF
validation-api-1.0.0.GA
Sirve para validar parámetros dentro de un bean.
xercesImpl-2.4.0 Un parser de XML
Tabla 4 Librerías eliminadas
Todas estas librerías se eliminaron ya que a fueron removidas a la hora de compilar y la aplicación compiló y corrió correctamente una vez instalada en el Portal.
10.3.5 Información y punto de vista de la información
Sólo se agregó un atributo llamado “descripción” (String) a la clase ruta. Debido a que no hubo cambios en la lógica de negocios no hubo mayores cambios en estas dos vistas.
10.4 C
AMBIOS EN TECNOLOGÍAS10.4.1 De Vaadin a JSP
El cambio más importante logrado durante el proyecto fue el cambio de tecnología de la capa de presentación. De usar Vaadin como framework, se pasó a utilizar JSR-286 en todos los portlets del Portal Viaje. Al usar el estándar de Java para portlets el mantenimiento y modificación de la capa de presentación es más sencillo ya que no es necesario conocer Vaadin para programar, al conocer tecnologías básicas de la capa web (HTML,CSS,AJAX,Javascript) y Java cualquier programador puede modificar el Portal a su antojo. Adicionalmente, se redujeron el número de clases por portlet de 6 a 2, lo que permite comprender y mantener el código de una manera más sencilla.
38
11
E
VALUACIÓN RESULTADO Y TRABAJO FUTURO
11.1
ESTADO DELP
ORTAL DESPUÉS DEL PROYECTOTras finalizar el proyecto y cumplir una parte de los objetivos el Portal Viaje se encuentra en un estado de transición hacia un ambiente móvil, con avances significativos desde el punto de vista del usuario y desarrollo. Con una documentación completa, unos portlets realizados en tecnologías más conocidas y unos lineamientos claros sobre el futuro del Portal Viaje, este proyecto seguirá evolucionando y no se estancará como ha ocurrido en ocasiones pasadas. Los cambios inmediatos para el usuario se notarán en la capacidad de acceder al Portal Viaje desde su teléfono móvil de manera más amigable. Por otro lado, cualquier programador interesado en trabajar en el proyecto le será mucho más fácil empezar a trabajar en el aplicativo, pues ya existe una base de documentos y trabajo realizado que permite que la curva de aprendizaje sobre la aplicación mucho más corta.
11.2 T
RABAJO POR REALIZARAunque se realizó una cantidad de trabajo significativa durante el semestre sobre el Portal, el análisis sobre la aplicación demuestra que todavía hay mucho por hacer. Algunos de los objetivos no se cumplieron (o se cumplieron parcialmente) y el usuario todavía encuentra dificultad a la hora de utilizar el Portal Viaje si se compara con soluciones como “Wheels Uniandes”. En el corto plazo se busca que el Portal Viaje sea la solución preferida por las personas vinculadas a la universidad para compartir su carro, para esto se deben afrontar retos importantes que se presentan a continuación:
11.2.1 Modificar el sistema de creación de rutas y ubicaciones para mejorar su usabilidad
El sistema de creación de rutas y ubicaciones sigue siendo el principal obstáculo para que más usuarios utilicen el Portal, múltiples quejas de los usuarios y problemas de usabilidad hacen la tarea de crear una ruta o ubicación una tarea difícil y tediosa. Por esta razón, es prioridad modificar este sistema dentro del Portal Viaje para que los usuarios creen de manera fácil y rápida sus rutas y ubicaciones dentro de la aplicación.
11.2.2 Integrar el Portal Viaje con Facebook
Como lo demuestra la tesis de grado de Natalia Torres, la integración con Facebook del Portal Viaje es una necesidad imperante si se quiere aumentar la base de usuarios que buscan y comparten viajes por medio de la aplicación.
11.2.3 Crear una aplicación móvil del Portal Viaje
Como se ha afirmado en varias ocasiones en este documento, el Portal Viaje debe tener una aplicación móvil si quiere aumentar la base de usuarios que lo utilizan. Esta tarea debe hacerse lo más pronto posible y mínimo debe contar con aplicaciones para los dos sistemas operativos más populares del mercado en la actualidad (Android y IOS).
39
11.2.4 Realizar la migración hacia un Portal de aplicaciones distinto
Dentro de los lineamientos planteados por este proyecto de grado se describe la necesidad de migrar el Portal Viaje hacia un Portal de contenidos distinto de Liferay. Esta tarea debe hacerse lo más pronto posible para empezar a construir nuevas funcionalidades sobre el Portal Viaje, pero ya instalado sobre una nueva plataforma.
11.2.5 Cualquier otro trabajo que demande el contexto
El Portal Viaje es una aplicación crucial para la Universidad de Los Andes y su crecimiento es un imperativo para que la institución mantenga vigente su política de movilidad sostenible. Por esta razón el Portal Viaje deberá estar en continua mejora y su desarrollo no deberá estancarse como ha ocurrido en semestres pasados.
12
T
RABAJO ADICIONAL
2014
Y NUEVA VERSIÓN
El trabajo realizado durante los 6 meses que duró el proyecto de grado fue necesario, más no suficiente, para modernizar y convertir al Portal Viaje en una solución competitiva para promover el uso del carro compartido dentro de la Universidad de los Andes. Aun así, las propuestas arquitecturales y de software planteadas en el documento sentaron las bases para la realización de cambios profundos en el Portal Viaje, en miras a mejorar la experiencia de usuario y aprovechar el auge de los teléfonos inteligentes para ganar mercado. Un resumen de estos cambios y el estado del Portal Viaje al inicio del primer semestre del 2015 son presentados al lector a continuación.
12.1 O
BJETIVOS PLANTEADOS NUEVA ETAPAUn análisis profundo desde el punto de vista de usabilidad realizado por la diseñadora Natalia Ardila Torres con ayuda de Mario Sanchez y Maurix Suarez reveló que el uso del Portal Viaje resultaba tedioso y complicado para los usuarios en comparación con otras alternativas para compartir el carro que no estaban presentes cuando el Portal fue lanzado en el 2010 (véase grupo en Facebook “Wheels Uniandes” o “On the Way”). Por otro lado, aprovechando el uso extendido de los teléfonos inteligentes, como fue descrito en la primera parte del documento, era imperativo no sólo mejorar el Portal Viaje en temas de usabilidad si no crear una aplicación móvil lo más pronto posible. Asimismo los siguientes objetivos reflejan un deseo de usar tecnologías más abiertas y adecuadas para el Portal Viaje como se argumentó en la sección de análisis de tecnologías:
O1.Rediseñar la interfaz web del Portal Viaje teniendo como eje la usabilidad por parte del usuario.
O2.Crear una aplicación móvil para IOS del Portal Viaje, teniendo en cuenta los lineamientos planteados en la tarea anterior.
