DEDICATORIA - UMSA

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.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.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.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.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

https://es.wikipedia.org/wiki/Software_de_c%C3%B3digo_abierto

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

https://es.wikipedia.org/wiki/Interfaz_de_usuario

https://en.wikipedia.org/wiki/Separation_of_concerns

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


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


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


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


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


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


Figura 3.5. CRUD de usuarios (Administrador)


41

Figura 3.6. Ubicación de Usuarios (Ver Mapa)


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


43

Figura 3.9. Interfaz Manejo Usuario


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


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


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


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


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


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


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.


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


Modifica el integrantes especificado

por su id

DELETE


Elimina un integrantes especificado

por su id

Tabla 3.6. Operaciones sobre los recursos


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.


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


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




Tabla 3.8. Test de aceptación de estabilización


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






TOTAL 16 100%




65





TOTAL 4 100%








TOTAL 6 100%




66





TOTAL 5 100%




3.6.2.6. RESUMEN DE RESULTADOS DE ITERACIONES




TOTAL 47 100%


Tabla 3.14. Resumen de resultados de iteraciones


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


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


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


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


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


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

DEDICATORIA - UMSA

Documents