SISTEMA DE GEOLOCALIZACION Y MONITOREO … · Archivo de con guraci on Symfony ‘ xtures.yml’...

UNIVERSIDAD TECNICA FEDERICO SANTA MARIADEPARTAMENTO DE ELECTRONICA

VALPARAISO - CHILE

“SISTEMA DE GEOLOCALIZACION Y MONITOREO

PARA DISPOSITIVOS MOVILES IPHONE”

JAVIER ALEJANDRO GIOVANNINI CAMPOS

MEMORIA DE TITULACION PARA OPTAR AL TITULO DE

INGENIERO CIVIL TELEMATICO

PROFESOR GUIA

TOMAS ARREDONDO VIDAL

PROFESOR CORREFERENTE

WERNER CREIXELL FUENTES

SEPTIEMBRE 2011

Resumen

EN el presente trabajo se documenta el diseno e implementacion de un sistema

que permite compartir la posicion geografica con otros usuarios por medio de

un telefono celular iPhone. Este sistema se diferencia de otros al poseer las siguientes

caracterısticas:

Utiliza un equipo de telefonıa, por lo que no requiere hardware adicional.

Utiliza internet movil del equipo, reduciendo los costos de plan de datos.

El sistema posee una aplicacion grafica que permite mostrar en un mapa a cada

usuario la posicion del resto de los usuarios.

El monitoreo de posiciones de usuarios es en tiempo real.

La aplicacion permite el contacto telefonico con los distintos usuarios del sistema

con solo pulsar un boton.

El usuario puede dejar un mensaje con su estado actual para comunicarselo al

resto de los usuarios.

Para el desarrollo de este proyecto se diseno un sistema de telecomunicaciones

basado en la arquitectura cliente-servidor, estos dos modulos son:

Una aplicacion cliente en el equipo iPhone encargada de enviar sus coor-

denadas geograficas al servidor.

Un Servidor web encargado almacenar y distribuir la informacion de posicion

geografica entre los distintos equipos conectados a el.

La aplicacion se conecta a Google Maps para descargar las imagenes satelitales o

mapas, y marcar sobre ellas la posicion de los usuarios del sistema.

i

Resumen ii

Palabras Clave

• Localizacion • Monitoreo • Tiempo real • iPhone • iOS • Mapkit • JSON •Servicios web • REST

Abstract

THE following work documents the design and implementation of a system that

allows people to share their geographical location with other members of the

system using an iPhone smartphone. The main differences of this system with others

are:

It uses a cellphone for location, so there is no need of any additional hardware.

It profits from the phone’s internet connection, reducing mobile data costs.

The system owns a graphical application that allows each user to see the position

of other users on a map.

It monitors the users in realtime.

The application allows phone calling with other users by just pushing a single

button on the interface.

The user can leave a status message to be communicated to other users.

To develop this system a client-server architecture was designed. The function of

this was:

An iPhone application as client to send the user’s coordinates to the server.

A Web Server, to store and distribute the users positions.

The application connects to GoogleMaps to download the satellite images or maps,

and to mark over them the position of the system’s users.

Key Words

• Location •Monitoring • Realtime • iPhone • iOS •Mapkit • JSON •Webservice

• REST

iii

Agradecimientos

CON este trabajo de tıtulo concluye una etapa importante tanto en mi formacion

profesional como en mi formacion como persona. Ha sido un proceso largo en el

que he contado con el apoyo incondicional de mi familia, estoy especialmente agrade-

cido de mis padres Eliana y Juan que han creıdo en mis proyectos desde nino y me

han inculcado lo que es mas importante en la vida, los valores que han hecho de mi

quien soy ahora.

Tambien es la oportunidad de agradecer a mis companeros de universidad, quie-

nes en el desarrollo de esta memoria me han brindado su apoyo tecnico, y lo que es

fundamental la motivacion en las dificultades. En este sentido para mi es importante

mencionar a Daniel, Arnaldo y Vıctor quienes ademas han sido mis camaradas desde

el inicio de esta travesıa a traves de la que en esos anos era la aun desconocida inge-

nierıa telematica.

Es tambien la ocasion de dar las gracias a Carolina, y a todos mis amigos que de

alguna forma estuvieron y siguen presentes conmigo.

Valparaıso, Chile

Mayo 2010

iv

Indice

Resumen I

Abstract III

Agradecimientos IV

Glosario XIII

1. INTRODUCCION 1

1.1. Identificacion del problema........................................................... 2

1.2. Objetivos del proyecto................................................................. 3

2. ESTADO DEL ARTE 4

2.1. Telefonıa celular e internet movil ................................................... 4

2.2. Telefonos inteligentes .................................................................. 4

2.3. Tecnologıas necesarias ................................................................. 5

2.3.1. Servicio de cartografıa en la web y localizacion ....................... 6

2.3.2. Servidor web y base de datos .............................................. 6

2.3.3. Servicios web ................................................................... 8

2.4. Softwares en la actualidad............................................................ 10

2.4.1. DondeEsta ...................................................................... 10

2.4.2. Cabulous ........................................................................ 10

2.4.3. Ndonde .......................................................................... 11

2.4.4. InstaMapper.................................................................... 11

2.4.5. goGlyph ......................................................................... 11

2.4.6. Lugares (Facebook)........................................................... 11

2.5. Tabla Comparativa ..................................................................... 12

3. ANALISIS DE REQUERIMIENTOS 13

3.1. Requerimientos funcionales .......................................................... 13

v

Indice vi

3.2. Requerimientos no funcionales ...................................................... 14

3.2.1. Requerimientos del producto............................................... 14

3.2.2. Requerimientos externos .................................................... 15

4. ANALISIS Y DISENO 17

4.1. Descripcion general del sistema ..................................................... 17

4.2. Arquitectura ............................................................................. 17

4.2.1. Aplicacion cliente ............................................................. 17

4.2.2. Servidor web ................................................................... 18

4.2.3. Base de datos .................................................................. 19

4.2.4. Google Maps ................................................................... 19

4.3. Modelo conceptual ..................................................................... 19

4.4. Casos de uso del sistema.............................................................. 21

4.4.1. Registro de usuario ........................................................... 21

4.4.2. Inicio de sesion de usuario .................................................. 22

4.4.3. Editar mensaje................................................................. 23

4.4.4. Ver detalles de usuario....................................................... 24

4.4.5. Llamar a usuario .............................................................. 25

5. IMPLEMENTACION DEL SISTEMA 26

5.1. Aplicacion cliente ....................................................................... 26

5.1.1. Plataforma ...................................................................... 26

5.1.2. Vistas ............................................................................ 27

5.2. Servidor ................................................................................... 38

5.2.1. Plataforma ...................................................................... 38

5.2.2. Mensaje cliente-servidor ..................................................... 39

5.2.3. Servicios web ................................................................... 39

5.3. Base de datos ............................................................................ 42

5.3.1. Plataforma ...................................................................... 42

5.3.2. Estructura de tablas.......................................................... 43

5.3.3. Relaciones entre tablas ...................................................... 44

6. MEDICIONES 46

6.1. Servidor ................................................................................... 46

6.1.1. Entorno de medicion ......................................................... 46

6.1.2. Resultados ...................................................................... 47

6.2. Aplicacion cliente ....................................................................... 47

6.2.1. Entorno de medicion ......................................................... 48

Indice vii

6.2.2. Resultados ...................................................................... 49

7. CONCLUSIONES 51

7.1. Recomendaciones ....................................................................... 51

7.1.1. Desarrollo en base a prototipos............................................ 51

7.1.2. No reinventar la rueda ....................................................... 52

7.2. Trabajo futuro........................................................................... 52

7.2.1. Aplicacion web................................................................. 52

7.2.2. Capacidad de servidores..................................................... 53

7.2.3. Incorporacion de Android................................................... 53

7.2.4. Datos geo-espaciales para base de datos ................................ 53

7.2.5. Consumo de baterıa .......................................................... 53

7.2.6. Notificaciones push ........................................................... 54

8. APENDICES 55

8.1. Acceso movil a nivel comunal en Chile ........................................... 55

8.2. Trafico de datos por dispositivo..................................................... 56

8.3. Estructura JSON ....................................................................... 56

8.4. Definicion modelo de datos en Symfony .......................................... 58

8.5. Datos iniciales en Symfony........................................................... 59

Referencias 60

Indice de Tablas

2.1. Comparacion de softwares localizadores para moviles......................... 12

4.1. Caso de uso: ‘registro de usuario’................................................... 21

4.2. Caso de uso: ‘inicio de sesion’ ....................................................... 22

4.3. Caso de uso: ‘editar mensaje’........................................................ 23

4.4. Caso de uso: ‘ver detalles de usuario’.............................................. 24

4.5. Caso de uso: ‘llamar a usuario’. ..................................................... 25

5.1. Tabla ‘user’ y sus columnas .......................................................... 43

5.2. Tabla ‘location’ y sus columnas ..................................................... 44

viii

Indice de Figuras

4.1. Arquitectura del sistema.............................................................. 19

4.2. Modelo conceptual ..................................................................... 20

5.1. Interfaz de usuario para inicio de sesion .......................................... 28

5.2. Mensaje de error en login............................................................. 29

5.3. Interfaz de usuario de registro....................................................... 30

5.4. Seleccion de foto a partir de camara del equipo ................................ 31

5.5. Diagrama de interaccion entre las funciones de la aplicacion cliente ...... 33

5.6. Interfaz de usuario de la ‘vista mapa’ ............................................. 34

5.7. Interfaz de usuario de la ‘vista mapa’ (hıbrida) y sus elementos ........... 34

5.8. Interfaz de usuario para detalle de usuario ...................................... 36

5.9. Vistas generadas al realizar llamada............................................... 36

5.10. Interfaz de usuario para editar mensaje de estado ............................. 38

5.11. Ejemplo de mensaje JSON utilizado en el sistema............................. 39

5.12. Mostrar listado de usuarios .......................................................... 40

5.13. Mostrar un usuario ..................................................................... 40

5.14. Mostrar posiciones...................................................................... 41

5.15. Respuesta al registrar un usuario................................................... 41

5.16. Respuesta al ingresar una nueva posicion ........................................ 42

5.17. Respuesta al modificar mensaje de estado de usuario ......................... 42

5.18. Diagrama de tablas de la base de datos .......................................... 44

5.19. Disparador que modifica la tabla ‘user’ al insertar en tabla ‘location’ .... 45

5.20. Evento para eliminar registros expirados ......................................... 45

6.1. Error en respuesta HTTP servidor REST........................................ 47

6.2. Ambientes de medicion 3G de (a) alto trafico y (b) bajo trafico ........... 48

6.3. Latencia para obtencion de datos desde servidor............................... 49

6.4. Tiempo de generacion de anotaciones en mapa ................................. 50

ix

INDICE DE FIGURAS x

8.1. Disposicion de ofertas comerciales de acceso movil a internet a nivel

comunal. (fuente: Subtel 2009 [5]).................................................. 55

