Gateway SMS Pull para Servicios Basados en Localización con una Arquitectura de Servicios Web

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Gateway SMS Pull para Servicios Basados en Localización con una Arquitectura de Servicios Web

presentada por

Pedro Quiñónez Bernardino Ing. en Sistemas Computacionales por el I. T. de Ciudad Guzmán

como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. Juan Gabriel González Serna

Codirector de tesis:

Dr. Víctor Jesús Sosa Sosa

Cuernavaca, Morelos, México. 10 Enero de 2008

ii

DEDICATORIA

A Dios:

Por ser el Padre Creador de todo lo que existe y ser quien me mantiene con fortaleza en los momentos difíciles, por darme más de lo que merezco.

A mi Padre Pedro Quiñonez Constantino:

Por ser mi guía, mi amigo, pero sobre todo mí ejemplo a seguir por inculcarme la

manera de proceder y actuar. Te quiero y te respeto mucho.

A mi Madre Emilia Bernardino de la Cruz:

Por motivarme a dar siempre lo mejor de mí. Por tener ese carácter tan fuerte y tan suave a la vez. Gracias por apoyarme y escucharme en todo momento. Te

quiero mucho.

A mis hermanos:

Joaquín, Leonardo, Pepe por ser la alegría de la familia y por sacarme esas sonrisas cuando las cosas no van tan bien.

A mi Tía Benita Bernardino de la Cruz:

Por siempre brindar una broma y tener una sonrisa en la cara, por ser parte de

nuestra familia y ayudar a mis Padres en la educación de mi hermano. Eres parte de nuestra familia y te quiero mucho.

A mi novia Elvia Araiza Lizarde:

Por apoyarme en todo momento, compartir todo lo que vivimos y ser parte de mi

vida, por ser la alegría y mi motivación estos dos años. Te amo.

iii

AGRADECIMIENTOS

Al Consejo Nacional de Ciencia y Tecnología (CONACYT) por brindar el apoyo económico para realizar mis estudios de postgrado. Al Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet) por darme la oportunidad de continuar con mi preparación profesional. A la Dirección General de Educación Superior Tecnológica (DGEST) por brindar el apoyo económico para la finalización de mis estudios de postgrado. A DIOS por darme la oportunidad de vivir y tener esta experiencia, por cruzar en mi camino a las personas que han dejado huella en mi vida y por mantenerme a flote en momentos difíciles, por ser quien me da las fuerzas para salir adelante. A mis Padres que junto con mis hermanos son lo más valioso que tengo. Gracias a ellos, que me han apoyado en todas mis decisiones y aunque no siempre son las más acertadas las respetan. Gracias por todo el amor y paciencia que me tienen. A mi director de tesis el Dr. Juan Gabriel González Serna por guiarme en el desarrollo de esta tesis y transmitirme sus conocimientos, pero sobretodo por brindarme su amistad y por esas charlas que tuvimos fuera de todo contexto escolar. Gracias por sus consejos y opiniones. A los revisores de esta tesis: Dr. Máximo López Sánchez, Dr. José Antonio Zarate Marceleño y al M.C. Mario Guillen Rodríguez por las sugerencias en torno a este trabajo y sus observaciones que ayudan a mejorar la calidad de esta tesis. A todos los profesores y personal académico de esta institución. Especialmente al Dr. José Antonio Zarate Marceleño quien no olvida el lado humano y siempre extiende la mano para ofrecer su ayuda incondicionalmente, gracias. Un especial agradecimiento a todos mis compañeros de la generación 2005-2007 con quienes en su momento compartimos vivencias y experiencias que no olvidare. De Ing. Software: Elvia, Erick, Edna, Lalo y Cindy; Inteligencia Artificial: Arturo, Gerardo y Ricardo. Especialmente a Erick por aguantarnos mutuamente estos dos años de convivencia en la misma casa y por esas charlas que se prolongaban hasta las 3 de la mañana compartiendo vivencias y opiniones, mi más sincera amistad. A mis hermanos SD´s: Lirio, Adriana, Daniel y Jesús. Con quienes pasamos de las mejores etapas en el inicio de esta aventura, cuentan con mi amistad y apoyo incondicional. A los compañeros de Sistemas Distribuidos de la generación 2006-2008: Lalo, Matilde, Katty, Omar, Claudia y Janet.

iv

RESUMEN Con la evolución de las tecnologías, servicios que se tenían sobre plataformas

fijas o de escritorio han migrado y se ofrecen a través de las tecnologías móviles.

Ahora es posible proporcionar servicios a los usuarios donde la información se

vuelve dinámica y depende de la posición donde se encuentra el dispositivo.

Aunque se proporcionan servicios basados en localización a través de mensajería

de SMS y sobre WAP, éstos son dependientes de la red celular y no proporcionan

el acceso a la información por medio de servicios Web.

El presente trabajo propone la arquitectura de una plataforma para proporcionar

servicios basados en localización a través de la mensajería de SMS, utilizando la

ubicación del dispositivo expresada en coordenadas geográficas para ubicar los

puntos de interés que se encuentran cerca por medio de una base de datos

espacial y tecnologías de los servicios Web para resolver información externa

basada en la localización.

El objetivo de esta tesis es desarrollar un Gateway –pasarela- que permita el

procesamiento de los mensajes SMS, los procese y retorne información –

contenida localmente en la base de datos espacial o externa por tecnologías de

servicios Web- acorde con la ubicación del dispositivo móvil. Con el desarrollo de

esta plataforma se cuenta con un software capaz de proporcionar servicios

basados en localización sin la restricción de la red celular sobre la que opera el

dispositivo y con las ventajas que proporcionan las tecnologías de los servicios

Web a través del referente de la telefonía celular, la mensajería de SMS.

v

ABSTRACT

With the evolution of technology, services that were on fixed platforms or desktop

have migrated and offered through mobile technologies. Now it is possible to

provide services to users where information becomes dynamic and depends of

device’s location. Although provides location-based services through SMS

messaging and WAP technology, they are dependent on the cellular network and

do not provide access to information via Web services.

This work proposes the architecture of a platform to providing location-based

services via SMS messaging, using the device location expressed in geographic

coordinates to locate the points of interest that are close by a spatial database and

the Web Services technology to solve external information based on location.

The objective of this thesis is to develop a Gateway, which enables the processing

of SMS messages, and returns to process information contained in the spatial

database or external by Web Services technology, consistent with the mobile

device location. With the development of this platform, we have a software capable

of providing location-based services without the restriction of the cellular network

upon which the device operates and with the benefits that provide the Web

Services technology services through the telephony cellular references, the

messaging SMS.

vi

TABLA DE CONTENIDO

CAPÍTULO 1 INTRODUCCIÓN .............................................................................. 1

1.1. Introducción............................................................................................................................................... 2

1.2. Antecedentes. ............................................................................................................................................. 2

1.3. Descripción del Problema. ........................................................................................................................ 3

1.4. Objetivo. ..................................................................................................................................................... 4

1.5. Justificación y Beneficios. ......................................................................................................................... 4 1.5.1. Justificación. ........................................................................................................................................ 4 1.5.2. Beneficios. ........................................................................................................................................... 6

1.6. Alcances...................................................................................................................................................... 6

1.7. Limitaciones. .............................................................................................................................................. 7

1.8. Estado del Arte. ......................................................................................................................................... 7

1.9. Organización de la Tesis. ........................................................................................................................ 13

CAPÍTULO 2 MARCO TEÓRICO ......................................................................... 15

2.1. Servicios Basados en Localización. ........................................................................................................ 16 2.1.1. Componentes de los LBS................................................................................................................... 16 2.1.2. Servicios PUSH y PULL. .................................................................................................................. 17

2.2. Sistemas de Información Geográfica. .................................................................................................... 18 2.2.1. Vectoriales. ........................................................................................................................................ 18

2.2.1.1. Shapefiles. .............................................................................................................................. 19 2.2.2. Raster. ................................................................................................................................................ 19

2.3. Red Inalámbrica GSM. ........................................................................................................................... 20 2.3.1. SMS. .................................................................................................................................................. 21

2.4. Servicios Web........................................................................................................................................... 22 2.4.1. Arquitectura. ...................................................................................................................................... 23

2.4.1.1. Red........................................................................................................................................... 24 2.4.1.2. Protocolo SOAP. .................................................................................................................... 24 2.4.1.3. WSDL. ..................................................................................................................................... 24

2.5. Patrón MVC............................................................................................................................................. 24

CAPÍTULO 3 PROPUESTA DE SOLUCIÓN........................................................ 26

3.1. Solución Propuesta. ................................................................................................................................. 27

3.2. Arquitectura Propuesta. ......................................................................................................................... 27

3.3. Criterios de Búsqueda............................................................................................................................. 29

vii

CAPÍTULO 4 IMPLEMENTACIÓN ....................................................................... 32

4.1. Base de Datos Espacial. ........................................................................................................................... 33

4.2. GW-SMS. ................................................................................................................................................. 36

4.3. Negocio2SMS. .......................................................................................................................................... 48

CAPÍTULO 5 PRUEBAS Y RESULTADOS ......................................................... 57

5.1. Plan de Pruebas. ...................................................................................................................................... 58

5.2. Características a Probar. ........................................................................................................................ 58 5.2.1. Pruebas de conexión y configuración. ............................................................................................... 58 5.2.2. Pruebas de invocación de información dinámica externa. ................................................................. 59 5.2.3. Almacenamiento y actualización de la información. ......................................................................... 59 5.2.4. Envío y recepción de información. .................................................................................................... 59 5.2.5. Registro y visualización de información georeferenciada. ................................................................ 59

5.3. Procedimiento para las Pruebas............................................................................................................. 60 5.3.1. SBLAGWSMS-001 Pruebas de conexión y configuración. .............................................................. 60 5.3.2. SBLAGWSMS-002 Pruebas de invocación de información dinámica externa. ................................ 62 5.3.3. SBLAGWSMS-003 Pruebas de almacenamiento de la información................................................. 64 5.3.4. SBLAGWSMS-004 Envío y recepción de información. ................................................................... 66 5.3.5. SBLAGWSMS-001 Pruebas de registro y visualización de la información..................................... 70

5.4. Resultados de Pruebas. ........................................................................................................................... 72

CAPÍTULO 6 CONCLUSIONES ........................................................................... 91

6.1. Conclusiones............................................................................................................................................. 92

6.2. Aportaciones. ........................................................................................................................................... 92

6.3. Problemas Encontrados. ......................................................................................................................... 93

6.4. Trabajos Futuros. .................................................................................................................................... 94

ANEXOS ............................................................................................................... 95

REFERENCIAS................................................................................................... 118

viii

LISTADO DE FIGURAS Figura 1 Incremento de telefonía móvil en México [COF07]............................................................... 5 Figura 2 Estadísticas de envío de mensajes SMS por día [NET07]. .................................................. 5 Figura 3 Implementación basada en HTTP/XML [KRI02]. .................................................................. 8 Figura 4 Implementación en Java de propuesta SMS [KRI02]. .......................................................... 8 Figura 5 Modelo de LBS para el control del crimen [ROO03]............................................................. 9 Figura 6 Arquitectura general del sistema de boletos basados en localización [BÖH05]. ............... 10 Figura 7 Componentes de los LBS. .................................................................................................. 16 Figura 8 Representación de GIS vectorial. ....................................................................................... 18 Figura 9 Estructura de archivos shapefile......................................................................................... 19 Figura 10 Representación de GIS raster. ......................................................................................... 20 Figura 11 Arquitectura de red GSM. ................................................................................................. 21 Figura 12 Pasos para el envío de mensajes SMS. ........................................................................... 22 Figura 13 Componentes de los servicios Web.................................................................................. 23 Figura 14 Pila conceptual de los servicios Web................................................................................ 23 Figura 15 Arquitectura del patrón MVC............................................................................................. 25 Figura 16 Modelo de la plataforma propuesta. ................................................................................ 28 Figura 17 Diagrama a bloques de la arquitectura propuesta. ........................................................... 28 Figura 18 Jerarquía de clases geométricas. ..................................................................................... 33 Figura 19 Operaciones sobre geometrías......................................................................................... 34 Figura 20 Diagrama relacional de base de datos. ............................................................................ 35 Figura 21 Arquitectura a bloques de módulo GW-SMS. ................................................................... 37 Figura 22 Casos de uso para módulo GW-SMS............................................................................... 38 Figura 23 Diagrama de clases de GW-SMS. .................................................................................... 39 Figura 24 Diagrama de clases de cliente servicio Web. ................................................................... 40 Figura 25 Diagrama de secuencia para inicio de módulo GW-SMS................................................. 42 Figura 26 Diagrama de secuencia para consulta local georeferenciada. ......................................... 42 Figura 27 Diagrama de secuencia de consulta local no georeferenciada. ....................................... 43 Figura 28 Diagrama de secuencia consulta externa georeferenciada.............................................. 44 Figura 29 Diagrama de secuencia consulta externa no georeferenciada. ....................................... 45 Figura 30 Implementación gráfica del módulo GW-SMS. ................................................................. 46 Figura 31 Algoritmo de Dijkstra. ........................................................................................................ 46 Figura 32 Ruta mínima entre dos puntos dados. .............................................................................. 47 Figura 33 Diagrama a bloques de sistema Negocio2SMS. .............................................................. 48 Figura 34 Casos de uso para Negocio2SMS. ................................................................................... 49 Figura 35 Clases de paquete entidades. .......................................................................................... 50 Figura 36 Clases de paquete base de datos. ................................................................................... 51 Figura 37 Clases de paquete negocio. ............................................................................................. 51 Figura 38 Clases de paquete acciones. ............................................................................................ 52 Figura 39 Diagrama de clases de módulo Negocio2SMS. ............................................................... 53 Figura 40 Diagrama de secuencia de inicio de aplicación. ............................................................... 54 Figura 41 Diagrama de secuencia de registro de proveedor. ........................................................... 54 Figura 42 Registro de proveedor de servicios. ................................................................................. 55 Figura 43 Clave generada para el sistema Negocio2SMS. .............................................................. 55 Figura 44 Visualización de registro almacenado en la base de datos.............................................. 56 Figura 45 Trama mensaje. .............................................................................................................. 115 Figura 46 Detalle de cabecera. ....................................................................................................... 115 Figura 47 Datos extras. ................................................................................................................... 115 Figura 48 Detalle de dato. ............................................................................................................... 116 Figura 49 Trama PoiGeo................................................................................................................. 116 Figura 50 Campo dato de trama Q_GEO_UBICACION. ................................................................ 116

ix

Figura 51 Campo dato de trama Q_CAMINO_GEO_GEO. ............................................................ 116 Figura 52 PoiNoGeo........................................................................................................................ 117 Figura 53 Campo dato de trama Q_CAMINO_GEO_NOGEO. ...................................................... 117 Figura 54 Campo dato de trama Q_GEO_CLIMA. ......................................................................... 117

x

LISTADO DE TABLAS Tabla 1 Comparativa de trabajos de la literatura con plataforma propuesta. ................................... 11 Tabla 2 Comparativa de servicios comerciales con la plataforma propuesta................................... 13 Tabla 3 Clasificación de los LBS basada en acciones. .................................................................... 17 Tabla 4 Acrónimos de componentes de la arquitectura de la red GSM. .......................................... 21 Tabla 5 Categorías para los criterios de búsqueda. ......................................................................... 30 Tabla 6 Mensajes de ejemplo para consultas a la plataforma propuesta......................................... 30 Tabla 7 Módulos de GW-SMS........................................................................................................... 36 Tabla 8 Clases pertenecientes a módulos de GW-SMS................................................................... 41 Tabla 9 Módulos de Negocio2SMS................................................................................................... 48 Tabla 10 Características a probar de la plataforma. ......................................................................... 58 Tabla 11 Caso de prueba SBLAGWSMS-001-001. .......................................................................... 72 Tabla 12 Caso de prueba SBLAGWSMS-001-002. .......................................................................... 73 Tabla 13 Caso de prueba SBLAGWSMS-001-003. .......................................................................... 74 Tabla 14 Caso de prueba SBLAGWSMS-001-004. .......................................................................... 75 Tabla 15 Caso de prueba SBLAGWSMS-002-001. .......................................................................... 76 Tabla 16 Caso de prueba SBLAGWSMS-002-002. .......................................................................... 77 Tabla 17 Caso de prueba SBLAGWSMS-003-001. .......................................................................... 78 Tabla 18 Caso de prueba SBLAGWSMS-003-002. .......................................................................... 79 Tabla 19 Caso de prueba SBLAGWSMS-003-003. .......................................................................... 80 Tabla 20 Caso de prueba SBLAGWSMS-004-001. .......................................................................... 81 Tabla 21 Caso de prueba SBLAGWSMS-004-002. .......................................................................... 82 Tabla 22 Caso de prueba SBLSAGWSMS-004-003......................................................................... 83 Tabla 23 Caso de prueba SBLAGWSMS-004-004. .......................................................................... 84 Tabla 24 Caso de prueba SBLAGWSMS-004-006. .......................................................................... 85 Tabla 25 Caso de prueba SBLAGWSMS-004-007. .......................................................................... 86 Tabla 26 Caso de prueba SBLAN2SMS-001-001............................................................................. 87 Tabla 27 Caso de prueba SBLAN2SMS-001-002_1......................................................................... 88 Tabla 28 Caso de prueba SBLAN2SMS-001-002_2......................................................................... 89 Tabla 29 Resumen de los casos de prueba de la plataforma propuesta.......................................... 90 Tabla 30 Tareas descritas para las pruebas................................................................................... 109 Tabla 31 Requisitos ambientales de hardware. .............................................................................. 111 Tabla 32 Requisitos ambientales de software. ............................................................................... 111 Tabla 33 Características de plan de pruebas. ................................................................................ 112 Tabla 34 Valores del campo Tipo de la cabecera de la trama........................................................ 115 Tabla 35 Valores del campo Palabra. ............................................................................................. 116 Tabla 36 Valores del campo Distancia............................................................................................ 116 Tabla 37 Valores del campo tipo Evento. ....................................................................................... 117

xi

GLOSARIO API Application Programming Interface. Interfaz de programación de aplicación. Es el

conjunto de funciones y procedimientos que ofrece cierta librería para ser utilizado por otro software como una capa de abstracción. Representa una interfaz de comunicación entre componentes de software.

Bluetooth Es el estándar 802.15 para redes WPAN propuesto por el IEEE. Creado originalmente por un conjunto de empresas del sector informático para solucionar el problema de la interconexión de periféricos de manera inalámbrica. Son redes inalámbricas de corta distancia, no alcanzan distancias mayores a los 10 metros.

EDGE Enhanced Data rates for GSM of Evolution. Tasas de datos mejoradas para la evolución de GSM. Es una tecnología de la telefonía móvil celular, que actúa como puente entre las redes 2G y 3G. EDGE se considera una evolución del GPRS. Esta tecnología funciona con redes TDMA y GSM. Puede alcanzar una velocidad de transmisión de 384 Kbps en modo de paquetes.

Gateway Hardware o software que realiza la conversión de protocolos entre diferentes tipos de redes.

GIS Geographical Information System. Sistema de información geográfica. Es una integración de hardware, software, datos geográficos y personal diseñado para capturar, almacenar, analizar y desplegar la información geográficamente referenciada con el fin de resolver problemas de planificación y gestión. También puede definirse como un modelo de una parte de la realidad referido a un sistema de coordenadas terrestres y construido para satisfacer necesidades concretas de información.

GPRS General Packet Radio Service. Servicio general de radio paquetes. Es un servicio que permite enviar paquetes de datos a través de las redes GSM. Por "envío por paquetes" se entiende aquellos datos que se pueden dividir en partes que se van enviando uno detrás del otro. De esta forma se pueden enviar varios paquetes por distintos canales o aprovechar los "huecos" que se producen en la comunicación y conseguir de esta forma un aprovechamiento más efectivo de los canales de transmisión.

GPS Global Position System. Sistema de posicionamiento global. El sistema GPS es un sistema de posicionamiento que permite, a través de 24 satélites en órbitas alrededor de la tierra, localizar mediante unas coordenadas únicas cualquier equipo radio receptor terrestre.

GSM Global System for Mobile communication. Sistema global para las comunicaciones móviles. GSM es un sistema digital de telefonía móvil que provee un estándar común para los usuarios, permitiendo el roaming internacional y la capacidad de ofrecer a alta velocidad servicios avanzados de transmisión de voz, datos, video y otros servicios de valor agregado.

HTTP HyperText Transfer Protocol. Protocolo de transferencia de hipertexto. Protocolo desarrollado por la W3C para la transferencia de información a través de la Web. Es un protocolo sin estado –no guarda información sobre conexiones anteriores- y está basado en el modelo de cliente-servidor.

xii

LBS Location Based Services. Servicios basados en localización. Son servicios que se proporcionan a un dispositivo en un instante determinado.

MMS Multimedia Messaging Service. Servicio de mensajería multimedia. Es un estándar de para los sistemas de mensajería de las telefonías celulares que permite el envío de mensajes que incluyen objetos de multimedia tales como: imágenes, audio, video y texto enriquecido.

MVC Model Vist Controller. Modelo Vista Controlador. Es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones Web, donde la vista es la página HTML el modelo es el sistema de gestión de base de datos y el controlador representa la lógica de negocio.

PostGIS Módulo que añade soporte de objetos geográficos a la base de datos objeto-relacional PostgreSQL para su utilización en Sistema de Información Geográfica. Se publica bajo la GNU -General Public License-.

PostgreSQL Servidor de base de datos libre desarrollado en su primera versión con el nombre de Ingres, proyecto desarrollado en la universidad de Berkeley. Considerado como el referente a los sistemas manejadores de base de datos libres.

Roaming Concepto utilizado en comunicaciones inalámbricas que está relacionado con la capacidad de un dispositivo para moverse de una zona de cobertura a otra.

Servicio Web

Conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web, intercambian datos entre sí con el objetivo de ofrecer servicios.

Shapefile Formato de archivo de tipo vectorial con extensión .shp desarrollado por la empresa Esri para la representación de la información a través de geometrías y un sistema de referencia espacial.

SMPP Short Message peer to peer Protocol. Protocolo punto a punto de mensajes cortos. Protocolo estándar de telecomunicaciones pensado para el intercambio de mensajes SMS entre equipos que gestionan los mensajes como pueden ser los SMSC ó un sistema de solicitud de SMS como puede ser un servidor WAP o cualquier gateway de mensajería.

SMS Short Message Service. Servicio de mensajería corta. Es una tecnología para la transmisión de mensajes de texto desde y hacia un teléfono móvil, fax, y/o dirección de IP. El cuerpo del mensaje es de 140 bytes que equivalen a 160 caracteres.

SOAP Simple Object Access Protocol. Protocolo de acceso de objeto simple. Protocolo basado en mensajes XML utilizado para el intercambio de datos entre aplicaciones de red encapsulados sobre HTTP.

Struts Marco de trabajo desarrollado por la fundación Apache para desarrollar aplicaciones empresariales bajo el patrón MVC –Model Vist Controller-.

TDMA Time Division Multiple Access. Acceso múltiple por división de tiempo. Es una tecnología inalámbrica que divide un único canal de frecuencia de radio en varios canales de tiempo. A cada canal se le asigna un espacio de tiempo especifico para la transmisión, lo que hace posible que varios usuarios utilicen el mismo canal simultáneamente sin interferir entre si.

UDDI Universal Description Discovery and Integration protocol. Protocolo de

xiii

descripción universal, exploración e integración. Define una interfaz SOAP con un registro de servicios Web. Es una iniciativa industrial abierta, en donde los negocios se listan a sí mismos en Internet, como si se tratase de las páginas amarillas en una guía telefónica. Es patrocinado por OASIS y permite a las empresas publicar listas de servicios y descubrirse entre sí.

WAP Wireless Application Protocol. Protocolo de aplicaciones inalámbricas. Es un estándar abierto internacional para aplicaciones que utilizan las comunicaciones inalámbricas con el objetivo de tener acceso a Internet desde los dispositivos móviles. Desarrollado por el WAP Forum conformado por cuatro empresas del sector de telecomunicaciones: Sony-Ericsson, Nokia, Motorota y chafatel.

WSDL Web Service Description Language. Lenguaje de descripción del servicio Web. Es un archivo XML en el que se identifica el servicio y se indica el esquema para poder utilizarlo, qué operaciones se pueden realizar con él, así como el protocolo o protocolos que son posibles utilizar.

XML eXtensible Markup Language. Lenguaje de marcado extensible. Es un meta-lenguaje que permite definir lenguajes de marcado adecuados a usos determinados. En la práctica corresponde a un estándar que permite a diferentes aplicaciones interactuar entre sí a través de una red.

Capítulo 1 Introducción

Capítulo 1 Introducción En este capítulo se muestran los antecedentes que existen en el Cenidet sobre el trabajo de tesis desarrollado, el problema a abordar junto con la motivación y justificación del desarrollo de esta tesis. Se describen los trabajos relacionados y estado del arte que influyen para el desarrollo del presente trabajo y por último se muestra la manera en que se encuentra estructurado el documento.


- - 2

1.1. Introducción. Un hito importante para conectar clientes potenciales, proveedores de servicios y productos fue marcado por la sección amarilla. Este fue uno de los instrumentos que impactó como mecanismo de enlace entre usuarios, proveedores de servicios y productos potenciales. Con la evolución de las tecnologías de comunicación, la sección amarilla tomó un nuevo enfoque, pasando de ser un libro de papel a un documento electrónico en la Web. El acceso a esta información por medios electrónicos vino a potencializar aún más el contacto entre los usuarios y los proveedores de servicios.

La Web como sistema informático ya no sólo ofrecía servicios tales como: encontrar una farmacia, hospital o productos consumibles, también se habilitaron servicios de clima, resultados de eventos deportivos, asesorías financieras, carteleras de cine, etc.

La Web marcó otro hito entre la interacción de clientes con los proveedores de servicios, sin embargo, la historia no para ahí, ya que la evolución en las tecnologías de comunicaciones ha avanzado a tal grado que ahora es posible que cualquier persona pueda acceder a sistemas informáticos desde la comodidad de un teléfono celular. Este hecho incrementó, de manera potencial la cantidad de clientes y usuarios hacia los servicios y productos ofrecidos por los distintos proveedores. El uso de la computadora y la Web, ha incrementado el número de usuarios y clientes potenciales de compañías que ofrecen productos y servicios a través de estos medios.

Con los evolución de los sistemas y tecnologías surgen los servicios basados en localización qué, en combinación con los sistemas de información geográfica –SIG- han permitido el desarrollo de un nuevo conjunto de servicios que se ofrecen en un tiempo y lugar determinado. Aplicaciones que en principio se utilizaron a través de Internet sobre plataformas de escritorio –páginas amarillas, búsqueda de hoteles, restaurantes, puntos de interés, cálculo de rutas etc.-; han migrado y ahora son servicios que se ofrecen por medio de dispositivos móviles en diversos formatos y categorías donde la ubicación es un punto crucial.

Por otro lado el incremento en el uso de la telefonía celular y la mensajería SMS ha desatado el desarrollo de múltiples aplicaciones para los usuarios de esta tecnología. Según estadísticas de COFETEL [COF07] existen en el país alrededor de sesenta millones de teléfonos celulares, lo que representa que por cada diez personas seis de ellas cuentan con un dispositivo de este tipo.

Con el fin de disminuir costos de migración y desarrollo de plataformas específicas para ofrecer servicios basados en localización y servicios de proveedores disponibles en la Web hacia los celulares, se propone una arquitectura para el desarrollo de aplicaciones basadas en localización orientada a dispositivos móviles que permita a proveedores de servicios entrar de manera más rápida, fácil y menos costosa al mercado de usuarios de celulares a través de la mensajería SMS.

