Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles




descargar 387.55 Kb.
títuloResumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles
página14/15
fecha de publicación28.11.2015
tamaño387.55 Kb.
tipoResumen
med.se-todo.com > Documentos > Resumen
1   ...   7   8   9   10   11   12   13   14   15


5.3.2.8 Cadena de eventos

Aunque el catálogo de eventos proporcionado cubre los aspectos básicos de un evento que se desearía seguir, se requiere la posibilidad de diseñar eventos complejos cuya ocurrencia esté dada por una serie de condiciones previas y en muchos casos complejas, dado que el sistema pretende automatizar el análisis de eventos de posición. Se crea entonces el concepto de cadena de eventos.
Cada evento individual puede contener una serie de eventos asociados o ‘eventos hijos’, cuando un evento posee eventos asociados el proceso de evaluación para determinar la ocurrencia del evento varía; en lugar de evaluar la posición entregada por el lector GPS (GPSReader) directamente, se evalúa el evento sólo si alguno de sus eventos asociados ha ocurrido. Visto de otra forma, cuando un evento asociado ocurre le notifica al evento principal que ha ocurrido, y el evento principal evaluará si él también ha ocurrido basado en la lectura GPS (GPSRead) con la cual ocurrió el primer evento.
Un evento asociado puede constituirse a su vez en una subcadena de eventos, donde el evento asociado es el evento principal de esa cadena y tiene eventos asociados frente a cuya ocurrencia se evalúa si se ha producido o no el evento principal.
cadena de eventos.jpg

figura . cadena de eventos
De esta forma, se puede usar la cadena de eventos para generar eventos mas específicos que serán desencadenados en orden, siguiendo el patrón diseñado por la cadena de eventos.
Como un ejemplo práctico de la cadena de eventos se presenta la siguiente situación: Se desea que se genere un evento cuando un usuario salga de la oficina principal y tarde más de media hora en volver.
Para el caso anterior ninguno de los eventos base se ajusta al requerimiento exacto, pero al usar la cadena de eventos podríamos configurar un evento de la siguiente forma dadas las siguientes consideraciones:
- Sea GPSOficina las coordenadas del centro de la oficina y considérese que dentro de un radio de 20 metros de dichas coordenadas el usuario está adentro; si está en un punto fuera de dicho radio, se considerará que está afuera.

figura . estructura de arbol para una cadena de eventos


En esta configuración de ejemplo el evento se evalúa desde los eventos más externos. Esta (en la gráfica) es una estructura de árbol en teoría computacional. La evaluación inicia desde las hojas del árbol; en este caso, si el usuario se encuentra fuera del área se dispara el ‘Evento de Proximidad Sale’, y continuará disparándose mientras el usuario esté por fuera del radio de 20 m previamente establecido. Cada vez que el ‘Evento de Proximidad Sale’ se dispare el ‘Evento de Tiempo’ se evaluará en función del tiempo transcurrido desde la primera vez que se detectó que el usuario salió del área, hasta que se completen 1800 segundos, momento en el que el ‘Evento de Tiempo’ se considera ocurrido. En el caso de que el usuario entre al área antes de que se completen los 1800 segundos (30 minutos) se disparará el ‘Evento de Proximidad Entra’, el cual hará que el ‘Evento de Tiempo’ reinicie su contador, dado que la propiedad ClearEventIndex esta en 1, indicando que cuando el evento con índice 1 ocurra (los índices inician desde 0) reiniciará el contador, dejando el evento listo para ocurrir cuando el usuario vuelva a salir del área.

ejemplo cadena de eventos.jpg

figura . cadena de eventos ejemplo

La cadena de eventos es una herramienta muy útil para dar especificidad a los eventos, poner condiciones y atenuantes a la ocurrencia de los eventos. Es de vital importancia recordar que su funcionamiento inicia en los nodos hojas o eventos asociados y avanza hacia los hacia los nodos padres o evento principal.

5.3.3 REACCIONES
Una reacción, para efectos del sistema, es una tarea que debe ejecutarse al ocurrir un evento asignado. Las reacciones son diseñadas en el servidor (LETSServer) y son ejecutadas por este mismo, su función es automatizar el proceso de responder a un evento, que normalmente podría ser realizado por un operador cuando el evento se detectase. Las reacciones son acciones digitales que interactúan de alguna forma con otros servicios informáticos para ejecutar alguna tarea más compleja, fuera del sistema, aunque pueden usarse para ejecutar acciones también sobre el servidor.
El sistema cuenta con un conjunto de reacciones básicas configurables, estas son:
5.3.3.2 Reacción de Correo Electrónico (EmailReaction)