8.2. Reporte de trafico de datos por dispositivos por paıs (fuente: ComSco-

re. Mayo 2011 [6] ....................................................................... 56

8.3. Definicion de un objeto JSON. (fuente: www.json.org 2011 [29]) .......... 57

8.4. Definicion de un arreglo JSON. (fuente: www.json.org 2011 [29]).......... 57

8.5. Definicion de un valor JSON. (fuente: www.json.org 2011 [29]) ............ 57

8.6. Archivo de configuracion Symfony ‘schema.yml’ ............................... 58

8.7. Archivo de configuracion Symfony ‘fixtures.yml’ ............................... 59

Glosario

3G Tercera generacion de transmision de voz y datos a traves de telefonıa movil. Los

servicios 3G proporcionan la posibilidad de transferir tanto voz y datos (como

la descarga de programas, intercambio de email, y mensajerıa instantanea).

clave foranea En el contexto de bases de datos relacionales, una clave foranea iden-

tifica una columna en una tabla (hija) que se refiere a una columna o grupo de

columnas en otra tabla (maestra).

clave primaria En diseno de bases de datos relacionales, se llama clave primaria a

un campo o a una combinacion de campos que identifica de forma unica a cada

fila de una tabla.

control de flota Sistema de seguimiento de vehıculos basado en GPS que determina

la ubicacion de un vehıculo, y ası gestionar el control sobre los mismos.

Darwin BSD Sistema operativo tipo UNIX basado en BSD que proporciona una

alta estabilidad y rendimiento.

disparador Mas conocido como Trigger, es un procedimiento de bases de datos que

se ejecuta cuando se cumple una condicion establecida al realizar una operacion,

por ejemplo modificar en elemento de una tabla cuando se inserta una fila en

otra tabla.

GPS Global Positioning System: sistema de posicionamiento global es un sistema

global de navegacion por satelite que permite determinar en todo el mundo la

posicion de un objeto, una persona o un vehıculo.

hebra En un programa informatico es una tarea que puede ser ejecutada en para-

lelo con otra tarea, compartiendo ciertos recursos como la memoria o archivos

abiertos.

xi

Glosario xii

iOS Sistema operativo movil de Apple desarrollado originalmente para el iPhone,

siendo despues usado en el iPod Touch e iPad. Es un derivado de Mac OS X,

que a su vez esta basado en Darwin BSD.

JSON Siglas en ingles de JavaScript Object Notation, es un formato para inter-

cambiar datos sencillos, entendiendo como sencillos el texto, los numeros y los

valores logicos, pudiendo estar organizados en estructuras. Es analogo a XML.

latencia Corresponde a la suma de retardos temporales dentro de una red. Un re-

tardo es producido por la demora en la propagacion y transmision de paquetes

dentro de la red.

MySQL Sistema de gestion de bases de datos relacional multiusuario, multiplata-

forma.

Objective-C Lenguaje de programacion orientado a objetos que se usa como len-

guaje principal para plataformas Mac OS X y iPhone.

PHP Acronimo Hypertext Pre-processor es un lenguaje de programacion disenado

originalmente para la creacion de paginas web dinamicas.

plug-in Es un modulo de software que anade una caracterıstica o un servicio es-

pecıfico a un sistema mas grande.

servicios de localizacion Servicios basados en mapas para dispositivos moviles ca-

paces de entregar informacion relativa a la posicion geografica del equipo.

smartphones Es el termino comercial para denominar a un telefono movil inteli-

gente, que ofrece mas funciones que un telefono celular comun, que soporta la

instalacion de programas para incrementar el procesamiento de datos y conec-

tividad.

WSDL El lenguaje de descripcion de servicios Web (Web Service Description Lan-

guage) es un dialecto basado en XML sobre el esquema que describe un servicio

Web. Un documento WSDL proporciona la informacion necesaria al cliente para

interactuar con el servicio Web..

Glosario xiii

XML Acronimo de la expresion inglesa eXtensible Markup Language. Es un lenguaje

para definir, validar y compartir formatos de documentos en la Web. El uso de

XML para la comunicacion entre aplicaciones se caracteriza por proveer una

representacion de los datos muy simple, facil de transmitir por la red, estandar.

En los ultimos tiempos este uso se esta haciendo muy popular con el surgimiento

de los Servicios web.

1 Introduccion

NO se puede entender una idea sin entender el contexto en el que ella se desarro-

lla, hoy nos encontramos viviendo la segunda decada del siglo XXI, muchas de

las vallas que veıamos al comenzar el milenio, hoy ya dejaron de ser obstaculos y se

han convertido en parte de la realidad.

Hoy la telefonıa es movil, un concepto cuya genesis algunos tuvieron la suerte

de vivir, pero que a las generaciones actuales ya no sorprende. Actualmente somos

capaces de transmitir datos a alta velocidad en sofisticados equipos que distan mucho

de ser simples telefonos, son equipos capaces de reproducir videos en lınea, conectarse

a internet, y lo que es mas relevante para el trabajo realizado, mostrarnos donde

estamos ubicados en el mapa, es decir, geo-localizarnos.

1

1.1 Identificacion del problema 2

1.1. Identificacion del problema

Para muchos es conocido el concepto de control de flota, sistema que permite a

traves de la localizacion por satelite (GPS) ver sobre un mapa donde estan en todo

momento vehıculos de empresas, y ası controlar el cumplimiento de recorridos u ob-

jetivos, lo que permite optimizar recursos.

Sin embargo, este sistema esta potencialmente incompleto y deja abierta las si-

guientes preguntas:

¿Por que tiene que estar limitado a vehıculos?

Existe una cantidad importante de personas que la mayor parte del dıa se movilizan

en transporte publico, a pie o en combinacion de distintos medios de transporte, para

las cuales la solucion actual esta fuera de contexto.

¿Solo las empresas necesitan esta tecnologıa?

Esta caracterıstica puede tener muchos otros usos fuera del empresarial, como por

ejemplo servicios publicos como policıa, o bien redes sociales como grupos de amigos.

¿Puede implementarse en dispositivos portables?

Hoy en dıa es perfectamente posible que esta tecnologıa acompane a las personas, y

no solo a vehıculos, esto debido a que una parte importante de los telefonos moviles

inteligentes cuentan con algun grado de tecnologıa de localizacion (GPS), sobre todo

en nuestro paıs, donde el costo de un equipo de estas caracterısticas es el menor de

Latinoamerica [1].

¿Podrıa el punto monitorizado ver a otros puntos?

El control hoy en dıa es principalmente centralizado, las partes monitoreadas en ge-

neral no estan en conocimiento en tiempo real sobre la posicion de otros miembros

de la red.

¿Se puede reducir costos?

El envıo de datos por celular a traves de los modulos de comunicacion de equipos

GPS para control de flota tiene un costo, por otro lado la mayor parte de quienes

utilizan estos servicios son suscriptores planes de voz y datos adicionales, por lo que

potencialmente existe una redundancia de suscripcion de datos.

1.2 Objetivos del proyecto 3

¿Por que no pueden comunicarse los distintos puntos monitorizados?

Los equipos de monitoreo instalados en vehıculos estan disenados para el envıo dis-

creto de datos, y no permiten la comunicacion de voz.

1.2. Objetivos del proyecto

El objetivo principal de este proyecto es el desarrollo de un sistema que permita

resolver las limitaciones expuestas. Es decir:

Una aplicacion para dispositivo movil capaz de enviar la posicion geografica del

dispositivo (coordenadas de latitud y longitud) a un servidor y almacenarla en

una base de datos.

El sistema debe poseer una aplicacion con una interfaz grafica que permita

mostrar en un mapa a cada usuario la posicion del resto de los usuarios del

sistema y monitorearlos en tiempo real.

La aplicacion debe permitir la comunicacion entre los distintos usuarios del

sistema, por ejemplo, a traves de una llamada telefonica.

Se debe llevar a cabo el proyecto utilizando tecnologıa que ya esta ampliamente

distribuida, pero que hasta el momento no ha sido explotada a cabalidad, con

el objetivo de reducir los costos y aumentar las funcionalidades.

2 Estado del arte

2.1. Telefonıa celular e internet movil

El crecimiento de la telefonıa celular en Chile durante la ultima decada llego a su

punto culmine en 2009, en que nuestro paıs se convirtio en el tercero en Latinoamerica

en alcanzar el 100 % de penetracion en telefonıa movil, es decir un habitante

por telefono [2].

Durante el 2010 el aumento continuo y hoy hay 21 millones de abonados a las

tres empresas de telefonıa movil en nuestro paıs. Un factor que empuja al sector y

que motiva el crecimiento de los contratos es la banda ancha movil, que se ha visto

impulsada por el auge de las redes sociales [3].

En cuanto a banda ancha movil, Chile presenta una penetracion del 18 %, versus

el 21 % que aun retiene la banda ancha vıa cable. Se espera que en el paıs, la banda

ancha movil supere a la fija en el 2012 [4].

Con respecto a la cobertura de la banda ancha, segun los ultimos antecedentes

de la Subsecretarıa de Telecomunicaciones de Chile existen 25 comunas sin acceso a

internet residencial, sin embargo solo 9 comunas en todo chile no disponen de acceso

movil a internet mediante tecnologıas 3G [5] (ver figura 8.1 del apendice), es decir, la

cobertura geografica de la banda ancha movil es mayor que la de internet

residencial.

2.2. Telefonos inteligentes

En la actualidad en Chile el 45.2 % del trafico de datos en equipos moviles

es generado por equipos iPhone, siendo su competidor mas cercano, pero aun

lejano, la plataforma Android con el 13.9 % [6], en este sentido Chile destaca tambien

4

2.3 Tecnologıas necesarias 5

en ambito global siendo el cuarto paıs con mas penetracion de iPhone tomando como

referencia el trafico, estos datos se pueden ver en detalle en la figura 8.2 del apendice.

Con respecto a las plataformas para dispositivos moviles, segun las ultimas es-

tadısticas [7] Android y iPhone continuan en crecimiento, mientras que RIM

(Blackberry) ha iniciado su descenso en el mercado.

En los EEUU el Android OS de Google capto un 34.7 % del mercado de celulares

inteligentes en el mes de marzo 2011, un crecimiento de 6 puntos con relacion a di-

ciembre 2010. Por su parte, iPhone obtuvo un 25.5 % del mercado para un crecimiento

de 0.5 puntos [7].

La lista de los fabricantes mas grandes de celulares inteligentes a nivel mundial

queda de esta manera por el momento:

1. Nokia con 24.2 millones de celulares vendidos

2. Apple con 18.7 millones

3. RIM/Blackberry con 13.9 millones

4. Samsung con 10.8 millones

5. HTC con 8.9 millones

En cuanto a fabricantes, Nokia es numero uno debido a que fabrica decenas de

modelos. En cuanto a plataformas Android es el primero a nivel mundial debido a que

varias empresas fabrican celulares Android (como Samsung, HTC, Sony y Motorola),

sin embargo como equipo celular el iPhone es el actual lıder indiscutible en

el mundo [7].

Del total de los equipos celulares en Chile, se calcula que 3,5 millones corres-

ponden a smartphones o telefonos inteligentes que permiten acceder a correo movil,

navegar en internet y usar mensajerıa instantanea. De hecho, durante 2010, el 22 %

de los equipos vendidos correspondio a esta categorıa [8].

2.3. Tecnologıas necesarias

A continuacion se describen las tecnologıas necesarias para la elaboracion del

sistema propuesto


2.3.1. Servicio de cartografıa en la web y localizacion

Se le llama servicio de cartografıa en la web (en ingles web mapping) al servicio

requerido para visualizar datos geoespaciales a traves de la web. Para el desarrollo

de esta aplicacion se requiere una instancia especial de estos servicios que se conoce

como servicios de localizacion (en ingles location-based-services), que son servicios de

mapas para dispositivos moviles capaces de desplegar menus contextuales con infor-

macion relativa a la posicion del equipo.

El desarrollo de servicios web de localizacion en sistemas iPhone, Android, Black-

Berry, Nokia y Windows utilizan el servicio de Google Maps [9], que ofrece tanto

imagenes de mapas como imagenes satelitales del mundo entero a las cuales se les

permite hacer desplazamientos, acercamientos y alejamientos.

Mapkit [10] es el nombre del framework que permite incorporar el servicio de

Google Maps dentro de una aplicacion para iPhone, este framework tambien provee

el soporte para agregar pins (anotaciones) sobre un mapa y desplegar menus con in-

formacion relativa a estas anotaciones.

Si bien Mapkit puede desplegar informacion de servicios de localizacion, las coor-

denadas de posicion geografica usadas por este servicio son obtenidas desde el equipo

a traves del framework de Localizacion [11] (Core Location Framework). Este fra-

mework utiliza la informacion obtenida a partir del celular, WiFi o GPS del equipo

para triangular una posicion y ası obtener una coordenada.

En resumen, estos dos frameworks en conjunto entregan las herramientas necesa-

rias para el desarrollo de un Servicio de Localizacion.

2.3.2. Servidor web y base de datos

Para este proyecto se requiere de un servidor web que centralice, procese y dis-

tribuya la informacion de los usuarios del sistema y una base de datos que almacene

esta informacion. A continuacion se describen las razones para la eleccion del conjun-

to PHP-MySQL como entorno de desarrollo para servidor.

PHP es un lenguaje de desarrollo web escrito por y para desarrolladores web. Se

trata de un lenguaje script hecho para usarse del lado del servidor. La mayor parte


de lo que PHP realiza es invisible al usuario que puede tambien usarse para ejecutar

scripts de lıneas de comando.

MySQL es una base de datos relacional de codigo abierto, que ultimamente

ha encontrado un segmento importante de usuarios debido a su caracter liberal en

terminos de licencias, buen desempeno y facilidad de uso. Una base de datos solo es

util si dispone de una completa gama de software que la apoye [12]. A continuacion se

enumeran las caracterısticas que destacan del conjunto PHP-MySQL, y por las cuales

se ha escogido como plataforma de desarrollo web.

Costo

PHP es gratis, no hay un costo asociado a desarrollar ni ejecutar programas hechos

en PHP. A pesar de que las licencias de MySQL han cambiado, se puede obtener la

licencia MySQL Community Server Edition en forma gratuita [13].

Facilidad de uso

Comparado con otros lenguajes, en PHP es facil desarrollar potentes aplicacio-

nes en pocos minutos, fundamentalmente debido a que muchas funciones especıficas

como por ejemplo abrir y cerrar conexiones estan implementadas. Ademas para aque-

llos programadores acostumbrados a sintaxis C se vuelve un lenguaje facil de leer y

escribir.

Compatibilidad entre plataformas

Tanto PHP como MySQL corren en forma nativa en cada distribucion Linux/Unix

(incluyendo Mac OSX) y Windows, y un gran porcentaje de los servidores HTTP del

mundo ocupan estos sistemas operativos. PHP es compatible tanto con Apache (ser-

vidor web mas popular en plataformas Linux/Unix) y Microsoft Internet Information

Server (Windows).

Estabilidad

El concepto de estabilidad puede significar dos cosas:

El servidor no necesita ser reiniciado en forma habitual.

El software no cambia radicalmente, o se vuelve incompatible entre versiones.

En el primer sentido, el servidor Apache se caracteriza por ser el mas estable de los

servidores web, la mayor parte de los cambios se pueden realizar sin necesidad de


reiniciar el servidor, estas caracterısticas son inherentes en PHP.

Con respecto a las actualizaciones de software, PHP y MySQL tienen una filo-

sofıa de proyecto, que no adopta cada nueva tecnologıa que aparece, si no mas bien

esta orientado a un desarrollo incremental de su desempeno, comunicacion con bases

de datos y soporte a programacion orientada a objetos.

No propietario

PHP no esta atado a ningun sistema operativo (a diferencia de Active Server), no

esta comprometido con alguna plataforma cruzada (middleware) como Java Server o

ColdFusion. No esta ligado a algun navegador en especial, lenguaje de programacion

ni base de datos. Y a pesar de ser un lenguaje abiertamente antipropietario ni siquie-

ra esta atado a trabajar solo con software de codigo abierto. Esta independencia y

cooperativismo le otorgan a PHP una posicion de maxima flexibilidad.

Comunidad de usuarios

La principal ventaja para los usuarios novatos de PHP consiste en el soporte tecni-

co gratuito que otorga la comunidad, en las que desarrolladores avanzados son capaces

de convivir de igual a igual con inexpertos. Las listas de correo estan disponibles las 24

horas del dıa los 365 dıas del ano para responder inquietudes o ayudar con el debugeo.

MySQL en tanto, siendo codigo abierto licenciado es menos comunitario en cuanto

a su desarrollo, sin embargo cuenta con una creciente comunidad de usuarios que son

atentamente escuchados por el equipo (oficial) de desarrollo. Raramente un proyecto

de software responde tan eficazmente a una demanda de la comunidad como es el

caso de MySQL.

2.3.3. Servicios web

Un servicio web es una arquitectura de computacion distribuida que funciona a

traves de la web, que permite a las aplicaciones compartir informacion y que ademas

invoquen funciones de otras aplicaciones independientemente de como se hayan crea-

do, de cual sea el sistema operativo o la plataforma en que se ejecutan y cuales los

dispositivos utilizados para obtener acceso a ellas.

La principales razones para usar Servicios Web son [14]:


Pueden utilizar HTTP sobre TCP en el puerto 80. Dado que las organizaciones

protegen sus redes mediante firewalls que filtran y bloquean gran parte del

trafico de Internet, cierran casi todos los puertos TCP salvo el 80. Los servicios

Web utilizan este puerto, por la simple razon de que no resultan bloqueados.

Los servicios web aportan interoperabilidad entre aplicaciones de software in-

dependientemente de sus propiedades o de las plataformas sobre las que se

instalen.

Los servicios Web fomentan los estandares y protocolos basados en texto, que

hacen mas facil acceder a su contenido y entender su funcionamiento.

Pueden aportar gran independencia entre la aplicacion que usa el servicio Web

y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no

deben afectar al otro.

Hoy existen fundamentalmente 2 formas de implementar servicios web:

Protocolo Simple de Acceso a Datos (SOAP)

SOAP son las siglas de Simple Object Access Protocol, que es un protocolo stan-

darizado que define como intercambiar datos entre aplicaciones a traves de la web,

SOAP fue el primer protocolo de comunicacion bajo HTTP que uso XML [15].

Se caracteriza por [16]:

Ser rıgido, al apegarse a las especificaciones de sus descriptores (WSDL).

Poseer amplia cantidad de herramientas de desarrollo, con soporte de grandes

empresas.

Utilizar XML para el intercambio de mensajes.

Transferencia de Estado Representacional (REST)

REST (Represntational State Transfer) es mas bien una filosofıa antigua, cuya

realizacion ha llegado recientemente. Mientras SOAP pareciera ser un salto a una

nueva era de internet con un set de nuevas especificaciones, REST expone que con

los principios ya existentes se pueden construir servicios web robustos [16].

Sus caracterısticas mas importantes:

2.4 Softwares en la actualidad 10

Los objetos o recursos son representados por una URI

(ejemplo http://servidor/usuario/id/juan).

Utiliza peticiones HTTP (verbos) para manipular los recursos: se puede obtener

contenido usando GET, modificarlo usando POST o PUT y borrarlo mediante

DELETE.

No necesita herramientas de desarrollo especializadas.

El intercambio de mensajes puede realizarse ademas de XML en JSON u algun

otro formato, que lo hace mas liviano y por lo tanto mas rapido bajo ciertas

circunstancias.

2.4. Softwares en la actualidad

A continuacion se listan los principales sistemas informaticos que existen hoy en

dıa y que permiten localizar telefonos celulares inteligentes (smartphones), ası mismo

se hace una descripcion de la tecnologıa que usan.

2.4.1. DondeEsta

DondeEsta [17] es un software disenado inicialmente para la plataforma Symbian

(hoy trabaja tambien en Windows Mobile y Blackberry) que entrega la posicion de

un equipo. Este software no entrega la posicion en forma continua en tiempo real,

sino que envıa su posicion cuando otro usuario (previamente autorizado) le envıa un

mensaje de texto al equipo cliente con el requerimiento.

Existe un costo asociado (SMS) cada vez que el equipo envıa su posicion.

2.4.2. Cabulous

Cabulous [18] Es la aplicacion mas completa y parecida al software realizado,

esta hecho para iPhone, entrega la localizacion geografica en tiempo real y permite

la comunicacion entre las partes.

Cabulous esta hecha unicamente para la comunicacion entre taxistas y pasajeros,

y la aplicacion controla un protocolo de comunicacion para la contratacion del servi-

cio de taxi (necesario para su modelo de negocio en que se cobra por este servicio al

2.4 Softwares en la actualidad 11

taxista), no permite hacer una llamada telefonica entre las partes en forma directa.

Como se trata de un unico servicio y red de usuarios, no tiene ningun tipo de res-

triccion de quien utiliza el sistema, por lo que tampoco requiere registro de usuarios

ni inicio de sesion para el pasajero.

2.4.3. Ndonde

Ndonde [19] es una aplicacion disenada para la plataforma Android, es muy com-

pleta y su objetivo es el mismo del software que se desarrolla en este trabajo de

memoria: ubicar en tiempo real a otro dispositivo. Tambien funciona almacenando

las posiciones en un servidor central y distribuyendo estos datos a los otros equipos.

Las diferencia fundamentales es su incapacidad de establecer algun grado de co-

municacion con otros usuarios.

2.4.4. InstaMapper

InstaMapper [20] es una aplicacion de geolocalizacion para iPhone cuyo objetivo

es enviar la posicion del equipo a un servidor central y monitorear los equipos a traves

de la web, pero no despliega un mapa en el equipo movil ni informacion sobre otros

usuarios. Tampoco corre en segundo plano, ni tiene opciones de comunicacion con

otros usuarios.

2.4.5. goGlyph

goPlyph [21], desarrollado para iPhone, es un sistema que permite localizar a otros

usuarios, pero tambien esta orientado a compartir informacion sobre el lugar en que

se encuentran las personas. Su objetivo es una red social para compartir lugares, no

posiciones instantaneas.

2.4.6. Lugares (Facebook)

Lugares [22] (originalmente Places en ingles) es un sistema compatible con iPhone,

BlackBerry, Android, HP webOS y Windows Phone 7, que permite compartir la po-

sicion actual con los contactos del usuario en la red Facebook. El usuario es quien

2.5 Tabla Comparativa 12

controla cuando compartir su posicion por lo que no entra en la categorıa de una

aplicacion de monitoreo.

2.5. Tabla Comparativa

Software Tiempo Segundo Comuni- Costo Plata- Ambito

real Plano cacion forma

Localizador X X Llamada Plano iPhone Personal

Empresa

Publico

Cabulous X X No Por iPhone Taxi

enlace

DondEsta No No No Por iPhone Personal

SMS Symbian

Windows

Ndonde X X No Mensual Android Personal

Empresa

Publico

InstaMapper X No No Plano iPhone Personal

Empresa

Publico

GoGlyph No X No Plano iPhone Publico

Lugares No X No Plano iPhone Personal

Blackberry

Windows

HP webOS

Tabla 2.1. Comparacion de softwares localizadores para moviles

3 Analisis de requerimientos

Al desarrollar un producto nuevo es necesario determinar los requerimientos y

caracterısticas que debera tener, basandose en las experiencias anteriores, productos

similares, buenas practicas y sugerencias realizadas por clientes y desarrolladores.

3.1. Requerimientos funcionales

Los requerimientos funcionales definen las funciones que el sistema sera capaz de

realizar, para cumplir con su objetivo.

Entrega datos de posicion

El software en el dispositivo debe ser capaz de obtener su posicion geografica y

de entregar esta informacion a un servidor centralizado a un intervalo de tiempo que

debe ser instantaneo para efectos practicos, todo esto sin mas intervencion del usuario

que su previa autorizacion.

Obtencion de posicion de otros usuarios

El sistema almacena la posicion de todos los usuarios del grupo, y debe distribuir

esta informacion al resto de los usuarios. Al igual que la entrega, la obtencion debe

ser transparente al usuario y realizarse en forma automatica.

Registro e Inicio de sesion de Usuario

El software debe poseer la capacidad de registrar nuevos usuarios en el sistema

y almacenar los datos de registro (nombre, clave, telefono) en una base de datos

centralizada. Tambien debe poseer la capacidad de iniciar sesion en el sistema a un

usuario previamente registrado mediante su nombre de usuario y contrasena.

13

3.2 Requerimientos no funcionales 14

Despliegue de datos a traves de Interfaz grafica

Los datos de posicion tanto del usuario como del resto de los miembros del sistema

debe poder desplegarse mediante una interfaz grafica dentro del equipo movil, que

muestre en un mapa la ubicacion geografica de los usuarios del sistema. Ademas de la

posicion debe poderse desplegar informacion entregada por los usuarios al momento

del registro como por ejemplo: foto, nombre o descripcion.

Comunicacion con otros usuarios

El sistema debe incluir en su interfaz grafica un boton para que cuando sea necesa-

rio un miembro del grupo pueda establecer comunicacion telefonica con otro usuario

del sistema. Ademas se debe otorgar al usuario la posibilidad de dejar un mensaje

que comunique al resto de los usuarios sobre su estado actual.

Ejecucion en segundo plano

El software debe ser capaz de continuar entregando informacion de su posicion

aun cuando el usuario haya dejado de usar la aplicacion, el equipo se encuentre en

reposo o este usando otras aplicaciones (por ejemplo navegando por internet, llaman-

do, escuchando musica o respondiendo emails). Esta caracterıstica se conoce tambien

como posibilidad de ejecutar la aplicacion en segundo plano (Background en ingles).

3.2. Requerimientos no funcionales

Los requerimientos no funcionales, como su nombre siguiere, son aquellos reque-

rimientos que no se refieren directamente a las funciones especıficas que proporciona

el sistema, si no a las propiedades emergentes de este como la fiabilidad y tiempos de

respuesta.

Los requerimientos no funcionales rara vez se asocian con caracterısticas particula-

res del sistema. Mas bien, estos requerimientos especifican o restringen las propiedades

emergentes del sistema. Por lo tanto pueden especificar el rendimiento del sistema,

la proteccion, la disponibilidad y otras propiedades emergentes. Esto significa que a

menudo son mas crıticos que los requerimientos funcionales particulares [23].

3.2.1. Requerimientos del producto

Estos requerimientos especifican el comportamiento del producto


Rapidez

El tiempo de respuesta al usuario y a eventos de comunicacion no debe superar

los 10 segundos, esto debe incluir tiempo para registro de usuarios, autenticacion en

el sistema y para mostrar a otros usuarios del sistema en mapa.

Con respecto al tiempo de actualizacion de la pantalla, por ejemplo despliegue

de menus o ver opciones, debe parecer instantaneo al usuario, con un lımite de un

segundo de espera.

Facilidad de uso

El tiempo de formacion para un usuario que no conoce el sistema y que no ne-

cesariamente tenga habilidades con productos tecnologicos no debe ser superior a su

primera experiencia con la aplicacion movil, considerando que el registro, autentica-

cion y uso del software no supera los 5 minutos de uso, este entrenamiento inicial

debe bastar para aprender a usar la aplicacion en sesiones futuras.

Robustez

El sistema debe ser capaz de responder apropiadamente ante situaciones que es-

capen a las condiciones normales de funcionamiento del software, por ejemplo un

numero excesivamente grande de usuarios, o falta de memoria en el sistema. Se debe

contemplar el uso de medidas preventivas y mensajes de advertencia.

3.2.2. Requerimientos externos

Son aquellos requerimientos que se derivan de los factores externos al sistema y de

su proceso de desarrollo, se incluyen requerimientos de interoperabilidad que definen

la manera en que el sistema interactua con sistemas de otras organizaciones como por

ejemplo requerimientos legislativos y eticos que aseguren que el sistema sera aceptado

por los usuarios y el publico en general [23].

Cumplir con normas legales

El sistema debe cumplir con las normas chilenas de privacidad, para ellos el usuario

debe autorizar previamente la instalacion del software y permitirle expresamente a la

aplicacion entregar sus datos de localizacion.


Proteccion de datos personales

El sistema no debera revelar a otros usuarios informacion personal fuera de la

necesaria para la funcionalidad del sistema.

4 Analisis y diseno

En esta seccion se describen los distintos modulos implementados en el software

y como se abordo cada uno de ellos.

4.1. Descripcion general del sistema

En este proyecto hablamos de un sistema de telecomunicaciones basado en ser-

vicios de localizacion web, compuesto basicamente de dos modulos que interactuan

entre ellos y con la web. Estos dos modulos son:

Una aplicacion en el equipo iPhone encargada de enviar sus coordenadas

geograficas al segundo modulo.

Un Servidor web, que distribuye la informacion de posicion geografica entre

los distintos equipos conectados a el.

La aplicacion iPhone se conecta a Google Maps para descargar las imagenes satelita-

les o mapas y marcar sobre ellas la posicion de los usuarios del sistema.

4.2. Arquitectura

El sistema de Geo-localizacion para iPhone se diseno con una arquitectura de

cliente-servidor, cuyos miembros se resumen a continuacion:

4.2.1. Aplicacion cliente

Corresponde a la aplicacion que se instala en el equipo movil, en este caso iPhone,

y que es la encargada de:

17

4.2 Arquitectura 18

Obtener los datos de posicion desde el equipo y enviarselos al servidor web.

Recuperar desde el servidor web las posiciones del resto de los clientes del sis-

tema.

Utiliza Google Maps para cargar las imagenes satelitales o de mapa desde la

web.

Enviar mensaje de estado del usuario al servidor, que puede ser visto por el

resto de los clientes del sistema.

Tanto el envıo como la recepcion de informacion desde la aplicacion al servidor

se realiza mediante mensajes JSON y servicios web (protocolo HTTP), este punto se

explica en detalle en la seccion 5.2 (implementacion del servidor).

4.2.2. Servidor web

La aplicacion cliente tiene el potencial de conectarse directamente a bases de datos

y poder escribir y hacer consultas en ella, entonces ¿Por que usar un servidor web?

razones hay muchas:

En la mayorıa de las redes de internet movil el acceso esta limitado a los puertos

HTTP, bloqueando puertos que ocupan las bases de datos.

Para mantener la privacidad de la logica del negocio y por seguridad no es bueno

almacenar en cada dispositivo movil informacion como la direccion, nombres de

usuario y contrasenas para conectarse a una base de datos.

Al usar un servidor web, el sistema podrıa migrar a una base de datos distinta,

sin tener que cambiar la aplicacion en cada uno de los equipos moviles.

El servidor web es la parte del sistema que se encarga de:

Obtener los datos de registro y autenticacion de los usuarios del sistema.

Obtener la posicion de cada usuario (coordenada) y guardarla en la base de

datos.

Reunir las posiciones de los usuarios a partir de la base de datos y entregar este

conjunto de coordenadas a la aplicacion cliente para que esta las muestre en un

mapa.

Recibir, almacenar en la base de datos y distribuir el mensaje de estado del

usuario cuando este lo actualice.

4.3 Modelo conceptual 19

4.2.3. Base de datos

Es el lugar en el que el servidor web almacena en forma historica los datos que

obtiene de cada usuario. El servidor web escribe y lee directamente en la base de

datos.

4.2.4. Google Maps

Es el servicio de Google que a traves del framework MapKit de Apple envıa las

imagenes satelitales o de mapa a la aplicacion cliente para mostrar la ubicacion de

los usuarios.

La figura 4.1 muestra la interaccion de las partes del sistema recien descritas de

la arquitectura del sistema.

Figura 4.1. Arquitectura del sistema

4.3. Modelo conceptual

Los requerimientos del usuario deberıan redactarse en lenguaje natural debido a

que tienen que ser comprendidos por personas que no son tecnicos ni expertos. Sin

embargo, pueden expresarse requerimientos del sistema mas detallados de forma mas

tecnica.

Una tecnica ampliamente usada es documentar la especificacion del sistema con

modelos del sistema, que son representaciones graficas que describen los procesos del

4.3 Modelo conceptual 20

sistema, el problema a resolver y el sistema que tiene que ser desarrollado [23].

La figura 4.2 muestra el diagrama del modelo conceptual (los distintos modulos

estan escritos en ingles para ser conservar la consistencia con los lenguajes de pro-

gramacion). En el modelo conceptual se muestra en detalle como se estructuran los

datos y la relacion que hay entre ellos en cada uno de los modulos descritos en la

arquitectura.

En la base de datos se almacenan los datos del usuario y en forma historica sus

posiciones, el servidor recoge esta informacion y forma un mensaje JSON que es

entregado al mapa de la aplicacion. El mapa a su vez separa de este mensaje los

usuarios conectados y le otorga a cada uno de ellos un pin (anotacion) dentro de la

aplicacion.

Figura 4.2. Modelo conceptual

4.4 Casos de uso del sistema 21

4.4. Casos de uso del sistema

Los casos de uso representan los requisitos funcionales del sistema. Son Conjun-

tos de secuencias que reflejan la interaccion entre los elementos externos al sistema

y el propio sistema, es decir, se trata de una descripcion de escenarios o situaciones

posibles donde se expone el comportamiento del sistema ante el uso por parte del

usuario [24].

El objetivo principal de incorporar los casos de uso en la etapa de Analisis y Di-

seno de la aplicacion es definir el lımite entre el sistema en desarrollo y los elementos

externos (en este caso los usuarios).

Las siguientes tablas son flujos de eventos de caso de uso y expresan lo que debe

hacer el sistema, sin tener en cuenta como debe hacerlo.

4.4.1. Registro de usuario

Nombre Registro de usuario

Actor principal Usuario

Interes Registrarse en el sistema para poder operar como

usuario valido e iniciar sesion.

Precondiciones El usuario ha instalado y ejecutado la aplicacion.

Postcondiciones Se registra el usuario en el sistema y podra iniciar

sesion en el futuro.

Escenario principal 1. El usuario pulsa sobre el ıcono para registrarse.

de exito 2. Ingresa los datos solicitados: nombre de usuario,

contrasena, telefono, etc.

3. Selecciona una foto o obtiene una mediante la

camara integrada en el equipo.

4. Pulsa sobre el boton en registrar.

5. Recibe confirmacion del sistema si la operacion se

realizo con exito, mensaje de error en caso contrario.

6. El usuario puede ir al caso de uso ‘iniciar sesion’.

Tabla 4.1. Caso de uso: ‘registro de usuario’


4.4.2. Inicio de sesion de usuario

Nombre Inicio de sesion de usuario


Interes Ingresar al sistema para poder enviar la

posicion propia y la del resto de los usuarios.


El usuario se ha registrado previamente.

Postcondiciones Se registra el usuario en el sistema y podra iniciar

sesion en el futuro.

Escenario principal 1. El usuario teclea el nombre de usuario y contrasena.

de exito en los casilleros correspondientes.

2. Pulsa sobre el ‘boton login’.

3. Recibe confirmacion del sistema

si la operacion se realiza con exito.

4. Se despliega el mapa que muestra la ubicacion

propia y de los otros usuarios.

Tabla 4.2. Caso de uso: ‘inicio de sesion’


4.4.3. Editar mensaje

Nombre Editar mensaje


Interes Poder editar, y comunicar el mensaje de estado

al resto de los usuario.



El usuario ha iniciado sesion y se encuentra en la ‘vista mapa’.

Postcondiciones Se actualiza el mensaje de estado en la base de datos.

Escenario principal 1. El usuario pulsa sobre el ‘editar mensaje’

de exito 2. El sistema despliega el vista para editar mensaje

con el mensaje actual en pantalla.

3. Al hacer click en el mensaje el usuario lo puede editar.

4. Al finalizar hace click en ’boton enviar’.

5. El usuario puede ir al caso de uso ‘ver detalles de usuario’

Tabla 4.3. Caso de uso: ‘editar mensaje’


4.4.4. Ver detalles de usuario

Nombre Ver detalles de usuario


Interes Poder ver detalles de otros usuarios del sistema:

foto, nombre, descripcion.



Existen otros usuarios en el sistema conectados.

El usuario ha iniciado sesion y se encuentra en la ‘vista mapa’.

Postcondiciones Se despliega la informacion del otro usuario en pantalla.

Escenario principal 1. El usuario pulsa sobre el ‘ıcono del usuario’ (pin)

de exito que quiere ver detalles.

2. El sistema despliega el menu contextual con una foto

pequena del usuario y el ıcono ‘ver detalle’.

3. Se despliega vista de detalles de usuario con una

imagen ampliada del usuario, su mensaje de estado y el

boton ‘llamar a usuario’

4. El usuario puede ir al caso de uso ‘llamar usuario’

o puede volver al mapa.

Tabla 4.4. Caso de uso: ‘ver detalles de usuario’


4.4.5. Llamar a usuario

Nombre Llamar a usuario

Actor Principal Usuario

Interes Poder comunicarse telefonicamente con otro usuario

que este conectado al sistema..



Existen otros usuarios en el sistema conectados.

El usuario se encuentra en caso de uso ‘ver detalles de usuario’.

Postcondiciones Se despliega la informacion del otro usuario en pantalla.

Escenario principal 1. El usuario pulsa sobre el ıcono ‘llamar a usuario’

de exito (ıcono con aspecto de equipo celular).

2. Se realiza la llamada al numero registrado por el otro usuario.

Tabla 4.5. Caso de uso: ‘llamar a usuario’.

5 Implementacion del sistema

5.1. Aplicacion cliente

5.1.1. Plataforma

La aplicacion cliente ha sido desarrollada en iPhone, por las razones ya expuestas

en la seccion 2.

iPhone funciona con el sistema operativo iOS basado en Darwin BSD, cuya version

al momento de realizar este trabajo es la 4.3.3.

Requisitos

Para poder programar para esta plataforma es necesario:

iOS SDK es el kit de desarrollo para la plataforma iOS, incluye frameworks,

compilador cruzado (para procesador ARM), Xcode y el simulador Aspen. El

iPhone SDK puede ser descargado en forma gratuita.

Xcode es el entorno de desarrollo para el lenguaje Objective-C que permite

manejar tanto la programacion y debuggeo de las funciones, el diseno de la

interfaz de usuario y la instalacion de certificados de licencias. Se descarga e

instala junto al iPhone SDK.

Licencia de desarrollo, es de pago [25] y sin ella no se pueden obtener los certifi-

cados necesarios para instalar las aplicaciones desarrolladas en equipos reales, lo

que es absolutamente necesario cuando se trabaja con localizacion, que es una

caracterıstica que no puede ser simulada. La licencia ademas da acceso al foro

oficial de desarrolladores iOS donde se puede acceder a informacion confidencial

sobre tecnologıas en desarrollo para futuras implementaciones del iOS.

26

5.1 Aplicacion cliente 27

Patron Modelo-Vista-Controlador

El desarrollo de aplicaciones con interfaz grafica en iOS utiliza el patron de diseno

Modelo-Vista-Controlador [26] (MVC), que es una forma de dividir el codigo en partes

funcionalmente independiente:

El modelo es el encargado de modelar y mantener la integridad de los datos.

La vista corresponde a la interfaz de usuario de la aplicacion y no se relaciona

directamente con el origen de los datos mostrados en su interfaz.

El controlador es la parte del codigo en la que actua como puente entre el modelo

y la vista, y es donde se realiza la mayor parte de la tarea de programacion de

la aplicacion

5.1.2. Vistas

Dado que la vista corresponde a lo visible por el usuario, resulta facil explicar las

distintas partes de la aplicacion cliente a partir de las vistas.

Inicio de sesion

Vista que contiene un formulario con el nombre de usuario y contrasena para que

el usuario pueda ingresar al sistema.

Funciones

• login

Funcion que es accionada al presionar el ‘boton login’. A traves de HTTP

POST envıa los datos del usuario al servidor, este devuelve un codigo de

respuesta HTTP [27], que es interpretado por la funcion login como una

autenticacion exitosa, o error en caso de que el usuario no este registrado,

la contrasena sea incorrecta o no sea posible establecer conexion con el

servidor, en estos casos se despliega un mensaje como el de la figura 5.2.

• registro

Accion que lleva al formulario de registro para usuarios no registrados.

Interfaz de Usuario

La vista de ‘inicio de sesion’ (figura 5.1) tiene en su interfaz los siguientes

elementos:


1. Registrar: Boton con el que se va a la ‘vista registro’.

2. Formulario: Campo en el que se solicitan nombre de usuario y contrasena

para ingresar al servicio.

3. Login: Boton para enviar los datos del formulario e iniciar sesion en el

sistema.

Figura 5.1. Interfaz de usuario para inicio de sesion


Figura 5.2. Mensaje de error en login

Registro de usuarios

Vista que contiene un formulario para que nuevos usuarios puedan crearse una

cuenta en el sistema.

Funciones

• registrar

A traves de HTTP POST envıa los datos de registro al servidor, este de-

vuelve un codigo de respuesta, que es interpretado por la funcion registrar

como un registro exitoso o un codigo de error.

• getPhoto

Funcion que se encarga de capturar una foto, desde la galerıa personal del

usuario, o bien toma una foto utilizando la camara integrada en el iPhone,

esta foto identificara al usuario en el sistema.

Interfaz de usuario

La vista del registro (figura 5.3) tiene en su interfaz los siguientes elementos:

1. Formulario: solicita los datos del usuario: nombre de usuario, telefono y

contrasena.


2. Elegir Foto: Da la opcion de obtener la fotografıa desde la librerıa de fotos

del usuario, o bien a partir de la camara del iPhone (figura 5.4).

3. Foto de Usuario: En este lugar se muestra la foto elegida por el usuario.

4. Boton Registrar: Envıa el formulario y su foto a la base de datos de usua-

rios.

5. Volver: Boton para regresar a ‘vista login’.

Figura 5.3. Interfaz de usuario de registro


Figura 5.4. Seleccion de foto a partir de camara del equipo

Mapa

Esta es la principal vista de la aplicacion cliente y se accede a ella despues de

iniciar sesion satisfactoriamente. Se visualiza la posicion del resto de los usuarios del

sistema y se puede interactuar con ellos.

Funciones

A continuacion se describen las funciones mas importantes utilizadas en esta

vista:

• viewDidLoad

Es la funcion principal y que debe ir en cualquier aplicacion para iOS,

se encarga de ejecutar todas las acciones iniciales al cargar una vista. En

ella se definen las posiciones iniciales en el mapa, y se hacen los primeros

llamados al resto de las funciones. Esta funcion inicia una hebra para la

ejecucion iterativa a intervalos de tiempo (normalmente 10 segundos) de

la funcion mostrarPuntos.

• mostrarPuntos

Esta funcion lleva al mapa como anotaciones una lista de posiciones que

obtiene al llamar a la funcion updateLocation.


• updateLocation

Funcion que se encarga del intercambio de mensajes de escritura y lectura

con el servidor:

Obtiene los datos de posicion del equipo iPhone y los envıa al servidor por

HTTP POST.

Adquiere por HTTP GET las posiciones de los otros usuarios. Las posicio-

nes son entregadas por el servidor en un mensaje JSON que es deserializado

e ingresados a una estructura de datos propia del lenguaje Objective-C, a

este arreglo se le llama diccionario.

• jsonParser

Librerıa externa utilizada por funcion updateLocation para deserializar un

mensaje JSON y llevarlo a objeto diccionario.

• mostrarPin

Funcion que se encarga del despliegue de un pin, que es la representacion

grafica de una anotacion (annotation), tambien se encarga del despliegue

del menu asociado a cada anotacion con sus respectivos ıconos (imagen de

usuario, texto con nombre y descripcion e iconos).

• detalle

Accion gatillada por el boton ‘detalle de usuario’ para cambiar a la vis-

ta ‘detalle de usuario’. Se pasa el parametro del usuario seleccionado del

mapa.

• editStatus

Accion gatillada por el boton ‘editar mensaje’ para cambiar a la vista ‘edi-

tar mensaje de status’. Se pasa como parametro la anotacion del usuario.

• mostrarHibrido

Funcion que permite alternar entre vista de mapa1 y vista hıbrida (mapa

y satelite).

En la figura 5.5 se ilustra como interactuan estas funciones para el intercambio

de posiciones con el servidor:

1Se debe diferenciar ‘vista mapa’ (correspondiente a una vista del patron MVC) de vista de mapa

(forma de desplegar informacion cartografica en Google Maps)


Figura 5.5. Diagrama de interaccion entre las funciones de la aplicacion cliente

Interfaz de usuario

La ‘vista mapa’ (figura 8.1) tiene en su interfaz los siguientes elementos:

1. Anotaciones: Se muestran dentro del mapa con un pin verde ubicado en la

posicion de cada usuario del sistema.

2. Menu contextual: Se despliega al hacer clic en una anotacion y muestra la

descripcion del usuario elegido acompanada de una foto.

3. Boton ver detalles: Al pulsarlo se va a la ‘vista detalle de usuario’.

4. Cambiar vista: Alterna entre la vista de mapa y vista hıbrida (satelital y

mapa) (figura 5.7).

5. Boton editar mensaje: Al pulsarlo se va a la ‘vista editar mensaje’.

6. Volver: Cierra sesion y vuelve a ‘vista login’.


Figura 5.6. Interfaz de usuario de la ‘vista mapa’

Figura 5.7. Interfaz de usuario de la ‘vista mapa’ (hıbrida) y sus elementos


Detalle de usuario

Vista que muestra informacion detallada del usuario seleccionado en el mapa: fo-

to, nombre y mensaje de estado. Ademas posee un boton para llamar por telefono al

usuario.

Funciones

• viewDidLoad

A traves de esta funcion se cargan los datos del usuario dentro de la vista,

es decir la foto ampliada del usuario, nombre y telefono.

• llamar

Accion gatillada por el boton del mismo nombre, y que se encarga de

realizar una llamada telefonica al usuario seleccionado. Esta llamada se

realiza con la aplicacion telefono integrada en el sistema, al finalizar se

retorna a la aplicacion cliente.

Interfaz de Usuario

La vista de ‘detalle de usuario’ (figura 5.8) tiene en su interfaz los siguientes

elementos:

1. Informacion de usuario: Muestra el nombre y numero telefonico del usuario

seleccionado.

2. Foto grande: Carga foto del usuario (descargada de internet).

3. Llamar: Boton para establecer llamada telefonica.

4. Volver: Boton para volver a la ‘vista mapa’.


Figura 5.8. Interfaz de usuario para detalle de usuario

Figura 5.9. Vistas generadas al realizar llamada


Editar mensaje

Vista que muestra el mensaje de estado dejado por el usuario anteriormente, el

que puede ser editado y actualizado en el servidor para comunicarlo al resto de los

usuarios.

Funciones

• viewDidLoad

A traves de esta funcion se carga el mensaje original para ser editado en

pantalla.

• send

Accion gatillada por el boton enviar mediante la cual se actualiza en el

servidor el mensaje de estado del cliente a traves de HTTP POST.

Interfaz de Usuario

La vista de ‘editar mensaje’ (figura 5.10) tiene en su interfaz los siguientes

elementos:

1. Mensaje de estado: muestra el mensaje de estado, al hacer click puede

editarse.

2. Boton enviar: Envıa el nuevo mensaje (editado) al servidor.

3. Volver: Boton para volver a la ‘vista mapa’.

5.2 Servidor 38

Figura 5.10. Interfaz de usuario para editar mensaje de estado

5.2. Servidor

5.2.1. Plataforma

El servidor fue implementado en leguaje PHP sobre un servidor Apache, y pro-

gramado con el entorno de trabajo (framework) Symfony [28]. Symfony es un fra-

mework para PHP que utiliza las caracterısticas del patron de diseno Modelo-Vista-

Controlador del cual ya se habıa hablado en la seccion 5.1.1.

La ventaja de usar un framework radica en que incorpora librerıas que hacen que

las tareas de alta complejidad, pero que son comunes a la mayorıa de los desarrollos

web, no se deban programar de nuevo, como por ejemplo: la creacion de las tablas de

la base de datos, la incorporacion de datos iniciales en la base de datos, la creacion

de metodos basados en peticiones GET y POST para obtener e ingresar datos desde

la BD.

5.2 Servidor 39

5.2.2. Mensaje cliente-servidor

JSON (JavaScript Object Notation - Notacion de Objetos de JavaScript) es el

formato de datos elegido para comunicarse con la aplicacion cliente, es un formato

ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras

que para las maquinas es simple interpretarlo y generarlo. JSON es un formato de

texto que es completamente independiente del lenguaje pero utiliza convenciones que

son ampliamente conocidos por los programadores de la familia de lenguajes C [29].

Inicialmente se considero la opcion de usar el formato XML, sin embargo tras

varias pruebas se comprobo que el formato XML excedıa siempre el tamano en bytes

a JSON, en promedio un 20 %, por lo que se opto por este ultimo como estructura

para el intercambio de datos entre servidor y aplicacion movil.

A continuacion en la figura 5.11 se muestra un ejemplo de mensaje JSON utilizado

en el sistema, en el se pueden apreciar 3 usuarios del sistema y como se serializan su

nombre de usuario (id), nombre, telefono, latitud y longitud respectivamente.

[

{” id ” : ” javier@usm . c l ” , ”name” : ” Jav i e r ” , ”phone” : ”2797107” ,

”message” : ” v i s i t a n d o c l i e n t e en v a l p a r a i s o ” ,

” l a t i t u d e ” : ”−33.03365” , ” l ong i tude ” : ”−71.54977”} ,

{” id ” : ”juan@usm . c l ” , ”name” : ”Jaime” , ”phone” : ”2797262” ,

”message” : ” es toy en l a c a r r e t e r a camino a sant i ago ” ,

” l a t i t u d e ” : ”−33.03265” , ” l ong i tude ” : ”−71.54925”}{” id ” : ” jul ieta@usm . c l ” , ”name” : ” J u l i e t a ” , ”phone” : ”5711534” ,

”message” : ” trabajando en word se pasa g e n i a l ” ,

” l a t i t u d e ” : ”−33.456” , ” l ong i tude ” : ”−71.23456”}]

Figura 5.11. Ejemplo de mensaje JSON utilizado en el sistema

5.2.3. Servicios web

Para la creacion de servicios web REST se debio incorporar a Symfony un plug-in

llamado sfRestWebServicePlugin [30], este plug-in automatizo la implementacion de

algoritmos de busqueda y la creacion de rutas para el acceso a los recursos.

5.2 Servidor 40

Los servicios Web RESTful (como se les conoce a aquellos servicios que cumplen

con el estandar REST) se basan en peticiones HTTP para realizar sus acciones. La

forma en se acceden a los recursos y la respuesta que entrega el servidor se describen

a continuacion:

GET

GET es el la peticion HTTP usada para solicitar recursos al servidor.

Mostrar lista de usuarios

GET a http://servidor/api/user

[

{” id ” : ” j a v i e r ” , ”name” : ” Jav i e r ” , ”phone” : ”2797107” ,

”message” : ” v i s i t a n d o c l i e n t e ” , ” l a t i t u d e ” : ”−33.03365” ,

” l ong i tude ” : ”−71.54977”} ,

{” id ” : ” juan ” , ”name” : ”Jaime” , ”phone” : ”2797262” ,

”message” : ” es toy en camino a sant i ago ” , ” l a t i t u d e ” : ”−33.03265” ,

” l ong i tude ” : ”−71.54925”}]

Figura 5.12. Mostrar listado de usuarios

Mostrar un usuario

GET a http://servidor/api/user/javier

[

{” id ” : ” j a v i e r ” , ”name” : ” Jav i e r ” , ”phone” : ”2797107” ,

”message” : ” v i s i t a n d o c l i e n t e ” , ” l a t i t u d e ” : ”−33.03365” ,

” l ong i tude ” : ”−71.54977”}]

Figura 5.13. Mostrar un usuario

Mostrar historial de posiciones

GET a http://servidor/api/location/search/id/javier

5.2 Servidor 41

[

{” id ” : ”3” , ” u s e r i d ” : ” j a v i e r ” , ” l a t i t u d e ” : ”−33.03365” ,

”message” : ” v i s i t a n d o c l i e n t e en v a l p a r a i s o ” ,

” l ong i tude ” : ”−71.58977” , ” t s ” : ”2011−06−27 15 : 06 : 46”} ,

{” id ” : ”4” , ” u s e r i d ” : ” j a v i e r ” , ” l a t i t u d e ” : ”−33.03365” ,

”message” : ”programando en l a o f i c i n a ” ,

” l ong i tude ” : ”−71.54977” , ” t s ” : ”2011−06−27 15 : 06 : 46”}]

Figura 5.14. Mostrar posiciones

POST

Con el peticiones HTTP POST se envıan datos para que sean procesados en el

servidor.

Registrar un usuario

POST “id=julieta&name=Julieta&password=udv1vvdu&phone=5711534 &latitude=-

33.456&longitude=-71.23456” a http://servidor/api/userapi/user

[

{” id ” : ” j u l i e t a ” , ”name” : ” J u l i e t a ” , ”phone” : ”5711534” ,

”message” : ” trabajando en word” , ” l a t i t u d e ” : ”−33.456” ,

” l ong i tude ” : ”−71.23456”}]

Figura 5.15. Respuesta al registrar un usuario

Ingresar una nueva posicion

POST “id=julieta&latitude=-33.444&longitude=-71.222”

a http://servidor/api/userapi/location

5.3 Base de datos 42

[

{” id ” : ”11” , ” u s e r i d ” : ” j u l i e t a ” , ” l a t i t u d e ” : ”−33.444” ,

” l ong i tude ” : ”−71.222” , ” t s ” : ”2011−07−7 22−59−30”}]

Figura 5.16. Respuesta al ingresar una nueva posicion

PUT

La peticion HTTP PUT2 es usado en la implementacion para modificar recursos

ya existentes.

Editar mensaje

PUT “message=En mi hora de colacion” a http://servidor/api/userapi/user/[email protected]

[

{” id ” : ” j u l i e t a ” , ”name” : ” J u l i e t a ” , ”phone” : ”7777777” ,

”message” : ”en mi hora de c o l a c i o n d i s f ru tando e l almuerzo ” ,

” l a t i t u d e ” : ”−33.456” , ” l ong i tude ” : ”−71.23456”}]

Figura 5.17. Respuesta al modificar mensaje de estado de usuario

5.3. Base de datos

5.3.1. Plataforma

Durante el desarrollo del proyecto se utilizo MySQL sobre MacOS X 10.6.6 que

es el sistema operativo que se utiliza para compilar la aplicacion cliente. El entorno

de trabajo es instalado mediante la suite MAMP [31] (Mac Apache MySQL PHP)

que reduce la tarea de instalar este conjunto a unos pocos pasos muy intuitivos. Las

tablas de la base de datos son generadas automaticamente por Symfony a traves de

un archivo de configuracion llamado ‘schema.yml’ (ver en anexo 8.6)

2En symfony PUT es implementado mediante POST con primer argumento “sf method=PUT”,

ya que PUT no es soportado por hostings compartidos.


5.3.2. Estructura de tablas

Es un sistema muy sencillo que contiene dos tablas3:

Tabla user

En la tabla ‘user’ (tabla 5.1) se guardan los datos de registro de cada usuario y su

ultima posicion entregada al sistema. Posee tambien una columna para almacenar el

ultimo mensaje de estado dejado por el usuario. Su clave primaria es el id de usuario.

Contiene las siguientes columnas:

Columna Tipo de datos Descripcion

id string(30) Nombre de usuario (clave primaria de la tabla)

name string(30) Nombre

password string(100) Contrasena

phone string(12) Numero telefonico

message string(200) Ultimo mensaje de estado ingresado

latitude string(20) Latitud de la ultima posicion conocida

longitude string(20) Longitud de la ultima posicion conocida

ts timestamp Fecha y hora de la ultima posicion conocida

Tabla 5.1. Tabla ‘user’ y sus columnas

Tabla location

La tabla ‘location’ (tabla 5.2) es usada para almacenar un registro historico de las

posiciones de todos los usuario, se relaciona con tabla ‘user’ mediante la clave foranea

‘user id’.

3Por diseno y consistencia con las sintaxis SQL los nombres de las tablas y sus columnas se escriben

en ingles.


Columna Tipo de datos Descripcion

id Entero(6) autoincremental Identificador (clave primaria de la tabla)

user id string(30) Nombre de usuario (clave foranea)

latitude string(20) Latitud de la posicion

longitude string(20) Longitud de la posicion

ts timestamp Fecha y hora del registro de la posicion

Tabla 5.2. Tabla ‘location’ y sus columnas

La relacion entre ambas tablas se muestra en la figura 5.18

Figura 5.18. Diagrama de tablas de la base de datos

5.3.3. Relaciones entre tablas

Eliminacion en cascada

Uno de los principales beneficios de usar clave foranea es que permite eliminar y

actualizar registros en cascada, con esto al eliminar un registro de la tabla ‘user’ se

eliminan a la vez todos los registros de posiciones (en tabla ‘location’) asociados al

usuario eliminado.

Disparadores

Para mantener actualizada la tabla ‘user’ con las ultimas posiciones ingresadas

en la tabla ‘location’, y mantener la consistencia de los datos se disena un disparador

(trigger), que modifica en la tabla ‘user’ las columnas latitude y longitude cada vez

que ingresa una nueva fila a la tabla ‘location’. Los Disparadores se ingresan en la base

de datos mediante secuencias SQL, en la figura 5.19 se muestra la implementacion


para MySQL.

DROP TRIGGER IF EXISTS l o c a t i o n i n s e r t

DELIMITER //

CREATE TRIGGER l o c a t i o n i n s e r t AFTER INSERT ON l o c a t i o n

FOR EACH ROW BEGIN

UPDATE user SET

l a t i t u d e = NEW. l a t i t u d e ,

l ong i tude = NEW. long i tude ,

t s = NEW. t s

WHERE

id = NEW. u s e r i d ;

END

//

DELIMITER ;

Figura 5.19. Disparador que modifica la tabla ‘user’ al insertar en tabla ‘location’

Expiracion de registros

Los tiempos de busqueda en bases de datos aumentan con la cantidad de regis-

tros en las tablas. Es por ello que resulta util poder eliminar registros de posiciones

antiguas en la base de datos. En MySQL se pueden crear eventos que pueden ser

programados para ejecutarse en el futuro, como se muestra en la figura 5.20.

CREATE EVENT l o c a t i o n e x p i r e

ON SCHEDULE EVERY 1 DAY

DO DELETE FROM l o c a t i o n WHERE t s < NOW( ) − INTERVAL 30 DAY;

Figura 5.20. Evento para eliminar registros expirados

6 Mediciones

6.1. Servidor

Lo mas importante en el servidor es poder estimar la capacidad de usuarios que

puede atender en forma simultanea, por lo tanto se escoge medir el porcentaje de error

en peticiones GET (obtener listado de usuarios y sus posiciones) y POST (enviar una

posicion desde el telefono a la base de datos) en funcion de la cantidad de usuarios

simultaneos en el sistema.

6.1.1. Entorno de medicion

Las mediciones se realizaron bajo las siguientes condiciones:

Se uso la herramienta jMeter [32], una aplicacion de Java que puede simular

peticiones HTTP al servidor de multiples usuarios simultaneamente.

El servidor es un equipo con sistema operativo Mac OSX 10.6 con procesador

Intel core 2 duo 2.8 Ghz y 4 GB de memoria RAM.

Para generar en forma automatica la cantidad de usuarios en la base de datos se

utilizo la propiedad de symfony de incluir bucles PHP en el archivo ‘fixtures.yml’

(ver figura 8.7) que inicializan los datos de la base de datos.

Las mediciones se hicieron de 50 en 50 hasta 500 usuarios.

Para cada usuario se realizo una consulta GET y luego POST.

Se realizaron 10 cargas de peticiones consecutivas de 10 segundos para cada

caso.

46


6.1.2. Resultados

Los resultados obtenidos se muestran en el grafico de la figura 6.1, en el se puede

ver como el servidor puede atender todas las solicitudes hasta 100 usuarios simultanea-

mente (tanto GET user como POST location), y almacenar las posiciones de todos

los usuarios (POST location) hasta con 250 usuarios simultaneamente.

Figura 6.1. Error en respuesta HTTP servidor REST

6.2. Aplicacion cliente

Una metrica importante en la aplicacion cliente es la velocidad con la que se

visualizan los datos de otros usuarios, esto depende de dos cosas:

Latencia de descarga de los datos de posiciones de usuarios desde el servidor.

Tiempo que tarda la aplicacion en cargar los datos en el mapa como anotacion

(pin).


6.2.1. Entorno de medicion

Las mediciones se realizaron bajo las siguientes condiciones:

Se utilizo un iPhone 3GS, con procesador ARM Cortex-A8 de 600 Mhz y 256

MB de memoria RAM.

La latencia de descarga se midio bajo 2 ambientes distintos de red: WiFi y 3G

(Movistar Chile).

Para las mediciones en red de datos 3G se hicieron muestreos a horas de alto

trafico (entre 6:00 y 6:30 PM) y bajo trafico (entre 1:30 y 2:00 AM), estas

condiciones se muestran en figura 6.2.

Para generar en forma automatica la cantidad de usuarios en la base de datos se

utilizo la propiedad de symfony de incluir bucles PHP en el archivo ‘fixtures.yml’

(ver figura 8.7) que inicializan los datos de la base de datos.

Para medir los tiempos se agrego al programa marcas de tiempo al inicio y final

de cada proceso, estos diferencias de tiempo fueron visualizadas directamente

en la consola de depuracion de Xcode.

Las mediciones se hicieron de 10 en 10 usuarios hasta los 100 usuarios, luego de

20 en 20 hasta los 300 usuarios.

Para cada caso de usuario se hicieron 10 mediciones.

a) b)