1.2. Antecedentes. En el Cenidet, específicamente en el área de sistemas distribuidos, se han realizado trabajos relacionados con el cómputo móvil. Los trabajos centran su atención en diversas problemáticas que existen en esta área -problemas de visualización en dispositivos móviles, interoperabilidad entre plataformas, problemas de conexión- y principalmente en el desarrollo tecnológico que aportan estas investigaciones. Dentro de los proyectos relacionados a este trabajo están:


- - 3

i. Sistema de archivos sobre una plataforma de servicios de Web. Se realizó el diseño e implementación de un sistema de archivos que ofrece un conjunto de funciones básicas para la gestión de archivos y directorios sobre un ambiente multiplataforma, utilizando la tecnología de los servicios Web[CAC05].

ii. Desarrollo de un prototipo de comercio electrónico orientado a dispositivos móviles

incorporando el Sistema de Posicionamiento Global. En este trabajo se desarrolló el prototipo de un módulo de búsquedas orientadas a servicios comerciales dependientes de la ubicación del usuario utilizando el protocolo de acceso inalámbrico –WAP- y el sistema de posicionamiento global –GPS- [SOL06].

iii. Gestor de acaparamiento de sitios Web transcodificados para plataforma Pocket PC. En

este trabajo se realizó el diseño e implementación de un prototipo de agente intermediario para plataforma Pocket PC 2000, que gestiona el acaparamiento de páginas Web transcodificadas cuando se presentan eventos de desconexión [OLI06].

A través de estos trabajos se reconoce la importancia de las tecnologías inalámbricas y el

potencial que se tiene en su desarrollo, especialmente enfocados en la creciente industria celular y sobre todo en los servicios basados en localización que se pueden ofrecer mediante la tecnología de los SMS.

1.3. Descripción del Problema. La industria de los servicios basados en localización ha tenido una evolución impresionante en los últimos años, debido a esto, aplicaciones que se ofrecían por medio de plataformas de escritorio a través de la Web, ahora son accedidas por dispositivos celulares por medio de enlaces GPRS1 o EDGE2 que permiten el acceso a la red de redes –Internet-. Sin embargo estas tecnologías no tiene la aceptación que se esperó en su momento, ya que salen a relucir diversos problemas entre los que destacan: la configuración de dichos dispositivos y en otras ocasiones que dichos servicios no están accesibles en cualquier sitio donde se tenga cobertura por parte del proveedor de telefonía. Con estas limitantes, aunque los servicios proporcionados son realmente buenos presentan restricciones que en contraparte con la mensajería de SMS no se tienen.

En este punto la transferencia por medio de mensajería de SMS resulta una buena alternativa para proporcionar servicios basados en localización aprovechando la facilidad de utilización y dándole el enfoque de servicios de LBS.

Actualmente, las pasarelas existentes para el envío y recepción de mensajería de SMS, no realizan el procesamiento de la información de manera que se proporcionen servicios basados en localización; y utilicen las tecnologías de los servicios Web para proporcionar la información demandada basada en la ubicación geográfica. Por otra parte, los servicios que se proporcionan a través de las compañías de telefonía celular utilizan técnicas de posicionamiento basadas en su red celular, lo que limita el acceso a los servicios sólo a los usuarios de la misma compañía celular.

Por esta razón se propone el desarrollo de la arquitectura de un Gateway que permita la

integración de diversos servicios que puedan ser accedidos por mensajería de SMS y que se ofrezcan como servicios basados en localización, proporcionando información relevante en un punto y tiempo determinado. Adicionalmente, se integran las tecnologías de los servicios Web

1 GPRS: General Packet Radio Service. Servicio general de radio paquetes. Servicio que permite enviar paquetes de datos a través de las redes GSM. 2 EDGE: Enhanced Data rates for GSM of Evolution. Tasas de datos mejoradas para la evolución de GSM. Alcanza velocidades de transmisión de 384 Kbps en modo de paquetes.


- - 4

para aprovechar sus ventajas, enfocados a los servicios basados en localización. El desarrollo de aplicaciones sobre esta tecnología representa un potencial de explotación a gran escala.

1.4. Objetivo. El objetivo general de esta tesis es desarrollar una pasarela -Gateway- para el procesamiento de mensajes SMS que identifique el tipo de consulta proveniente del cliente móvil y la procese de manera local a través de un sistema de información geográfica o de manera externa por tecnologías de servicios Web. De forma particular se plantean los siguientes objetivos específicos:

i. Implementar una arquitectura de cómputo que permita ofrecer a usuarios de telefonía celular los servicios disponibles en Internet –con tecnologías de servicios Web y basados en su localización- a través de la mensajería de SMS.

ii. Procesar los mensajes SMS provenientes de cualquier proveedor de telefonía celular sin importar la tecnología GSM ó GPRS que utilice y separarlo en diferentes parámetros.

iii. Realizar la invocación remota de servicios Web a través de peticiones SOAP/HTTP.

iv. Permitir el registro de servicios que cuenten con tecnología de servicios Web que se

ofrezcan en Internet.

v. Diseñar e implementar una base de datos espacial que satisfaga las necesidades de la arquitectura propuesta.

1.5. Justificación y Beneficios.

1.5.1. Justificación. La motivación principal del desarrollo de esta tesis fue:

• Eliminar la dependencia que tiene tienen los usuarios con la red celular del proveedor de servicios para acceder a la información basada en la localización que se proporcionan a través de diversos formatos.

• Habilitar una pasarela que proporcione servicios basados en localización a través de la

mensajería de SMS.

• Integrar las tecnologías de los sistemas de información geográfica, el sistema de posicionamiento global, la mensajería de SMS y los servicios Web para proporcionar los servicios basados en localización.

• Contar con una arquitectura que sea escalable y permita la representación en diversos

formatos.


- - 5

Las estadísticas de la evolución de la telefonía celular se observan en la Figura 1

0

10000

20000

30000

40000

50000

60000

70000

1990 1992 1994 1996 1998 2000 2002 2004 2006

Telefonía móvil (miles deusuarios 1990 - 2007)

Figura 1 Incremento de telefonía móvil en México [COF07].

En la Figura 1, se observa que, en la última barra correspondiente al año 2007, el total de

dispositivos rebasa los sesenta millones de unidades lo que representa que seis de cada diez personas cuentan con un celular habilitado para la transmisión de SMS. Estas cifras según [COF07] representan un incremento del veintidós por ciento con respecto al mismo período del 2006.

No sólo la telefonía celular ha ido en aumento en el transcurso de los años, la mensajería de SMS también ha tenido una evolución y mayor uso. En [NET07] se observan las cifras proporcionadas por Sybase.

0102030405060

L M M J V S D

Millones de SMS por día

Figura 2 Estadísticas de envío de mensajes SMS por día [NET07].

Como se observa en la Figura 2 en el país se envían un promedio de treinta y ocho

millones de SMS cada día y hasta cincuenta y cinco millones los días del fin de semana, lo que representa un promedio de cuarenta y dos punto ochenta y cinco millones de mensajes de SMS al día y, da un panorama de la utilización de este servicio.

El acceso a la información y servicios a través de mensajería SMS representa un gran mercado de desarrollo y aunque los usuarios cuentan con una opción como lo es WAP3 para acceder a sistemas de información, ésta no ha sido utilizada ampliamente porque implica una

3 WAP: Wireless Application Protocol. Protocolo de aplicaciones inalámbricas. Estándar para aplicaciones que utilizan las comunicaciones inalámbricas con el objetivo de tener acceso a Internet desde los dispositivos móviles.


- - 6

conexión permanente, lo que se traduce en un alto costo de conexión, desmotivando así su uso y aplicación. Otra razón por la que la opción de WAP no ha sido explotada es por los problemas que presenta en la configuración y activación del servicio.

1.5.2. Beneficios.

i. Contar con un desarrollo tecnológico que permita deslindar a los usuarios de la dependencia de la red celular, para obtener los servicios basados en localización. Las aplicaciones existentes en el sector privado, ofrecen los servicios de envió/recepción de mensajería SMS sobre su propia red celular, delimitando esos servicios solamente para usuarios de la misma compañía.

ii. Desarrollar un sistema de registro de proveedores que permita almacenar la ubicación del

proveedor de forma georeferenciada, para utilizar esta información dentro de la plataforma propuesta.

iii. Permitir a las industrias olvidarse del desarrollo de aplicaciones para diferentes

tecnologías, por las cuales puedan ofrecer sus servicios, con lo cual se eliminan los costos de nuevas infraestructuras tecnológicas y se pueden ofrecer los mismos servicios a mayor cantidad de usuarios.

iv. Ofrecer servicios basados en localización a los usuarios de telefonía celular a través de la

mensajería SMS como una alternativa a los sistemas que operan sobre WAP.

1.6. Alcances. Como producto resultado se pretende diseñar e implementar una arquitectura que permita la consulta de servicios y proveedores de servicios por medio de mensajería de SMS. La arquitectura será estructurada con módulos que formen el núcleo de la plataforma, los cuales proporcionen la funcionalidad básica y cuente con la opción de incorporar nuevos módulos para presentar la información en diversos formatos sin tener que modificar toda la estructura de la plataforma.

La plataforma cuenta con un sistema de información geográfica que permite responder a las peticiones de los servicios basados en localización a través de la mensajería de SMS. Los alcances específicos de este proyecto se mencionan a continuación:

i. Se permite el envío/recepción de cualquier dispositivo que tenga la capacidad de transferir un mensaje SMS.

ii. En la plataforma se cuenta con estrategias para el tratamiento y clasificación de los mensajes.

iii. La plataforma responde a peticiones georeferenciadas o no georeferenciadas, la petición

se puede realizar con coordenadas de tipo latitud-longitud en caso de ser georeferenciadas o por medio del nombre de calles, colonias o código postal cuando no son georeferenciadas.

iv. Desarrollar un sistema Web que permite el registro de proveedores de servicios para el despliegue de su información en formato de mensajes de SMS.

v. Se permite la invocación de servicios Web que pueden ser o no servicios georeferenciados para mostrar su información en dispositivos celulares a través de SMS.


- - 7

vi. Se desarrolló una base de datos espacial que satisface las necesidades de la arquitectura propuesta.

1.7. Limitaciones.

i. El desarrollo sólo contempla la transferencia por medio de mensajes SMS – información en texto-.

ii. Las pruebas de verificación se realizaron en el espacio donde se encuentra el Cenidet para las consultas georeferenciadas o no georeferenciadas.

iii. El módulo de los servicios Web se validó con un servicio de clima.

iv. El envío de la información está limitado por los 160 caracteres que se tienen para el envío

de los mensajes SMS. La reducida cantidad de caracteres que se tienen para el envío de la información, limita el que alguna operación se realice de manera real por lo cual, la opción de mostrar el camino más corto solamente se simulará.

1.8. Estado del Arte. La investigación del estado del arte cubre dos aspectos: el primero son los trabajos encontrados en la literatura y el segundo son aquellos desarrollos existentes, en su mayoría del sector privado y que se proporcionan a los usuarios por parte del proveedor de telefonía o un tercero.

Para cubrir el primer punto se mencionan los trabajos más importantes encontrados junto con sus características. Location Services in the GSM and UMTS Networks [TAY05]. En este artículo se muestran las tecnologías de posicionamiento relacionadas con los servicios basados en localización, la mayoría de ellas basadas en la red celular. Se menciona la importancia de los LBS y se compara el: desempeño, costo disponibilidad y actualización de las trayectorias para las futuras redes que se puedan beneficiar de los LBS. Se evalúan los requerimientos necesarios para implementar dichos servicios en redes GSM y UMTS; y comparan las tecnologías de localización disponibles para los operadores de dichas redes. En resumen en este artículo se discuten los siguientes puntos:

a). La arquitectura general de red para servicios basados en localización. b). Una discusión sobre las tecnologías de localización basadas en estándares para redes

GSM4 y UMTS5.

c). Un procedimiento de posicionamiento de red general.

d). Un resumen comparativo de las tecnologías de localización comparando aspectos como: limite de precisión, implementación y costo.

Using SMS to Deliver Location Based Services [KRI02]. En este artículo se introduce el concepto de los servicios basados en localización y la importancia que tienen para los operadores de la telefonía. Se discute como estos servicios a través de la 4 GSM: Global System for Mobile communication. Sistema global para las comunicaciones móviles. 5 UMTS: Universal Mobile Telecommunication System. Sistema de telecomunicación móvil universal. Es una tecnología utilizada por los móviles de tercera generación, es el sucesor de la red GSM.


- - 8

mensajería SMS, pueden retribuir la inversión de las redes existentes. Otro aspecto importante es la discusión de las ventajas y desventajas que conlleva el enfoque de los servicios basados en localización a través de mensajes SMS.

La Figura 3 muestra el enfoque tradicional para la petición-respuesta de servicios a través de dispositivos móviles.

Figura 3 Implementación basada en HTTP/XML [KRI02].

Una implementación que se propone en este artículo diferente a la forma tradicional que se

realiza a través de WAP es la que se muestra en la Figura 4.

Figura 4 Implementación en Java de propuesta SMS [KRI02].


- - 9

La propuesta de este enfoque tiene algunas limitaciones que se mencionan a continuación:

i. Los mensajes SMS tienen una limitante de 160 caracteres. Si la longitud de caracteres del resultado excede este límite, la respuesta debe ser enviada en múltiples mensajes.

ii. Aplicaciones tales como direcciones de manejo que necesitan mapas no pueden ser utilizadas. Solamente se tiene información textual como direcciones.

A Model of Location Based Services for Crime Control [ROO03]. El objetivo de este trabajo es, presentar los resultados del diseño de un modelo de servicios basados en localización para el control del crimen que refleje las demandas de los ciudadanos y la policía. Se analizan aspectos de seguridad. El sistema se desarrolló mediante la integración del Minnesota MapServer –sistema para el desarrollo de aplicaciones GIS basadas en Web-, un servidor Web y una base de datos de crimen dentro de un ambiente cliente-servidor basado en Web. El sistema es accedido mediante dispositivos móviles o cualquier PC, después que los usuarios se identifican en el sistema, éste convierte a coordenadas en forma de latitud-longitud la información y se envía a la base de datos la cual esta compuesta por datos de crimen y los datos espaciales.

El modelo planteado en este trabajo se muestra en la Figura 5, donde se observan los módulos que lo componen.

Figura 5 Modelo de LBS para el control del crimen [ROO03].

Location-based ticketing in public transport [BÖH05]. El objetivo del trabajo presentado en [BÖH05] es: aplicar la tecnología de los LBS en el campo de los boletos de transporte público basados en localización. Para utilizar el servicio es necesario el registro con el proveedor del servicio. Las metas principales de este proyecto son:

i. Verificar la precisión que se necesita en la localización para calcular el precio del boleto.


- - 10

ii. Probar métodos de mejora para la localización de los teléfonos con diferentes redes

celulares.

iii. Contar con la aceptación por parte de los usuarios para el trazo de su localización en el transporte público.

iv. Determinar la información que necesita el usuario en un punto determinado y verificar que

información puede proporcionar el sistema.

La localización está basada en la red celular por medio de algoritmos desarrollados en esta investigación. El proyecto desarrolla una investigación técnica y se enfoca a los procesos de negocio detrás de la venta de boletos de transporte público basados en localización. La meta principal de las pruebas realizadas es: la demostración del proceso del servicio que inicia con el registro del usuario y finaliza con la facturación y cobro del servicio.

El trabajo esta basado en tecnología GPRS y programas desarrollados en Java para realizar el proceso dentro del sistema. La Figura 6 muestra la arquitectura general del sistema.

Figura 6 Arquitectura general del sistema de boletos basados en localización [BÖH05].

Developing GIS-Supported Location-Based Services [VIR01]. En este trabajo se realiza un análisis de la combinación de los sistemas de información geográfica y los LBS. Se desarrolló un sistema piloto que se denominó MLS –Multimeetmobile Location Services system-. Este sistema es utilizado para dispositivos móviles y ofrece mapas y servicios de navegación acompañados con la información basada en la localización del usuario.

El sistema trata de anticiparse a la disponibilidad de los servicios disponibles. Las principales características de este sistema son las siguientes:

i. Está basado en datos geográficos vectoriales.


- - 11

ii. Utiliza XML.

iii. Los cálculos son delegados a la aplicación cliente.

iv. La aplicación cliente del sistema MLS se encuentra implementada en Java.

v. Utiliza un algoritmo inteligente para la selección de datos.

vi. Soporta la administración de transacciones.

General Plataform of Location based Services in Ubiquitous Enviroment [XIA07]. Analiza las características de aplicaciones ubicuas y la relación que se tiene con los servicios basados en localización. En esta investigación se propone una plataforma general para los servicios basados en localización en ambientes sobre dispositivos móviles. Los trabajos anteriores, cubren el primer punto referente a los trabajos más importantes y relacionados con el desarrollo de esta tesis, en [KRI02] se observa una propuesta muy parecida al proyecto planteado.

En la Tabla 1, se muestra una comparativa de los trabajos anteriores con la plataforma que se propone en esta tesis.

Tabla 1 Comparativa de trabajos de la literatura con plataforma propuesta.

Nombre LBS GIS Posicionamiento Presentación

Datos Servicios

Web

Location Services in the GSM and UMTS Networks. Si No Basado en red GPRS, UMTS No

Using SMS to Deliver Location Based Services. Si No Basado en red SMS No

A Model of Location Based Services for Crime Control. Si Si Técnicas híbridas GPRS, WAP No

Location-based ticketing in public transport. Si No Basado en red WAP No

Developing GIS-Supported Location-Based Services. Si Si Basado en red WAP No

General Plataform of Location based Services in Ubiquitous Enviroment. Si Si Técnicas híbridas WAP No

Tesis Si Si GPS SMS Si

La mayoría de estos trabajos realizan el posicionamiento a través de la red celular ó tecnologías híbridas, esta característica hace que los servicios que se proporcionan sean dependientes de la red donde operan, por otra parte el soporte de un GIS es a través de un tercero lo cual limita su funcionalidad al desarrollo con el que cuenta el proveedor de la información espacial. La presentación de los datos en la mayoría de los trabajos es a través de tecnología WAP que no ha tenido la aceptación por parte de los usuarios por diversos problemas.

El trabajo más relacionado es el presentado en [KRI02], la limitante de este trabajo es su dependencia de la red celular donde opera y la información espacial la obtiene de un tercero. Por último, ningún trabajo presentado en la tabla anterior utiliza las tecnologías de servicios Web para proporcionar servicios basados en localización con información dinámica.


- - 12

La plataforma propuesta presenta ventajas considerables a los trabajos presentados puesto que incluye soporte para LBS, un SIG integrado, no depende de la red celular para proporcionar la ubicación e implementa las tecnologías de servicios Web para obtener información de servidores externos basada en la posición actual.

La segunda parte que conforma el estado del arte la cubren desarrollos tecnológicos que se encuentran operando en el sector privado, los principales desarrollos son servicios que proporcionan las compañías telefónicas para sus usuarios. Servicio de localización de UNEFON [UNE07]. Es una serie de servicios que permiten tener información de: localización, calles, lugares y puntos de interés cercanos, basado en la ubicación del teléfono dentro de la red celular Unefon.

El servicio cuenta con dos aplicaciones disponibles:

Ubícame: permite conocer la ubicación del usuario del servicio así como consultar puntos de interés alrededor de la ubicación.

Ubícalos: permite realizar la localización de otros usuarios dentro de la red Unefon y consultar puntos de interés que estén alrededor del usuario que se localizó. Servicio UBICACEL de iusacell [IUS07]. Servicio de localización que permite conocer la ubicación geográfica de dispositivos Iusacell. Sirve para localizar dispositivos con capacidad de GPS y GPSOne cuando se encuentren dentro del alcance de la red celular y satelital.

Su funcionamiento es el siguiente: mediante una aplicación instalada en el teléfono celular a través de técnicas de triangulación se obtiene la localización del dispositivo y se puede generar la respuesta sobre la ubicación del teléfono. Servicio Localízame de Movistar [MOV07]. Servicio proporcionado por la compañía telefónica Movistar para localizar dispositivos móviles por medio de mensajes SMS. Cuenta con la opción de localización por medio de su página de Internet, la localización se hace por medio de la infraestructura de red de la telefónica. Su precisión varía dependiendo de la zona en que se encuentra el dispositivo móvil.

Cuenta con tres opciones del servicio: para localizar otros dispositivos móviles, para que localicen mi dispositivo y para saber mi propia ubicación. Necesita autorización para conocer la ubicación de otro dispositivo. Servicio de sección amarilla por SMS [AMA07]. Es un servicio que proporciona la sección amarilla mediante mensajería SMS, se puede obtener información sobre servicios de los cuales se requiere información. Se pueden considerar servicios basados en localización aunque no contienen todos sus componentes. Permite realizar búsquedas por:

i. Servicio, Estado, Colonia.

ii. Nombre Comercial, Estado, Colonia.

iii. Servicio, Estado.


- - 13

iv. Servicio, Estado, Delegación/Municipio, Colonia.

v. Servicio, C.P.

En la Tabla 2 se muestra una comparativa de los trabajos relacionados, se muestran los

parámetros de comparación y las ventajas que se obtienen con la investigación desarrollada.

Tabla 2 Comparativa de servicios comerciales con la plataforma propuesta.

Nombre LBS GIS Posicionamiento Presentación

Datos Servicios

Web

Servicio de localización Unefon Si Si* Técnicas híbridas WAP,SMS No

Servicio UBICACEL de Iusacell Si Si* Técnicas híbridas WAP,SMS No

Servicio Localízame de Movistar Si Si* Basada en red WAP, SMS No

Servicios de sección amarilla por SMS Si No - SMS No

Tesis Si Si GPS SMS Si

La mayoría de los desarrollos presentados en la tabla anterior, utilizan técnicas híbridas para obtener la localización de los dispositivos. La presentación de los datos puede ser en una página Web o en formato de un SMS. La desventaja que tiene cada uno de estos desarrollos es su dependencia con la red celular para obtener la ubicación y proporcionar los servicios que se demandan. Con la plataforma que se propone no se tiene ninguna limitante para obtener la localización y la respuesta se envía con los servicios basados en la posición actual.

Otra ventaja de la plataforma propuesta sobre los desarrollos mencionados es que se tiene un módulo para la invocación de servicios Web, éste permite que la información a proporcionar sea dinámica y no solo estática, lo cual proporciona información actualizada -por ejemplo de climas, eventos, noticias- basada en la localización actual.

Por último, el registro de los proveedores de servicios se realiza por medio del sistema Web desarrollado, por lo que, el nivel de información de los servicios que se pueden ofrecer es muy variado y va acorde a los servicios que se tengan registrados en la base de datos espacial.

1.9. Organización de la Tesis. El documento se encuentra organizado en 6 capítulos, los cuales presentan la siguiente información:

Capítulo 2, “Marco Teórico”, se presentan los fundamentos teóricos de las diferentes

tecnologías usadas y su forma de operación. Se describen los conceptos utilizados en el desarrollo del documento y la forma en que se utiliza dicha tecnología para los objetivos propuestos.

* Se supone que utilizan un sistema de información geográfica, ya que no se puede asegurar debido a que no se cuenta con acceso a la información de la forma en que operan los servicios.


- - 14

Capítulo 3 “Propuesta de solución”, se presenta el análisis de requerimientos para la implementación de la plataforma, y la manera en que se aborda el problema a resolver a través de los distintos escenarios que se presentan para la disposición de la información.

Capítulo 4 “Implementación”, se muestra la implementación de la arquitectura y la forma en que colaboran los diferentes módulos que la conforman. Se describen las interfaces de usuario desarrolladas para su manejo y se menciona la relación entre cada uno de los módulos que la conforman.

Capítulo 5 “Pruebas y Resultados”, esta sección muestra las pruebas realizadas a la plataforma, sus características, lo que puede realizar y los principales resultados obtenidos de la arquitectura propuesta. Comprueba el cumplimiento de los objetivos propuestos y mediante los casos de prueba se comprueba el funcionamiento de la arquitectura.

Capítulo 6 “Conclusiones”, se presentan las conclusiones derivadas de este trabajo, las principales aportaciones que se generaron con la implementación de la plataforma y los posibles trabajos futuros que se pueden realizar derivados de esta investigación.

Finalmente se cuenta con una sección de anexos donde se encuentra información referente a la instalación de las herramientas utilizadas, una descripción de la manera en que trabajan, las funciones definidas en la especificación de características simples [SFS99] y ejemplos de funciones espaciales sobre la información almacenada en la base de datos espacial.

Capítulo 2 Marco Teórico

Capítulo 2 Marco Teórico En este capítulo se presentan los conceptos necesarios para comprender la forma en que trabajan las tecnologías utilizadas para el desarrollo. Se presentan los componentes de cada una de las tecnologías y su forma operación dentro de ellas.

Capitulo 2 Marco Teórico

- - 16

2.1. Servicios Basados en Localización. Los LBS –Location Based Services, Servicios Basados en Localización- son servicios que se proporcionan en un lugar y tiempo determinado. La información que proporcionan es dinámica y cambiante según el instante en el que se solicita. A continuación se muestran 2 definiciones que se dan para este tipo de servicios:

i. En [STE06] se define a los LBS como servicios de información accesible con dispositivos móviles a través de una red móvil y utilizando la capacidad de hacer uso de la localización del dispositivo móvil.

ii. En [OGC05] se define como un servicio inalámbrico a través de IP que usa información geográfica para servir a los usuarios móviles. Cualquier servicio ó aplicación que tome ventaja de la posición de un dispositivo móvil.

En las dos definiciones se hace referencia a la intersección entre 3 tecnologías. Según estas definiciones, los LBS están formados por: Sistemas de comunicaciones y dispositivos móviles, Internet y un sistema de información geográfica con bases de datos espaciales. La intersección de estas tecnologías se observa en la Figura 7 y se puede ubicar el lugar que tienen los LBS dentro de ellas.

Figura 7 Componentes de los LBS.

2.1.1. Componentes de los LBS. En la arquitectura de los LBS intervienen diferentes elementos que colaboran entre sí para proporcionar la información que es requerida por el usuario en un instante determinado. Los componentes se describen a continuación [STE06]:

i. Dispositivos móviles: El medio por el cual los usuarios piden la información que requieren.

ii. Red de comunicación: El medio por el cual se transfiere la información entre el proveedor del servicio y el usuario.

iii. Componente de posicionamiento: Utiliza alguna técnica de posicionamiento para obtener

datos acerca de la localización del usuario. El método puede variar y puede ser mediante técnicas basadas en la red celular o a través del sistema de posicionamiento global.


- - 17

iv. Proveedor de contenido: Los servicios que se pueden proporcionar para las diferentes

peticiones provenientes del usuario.

Las aplicaciones de los LBS que se pueden desarrollar son variadas y amplias, debido a esto

se clasifican en base a las operaciones que se realizan o a la información que es demandada. En [STE06] se muestra una clasificación basada en las acciones que realiza el usuario, dichas clasificación se pueden observar en la Tabla 3.

Tabla 3 Clasificación de los LBS basada en acciones.

Acción Interrogante Operación

Orientación y clasificación

¿Dónde estoy? ¿Dónde está?

Posicionamiento Geocodificación

Navegación ¿Cómo voy a…?

Posicionamiento Geocodificación Ruteo

Búsqueda ¿Dónde está x, y?

Posicionamiento Geocodificación Calculo de distancia

Identificación

¿Qué es? ¿Quién está ahí?

Búsquedas temáticas ó espacial , selección,

Verificación de eventos ¿Qué sucede en…? *

2.1.2. Servicios PUSH y PULL. Existen dos tipos de servicios de localización y se basan en la consideración de si la información es entregada por la interacción del usuario o no. A continuación se describen dichos servicios:

