Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
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
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y
NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.
b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este
material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS
CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
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 apoyarme moralmente y
psicológicamente.
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 16
2.5. INGENIERÍA MÓVIL 18
2.5.1.. METODOLOGÍA DE DESARROLLO MOBILED 18
2.5.2. ELEMENTOS 21
2.6. GEOLOCALIZACIÓN 22
2.6.1. API GOOGLE MAPS 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 27
2.9. EMULADOR RIPPLE 29
2.10. CAPACIDADES DE RIPPLE 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 47
3.4.1.4. MODELO DE DATOS DE USUARIOS 49
3.4.1.5. MODELO DE DATOS PARA INTEGRANTES 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 GPS 1
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 que 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ón de personas por medio del GPS de su dispositivo 2
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 API . 3
2 Es 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 Source y basado en un modelo de 4
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 Es 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 interfaz 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, que también administra los miembros de su familia
Usuario
Administrador Verifica la funcionalidad de los servicios que el usuario final utiliza
Administrador
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 e
implementación de Web
Service
Iteración 1
Implementación de módulos.
Refinamiento de interfaces.
Generación 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.
Pruebas del sistema Iteración pruebas
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 (CRUD ) 5
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.
<?php
abstract class VistaApi
public $estado;
public abstract function imprimir ($cuerpo);
La clase abstracta VistaApi representa de forma general los requerimientos básicos para
imprimir una respuesta en cualquier formato. El miembro $estado se refiere al código de
error HTTP que se enviará en la respuesta. El método imprimir() debería ser sobrescrito
para añadir la cabecera ContentType e imprimir el formato.
3.4.1.3. MANEJO DE EXCEPCIONES EN LA API
Desarrollar un api REST solamente pensando en los resultados ideales hace que nuestro
servicio pierda congruencia cuando surgen flujos anómalos de comportamiento.
Por esta razón debemos pensar en la construcción de respuestas que incluyan la
información sobre los errores que puedan darse.
En la sección anterior vimos diferentes vistas que pueden sernos de ayuda para transmitir
errores al cliente. Pero adicionalmente podemos usar el lanzamiento de excepciones como
estrategia.
47
Una buena forma de hacerlo es añadir al inicio de nuestro archivo index.php un manejador
de excepciones personalizado para imprimir la respuesta cada que ocurra una.
Figura 3.11. Fragmento de excepción en index.php
Fuente: Elaboración propia
A través de la función set_exception_handler() invocamos las instrucciones necesarias para
crear una nueva vista basada solo en el mensaje y un estado. Este sería el cuerpo común de
un error en nuestra API. Así nos aseguramos tener controlados los errores que se nos salgan
de la mano.
Puedes extender un poco más el comportamiento si deseas enviar información que le diga
al usuario como resolver el problema en cuestión. En esta ocasión usaremos una nueva
clase de excepción que contenga el estado de error.
48
En un archivo llamado ExcepcionApi.php. Este contendrá una pequeña extensión de la
clase Exception para cubrir el estado de error que presenten las excepciones de nuestro
servicio web REST.
3.4.1.4. MODELO DE DATOS DE USUARIOS
Las únicas acciones que deseamos realizar en el recurso usuarios son el registro y un
proceso de login. Ambas acciones podemos asociarlas a la url añadiendo un segmento que
especifique la acción de la siguiente forma:
MÉTODO DESCRIPCIÓN
POST
api.devfabio.xyz/v1/usuarios/registro
Crea un nuevo elemento en la
colección de usuarios
POST
api.pdevfabio.xyz/v1/usuarios/login
Autoriza el acceso de un usuario a
los recursos
Tabla 3.5. Recursos de registro y proceso de login
Fuente: Elaboración propia
Ambas acciones requieren del método POST para ser procesadas. Dependiendo de la
intención así mismo seguiremos el flujo de procesamiento.
Por el momento crea un nuevo archivo llamado usuarios.php dentro de modelos. El
esquema general de la clase que representará a los usuarios sería el siguiente.
49
Figura 3.12 Clase usuarios
Fuente: Elaboración propia
Como estrategia de nombrado usaremos la cadena usuarios en el nombre de la clase para
comparar su existencia como recurso.
También se usa el nombre de cada verbo de la petición como firma de cada método, es
decir, paraGET tendremos get(), para POST el método post() y así sucesivamente. Esta
condición permitirá generalizar la invocación de estos métodos sin importar la clase.
Ahora pensemos un poco en la lógica que debemos seguir para que el login y registro se
lleven a cabo. Con login nos referimos a la autorización que se da luego de autenticar los
datos de un usuario existente. El registro es simplemente la creación de un nuevo usuario.
50
Figura 3.13. Diagrama de procesamiento
Fuente: Elaboración propia
El diagrama anterior deja claro la forma en que procederemos para registrar usuarios. En
esencia, tenemos 4 pasos para procesar esta acción.
1. Extraer los campos de la petición POST.
2. Validar la sintaxis y restricciones de estos campos.
3. Crear un nuevo registro en la tabla usuario.
4. Imprimir la respuesta
Con estas ideas en mente, entonces comencemos por filtrar el segmento que viene desde la
url dentro del método post() de la clase usuarios. Simplemente comparamos el contenido
del parámetro de entrada con las acciones correspondientes.
51
Figura 3.14. Invocación de registro o login
Fuente: Elaboración propia
Extraer campos de petición POST— El registro de un usuario requiere los campos
nombre,contraseña y correo. El cual tiene el siguiente formato:
"nombre":"nick", "contrasena":"12345", "correo":"[email protected]"
Validar datos del usuario.Este paso no hará parte del registro a implementar, ya que no
tenemos unas reglas de negocio previamente definidas.
Aquí debes comprobar todos los campos que usarás para el registro con el fin de que tengan
el formato y sintaxis acorde al comportamiento natural del servicio web.
Por ejemplo, hay servicios que no permiten caracteres especiales en el nombre de usuario.
O contraseñas que requieren obligatoriamente un número y un carácter especial. También
comprobar la validez de la estructura de correo y otros.
52
Crear nuevo usuario en la base de datos. La inserción de un nuevo registro requiere que
usemos nuestro singleton ConexionBD.
Para ello crearemos una sentencia preparada con un comando INSERT INTO y luego
uniremos los valores del objeto que viene como parámetro en el método que
implementaremos para la creación.
El método crear() recibe como parámetro el objeto decodificado anteriormente. La primera
acción es la obtención de cada columna en variables locales.
En el caso de la contraseña, recuerda que es mejor dificultar su lectura a personajes
maliciosos a través de algoritmos de encriptado. Por ello tenemos el método
encriptarContrasena() el cual usa el método password_hash() con un encriptado hash
simple. Puedes extender la seguridad según te parezca.
La clave del api para el usuario se genera con generarClaveApi(). Esto se hace con un
número aleatorio al cual se le aplica MD5. Es una generación simple, pero tu puedes
emplear otros métodos. Ten en cuenta que esta clave es estática, puedes optar por usar un
tiempo de expiración para esta y así para aumentar la seguridad.
Login de usuarios. Como se veía en el diagrama de flujo inicial, el login se basa en
comprobar las credenciales de un usuario para permitirle acceder a los contactos.
Los pasos que seguiremos serán:
1. Extraer credenciales del cuerpo de la petición POST
2. Verificar la validez de las credenciales
53
3. Obtener los datos del usuario
4. Imprimir la respuesta
Extraer credenciales. Para la autenticación usaremos el correo electrónico y la contraseña
del usuario. Así que extraemos ambas credenciales desde el objeto decodificado del cuerpo
de la petición.
Verificar la validez de las credenciales. La autenticación se basa en la comprobación de
que exista un registro de la contraseña comprobada según el correo. Si esta existe, entonces
se pasa a comprobar el valor hash que está almacenado en la base de datos con la
contraseña plana. Con esto claro creemos el método autenticar().
Obtener los datos del usuario. una vez comprobado que el usuario es válido, entonces
pasamos a obtener sus datos completos. Entre ellos la clave del api para permitir autorizar
las operaciones sobre los recursos de los contactos.
Imprimir la respuesta. Finalmente determinamos que tipo de cuerpo enviaremos en la
respuesta. Si el método obtenerUsuarioPorCorreo() retorna exitosamente, entonces
crearemos un arreglo Json para enviarlo. De lo contrario en cualquier situación adversa,
construiremos el formato de error.
3.4.1.5. MODELO DE DATOS PARA INTEGRANTES
Con los integrantes si tendremos un trato basado en CRUD . Los usuarios autorizados 6
podrán realizar cualquier de las cuatro acciones solo si tienen una clave de api asignada. La
siguiente tabla muestra la descripción formal de las operaciones sobre el recurso.
6 Del acrónimo en inglés Create, Read, Update y Delete
54
MÉTODO DESCRIPCIÓN
GET
api.devfabio.xyz/v1/integrante Obtiene la colección de integrantes
GET
api.devfabio.xyz/v1/integrante/:id
Obtiene un solo recurso de los
integrantes con el id especificado
POST
api.devfabio.xyz/v1/integrante
Añade un nuevo integrantes a la
colección
PUT
api.devfabio.xyz/v1/integrante/:id
Modifica el integrantes especificado
por su id
DELETE
api.devfabio.xyz/v1/integrante/:id
Elimina un integrantes especificado
por su id
Tabla 3.6. Operaciones sobre los recursos
Fuente: Elaboración propia
Autorización de Usuarios. La autorización tiene el fin de permitir al usuario el acceso a
los recursos que proporciona el servicio web REST. Esto equivale a comparar la clave del
api del usuario con su registro en la base de datos.
Quiere decir que la petición del cliente debe enviar la clave luego de que el usuario esté
logueado. Un método sería añadir un parámetro a la url con este valor, pero debido a que
nuestra api es privada es mejor aislar este componente con la cabecera Authorization.
55
La implementación es sencilla. Solo extraemos el valor de Authorization con el
métodoapache_request_headers() o getallheaders(). Con este comparamos la clave que se
encuentra en la base de datos. Si todo sale bien el permiso será otorgado y retornaremos el
id del usuario.
Obtener la colección de integrantes. Tanto para obtener la colección completa de los
contactos o uno en particular, es posible usar un solo conjunto de instrucciones que se
basen en el segmento de la url que viene en la petición.
Para ello iremos al método get() de contactos y llamaremos al método usuarios::autorizar()
para determinar el id del usuario y así construir la consulta correcta en la base de datos.
Si la petición que se recibió está vacía consultaremos todos los contactos, de lo contrario se
extrae el supuesto identificador del contacto que viene en la url. Sin importar el caso,
imprimimos una respuesta con código 200.
Añadir un nuevo integrante. Añadir un nuevo usuario requiere que construyamos una
petición POST hacia la url de los contactos con un cuerpo que contenga el primer nombre,
el primer apellido, teléfono y correo del contacto.
La respuesta común sería un mensaje que traiga consigo el id del nuevo registro, un
mensaje y código de éxito. Adicionalmente si deseas, puedes usar la cabecera Location para
especificar a la url de acceso del recurso como complemento.
Teniendo en cuenta estas restricciones, dentro de post() haremos lo siguiente:
Autorizar al usuario
56
Extraer el cuerpo de la petición en forma de objeto
Crearemos el nuevo registro en la base de datos con un nuevo método llamado
crear()
Si todo salió bien, entonces imprimimos la respuesta.
Editar un contacto a través de su id. La edición se realiza a través del método PUT hacia
la url del recurso contacto junto al identificador del elemento que se actualizará.
El método put() es mucho más simple que post() o get(). Solo debemos extraer el segmento
del id y luego realizar una consulta UPDATE sobre la base de datos. Al igual que los demás
métodos se requiere una autorización primero.
Eliminar un contacto. Al igual que la actualización, la eliminación requiere el id del
contacto ya sea como parámetro o en el segmento de la url. El método que usaremos para
representar esta operación será DELETE.
El método delete() tiene una forma similar a put(), por lo que el siguiente código no te
parece extraño. La única diferencia es que no recibimos un cuerpo en la petición.
3.4.2. IMPLEMENTACIÓN APLICACIÓN MÓVIL
Una vez creado el api RESTful, es hora de construir nuestra aplicación.
Diseñar Interfaz de la aplicación.
Crear la petición personalizada para tratar respuestas Json.
Crear un adaptador que procese los elementos del recycler view.
Tratar los eventos para la comunicación de datos a través de los controles.
57
3.4.2.1. OBTENER LA UBICACIÓN ACTUAL DEL USUARIO
La ubicación actual del usuario puede obtenerse usando la función getCurrentPosition del
objetonavigator.geolocation. Esta función acepta tres parámetros “– Success callback
function, Error callback function and position options”.
Si los datos de localización se recuperan satisfactoriamente, se invocará la función callback
de éxito con el objeto que contiene la position como parámetro de entrada. De lo contrario,
se invocará la función callback de error con el objeto de error como su parámetro de
entrada.
Función callback de éxito
Esta función de devolución de llamada se invoca únicamente cuando el usuario se
compromete a compartir la información de su ubicación y los datos de localización se
recuperan con éxito por el navegador.
Los datos de localización estarán disponibles como un objeto de posición y se llamará a la
función con el objeto de posición como su parámetro de entrada. Un objeto position
contiene una propiedad timestamp que denota el tiempo en que se recuperan los datos de
localización y el objeto coords.
El objeto coords tiene las siguientes propiedades:
Latitude, longitude – coordenadas Geográficas en grados decimales.
Accuracy (precision) – nivel de precisión de las coordenadas de latitud y longitud
en metros.
Altitude – altura de la posición sobre el nivel del mar en metros.
58
AltitudeAccuracy – precision de la altura respecto al nivel del mar obtenida en
metros.
Heading (Dirección) – proporciona información sobre el rumbo en 360 grados.
Speed (velocidad) – indica la velocidad relativa en metros por segundo.
Función callback de error
Esta es una función opcional que toma un objeto ‘Error de posición’ como su parámetro de
entrada. Esta función es invocada bajo cualquiera de las siguientes circunstancias
Error desconocido.
Agotado el tiempo de solicitud.
El Usuario no quiere compartir la información de ubicación.
No está disponible la información de la ubicación.
Opciones de posición
Describe las opciones para utilizar al recuperar la ubicación del usuario.
enableHighAccuracy: Booleano opcional. Si es true, el agente de usuario
(navegador) intentará proporcionar la posición más exacta. Esto puede resultar un
tiempo de respuesta más lento y mayor consumo de energía. Si es false, se obtendrá
una posición menos precisa. EL valor predeterminado por defecto es false.
Timeout (Tiempo de espera: Valor long positivo. Indica el tiempo máximo (en
milisegundos) que el agente de usuario puede tomar para responder con los datos de
localización. El valor predeterminado es infinito.
maximumAge: Valor long positivo. ¿Cuánto tiempo (en milisegundos) el navegador
puede seguir usando los datos de localización en la memoria caché antes de tratar de
59
obtener nuevos datos de localización. Un valor de cero indica que el agente de
usuario no debe utilizar los datos de localización en la memoria caché y un valor
infinito indica que los datos de localización en la memoria caché deben ser
utilizados siempre por el agente de usuario.
Seguimiento de los cambio de ubicación
watchPosition() puede utilizarse para obtener los datos de localización a intervalos
regulares. La función de callback de éxito se invoca automáticamente siempre y cuando el
dispositivo o el navegador cambien de posición.
Los parámetros de esta función son similares a la función getCurrentPosition(). Devuelve
un valor de whatch IDcon los intervalos marcados en maximunAge, que podemos eliminar
mediante la función clearWatch().
3.4.3. WORKSHOP DE POST ITERACIÓN
Mejoras: Se debe mejorar la obtención de los datos de las personas, y el CRUD 7
del RESTful.
Fortalezas: La aplicación móvil funciona con normalidad. Los datos mostrados
están referidos a la ubicación del usuario.
El CRUD de parte de los usuarios funciona con normalidad.
Debilidades: El intercambio de información con el servidor es lenta por el uso de
Internet mediante tecnología 2G y 3G, pero con el uso de WI FI la interacción con
el servidor cuenta de relativa normalidad.
7 Del acrónimo en inglés Create, Read, Update y Delete
60
3.4.3.1. TEST DE ACEPTACIÓN
HOJA DE PRUEBA DE ACEPTACIÓN
Test ID 1
Historia Funcionalidad Móvil Web Service
Fecha Escrita 02/11/2015
Fecha Corrida 31/11/2015
Paso / Defecto Paso
Descripción
1. Procesar las rutas de los recursos
2. Manejadores de salida en la vista
3. Manejo de excepciones en la API
4. Modelo de Datos de Usuarios
5. Modelo de Datos para Integrantes
6. Obtener la ubicación actual del
Usuario
Resultados Esperados
1. Manejo de datos mediante una sola
URL a la base de datos del
servidor.
2. Utilización de las respuestas hacia
el cliente manejando los errores
4xx de parte del cliente y 5xx del
lado del servidor
61
3. Mostrar posibles soluciones al
cliente en el manejo de errores
4. Creación de datos por medio de de
HTTP a la base de datos y logueo
5. Ingreso de datos mediante HTTP
bajo la autorización del ApiKey de
los usuarios, es decir CRUD
6. Captura correcta de las
coordenadas del Integrante
Tabla 3.7. Test de aceptación de producción
Fuente: Elaboración propia
3.5. FASE DE ESTABILIZACIÓN
En el caso de este trabajo siendo un solo programador para el desarrollo de la aplicación se
adapta esta fase para conexión entre la aplicación móvil y la plataforma que se desarrolla
simultáneamente. También se realiza la documentación, dado que en anterior fase se van
integrando los módulos, aplicando las pruebas respectivas.
3.5.1. WORKSHOP DE POST ITERACIÓN
Mejoras: mejora en los estilos de la interfaz gráfica tanto en la aplicación móvil
como en la plataforma web dando una mejor apariencia y presentación al usuario
final y al administrador respectivamente.
Fortalezas: la aplicación funciona de manera adecuada contando con una conexión
a internet.
Debilidades: la aplicación funciona solamente si se cuenta con una conexión a
internet.
62
3.5.2. TEST DE ACEPTACIÓN
HOJA DE PRUEBA DE ACEPTACIÓN
Test ID 2
Historia Correcciones Móvil Web Service
Fecha Escrita 31/11/2015
Fecha Corrida 1/12/2015
Paso / Defecto Paso
Descripción
1. Lista desplegable de resultados
2. Despliegue de mensajes de
confirmación
3. Validación de campos
Resultados Esperados
1. Inspección visual
2. Inspección visual
3. Inspección visual
4. Inspección visual
Tabla 3.8. Test de aceptación de estabilización
Fuente: Elaboración propia
3.6. FASE DE PRUEBAS
Dado que durante las anteriores fases se contempla la ejecución de pruebas unitarias y de
aceptación, ya la aplicación está lista para pasar por las pruebas de integración siendo la
63
etapa final del desarrollo, dando como resultado el producto final ya probado listo para la
puesta en producción.
3.6.1. PLAN DE PRUEBAS
Para cada pantalla se prueba lo siguiente:
Datos válidos
Valores límite
Datos inválidos
El diseño debe ser como esta en la documentación
Los enlaces entre pantallas tanto del software móvil como de la plataforma web
deben funcionar tal como se las describe en la documentación.
Para las pruebas de tiempo de carga se tomó en cuenta los siguientes criterios:
Se tomaron en cuenta los requerimientos funcionales más relevantes.
Se midió el tiempo de respuesta
Para las pruebas de tiempo de acceso se tomó en cuenta los siguientes criterios:
Se tomó en cuenta el requerimiento funcional más importante para la comparación
(ubicación en tiempo real)
Se considera tiempo de acceso al tiempo desde que un usuario abre una aplicación y
recibe totalmente la información deseada.
3.6.2. PRUEBAS DE ACEPTACIÓN POR ITERACIÓN
Las pruebas de aceptación por iteración se realizan a los requerimientos funcionales, y a los
no funcionales como facilidad de uso, recuperación eficiencia, entre otros; y se pretende
lograr: corrección, vale decir, carencia de ambigüedad; completitud, es decir, especificación
completa, y clara del problema; y por último consistencia, que no haya requisitos
contradictorios.
64
3.6.2.1. RESULTADOS ITERACIÓN 1
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 14 88%
Pruebas reprobadas 2 12%
TOTAL 16 100%
Pruebas Corregidas 2 100%
Tabla 3.9. Resultados iteración 1
Fuente: Elaboración propia
3.6.2.2. RESULTADOS ITERACIÓN 2
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 13 81%
Pruebas reprobadas 3 19%
TOTAL 16 100%
Pruebas Corregidas 3 100%
Tabla 3.10. Resultados iteración 2
Fuente: Elaboración propia
65
3.6.2.3. RESULTADOS ITERACIÓN 3
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 3 75%
Pruebas reprobadas 1 25%
TOTAL 4 100%
Pruebas Corregidas 1 100%
Tabla 3.11. Resultados iteración 3
Fuente: Elaboración propia
3.6.2.4. RESULTADOS ITERACIÓN 4
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 5 84%
Pruebas reprobadas 1 16%
TOTAL 6 100%
Pruebas Corregidas 1 100%
Tabla 3.12. Resultados iteración 4
Fuente: Elaboración propia
66
3.6.2.5. RESULTADOS ITERACIÓN 5
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 4 80%
Pruebas reprobadas 1 20%
TOTAL 5 100%
Pruebas Corregidas 1 100%
Tabla 3.13. Resultados iteración 5
Fuente: Elaboración propia
3.6.2.6. RESUMEN DE RESULTADOS DE ITERACIONES
NÚMERO DE PRUEBAS PORCENTAJE
Pruebas aceptadas 39 83%
Pruebas reprobadas 8 17%
TOTAL 47 100%
Pruebas Corregidas 8 100%
Tabla 3.14. Resumen de resultados de iteraciones
Fuente: Elaboración propia
67
CAPÍTULO IV
68
4. PRUEBA DE HIPÓTESIS
4.1. INTRODUCCIÓN
En los siguientes acápites se presenta el desarrollo de las pruebas y el análisis del
cumplimiento de los requerimientos, dando lugar a la prueba de la hipótesis planteada y por
tanto el cumplimiento de los objetivos planteados.
4.2. EVALUACIÓN DE LOS CASOS DE PRUEBA
En este punto recordaremos el resumen de los resultados obtenidos mediante las pruebas de
aceptación por iteración desarrolladas en el anterior capítulo, siendo estos los siguientes:
Pruebas Totales: 47
Pruebas Aceptadas: 39
Pruebas Reprobadas: 8
Porcentaje de Éxitos: 83%
Porcentaje de Fracasos: 17%
Como se observa en los resultados, el porcentaje de éxitos es del 83% esperado al momento
de plantearse la Hipótesis, pero para comprobar de manera cuantificable este valor se
asemeja al valor esperado, se realiza una prueba de hipótesis estadística.
4.3. PRUEBA DE HIPÓTESIS
Una hipótesis es una suposición que se establece como base de una investigación que puede
confirmar o negar su validez, su función principal es demarcar el problema que se va a
investigar considerando componentes tales como lugar, características de los sujetos,
tiempo y otros.
69
4.3.1. DEFINICIÓN DE LA HIPÓTESIS
H0: “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”
H1: Se Rechaza H0
En este caso se espera que el porcentaje de éxitos sea igual o mayor a 90%, tomando un
nivel de significancia del 5%
H0: p0 0.9≥
H1: p0 0.9<
4.3.2. EVALUACIÓN DE RESULTADOS
Para determinar si el porcentaje de éxitos obtenido en las pruebas puede ser considerado
cercano al 90% de nivel de confianza esperado, se hará uso de una Prueba de Hipótesis para
Proporciones.
Las variables usadas en dicha prueba serán las mismas mencionadas en la evaluación de
casos de prueba:
p0 = 0.9
X = 39
n = 47
.5α = 0
70
4.3.3. DETERMINACIÓN DE LA REGIÓN CRÍTICA
La región crítica para la hipótesis planteada, es la siguiente:
Figura 4.1. Región crítica para la hipótesis
Fuente: Elaboración propia
Como n se refiere en este caso al número de pruebas, en este caso 47, el punto crítico a usar
es Z0 y se determina mediante:
Z0 = Z1 = Z10.05 α
Este valor se halla de la tabla de la función de distribución normal, la cual se encuentra en
el anexo A. Para obtener el valor de z se elige de la tabla mencionada el valor más cercano
a 0.95; el cual está ubicado en la fila 1.6 y columna 0.04
z . . . 0.04
. . .
71
1.6 0.94950
Tabla 4.1. Resultado tabla de la función de distribución normal
Fuente: Elaboración propia
El valor de z se obtiene sumando ambos valores:
Z0.95 = 1.6 + 0.04 = 1.64
4.3.4. CÁLCULO ESTADÍSTICO DE LA PRUEBA
Como se conoce el número total de individuos en el espacio muestral, el valor estadístico
de la prueba se obtiene mediante la fórmula:
Z = X n p− * 0
√n p (1 p )* 0 − 0
Reemplazando los valores y haciendo los cálculos correspondientes obtenemos:
.78Z = 39 47 0.9− *√47 0.9(1 0.9)* −
= − 0
4.3.5. TOMA DE DECISIÓN
Figura 4.2. Distribución de Z en el gráfico para la toma de decisión
Fuente: Elaboración propia
72
El promedio de éxito del prototipo al momento de reconocer las muestras se acerca al 90%.
Por tanto como se acepta H0 se podría concluir y afinar la hipótesis:
H0: “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”
73
CAPÍTULO V
74
5. CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES
Se pudo alcanzar el objetivo principal de estudio: Desarrollar una plataforma de
geolocalización que brinde información confiable de la ubicación de una persona.
Mediante el uso de la metodología MobileD y usando SOA se desarrolló la aplicación
webmóvil y el API RESTful cumpliendo los siguientes objetivos específicos planteados en
el primer capítulo:
Automatizar la ubicación de una persona específica, se resolvió mediante el API de
geolocalización de HTML5
Desarrollar una plataforma web orientado a servicios, se logró mediante el manejo
de REST creando una propia API RESTful
Integrar a la aplicación Google Maps, para su manejo se integró el API Maps de
Google para mostrar la ubicación de una persona; y a su vez para resolver el
objetivo de Mostrar la trayectoria de una persona.
Se usó Phonegap para el desarrollo de la aplicación móvil compatible con sistemas
operativos móviles y para aplicaciones web, de tal manera que cumpla el principio
de SOA ser multiplataforma.
Mediante el análisis de resultados obtenidos en el capítulo cuatro se concluye la solución
del problema principal de la investigación:
“¿Cómo obtener información confiable sobre la ubicación de una persona?”
Al crear una aplicación para dispositivos móviles se incrementa la usabilidad de las
personas, además de ser parte, una importante herramienta para la seguridad ciudadana en
nuestra ciudad.
75
El desarrollo basado en pruebas permitió detectar y corregir errores en un temprana etapa
del desarrollo lo que permite no arrastrar errores en otros disminuyendo el impacto de la
corrección de error, permitiendo que el software móvil tenga alta calidad.
Se logró demostrar que la hipótesis propuesta en el capítulo 1 es verdadera, mediante el uso
de Prueba de Hipótesis para Proporciones, el objetivo de estas prueba es evaluar las
afirmaciones con respecto a una proporción (o Porcentaje), el cual usa la Distribución
Normal, dando datos los cuales se usan para la toma de decisiones.
5.2. RECOMENDACIONES
El presente trabajo es una base para otras investigaciones o usos que se puede dar a la
plataforma, el cual está pensado para extenderse a otros aspectos donde se necesitan usar la
geolocalización no necesariamente de personas sino también de objetos y/o lugares.
El trabajo tienen que mejorar el manejo de los principios de S.O.L.I.D. para el manejo de
código reutilizable y robusto, en la parte del desarrollo de la aplicación móvil. Para así ser
comercializable
Se debe tener en cuenta que los usuarios son del tipo ocasional, es decir no están
constantemente usando las aplicaciones todo el tiempo sino por intervalos cortos, por lo
cual se debe permitir al usuario acceder a las funcionalidades más importantes de forma
más rápida e intuitiva, el cual también lo puede usar en el navegador.
76
BIBLIOGRAFÍA
1. Bell, M. (2008) Service Oriented Modeling. New Jersey : Jonh Wiley & Sons Inc.,
Hoboken.
2. Chang, K.T. (2013). Introduction to Geographic Information Systems. USA:
MCGrawHill.
3. Domínguez, S., Sánchez, E. E. y Sánchez, G. A. (2009) Guia para Elaborar una
Tesis. México: McGrawHill.
4. Duclos, C. (2010). Product Forums Google. Recuperado de
http://productforums.google.com/forum.
5. Fling B. (2009). Mobile Design and Development. O’Reilly, ISBN:
9780596155445.
6. Gaedke, M. (2014). Wen Engineering Community. Recuperado de
http://www.webengineering.org/
7. Guarachi, R. (2012). Sistema de Ubicación o Localización Móvil Basado en
Dispositivos Móviles. Tesis de pregrado, UMSA, La Paz, Bolivia.
8. Gutiérrez, J. (2000). SIG: Sistemas de Información Geográfica. México: Síntesis.
9. Hernández, R., Fernández, C. y Baptista, M. P. (2010). Metodología de la
Investigación, México: McGrawHill.
10. Nilsson, J. (2011).The First GPS: HighTech Navigation in 1909. Recuperado de:
http://www.saturdayeveningpost.com
11. Pérez, A. (2014), Software Móvil de Geolocalización para la Banca en la Ciudad de
La Paz. Tesis de pregrado, UMSA. La Paz, Bolivia.
12. Ramírez, R. (2013) Métodos para el desarrollo de aplicaciones móviles. España:
UOC.
13. Salgueiro, E. I. (2012). Herramienta Metodológica para el Desarrollo de
Aplicaciones Web Móvil. Tesis de pregrado, UMSA, La Paz, Bolivia.
77
14. Soto, J. (2010). Plataforma de geolocalización de centros de salud con tecnología
móvil implementando el protocolo de comunicación HL7. Proyecto Académico.
Universidad Privada Dr. Rafael Belloso Chacín, Venezuela.
15. Spataru, (2010). Agile Development Methods for Mobile Application .
16. Tanja, (2012). Agile Documentation in Mobile D.
17. Vásquez, M. (12 de mayo de 2015). Se duplica el acceso a Internet a través de
terminales móviles. El Deber.
18. Vera, M. (2014). ¿Qué se entiende por SOA, y cuáles son sus beneficios?
Recuperado de: http://www.i2btech.com/
78
ANEXOS
79
ANEXO A
TABLA DE DISTRIBUCIÓN NORMAL
80
DOCUMENTACIÓN
81