Figura 6.2. Ambientes de medicion 3G de (a) alto trafico y (b) bajo trafico


6.2.2. Resultados

Latencia para obtencion de datos desde servidor

En la figura 6.3 se observa que la latencia en la descarga de datos desde el ser-

vidor crece muy poco a medida que el numero de usuarios aumenta (y por lo tanto

el tamano del mensaje en bytes), esta diferencia solo es apreciable en el caso de la

conexion WiFi en que la velocidad de descarga es comparable al tiempo que se tarda

en establecer el enlace.

De las mediciones en 3G, se ve que tienen un retardo mucho mayor que bajo Wi-

Fi, las mediciones arrojan un promedio de 7,4 segundos para 3G con alto trafico y

5,5 segundos para 3G con bajo trafico, una diferencia promedio de cerca de 2 segundos.

Estas mediciones solo pueden considerarse referenciales, ya que no se consideran

muchas otras variables externas al sistema, como por ejemplo la companıa de telefonıa,

la antena base o la velocidad de la fuente. Una medicion concluyente involucrarıa por

si sola un estudio independiente a los objetivos de este trabajo.

Figura 6.3. Latencia para obtencion de datos desde servidor


Generacion de anotaciones en mapa

Se midio el tiempo que tarda la aplicacion en pasar un listado de posiciones (ya

descargado desde el servidor) a anotaciones en el mapa, por lo tanto es independiente

