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

GOOGLE

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