sistema de geolocalizacion y monitoreo … · archivo de con guraci on symfony ‘ xtures.yml’...
TRANSCRIPT
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 Tecnologıas necesarias 6
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
2.3 Tecnologıas necesarias 7
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
2.3 Tecnologıas necesarias 8
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]:
2.3 Tecnologıas necesarias 9
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
3.2 Requerimientos no funcionales 15
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.
3.2 Requerimientos no funcionales 16
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 Casos de uso del sistema 22
4.4.2. Inicio de sesion de usuario
Nombre Inicio de sesion de usuario
Actor principal Usuario
Interes Ingresar al sistema para poder enviar la
posicion propia y la del resto de los usuarios.
Precondiciones El usuario ha instalado y ejecutado la aplicacion.
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 Casos de uso del sistema 23
4.4.3. Editar mensaje
Nombre Editar mensaje
Actor principal Usuario
Interes Poder editar, y comunicar el mensaje de estado
al resto de los usuario.
Precondiciones El usuario ha instalado y ejecutado la aplicacion.
El usuario se ha registrado previamente.
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 Casos de uso del sistema 24
4.4.4. Ver detalles de usuario
Nombre Ver detalles de usuario
Actor principal Usuario
Interes Poder ver detalles de otros usuarios del sistema:
foto, nombre, descripcion.
Precondiciones El usuario ha instalado y ejecutado la aplicacion.
El usuario se ha registrado previamente.
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 Casos de uso del sistema 25
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..
Precondiciones El usuario ha instalado y ejecutado la aplicacion.
El usuario se ha registrado previamente.
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:
5.1 Aplicacion cliente 28
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
5.1 Aplicacion cliente 29
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.
5.1 Aplicacion cliente 30
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
5.1 Aplicacion cliente 31
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.
5.1 Aplicacion cliente 32
• 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)
5.1 Aplicacion cliente 33
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’.
5.1 Aplicacion cliente 34
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
5.1 Aplicacion cliente 35
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’.
5.1 Aplicacion cliente 36
Figura 5.8. Interfaz de usuario para detalle de usuario
Figura 5.9. Vistas generadas al realizar llamada
5.1 Aplicacion cliente 37
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 Base de datos 43
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.
5.3 Base de datos 44
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
5.3 Base de datos 45
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.2 Aplicacion cliente 47
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 Aplicacion cliente 48
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 Aplicacion cliente 49
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
6.2 Aplicacion cliente 50
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
7.2 Trabajo futuro 53
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
7.2 Trabajo futuro 54
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 :
type : s t r i n g (30)
no tnu l l : t rue
password :
type : s t r i n g (100)
no tnu l l : t rue
phone :
type : s t r i n g (20)
no tnu l l : t rue
l a t i t u d e :
type : s t r i n g (20)
l ong i tude :
type : s t r i n g (20)
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 :
type : s t r i n g (30)
l a t i t u d e :
type : s t r i n g (20)
l ong i tude :
type : s t r i n g (20)
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
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/