del tipo de conexion utilizada. Los resultados de las mediciones estan graficados en

la figura 6.4 y se puede observar como hay una directa relacion entre la cantidad de

usuarios y el aumento en el tiempo que tarda la aplicacion en generar la totalidad de

las anotaciones.

Figura 6.4. Tiempo de generacion de anotaciones en mapa

7 Conclusiones

AL haber finalizado el desarrollo del proyecto, y revisar los objetivos propuestos

inicialmente es posible darse cuenta que se cumplieron cada uno de ellos, de lo

que se puede concluir:

La implementacion del sistema para distribuir las posiciones geograficas entre

los usuario del sistema requirio la implementacion de una arquitectura cliente-

servidor por medio de servicios web REST, una tecnologıa que demostro que

una herramienta potente no tiene por que ser complicada.

La utilizacion del patron de diseno Modelo-Vista-Controlador permite abstraer-

se en gran medida de la interfaz de usuario, es decir, se pudo disenar una interfaz

base y modificarla sin necesidad de alterar el codigo de los controladores.

Pudo implementarse un sistema de localizacion para smartphone, y si bien en

este proyecto se utilizo un equipo iPhone, hoy existen herramientas analogas en

otras plataformas que tienen excelentes proyecciones de mercado.

7.1. Recomendaciones

