En esta secci´on aparecen los resultados obtenidos con el prototipo descrito en la secci´on anterior. Las figuras 5.5, 5.8 muestran la aplicaci´on residente en el dispositivo m´ovil que utiliza el MD-API para comunicarse con el resto de los componentes de la arquitectura de la figura 4.1. Se cubren los siguientes casos dentro de la experimentaci´on:
• El dispositivo m´ovil entra en la zona donde se provee el servicio de electrocardio- grama y utiliza todas las funcionalidades prove´ıdas por el servicio.
• El dispositivo m´ovil entra en la zona donde se ofrece el servicio de historial del paciente y utiliza todas las funcionalidades prove´ıdas por el servicio.
• El dispositivo m´ovil entra en una zona donde no se ofrece ning´un servicio y realiza una b´usqueda de servicios.
• El dispositivo m´ovil se encontraba accesando a un servicio y sale del ´area donde se provee dicho servicio.
El experimento inicia cuando la doctora Hellen, nuestra usuaria se encuentra real- izando su ronda y visitando a los pacientes. Como apenas va iniciando su turno Hellen accede a la aplicaci´on del dispositivo m´ovil al entrar en la habitaci´on de unos pacientes y se autentifica (figura 5.5(a)). En las figuras 5.5(b), 5.5(c) y 5.5(d) se muestra el sigu- iente paso llevado a cabo por la aplicaci´on en el cual se obtenine la ubicaci´on actual de Hellen(5.5(b)) y se establece comunicaci´on con el servidor Proxy con el prop´osito de obtener los servicios disponibles de la zona.
El servidor obtiene los servicios disponibles en esa habitaci´on (figura5.6(a)). Hellen desea verificar el estado de Jane Smith y al seleccionarla de la lista, aparecen las op- ciones disponibles (figura 5.6(b)). Al seleccionar la opci´on de View Information, la aplicaci´on interactua con el servidor Proxy y Hellen es capaz de ver el historial m´edico
(a) Proceso de autentificaci´on (b) Conect´andose a la red
(c) Ubicaci´on obtenida (d) Conect´andose con el Proxy
como se puede apreciar en la figura 5.6(c). Hellen examina a la paciente y decide que es necesario administrarle un nuevo medicamento para aliviar un malestar. Para ello re- gresa al men´u de la figura 5.6(b) y selecciona la opci´on de Modify Information. Hellen agrega informaci´on referente a la nueva medicaci´on de la paciente (figura 5.6(d)) y guarda los cambios. Despu´es de los cambios el historial m´edico de Jane Smith se puede apreciar en la figura 5.7(a).
A continuaci´on Hellen abandona la habitaci´on. Mientras camina decide actualizar los servicios y selecciona la opci´on de Update (figura 5.7(b)). Dado que Hellen se en- cuentra en un ´area en la cual no existen servicios disponibles, la aplicaci´on muestra el mensaje de la figura 5.7(c). Hellen se percata de este mensaje y camina hacia la habitaci´on el la cual se realizan los Electrocardiogramas (ECG). Una vez que entra en la habitaci´on, selecciona la opci´on Update (figura 5.7(c)).
Dado que Hellen se encuentra dentro de la zona donde se ofrece el servicio de ECG, el servidor le permite visualizar este servicio (figura 5.8(a)). Hellen selecciona el servicio y a continuaci´on aparecen las opciones disponibles (figura 5.8(b)). Ahora Hellen selec- ciona la opci´on View information y prosigue a aplicar el criterio de b´usqueda (figura 5.8(c)), es decir, el nombre del paciente al cual se le realiz´o el ECG. Los resultados de la b´usqueda muestran la informaci´on del ECG de Kerrie Smith (figura 5.8(d)), como se especific´o en el criterio de b´usqueda citado.
Mientras Hellen revisa la informaci´on de ECG, una enfermera lleva una paciente la cual requiere de un ECG. Hellen selecciona la opci´on Add new Information (figu- ra 5.8(b)) y a continuaci´on empieza a llenar la orden que utilizar´a la enfermera para realizar el ECG (figura 4d). La orden queda almacenada y puede ser consultada para futuras referencias.
Cuando Hellen termina la orden del ECG abandona la habitaci´on. Justo en ese momento decide que desea verificar un par´ametro de la orden de ECG. Como a´un tiene accesible el men´u de ECG selecciona la opci´on de View Information (figura 5.8(b)) y proporciona el nombre del paciente. Debido a que ella ya no se encuentra dentro del ´
area de ofrecimiento del servicio, la aplicaci´on regresa el mensaje de la figura 5.9(a). Si ella hubiera hecho esta misma operaci´on dentro de la operaci´on habr´ıa obtenido el resultado de la figura 5.9(b)
(a) Servicio de historial del paciente (b) Opciones del servicio de historial
(c) Historial de Jane Smith (d) Modificaci´on del historial de Jane Smith
(a) Historial de Jane Smith actual- izado
(b) Actualizar servicios
(c) No servicios en el ´area (d) Creaci´on de una ECG
(a) Servicio de ECG (b) Opciones del servicio de ECG
(c) B´usqueda del ECG de Kerrie Smith
(d) Resultados de la b´usqueda
(a) Servicio fuera de ´area (b) ECG del paciente
Cap´ıtulo 6
Conclusiones
Los servicios dependientes de la localizaci´on para dispositivos m´oviles(MLDS) con- tin´uan siendo un ´area muy nueva y por tal motivo no se han explotado al m´aximo ni se han establecido concretamente los requerimientos que debe satisfacer. El objetivo prin- cipal de esta tesis fue definir un modelo gen´erico que pueda ser utilizado en cualquier implementaci´on de MLDS. A fin de proveer verdaderamente un modelo gen´erico se hi- zo un an´alisis para determinar los requerimientos t´ecnicos b´asicos de un MLDS. Estos requerimientos t´ecnicos se basan en espectos de comunicaci´on entre la terminal m´ovil y el servicio. Esta comunicaci´on incluye la b´usqueda de servicios y el acceso a los mismos. Dos aspectos importantes tomados en consideraci´on fueron el incremento de tr´afico que estos servicios pueden significar ya que en un futuro la cantidad de usuarios que ha- gan uso de ellos superar´a a la cantidad de usuarios que utilizan Internet. Esto se debe a la facilidad de una persona para adquirir un dispositivo m´ovil. El segundo aspecto importante consiste en reducir en lo posible el procesamiento que debe ser llevado a cabo en el dispositivo m´ovil. Como se mencion´o en cap´ıtulos anteriores, los disposivos m´oviles poseen bajas capacidades de almacenamiento y de procesamiento. Un aspecto hasta hace poco considerado innecesario era la privacidad de la informaci´on prove´ıda por los servicios. Inicialmente los MLDS fueron concebidos principalmente para proveer informaci´on masivamente. Posteriormente surgi´o el esquema de limitar el acceso a la informaci´on prove´ıda por estos servicios. Finalmente se se˜nala la necesidad de asegurar que la informaci´on sea privada dada su confidencialidad (en esta tesis se propone un caso de historial de pacientes en un hospital, donde la privacidad de la informaci´on es un factor clave).
Posterior a la definici´on de requerimientos t´ecnicos se adapt´o un modelo distribui- do (que cumple con las caracter´ısiticas de expandibilidad y escalabilidad) que cumpli- era con dichos requerimientos. Uno de los objectivos espec´ıficos propuestos consiste de proveer la funcionalidad de a˜nadir o modificar la informaci´on de un servicio. Esta fun- cionalidad se agreg´o en la arquitectura. Para corroborar que este modelo fuera adecuado se realiz´o un prototipo cuyo escenario fue un hospital. En este prototipo se crearon 2 servicios diferentes. Cada servicio posee sem´antica y funciones diferentes. Con esto se
prob´o que la arquitectura basada en los requerimientos t´ecnicos ya mencionados puede ser utilizada sin importar la naturaleza del servicio. Cabe mencionar que en esta tesis se define un modelo flexible que puede ser adaptable, es decir se proveen las operaciones que pueden ser llevadas a cabo dentro de la arquitectura y entre sus componentes, pero no se establecen los mecanismos utilizados para llevarlos a cabo.
Se puede concluir que los MLDS pueden ser bbstra´ıdos como una arquitectura de 3 capas. En este caso, la comunicaci´on con los servicios y el acceso a los mismos se lleva a cabo en la capa intermedia repartida entre los diferentes componentes de la arquitectura. Con el prop´osito de separar la capa de presentaci´on de la capa in- termedia, se propuso en esta tesis el uso de un API de acceso a servicios. Dicho API permite a una aplicaci´on acceder a los servicios de manera transparente ocultando de- talles del acceso a los servicios. El API propuesto fue programado en J2ME ya que se considera que es una tecnolog´ıa con un gran impacto en las aplicaciones m´oviles. Este API ofrece las operaciones b´asicas necesarias para acceder la informaci´on de un servicio. Por lo tanto se puede afirmar que la hip´otesis propuesta es verdadera ya que se puede utilizar el modelo propuesto para proveer diferentes tipos de aplicaciones m´oviles dependientes de la localizaci´on.
6.1.
Trabajo futuro
El trabajo referente a los requerimientos de los MLDS se encuentra a´un en una fase temprana. Existen una gran variedad de aspectos a considerar as´ı como m´etricas que deben ser definidas para validar la viabilidad y ´exito de dichos requerimientos. Un importante ´area de oportunidad para MLDS es la definici´on de requerimientos de diferentes ´areas.
El modelo propuesto no cubre a fondo aspectos de seguridad avanzados. Una investigaci´on futura puede profundizar y extender este modelo a fin de enforzar la seguridad de la informaci´on.
Ap´endice A
Definici´on del MD-API
El MD-API se divide sus funciones en tres grupos. El primer grupo corresponde a la interacci´on a trav´es de mensajes con el servicio. Mediante esta comunicaci´on el cliente obtiene una respuesta del servicio encapsulada en un objeto de tipo MD-API. Dentro del grupo I se encuentran adem´as, la funci´on para establecer una sesi´on con el servidor Proxy. El segundo grupo ofrece funciones que permiten configurar la interacci´on con el servicio. La funcionalidad ofrecida en el tercer grupo se centra en obtener la informaci´on encapsulada en el objeto MD-API.
A.1.
Grupo I
Este grupo ofrece principalmente funciones de configuraci´on que deben usarse
previamenteal establecimiento de cualquier comunicaci´on con el servidor Proxy. Cada vez que se desee solicitar un tipo de operaci´on al servidor Proxy, se deben utilizar las funciones definidas en este grupo.
publicMD-API()
Construye un objecto MD-API e inicializa sus estructuras internas.
public void setProxy( String url )
Permite establecer la direcci´on IP del servidor Proxy. Por ejemplo http://10.17.90.81:80
Par´ametros
url. La direcci´on en la que se encuentra localizado el servidor Proxy.
Almacena de forma temporal los par´ametros de servicio que se van a solicitar al servidor Proxy. Permite establecer todos los par´ametros en una sola operaci´on.
Par´ametros
parametersService. Arreglo con los nombres de los par´ametros que se desean solicitar.
public void setRequestParameter( String parametersService )
Almacena de forma temporal un par´ametro de servicio que se van a solicitar al servidor Proxy. Permite establecer un par´ametro. Puede ser llamada consecutivamente si se desean establecer varios par´ametros.
Par´ametros
parametersService. Nombres del par´ametro que se desea solicitar.
public void setFilter( String parameter, String cond )
Almacena una condici´on que es enviada cuando se hace la solicitud de un servicio. El filtro corresponde a un par´ametro el cual debe poseer un determinado valor.
Par´ametros
parameter. El nombre del par´ametro. cond. El valor asociado a ese par´ametro.
public void setParameter( String parameterName, String parameterValue )
Asocia a un par´ametro un valor espec´ıfico. Define las parejas par´ametro=valor utilizadas para actualizar la informaci´on de un servicio.
Par´ametros
parameterName. Nombre del par´ametro. parameterValue. Valor del par´ametro.
public intremoveParameter( String parameterName, String ParameterValue ) Remueve el valor asociado a un par´ametro. El valor debe coincidir con el almace- nado.
Par´ametros
parameterName. Nombre del par´ametro. parameterValue. Valor del par´ametro.
Regresa
C´odigo del resultado de la operaci´on. 0 Par´ametro removido exitosamente.
-1 Par´ametro o valor asociado a el no encontrado.
public void setLocation( String location )
Permite establecer las coordenadas actuales del dispositivo m´ovil as´ı como el c´odi- go de la tecnolog´ıa de posicionamiento utilizada.
Par´ametros
location. Ubicaci´on codificada como un String. El string debe contener 3 datos sep- arados por un espacio. Por ejemplo ”2 4 1”donde 2 es la coordenada en x, 4 es la coordenada en y, 1 el c´odigo de la tecnolog´ıa de posicionamiento utilizada.
public void setLocation( int x, int y, String ptCode)
Permite establecer las coordenadas actuales del dispositivo m´ovil as´ı como el c´odi- go de la tecnolog´ıa de posicionamiento utilizada.
Par´ametros
x. Coordenada en x. y. Coodernada en y.
ptCode. C´odigo de la tecnolog´ıa de posicionamiento utilizada para ubicar al dispositivo.
public void setKey( String key )
Permite establecer la clave privada utilizada para cifrar la informaci´on.
Par´ametros
key. String que contiene la llave privada .