Tesis de Grado
Descrição do Produto
UNIVERSIDAD MAYOR DE SAN ANDRÉS FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMATICA
TESIS DE GRADO “PLATAFORMA DE GEOLOCALIZACIÓN DE PERSONAS MEDIANTE DISPOSITIVO MÓVIL” PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMATICA MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
POSTULANTE: FABIO RODOLFO GUACHALLA BLANCO TUTOR METODOLOGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO ASESOR: LIC. MARCELO GERMAN ARUQUIPA CHAMBI LA PAZ – BOLIVIA 2015
DEDICATORIA Esta tesis se la dedico a mis padres quienes me han apoyado para poder llegar a esta instancia de mis estudios, ya que ellos siempre han estado presentes
para
psicológicamente.
apoyarme
moralmente
y
AGRADECIMIENTO Primeramente doy gracias a Dios por permitirme llegar a ser un profesional, gracias a mi familia quienes me apoyan y soportan en cada momento de mi vida, gracias a cada Docente que fue parte del proceso de mi formación académica. gracias a mis amigos que me ayudaron a superar los obstáculos que se presentaron.
CONTENIDO RESUMEN SUMMARY CAPÍTULO I
1
1. MARCO INTRODUCTORIO
2
1.1. INTRODUCCIÓN
2
1.2. ANTECEDENTES
3
1.3. PLANTEAMIENTO DEL PROBLEMA
5
1.3.1. PROBLEMA CENTRAL
5
1.3.2. PROBLEMAS SECUNDARIOS
6
1.4. DEFINICIÓN DE OBJETIVOS
6
1.4.1. OBJETIVO GENERAL
6
1.4.2. OBJETIVOS ESPECÍFICOS
6
1.5. HIPÓTESIS
7
1.5.1. OPERACIONALIZACIÓN DE VARIABLES
7
1.6. JUSTIFICACIÓN
7
1.6.1. JUSTIFICACIÓN ECONÓMICA
7
1.6.2. JUSTIFICACIÓN SOCIAL
7
1.6.3. JUSTIFICACIÓN CIENTÍFICA
8
1.7. ALCANCES Y LÍMITES
8
1.7.1. ALCANCES
8
1.7.2. LÍMITES
8
1.8. APORTES
9
1.8.1. PRÁCTICO
9
1.8.2. TEÓRICO
9
1.9. METODOLOGÍA
9
1.9.1. TIPO DE INVESTIGACIÓN
9
CAPÍTULO II
12
2. MARCO TEÓRICO
13
2.1. INTRODUCCIÓN
13
2.2. INGENIERÍA WEB
13
2.2.1. ARQUITECTURA SOA
13
2.3. CONSUMO DE SERVICIOS
15
2.3.1. SERVICIOS WEB
16
2.4. REST
2.5. INGENIERÍA MÓVIL
16 18
2.5.1.. METODOLOGÍA DE DESARROLLO MOBILED
18
2.5.2. ELEMENTOS
21
2.6. GEOLOCALIZACIÓN 2.6.1. API GOOGLE MAPS
22
22
2.7. MODELO VISTA CONTROLADOR (MVC)
23
2.7.1. DESCRIPCIÓN DEL PATRÓN
24
2.7.2. USO EN APLICACIONES WEB
26
2.8. PHONEGAP
2.9. EMULADOR RIPPLE 2.10. CAPACIDADES DE RIPPLE
27
29
29
CAPÍTULO III
31
3. MARCO APLICATIVO
32
3.1. INTRODUCCIÓN
32
3.2. EXPLORACIÓN Y CATEGORIZACIÓN
32
3.2.1. DEFINICIÓN DE LOS GRUPOS DE INTERÉS
33
3.2.2. ACTORES
33
3.2.3. ROLES Y TAREAS
33
3.2.4. COLECCIÓN DE REQUERIMIENTOS
34
3.2.5. CATEGORIZACIÓN DE REQUERIMIENTOS
34
3.2.6. ARQUITECTURA PROTOTIPO
35
3.3. INICIALIZACIÓN
35
3.3.1. ENTORNO DE TRABAJO
36
3.3.2. LISTA DE FUNCIONALIDADES
36
3.3.3. PLANIFICACIÓN DE FASES
37
3.3.4. ITERACIONES
37
3.3.5. PLANIFICACIÓN DEL SERVICIO WEB RESTful
39
3.3.6. DISEÑO E IMPLEMENTACIÓN DE LA BASE DE DATOS
40
3.3.7. DISEÑO DE LA INTERFAZ DEL ADMINISTRADOR
41
3.3.8. DISEÑO DE LA INTERFAZ DEL USUARIO
43
3.4. PRODUCTIZACIÓN E IMPLEMENTACIÓN DE WEB SERVICE
41
3.4.1. IMPLEMENTACIÓN DE DE LOS WEB SERVICES
44
3.4.1.1 PROCESAR LAS RUTAS DE LOS RECURSOS
45
3.4.1.2. MANEJADORES DE SALIDA EN LA VISTA
46
3.4.1.3. MANEJO DE EXCEPCIONES EN LA API 3.4.1.4. MODELO DE DATOS DE USUARIOS
3.4.1.5. MODELO DE DATOS PARA INTEGRANTES
47
49
54
3.4.2. IMPLEMENTACIÓN APLICACIÓN MÓVIL
57
3.4.2.1. OBTENER LA UBICACIÓN ACTUAL DEL USUARIO
58
3.4.3. WORKSHOP DE POST ITERACIÓN
60
3.4.3.1. TEST DE ACEPTACIÓN
61
3.5. FASE DE ESTABILIZACIÓN
62
3.5.1. WORKSHOP DE POST ITERACIÓN
62
3.5.2. TEST DE ACEPTACIÓN
63
3.6. FASE DE PRUEBAS
63
3.6.1. PLAN DE PRUEBAS
64
3.6.2. PRUEBAS DE ACEPTACIÓN POR ITERACIÓN
64
CAPÍTULO IV
68
4. PRUEBA DE HIPÓTESIS
69
4.1. INTRODUCCIÓN
69
4.2. EVALUACIÓN DE LOS CASOS DE PRUEBA
69
4.3. PRUEBA DE HIPÓTESIS
69
4.3.1. DEFINICIÓN DE LA HIPÓTESIS
70
4.3.2. EVALUACIÓN DE RESULTADOS
70
4.3.3. DETERMINACIÓN DE LA REGIÓN CRÍTICA
71
4.3.4. CÁLCULO ESTADÍSTICO DE LA PRUEBA
72
4.3.5. TOMA DECISIÓN
72
CAPÍTULO V
74
5. CONCLUSIONES Y RECOMENDACIONES
75
5.1. CONCLUSIONES
75
5.2. MEJORAR TRABAJO
76
BIBLIOGRAFÍA
77
ANEXOS
79
ANEXO A
80
TABLA DE DISTRIBUCIÓN NORMAL
80
DOCUMENTACIÓN
81
ÍNDICE DE FIGURAS FIGURA 2.1. COMPONENTES DE LA ARQUITECTURA SOA
15
FIGURA 2.2. CICLO DE DESARROLLO DE MOBILED
19
FIGURA 2.3. DIAGRAMA MVC
24
FIGURA 2.4. DESARROLLO DE APLICACIONES BASADOS EN PHONEGAP
27
FIGURA 2.5. PHONEGAP BUILD
28
FIGURA 3.1. ARQUITECTURA DEL PROTOTIPO
35
FIGURA 3.2. ESQUEMA DE DESARROLLO DEL SISTEMA
37
FIGURA 3.3. MODELO RELACIONAL
40
FIGURA 3.4. INICIO DE SESIÓN
41
FIGURA 3.5. CRUD DE USUARIOS
41
FIGURA 3.6. UBICACIÓN DE USUARIOS
42
FIGURA 3.7. RASTREO DE UN USUARIO
42
FIGURA 3.8. REGISTRO EN LA APLICACIÓN
43
FIGURA 3.9. INTERFAZ MANEJO DE USUARIO
44
FIGURA 3.10. ESTRUCTURA DEL INDEX.PHP
46
FIGURA 3.11. FRAGMENTO DE EXCEPCIÓN INDEX.PHP
48
FIGURA 3.12. CLASE USUARIO
50
FIGURA 3.13. DIAGRAMA DE PROCESAMIENTO
51
FIGURA 3.14. INVOCACIÓN DE REGISTRO/LOGIN
52
FIGURA 4.1. REGIÓN CRÍTICA PARA LA HIPÓTESIS
71
FIGURA 4.2. DISTRIBUCIÓN DE Z PARA LA TOMA DE DECISIÓN
72
ÍNDICE DE TABLAS TABLA 3.1. ROLES Y TAREAS DE LOS USUARIOS
33
TABLA 3.2. LISTA DE TAREAS
36
TABLA 3.3. DESCRIPCIÓN DE LAS ITERACIONES
37
TABLA 3.4. ESTIMACIÓN DE ESFUERZOS DE PROCESOS PRINCIPALES
39
TABLA 3.5. RECURSOS DE REGISTROS Y PROCESO DE LOGIN
49
TABLA 3.6. OPERACIONES SOBRE LOS RECURSOS
55
TABLA 3.7. TEST DE ACEPTACIÓN DE PRODUCCIÓN
61
TABLA 3.8. TEST DE ACEPTACIÓN DE ESTABILIZACIÓN
63
TABLA 3.9. RESULTADOS ITERACIÓN 1
65
TABLA 3.10. RESULTADOS ITERACIÓN 2
65
TABLA 3.11. RESULTADOS ITERACIÓN 3
66
TABLA 3.12. RESULTADOS ITERACIÓN 4
66
TABLA 3.13. RESULTADOS ITERACIÓN 5
67
TABLA 3.14. RESUMEN DE LOS RESULTADOS DE ITERACIONES
67
TABLA 4.1. RESULTADO DE TABLA DE LA FUNCIÓN DE DISTRIBUCIÓN NORMAL
71
RESUMEN Las nuevas tecnologías y la sociedad de la información están creando nuevas vías de comunicación social, en nuestro medio se hace evidente el crecimiento del uso de terminales móviles facilitando el acceso a Internet, produciendo sociedades inteligentes. El presente trabajo tiene como objetivo transformar esa necesidad emergente en un marco teórico y aplicativo que convergen como una base para el desarrollo de un sistema cuyo proceso principal es la geolocalización de personas por medio del GPS de su dispositivo móvil. La construcción de esta aplicación fue posible con el uso de herramientas tales como: PhoneGap, para la creación de la interface, SOA para el modelado de los servicios usando RESTful para la integración de la aplicación con el SOA de ésta a partir de marcadores propios de la librería. Los resultados obtenidos a partir de las pruebas de la aceptación, nos indican que es posible la ampliación de los Web Service, y para varias aplicaciones con la misma ideología. Palabras clave: Web Service, RESTful, SOA, geolocalización, GPS
SUMMARY New technologies and the information society are creating new channels of social communication, in our growth in the use of mobile terminals is evident facilitating access to Internet, producing intelligent societies. This paper aims to transform the emerging need for a theoretical and applicative framework converging as a basis for the development of a system whose primary process is the geolocation of people through the GPS of your mobile device. The construction of this implementation was possible with the use of tools such as PhoneGap, for creating the interface, for SOA modeling using RESTful services for integrating the SOA application thereof from own markers the library. The results from the acceptance tests, we show that it is possible to expand the Web Service, and for multiple applications with the same ideology. Keywords: Web Service, RESTful SOA, geolocation, GPS
CAPÍTULO I 1
1. MARCO INTRODUCTORIO 1.1. INTRODUCCIÓN Las nuevas tecnologías y la sociedad de la información están creando nuevas vías de comunicación social, en nuestro medio se hace evidente el crecimiento del uso de terminales móviles facilitando el acceso a Internet, produciendo sociedades inteligentes. En la actualidad la geolocalización o georreferenciación, que es utilizado como un proceso en el desarrollo de Sistemas de Información Geográfica (SIG), se ha convertido en una poderosa herramienta para obtener ubicaciones según su latitud y longitud. Tal utilidad puede ser utilizada para obtener datos sobre la ubicación de personas por medio del GPS1 de su dispositivo móvil. Uno de los servicios que causó un salto cualitativo en cuanto a georreferenciación es Google Earth, ya que se ha democratizado el uso de información georreferenciada, puesto que puede ser utilizado sobre todo los contenidos de tipo social presentes en la actualidad. Aún en la actualidad algunos de estos servicios son poco exactos al momento de georreferenciar una ubicación, además de que son de difícil uso. Google Maps como referencia ha mostrado un registro moroso de sitios y lugares, además de inexactitud de ubicaciones. El presente trabajo tiene como objetivo transformar esa necesidad emergente en un marco teórico y aplicativo que convergen como una base para el desarrollo de un sistema cuyo
1
GPS, Global Position System o Sistema de Posicionamiento Global q ue permite determinar en todo el mundo la posición de un objeto (una persona, un vehículo, un dispositivo móvil u otros)
2
proceso principal es la geolocalización2 de personas por medio del GPS de su dispositivo móvil. 1.2. ANTECEDENTES El uso de los teléfonos inteligentes, avanza exponencialmente en nuestro país. De acuerdo con datos de la Autoridad de Regulación y Fiscalización de Telecomunicaciones y Transportes (ATT), el acceso a internet a través de terminales móviles tuvo un crecimiento de 133%. El director ejecutivo de la ATT, informó que la penetración de este servicio llega a 10,7 millones de habitantes. De los cuales 4,9 millones de conexiones a internet que existen en el país, 4,8 millones se realizan a través de dispositivos móviles (2G, 3G y 4G, dongles y terminales), 169.126 a usuarios con tecnologías alámbricas y 11.061 a usuarios inalámbricos. (Vasquez, 2015). Desde la aparición del Canadian Geographical Information System (CGIS) en 1962 hasta la actualidad se han ido implementando numerosas aplicaciones de los SIG en los más variados ámbitos, por lo que ha dejado de ser un campo de geógrafos y planificadores y se ha convertido en una herramienta cuya facilidad de uso ha extendido y democratizado esta tarea fuera del ámbito técnico existente hasta ahora (Chang, 2010). El área en cuanto a servicios referentes a georreferenciación ha ido en crecimiento con constantes avances para mejorar los tiempos de respuesta al usuario. Una de estas empresas es Foursquare que es una red social con más de 2.7 millones de usuarios, una aplicación multiplataforma excepto la aplicación nativa para iPad y cuenta con su propia API3. 2
E s un término nuevo surgido con el avance tecnológico que da a entender por, ubicación satelital de un objeto o persona que transmita coordenadas de su posicionamiento. 3
Application Programming Interface es el conjunto de funciones y procedimientos.
3
Google Maps de la empresa Google, es el SIG que más usuarios tiene, ya que cuenta con información mundial de fácil acceso por su documentación y servicio de soporte, pero cuenta con imprecisiones y retraso dependiendo al ancho de banda y al hardware del ordenador. Google Maps tiene documentación aún en fase de desarrollo, es por eso que varias empresas van colaborando al proyecto Open Street Maps como por ejemplo: Apple, Microsoft (Mapas Bing), Yahoo (Mapas Yahoo), Foursquare que recientemente cambió de Google Maps a Open Street Maps en su versión de escritorio, ya que su versión para móviles aún sigue usando Google Maps. (Duclos, 2010) Del mismo modo, la masificación y evolución constante de la georreferenciación se ha visto impulsada por el uso mashups (aplicaciones web híbridas) en sitios Web 2.0, permitiendo la localización de contenidos digitales (vídeo, noticias, modelados 3D) en cartografía digital, dentro de lo que se ha venido a llamar la Información Geográfica Voluntaria. Tesis/Proyectos Nacionales “ Herramienta Metodológica para el Desarrollo de Aplicaciones Web Móvil ” de Salgueiro (2012) propone una herramienta metodológica para el desarrollo de software web móvil, que permita obtener software de altas prestaciones, calidad y evitar que provocan insatisfacción en los usuarios finales, que es la causa fundamental para que proyectos con buenos criterios y perspectivas a futuro no fracasen y sean desechadas incluso antes de su implementación y uso. “Sistema de Ubicación o Localización Móvil Basado en Dispositivos Móviles” de Guarachi (2012) realiza el desarrollo de un sistema de ubicación, capaz de explotar los 4
servicios de localización en combinación con las tecnologías usadas para el desarrollo de aplicaciones móviles, tecnologías y servicios web. “Software Móvil de Geolocalización para la Banca en la Ciudad de La Paz” de Pérez (2014) ofrece un Sistema cuyo proceso principal se basa en la geolocalización de servicios que nos brindan las entidades bancarias, que permita al usuario ubicar a la sucursal de la entidad requerida más próxima a su ubicación trazando una ruta. Tesis/Proyectos Internacionales “Plataforma de Geolocalización de Centros de Salud con Tecnología Móvil Implementando el Protocolo de Comunicación HL7” de Soto (2009) presenta una plataforma de geolocalización encargada de localizar centros de salud. La plataforma incluye: el protocolo de comunicaciones Health Level Seven (HL7), tecnología de telefonía móvil y sistemas de posicionamiento global (GPS). Se construyó una Arquitectura Orientada a Servicios (SOA) estructurada en tres capas: presentación, lógica de negocios y repositorio de data geográfica. 1.3. PLANTEAMIENTO DEL PROBLEMA Mediante el análisis y la respectiva observación de antecedentes, y la importancia de la seguridad ciudadana, se determinó la necesidad de implementar una plataforma de geolocalización que permita saber la ubicación de un grupo de personas. 1.3.1. PROBLEMA CENTRAL Los datos sobre las ubicaciones de un grupo personas como ser una familia, son desconocidas, en lo cual hay bajo control familiar ya que en nuestro medio actualmente existe secuestros, asaltos y otros, lo cual es preocupante para los padres de familia. 5
Planteándose así un problema central de la investigación que es: ¿Cómo obtener información confiable sobre la ubicación de una persona? 1.3.2. PROBLEMAS SECUNDARIOS ● Bajo Control Familiar, actualmente existen pocas aplicaciones que nos ayudan a tener información de nuestra familia. Y estas aplicaciones son de paga. ● Desconocimiento de Lugares , las aplicaciones que nos ofrecen el reconocimiento de lugares están en desarrollo para países de primer mundo, por lo tanto en nuestro país tiene poco acceso a este servicio. ● Trayectoria seguida, la trayectoria que sigue el usuario muchas veces el dispositivo móvil no es almacenado, o en otros casos solo se activa cuando el dispositivo móvil se encuentra denunciado como robado. 1.4. DEFINICIÓN DE OBJETIVOS 1.4.1. OBJETIVO GENERAL Desarrollar una plataforma de geolocalización que brinde información confiable de la ubicación de una persona. 1.4.2.OBJETIVOS ESPECÍFICOS ● Automatizar la ubicación de una persona específica. ● Desarrollar de una plataforma web orientado a servicios. ● Integrar a la aplicación con Google Maps y Open Street Maps. ● Mostrar la trayectoria de una persona. ● Implementar servicio de alerta cuando se encuentre en una zona peligrosa.
6
1.5. HIPÓTESIS H : “La plataforma de geolocalización como proceso de un sistema de información geográfica permite recibir información con un 90% de confiabilidad sobre la ubicación de una persona mediante el GPS de su dispositivo móvil”. 1.5.1. OPERACIONALIZACIÓN DE VARIABLES VARIABLE INDEPENDIENTE Información del 90% confiable sobre ubicaciones de las personas dentro de un mapa mediante el GPS. VARIABLE DEPENDIENTE Mediante el uso de un dispositivo móvil o web se podrá ubicar la posición de la persona seleccionada VARIABLE MODERANTE La geolocalización como proceso de un sistema de información geográfica. 1.6. JUSTIFICACIÓN 1.6.1. JUSTIFICACIÓN ECONÓMICA El presente trabajo se justifica económicamente ya que el costo económico en cuanto al sistema se refiere solamente al mantenimiento, puesto que las herramientas utilizadas para el desarrollo e implementación de la plataforma es Open Source4 y basado en un modelo de Arquitectura Orientada a Servicios (SOA). 1.6.2. JUSTIFICACIÓN SOCIAL La necesidad de implementar esta plataforma se centra en crear un servicio para la seguridad ciudadana por parte del usuario al momento de buscar a una persona dando la ubicación actual, teniendo a la mano la información necesaria 4
E s la expresión con la que se conoce al software o hardware distribuido y desarrollado libremente.
7
1.6.3. JUSTIFICACIÓN CIENTÍFICA La presente investigación se desarrolló a partir del framework de Phonegap JS, que permite desarrollar aplicaciones para diferentes plataformas móviles (Android, IOs, Windows Phone y otros), basándose en tecnologías web (HTML, CSS, JavaScript), con el fin de adaptar la compatibilidad con la mayor cantidad de navegadores web y dispositivos móviles. 1.7. ALCANCES Y LÍMITES 1.7.1. ALCANCES ● La plataforma ofrece servicios de geolocalización. ● La plataforma de geolocalización se desarrollará para dispositivos móviles y web, con pruebas en el sistema operativo Android y Navegador Chrome. ● La interacción de la plataforma con los mapas de Google Maps y Open Street Maps brindará información confiable y actualizada desde cualquier dispositivo móvil y web. ● Mostrar la ubicación de las personas en tiempo real. ● Notificar a la familia si se encuentra en algún peligro. 1.7.2. LÍMITES ● Los usuarios y las personas a ser ubicadas tendrán que tener acceso a Internet. ● Debido a que la información a ser manejada es privado, no tendrá conexión a redes sociales. ● La plataforma ofrece servicios de geolocalización para dispositivos móviles
8
1.8. APORTES 1.8.1. PRÁCTICO La plataforma será un gran aporte a la sociedad, debido a que es una herramienta para la seguridad ciudadana y a reducir peligros que aterra a nuestra ciudad. Creación de servicio de geolocalización usando método SOA, el cual es flexible que permite la reutilización de las tecnologías existentes. 1.8.2. TEÓRICO La presente investigación permitirá ver de otro modo la comunicación y de seguridad ciudadana, viendo a los antecedentes para poder explotar las tecnologías de otras formas más innovadoras en el futuro. Esto debido a los trabajos realizados con anterioridad con estas tecnologías aún se usan de manera incorrecta. 1.9. METODOLOGÍA 1.9.1. TIPO DE INVESTIGACIÓN La metodología que se utilizara para la presente tesis es el método científico esto debido a las etapas que esta presenta y que son necesarias como: ● Observación ● Formulación de hipótesis ● Experimentación ● Emisión de conclusiones Se procederá a asignar pasos bien especificados sobre la realización de cada uno de los procesos, documentando cada avance y cada proceso para que forme parte del manual que se presentará al final del proceso e implementación del software. Es por ello que se requiere hacer un tipo de estudio aplicado y tecnológico basado en pruebas del objeto de estudio. 9
MÉTODO APLICATIVO Las características requeridas para el desarrollo de la plataforma se adaptan a metodologías ágiles, aunque la metodología elegida es MobileD para la parte móvil, que viene siendo una mezcla de muchas técnicas, que han apoyado en otras soluciones.Se trata de método basado en soluciones conocidas y consolidadas: Extreme Programming (XP), Crystal Methodologies y Rational Unified Process (RUP), XP para las prácticas de desarrollo, Crystal para escalar los métodos y RUP como base en el diseño del ciclo de vida. (Ramírez, 2013) La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura. MobileD al combinar los beneficios de las metodologías los beneficios de las metodologías XP, Crystal y RUP proporciona las siguientes razones para ser la metodología seleccionada en el desarrollo de software móvil: ● Está diseñada para el desarrollo de aplicaciones móviles. ● Es una metodología ágil con ciclos de desarrollo cortos. ● Facilidad para detectar y resolver tempranamente problemas técnicos. ● Se basa en el desarrollo basado en pruebas que es una de las mejores formas de asegurar la calidad. ● Se logra mejores diseños al basarse en el desarrollo basado en pruebas ● Tiene un enfoque centrado en la satisfacción del usuario final, permitiendo mejorar el producto al realizar iteraciones cortas. 10
El gran beneficio de SOA es la agilidad que proporciona a las organizaciones que la usan. Las características propias de SOA permite a las organizaciones la capacidad de controlar un problema de forma general, permitiendo una respuesta más rápida y eficaz y por tanto adaptarse de la mejor forma a los cambios. Los beneficios que puede obtener una organización que adopte SOA son: ● Mejora en los tiempos de realización de cambios en procesos ● Facilidad para evolucionar a modelos de negocios basados en tercerización ● Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio ● Facilidad para la integración de tecnologías disímiles ● Aplicaciones flexibles: la orientación a servicios permite desarrollar aplicaciones con independencia de las plataformas y lenguajes de programación que realizan los procesos ● Reducción de costes: el coste de ampliar o crear nuevos servicios se reduce considerablemente tanto en aplicaciones nuevas como ya existentes ● Riesgo de migración: al adaptar SOA a partir de una tecnología existente se siguen utilizando los componentes existentes, por lo que se reduce el riesgo de introducir fallos 11
CAPÍTULO II
12
2. MARCO TEÓRICO 2.1. INTRODUCCIÓN Este capítulo está conformado por la explicación de los modelos aplicados en esta tesis. Es decir: requerimientos, análisis y diseño con MobileD y modelado de SOA 2.2. INGENIERIA WEB La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web.
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía. Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio. (Gaedke, 2014). 2.2.1. ARQUITECTURA SOA La Arquitectura Orientada a Servicios (SOA), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite además, la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, y que a su vez brindan de una forma bien definida la exposición 13
e invocación de servicios (de forma común, pero no exclusiva de los servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. Los conceptos de software futurista probablemente contribuirán a otra capa de los entornos computacionales complejos, un demandante de recursos para el apoyo de presupuestos. La Arquitectura Orientada a Servicios ayuda a resolver los problemas de la interoperabilidad, reutilización, y otros problemas asociados con este paradigma. La visión de SOA también se ocupa de los retos de software fuertemente acoplados y clama por una arquitectura que se basa en el acoplamiento de los “assets”. SOA ayuda a la reducción del tiempo de salida al mercado y la agilidad del negocio. De hecho, la lista de ventajas sigue creciendo. El modelado orientado a los servicios proporciona mecanismo que nos permite concebir productos de software que hemos ido construyendo, adquiriendo, y a la integración en las últimas décadas como un servicio orientado a componentes. Es importante que deben de ser tratadas por igual la parte de análisis, diseño, arquitectura y deben ser reconocidos como servicios. (Bell, 2008). SOA ofrece la posibilidad de llamar a un componente de negocios desarrollado en una plataforma X, desde una aplicación corriendo en cualquier plataforma, en cualquier parte del mundo, utilizando para ello protocolos estándar como REST, XML y HTTP. Los sistemas orientados a servicios, son diseñados con un bajo nivel de acoplamiento que facilita la implementación de cambios y estos servicios pueden ser desarrollados en cualquier lenguaje corriendo en diferentes plataformas. 14
Los servicios son utilizados por una aplicación cliente que les envía mensajes respetando un determinado contrato de servicios, pero internamente estos servicios utilizan los conceptos de la Programación Orientada a Objetos (OOP).
Figura 2.1 Componentes de la Arquitectura SOA Fuente: SEUR, 2012 2.3. CONSUMOS DE SERVICIOS ¿Una vez que los servicios están disponibles en la plataforma SOA, que se hace con ellos? Existen 2 escenarios de uso clave: 1. Consumir los servicios desde una aplicación cliente. Al consumir, nos referimos a utilizar el servicio, es decir invocar el servicio en cualquier otra aplicación.
15
2. Composición de los servicios en los procesos de negocio. El otro método más popular para el uso de los servicios es en los procesos de negocio, por la orquestación de los servicios. Esto consiste esencialmente en la orquestación "encadenar" los servicios disponibles en el dominio para llevar a cabo una función de negocios o procesos. Este es un enfoque de programación relativamente de alto nivel, sus construcciones de flujo de programación pueden definir gráficamente el proceso, tanto como el dibujo de un diagrama de flujo o un diagrama de actividad con UML. 2.3.1. SERVICIOS WEB Los Servicios web son una innovación en tecnología de la World Wide Web. Un servicio web es un programa de aplicación basado en la web con una interfaz definida que acepta y procesa las solicitudes y devuelve una respuesta al solicitante. Un servicio web no está directamente ligado a una aplicación específica. En algunos aspectos, un servicio web es similar a un modelo clienteservidor, donde el servicio web es un servidor. Los servicios web se basan en un conjunto de estándares de comunicación, como son XML para la representación de datos, SOAP (Simple Object Access Protocol) para el intercambio de datos y el lenguaje WSDL (Web Services Description Language) para describir las funcionalidades de un servicio web. 2.4. REST REST, REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP. REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y
16
convencional que otras alternativas que se han usado en los últimos diez años como SOAP y XMLRPC. REST se definió en el 2000 por Roy Fielding, coautor principal también de la especificación HTTP. Podríamos considerar REST como un framework para construir aplicaciones web respetando HTTP. Por lo tanto REST es el tipo de arquitectura más natural y estándar para crear APIs para servicios orientados a Internet. Existen tres niveles de calidad a la hora de aplicar REST en el desarrollo de una aplicación web y más concretamente una API que se recogen en un modelo llamado Richardson Maturity Model en honor al tipo que lo estableció, Leonard Richardson padre de la arquitectura orientada a recursos. Estos niveles son: 1. Uso correcto de URIs 2. Uso correcto de HTTP. 3. Implementar Hypermedia. Además de estas tres reglas, nunca se debe guardar estado en el servidor, toda la información que se requiere para mostrar la información que se solicita debe estar en la consulta por parte del cliente. Al no guardar estado, REST nos da mucho juego, ya que podemos escalar mejor sin tener que preocuparnos de temas como el almacenamiento de variables de sesión e incluso, podemos jugar con distintas tecnologías para servir determinadas partes o recursos de una misma API. 17
2.5. INGENIERÍA MÓVIL Cuando se piensa desarrollar una aplicación para un dispositivo móvil en cualquiera de las plataformas y para cualquier entorno es de vital importancia reconocer y establecer condiciones que garanticen la pertinencia, la calidad, la seguridad, la eficiencia y el rendimiento del programa que se desea construir y utilizar por medio del dispositivo móvil (Fling, 2009). Por tal razón es de suma importancia seguir en forma clara las etapas generales del ciclo de vida del software (definición y análisis de requisitos, diseño, desarrollo, pruebas, y mantenimiento), pero teniendo muy presentes las grandes diferencias que existen entre el desarrollo de una aplicación para ejecutar en un PC de escritorio y el de una aplicación para ejecutar en un dispositivo móvil. Cada etapa debe ir enfocada a establecer muy claramente qué es lo que se busca en una pieza de software para un dispositivo móvil, que garantice la movilidad, el fácil uso y el aprovechamiento de los limitados recursos de memoria. 2.5.1. METODOLOGÍA DE DESARROLLO MOBILE D El método MobileD se desarrolló junto con un proyecto finlandés en el 2004. Fue realizado, principalmente, por investigadores de la VTT (Instituto de Investigación Finlandés) y, a pesar de que es un método antiguo, sigue en vigor. El objetivo es conseguir ciclos de desarrollos muy rápidos en equipos muy pequeños trabajando en un mismo espacio físico. Según este método, trabajando de esa manera se deben conseguir productos totalmente funcionales en menos de diez semanas. Se trata de método basado en soluciones conocidas y consolidadas: Extreme Programming (XP), Crystal Methodologies y Rational Unified Process (RUP), XP para las prácticas de
18
desarrollo, Crystal para escalar los métodos y RUP como base en el diseño del ciclo de vida.
Figura 2.2 Ciclo de Desarrollo de MobileD Fuente: Métodos para el Desarrollo de Aplicaciones Móviles (Ramírez, 2013) Cada fase (excepto la inicial) tiene siempre un día de planificación y otro de entrega. Las fases son: ● Exploración. La fase de exploración, siendo ligeramente diferente del resto del proceso de producción, se dedica al establecimiento de un plan de proyecto y los conceptos básicos. por lo tanto, se puede separar del ciclo principal de desarrollo (aunque no debería obviarse). Los autores de la metodología ponen además especial atención a la participación de los clientes en esta fase. ● Inicialización. Durante esta fase, se preparan e identifican todos los recursos necesarios. Se preparan los planes para las siguientes fases y se establece el entorno técnico. Los autores de MobileD afirman que su contribución al desarrollo ágil se 19
centra fundamentalmente en esta fase, en la investigación de la línea arquitectónica. Esta acción se lleva a cabo durante el día de planificación. Los desarrolladores analizan el conocimiento y los patrones arquitectónicos utilizados en la empresa (extraídos de proyectos anteriores) y los relacionan con el proyecto actual. Se agregan las observaciones, se identifican similitudes y se extraen soluciones viables para su aplicación en el proyecto. Finalmente, la metodología también contempla algunas funcionalidades nucleares que se desarrollan en esta fase, durante el día de trabajo. ● Productización o fase de producto. Se repite la programación de tres días (planificación trabajoliberación) se repite iterativamente hasta implementar todas las funcionalidades. Primero se planifica la iteración de trabajo en términos de requisitos y tareas a realizar. Se preparan las pruebas de la iteración de antemano (de ahí el nombre de esta técnica de Test Driven Development, TDD). Las tareas se llevarán a cabo durante el día de trabajo, Durante el último día se lleva a cabo la integración del sistema seguida de las pruebas de aceptación. ● Fase de estabilización. Se llevan a cabo las últimas acciones de integración para asegurar que el sistema completo funciona correctamente. Esta será la fase más importante en los proyecto multiequipo con diferentes subsistemas desarrollados por equipos distintos. En esta fase, los desarrolladores realizarán tareas similares a las que debían desarrollar en la fase de "productización", aunque en este caso todo el esfuerzo se dirige a la integración del sistema. Adicionalmente se puede considerar en esta fase la producción de documentación. ● Fase de pruebas y reparación. La última fase (prueba y reparación del sistema) tiene como meta la disponibilidad de una versión estable y plenamente funcional del 20
sistema. El producto terminado e integrado se prueba con los requisitos de cliente y se eliminan todos los defectos encontrados. 2.5.2. ELEMENTOS Existen elementos principales involucrados en las diferentes prácticas en el transcurso del ciclo de desarrollo. ● Ajuste y enfoque de fases: Los proyectos se llevan a cabo en iteraciones donde cada una comienza con un día de planificación. ● Línea de arquitectura: Éste enfoque es utilizado junto con los patrones de arquitectura y modelado ágil. ● Desarrollo basado en pruebas: El enfoque de pruebas primero es utilizado junto con casos de prueba automatizadas. ● Integración continua: Las prácticas de Software Configuration Manager (SCM) se aplican a través de múltiples medios. ● Métricas: Pocas métricas se recogen con rigurosidad y se utilizan con fines de mejorar la retroalimentación y el proceso de desarrollo. ● Mejoras en el proceso de software ágil: Talleres de post iteración son utilizados para mejorar continuamente el proceso de desarrollo. ● Enfoque centrado en el usuario: Se hace hincapié en la identificación y el cumplimineto de necesidades del usuario final. Estos elementos son prácticas ya establecidas en metodologías ágiles, con la inclusión de la línea de arquitectura, que se usa para capturar el conocimiento de una organización de soluciones arquitectónicas, tanto de fuentes internas y externas, y usar estas soluciones cuando sea necesario. 21
2.6. GEOLOCALIZACIÓN Geolocalización es un concepto relativamente nuevo, que ha proliferado de unos dos años a esta parte y que hace referencia al conocimiento de la propia ubicación geográfica de modo automático. También denominada georreferenciación, la geolocalización implica el posicionamiento que define la localización de un objeto en un sistema de coordenadas determinado. Este proceso es generalmente empleado por los sistemas de información geográfica, un conjunto organizado de hardware y software, más datos geográficos, que se encuentra diseñado especialmente para capturar, almacenar, manipular y analizar en todas sus posibles formas la información geográfica referenciada, con la clara misión de resolver problemas de gestión y planificación. Existen varias alternativas para conocer esta ubicación, aunque claro, son los dispositivos móviles los que por su portabilidad con nosotros mismos nos permitirán más fácilmente conocer nuestra ubicación y actualizarla a medida que nos vamos movilizando y por tanto, cambiando de ubicación geográfica. 2.6.1. API GOOGLE MAPS Google Maps provee a los desarrolladores un API capaz de aprovechar los datos disponibles a través del servicio, en el seno de las propias aplicaciones, permitiendo a los desarrolladores programar dentro de mapas basándose en un conjunto de librerías y servicios proporcionadas por la API de Google Maps como se menciona a continuación. 2.6.1.1. LIBRERÍA DE DIBUJO La API de Google Maps proporciona un conjunto de clases que permite el dibujo de figuras geométricas como se presentan a continuación: 22
● CÍRCULOS: Google Maps incluye la clases circle que permite trazar círculos en los cuales se puede definir colores, grosores y niveles de opacidad personalizados para el borde del círculo, así como colores y opacidades personalizados para el área que engloba. ● POLILÍNEAS: Google Maps incluye la clase polyline que permite trazar caminos, como la creación de rutas de ciclismo, caminata y otros. Las polilíneas se componen de varias líneas conectadas. Una línea consiste en dos puntos: un punto e partida y un punto de terminal. Estos se componen de coordenadas. ● SERVICIO DE RUTAS: El servicio de rutas de Google Maps proporciona la clase directions Service, que despliega una ruta completamente modificable, a la cual se le debe especificar un origen y destino mediante coordenadas geográficas, las coordenadas geográficas se deben representar en base a pares ordenados de latitud y longitud, además esta ruta se adapta automáticamente a calles y avenidas permitiendo describir rutas dentro de Google Maps. 2.7. MODELO VISTA CONTROLADOR (MVC) El modelo–vista–controlador (MVC) es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la int erfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos ,
23
características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. 2.7.1. DESCRIPCIÓN DEL PATRÓN
Figura 2.3. Diagrama MVC Fuente: W3School, 2015 De manera genérica, los componentes de MVC se podrían definir como sigue: ● El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que
24
sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'. ● El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo'. ● La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida. INTERACCIÓN DE LOS COMPONENTES Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue generalmente es el siguiente: 1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace) 2. El controlador recibe (por parte de los objetos de la interfazvista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a
25
menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. 2.7.2. USO EN APLICACIONES WEB Aunque originalmente MVC fue desarrollado para aplicaciones de escritorio, ha sido ampliamente adoptado como arquitectura para diseñar e implementar aplicaciones web en los principales lenguajes de programación. Se han desarrollado multitud de frameworks, comerciales y no comerciales, que implementan este patrón estos frameworks se diferencian básicamente en la interpretación de cómo las funciones MVC se dividen entre cliente y servidor.
26
Los primeros frameworks MVC para desarrollo web plantean un enfoque de cliente ligero en el que casi todas las funciones, tanto de la vista, el modelo y el controlador recaen en el servidor. En este enfoque, el cliente manda la petición de cualquier hiperenlace o formulario al controlador y después recibe de la vista una página completa y actualizada tanto el modelo como el controlador están completamente alojados en el servidor. Como las tecnologías web han madurado, ahora existen frameworks como JavaScriptMVC, Backbone o jQuery que permiten que ciertos componentes MVC se ejecuten parcial o totalmente en el cliente 2.8. PHONEGAP PhoneGap es un framework para el desarrollo de aplicaciones móviles producido por Nitobi, y comprado posteriormente por Adobe Systems. Principalmente, PhoneGap permite a los programadores desarrollar aplicaciones para dispositivos móviles utilizando herramientas genéricas tales como JavaScript, HTML5 y CSS3.
Figura 2.4. Desarrollo de aplicaciones basados en PhoneGap Fuente: Pixelover, 2012 PhoneGap permite el desarrollo ya sea ejecutando las aplicaciones en nuestro navegador web, sin tener que utilizar un simulador dedicado a esta tarea, y brinda la posibilidad de 27
soportar funciones sobre frameworks como JQuery Mobile, además nos permite acceder a las funcionalidades nativas de los dispositivos móviles utilizando JavaScript. Así podemos desarrollar toda la lógica de nuestra aplicación en JavaScript y utilizar la API de PhoneGap para acceder a las funcionalidades nativas del dispositivo. Para poder compilar el código generado al código nativo para las diferentes plataformas móviles, PhoneGap nos proporciona el servicio PhoneGap Build que permite subir nuestros archivos con código a un servidor que se encarga de compilar nuestro código al código nativo para las diferentes plataformas móviles.
Figura 2.5 PhoneGap Build Fuente: Pixelover, 2012
28
2.9. EMULADOR RIPPLE Ripple es una extensión para Google Chrome que recrea el entorno y sensores de un dispositivo móvil real (iOS, Android y Blackberry) dentro del navegador web. Tiene un sistema avanzado de simulación para probar aplicaciones basadas en PhoneGap y WebWorks de Blackberry. Con este plugin y el soporte HTML5 de Google Chrome es posible simular, con bastante aproximación a la realidad, prácticamente cualquier aplicación basada en tecnologías web, incluso si utiliza eventos o sensores exclusivos del móvil como uso de botones o movimientos del acelerómetro. 2.9.1. CAPACIDADES DE RIPPLE A pesar que Chrome comparte el mismo motor de render (WebKit) que iOS, Android y Blackberry y tiene la posibilidad de mostrar elementos gráficos prácticamente en las mismas condiciones que un equipo móvil, tiene algunas restricciones. Los navegadores carecen de algunos eventos y sensores exclusivos de los dispositivos móviles. Ripple se encarga de simular estas capacidades para acercarse al máximo posible al verdadero entorno móvil algunas de las capacidades que instala en el navegador son: ● Devices: Simula la apariencia, tamaño y resolución de pantalla de múltiples equipos y sistemas operativos móviles. También permite cambiar la orientación del equipo en horizontal o vertical. ● Platforms: Muestra las plataformas y versiones disponibles para emulación: PhoneGap (Apache Cordova), Blackberry Webworks y web móvil. ● Information: Despliega información importante sobre el documento y modo de emulación actual. 29
● Accelerometer: Muestra un dispositivo virtual en 3D que se puede rotar libremente sobre todos sus ejes. Al manipular el dispositivo virtual se envía directamente la información a la aplicación para que reaccione de igual manera, simulando así el movimiento real de un dispositivo. la información detallada se muestra en tiempo real para depurar y comprobar los resultados. Incluye también la opción de simular la acción de “sacudida” o “shake”. ● Geolocation: Permite simular y manipular todos los valores de las coordenadas de geolocalización, desde la latitud y longitud hasta la dirección y velocidad en que se desplaza el móvil. Incluye además un mapa para ubicar gráficamente las coordenadas que se introducen. ● Events: Activa eventos específicos de PhoneGap como deviceReady, que señala el momento en que el dispositivo está listo o backbutton, que se activa cuando se presiona el botón de regresar de algunos dispositivos. Esta característica es particularmente útil porque permite emular el comportamiento de una aplicación PhoneGap en un dispositivo móvil real. 30
CAPÍTULO III 31
3. MARCO APLICATIVO 3.1. INTRODUCCIÓN En este capítulo se desarrollará el marco teórico constituido por los métodos, técnicas (procedimientos), e instrumentos que se emplearán en la ejecución del proyecto de investigación para poner a prueba la hipótesis, alcanzar los objetivos propuestos y así dar una respuesta al problema de investigación. Como se trata de una Plataforma de Geolocalización el cual hace el uso de teléfonos móviles surge la necesidad de utilizar la metodología; orientada a móviles MobileD Se integra métodos de Web Service usando Rest (SOA), para la comunicación entre la plataforma web y la aplicación móvil. Para el desarrollo del presente trabajo se usa las fases del MobileD, para realizar la aplicación móvil y plataforma web del cual se consume los servicios, para dar solución a los objetivos planteados: ● Exploración y Categorización ● Inicialización ● Productización e implementación del Web Service ● Fase de Estabilización ● Fase de Prueba 3.2. EXPLORACIÓN Y CATEGORIZACIÓN Para esta fase se va a comenzar con el levantamiento de información, identificar los requerimientos necesarios para la ejecución del presente trabajo, es decir analizar los datos necesarios que los usuarios (cliente, administrador) deben suministrar. 32
La categorización de servicios en base a los requerimientos es muy buena práctica a la hora de administrar nuestra arquitectura SOA (gobierno SOA) ya que nos ayuda a etiquetar los servicios que conformarán nuestro inventario en función de la lógica que contienen y su grado de reutilización. 3.2.1. DEFINICIÓN DE LOS GRUPOS DE INTERÉS ● Miembros de una familia que necesitan contar con información al alcance de la mano sobre la ubicación de alguna persona dentro de la familia. ● Personas que necesiten estar seguros en lugares desconocidos o en horarios nocturnos. 3.2.2. ACTORES Los actores del sistema involucrados con la construcción de la plataforma de geolocalización de personas son principalmente el usuario y el administrador. 3.2.3. ROLES Y TAREAS Para el desarrollo del sistema se han logrado identificar a los siguientes usuarios: NOMBRE
DESCRIPCIÓN
STAKEHOLDER
Usuario Final
Es el que requiere los servicios de información, Usuario que también administra los miembros de su familia
Administrador
Verifica la funcionalidad de los servicios que el usuario Administrador final utiliza Tabla 3.1 Roles y tareas de los usuarios Fuente: Elaboración propia 33
3.2.4. COLECCIÓN DE REQUERIMIENTOS Es una tarea en la cual los requerimientos para el producto son establecidos en nivel apropiado, los cuales pueden ser funcionales o no funcionales. El objetivo es producir definición inicial general del producto, propósito y funcionalidad. 3.2.4.1. FUNCIONALES ● La aplicación debe ser capaz de mostrar todos miembros de la familia. ● La aplicación debe ser capaz de agregar un nuevo miembro a la familia. ● La aplicación debe ser capaz de mostrar la trayectoria en tiempo real de un miembro de la familia. ● La plataforma deberá permitir: Adicionar, eliminar y modificar a otros usuarios que tengan acceso al control de la base de datos. ● La plataforma deberá permitir gestionar a los usuarios finales. ● La base de datos deberá tener la última ubicación proporcionada por la aplicación. 3.2.4.2. NO FUNCIONALES ● La plataforma deberá ser autenticado mediante algoritmos de seguridad. ● La aplicación y la plataforma desplegará mensajes de confirmación acorde a las acciones de adición, eliminación o modificación 3.2.5. CATEGORIZACIÓN DE REQUERIMIENTOS ● Servicios de Entidad ○ Son los requerimientos que tienen las operaciones de adicionar, eliminar y modificar, tanto en la plataforma como en la aplicación. ● Servicios de Tarea ○ Autentificación para el acceso a la plataforma o aplicación móvil 34
3.2.6. ARQUITECTURA PROTOTIPO Mediante la identificación de los requerimientos funcionales, se establecieron dos subsistemas que son implementados, para cumplir con los objetivos del presente trabajo.
Figura 3.1. Arquitectura del prototipo Fuente: Elaboración propia Básicamente el prototipo presenta dos módulos plenamente identificados: Administración, destinado a la gestión de los datos del sistema y usuario, orientada al uso de la aplicación con interfaces gráficas. ● Administración: Esta opción del sistema permite ver las ubicaciones de todos los usuarios. Esta opción está habilitada solamente para aquellos usuarios autorizados para acceder a la plataforma. ● Usuario: Quienes a partir de la interfaz gráfica que tiene la aplicación, éste puede realizar búsquedas de personas. 3.3. INICIALIZACIÓN La planificación del proyecto entorno a la parte técnica se hará durante esta fase, definiendo el editor, lenguaje, framework y APIs con el que se va a trabajar para el desarrollo del 35
servicio web y la aplicación móvil como tal; en cuanto al servicio web se hace el diseño de la arquitectura a usar y la aplicación se lista las funcionalidades que se hacen necesarias dentro de los módulos a desarrollar 3.3.1. ENTORNO DE TRABAJO ● Brackets, editor de texto de desarrollo web. ● PhoneGap, framework para desarrollo de aplicaciones híbridas. ● API Google Maps ● Web Service Rest ● Extensión de Google Chrome “Advanced REST Client.” 3.3.2. LISTA DE FUNCIONALIDADES Para llevar con éxito el desarrollo del prototipo, se definió una serie de tareas TAREA
PRIORIDAD
Diseño de interfaces de usuario
1
Diseño de la base de datos
2
Diagrama de Base de Datos
3
Gestión de usuarios
4
Gestión de EndPoints
5
Establecimiento parámetros de búsqueda
6
Traza de rutas
7
36
Pruebas de aceptación
8
Tabla 3.2. Lista de tareas Fuente: Elaboración propia 3.3.3. PLANIFICACIÓN DE FASES Para el desarrollo de la aplicación, se planifica realizar por lo menos tres iteraciones ejecutadas con un periodo de una semana cada una según los criterios de prioridad establecidas para cada una de las tareas que se definieron en la anterior tabla.
Figura 3.2. Esquema de desarrollo del sistema Fuente: Elaboración Propia 3.3.4. ITERACIONES FASE
ITERACIÓN
DESCRIPCIÓN
Exploración
Inicialización
Iteración 0
Establecimiento del proyecto, 37
desarrollo de tareas basadas por prioridades
Productización implementación
Implementación de módulos.
e de
Web Iteración 1
Service
Refinamiento Generación
de
interfaces.
y ejecución de
pruebas de aceptación
Estabilización
Iteración 2
Generación
y ejecución de
pruebas
de
aceptación.
Refactorización de módulos.
Iteración pruebas
Pruebas del sistema
de sistemas
Se realiza la evaluación de las pruebas y se realiza el análisis de los resultados
Tabla 3.3. Descripción de las Iteraciones Fuente: Elaboración propia Las tareas 1, 2 y 3 deben ser elaborados en la iteración 1 con la una planificación de elaboración de una semana. Las tareas 4 y 5 son realizados en la iteración 2. La planificación de entregas del trabajo es de aproximadamente una semana, las actividades se realizan de forma paralela. Finalmente las tareas 6, 7 y 8 se realizan en la última iteración de forma paralela secuencial con duración de dos semanas. 38
TAREA
DÍAS
Diseño de interfaces de usuario
1
Diseño de la base de datos
2
Diagrama de clases
2
Gestión de usuarios
4
Gestión de EndPoints
4
Establecimiento parámetros de búsqueda
3
Traza de rutas
4
Pruebas de aceptación
6
Tabla 3.4. Estimación de esfuerzos de Procesos Principales Fuente: Elaboración propia 3.3.5. PLANIFICACIÓN DEL SERVICIO WEB RESTful La aplicación Android a construir requiere que el servicio web le posibilite centralizar la base de datos en un servidor remoto y que permita realizar las 4 operaciones básicas sobre estos datos. También es necesario que el usuario cree primero una cuenta y luego se loguee para poder obtener una clave de acceso a la API. Sin estas condiciones el usuario no tendrá acceso a la información.
39
En cuanto a la estructura del servicio, nos guiaremos en un estilo sencillo MVC para manejar las peticiones del cliente. Así que los pasos de desarrollo quedarían de la siguiente forma: ● Configuración para desarrollo web ● Diseño e implementación de la base de datos ● Realización de conexion Mysql con Php ● Creación de los modelos de datos ● Definición de las vistas ● Manejo de las llamadas al servicio web RESTful (CRUD5) ● Realizar pruebas al servicio web
3.3.6. DISEÑO E IMPLEMENTACIÓN DE LA BASE DE DATOS
Figura 3.3. Modelo Relacional Fuente: Elaboración propia
5
Del acrónimo en inglés Create, Read, Update y Delete
40
3.3.7. DISEÑO DE LA INTERFAZ DEL ADMINISTRADOR
Figura 3.4. Inicio de sesión Fuente: Elaboración propia
Figura 3.5. CRUD de usuarios (Administrador) Fuente: Elaboración propia 41
Figura 3.6. Ubicación de Usuarios (Ver Mapa) Fuente: Elaboración propia
Figura 3.7. Rastreo de un Usuario Fuente: Elaboración propio 42
3.3.8. DISEÑO DE LA INTERFAZ DEL USUARIO
Figura 3.8. Registro en la Aplicación Fuente: Elaboración propia 43
Figura 3.9. Interfaz Manejo Usuario Fuente: Elaboración propia 3.4. PRODUCTIZACIÓN E IMPLEMENTACIÓN DE WEB SERVICE Durante esta fase ya se hace el desarrollo de la aplicación en su totalidad, una vez establecidas las listas de funcionalidades se comienza a desarrollar según el método que se recomienda en esta metodología (Planificacióntrabajoliberación) haciendo las iteraciones necesarias para la programación. Identificando la cantidad de actividades, diálogos y formularios que se necesiten para desarrollar los Scripts del Web Service. 44
3.4.1. IMPLEMENTACIÓN DE LOS WEB SERVICES 3.4.1.1. PROCESAR LAS RUTAS DE LOS RECURSOS Crear el archivo index.php como el núcleo monitor que exponga las rutas de los recursos. Es decir, procesar todas las urls desde aquí para mantener el control de forma compacta. La idea básica es usar una estructura switch para atender los cuatro verbos GET, POST, PUT y DELETE dependiendo del segmento que llega a través de PATH_INFO. El algoritmo preciso sería el siguiente: Los pasos a seguir son los siguientes. 1. Obtener el segmento de la url para identificar el recurso. Usa el método explode() con el limitador ‘/’ para separar la ruta que se encuentra en PATH_INFO. 2. Determina si el recurso solicitado existe. Una alternativa es usar array_shift() para obtener el primer valor del array (en el caso anterior sería el valor “contactos”) y luego comparar su existencia en un array que contenga los recursos disponibles. 3. Extrae el método de la petición a través de $_SERVER['REQUEST_METHOD'] y usa el valor como parámetro de una estructura switch. Dependiendo del recurso que se obtuvo y el método procesado así mismo se escribirán las instrucciones necesarias. El marco general quedaría de la siguiente forma:
45
Figura 3.10. Estructura del index.php Fuente: Elaboración propia 3.4.1.2. MANEJADORES DE SALIDA EN LA VISTA Los manejadores de salida permiten construir las respuestas hacia el cliente con el formato y las cabeceras necesarias para seguir los estándares de REST. 46
Con estos componentes aseguramos la misma estructura en todas las respuestas. Por cada formato de datos aceptado construiremos una clase. Crear un nuevo archivo llamado VistaApi.php y añadir la siguiente definición.
Lihat lebih banyak...
Comentários