De la experiencia en el trabajo realizado se pueden entregar las siguientes reco-

mendaciones para desarrollos futuros o proyectos similares:

7.1.1. Desarrollo en base a prototipos

Este trabajo involucro tecnologıas, plataformas y lenguajes de programacion dis-

tintos, existıan variadas alternativas de diseno e implementacion. Muchas de estas

variables fueron en un principio desconocidas, y a medida que mas se investiga sur-

gen diversas opciones que pueden conducir en lo que en ingenierıa de software se llama

‘Analisis Paralisis”, es decir, un estado en el que al analizar y modelar cada una de las

51

7.2 Trabajo futuro 52

posibles soluciones se produce un paralisis que puede acabar con un proyecto incluso

antes de escribir la primera lınea de codigo.

Para evitar esto es que el proyecto se realizo por medio de prototipos que fueron

incrementando sus funcionalidades y complejidad sobre la marcha. Esta modalidad de

trabajo tambien tiene efectos colaterales negativos, como el tener que retroceder cada

vez que por tiempo se adopto una tecnologıa que mas tarde tuvo que ser cambiada

por una alternativa mejor.

7.1.2. No reinventar la rueda

Al llevar a cabo un proyecto telematico es importante dedicar tiempo a la investi-

gacion de un problema y las distintas alternativas que existen para abordarlo. Esto es