Esta reacción envía un correo electrónico a los destinatarios configurados en formato HTML y utilizando una plantilla para el título del email y otra para el contenido del mensaje. La utilización de plantillas permite que el mensaje enviado tenga contenido estático o dinámico. Para el correcto funcionamiento de esta reacción debe configurarse correctamente el servidor SMTP en la configuración global del sistema. (Ver 5.3.3.7 Plantillas)

5.3.3.3 Reacción de Petición a Página Web (HttpRequestReaction)

Este tipo de reacción genera una petición a una página web determinada por el parámetro URL de la reacción; la petición puede ser por GET o POST y los parámetros que han de usarse son obtenidos del evento ocurrido y pueden ser estáticos o dinámicos; el uso de parámetros dinámicos se definirá en la sección 5.3.3.7.
5.3.3.4 Reacción de mensaje (MessageReaction)

Envía por medio del sistema un mensaje a la aplicación cliente (LETSClient), la cual lo mostrará en pantalla y alertará al usuario. El mensaje puede definirse para varios usuarios, configurados en la lista de destinatarios, y el contenido del mensaje puede ser estático o dinámico de acuerdo a la plantilla que se use. (Ver 5.3.3.7 Plantillas)
5.3.3.5 Reacción de Mensaje de Texto (SMSReaction)

Esta reacción hace uso de un dispositivo celular conectado físicamente en el servidor en un puerto serial de comunicación (COM). La aplicación envía por medio de este dispositivo, y mediante comandos AT en formato PDU, el mensaje a los números telefónicos configurados. El mensaje puede ser estático o dinámico según la plantilla usada. Para el uso de esta reacción debe asegurarse la correcta comunicación entre el equipo usado como servidor y el dispositivo celular, y la posibilidad del dispositivo celular para enviar mensajes de texto (disponibilidad de red, saldo, batería etc.).
5.3.3.6 Reacción a Servicio Web (WebServiceReaction)

Ofrece la posibilidad de notificar a un servicio web (WebService). Para esto debe especificarse la URL del servicio web así como el nombre del método que se usara, y los parámetros que se enviarán. Los parámetros pueden ser estáticos o dinámicos según la plantilla utilizada. Para este tipo de reacción hay que asegurarse de que el directorio temporal en la configuración general del sistema esté disponible en lectura y escritura, y que los datos del servicio web estén correctos. Se prefiere el uso de parámetros sencillos (primitivos).

5.3.3.7 Plantillas y Transformaciones para contenido Dinamico