i. Servicios Pull: Estos servicios entregan información solicitada directamente por el usuario. La información se envía bajo demanda y es el usuario o cliente quien inicia el proceso para recibir la información. Un ejemplo de este tipo de servicio son las peticiones que se realizan por medio de un navegador Web hacia Internet; el usuario es quien inicia la petición introduciendo la URL6 en el navegador, cuando el servidor obtiene una petición, este responde con la información pertinente. Mientras el servidor no recibe ninguna petición, aunque cuenta con la información, éste no la envía hasta que se solicite por algún usuario.

ii. Servicios Push: Este tipo de servicio entrega la información que es indirectamente pedida

por el usuario. Son activados por un evento, el cual podría ser disparado si una área específica es registrada o disparada por un cronometro. Un ejemplo de los servicios push son los registros en sitios Web donde posteriormente a cada tiempo determinado se envía publicidad o noticias relevantes sobre algún tema de interés.

6 URL: Uniform Resource Locutor. Localizador de recurso uniforme. Secuencia de caracteres de acuerdo a un formato estándar, que se usa para nombrar recursos en Internet por su localización.


- - 18

2.2. Sistemas de Información Geográfica. Los sistemas de información geográfica por sus siglas en inglés Geographic Information System -GIS-, son una tecnología para el manejo de información geográfica. Es un conjunto de herramientas que permiten manejar eficientemente datos espaciales junto con sus características alfanuméricas asociadas [VEG02]. Otra definición es la que se dá en [VIA03] y dice: un software GIS se asemeja a un programa de base de datos, ya que analiza y relaciona información almacenada bajo la forma de registros, con una diferencia crucial: cada registro en una base de datos GIS contiene información usada para dibujar formas -normalmente un punto, una línea, o un polígono- también denominada información espacial.

Un GIS almacena y despliega información que puede ser relacionada con lugares, es decir, información que tiene una ubicación geográfica -geocodificación-.

El objetivo primordial de un GIS es abstraer la complejidad del mundo real a una representación simplificada entendible para el lenguaje de las computadoras actuales. Este proceso tiene diversos niveles y comienza con la concepción de la estructura de una base de datos organizada generalmente en capas.

En los GIS existen relaciones espaciales entre los objetos geográficos que el sistema no puede obviar; es lo que se denomina topología que es usada para definir las relaciones espaciales entre los objetos geográficos. Los sistemas de información geográfica se clasifican en dos categorías –vectoriales y raster- que cuentan con características diferentes para su procesamiento y utilización.

2.2.1. Vectoriales.

Los GIS vectoriales son aquellos que utilizan vectores definidos por pares de coordenadas relativas a algún sistema cartográfico para la descripción de los objetos geográficos.

Con un par de coordenadas y su altitud se gestiona un punto, con dos puntos se genera una línea y con una agrupación de líneas se forman polígonos. En la Figura 8 se muestra como se estructura la información geográfica dentro de tablas en algún manejador de base de datos que permita el tratamiento de esta información [ORT01].

Figura 8 Representación de GIS vectorial.


- - 19

Este modelo es adecuado cuando se trabaja con objetos geográficos con límites bien establecidos, como pueden ser fincas, carreteras, puntos de interés etc.

2.2.1.1. Shapefiles. Un archivo shapefile con extensión .shp almacena información sobre las geometrías y atributos espaciales dadas en un grupo de datos.

Los shapefiles soportan características de un área, línea o puntos. Las características de área son representadas como un ciclo cerrado de líneas, las líneas como una secuencia de puntos y los puntos la más simple de esta representación. Los atributos alfanuméricos de cada objeto geométrico son guardados en un archivo de formato database file -.dbf- [ESR98]. Los archivos shapefile pueden ser creados por:

i. Exportación: Puede ser creado mediante la exportación de cualquier recurso de datos utilizando un software especial para dicho proceso.

ii. Digitalización: Pueden ser creados por la digitalización de capas utilizando herramientas de creación de características GIS. Por ejemplo con el software de ArcView de ESRI.

iii. Programado: Por medio de software específico se pueden crear los archivos shapefiles. Los componentes de un archivo shapefile son:

i. Un archivo principal, “.shp”, contiene una cabecera de longitud fija seguida de los registros de longitud variable. Cada registro consta de una cabecera y su contenido.

ii. Un archivo de índice, “.shx”, que contiene el desplazamiento del registro del archivo principal correspondiente al inicio del mismo.

iii. Un archivo de tabla, “.dbf”, contiene atributos alfanuméricos relacionados por cada objeto

geométrico en un registro. La relación uno a uno entre geometría y atributos está basado en el número de registros.

Una característica importante de estos tipos de archivos es que los tres deben llamarse de la misma manera, en la Figura 9 se muestra un ejemplo de la estructura de un archivo shapefile.

Figura 9 Estructura de archivos shapefile.

2.2.2. Raster.

Los sistemas de información raster basan su funcionalidad en una relación de vecindad entre los objetos geográficos. Su funcionamiento se basa en dividir la zona en una retícula o malla de pequeñas celdas -pixel- y atribuir un valor numérico a cada celda como representación de su valor


- - 20

temático. Debido a que la malla es regular -el tamaño del pixel es constante- y se conoce la posición en coordenadas del centro de cada una de las celdas, se puede decir que todos los pixeles están georeferenciados [ORT01].

El inconveniente de estos sistemas es que a mayor número de filas y columnas en la malla -más resolución-, existe mayor esfuerzo en el proceso de captura de la información y mayor costo computacional a la hora de procesar la misma. La Figura 10 muestra la representación de éste tipo de GIS.

Figura 10 Representación de GIS raster. El modelo de datos raster es útil en la descripción de objetos geográficos con límites difusos, por ejemplo: la dispersión de una nube de contaminantes, o los niveles de contaminación de un acuífero subterráneo, donde los contornos no son absolutamente nítidos; en esos casos, el modelo raster es más apropiado que el vectorial.

2.3. Red Inalámbrica GSM. GSM -Global System Mobile, Sistema global para las comunicaciones móviles- es un sistema basado en el uso de células digitales, se desarrolló para crear un sistema de comunicación para dispositivos móviles que sirviese de estándar para Europa y que fuese compatible con los servicios existentes y futuros [LAB04].

En el año 1982 el CEPT -Conference of European Posts and Telecommunications, Conferencia europea de administraciones de correos y telecomunicaciones- creó el denominado GSM para desarrollar un sistema basado en células de radio servicio para todos los países europeos.

En el año 1989 todas las responsabilidades que había tenido el CEPT se traspasaron al

ETSI -European Telecommunications Standards Institute, Instituto de estándares de telecomunicación europeos-, este organismo es el encargado de regular todos los aspectos de las comunicaciones a través de GSM, los primeros sistemas comerciales basados en esta red aparecen en el año 1991.


- - 21

La arquitectura de la red GSM se muestra en la Figura 11.

Figura 11 Arquitectura de red GSM.

La Tabla 4 muestra el significado de los acrónimos observados en la Figura 11.

Tabla 4 Acrónimos de componentes de la arquitectura de la red GSM. Acrónimo Significado

BTS Base Tranceiver Station, Transmisor de estación base BSC Base Station Controller, Controlador de estación base

MSC / VLR Mobile services Switching Center / Visitor Location Register, Centro de conmutación de servicios móviles/ Registro de localización de abonados

HLR Home Location Register, Registro de localización principal SMSC Short Message Service Center, Centro de servicio de mensajería corta ISDN Integrated Services Digital Network, Red digital de servicios integrados VMS Virtual Memory System, Sistema de memoria virtual PSTN Public Switched Telephone Network, Red telefónica de conmutación publica

2.3.1. SMS. SMS -Short Message Service, Servicio de mensajería corta -, es una tecnología para la transmisión de mensajes de texto desde y hacia un teléfono móvil, fax, y/o dirección de IP. El cuerpo del mensaje es de 140 bytes que equivalen a 160 caracteres.

Permite transferir un mensaje de texto entre una estación móvil y un SME -Short Message Entity, Entidad de Mensajería Corta- que puede ser otra estación móvil o un nodo dentro de una red a través de un SMSC. Según [GPP06] la mensajería SMS puede ser de dos tipos:

i. SM MT -Short Message Mobile Terminated Point-to-Point-. Servicio de entrega de un mensaje desde el SC hasta una MS, obteniéndose un informe sobre lo ocurrido.

ii. SM MO -Short Message Mobile Originated Point-to-Point-. Servicio de envío de un mensaje desde una MS hasta un SC, obteniéndose un informe sobre lo ocurrido.


- - 22

La forma de operación de este servicio se muestra en la Figura 12.

Figura 12 Pasos para el envío de mensajes SMS.

2.4. Servicios Web. Según la literatura existen diversas definiciones para la tecnología de servicios Web. Las que más se apegan al concepto de esta tecnología se mencionan en los siguientes puntos:

i. Un servicio Web es una interfaz que describe una colección de operaciones que son accesibles en una red por medio de mensajes XML estandarizados, es descrito usando un estándar, una noción formal de XML al cual se le llama descripción del servicio. Este cubre todos los detalles necesarios para interactuar con servicios tales como: El formato de mensaje, protocolo de transporte y localización [KRE01].

ii. Un servicio Web en [KNU02] es definido como un componente con las siguientes características:

a. Un servicio que implementa los métodos de una interfaz que es descrita por

WSDL. b. Una interfaz publicada en uno o más registros durante su despliegue. c. Una instancia llamada puerto que es manejada por el contenedor.

iii. El W3C7 los define como un conjunto de aplicaciones o tecnologías con capacidad para

interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer servicios [W3C05].

Los servicios Web permiten integrar aplicaciones de manera más rápida, fácil y menos

costosa. Su integración se da en el nivel superior de la pila de protocolos y está más orientado a la semántica del servicio que a los protocolos de red.

Los servicios Web permiten reutilizar las aplicaciones desarrolladas sin importar la plataforma en la que funcionan o el lenguaje en el que están escritos. La idea de los servicios Web es; ofrecer

7 W3C: World Wide Web Consortium. Consorcio internacional que se encarga del desarrollo de los estándares para la World Wide Web.


- - 23

una serie de servicios que se encuentran en distintas computadoras a través de la red y que además, son accedidos de modo independiente de la plataforma utilizando protocolos estándares [ROD02].

2.4.1. Arquitectura. La arquitectura de los servicios Web está basada en la interacción de tres componentes: El proveedor del servicio, el registro del servicio y quien solicita el servicio. La interacción involucra las operaciones de publicación, búsqueda y enlace con el servicio. La Figura 13 muestra los componentes y operaciones en la arquitectura de los servicios Web.

Figura 13 Componentes de los servicios Web.

Para desempeñar las operaciones definidas en la Figura 13 de manera interoperable debe

existir una pila de servicios Web que adopte estándares en cada nivel, en los cuales las capas superiores se construyen sobre las capacidades proporcionadas por las capas inferiores, la Figura 14 muestra una pila conceptual de los servicios Web.

Figura 14 Pila conceptual de los servicios Web.


- - 24

Debido a que los servicios Web son accesibles en una red por medio de mensajes SOAP y representados por una descripción del servicio, las primeras 3 capas de ésta pila son requeridas para proporcionar o usar cualquier servicio Web. La pila más simple consiste del protocolo HTTP para la capa de red, el protocolo SOAP para la capa de mensajes basados en XML y de WSDL para la capa de descripción del servicio.

2.4.1.1. Red. Esta es la capa fundamental sobre la que trabajan los servicios Web, representa cualquier protocolo de red. Los servicios Web son publicados y disponibles sobre Internet utilizando comúnmente protocolos como HTTP que es el protocolo de facto para que los servicios Web estén disponibles en Internet, aunque pueden ser soportados otros protocolos tales como: SMTP, FTP, RMI.

2.4.1.2. Protocolo SOAP. SOAP -Simple Object Access Protocol, Protocolo de acceso de objeto simple-. Protocolo basado en mensajes XML utilizado para el intercambio de datos entre aplicaciones de red por las siguientes razones:

i. Es un mecanismo para la comunicación centrado en el documento y para invocaciones de procesos remotos usando XML.

ii. Es simple: básicamente una petición POST de HTTP envuelto en XML.

iii. Es preferido sobre una petición HTTP POST de XML porque define un mecanismo estándar para incorporar extensiones al mensaje utilizando cabeceras SOAP y codificación estándar de las operaciones y funciones.

iv. Soporta las operaciones de publicación, búsqueda y enlace en la arquitectura de servicios

Web.

2.4.1.3. WSDL. WSDL -Web Service Description Language, Lenguaje de descripción del servicio Web-. Es un archivo XML en el que se identifica el servicio, se indica el esquema para poder utilizarlo, qué operaciones se pueden realizar con él y los protocolos que se pueden utilizar sobre el servicio.

2.5. Patrón MVC.

La arquitectura MVC -Model/View/Controller, Modelo Vista Controlador- fue introducida como parte de la versión Smalltalk-80 del lenguaje de programación Smalltalk, diseñada para reducir el esfuerzo de programación necesario en la implementación de sistemas múltiples y sincronizados. El desarrollo de las aplicaciones se puede realizar por separado en tres componentes y al final del desarrollo se conjuntan para construir el sistema o aplicación. Su característica principal es que sus componentes se tratan como entidades separadas; esto hace que cualquier cambio producido en un componente se refleje automáticamente en otro.

El propósito principal de organizar las aplicaciones de esta forma es: Dividir un componente o subsistema en tres partes lógicas –el modelo, las vistas y el controlador- haciendo que la modificación o personalización de cada una de las partes sea lo más sencilla posible [STE02].


- - 25

En la Figura 15 se muestra el diagrama de componentes de esta arquitectura.

Figura 15 Arquitectura del patrón MVC.

Una pequeña descripción de cada uno de los componentes se da a continuación:

i. Modelo: Representa los datos del programa. Maneja los datos y controla todas sus transformaciones. El modelo no tiene conocimiento específico de los controladores o de las vistas, ni siquiera contiene referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de mantener enlaces entre el modelo y vistas además de notificar a las vistas cuando el modelo cambia.

ii. Vista: Maneja la presentación visual de los datos representados por el modelo. Genera una

representación visual y muestra los datos al usuario. Interactúa con el modelo a través de una referencia al propio modelo.

iii. Controlador: Proporciona significado a las ordenes del usuario, actuando sobre los datos

representados por el modelo. Cuando se realiza algún cambio, entra en acción, bien sea por cambios en la información del modelo o por alteraciones de la vista. Interactúa con el modelo a través de una referencia al propio modelo.

Capítulo 3 Propuesta de Solución

Capítulo 3 Propuesta de Solución En el capítulo 3, se presenta la solución propuesta para solventar la disposición de información basada en localización a través de la mensajería de SMS. Se presenta la arquitectura planteada, se describen cada uno de los módulos que la conforman y se explica la forma en que operan. Por último se presenta una sección que define los criterios de búsqueda que se tienen contemplados y algunos ejemplos de los tipos de consultas que se pueden realizar sobre la plataforma.

Capítulo 3 Propuesta de solución

- - 27

3.1. Solución Propuesta. Para solucionar el problema de la disposición de información basada en la localización de los clientes móviles a través de mensajería de SMS, se propone una plataforma que integra un sistema de posicionamiento del lado cliente para obtener los datos de localización, un sistema de información geográfica –GIS- para la manipulación de los datos espaciales, la tecnología de los servicios Web y un dispositivo GSM para la transferencia de la información entre cliente y servidor.

En conjunto estos componentes proporcionan los servicios de localización para los dispositivos móviles por medio de la mensajería de SMS. Para la transferencia de la información se utiliza un dispositivo GSM que cuenta con una conexión directa al servidor que realiza el procesamiento de la información proveniente del dispositivo, el dispositivo GSM es el encargado de obtener los mensajes de los clientes que realizan las peticiones. El sistema de posicionamiento utilizado es el GPS que proporciona la ubicación en términos de latitud-longitud y permite obtener la localización de los dispositivos independientemente de la red celular a la cual pertenezcan. La tecnología de los servicios Web, proporciona el enlace con servicios externos a través de peticiones SOAP sobre HTTP para información que no puede ser resueltas por el GIS o que representa una información que se encuentra en constante cambio, por ejemplo, información sobre clima, noticias, eventos etc. Por último, el GIS que procesa las peticiones georeferenciadas basadas en la especificación de características simples del OpenGIS [SFS99].

El objetivo principal de esta tesis es proporcionar información -sobre servicios- basada en la localización actual del dispositivo por medio de mensajes de SMS. Debido a que algunos teléfonos no cuentan con un dispositivo GPS integrado o con enlace Bluetooth para establecer una conexión con un dispositivo GPS, en esta plataforma se contemplan búsquedas que no utilizan la información que se obtiene desde el dispositivo de posicionamiento, como alternativa se realizan búsquedas textuales que están basadas en el código postal, nombre de la colonia y calle.

Para solventar el problema de la disposición de los servicios que se encuentran disponibles en Internet a través de formatos como HTML se cuenta con un prototipo de registro de los servicios en la base de datos espacial y con la invocación de información a través de peticiones por medio de HTTP/SOAP. En las siguientes secciones se describen los módulos de la plataforma propuesta y la interacción entre ellos para proporcionar los servicios basados en localización.

3.2. Arquitectura Propuesta. El desarrollo de aplicaciones para servicios basados en localización abarca un conjunto de tecnologías que colaboran entre sí para proporcionar los servicios solicitados desde los dispositivos móviles. El modelo de la plataforma propuesto consta de dos módulos principales y la base de datos espacial. Dentro de la plataforma se consideran dos enfoques, uno por parte del proveedor del servicio y otro por parte del cliente que demanda y consume la información.

El primer módulo está relacionado con el proveedor del servicio que registra sus productos o servicios a través de una interfaz Web. El segundo módulo realiza la interacción con el cliente que demanda los servicios. Por último la arquitectura contiene una base de datos espacial que proporciona toda la información al módulo que interactúa con el cliente y sirve para almacenar y registrar nuevos proveedores de servicios desde el módulo del sistema Web. La Figura 16 muestra el diseño de la arquitectura general de la plataforma.


- - 28

Figura 16 Modelo de la plataforma propuesta. Un diagrama a bloques del funcionamiento general de la plataforma se muestra en la Figura 17.

Figura 17 Diagrama a bloques de la arquitectura propuesta.


- - 29

En el diagrama a bloques de la figura anterior se observan los 3 módulos principales –GW-SMS, Negocio2SMS, base de datos espacial- de la arquitectura propuesta. La forma de operación de la arquitectura se divide en dos: Por parte del cliente que solicita los servicios y por parte del proveedor que registra los servicios. La parte del cliente En la parte del cliente, el módulo que atiende las peticiones es el GW-SMS quien se encuentra ejecutándose y sondeando a intervalos de tiempos predefinidos –configurables- el dispositivo GSM en busca de nuevos mensajes. Los pasos a realizar después que llegan los mensajes de SMS al dispositivo GSM para ser procesados por el GW-SMS se mencionan a continuación:

i. Cuando el GW-SMS sondea el dispositivo GSM y encuentra mensajes almacenados en él, los extrae y almacena en memoria para procesarlos.

ii. Por cada mensaje, éste se descompone en diferentes tokens contemplados para realizar

su procesamiento.

iii. En base a los tokens que se obtienen es la acción que se realiza, el módulo GW-SMS es quien toma esta decisión a través del sub-módulo correspondiente. El sub-módulo cuenta con dos alternativas para responder a la información demandada: consultar la base de datos espacial o traer la información de servidores externos a través de peticiones SOAP sobre HTTP.

iv. Después que se procesó el mensaje, se retorna la información acorde a la petición

demandada por parte del dispositivo móvil.

En la parte cliente se cuenta con dos tipos de consultas: Georeferenciada, en la cual se envían las coordenadas en forma latitud-longitud dentro del mensaje y no georeferenciada donde las búsquedas se realizan textualmente basadas en parámetros como código postal, colonia y calle. La parte del proveedor del servicio Por la parte del registro de los proveedores de servicios, cada uno de los servicios registrados cuenta con información para su consulta a través de peticiones georeferenciadas y no georeferenciadas por medio de la mensajería de SMS. La mecánica que se sigue es la siguiente:

i. El usuario accede al front-end del sistema y se recolectan los datos de dicho servicio.

ii. Cuando se recolectan estos datos son procesados por el back-end y son almacenados en la base de datos espacial.

iii. Los datos almacenados en la base de datos espacial cuentan con información

georeferenciable para cada uno de los servicios que se registran por medio del módulo de Negocio2SMS.

3.3. Criterios de Búsqueda. Para la búsqueda de los servicios a través de la plataforma se estableció una lista de palabras clave dividida por categorías. Con esto la búsqueda de los servicios se delimita y se realizan búsquedas por tipos de servicio, por giro o por distancia desde el punto actual del usuario.

Las búsquedas se realizan basadas en información de posición por medio de las coordenadas latitud-longitud y a través de información textual para el caso de las consultas no georeferenciadas.


- - 30

La Tabla 5 muestra la lista de categorías propuesta en esta tesis para organizar los tipos

de servicios que se pueden registrar a la base de datos espacial.

Tabla 5 Categorías para los criterios de búsqueda. Categoría

1 HOTEL 2 BANCO 3 BUS 4 CINE 5 HOSPITAL 6 RESTAURANTE 7 SMERCADO 8 TAXI 9 PASTELERIA 10 CLIMA 11 MSUPER 12 GYM 13 ESCUELA 14 VIDEOS 15 FARMACIA 16 EVENTO 17 RCORTA

La mayoría de estas categorías están pensadas para organizar la información y responder

a consultas del tipo ¿Qué hay cerca de?; aunque también se cuenta con categorías para solucionar preguntas tales como: ¿Cómo puedo ir a? ¿Qué sucede en?. Que son interrogantes que los LBS pretenden solucionar auxiliados por la posición actual del dispositivo. La propuesta de solución para la recepción de los mensajes, abarca la interpretación de la información contenida en los SMS, por ejemplo, se contempla una estructura de los mensajes basado en palabras clave, donde el mensaje está organizado por campos que son procesados por el GW-SMS y dividido en tokens para interpretarlo según la trama definida para cada tipo de petición. La información de las tramas de los mensajes georeferenciados se muestra en el Anexo D. La Tabla 6 muestra ejemplos de peticiones que se contemplan para la búsqueda de los servicios.

Tabla 6 Mensajes de ejemplo para consultas a la plataforma propuesta. Mensaje Descripción del mensaje

0;2;0;14,10, 18.237349,-99.219723 Este mensaje define una consulta georeferenciada de las escuelas que se encuentran a una distancia lineal de 1000 metros de la ubicación del dispositivo móvil definida por los últimos dos parámetros.

Escuela Colonia Palmira 62490 Define una consulta no georeferenciada de las escuelas en la calle Palmira y con un código postal definido en el tercer parámetro.

Clima -99.121423 18.823824 Define una consulta georeferenciada para la invocación de información externa con la localización geográfica definida en los últimos dos parámetros.


- - 31

Clima Cuernavaca Define una consulta no georeferenciada para la consulta de la información externa.

En algunos ejemplos de la tabla anterior se observan campos numéricos, estos campos

representan la posición actual del dispositivo expresada en coordenadas geográficas del tipo Longitud-Latitud. En el caso de las consultas no georeferenciadas es necesario establecer explícitamente campos que permiten realizar la consulta, por ejemplo: en el caso del mensaje con el texto Escuela Colonia Palmira 62490 se solicita información sobre las escuelas en la colonia Palmira con el código postal 62490. Para las consultas no georeferenciadas no se puede realizar la consulta sólo con el nombre de la calle o colonia ya que dichos nombres se pueden repetir o ser parecidos, es por eso que se especifica el código postal que es único en una posición dada.

Incluso a nivel de municipio tampoco se puede realizar la búsqueda sólo por el nombre de la ciudad puesto que en diferentes estados existen municipios con nombres idénticos, por ejemplo: Tuxpan-Veracruz, Tuxpan-Jalisco ó Cuautla-Morelos, Cuautla-Jalisco.

Capítulo 4 Implementación

- - 32


Capítulo 4 Implementación En este capítulo se presenta el desarrollo de la arquitectura propuesta. Se diseña e implementan los módulos de la plataforma: base de datos espacial, módulo GW-SMS y el módulo Negocio2SMS. Se realizan los diagramas de clases necesarios para la implementación de cada uno de los módulos y se explica el funcionamiento en conjunto de los componentes que integran la plataforma propuesta.


- - 33

4.1. Base de Datos Espacial. Para la interpretación de la información espacial se trabaja con un manejador de base datos que soporta la especificación de características simples del OpenGIS8. Dicha especificación proporciona una extensión a los tipos de datos que se pueden utilizar dentro de un manejador de base de datos convencional. Esta especificación agrega el tipo de dato geométrico al cual son mapeados los datos espaciales.

La motivación de utilizar esta especificación es debido a que, recordando la definición de un sistema de información geográfica, estos sistemas representan toda una realidad en diversas capas, distinguidas principalmente en tres tipos:

i. Puntos, que pueden representar entidades únicas como: individuos, árboles, carros, ciudades, cualquier entidad que pueda representarse mediante un punto.

ii. Líneas, que permiten representar entidades como son: carreteras, calles, ríos etc.

iii. Polígonos, este tipo de geometría permite representar cualquier superficie que tenga un

perímetro, por ejemplo: estados, municipios, países, colonias, cuadras etc.

Con esta referencia se observa que se puede representar la realidad a una abstracción que puede ser manipulada por funciones espaciales dentro de un DBMS9 con soporte para datos espaciales.

El modelo de objetos geométricos se encuentra basado en una especificación del modelo geométrico del OpenGIS. La jerarquía de clases de este modelo se presenta en la Figura 18 [SFS99].

Geometría Sistema de Referencia Espacial

Punto Curv aColección GeométricaSuperficie

Grupo Lineas

Linea Anillo Linear

Polígono Multisuperficie Multicurv a

Multipunto

Multipolígono

Grupo Multilíneas

Figura 18 Jerarquía de clases geométricas.

8 OpenGIS: Consorcio internacional dedicado a desarrollar estándares para la interoperabilidad de los GIS. 9 DBMS: DataBase Manager System. Sistema administrador de base de datos.


- - 34

Geometría es la clase principal de la jerarquía de clases geométricas, esta es una clase

abstracta –no instanciable-. Sobre las clases de tipos geométricos derivados de la clase principal, se pueden realizar diversas operaciones que permiten el manejo de los objetos geométricos independientemente de su topología. Esta característica permite que se puedan realizar operaciones tales como intersecciones, cruces, traslapes, distancias entre objetos, uniones etc. Para la referencia completa de las operaciones soportadas por la Simple Feature Specification –SFS- consultar Anexo A.

Con esta característica, definiendo la posición del dispositivo móvil y la del servicio a buscar a través de una representación geométrica, se pueden realizar las operaciones geométricas definidas en [SFS99], y obtener información sobre que objetos se encuentran cerca, la distancia entre ellos, que objetos se encuentran dentro de una geometría y la relación entre geometrías de distinta topología. La Figura 19 muestra algunas operaciones definidas en [SFS99] efectuadas entre geometrías.

Figura 19 Operaciones sobre geometrías.

Para el manejo de la información espacial y relacional que se necesita, se desarrolló el

diseño conceptual de la base de datos. Dicha base de datos soporta el manejo de objetos geométricos y proporciona todas las funcionalidades definidas en [SFS99].

La base de datos da el soporte para los dos módulos que conforman la plataforma propuesta, permite el registro de nueva información proveniente del módulo Negocio2SMS y la consulta de información a través del módulo GW-SMS para su posterior transformación en formato de SMS. La Figura 20 muestra el diagrama relacional de la base de datos.

Capitulo 4 Implementación

- - 35

categoria