especialmente trascendental en tecnologıas de la informacion y comunicaciones donde

los cambios y avances son muy rapidos y es facil caer en la “reinvencion de la rueda”

por desconocimiento, y a veces incluso, por temor a lo desconocido.

En concreto en este proyecto valio la pena investigar sobre el uso de entornos de

trabajo (frameworks) y plug-ins que facilitaron enormemente el trabajo. Si bien la uti-

lizacion de estas herramientas supone un esfuerzo inicial mayor por el hecho de tener

que aprender a utilizarlas, a mediano plazo ahorran mucho tiempo ya que entregan

soluciones que cumplen con especificaciones altamente documentadas y robustas.

Se debe considerar tambien que el uso de frameworks implica la creacion de mu-

chos objetos y metodos en forma automatica que estan listos para ser usados, esto

constituye un arma de doble filo, que reduce el control del programador sobre la apli-

cacion y dificulta la inspeccion del codigo cuando se requiere optimizacion de modulos

en concreto.

7.2. Trabajo futuro

En la etapa de desarrollo de un producto comercial se deben considerar los si-

guientes aspectos:

7.2.1. Aplicacion web

Brindar la posibilidad de una interfaz web con mas funcionalidades para el mo-

nitoreo es una caracterıstica que se complementarıa muy bien y que harıa al sistema