Debido a la naturaleza diversa de los eventos, y dado que el sistema pretende comunicarse por diversos medios con otros sistemas, se presenta una alternativa en cuanto al contenido de los datos de las reacciones. De esta forma, se crea un sistema de plantillas para transformar el contenido de acuerdo a los datos que vengan en el evento ocurrido (OcurredGPSEvent).
5.3.3.7.1 Plantilla Básica: Dentro de las propiedades de las reacciones en las que se permite contenido dinámico, las cuales son de tipo texto (String), el sistema revisará y tomará como plantilla cualquier campo que se encuentre entre caracteres ‘#event:#’‘ donde identificador es el nombre del campo propiedad del objeto que se desea reemplazar en el texto, partiendo desde el objeto evento ocurrido (OcurredGPSEvent) y usando el caracter punto ‘.’ como delimitador de objeto-propiedad. Por ejemplo, si en una reacción de email se desea en el titulo enviar el nombre del usuario que realizó el evento, se debe poner en el campo Subject el texto “Reacción generada por el usuario #event:user.name#”, en este ejemplo el sistema reemplazara #event:user.name” por la propiedad name del objeto user del evento ocurrido. Para ver los posibles identificadores hay que revisar el diagrama de clases del objeto OcurredGPSEvent. (Ver Anexos)
5.3.3.7.2 Plantilla Avanzada: Las plantillas avanzadas hacen uso de las transformaciones sobre XML, las transformaciones XSL. El evento ocurrido es serializado en XML y se le aplica la transformación XSL que el usuario escoja; esto, a diferencia de la plantilla básica, permite acceder por los datos de los eventos encadenados y aplicar plantillas a los mismos para comunicar sus datos, obteniendo mayor control sobre la transformación de contenido que se desee aplicar.
Las reacciones que soportan transformaciones XSL tienen una plantilla base para XSL la cual proporciona un ejemplo de como hacer las transformaciones.
5.4 IMPLEMENTACIÓN
Durante el desarrollo de la aplicación del presente proyecto y por la misma metodología de desarrollo de software utilizada, el sistema se construyo por fases obteniendo prototipos que fueron implementando las funciones requeridas. Cada prototipo busca demostrar la posibilidad de la función más crítica que el sistema necesita para su funcionamiento y su progreso hacia la siguiente fase.
A continuación se detallan las características y alcances de cada uno de los prototipos.
5.4.1 PRIMER PROTOTIPO
La implementación de este primer prototipo abarca 2 funciones fundamentales: la obtención de la posición del dispositivo, y la comunicación con el servidor.
En la aplicación móvil (LETSCLient) se crea la clase GPSReader la cual es la responsable de la comunicación con el GPS del dispositivo por medio del objeto LocationProvider. Esta clase gestiona la obtención de la posición a intervalos regulares de tiempo y notifica esta posición a los objetos que implementen la interfaz IGPSReadListener que se encuentren suscritos al objeto GPSReader. La posición descrita se representa mediante un objeto GPSRead que contiene la información de latitud y longitud de la lectura, así como de la fecha y hora en que fue tomada la lectura. Se crea también la clase CommandClient que es encargada de la creación, envío y serialización de los comandos que hayan de ejecutarse en el servidor, así como de recibir las respuestas y notificarlas; un objeto CommandClient envía comandos, los cuales están representados por la clase wCommand. Los parámetros que reciben los comandos deben ser variables primitivas u objetos que implementen la interfaz ISerializable. Cuando el servidor envía la respuesta del comando, el CommandClient notifica a los objetos que implementen la interfaz ICommandListener que hayan sido registrados en el.
En un formulario básico se muestran la latitud, longitud y estado del GPS obtenidos por el GPSReader. El formulario incluye opciones para iniciar las lecturas y detenerlas; también una opción para enviar la posición actual al servidor en forma de un comando y mostrar la respuesta en pantalla.


p1 - formulario.jpg

figura . FORMULARIO BÁSICO DEL CLIENTE MÓVIL

En el servidor se crea la aplicación LETSServer. Se configura el IHttpHandler para recibir los comandos del cliente; posteriormente, se crea el objeto CommandServer el cual es el encargado de des-serializar los comandos e invocar al objeto ICommandListener que se encuentra registrado en él, y que corresponde con el texto de comando que viene en el comando del cliente (Command). Se crea un ICommandListener de prueba para recibir la lectura GPS (GPSRead) del cliente y devolver el texto, “Lectura registrada con éxito”.
p1 - envio de posicion.jpg

figura . RESPUESTA AL ENVÍO DE POSICIÓN


5.4.2 SEGUNDO PROTOTIPO
El segundo prototipo demuestra la posibilidad de la utilización de la API de Google Maps dentro del sistema, más específicamente en el área del monitor (LETSMonitor), y la utilización del almacenamiento de datos por parte del servidor y monitor.
La API de Google Maps para visualizar y manipular mapas está escrita enteramente en JavaScript, por lo que para integrarla de una forma coherente dentro de la filosofía de construcción de sitios web de ASP.NET se contruyeron controles de ASP.NET (ScriptControl) para crear una interfaz entre el código de ASP.NET y Javascript. De esta forma es más sencillo el desarrollo y reutilización de estos componentes en futuros proyectos. Las librerías OpenSource con controles para Google Maps disponibles a la fecha de realización del proyecto no contemplaban el uso de la versión 3 de Google Maps, por lo que se vio la necesidad y oportunidad de crear controles personalizados.
Estos controles permiten visualizar Mapas (MapControl), dibujar superposiciones (Polígonos, Polilíneas, Marcadores, Imagenes, Círculo) en el mapa (MapDrawControl) y seleccionar elementos sobre el mapa (MapSelectionControl). Tambien permiten reaccionar ante eventos como click y drag&drop sobre el mapa o superposiciones.
p2 - controles dibujo mapa.jpg

figura . CONTROLES DE DIBUJO DEL MAPA
p2 - contoles de mapa de seleccion.jpg

