prototipo arquitectural para la...
Post on 19-Sep-2018
220 Views
Preview:
TRANSCRIPT
PROTOTIPO ARQUITECTURAL PARA LA INTEROPERABILIDAD ENTRE PLATAFORMAS EMPRESARIALES Y PLATAFORMAS MOVILES QUE
SOPORTAN INTERACCION CON SERVICIOS GEOGRAFICOS
SERGIO CAMILO TORRES MOLINA RAUL ANDRES CASTRO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA INGENIERIA DE SISTEMAS
BOGOTA D.C. 2015
PROTOTIPO ARQUITECTURAL PARA LA INTEROPERABILIDAD ENTRE PLATAFORMAS EMPRESARIALES Y PLATAFORMAS MOVILES QUE
SOPORTAN INTERACCION CON SERVICIOS GEOGRAFICOS
AUTORES: SERGIO CAMILO TORRES MOLINA: 20032020145
RAUL ANDRES CASTRO: 20032020030
PROYECTO DE GRADO
MODALIDAD DE MONOGRAFIA
DIRECTOR:
JULIO BARON VELANDIA Profesor Facultad de Ingeniería
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA INGENIERIA DE SISTEMAS
BOGOTA D.C. 2015
INDICE GENERAL
CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA ............................................ 8
1.1 DESCRIPCIÓN DEL PROBLEMA .............................................................. 8
1.2 FORMULACIÓN DEL PROBLEMA ............................................................ 9
1.3 JUSTIFICACIÓN DEL PROBLEMA .......................................................... 10
CAPÍTULO 2. OBJETIVOS Y ALCANCES DEL PROYECTO ............................ 11
2.1 OBJETIVO GENERAL .............................................................................. 11
2.2 OBJETIVOS ESPECIFICOS ..................................................................... 11
2.3 ALCANCES .............................................................................................. 12
2.4 LIMITACIONES ........................................................................................ 12
2.5 RESULTADOS ESPERADOS .................................................................. 12
CAPÍTULO 3. MARCO REFERENCIAL ............................................................. 14
3.1 MARCO CONCEPTUAL ........................................................................... 14
3.2 MARCO TEORICO ................................................................................... 23
CAPÍTULO 4. MARCO METODOLOGICO ......................................................... 41
4.1 METODOLOGÍA ....................................................................................... 41
4.2 DISEÑO DE LA PROPUESTA DE INVESTIGACION ............................... 41
4.3 PROCESO DE DESARROLLO DEL PROYECTO ................................... 43
CAPÍTULO 5. MARCO TEMÁTICO .................................................................... 48
5.1 GESTIÓN DEL PROYECTO BAJO EL MODELO OPENUP .................... 48
5.2 CARONTE ................................................................................................ 78
CAPÍTULO 6. RESULTADOS .......................................................................... 101
CAPÍTULO 7. BIBLIOGRAFIA .......................................................................... 104
CAPÍTULO 8. ANEXOS .................................................................................... 106
8.1. EVALUACION DEL PROYECTO: ANALISIS COSTO / BENEFICIO ...... 106
8.2. PLAN DE RIESGOS O RISKLIST .......................................................... 110
8.3. ESPECIFICACIÓN DE CASOS DE PRUEBA ........................................ 111
INDICE DE TABLAS
TABLA 1. ESTILOS ARQUITECTÓNICOS ............................................................ 17 TABLA 2. PLANTEAMIENTO DEL PROBLEMA.................................................... 49 TABLA 3. CARACTERIZACIÓN DEL PRODUCTO ............................................... 49 TABLA 4. COMPENDIO DE INVOLUCRADOS DE INTERÉS .............................. 50
TABLA 5. NECESIDADES Y CARACTERÍSTICAS ............................................... 51 TABLA 6. OTROS REQUERIMIENTOS ................................................................ 53 TABLA 7. HITOS Y OBJETIVOS ........................................................................... 55 TABLA 8. HITOS FASE DE INICIO ....................................................................... 57
TABLA 9. HITOS FASE DE ELABORACIÓN ........................................................ 58 TABLA 10. HITOS FASE DE CONSTRUCCIÓN ................................................... 58
TABLA 11. HITOS FASE DE PRUEBAS ............................................................... 59 TABLA 12. LISTADO MAESTRO DE REQUERIMIENTOS ................................... 60
TABLA 13. CASO DE USO INGRESAR A LA APLICACIÓN ................................. 68 TABLA 14. CASO DE USO CREAR USUARIOS ................................................... 70 TABLA 15. CASO DE USO MODIFICAR USUARIOS ........................................... 71
TABLA 16. CASO DE USO CONSULTAR USUARIOS ......................................... 72 TABLA 17. CASO DE USO CREAR ASEGURADORAS ....................................... 72
TABLA 18. CASO DE USO MODIFICAR ASEGURADORAS................................ 73 TABLA 19. CASO DE USO CONSULTAR ASEGURADORAS .............................. 73
TABLA 20. CASO DE USO REGISTRAR ACCIDENTE ........................................ 74 TABLA 21. CASO DE USO CONSULTAR ACCIDENTE ....................................... 75
TABLA 22. CASO DE USO VER DETALLE ACCIDENTE ..................................... 76 TABLA 23. CASO DE USO IDENTIFICAR ACCIDENTE ....................................... 77 TABLA 24. CASO DE USO OBTENER UBICACIÓN ............................................. 77
TABLA 25. FACTORES DE SELECCIÓN SERVIDOR DE APLICACIONES......... 78 TABLA 26. FACTORES DE SELECCIÓN LENGUAJE DE PROGRAMACIÓN ..... 79 TABLA 27. FACTORES DE SELECCIÓN PLATAFORMA MÓVIL ........................ 80 TABLA 28. FACTORES DE SELECCIÓN APIS GEOGRÁFICAS ......................... 80
TABLA 29. FACTORES DE SELECCIÓN SERVIDORES DE APLICACIÓN ........ 81 TABLA 30. PATRONES CAPA DE PRESENTACIÓN ........................................... 83 TABLA 31. PATRONES CAPA DE NEGOCIO ...................................................... 83
TABLA 32. PATRONES CAPA DE INTEGRACIÓN .............................................. 84 TABLA 33. CUADRO DESCRIPTIVO IMPLEMENTACIÓN DAO .......................... 89 TABLA 34. CUADRO DESCRIPTIVO IMPLEMENTACIÓN ENTITY ..................... 90 TABLA 35. CUADRO DESCRIPTIVO IMPLEMENTACIÓN EXCEPTION ............. 90
TABLA 36. CUADRO DESCRIPTIVO IMPLEMENTACIÓN RESOURCEMAN...... 91 TABLA 37. CUADRO DESCRIPTIVO IMPLEMENTACIÓN SERVICES ................ 92 TABLA 38. CUADRO DESCRIPTIVO IMPLEMENTACIÓN CHECKEDEXCEP .... 93 TABLA 39. CUADRO DESCRIPTIVO IMPLEMENTACIÓN DTO .......................... 94 TABLA 40. CUADRO DESCRIPTIVO HELPER..................................................... 94 TABLA 41. CUADRO DESCRIPTIVO SESSION FACADE ................................... 96
TABLA 42. CUADRO DESCRIPTIVO UTILS ......................................................... 96 TABLA 43. CUADRO DESCRIPTIVO IMPLEMENTACIÓN MANAGEDBEANS ... 97 TABLA 44.CUADRO DESCRIPTIVO IMPLEMENTACIÓN SECURITYUTILS....... 98 TABLA 45. CUADRO DESCRIPTIVO IMPLEMENTACIÓN WEB SERVICES ...... 99 TABLA 46. CUADRO DESCRIPTIVO IMPLEMENTACIÓN OTROS. .................... 99
TABLA 47. RELACIÓN COSTO BENEFICIO. ..................................................... 108 TABLA 48. LISTADO DE PLAN DE RIESGOS .................................................... 110 TABLA 49. ESPECIFICACIÓN PRUEBAS CU001 .............................................. 111 TABLA 50. ESPECIFICACIÓN PRUEBAS FE 1 CU002 ...................................... 112 TABLA 51. ESPECIFICACIÓN PRUEBAS FE 2 CU001 ...................................... 112
TABLA 52. ESPECIFICACIÓN PRUEBAS CU002 .............................................. 114
TABLA 53. ESPECIFICACIÓN PRUEBAS FE 1 CU002 ...................................... 115
TABLA 54. ESPECIFICACIÓN PRUEBAS FE 2 CU002 ...................................... 116 TABLA 55. ESPECIFICACIÓN PRUEBAS FE 3 CU002 ...................................... 117 TABLA 56. ESPECIFICACIÓN PRUEBAS FE 4 CU002 ...................................... 118 TABLA 57. ESPECIFICACIÓN PRUEBAS CU004 .............................................. 118
TABLA 58. ESPECIFICACIÓN PRUEBAS CU005 .............................................. 120 TABLA 59. ESPECIFICACIÓN PRUEBAS CU006 .............................................. 121
TABLA 60. ESPECIFICACIÓN PRUEBAS CU007 .............................................. 122 TABLA 61. ESPECIFICACIÓN PRUEBAS CU008 .............................................. 122 TABLA 62. ESPECIFICACIÓN PRUEBAS CU009 .............................................. 124
TABLA 63. ESPECIFICACIÓN PRUEBAS CU010 .............................................. 125 TABLA 64. ESPECIFICACIÓN PRUEBAS CU011 .............................................. 126
TABLA 65. ESPECIFICACIÓN PRUEBAS CU012 .............................................. 127
INDICE DE FIGURAS
FIGURA 1. MODELO DE ARQUITECTURA .......................................................... 14 FIGURA 2. ESQUEMA DE CALIDAD DE SOFTWARE ......................................... 20
FIGURA 3. COMPONENTES DE LA CAPA CLIENTE .......................................... 24 FIGURA 4. CAPA WEB ......................................................................................... 25 FIGURA 5. LÓGICA DE EJECUCIÓN ENTRE LAS CAPAS ................................. 26 FIGURA 6. COMPONENTES HIBERNATE ........................................................... 30 FIGURA 7. COMPARATIVO DE LOS TIPOS DE SERVICIOS .............................. 35
FIGURA 8. CICLO DE VIDA DE UNA ACTIVIDAD ................................................ 36
FIGURA 9. COMPONENTES GENERALES DEL SISTEMA ................................. 40 FIGURA 10. CICLO DE VIDA DE UNA ITERACIÓN ............................................. 45
FIGURA 11. RELACIONES EN EL CICLO DE VIDA DE UN PROYECTO. ........... 46
FIGURA 12. MODELO ARQUITECTURAL (VISTA LÓGICA)................................ 67 FIGURA 13. DIAGRAMA DE CASOS DE USO ..................................................... 68
FIGURA 14. PATRONES JEE ............................................................................... 83 FIGURA 15. COMPONENTE GEOGRÁFICO ........................................................ 85 FIGURA 16. SISTEMAS Y RECURSOS INVOLUCRADOS .................................. 85
FIGURA 17. REPRESENTACION NIVELES DE ARQUITECTURA ANDROID..... 86 FIGURA 18. ARQUITECTURA ESPECIFICA DEL SISTEMA ............................... 87
FIGURA 19. IMPLEMENTACIÓN DAO ................................................................. 88
FIGURA 20. IMPLEMENTACIÓN ENTITY ............................................................ 89
FIGURA 21. IMPLEMENTACIÓN EXCEPTION..................................................... 90 FIGURA 22. IMPLEMENTACIÓN RESOURCEMANAGER ................................... 91
FIGURA 23. IMPLEMENTACIÓN SERVICES ....................................................... 92 FIGURA 24. IMPLEMENTACIÓN CHECKEDEXCEPTION ................................... 93 FIGURA 25. IMPLEMENTACIÓN DTO .................................................................. 93
FIGURA 26. IMPLEMENTACIÓN HELPER ........................................................... 94 FIGURA 27. IMPLEMENTACIÓN SESSION FACADE .......................................... 95
FIGURA 28. IMPLEMENTACIÓN UTILS ............................................................... 96 FIGURA 29. IMPLEMENTACIÓN MANAGEDBEANS ........................................... 97 FIGURA 30. IMPLEMENTACIÓN SECURITYUTILS ............................................. 98 FIGURA 31. IMPLEMENTACIÓN WEB SERVICES .............................................. 98
FIGURA 32. MODELO DE DATOS ........................................................................ 99 FIGURA 33. LÍNEA BASE ................................................................................... 107 FIGURA 34. ARQUITECTURA OBJETIVO. ........................................................ 107
CONSIDERACIONES DE DOCUMENTACIÓN
Este documento tiene en cuenta la Norma Técnica Colombiana NTC 1486 para la presentación de tesis, trabajos de grado y otros trabajos de investigación y la Norma Técnica Colombiana NTC 5613 de referencias bibliográficas, contenido forma y estructura.
AGRADECIMIENTOS
El más cordial agradecimiento a nuestro director de proyecto de grado Julio Barón Velandia cuyos lineamientos y conocimientos ayudaron a encauzar el camino para la materialización de esta iniciativa.
A nuestro jurado Alberto Acosta por permitirnos retribuir al menos un poco el conocimiento obtenido y demostrar lo que la universidad ha forjado.
Queremos resaltar los valiosos aportes de Cristian David Palomino, analista de pruebas (Certified tester ISTQB foundation level) quien nos guió en el aseguramiento de calidad de la documentación y la implementación realizada.
Por ultimo a nuestras familias quienes nos han brindado la fuerza y el apoyo para recorrer este camino lleno de retos y desafíos pero al final lleno del sentimiento de satisfacción y realización tanto personal como profesional.
8
CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN DEL PROBLEMA
Producto de la revolución tecnológica de las últimas décadas están emergiendo una gran cantidad de sistemas de información que por lo general están construidos sobre diferentes plataformas y lenguajes de programación, sin embargo la disponibilidad, validez e integridad de la información son necesidades que se tienen que seguir cumpliendo principalmente en soluciones que se implementan para entornos empresariales, un ejemplo son los ERP (por sus siglas en inglés, enterprise resource planning o planificación de recursos empresariales en español) los cuales se alimentan de varias fuentes de información y cuentan con una gran cantidad de reglas de negocio las cuales obedecen a intereses de múltiples áreas de la organización (comercial, administrativa, gerencial u operativa), revisando el tema a gran escala para la integración de estas plataformas existen buses empresariales los cuales interpretan y traducen el paso de mensajes entre las mismas, sin embargo si una organización contemplara la iniciativa de intentar descentralizar sus funcionalidades trasladándolas a un entorno móvil encontraría una barrera al querer cumplir ese deseo debido a la baja disponibilidad de recursos que tiene en este ambiente, esto sin mencionar que las oportunidades de mejora al operar con este tipo de aplicaciones se deben reflejar en un soporte del negocio más versátil y transversal que permita a la vez un manejo complejo y robusto de la capa de lógica de negocio con el fin de responder y adaptarse a las variaciones del entorno con implementaciones cada vez más portables y que integren el uso de herramientas geográficas.
Es así como la arquitectura de software surge como pilar fundamental en el propósito de lograr la descentralización de estos sistemas situándose como una de las principales necesidades de la industria del Software a nivel mundial, sin embargo en la fase de análisis y diseño arquitectural pueden existir diferentes enfoques para un mismo escenario de solución, cada uno planteando su propio conjunto de patrones, componentes, herramientas, buenas prácticas, ventajas y desventajas por lo que en ultimas el verdadero resultado que debe obtenerse de la fase de análisis es la correcta elección de ese conjunto de elementos para lograr la implementación más adecuada conforme al requerimiento que se está abordando
En el documento “Introducción a la Arquitectura de Software” de David Garlan y Mary Shaw se argumenta la relevancia de la Arquitectura de Software en el aumento del tamaño y la complejidad de los sistemas de software, los autores plantean que la fase del diseño tiene que ir más allá de los algoritmos y estructuras de datos en un proceso de computación y concentrarse más en el
9
diseño y especificación de la estructura general del sistema, no obstante para lograr que esta interacción sea fluida y transparente en los componentes que constituyen el sistema hay que lograr un nivel apropiado de abstracción de las funcionalidades con el fin de acceder de modo estandarizado a la lógica que se encuentra encapsulada en estas, una vez establecido ese modelo se definen las interfaces por la cuales se constituyen los contratos en el que los componentes se comunicarán y compartirán la información; Es en este punto donde se plantea el escenario de análisis para definir cuáles son los parámetros, las interacciones y los componentes que conformarán el sistema para lograr un ambiente colaborativo funcional, sin embargo uno de los principales inconvenientes de los dispositivos móviles como tabletas o teléfonos inteligentes radica en sus limitadas capacidades en cuanto a recursos como almacenamiento, memoria y demás aspectos técnicos en comparación con equipos de cómputo tradicionales.
Adicionalmente se debe tener presente que la efectividad de una solución de este estilo se encuentra directamente relacionada a la interacción entre los diferentes componentes que la conforman con el usuario y con otros sistemas, variables como el tiempo de respuesta, la calidad del formato y la cantidad de información son métricas que definen en última instancia el nivel de aceptación final, en el propósito de hacer que esta interacción sea factible hoy en día han surgido herramientas informáticas como lenguajes de programación multiplataforma y metodologías arquitecturales que permiten establecer la sinergia de múltiples sistemas implementados en diferentes tecnologías.
1.2 FORMULACIÓN DEL PROBLEMA
Dado un conjunto de funcionalidades de negocio que soportan una interacción con servicios geográficos ¿qué componentes, patrones y herramientas se requieren para la confiabilidad, escalabilidad, portabilidad y disponibilidad de la lógica de negocio y de la información que se encuentra centralizada ambientes empresariales robustos para ser aplicada en dispositivos móviles?
10
1.3 JUSTIFICACIÓN DEL PROBLEMA
Entre los avances de mayor desarrollo y popularización en la actualidad se encuentra la Internet móvil la cual ha permitido compartir información en tiempo real de una forma más eficiente gracias al uso de dispositivos móviles, conforme a la experiencia obtenida en el desarrollo de actividades laborales en entornos empresariales se percibe la oportunidad de extender estos avances a escenarios de negocio de mayor complejidad; Realizando indagaciones preliminares se encuentra que la mayoría de organizaciones encuentran una barrera tecnológica en el deseo de descentralizar la información de sus compañías principalmente por la gran cantidad de personalizaciones hechas a las herramientas, a una lógica de negocio muy compleja y a las diferentes plataformas tecnológicas sobre las que esta se apoya.
En un primer acercamiento al escenario solución se contempla una gran oportunidad en el desarrollo de este proyecto al adelantar el análisis y aplicación de patrones de diseño en la implementación de la API (en inglés Application Programming Interfaceo interfaz de programación de aplicaciones en español) de dispositivos móviles la cual es de reciente aparición y que en revisiones a la documentación entregada por el fabricante presenta una gran versatilidad, por otro lado el uso de software libre permite la utilización y explotación de funcionalidades y componentes expuestos por herramientas propietarias con un costo muy bajo (casi nulo) optimizando la relación costo/beneficio de este tipo de implementaciones.
El propósito del presente proyecto es proponer el diseño y establecer las características de arquitectura para la implementación de una aplicación móvil que integre escenarios de negocio robustos e información geográfica para plataformas móviles brindando una aproximación al fundamento teórico y práctico que un desarrollo de esta naturaleza pueda poseer para su puesta en escena avalando su mantenibilidad y adaptabilidad a lo largo del tiempo. Por ultimo emplear este diseño en el desarrollo de un prototipo orientado a respaldar y alentar la escasa oferta de soluciones con enfoque empresarial que existe en el mercado hoy en día, buscando maximizar el aprovechamiento de estas tecnologías que en la actualidad se encuentran en proceso de popularización y avance
Como aporte a la innovación hay un impacto positivo en este proyecto debido a que se plantean las bases, directrices y lineamientos para la implementación de soluciones móviles que integren escenarios empresariales complejos, dándoles el rigor académico necesario de cualquier disciplina y brindándole un enfoque dirigido a la incorporación de patrones que apliquen en el proceso de integración de las diferentes tecnologías y a las buenas prácticas que propone la industria para su posterior discusión y mejora.
11
CAPÍTULO 2. OBJETIVOS Y ALCANCES DEL PROYECTO
2.1 OBJETIVO GENERAL
Diseñar y desarrollar una arquitectura que permita una integración robusta entre el entorno empresarial con plataformas móviles utilizando herramientas geográficas interactuando en una arquitectura orientada a servicios.
2.2 OBJETIVOS ESPECIFICOS
2.2.1 Establecer los criterios de diseño arquitecturales para cada uno de los componentes que garanticen una alta cohesión entre los mismos para obtener artefactos ampliamente escalables y que describa las siguientes características:
Soporte multiplataforma de los componentes de software generados.
Utilización de estándares y estrategias de diseño para su mantenibilidad y escalar el modelo de negocio exponiendo de manera segura los elementos del mismo.
Acceso a componentes complejos modulares a través de interfaces ligeras. 2.2.2 Analizar la viabilidad arquitectural mediante la elaboración de unas matrices donde se compare las cualidades, funciones, ventajas y desventajas para el desarrollo de aplicaciones en dispositivos móviles que proporcione integración con entornos robustos, agilidad en el desarrollo, funcionalidad, mantenimiento, seguridad en la información y velocidad en la ejecución teniendo presente el costo total de propiedad Vs. estimación de beneficios de esa implementación desde un enfoque metodológico y tecnológico de las diferentes plataformas indagadas logrando un balance entre calidad y esfuerzo. 2.2.3 Diseñar la arquitectura de una aplicación móvil que establezca una conexión liviana con aplicaciones empresariales. 2.2.4 Realizar autenticación sobre una BD, consulta y actualización datos y cargar información basada en un sistema espacial georeferenciado. 2.2.5 Desarrollar la aplicación prototipo bajo un sistema operativo para móviles el cual será elegido conforme a los resultados del análisis de factibilidad, aplicando la arquitectura diseñada como evidencia de la viabilidad de lo planteado.
12
2.3 ALCANCES
Con el desarrollo del presente proyecto se busca la realización de los siguientes hitos como consolidación y aplicación de lo propuesto:
2.3.1 La definición de arquitectura debe permitir a la aplicación móvil el uso de un módulo de mapas que permita hacer uso de las herramientas geográficas dentro del dispositivo móvil y de servicios como la captura de imágenes a través de la cámara del mismo. 2.3.2 Se contempla el desarrollo de un cliente web por lo que se debe suministrar tanto para este como para la aplicación móvil estándares mínimos de seguridad para el ingreso mediante un componente centralizado. 2.3.3 Utilización de XML por su flexibilidad para que la arquitectura tenga la capacidad de interoperar con otras tecnologías lo que garantizará que los métodos de negocio puedan ser utilizados tanto desde el cliente web como desde el aplicativo móvil. 2.3.4 Garantizar la integridad dela información que se trasmite y se recibe en el dispositivo móvil debido a que la aplicación debe transferir archivos binarios.
2.4 LIMITACIONES
Las características que se listan a continuación se establecen como cotas para el proyecto.
2.4.1 En el ideal de soportar el proyecto en tecnologías libres y de bajo costo se contempla el desarrollo de la línea base del aplicativo móvil con una capacidad funcional inicial, cualquier oportunidad de mejora se evidenciará por escrito sin que esto afecte el proceso de la implementación. 2.4.2 Se considera a ARCGIS como el proveedor de servicio de mapas más viable para la implementación en este proyecto por la experiencia, la robustez de la plataforma y calidad de la información, conforme a esto los demás requerimientos y tecnologías que se diseñen y levanten deberán ir alineados a las especificaciones técnicas que se soporten en tal plataforma.
2.5 RESULTADOS ESPERADOS
Se consideran los siguientes entregables como los demostrables deseables que resultarán de la ejecución del proyecto:
2.5.1 Documentación soportando el Diseño arquitectural del prototipo representando la interoperabilidad entre los componentes.
13
2.5.2 Documentación con aplicación de la metodología OpenUP para el desarrollo y gestión del proyecto 2.5.3 Aplicativo Web con funcionalidades iniciales básicas evidencia de la aplicación del diseño. 2.5.4 Aplicativo Móvil Interoperando con escenario empresarial robusto. 2.5.5 Servidor de aplicaciones con implementaciones de negocio robustas interoperando con el dispositivo móvil.
14
CAPÍTULO 3. MARCO REFERENCIAL
3.1 MARCO CONCEPTUAL
3.1.1 Arquitectura de software y su relevancia. Siendo el software una estructura compleja debe ser construida desde una base conceptual sólida, no considerar escenarios clave como problemas comunes, mantenibilidad o permanencia a largo plazo puede poner cualquier intento de implementación en riesgo. Herramientas y entornos de desarrollo simplifican la creación de aplicaciones pero no reemplazan la necesidad de diseñar la aplicación teniendo en cuenta diferentes escenarios y requerimientos específicos. Los riesgos implícitos en una mala arquitectura incluyen: software inestable, pobre desempeño en un entorno de producción, difícil adopción o implementación y que no es capaz de soportar los requerimientos de negocio existentes o futuros. Los sistemas deben ser diseñados en consideración con el usuario, el sistema (la infraestructura de Tecnologías de la Información) y los objetivos de negocio. Para cada una de estas áreas se deben esbozar escenarios clave identificando atributos de calidad importantes (por ejemplo la fiabilidad o la escalabilidad) y áreas clave de la satisfacción y la insatisfacción del usuario y en lo posible se debe desarrollar y considerar las métricas que miden el éxito encada una de estas áreas, a continuación se representa en una figura la interacción de estas áreas en la conformación de un modelo de arquitectura.
Figura 1. Modelo de Arquitectura
Fuente los autores
El equilibrio y armonía entre los requisitos de estas tres áreas es esencial, por ejemplo la experiencia general del usuario de la solución es a menudo una suma de las necesidades de negocio con la infraestructura que la soporta, sin embargo
15
los cambios en uno o el otro puede afectar significativamente el resultado de esta experiencia, del mismo modo cambios en los requisitos de frente a la experiencia de usuario pueden tener un impacto significativo en los requerimientos de negocios e infraestructura en entornos donde el rendimiento podría ser un objetivo importante para el usuario, pero el dueño del sistema puede no ser capaz de invertir recursos en el hardware requerido para cumplir con esa meta el 100 por ciento de las veces o el hardware cuenta con recursos limitados como es el caso de los dispositivos móviles. Es por eso que la arquitectura de software se centra en cómo los principales elementos y componentes dentro de una aplicación son utilizados o interactúan con otros elementos y componentes más importantes dentro de la aplicación, la selección de las estructuras de datos y algoritmos o los detalles de la implementación de los componentes individuales son los temas de análisis y diseño. La arquitectura y el diseño son preocupaciones que muy a menudo se superponen, en lugar de utilizar reglas específicas y rápidas para distinguir entre la arquitectura y el diseño hay un mayor sentido colaborativo cuando se combinan estas dos áreas. En algunos casos las decisiones son claramente más arquitectónicas de frente al entorno, pero en otros casos las decisiones pesan más sobre el diseño. 3.1.2 La arquitectura actual de las aplicaciones móviles. Con el paso de los años el diseño de aplicativos móviles parece cada vez más sencillo sin embargo la potencia de cálculo disponible en estos dispositivos se encuentra aún por detrás de sus homólogos de escritorio o servidores y en el corto o mediano plazo no se vislumbra un cambio significativo en ese sentido, Incluso los dispositivos más recientes todavía cuentan con sólo alrededor de un tercio o en el mejor de los casos la mitad de los recursos de computación (Memoria) de una computadora de escritorio de gama baja, adicionalmente la calidad de las conexiones de datos disponibles en un dispositivo móvil suele ser muy variables en base a la fuerza de la señal o localización la que es muy inferior a la banda ancha de acceso a Internet. A menudo durante el desarrollo ágil de aplicaciones estas consideraciones de rendimiento se ignoran hasta el final del proyecto y optimizados sólo cuando es necesario. En el desarrollo de aplicaciones móviles se debe tener más consideración en las limitaciones de rendimiento del dispositivo por lo que hay que dársele prioridad en la fase de diseño. Cada plataforma tiene diferentes “mejores prácticas” a nivel de código para la optimización del rendimiento en función del lenguaje de programación y los marcos disponibles en la plataforma, algunas buenas prácticas sin embargo temas como el uso correcto de la memoria y los límites al número de objetos creados innecesarios se pueden aplicar a todas las plataformas. En la fase de diseño se debe dar a las decisiones arquitectónicas mayor relevancia
16
especialmente a aquellas que pueden limitar el rendimiento y que también sean difíciles de cambiar posteriores al ciclo de desarrollo tales como el diseño de las interfaces de programación de servicios web y formatos de datos. Estas consideraciones se derivan principalmente del limitado ancho de banda disponible para los dispositivos móviles. Si es posible las API (Application Programming Interface por sus siglas en inglés o Interfaz de programación de aplicaciones en español) utilizadas por una aplicación móvil deben ser diseñados para recuperar sólo la información más relevante y útil excluyendo cualquier dato adicional que no sea utilizado por la aplicación. En el diseño de las API para comunicarse con las aplicaciones móviles existen varias recomendaciones como utilizar un formato de datos ligero como JSON en lugar de formato más detallado como XML con el fin de hacer el mejor uso del ancho de banda limitado disponible para dispositivos móviles. Entre algunas ventajas en el uso de un formato ligero como JSON se tienen:
Conservar el ancho de banda.
Permitir que los resultados que se obtengan más rápidamente.
Ágil deserialización de los datos a medida que llega al cliente. Otras consideraciones importantes respecto al rendimiento en un dispositivo móvil es la vida de la batería, por eso si se debe desarrollar una aplicación que este en constante sondeo de un servicio web para actualizaciones o procesamiento de datos en segundo plano continuamente, la batería se agotará más rápidamente. Si arquitectónicamente viable (y si existen las capacidades de notificación de inserción en la plataforma móvil), se recomienda el uso de notificaciones push para proporcionar actualizaciones de datos a través de votación periódica. Actualmente existen capacidades de notificación push en los teléfonos con plataformas iPhone, Android, y Windows 7. Por ultimo siendo la idea de la aplicación llevar a cabo una gran cantidad de procesamiento o análisis de datos estos deberán ser subidos a la plataforma del servidor de aplicaciones empresarial para que se realice allí el procesamiento intensivo de la CPU y luego devolver los resultados al dispositivo para evitar que se descargue la batería y proporcionar una experiencia más ágil al usuario. 3.1.3 Componentes, conectores y relaciones. En la investigación de arquitectura de software hay conceptos clave como los componentes y conectores, con el paso del tiempo la tecnología ha madurado a un nivel donde la adopción de la industria es muy extendida sin embargo se evidencian algunos principios fundamentales que aún permanecen, el punto de vista tradicional de la arquitectura de software adolece de una serie de problemas clave que no puede ser resuelto sin necesidad de cambiarla perspectiva sobre el mismo concepto de arquitectura de software. Estos problemas incluyen la falta de alta calidad en las decisiones y representaciones de diseño, el hecho de que estas decisiones de
17
diseño son transversales y se entrelazan, que estos problemas conducen a altos costos de mantenimiento, debido a que las reglas de diseño y limitaciones son fácilmente violados y las decisiones de diseño obsoletos no se eliminan, la principal consideración en este punto es que las decisiones de diseño deben permitir la posibilidad de añadir, quitar y cambiar los componentes del diseño arquitectónico con un menor esfuerzo en cualquier momento. 3.1.4 Estilos o Patrones Arquitectónicos. Un estilo arquitectónico a veces llamado patrón arquitectónico es un conjunto de principios-patrón que proporcionan un marco abstracto para una familia de sistemas. Un estilo arquitectónico mejora la clasificación y promueve la reutilización del diseño proporcionando soluciones a problemas recurrentes con frecuencia. Garlan y Shaw definen un estilo arquitectónico como: “un tipo de familia de sistemas en términos de un modelo de organización estructural. Específicamente un estilo arquitectónico determina el vocabulario de los componentes y conectores que se pueden utilizar en ese estilo, con un conjunto de restricciones sobre cómo se pueden combinar”. El beneficio más importante es que proporciona un lenguaje común con oportunidades para realizar diferentes tipos de análisis independientes de la tecnología que se hable, esto facilita un mayor nivel de entendimiento lo que también incluye patrones y principios, los estilos arquitectónicos se pueden organizar por su área clave de enfoque. La siguiente tabla muestra las principales áreas de interés y los correspondientes estilos arquitectónicos. Tabla 1. Estilos arquitectónicos
Categoría Estilo Arquitectural Descripción
Comunicación
Arquitectura Orientada a Servicios (SOA)
Se refiere a las aplicaciones que exponen y consumen funcionalidad como un servicio a través de contratos y mensajes.
Bus de mensajes
Un estilo de arquitectura que prescribe el uso de un sistema de software que puede recibir y enviar mensajes a través de uno o más canales de comunicación, por lo que las aplicaciones puedan interactuar sin necesidad de conocer los detalles específicos sobre la otra.
Despliegue Cliente / Servidor Segrega el sistema en dos aplicaciones, donde el cliente hace
18
Categoría Estilo Arquitectural Descripción
peticiones al servidor. En muchos casos, el servidor es una base de datos con la lógica de la aplicación representada como procedimientos almacenados.
N-capas
tres capas
Segrega funcionalidad en segmentos separados de la misma manera que el estilo en capas, pero con cada segmento siendo un nivel situado en un equipo separado físicamente.
Dominio Diseño Guiado por el dominio
Un estilo arquitectónico orientado a objetos centra en el modelado de un dominio del negocio y la definición de los objetos de negocio basado en las entidades del dominio del negocio.
Estructura
Basado en Componentes,
Se descompone el diseño de aplicaciones en componentes funcionales o lógicos reutilizables que exponen bien definidas las interfaces de comunicación.
Orientada a objetos
Un paradigma de diseño basado en la división de responsabilidades para una aplicación o sistema en objetos reutilizables y autosuficientes individuales, cada uno con los datos y el comportamiento relevantes para el objeto.
Arquitectura por niveles
Particiones de las preocupaciones de la aplicación en grupos apilados (capas).
Fuente los autores
3.1.5 Patrones de Diseño. Los patrones de diseño son los patrones de mediana escala. Son de menor escala que los patrones arquitectónicos, pero están en un
19
nivel más alto que los modismos específicos del lenguaje de programación. La aplicación de un patrón de diseño no tiene efecto en la estructura fundamental de un sistema de software, pero puede tener una fuerte influencia en la arquitectura de un subsistema. Agrupaciones relevantes de Patrones de Diseño:
Descomposición Estructural: Esta categoría incluye patrones que apoyan una descomposición adecuada de los subsistemas y componentes complejos en partes cooperantes. El patrón de todo-parte es el patrón más general de que somos conscientes de esta categoría. Cuenta con una amplia aplicabilidad para la estructuración de componentes complejos.
Organización de las actividades: Esta categoría comprende los patrones que definen cómo los componentes colaboran juntos para resolver un problema complejo. Aquí se resalta el patrón maestro-esclavo, lo que le ayuda a organizar el cálculo de los servicios para los cuales se requiere tolerancia a fallos o precisión de cálculo. También es compatible con la división de servicios en partes independientes y su ejecución en paralelo.
Control de acceso: Estos patrones custodian y controlan el acceso a los servicios o componentes. Aquí se encuentra el patrón Proxy que permite a los clientes la comunicación con el representante de un componente en lugar de con el componente en sí.
Gestión: Esta categoría grupa los patrones que organizan y dan las pautas para el manejo de las colecciones homogéneas de objetos, servicios y componentes en su totalidad. Se destacan dos patrones: el patrón Command Processor que aborda la gestión y programación de los comandos del usuario y el patrón View Handler que describe cómo administrar vistas en un sistema de software.
Comunicación: Los patrones de esta categoría ayudan a organizar la comunicación entre los componentes. Aquí está como ejemplo el patrón publicador-suscriptor el cual ayuda con la tarea de mantener datos consistentes entre los componentes cooperantes.
La mayoría de los patrones de diseño son independientes de un paradigma de programación en particular. Por lo general, pueden ser implementados fácilmente en una manera a objetos, pero todos nuestros patrones de diseño son suficientes para adaptarse a las prácticas de programación más tradicionales, en general como un estilo de procedimiento. 3.1.6 Calidad de Software. Según Pressman la calidad de software es “la concordancia con los requisitos funcionales y de rendimiento establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado de forma profesional”.
20
Una clasificación de atributos de calidad se muestra en la siguiente figura y está basada en el estándar internacional ISO 9126 para la evaluación de la calidad del software. Figura 2. Esquema de Calidad de Software
Fuente: los autores
3.1.6.1 Eficiencia: Conjunto de atributos que se correlacionan entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas
Desempeño: Grado en el cual un sistema o componente cumple sus funciones dentro de restricciones dadas tales como velocidad, exactitud, o uso de memoria. Ejecutar las funciones del sistema lo suficientemente rápido para satisfacer las expectativas del usuario
Disponibilidad: Asegurar que el servicio este “siempre” disponible. Procurar porque el servicio sea altamente accesible.
Disponibilidad = tiempo disponible / tiempo posible.
Escalabilidad: Capacidad para sostener la calidad del servicio a medida que aumenta la carga: o Escalabilidad Vertical: Adicionar capacidad de Memoria y CPU a los equipos
existentes. o Escalabilidad Horizontal: Adicionar el número de servidores
La Escalabilidad está muy ligada al desempeño y a la definición de la plataforma tecnológica. La escalabilidad surge como una solución para resolver los problemas de desempeño presentados en una aplicación. 3.1.6.2 Fiabilidad (Confiabilidad): Una vez el software se encuentra funcionando, según se especificó, la confiabilidad define la capacidad de un sistema de mantener su nivel de servicio bajo condiciones definidas por periodos
21
específicos de tiempo. Se fijan las tasas de falla para que el sistema sea aceptable.
Madurez: Atributos del software que se relacionan con la frecuencia de falla por fallas en el software.
Recuperabilidad: Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello.
Tolerancia a fallos: Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeño en casos de fallas de software o de una infracción a su interfaz especificada.
Cumplimiento de Fiabilidad: La capacidad del producto software para adherirse a normas, convenciones o legislación relacionadas con la fiabilidad.
3.1.6.3 Usabilidad (Facilidad de Uso): Habilidad de software para que el usuario invierta el mínimo esfuerzo en usar el sistema.
Facilidad de Aprendizaje: Mide la velocidad a la cual los usuarios nuevos se convierten en expertos utilizando el sistema.
Tiempo de un usuario típico en aprender la manera en cómo se usan los comandos relevantes a un conjunto de tareas: Se refiere a que tan rápido el usuario va a aprender a usar un sistema con el cual no había tenido contacto previamente. Este punto se refiere a la consecución de tareas básicas por parte de un usuario novato.
Tasas de error por parte de los usuarios: Este atributo se refiere a aquellos errores que comete el usuario al utilizar el sistema. Una aplicación ideal evitaría que el usuario cometiera errores y funcionaría de manera óptima a cualquier petición por parte del usuario. En la práctica esto difícilmente se logra. Es vital que una vez que se produzca un error el sistema se lo haga saber rápida y claramente al usuario, le advierta sobre la severidad del mismo y le provea de algún mecanismo para recuperarse de ese error.
Eficiencia: Mide el nivel de soporte que un sistema le provee al usuario para que termine con éxito sus tareas. Velocidad de desempeño, una vez que el usuario ha aprendido a utilizar el sistema, se va a ponderar el lograr la velocidad con que puede completar una tarea específica.
Memoria: Cuando un usuario ha utilizado un sistema tiempo atrás, y tiene la necesidad de utilizarlo de nuevo la curva de aprendizaje debe de ser significativamente menor que el caso del usuario que nunca haya utilizado dicho sistema. Esto es de primordial importancia para aplicaciones usadas intermitentemente.
Satisfacción subjetiva: Este atributo se refiere a la impresión subjetiva del usuario respecto al sistema.
3.1.6.4 Facilidad de mantenimiento (Mantenibilidad): La habilidad para identificar y corregir un defecto dentro de un componente de software.
22
Analizabilidad: Facilidad para diagnosticar en el sistema deficiencias o bugs o identificar partes que deben ser modificados.
Flexibilidad: qué tan fácil o difícil es hacer una modificación previamente especificada en el sistema
Estabilidad: Capacidad del producto de software de minimizar los efectos inesperados de las modificaciones
Facilidad para pruebas: Capacidad del producto de software de permitir evaluar las partes modificadas
Conformidad: Capacidad del producto de software de satisfacer los estándares o convenciones relativas a la mantenibilidad.
3.1.6.5 Portabilidad: Esta métrica define que tan fácil es adaptar el software para que corra sobre diferentes plataformas, no solo de sistemas operativos sino diferentes versiones diferentes esquemas, base de datos, navegadores y ambientes.
Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o desinstalar de forma exitosa en un determinado entorno.
Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de otro producto software determinado con el mismo propósito y en el mismo entorno.
Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.
Co-Existencia - Coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes.
3.1.6.6 Funcionalidad: Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas 3.1.6.7 Seguridad: Este atributo de calidad garantiza que la información no es ni modificada ni divulgada a nadie excepto aquellos estipulados por las reglas de seguridad. Para cumplirlo se basa en los siguientes principios básicos:
Identidad: Los usuarios son identificados con un mecanismo de autenticación.
Autoridad: El usuario solo puede realizar acciones permitidas.
Integridad: La información solo puede ser alterada de formas permitidas.
Privacidad: La información solo es vista por las personas autorizadas de las formas autorizadas.
Auditoria: El sistema mantiene un registro de las acciones que se han realizado,
para efectos de análisis futuros.
23
3.2 MARCO TEORICO
En el contexto del desarrollo de este proyecto se ven involucrados diferentes plataformas, tecnologías, herramientas y soluciones con el propósito de lograr el objetivo de exponer las funcionalidades de negocio y la interoperación de las mismas. Principalmente se tienen cinco bloques de los cuales la mayoría de la documentación oficial de los fabricantes se encuentra aún en proceso de consolidación o en fuentes como Wikipedia, por lo que a continuación se describen y sintetizan específicamente las características más relevantes y de utilidad en el proyecto. 3.2.1 JAVA EE. Es una plataforma de programación parte del lenguaje Java para desarrollar y ejecutar software de aplicaciones.(ORACLE, 2013) JEE permite utilizar arquitecturas de N capas distribuidas y se apoya en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación similar a otras especificaciones de Java, sin embargo también es considerada informalmente como un estándar debido a que los proveedores deben cumplir ciertos requisitos para declarar que sus productos son conformes a Java EE estandarizado por The Java Community Process. 3.2.1.1 Componentes en JEE. Un componente Java EE es una unidad de software funcional auto-contenida que se ensambla en una aplicación con sus clases, archivos relacionados y tiene la capacidad de comunicarse con otros componentes (ORACLE, 2013). La especificación Java EE define los siguientes componentes:
Aplicaciones Cliente y applets: son componentes que se ejecutan en el cliente.
Java Servlets, JavaServer Faces y JavaServerPages (JSP): componentes de la tecnología que se ejecutan en el servidor (componentes web).
Componentes EJB: son componentes de negocio que se ejecutan en el servidor.
Los componentes Java EE están escritos en el lenguaje de programación Java y son compilados en la misma forma. Las diferencias entre los componentes Java EE y las clases Java "normales" se fundamenta en que los componentes Java EE son ensamblados en una aplicación Java EE que se despliega en ambientes productivos en el que son administrados y gestionados por un servidor Java EE. 3.2.1.2 Clientes Java EE los clientes Java EE por lo general son clientes web o aplicaciones cliente.
24
Clientes Web Un cliente web a veces se llama “cliente ligero” y se compone de dos partes: o Páginas web dinámicas que contienen varios tipos de lenguaje (HTML, XML,
etc), y son generados por los componentes web que se ejecutan en la capa web
o Navegador web que ejecuta las páginas recibidas desde el servidor.
Los clientes ligeros no suelen consultar bases de datos, ejecutar reglas de negocio complejas, o conectarse a aplicaciones heredadas(ORACLE, 2013). Cuando se utiliza un cliente ligero este tipo de operaciones robustas se asignan a Enterprise JavaBeans que se ejecutan en el servidor Java EE donde pueden aprovechar aspectos como la seguridad, velocidad y la fiabilidad de las tecnologías del lado del servidor. Los Enterprise JavaBeans se especifican en la sección 3.1.3
Aplicaciones Cliente. Las aplicaciones cliente se ejecutan en una máquina cliente y proporciona a los usuarios una interfaz gráfica para la interacción con el sistema y manejo de sus requerimientos.
Las aplicaciones cliente escritas en otros idiomas además de Java pueden interactuar con los servidores Java EE lo que le da a la plataforma gran versatilidad al permitirle interoperar con sistemas heredados, clientes e idiomas que no son Java. 3.2.1.3 Servidor de comunicaciones Java EE. La Figura 3 muestra los diversos elementos que constituyen la capa cliente la cual se comunica con la capa de negocio que se ejecuta en el servidor Java EE ya sea directamente o a través de páginas web que se ejecutan en la capa del mismo nombre.
Figura 3. Componentes de la capa cliente
Fuente: (ORACLE, 2013)
25
3.2.1.4 Componentes Web Java EE. Los componentes Web Java usan la tecnología Java Server Faces o tecnología JSP para la ejecución de las mismas(ORACLE, 2013) y por su clasificación estas pueden ser de dos tipos:
Servlets: son clases de lenguaje de programación que procesan dinámicamente peticiones y construyen respuestas.
Páginas JSP: son documentos basados en texto que se ejecutan como servlets pero permitir un enfoque más natural para la creación de contenidos estáticos.
Las páginas HTML estáticas y applets se empaquetan en los componentes web durante el ensamblaje de las aplicaciones, sin embargo estos no se consideran componentes web por la especificación Java EE. Como se muestra en la Figura 4 la capa web al igual que la capa cliente podría incluir el componente Enterprise JavaBeans para manejar la entrada del usuario y enviar ese flujo a la capa de negocio para su procesamiento. Figura 4. Capa Web
Fuente: (ORACLE, 2013)
3.2.1.5 Componentes de Capa de Negocio. La lógica de negocio que es la que en últimas resuelve o satisface las necesidades de un dominio en particular (banca, comercio, finanzas) está a cargo de que los Enterprise JavaBeans se ejecuten en la capa de negocio o en la capa web (ORACLE, 2013). En la siguiente figura se muestra cómo los Enterprise JavaBeans reciben los datos de programas cliente, los procesa si es necesario y los envía a la capa de información para el almacenamiento. Un Enterprise JavaBean también puede
26
recuperar los datos almacenados, procesarlos y enviarlos de vuelta a la aplicación cliente.
Figura 5. Lógica de ejecución entre las capas
Fuente: (ORACLE, 2013)
3.2.2 Servidor de Aplicaciones JEE. El servidor de aplicaciones JEE se puede definir como una plataforma de software que proporciona servicios de aplicación a los sistemas clientes, ofreciendo un componente de alto rendimiento para aplicaciones de negocio. El servidor de aplicaciones gestiona las peticiones de acceso a la lógica de negocio y acceso de datos de la aplicación. 3.2.2.1 El servidor de aplicaciones JBoss. Es el primer servidor de aplicaciones de código abierto preparado para la producción y certificado JEE, entre sus cualidades resalta su gran capacidad de procesamiento lo que le ha otorgado gran aceptación y popularidad a nivel general. (JBoss Comunity, 2014) Se ha seleccionado para el presente proyecto debido a su combinación entre una arquitectura orientada a servicios y una licencia de código abierto, JBoss AS puede ser descargado, utilizado, embebido y distribuido sin restricciones de licencia. Las características destacadas de JBoss incluyen:
Producto de licencia de código abierto sin coste adicional.
27
Cumple los estándares de la industria.
Confiable a nivel de empresa
Orientado a arquitectura de servicios.
Flexibilidad consistente
Servicios del middleware para cualquier objeto de Java.
Soporte completo para JMX. JBoss contiene un conjunto de API's (applicationProgramming Interface), que permiten la aplicación de estándares JEE, y la implementación de soluciones más robustas y mejor formadas. 3.2.2.2 Arquitectura JBoss. En un nivel macro el servidor de aplicaciones consta de dos elementos principales: (JBoss Comunity, 2014)
Un núcleo contenedor de servicios administrable basado en la carga de clases modulares.
Extensiones a ese núcleo que ofrecen a las funcionalidades que la mayoría de usuarios asocian con un servidor de aplicaciones como el manejo de las peticiones HTTP y gestión de transacciones
Núcleo del Servidor de Aplicaciones El núcleo del servidor de aplicaciones consta de los siguientes elementos principales: o Un sistema de carga de clases modular o Una infraestructura de contenedores de servicio rápido y de gran
escalabilidad o Una capa de gestión extensible que tiene la intención de mediar en el acceso
al contenedor de servicios mediante la lógica que se requiera agregar, eliminar o modificar. La capa de gestión también proporciona un modelo coherente y persistente de configuración para el servidor de aplicaciones. La capa de gestión posee: Capacidad de administración remota a través de los módulos de protocolo
y administración de dominio-http Dominios de varios servidores gestionados a través de los módulos de
controlador host-proceso-controlador. Elementos diversos prestados a través del administración cliente-
contenido y módulos propios de la plataforma. Un marco de implementación para coordinar la instalación de contenido de
implementación en el tiempo de ejecución.
Extensiones La mayor parte de la funcionalidad que los usuarios finales asocian con un servidor de aplicaciones es lo que se denomina extensiones. Los módulos en el código fuente del servidor de aplicaciones son implementaciones de esas extensiones, con cada extensión se proporciona un conjunto coherente de funcionalidades muchas de ellas compatibles con varios aspectos de las especificaciones técnicas de Java EE.
28
Al implementar estas extensiones a la interfaz se le permite la integración con el núcleo del servidor de aplicaciones en su capa de administración. A través de ese mecanismo las extensiones tienen la capacidad de: o Participar en el análisis y cálculo de referencias de los documentos de
configuración del servidor de aplicaciones. o Registrar los recursos y las operaciones que se exponen a través de la API
de gestión del servidor de aplicaciones. o Instalar los servicios en un contenedor de servicio del servidor de
aplicaciones o Registrarse procesadores unidad de despliegue con el marco de la
implementación del servidor de aplicaciones. 3.2.3 Enterprise JavaBeans (EJB). Los EJB proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables. (Enterprise JavaBeans, 2014) No hay que confundir los Enterprise JavaBeans con los JavaBeans. Los JavaBeans también son un modelo de componentes creado por Oracle - Sun Microsystems para la construcción de aplicaciones, pero no pueden utilizarse en entornos de objetos distribuidos al no soportar nativamente la invocación remota (RMI). 3.2.3.1 EJB de Entidad (EntityEJBs). Su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJB de entidad presentan la característica fundamental de la persistencia: (Enterprise JavaBeans, 2014) Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de
almacenar y recuperar los datos del objeto de entidad mediante el mapeo o vinculación de las columnas de una tabla de la base de datos con los atributos del objeto.
Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual la responsabilidad de implementar los mecanismos de persistencia es del programador.
3.2.3.2 EJB de Sesión (SessionEJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos: (Enterprise JavaBeans, 2014) Con estado (stateful). En un bean de sesión con estado, las variables de
instancia del bean almacenan datos específicos obtenidos durante la conexión con el cliente. Cada bean de sesión con estado, por tanto, almacena el estado
29
conversacional de un cliente que interactúa con el bean. Este estado conversacional se modifica conforme el cliente va realizando llamadas a los métodos de negocio del bean. El estado conversacional no se guarda cuando el cliente termina la sesión.
Sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método.
3.2.3.3 EJB dirigidos por mensajes (Message-drivenEJBs). Son los únicos beans con funcionamiento asíncrono. Usando el Java MessagingSystem (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente. (Enterprise JavaBeans, 2014) 3.2.3.4 Funcionamiento de un Enterprise JavaBean. Los EJB se disponen en un contenedor EJB dentro del servidor de aplicaciones. La especificación describe cómo el EJB interactúa con su contenedor y cómo el código cliente interactúa con la combinación del EJB y el contenedor, cada EJB debe facilitar una clase de implementación Java y dos interfaces Java. (Enterprise JavaBeans, 2014) El contenedor EJB creará instancias de la clase de implementación Java para facilitar la implementación EJB. Las interfaces Java son utilizadas por el código cliente del EJB. Las dos interfaces conocidas como interfaz "home" e interfaz remota, especifican las firmas de los métodos remotos del EJB. Los métodos remotos se dividen en dos grupos: Métodos que no están ligados a una instancia específica, por ejemplo aquellos
utilizados para crear una instancia EJB o para encontrar una entidad EJB existente. Estos métodos se declaran en la interfaz "home".
Métodos ligados a una instancia específica. Se ubican en la interfaz remota. Dado que se trata simplemente de interfaces Java y no de clases concretas, el contenedor EJB genera clases para esas interfaces que actuarán como un proxy en el cliente. El cliente invoca un método en los proxies generados que a su vez sitúa los argumentos método en un mensaje y envía dicho mensaje al servidor EJB. Los proxies usan RMI-IIOP para comunicarse con el servidor EJB. El servidor llamará a un método correspondiente a una instancia de la clase de implementación Java para manejar la llamada del método remoto. 3.2.4 Hibernate. Hibernate facilita la creación de clases de persistencia utilizando el lenguaje Java incluyendo la asociación, herencia, polimorfismo y composición y el entorno de colecciones Java. (Hibernate, 2014)
30
Figura 6. Componentes Hibernate
Fuente: (Hibernate, 2014)
Hibernate es un servicio de persistencia objeto/relacional y consultas para Java, entre las principales características tenemos: 3.2.4.1 Mapeo. El mapeo en Hibernate gestiona asociaciones donde un objeto tiene una relación de uno a varios con otras instancias de su propio tipo, esto facilita un esquema las clases cuando existen varias relaciones de este tipo. (Hibernate, 2014) La asignación de clases Java a tablas de bases de datos se lleva a cabo a través de la configuración de un archivo XML o mediante notación Java. Cuando se utiliza un archivo XML Hibernate genera el código fuente para las clases de persistencia. Hibernate soporta el mapeo de tipos de valor personalizado. Esto hace que los siguientes escenarios posibles:
Asignación de una propiedad a múltiples columnas.
Los objetos en una aplicación front-end siguen los principios de POO, mientras que los objetos en el back-end siguen los principios de normalización de bases de datos, dando lugar a diferentes requisitos de representación. Este problema se llama "impedancia desajuste objeto-relacional". El mapeo es una forma de resolver el problema de falta de concordancia.
3.2.4.2 HibernateQueryLanguage. Hibernate ofrece un lenguaje SQL nativo denominado Hibernate Query Language (HQL) que permite consultas tipo SQL que se escriben contra los objetos de datos de Hibernate. (Hibernate, 2014) 3.2.4.3 Persistencia. Hibernate proporciona persistencia transparente para los POJOs (Plain Old Java Objects) el único requisito para una clase persistente es un
31
constructor sin argumentos, el comportamiento apropiado en algunas aplicaciones también requiere una atención especial a los métodos equals () y hashCode () (Hibernate, 2014). Las colecciones de objetos de datos normalmente se almacenan en objetos de la colección de Java tales como Sets y Listas propios de Java. 3.2.4.4 Integración. Hibernate puede ser utilizado tanto en aplicaciones Java autónomas y en las aplicaciones Java EE utilizando servlets, EJB de sesión y componentes de servicio, también se puede incluir como una característica en otros lenguajes de programación. 3.2.4.5 Entidades y componentes. En el contexto de Hibernate una entidad es un objeto independiente del mecanismo de persistencia que puede ser manipulado de forma independiente de otros objetos. En contraste un componente está subordinada a una entidad y puede ser manipulado sólo con respecto a esa entidad. (Hibernate, 2014) 3.2.5 JSF (JavaServer Faces). Es una tecnología y marco para aplicaciones Web Java que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. JSF usa Java Server Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías, la especificación de JSF incluye: (Oracle, 2014)
Un conjunto de APIs para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entrada, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.
Un conjunto por defecto de componentes para la interfaz de usuario.
Dos bibliotecas de etiquetas personalizadas para Java Server Pages que permiten expresar una interfaz Java Server Faces dentro de una página JSP.
Un modelo de eventos en el lado del servidor.
Administración de estados.
Beans administrados.
Lo que constituye el pilar fundamental en el desarrollo de los siguientes objetivos de diseño:
Definir un conjunto simple de clases base de Java para componentes de la interfaz de usuario, estado de los componentes y eventos de entrada. Estas clases tratarán los aspectos del ciclo de vida de la interfaz de usuario, controlando el estado de un componente durante el ciclo de vida de su página.
Proporcionar un conjunto de componentes para la interfaz de usuario, incluyendo los elementos estándares de HTML para representar un formulario. Estos componentes se obtendrán de un conjunto básico de clases base que se pueden utilizar para definir componentes nuevos.
32
Proporcionar un modelo de JavaBeans para enviar eventos desde los controles de la interfaz de usuario del lado del cliente a la aplicación del servidor.
Definir APIs para la validación de entrada, incluyendo soporte para la validación en el lado del cliente.
Especificar un modelo para la internacionalización y localización de la interfaz de usuario.
Automatizar la generación de salidas apropiadas para el objetivo del cliente, teniendo en cuenta todos los datos de configuración disponibles del cliente, como versión del navegador.
3.2.5.1 PrimeFaces Es un marco de interfaz de usuario basado en JavaServer Faces que facilita el desarrollo de aplicaciones robustas para la empresa o para los sitios web estándar, las aplicaciones JSF tradicionales son fáciles de crear y configurar sin embargo una de las ventajas de Prime Faces sobre en una aplicación JSF es que solo se tienen que agregar la biblioteca Prime Faces a una aplicación. Hay algunas configuraciones opcionales de menor importancia para la utilización de características de Prim eFaces tales como la carga de archivos y plantillas personalizadas. (Oracle EJB , 2014) 3.2.6 Android. Android es un sistema operativo basado en Linux, diseñado principalmente para dispositivos ligeros como teléfonos inteligentes y tablets. La mayoría de aplicaciones de Android están escritas en JAVA, aunque el sistema operativo no consta de una máquina virtual, por lo que para ejecutar el código JAVA este se compila en un ejecutable DALVIK y corre en la máquina virtual Dalvik la cual es especializada y diseñada específicamente para Android. (Android, 2013) Android para el desarrollo de sus aplicaciones provee un conjunto de herramientas denominada SDK, el cual facilita las librerías necesarias para la construcción de las aplicaciones para el sistema operativo, permite compilar el código en un paquete Androidapk, listas para ser instaladas en los dispositivos. Las características de operación de las aplicaciones en el sistema Android son las siguientes:
Android es un sistema Linux multi-usuario en la que cada aplicación es un usuario diferente.
Por defecto el sistema asigna a cada aplicación un ID único (es conocido solo por el sistema operativo y desconocido e inalcanzable para la aplicación). El sistema operativa asigna permisos a los archivos de acuerdo a cada ID de la aplicación.
Cada aplicación crea su propio proceso en el dispositivo, por lo que cada aplicación se ejecuta en forma aislada de las otras aplicaciones.
Por defecto cada aplicación se ejecuta sobre su propio proceso Linux, Android inicia el proceso cuando alguno de los componentes de la aplicación necesita
33
ser ejecutado, por lo que el proceso de una aplicación en desuso será eliminado para permitir que la memoria sea usada por otras aplicaciones.
3.2.6.1 Arquitectura del sistema operativo de Android. Los componentes del sistema Android se describen en detalle a continuación: (Android, 2013)
Aplicaciones: las aplicaciones base incluyen un cliente de correo electrónico, programa de SMS, calendario, mapas, navegador, contactos y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.
Marco de trabajo de aplicaciones: los desarrolladores tienen acceso completo a los mismos APIs del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar la reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario.
Bibliotecas: Android incluye un conjunto de bibliotecas de C/C++ usadas por varios componentes del sistema. Estas características se exponen a los desarrolladores a través del marco de trabajo de aplicaciones de Android; algunas son: System C library (implementación biblioteca C estándar), bibliotecas de medios, bibliotecas de gráficos, 3D y SQLite, entre otras.
Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato DalvikExecutable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros y corre clases compiladas por el compilador de Java que han sido transformadas al formato .dex por la herramienta incluida "dx".
Núcleo Linux: Android depende de Linux para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto de la pila de software.
3.2.6.2 Componentes Android.
Intent. Un Intent es un objeto de mensajería que puede utilizar para solicitar una acción de otro componente de aplicación. Aunque las intenciones de facilitar la comunicación entre los componentes de varias maneras, hay tres casos de uso fundamentales: (Android, 2013) o Para iniciar una actividad. o Recibir un resultado de la actividad cuando termine. o Para iniciar un servicio. o Para entregar una emisión.
34
Tipos de Intent. Hay dos tipos de intent: o Intentos explícitos: especifican el componente para empezar por su nombre
(el nombre de clase completo). Lo general, usarás una intención explícita para iniciar un componente de su propia aplicación, porque usted sabe el nombre de la clase de la actividad o servicio que desea iniciar. Por ejemplo, iniciar una nueva actividad en respuesta a una acción del usuario o iniciar un servicio para descargar un archivo en segundo plano.
o Intenciones implícitas: no nombran un componente específico, sino que declaran una acción general para llevar a cabo, lo que permite que un componente de otra aplicación para manejar la situación. Por ejemplo, si desea mostrar al usuario una ubicación en un mapa, puede utilizar una intención implícita de solicitar que otra aplicación capaz muestran una ubicación especificada en un mapa.
Serviceso Servicios Un Service o Servicio es un componente de aplicación que puede realizar operaciones de larga ejecución en segundo plano y no proporciona una interfaz de usuario. Otro componente de la aplicación se puede iniciar un servicio y continuará funcionando en segundo plano, incluso si el usuario cambia a otra aplicación. Además, un componente puede unirse a un servicio para interactuar con él e incluso realizar la comunicación entre procesos (IPC). Por ejemplo, un servicio puede manejar las transacciones de red, reproducir música, ejecutar archivos de entrada y salida, o interactuar con un proveedor de contenidos, todo desde el fondo. (Android, 2013) Un servicio esencialmente puede tomar dos formas: o Iniciado: Un servicio es "Iniciado" cuando un componente de la aplicación
(por ejemplo, una actividad) comienza llamando startService(). Una vez iniciado, un servicio puede ejecutarse en segundo plano de forma indefinida, incluso si el componente que se inició, se destruye. Por lo general, un servicio iniciado realiza una sola operación y no devuelve un resultado a la persona que llama. Por ejemplo, puede descargar o cargar un archivo a través de la red. Cuando se realiza la operación, el servicio debería pararse.
o Bound Un servicio es Bound u "obligada" cuando un componente de aplicación se une a ella llamando bindService(). Un servicio cota ofrece una interfaz de cliente-servidor que permite a los componentes para interactuar con el servicio, envían solicitudes, obtener resultados, e incluso lo hacen a través de los procesos con la comunicación entre procesos (IPC). Un servicio unido sólo se ejecuta siempre como otro componente de la aplicación está vinculada a la misma. Varios componentes pueden unirse al servicio de una sola vez, pero cuando todos ellos unbind, se destruye el servicio.
En la siguiente figura se muestra un comparativo entre los dos tipos de servicios.
35
Figura 7. Comparativo de los tipos de servicios
Fuente: (Android, 2013)
Independientemente de si se inicia su aplicación con destino, o ambos, cualquier componente de aplicación puede utilizar el servicio (incluso desde una aplicación independiente), de la misma manera que cualquier componente puede utilizar una actividad-comenzando con un Intent. Sin embargo, se puede declarar el servicio como privado, en el archivo de manifiesto, y bloquear el acceso desde otras aplicaciones. Esto se discute más en la sección sobre Declarando el servicio en el manifiesto.
Actividades o Activity. Una Activity es un componente de aplicación que proporciona una pantalla con la que los usuarios pueden interactuar con el fin de hacer algo, como marcar el teléfono, tomar una foto, enviar un correo electrónico, o ver un mapa. Cada actividad se da una ventana en la que dibujar su interfaz de usuario. La ventana normalmente llena la pantalla, pero puede ser más pequeña que la pantalla y flotar en la parte superior de otras ventanas. (Android, 2013) Una aplicación por lo general consiste de múltiples actividades que están más o menos ligados entre sí. Por lo general, una actividad en una aplicación se especifica como la actividad "principal", que se presenta al usuario al iniciar la aplicación por primera vez. Cada actividad puede entonces comenzar otra actividad con el fin de realizar diferentes acciones. Cada vez que se inicia una nueva actividad, la actividad anterior se detiene, pero el sistema conserva la
36
actividad en una pila (la "pila back"). Cuando se inicia una nueva actividad, que se inserta en la pila hacia atrás y lleva la atención al usuario. La pila de vuelta permanece al "último en entrar, primero en salir" mecanismo de pila básica, por lo que, cuando el usuario se realiza con la actividad actual y presiona el botón Atrás, que se extrae de la pila (y destruido) y la actividad anterior se reanuda. (La pila de vuelta se discute más en las tareas y Volver pila de documentos) como se muestra en la siguiente figura.
Figura 8. Ciclo de vida de una Actividad
Fuente: (Android, 2013)
Cuando se detiene una actividad, ya una nueva actividad se inicia, es notificado de este cambio en el estado a través de métodos de devolución de llamada de ciclo de vida de la actividad. Hay varios métodos de devolución de llamada que una actividad pueda recibir, debido a un cambio en su estado-si el sistema está creando él, detenerlo, reanudarla o destruirlo-y cada devolución de llamada que ofrece la oportunidad de realizar un trabajo específico que es apropiado que cambio de estado. Por ejemplo, cuando se detuvo, su actividad debe liberar
37
cualquier objeto grande, como las conexiones de red o base de datos. Cuando la actividad se reanuda, se puede volver a adquirir los recursos necesarios y reanudar las acciones que fueron interrumpidos. Estas transiciones de estado son parte del ciclo de vida de la actividad.
3.2.7 Servidor Información Geográfica – ArcGIS. Es un servidor de pago utilizado para crear y administrar GIS Web Services, aplicaciones e información. ArcGIS Server utiliza generalmente una arquitectura orientada a servicios SOA para la exposición de la información impulsando la filosofía computacional de la nube (cloudcomputing) y a través de los servicios WEB ArcGIS Server publica mapas y funcionalidades GIS. (ARGIS, 2014) ArcGIS aunque es un servicio pago también provee un conjunto de funcionalidades gratuitas entre las que se destacan servicios de geometría, mapas detallados y lo más importante un conjunto de API para diferentes plataformas entre ellas Android con un conjunto de librerías que permite una integración total y confiable en las aplicaciones de esa plataforma, aún con su relativo poco tiempo en producción la API logra madurar un conjunto de objetos que combinado con su arquitectura SOA, las diferentes funcionalidades desarrolladas, y la portabilidad da lugar a un sistema solido de soluciones geográficas que permiten potenciar diferentes aplicaciones. (ESRI, 2013) ArcGIS Provee la API Web Mapping para soportar la integración con varios idiomas lo que le permite a los usuarios construir y desplegar aplicaciones que incluyen servicios de funcionalidad GIS y servicios Web de ArcGIS Online y ArcGIS Server, Adobe Flex, JavaScript y Microsoft Silverlight. 3.2.7.1 Componentes GIS: Mapas y capas Un mapa es un espacio que dibuja capas de datos geográficos por lo que se tiene que diferentes tipos de capas se utilizan para dibujar diferentes tipos de datos. Por ejemplo, es posible que los datos que se proporciona por un servicio o de archivos locales; los datos podrían ser de naturaleza estática, o cambiar con el tiempo. Para Android específicamente se tienen el componente Map View el cual permite dibujar un mapa en una aplicación y actúa como un contenedor de uno o más objetos de capa. (ARGIS, 2014) 3.2.7.2 Tipos de capas. Las capas generalmente se pueden considerar como mapas base o capas de gráficos operacionales, dependiendo de los datos que se muestran y cómo se utilizan, con cada tipo de capa ofrece diferentes características de funcionalidad y rendimiento. (ARGIS, 2014)
Información Inicial de base o de fondo: ofrece el contexto y no cambia, a menudo se considera generalmente como el mapa base, por ejemplo, la topografía, datos de imágenes, calles o edificios. El mapa base de datos generalmente se prepara y se almacena en caché en el servidor como imágenes listas para su acceso lo que maximiza la eficiencia en el momento de
38
cualquier solicitud y despliegue en una aplicación. ArcGIS Online ofrece un conjunto gratuito de capas de mapas base listas para su uso, alternativamente puede utilizar la plataforma ArcGIS para crear tus propios mapas base.
Datos editados por los usuarios, estos datos son lo que cambian periódicamente o son datos resultantes de los análisis, una mejor interpretación de estos datos es que son capas que resultan de la operación de la aplicación y son a menudo el objetivo principal resultado de las funciones de la aplicación.
Datos ligeros son los datos que generan los gráficos en la memoria en una aplicación o creados por una fuente de información externa, ejemplo: ubicaciones de vehículos, de mano de obra o resultados de consultas temporales.
Una amplia variedad de clases de capa son proporcionadas por la API y cada uno puede ser utilizado para mostrar un tipo de datos específico con sus propias características de funcionalidad y rendimiento. Generalmente, cada clase se utiliza para la capa de mapa base, capas operacionales, o gráficos, sin embargo, estas no son reglas absolutas y la elección de la clase deben basarse en una comprensión de las características de cada tipo. 3.2.7.3 Orden de las capas. El orden de las capas en un mapa es importante. Los mapas base típicamente cubren toda la superficie del mapa. Se añaden al mapa primero de manera que dibujan debajo de la capa y no lo hacen otras capas oscuras. Las capas pueden ser reordenadas, pero esto no va a cambiar de referencia espacial del mapa. (ARGIS, 2014) 3.2.8 SOAP. Básicamente SOAP es un paradigma de mensajería de una dirección sin estado, que puede ser utilizado para formar protocolos más complejos y completos según las necesidades de las aplicaciones que lo implementan. Puede formar y construir la capa base de una "pila de protocolos de web service", ofreciendo un framework de mensajería básica en el cual los web services se pueden construir. (SOAP, 2014) Este protocolo está basado en XML y se conforma de tres partes:
Sobre (envelope): el cual define qué hay en el mensaje y cómo procesarlo
Conjunto de reglas de codificación para expresar instancias de tipos de datos
La Convención para representar llamadas a procedimientos y respuestas. El protocolo SOAP tiene tres características principales:
Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).
Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP, SMTP, TCP o JMS).
Independencia (SOAP permite cualquier modelo de programación).
39
La arquitectura SOAP está formada por varias capas de especificación: MEP (Message Exchange Patterns) para el formato del mensaje, enlaces subyacentes del protocolo de transporte, el modelo de procesamiento de mensajes, y la capa de extensibilidad del protocolo. SOAP es el sucesor de XML-RPC, a pesar de que toma el transporte y la neutralidad de la interacción, así como el envelope / header / body, de otros modelos (probablemente de WDDX). Al uso de XML para el intercambio de información se agrega la utilización del formato JSON el cual es un formato ligero para el intercambio de datos, se utiliza para el paso de imágenes a través de los servicios Web.
3.2.9 JSON (JavaScript ObjectNotation). Es un formato de intercambio de datos ligero, se basa en un subconjunto del lenguaje de programación JavaScript, estándar sin embargo JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son familiares para los programadores de la familia de lenguajes C , C ++, C #, Java, JavaScript, Perl, Python entre otros. Estas características hacen a JSON un lenguaje ideal en el propósito de intercambio de datos. (JSON, 2014)
JSON se basa en dos estructuras:
Una colección de pares nombre / valor. En varios idiomas, esto se realiza como un objeto, registro, estructura, diccionario, tabla hash, lista con clave, o matriz asociativa.
Una lista ordenada de valores. En la mayoría de los idiomas, esto se realiza como una matriz, vector, lista o secuencia.
En general todos los lenguajes de programación modernos soportan de una forma u otra estas estructuras de datos universales. 3.2.10 Integración de sistemas. Para poder obtener un sistema en el que logren interactuar todas las plataformas mencionadas es necesario definir un canal de comunicación por el cual fluyan los procesos y mensajes necesarios para construir un sistema robusto, de alta usabilidad y portabilidad en los diferentes problemas que buscan abarcar las aplicaciones en los dispositivos móviles y de entorno empresarial. Esta comunicación se logra utilizando SOA (Arquitectura orientada a Servicios), para poder exponer los métodos de negocio necesarios (Entorno empresarial), así como los servicios web geográficos (ArcGIS Server), estos servicios que posteriormente van a ser consumidos en una aplicación Android a través de archivos XML. Es así como la información de negocio consultada desde el servidor empresarial es mostrada a través de mapas los cuales son creados desde el consumo de web services del servidor ArcGIS, dando mayor funcionalidad y usabilidad a la información de una aplicación independiente empresarial. La figura a conitnuacion
40
A continuación representa los componentes a un nivel general que constituyen el sistema.
Figura 9. Componentes Generales del sistema
Fuente los autores
41
CAPÍTULO 4. MARCO METODOLOGICO
4.1 METODOLOGÍA
Entendiendo la metodología como el conjunto de procedimientos racionales utilizados para alcanzar los objetivos en este proyecto se realiza un estudio descriptivo de características cualitativas aplicando una combinación entre el método sistémico y el método lógico inductivo, se establece como estrategia fundamental y general la ejecución de actividades versátiles que brinden resultados en corto plazo tanto para la planificación y administración del proyecto como para el desarrollo de artefactos de SW, entendiendo que el factor de éxito principal se centra en establecer objetivos realistas dentro de las limitaciones tecnológicas, de recursos y ambientales que se consideren de impacto con el compromiso de dar cumplimento en un tiempo estimado.
4.2 DISEÑO DE LA PROPUESTA DE INVESTIGACION
4.2.1 Recopilar documentación. Siendo un estudio descriptivo y cualitativo el primer paso consiste en recopilar una cantidad suficiente de documentación de los diversos fabricantes de los componentes más significativos que intervienen en la posible solución, prestando especial cuidado a que se encuentren vigentes en el mercado y que esta literatura corresponda a la oficial y actual proporcionada por el mismo con la intención de construir una base conceptual sólida y valida a todo el soporte documental que caracterizará la solución final. Sin embargo como la documentación para cada producto es diferente se debe enfatizar en que la literatura conciba conceptos clave como arquitectura, patrones, tecnologías, implementaciones, protocolos y plataformas para así realizar el análisis respectivo de estas características. 4.2.2 Sintetizar y Caracterizar. Una vez finalizada la fase de recolección de documentación se debe agrupar y consolidar el material donde se destaque los atributos más relevantes de diseño con sus clasificaciones, donde claramente se identifiquen y diferencien las principales ventajas y debilidades del uso de cada tecnología. Estas diferentes alternativas de soluciones brindan el marco donde se encuentra la arquitectura objetivo, la síntesis de las mismas es un cuadro comparativo de las agrupaciones que se asemejen y una ponderación entre las mismas. 4.2.3 Análisis. En el proceso de análisis los factores como arquitectura, patrones, tecnologías, implementaciones y plataformas deben examinarse bajo el enfoque donde la interacción de la mayoría de ellas conlleve a un caso de éxito,
42
realizando una comparación de los principales atributos y características de las mismas y con énfasis en que estas permitan la reutilización de la lógica de negocio que se implemente sea reutilizable en un ambiente ligero. Por otro lado también se contempla que de este análisis se obtengan hallazgos del comportamiento de la integración de los componentes donde se evidencia que las diferentes alternativas de solución que aplican en el problema implican diferentes cantidades de esfuerzo en el desarrollo, es decir se debe indagar que el conjunto de componentes seleccionados permitan satisfacer de manera sencilla y efectiva las necesidades de los requerimientos funcionales y no funcionales planteados para limitar el alcance de la solución, estos hallazgos se deben evaluar de frente a los requerimientos funcionales y no funcionales del aplicativo considerando las consecuencias que implica o no su aplicación y adicionalmente de frente a aspectos generales y transversales que no son propios de la arquitectura pero que si pueden dar valor agregado en el propósito de garantizar la escalabilidad de la solución. 4.2.4 Selección. El resultado de este análisis culmina en la elección de las plataformas y componentes que interactúan en la arquitectura, para esto se selecciona un conjunto de componentes, patrones, relaciones, comunicaciones y servicios que constituyen la arquitectura objetivo, como criterio de evaluación se consideran aspectos como el usuario, los recursos disponibles y principalmente las necesidades de negocio que se requieren satisfacer, el conjunto de componentes que se identifique como el que menos impacte y que provea mayor verticalidad para garantizar una solución transversal y no especifica será el que se elija.
Con estas necesidades satisfechas también se analizan características más específicas como la reutilización de la lógica de negocio con un conjunto de variables como los recursos del dispositivo móvil.
Validación y Pruebas. Con el conjunto de componentes elegidos que soportan la arquitectura se empiezan a realizar abstracciones de la implementación evaluando que partes de la tecnología específicamente se van a utilizar y los procesos de comunicación entre las partes; Después se realizan pruebas de concepto donde una a una y después por pares se comprueba que se ajusta a los requerimientos verificando principalmente la interoperación entre las tecnologías.
4.2.5 Integración. Por último se realiza una integración de los componentes, protocolos, tecnologías y herramientas seleccionados en una implementación piloto llamada CARONTE evaluando el comportamiento de las mismas.
43
4.3 PROCESO DE DESARROLLO DEL PROYECTO
La fase de elaboración el proyecto se apoya en la aplicación del modelo de referencia propuesto en OpenUP para la gestión del proyecto y el desarrollo de piezas de Software ya que este método es el que más se ajusta al propósito del análisis y diseño arquitectural de la solución, la estrategia es producir estimaciones aproximadas del tamaño de cada iteración y pruebas al final de cada fase para verificar que el hito se ha cumplido, de lo contrario se debe proponer la entrada de un control de cambios documentando un nuevo alcance de los entregables y su respectivo impacto en recursos y cronograma, la documentación del proyecto así como los demás artefactos de cada iteración también serán sometidos a revisión garantizando que se cumpla con los objetivos y estándares de calidad planteados en el proyecto.
4.3.1 OpenUP. El Proceso Unificado Abierto o OpenUP por sus siglas en ingles es un método incremental iterativo bajo un marco de código abierto para el desarrollo de software que se puede describir como mínimo y suficiente (OpenUP, 2014), esto significa que solo el contenido fundamental y necesario es incluido por lo tanto no provee lineamientos para todos los elementos que se manejan dentro de un proyecto sino los componentes básicos que pueden servir de soporte a procesos específicos, esto a diferencia de otros modelos más robustos y amplios como Rational Unified Process (RUP) OpenUP ofrece un método ágil para la gestión del ciclo de vida de una implementación en la pretensión del éxito. La mayoría de los elementos de OpenUP fomentan el intercambio de información entre los equipos de desarrollo y mantienen un entendimiento compartido del proyecto, objetivos, alcance y avances.
Entre algunas de las características de OpenUP se incluye el desarrollo iterativo, documentos de casos de uso y escenarios de desarrollo, gestión de riesgos y el enfoque centrado en la arquitectura, como resultado se obtiene un proceso mucho más simple sin embargo conserva aún algunos lineamientos con los principios RUP.
4.3.1.1 Elementos Básicos en OpenUP. Los elementos básicos de un proceso OpenUP son:
Workproduct: lo que se produce.
Task: cómo realizar el trabajo.
Role: quien realiza el trabajo.
Process: se utiliza para definir el flujo de trabajo o la interrupción del mismo. 4.3.1.2 Desarrollo Iterativo. El objetivo de las iteraciones es la entrega de valor al cliente de forma incremental en un lapso muy corto (días o semanas) representado por la entrega de funcionalidades completamente probadas o un componente empaquetable que pertenece al incremento de un producto. Esto crea
44
un enfoque saludable para asegurar que el esfuerzo realizado en el desarrollo sea de valor para las partes involucradas. En este enfoque la toma de decisiones sucede de forma más rápida que en un proceso formal debido a que no hay ni el tiempo ni la intensión para el debate extenso reduciendo el riesgo de caer en el inconveniente del análisis-parálisis con mecanismos de retroalimentación que permiten corregir el rumbo del desarrollo en cada momento que sea necesario. (OpenUP, 2014) En el ciclo de vida de cada iteración se consideran 4 fases fundamentales:
Iniciación (Concepción y/o análisis). En esta fase se debe: o Entender qué construir, determinando una visión global que incluyendo el
alcance del sistema y de sus límites. o Identificar los grupos de interés respondiendo a las preguntas ¿Quién está
interesado en este sistema y cuáles son sus criterios de éxito? o Identificar la funcionalidad clave del sistema. decidiendo qué requerimientos
son los más críticos. o Determinar al menos una posible solución evaluando si la visión es
técnicamente factible, esto puede implicar la identificación de una arquitectura de alto nivel candidata, elaboración de prototipos técnicos o ambos.
o Elaborar una estimación de alto nivel para los costos, cronograma y los riesgos asociados con el proyecto.
Elaboración. El objetivo de esta fase contempla: o Obtener una comprensión más detallada de los requisitos con el propósito
de crear un plan más detallado y realista para conseguir la aceptación de los interesados.
o Diseñar, implementar, validar y establecer la línea de base para la arquitectura. Diseñar, implementar y probar una estructura del esqueleto del sistema. Aunque la funcionalidad aún no está completo, la mayoría de las interfaces entre los bloques de construcción están implementados y probados. Esto se conoce como una arquitectura ejecutable.
o Mitigar los riesgos esenciales, y producir programación y costos estimados precisos. Muchos riesgos técnicos se tratan como resultado de detallar los requisitos y de diseñar, implementar y probar la arquitectura.
Construcción. Esta fase debe considerar: o Desarrollar un producto completo de forma Iterativa y que esté listo para la
transición al grupo de usuarios. describiendo los requisitos restantes, completar los detalles de diseño, completar la aplicación y probar el software. Suelte la primera versión operativa (beta) del sistema y determinar si los usuarios están listos para que la aplicación se desplegará.
o Minimizar los costes de desarrollo y lograr un cierto grado de paralelismo. Optimizar los recursos y el desarrollo de apalancamiento paralelismo entre los desarrolladores o equipos de desarrolladores, por ejemplo, la asignación
45
de los componentes que se pueden desarrollar de forma independiente el uno del otro.
Transición. En esta fase se debe realizar: o Pruebas para validar el cumplimiento de las expectativas del usuario, por lo
general requiere realizar algunas actividades de ajuste como corrección de errores y mejoras de rendimiento y usabilidad.
o Lograr la concurrencia de las partes interesadas para que el despliegue se ha completado, esto puede implica varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales.
o Documentar y retroalimentar las lecciones aprendidas en términos del rendimiento del proyecto para futuras implementaciones contemplando lecciones aprendidas, mejoramiento del entorno o una solución para la gestión y seguimiento del proyecto.
Figura 10. Ciclo de vida de una iteración
Fuente (OpenUP, 2014)
4.3.1.3 Componentes y relaciones. OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método y el proceso. El contenido del método es donde los elementos del método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo de vida del proyecto. El proceso es donde los elementos del método son aplicados de forma ordenada en el tiempo por el equipo de trabajo el cual es conformado por pocos miembros que trabajan bajo la figura de la autogestión, esto significa que toman sus propias decisiones acerca de lo que necesitan para trabajar, cuáles son las prioridades y la mejor forma de atender las necesidades de las partes interesadas. El compromiso de la parte administrativa es apoyar al equipo.
OpenUP se centra en reducir significativamente el riesgo desde fases tempranas del ciclo de vida del proyecto lo que requiere múltiples reuniones de revisión de riesgos regulares y la aplicación rigurosa de estrategias de mitigación.
Los casos de uso se utilizan para obtener y describir los requisitos, por lo tanto una habilidad fundamental en los miembros del equipo tienen que ser el desarrollo
46
de casos de uso de forma eficiente involucrando a los interesados quienes en última instancia son responsables de revisar y certificar que los requisitos se hayan cumplido.
Los requerimientos funcionales arquitecturales más significativos y de valor deben ser identificados y detallados en la fase de elaboración de manera que una arquitectura robusta se debe crear como núcleo del sistema. El modelo iterativo incremental permite un ajuste o cambio en un requisito arquitectural significativo que incluso puede ser tratado en la fase del desarrollo.
Por ultimo las pruebas se realizan múltiples veces por iteración por recomendación del marco cada vez que el valor de la solución se incrementa con el desarrollo de un producto, estas pruebas se producen después que los desarrolladores han desarrollado la solución y la integran en la base de código. Estas pruebas ayudan a garantizar que se crea una versión estable y siempre disponible como avanza el desarrollo. En la siguiente figura se representa la interacción entre las relaciones en el ciclo de vida del proyecto y su comportamiento
Figura 11. Relaciones en el Ciclo de vida de un proyecto y comportamiento.
Fuente (OpenUP, 2014)
4.3.1.4 Artefactos OpenUP para la gestión del proyecto.
Debido a que uno de los objetivos principales del método es centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo OpenUP es el método de referencia ideal para el proyecto que se está abordando, en ese orden de ideas se seleccionaron los siguientes documentos para la gestión del proyecto:
Vision
Project Plan
47
Architecture Notebook
Risk List
Documentos de especificación de casos de uso
Documentos de especificación de casos de Prueba.
Estos documentos están basados en las plantillas que se encuentran en el sitio oficial de OpenUP. (HTTP://EPF.ECLIPSE.ORG/WIKIS/OPENUP/)
48
CAPÍTULO 5. MARCO TEMÁTICO
5.1 GESTIÓN DEL PROYECTO BAJO EL MODELO OPENUP
5.1.1 Visión
5.1.1.1 Introducción. La disponibilidad, validez e integridad de la información es una necesidad que las empresas a nivel mundial buscan satisfacer día a día, un ambiente donde las tecnologías de información y comunicación vienen en crecimiento y cobran cada vez más importancia gracias a la facilidad para acceder a internet y a los equipos que ofrecen distintas aplicaciones que en la actualidad se apoyan en la red de telefonía móvil celular y en diferentes tecnologías que permiten el acceso a la información en todo momento, esto plantea un escenario donde los dispositivos móviles son herramientas que se convierten en un actor muy importante en la medida que los mismos permiten consultar, actualizar y actualizar la información desde cualquier lugar y con mayor versatilidad.
Estos avances también se reflejan en los SIG (Sistemas de información geográfica) que han implementado cambios importantes en su desarrollo, esto se puede evidenciar en el hecho que hoy en día tenemos acceso a mapas de una excelente calidad y con un cubrimiento superior comparado con el que se contaba hace algunos años, por esto y contemplando el panorama de la oferta en el ambiente Java así como en el ambiente geográfico y considerando que la información geo-referenciada es una de las más útiles y mejor tasadas en estos momentos en los mercados, la realización de una aplicación que reúna todas estas características ofrece un nicho que tiene que ser profundizado para su estudio y explotación con el objetivo de ofrecer a todos sus usuarios el valor agregado de apoyarse en la capacidades de la tecnología móvil y particularmente enfocados en la utilización de una plataforma ligera de acceso y manipulación de los datos de las aplicaciones.
Según el reporte “Informe de la economía de la información del 2010: TIC, empresas y alivio de la pobreza” revelado en la conferencia de las naciones unidas sobre el comercio y desarrollo, UNCTAD; el énfasis de los celulares y sus aplicaciones debe ser mucho mayor porque la penetración de los teléfonos es mucho mayor que la de internet en conexiones banda ancha; en este orden de ideas una solución que permita tener acceso a información seleccionada desde el celular y que la misma sea compartida con otros usuarios en la nube y que dicha información se encuentre disponible de forma “casi” inmediata, marca la pauta para el nuevo camino dentro del desarrollo de soluciones informáticas a la medida.
49
5.1.1.2 Caracterización
Planteamiento del problema
Tabla 2. Planteamiento del problema
El problema de Escenarios empresariales robustos soportados en infraestructura centralizada y de alto costo tanto en adquisición como soporte.
Afecta a Organizaciones con intenciones de descentralizar la operación a lugares remotos.
El impacto del problema es
La operación centralizada imposibilita a la organización a interactuar directamente con el entorno aislándolo de las verdaderas necesidades de negocio de sus clientes y oportunidades de mejora que el medio ofrece, también genera reprocesos al interior de la organización al tener que tomar información en campo procedimentalmente e ingresarla posteriormente en el sistema.
Una solución efectiva seria
Acceso a funcionalidades de negocio desde cualquier lugar.
Interacción directa con las necesidades de negocio de los clientes.
Mejora en tiempos de respuesta al desplegar la operación a los lugares de mayor impacto.
Fuente los autores
Planteamiento y Caracterización del producto
Tabla 3. Caracterización del Producto
Para Organizaciones empresariales.
Quienes Desarrolladores que buscan acceder e interoperar con escenarios de negocios robustos desde aplicativos móviles y viceversa.
Caronte Es un prototipo arquitectural
Que Que permite la integración entre aplicativos móviles y funcionalidades de negocio alojadas en servidores de la organización aplicando buenas prácticas de desarrollo, patrones y recomendaciones delos fabricantes para el mantenimiento y permanencia de la implementación de manera correcta en el tiempo.
A diferencia De los aplicativos móviles comunes que tan solo
50
consumen información o aportan muy poco a escenarios de negocio, desarrollados con bajos estándares de calidad y sin un marco conceptual que le dé formalidad al producto.
Nuestro producto Integra diferentes escenarios desacoplando la mayoría de funcionalidades para ser consumidas desde cualquier entorno móvil.
Fuente los autores
Descripción de los Involucrados Principales y de interés
Compendio de Involucrados de interés
Tabla 4. Compendio de involucrados de interés
Nombre Descripción Responsabilidades
Organizaciones empresariales
Compañías que soportan su operación en plataformas tecnológicas y de información y con lógicas de negocio de complejidades medias y altas.
Delimitar las necesidades de negocio manteniéndolas lo más simple que se puedan
Suministrar acceso a la lógica que soporta la operación y a la infraestructura.
Usuarios Finales
Clientes que utilizaran los aplicativos desde diferentes entornos dispositivos móviles, equipos de escritorio en general.
Experiencias de uso y necesidades de negocio que pueden ser exploradas para extender utilidad de la aplicación de la arquitectura.
Desarrolladores e Ingenieros de Software
Profesionales del área de sistemas que se encuentren en proceso de implementación de soluciones donde se integren estos escenarios.
Análisis argumentativo de oportunidades de mejora desde el enfoque técnico .
Instituciones Académicas y de investigación
Docentes con el deseo de investigar los conceptos relacionados con el desarrollo, innovación y formalización de este tipo de tecnologías.
Base del marco teórico
Evolución del soporte conceptual.
Fabricantes de dispositivos
Multinacionales dedicadas a la
Procesos de verificación y Mejora continua sobre el
51
Nombre Descripción Responsabilidades
móviles fabricación y manufactura de los dispositivos móviles que soportan los procesos de negocio.
hardware que comercializan centralizado en las tecnologías que pueden soportar y que son de mayor utilidad para los usuarios.
Fuente los autores
Entorno de Usuario.
Recursos técnicos que se encuentren en los equipos de desarrollo de software y en general miembros involucrados en el desarrollo de procesos de ingeniería de software que tengan la intención de realizar aplicaciones en plataformas móviles que interactúen con escenarios empresariales robustos y que necesiten un compendio de buenas prácticas, soporte conceptual y documentación base para el marco de implementación de una aplicación de estas características. 5.1.1.3 Descripción del producto
Necesidades y características.
Tabla 5. Necesidades y características
Necesidad Prioridad (1-5)
Funcionalidad Lanzamiento Planeado para
Servidor de base de datos
3
Instalación de plataforma de BD.
Creación del modelo Relacional.
Creación y ejecución del Script SQL.
Adición de datos iniciales.
01/sept/2014
Servidor de aplicaciones e integración con la base de datos
5
Instalación de Plataformas y herramientas de apoyo.
Creación de proyecto y renunciación a fuentes.
Mapeo de las entidades desde BD.
Implementación de desarrollos de la capa negocio.
Integración del Servidor de Aplicación a la BD mediante configuración de acceso.
15/sept/2014
Servidor ArcGis 3 instalación y configuración 15/sept/2014
52
Necesidad Prioridad (1-5)
Funcionalidad Lanzamiento Planeado para
e integración con la base datos
del servidor ArcGis.
Creación Archivo de mapa apoyándose en las Tablas de B.D.
Instalación de herramientas de geoprocesamiento.
Publicación del Servicio de Mapa.
Cliente Web e integración con Aplication server y DB Server
4
Creación de Proyectos EJB EAR y WEB
Creación de archivos de configuración para JSF, RichFaces e Hibernate.
Creación de la capa de Controlador.
Creación de la capa de Vista.
Creación de la capa de modelo de negocio.
15/oct/2014
Cliente Android pruebas funcionales e integración con los demás sistemas
5
Creación y configuración del proyecto (Adición de fuentes JSON y SOAP).
Creación de la Interfaz Gráfica de usuario.
Creación de Objetos del contrato SOAP.
Implementación y desarrollos de las funcionalidades de la Aplicación.
Creación de la aplicación de mapas en el cliente Android.
Integración y consumo de Servicios y funcionalidades de los demás sistemas.
21/oct/2014
Fuente los autores
Otros requerimientos del producto El desarrollo del aplicativo debe garantizar unos estándares mínimos de calidad por lo que se debe mantener especial cuidado en el diseño y construcción intentando cubrir los siguientes aspectos:
53
Tabla 6. Otros Requerimientos
Requerimiento Prioridad (1-5)
Lanzamiento Planeado para
Disponibilidad: Reserva del Sistema para ser utilizado.
4 21/oct/2014
Confiabilidad: El sistema debe mantenerse operativo a lo largo del tiempo.
4 21/oct/2014
Desempeño: Dado el conjunto de recursos con los que se cuente el sistema tiene que responder con precisión en un lapso razonable de tiempo.
5 21/oct/2014
Seguridad: Se debe garantizar un conjunto mínimo de características que no permitan el uso del sistema por personal no designado o acceso a la información del mismo.
4 21/oct/2014
Fuente los autores
5.1.2 Project Plan
5.1.2.1 Introducción. El propósito del Project plan es definir los lineamientos de alto nivel en cuanto al alcance del proyecto CARONTE acordando elementos clave como Practicas, Objetivos, Estrategias de despliegue, Marco Inicial de Tiempo, criterios de calidad y de éxito con el propósito de que todos los involucrados en la ejecución y término estén comprometidos y sintonizados con este fin.
Se define como objetivo general de este proyecto la implementación de una aplicación que Integre entornos de soluciones geográficas que se desplieguen en dispositivos móviles con el apoyo de plataformas tecnológicas empresariales, haciendo énfasis en la adopción de buenas prácticas desde fases tempranas del diseño tanto para el planteamiento de la arquitectura como el desarrollo de los componentes de Software, esto con el fin de dar alcance a los criterios de calidad y asegurar el éxito de la solución.
Se establece como estrategia fundamental y general la ejecución de métodos y procesos versátiles que brinden resultados en corto plazo tanto para la planificación y administración del proyecto como para el desarrollo de artefactos de SW, entendiendo que el factor de éxito principal se centra en establecer objetivos realistas dentro de las limitaciones tecnológicas de recursos y ambientales que se consideren, con el compromiso de dar cumplimento en el tiempo estimado.
54
Considerando lo anterior nos apoyaremos en la aplicación del método OpenUP para la gestión del proyecto y para el desarrollo de piezas de Software produciendo estimaciones aproximadas del tamaño de cada elemento de trabajo y proponiendo pruebas al final de cada iteración para verificar que el hito se ha cumplido, de lo contrario se propondrá la entrada de un control de cambios documentando un nuevo alcance de los entregables y su respectivo impacto en el cronograma, la documentación del proyecto así como los demás artefactos de cada iteración también serán sometidos a revisión garantizando que se cumpla con los objetivos y la calidad propuesta en el proyecto.
5.1.2.2 Organización del proyecto e identificación de los principales interesados. Para la ejecución de este proyecto se cuenta este momento con dos recursos que respectivamente se dividirán en los siguientes roles con sus respectivas responsabilidades:
Recurso 1: Raul Andres Castro: Project Manager, Analist y Tester
Recurso 2: Sergio Camilo Torres: Architect, Developer y Tester También se identifica como uno de los principales Interesados en la evaluación de la aplicación y calidad de este Proyecto al Director Julio Barón Velandia, el cual desempeñará la función de Usuario Experto.
5.1.2.3 Prácticas de apoyo para el desarrollo del proyecto. Dada la naturaleza del proceso OpenUP para la gestión del ciclo de vida del proyecto se propone un trabajo fuerte en arquitectura desde la fase de concepción y diseño de la implementación, gran parte de la fortaleza en el desarrollo de esta aplicación consiste en la claridad que tienen los recursos involucrados en el desarrollo en cuanto a los artefactos que componen la solución y a una alineación clara con el panorama en cuanto a lo que el Roadmap de la arquitectura objetivo nos pueda brindar o limitar.
Respecto a la ejecución del proyecto se propone la estrategia de un desarrollo iterativo tal cual como lo plantea el método adoptado, siendo el resultado de cada iteración un producto con funcionalidad específicamente detallada en los hitos del proyecto, a su vez este producto se convierte en el insumo principal de entrada para la siguiente iteración, así sucesivamente subiendo la complejidad funcional y el alcance del producto final.
Para asegurar la calidad de la aplicación se atenderán las recomendaciones y buenas prácticas que se proponen aplicando patrones de diseño para la fase construcción de la implementación, divididas según las capas de desarrollo como se muestra a continuación:
Patrones de presentación: • InterceptingFilter
55
• ApplicationController • Composite View • Dispatcherview
Patrones de integración: • Data Access Object • DomainStore • Web ServiceBroker
Patrones de negocio: • BussinesDelegate • serviceLocator • Session Facade • Bussines Object • Composite Entity • Transfer Object
5.1.2.4 Hitos del proyecto y objetivos. Para el proyecto se definen como los artefactos entregables los hitos destacados en cada iteración, así como la documentación que apoya los desarrollos y la documentación del método OpenUP.
Tabla 7. Hitos y objetivos
Iteración Objetivo primario Estimación de tiempo / Hito
Inicio 1. Establecer la Visión del problema
2. Listar y Enumerar riesgos
3. Establecer costos 4. Realizar un pronóstico de
tiempos 5. Estimar los Hitos de cada
iteración 6. Plantear los objetivos
iníciales de acuerdo a los requerimientos funcionales
7. Establecer proceso para la gestión de riesgos
8. Listar y Enumerar las herramientas y la forma de la solución y evaluar la más viable .
9. Realizar diagrama de
2 Semanas Definición del ciclo de vida del proyecto CARONTE e identificación y mapeo de Objetivos.
56
Iteración Objetivo primario Estimación de tiempo / Hito
casos de uso
Elaboración 10. Realización del documento de Definición de procesos y subprocesos propios de la iteración
11. Elaboración de documento pormenorizando actividades (WBS)
12. Especificación de caso de uso
13. Diagrama de componentes.
14. Diagrama de despliegue. 15. Diagrama de integración
de componentes a nivel arquitectural (desarrollo de solución)
16. Elaborar documento de evaluación de riesgos
2 Semanas Especificación Arquitectural de la solución y relación funcional de los componentes.
Construcción 17. Implementación y puesta en marcha de
18. Servidor de bases de datos
19. Servidor de aplicaciones 20. Servidor de mapas 21. Cliente web 22. Cliente Android 23. Para la parte de pruebas
de esta fase se contempla probar la integración funcional de:
24. Servidor de Aplicaciones con el Servidor de Bases de Datos
25. Servidor de mapas con Servidor de Bases de Datos
26. Cliente web con el servidor de Aplicaciones y Servidor de Bases de
12 Semanas Puesta en marcha y ejecución de la Aplicación con capacidad operacional y funcional inicial.
57
Iteración Objetivo primario Estimación de tiempo / Hito
datos 27. Cliente Android con
todos los sistemas
Transición 28. Despliegue de la solución
29. Estabilización del producto
30. Pruebas Funcionales 31. Gestión de cambios
1 Semana Liberación del producto en ambiente productivo con capacidad operacional y funcional total.
Fuente los autores
5.1.2.5 Despliegue. El equipo considera que el despliegue y liberación de SW debe realizarse en pequeñas emisiones (ciclos de lanzamiento de una a dos semanas como máximo). La liberación de software en producción con esta frecuencia se establece como una estrategia en la que obtendremos retroalimentación temprana respecto al alcance y a la calidad global del producto. 5.1.3 Iteration Plan. El propósito del Iteration Plan tiene como objetivo definir el proceso a alto nivel en el cual los componentes del proyecto serán desarrollados así como también los diferentes entregables e hitos relacionados con sus respectiva asignación de recursos, esto definirá cada una de las iteraciones en sus diferentes fases del ciclo de vida del proyecto y la evolución que estos van presentando.
5.1.3.1 Hitos Estratégicos del Proyecto
Fase de inicio
Tabla 8. Hitos fase de inicio
Iteración Proceso Hito Fecha
propuesta
Inicio de la iteración
- 01/sept/2014
Iteración 1 Gestión del
Proyecto
Iniciación del Proyecto
Definición del ciclo de vida del proyecto Caronte e identificación y mapeo de Objetivos.
Iteración 1 Requisitos
Planeación y administración de recursos
Iteración 1 Acuerdo de
58
Iteración Proceso Hito Fecha
propuesta
Arquitectura enfoque técnico
Iteración 1 Implementación
Identificación y análisis de requerimientos
Fin de la iteración
- 15/sept/2014
Fuente los autores
Fase de elaboración
Tabla 9. Hitos fase de elaboración
Iteración Proceso Hito Fecha
propuesta
Inicio de la iteración
- 16/sept/2014
Iteración 2 Gestión del
Proyecto
Planeación y gestión de las Iteraciones Especificación
Arquitectural de la solución y relación funcional entre los componentes.
Iteración 2 Requisitos
Refinar alcance y requerimientos
Iteración 2 Arquitectura
Desarrollo de arquitectura
Iteración 2 Implementación
Desarrollo de la solución
Iteración 1 Pruebas
Diseño de pruebas
Fin de la iteración
- 01/oct/2014
Fuente los autores
Fase de construcción
Tabla 10. Hitos fase de construcción
Iteración Proceso Hito Fecha
propuesta
Inicio de la iteración
- 02/oct/2014
Iteración 3 Gestión del
Proyecto
Planeación y gestión de los artefactos y recursos involucrados
Puesta en marcha y ejecución de la Aplicación con capacidad operacional y
Iteración 3 Refinar
59
Iteración Proceso Hito Fecha
propuesta
Requisitos requerimientos funcional inicial. Iteración 3
Implementación Desarrollar la solución
Iteración 2 Pruebas
Pruebas de desarrollador.
Fin de la iteración
- 25/oct/2014
Fuente los autores
Fase de pruebas
Tabla 11. Hitos fase de pruebas
Iteración Proceso Hito Fecha
propuesta
Inicio de la iteración
- 26/oct/2014
Iteración 4 Implementación
Despliegue de la solución
Liberación del producto en ambiente productivo con capacidad operacional y funcional total
Iteración 4 Requisitos
Gestión de cambios
Iteración 4 Implementación
Estabilización del producto
Iteración 3 Pruebas
Pruebas usuario Final
01/nov/2014
Fin de la iteración
-
Fuente los autores
5.1.3.2 Objetivos de Alto nivel
Obtener una visión clara del problema y lograr un acuerdo de enfoque técnico a la aproximación de la solución
Definición funcional de los artefactos y entregables de cada iteración.
Identificar y refinar requerimientos.
Desarrollar escenarios de prueba.
Gestionar cambios minimizando el impacto.
Implementación y puesta en marcha del servidor de base de datos
Implementación y puesta en marcha del servidor de aplicaciones y funcionalidades asociadas
Implementación y puesta en marcha del Servidor de mapas y funcionalidades asociadas
60
Desarrollo del Cliente Web e integración del cliente Web con el servidor de bases de datos y con el servidor de aplicaciones.
Desarrollo del Cliente Android e Integración con los demás sistemas.
Desplegar la solución.
5.1.3.3 Listado Maestro de Requerimientos. A continuación se listan los artefactos que serán desarrollados en las diferentes fases del proyecto y que a su vez son el insumo para las posteriores iteraciones, se relacionan con el recurso responsable de su gestión.
D.E. = Documento de especificación PCU= Puntos De Caso De Uso (Esfuerzo x Complejidad x 2) Tabla 12. Listado maestro de requerimientos
Nombre o Palabra clave de Descripción
Pri
ori
dad
Es
tim
ació
n
de t
am
añ
o
(PC
U)
Iteración Objetivo
Asignado a
Es
tim
ació
n
de t
iem
po
(ho
ras
)
FASE DE INICIO.
Kick off del Proyecto con identificación de Stakeholders.
5 80 2 Raúl Castro y Sergio Torres
8
D. E. Visión del problema.
5 40 - Raúl Castro 4
Risklist. 3 24 2 Raúl Castro 4
D.E. Estimación de tiempos y costos.
3 36 2 Raúl Castro 6
Estimación de Hitos. 4 32 2 Raúl Castro 4
Levantamiento a alto nivel de requerimientos funcionales y Planteamiento de Objetivos.
4 64 - Raúl Castro 8
Enumeración de posibles herramientas y formas de solución.
3 48 2 Sergio Torres 8
Evaluación de las posibles soluciones y selección de la más apropiada.
4 32 2 Sergio Torres 4
Diagrama de casos de uso
3 18 2 Raúl Castro 3
61
Nombre o Palabra clave de Descripción
Pri
ori
dad
Es
tim
ació
n
de t
am
añ
o
(PC
U)
Iteración Objetivo
Asignado a
Es
tim
ació
n
de t
iem
po
(ho
ras
)
FASE DE ELABORACIÓN.
Especificación de Casos de uso
3 36 - Raúl Castro 6
Diagrama de componentes
4 24 2 Raúl Castro 3
Diagrama de despliegue 4 24 2 Raúl Castro 3
D.E. Diagrama de integración (Arquitectura de la solución)
5 64 3 Sergio Torres 8
D.E. Evaluación de Riesgos
4 32 2 Raúl Castro 4
Análisis de requerimientos y mapeo con los objetivos.
4 64 3 Raúl Castro 8
Gestión de Cambios. - Raúl Castro
FASE CONSTRUCCIÓN.
Artefacto: Base de Datos
4
Instalación de plataforma de BD
- 64 1 Sergio Torres 8
Creación del modelo Relacional
- 80 2 Sergio Torres 10
Creación y ejecución del Script SQL
- 96 3 Sergio Torres 12
Adición de datos iniciales
- 64 3 Sergio Torres 8
Artefacto: Servidor de Aplicaciones
4
Instalación de Plataformas y herramientas de apoyo
- 48 2 Sergio Torres 6
Creación de proyecto y referenciación a fuentes
- 32 3 Sergio Torres 4
Mapeo de las entidades desde BD
- 32 3 Sergio Torres 4
Implementación de - 166 3 Sergio Torres 22
62
Nombre o Palabra clave de Descripción
Pri
ori
dad
Es
tim
ació
n
de t
am
añ
o
(PC
U)
Iteración Objetivo
Asignado a
Es
tim
ació
n
de t
iem
po
(ho
ras
)
desarrollos de la capa negocio.
Integración del Servidor de Aplicación a la BD mediante configuración de acceso
- 32 4 Sergio Torres 4
Artefacto: Servidor ArcGis
4
Instalación y configuración del servidor ArcGis
- 128 2 Sergio Torres 16
Creación Archivo de mapa apoyándose en las Tablas de B.D.
- 480 3 Sergio Torres 60
Instalación de herramientas de geo-procesamiento
- 64 2 Sergio Torres 8
Publicación del Servicio de Mapa
- 256 4 Sergio Torres 32
Artefacto: Cliente WEB 3
Creación de Proyectos EJB EAR y WEB
- 96 2 Sergio Torres 16
Creación de archivos de configuración para JSF, RichFaces e Hibernate
- 96 2 Sergio Torres 16
Creación de la capa de Controlador
- 240 3 Sergio Torres 40
Creación de la capa de Vista
- 180 4 Sergio Torres 30
Creación de la capa de modelo de negocio.
- 300 3 Sergio Torres 50
Artefacto: Cliente Android
5
Creación y configuración del proyecto (Adición de fuentes JSon y SOAP)
- 160 2 Sergio Torres 16
Creación de la Interfaz - 240 3 Sergio Torres 24
63
Nombre o Palabra clave de Descripción
Pri
ori
dad
Es
tim
ació
n
de t
am
añ
o
(PC
U)
Iteración Objetivo
Asignado a
Es
tim
ació
n
de t
iem
po
(ho
ras
)
Gráfica de usuario
Creación de Objetos del contrato SOAP
- 400 3 Sergio Torres 40
Implementación y desarrollos de las funcionalidades de la Aplicación
- 660 3 Sergio Torres 66
Creación de la aplicación de mapas en el cliente Android
- 400 3 Sergio Torres 40
Integración y consumo de Servicios y funcionalidades de los demás sistemas
- 160 4 Sergio Torres 16
Gestión de cambios - 3 Raúl Castro
FASE DE TRANSICIÓN.
Transporte y Liberación del SW en ambientes productivos
4 64 4 Sergio Torres 8
Estabilización del producto.
4 128 4 Sergio Torres 16
Pruebas de usuario final 4 64 4 Raúl Castro 8
Gestión de cambios - - Raúl Castro
Revisión, ajustes y completitud de la Documentación
4 160 Raúl Castro 20
Cierre del proyecto 5 40
Raúl Castro y Sergio torres
4
Fuente los autores
5.1.3.4 Criterio de Evaluación
Respuesta favorable y aceptación por parte de usuarios finales.
80% de la especificación técnica aplicada.
90% de los artefactos construidos.
90% de los requerimientos funcionales alcanzados
Aprobación sobre el 90% de los escenarios de casos de pruebas.
64
5.1.3.5 Valoración. Uno de los principios básicos del Método OpenUP propone la implementación de un ambiente colaborativo con el fin de alinear los intereses y la comprensión de todos los involucrados en el desarrollo del proyecto, este principio promueve prácticas que fomentan un entorno de trabajo saludable, permitir la colaboración y desarrollar una comprensión compartida del proyecto, por eso se plantea al final de cada iteración documentar y socializar las lecciones aprendidas y el valor ganado en la implementación de forma que se pueda retroalimentar la información y realizar mejoras continuas a nivel de equipo de trabajo y que todos los recursos se encuentren en sintonía con lo que el día a día del proyecto puede brindar.
Estas valoraciones brindarán una visión en cuanto a estímulos en el estado del proyecto como también posibles impactos que se recopilarán a lo largo de este, con el propósito de mejorar el proceso actual o para posteriores proyectos.
Se proponen las siguientes valoraciones:
Valor ganado contra objetivos: en la especificación del objetivo no se tenía contemplado una ampliación en cuanto a funcionalidad.
Artefactos Planeados Vs. Construidos: un total de la cantidad de los artefactos construidos vs los planeados puede que resultar en un balance positivo o negativo el cual tendría impacto en el proyecto.
Valoración de Criterios de Evaluación contra resultados de las pruebas: se pueden recoger las diferentes experiencias y sensaciones que se tengan en el proceso de evaluación de criterios contra el resultado que brinden las pruebas.
Otras áreas de interés y desviaciones: se pueden listar otras áreas como Financieros, desviación del cronograma como también la retroalimentación de los Stakeholders o involucrados de interés en el desarrollo del proyecto.
5.1.4 Architecture Notebook
5.1.4.1 Propósito. El proyecto consiste en una arquitectura estricta y bien formada en cada uno de sus componentes, para garantizar una alta cohesión entre los mismos y así poder generar un sistema robusto. El proyecto consiste en 3 entornos principales: entorno empresarial, entorno móvil, entorno geográfico; interactuando en una arquitectura SOA (Arquitectura Orientada a Servicios por sus siglas en ingles) para obtener componentes altamente escalables.
JEE es una plataforma para desarrollar productos de software empresarial distribuido, que promueve la correcta aplicación de estándares de desarrollo transversales a las buenas prácticas. ANDROID es un sistema operativo basado en JAVA que provee un entorno flexible y sólido para aplicaciones en dispositivos móviles e integrados, creado para paliar limitaciones de procesamiento y
65
almacenamiento. ArcGIS es una plataforma de herramientas geográficas que provee soluciones para diferentes entornos (servidor, desktop, móvil, WEB).
El entorno empresarial consiste en una plataforma robusta que encapsula todo el modelo de negocio, generalmente basando su presentación sobre la WEB, lo que la hace ineficiente para algunas interfaces de menor procesamiento y almacenamiento, es necesario abstraer y utilizar solamente los componentes de negocio necesarios para cumplir tareas puntuales y específicas para implementar soluciones que reutilicen el modelo de negocio en dichas interfaces limitadas. Además reutilizar las herramientas geográficas para así poder explotar las capacidades y potencialidades que ofrecen cada uno de los entornos de ejecución, sin que el usuario perciba un cambio brusco de interfaces. La arquitectura SOA garantiza una sincronía entre cada componente que es capaz de existir por si solo, generar las condiciones de comunicación entre cada componente y establecer un lenguaje entre las mismas (XML), con un trasfondo de implementación basado en operaciones sencillas, adaptables y reutilizables.
5.1.4.2 Objetivos y filosofía de la arquitectura. Los objetivos de los componentes arquitecturales y la arquitectura como producto son:
Garantizar el soporte multiplataforma de los componentes de software generados.
Aplicar estándares y estrategias de diseño para escalar el modelo de negocio y exponer de manera segura elementos del mismo.
Utilizar herramientas geográficas para potencializar las capacidades del sistema.
Clasificar y seleccionar una herramienta de procesamiento y presentación geográfica ajustable a la arquitectura SOA.
Acceder a componentes complejos modulares a través de interfaces ligeras, altamente cohesionadas y escalables.
El sistema mantiene como piedras angulares los estándares y buenas prácticas para generar componentes de software de calidad, modular, escalable, robusto, cohesionados, correctos y de constante evolución; que se respaldan en una arquitectura que enfoca el esfuerzo sobre el núcleo de los desarrollos, más que, sobre los elementos de interacción.
5.1.4.3 Suposiciones y dependencias. El entorno empresarial es el encargado de encapsular la lógica de negocio y proveer los servicios correspondientes, se deben exponer, utilizar y suponer métodos sencillos que permitan una comunicación fluida entre los componentes.
Los recursos utilizados en las herramientas geográficas provienen de distintas fuentes de crecimiento continuo y ajeno al sistema, se debe suponer la
66
disponibilidad de los recursos Web así como las api’s de acceso a dichas plataformas.
Todo el sistema está pensado para satisfacer una necesidad empresarial concreta, la solución basada en la arquitectura del componente empresarial almacena y sincroniza los servicios que alimentan los demás ambientes del sistema, convirtiendo así al entorno empresarial en el eje sobre el cual giran los demás ambientes, generando una dependencia fuerte sobre la disponibilidad de la solución empresarial (JEE).
5.1.4.4 Requerimientos relevantes en la arquitectura. A nivel empresarial la arquitectura debe permitir exponer elementos de negocio sin exponer su lógica, esto significa presentar desacoplamiento entre la interfaz de exposición y el componente de negocio; como un factor emergente de este desacoplamiento se presenta la reusabilidad de los métodos de negocio utilizados en la solución empresarial entre la capa de presentación y la de modelo.
En el aspecto geográfico la herramienta debe proveer un protocolo de acceso a la información geográfica que sea escalable tanto en la solución empresarial como en la solución móvil, para garantizar la reutilización de las potencialidades de geo-procesamiento implementadas del lado de la solución geográfica.
En el componente móvil se debe seleccionar un entorno que permita la aplicación de estándares y métodos mínimos para acoplarse a los demás componentes y hacer uso de los servicios expuestos en el componente empresarial y el componente geográfico.
5.1.4.5 Capas de la arquitectura. Los componentes del sistema (componente empresarial, componente geográfico y componente móvil), interactúan en una arquitectura SOA para garantizar que los componentes se encuentran débilmente acoplados y que son altamente escalables. La arquitectura SOA está basada en la exposición de servicios que cumplen con los requisitos de negocio y facilitan la interacción entre los componentes propios y de terceros.
Las capas de la arquitectura SOA se definen así:
Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos.
De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web);
De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
67
De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
De entrega - donde los servicios son desplegados a los usuarios finales.
5.1.4.6 Vistas Arquitecturales. Los patrones de diseño, el patrón de arquitectura MVC y la concepción de un sistema distribuido por capas actúan juntas dando cabida a un modelo arquitectural robusto expresado en el siguiente gráfico de vista lógica:
Figura 12. Modelo arquitectural (vista lógica)
Fuente: Los autores
Con estos componentes se pretende dar alcance a los siguientes requerimientos funcionales más significativos en la aplicación prototipo expresados en el siguiente grafico de casos de uso:
68
Figura 13. Diagrama de casos de uso
Fuente: Los autores
5.1.5 Especificación de casos de uso. La siguiente sección proporciona información sobre las acciones que el sistema debe realizar al responder a los diferentes eventos e interacciones con los diferentes actores en el propósito de operar con información geográfica en un entorno empresarial robusto.
Tabla 13. Caso de uso Ingresar a la aplicación
Nombre del CU CU001 Ingresar a la Aplicación.
Descripción Funcional
Este caso de uso consulta y valida las credenciales de acceso del usuario al sistema y los permisos que tiene el usuario sobre el sistema.
Actor(es) del Caso de Uso
Usuarios. Sistema.
69
Precondiciones
Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información.
La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de Entrada
Campo Tipo Longitud Validación Nombre de usuario Alfanumérico 32 Obligatorio Contraseña Alfanumérico 64 Obligatorio
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario diligencia en el sistema los campos usuario y contraseña.
El sistema captura la información del usuario y busca información del usuario en los repositorios de información, si el sistema no encuentra la información del usuario en el repositorio se dispara el flujo de excepción número 01, de lo contrario continua el flujo normalmente.
2
El sistema con la información del usuario encontrada en el repositorio valida si la contraseña ingresada es la correspondiente al usuario, si la contraseña no corresponde al usuario se dispara el flujo de excepción número 01, de lo contrario continua el flujo normalmente.
3
El sistema consulta los permisos asociados al usuario, si el sistema no encuentra permisos asignados a ese usuario se dispara el flujo de excepción número 02, de lo contrario le brinda acceso al usuario al sistema con los permisos respectivos.
Fin del caso de uso.
Flujo de Excepción 01
Paso Usuario Sistema
1 El flujo de excepción inicia cuando las credenciales de usuario son inválidas.
El sistema le retorna al usuario un mensaje de error notificándole que las credenciales ingresadas no son válidas.
Fin del flujo de excepción 01.
Flujo de Excepción 02
Paso Usuario Sistema
1
El flujo de excepción inicia cuando el usuario no tiene permisos en la aplicación.
El sistema le retorna al usuario un mensaje de error notificándole que no posee permisos sobre la aplicación.
Fin del flujo de excepción 02.
Poscondiciones Usuario ingreso a la aplicación de forma exitosa.
70
En el cliente móvil consulta los accidentes.
Tabla 14. Caso de uso Crear usuarios
Nombre del CU CU002 Crear usuarios.
Descripción Funcional
Permite registrar usuarios y asignarle permisos en el sistema
Actor(es) del Caso de Uso
Usuario Sistema
Precondiciones Los mismos del CU001.
Información del usuario que se desea ingresar (login y permisos).
Datos de Entrada
Campo Tipo Longitud Validación Identificación Alfanumérico 32 Obligatorio Login Alfanumérico 32 Obligatorio Nombres Alfanumérico 128 Obligatorio Apellidos Alfanumérico 128 Obligatorio Correo Alfanumérico 256 Obligatorio Teléfono Alfanumérico 32 NA
Contraseña Alfanumérico 64 Obligatorio, los campos contraseña debe ser iguales
Confirmación Contraseña
Alfanumérico 64 Obligatorio, los campos contraseña debe ser iguales
Permisos Lista NA Obligatorio, Debe tener al menos una opción seleccionada
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario administrador diligencia los campos: Identificación, login, nombres, apellidos, correo teléfono y contraseña en la opción Registrar Usuario
El sistema captura la información del cliente y valida que los campos confirmación de contraseña y contraseña sean iguales, que se haya asignado al menos un permiso al usuario, que el login ingresado no se encuentre registrado en el sistema y que la identificación no se encuentre en el sistema, en caso de que no se cumplan estas premisas se dispara flujo de excepción 01, de lo contrario continua el flujo normalmente.
2 El sistema guarda la información del usuario registrada y los permisos.
Fin del caso de uso.
Flujo de Excepción 01
Paso Usuario Sistema
1
El flujo de excepción inicia cuando el sistema identifica que la información registrada no se encuentra conforme a las premisas de validación.
El sistema muestra mensaje de error al usuario notificándole dependiendo de cada evento lo siguiente: Contraseñas no coinciden No se ha seleccionado al menos
71
un permiso al usuario El login ingresado o la identificación pertenecen a un usuario registrado en el sistema.
Fin del flujo de excepción.
Poscondiciones Usuario registrado en el sistema de forma exitosa, activo y con permisos asignados.
Tabla 15. Caso de uso Modificar Usuarios
Nombre del CU CU003 Modificar usuarios.
Descripción Funcional
Permite modificar la información registrada al usuario y permisos en el sistema.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Información del usuario que se desea modificar.
Datos de Entrada
Campo Tipo Longitud Validación Nombres Alfanumérico 128 Obligatorio Apellidos Alfanumérico 128 Obligatorio Correo Alfanumérico 256 Obligatorio Teléfono Alfanumérico 32 NA
Contraseña Alfanumérico
64 Obligatorio, los campos contraseña y Validación deben ser iguales
Permisos Lista Por
Definir Debe tener al menos una opción seleccionada
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario administrador busca al usuario al que desea modificarle la información en la opción Usuarios, ingresando en el filtro identificación el número de identificación del usuario.
El sistema captura la información ingresada en el filtro y busca en el repositorio la información básica del usuario, en caso de no encontrar información el sistema no muestra nada de lo contrario muestra la información básica del usuario y la opción modificar, continua el flujo normalmente.
2 El usuario selecciona la opción modificar del sistema.
El sistema muestra la siguiente información del usuario: Identificación (no modificable), login (no modificable), nombres, apellidos, correo teléfono contraseña y permisos, continua el flujo normalmente.
3
El usuario modifica los datos en el sistema, cuando finaliza los ajustes selecciona la opción guardar.
El sistema valida que exista permisos asociados y resguarda la información ingresada, si no existe permisos asociados se dispara el flujo de excepción 01.
Fin del caso de uso
Flujo de Paso Usuario Sistema
72
Excepción 01
1
El flujo de excepción inicia cuando el sistema identifica que no existe asociado al menos un permiso al usuario.
El sistema muestra el siguiente mensaje de error al usuario Debe seleccionar al menos un permiso al usuario
Fin del flujo de excepción.
Poscondiciones Usuario con información modificada en el sistema de forma exitosa.
Tabla 16. Caso de uso consultar usuarios
Nombre del CU CU004 Consultar usuarios.
Descripción Funcional
Permite consultar los usuarios registrados en el sistema.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001
Datos de Entrada
Campo Tipo Longitud Validación Identificación Alfanumérico 32 Obligatorio Correo Alfanumérico 256 Obligatorio Nombres Alfanumérico 128 Obligatorio Apellidos Alfanumérico 128 Obligatorio
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario administrador busca al usuario al que desea consultar la información en la opción Usuarios, ingresando en los campos identificación, correo, nombres o apellidos la información respectiva del usuario y selecciona la opción consultar.
El sistema captura la información ingresada, en el campo identificación busca la información exacta ingresada, por nombre y login busca la información parcialmente relacionada con los datos ingresados, en caso de no encontrar información relacionada el sistema muestra el mensaje “sin resultados”, de lo contrario muestra la información relacionada.
Fin del caso de uso.
Poscondiciones NA
Tabla 17. Caso de uso Crear aseguradoras
Nombre del CU CU005 Crear aseguradoras.
Descripción Funcional
Permite la creación del catálogo de aseguradoras.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación NIT Alfanumérico 128 Obligatorio Nombre Alfanumérico 256 Obligatorio Descripción Alfanumérico 512 NA
Flujo Básico
Paso Usuario Sistema
1 El caso de uso inicia cuando el usuario administrador ingresa a la opción Registrar Aseguradora
El sistema captura la información ingresada y valida que los campos
73
e ingresa la información NIT, nombre y descripción
obligatorios hayan sido diligenciados, si no han sido ingresados muestra el mensaje indicándoles al usuario que ese campo es requerido bajo cada uno, de lo contrario resguarda la información.
Fin del caso de uso.
Poscondiciones Aseguradora creada con éxito en el sistema.
Tabla 18. Caso de uso Modificar aseguradoras
Nombre del CU CU006 Modificar aseguradoras.
Descripción Funcional
Permitir ajustar o modificar la información de las aseguradas ingresadas en el sistema.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación NIT Alfanumérico 128 Obligatorio Nombre Alfanumérico 256 Obligatorio Descripción Alfanumérico 512 NA
Flujo Básico
Paso Usuario Sistema
1 El caso de uso inicia cuando el usuario consulta la aseguradora y selecciona la opción Modificar.
El sistema despliega un formulario con los campos NIT, nombre y descripción.
2
El usuario modifica los campos que desea ajustar, una vez finalizado el ajuste selecciona la opción guardar.
El sistema valida que los campos obligatorios estén diligenciados, si no están diligenciados muestra bajo cada campo el mensaje campo requerido, de lo contrario resguarda la información ingresada.
Fin del caso de uso.
Poscondiciones Información de aseguradora modificada exitosamente.
Tabla 19. Caso de uso Consultar aseguradoras
Nombre del CU CU007 Consultar seguradoras.
Descripción Funcional
Permite consultar la información de las aseguradoras.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación NIT Alfanumérico 128 Obligatorio Nombre Alfanumérico 256 Obligatorio
Flujo Básico Paso Usuario Sistema
1 El caso de uso inicia cuando el usuario ingresa a la opción
El sistema captura la información ingresada, en el
74
Consultar Aseguradoras ingresando NIT o Nombre.
campo NIT y nombre busca la información parcialmente relacionada con los datos ingresados, en caso de no encontrar información relacionada el sistema muestra el mensaje “sin resultados”, de lo contrario muestra la información relacionada.
Fin del caso de uso.
Poscondiciones NA
Tabla 20. Caso de uso Registrar accidente
Nombre del CU CU008 Registrar accidente.
Descripción Funcional
Permite al usuario realizar el registro de un nuevo evento tipo accidente.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Aseguradora previamente Creada.
Datos de Entrada
Campo Tipo Longitud Validación
Coordenadas Numérico de punto flotante
NA Obligatorio
Dirección Alfanumérico 128 NA Imagen Binario NA Obligatorio Intensidad Entero NA Obligatorio Victimas Entero NA Obligatorio Heridos Entero NA Obligatorio Vehículos implicados
Entero NA Obligatorio
Fecha y hora Fecha NA Obligatorio descripción Alfanumérico 512 NA Tipo Alfanumérico 128 Obligatorio Persona que registra el accidente
Alfanumérico 32 Obligatorio
Aseguradora Alfanumérico 256 Obligatorio
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario ingresa a la opción Registrar Accidente y selecciona el punto en el mapa donde desea registrar el evento.
El sistema captura la información geográfica y despliega la opción de capturar imagen con el formulario de ingreso de información con los siguientes campos: dirección, Intensidad, Victimas, Heridos, Vehículos implicados, Fecha y hora, descripción y tipo.
2 El usuario captura la imagen del y diligencia el formulario con la información del evento.
El sistema valida que la información obligatoria haya sido diligenciada, en caso de no ingresar algún campo obligatorio
75
el sistema mostrara el mensaje existen campos obligatorios que no han sido diligenciados, de lo contrario, envía la información por el servicio web expuesto para su registro y continua el flujo normalmente.
3
El sistema valida que la información haya sido resguardad con éxito, si no ha sido resguardado con éxito le devuelve un mensaje al usuario notificándole que no se pudo guardar la información, de lo contrario le muestra el mensaje evento ha sido registrado, continua el flujo normalmente.
4
El sistema retorna a la ventana del mapa y actualiza la información mostrando la información con el último evento registrado.
Fin del caso de uso.
Poscondiciones Evento registrado con éxito.
Tabla 21. Caso de uso Consultar accidente
Nombre del CU CU009 Consultar accidente.
Descripción Funcional
Permite al usuario consultar y resaltar los accidentes en el mapa que cumplen con los filtros seleccionados.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Evento registrado en el sistema.
Datos de Entrada
Campo Tipo Longitud Validación Victimas Entero NA Obligatorio Heridos Entero NA Obligatorio Vehículos implicados Entero NA Obligatorio
Flujo Básico
Paso Usuario Sistema
1 El caso de uso inicia cuando el usuario ingresa a la opción Consultar Accidentes.
El sistema despliega una ventana emergente con los filtros: Víctimas, Heridos y Vehículos.
2
El usuario selecciona uno de los filtros y en el filtro selecciona de los posibles valores el que desea consultar.
El sistema muestra en un mapa las ubicaciones de los eventos que cumplen con los criterios de consulta, resaltados con un icono representativo y muestra el mensaje en la pantalla “seleccione para ver detalles”, si el sistema no encuentra eventos que cumplan con las condiciones de búsqueda
76
muestra el mensaje “no existe información relacionada”.
Fin del caso de uso.
Poscondiciones NA
Tabla 22. Caso de uso Ver detalle accidente
Nombre del CU CU010 Ver detalle de accidente.
Descripción Funcional
Visualizar la información en detalle de un accidente.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación Id de accidentes Colección de datos 1,n Obligatorio
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario selecciona la opción Consultar Detalles en la ventana donde se visualiza el mapa con la consulta de accidentes.
El sistema llama al servicio de consulta de información con el primer Id de accidente identificado, recibe la información del evento seleccionado y despliega en la ventana los detalles del mismo: imagen, dirección, intensidad, victimas, heridos, vehículos implicados, fecha y hora descripción, tipo e información geográfica; Si existen múltiples eventos relacionados mostrará las opciones siguiente y anterior, de lo contrario las opciones se encontrarán deshabilitadas.
2 Si el usuario selecciona las opciones “siguiente” o “anterior” se dispara el flujo alterno 01.
Fin del caso de uso.
Flujo Alterno 01
Paso Usuario Sistema
1 El flujo alterno inicia cuando el usuario selecciona las opciones siguiente o anterior.
El sistema llama al servicio de consulta de información con el siguiente Id de accidente identificado, recibe la información del evento seleccionado y despliega en la ventana los detalles del mismo: imagen, dirección, intensidad, victimas, heridos, vehículos, implicados, fecha y hora descripción, tipo e información geográfica; Si existen múltiples eventos relacionados mostrara las opciones siguiente y
77
anterior, de lo contrario las opciones se encuentran deshabilitadas.
Fin del flujo alterno.
Poscondiciones NA
Tabla 23. Caso de uso Identificar accidente
Nombre del CU CU011 Identificar accidente.
Descripción Funcional
Permite identificar los accidentes en un área seleccionada por el usuario en un mapa.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación Coordenada Numérico de punto flotante NA Obligatorio
Flujo Básico
Paso Usuario Sistema
1
El caso de uso inicia cuando el usuario selecciona la opción Identificar Accidente y selecciona en el mapa un punto geográfico.
El sistema captura la coordenada seleccionada y genera un área de búsqueda de 20 puntos de pantalla de acuerdo al nivel visualización o zoom seleccionado, y resalta los accidentes cuyas coordenadas se encuentren en esa área, si el sistema no identifica eventos en el área seleccionada mostrara el mensaje “no se encontraron eventos relacionados en el área seleccionada”, de lo contrario continua el flujo normalmente.
2 El sistema despliega el mensaje “seleccione para ver detalles”.
Fin del caso de uso.
Poscondiciones NA
Tabla 24. Caso de uso Obtener ubicación
Nombre del CU CU012 Obtener ubicación.
Descripción Funcional
Permite obtener la ubicación del dispositivo móvil utilizando a la información del GPS o de un punto seleccionado por el usuario y transformarlo al sistema de referencia de la aplicación.
Actor(es) del Caso de Uso
Usuario. Sistema.
Precondiciones Los mismos del CU001.
Datos de Entrada
Campo Tipo Longitud Validación Coordenada Numérico de punto flotante NA Obligatorio
Flujo Básico Paso Usuario Sistema
1 El caso de uso inicia cuando el
78
sistema captura una nueva coordenada, continua el flujo normalmente.
2
El sistema realiza una proyección de la coordenada capturada al sistema de referencia geográfico en el cual se encuentra la aplicación.
Fin del caso de uso.
Poscondiciones NA
5.1.6 Especificación de Pruebas
Las especificaciones de pruebas se encuentran en la sección de anexos.
5.2 CARONTE
5.2.1 Caracterización y análisis. Como parte del proceso de desarrollo metodológico del presente proyecto se establecieron como los componentes principales que intervienen en la formación de la arquitectura los siguientes:
Servidor de Aplicaciones
Lenguaje de programación
Plataforma móvil
APIS geográficas
Servidor de bases de datos
De los cuales se realizó una indagación de sus aspectos generales con el fin de obtener las características relevantes para el éxito en una posible integración.
5.2.1.1 Servidor de aplicaciones. Como parte esencial de este proyecto, el servidor de aplicaciones es una elección fundamental en la consolidación del mismo, el mercado actualmente ofrece una gran variedad de plataformas entre las cuales se destacan las siguientes:
Tabla 25. Factores de selección servidor de aplicaciones
Servidores de
aplicación Ventajas Desventajas
Esfuerzo en
desarrollo
Reutilización de lógica nivel de adaptabilidad
Integración Escalable
Tomcat Gratis y de
fácil instalación
No hay soporte del fabricante
MEDIA 3 4 5
Glassfish Robustez Bajo
acoplamiento con IDE
BAJA 5 4 4
Liberty profile
No requiere plataforma
Entornos de ejecución
ALTA 4 4 3
79
Servidores de
aplicación Ventajas Desventajas
Esfuerzo en
desarrollo
Reutilización de lógica nivel de adaptabilidad
Integración Escalable
JAVA limitados y pequeños
Jboss
Madurez y agilidad
Solo el fabricante
proporciona el paquete de instalación completo
(JDK + JVM)
BAJA 5 4 4
Fuente los autores
5.2.1.2 Lenguaje de programación. Debido a que la mayoría de procesos y comportamientos de la aplicación se ejecutan en diferentes plataformas se tiene la necesidad de contar con un lenguaje de programación lo suficientemente transversal a estas premisas, en ese orden de ideas se seleccionan los que tienen mayor popularidad en estos aspectos:
Tabla 26. Factores de selección lenguaje de programación
Lenguajes de
programación
Ventajas Des-ventajas Esfuerzo
en desarrollo
Reutilización de lógica nivel de adaptabilidad
Integración Escala
ble
JAVA
Open source multi- plataforma,
soporta desarrollo
de aplicativos
móviles
Máquina virtual en tiempo de ejecución no es fiable para tiempos de respuesta transacciones inmediatas
MEDIO 5 5 5
.NET
Compilador Just in time,
lo que aumenta el rendimiento
Solo ambientes MS, rendimiento impacta sobre carga y requisitos del sistema, Alto costo para las empresas
BAJA 2 2 5
Fuente los autores
5.2.1.3 Plataformas móviles. Las relaciones y factores de incidencia en la selección de la herramienta usada en la parte móvil se destacan en el siguiente cuadro:
80
Tabla 27. Factores de selección plataforma móvil
Plataformas móviles
Ventajas Des-ventajas Esfuerzo
en desarrollo
Integración Escalable
IOS Soporte JAVA e integración de
librerías.
Propietario, todas las
actualizaciones y mejoras
depende de un solo fabricante
MEDIA 2 2
ANDROID
Personalizable, Asequible, Comunidad
mundial trabajando en
su mejora
Se dificulta correr
aplicaciones en segundo plano (consumo de
recursos excesivo)
BAJA 5 4
BlackBerry OS
Rendimiento, Multitarea y seguridad
OS empotrado, Poco o casi nulo soporte a desarrolladores y Poca Aceptación por parte de los usuarios.
ALTA 3 2
Windows Mobile
Seguridad robusta
No permite una integración
fácil de aplicaciones de
terceros
ALTA 3 2
Fuente los autores
5.2.1.4 APIS Geográficas. En la indagación realizada el apartado de API´s geográficas es el más complicado debido a la falta de propuestas en el mercado, sin embargo se pueden rescatar las siguientes:
Tabla 28. Factores de selección APIS geográficas
APIS Geográficas
Ventajas Desventajas Esfuerzo
en desarrollo
Reutilización de lógica nivel
de adaptabilidad
Integración Escalable
Soporte de uno de los
más grandes
fabricantes de la
actualidad.
Demasiadas restricciones comerciales
del fabricante para su uso,
poca robustez e integración
con JavaScript.
MEDIA 5 2 3
ArcGIS Tiene el
más Complejidad a
la hora de BAJA 4 5 5
81
APIS Geográficas
Ventajas Desventajas Esfuerzo
en desarrollo
Reutilización de lógica nivel
de adaptabilidad
Integración Escalable
completo set de
información geográfica y APIS de integración
con plataformas
móviles, escalable
programar, las mejoras o
add-on no son gratis
Fuente los autores
5.2.1.5 Servidores de bases de datos. Conforme a la documentación recopilada tenemos los siguientes candidatos como servidores empresariales para la aplicación:
Tabla 29. Factores de selección servidores de aplicación
Servidores de
aplicación Ventajas Desventajas
Esfuerzo en
desarrollo
Reutilización de lógica nivel de
adaptabilidad
Escalable
POSTGRESS
Operación y mantenimiento
con costos muy bajos
Poca documentación
y soporte en línea por parte del fabricante
BAJA 5 4
MYSQL
Es muy Ágil, fácil de
aprender y Open source
Algunas funcionalidades
son poco intuitivas en comparación
con otros motores de BD
MEDIA 4 3
ORACLE
Motor más usado a nivel mundial por
las empresas “serias”
Costos de licenciamiento
muy altos ALTA 5 5
Fuente los autores
5.2.2 Selección, limitaciones, justificaciones y decisiones
Nivel Móvil. Las opciones a nivel móvil han tenido un crecimiento notable en los últimos 5 años, han surgido propuestas de grandes proveedores de la industria donde muchas han surgido y otras se han quedado rezagadas en el tiempo, dentro de las opciones de mayor índice de crecimiento se destaca Google entre sus competidores, el cual provee un sistema operativo multiplataforma
82
(variedad de equipos, variedad de marcas) para móviles, a diferencia de sus competidores más cercanos. Android se ha seleccionado como herramienta para la plataforma móvil dadas sus capacidades en la parte geográfica, el crecimiento que ha tenido, la aceptación en diferentes marcas y tipos de dispositivos y por estar basado en un sistema operativo libre.
Nivel geográfico. En el componente geográfico se seleccionó ArcGIS, por proveer una API mucho más robusta que la de Google. ArcGIS provee un conjunto de API’s para diferentes entornos entre los que se destacan API Javascript, y API Android, los cuales concuerdan con los requerimientos planteados en la arquitectura para poder escalar la filosofía de la aplicación al entorno empresarial y al entorno móvil, consumiendo los mismos servicios y utilizando las mismas herramientas de geo-procesamiento.
Nivel Empresarial. A nivel empresarial se va a manejar JAVA para utilizar la plataforma JEE, la cual provee un esquema de patrones, frameworks y reusabilidad lo suficientemente maduro para escalar la solución desde aplicaciones pequeñas hasta grandes soluciones empresariales utilizando los mismos estándares. Además provee soporte para tecnologías de Web Service, JSON, WEB, entre otros, que facilitan y encajan dentro de los requerimientos arquitectónicos aquí planteados.
Las API se conectan al servidor utilizando WebService con el protocolo REST, esto garantiza portabilidad entre sistemas, aunque los objetos varían entre los entornos la filosofía se mantiene, entre otras de las capacidades de ArcGIS se destacan que los datos fuente de los servicios de mapa pueden estar alojados en Bases de Datos externas. Existe una limitación al utilizar ArcGIs como el proveedor de los servicios geográficos, para implementar y desplegar un servicio con datos propios es necesario utilizar software propietario de los módulos Desktop y server de ArcGIS.
5.2.2.1 Componentes y mecanismos de Arquitectura. El modelo arquitectónico de la aplicación, se puede analizar en componentes más sencillos. Cada elemento tiene un componente arquitectónico complejo en mayor o menor medida, enfocado a la integración con los otros componentes del sistema. La división lógica del sistema se va de la siguiente manera:
Componente empresarial. El componente empresarial consiste en una arquitectura basada en el patrón de arquitectura de software MVC, el cual se encarga de separar la vista, de los datos y el modelo de negocio propio de la empresa. Para el diseño de arquitectura se aplican patrones, estrategias de diseño y mejores prácticas, las cuales deben ser aplicadas en las diferentes capas del sistema como se muestra en la siguiente figura:
83
Figura 14. Patrones JEE
Fuente (ORACLE, 2013)
Gráfica basada en la información extraída del libro”Core J2EE Patterns best a practices and design strategies. [Sunmicrosystems, Martin Fowler, Prentice Hall]
Los patrones actúan transversales y como interfaz de comunicación entre cada una de las capas del sistema, la lista de patrones de diseño y su correspondiente descripción se expresa así:
Tabla 30. Patrones capa de presentación
Capa de presentación
Nombre del patrón Descripción
Intercepting Filter Facilita el pre-procesamiento y post-procesamiento de un "request"
Front Controller Provee un controlador central para administrar y manejar un "request".
Application Controler Centraliza y modulariza acciones y administración de vistas.
Composite View Crea y agrega vistas desde partes más pequeñas.
Fuente los autores
Tabla 31. Patrones capa de negocio
Capa de Negocio
Nombre del patrón Descripción
Business Delegate Encapsula el acceso a los servicios
84
Capa de Negocio
Nombre del patrón Descripción
de negocio.
ServiceLocator Encapsula la búsqueda de servicios y componentes.
Session Facade Encapsula componentes de la capa de negocio y expone y valor agregado a los clientes.
Composite Entity Implementa objetos persistentes de negocio usando EntityBeans y POJO's
Transfer Object Objetos que se encargan de pasar información entre capas
Fuente los autores
Tabla 32. Patrones capa de integración
Capa de Integración
Nombre del patrón Descripción
Data Access Object Abstrae y encapsule el acceso a la persistencia.
Domain Store Provee un mecanismo transparente de persistencia para objetos de negocio.
Web Service Broker Expone uno o más servicios usando XML, y protocolos WEB.
Fuente los autores
Componente geográfico. El componente ArcGIS tiene una arquitectura propia orientada a la computación en la nube (cloud computing) en la cual se proveen los recursos en uno o varios ambientes de la WEB y proveer herramientas que permitan consumir los mismos recursos en los diferentes escenarios del sistema.
85
Figura 15. Componente geográfico
Fuente: seminario ON-LINE, ArcGIS.com, esri-training proggram, (Enero de 2012)
El núcleo de los sistemas geográficos ArcGIS está basado en la creación de mapas en un entorno desktop, publicarlos en el servidor ArcGIS y exponerlos a través de servicios web utilizando el protocolo REST para consumir los recursos embebidos en el servidor (Mapas, imágenes, geo-procesamiento, geo-database).
Figura 16. Sistemas y recursos involucrados
Fuente: seminario ON-LINE, ArcGIS.com, esri-training proggram, (Enero de 2012)
Componente móvil. Una aplicación del sistema operativo ANDROID se basa en actividades, las cuales son GUI y un manager que lo respalda, cada actividad significa un hilo de proceso, además existen servicios, los cuales son procesos que corren en background y no tienen una interfaz gráfica. Todas las
86
aplicaciones existentes en el dispositivo puedes compartir sus datos utilizando content providers, y pueden ser invocadas y/o utilizadas por otras aplicaciones generando un intent para utilizar capacidades de otra aplicación (p. ej. Generar un intent para capturar y obtener una foto desde la cámara del dispositivo).
En la arquitectura ANDROID se destacan 5 niveles básicos:
• Aplicaciones: Son las aplicaciones existentes en el dispositivo. • Framework de aplicaciones: Es el encargado de gestionar los procesos
generados por las actividades. Trabajan de manera transversal a las aplicaciones y ayudan en el paso de mensajes entre las mismas.
• Librerías: Son los paquetes de componentes y funcionalidades de soporte a las operaciones realizadas en las actividades.
• AndroidRuntime: Define el conjunto de librerías del núcleo de ANDROID. • Linux Kernel: Android está basado en el núcleo de Linux 2.6 utilizado para
manejar la seguridad, la gestión de memoria y procesos, es la interfaz de conexión entre el hardware y el resto del software.
Figura 17. Representacion niveles de arquitectura Android.
Fuente: (Android)
5.3 Integración
Con las principales tecnologías y plataformas seleccionadas se realiza la implementación de la aplicación de la cual emerge la siguiente arquitectura de la y se destacan como principales características la capacidad de permitirle añadir más recursos a un componente particular del sistema, (ejemplo: memoria, un disco
87
duro más rápido) para mejorar el rendimiento del sistema global o añadir una nuevo servidor para el balanceo de carga, es decir su escalabilidad de forma horizontal y vertical, también bajo el marco del rigor académico que debe contemplar la aplicación y la incidencia del factor de calidad de este proyecto.
Figura 18. Arquitectura especifica del sistema
Fuente: los autores
A continuación se amplían la descripción de los componentes y sus principales características como patrones e integraciones.
88
5.3.1 EJB
DAO
Figura 19. Implementación DAO
Fuente: los autores
89
Tabla 33. Cuadro descriptivo implementación DAO
Patrón Descripción Aplicación Relación
Bussiness delegate
Encapsula el acceso a los servicios de negocio.
Interfaces por cada concepto de negocio, que encapsula y expone los servicios necesarios en cada componente
Son las interfaces de más bajo nivel quienes exponen los servicios básicos y atómicos, son llamados únicamente por los EJBs de negocio que dan valor agregado (Session Facade)
Data Access Object
Abstrae y encapsule el acceso a la persistencia.
Clases especializadas que contienen el entity manager de acceso a la capa de datos (EIS – en la arquitectura JEE)
Son las implementaciones de las interfaces de negocio (Bussiness Delegate), implementan los servicios de acceso a datos de un concepto por cada clase.
Fuente los autores.
Entity
Figura 20. Implementación Entity
Fuente: los autores
90
Tabla 34. Cuadro descriptivo implementación Entity
Patrón Descripción Aplicación Relación
Composite Entity
Implementa objetos persistentes de negocio usando Entity Beans y POJO's
Son las clases del mapeo objeto relacional y la interfaz por la que se envían los datos a la base de datos, contiene el control de columnas y relaciones especiales, autonuméricas y muchos a muchos respectivamente.
Son utilizados por los objetos DAO que acceden a la capa de persistencia y que contienen el entity manager.
Fuente los autores
Exception
Figura 21. Implementación Exception
Fuente: los autores
Tabla 35. Cuadro descriptivo implementación Exception
Patrón Descripción Aplicación Relación
Manejar excepciones personalizadas, para controlar la propagación de las mismas
En el nivel más bajo categorizar las excepciones disparadas, para generar una excepción más fácil de controlar y propia de la solución
El componente DAO captura las excepciones y las categoriza en las excepciones de la solución para que en niveles más arriba se tomen las acciones correspondientes
Fuente los autores
91
ResourceManager
Figura 22. Implementación ResourceManager
Fuente: los autores
Tabla 36. Cuadro Descriptivo implementación ResourceManager
Patrón Descripción Aplicación Relación
SINGLETON Centralizar y especializar el acceso a archivos de configuración necesarios en la solución
Solo permite una instancia y lectura del archivo properties.
El componente de negocio que requiere datos alojados en los archivos .properties
Fuente los autores
92
5.3.2 Services
Services
Figura 23. Implementación Services
Fuente: los autores
Tabla 37. Cuadro descriptivo Implementación Services
Patrón Descripción Aplicación Relación
Session Facade
Encapsula componentes de la capa de negocio y expone y valor agregado a los clientes.
Provee valor agregado y agrupa los servicios de manera funcional y en términos del concepto de negocio
Es llamado por la capa de controlador de la interfaz y servicios web, y es el encargado de aplicar el flujo de negocio para utilizar los DAOs
Fuente los autores
93
CheckedException
Figura 24. Implementación CheckedException
Fuente: los autores
Tabla 38. Cuadro descriptivo Implementación CheckedException
Patrón Descripción Aplicación Relación
NA Provee una especialización de las excepciones de la aplicación.
Permite recoger las excepciones, para ser controladas, y mostradas en la interfaz.
Surgen desde la capa de services (Session Facade) y se escalan en las capas que suceden en más alto nivel a la misma.
Fuente los autores
DTO
Figura 25. Implementación DTO
Fuente: los autores
94
Tabla 39. Cuadro descriptivo implementación DTO
Patrón Descripción Aplicación Relación
Transfer Object
Objetos que se encargan de pasar información entre capas.
Transformación entre objetos entity y objetos serializables limpios para paso por WS y capas de la aplicación.
Es creado por la capa de servicios (Session facade) y se maneja en el resto de la aplicación.
Fuente los autores
Helper
Figura 26. Implementación Helper
Fuente: los autores
Tabla 40. Cuadro descriptivo Helper
Patrón Descripción Aplicación Relación
NA Encargados de encapsular la lógica de transformación de los objetos entities y DTO.
Utilizados para reducir complejidad y especializar los elementos de negocio EJB.
Solo son utilizados por los EJBs por lo mismo también se ven como una extensión de los mismos.
Fuente los autores
95
Session Facade
Figura 27. Implementación Session Facade
96
Fuente los autores. Tabla 41. Cuadro descriptivo Session Facade
Patrón Descripción Aplicación Relación
Session Facade
Encapsula componentes de la capa de negocio y expone y valor agregado a los clientes.
Provee valor agregado y agrupa los servicios de manera funcional y en términos del concepto de negocio
Es llamado por la capa de controlador de la interfaz y servicios web, y es el encargado de aplicar el flujo de negocio para utilizar los DAOs
Fuente los autores
5.3.3 Utils
Figura 28. Implementación Utils
Fuente: los autores
Tabla 42. Cuadro descriptivo Utils
Patrón Descripción Aplicación Relación
NA Elementos Se generan clases con los Es manejado desde
97
Patrón Descripción Aplicación Relación
comunes y de acceso en varios niveles.
mensajes a ser mostrados en la aplicación para centralizar los mensajes y facilitar el mantenimiento.
la capa de servicios y las capas subsecuentes de más alto nivel.
Fuente los autores
5.3.4 Web
ManagedBeans
Figura 29. Implementación ManagedBeans
Fuente: los autores
Tabla 43. Cuadro descriptivo implementación ManagedBeans
Patrón Descripción Aplicación Relación
Front Controller
Provee un controlador central para administrar y manejar un "request".
Creación de clases controladoras de la interfaz que capturan los eventos del usuario y garantizan la navegación y usabilidad de la aplicación.
Son los encargados de capturar la información y pasarla a los elementos de servicio para su correspondiente transformación y uso.
98
Fuente los autores
SecurityUtils
Figura 30. Implementación SecurityUtils
Fuente: los autores
Tabla 44.Cuadro descriptivo implementación SecurityUtils
Patrón Descripción Aplicación Relación
Application Controller
Centraliza y modulariza acciones y administración de vistas.
Centraliza el manejo de la sesión http sobre la que se ejecutan todas las peticiones al servidor.
Es utilizada únicamente por los controladores del frente o managed beans.
Fuente los autores
5.3.5 Web services
Figura 31. Implementación Web Services
99
Fuente: los autores
Tabla 45. Cuadro descriptivo implementación Web Services
Patrón Descripción Aplicación Relación
Web service broker
Expone uno o más servicios usando XML, y protocolos WEB.
Clases explícitas que atienden las peticiones de Web Service, no contienen lógica de negocio solo ejercen como traductores entre los datos del negocio y los datos de servicio web.
Utiliza los objetos DTO, y los servicios de negocio.
Fuente los autores
5.3.6 Modelo de datos. El modelo de datos implementado solo aplica para este solución en particular, sin embargo la arquitectura implementada puede soportar modelos más complejos manteniendo características esenciales como desempeño en la gestión de la información.
Figura 32. Modelo de datos
Fuente: Los autores
5.3.7 Otros componentes
Tabla 46. Cuadro descriptivo implementación otros componentes.
Patrón Descripción Aplicación Relación
Composite View
Crea y agrega vistas desde partes más pequeñas.
Se utilizan vistas compuestas a partir de plantillas especializadas para los elementos comunes de la capa de presentación.
Su única relación es con los elementos del controlador (Front Controller).
Domain Store
Provee un mecanismo transparente
Utilizar este patrón permite crear una aplicación y una lógica independiente del
El persistence.xml es el encargado de comunicar la aplicación y los entities
100
Patrón Descripción Aplicación Relación
de persistencia para objetos de negocio.
motor de acceso a datos, utilizando archivos de configuración y herramientas de concurrencia de bajo nivel.
con el correspondiente DATASOURCE y hacer la transformación al lenguaje correspondiente al motor de acceso a datos.
Fuente los autores
101
CAPÍTULO 6. RESULTADOS
La relevancia de este prototipo arquitectural radica en que puede ser utilizado como el fundamento o base en la consolidación de futuras aplicaciones para que principalmente contemplen como enfoque la implementación de patrones arquitecturales y buenas prácticas para el desarrollo de aplicaciones móviles que se integren con escenarios de negocio aún más complejos.
Este prototipo puede ser implementado en aplicaciones de cualquier naturaleza bajo cualquier contexto garantizando escalabilidad y mantenibilidad a lo largo del tiempo.
Se resalta la versatilidad del marco de OpenUP para la gestión de este proyecto debido a que el esfuerzo se centraliza desde etapas tempranas en el análisis y diseño de la arquitectura objetivo del sistema, lo que era el claro propósito de esta iniciativa.
En términos de calidad se resalta el uso de la documentación estándar de Java y de una arquitectura basada en capas lo que permite un mejor entendimiento y extensión de la solución, esto garantiza componentes especializados y correctamente encapsulados donde la lógica no se encuentra atada a procesos externos específicos sino que es propia.
En un principio se consideró que la metodología propuesta en OpenUP solo serviría para la gestión del proyecto, sin embargo siendo un marco de referencia basado en el agilísimo también integra de forma muy simple la fase de construcción y desarrollo del producto, demostrando ser altamente versátil y útil para la gestión transversal de las fases de este proyecto.
Cuando se empezó a realizar la integración de las herramientas se encontraron comportamientos específicos propios de la implementación lo que llevó a revisar el conjunto de patrones para mejorar la solución como por ejemplo llamados a WS y tecnología de bajo nivel donde se visualizó que podía encapsularse en componentes genéricos temas específicos que solo son aplicables a la solución.
Respecto a la gestión del repositorio de imágenes se encontró que debía ser un recurso externo por temas de mantenibilidad y administración del mismo ya que por lo general estas ubicaciones que resguardan imágenes presentan un crecimiento mayor al de una base de datos normal.
102
Respecto a ArcGIS se encontraron algunas limitaciones en el uso debido principalmente a que el objetivo de la aplicación prototipo nunca es la construcción de mapas sino la utilización de los que son suministrados por ArcGIS, por temas de licenciamiento estos mapas solo se pueden implementar en entornos y aplicaciones de pruebas y no para entornos productivos.
En la arquitectura objetivo se utiliza una capa para transacciones generales donde no se gestiona información parcial sino general, también se resalta que no existen elementos hardcoded lo que permite centralizar el manejo de las constantes y los mensajes del sistema
La capa de vista de Android solo se especializa en la parte visual y comunicaciones sin embargo este entorno por ser tan liviano presenta el desafío del manejo de procesos complejos, este inconveniente se resolvió utilizando herramientas externas como KSOAP lo que brinda la oportunidad de realizar el llamado a WS.
Se presentaron inconvenientes con los tiempos de respuesta del aplicativo Android ya que en el momento de realizar consultas el sistema no respondía de forma esperada, dando la impresión que estaba procesando algún tipo de información, se tuvo que realizar una re-implementación por la cantidad de información que transitaba por el WS, se generaron transacciones más pequeñas de información específica que necesitaba el usuario lo que denominamos sistema de carga de datos por demanda esto para garantizar transacciones livianas y que solo los datos necesarios sean los que se transporten, no obstante la funcionalidad está planteada para generar una nueva petición cuando se requiere más detalle en la información.
Para el componente de seguridad se creó un sistema basado en R-BAC (role-based access control por sus siglas en inglés o control de acceso basado en roles) con roles centralizados con el propósito de garantizar que los usuarios de Android son administrados por la aplicación empresarial lo que impide la posibilidad de tener usuarios duplicados.
En esta arquitectura al contar con un servidor centralizado y utilizando el protocolo HTML el cliente Web es independiente y no importa si está basado en plataformas de 32 o 64 bits en todo momento este componente puede acceder a la aplicación.
La utilización de patrones como Business Delegate permite encapsular en bloques complejos lógicas de procesos que acceden a los componentes más específicos por lo tanto nunca se consulta un objeto o un documento, sino información en sí que brinda el valor agregado con el uso del patrón DTO se independizó las identidades para ser transportadas vía WS como entidades
103
básicas lo que después se constituyen en objetos para la los entornos empresariales y móvil.
La utilización de herramientas de integración continua facilitan el trabajo en equipo y permiten la automatización de tareas y de despliegue. El desarrollo por capas permitió realizar el despliegue en entornos sencillos y la parte de lógica se desacopló de la configuración para ser implementado en un clúster gracias a la configuración del servidor y los recursos de maquina utilizados.
El proyecto no recurrió a desarrollos redundantes debido a las bondades de los componentes seleccionados como si puede ocurrir con muchas herramientas o marcos de desarrollo web diferentes como NET, las cuales permiten adaptarse a entornos móviles sin embargo se ven limitados en la utilización directa de componentes como la cámara del dispositivo o el GPS .
104
CAPÍTULO 7. BIBLIOGRAFIA
Android. (2013, Mayo 16). Herramientas Android para desarrolladores. Retrieved Mayo 16, 2013, from API Guides for Developers: http://developer.android.com/guide/components/index.html
ARGIS. (2014, 03 05). Capas y mapas en ARGIS. Retrieved 03 05, 2014, from Maps and Layers: HTTPS://DEVELOPERS.ARCGIS.COM/ANDROID/GUIDE/MAPS-AND-LAYERS.HTM
ECLIPSE. (2013, MAYO 16). Introduction OpenUp. Retrieved MAYO 16, 2013, from http://epf.eclipse.org/wikis/openup/
Enterprise JavaBeans. (2014, 09 25). Enterprise JavaBeans Wikipedia. Retrieved 09 25, 2014, from http://es.wikipedia.org/wiki/Enterprise_JavaBeans
Eric Jendrock, I. E. (2010). The Java EE 6 Tutorial: Basic Concepts. Boston MA: Addison-Wesley.
ESRI. (2013, Mayo 16). Entornos de ejecución y SDK para Android . Retrieved Mayo 16, 2013, from ArcGIS Runtime SDK for Android: http://resources.arcgis.com/en/communities/runtime-android/
Google. (2013, MAYO 16). Developer Support Resources. Retrieved MAYO 16, 2013, from http://developer.android.com/support.html
Hibernate. (2014, 09 14). Hibernate Wikipedia . Retrieved 09 14, 2014, from http://en.wikipedia.org/wiki/Hibernate_(Java)
JBoss Comunity. (2014, 09 25). Jboss AS 6 Documentation. Retrieved 09 25, 2014, from http://www.jboss.org/jbossas/docs/6-x
JSON. (2014, 09 05). JSON. Retrieved 09 05, 2014, from JSON: http://www.json.org/
Malks, D. A.-J.-D. (2003). Core J2EE Patterns - Best Practices and Design Strategies. Pearson Education.
OpenUP. (2014, 09 14). OpenUP. Retrieved 09 14, 2014, from http://epf.eclipse.org/wikis/openup/
ORACLE. (2013, MAYO 16). Java Documentation. Retrieved MAYO 16, 2013, from http://www.oracle.com/technetwork/java/javaee/overview/index.html
105
Oracle. (2014, 09 14). Oracle JSF Documentation. Retrieved 09 14, 2014, from HTTP://WWW.ORACLE.COM/TECHNETWORK/ARTICLES/JAVA/JAVA-PRIMEFACES-2191907.HTML
Oracle EJB . (2014, 03 05). Enterprise Java Beans Technology. Retrieved 03 05, 2014, from http://www.oracle.com/technetwork/java/javaee/ejb/index.html
Sampieri, R. H. (1991). METODOLOGÍA DE LA INVESTIGACION. Ciudad deMexico: McGRAW - HILL INTERAMERICANA DE MÉXICO, S.A. de C.V.
SCRUM.ORG. (2013, MAYO 16). SCRUM Resources. Retrieved MAYO 16, 2013, from http://www.scrum.org/Resources
Shaw, D. G. (1994). An Introduction to Software Architecture. Pittsburgh, PA: World Scientific.
SOAP. (2014, 09 16). SOAP Wikipedia . Retrieved 09 16, 2014, from SOAP: HTTP://ES.WIKIPEDIA.ORG/WIKI/SIMPLE_OBJECT_ACCESS_PROTOCOL
106
CAPÍTULO 8. ANEXOS
8.1. EVALUACION DEL PROYECTO: ANALISIS COSTO / BENEFICIO
La evaluación de proyectos es un proceso por el cual se determina el impacto de los cambios generados en la posible implementación de un proyecto a partir de la comparación entre el estado actual y el estado objetivo previsto en su planificación, en ese orden de ideas la evaluación se puede considerar como una actividad orientada a mejorar la eficacia de los proyectos en relación con sus fines además de promover mayor eficiencia.
8.1.1. Tipo de evaluación. En el análisis se busca conocer del proyecto su pertinencia, viabilidad y eficacia potencial al seleccionar entre varias alternativas técnicamente factibles la que produce el mayor impacto con un mínimo costo, para esto se propone realizar una evaluación técnica ya que es una mezcla entre Estrategia (parte que considera el entorno social y político) con su capacidad para trascender en el tiempo siendo equitativo y la parte Administrativa donde el fin siempre es la mayor racionalización de todos los recursos y expresión concreta de la eficiencia. . 8.1.2. Criterio. Eficiencia: medida en que los recursos (insumos, dinero, tiempo) son convertidos en los resultados del proyecto, este criterio es fundamental en el análisis costo-beneficio.
8.1.3. Evaluación. Costo / Beneficio: La evaluación debe establecer una relación positiva entre su costo (económico, de tiempo o recursos) y su contribución en valor agregado para la experiencia de los involucrados en el proyecto. 8.1.4. Línea Base y Arquitectura Empresarial Objetivo Para establecer el diferencial que existe entre el escenario actual y el diseño que se propone se plantean los conceptos de línea base y arquitectura empresarial objetivo los cuales brindarán una perspectiva a nivel general de los beneficios en la implementación. Con el propósito de materializar los costos y los posibles beneficios a continuación se concreta la idea del prototipo arquitectural en la implementación de un ERP que obtiene información en campo (exteriores) el cual es un entorno empresarial común y muy útil como base de ejemplo.
107
8.1.4.1. Línea Base
Figura 33. Línea base.
Fuente: Los autores.
8.1.4.2. Arquitectura empresarial objetivo Figura 34. Arquitectura Objetivo.
Fuente: Los autores.
108
8.1.5. Beneficios. Estos son los beneficios asociados al implementar una arquitectura que articule el entorno empresarial con una solución móvil:
Operación descentralizada. Alta disponibilidad y fiabilidad al contar con información en tiempo real obtenida
en campo. Integración de la plataforma a las tendencias mundiales lo que potencia su uso y
permanencia. Utilización de información geográfica gestionada y enriquecida por el dispositivo
móvil. Fortalecimiento e integración de procesos.
8.1.6. Costos. los principales costos al no contar con una solución de este estilo se listan a continuación:
Manejo procedimental o posibilidad de manipulación de la información lo que puede conllevar errores manuales, reprocesos o perdida de información.
Ocupación innecesaria de recurso humano al tener que utilizar procedimientos poco eficientes para la obtención de datos y su posterior cargue en la plataforma empresarial.
Gestión ineficiente de los recursos empresariales (información y tecnología).
8.1.7. Análisis Cuantitativo Relación Costo / Beneficio. Los principales conceptos que ayudan a cuantificar la inversión de recursos que intervienen en el propósito de implementar las solución de arquitectura se listan a continuación: Tabla 47. Relación Costo beneficio.
ID Concepto Sin arquitectura Integrada a ERP
Con Arquitectura Integrado a ERP
Costos de implementación (solo una vez)
1 Licenciamiento ERP (aplica para ambos casos) multiusuario.
$100´000.000 $100´000.000
2 Análisis No Aplica $1´304.000
3 diseño No Aplica $1´000.000
4 desarrollo No Aplica $2´396.000
5 Pruebas No Aplica $2´213.000
6 Infraestructura $6´000.000 (Servidor de aplicaciones)
$7´577.000 (Servidor de aplicaciones + dispositivos móviles + canales de internet móvil)
7 Gestión del proyecto (incluye capacitación)
$30´000.000 $15´000.000
109
ID Concepto Sin arquitectura Integrada a ERP
Con Arquitectura Integrado a ERP
Costos de operación y soporte calculados para el primer año
8 Soporte (10% de la licencia + 10% de implementación)
$10´000.000 $12´000.000
9 Costo de recursos en Campo para toma de información.
2 recursos para cumplir con objetivo. $24´000.000
1 recurso para cumplir con objetivo. $12´000.000
10 Costo de recursos en entorno empresarial cargando la información.
1 Recurso. $12´000.000
No Aplica
11 Costos reprocesos por toma de información errónea o corrupta
30% del costo de 1 recurso en campo. $4´000.000
No Aplica
TOTAL $187´000.000 $154´490.000
Fuente: Los autores.
Para este escenario de un ERP multi-usuario e implementando el prototipo arquitectural se tiene una optimización de recursos (eficiencia) de:
$187´000.000 = 100%
$154´490.000 = 82.35%
Beneficio =17.65 % Solo en el primer año de operación y contando con la puesta en marcha.
110
8.2. PLAN DE RIESGOS O RISKLIST
Tabla 48. Listado de plan de riesgos
Risk ID
Identificado en
la Fech
a
Titulo Descripción Tipo
Impacto
Probabilidad
Magnitud
Responsable
Estrategia de mitigación
1 21/03/ 2012
Elección Errónea de plataforma tecnológica
Diseño de la solución desde el escenario arquitectural sin tener pleno conocimiento de problemas en la ejecución
Technical
5 50%
2.5 Analist Pruebas en cada iteración, documentación de errores
2 21/03/ 2012
Daño del Equipo Móvil
Manipulación del registro del dispositivo móvil desde el IDE puede generar daños irreversibles
Technical
5 50%
2.5 Developer Escenarios de pruebas, emuladores
3 21/03/ 2012
Sub-estimación de tiempos de entrega de desarrollos y documentación
Desconocimiento del nuevo método y/o proceso de desarrollo de la solución, atascamiento en una iteración
Schedule
3 50%
1.5 Project manager
Entregables ajustados al cronograma con buffer del 15% sobre el tiempo total del desarrollo.
4 21/03/ 2012
Licenciamiento no normativizado o desregularizado
Implementación de una arquitectura que implique el uso de SW que en su licencia se contemple el pago por algún tipo de concepto no previsto
Technical
4 33%
1.3 architect Diseño arquitectural acucioso para evitar choques de funcionalidades y de respectivos licenciamientos.
5 21/03/ 2012
falta de conexión del cliente web
falla de conexión del cliente WEB a través de internet móvil
Technical
2 5%
0.1 tester funcionalidad y conexión a través de LAN
Fuente: Los autores
111
8.3. Especificación de casos de prueba
Flujo Básico CU001
Tabla 49. Especificación Pruebas CU001
Nombre caso de uso: Ingresar a la aplicación
Autor Raul Castro
Fecha 16/10/2014
Descripción: Ingreso del sistema validando credenciales de acceso, y los permisos que tiene el usuario en el sistema
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
Usuario Contraseña
Sergio 2145
*Sergio */23 ser
insert david insert 1234
update nombre usuario update contraseña
Resultado esperado Ingreso exitoso cargando los permisos asignados
Poscondiciones Se debe realizar un ingreso satisfactorio a la aplicación con los permisos cargados según configuración En el cliente móvil consulta los accidentes.
Resultado Obtenido Ingreso exitoso cargando los permisos asignados
Validación de datos obligatorios
Campo Tipo Longitu
d Validación Obligatoriedad Longitud Tipo
Nombre de usuario
Alfanumérico 32 Obligatorio SI SI NO 1 33 "#$%&/()?¡
Contraseña Alfanumérico 64 Obligatorio SI NO SI 1 65 !"#$%&/()=?¡
112
Resultado esperado
Ingreso al sistema
Mensaje de error
Mensaje de error
Ingreso al sistema
Mensaje de error
Ingreso al sistema
Resultado Obtenido
Flujo de Excepción 1 CU001
Tabla 50. Especificación Pruebas FE 1 CU002
Nombre caso de uso: Ingresar a la aplicación
Autor Raul Castro
Fecha 16/10/2014
Descripción: Credencial de usuario no es valida
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
Usuario Contraseña
SeRgIo 2145
*Sergio */23 ser
insert david insert 1234
update nombre usuario update contraseña
Resultado esperado Mensaje de error indicando que las credenciales son incorrectas (NO debe mostrar puntualmente que es el usuario incorrecta )
Poscondiciones NO permite el ingreso al aplicativo NO consulta en el cliente móvil los accidentes.
Resultado Obtenido Mensaje de error indicando que las credenciales son incorrectas (NO debe mostrar puntualmente que es el usuario incorrecta )
Flujo de Excepción 2 CU001
Tabla 51. Especificación Pruebas FE 2 CU001
Nombre caso de uso: Ingresar a la aplicación
113
Autor Raul Castro
Fecha 16/10/2014
Descripción: Contraseña no es valida
Actores: Usuario
Precondiciones Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
Usuario Contraseña
Sergio 2146
*Sergio */23 ser
insert david insert 1234
update nombre usuario update contraseña
Resultado esperado Mensaje de error indicando que las credenciales son incorrectas(NO debe mostrar puntualmente que es la contraseña incorrecta )
Poscondiciones NO permite el ingreso al aplicativo NO consulta en el cliente móvil los accidentes.
Resultado Obtenido Mensaje de error indicando que las credenciales son incorrectas(NO debe mostrar puntualmente que es la contraseña incorrecta )
Flujo de Excepción 2 CU001
Nombre caso de uso: Ingresar a la Aplicación
Autor Raul Castro
Fecha 16/10/2014
Descripción: Ingreso SIN permisos al sistema.
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema pero sin permisos en el sistema.
Datos de prueba
Usuario Contraseña
Sergio 2145
*Sergio */23 ser
insert david insert 1234
update nombre usuario update contraseña
114
Resultado esperado Mensaje de error notificándole que no posee permisos sobre la aplicación.
Poscondiciones No permite el ingreso al sistema ya que no posee permisos en la aplicación.
Resultado Obtenido Mensaje de error notificándole que no posee permisos sobre la aplicación.
Flujo Básico CU002
Tabla 52. Especificación Pruebas CU002
Nombre caso de uso:
Crear usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite registrar usuarios y asignarle permisos en el sistema
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. Información del usuario que se desea ingresar (login y permisos)
Datos de prueba
identificación Login Nombres Apellidos Correo Teléfono Contraseña Confirmación Contraseña
Permisos
80771138 davin cristian palomino davin@gmail.com 6871802 1234 1234 Todos
80771139 javier javier torres Torres@gmail.com 4542045 1235 1235 Todos
80771140 sergio sergio almanza almanza@gmail.com 6936533 1236 1236 Todos
80771141 camilo camilo romero romero@gmail.com 2274525 1237 1237 Todos
Resultado esperado
Se crea el usuario con los permisos activos y listo para ser usado
Poscondiciones Usuario registrado en el sistema de forma exitosa, activo y con permisos asignados.
Resultado Obtenido
Se crea el usuario con los permisos activos y listo para ser usado
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
identificación Alfanumérico 32 Obligatorio NO NO NO NO NO 1 33 "#$%&/()?¡
115
Login Alfanumérico 32 Obligatorio NO NO NO NO NO 1 65 !"#$%&/()=?¡
Nombres Alfanumérico 128 Obligatorio NO NO NO NO NO 1 129 !"#$%&/()=?¡
Apellidos Alfanumérico 128 Obligatorio NO NO NO NO NO 1 129 !"#$%&/()=?¡
Correo Alfanumérico 256 Obligatorio SI NO NO NO NO 1 257 !"#$%&/()=?¡
Teléfono Alfanumérico 32 NA 31 33 !"#$%&/()=?¡
Contraseña Alfanumérico 64
Obligatorio, los campos contraseña debe ser iguales
NO NO SI NO NO
1 65 !"#$%&/()=?¡
Confirmación Contraseña
Alfanumérico 64
Obligatorio, los campos contraseña debe ser iguales
NO NO NO SI NO
60 65 !"#$%&/()=?¡
Permisos Lista NA
Obligatorio, Debe tener al menos una opción seleccionada
NO NO NO NO SI
N/A N/A Todos
Resultado esperado
Mensaje de error
Mensaje de error
Mensaje de error
Mensaje de error
Mensaje de error
Creación de usuario
Mensaje de error
Creación de usuario
Resultado Obtenido
Flujo de Excepción 1 CU002
Tabla 53. Especificación Pruebas FE 1 CU002
Nombre caso de uso: Crear usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Valida que la contraseña no coincide con la confirmación de contraseña
Actores: Administrador
116
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. Información del usuario que se desea ingresar (login y permisos)
Datos de prueba
identificación Login Nombres Apellidos Correo Teléfono Contraseña Confirmación Contraseña
Permisos
80771138 davin cristian palomino davin@gmail.com 6871802 1234 234 Todos
80771139 javier javier torres Torres@gmail.com 4542045 1235 234 Todos
80771140 sergio sergio almanza almanza@gmail.com 6936533 1236 234 Todos
80771141 camilo camilo romero romero@gmail.com 2274525 1237 234 Todos
Resultado esperado No crea usuario y presenta mensaje de error
Poscondiciones NO registra Usuario en el sistema de forma exitosa, ni activo y sin permisos asignados.
Resultado Obtenido No crea usuario y presenta mensaje de error
Flujo de Excepción 2 CU002
Tabla 54. Especificación Pruebas FE 2 CU002
Nombre caso de uso: Crear usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: No se selecciona un permiso asociado al usuario que se está creando
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. Información del usuario que se desea ingresar (login y permisos)
Datos de prueba
identificación Login Nombres Apellidos Correo Teléfono Contraseña Confirmación Contraseña
Permisos
80771138 davin cristian palomino davin@gmail.com 6871802 1234 234
80771139 javier javier torres Torres@gmail.com 4542045 1235 234
80771140 sergio sergio almanza almanza@gmail.com 6936533 1236 234
117
80771141 camilo camilo romero romero@gmail.com 2274525 1237 234
Resultado esperado No crea usuario y presenta mensaje de error asociado a los permisos.
Poscondiciones NO registra Usuario en el sistema de forma exitosa, ni activo y sin permisos asignados.
Resultado Obtenido No crea usuario y presenta mensaje de error asociado a los permisos.
Flujo de Excepción 3 CU002
Tabla 55. Especificación Pruebas FE 3 CU002
Nombre caso de uso: Crear usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: El login ingresado ya está en uso
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. Información del usuario que se desea ingresar (login y permisos)
Datos de prueba
Identificación Login Nombres Apellidos Correo Teléfono Contraseña Confirmación Contraseña
Permisos
80771138 davin cristian palomino davin@gmail.com 6871802 1234 234
80771139 davin javier torres Torres@gmail.com 4542045 1235 234
80771140 sergio sergio almanza almanza@gmail.com 6936533 1236 234
80771141 sergio camilo romero romero@gmail.com 2274525 1237 234
Resultado esperado No crea usuario y presenta mensaje de error asociado a el login del usuario
Poscondiciones No registra Usuario en el sistema de forma exitosa, ni activo y sin permisos asignados.
Resultado Obtenido No crea usuario y presenta mensaje de error asociado a el login del usuario
Flujo de Excepción 4 CU002
118
Tabla 56. Especificación Pruebas FE 4 CU002
Nombre caso de uso: Crear usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: La identificación ingresada ya está en uso
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. Información del usuario que se desea ingresar (login y permisos)
Datos de prueba
identificación Login Nombres Apellidos Correo Teléfono Contraseña Confirmación Contraseña
Permisos
80771138 davin cristian palomino davin@gmail.com 6871802 1234 234 todos
80771138 javier javier torres Torres@gmail.com 4542045 1235 234 todos
80771138 sergio sergio almanza almanza@gmail.com 6936533 1236 234 todos
80771138 camilo camilo romero romero@gmail.com 2274525 1237 234 todos
Resultado esperado No crea usuario y presenta mensaje de error asociado a la identificación del usuario
Poscondiciones No registra Usuario en el sistema de forma exitosa, ni activo y sin permisos asignados.
Resultado Obtenido No crea usuario y presenta mensaje de error asociado a la identificación del usuario
Flujo Básico CU004
Tabla 57. Especificación Pruebas CU004
Nombre caso de uso: Modificar usuarios.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite modificar la información registrada al usuario y permisos en el sistema.
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información.
119
Información del usuario que se desea modificar. Según el filtro encontrado trae los datos solicitados
Datos de prueba
Nombres Apellidos Correo Teléfono Contraseña Permisos
cristian palomino davin@gmail.com 6871802 1234 Todos
javier torres Torres@gmail.com 4542045 1235 Todos
sergio almanza almanza@gmail.com 6936533 1236 Todos
camilo romero romero@gmail.com 2274525 1237 Todos
Resultado esperado Encuentra y visualiza los datos solicitados según los filtro seleccionados
Poscondiciones Muestra la información básica del usuario y la opción modificar
Resultado Obtenido Encuentra y visualiza los datos solicitados según los filtro seleccionados
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
Nombres Alfanumérico 128 Obligatorio NO NO NO NO 1 33 "#$%&/()?¡
Apellidos Alfanumérico 128 Obligatorio NO NO NO NO 1 65 !"#$%&/()=?¡
Correo Alfanumérico 256 Obligatorio SI NO NO NO 1 257 !"#$%&/()=?¡
Teléfono Alfanumérico 32 NA 30 33 !"#$%&/()=?¡
Contraseña Alfanumérico 64
Obligatorio, los campos contraseña y Validación deben ser iguales
NO NO SI NO 1 65 !"#$%&/()=?¡
Permisos Lista Por
Definir
Debe tener al menos una opción seleccionada
NO NO NO SI al
menos uno
toda la lista
Resultado esperado
Ingreso al
sistema
Mensaje de error
Mensaje de error
Mensaje de error
Modifica usuario
Mensaje de error
Modifica usuario
Resultado Obtenido
120
Flujo Básico CU005
Tabla 58. Especificación Pruebas CU005
Nombre caso de uso: Crear aseguradoras.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite la creación del catálogo de aseguradoras.
Actores: Administrador
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
NIT Nombre Descripción
900.801.788-8 Colseguros seguros
900.801.788-9 Americana de seguros seguros
900.801.788-10 Seguros Águila seguros
900.801.788-11 Seguros viaje seguro seguros
Resultado esperado Creación exitosa de la aseguradora
Poscondiciones Aseguradora creada con éxito en el sistema.
Resultado Obtenido Creación exitosa de la aseguradora
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
NIT Alfanumérico 128 Obligatorio SI SI NO 1 129 "#$%&/()?¡
Nombre Alfanumérico 256 Obligatorio SI NO SI 1 257 !"#$%&/()=?¡
Descripción Alfanumérico 512 NA 1 513 !"#$%&/()=?¡
Resultado esperado
Creación de aseguradora
Mensaje de error
Mensaje de error
Ingreso al sistema
Mensaje de error
Ingreso al sistema
Resultado Obtenido
Flujo Básico CU006
121
Tabla 59. Especificación Pruebas CU006
Nombre caso de uso:
Modificar aseguradoras.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite la modificación de los datos del catálogo de aseguradoras.
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
NIT Nombre Descripción
900.801.788-8 Colseguros S.A seguros
900.801.788-9 Americana de seguros S.A seguros
900.801.788-10 Seguros Águila S.A seguros
900.801.788-11 Seguros viaje seguro S.A seguros
Resultado esperado Modificación exitosa de la aseguradora
Poscondiciones Aseguradora modificada con éxito en el sistema.
Resultado Obtenido Modificación exitosa de la aseguradora
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
NIT Alfanumérico 128 Obligatorio SI SI NO 1 129 "#$%&/()?¡
Nombre Alfanumérico 256 Obligatorio SI NO SI 1 257 !"#$%&/()=?¡
Descripción Alfanumérico 512 NA 1 513 !"#$%&/()=?¡
Resultado esperado
Modifica aseguradora
Mensaje de error
Mensaje de error
Ingreso al sistema
Mensaje de error
Modifica aseguradora
Resultado Obtenido
Flujo Básico CU007
122
Tabla 60. Especificación Pruebas CU007
Nombre caso de uso: Consultar Aseguradora
Autor Raul Castro
Fecha 16/10/2014
Descripción: Consulta la información de una aseguradora en el sistema
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
NIT Nombre
900.801.788-8 Colseguros S.A
900.801.788-9 Americana de seguros S.A
900.801.788-10 Seguros Águila S.A
900.801.788-11 Seguros viaje seguro S.A
Resultado esperado Consulta la información de NIT y Nombre de la aseguradora
Poscondiciones Consulta la información de la aseguradora
Resultado Obtenido Consulta la información de NIT y Nombre de la aseguradora
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
NIT Alfanumérico 128 Obligatorio SI SI NO 1 129 "#$%&/()?¡
Nombre Alfanumérico 256 Obligatorio SI NO SI 1 257 !"#$%&/()=?¡
Resultado esperado
Creación de aseguradora
Mensaje de error
Mensaje de error
Ingreso al sistema
Mensaje de error
Creación de aseguradora
Resultado Obtenido
Flujo Básico CU008
Tabla 61. Especificación Pruebas CU008
Nombre caso de Registrar accidente.
123
uso:
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite al usuario realizar el registro de un nuevo evento tipo accidente.
Actores: Usuario
Precondiciones: • Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso. • Aseguradora previamente Creada.
Datos de prueba
Coordenadas
Dirección Imagen Intensidad
Victimas
Heridos Vehículos implicado
s
Fecha y hora
descripción
Tipo Persona que
registra el accidente
Aseguradora
Resultado esperado
Genera un mensaje indicando que el accidente fue guardado con éxito
Poscondiciones Se registra con éxito el accidente
Resultado Obtenido
Genera un mensaje indicando que el accidente fue guardado con éxito
Validación de datos obligatorios
Campo Tipo Longit
ud Validació
n Obligatoriedad Longitud Tipo
Coordenadas
Numérico de punto flotante
NA Obligatorio NO NO NO NO NO NO NO NO NA NA NA
Dirección Alfanumérico
128 NA NO NO NO NO NO NO NO NO 1 129 !"#$%&/()=?¡
Imagen Binario NA Obligatorio NO NO NO NO NO NO NO NO 1 NA NA
Intensidad Entero NA Obligatorio NO NO NO NO NO NO NO NO 1 NA NA
Victimas Entero NA Obligatorio SI NO NO NO NO NO NO NO 1 NA NA
Heridos Entero NA Obligatorio NO SI NO NO NO NO NO NO 31 NA NA
Vehículos Entero NA Obligatorio NO NO SI NO NO NO NO NO 1 NA NA
124
implicados
Fecha y hora Fecha NA Obligatorio NO NO NO SI NO NO NO NO NA NA 2015/55/88
descripción Alfanumérico
512 NA NO NO NO NO SI NO NO NO 10 513 !"#$%&/()=?¡
Tipo Alfanumérico
128 Obligatorio NO NO NO NO NO SI NO NO 1 129 !"#$%&/()=?¡
Persona que registra el accidente
Alfanumérico
32 Obligatorio NO NO NO NO NO NO SI NO 1 33 !"#$%&/()=?¡
Aseguradora Alfanumérico
256 Obligatorio NO NO NO NO NO NO NO SI 1 257 !"#$%&/()=?¡
Resultado esperado
Mensaje de error
Mensaje de error
Mensaje de error
Mensaje de error
Mensaje de error
Creación de usuario
Mensaje de error
Creación de usuario
Resultado Obtenido
Flujo Básico CU009
Tabla 62. Especificación Pruebas CU009
Nombre caso de uso: Consultar accidente.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite la modificación de los datos del catálogo de aseguradoras.
Actores: Usuario
Precondiciones:
Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información. La información que suministren los clientes debe ser verídica para la realización del ingreso.
Datos de prueba
Victimas Heridos Vehículos implicados
1 1 5
10 50 30
Resultado esperado Muestra en un mapa las ubicaciones de los eventos que cumplen con los criterios de consulta, resaltados con un icono representativo
125
Poscondiciones Realiza la consulta con éxito
Resultado Obtenido Muestra en un mapa las ubicaciones de los eventos que cumplen con los criterios de consulta, resaltados con un icono representativo
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
Victimas Entero NA Obligatorio SI SI NO 1 129 "#$%&/()?¡
Heridos Entero NA Obligatorio SI NO SI 1 257 !"#$%&/()=?¡
Vehículos implicados
Entero NA Obligatorio Si 1 513 !"#$%&/()=?¡
Resultado esperado
Mensaje de error
Mensaje de error
Ingreso al sistema
Mensaje de error
Resultado Obtenido
Flujo Básico CU010
Tabla 63. Especificación Pruebas CU010
Nombre caso de uso: Ver detalle de accidente.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Visualizar la información en detalle de un accidente.
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información.
Datos de prueba
Id de accidentes
1
10
Resultado esperado Despliegue de los detalles del accidente : imagen, dirección, intensidad, victimas, heridos, vehículos implicados, fecha y hora descripción, tipo e información geográfica
Poscondiciones Se observaran los detalles de la ubicación del accidente
Resultado Obtenido Despliegue de los detalles del accidente : imagen, dirección, intensidad, victimas, heridos,
126
vehículos implicados, fecha y hora descripción, tipo e información geográfica
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
Victimas Entero NA Obligatorio SI NA NA
Resultado esperado
ve detalle de accidente
NA NA
Resultado Obtenido
Flujo Básico CU011
Tabla 64. Especificación Pruebas CU011
Nombre caso de uso: Identificar accidente.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite identificar los accidentes en un área seleccionada por el usuario en un mapa.
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información.
Datos de prueba
Coordenada
-74.0833,4.6
-75.0833,4.9
Resultado esperado Resalta los accidentes cuyas coordenadas se encuentren en esa área resaltada
Poscondiciones Se visualiza los accidentes según coordenadas
Resultado Obtenido Resalta los accidentes cuyas coordenadas se encuentren en esa área resaltada
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
Coordenada Coordenada NA Obligatorio SI NA NA
127
Resultado esperado Identifica accidente NA NA
Resultado Obtenido
Flujo Básico CU012
Tabla 65. Especificación Pruebas CU012
Nombre caso de uso: Obtener ubicación.
Autor Raul Castro
Fecha 16/10/2014
Descripción: Permite obtener la ubicación del dispositivo móvil utilizando a la información del GPS o de un punto seleccionado por el usuario y transformarlo al sistema.
Actores: Usuario
Precondiciones: Los usuarios deben estar registrados en el sistema y contar con equipos para acceso al sistema de información.
Datos de prueba
Coordenada
-74.0833,4.6
-75.0833,4.9
Resultado esperado Se obtiene una coordenada de posicionamiento geográfico
Poscondiciones Proyección de una coordenada capturada en el sistema de referencia geográfica
Resultado Obtenido Se obtiene una coordenada de posicionamiento geográfico
Validación de datos obligatorios
Campo Tipo Longitud Validación Obligatoriedad Longitud Tipo
Coordenada Coordenada NA Obligatorio SI NA NA
Resultado esperado Identifica accidente NA NA
Resultado Obtenido
128
8.4. RECURSOS
8.3.1 Presupuesto
Concepto Detalle Costo
unitario Costo total
Infraestructura
Uso por 3 meses Servidor de Aplicaciones y de BD (Virtualización) de características :
1 procesador
2 Gb. de memoria RAM.
100 Gb. de espacio de almacenamiento
1 IP Publica con Dominio .ORG Con el proveedor Dominio Amigo Punto Com
$577.000 $1´577.000
Compra Dispositivo Móvil Teléfono inteligente.
$1´000.000
Talento Humano(Implementación del CV del
Proyecto)
Análisis10 días $1´304.000
$6´913.000 Diseño 10 días $1´000.000
Desarrollo 30 días $2´396.000
Pruebas 8 días $2´213.000
Servicios de comunicaciones y salida en vivo de la solución
2 planes de datos de Internet Móvil 3G durante dos meses con el operador Claro.
$280.000
$649.000 Hosting de la solución con el proveedor Dominio Amigo Punto Com
$ 369.000
Licenciamiento Implementación de Tecnologías Libres como Java (de costo bajo o inexistente)
$ 0 $ 0
TOTAL $9´139.000 Fuente: Los autores
top related