llegar a muchas mas plataformas.

7.2.2. Capacidad de servidores

Quedo de manifiesto en las mediciones de desempeno que el lımite de usuarios de

un servicio web REST en PHP como el desarrollado en este proyecto no es suficiente

para una aplicacion comercial, en este sentido se puede optar por poner multiples

servidores fısicos o virtualizados de acuerdo a la cantidad de usuarios que pueda

llegar a atenderse. Por las caracterısticas de los servicios web REST, se puede migrar

a un lenguaje distinto a PHP sin modificar la aplicacion, y aumentar el rendimiento

con un lenguaje compilado (no interpretado) que pueda trabajar en multiples hebras.

7.2.3. Incorporacion de Android

De la investigacion realizada en el estado del arte se puede concluir que Android

es la plataforma ideal para comenzar a ampliar la gama de plataformas moviles, esto

no debiera suponer gran esfuerzo adicional, ya que la plataforma de servicios web

implementada en REST no necesita modificaciones porque es independiente de la

plataforma del cliente.

7.2.4. Datos geo-espaciales para base de datos

Si el sistema escala, es muy probable que no se puedan cargar varios cientos de

usuarios en la vista de mapa y haya que seleccionar solo a los mas cercanos, entonces

surge la pregunta ¿Cuales son los mas cercanos? ¿De quien es la labor de seleccionar-

los: de la base de datos, del servicio web o de la aplicacion?

Lo mas natural serıa escogerlos directamente de la base de datos para que no haya

flujo de datos innecesario hacia el servicio web o la aplicacion. Para esto en Bases de

datos existe el tipo de dato Geo-espacial que mediante sentencias SQL puede obtener

directamente los puntos mas cercanos a otro punto.

La implementacion de este tipo de datos requiere un estudio profundo de los

sistemas de representacion cartograficas y sus transformaciones.

7.2.5. Consumo de baterıa

Es un problema inherente al uso de Localizacion con GPS y es necesario hacer