figura . CONTROLES DE SELECCIÓN DEL MAPA
Se crean tanto para el servidor (LETSServer) y monitor (LETSMonitor) objetos para manejar el acceso a datos (DataBaseSource) y se establece un modelo para los objetos que vendrán a representar la lógica de funcionamiento del sistema (Entity, EntityProvider, EntityManager).
Se añade la funcionalidad de almacenar la posición (GPSRead) al Comando de Servidor (ICommandListener) que se creo en el prototipo anterior, la cual después es recuperada por una página del sitio monitor (LETSMonitor), y mostrada por medio del uso de los controles previamente creados.
5.4.3 TERCER PROTOTIPO
En este prototipo se crean los objetos que representan los eventos (GPSEvent) tanto en la aplicación cliente (LETSClient) como en la aplicación servidor (LETSServer), los cuales incluyen los algoritmos necesarios para evaluar si el evento ha ocurrido, y la notificación de esta ocurrencia.
Inicialmente se crea la definición base de evento (GPSEvent), el cual permite registrar una serie de objetos que serán notificados cuando el evento ocurra. Estos objetos deberán implementar la interfaz IGPSEventListener para ser notificados. Cada evento posee un conjunto de eventos hijos (GPSEventCollection), esto con el fin de representar la cadena de eventos que debe ejecutarse antes de ocurrir el evento. Para notificar al evento de cuando uno de sus eventos asociados ha ocurrido cada evento implementa para sí mismo la interfaz IGPSEventListener, y para poder evaluar si el cambio de posición hace que el evento ocurra, cada evento también implementa la interfaz IGPSReadListener de esta forma obtiene la posición por medio de un GPSReader.
Entonces, de acuerdo al diseño, se implementan los eventos GPSProximityEvent, GPSAreaEvent, GPSDistanceEvent, GPSSpeedEvent, GPSTimeEvent, GPSDateTimeEvent y GPSCounterEvent, así como los argumentos de cada evento (GPSEventArgs), que son los objetos que almacenan la información del evento cuando ocurre.
Adicionalmente, los eventos deben ser deserializados dado que provienen del servidor, y los argumentos de evento deben ser serializados para enviarlos al servidor como notificación de que un evento ha ocurrido. Por esto tanto los eventos (GPSEvent) y los argumentos de evento (GPSEventArgs) implementan la interfaz ISerializable.

p3 - carga de eventos.jpg

figura . EVENTOS CARGADOS EN EL MÓVIL DESDE EL SERVIDOR

Se crea aquí un comando de servidor, el comando RequestConfigurationCommand, que trasmitirá los eventos configurados, y otro comando ReportEvent que almacenará los argumentos de evento que reciba como reporte de la ocurrencia de un evento.
Para el almacenamiento de los eventos y argumentos se crean los objetos AssignedGPSEvent y OcurredGPSEvent con sus respectivos objetos en el modelo de negocio de la aplicación (AssignedGPSEventProvider, AssignedGPSEventManager, OcurredGPSEventProvider, OcurredGPSEventManager).
Finalmente, se elabora una opción en la aplicación cliente para visualizar los efectos de la evaluación de cada evento. Para esto se crea una superficie de dibujo bajo coordenadas GPS usando la clase Canvas de J2ME, esto con el fin de verificar la correcta evaluación de cada evento.
p3 - menu nuevas funciones.jpg

figura . MENÚ INICIAL DEL CLIENTE MÓVIL

p3 - visor de eventos.jpg

figura . VISOR DE EVENTOS

p3 - evento de distancia1.jpg

figura . REPRESENTACIÓN VISUAL DEL EVENTO DE DISTANCIA

p3 - evento proximidad1.jpg

figura . REPRESENTACIÓN VISUAL DEL EVENTO DE PROXIMIDAD
1   ...   7   8   9   10   11   12   13   14   15

similar:

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconResumen el presente trabajo trata del diseño, construcción y caracterización...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconProtocolo de calidad para la implementación de herramientas de la...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconResumen El presente avance constituye el resumen de un artículo a...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles icon2011 diseño y construccion de la herramienta miosma para el posicionamiento...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconResumen general del software

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconDiseño e implementación de objetos virtuales de aprendizaje para...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles icon"diseño e implementación de un aula virtual como apoyo a las estrategias...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles icon"diseño e implementación de un aula virtual como apoyo a las estrategias...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles icon"diseño e implementación de un aula virtual como apoyo a las estrategias...

Resumen título: diseñO, análisis e implementación de un prototipo de herramienta de software orientada a geolocalización y seguimiento por eventos de terminales móviles iconResumen se realizo el proceso de cromatografía plana en papel utilizando...


Medicina



Todos los derechos reservados. Copyright © 2015
contactos
med.se-todo.com