«column»*PK idcategoria: integer = nextval('catego...* tipo: varchar(15)

«PK»+ pk_categoria(integer)

«index»+ categoria_pkey(integer)

colonia

«column»*pfK idestado: integer = 0*pfK idmunicipio: integer = 0*PK idcolonia: integer = 0* descripcion: varchar(80)* cp: varchar(8)

«PK»+ pk_colonia(integer, integer, integer)

«index»+ colonia_pkey(integer, integer, integer)

«FK»+ colonia_ibfk_1(integer, integer)

estado

«column»*PK idestado: integer* nomestado: varchar(30)

«PK»+ pk_estado(integer)

«index»+ estado_pkey(integer)

geometry_columns

«column»*PK f_table_catalog: varchar(256)*PK f_table_schema: varchar(256)*PK f_table_name: varchar(256)*PK f_geometry_column: varchar(256)* coord_dimension: integer* srid: integer* type: varchar(30)

«FK»+ FK_geometry_columns_spatial_ref_sys(integer)

«PK»+ pk_geometry_columns(varchar, varchar, varchar, varchar)

«index»+ geometry_columns_pk(varchar, varchar, varchar, varchar)

msj temp

«column» n_telefono: varchar(15) p_clave: varchar(15) lat: varchar(12) long: varchar(12) tot_resul: integer tot_env: integer = 0 ban_res: boolean = false

municipio

«column»*PK idmunicipio: integer* nommunicipio: varchar(60)*pfK idestado: integer

«PK»+ pk_municipio(integer, integer)

«index»+ municipio_pkey(integer, integer)

«FK»+ municipio_idestado_fkey(integer)

rol_usuario

«column»*pfK idusuario: varchar(15)*pfK nombre_rol: varchar(15)

«FK»+ FK_rol_usuario_roles(varchar)+ FK_rol_usuario_usuario(varchar)

«PK»+ pk_rol_usuario(varchar, varchar)

«index»+ rol_usuario_pkey(varchar, varchar)

roles

«column»*PK nombre_rol: varchar(15)

«PK»+ pk_roles(varchar)

«index»+ roles_pkey(varchar)

serv icios

«column»*PK idservicio: integer = nextval('servic...* nomservicio: varchar(100) webservicio: varchar(40)* calle: varchar(25)* numero: integer colonia: varchar(20) cp: integer FK idcategoria: integer FK idestado: integer idmunicipio: integer the_geom*pfK idusuario: varchar(15) wsdl: boolean = false urlwsdl: varchar(80)

«FK»+ FK_servicios_usuario(varchar)+ categoria_idcategoria_fkey(integer)+ estado_idestado_fkey(integer)

«PK»+ pk_servicios(integer, varchar)

«index»+ servicios_pkey(integer, varchar)

«check»+ enforce_dims_the_geom()+ enforce_geotype_the_geom()+ enforce_srid_the_geom()

sms_in

«column»*PK id_sms: integer = nextval('sms_in... tipo: char(1) fecha_mensaje: time* origen: varchar(32) = ''::character v...* texto: varchar(160) num_ref: integer fecha_envio_original: time fecha_recibido: time

«PK»+ pk_sms_in(integer)

«index»+ sms_in_pkey(integer)

sms_out

«column»*PK id: integer = nextval('sms_ou...* recipient: varchar(45) = ''::character v...* text: text dispatch_date: time* status_report: integer = 0* flash_sms: integer = 0* src_port: integer = 0* dst_port: integer = 0* validity_period: integer = 0

«PK»+ pk_sms_out(integer)

«index»+ sms_out_pkey(integer)

spatial_ref_sys

«column»*PK srid: integer auth_name: varchar(256) auth_srid: integer srtext: varchar(2048) proj4text: varchar(2048)

«PK»+ pk_spatial_ref_sys(integer)

«index»+ spatial_ref_sys_pkey(integer)

usuario

«column»*PK idusuario: varchar(15)* password: varchar(15)* nomusuario: varchar(12)* apusuario: varchar(15)* amusuario: varchar(15)* mailusuario: varchar(35)

«PK»+ pk_usuario(varchar)

«index»+ usuario_pkey(varchar)

+FK_rol_usuario_roles 0..*

(nombre_rol = nombre_rol)

«FK»

+pk_roles

1

+FK_rol_usuario_usuario 0..*

(idusuario = idusuario)

«FK»

+pk_usuario 1

+FK_servicios_usuario

0..*(idusuario = idusuario)

«FK»

+pk_usuario

1

+estado_idestado_fkey

0..* (idestado = idestado)

+pk_estado

1

+categoria_idcategoria_fkey 0..*

(idcategoria = idcategoria)

+pk_categoria 1

+municipio_idestado_fkey 0..*

(idestado = idestado)

+pk_estado 1

+colonia_ibfk_1 0..*

(idestado = idmunicipioidmunicipio = idestado)

+pk_municipio 1

+FK_geometry_columns_spatial_ref_sys

0..*

(srid = srid)

«FK»

+pk_spatial_ref_sys 1

+FK_geometry_columns_servicios

Figura 20 Diagrama relacional de base de datos.


- - 36

En el diagrama de la base de datos se encuentran 3 tablas que permiten el manejo de la información espacial, estas son: spatial_ref_sys, geometry_columns y sql_features. La descripción de estas tablas se muestra a continuación:

i. spatial_ref_sys: Esta tabla almacena información sobre cada uno de los sistemas de referencia espacial en la base de datos. Describe los sistemas de coordenadas y transformaciones para las geometrías.

ii. geometry_columns: Esta tabla describe las tablas de características disponibles y sus

propiedades geométricas. Almacena un registro en esta tabla por cada tabla geométrica que exista en la base de datos. Esta tabla almacena las siguientes columnas por cada columna geométrica

• La identidad de la tabla de características a la que pertenece. • El identificador del sistema de referencia espacial –SRID-. • El tipo de geometría para la columna. • La dimensión sobre la cual se encuentra la tabla. • El nombre de la tabla que almacena ese tipo de geometría.

En el diagrama se observan 3 tablas: msjtemp, smsin y smsout. Estas tablas almacenan

los mensajes recibidos y enviados por parte del módulo GW-SMS. La tabla de msjtemp se utiliza para llevar un control de las peticiones cuando se tiene más de un registro de respuesta.

Las tablas restantes: colonia, municipio, estado, categoría, servicios, usuario, rol_usuario y roles son utilizadas por el módulo Negocio2SMS para el registro de los proveedores de servicios obteniendo desde el sistema Web la posición geográfica del servicio a proporcionar. Las tablas de servicios y colonia son comunes para los dos módulos que conforman la plataforma. Desde el módulo de Negocio2SMS se puede consultar la información y agregar nueva, pero desde el módulo GW-SMS sólo se puede consultar dicha información.

4.2. GW-SMS. El módulo GW-SMS es el encargado de atender peticiones que provienen de la red GSM y realizar el tratamiento de los mensajes de SMS. Procesa la información y decide qué tipo de consulta es la que se va a tratar, realizando las peticiones a servidores externos cuando se requiere la invocación de algún servicio Web.

La Tabla 7 muestra una breve descripción del funcionamiento de cada uno de los módulos del GW-SMS.

Tabla 7 Módulos de GW-SMS.

Módulo Descripción

API´s Bibliotecas que permiten desarrollar la funcionalidad de los módulos que comprenden la arquitectura del GW-SMS.

Control Módulo principal que se encarga de recibir y enviar peticiones de los dispositivos móviles e invocar una instancia de los módulos de configuración, servicios Web y BD.

Configuración Recibe los parámetros de configuración de la base de datos y del dispositivo GSM que se encuentra conectado a la PC.

BD –Base de Datos- Módulo que contiene los métodos para acceder a la base de datos.


- - 37

Dijkstra Módulo para la implementación de la ruta más corta a través del algoritmo de Dijkstra.

Servicio Web Módulo que contiene los distintos servicios que se invocan para realizar peticiones remotas de información solicitada.

Archivo configuración Archivo donde se especifican los parámetros de configuración del dispositivo GSM, base de datos etc.

La arquitectura en forma de bloques del módulo GW-SMS se muestra en la Figura 21.

Figura 21 Arquitectura a bloques de módulo GW-SMS.

En la figura anterior se muestra la arquitectura a bloques del módulo GW-SMS que es el

encargado de procesar las peticiones provenientes de los clientes a través de mensajes SMS. La forma en que opera el módulo se detalla a continuación:

i. Para la ejecución del módulo GW-SMS se cuenta con un archivo –SMSServer.conf- que contiene los parámetros de configuración que se deben establecer para ejecutar el módulo.

ii. Al ejecutar el GW-SMS, el módulo de control busca el archivo de configuracion para

establecer los parámetros de conexión, después de esto, se mantiene en un ciclo esperando peticiones por parte del modem GSM.

iii. Cuando se detectan mensajes entrantes, el módulo de control extrae la información de

ellos y delimita que tipo de información es la requerida.

iv. Si se trata de una consulta local, la información demandada se pasa al módulo de la base de datos para resolver la petición.


- - 38

v. La base de datos responde con la información hacia el módulo de control quien es el encargado de retornar la información hacia el dispositivo GSM para proporcionar la respuesta.

vi. En caso de ser una petición externa, el módulo de control se comunica directamente con el

módulo de servicios Web que hace la petición hacia servidores externos para resolver la información y ésta es devuelta hacia el módulo de control, quien entrega dicha información al dispositivo GSM.

En la Figura 22 se muestran los diferentes casos de uso para este módulo que representan las

diferentes acciones que se pueden realizar.

Usuario

Información local georeferenciada

Consultar información local o

externaInformación local no

georeferenciada

Información externa georeferenciada

Información externa no georeferenciada

Configuración sistema

Establecer parámetros en

archiv o de configuración

«include»

«extend»

«extend»

«extend»

«extend»

Figura 22 Casos de uso para módulo GW-SMS.

En la Figura 22 se muestran los casos de uso para las acciones que se realizan sobre el

módulo de GW-SMS. Los escenarios correspondientes a cada uno de los casos de uso se representan por medio de diagramas de secuencia en la Figura 25 y Figura 26 donde se observa la operación para cada caso de uso.

En la Figura 23 y Figura 24 se presentan los diagramas de clases del módulo GW-SMS

quien realiza el procesamiento de las peticiones provenientes de los dispositivos móviles.


- - 39

CDatabase

- C_CAMINO: int = 4 {readOnly}- C_EVENTO: int = 3 {readOnly}- C_GEOREFERENCIADA: int = 1 {readOnly}- C_NO_GEOREFERENCIADA: int = 2 {readOnly}- connection: Connection- dijsktra: Di jkstra- mainThread: CMainThread- parametros: CMensaje- settings: CSettings- vRes: Vector = new Vector(10)

+ ActualizaTemporales(CMensaje) : void+ CConsultas(CIncomingMessage) : Vector+ CDatabase(CSettings, CMainThread)+ checkForOutgoingMessages() : void+ close() : void# escapeDate(java.util .Date, boolean) : String+ getConnection() : Connection+ getRegistros(CMensaje) : CMensaje+ isOpen() : boolean+ obtenTemperatura(String) : String+ open() : void+ SalvaTemporales(CMensaje) : void+ saveMessage(CIncomingMessage) : void+ saveSentMessage(COutgoingMessage) : void+ VerificaTMP(CMensaje) : boolean

ThreadCMainThread

- connectRequest: boolean# database: CDatabase- exitFinished: boolean- exitRequest: boolean# mainWindow: CMainWindow# service: CService# settings: CSettings# SmsServer: SMSServer- vRes: Vector = new Vector(10,5)

- checkXmlOutQueue() : void+ CMainThread(SMSServer, CMainWindow, CSettings)+ connect(boolean) : boolean+ disconnect(boolean) : void+ exitFinished() : boolean+ exitRequest() : void+ initial ize() : void- parseXmlMessageFile(COutgoingMessage, String) : void+ processMessage(CIncomingMessage) : boolean- processStoredMessages() : void- RetornaRespuesta(CIncomingMessage, Vector) : void+ run() : void- saveToXmlInQueue(CIncomingMessage) : void- saveToXmlOutQueue(CIncomingMessage) : void# sendMessage(COutgoingMessage) : void- textDate(java.uti l.Date, boolean) : String

JFrameCMainWindow

+ CMainWindow(SMSServer, CSettings)+ getService() : CMainThread+ setBatteryIndicator(int) : void+ setConnected(boolean) : void+ setIMSIText(String) : void+ setInDate(String) : void+ setInFrom(String) : void+ setInterfaceDB(boolean) : void+ setInterfaceXML(boolean) : void+ setInText(String) : void+ setManufText(String) : void+ setModelText(String) : void+ setOutDate(String) : void+ setOutText(String) : void+ setOutTo(String) : void+ setRawInLog(boolean) : void+ setRawOutLog(boolean) : void+ setSerialNoText(String) : void+ setSignalIndicator(int) : void+ setStatusText(String) : void+ setSwVersionText(String) : void+ setTrafficIn(int) : void+ setTrafficOut(int) : void

JDialog

«static»CMainWindow::CAboutDialog

- serialVersionUID: long = -68327005761360... {readOnly}

+ CAboutDialog(JFrame)

CMensaje

- bRegTemp: boolean- fecha: Date- pClave: String- rEnviados: int- rTotales: int- telefono: String

+ CMensaje()+ getBan() : boolean+ getFecha() : String+ getPClave() : String+ getREnviados() : int+ getRTotales() : int+ getTelefono() : String+ setBan(boolean) : void+ setFecha(Date) : void+ setPClave(String) : void+ setREnviados(int) : void+ setRTotales(int) : void+ setTelefono(String) : void

CSettings

- CONFIG_FILE: String = "SMSServer.conf" {readOnly}- databaseSettings: CDatabaseSettings- generalSettings: CGeneralSettings- mainWindow: CMainWindow- phoneSettings: CPhoneSettings- serialDriverSettings: CSerialDriverSettings

+ CSettings()+ getDatabaseSettings() : CDatabaseSettings+ getGeneralSettings() : CGeneralSettings+ getPhoneSettings() : CPhoneSettings+ getSerialDriverSettings() : CSerialDriverSettings+ loadConfiguration() : void+ loadConfiguration(String) : void+ setMainWindow(CMainWindow) : void

«static»CSettings::

CSerialDriv erSettings

- baud: int- port: String

+ getBaud() : int+ getPort() : String+ setBaud(int) : void+ setPort(String) : void

«static»CSettings::CDatabaseSettings

+ DB_TYPE_MSSQL: int = 3 {readOnly}+ DB_TYPE_MYSQL: int = 2 {readOnly}+ DB_TYPE_POSTGRESQL: int = 4 {readOnly}+ DB_TYPE_SQL92: int = 1 {readOnly}- driver: String- enabled: boolean- password: String- type: int- url: String- username: String

+ CDatabaseSettings()+ getDriver() : String+ getEnabled() : boolean+ getPassword() : String+ getType() : int+ getUrl() : String+ getUsername() : String+ setDriver(String) : void+ setEnabled(boolean) : void+ setPassword(String) : void+ setType(int) : void+ setUrl(String) : void+ setUsername(String) : void

«static»CSettings::CPhoneSettings

- batchIncoming: int- batchOutgoing: int- deleteAfterProcessing: boolean- forwardNumber: String- manufacturer: String- messageEncoding: String- model: String- periodInterval: int- protocol: int- simPin: String- smscNumber: String- xmlInQueue: String- xmlOutQueue: String

+ CPhoneSettings()+ getBatchIncoming() : int+ getBatchOutgoing() : int+ getDeleteAfterProcessing() : boolean+ getForwardNumber() : String+ getManufacturer() : String+ getMessageEncoding() : String+ getModel() : String+ getPeriodInterval() : int+ getProtocol() : int+ getSimPin() : String+ getSmscNumber() : String+ getXmlInQueue() : String+ getXmlOutQueue() : String+ setBatchIncoming(int) : void+ setBatchOutgoing(int) : void+ setDeleteAfterProcessing(boolean) : void+ setForwardNumber(String) : void+ setManufacturer(String) : void+ setMessageEncoding(String) : void+ setModel(String) : void+ setPeriodInterval(int) : void+ setProtocol(String) : void+ setSimPin(String) : void+ setSmscNumber(String) : void+ setXmlInQueue(String) : void+ setXmlOutQueue(String) : void

«static»CSettings::CGeneralSettings

- guiEnabled: boolean = true- rawInLog: RandomAccessFile = nul l- rawOutLog: RandomAccessFile = null

+ CGeneralSettings()- date2LogString(java.util .Date) : String+ getGui() : boolean+ isRawInLogEnabled() : boolean+ isRawOutLogEnabled() : boolean+ rawInLog(CIncomingMessage) : void+ rawOutLog(COutgoingMessage) : void+ setGui(boolean) : void+ setRawInLog(String) : void+ setRawOutLog(String) : void

CUserThread

+ CUserThread(SMSServer, CMainWindow, CSettings)+ processMessage(CIncomingMessage) : boolean

ThreadSMSServ er

- mainWindow: CMainWindow# service: CMainThread- settings: CSettings

+ initial ize() : void+ main(String[]) : void+ run() : void+ stripHtml(String) : String

Thread

«static»SMSServ er::CShutdown

+ run() : void

itinerarios::Dijkstra

~ con: Connection~ error: String

+ conecta() : void+ conexion() : int+ crea_matriz(int) : int[]+ crea_matriz_tramos(int) : int[]+ dijsktra(int[][], int[][], int, int, int) : String+ nodo(String) : int+ separacion(String) : String+ vertramos(String) : ResultSet

-databaseSettings

-parametros

-settings

#database

#mainWindow

#settings

#SmsServer

-aboutDialog

-service

-mainThread

-SmsServer

-dijsktra

-generalSettings

-mainWindow

-phoneSettings

-serialDriverSettings

-mainWindow

#service

-settings

-settings

Figura 23 Diagrama de clases de GW-SMS.


- - 40

javax.xml.rpc.Service«interface»

GlobalWeather

+ getGlobalWeatherSoap() : edu.mx.cenidet.gateway.webservices.clima.NET.webserviceX.www.GlobalWeatherSoap+ getGlobalWeatherSoap(java.net.URL) : edu.mx.cenidet.gateway.webservices.clima.NET.webserviceX.www.GlobalWeatherSoap+ getGlobalWeatherSoapAddress() : java.lang.String

org.apache.axis.client.ServiceGlobalWeatherLocator

- GlobalWeatherSoap_address: java.lang.String = "http://www.web...- GlobalWeatherSoapWSDDServiceName: java.lang.String = "GlobalWeatherSoap"- ports: java.uti l .HashSet = null

+ getGlobalWeatherSoap() : edu.mx.cenidet.gateway.webservices.clima.NET.webserviceX.www.GlobalWeatherSoap+ getGlobalWeatherSoap(java.net.URL) : edu.mx.cenidet.gateway.webservices.clima.NET.webserviceX.www.GlobalWeatherSoap+ getGlobalWeatherSoapAddress() : java.lang.String+ getPort(Class) : java.rmi.Remote+ getPort(javax.xml.namespace.QName, Class) : java.rmi.Remote+ getPorts() : java.uti l .Iterator+ getServiceName() : javax.xml.namespace.QName+ GlobalWeatherLocator()+ GlobalWeatherLocator(org.apache.axis.EngineConfiguration)+ GlobalWeatherLocator(java.lang.String, javax.xml.namespace.QName)+ setEndpointAddress(java.lang.String, java.lang.String) : void+ setEndpointAddress(javax.xml.namespace.QName, java.lang.String) : void+ setGlobalWeatherSoapEndpointAddress(java.lang.String) : void

«property get»+ getGlobalWeatherSoapWSDDServiceName() : java.lang.String

«property set»+ setGlobalWeatherSoapWSDDServiceName(java.lang.String) : void

java.rmi.Remote«interface»

GlobalWeatherSoap

+ getCitiesByCountry(java.lang.String) : java.lang.String+ getWeather(java.lang.String, java.lang.String) : java.lang.String

org.apache.axis.client.StubGlobalWeatherSoapStub

~ _operations: org.apache.axis.description.OperationDesc ([])- cachedDeserFactories: java.uti l .Vector = new java.uti l.V...- cachedSerClasses: java.uti l .Vector = new java.uti l.V...- cachedSerFactories: java.util .Vector = new java.util .V...- cachedSerQNames: java.util .Vector = new java.uti l .V...

- _initOperationDesc1() : void# createCall() : org.apache.axis.client.Call+ getCitiesByCountry(java.lang.String) : java.lang.String+ getWeather(java.lang.String, java.lang.String) : java.lang.String+ GlobalWeatherSoapStub()+ GlobalWeatherSoapStub(java.net.URL, javax.xml.rpc.Service)+ GlobalWeatherSoapStub(javax.xml.rpc.Service)

Figura 24 Diagrama de clases de cliente servicio Web.


- - 41

En las figuras anteriores se presentaron las clases del módulo GW-SMS, en la arquitectura propuesta se muestra este módulo como la integración de 5 componentes: Control, Configuración, BD, Dijsktra y el de Cervicios Web. En la Tabla 8 se muestran las clases que pertenecen a cada uno de estos módulos y una pequeña descripción de ellas.

Tabla 8 Clases pertenecientes a módulos de GW-SMS. Módulo Clases Descripción

Control SMSServer, CMAinWindow, CMainThread

La clase principal es la de SMSServer la cual invoca a las otras dos clases para comenzar la ejecución del módulo de GW-SMS.

Configuración CSettings, CSerialDriverSettings,

CDatabaseSettings, CGeneralSettings, CPhoneSettings

El módulo de configuración está integrado por una clase principal y cuatro estáticas que permiten la configuración de los siguientes elementos: la base de datos, el teléfono, configuraciones generales y la comunicación del teléfono a nivel de hardware.

BD –base de

datos- CDatabase,CMensaje

Está conformado por dos clases: La clase que contiene todo el acceso a la base de datos –CDatabase- y una clase auxiliar –CMensaje- para el tratamiento de los mensajes.

Dijsktra Dijsktra

Este módulo para la ruta más corta con acceso a la base de datos para extraer de ella información para la ejecución del algoritmo.

Servicios Web

GlobalWeather, GlobalWeatherLocator, GlobalWeatherSoap,

GlobalWetherSoapStub

El módulo de servicios Web esta conformado por cuatro clases que permiten la invocación de la información remota en base a parámetros establecidos en el momento de la invocación.

En conjunto estas clases permiten el procesamiento de la información proveniente de los clientes móviles. Los escenarios que se presentan en los casos de uso se representan como diagrama de secuencias en las siguientes figuras. En ellos se presenta la secuencia que se sigue para el retorno de la información a través de los módulos que intervienen en el procesamiento de los mensajes.


- - 42

La Figura 25 muestra el diagrama de secuencia para el escenario donde se realiza la

ejecución y puesta en marcha del módulo del GW-SMS.

Figura 25 Diagrama de secuencia para inicio de módulo GW-SMS.

La Figura 26 muestra el diagrama de secuencia para el escenario donde se realiza una petición espacial que se puede procesar por el GIS de manera local.

Figura 26 Diagrama de secuencia para consulta local georeferenciada.


- - 43

Las consultas no georeferenciadas mantienen parámetros diferentes para la búsqueda,

mientras en las consultas georeferenciadas –espaciales- se utiliza la topología de las geometrías para realizar las búsquedas. La Figura 27 muestra el diagrama de secuencia para este tipo de consulta.

Figura 27 Diagrama de secuencia de consulta local no georeferenciada.

Las figuras anteriores muestran los diagramas de secuencia donde la información que se

demanda se resuelve de manera local a través de los datos almacenados en la base de datos espacial. Estos diagramas abarcan la demanda de la información local georeferenciada y no georeferenciada.


- - 44

A continuación se presentan los diagramas de secuencia para los casos cuando la información no se puede resolver directamente desde la base de datos espacial y se obtiene la información desde servidores externos para su despliegue a través de mensajes de SMS.

Las peticiones, al igual que los dos casos anteriores pueden representar consultas georeferenciadas y no georeferenciadas. En el caso de las consultas no georeferenciadas se contempla un formato especial para dichas peticiones.

En la Figura 28 se muestra el diagrama de secuencia para una consulta externa georeferenciada.

Figura 28 Diagrama de secuencia consulta externa georeferenciada.

Consultas del tipo externas no georeferenciadas se realizan a través de palabras clave enviadas directamente en el mensaje, en este caso, se asume que el usuario conoce como mínimo la colonia o calle y código postal donde se encuentra para realizar la búsqueda de los servicios a proporcionar.


- - 45

La Figura 29 muestra el diagrama de secuencia para el caso de las consultas externas no

georeferenciadas.

Figura 29 Diagrama de secuencia consulta externa no georeferenciada.


- - 46

Las interfaces gráficas del módulo GW-SMS se muestra en la Figura 30.

Figura 30 Implementación gráfica del módulo GW-SMS. En la aplicación gráfica en la Figura 30 la parte de (a) se utiliza para visualizar la

información del dispositivo que se encuentra conectado a la PC, en (b) se observa una pantalla donde se muestra la fecha de actividad, los mensajes recibidos, enviados y las interfaces que se encuentran activadas, en (c) y (d) se muestran las pantallas que permiten observar el texto de los mensajes recibidos y enviados respectivamente. El pseudo código del algoritmo se muestra en la Figura 31.

Figura 31 Algoritmo de Dijkstra.

Algoritmo de Dijsktra °-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-° 1.- Procedimiento dijkstra (w,a,z,L ) 2.- L(a)=0 3.-para todos los vértices x ≠ a hacer 4.-L(x) = ∞ 5.- //T es el conjunto de vértices cuya distancia mas corta 6.- //a “a” no ha sido determinada 7.- mientras z Є T hacer 8.- begin 9.- elegir v Є T con L(v) mínimo 10.- T : = T – {v} 11.- para cada x Є T adyacente a v hacer 12.- L(x) : = mínimo {L(x) , L(v) + w ( v , x)} 13.- end 14.- end dijsktra °-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°-°

(a) (b)

(c) (d)


- - 47

Para aplicar el algoritmo de Dijkstra se requiere una matriz de adyacencia donde se almacenan los nodos totales y las aristas adyacentes a cada uno de estos nodos. Para generar esta información se realizó un procedimiento que se aplica sobre tablas espaciales y permite obtener los nodos y sus aristas adyacentes. El procedimiento que se realizó se describe a continuación:

i. El primer paso es obtener los puntos donde se intersectan cada uno de los tramos. ii. Los puntos que se obtienen se almacenan en una nueva tabla que es llamada nodos. iii. En la tabla nodos, en base a funciones espaciales del DBMS, se obtiene una nueva tabla

llamada adyacencia que contiene el identificador del nodo, el identificador de los nodos adyacentes, el identificador del tramo y la longitud del tramo correspondiente.

iv. Se desarrolló una clase en Java con métodos requeridos para la implementación del

algoritmo. La primera conexión a la BD (base de datos), la realiza el método conexión () que retorna el número máximo de nodos.

v. El resultado de este método lo recibe el método crea_matriz (int a), que se encarga de

crear una matriz con los valores extraídos de la base de datos.

vi. Por último, el método Dijsktra recibe los parámetros para la ejecución del algoritmo. Al finalizar retorna un arreglo de cadenas que contiene los identificadores geométricos de cada uno de los tramos que representan la ruta mínima. Los valores de este arreglo sirven para generar una consulta a la base de datos que retorna los tramos o aristas con la ruta más corta del nodo inicial al que se definió como nodo final.

El módulo de Dijkstra se validó mediante la ejecución sobre una capa vectorial de carreteras,

donde se utiliza para consultar la ruta más corta entre dos ciudades. Después de ejecutar el algoritmo se genera una nueva capa donde se visualiza la ruta más corta entre las dos ciudades, la Figura 32 muestra la capa generada resaltada en negrilla sobre la capa de carreteras.

Figura 32 Ruta mínima entre dos puntos dados.


- - 48

4.3. Negocio2SMS. El sistema Web Negocio2SMS surge por la necesidad de alimentar la base de datos con nuevos proveedores de servicios que puedan ofrecer sus productos a través de la plataforma que se propuso. El sistema se diseñó bajo una arquitectura empresarial –J2EE- donde la escalabilidad, portabilidad e interoperabilidad son aspectos fundamentales para dichas aplicaciones. Los módulos que componen dicha aplicación se mencionan en la Tabla 9.

Tabla 9 Módulos de Negocio2SMS. Módulo Descripción

Contenedor de Servlets –Tomcat- En éste reside la aplicación Web, comúnmente llamado servidor de aplicaciones aunque puede funcionar como tal, no es su objetivo principal.

API´s Bibliotecas que nos permiten desarrollar la funcionalidad de los módulos que comprenden la arquitectura del prototipo del sistema.

Vista Módulo que contiene las páginas JSP que se encargan de mostrar los datos en un explorador Web.

Modelo de negocio Permite interactuar con el modelo de datos a través de acciones definidas en el módulo de acciones.

Acciones Se encuentran todas las acciones que se pueden desarrollar para acceder a los datos a través del modelo de negocio y modelo de datos.

Modelo de datos Módulo de acceso a los datos.

Para la construcción de la aplicación se utilizó el framework de Struts que está basado en el patrón de implementación MVC –modelo, vista, controlador- [STR06]. Un diagrama a bloques de la organización de la aplicación se muestra en la Figura 33.

Figura 33 Diagrama a bloques de sistema Negocio2SMS.


- - 49

En la Figura 33 se observa el diagrama a bloques del sistema realizado, toda la funcionalidad se encuentra dividida según el patrón de struts. La operación de cada uno de los módulos observados se describe a continuación:

i. Servlet de acción: Esta parte realiza la función del controlador de la aplicación y es quien ejecuta las operaciones correspondientes a las peticiones que se realizan, se comunica directamente con la parte de la vista –páginas JSP- y con las clases Action.

ii. Clases Action: Son las encargadas de dar toda la funcionalidad al sistema, aquí se definen las operaciones que se pueden realizar sobre el sistema, se comunica directamente con los objetos de negocio y con el modelo de objetos de acceso a los datos.

iii. Bibliotecas de etiquetas: Encapsulan en etiquetas funcionalidades específicas para la

generación de la parte visual de la aplicación.

iv. Páginas JSP: Son la parte de la vista del modelo, representan los datos que se pueden visualizar y proporciona interfaces para el manejo de la información del modelo de datos. Hace uso de la biblioteca de etiquetas para la representación de los datos.

v. Objetos de negocio: Contiene las normas de negocio asociadas al mantenimiento de las entidades del sistema.

vi. Modelo de entidad y objetos de acceso a datos: Se utilizan para transformar los registros de la base de datos en instancias de clases de entidades y viceversa de forma que se agrupan las llamadas a la base de datos y se aíslan otras partes de la aplicación de las instrucciones SQL.

El sistema cuenta con las funcionalidades básicas de registrar, actualizar, consultar y borrar. Se hace énfasis en el registro de los proveedores ya que es aquí, donde se alimenta a la base de datos con los servicios que se pueden representar a través de los mensajes de SMS. La Figura 34 muestra los casos de uso para el sistema.

Figura 34 Casos de uso para Negocio2SMS.


- - 50

Los diagramas de clases para los paquetes de la aplicación se muestran en las figuras subsecuentes. La aplicación se encuentra dividida en cuatro paquetes: El paquete de entidades, base de datos, paquete de negocio y el paquete de acciones. La Figura 35 muestra el diagrama de clases del paquete de entidades.

ActionFormCategoria

- idCategoria: int- tipo: String

+ Categoria()+ getTipo() : String+ setTipo(String) : void

«property get»+ getidCategoria() : int

«property set»+ setidCategoria(int) : void

Estado

- id: int- nombre: String

+ Estado()+ getId() : int+ getNombre() : String+ setId(int) : void+ setNombre(String) : void

Municipio

- idEstado: int- idMunicipio: int- nombre: String

+ getNombre() : String+ Municipio()+ setNombre(String) : void

«property get»+ getidEstado() : int+ getidMunicipio() : int

«property set»+ setidEstado(int) : void+ setidMunicipio(int) : void

Roles

- nomRol: String

+ getRol() : String+ Roles()+ setRol(String) : void

RolUsuario

- idUsuario: String- nomRol: String

+ getNomRol() : String+ RolUsuario()+ setNomRol(String) : void

«property get»+ getidUsuario() : String

«property set»+ setidUsuario(String) : void

ActionFormServ icios

- calle: String- colonia: String- cp: int- idCategoria: int- idEstado: int- idMunicipio: int- idServicio: int- idUsuario: String- latitud: String- longitud: String- nomServicio: String- numero: int- pagWeb: String

+ getCalle() : String+ getColonia() : String+ getCP() : int+ getLatitud() : String+ getLongitud() : String+ getNomServicio() : String+ getNumero() : int+ getPagWeb() : String+ Servicios()+ setCalle(String) : void+ setColonia(String) : void+ setCP(int) : void+ setLatitud(String) : void+ setLongitud(String) : void+ setNomServicio(String) : void+ setNumero(int) : void+ setPagWeb(String) : void

«property get»+ getidCategoria() : int+ getidEstado() : int+ getidMunicipio() : int+ getidServicio() : int+ getidUsuario() : String

«property set»+ setidCategoria(int) : void+ setidEstado(int) : void+ setidMunicipio(int) : void+ setidServicio(int) : void+ setidUsuario(String) : void

ActionFormUsuario

- amUsuario: String- apUsuario: String- idUsuario: String- mail: String- nomUsuario: String- password: String

+ getAMUsuario() : String+ getAPUsuario() : String+ getMail() : String+ getNomUsuario() : String+ getPassword() : String+ setAMUsuario(String) : void+ setAPUsuario(String) : void+ setMail(String) : void+ setNomUsuario(String) : void+ setPassword(String) : void



Figura 35 Clases de paquete entidades.

El paquete entidades maneja los registros de la base de datos como objetos que se

pueden instanciar mediante las clases que se encuentran en la Figura 35, las clases definidas en el paquete entidades corresponden a las tablas respectivas en el diagrama de base de datos.

El paquete encargado de todo el acceso a la base de datos es el paquete base de datos; el cual contiene las clases necesarias para realizar las operaciones de inserción, modificación,


- - 51

borrado y las operaciones que se realizan sobre la base de datos. La Figura 36 muestra las clases que conforman dicho paquete.

CategoriaOAD

- con: Connection

+ borrar(String) : void+ buscaporCategoria(String) : Categoria+ CategoriaOAD(Connection)+ crear(Categoria) : void+ listaTodos() : Collection

ExceptionCreaExcepcion

+ CreaExcepcion(String)

EstadoOAD

- con: Connection

+ borrar(int) : void+ buscaporEstado(int) : Estado+ crear(Estado) : void+ EstadoOAD(Connection)+ l istaTodos() : Collection

ExceptionFinderException

+ FinderException(String)

MunicipioOAD

- con: Connection

+ borrar(int, int) : void+ buscaporMunicipio(int, int) : Municipio+ crear(Municipio) : void+ l istaTodos(int) : Collection+ MunicipioOAD(Connection)

RuntimeExceptionNoExisteEntidadExcepcion

+ NoExisteEntidadExcepcion(String)

ObjetoNoEncontradoExcepcion

+ ObjetoNoEncontradoExcepcion(String)

RegistroDuplicadoExcepcion

+ RegistroDuplicadoExcepcion(String)

RolesOAD

- con: Connection

+ borrar(String) : void+ buscaporRol(String) : Roles+ crear(Roles) : void+ RolesOAD(Connection)

RolUsuarioOAD

- con: Connection

+ borrar(String, String) : void+ buscaporPrimaryKey(String, String) : RolUsuario+ crear(RolUsuario) : void+ RolUsuarioOAD(Connection)

Serv iciosOAD

- con: Connection

+ actualiza(Servicios) : void+ borra(String) : void+ buscaporServicio(String) : Servicios+ crear(Servicios) : void+ listaTodos() : Collection+ ServiciosOAD(Connection)

UsuarioOAD

- con: Connection

+ actualiza(Usuario) : void+ borra(String) : void+ buscaporUsuario(String) : Usuario+ crear(Usuario) : void+ UsuarioOAD(Connection)

Figura 36 Clases de paquete base de datos.

En la Figura 37 se muestran las clases del paquete negocio encargado de comunicarse

con las acciones y con el paquete de base de datos de la aplicación.

«interface»Rol

+ SERVICIO: String = "serviciosms" {readOnly}

ExceptionServ iciosExcepcion

+ ServiciosExcepcion(String)

Serv iciosON

- pool: PoolConexion

+ actualizaServicio(Servicios) : void+ creaServicio(Servicios) : void+ ServiciosON()- validaServicios(Servicios) : void

ExceptionUsuarioExcepcion

+ UsuarioExcepcion(String)

UsuarioON


+ actualizaUsuario(Usuario) : void+ borraUsuario(String) : void+ registraUsuario(Usuario) : void+ UsuarioON()- validaUsuario(Usuario) : void

Figura 37 Clases de paquete negocio.

Las clases del paquete negocio sirven para comunicarse con las acciones que se ejecutan

en el sistema y con las clases de base de datos para realizar las peticiones a la base de datos. Las


- - 52

clases de negocio sirven como intermediario para separar las acciones que se realizan dentro del sistema de las operaciones de acceso a datos realizadas por dichas acciones. En las clases del paquete acciones se define una clase por cada petición o acción que involucra el acceso a la base de datos. Por último las clases del paquete acciones se comunican directamente con la interfaz Web y realizan las peticiones al servidor Web. En la Figura 38 se muestran las clases del paquete acciones.

ActionAccionActualizaServ icios

+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionActualizaUsuario


ActionAccionCategoria


+ AccionCategoria()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEditarServ icios


+ AccionEditarServicios()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEditarUsuario


+ AccionEditarUsuario()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEliminaUsuario


ActionAccionInicio


+ AccionInicio()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionLogOut


ActionAccionRegistraServ icios


ActionAccionRegistraUsuario


ActionAccionVerServ icios


+ AccionVerServicios()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

«interface»NombreBeans

+ FORMA_CATEGORIA: String = "formaCategoria" {readOnly}+ FORMA_SERVICIOS: String = "formaServicios" {readOnly}+ FORMA_USUARIOS: String = "formaUsuario" {readOnly}+ LISTA_CATEGORIA: String = "l istaCategoria" {readOnly}+ LISTA_SERVICIOS: String = "listaServicios" {readOnly}+ LISTA_USUARIOS: String = "l istaUsuarios" {readOnly}

Figura 38 Clases de paquete acciones.

Las clases del paquete acciones representan la funcionalidad del sistema para el usuario,

estas clases se ejecutan por las peticiones que se realizan desde el navegador y son las que desencadenan las acciones que pueden realizarse. Con estos 4 paquetes de clases se cuenta con una arquitectura de la aplicación conocida como una arquitectura de 3 capas, donde se cuenta con la parte de la presentación visualizada en este caso por medio de páginas JSP, la parte de la lógica del negocio que incluye todo el flujo de trabajo, los cálculos, validaciones y finalmente el modelo de datos que contiene las tablas, bases de datos y componentes de datos.

La aplicación está basada en el marco de trabajo de Struts desarrollado por la Apache Software Foundation, este marco de trabajo permite dividir la aplicación bajo el patrón MVC donde el componente controlador ya se encuentra desarrollado en un servlet. Este servlet mapea las peticiones que se ejecutan en el explorador a través de un archivo de configuración en formato XML. El contar con la parte del controlador desarrollado facilita el desarrollo, puesto que el esfuerzo se centra en la parte del modelo y las vistas necesarias.

En la Figura 39 se muestra el diagrama de clases de los 4 paquetes en conjunto.


- - 53

ActionAccionActualizaServ icios


ActionAccionActualizaUsuario


ActionAccionCategoria


+ AccionCategoria()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEditarServ icios


+ AccionEditarServicios()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEditarUsuario


+ AccionEditarUsuario()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionEliminaUsuario


ActionAccionInicio


+ AccionInicio()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

ActionAccionLogOut


ActionAccionRegistraServ icios


ActionAccionRegistraUsuario


ActionAccionVerServ icios


+ AccionVerServicios()+ perform(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) : ActionForward

CategoriaOAD

- con: Connection

+ borrar(String) : void+ buscaporCategoria(String) : Categoria+ CategoriaOAD(Connection)+ crear(Categoria) : void+ l istaTodos() : Collection

ExceptionCreaExcepcion

+ CreaExcepcion(String)

EstadoOAD

- con: Connection

+ borrar(int) : void+ buscaporEstado(int) : Estado+ crear(Estado) : void+ EstadoOAD(Connection)+ listaTodos() : Collection

ExceptionFinderException

+ FinderException(String)

MunicipioOAD

- con: Connection

+ borrar(int, int) : void+ buscaporMunicipio(int, int) : Municipio+ crear(Municipio) : void+ l istaTodos(int) : Collection+ MunicipioOAD(Connection)

RuntimeExceptionNoExisteEntidadExcepcion

+ NoExisteEntidadExcepcion(String)

ObjetoNoEncontradoExcepcion

+ ObjetoNoEncontradoExcepcion(String)

RegistroDuplicadoExcepcion

+ RegistroDuplicadoExcepcion(String)

RolUsuarioOAD

- con: Connection

+ borrar(String, String) : void+ buscaporPrimaryKey(String, String) : RolUsuario+ crear(RolUsuario) : void+ RolUsuarioOAD(Connection)

RolesOAD

- con: Connection

+ borrar(String) : void+ buscaporRol(String) : Roles+ crear(Roles) : void+ RolesOAD(Connection)

Serv iciosOAD

- con: Connection

+ actualiza(Servicios) : void+ borra(String) : void+ buscaporServicio(String) : Servicios+ crear(Servicios) : void+ l istaTodos() : Collection+ ServiciosOAD(Connection)

UsuarioOAD

- con: Connection

+ actualiza(Usuario) : void+ borra(String) : void+ buscaporUsuario(String) : Usuario+ crear(Usuario) : void+ UsuarioOAD(Connection)PoolConexion

- ds: DataSource- mySelf: PoolConexion

+ getConnection() : Connection+ getInstance() : PoolConexion+ init(DataSource) : void+ PoolConexion(DataSource)

HttpServletServ letIniciaBD

+ init(ServletConfig) : void

ActionFormCategoria

- idCategoria: int- tipo: String

+ Categoria()+ getTipo() : String+ setTipo(String) : void

«property get»+ getidCategoria() : int

«property set»+ setidCategoria(int) : void

Estado

- id: int- nombre: String

+ Estado()+ getId() : int+ getNombre() : String+ setId(int) : void+ setNombre(String) : void

Municipio

- idEstado: int- idMunicipio: int- nombre: String

+ getNombre() : String+ Municipio()+ setNombre(String) : void

«property get»+ getidEstado() : int+ getidMunicipio() : int

«property set»+ setidEstado(int) : void+ setidMunicipio(int) : void

RolUsuario

- idUsuario: String- nomRol: String

+ getNomRol() : String+ RolUsuario()+ setNomRol(String) : void



Roles

- nomRol: String

+ getRol() : String+ Roles()+ setRol(String) : void

ActionFormServ icios

- calle: String- colonia: String- cp: int- idCategoria: int- idEstado: int- idMunicipio: int- idServicio: int- idUsuario: String- latitud: String- longitud: String- nomServicio: String- numero: int- pagWeb: String

+ getCalle() : String+ getColonia() : String+ getCP() : int+ getLatitud() : String+ getLongitud() : String+ getNomServicio() : String+ getNumero() : int+ getPagWeb() : String+ Servicios()+ setCalle(String) : void+ setColonia(String) : void+ setCP(int) : void+ setLatitud(String) : void+ setLongitud(String) : void+ setNomServicio(String) : void+ setNumero(int) : void+ setPagWeb(String) : void

«property get»+ getidCategoria() : int+ getidEstado() : int+ getidMunicipio() : int+ getidServicio() : int+ getidUsuario() : String

«property set»+ setidCategoria(int) : void+ setidEstado(int) : void+ setidMunicipio(int) : void+ setidServicio(int) : void+ setidUsuario(String) : void

ActionFormUsuario

- amUsuario: String- apUsuario: String- idUsuario: String- mail: String- nomUsuario: String- password: String

+ getAMUsuario() : String+ getAPUsuario() : String+ getMail() : String+ getNomUsuario() : String+ getPassword() : String+ setAMUsuario(String) : void+ setAPUsuario(String) : void+ setMail(String) : void+ setNomUsuario(String) : void+ setPassword(String) : void



ExceptionServ iciosExcepcion

+ ServiciosExcepcion(String)

Serv iciosON


+ actualizaServicio(Servicios) : void+ creaServicio(Servicios) : void+ ServiciosON()- validaServicios(Servicios) : void

ExceptionUsuarioExcepcion

+ UsuarioExcepcion(String)

UsuarioON


+ actualizaUsuario(Usuario) : void+ borraUsuario(String) : void+ registraUsuario(Usuario) : void+ UsuarioON()- validaUsuario(Usuario) : void

«interface»Rol

+ SERVICIO: String = "serviciosms" {readOnly}

-mySelf

-pool

-pool

-pool

-pool

-pool

-pool -pool

Figura 39 Diagrama de clases de módulo Negocio2SMS.


- - 54

En el módulo de Negocio2SMS se cuenta con las clases necesarias para satisfacer los requerimientos del sistema Web. La parte importante y trascendental del sistema es el registro de nuevos proveedores para proporcionar su servicio a través de mensajes de SMS. Para este caso de uso en la Figura 40 se presenta el diagrama de secuencia que se sigue en el registro de los nuevos proveedores de servicios.

Usuario

AccionPrincipalindex.jspNavegador Web ServiciosOAD requestHttpServletRequest

principal.jsp contenidoPrincipal.jsp

Introduce URL

peticion HTTP GET

ejecuta accionprincipal.do

<constructor>(Connection)

listaTodos():Collection

pone atributos en larequest

redirecciona

includes

Figura 40 Diagrama de secuencia de inicio de aplicación.

Para llevar a cabo el registro de un nuevo proveedor de servicio se debe de invocar la

aplicación por medio del navegador, los pasos para cargar la página principal de la aplicación se muestraron en el diagrama de secuencia de la Figura 40. Los pasos necesarios para el registro de un nuevo proveedor se muestran en la Figura 41.

registrarUsuario.jsp confirmarRegistro.jspAccionRegistrarServicio

registrarServicio.jsp

contenidoRegistraUsuario.jsp

Usuario

AccionRegistraUsuario

UsuarioON contenidoRegistrarServicio.jsp

ServicioON

Peticion HTTPGET

includes

Proporciona datosPoolConexion:getInstance()

includesEjecuta accionregistrarUsuario.do

UsuarioON:crear( form)

PoolConexion:getInstance()redirecciona

Proporciona datosEjecuta accionregistrarServicio.do

ServicioON:crear(form)

redirecciona

Figura 41 Diagrama de secuencia de registro de proveedor.

Los datos que se almacenan en la base de datos espacial a través de este módulo se

acceden desde la mensajería de SMS por medio del módulo de GW-SMS. Estos datos se almacenan en la base de datos espacial como una geometría con sus datos alfanuméricos


- - 55

correspondientes. De esta manera se aplican algunas operaciones definidas en [SFS99] para tratar la información como objetos geométricos. La interfaz Web del sistema de registro de nuevos proveedores se presenta en la Figura 42.

Figura 42 Registro de proveedor de servicios.

En la aplicación desarrollada se observa un mapa, este mapa es proporcionado por el API

de GoogleMaps [AGM06], por medio de funciones de esta API se permite visualizar imágenes aéreas de la ubicación del proveedor de servicio que se registra. En la imagen se observa una marca que hace referencia a la posición donde se encuentra el negocio, a través de funciones del API de GoogleMaps se puede obtener las coordenadas en formato de Latitud-Longitud y almacenarlas en la base de datos espacial.

Para contar con este servicio es necesario contar con una cuenta de Google para generar una clave que permite el acceso a los servicios del API. Para cada dominio específico de debe crear una llave para utilizar las funcionalidades de API de GoogleMaps dentro de la página Web donde se necesita habilitar la visualización de imágenes satelitales.

La llave que se genera es una secuencia de caracteres que identifican el dominio o IP donde se habilita el servicio. La Figura 43 muestra la clave generada para la aplicación.

Figura 43 Clave generada para el sistema Negocio2SMS.


- - 56

Habilitando esta clave por medio de código JavaScript se accesa a los servicios de GoogleMaps desde cualquier página dentro del sistema Negocio2SMS.

De esta forma la información es almacenada en la base de datos donde podemos observar que existe un campo con varios números y letras. Este campo representa la información espacial que se puede utilizar.

Figura 44 Visualización de registro almacenado en la base de datos.

Capitulo 5 Pruebas y resultados

- - 57

Capítulo 5 Pruebas y Resultados

Capítulo 5 Pruebas y Resultados En este capítulo se presentan las pruebas realizadas en base al estándar IEEE 829-1998. Se presenta el plan de pruebas desarrollado, la nomenclatura a utilizar en la fase de pruebas y todos los casos posibles para las pruebas del módulo GW-SMS y el módulo Negocio2SMS.


- - 58

5.1. Plan de Pruebas. Los distintos casos de prueba contemplados para la validación de la funcionalidad de la plataforma, se encuentran divididos por grupos basados en la funcionalidad o características de cada uno de los casos de prueba, el documento de la especificación de pruebas, así como el plan y casos de prueba definidos se encuentran desarrollados bajo el estándar IEEE 829-1998 definido en [STD98]. En los siguientes apartados se muestran todos los casos de prueba definidos para la validación de los objetivos propuestos para esta tesis.

5.2. Características a Probar. Los distintos casos de prueba definen las características a ser probadas que se muestran en la Tabla 10.

Tabla 10 Características a probar de la plataforma. Característica Descripción

Configuración y conexiones

Define los casos de prueba para verificar la correcta configuración de los parámetros a utilizar por el SBLAGWSMS para la conexión con el MODEM GSM y la Base de datos.

Interpretación de la información

Define los casos de prueba para la interpretación de la información proveniente de los dispositivos móviles.

Envío y recepción de la información Define la información recibida y enviada

Persistencia de consultas mayores a 2 resultados

Define la persistencia de los datos para proporcionar la información de cierta categoría dependiendo de la información de estado almacenada en el servidor

Registro de y visualización de información georeferenciada.

Define los casos de prueba utilizados para verificar que la información georeferenciada se almacene en la base de datos.

Petición de información externa al servidor Validar que se puede obtener y enviar hacia el dispositivo móvil información que no se encuentra almacenada en el servidor.

Almacenamiento de información

Se registran en la base de datos todas las peticiones y respuestas que ocurren en el servidor con el objetivo de almacenar un historial sobre los SMS recibidos y enviados.

5.2.1. Pruebas de conexión y configuración. SBLAGWSMS-001 Pruebas de conexión y configuración

SBLAGWSMS-001-001 Configuración y conexión con el dispositivo móvil. SBLAGWSMS-001-002 Configuración y conexión con la base de datos. SBLAGWSMS-001-003 Operación en modo texto. SBLAGWSMS-001-004 Operación en modo gráfico.


- - 59

5.2.2. Pruebas de invocación de información dinámica externa. SBLAGWSMS-002 Pruebas de invocación de información dinámica externa

SBLAGWSMS-002-001 Invocación de servicio Web para la obtención dinámica de la información a mostrar (simulada). SBLAGWSMS-002-002 Invocación de servicio Web para la obtención dinámica de la información a mostrar (real).

5.2.3. Almacenamiento y actualización de la información. SBLAGWSMS-003 Pruebas de almacenamiento de la información SBLAGWSMS-003-001 Almacenamiento de mensajes recibidos. SBLAGWSMS-003-002 Almacenamiento de mensajes enviados.

SBLAGWSMS-003-003 Almacenamiento de datos temporales para persistencia de información demandada. SBLAGWSMS-003-004 Actualización de la información de persistencia sobre datos enviados contra totales.

5.2.4. Envío y recepción de información. SBLAGWSMS-004 Envío y recepción de información SBLAGWSMS-004-001 Recepción de mensajes.

SBLAGWSMS-004-002 Procesamiento de consulta georeferenciada por tipo o categoría. SBLSAGWSMS-004-003 Procesamiento de consulta georeferenciada general. SBLAGWSMS-004-004 Procesamiento de consulta no georeferenciada por tipo. SBLAGWSMS-004-005 Consulta georeferenciada/no georeferenciada. SBLAGWSMS-004-006 Consulta no georeferenciada por colonia y código postal. SBLAGWSMS-004-007 Consulta no georeferenciada por calle y codigo postal.

5.2.5. Registro y visualización de información georeferenciada. SBLAN2SMS-001 Envío y recepción de información

SBLAN2SMS-001-001 Visualización de información almacenada en la base de datos.

SBLAN2SMS-001-002 Registro de información georeferenciada en la base de datos.


- - 60

5.3. Procedimiento para las Pruebas. Este apartado contiene la descripción de los procedimientos correspondientes a todos los casos de prueba que conforman el presente documento. La organización de todos los casos de prueba se basa en cada uno de los grupos definidos. El objetivo fundamental de cada uno de los casos es verificar y validar una funcionalidad específica del software SBLAGWSMS –acrónimo de plan de pruebas, consultar anexo C-. Dentro de cada uno de los grupos de pruebas se definen casos de prueba para cierta funcionalidad específica a modo de comprobar que cumple con aspectos funcionales que deben ser cubiertos por ese grupo de casos de prueba.

Cada uno de los casos de prueba se enfoca en la validación y verificación de una funcionalidad concreta del software SBLAGWSMS.

La descripción de cada uno de los casos de prueba muestra el objetivo general del grupo, el entorno de prueba necesario y todos los casos de prueba que lo conforman.

Para cada uno de los casos de prueba se define el propósito del caso, el entorno necesario para su ejecución, el procedimiento y los resultados esperados de la prueba.

Como recomendación para la revisión de los casos de prueba, se deben llevar acabo en orden de aparición.

5.3.1. SBLAGWSMS-001 Pruebas de conexión y configuración. Objetivo Verificar que la conexión a la base de datos y al modem GSM o en su defecto un teléfono con capacidad para trabajar como modem se establezcan correctamente. Entorno de prueba Para los casos de prueba contenidos en este grupo se utilizan los siguientes elementos:

• Pc o Laptop. • MODEM GSM o teléfono. • Manejador de base de datos iniciado.

SBLAGWSMS-001-001 Configuración y conexión con el dispositivo móvil.

Objetivo

Establecer la configuración en el archivo SMSServer.conf y verificar la conexión del software SBLAGWSMS con el dispositivo.

Entorno de prueba

La prueba se llevará a cabo con dos teléfonos con capacidad de operar como modem GSM, los modelos SonyEricsson W300i y el Sagem myX-7 y con un modem Multitech modelo MTCBA-G-U-F2.


- - 61

Proceso

1. Conectar el dispositivo mediante un cable USB hacia la computadora. 2. Establecer los parámetros de conexión al teléfono en el archivo SMSServer.conf. 3. Ejecutar la aplicación, presionar el botón conectar en el menú acciones (en caso

de estar en modo gráfico) y observar los resultados.

Resultados

Lograr la conexión con el dispositivo y obtener datos sobre fabricante y modelo del hardware entro otros.

SBLAGWSMS-001-002 Configuración y conexión con la base de datos.

Objetivo Establecer la configuración a la base de datos en el archivo SMSServer.conf y verificar la conexión del software SBLAGWSMS con la misma.

Entorno de prueba La prueba se llevará a cabo con el manejador de bases de datos PostgreSql 8.1.5 en ejecución.

Proceso

1. En caso de que el servidor de base de datos no se encuentre en ejecución, iniciar su proceso.

2. Establecer los parámetros de conexión a la base de datos en el archivo SMSServer.conf.

3. Ejecutar la aplicación y observar los resultados.

Resultados Obtener y mantener una conexión a la base de datos y verificar que se cuenta con el acceso a ella en la aplicación SBLAGWSMS.

SBLAGWSMS-001-003 Operación en modo texto.

Objetivo Establecer la configuración para modo texto en el archivo SMSServer.conf y observar la ejecución en modo texto.

Entorno de prueba La prueba se lleva a cabo bajo el entorno del IDE (Integrate Development Enviroment Ambiente de desarrollo Integrado) de netbeans 5.5.


- - 62

Proceso

1. Establecer los parámetros de configuración para ejecutar la aplicación en modo texto.

2. Ejecutar la aplicación 3. Observar el comportamiento.

Resultados Verificar la ejecución de la aplicación en el entorno de desarrollo en modo texto.

SBLAGWSMS-001-004 Operación en modo gráfico.

Objetivo Establecer la configuración para visualizar la interfaz gráfica en el archivo SMSServer.conf y observar su correcto funcionamiento.

Entorno de prueba La prueba se lleva a cabo bajo el entorno del IDE (Integrate Development Enviroment Ambiente de desarrollo Integrado).

Proceso

1. Establecer los parámetros de configuración para ejecutar la aplicación en modo gráfico.

2. Ejecutar la aplicación 3. Observar el comportamiento.

Resultados Observar la ejecución de la interfaz gráfica de la aplicación.

5.3.2. SBLAGWSMS-002 Pruebas de invocación de información dinámica externa.

Objetivo

Verificar que la invocación del servicio Web se realice de la manera correcta y se encuentre disponible para su uso. Entorno de prueba Para realizar esta prueba se necesitan 3 elementos que se mencionan a continuación:

• Pc o LapTop. • Modem GSM o teléfono. • Enlace a Internet. • Documento WSDL para la invocación del servicio.


- - 63

SBLAGWSMS-002-001 Invocación de servicio Web para la obtención dinámica de la información a mostrar (simulada).

Objetivo Invocar desde línea de comandos el servicio Web para obtener el clima de una ciudad a partir de parámetros proporcionados por el usuario para obtener los resultados en la ventana de línea de comandos.

Entorno de prueba Para la simulación de una petición se utilizan el acceso a Internet, la computadora y un programa desarrollado para la invocación del servicio Web desde línea de comandos basado en su WSDL.

Proceso

1. Verificar que se tiene acceso a Internet ya que la información solicitada proviene de un servidor externo.

2. Ejecutar desde línea de comandos el programa realizado. 3. Observar los resultados obtenidos.

Resultados Se espera obtener el clima de una ciudad específica en una respuesta desde el servidor remoto.

SBLAGWSMS-002-002 Invocación de servicio Web para la obtención dinámica de la información a mostrar –real-.

Objetivo Recibir una petición desde un dispositivo móvil a través de mensajería SMS con una petición con el siguiente mensaje “CLIMA XXXXX” donde XXXXX puede ser cualquier ciudad de la cual el servidor externo pueda responder o tenga registro de ella.

Entorno de prueba Para la recepción y respuesta de una petición se utilizan el acceso a Internet, la computadora y el software SBLAGWSMS en ejecución el cual está en espera de peticiones. Proceso

1. Verificar que se cuenta con el acceso a Internet. 2. Verificar que el software SBLAGWSMS se encuentra en ejecución, en caso

contrario iniciarlo. 3. Enviar un mensaje SMS con el texto “CLIMA XXX”. 4. Esperar los resultados tanto en la parte servidor como cliente.

Resultados Se espera obtener del servidor externo el clima de la ciudad que se especificó y además que la respuesta se envíe al dispositivo que lo solicitó en un mensaje SMS.


- - 64

5.3.3. SBLAGWSMS-003 Pruebas de almacenamiento de la información. Objetivo Verificar que los datos que se envían y reciben sean almacenados en la base de datos, así como, verificar que se actualiza la tabla de los mensajes temporales msjtemp. Entorno de prueba Para la ejecución de este grupo de pruebas se requiere la interacción de un cliente realizando una petición, la base de datos y el software SBLAGWSMS.

SBLAGWSMS-003-001 Almacenamiento de mensajes recibidos.

Objetivo

Comprobar que los mensajes provenientes de una petición se almacenen en la base de datos

Entorno de prueba

Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS.

Proceso

1. Verificar que el software SBLAGWSMS se esté ejecutando, si no es así proceder con su ejecución.

2. Verificar que el servidor de base de datos se encuentra en ejecución en caso contrario proceder a iniciarlo.

3. Enviar cualquier petición que acepte el software SBLAGWSMS para su procesamiento.

4. Verificar los registros de la tabla sms_in de la base de datos. Resultados

Validar que la petición proveniente del dispositivo móvil se almacenó como un registro en la base de datos en la tabla sms_in.

SBLAGWSMS-003-002 Almacenamiento de mensajes enviados.

Objetivo Comprobar que los mensajes provenientes de una petición se almacenen en la base de datos Entorno de prueba


- - 65

Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS. Proceso



3. Enviar cualquier petición que acepte el software SBLAGWSMS para su procesamiento.

4. Verificar los registros de la tabla sms_out de la base de datos.

Resultados Comprobar que la petición proveniente del dispositivo móvil se almacenó como un registro en la tabla sms_out.

SBLAGWSMS-003-003 Almacenamiento de datos temporales para persistencia de información demandada

Objetivo Comprobar que los mensajes de respuesta a una petición se almacenen en la base de datos

Entorno de prueba Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS. Proceso

1. Después de que llega la petición de un dispositivo móvil esperar a que la consulta se procese.

2. Verificar la tabla de sms_out en busca del registro que se envió. Resultados Comprobar que la respuesta se almacenó como un registro en la tabla sms_out.

SBLAGWSMS-003-004 Actualización de la información de persistencia sobre datos enviados contra totales

Objetivo Verificar la actualización de la tabla msjtemp en su campo tot_env para mantener el registro del tipo de información que requiere el cliente y en caso de solicitar la misma consulta no retornar los mismos resultados.


- - 66

Entorno de prueba Se realizan consultas consecutivas sobre un servicio específico o una palabra clave específica. Proceso

1. Tener ejecutando el software y la base de datos. 2. Realizar peticiones consecutivas de un mismo servicio hacia el servidor. 3. Verificar el registro correspondiente en la base de datos.

Resultados Comprobar que el registro se actualizó en la tabla msjtemp en el campo tot_env y que cuando ya no existan resultados se borre el registro que hace referencia a esa petición.

5.3.4. SBLAGWSMS-004 Envío y recepción de información. Objetivo Probar que la recepción y transferencia de la información se realice de manera correcta de acuerdo a los criterios de búsqueda que se reciban de la petición del cliente móvil. Otro aspecto importante es la correcta interpretación del texto que proviene del dispositivo. Entorno de prueba Para la ejecución de este grupo de pruebas se requiere la interacción de un cliente realizando una petición, la base de datos y el software SBLAGWSMS. SBLAGWSMS-004-001 Recepción de mensajes

Objetivo Obtener el texto de los mensajes que se envía hacia el servidor para su procesamiento.

Entornos de prueba


Proceso

1. Verificar que el software SBLAGWSMS se esté ejecutando, si no es así, proceder con su ejecución.

2. Verificar que el servidor de base de datos se encuentra en ejecución, en caso contrario, proceder a iniciarlo.

3. Enviar una petición desde el dispositivo móvil hacia el servidor. 4. Esperar a que llegue al teléfono y observar los resultados.

Resultados Comprobar que el software SBLAGWSMS recibió la información proveniente del dispositivo móvil.


- - 67

SBLAGWSMS-004-002 Procesamiento de consulta georeferenciada por tipo o categoría

Objetivo Obtener los puntos de interés más cercanos en base a la petición del cliente, por ejemplo, con un mensaje que haga la búsqueda de escuelas a una distancia de 1 Km. basadas en la API para LBS definida en [RUI05]. Entorno de prueba Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS. Proceso


2. Verificar que el servidor de base de datos se encuentra en ejecución en caso contrario, proceder a iniciarlo.

3. Enviar cualquier petición que acepte el software SBLAGWSMS para su procesamiento (por ejemplo 0;2;0;14,10,18.8765666,-99.2197585). Para verificar la interpretación de esta trama consultar el Anexo D.

4. Comparar los resultados enviados con los resultados esperados.

Resultados Comprobar que los resultados las estas consultas coincidan en un 100% con las establecidas.

SBLAGWSMS-004-003 Procesamiento de consulta georeferenciada general

Objetivo Obtener todos los puntos de interés más cercanos en base a la petición del cliente por ejemplo con un mensaje que haga la búsqueda de todos los servicios disponibles a una distancia de 1 Km. basadas en la API definida en [RUI05]. Entorno de prueba Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS. Proceso



3. Enviar una petición con la trama con el identificador de búsqueda denominado TODOS (por ejemplo: 0;2;0;17,10,18.8765666,-99.2197585). Consultar Anexo D.

4. Comparar los resultados enviados con los resultados esperados.


- - 68

Resultados Comprobar que se retornaron los dos puntos más cercanos a la ubicación y que se guarde en la tabla msjtemp un registro para las consultas posteriores sobre el mismo texto.

SBLAGWSMS-004-004 Procesamiento de consulta no georeferenciada por tipo

Objetivo Realizar una consulta no georeferenciada que permita obtener una respuesta sin formatearla bajo la trama de la API para SBL. Entorno de prueba Estas pruebas se realizan en la computadora que contiene el servidor de base de datos y el software SBLAGWSMS. Proceso



3. Ingresar directamente desde la bandeja principal del teléfono la palabra CLIMA XXXX donde XXXX puede ser cualquier ciudad (que esté registrada en el servidor externo) de la cual se requiere obtener la información.

Resultados Validar que se envió y se puede leer la información en la pantalla de un dispositivo móvil.

SBLAGWSMS-004-005 Consulta georeferenciada/no georeferenciada

Objetivo

Verificar las consultas del tipo georeferenciadas o no georeferenciadas.

Entorno de prueba


Proceso



3. Realizar cualquier consulta georeferenciada / no georeferenciada. 4. Verificar en la tabla de sms_out los distintos puertos por los que se puede enviar la

respuesta.


- - 69

Resultados

Validar que la aplicación funciona independientemente de la trama que especifica el API de SBL definida en [RUI05] complemento de este proyecto.

SBLAGWSMS-004-006 Consulta no georeferenciada por colonia y código postal

Objetivo

Verificar que se procesan peticiones no georeferenciadas desde cualquier celular y que se realiza la búsqueda de servicios por medio de las palabras clave: tipo de servicio, el nombre de la colonia y el código postal.

Entorno de prueba


Proceso

1. Verificar que el software SBLAGWSMS se esté ejecutando, si no es así, proceder

con su ejecución. 2. Verificar que el servidor de base de datos se encuentra en ejecución, en caso

contrario, proceder a iniciarlo. 3. Realizar una consulta no georeferenciada por ejemplo: “farmacia colonia Palmira

62490”. 4. Verificar que la información que se envió al dispositivo celular sea correcta.

Resultados

Se obtiene una respuesta a la petición no georeferenciada en el dispositivo móvil con los servicios encontrados en la colonia donde se realizó la petición.

SBLAGWSMS-004-007 Consulta no georeferenciada por calle y código postal

Objetivo

Verificar que se procesan peticiones no georeferenciadas desde cualquier celular y que se realiza la búsqueda de servicios por medio de las palabras clave: tipo de servicio, el nombre de la calle y el código postal.

Entorno de prueba


Proceso

1. Verificar que el software SBLAGWSMS se esté ejecutando, si no es así, proceder

con su ejecución. 2. Verificar que el servidor de base de datos se encuentra en ejecución, en caso

contrario, proceder a iniciarlo. 3. Realizar una consulta no georeferenciada por ejemplo: “farmacia calle Internado

Palmira 62490”.


- - 70

4. Verificar que la información que se envió al dispositivo celular sea correcta.

Resultados

Validar que se obtuvo una respuesta a la petición no georeferenciada en el dispositivo móvil con los servicios encontrados en la calle donde se realizó la petición.

5.3.5. SBLAGWSMS-001 Pruebas de registro y visualización de la información. Objetivo Verificar que el sistema Negocio2SMS registre y despliegue la información georeferenciada de manera correcta. Entorno de prueba Para los casos de prueba contenidos en este grupo se utilizan los siguientes elementos:

• Pc o Laptop. • Manejador de base de datos iniciado. • Explorador Web. • Sistema Negocio2SMS.

SBLAN2SMS-001-001 Visualización de la información en el explorador Web

Objetivo

Comprobar que la información almacenada en la base de datos se puede visualizar desde el sistema Negocio2SMS

Entorno de prueba

Las pruebas para este caso de prueba se realizan mediante cualquier navegador Web con acceso a Internet.

Proceso

1. Verificar que el servidor de base de datos se encuentra en ejecución en caso

contrario proceder a iniciarlo. 2. Verificar que el servidor de Web se encuentre en ejecución en caso contrario

iniciarlo. 3. Introducir la URL http://localhost:8080/Negocio2SMS en el explorador Web. 4. Verificar la página que se muestra.

Resultados

Comprobar que se obtiene la información almacenada en la base de datos y se despliega en una página JSP.


- - 71

SBLAN2SMS-001-002 Registro de información georeferenciada en la base de datos

Objetivo Comprobar que la información que se introduce mediante el sistema Negocio2SMS se almacena en la base de datos junto con su ubicación expresada en forma de un objeto geométrico.

Entorno de prueba

Las pruebas para este caso de prueba se realizan mediante cualquier navegador Web con acceso a Internet.

Proceso

1. Verificar que el servidor de base de datos se encuentra en ejecución en caso

contrario proceder a iniciarlo. 2. Verificar que el servidor de Web se encuentre en ejecución en caso contrario

iniciarlo. 3. Introducir la URL http://localhost:8080/Negocio2SMS en el explorador Web. 4. Realizar el registro de un nuevo proveedor de servicios. 5. Visualizar su registro en la página de inicio.

Resultados Comprobar que se almacenó la información georeferenciada en la base de datos espacial.


- - 72

5.4. Resultados de Pruebas.

Tabla 11 Caso de prueba SBLAGWSMS-001-001. Caso de prueba: SBLAGWSMS-001-001 Configuración y conexión con el dispositivo móvil.

Resultado: OK

general.gui = yes phone.interval=10 phone.smsc_number= phone.sim_pin=0000 phone.protocol=pdu serial.port=COM7 serial.baud=115200

general.gui = yes phone.interval=10 phone.smsc_number= phone.sim_pin=0000 phone.protocol=pdu serial.port=COM10 serial.baud=115200

Observaciones: La conexión se realizó de manera exitosa a los dos teléfonos, esta prueba también se realizó con un celular Nokia 9300i pero presenta problemas para extraer los datos del teléfono. Se observó en los parámetros de conexión que el protocolo de comunicación es PDU (protocol data unit, unidad de datos de protocolo), el cual permite el envío de mensajería a través de un puerto específico.

Responsable de la prueba: Pedro Quiñónez Bernardino Cargo: Autor


- - 73

Tabla 12 Caso de prueba SBLAGWSMS-001-002.

Caso de prueba: SBLAGWSMS-001-002 Configuración y conexión con la base de datos.

Resultado: OK

database.enabled=yes database.type=postgresql database.url=jdbc:postgresql://localhost:5432/LBSdatabase.driver=org.postgresql.Driver database.username=postgres database.password=distribuidos

database.enabled=no database.type=postgresql database.url=jdbc:postgresql://localhost:5432/LBS database.driver=org.postgresql.Driver database.username=postgres database.password=distribuidos

Observaciones: Se comprobó que ejecución de la aplicación mediante la interfaz gráfica y en modo texto funcionan correctamente y se establece la comunicación con la base de datos, en la parte izquierda se observa en monocromático la opción JDBC, que indica que se obtuvo la conexión a la base de datos satisfactoriamente. Un aspecto importante en esta parte es que, la conexión con la base de datos permanece abierta, en espera de peticiones por parte del software SBLAGWSMS, con esto se elimina la carga de estar abriendo y cerrando la conexión a la base de datos cada vez que se necesita información de ella. Responsable de la prueba: Pedro Quiñónez Bernardino Cargo: Autor


- - 74


Caso de prueba: SBLAGWSMS-001-003 Operación en modo texto.

Resultado:OK

general.gui = no phone.interval=10 phone.smsc_number= phone.sim_pin=0000 phone.protocol=pdu serial.port=COM10 serial.baud=115200

Observaciones: Esta prueba define los parámetros para la configuración en modo consola y la forma en que se define cuando debe de operar de esta forma. Se encuentra en espera de peticiones y está configurado para buscar nuevas peticiones cada 10 segundos.



- - 75

Tabla 14 Caso de prueba SBLAGWSMS-001-004. Caso de prueba: SBLAGWSMS-001-004 Operación en modo gráfico.

Resultado:OK

general.gui = yes

Observaciones: Solamente se muestra la forma en que se ejecuta la aplicación en modo gráfico.



- - 76

Tabla 15 Caso de prueba SBLAGWSMS-002-001. Caso de prueba: SBLAGWSMS-002-001 Invocación de servicio Web para la obtención

dinámica de la información a mostrar (simulada).

Resultado:OK

Observaciones: La prueba se realizó de nueva cuenta debido a que no se capturaron las pantallas en el momento de la primera ejecución simulada. Se observa que la invocación del servicio Web hace referencia al clima actual en el instante en la ciudad de Cuernavaca Morelos. En este apartado se generaron problemas al invocar los métodos del servicio Web de forma nativadebido a que las plataformas sobre las que se desarrollaron el servicio Web y el cliente fueron distintas.



- - 77

Tabla 16 Caso de prueba SBLAGWSMS-002-002. Caso de prueba: SBLAGWSMS-002-002 Invocación de servicio Web para la obtención

dinámica de la información a mostrar (real).

Resultado:OK

Observaciones: Como se puede observar en la prueba simulada, se obtienen diferentes parámetros de los cuales solamente se extraen la parte que se encuentra entre la etiquetas de <temperature> El valor es cambiante y se invoca de la manera CLIMA XXXXX donde XXXXX puede ser cualquier ciudad que el servidor externo reconozca.



- - 78


Caso de prueba: SBLAGWSMS-003-001 Almacenamiento de mensajes recibidos.

Resultado:OK

Observaciones: Se puede observar que en el campo texto se encuentran los mensajes que son enviados mediante el cliente móvil utilizando la API definida en [RUI05] que se encarga de la transferencia de la información en un formato determinado de las consultas que se deben de realizar, estos datos los procesa el servidor para proporcionar los resultados a mostrar. Los mensajes entrantes se almacenan para llevar un registro del servicio más pedido y tener una lista de todos los usuarios que utilizan el servicio.



- - 79

Tabla 18 Caso de prueba SBLAGWSMS-003-002. Caso de prueba: SBLAGWSMS-003-002 Almacenamiento de mensajes enviados.

Resultado: OK

Observaciones: Uno de los principales problemas en el desarrollo de este módulo fue al momento de retornar la respuesta al dispositivo, se puede observar que existen registros repetitivos en el campo text con la palabra CINEPOLIS, esta parte se repetía ya que realizaba la consulta pero no llegaba el mensaje. El desconocimiento de la API en este aspecto fue el principal problema para resolver la incidencia ya que maneja de una forma los mensajes que recibe y de distinta manera los mensaje que retorna.



- - 80

Tabla 19 Caso de prueba SBLAGWSMS-003-003. Caso de prueba: SBLAGWSMS-003-003 Almacenamiento de datos temporales para

persistencia de información demandada.

Resultado: OK

Observaciones: Esta tabla mantiene la consulta que se genera para una palabra clave en donde los resultados se exceden el número que se puede enviar en una petición, predeterminadamente se envían dos resultados que en promedio son los que caben en un mensaje SMS sin exceder los 160 caracteres. Cuando se cumple la condición de ban_res = ‘TRUE’ el registro se borra automáticamente cuando el campo tot_env es mayor o igual a tot_resul.



- - 81

Tabla 20 Caso de prueba SBLAGWSMS-004-001. Caso de prueba: SBLAGWSMS-004-001 Recepción de mensajes.

Resultado:OK

Observaciones: En las pantallas expuestas se muestran peticiones que se realizaron al servidor y se observa. Las tramas son distintas ya que se trata de diferentes peticiones, georeferenciadas y no georeferenciadas.



- - 82

Tabla 21 Caso de prueba SBLAGWSMS-004-002. Caso de prueba: SBLAGWSMS-004-002 Procesamiento de consulta georeferenciada por tipo

o categoría.

Resultado:

Mensaje Recibido con la trama 0;2;0;10,10,18.87.65666, -99.2197585 Esta trama nos especifica una búsqueda georeferenciada de tipo TAXI y que lo encuentre a un radio de 1 kilómetro en distancia lineal con las coordenadas 18.87.65666, -99.2197585, que son el punto de su ubicación.

Mensaje convertido y enviado en trama La trama que se muestra en la figura establece que un identificador de trama, no hay más resultados y otros identificadores de trama para control. Después se puede observar que existe un registro llamado: Nombre: Taxi guacamayas Dirección: Reforma 5 Colonia Lomas de Cuernavaca

Observaciones: Para consultas por tipos se observa que se pueden realizar cualquier consulta en base a las palabras claves que se tienen registradas tanto en la API como en el Servidor. Las búsquedas se realizan en distancias lineales por medio de funciones espaciales contenidas en el GIS.



- - 83

Tabla 22 Caso de prueba SBLSAGWSMS-004-003. Caso de prueba: SBLSAGWSMS-004-003 Procesamiento de consulta georeferenciada general.

Resultado: Ok

Primera consulta Se muestra una consulta que pide todos los puntos de interés en una distancia de un kilómetro.

Primer envío Retorna los primeros dos resultados, como la coordenada establecida en el mensaje que llega es la de cenidet muestra como dos primeros lugares este mismo y el IIE.

Segunda consulta Se muestra la segunda petición con los mismos datos.

Segundo envío En esta ocasión como se almacenó en la tabla de msjtemp un registro que permite saber los resultados que se han enviado, ahora se retornan los siguientes dos registros que en este caso son el Videocentro y el local de Farmacias del Ahorro.

Observaciones: Se retornan resultados diferentes hasta que el registro temporal se borre de la tabla msjtemp y esto sucede cuando ya no existen resultados a mostrar o se reinicia el servidor.

Responsable de la prueba: Pedro Quiñónez Bernardino

Cargo: Autor


- - 84

Tabla 23 Caso de prueba SBLAGWSMS-004-004. Caso de prueba: SBLAGWSMS-004-004 Procesamiento de consulta no georeferenciada por

tipo.

Resultado: OK Fecha:

Para este tipo de consulta se utilizó el mismo caso de prueba que en la de los servicios Web, ya que permite realizar una consulta no georeferenciada. Para este caso de prueba tenemos dos peticiones del clima desde distintos teléfonos y hacia ciudades distintas.

Primera petición

Primera respuesta

Segunda petición

Segunda petición

Observaciones: Se pueden realizar peticiones de cualquier ciudad que se encuentre registrada en el servicio Web. Una opción atractiva para proporcionar diversos servicios que se encuentran en la Web.



- - 85

Tabla 24 Caso de prueba SBLAGWSMS-004-006. Caso de prueba: SBLAGWSMS-004-006 Consulta no georeferenciada por colonia y código

postal.

Resultado: OK

Las consultas no georeferenciadas se realizan por medio de un formato de mensaje donde se cuenta con 4 parametros: El tipo de servicio, la palabra colonia, el nombre de la colonia y el código postal de donde se requiere obtener los servicios. Por ejemplo: escuela colonia Palmira 62490

Primera petición

escuela colonia Palmira 62490

Primera respuesta

Segunda petición

msuper colonia Palmira 62490

Segunda respuesta

Observaciones: En las imágenes se observa la palabra MSJ_STANDARD que se interpreta como un mensaje que se retorna en texto plano y no se necesita codificarlo en ninguna trama como es el caso de los mensajes georeferenciados. Se muestra el total de resultados que se obtienen de la petición y por último el detalle de cada uno de los servicios encontrados.



- - 86

Tabla 25 Caso de prueba SBLAGWSMS-004-007. Caso de prueba: SBLAGWSMS-004-007 Consulta no georeferenciada por calle y código

postal.

Resultado: OK

Las consultas no georeferenciadas se realizan por medio de un formato de mensaje donde se cuenta con 4 parametros: El tipo de servicio, la palabra calle, el nombre de la calle y el código postal de donde se requiere obtener los servicios. Por ejemplo: escuela calle Palmira 62490

Primera petición

videos calle Palmira 62304

Segunda respuesta

Segunda petición

escuela calle interior internado 62490

Segunda respuesta

Tercera petición

escuela calle reforma 62493

Tercera respuesta

Observaciones: Las peticiones para el caso de las calles se realizan de forma similar a las que se realizan con la palabra colonia. En esta consulta la búsqueda se delimita en base a la calle donde se encuentra o de la cual se requiere saber datos de un servicio en específico.



- - 87

Tabla 26 Caso de prueba SBLAN2SMS-001-001. Caso de prueba: SBLAN2SMS-001-001 Visualización de la información en el explorador Web.

Resultado: OK

En este caso de prueba se validó que la información se desplegó y visualizó en los exploradores Web Firefox e Internet Explorer. Los datos que se muestran en la pantalla principal en la imagen (a) son cargados cuando se realiza la petición al servidor. La imagen (b) muestra los datos específicos de cada uno de los servicios que se encuentran almacenados en la base de datos.

(a)

(b) Observaciones: En las imágenes se observan todos los servicios registrados en la base de datos espacial. En (a) se muestran los servicios almacenados en la base de datos cuando se carga la página de inicio de la aplicación Web. En (b) se muestra el detalle de uno de los servicios registrados en la base de datos. Con esto se comprueba el correcto funcionamiento del acceso a la base de datos espacial desde el sistema Web.


Datos leídos desde la base de datos cuando se carga la aplicación.

Datos leídos desde la base para el visualizar el detalle de cada uno de los servicios registrados


- - 88

Tabla 27 Caso de prueba SBLAN2SMS-001-002_1. Caso de prueba: SBLAN2SMS-001-002 Registro de la información georeferenciada en la base

de datos.

Resultado: OK

Para el registro de un nuevo proveedor de servicios se debe cargar la aplicación en el explorador Web y seleccionar la opción de Registrar la cual muestra las páginas mostradas en las imágenes (a) y (b).

(a)

(b)

Observaciones: Para el registro de un nuevo proveedor se capturan dos formularios: El primero para los datos del responsable del servicio (a) y el segundo para introducir los datos del servicio. En la imagen (b) se observa una leyenda denominada Georeferenciación y hace énfasis a la parte de la imagen proporcionada por el API de Google Maps [AGM06] donde se encuentra una marca que identifica el lugar donde está ubicado el servicio. Esta marca permite ubicar geográficamente el servicio dentro de la base de datos a través de coordenadas geográficas. Responsable de la prueba: Pedro Quiñónez Bernardino Cargo: Autor

Datos generales del responsable del servicio

Datos generales del servicio

Georeferenciación


- - 89

Tabla 28 Caso de prueba SBLAN2SMS-001-002_2. Caso de prueba: SBLAN2SMS-001-002 Registro de la información georeferenciada en la base

de datos.

Resultado: OK

(a)

(b)

Observaciones: La comprobación del registro del nuevo proveedor del servicio se observa en las imágenes (a) y (b). La imagen (a) muestra la información del nuevo servicio en la página principal del sistema Web. La imagen (b) muestra los datos almacenados en la base de datos SBL, al final de la imagen se observa el nuevo servicio registrado con sus coordenadas geográficas. En los resultados se observa un campo llamado asText que representa el tipo de dato geométrico expresado en forma de coordenadas de tipo Longitud-Latitud. Responsable de la prueba: Pedro Quiñónez Bernardino Cargo: Autor

Servicio registrado

El nuevo registro almacenado en la base de datos espacial.


- - 90

Los casos de prueba presentados validaron la funcionalidad de los módulos que conforman la arquitectura. En la Tabla 29 se muestra un resumen de los grupos de casos de prueba con una conclusión sobre la operación y comportamiento de la plataforma para cada grupo.

Tabla 29 Resumen de los casos de prueba de la plataforma propuesta.

Grupo Descripción Resultado Conclusión

SBLAGWSMS-001 Pruebas conexión y configuración

Exitoso La conexión a la base de datos y al dispositivo GSM se realizó

de manera correcta.

SBLAGWSMS-002 Pruebas de invocación de información externa

Exitoso

La invocación de la información georeferenciada y

no georeferenciada resulto satisfactorio obteniendo los datos esperados a través de

los servicios Web.

SBLAGWSMS-003 Pruebas de almacenamiento de la información

Exitoso

Las pruebas de almacenamiento cubrieron los

objetivos planteados en los casos de prueba para los

mensajes recibidos, enviados y para la parte del estado de

las peticiones cuando los resultados son mayores a dos.

SBLAGWSMS-004 Prueba de envío y recepción de información

Exitoso

Las consultas georeferenciadas y no

georeferenciadas que son atendidas por el GIS fueron resultas de manera correcta.

SBLAGWSMS-005 Registro y visualización de la información

Exitoso

El registro de la información de los proveedores de servicios se almacenó

correctamente en la base de datos y se pudo verificar que

se puede obtener la información de los

proveedores de servicios por medio de la mensajería de

SMS.

Capítulo 6 Conclusiones

- - 91


Capítulo 6 Conclusiones En este capítulo se mencionan las aportaciones que se generaron con el trabajo de investigación de esta tesis. Se plantean las conclusiones a las que se llegaron después de la investigación realizada y se proponen los trabajos futuros que se pueden derivar del trabajo desarrollado. Se muestran las experiencias obtenidas con el desarrollo de la tesis así como los casos de éxito y fracaso encontrados durante la investigación.


- - 92

6.1. Conclusiones. Mediante la tecnología de los sistemas de información geográfica, las tecnologías de los servicios Web y un sistema de posicionamiento es posible ofrecer servicios basados en localización a dispositivos móviles a través de la mensajería de SMS, explotando la utilización de ellos sobre las redes GSM. Utilizando las coordenadas geográficas proporcionadas por un sistema de posicionamiento global se pueden proporcionar los servicios basados en localización eliminando la dependencia con la red celular a la que pertenece el dispositivo móvil. De esta forma se proporcionan los servicios a dispositivo de cualquier compañía de telefonía celular. Las coordenadas geográficas expresadas en forma de latitud-longitud permiten que los sistemas de información geográfica puedan manipular esa información como un objeto geométrico, con lo cual se pueden realizar operaciones de cercanía, traslapes, vecindad y otras funciones, por esto, la información geográfica proporcionada por un sistema de posicionamiento fue de vital importancia para el desarrollo de este trabajo, ya que sin dicha información no se pueden ejecutar las funciones espaciales sobre la base de datos espacial. El trabajar con archivos de tipo vectorial, permite almacenar dentro de un GIS la información con la que cuentan los archivos y manipularlos mediante funciones espaciales dentro del manejador de base de datos espacial. Para manipular correctamente la información a presentar a los dispositivos móviles, la información geográfica proporcionada por el sistema de posicionamiento, debe estar en el mismo sistema de referencia espacial que los archivos vectoriales almacenados en la base de datos. De no ser así, la información que se retorne resulta errónea.

Los desarrollos e investigaciones se han vuelto campos multidisciplinarios que conjuntan diversas tecnologías para proponer alternativas y soluciones a problemas en donde un solo campo de investigación no resuelve completamente la problemática. La tesis desarrollada

La tecnología de los servicios Web permitió invocar información que no puede almacenarse dentro de una base de datos para solucionar servicios basados en localización ya que representa información dinámica.

Por último el trabajar con aplicaciones de servicios basados en localización representa un campo de investigación muy amplio enfocándolo a la integración de diversas tecnologías que permitan proporcionar mejores servicios en diferentes formatos y representaciones.

6.2. Aportaciones. Análisis, diseño, implementación y puesta en marcha de un sistema de información geográfica.

• El GIS esta conformado por archivos vectoriales importados hacia la base de datos e información espacial proveniente del sistema Web desarrollado que permiten realizar las operaciones espaciales sobre los datos geométricos almacenados.

• El GIS cuenta con un conjunto de consultas espaciales para solventar las peticiones que

se realizan desde los dispositivos móviles. Estas consultas quedan preparadas para ampliar su funcionalidad y realizar su representación en otros formatos.


- - 93

Procedimiento para generar la información requerida en la implementación del algoritmo de Dijkstra.

• El procedimiento realizado, se valida con clases desarrolladas para cada una de las fases que lo conforman.

• La primera fase consta de generar una nueva tabla en la base de datos espacial con todos

los nodos que se generan del archivo vectorial importado en el GIS.

• La siguiente fase es crear una segunda tabla denominada adyacencia que contiene el identificador del nodo, el identificador de los nodos adyacentes, el identificador del tramo al cual pertenecen los nodos adyacentes y la longitud del tramo correspondiente.

• Posteriormente se ejecutan las clases de java correspondientes para cargar en memoria la

información y quede preparada para la ejecución del algoritmo de Dijkstra. Implementación del módulo de ruta más corta por medio del algoritmo de Dijkstra.

• El algoritmo es aplicado directamente sobre tablas de la base de datos que son creadas de manera semiautomática por el procedimiento desarrollado. Los datos necesarios para aplicar el algoritmo se generan automáticamente por medio de consultas espaciales en las tablas correspondientes, generando nuevas tablas que sirven para la ejecución del algoritmo.

Un sistema de registro de proveedores que permite introducir información georeferenciada en la base de datos espacial.

• Este sistema permite que el registro de los proveedores se realice de forma rápida sin tener que acudir a los lugares donde se encuentran los negocios con un dispositivo de posicionamiento como lo es un GPS para tomar las coordenadas geográficas de su ubicación y después vaciar la información en la base de datos de forma manual.

6.3. Problemas Encontrados.

• Durante esta investigación se presentaron problemas relacionados con el sistema de proyección de coordenadas de los archivos shapefiles. El reconocer la importancia de la proyección espacial de los datos que se almacenan en la base de datos es trascendental, si los datos que se almacenan en la base de datos no se encuentran en el mismo sistema de coordenadas, no se pueden realizar las operaciones espaciales.

• Al momento de probar las consultas espaciales desarrolladas, hubo ocasiones en que la

información que se proporcionaba no era la correcta. Este problema surgió debido a que no se utilizaban las funciones espaciales adecuadas. Adecuando las consultas con las funciones espaciales correctas el resultado fue satisfactorio para proporcionar la información que se debía mostrar.

• Con respecto a la mensajería de SMS se probaron diversos desarrollos que

proporcionaban la opción de realizar el envío de mensajes de SMS, de los principales problemas que se encontraron fue el tiempo de respuesta que daban las plataformas, otro de los problemas encontrados fue la forma de transferir los mensajes ya que, cuando se utiliza la API desarrollada en [RUI05], la respuesta se debe de mandar a un puerto específico y esta opción no se encuentra habilitada en algunas pasarelas probadas. Debido a estos inconvenientes se optó por utilizar una API para el envío y recepción de mensajería SMS.


- - 94

Para los trabajos futuros donde la representación de la información será en formatos distintos a los SMS. El tener la información calibrada en el mismo sistema de referencia espacial es primordial para el despliegue correcto de la información. Por ejemplo si la información se que captura desde el sistema Web se almacena en la base de datos y posteriormente se guarda un archivo con información vectorial de colonias dentro de la base de datos para realizar búsquedas espaciales que integren la información de las dos tablas, si no se encuentran en el mismo sistema de referencia de coordenadas, de nada sirve que se tenga soporte para datos espaciales dentro del manejador de base de datos pues las funciones no se pueden aplicar a la información.

6.4. Trabajos Futuros. En lo que respecta a la base de datos espacial se contempla importar dentro de ella archivos vectoriales que sirvan para agregar funcionalidad en cuanto a los servicios que se pueden proporcionar. Mejorar el módulo de GW-SMS para que el acceso concurrente se maneje de manera adecuada y no se produzcan tiempos de respuestas prolongados.

Con respecto al módulo del algoritmo de Dijkstra, buscar la manera de optimizar su funcionamiento a través de la modificación del algoritmo o la implementación de una variante para evaluar su desempeño. El algoritmo presenta un tiempo de respuesta considerable cuando se ejecuta sobre tablas que contienen miles de registros, ya que la forma en que opera es por medio de inundación y su condición de parada se da cuando visitó todos los nodos contenidos en la red.

Almacenar las rutas generadas por la ejecución del algoritmo de Dijkstra, para el momento que se requiera la ruta más corta entre dos puntos conocidos, ya se tenga almacenada la ruta en una base de datos especial cuando el número de registros oscila en los miles y la ejecución del algoritmo se torna deficiente. Con estas rutas almacenadas en la base de datos, se pueden generar patrones que permitan calcular la ruta en un menor número de nodos.

Utilizar servidores de mapas que permitan realizar la transformación de las consultas generadas en imágenes para su posterior envío por ejemplo en mensajería MMS. Los servidores de mapas permiten manejar la información contenida en una base de datos espacial de forma gráfica y para los usuarios representa una ventaja puesto que los resultados que genera el módulo de Dijkstra se pueden mostrar de manera gráfica por ejemplo: a través de una imagen en un mensaje MMS.

Utilizar los servicios que proporcionan los proveedores por medio de las tecnologías de los servicios Web. El diseño de la base de datos cuenta con campos para almacenar la dirección del documento WSDL con el cual se pueden invocar los servicios Web de los proveedores.

Un trabajo futuro que permitiría realizar una comparativa con la tesis desarrollada es:

utilizar técnicas de posicionamiento basada en la red celular para que en función de la célula donde se encuentre conectado el dispositivo, se envíe información de servicios disponibles. Este trabajo permitiría realizar una comparativa en cuestión de los servicios que se ofrecen sobre la plataforma desarrollada en esta tesis y los que se dan basados en las células de las compañías telefónicas.

En la parte del sistema de registro para capturar la información de la ubicación se utiliza el API de GoogleMaps, para quitar esta dependencia a la información disponible por GoogleMaps se puede implementar la infraestructura propia y presentarla a través de los servidores de mapas.

Una expectativa que requiere de una amplia investigación y desarrollo consiste en la integración de todos los servicios e infraestructura para proporcionarlos a través de servicios Web y así como la infraestructura de Google poder ofrecer los servicios para aplicaciones Web donde se integren diversos servicios para que colaboren entre sí.

Anexos

- - 95

Anexos

Anexos

Anexo B

- - 96

Anexo A

Funciones y operaciones definidas en la SFS

-Simple Features Specification-

Anexo B

- - 97

La clase base de la especificación definida en [SFS99] es la clase Geometry la cual contiene subclases para puntos, curvas, líneas, y colecciones de geometrías. En ésta cada objeto geométrico es asociado con un sistema de referencia espacial el cual describe el espacio de coordenadas en el que es definido el objeto geométrico. Para la manipulación de los objetos geométricos existen diversas categorías de funciones y métodos básicos. A continuación se describen las funciones que se pueden realizar dividas por categorías. Métodos básicos sobre geometrías En esta sección se definen las operaciones que se pueden realizar sobre cualquier geometría que herede de la clase base Geometry, las operaciones se definen a continuación:

• Dimension(): Integer.- Devuelve un entero con la dimensión inherente del objeto geométrico. Esta especificación está restringida a geometrías en espacios de coordenadas de dos dimensiones.

• GeometryType(): String.- Retorna el nombre del subtipo de geometría que se encuentra

instanciada.

• SRID(): Integer.- Retorna el Spatial Referente System ID para la geometría.

• Envelope(): Geometry.- Retorna como una geometría los limites mínimos para la geometría. El polígono definido por los pares de coordenadas del rectángulo limitante ((MINX,MINY), (MAXX,MINY), (MAXX,MAXY), (MINX,MAXY), (MINX,MINY)).

• AsText(): String.- Exporta la geometría a una representación WKT10.

• AsBinary(): Binary.- Exporta la geometría a una representación WKB11.

• IsEmpty(): Integer.- Retorna 1 –verdadero- si la geometría es una geometría vacía. Si

retorna verdadero, entonces esa geometría representa un grupo de puntos vacíos para el espacio de coordenadas.

• IsSimple(): Integer.- Retorna 1 –verdadero- si la geometría no tiene geometrías anómalas

tal que se intersecte con ella misma o se contenga.

• Boundary(): Geometry.- Retorna el cierre del limite combinatorio para la geometría. Métodos para pruebas de relaciones espaciales entre objetos geométricos.

• Equeals(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría es “espacialmente igual” con otra geometría.

• Disjoint(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría es

“espacialmente disjunta” con otra geometría.

• Intesects(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría se “intersecta espacialmente” con otra geometría.

10 WKT: Well-Know Text: Representación textual de la geometría. 11 WKB: Well-Know Binary: Representación binaria de la geometría.

Anexo B

- - 98

• Touches(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría se “toca espacialmente” con otra geometría.

• Crosses(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría se “cruza

espacialmente” con otra geometría.

• Within(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría se “encuentra espacialmente” en otra geometría.

• Contains(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría “contiene

espacialmente” a otra geometría.

• Overlaps(geometry,geometry): Integer.- Retorna 1 –verdadero- si la geometría se “traslapa espacialmente” con otra geometría.

• Relate(anotherGeometry:Geometry, intersectionPatternMatrix:String): Integer.-

Retorna 1 –verdadero- si la geometría corresponde con otra geometría mediante la prueba de intersecciones entre el límite interior y exterior de las dos geometrías.

Métodos que soportan análisis espacial.

• Distance(geometry,geometry): Double.- Retorna la distancia más corta entre dos puntos cualesquiera en dos geometrías calculado en el sistema de referencia espacial en el cual están las geometrías.

• Buffer(distance:Double): Geometry.- Retorna una geometría que representa todos los

puntos cuya distancia de la geometría es menor o igual que distance.

• ConvexHull(): Geometry.- Retorna una geometría que representa el casco convexo de la geometría.

• Intersection(geometry,geometry): Geometry.- Retorna una geometría que representa el

grupo de puntos de intersección de las dos geometrías.

• Union(geometry,geometry): Geometry.- Retorna una geometría que representa un grupo de puntos con la unión de las dos geometrías.

• Difference(geometry,geometry): Geometry.- Retorna una geometría con el grupo de

puntos que representa la diferencia entre las dos geometrías.

• SymDifference(geometry,geometry): Geometry.- Retorna una geometría con el grupo de puntos que representan la diferencia simétrica entre las dos geometrías.

GeometryCollection Es una geometría que consta de una colección de una o más geometrías. Todos los elementos en dicha colección deben estar en la misma referencia espacial. Tiene los siguientes métodos.

• NumGeometries(): Integer.- Retorna el número de geometrías en la colección. • GeometryN(integer): Geometry.- Retorna la geometría N de la colección.

Point

Anexo B

- - 99

Es una geometría de cero dimensiones y representa una localización simple en un espacio de coordenadas. Tiene un valor de coordenada X y un valor de coordenada Y. Cuenta con los métodos.

• X(): Double.- Retorna el valor de la coordenada X para el punto. • Y(): Double.- Retorna el valor de la coordenada Y para el punto.

Multipoint

Es una colección geométrica de cero dimensiones. Los elementos de un MultiPoint están restringidos por puntos. Estos no están conectados o en orden. Curve Es una objeto geométrico unidimensional usualmente almacenado como una secuencia de puntos con el subtipo de Curve especificando la forma de interpolación entre los puntos. Una curva es simple si no pasa dos veces a través del mismo punto. Una curva es cerrada si el punto inicial es igual al punto final. El límite de una curva cerrada está vacío. Una curva que es simple y cerrada es un anillo. El límite de una curva no cerrada consiste de dos puntos finales. Una curva es definida como cerrada topológicamente. Los métodos para Curve son:

• Length(): Double.- Retorna la longitud de la curva en el sistema de referencia espacial asociado.

• StartPoint(): Point.- El punto inicial de la curva.

• EndPoint(): Point.- El punto final de la curva.

• IsClosed(): Integer.- Retorna 1 –verdadero- si la curva es cerrada (StartPoint() =

EndPoint()).

• IsRing(): Integer.- Retorna1 –verdadero- si la curva es cerrada (StartPoint() = EndPoint()) y además no pasa por el mismo punto más de una vez.

LineString, Line, LinearRing Es una curva con interpolación lineal entre puntos. Cada par consecutivo de puntos define un segmento de la línea. Una line es una linestring con exactamente dos puntos. Una linearring es una linestring que es cerrada y simple. Los métodos aplicables a esta geometría son:

• NumPoints(): Integer.- Retorna el número de puntos en la linestring. • PointN(integer): Point.- Retorna el punto N especificado de la linestring.

MultiCurve Una MultiCurve es una geometrycollection de una dimensión cuyos elementos son curves. Una multicurve es una clase no instanciable y define un grupo de métodos para las subclases y son incluidas por razones de ampliación. Los métodos de este tipo son:

• IsClosed(): Integer.- Retorna 1 –verdadero- si la multicurve es cerrada por cada Curve.

Anexo B

- - 100

• Length(): Double.- Retorna la longitud de la multicurve la cual es la suma de las

longitudes de todos los elementos Curve contenidos en la multicurve. MultiLneString Una multilinestring es una multicurve cuyos elementos son linestrings. Surface Un surface es un objeto geométrico de dos dimensiones. Los métodos de esta clase geométrica son:

• Area(): Double.- Retorna el área de la geometría expresada en el sistema de referencia espacial.

• Centroid(): Point.- El centroide matemático para la geometría surface como un punto. No

garantiza que sea sobre el surface.

• PointOnSurface(): Point.- Retorna un punto que garantiza que sea un surface. Polygon Un Polygon es un surface definido por un límite exterior y cero o más límites interiores. Cada límite interior define un agujero en el polígono. Las características que definen a los polígonos son: Los poligonos son topológicamente cerrados, el límite de un polígono consiste de un grupo de linearrings, No se cruzan dos anillos en los límites y el interior de cada polígono es una conexión de un grupo de puntos. Los métodos de esta geometría son:

• ExteriorRing(): LineString.- Retorna el anillo exterior para el polígono. • NumInteriorRing() Integer.- Retorna el número de anillos interiores del polígono.

• InteriorRingN(integer): LineString.- Retorna el anillo interior N para el polígono como una

LineString. MultiSurface Una multisurface es una colección geométrica de dos dimensiones cuyos elementos son surfaces. El interior de dos superficies en una multisuperficie puede no intersectarse. Los límites de dos elementos en un multisurface pueden intersectarse en más de un número finito de puntos. La geometría multisurface no es una clase instanciable, pero define un grupo de métodos para las subclases que deriven de ella y por cuestiones de extensibilidad. Los métodos de esta clase geométrica son:

• Area(): Double.- El área de un multisurface es medido en el sistema de referencia espacial del MultiSurface.

• Centroid(): Point.- El centroide matemático del multisurface.

• PointOnSurface(): Point.- Retorna un punto que se garantiza que esta sobre el

multisurface.

Anexo B

- - 101

Anexo B

Instalación de servidor de base de datos espacial

Anexo B

- - 102

PostgreSQL Para la instalación del servidor del sistema de información geográfica se requiere una instalación del servidor PostgreSQL desde sus fuentes para montar la extensión PostGis sobre éste. Los paquetes RPM no permiten la agregación del PostGis por lo cual se debe realizar la instalación a través de los fuentes.

Se descarga el archivo de instalación desde www.postgresql.org. La versión utilizada fue la 8.1.5 o se puede utilizar la versión 8.1.9. El siguiente link http://www.postgresql.org/ftp/source/v8.1.9/ muestra los archivos que se pueden descargar en este caso puede ser postgresql-8.1.9.tar.bz2 o postgresql-8.1.9.tar.gz.

Adicionalmente, se necesitan algunos paquetes, estos son:

i. GNU make o mejor conocido como gmake o make.

ii. Compilador ISO/ANSI C, recomendado el GNU C o gcc.

iii. Programas de compresión y descompresión tales como zip y tar.

Ya que se tiene el código fuente del servidor de base de datos se inicia el proceso de creación, compilación e instalación del servidor. El proceso se dividió en siete pasos y son los siguientes:

1) Se crea el usuario postgres que es el usuario con máximos privilegios en el servidor de base de datos PostgreSQL. Se crea con cuenta de root mediante el comando:

useradd postgres

2) Ya descargados los fuentes de PostgreSQL, el archivo se mueve hacia el directorio /usr/local/src para descomprimirlo en esa ruta. El mover el paquete a ese directorio es opcional ya que se puede descomprimir en cualquier ruta, se coloca en este directorio para mantener un orden en los paquetes descargados e instalados.

mv postgresql-8.1.9.tar.gz /usr/local/src cd /usr/local/src Tar –xvfz postgresql-8.1.9.tar.gz

Cuando se descomprime el paquete genera un nuevo directorio al cual le cambiaremos de propietario mediante el siguiente comando:

chown –R postgres postgresql-8.1.9

3) Ya que se descomprimió el archivo se ingresa en el directorio creado y se ejecuta el

comando ./configure. Para una correcta instalación, se recomienda usar por lo menos las opciones que se muestran a continuación con el comando ./configure:

-with-CXX Permite construir programas C++ mediante la librería libpq++.

-enable-odbc Permite conectar el servidor con porgramas que tienen un driver ODBC compatible.

-enable-multibyte Permite usar caracteres multibyte. –with-maxbackends=NUMERO Establece el número máximo de conexiones permitidas

(32 por defecto)

http://www.postgresql.org/

http://www.postgresql.org/ftp/source/v8.1.9/

http://wwwmaster.postgresql.org/download/mirrors-ftp?file=%2Fsource%2Fv8.1.9%2Fpostgresql-8.1.9.tar.bz2

http://wwwmaster.postgresql.org/download/mirrors-ftp?file=%2Fsource%2Fv8.1.9%2Fpostgresql-8.1.9.tar.gz

Anexo B

- - 103

4) Después de haber configurado los archivos fuentes se utiliza el comando make para la construcción de la instalación hasta el punto que muestre el siguiente mensaje:

All of PostgreSQL is successfully made. Ready to install

5) Una vez configurado y compilado el código fuente de PostgreSQL, es hora de instalar las librerías, binarios y archivos de datos compilados en una ubicación más adecuada del sistema. Se instala con el comando make install. Terminada la instalación en el directorio usr/local/ se creó un directorio llamado pgsql en el cual se encuentran todas las librerías, binarios y archivos del servidor. Como superusuario cambiamos el dueño de ese directorio y hacemos al usuario postgres su propietario con el comando:

chown –R postgres /usr/local/pgsql

6) El uso de las variables de entorno de PostgreSQL no es requerido. Sin embargo, son útiles cuando se realizan tareas como el arranque y parada de los procesos del postmaster. Las variables de entorno que deberían ser configuradas lo son para las páginas man y para el directorio bin. Esto se hace añadiendo las siguientes líneas en el archivo /etc/profile.

PATH=$PATH:/usr/local/pgsql/bin MANPATH=$MANPATH:/usr/local/pgsql/man Export PATH MANPATH

7) Completados los pasos anteriores, se puede iniciar el servidor de base de datos.

Primeramente ingresamos como usuario postgres con el comado su –l postgres, ya logeados se ejecuta la siguiente instrucción:

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

Esta instrucción sólo se ejecuta la primera vez que se inicia el servidor es la que le dice al servidor donde se almacenan las bases de datos.

Después se inicia el servidor con el siguiente comando:

/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data

Si todo se realizó sin ningún problema el servidor de base de datos se instaló exitosamente.

PostGis

Para la instalación de la extensión PostGis como se mencionó anteriormente se necesita de un árbol de código fuente del PostgreSQL construido y configurado completamente. Para el correcto funcionamiento se tienen otros requerimientos de software que se mencionan a continuación:

i. La librería de reproyección Proj4. Proporciona soporte a la reproyección de coordenadas en PostGis. Disponible en http://www.remotesensing.org/proj.

ii. Librería geométrica GEOS. Usada para proporcionar tests geométricos. Disponible en

http://geos.refractions.net.

NOTA: Estas dos librerías se deben de instalar antes de hacer la construcción, compilación e instalación de PostGis.

La instalación de estas dos librerías se realiza con el siguiente procedimiento:

http://www.remotesensing.org/proj

http://geos.refractions.net/

Anexo B

- - 104

1) Se descomprimen los fuentes de los archivos en /usr/local/src con el comando tar vfz pro4.1.1.x.tgz

2) Se accede al directorio creado después de la ejecución del comando y se ejecuta el

comando ./configure.

3) Por último se ejecuta el comando make install. Este proceso se realiza para las dos librerías que se deben de instalar, en caso de que las librerías sean paquetes rpm sólo se ejecuta el comando rpm –ivh nombredelpaquete.

Ya que se tienen los requerimientos de software, descargamos el archivo de PostGis desde http://postgis.refractions.net/download/, descargamos el archivo postgis-1.1.6.tar.gz este archivo lo descomprimimos en la carpeta /usr/local/src/postgresql-8.1.9/contrib y nos genera el directorio postgis-1.1.6. Ingresamos a este directorio y se configura la instalación por medio del comando ./configure. Posteriormente se compila con el comando make y finalmente se instala con el comando make install.

Si todo resultó correcto todos los archivos de PostGis fueron instalados en el directorio de

de instalación de PostgreSQL. Se crea la base de datos que se va utilizar con el siguiente comando:

createdb <nombre de base de datos>

PostGIS requiere una extensión del lenguaje procedural PL/pgSQL. Antes de cargar los scripts necesarios con las funciones espaciales se debe de habilitar la compatibilidad con dicho lenguaje. Esto se realiza mediante el siguiente comando:

su –l postgres

psql createlang plpgsql <nombre de base de datos> El archive lwpostgis.sql contiene las definiciones de funciones y objetos. El archivo

spatial_ref_sys.sql contiene un conjunto de identificadores de sistemas de coordenadas ESPG. Cabe mencionar que estas tres últimas instrucciones se realizan con el usuario postgres. Para dotar a una base de datos con capacidades espaciales se necesita cargar en ella dos scripts que vienen en el archivo de PostGis. Las instrucciones son las siguientes:

psql -d <nombre base de datos> -f /usr/local/pgsql/share/contrib/lwpostgis.sql

psql -d <nombre base de datos> -f /usr/local/pgsql/share/contrib/spatial_ref_sys.sql

El archive lwpostgis.sql contiene las definiciones de funciones y objetos. El archivo spatial_ref_sys.sql contiene un conjunto de identificadores de sistemas de coordenadas ESPG. Cabe mencionar que estas tres últimas instrucciones se realizan con el usuario postgres. NOTA: Al cargar los dos scripts en ocasiones ocurre un pequeño problema. Al ejecutar el primer comando se genera el siguiente error: psql:postgis.sql:38: NOTICE: ProcedureCreate: type histogram2d is not yet defined

psql:postgis.sql:38: ERROR: Load of file /usr/local/pgsql/lib/libpostgis.so.0.8 failed: libgeos.so.1: cannot open shared object file: No such file or directory

Este error se genera porque no se encuentra la librería libgeos.so.1 y libproj.so.1 que se encuentran en la ruta /usr/local/lib. Para solucionarlo se enlaza la librería libgeos.so.1 y la libproj.so.0 por medio de las siguientes instrucciones:

cd /usr/local/pgsql/lib

http://postgis.refractions.net/download/

Anexo B

- - 105

ln –s ../../lib/libgeos.so.1 ln –s ../../lib/libproj.so.0

Respaldos y restauración Para el respaldo de la base de datos se utiliza el comando pg_dump. El uso de este comando se muestra a continuación:

pg_dump nombre de base de datos > archivo de salida

Los archivos de texto creados por el programa pg_dump son intentados leer por el programa psql, la forma general del comando para restaurar una descarga es la siguiente:

psql base de datos < archivo de entrada Archivo de entrada es el que fue usado como archivo de salida por el comando pg_dump. La base de datos base de datos no es creada por este comando, se debe de crear antes de ejecutar el comando psql. Es apropiado analizar cada base de datos para optimizar las estadísticas útiles. Una manera de hacer esto es ejecutar vacuumdb –a –z, para analizar todas las base de datos.

Anexo C

- - 106

Anexo C

Plan de pruebas

Gateway SMS para consultas basadas en localización

Anexo C

- - 107

Introducción El desarrollo de nuevas tecnologías y aplicaciones sobre las redes inalámbricas se ha vuelto un área de gran desarrollo y explotación. La localización de los dispositivos móviles, es un tema de gran interés para los operadores de redes móviles debido a la gran cantidad de aplicaciones y servicios que se pueden ofrecer al usuario basados en la posición. El grado de precisión obtenido en la localización es un factor importante al momento de decidir el tipo de servicios que se pueden ofrecer al usuario. A continuación se presenta el plan de pruebas realizado basado en el Estándar IEEE 829-1998 [STD98] y su ejecución sobre los casos de uso especificados en el plan de pruebas.

Objetivo

Desarrollar una pasarela para el procesamiento de mensajes SMS/MMS identificando si es una consulta dependiente o independiente de la ubicación del cliente móvil, una vez identificado el tipo de consulta ésta se puede procesar de manera local o externa. Todo esto sobre una arquitectura que sea soportada por las tecnologías de los servicios Web.

1. Identificador del plan de pruebas.

SBLAGWSMS SBL – A – GW – SMS – XX – XX

SBLAN2SMS SBL – A – N2SMS – XX – XX

Identificador de caso de prueba. Identificador del grupo de prueba. Servicios Mensajes Cortos. Gateway. Servicios Basados en localización.

Identificador de caso de prueba. Identificador del grupo de prueba. Sistema Web Negocio2SMS. Servicios Basados en localización.

Anexo C

- - 108

2. Introducción.

Este documento define el plan de pruebas que permite la verificación del sistema SBLAGWSMS (Servicios Basados en Localización a Gateway SMS). El software desarrollado consta de la integración de diversas tecnologías tales como: transferencia de mensajería SMS(Short Message Service, Servicio Mensajería Corta), tecnología de posicionamiento a través de GPS (Global Positioning System, Sistema de Posicionamiento Global) y el uso de bases de datos espaciales. El documento se encuentra organizado en orden secuencial según las recomendaciones del estándar IEEE 829-1998 y se definen los apartados de la siguiente manera:

3 Descripción del plan de pruebas: en este apartado se indica lo que se va a probar, los elementos necesarios para las pruebas así como planificación y resolución de posibles incidencias. 4 Casos de pruebas: en este apartado se muestran los distintos grupos de pruebas que se van a realizar. 5 Procedimiento de pruebas: describe cada uno de los grupos de prueba y casos de prueba que se han establecido. 6 Informe de pruebas: en este punto se recogen los resultados de las pruebas realizadas, observaciones y comentarios que surjan en el desarrollo de la prueba.

3. Descripción del plan.

3.1. Características a probar.

El siguiente plan de pruebas contiene la descripción de los casos de prueba definidos con el fin de validar y verificar que el software SBLAGWSMS cumple con los objetivos propuestos para el desarrollo de la tesis sobre aplicaciones de servicios basados en localización utilizando el servicio de mensajería corta.

3.2. Características excluidas de las pruebas.

Los casos de prueba contemplados y desarrollados para este plan no cubren y por tanto no incluyen los siguientes aspectos:

• Consulta georeferenciada/no georeferenciada de la opción camino de un punto de localización hacia el punto destino.

• Peticiones por el puerto o identificador por defecto establecido en las aplicaciones instaladas en los dispositivos móviles para la transferencia de mensajes (en algunos casos).

• Pruebas de estress o concurrencia. • Pruebas físicas o de elementos de hardware.

3.3. Enfoque.

El tipo de pruebas y mediciones que se realizan al software SBLAGWSMS y SBLAN2SMS son principalmente de factibilidad y funcionalidad. Las peticiones y respuestas que se procesan son enfocadas a la tecnología de servicios basados en localización sobre mensajería SMS.

Anexo C

- - 109

Por ésta razón, el servidor debe de responder de manera correcta a las principales preguntas establecidas para aplicaciones SBL tales como: ¿Qué hay cerca de….? ¿Qué clima hay en….? ¿Como llego a…..?. Las peticiones provienen de un dispositivo móvil, por lo cual se interactúa de manera coordinada con la parte cliente del proyecto que establece una API (Application Program Interface) para el desarrollo de aplicaciones de SBL.

3.4. Criterio de éxito o fracaso de caso de prueba.

La decisión de éxito o fracaso de cada uno de los caso de prueba contenidos en el presente documento, será basada en la comparación de los resultados esperados contra los resultados obtenidos. Los resultados esperados están basados en mediciones tomadas mediante un software específico para obtener las distancias lineales entre puntos espaciales con coordenadas geográficas específicas. Se considera que una prueba ha pasado con éxito cuando los resultados obtenidos coincidan con los resultados descritos para cada unos de los casos de prueba. En caso que los resultados obtenidos y descritos no coincidan, se evaluarán las posibles causas y se realizarán las modificaciones necesarias para que el caso de prueba cumpla con éxito la especificación de los resultados descritos.

3.5. Criterio de suspensión y requerimientos de reanudación.

El proceso de pruebas no se suspenderá completamente en ningún momento, solamente se detendrá el tiempo que defina la persona encargada de las pruebas en caso de que surja algún error para evaluar y corregir éste en el menor tiempo posible, haciendo iterativo este proceso hasta que cumpla con los requerimientos del caso de prueba y no se presente ninguna dificultad con el mismo. El requerimiento principal para la reanudación del proceso de pruebas es haber cumplido satisfactoriamente con los requerimientos descritos para el caso de prueba en curso.

3.6. Tareas de pruebas.

Las tareas necesarias para preparar, diseñar y aplicar el plan de pruebas se mencionan en la Tabla 30.

Tabla 30 Tareas descritas para las pruebas. Tarea Tarea Precedente Habilidades especiales Responsabilidad

1.-Preparación del plan de pruebas.

Análisis de sistemas de información geográfica y servicios basados en localización.

Conocimiento sobre la forma de operar de los SBL y los sistemas de información geográfica. Así como la forma de operación de la mensajería SMS. Visión general del Estándar IEEE 829-1998

Autor

Tarea 1.

Conocimiento de la forma de operación del sistema

Anexo C

- - 110

2.-Preparación del diseño de pruebas.

desarrollado así como de los módulos que lo conforman. Conocimiento del Estándar IEEE 829-1998

Autor

3.-Preparación de los casos de prueba.

Tarea 2.

Conocimiento profundo de las características del software desarrollado. Conocimiento de operación de servicios Web. Conocimiento de operación de bases de datos espaciales.

Autor

4.- Aplicación de las pruebas.

Tarea 3.

Conocimiento del ambiente de desarrollo. Conocimiento de las fases de desarrollo, módulos y funcionamiento general del SBLAGWSMS

Autor

5.-Resolver los incidentes de pruebas.

Tarea 4.

Conocimientos del lenguaje de programación Java. Conocimiento del ambiente de desarrollo integrado. Conocimiento de bases de datos relacionales y espaciales. Conocimiento de forma de operación de servicios Web. Conocimiento de API´s de mensajería SMS.

Autor

6.- Evaluación de los resultados.

Tarea 4

Tarea 5

Conocimiento de las preguntas de investigación estipuladas para la tesis. Conocimiento de los objetivos planteados de la tesis.

Autor

3.7 Liberación de las pruebas.

El caso de éxito de las pruebas y su posterior liberación se basan en la coincidencia de dos aspectos: los resultados esperados contra los resultados obtenidos, en este punto dichos resultados se consideran satisfactorios para alcanzar el objetivo planteado para el desarrollo de esta tesis y en consecuencia la liberación de las pruebas.

3.8. Requisitos ambientales.

Dentro de este apartado se especifican todas las herramientas necesarias para el desarrollo del plan de pruebas, elementos necesarios de hardware, software y enlaces para algún caso de prueba, tales requisitos se muestran en la Tabla 31 y Tabla 32.

Anexo C

- - 111

Tabla 31 Requisitos ambientales de hardware. Hardware Características mínimas

PC. de escritorio o Lap Top.

Procesador Pentium 4 2.0Ghz 256 MB RAM. 10 GB en disco duro. Puerto USB o Serial disponible. Sistema operativo XP.

MODEM GSM o en su defecto celular En caso de ser un celular debe contar con la capacidad de funcionar como MODEM GSM. Celulares probados ( Sony Ericsson W300i, Sagem MYX-7 )

Tabla 32 Requisitos ambientales de software. Software Descripción

JSDK SE de java version 1.4 o posterior

Lenguaje de programación.

IDE NetBeans 5.x

Entorno de desarrollo de la aplicación.

API Java Comunicaciones.

API para la comunicación serial a través de Java.

API SMSLib

API para la transferencia y recepción de mensajes SMS.

API APISMSLBS API para el desarrollo de aplicaciones de SBL.

API ant

API para la construcción de aplicaciones.

DBMS Postgresql 8.x Sistema manejador de base de datos.

PostGis Extensión para el manejador PostgreSql para la manipulación de objetos geométricos.

Conector JDBC Postgres API para la conexión a la base de datos a través de Java.

API Axis API del proyecto jakarta para la creación e invocación de servicios Web.

API Logger Necesaria para el funcionamiento del API SMSLib.

Enlace a Internet 128 Kbps mínimo

Necesario para la invocación del servicio

Web (la velocidad es variable recomendado

128 kbps para un buen desempeño).

3.9. Responsabilidades.

Toda la responsabilidad de la administración, diseño, preparación, ejecución, chequeo y resolución de las pruebas recae totalmente en el autor del documento.

3.10. Riesgos y contingencias.

Anexo C

- - 112

El mayor riesgo que se corre en el desarrollo del plan de pruebas está relacionado con el tiempo que se pueda llevar un caso de prueba cuando ocurra un error y en la iteración que se realice para corregirlo. En este aspecto, se comprometen mínimo 2 casos de prueba que validen la funcionalidad del software SBLAGWSMS con respecto a los objetivos de la tesis. Dependiendo del tiempo llevado en cada caso de prueba, se pueden extender a probar las demás características del software. Con respecto a las contingencias que se puedan o no presentar durante el desarrollo de las pruebas, éstas se deben de evaluar y corregir a fin de continuar con el proceso. Las modificaciones se deben de realizar de forma iterativa con el fin de cumplir los objetivos planteados en cada caso de prueba y los objetivos de la tesis.

4. Casos de prueba.

Los distintos casos de prueba contemplados para la validación de la funcionalidad del software SBLAGWSMS, se encuentran divididos por grupos basados en la funcionalidad o características de cada uno de los casos de prueba. En los siguientes apartados se muestran todos los casos de prueba definidos para la validación de los objetivos propuestos para esta tesis.

4.1. Características a probar.

Los distintos casos de prueba definen las características a ser probadas que se muestran en la Tabla 33.

Tabla 33 Características de plan de pruebas. Característica Descripción

Configuración y conexiones

Define los casos de prueba para verificar la correcta configuración de los parámetros a utilizar por el SBLAGWSMS para la conexión con el MODEM GSM y la Base de datos.

Interpretación de la información

Define los casos de prueba para la interpretación de la información proveniente de los dispositivos móviles.

Envío y recepción de la información Define la información recibida y enviada

Persistencia de consultas mayores a 2 resultados

Define la persistencia de los datos para proporcionar la información de cierta categoría dependiendo de la información de estado almacenada en el servidor

Petición de información externa al servidor Validar que se puede obtener y enviar hacia el dispositivo móvil información que no se encuentra almacenada en el servidor.

Registro de y visualización de información georeferenciada.

Define los casos de prueba utilizados para verificar que la información georeferenciada se almacene en la base de datos.

Almacenamiento de información

Se registran en la base de datos todas las peticiones y respuestas que ocurren en el servidor con el objetivo de llevar un historial sobre los SMS recibidos y enviados.

4.2. Pruebas de conexión y configuración.

SBLAGWSMS-001 Pruebas de conexión y configuración

SBLAGWSMS-001-001 Configuración y conexión con el dispositivo móvil. SBLAGWSMS-001-002 Configuración y conexión con la base de datos.

Anexo C

- - 113

SBLAGWSMS-001-003 Operación en modo texto. SBLAGWSMS-001-004 Operación en modo gráfico.

4.3. Pruebas de invocación de información dinámica externa.

SBLAGWSMS-002 Pruebas de invocación de información dinámica externa

SBLAGWSMS-002-001 Invocación de servicio Web para la obtención dinámica de la información a mostrar (simulada). SBLAGWSMS-002-002 Invocación de servicio Web para la obtención dinámica de la información a mostrar (real).

4.4. Almacenamiento y actualización de la información.

SBLAGWSMS-003 Pruebas de almacenamiento de la información SBLAGWSMS-003-001 Almacenamiento de mensajes recibidos. SBLAGWSMS-003-002 Almacenamiento de mensajes enviados.

SBLAGWSMS-003-003 Almacenamiento de datos temporales para persistencia de información demandada. SBLAGWSMS-003-004 Actualización de la información de persistencia sobre datos enviados contra totales.

4.5. Envío y recepción de información.

SBLAGWSMS-004 Envío y recepción de información SBLAGWSMS-004-001 Recepción de mensajes.

SBLAGWSMS-004-002 Procesamiento de consulta georeferenciada por tipo o categoría. SBLSAGWSMS-004-003 Procesamiento de consulta georeferenciada general. SBLAGWSMS-004-004 Procesamiento de consulta no georeferenciada por tipo. SBLAGWSMS-004-005 Consulta georeferenciada/no georeferenciada a puerto especifico. SBLAGWSMS-004-006 Consulta no georeferenciada por colonia y código postal. SBLAGWSMS-004-007 Consulta no georeferenciada por calle y codigo postal.

Anexo D

- - 114

Anexo D

Tramas de mensajes de SMS

API para LBS

Anexo D

- - 115

Se diseñaron 16 tramas para el envío de datos de consulta y respuesta, en la Figura 45 se muestra la trama general del mensaje.

Cabecera Datos Datos Extra Figura 45 Trama mensaje.

En la Figura 46 se muestran los campos contenidos en la cabecera de la trama.

Tipo Número de respuestas Indicador de datos extra

Figura 46 Detalle de cabecera. Los posibles valores del campo Tipo y su descripción se encuentran en la Tabla 34. En la Figura 47 se muestra el detalle del campo Datos Extra de la trama general del mensaje, consiste en uno o mas datos extra que contienen texto

Datos Extra Datos Extra … Figura 47 Datos extras.

Tabla 34 Valores del campo Tipo de la cabecera de la trama.

Valor Tipo Descripción

0 Q_GEO_UBICACION Consulta de sitios de interés cercanos, la ubicación del dispositivo móvil es un punto georeferenciado.

1 Q_CAMINO_GEO_GEO Consulta de un camino donde el inicio y el fin es un punto georeferenciado.

2 Q_CAMINO_GEO_NOGEO Consulta de un camino donde el inicio es un punto georeferenciado y el fin es un punto no georeferenciado.

3 Q_GEO_EVENTO Consulta de Eventos cercanos, la ubicación del dispositivo móvil es un punto georeferenciado.

4 Q_GEO_CLIMA Consulta del clima, la ubicación del dispositivo móvil es un punto georeferenciado.

5 Q_NOGEO_UBICACION Consulta de sitios de interés cercanos, la ubicación del dispositivo móvil es un punto no georeferenciado.

6 Q_CAMINO_NOGEO_GEO Consulta de un camino donde el inicio es un punto no georeferenciado y el fin es un punto georeferenciado.

7 Q_CAMINO_NOGEO_NOGEO Consulta de un camino donde el inicio y el fin es un punto no georeferenciado.

8 Q_NOGEO_EVENTO Consulta de Eventos cercanos, la ubicación del dispositivo móvil es un punto no georeferenciado.

9 Q_NOGEO_CLIMA Consulta del clima, la ubicación del dispositivo móvil es un punto no georeferenciado que indica la ciudad, el estado y el país.

a R_GEO_UBICACION Respuesta con sitios de interés cuya ubicación es punto georeferenciado.

b R_GEO_CAMINO Respuesta de un camino. Es una sucesión de puntos georeferenciados.

c R_GEO_EVENTO Respuesta de Eventos cercanos, la ubicación es un punto georeferenciado

d R_CLIMA Respuesta de clima.

e R_NOGEO_UBICACION Respuesta con sitios de interés cuya ubicación es un punto no georeferenciado.

f R_NOGEO_EVENTO Respuesta de Eventos cercanos, la ubicación es un punto no georeferenciado.

Anexo D

- - 116

En la Figura 48 se muestra el detalle del campo dato, que consiste en uno o más datos disponibles; PoiGeo, PoiNoGeo, Evento, Clima, Consulta Camino. Dato Dato …

Figura 48 Detalle de dato. En la Figura 49 se muestra los campos contenidos en un dato de tipo PoiGeo.

Latitud Longitud Figura 49 Trama PoiGeo.

En la Figura 50 se muestran los campos contenidos en el campo Datos de una consulta georeferenciada de ubicación.

Palabra Distancia PoiGeo Figura 50 Campo dato de trama Q_GEO_UBICACION.

Los posibles valores de los campos Palabra y distancia se muestran en las Tabla 35 y ¡Error! No se encuentra el origen de la referencia. respectivamente. Tabla 35 Valores del campo Palabra.

Tabla 36 Valores del campo Distancia.

En la Figura 51 se muestran los campos contenidos en el campo Datos de una consulta de camino, cuyo inicio y fin están representados por un punto georeferenciado. En la se muestran los campos contenidos en el campo Datos de una consulta

2 PoiGeo Inicial PoiGeo Final

Figura 51 Campo dato de trama Q_CAMINO_GEO_GEO.

Valor Tipo 0 EVENTO 1 CLIMA 2 CAMINO 3 HOTEL 4 BANCO 5 BUS 6 CINE 7 HOSPITAL 8 RESTAURANTE 9 SMERCADO 10 TAXI 11 PASTELERIA 12 MSUPER 13 GYM 14 ESCUELA 15 VIDEO 16 FARMACIA 17 TODOS 18 SIN DEFINIR

Valor Distancia en Metros 1 50 2 100 3 150 4 200 5 250 6 300 7 350 8 400 9 450 10 500 11 1000 12 1500 13 2000 14 2500 15 3000 16 SIN DEFINIR

Anexo D

- - 117

En la Figura 52 se muestran los campos que representan un Punto no georeferenciado. Algunos campos pueden quedar vacíos.

calle Núm Colonia CP Localidad Municipio Edo País

Figura 52 PoiNoGeo. En la Figura 53 se muestran los campos contenidos en el campo Datos de una consulta de camino cuyo inicio está representado por un punto georeferenciado y fin por un punto no georeferenciado.

2 Poigeo Inicial

PoiNogeo final

Figura 53 Campo dato de trama Q_CAMINO_GEO_NOGEO. En la Tabla 37 se listan los posibles valores del campo Tipo Evento.

Tabla 37 Valores del campo tipo Evento. Valor Tipo 0 POLÍTICO 1 SOCIAL 2 CULTURAL 3 RELIGIOSO 4 MUSICAL 5 OTRO 6 SIN DEFINIR 7 TODOS

En la Figura 54 se muestran los campos contenidos en el campo Datos de una consulta georeferenciada de clima.

1 PoiGeo Figura 54 Campo dato de trama Q_GEO_CLIMA.

- - 118

Referencias [CAC05] Caceres Morales, Santos Francisco. Sistema de archivos sobre plataforma de servicios

de Web. Cuernavaca, Morelos. Centro Nacional de Investigación y Desarrollo Tecnológico, Tesis de maestría, Octubre 2005.

[SOL06] Solano Lira, Hilda. Desarrollo de un prototipo de comercio electrónico orientado a dispositivos móviles incorporando el Sistema de Posicionamiento Global. Cuernavaca, Morelos. Centro Nacional de Investigación y Desarrollo Tecnológico, Tesis de maestría en desarrollo, Junio 2006.

[OLI06] Olivares Rojas, Juan Carlos. Gestor de acaparamiento de sitios Web transcodificados para plataforma Pocket PC. Cuernavaca, Morelos. Centro Nacional de Investigación y Desarrollo Tecnológico, Tesis de maestría, Junio 2006.

[COF07] Comisión Federal de Telecomunicaciones. Telefonía móvil penetración [En línea] http://www.cofetel.gob.mx/wb/COFETEL/COFE_Telefonia_Movil_Usuarios_1990__2005 [consulta: 15 septiembre 2007]

[ROD02] Rodríguez Gómez-Stern Miguel. Desarrollo de aplicaciones .NET con Visual C#. México, MC Graw Hill, 2002. 620p.

[KRE01] Kreger Heather.Web Services Conceptual Architecture. IBM Group Software [En línea] <http://www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf> Mayo 2001. [Consulta: 18 noviembre 2006]

[KNU02] Knutson Jim, Kreger Heather. Web Services for J2EE. IBM Public Draft [En línea] <www.ibm.com/webservices/pdf/websvcs-0_3-pd.pdf> Abril 2002 [Consulta: 15 noviembre 2006]

[W3C05] World Wide Web Consortium. Guía breve de servicios Web [En línea] <http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb> [consulta: 10 agosto 2007]

[VEG02] Vega Munguía Elio. Análisis y desarrollo de un sistema gráfico para el Web que muestre información georeferenciada de consultas interactivas. [En línea] < www.labvis.unam.mx/elio/trabajo.pdf > [consulta: 19 septiembre 2006]

[VIA03] Viáncos S. René, Salinas S. Rentato. Prototipo de Servidor de Mapas sobre una Red TCP/IP, Integrando Tecnologías de Internet y de Sistemas de Información Geográfica. Departamento de Ingeniería Eléctrica, USACH, 2003.

[ORT01] [ORTIZ], Gabriel. Tipos de SIG y modelos de datos. Un artículo introductorio para entender las bases de los SIG. [En línea] <http://recursos.gabrielortiz.com/art.asp? Info=012> [consulta: 7 agosto 2006]

[NET07] Netmedia el portal de la comunidad IT. Mensajes MMS deben ser más baratos: Sybase [En línea] <http://netmedia.info/articulo-65-7243-1.html> [consulta: 18 septiembre 2007]

[TAY05] Tayal Mayank. “Location services in the GSM and UMTS networks”. International Conference on Personal Wireless Communications, 2005. ICPWC 2005, IEEE.

[KRI02] Krishnamurthy Nandini. “Using SMS to deliver location-based services”. International Conference on Personal Wireless Communications, 2002. ICPWC 2002, IEEE.

http://www.cofetel.gob.mx/wb/COFETEL/COFE_Telefonia_Movil_Usuarios_1990__2005

- - 119

[ROO03] Roongrasamee Boondao, Vatcharaporn Esichaikul, Nitin Kumar Tripathi. “A Model of Location Based Services for Crime Control”. Web GIS Map Asia Conference 2003, Map Asisa 2003

[BÖH05] Böhm Andreas, Murtz Bernhard, Sommer Carsten.”Locatoin-based ticketing in public transport”. IEEE Conference on Intelligent Transportation Systems, Vienna, Austria, September 13-16, 2005

[VIR01] Virrantaus, K.; Markkula, J.; Garmash, A.; Terziyan, V.; Veijalainen, J.; Katanosov, A.; Tirri, H. “Developing GIS-supported location-based services”. Second International Conference on Web Information Systems Engineering, 2001. WISE 2001, Kioto, Japón.

[XIA07] Xia, Bae, "General Platform of Location based Services in Ubiquitous Environment," International Conference on Multimedia and Ubiquitous Engineering (MUE'07), mue, pp. 791-795, 2007.

[UNE07] Unefon. Servicios Basados en Localización. [En línea] <http://www.unefon.com.mx/evolution/content/html/servicios/localizaion.jsp> [consulta: 5 Septiembre 2007]

[IUS07] Iusacell. Servicio Ubicacel de Iusacell. [En línea] <http://www.iusacell.com.mx> [consulta: 4 septiembre 2007]

[MOV07] Telefónica Movistar. Servicio Localízame de Movistar. [En línea] < http://www.movistar.com.mx/servicios/serv_loca.html> [consulta: 4 septiembre 2007]

[AMA07] Sección Amarilla. Servicio Libertad de Sección Amarilla. [En línea] < http://www.seccionamarilla.com.mx/libertad.aspx> [consulta: 5 septiembre 2007]

[LAB04] Henry-Labordere, Arnaud, Jonack, Vincent. SMS and MMS Interworking in Mobile Networks. Incorporated Artech House, 2004

[GPP06] 3GPP TS 23.040 V6.5.0. Technical realization of the Short Message Service. [En línea] <http://www.arib.or.jp/IMT-2000/V460Nov05/5_Appendix/Rel6/23/23040-650.pdf> [consulta: Septiembre 2007].

[STE02] Stelting Stephen, Maassen Olav. Applied Java Patterns. Sun MicroSystems, United States of America. Pretince Hall Title, 2002. 576 pag.

[ESR98] ESRI. Descripción tecnica de shapefiles de ESRI. [En línea] < http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf> [consulta: 15 noviembre 2006]

[OGC05] Open Geospatial Consortium. Open GIS Location Services. [En línea] < http://portal.opengeospatial.org/files/?artifact_id=3418> [consulta: 18 octubre 2006]

[STE06] Stefan Steiniger, Moritz Neun and Alistair Edwardes. Foundations of Location Based Services. CartouCHe, Lecture Notes on LBS, V. 1.0, 2006.

[SFS99] Open Geospatial Consortium. Simple Feature Specification. [En línea] < http://portal.opengeospatial.org/files/?artifact_id=829> [consulta: 25 octubre 2006]

[STR06] Apache Software Foundation. Proyecto Struts [En línea] < http://struts.apache.org/1.3.8/index.html > [consulta: 5 diciembre 2006]

- - 120

[AGM06] GoogleMaps API. API para la visualización de mapas en páginas Web. [En Línea] < http://www.google.com/apis/maps/> [consulta:20 septiembre 2007]

[POS06] Base de datos open source. [En línea] <http://www.postgresql.org > [consulta: 30 agosto 2007]

[RUI05] Ruiz Guerra, Lirio. API SMS para Servicios Basados en Localización con Sistema de Posicionamiento Global. Cuernavaca, Morelos. Centro Nacional de Investigación y Desarrollo Tecnológico, Tesis de maestría en desarrollo, Junio 2007.

[STD98] IEEE Standard of Software Test Documentation. [En línea] <http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel4/5976/16010/00741968.pdf> [consulta: 15 mayo 2007]

[SMS06] API para el envío y recepción de mensajes SMS. [En línea] <http://www.smslib.org> [consulta: 15 octubre 2007]

Gateway SMS Pull para Servicios Basados en Localización con una Arquitectura de Servicios Web

Technology

Transcript of Gateway SMS Pull para Servicios Basados en Localización con una Arquitectura de Servicios Web