pruebas que permitan establecer cuanto y cuando se puede sacrificar precision en la


localizacion en favor de un menor consumo de baterıa en el dispositivo.

7.2.6. Notificaciones push

Uno de los objetivos del proyecto propuesto fue establecer algun grado de comu-

nicacion con el resto de los usuarios del sistema, esto se resolvio mediante la incorpo-

racion de la opcion de llamada telefonica (que normalmente tiene un costo asociado)

y el mensaje de estado. Otra alternativa son las ‘notificaciones push’, que es una for-

ma de enviar un mensaje directamente a la aplicacion cliente de otro usuario usando

internet movil (sin costo adicional).

8

Apendices

8.1. Acceso movil a nivel comunal en Chile

Figura 8.1. Disposicion de ofertas comerciales de acceso movil a internet a nivel comunal.

(fuente: Subtel 2009 [5])

55

8.2 Trafico de datos por dispositivo 56

8.2. Trafico de datos por dispositivo

Figura 8.2. Reporte de trafico de datos por dispositivos por paıs (fuente: ComScore. Mayo

2011 [6]

8.3. Estructura JSON

JSON esta constituido por dos estructuras:

Una coleccion de pares de nombre/valor. En varios lenguajes esto es conocido

como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o

un arreglo asociativo.

Una lista ordenada de valores. En la mayorıa de los lenguajes, esto se imple-

menta como arreglos, vectores, listas o secuencias.

Estas son estructuras universales; virtualmente todos los lenguajes de programa-

cion las soportan de una forma u otra. Es razonable que un formato de intercambio de

8.3 Estructura JSON 57

datos que es independiente del lenguaje de programacion se base en estas estructuras.

En JSON, se presentan de estas formas:

Un objeto (figura 8.3) es un conjunto desordenado de pares nombre/valor. Un

objeto comienza con { y termine con }. Cada nombre es seguido por : y los pares

nombre/valor estan separados por , (coma).

Figura 8.3. Definicion de un objeto JSON. (fuente: www.json.org 2011 [29])

Un arreglo (figura 8.4) es una coleccion de valores. Un arreglo comienza con [ y

termina con ]. Los valores se separan por , (coma).

Figura 8.4. Definicion de un arreglo JSON. (fuente: www.json.org 2011 [29])

Un valor (figura 8.5) puede ser una cadena de caracteres con comillas dobles, o

un numero, o true o false o null, o un objeto o un arreglo. Estas estructuras pueden

anidarse.

Figura 8.5. Definicion de un valor JSON. (fuente: www.json.org 2011 [29])

8.4 Definicion modelo de datos en Symfony 58

8.4. Definicion modelo de datos en Symfony

User :

columns :

id :

type : s t r i n g (30)

primary : t rue

name :


no tnu l l : t rue

password :


no tnu l l : t rue

phone :


no tnu l l : t rue

l a t i t u d e :


l ong i tude :


t s :

type : timestamp

Locat ion :

columns :

id :

primary : t rue

autoincrement : t rue

type : i n t e g e r (6 )

u s e r i d :


l a t i t u d e :


l ong i tude :


t s :

type : timestamp

r e l a t i o n s :

User : { onDelete :CASCADE, c l a s s : User , l o c a l : u s e r i d , f o r e i g n : id }

Figura 8.6. Archivo de configuracion Symfony ‘schema.yml’

8.5 Datos iniciales en Symfony 59

8.5. Datos iniciales en Symfony

User :

Jav i e r :

id : javier@usm . c l

name : Jav i e r

password : 1

phone : 56−32−2797107

l a t i t u d e : −33.03360

l ong i tude : −71.58977

J u l i e t a :

id : jul ieta@usm . c l

name : J u l i e t a

password : 1

phone : 56−32−2797107

l a t i t u d e : −33.03260

l ong i tude : −71.58917

<?php f o r ( $ i = 1 ; $ i <= 98 ; $ i++) : ?>

<?php $ l a t i t u d e=( rand () %999)∗0.00006−33.08 ; ?>

<?php $ long i tude=( rand () %999)∗0.00008−71.60 ; ?>

Usuario <?php echo $ i ?> :

id : <?php echo $ i . ”@usm. c l \n” ?>

name : Usuario <?php echo $ i . ”\n” ?>

password : <?php echo $ i . ”\n” ?>

phone : 56−32−2797107

l a t i t u d e : <?php echo $ l a t i t u d e . ”\n” ?>

l ong i tude : <?php echo $ l ong i tude . ”\n” ?>

<?php endfor ; ?>

Locat ion :

f i r s t J a v i e r :

u s e r i d : j a v i e r

l a t i t u d e : −33.03360

l ong i tude : −71.58977

f i r s t J u l i e t a :

u s e r i d : j u l i e t a

l a t i t u d e : −33.03260

l ong i tude : −71.58917

Figura 8.7. Archivo de configuracion Symfony ‘fixtures.yml’

8

Referencias

[1] (2011, Abril). [Online]. Disponible: http://www.lanacion.com.ar/nota.asp?nota id=

1295643

[2] (2011, Mayo). [Online]. Disponible: http://www.economiaynegocios.cl/noticias/noticias.

asp?id=69618

[3] (2011, Mayo). [Online]. Disponible: http://www.diariopyme.com/2011/02/

clientes-de-celulares-superan-los-21-millones-en-chile/

[4] (2011, Mayo). [Online]. Disponible: http://www.123.cl/adm cont/tecnologia/

actualidad/articulo 12679 a.html

[5] Informe Anual de Actividad del Sector Telecomunicaciones, 2009.

[6] (2011, Junio). [Online]. Disponible: http://www.comscore.com/esl/Press Events/

Press Releases/2011/7/comScore Introduces Device Essentials in Latin America

[7] (2011, Junio). [Online]. Disponible: http://www.eliax.com/index.cfm?post id=8697

[8] (2011, Junio). [Online]. Disponible: http://www.infoweek.biz/la/2011/05/

dispositivos-moviles-entre-lo-personal-y-lo-laboral/

[9] (2011, Junio). [Online]. Disponible: http://www.google.com/mobile/maps/

[10] A. Inc., Mapkit Framework Reference, Apple Inc., 1 Infinite Loop. Cupertino. California,

Mayo 2011.

[11] ——, Location Awareness Programming Guide, Apple Inc., 1 Infinite Loop. Cupertino.

California, Diciembre 2010.

[12] T. C. y. J. P. Steve Suehring, PHP 6 and MySQL 6 Bible. Indianapolis, USA: Wiley

Publishing, Inc., 2009.

[13] (2011, Marzo). [Online]. Disponible: http://www.mysql.com/products/community/

[14] (2011, Julio). [Online]. Disponible: http://es.wikipedia.org/wiki/Servicio web

[15] (2011, Julio). [Online]. Disponible: http://www.desarrolloweb.com/articulos/1557.php

[16] (2011, Julio). [Online]. Disponible: http://greatgandhi.wordpress.com/2010/06/16/

soap-vs-rest-%E2%80%93-the-best-webservice/

[17] (2011, Abril). [Online]. Disponible: http://www.dondeesta.com/la/

[18] (2011, Abril). [Online]. Disponible: http://cabulous.com/

[19] (2011, Abril). [Online]. Disponible: http://www.ndonde.es/gps/

60

http://www.lanacion.com.ar/nota.asp?nota_id=1295643

http://www.lanacion.com.ar/nota.asp?nota_id=1295643

http://www.economiaynegocios.cl/noticias/noticias.asp?id=69618

http://www.economiaynegocios.cl/noticias/noticias.asp?id=69618

http://www.diariopyme.com/2011/02/clientes-de-celulares-superan-los-21-millones-en-chile/

http://www.diariopyme.com/2011/02/clientes-de-celulares-superan-los-21-millones-en-chile/

http://www.123.cl/adm_cont/tecnologia/actualidad/articulo_12679_a.html

http://www.123.cl/adm_cont/tecnologia/actualidad/articulo_12679_a.html

http://www.comscore.com/esl/Press_Events/Press_Releases/2011/7/comScore_Introduces_Device_Essentials_in_Latin_America

http://www.comscore.com/esl/Press_Events/Press_Releases/2011/7/comScore_Introduces_Device_Essentials_in_Latin_America

http://www.eliax.com/index.cfm?post_id=8697

http://www.infoweek.biz/la/2011/05/dispositivos-moviles-entre-lo-personal-y-lo-laboral/

http://www.infoweek.biz/la/2011/05/dispositivos-moviles-entre-lo-personal-y-lo-laboral/

http://www.google.com/mobile/maps/

http://www.mysql.com/products/community/

http://es.wikipedia.org/wiki/Servicio_web

http://www.desarrolloweb.com/articulos/1557.php

http://greatgandhi.wordpress.com/2010/06/16/soap-vs-rest-%E2%80%93-the-best-webservice/

http://greatgandhi.wordpress.com/2010/06/16/soap-vs-rest-%E2%80%93-the-best-webservice/

http://www.dondeesta.com/la/

http://cabulous.com/

http://www.ndonde.es/gps/

Referencias 61

[20] (2011, Abril). [Online]. Disponible: http://www.instamapper.com/

[21] (2011, Abril). [Online]. Disponible: http://goglyph.com/goGlyph/main.html

[22] Facebook. (2011, Abril) Lugares de facebook. [Online]. Disponible: http://www.

facebook.com/places/

[23] I. Sommerville, Ingenierıa de Software, 7th ed. Pearson Education, 2005.

[24] (2011, Junio). [Online]. Disponible: http://www.manycomics.com/

ingenieria-del-software/uml/casos-de-uso/

[25] (2011, Abril). [Online]. Disponible: http://developer.apple.com/programs/ios/

[26] A. Inc., iOS Application Programming Guide, Apple Inc., 1 Infinite Loop. Cupertino.

California, Febrero 2011.

[27] (2011, Julio). [Online]. Disponible: http://www.google.com/support/webmasters/bin/

answer.py?hl=es&answer=40132

[28] (2011, Julio). [Online]. Disponible: http://www.symfony-project.org/

[29] (2011, Abril). [Online]. Disponible: http://www.json.org/json-es.html

[30] (2011, Julio). [Online]. Disponible: http://www.symfony-project.org/plugins/

sfRestWebServicePlugin

[31] (2011, Julio). [Online]. Disponible: http://www.mamp.info/en/mamp/index.html

[32] (2011, Julio). [Online]. Disponible: http://jakarta.apache.org/jmeter/

http://www.instamapper.com/

http://goglyph.com/goGlyph/main.html

http://www.facebook.com/places/

http://www.facebook.com/places/

http://www.manycomics.com/ingenieria-del-software/uml/casos-de-uso/

http://www.manycomics.com/ingenieria-del-software/uml/casos-de-uso/

http://developer.apple.com/programs/ios/

http://www.google.com/support/webmasters/bin/answer.py?hl=es&answer=40132

http://www.google.com/support/webmasters/bin/answer.py?hl=es&answer=40132

http://www.symfony-project.org/

http://www.json.org/json-es.html

http://www.symfony-project.org/plugins/sfRestWebServicePlugin

http://www.symfony-project.org/plugins/sfRestWebServicePlugin

http://www.mamp.info/en/mamp/index.html

http://jakarta.apache.org/jmeter/

SISTEMA DE GEOLOCALIZACION Y MONITOREO … · Archivo de con guraci on Symfony ‘ xtures.yml’...

Documents

Transcript of SISTEMA DE GEOLOCALIZACION Y MONITOREO … · Archivo de con guraci on Symfony ‘ xtures.yml’...