INGENIER DE TELECOMUNICACION IA

PROYECTO FIN DE CARRERA

BLUEPILLS: ENV DE P IO ILDORAS DE BLUETOOTH DOCENTES A TRAVES

Autor: Jorge Beca Baulenas Tutor: Mario Muoz Organero n Legans, 6 de julio de 2011 e

Agradecimientos
A mis amigos, por instarme a recorrer los ultimos metros de este largo viaje. A mis hermanos, mis t y mi prima, por acompaarme en el trayecto. as n A mi tutor Mario, por allanarme el camino, gracias a su enorme amabilidad. Y a mis padres, por todo.

Resumen
El objeto del presente proyecto es el estudio de un sistema, dentro del ambito docente, que permita la transmisin de cheros desde un ordenador a un conjunto o de terminales mviles cercanos. o Utilizando la librer BlueCove para Bluetooth, se ha implementado una soa lucin software al problema, desarrollada en el lenguaje de programacin Java. o o Aprovechando la versatilidad de Java en el desarrollo de aplicaciones grcas mula tiplataforma, se ha buscado una solucin que, adems de satisfacer los requisitos o a del problema, facilite su uso. A pesar de presentar una velocidad de transmisin inferior a otros sistemas o de comunicacin inalmbrica, Bluetooth posee una serie de caracter o a sticas que justican su uso en el problema propuesto: no requiere conguraciones de red previas y ofrece mecanismos de alto nivel para el intercambio rpido de cheros. a

Palabras clave: Bluetooth, OBEX, Java, BlueCove, P ldoras docentes.

Abstract
The purpose of this project is the study of a system, within the teaching eld, that allows the transmission of les from one computer to a set of mobile terminals nearby. Using Bluetooth BlueCove library, we have implemented a software solution to the problem, developed in the Java programming language. Taking advantage of the versatility of Java in developing cross-platform graphical applications, we have sought a solution that not only satises the requirements of the problem, but eases to use. In spite of having a transmission rate lower than other wireless communication systems, Bluetooth has a number of features that justify its use in the proposed problem: it doesnt require network pre-congurations and provides high-level mechanisms for the rapid exchange of les.

Keywords: Bluetooth, OBEX, Java, BlueCove, Teaching pills.

 Indice general
1. Introduccin y objetivos o 1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Fases del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del arte 2.1. La tecnolog Bluetooth . . . . . . . . . . . . . . . . . . . . . . . a 2.1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Caracter sticas radio . . . . . . . . . . . . . . . . . . . . . 2.1.3. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4. Arquitectura de la pila Bluetooth . . . . . . . . . . . . . . 2.1.5. Perles Bluetooth . . . . . . . . . . . . . . . . . . . . . . . 2.1.6. Seguridad en Bluetooth . . . . . . . . . . . . . . . . . . . 11 11 12 13 14 15 15 15 16 18 19 21 22 24 24 25 27 27 27 29 30

2.2. OBEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.2.2. OBEX Object Push . . . . . . . . . . . . . . . . . . . . . . 2.3. Java y Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. El estndar JSR-82 . . . . . . . . . . . . . . . . . . . . . . a 2.3.2. BlueCove . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. El paquete javax.bluetooth de Java . . . . . . . . . . . . . 2.3.4. El paquete javax.obex de Java . . . . . . . . . . . . . . . . 7

INDICE GENERAL 2.4. Java GUI: Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3. Hilos en Swing . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Java Servlets y JSP . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2. Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . 31 31 32 34 36 36 37 39 39 40 43 44 44 45 46 49 49 52 52 54 57 61 64 65 68 70 70

3. Descripcin general del sistema o 3.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . 3.2. Estructura general del sistema . . . . . . . . . . . . . . . . . . . . 3.3. Funcionamiento general del sistema . . . . . . . . . . . . . . . . . 3.4. Modelo de cheros . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Fichero de usuarios . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Fichero de grupos . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. Fichero de sesiones . . . . . . . . . . . . . . . . . . . . . . 4. Desarrollo de la aplicacin Bluepills o 4.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Mdulo Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.2.1. El modelo cliente-servidor Bluetooth . . . . . . . . . . . . 4.2.2. Comunicacin cliente-servidor OBEX . . . . . . . . . . . . o 4.2.3. Sesin de env de cheros . . . . . . . . . . . . . . . . . . o o 4.2.4. Estructura de clases del Mdulo Bluetooth . . . . . . . . . o 4.3. Mdulo Grco . . . . . . . . . . . . . . . . . . . . . . . . . . . . o a 4.3.1. Funcionalidad de la GUI . . . . . . . . . . . . . . . . . . . 4.3.2. Estructura de clases del Mdulo Grco . . . . . . . . . . o a 4.4. Mdulo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4.1. Estructura de clases del Mdulo de Datos . . . . . . . . . o

 INDICE GENERAL 5. Desarrollo de la aplicacin Web Bluepills o 5.1. Modelo de la aplicacin Web . . . . . . . . . . . . . . . . . . . . . o 5.2. Funcionalidad de la aplicacin Web . . . . . . . . . . . . . . . . . o 5.2.1. Perl de Usuario . . . . . . . . . . . . . . . . . . . . . . . 5.2.2. Perl de Administrador . . . . . . . . . . . . . . . . . . .

9 71 71 73 74 75 76 76 78 81 81 84 89 89 92 93 95 95 95 96 96 98 101

5.3. Estructura de la aplicacin Web . . . . . . . . . . . . . . . . . . . o 5.3.1. Diseo de servlets . . . . . . . . . . . . . . . . . . . . . . . n 5.3.2. Diseo de JSPs . . . . . . . . . . . . . . . . . . . . . . . . n 6. Pruebas 6.1. Bater de pruebas de la Aplicacin Web Bluepills . . . . . . . . . a o 6.2. Bater de pruebas de la Aplicacin Bluepills . . . . . . . . . . . . a o 7. Conclusiones y trabajos futuros 7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. L neas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . A. Presupuesto B. Aplicacin Bluepills: Instalacin y Uso o o B.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2. Manual de Instalacin . . . . . . . . . . . . . . . . . . . . . . . . o B.3. Manual de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3.1. Inicio de la aplicacin . . . . . . . . . . . . . . . . . . . . . o B.3.2. Sesiones en Bluepills . . . . . . . . . . . . . . . . . . . . . C. Aplicacin Web: Instalacin y Uso o o

C.1. Manual de Instalacin de Apache Tomcat . . . . . . . . . . . . . . 101 o C.2. Manual de Conguracin de Apache Tomcat . . . . . . . . . . . . 102 o C.2.1. Estructura de directorios de Tomcat . . . . . . . . . . . . 102

C.2.2. Descriptor de despliegue . . . . . . . . . . . . . . . . . . . 102

10

INDICE GENERAL C.3. Manual de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 C.3.1. Acceso a la aplicacin Web . . . . . . . . . . . . . . . . . . 103 o C.3.2. Perl de Usuario . . . . . . . . . . . . . . . . . . . . . . . 103 C.3.3. Perl de Administrador . . . . . . . . . . . . . . . . . . . 104

Cap tulo 1 Introduccin y objetivos o

1.1. Motivacin o

Hoy en d ms del 90 % de los terminales mviles del mercado incorporan a, a o la tecnolog Bluetooth. Adems, existen numerosas aplicaciones y servicios que a a permiten comunicar el dispositivo mvil con otros dispositivos Bluetooth para o el env de voz o datos. Estas comunicaciones Bluetooth pueden darse no slo o o entre dispositivos mviles, sino tambin entre muchos otros dispositivos: mandos o e inalmbricos, ordenadores, impresoras... a Por otro lado, la funcionalidad que ofrecen los terminales mviles es cada d o a mayor, por lo que empieza a ser habitual que los usuarios utilicen sus telfonos e mviles para nuevos usos, adems de para la comunicacin de voz. Algunos de o a o estos nuevos usos son: reproductor de msica, cmara de fotos, agenda persou a nal, almacenamiento de datos... Lo que aproxima a los mviles cada vez ms a o a los ordenadores personales, con la ventaja de ser porttiles en todo momento. a Adems, los usuarios pueden comunicar sus mviles y ordenadores personales a o para sincronizar agendas o transferir archivos. Esta comunicacin puede realio zarse mediante cables o mediante comunicacin inalmbrica, ya sea a travs de o a e infrarrojos, Bluetooth o incluso v Wi-Fi. a En entornos docentes o en aqullos donde se imparte una charla o curso, el uso e de material multimedia constituye hoy una prctica fundamental e indispensable. a Este material, dividido en pequeos cheros o p n ldoras docentes (presentaciones, apuntes, v deos de corta duracin, ejercicios...) no slo refuerza la prctica o o a docente, sino que permite que los asistentes puedan seguir utilizndolos una vez a concluida la sesin, ya sea para repasar, aanzar o ampliar temas y conceptos. o Existen muchas maneras de transmitir estas p ldoras docentes a los asistentes, 11

12

CAP ITULO 1. INTRODUCCION Y OBJETIVOS

siendo el correo electrnico la ms habitual de ellas. Sin embargo, el hecho de que o a la tecnolog Bluetooth est extendida a todos los mviles, unido a la gran caa e o pacidad de almacenamiento que stos ofrecen, hace que resulte util poder enviar e dichos archivos desde el ordenador que utiliza el orador a los dispositivos mviles o de los oyentes, de una manera rpida y sencilla. Gracias a la tecnolog Java, es a a posible desarrollar aplicaciones que hagan esto posible y que, adems, se adapten a a las necesidades del problema.

1.2.

Objetivos

El objetivo principal del presente proyecto es el desarrollo de un sistema que permita enviar un conjunto de cheros desde un ordenador a una serie de dispositivos mviles, mediante comunicacin Bluetooth. A su vez, el sistema deo o be presentar una serie de caracter sticas, las cuales podemos enmarcarlas como subobjetivos a perseguir: 1. El sistema debe funcionar en el mayor nmero posible de dispositivos mviu o les del mercado, independientemente de la marca y el modelo. 2. El sistema debe ser lo ms transparente posible a los usuarios nales de los a dispositivos mviles, buscando la mayor sencillez en su uso. o 3. La aplicacin que realiza el env de cheros debe ser sencilla de utilizar y o o presentar un interfaz amigable al usuario. 4. El sistema debe ser capaz de enviar cualquier tipo de chero, independientemente del formato. 5. El sistema debe ser capaz de enviar los archivos unicamente a una serie de dispositivos mviles, siguiendo algn determinado criterio. o u 6. El sistema debe proveer algn mecanismo que permita detectar errores en u el env de los cheros y ser capaz de realizar un reenv de los mismos. o o 7. El sistema debe ser capaz de llevar un seguimiento de los usuarios que han recibido los cheros, tanto en la sesin actual como en posteriores. o

1.3. FASES DEL DESARROLLO

13

1.3.

Fases del desarrollo

El sistema a implementar ha sido desarrollado siguiente una serie de cinco pasos o fases: 1. Desarrollar una aplicacin en Java (J2SE) capaz de realizar el env (v o o a Bluetooth) de uno o varios cheros desde un ordenador a los dispositivos mviles circundantes. o 2. Desarrollar una aplicacin Web en Java (J2EE), que permita el registro al o sistema de una serie de usuarios, identicando as su nombre y los datos de su dispositivo mvil. Adems, la aplicacin Web debe permitir al adminiso a o trador de la misma consultar, modicar o eliminar los datos de los usuarios registrados. 3. Desarrollar un mdulo adicional sobre la aplicacin desarrollada en la fase o o 1, que presente las siguientes funcionalidades adicionales: Muestre un interfaz grco al usuario. a Permita seleccionar los cheros a enviar. Permita realizar el env de cheros unicamente a los usuarios regiso trados en la aplicacin Web desarrollada en la fase 2. o Permita al usuario de la aplicacin llevar un seguimiento del estado de o los dispositivos mviles circundantes. o Implemente un mecanismo que permita llevar un seguimiento de los usuarios que han recibido cheros en diferentes sesiones, aunque en cada sesin utilicen un terminal mvil distinto. o o 4. Implementar una mejora adicional en la aplicacin Web desarrollada en la o fase 2, que permita al usuario inscribirse en uno o ms grupos de usuarios. a 5. Implementar una mejora adicional en la aplicacin desarrollada en la fase o 1, que permita a la aplicacin enviar los cheros unicamente a los usuarios o de un determinado grupo de usuarios.

14

CAP ITULO 1. INTRODUCCION Y OBJETIVOS

1.4.

Contenido de la memoria

El contenido de la memoria del proyecto se desglosa en los siguientes cap tulos: En el Cap tulo 2 se describen las tecnolog implicadas en el desarrollo del as proyecto: Bluetooth, OBEX, Java y BlueCove. El Cap tulo 3 muestra la descripcin, a alto nivel, de la solucin propuesta o o al problema. En el Cap tulo 4 se describe el desarrollo de la aplicacin Bluepills, analio zando el proceso de comunicacin entre las distintas entidades del modelo o planteado, as como la estructura de mdulos y clases Java que lo constitu o yen. En el Cap tulo 5 se describe el desarrollo de la aplicacin Web Bluepills, o complementaria a la aplicacin Bluepills. o En el Cap tulo 6 se incluye la bater de pruebas realizadas sobre el sistema a completo. En el Cap tulo 7 se describen las conclusiones extra das tras la realizacin o del proyecto, as como las posibles l neas de trabajo futuro. En el Apndice A se describe el contenido del presupuesto del proyecto, e adjuntado al nal del presente documento. En el Apndice B se incluye el manual de instalacin y uso de la aplicacin e o o Bluepills. En el Apndice C se incluye el manual de instalacin y uso de la aplicacin e o o Web Bluepills.

Cap tulo 2 Estado del arte

2.1.
2.1.1.

La tecnolog Bluetooth a
Antecedentes

La tecnolog Bluetooth es una tecnolog de comunicaciones inalmbricas de a a a corto alcance que permite la transmisin de voz y datos entre diferentes tipos o de dispositivos, como ordenadores, telfonos mviles, PDAs, impresoras, auricue o lares... entre otros muchos. Bluetooth es el nombre comn de la especicacin industrial IEEE 802.15.1 u o para Redes Inalmbricas de rea Personal (WPANs), la cual dene un estndar a a a global de comunicacin inalmbrica. Sus or o a genes se remontan a 1994, cuando la compa Ericsson comenz a investigar distintas alternativas para comunicar na o sus terminales mviles con ciertos accesorios. Entre muchas de sus conclusiones, o determinaron que para que esta nueva tecnolog tuviera xito, resultaba impresa e cindible que sta perteneciera a un estndar abierto y no a uno propietario. Para e a ello, en 1998 formaron el Bluetooth Special Interest Group (SIG), junto a otras compa como Intel, IBM, Nokia o Toshiba. Su objetivo era desarrollar conjunnas tamente las especicaciones para Bluetooth 1.0, que se terminar publicando an en julio de 1999.

15

16

CAP ITULO 2. ESTADO DEL ARTE

2.1.2.

Caracter sticas radio

Las caracter sticas que presenta Bluetooth en cuanto a la transmisin radio o son las siguientes:

Frecuencia Bluetooth fue diseado para trabajar en entornos de radio ruidosos, n por lo que utiliza un sistema de saltos de frecuencia para garantizar cierta robustez al enlace. Sus mdulos radio eliminan la interferencia con otras seales saltando o n de frecuencia inmediatamente despus de transmitir o recibir un paquete. e Bluetooth opera en la banda ISM de frecuencias de 2.4 GHz, por lo que no necesita licencia para su uso. A diferencia de otros sistemas que utilizan la misma banda (como 802.11), Bluetooth realiza saltos de frecuencia ms rpidos y emplea a a paquetes de menor tamao. La banda de frecuencia de trabajo est dividido en n a 79 frecuencias diferentes de 1 MHz, entre 2.402 GHz y 2.480 GHz, y pueden realizarse hasta 1600 saltos por segundo.

Transmisin La velocidad de transmisin se encuentra alrededor de 1 Mb/s, o o un valor inferior a otros estndares radio como 802.11b (11 Mb/s), aunque algo a superior a la transmisin infrarroja. o Bluetooth utiliza un esquema de divisin en el tiempo y una transmisin o o full-dplex. Su protocolo de banda base es una combinacin de conmutacin de u o o paquetes y conmutacin de circuitos, y posee cuatro canales: tres canales s o ncronos de voz y un canal as ncrono de datos. Cada canal de voz permite un enlace s ncrono de 64 kb/s. El canal as ncrono permite un enlace asimtrico de 721 kb/s e y 57.6 kb/s en la respuesta, o un enlace simtrico de 432.6 kb/s. e

Potencia La potencia m nima para funcionar es de 1 mW, un valor considerablemente bajo, lo que permite que dispositivos limitados en potencia puedan utilizarlo sin afectar demasiado al consumo de sus bater La potencia mxima as. a permitida segn la regulacin vigente es de 100 mW (PIRE). u o

Alcance El estndar Bluetooth dene tres clases de transmisores, todos coma patibles entre ellos, cuyo alcance var en funcin de su potencia radiada (ver a o cuadro 2.1). A diferencia de la tecnolog infrarroja, que emplea radiacin de luz para ena o viar datos, Bluetooth utiliza ondas de radio a 2.4 GHz. Como consecuencia, los

2.1. LA TECNOLOG BLUETOOTH IA Clase I II III Potencia 100 mW (20 dBm) 2.5 mW (4 dBm) 1 mW (0 dBm) Alcance 100 metros 10 metros 1 metro

17

Cuadro 2.1: Clases de dispositivos Bluetooth dispositivos no necesitan estar visualmente enfrentados para comunicarse, pudiendo incluso superar obstculos en el enlace, como pueden ser paredes o ventanas. a Redes Cuando un dispositivo Bluetooth se conecta a otros compartiendo un mismo canal de comunicacin, forman una pequea red denominada piconet. Eso n tas redes se componen de un dispositivo maestro que impone la frecuencia de saltos y de uno o ms (hasta siete) dispositivos esclavos. No obstante, hasta 255 a dispositivos pasivos pueden permanecer conectados a la piconet, de manera inactiva. A su vez, los esclavos pueden estar interconectados a diferentes piconets, formando una scatternet. En la gura 2.1 puede verse un ejemplo de la misma.

Figura 2.1: Scatternet Bluetooth Una peculiaridad de las redes piconet es que en ellas un dispositivo maestro puede conectarse con cualquier dispositivo esclavo pero, sin embargo, los dispositivos esclavos no pueden comunicarse entre ellos. En lo que a redes scatternet se reere, un dispositivo puede actuar de esclavo en dos piconets distintas, o actuar

18 como maestro en una y esclavo en otra.

CAP ITULO 2. ESTADO DEL ARTE

2.1.3.

Versiones

Desde su primera aparicin en 1999, han ido surgiendo distintas versiones del o estndar Bluetooth, caracterizadas por la introduccin de mejoras en cuanto a a o velocidad de transmisin, consumo de energ y seguridad: o a Bluetooth v1.1: El estndar Bluetooth surge a partir de un estudio inia ciado por Ericsson para investigar la viabilidad de una nueva interfaz de bajo consumo para la interconexin v radio entre dispositivos mviles y o a o otros accesorios. Conforme este proyecto fue avanzado, empez a vislumo brarse que este tipo de enlace pod ser utilizado en un gran nmero de a u aplicaciones, al estar basado en unico chip de radio. Bluetooth v1.2: Provee una solucin inalmbrica complementaria que pero a mite la coexistencia de Bluetooth y Wi-Fi en el espectro de frecuencias de 2.4 GHz. Utiliza la tcnica Adaptative Frequency Hopping (AFH), que pere mite una transmisin ms eciente y un cifrado ms seguro. Ofrece adems o a a a una calidad de voz con menor ruido ambiental y una conguracin ms o a rpida con el resto de dispositivos Bluetooth. a Bluetooth v2.0: Incorpora la tcnica Enhanced Data Rate (EDR), que e permite mejorar la velocidad de transmisin hasta 3 Mbps, y corrige algunos o errores detectados en la especicacin 1.2. o Bluetooth v2.1: Disminuye hasta cinco veces el consumo de potencia y simplica el proceso de creacin de conexiones entre dispositivos. o Bluetooth v3.0: Aumenta considerablemente la velocidad de transferencia. Bluetooth v4.0: Disminuye drsticamente el consumo de potencia, lo que a permite incorporar la tecnolog Bluetooth en pequeos dispositivos, como a n relojes o reproductores porttiles. Se mejora la seguridad, introduciendo a cifrado AES-128.

2.1. LA TECNOLOG BLUETOOTH IA

19

2.1.4.

Arquitectura de la pila Bluetooth

La pila de protocolos Bluetooth puede dividirse en dos grandes bloques: el Bluetooth Host y el Bluetooth Controller. Cada uno de ellos, como puede verse en la gura 2.2, consta de una serie de protocolos, los cuales describiremos a continuacin. El Host Controller Interface (HCI), situado entre medias, proporciona o un interfaz estandarizado entre ambos. El Bluetooth Host generalmente est ima plementado en software y se encuentra integrado con el sistema operativo del dispositivo. El Bluetooth Controller (tambin llamado Bluetooth Radio Module) e es el mdulo hardware del dispositivo Bluetooth que interacta con el Bluetooth o u Host a travs de mecanismos de entrada/salida, como puede ser PCMCIA (Peripe herical Componente Microchannel Interconnect Architecture), UART (Universal Asynchronous Receiver-Transmiter ) o USB (Universal Serial Bus). No obstante, aunque esta subdivisin de la pila Bluetooth se aplica en la mayor de disposio a tivos, en muchos de ellos ambas partes se encuentran integradas, prescindiendo del uso del HCI.

Figura 2.2: Pila de protocolos Bluetooth La pila de protocolos est compuesta por protocolos espec a cos de la tecnolog Bluetooth, como SDP, mientras que otros son protocolos adoptados de otras a tecnolog como es el caso de OBEX. A continuacin describimos brevemente as, o la funcionalidad de cada uno de ellos:

20

CAP ITULO 2. ESTADO DEL ARTE Bluetooth radio: La capa de radio Bluetooth es la capa ms baja de las a denidas en la especicacin. Dene los requisitos del dispositivo transcepo tor radio, como son la frecuencia de los canales, los saltos en frecuencia o los niveles de potencia de transmisin. o Baseband: La capa de banda base permite realizar una conexin entre dos o dispositivos Bluetooth. Gestiona el procesado de canales y la temporizacin, o as como el acceso a los canales. Permite dos tipos de canales: Orientado a Conexin Sncrono (SCO) y No Orientado a Conexin (SCL). Un enlace o o ACL transporta paquetes de datos, mientras que un enlace SCO transporta trco de audio en tiempo real. El audio no es en realidad una capa de a la pila de protocolos, y se encamina directamente a la capa de banda base sobre un enlace SCO o ACL. Link Manager Protocol (LMP): El Protocolo de Gestin de Enlace o (LMP) es el responsable de gestionar las conexiones entre los dispositivos Bluetooth, con todos los pasos que ello implica. Se encarga adems de cona trolar y negocia el tamao de los paquetes que se env al nivel de banda n an base, as como de los aspectos de seguridad, como son la autenticacin y el o cifrado de datos. Host Controller Interface (HCI): El HCI, comentado anteriormente, es un interfaz estndar para acceder a las capacidades banda base de Bluetooth a y a los registros de estado y control del hardware. Logical Link Control and Adaptation Protocol (L2CAP): El Protocolo de Control Lgico de Enlace y Adaptacin (L2CAP) oculta los detalles o o de los protocolos inferiores a los protocolos de las capas superiores, multiplexando sus conexiones lgicas. o Service Discovery Protocol (SDP): El Protocolo de Descubrimiento de Servicios (SDP) permite a las aplicaciones solicitar qu servicios hay e disponibles, as como las caracter sticas de los mismos. A diferencia de las Redes de Area Local (LAN), en donde los dispositivos se conectan primero a la red y luego encuentran otros dispositivos, en el estndar Bluetooth a primero encuentran a los dispositivos existentes en la red y, tras descubrir sus servicios, se conectan a ellos. Adems, los servicios disponibles pueden a cambiar mientras los dispositivos siguen conectados. RFCOMM: Los puertos serie son uno de los interfaces ms comunes de a comunicacin entre dispositivos. La funcin del protocolo RFCOMM es o o emular los puertos serie sobre L2CAP para proporcionar un mecanismo de transporte de datos para servicios de alto nivel. RFCOMM permite realizar

2.1. LA TECNOLOG BLUETOOTH IA

21

tanto mltiples conexiones concurrentes a un dispositivo como conexiones u de uno a mltiples dispositivos. u Telephone control Specication (TCS): El Protocolo de Especicacin o de Control de Telefona Binario (TCS Binary) dene la sealizacin de n o control para el establecimiento de llamadas de voz y datos entre dispositivos Bluetooth. Otros protocolos como OBEX e IP funcionan sobre alguno de los protocolos descritos anteriormente. La descripcin del protocolo OBEX (OBject EXchange), o en particular, se detallar en la seccin 2.2. a o

2.1.5.

Perles Bluetooth

Adems de los protocolos, el estndar Bluetooth dene una serie de perles. a a Un perl Bluetooth puede describirse como una seleccin vertical en la pila de o protocolos, y dene tanto las diferentes capas de protocolos empleados como las distintas caracter sticas de cada uno de ellos. Un dispositivo Bluetooth puede soportar uno o ms perles. Los cuatro perles bsicos son: a a Generic Access Prole (GAP) Es el perl base de los dems perles. a Dene los procedimientos genricos relativos al establecimiento de conee xiones entre dos dispositivos, incluyendo el descubrimiento de dispositivos Bluetooth, la gestin de enlace y la conguracin, y los procedimientos o o relacionados con la seguridad. Service Discovery Application Prole (SDAP) Describe los protocolos y procedimientos necesarios para descubrir los servicios disponibles en otros dispositivos Bluetooth, utilizando el Protocolo de Descubrimiento de Servicios (SDP). Serial Port Prole (SPP) Dene los requisitos necesarios en los dispositivos Bluetooth para emular conexiones serie entre dos terminales usando el protocolo RFCOMM. Generic Object Exchange Protocol (GOEP) Proporciona un modelo genrico para otros perles que implementen el protocolo OBEX y dene e los papeles para los dispositivos clientes y servidores. Estipula que debe ser el cliente el que inicie la transaccin pero, sin embargo, no describe o cmo las aplicaciones deber denir los objetos a intercambiar ni cmo o an o se deber implementar exactamente el intercambio. Esos detalles se dejan a

22

CAP ITULO 2. ESTADO DEL ARTE en manos de perles OBEX ms espec a cos, como OBEX File Transfer u OBEX Object Push.

2.1.6.

Seguridad en Bluetooth

Bluetooth incorpora varios mecanismos de seguridad, denidos a dos niveles: nivel banda base y nivel de enlace. Nivel banda base Est basada en la secuencia de saltos en frecuencia, slo conocida por a o los dispositivos pertenecientes a la misma piconet, y establecida a priori por el dispositivo maestro. Proporciona cierta condencialidad a los datos, siempre y cuando el posible atacante desconozca la secuencia de saltos. Nivel de enlace En l se denen tres mecanismos de seguridad: e 1. Autenticacin Cuando dos dispositivos Bluetooth intentan comunicarse, o se inicia un procedimiento de emparejamiento o pairing, creando una clave de enlace comn conocida por ambos dispositivos. u 2. Autorizacin El mecanismo de autorizacin se lleva a cabo mediante nio o veles de conanza, los cuales determinan la capacidad de acceso de un determinado dispositivo a los servicios ofrecidos por el servidor: Nivel de conanza Pairing TOTAL S PARCIAL S NULA No Acceso a servicios Sin restricciones Restringido a uno o varios servicios Restringido a todos los servicios

Cuadro 2.2: Niveles de conanza Todos los dispositivos Bluetooth disponen de una base de datos interna con una lista de dispositivos de conanza y el nivel de conanza asociado a cada uno de ellos. En caso de que un determinado dispositivo no conable intente acceder a un servicio restringido, se requiere un procedimiento expl cito de conrmacin por parte del usuario. o

2.1. LA TECNOLOG BLUETOOTH IA

23

3. Cifrado El cifrado de datos protege la informacin transmitida en una o conexin Bluetooth, garantizando su condencialidad. No obstante, su imo plementacin es opcional, por lo que maestro y esclavo deben acordar su o uso. Relacionados con los tres mecanismos de seguridad Bluetooth a nivel de enlace, se denen para cada dispositivo y servicio tres modos de seguridad en funcin o de su grado de implementacin: o Modo 1: Todos los mecanismos de seguridad estn deshabilitados. Adems, a a el dispositivo funciona en modo promiscuo, permitiendo que todos los dispositivos Bluetooth puedan conectarse a l. No se cifran los datos. e Modo 2: Proporciona seguridad a nivel L2CAP. Utiliza unicamente au torizacin, por lo que la interaccin con el usuario se limita a solicitar su o o conrmacin de acceso. Slo se cifran las conexiones punto a punto. o o Modo 3: Proporciona seguridad a nivel LMP. Utiliza autenticacin, por lo o que requiere el emparejamiento de dispositivos mediante una clave compartida por ambos e introducida por el usuario (cdigo PIN). Se cifran todas o las conexiones. Los primeros terminales que implementaron Bluetooth incorporaban por defecto el Modo 1. Poco a poco y debido al enorme riesgo que esto supon para la a seguridad, los distintos servicios han ido incorporando cada vez modos de seguridad ms altos. Hoy en d prcticamente la totalidad de los telfonos mviles a a, a e o del mercado incorporan el Modo 3 en todos sus servicios, a excepcin del Perl o de Carga de Objectos (OBEX Object Push Prole), que utiliza el Modo 2. En lo que a descubrimiento de dispositivos se reere, existen dos modos: Modo Visible (Discoverable) y Modo No Visible (Non Discoverable). No obstante, aunque un dispositivo se encuentre en modo No Visible, es posible realizar conexiones con l si se conoce previamente su Direccin Fsica Bluetooth (Bluetooth e o Address).

24

CAP ITULO 2. ESTADO DEL ARTE

2.2.
2.2.1.

OBEX
Descripcin o

OBEX (OBject EXchange) es un protocolo de nivel de sesin desarrollado o originariamente por la asociacin IrDA (Infrared Data Association) para el ino tercambio de objetos de forma sencilla. Su funcionalidad es similar al protocolo HTTP: utiliza mensajes compuestos por una o ms cabeceras de mensaje y (opa cionalmente) un cuerpo de mensaje. A su vez, los mensajes de respuesta poseen un cdigo de respuesta indicando el xito o noticando un posible error. o e El protocolo OBEX dene las distintas operaciones que puede realizar un cliente con el servidor: CONNECT: Inicia una sesin. o DISCONNECT: Finaliza una sesin. o PUT: Env un objeto al servidor. a GET: Solicita un objeto al servidor. DELETE: Solicita la eliminacin de un objeto del servidor. o SETPATH: Solicita un cambio del directorio actual dentro del rbol de a directorios del servidor. Como se coment en la seccin 2.1.5, el perl GOEP incluye dos perles ms o o a espec cos: OBEX Object Push: Proporciona un escenario de conexin rpida (transo a ferencia de objetos y desconexin), por lo que slo permite las operaciones o o CONNECT, PUT GET y DISCONNECT. Utiliza un nivel de seguridad Modo 2, por lo que slo es necesaria la autorizacin por parte del usuario o o del dispositivo servidor para poder establecer la conexin. Esto es debido a o que en un principio su uso estaba destinado al intercambio de tarjetas de visita entre dispositivos mviles. Actualmente el perl conserva esta funo cionalidad, pero puede utilizarse tambin para la transferencia rpida de e a cheros. No obstante, debido a su bajo nivel de seguridad, como servicio slo est implementado en dispositivos mviles. o a o

2.2. OBEX

25

OBEX File Transfer: Establece sesiones en las que las transferencias tienen lugar durante un largo per odo de tiempo, manteniendo la conexin o incluso cuando sta est inactiva. Permite todas las operaciones OBEX y e e utiliza un nivel de seguridad Modo 3, por lo que es necesario la autenticacin o de ambas partes, cliente y servidor, mediante el uso de un cdigo PIN o conocido y compartido por ambos. Lo implementan todos los dispositivos Bluetooth que gestionan sistemas de cheros. Debido a su implementacin en el presente proyecto, en la siguiente subseccin o o se detalla el funcionamiento del perl OBEX Object Push en particular. El esquema del perl OBEX File Transfer es similar, salvo que permite ms operaciones, a como se ha descrito en la comparativa anterior.

2.2.2.

OBEX Object Push

El Perl de Carga de Objetos (OBEX Object Push) permite la carga (push en ingls) de objetos desde un cliente a un servidor OBEX. Estos objetos pueden e ser una tarjeta de visita, un chero o simplemente un texto plano. La especicacin del perl OBEX Object Push [2] dene cmo deben comunicarse las o o aplicaciones con el perl, pero no dene los requisitos para los niveles Baseband, LMP, L2CAP o RFCOMM.

Figura 2.3: Pila de protocolos para OBEX Object Push

26 CLIENTE

CAP ITULO 2. ESTADO DEL ARTE SERVIDOR Activa el modo Object Exchange

Realiza una bsqueda del u servicio OBEX Object Push en el dispositivo servidor Inicia una conexin OBEX o y transmite el objeto al servidor El objeto es recibido por el servidor, tras solicitar previamente al usuario si acepta o rechaza el env o Opcionalmente la aplicacin cliente puede informar o al usuario del resultado de la operacin o Cuadro 2.3: Diagrama de comunicacin OBEX Object Push o En la gura 2.3 se muestra la relacin entre un cliente y un servidor OBEX o Object Push. Como podemos observar, por debajo del nivel de aplicacin la pila o de protocolos Bluetooth mantiene el esquema descrito en la seccin 2.1.4. El proo tocolo SDP permitir el descubrimiento, por parte del cliente, del servicio OBEX a Object Push ofrecido por el servidor. Por otro lado, hay que tener en cuenta que la conexin siempre debe iniciarla el cliente, ya sea para enviar un objeto (mediante o la operacin PUT) o para solicitar el env de un objeto (mediante la operacin o o o GET) por parte del servidor. Para el caso particular del env (o push) de objetos (la implementada en el o presente proyecto), la secuencia de comunicacin que ambas aplicaciones, cliente o y servidora, deben seguir es la mostrada en el cuadro 2.3. En cuanto a cuestiones de seguridad, los requisitos son los mismos que los denidos en el perl GOEP: la autenticacin y el cifrado de datos a nivel de o enlace son obligatorias de implementar aunque su uso es opcional.

2.3. JAVA Y BLUETOOTH

27

2.3.
2.3.1.

Java y Bluetooth
El estndar JSR-82 a

Los APIs (Application Programming Interface) de Java permiten, entre otras cosas, disear aplicaciones independientes del hardware, el sistema operativo o el n tipo de dispositivo empleado. Adems, al ser un lenguaje de alto nivel orientado a a objetos, Java permite una gran capacidad de abstraccin a la hora de modelar o aplicaciones. Por stas y otras razones, se desarrollaron unos estndares API para e a Bluetooth utilizando el lenguaje de programacin Java, conocidos como JABWT o (Java APIs for Bluetooth Wireless Technology). En Java, todas las conguraciones, perles y paquetes opcionales se denen como un JSR (Java Specication Request). En el caso de JABWT, ste se deni como el estndar JSR-82. e o a El estndar JSR-82 permite esconder la complejidad y los detalles de bajo a nivel del estndar Bluetooth y centrarse en el desarrollo rpido y sencillo de a a aplicaciones. Las capacidades que JSR-82 ofrece son las siguientes: Registro de servicios. Descubrimiento de dispositivos y servicios. Establecer conexiones RFCOMM, L2CAP y OBEX entre dispositivos para el env de datos. La comunicacin de voz, no obstante, no est soportada. o o a Establecer seguridad en las comunicaciones, mediante autenticacin y cifrao do de datos. Los APIs Java para Bluetooth denen dos paquetes dentro del paquete javax.microedition.io: javax.bluetooth y javax.obex.

2.3.2.

BlueCove

En un principio, el estndar JSR-82 fue diseado exclusivamente para la plaa n taforma J2ME (Java 2 Micro Edition), la cual permite desarrollar aplicaciones para dispositivos embebidos, fundamentalmente terminales mviles. No obstante, o tambin es posible disear aplicaciones Bluetooth para dispositivos que utilizan e n J2SE (Java 2 Standard Edition), como ordenadores y otros dispositivos de mayor capacidad. Esto es posible mediante la instalacin de la librer BlueCove. o a BlueCove es una librer de J2SE para Bluetooth que posee los interfaces JSRa 82 pero, sin embargo, no puede denirse formalmente como una implementacin o

28

CAP ITULO 2. ESTADO DEL ARTE

de JSR-82, ya que actualmente no pasa todos los tests JSR-82 TCK (para ms a informacin, vase la referencia [3]). BlueCove posee adems licencia LGPL, por o e a lo que es posible distribuir libremente software implementado con BlueCove. La librer BlueCove permite interactuar con MAC OS X, WIDCOMM, Bluea Soleil, Linux (con BlueZ) y la pila Bluetooth de Microsoft. En este ultimo caso, BlueCove funciona en los sistemas operativos Windows XP Service Pack 2, Windows Vista, Windows 7 (32bits) y Windows Mobile 2003 o superior. En lo que a Java se reere, BlueCove funciona con la versin 1.1 de J2SE y superiores. o En la gura 2.4 se muestra la arquitectura de la librer BlueCove en relaa cin con la pila de protocolos Bluetooth. Como podemos observar, los protocolos o de niveles inferiores (Bluetooth Controller) son implementados por el hardware Bluetooth, mientras que la pila Bluetooth Host y el HCI son implementados por el propio sistema operativo. La aplicacin en ejecucin residir en la Mquina o o a a Virtual de Java (JVM), y las librer BlueCove ofrecer un interfaz entre sta as an e y los protocolos de la pila Bluetooth.

Figura 2.4: BlueCove y la pila Bluetooth

2.3. JAVA Y BLUETOOTH

29

2.3.3.

El paquete javax.bluetooth de Java

Como se coment anteriormente, en toda comunicacin Bluetooth existe un o o dispositivo que ofrece un servicio (servidor) y uno o ms dispositivos que accea den a l (clientes). A continuacin se describen, desde el punto de vista de las e o aplicaciones Java, las funciones que desempean cada uno de ellos, y que pueden n implementarse mediante el API javax.bluetooth del JSR-82. CLIENTE BLUETOOTH Para comunicarse con un servidor Bluetooth, los pasos que la aplicacin cliente o Bluetooth debe realizar son los siguientes: 1. Bsqueda de dispositivos u 2. Bsqueda de servicios en el dispositivo u 3. Establecimiento de la conexin o 4. Comunicacin: transmisin de datos o o 5. Cierre de la conexin o SERVIDOR BLUETOOTH A diferencia de las aplicaciones cliente Bluetooth, la aplicacin servidora no o realiza ninguna bsqueda de dispositivos. Esta debe tan slo registrar el servicio u o que desea ofrecer y esperar a que los clientes se conecten a ella. En este caso, los pasos que la aplicacin servidora debe seguir son los siguientes: o 1. Crear una conexin servidora o 2. Especicar los atributos de servicio 3. Escuchar posibles conexiones cliente 4. Abrir las conexiones cliente

30

CAP ITULO 2. ESTADO DEL ARTE

2.3.4.

El paquete javax.obex de Java

Como se coment en la seccin 2.2.1, OBEX es un protocolo de alto nivel muy o o similar a HTTP, ya que se basa en mensajes compuestos por una o ms cabeceras a de mensaje y, opcionalmente, un cuerpo de mensaje. El cuerpo del mensaje es en realidad un objeto, y ste puede ser un archivo, un texto, una tarjeta de visita, e un array de bytes... Al igual que en HTTP, los mensajes de peticin del cliente al servidor se clao sican por mtodos (CONNECT, PUT, GET, DELETE, SETPATH y DISCONe NECT), y se implementan mediante la clase ClientSession. La funcionalidad de estos mtodos u operaciones fue descrita anteriormente en la seccin 2.2.1. e o Las cabeceras o headers de un mensaje OBEX se encapsulan en Java mediante un objeto de la clase HeaderSet. Existen cabeceras comunes que indican distintas caracter sticas del mensaje, como son su nombre, su tamao... aunque n tambin pueden crearse cabeceras personalizadas. Las cabeceras de mensaje ms e a habituales son: Identicador COUNT NAME TYPE LENGTH TIME 4 BYTE DESCRIPTION Funcin o Nmero de objetos utilizados en la sesin u o Nombre del objeto Tipo MIME del objeto Tamao del objeto n Fecha y hora del objeto Breve descripcin del objeto o Tipo Long String String Long Calendar String

Cuadro 2.4: Tipos de cabeceras de mensaje OBEX Para enviar y recibir mensajes que no slo poseen cabeceras sino tambin un o e cuerpo de mensaje (operaciones GET y PUT), se utiliza la clase Operation. A travs de un objeto de esta clase y, tras establecerse la conexin entre cliente y e o servidor, pueden enviarse u obtenerse cheros mediante ujos de bytes.

2.4. JAVA GUI: SWING

31

2.4.

Java GUI: Swing

Swing es una biblioteca grca de Java, perteneciente a la plataforma J2SE, a que proporciona un rico conjunto de componentes GUI (Graphical User Interface), como cajas de texto, botones, mens, desplegables y tablas. u Desde sus inicios, el entorno Java ya contaba con una biblioteca de componentes grcos, conocida como AWT (Abstract Window Toolkit). Esta biblioteca a estaba concebida como una API estandarizada que permit utilizar los compoa nentes nativos de cada sistema operativo. En la prctica, esta tecnolog no funa a cion como se esperaba, ya que tanto el funcionamiento como el comportamiento o de los controles variaba mucho de un plataforma a otra. Por otro lado, exist ya desde 1996 una biblioteca grca para el lenguaje a a de programacin Java, conocida como las Internet Foundation Classes (IFC), y o desarrollada por Netscape. A diferencia de AWT, los componentes de IFC eran mostrados y controlados directamente por cdigo Java, independientemente de la o plataforma. Dichos componentes, denominados componentes ligeros, no requer an reservar recursos nativos del sistema de ventanas del sistema operativo. En 1997, Sun Microsystems y Netscape Communications Corporation anunciaron su intencin de combinar IFC con otras tecnolog de las Java Foundation o as Classes, de cuyo resultado surgi Swing. Adems de los componentes ligeros sumio a nistrados originalmente por la IFC, Swing introdujo un mecanismo que permit a que el aspecto de cada componente de una aplicacin pudiese cambiar sin ino troducir cambios sustanciales en el cdigo de la aplicacin. La introduccin de o o o un soporte ensamblable para el aspecto, permiti a Swing emular la apariencia o de los componentes nativos manteniendo las ventajas de la independencia de la plataforma.

2.4.1.

Caracter sticas

Incluso el ms sencillo de los componentes Swing tiene capacidades que van a ms all de las ofrecidas por los componentes AWT. Las principales caracter a a sticas que presenta Swing son: Est desarrollado totalmente en java. a No reemplaza a AWT, sino que se apoya sobre l y le aade JComponents. e n Aade nuevos componentes, como rboles, tablas y frames internos... as con a mo iconos y bordes.

32

CAP ITULO 2. ESTADO DEL ARTE Utiliza un modelo basado en eventos. Swing no se apoya en los componentes proporcionados por el sistema, por lo que stos se comportan igual en cualquier plataforma. Por otro lado, la e apariencia que presentan (look and feel ) es congurable. Se puede modicar fcilmente el comportamiento o la apariencia de un a componente Swing llamando a mtodos o creando una subclase. e Las tecnolog asistidas como los lectores de pantallas pueden fcilmente as a obtener informacin desde los componentes Swing. Por ejemplo, una herrao mienta puede fcilmente obtener el texto mostrado en un botn o en una a o etiqueta.

2.4.2.

Componentes

Toda aplicacin grca realizada con Swing consta de al menos un conteo a nedor principal donde se sitan todos los dems componentes. En el caso de u a aplicaciones con ventanas estndar, el contenedor principal pertenece a la clase a javax.swing.JFrame. Esta clase representa a la ventana principal de la aplicacin y suele contener, al menos: un marco con t o tulo y botones para minimizar o cerrar la ventana, una barra de mens, una barra de herramientas con botones... u

Figura 2.5: Ejemplo de JFrame y JDialog Adems de la ventana principal, otro tipo de ventanas secundarias que se a suelen utilizar son: JDialog: Ventana que suele mostrar un mensaje o una pregunta al usuario, y que no se puede minimizar ni maximizar.

2.4. JAVA GUI: SWING

33

JFileChooser: Ventana que permite seleccionar un chero o un directorio del sistema. Dentro de cada ventana, pueden aadirse uno o ms paneles de distintos tipos: n a JPanel: Panel de tamao jo. n JScrollPane: Panel con barras de desplazamiento. JTabbedPane: Grupo de paneles en pestaas. n A su vez, dentro de cada panel pueden aadirse, entre otros, los siguientes n componentes grcos: a JButton: Botn con texto e imgenes. o a JRadioButton: Botones de seleccin unica. o JCheckBox: Casillas de seleccin mltiple. o u JComboBox: Botn de seleccin desplegable. o o JSpinner: Casilla de texto numrico, con botones para incrementar o dee crementar su valor secuencialmente. JTextArea: Area de texto editable o no editable. JTable: Tabla con celdas seleccionables y/o editables. JTree: Arbol de elementos, por ejemplo, directorios y cheros. Con respecto a los elementos de la barra de mens, Swing permite crear: u JMenuBar: Barra de men. u JMenu: Men, del que se despliegan uno o ms elementos. u a JMenuItem: Elemento del men. u JRadioButtonMenuItem: Elemento de men de seleccin unica. u o JCheckboxMenuItem: Elemento de men con seleccin multiple. u o Los mens se construyen de forma jerrquica: la barra de men consta de u a u varios mens, y cada men consta de varios elementos de men o submens u u u u (elemento perteneciente tambin a JMenuItem). e

34

CAP ITULO 2. ESTADO DEL ARTE

2.4.3.

Hilos en Swing

Una aplicacin Swing bien diseada usa concurrencia para evitar bloqueos y o n lograr que sta responda siempre a la interaccin del usuario, independientemente e o de la circunstancia. Para ello, es importante conocer primero qu tipos de hilos e utilizan el framework Swing: Initial Threads: Hilo o hilos que ejecutan el cdigo inicial de la aplicacin, o o y que sitan y conguran todos los elementos grcos. u a Event Dispatch Thread : Hilo que ejecuta todo el cdigo manejador de eveno tos; fundamentalmente, los eventos ocurridos cuando el usuario interacta u con alguno de los elementos de la interfaz grca. a Worker Threads: Tambin conocidos como Background Threads (hilos de e tarea de fondo), son hilos que se ejecutan en un segundo plano y que realizan tareas que consumen mucho tiempo. Como cualquier otro programa de la plataforma Java, un programa Swing puede crear hilos adicionales pero, sin embargo, slo necesita los hilos descritos o anteriormente para funcionar. En los programas Swing, los hilos iniciales no tienen demasiadas tareas que realizar. Su trabajo esencial es crear un objeto Runnable que inicializa la interfaz grca y lo programa para su ejecucin en el hilo despachador de eventos. Una a o vez creados los elementos grcos, la ejecucin del programa es conducida prina o cipalmente por los acontecimientos ocurridos en la interfaz grca de usuario, lo a que origina la ejecucin de tareas cortas en el hilo despachador de eventos (Event o Dispatch Thread ). No obstante, cuando el programa necesita ejecutar tareas que requieren un largo periodo de tiempo, stas no deben ser realizadas por el despachador de e eventos, sino que deben delegarse a un objeto que herede de la clase SwingWorker. Las subclases de SwingWorker deben implementar el mtodo doInBackground() e para realizar el clculo en un segundo plano. A su vez, para invocar a dicho a mtodo debe invocarse el mtodo execute() de la clase SwingWorker. e e SwingWorker es una clase genrica, con dos parmetros de tipo. El primer e a parmetro de tipo especica el tipo devuelto por el mtodo get(), que es invoa e cado por otros hilos para recuperar el objeto devuelto por doInBackground(). El segundo parmetro de tipo de SwingWorker especica un tipo de resultados a provisionales mientras la tarea de fondo sigue activa. Dichos resultados provisionales pueden publicarse llamando a publish(), que recibe un nmero variable u de parmetros. a

2.4. JAVA GUI: SWING

35

Para recopilar los resultados proporcionados por publish(), debe sobrescribirse el mtodo process(). Este mtodo se invoca desde el despachador de evene e tos; es por ello que el resultado de varias invocaciones de publish() a menudo es acumulado por una sola invocacin de process(). o Una vez que el mtodo doInBackground() termina, el mtodo done() de e e SwingWorker es invocado automticamente por el despachador de eventos. a

36

CAP ITULO 2. ESTADO DEL ARTE

2.5.
2.5.1.

Java Servlets y JSP

Servlets

Los servlets son programas Java que se ejecutan en un servidor Web y construyen pginas Web de manera dinmica. Los servlets son gestionados por un a a contenedor de servlets, residente tambin en el servidor. A diferencia de los ape plets, que se ejecutan en un cliente Web, los servlets se ejecutan exclusivamente en el servidor Web, reciben peticiones HTTP de los clientes y, como resultado, devuelven unicamente una pgina HTML o un archivo XML. a

Figura 2.6: Esquema cliente/servidor de servlets El proceso de ejecucin de un servlet es el siguiente: o 1. La peticin Web llega al servidor Web. o 2. La peticin se traslada al contenedor de aplicaciones, en concreto a su motor o del servicio Servlet/JSP, el cual posee su propia mquina virtual. a 3. El motor encapsula la informacin de la peticin en un objeto de tipo o o HttpServletRequest. Por otro lado, encapsula el ujo de respuesta en un objeto de tipo HttpServletResponse. 4. El motor crea, por cada peticin cliente, un hilo con el que invocar al o mtodo service() del servlet. En funcin del t` de peticin HTTP e o po o (POST o GET), service() llama al mtodo correspondiente del servlet: e doPost(), doGet()..., pasndole como parmetro los objetos asociados a a a HttpServletRequest y HttpServletResponse. 5. Cada clase del tipo servlet, tiene una unica instancia, sobre la que corren los diferentes hilos, uno por cada peticin HTTP. o

2.5. JAVA SERVLETS Y JSP

37

El funcionamiento de los servlets es similar al de CGI (Common Gateway Interface), pero con una arquitectura diferente. Las principales ventajas de los servlets frente a otras tecnolog Web son: as Est desarrollado en Java, por lo que es multiplaforma y orientado a objetos. a Cada peticin genera un hilo dentro de un proceso, mientras que en CGI o cada peticin genera un proceso. Esto permite un menor consumo de meo moria, un menor retraso en las peticiones y una mayor escalabilidad. El servlet mantiene automticamente su estado y recursos externos. a Permite realizar tareas t picas de un servidor: logging, gestin de errores, o sesiones... Los diferentes servlets pueden compartir datos entre ellos o utilizar bases de datos. Posee un gran nmero de APIs: bases de datos, red... u Posee una comunidad muy amplia de desarrolladores.

2.5.2.

Java Server Pages (JSP)

Las pginas JSP (Java Server Pages), son documentos HTML/XML con etia quetas especiales para programar scripts de servidor en sintaxis Java. Los JSPs son en realidad servlets: un JSP se compila a un programa Java la primera vez que se invoca, y del programa en Java se crea una clase que se empieza a ejecutar en el servidor como un servlet. La principal diferencia entre servlets y JSPs es el enfoque de la programacin: o Un JSP es una pgina Web con etiquetas especiales y cdigo Java incrusa o tado, el cual genera dinmicamente parte del cdigo HTML, a partir de a o datos incluidos en la peticin HTTP u otros provenientes de otros JSPs o o servlets. Un servlet es un programa que recibe peticiones y, a partir de ellas, genera una pgina HTML. a

38

CAP ITULO 2. ESTADO DEL ARTE

Cap tulo 3 Descripcin general del sistema o

3.1. Planteamiento del problema

El objetivo principal del presente proyecto, como se introdujo en la seccin 1.2, o es el desarrollo de un sistema que permita el env de cheros o p o ldoras desde un ordenador a una serie de terminales mviles, mediante comunicacin Bluetooth. o o Por el hecho de emplear Bluetooth en lugar de otras tecnolog de transmisin as o de datos, este escenario presenta una serie de peculiaridades que deben tenerse en cuenta: Bluetooth es una tecnolog inalmbrica y permite que cualquier dispositivo a a Bluetooth sea capaz de descubrir a los dispositivos Bluetooth cercanos, independientemente de que realice funciones de cliente o de servidor. Bluetooth permite implementar ciertas caracter sticas de seguridad (ver seccin 2.1.6). Cada servicio Bluetooth, adems, presenta un nivel de seguridad o a distinto. Los dispositivos Bluetooth se identican mediante dos sistemas: Friendly Name: Representa el nombre del dispositivo Bluetooth. Es de carcter alfanumrico y editable por el usuario del dispositivo. a e (Ej.:Mvil de Luis). o Bluetooth Address: Representa la direccin f o sica y un voca del dispositivo Bluetooth. Est escrita en hardware, por lo que no se puede a modicar. Est compuesto por 6 bytes y suele representarse en sistema a hexadecimal (Ej.:001CD41B3EA5 ). 39

40

CAP ITULO 3. DESCRIPCION GENERAL DEL SISTEMA Como se coment en la seccin 2.1, la frecuencia de trabajo de Bluetooth o o permite que las ondas transmitidas superen obstculos, como paredes o a ventanas. Por otro lado, el alcance de comunicacin entre dispositivos Blueo tooth es de aproximadamente 10 metros.

Como se describe en la seccin 1.3 sobre el desarrollo de las fases del proyecto, o el sistema consta de dos subsistemas o aplicaciones que funcionan independientemente pero que, como veremos ms adelante, comparten datos comunes entre a ellas. Estas dos aplicaciones son: Aplicacin Bluepills: Aplicacin grca desarrollada o o a ntegramente en lenguaje Java (J2SE), que realiza el env (v Bluetooth) de un conjunto de o a cheros desde un ordenador a los terminales mviles de los usuarios regiso trados. Constituye el eje principal del sistema. Es el resultado del desarrollo de las fases 1, 3 y 5 del proyecto. Aplicacin Web Bluepills: Aplicacin Web desarrollada en lenguaje Java o o (J2EE), que permite registrar los datos Bluetooth de los terminales mviles o de los usuarios. Corresponde al desarrollo de las fases 2 y 4 del proyecto.

3.2.

Estructura general del sistema

El sistema a desarrollar en el presente proyecto plantea un escenario compuesto por una serie de entidades que se relacionan siguiendo el esquema de la gura 3.1. Dicha gura muestra la relacin entre el ordenador que env los cheros y los o a dispositivos mviles sobre los que se realiza el env de cheros. En lo sucesivo, o o denominaremos equipo Bluetooth a la mquina en la que corre la aplicacin a o Bluepills y terminales Bluetooth a los terminales mviles equipados con Blueo tooth. A su vez, al usuario del equipo Bluetooth le denominaremos usuario del equipo, y a los usuarios de los terminales mviles Bluetooth, usuarios nales. o Como puede observarse en la gura 3.1, la transmisin de datos se realiza o en un unico sentido, desde el equipo Bluetooth a los terminales Bluetooth. Los papeles que desempean tanto el equipo como los terminales Bluetooth son los n siguientes: Equipo Bluetooth: En l reside la aplicacin Bluepills en ejecucin. Locae o o liza a los terminales Bluetooth cercanos y realiza el env de cheros. Debe o disponer de un dispositivo hardware Bluetooth.

3.2. ESTRUCTURA GENERAL DEL SISTEMA

41

Figura 3.1: Relacin entre el equipo y los terminales Bluetooth o Terminal Bluetooth: Permite ser localizado por el equipo Bluetooth y recibe el env de cheros. No requiere la instalacin ni ejecucin de ninguna o o o aplicacin. o Por otro lado, las funciones que desempean los distintos usuarios del sistema n son las siguientes: Usuario del equipo: Interacta con la aplicacin Bluepills, seleccionando u o los cheros que desea enviar e iniciando el proceso de env A travs de la o. e interfaz grca ofrecida por la aplicacin, puede acceder a cierta informacin a o o relativa a los dispositivos Bluetooth circundantes. Usuario nal: Interacta exclusivamente con su terminal mvil corresponu o diente. Realiza las siguientes tareas: 1. Activa el sistema Bluetooth en su terminal, de manera que pueda ser detectado por otros dispositivos Bluetooth. 2. Acepta solicitudes de env de cheros por parte del equipo Bluetooth. o

42

CAP ITULO 3. DESCRIPCION GENERAL DEL SISTEMA

Como se coment en la seccin 3.1, el sistema Bluepills consta tambin de una o o e aplicacin Web que permite el registro de los usuarios al sistema. Esta aplicacin o o Web reside en un servidor Web (que puede ser remoto o local), y a l acceden los e usuarios a travs de un navegador Web. A esta aplicacin Web tambin pueden e o e acceder otro tipo de usuarios, con perl de administrador. Las funciones de ambos, usuario a registrar y administrador, son las siguientes: Nuevo Usuario: Registra sus datos en la aplicacin Web, introduciendo o su nombre de usuario y el nombre de su dispositivo Bluetooth (Friendly Name). Administrador: Accede a la aplicacin Web para consultar, modicar o o borrar datos de los usuarios registrados.

3.3. FUNCIONAMIENTO GENERAL DEL SISTEMA

43

3.3.

Funcionamiento general del sistema

En la gura 3.2 se muestra la relacin entre la aplicacin Bluepills y la aplicao o cin Web. El funcionamiento de todo el sistema, aplicacin Bluepills y aplicacin o o o Web, consta de varias fases: 1. Los usuarios nales, utilizando un navegador Web, acceden a la aplicacin o Web y registran sus datos. Dichos datos quedan almacenados en el servidor Web en forma de cheros. 2. El usuario del equipo Bluetooth importa los datos de registro de usuario, almacenados en el servidor Web, a travs de la aplicacin Bluepills. La aplie o cacin Bluepills puede residir en la misma mquina que ejerce de servidor o a Web o en otra. 3. El usuario del equipo Bluetooth, utilizando la aplicacin Bluepills, seleco ciona un conjunto de cheros en su equipo. A continuacin, la aplicacin o o Bluepills env los cheros seleccionados, exclusivamente, a los terminales a Bluetooth de los usuarios nales registrados.

Figura 3.2: Esquema de funcionamiento del sistema Bluepills

44

CAP ITULO 3. DESCRIPCION GENERAL DEL SISTEMA

3.4.

Modelo de cheros

Como se ha comentado anteriormente, en principio la aplicacin Bluepills no o realiza el env de cheros a todos los dispositivos Bluetooth circundantes, sino o unicamente a los terminales mviles de los usuarios registrados. La informacin o o relativa a dichos usuarios se almacena en varios cheros en formato .csv. Los cheros CSV (Comma-Separated Values) son cheros de texto sencillos que permiten representar datos en forma de tabla: las columnas se separan por un carcter delimitador y las las por saltos de l a nea. El carcter delimitador a depende de la conguracin regional del sistema operativo; en el caso de Espaa, o n el delimitador por defecto es el punto y coma (;), para no confundirlo con la coma decimal empleada en datos numricos. Existen numerosos programas capae ces de interpretar estos cheros (por ejemplo, Microsoft Excel) y proporcionar un formato visual en forma de tabla.

3.4.1.

Fichero de usuarios

El chero CSV de usuarios registrados, utilizado por la aplicacin Bluepills, o consta de los siguientes campos, separados por punto y coma: Nombre del usuario: Describe un vocamente al usuario del sistema. Friendly Name: Nombre del dispositivo Bluetooth del terminal del usuario (ver seccin 3.1). o Bluetooth Address: Direccin f o sica del dispositivo Bluetooth del terminal del usuario (ver seccin 3.1). o Grupos: Lista con los identicadores de los grupos de usuarios en los que est inscrito el usuario. Cada identicador se separa con el carcter coma a a (,). En la gura 3.3 se muestra un ejemplo de un chero de usuarios y su interpretacin en un lector de cheros CSV. o

3.4. MODELO DE FICHEROS

45

Figura 3.3: Ejemplo de chero de usuarios

3.4.2.

Fichero de grupos

Adems del chero de usuarios, el sistema Bluepills utiliza otro chero CSV, a para gestionar grupos de usuarios. Este chero consta de los siguientes campos, separados por punto y coma: Identicador de grupo: Describe un vocamente a un grupo, mediante un identicador numrico. e Nombre de grupo: Nombre del grupo de usuarios.

Figura 3.4: Ejemplo de chero de grupos Alternativamente al env de cheros a usuarios registrados, la aplicacin o o Bluepills permite ltrar a los usuarios por grupos. Cada usuario registrado puede pertenecer a uno, a varios o a ningn grupo. Seleccionando la opcin corresponu o diente, la aplicacin puede realizar el env de cheros unicamente a los miembros o o de un determinado grupo, en lugar de a todos los usuarios registrados. En un entorno docente, por ejemplo, esta clasicacin en grupos puede emplearse para o separar alumnos por asignaturas.

46

CAP ITULO 3. DESCRIPCION GENERAL DEL SISTEMA

3.4.3.

Fichero de sesiones

Cada ejecucin de la aplicacin Bluepills para el env de cheros se enmarca o o o en un contexto que denominamos sesin. Al trmino de cada sesin, es posio e o ble almacenar los datos correspondientes a la misma en un chero de sesiones. Posteriormente, si el usuario del equipo realiza un nuevo env de cheros, pueo de almacenar los datos de la nueva sesin en un nuevo chero de sesiones o en o un chero de sesiones existente. Cada chero de sesiones almacena los siguientes datos, en formato CSV: Nombre del usuario: Describe un vocamente al usuario del sistema. Coincide con el nombre de usuario del chero de usuarios. Fecha: Fecha de la sesin. o Ficheros: Lista de cheros enviados durante la sesin. Cada nombre de o chero se separa con el carcter coma (,). a Fecha: ... Ficheros: ... Fecha: ... Ficheros: ...

Figura 3.5: Ejemplo de chero de sesiones

3.4. MODELO DE FICHEROS

47

En la gura 3.5 se muestra un ejemplo de un chero de sesiones. En el ejemplo, el usuario Alejandro recibi el chero documento.txt durante la sesin del d o o a 20 de diciembre de 2010. El usuario Luis, por su parte, particip en dos sesiones: o la sesin del d 11 de diciembre, en la que recibi dos cheros, y la sesin del d o a o o a 20 de diciembre.

48

CAP ITULO 3. DESCRIPCION GENERAL DEL SISTEMA

Cap tulo 4 Desarrollo de la aplicacin o Bluepills

4.1. Estructura

La aplicacin Bluepills est desarrollada o a ntegramente en lenguaje Java y consta de tres mdulos, representados en la gura 4.1. o

Figura 4.1: Mdulos de la aplicacin Bluepills o o Cada uno de estos mdulos est compuesto por una serie de clases Java con o a una funcionalidad determinada pero, no obstante, todos ellos se relacionan entre s ya sea para acceder a datos compartidos o para invocar alguno de sus mtodos. , e 49

50

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

A grandes rasgos, la funcionalidad de cada uno de los mdulos Bluepills es la o siguiente: Mdulo Grco: Presenta una interfaz grca entre la aplicacin y el o a a o usuario del equipo. Permite seleccionar los cheros a enviar en cada sesin, o acceder a la informacin relativa a los terminales Bluetooth circundantes e o iniciar el env de cheros. o Mdulo Bluetooth: Gestiona todo lo concerniente a las comunicaciones o Bluetooth (bsqueda de dispositivos, establecimiento de conexiones, env u o de cheros...) utilizando los APIs de la librer BlueCove (ver seccin 2.3.2). a o Mdulo de Datos: Gestiona la lectura y escritura de todos los cheros de o datos (cheros de usuarios, de grupos y de sesiones). Tambin gestiona las e estructuras de datos asociadas a dichos cheros, que son compartidas por los tres mdulos. o En la gura 4.2 se muestra la estructura, en forma de arbol, de los distintos paquetes y clases java que componen la aplicacin Bluepills. La relacin de los o o mdulos de la aplicacin con dichos paquetes es la siguiente: o o Mdulo Grco: paquete GUI. o a Mdulo Bluetooth: paquete BTI. o Mdulo de Datos: paquete users. o A continuacin, en las siguientes secciones, se analiza en detalle la estructura o y el funcionamiento de cada uno de los tres mdulos. o

4.1. ESTRUCTURA

51

Figura 4.2: Diagrama de clases de la aplicacin Bluepills o

52

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

4.2.

Mdulo Bluetooth o

Aunque el eje principal de la aplicacin Bluepills es el Mdulo Grco, ya que o o a de l parte el punto de inicio del programa, el ncleo fundamental del sistema e u reside en el Mdulo Bluetooth, pues es el encargado de realizar todo el proceso o de comunicacin con los terminales Bluetooth. Este mdulo est compuesto por o o a un conjunto de clases Java que, a su vez, utilizan el API javax.bluetooth y javax.obex, pertenecientes a la librer BlueCove, para poder interactuar con a el dispositivo hardware Bluetooth del equipo. Las principales funciones de este mdulo son: o Realizar bsquedas de dispositivos Bluetooth remotos. u Obtener informacin de los servicios ofrecidos por los dispositivos Bluetooth o remotos. Obtener informacin sobre las caracter o sticas de los dispositivos Bluetooth remotos, como su direccin f o sica o su nombre. Establecer comunicaciones OBEX Bluetooth con los dispositivos remotos para la transmisin de cheros. o

4.2.1.

El modelo cliente-servidor Bluetooth

Al igual que en muchos otros sistemas de comunicaciones, el modelo de comunicaciones Bluetooth no es simtrico. Por ello, antes de desarrollar en Java cuale quier cdigo relacionado con las comunicaciones Bluetooth, es necesario entender o el papel y las funciones que desempean cada uno de los terminales situados en n ambos extremos de la comunicacin. o Cuando se establece un enlace Bluetooth entre dos dispositivos, uno de los dispositivos se dene como maestro y otro como esclavo (ver seccin 2.1.2). o El estndar Bluetooth establece que el dispositivo que inicia la conexin asume a o el papel de maestro, mientras que el dispositivo que acepta la conexin ejerce o el papel de esclavo. El rol de maestro no otorga ningn privilegio sobre el de u esclavo, pero implica que ser el dispositivo maestro el encargado de calcular la a secuencia de saltos en frecuencia, as como de controlar la sincronizacin entre o ambos dispositivos. Adicionalmente, algunos dispositivos Bluetooth son capaces de soportar la conmutacin entre ambos papeles, permitiendo que en cualquier o momento el dispositivo maestro se convierta en esclavo y viceversa. En conexiones entre dos dispositivos no es relevante en realidad quin ejerce de maestro y quin e e

 4.2. MODULO BLUETOOTH

53

de esclavo. Sin embargo, en conexiones entre mltiples dispositivos, slo pueden u o existir un dispositivo maestro y siete esclavos funcionando simultneamente, y a hasta 255 esclavos en estado inactivo. En la gura 4.3 se muestra la relacin, a distintos niveles, entre un dispositivo o Bluetooth cliente y un dispositivo Bluetooth servidor. En un principio, segn el u esquema de la relacin entre el equipo y los terminales Bluetooth (ver gura 3.1), o parece lgico pensar que, en nuestro modelo de comunicacin, es el equipo Blueo o tooth el que ejerce de servidor y que son los terminales Bluetooth los que ejercen de clientes. No obstante, en realidad el modelo no funciona exactamente as como , veremos a continuacin. El equipo Bluetooth no transmite simultneamente los o a cheros a todos los terminales Bluetooth sino que, tras realizar una bsqueda de u dispositivos y servicios, establece una conexin Bluetooth independiente con cada o uno de ellos. El modo en que se realizan dichas conexiones determina los roles cliente/servidor de cada uno de los dispositivos, a distintos niveles: Nivel de aplicacin: A nivel de aplicacin, el env de cheros se realiza o o o utilizando la operacin PUT del protocolo OBEX (ver seccin 2.2), la cual o o determina que es el cliente el que realiza el env o carga de objetos, mientras o que el servidor es el receptor de los mismos. Nivel JSR-82: A este nivel, es el terminal Bluetooth el que ofrece el servicio OBEX Object Push, y el equipo Bluetooth el que realiza la bsqueda del u servicio en el terminal. Una vez descubierto el servicio, es el cliente (equipo Bluetooth) el que inicia la conexin con el servidor (terminal Bluetooth). o Nivel Bluetooth: Como comentamos en el prrafo anterior, todo dispoa sitivo que inicia la comunicacin se convierte en maestro y, por ende, el o otro dispositivo se convierte en esclavo. No obstante, si se especica en los parmetros del servicio y los dispositivos lo permiten, durante la comunia cacin estos papeles pueden intercambiarse. o

54

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

Figura 4.3: Modelo cliente-servidor en Bluepills

4.2.2.

Comunicacin cliente-servidor OBEX o

Como se coment en la seccin anterior, en la comunicacin OBEX entre o o o el equipo y un terminal Bluetooth, es ste ultimo el que ejerce la funcin de e o servidor. Adems, todos los terminales mviles del mercado equipados con la a o tecnolog Bluetooth implementan el servicio OBEX Object Push (para poder a enviar y recibir objetos entre dispositivos), por lo que no es necesario el desarrollo de cdigo adicional en la parte del servidor. o El perl GOEP de la especicacin Bluetooth [1] determina los roles denidos o para clientes y servidores OBEX: Servidor OBEX: proporciona un servidor de intercambio de objetos, hacia o desde el cual los objetos pueden ser enviados (push) o solicitados (pull). Cliente OBEX: Env o solicita objetos hacia o desde el servidor. a Para permitir que el dispositivo cliente pueda encontrar al dispositivo servidor y establecer conexiones con l, es necesario que este ultimo se encuentre en Modo e Visible y en Modo Conectable. Para ello, el usuario nal debe activar el dispositivo Bluetooth en su terminal mvil y congurarlo para tal propsito. o o El perl GOEP especica que si la autorizacin o la autenticacin OBEX o o estn soportadas, y la implementan tanto el servidor como el cliente, sta debe a e inicializarse antes de establecer la sesin OBEX entre ambos dispositivos. Para o

 4.2. MODULO BLUETOOTH

55

el caso particular del servicio OBEX Object Push, ste utiliza un nivel de segue ridad Modo 2 (ver seccin 2.1.6), por lo que el unico mecanismo de seguridad o implementado es el de autorizacin. En este caso, antes de que el cliente inicie o una sesin OBEX con el dispositivo servidor, ste es noticado del intento de coo e nexin, mostrndole por pantalla al usuario el nombre del dispositivo cliente que o a intenta conectarse con l. En caso de que el usuario nal la autorice (pulsando la e opcin correspondiente en su terminal), la sesin OBEX puede iniciarse. En caso o o contrario, la conexin se rechaza. o En la siguiente gura se muestra el diagrama de intercambio de mensajes entre cliente y servidor, durante una sesin OBEX en Bluepills, una vez que el proceso o de autorizacin ha concluido con xito. o e

Figura 4.4: Diagrama de comunicacin OBEX en Bluepills o

56

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

Como puede observarse en la gura 4.4, el cliente inicia cada operacin OBEX o con un mensaje de peticin y, a continuacin, espera una respuesta del servidor. o o Una sesin OBEX comienza con una peticin CONNECT del cliente al servidor. o o A su vez, la sesin naliza con una peticin DISCONNECT. Entre las peticioo o nes CONNECT y DISCONNECT, el cliente puede enviar un nmero ilimitado u de peticiones PUT, GET o SETPATH al servidor. En el caso de la aplicacin o Bluepills, tras la peticin CONNECT slo se env peticiones PUT. o o an Cada mensaje de peticin y respuesta anterior incluye una o ms cabeceras o a OBEX. Como se describi en la seccin 2.3.4, estas cabeceras puede ser de diso o tintos tipos: NAME, LENGTH, TYPE, COUNT, DESCRIPTION... En el caso particular de la operacin CONNECT en la implementacin Bluepills, sta ino o e cluye una cabecera de tipo COUNT, en la que se indica el nmero de objetos u o cheros a enviar. Cuando el dispositivo mvil servidor recibe la peticin, proo o cesa las cabeceras recibidas y determina si acepta o rechaza la conexin. Si el o servidor acepta la conexin, responde con un cdigo de respuesta de tipo OK, o o SUCCESS. Si por el contrario el servidor rechaza la conexin, ste responde con o e un cdigo de respuesta HTTP que especica el motivo del rechazo. o Una vez que la conexin se ha establecido satisfactoriamente, el cliente emite o una peticin PUT al servidor, con el n de transmitir el primero de los cheros. o En este caso, el mensaje OBEX incluye cuatro cabeceras: NAME: nombre del chero a enviar. TYPE: tipo MIME del objeto a enviar; al tratarse de un chero, el tipo es object. LENGTH: tamao del chero a enviar, en nmero de bytes. n u BODY: especica que dentro del mensaje OBEX van incluidos bytes de datos, correspondientes a un objeto. Una vez que el objeto ha sido transmitido correctamente al servidor, ste rese ponde de nuevo con un cdigo de respuesta OK, SUCCESS. En caso contrario, o responde con el cdigo de respuesta HTTP pertinente. o A partir de este punto, continan envindose tantas peticiones PUT como u a nmero de cheros haya pendientes de enviar. Para nalizar la sesin OBEX, el u o cliente debe enviar una peticin DISCONNECT. Generalmente, la peticin DISo o CONNECT no requiere el uso de cabeceras adicionales, aunque stas podr e an incluirse. Cuando recibe una peticin DISCONNECT, el servidor libera los reo cursos reservados y env una respuesta OK, SUCCESS al cliente. Cuando el a cliente recibe dicha respuesta, la sesin OBEX termina. o

 4.2. MODULO BLUETOOTH

57

En el transcurso de la sesin OBEX, si el cliente recibe un cdigo de respuesta o o HTTP distinto a OK, SUCCESS o la transmisin de alguno de los objetos se o interrumpe por cualquier motivo, el cliente env una peticin DISCONNECT al a o servidor, con el n de cerrar la sesin y evitar que ste se bloquee indenidamente, o e esperando una nueva peticin OBEX del cliente. o

4.2.3.

Sesin de env de cheros o o

Una vez expuesto el proceso de comunicacin cliente-servidor en una sesin o o Bluepills de transferencia de cheros, a continuacin se describen los pasos neo cesarios para poder llevarlo a cabo, desde un punto de vista esquemtico. En la a siguiente seccin, no obstante, se describen las clases y mtodos Java implicados o e en dicha tarea. A nivel de los mdulos que componen la aplicacin Bluepills, el Mdulo Blueo o o tooth es invocado por el Mdulo Grco cada vez que se realiza un nuevo env o a o de cheros a los dispositivos Bluetooth remotos. A travs de la interfaz grca e a ofrecida por el Mdulo Grco, el usuario del equipo puede iniciar en cualquier o a momento una nueva sesin de env de cheros. Cuando esto sucede, el Mdulo o o o Bluetooth (invocado por el Mdulo Grco) ejecuta una secuencia de pasos, reo a presentada en el diagrama de ujo de la gura 4.5 y resumida en los siguientes puntos: 1. El usuario de la aplicacin inicia la sesin. o o 2. El Mdulo Bluetooth inicia una bsqueda de dispositivos Bluetooth remotos o u y permanece a la espera. 3. Una vez que la bsqueda de dispositivos Bluetooth remotos ha concluido, u contabiliza el nmero de dispositivos remotos encontrados. u 4. Accede a la informacin de los usuarios registrados, a travs del chero de o e usuarios. 5. Compara la informacin de los dispositivos encontrados con la de de los o usuarios registrados; si alguno de los datos (Friendly Name o Bluetooth Address) ha cambiado, actualiza el chero de usuarios. 6. Para el dispositivo n encontrado, si ste se encuentra registrado, realiza e una bsqueda del servicio OBEX Object Push. u 7. Si se encuentra el servicio, crea un hilo independiente, que se encargar de a realizar la comunicacin OBEX para el env de cheros al dispositivo. o o

58

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS 8. Si hay ms dispositivos remotos encontrados, vuelve al paso 4. En caso a contrario, la sesin de env de cheros termina. No obstante, como se deso o cribe en la seccin 4.3.1, el Mdulo Grco invoca de nuevo este proceso, o o a c clicamente, hasta que el usuario solicita su detencin. o

El servicio OBEX Object Push (ver seccin 2.2.2) proporciona un mecanismo o de alto nivel para la transmisin de cheros desde el equipo Bluetooth hacia los o terminales Bluetooth. No obstante, como puede deducirse en el diagrama de ujo de la gura 4.5, el env de cheros a cada uno de los terminales no es simultneo o a sino que, tras vericar que stos implementan el servicio, la aplicacin abre una e o conexin distinta con cada uno de ellos. Cada una de estas conexiones se delega o en un nuevo hilo de ejecucin independiente, evitando as el env secuencial (y o o bloqueante) de los cheros. Cada hilo de comunicacin OBEX ejecuta a su vez una secuencia de pasos, o los cuales se describen grcamente en la gura 4.6. Estos pasos son: a 1. El hilo de comunicacin OBEX obtiene la URL (Uniform Resource Locator ) o del servicio, a partir de los datos obtenidos en la bsqueda del servicio (ver u gura 4.5). 2. Intenta establecer una conexin con el dispositivo remoto, utilizando la URL o obtenida anteriormente. 3. El terminal del usuario, al recibir el intento de conexin Bluetooth, solicita o permiso al usuario. Si el usuario rechaza la conexin, la ejecucin del hilo o o termina. 4. Una vez que el usuario ha aceptado la conexin, env un mensaje OBEX o a CONNECT a su dispositivo remoto, y espera una respuesta a dicho mensaje. 5. Si la respuesta del mensaje OBEX CONNECT es correcta, contina; en caso u contrario, env un mensaje OBEX DISCONNECT al dispositivo remoto y a la ejecucin termina. o 6. Env un mensaje OBEX PUT al dispositivo remoto, con uno de los cheros a como cuerpo del mensaje. Si durante la transmisin del chero se produce o algn error, env un mensaje OBEX DISCONNECT al dispositivo remoto u a y la ejecucin termina. o 7. Si hay ms archivos pendientes de enviar, vuelve al paso 6. En caso contraa rio, la ejecucin termina. o

 4.2. MODULO BLUETOOTH

59

Figura 4.5: Diagrama de ujo: Sesin de envo de cheros o

60

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

Figura 4.6: Diagrama de ujo: Comunicacin OBEX o

 4.2. MODULO BLUETOOTH

61

4.2.4.

Estructura de clases del Mdulo Bluetooth o

Como se ha apuntado anteriormente, la funcin principal del Mdulo Blueo o tooth es la de implementar el proceso de comunicacin entre el equipo y los tero minales Bluetooth. Para ello, las clases Java de este mdulo utilizan las librer o as JSR-82 proporcionadas por BlueCove para poder interactuar con los protocolos inferiores del dispositivo hardware Bluetooth del equipo. Dentro de la aplicacin Bluepills, dichas clases estn contenidas en el paquete Java BTI (Bluetooth o a Interface). La funcionalidad de cada una de estas clases es la siguiente: BTManager Constituye el eje principal del Mdulo Bluetooth. Ejerce de nexo entre o el Mdulo Grco y los otros dos mdulos, invocando a los mtodos de stos. o a o e e Utiliza estructuras de datos compartidas con el Mdulo de Datos. o BTSearch Clase que implementa la bsqueda de dispositivos y servicios Bluetooth u remotos. Posee, entre otros, los siguientes mtodos: e searchDevices(): Solicita una bsqueda de los dispositivos Bluetooth ciru cundantes. Tras esto, el hilo de ejecucin permanece a la espera de que la o bsqueda de dispositivos concluya. u deviceDiscovered(): Cada vez que un dispositivo Bluetooth remoto es encontrado, este mtodo es invocado por el escuchador de eventos. A travs e e de este objeto puede obtenerse informacin relativa al dispositivo remoto o encontrado. inquiryCompleted(): Una vez que la bsqueda de dispositivos ha concluiu do, el escuchador de eventos invoca a este mtodo, indicando el motivo e de la nalizacin: bsqueda completada, bsqueda cancelada o error en la o u u bsqueda. Adems, reactiva al hilo de ejecucin que permanec a la espera u a o a tras invocar a searchDevices(). searchService(): Anlogamente a la bsquedas de dispositivos remotos, a u insta al protocolo SDP a que realice una bsqueda de servicios en un deteru minado dispositivo remoto. Este mtodo recibe como parmetros un array e a con los UUID (Universal Unique IDentier ) de los servicios buscados y un array con los atributos que se desean obtener de dichos servicios (tipo de

62

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS servicio, nombre...). Cada servicio estandarizado posee su propio UUID, y existe un rango de numeracin disponible para cualquier nueva aplicacin o o que se cree. En el caso del servicio OBEX Object Push, el UUID asociado es el 0x1105 (en sistema hexadecimal). Para el caso de los atributos de servicio, stos poseen tambin su propia numeracin. Por ejemplo, el atributo e e o de servicio que describe el nombre del servicio es el 0x0100. Al igual que en la bsqueda de dispositivos, tras invocar una bsqueda de servicios el hilo u u de ejecucin permanece a la espera. o servicesDiscovered(): Una vez encontrados los servicios buscados, el escuchador de eventos invoca a este mtodo, el cual recibe un array de objetos e ServiceRecord, con una instancia por cada servicio encontrado. A travs e del mtodo getConnectionURL() de la clase ServiceRecord se obtiene la e URL del servicio, con una serie de parmetros de conexin. En el caso del a o servicio OBEX Object Push, la URL obtenida mostrar el siguiente aspeca to: btgoep://001CD41B3EA5:9;authenticate=false;encrypt=false; master=false En este ejemplo, vemos que el perl utilizado es GOEP, 001CD41B3EA5 es la direccin f o sica del dispositivo Bluetooth y 9 el valor del puerto asociado al servicio. El servicio OBEX Object Push, por defecto, no implementa ni autenticacin ni cifrado. El ultimo parmetro indica que el cliente o a no impondr su rol de maestro durante el tiempo que dure la conexin, sino a o que ambos papeles podrn ser intercambiados. a serviceSearchCompleted(): Cuando la bsqueda de servicios naliza, el u escuchador de eventos invoca a este mtodo, indicando el motivo de la nae lizacin: bsqueda nalizada con normalidad, bsqueda cancelada, error en o u u la bsqueda, no se encontr el dispositivo o no existe informacin del serviu o o cio solicitado. Al igual que en la bsqueda de dispositivos, reactiva al hilo u de ejecucin que permanec a la espera tras invocar a searchServices(). o a

BTObexPush Realiza todo el proceso de comunicacin OBEX, el cual permite la transmisin o o de cheros a travs del servicio OBEX Object Push. Como se describe en la e gura 4.5, por cada dispositivo remoto sobre el que se realiza el env de cheros, o la instancia de la clase BTManager crea un hilo de ejecucin independiente o asociado a una instancia de esta clase. El constructor de esta clase recibe la URL del servicio OBEX Object Push obtenido previamente en la bsqueda de u

 4.2. MODULO BLUETOOTH

63

servicios asociados al dispositivo, as como la ruta del directorio y el nombre de los cheros a enviar. Los mtodos principales de esta clase son: e sendFiles(): Implementa el establecimiento de una sesin OBEX de la o aplicacin cliente con el servidor OBEX Object Push. Una vez establecida o la sesin mediante la operacin CONNECT de OBEX, realiza una llamada o o al mtodo putFile() por cada chero a enviar. Una vez realizadas todas las e operaciones PUT necesarias, cierra la sesin OBEX mediante la operacin o o DISCONNECT. putFile(): Implementa la operacin PUT de OBEX, creando un canal o de ujo de bytes que permite la transmisin del chero desde el equipo o cliente hasta el dispositivo mvil servidor. En caso de producirse un error o en la transmisin del chero, este mtodo lanza una excepcin y env un o e o a mensaje DISCONNECT al servidor, con el n de cerrar la sesin. De esta o manera, se evita que el terminal Bluetooth quede bloqueado a la espera de respuesta por parte del equipo Bluetooth. BTDevice Estructura de datos que representa a un dispositivo remoto encontrado. Posee una serie de atributos, muchos de los cuales son mostrados en la tabla de dispositivos encontrados (ver seccin 4.3). Algunos de estos atributos, como el o nombre de usuario y los grupos de usuarios a los que pertenece, se obtienen de los datos del usuario asociado a este dispositivo.

64

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

4.3.

Mdulo Grco o a

El Mdulo Grco representa el ncleo principal de la aplicacin Bluepills. o a u o Adems de ser el punto de partida de ejecucin del programa, presenta una ina o terfaz grca al usuario del equipo Bluetooth que permite: a Mostrar la informacin relativa a los terminales Bluetooth encontrados tras o realizar bsquedas de dispositivos. u Crear sesiones de env de cheros a dispositivos Bluetooth remotos de o usuarios registrados, mostrando un seguimiento del mismo en tiempo real. Seleccionar el directorio donde se hallan los cheros a enviar. Llevar un seguimiento de varias sesiones realizadas en d distintos. as Realizar el reenv de cheros a cualquier dispositivo Bluetooth remoto. o

Figura 4.7: Interfaz Grca de Usuario a

 4.3. MODULO GRAFICO

65

4.3.1.

Funcionalidad de la GUI

En la siguiente seccin se describen las distintas funcionalidades que ofrece la o interfaz grca de usuario o GUI (Graphical User Interface) proporcionada por a el Mdulo Grco. o a - B squeda rpida u a Antes de comenzar una sesin de env de cheros, la aplicacin permio o o te realizar una bsqueda rpida de dispositivos Bluetooth prximos al equipo u a o Bluetooth. Esto permite que el usuario de la aplicacin pueda conocer a o priori qu dispositivos participarn posteriormente en la sesin. Tras nalizar e a o la bsqueda, muestra una tabla con informacin relativa a cada dispositivo u o encontrado: nombre del dispositivo (Friendly Name), direccin Bluetooth y o nombre del usuario (si ste se encuentra registrado). e - Sesiones Como se ha comentado anteriormente, las sesiones Bluepills permiten realizar el env de varios cheros a los dispositivos Bluetooth prximos, y que se o o encuentren registrados previamente en el chero de usuarios (ver seccin 3.4.1). o El diagrama de ujo de la gura 4.8 muestra la secuencia de pasos que debe realizar el usuario al iniciar una sesin Bluepills, a travs de la interfaz grca. o e a En dicha secuencia, el usuario: 1. Crea una nueva sesin. o 2. Selecciona el directorio donde se encuentran los cheros a enviar. 3. Selecciona el tipo de dispositivos sobre los que realizar el env (ver siguiente o punto Tipos de sesiones). 4. Arranca la sesin. Al hacerlo, el Mdulo Grco invoca al Mdulo Blueo o a o tooth e inicia una sesin de env de cheros (ver seccin 4.2.3). Mientras el o o o usuario no detenga la sesin, la aplicacin contina realizando, c o o u clicamente, nuevas bsquedas de dispositivos no detectados anteriormente. Cada vez u que se encuentran nuevos dispositivos Bluetooth, se realiza un nuevo env o de cheros, si procede (ver siguiente punto Tipos de sesiones). 5. Una vez detenida la sesin, el usuario puede opcionalmente guardar los dao tos de la sesin en un chero de sesiones (ver seccin 3.4.3). En ese caso, el o o

66

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS usuario puede seleccionar actualizar un chero de sesiones creado anteriormente o solicitar la creacin de uno nuevo. o 6. A continuacin, el usuario puede optar por una de estas dos opciones: o a) Volver a seleccionar el tipo de dispositivos y arrancar de nuevo la sesin. o b) Finalizar la sesin. o

- Tipos de sesiones Antes de arrancar una sesin de env de cheros, el usuario de la aplio o cacin puede seleccionar el tipo de dispositivos que se incluirn en la sesin: o a o 1. Usuarios registrados: usuarios cuyos terminales se encuentren registrados en el chero de usuarios. 2. Todos los dispositivos: todos los dispositivos Bluetooth encontrados que soporten el servicio OBEX Object Push. 3. Grupo de usuarios: usuarios registrados que pertenezcan al grupo de usuarios seleccionado (ver seccin 3.4.2). o 4. Dispositivos seleccionados: dispositivos Bluetooth seleccionados por el usuario. Para ello, es necesario que la aplicacin haya realizado al menos o una primera bsqueda de dispositivos, por lo que esta opcin se habilita u o unicamente tras parar la sesin. Esta opcin permite, adems, el reenv de o o a o cheros a cualquier dispositivo. - Opciones de conguracin o La interfaz grca de la aplicacin Bluepills permite ajustar ciertas opa o ciones sobre la conguracin de las sesiones. Estas opciones son: o Cargar los datos del chero de usuarios. Cargar los datos del chero de grupos de usuarios. Ajustar el tamao mximo total (en Megabytes) de los cheros a enviar, n a contenidos en el directorio seleccionado. Ajustar el tiempo de espera (en segundos), durante una sesin, entre nuevas o bsquedas de dispositivos. u

 4.3. MODULO GRAFICO

67

Figura 4.8: Diagrama de ujo: Sesin a travs de la interfaz de usuario o e

68

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

4.3.2.

Estructura de clases del Mdulo Grco o a

El Mdulo Grco est compuesto principalmente por cuatro clases princio a a pales y un conjunto de clases auxiliares, contenidas todas ellas en el paquete Java GUI (Graphical User Interface). La funcionalidad de las clases principales se describe a continuacin: o JFrame Main Constituye la clase principal que contiene el mtodo main(), de donde e parte el hilo principal de ejecucin de toda la aplicacin. Construye e inicializa o o todos los elementos grcos de la aplicacin (ventanas, botones, mens...). a o u Posee mltiples mtodos que reaccionan ante eventos de usuario (pulsacin de u e o botones, seleccin de mens...), actuando en consecuencia. Se relaciona con el o u Mdulo Bluetooth invocando sus mtodos a travs de una instancia de la clase o e e BTManager. SearchWorker Hereda de la clase SwingWorker (ver seccin 2.4.3), por lo crea un hilo o de ejecucin independiente que evita el bloqueo de la aplicacin. A travs de o o e la instancia de la clase BTManager, invoca una bsqueda rpida de dispositivos u a remotos (ver seccin 4.3.1). Una vez terminado el proceso de bsqueda, aade o u n los datos de los dispositivos encontrados en una tabla mostrada en la interfaz grca. a SessionWorker Al igual que SearchWorker, hereda de la clase SwingWorker. Utilizando la instancia de la clase BTManager, implementa el desarrollo de una sesin o Bluepills, a travs de sus mtodos correspondientes. En funcin de la interaccin e e o o del usuario con los botones correspondientes, arranca o detiene la sesin con los o parmetros seleccionados (tipo de sesin y opciones de conguracin). a o o LogWriter Imprime mensajes de seguimiento en un cuadro de texto de la interfaz grca. Estos mensajes muestran la hora y la accin que va realizando la a o aplicacin en cada momento (bsqueda de dispositivos, env de cheros a un o u o

 4.3. MODULO GRAFICO

69

determinado dispositivo Bluetooth, errores...). La instancia de esta clase, por tanto, es invocada oportunamente por el resto de clases de la aplicacin. o

70

CAP ITULO 4. DESARROLLO DE LA APLICACION BLUEPILLS

4.4.
4.4.1.

Mdulo de Datos o
Estructura de clases del Mdulo de Datos o

El Mdulo de Datos est constituido por un conjunto de clases Java, contenio a das en el paquete users, que gestionan las estructuras de datos internas asociadas a los cheros de datos y que son compartidas por los tres mdulos. Para evitar o el acceso concurrente o simultneo a dichos datos (lectura o escritura), lo que a provocar inconsistencia en los mismos, se utilizan mtodos sincronizados [15]. a e La funcionalidad de cada una de las clases de describe a continuacin: o UsersManager Gestiona la lectura y escritura de datos relacionados con los usuarios registrados, contenidos inicialmente en el chero de usuarios. La estructura de dichos datos consiste en un vector de clases de tipo RegisteredUser, con una instancia por cada usuario registrado. GroupsManager Gestiona la lectura y escritura de datos relacionados con los grupos de usuarios, contenidos inicialmente en el chero de grupos de usuarios. La estructura de dichos datos consiste en un vector de clases de tipo UsersGroup, con una instancia por cada grupo de usuarios registrados. SessionsFilesManager Gestiona la lectura y escritura de datos relacionados con las sesiones Bluepills, que posteriormente pueden almacenarse en un chero de sesiones. La estructura de dichos datos consiste en un vector de clases de tipo SessionsFileUser, con una instancia por cada usuario asociado a las sesiones. CsvReader y CsvWriter Implementan la lectura y la escritura, respectivamente, de cualquier chero en formato CSV, facilitando el proceso al resto de clases. Ambas clases estn contenidas en el subpaquete users.javacsv. Pertenecen a la librer Java a a CSV [14], diseada por Bruce Dunwiddie. n

Cap tulo 5 Desarrollo de la aplicacin Web o Bluepills

Como se coment en el cap o tulo 3, antes de que el usuario del equipo Bluetooth inicie una sesin de env de cheros, es necesario que los usuarios nales se o o registren en el sistema a travs de la aplicacin Web de registro. En las siguientes e o secciones se describen las caracter sticas y la funcionalidad de dicha aplicacin o Web, as como su estructura.

5.1.

Modelo de la aplicacin Web o

La aplicacin Web Bluepills ha sido desarrollada con la tecnolog J2EE (Java o a 2 Enterprise Edition) de Java, utilizando para ello tanto servlets como JSPs (ver seccin 2.5). Como servidor de la aplicacin Web se ha utilizado Apache Tomcat o o 6.0 (ver anexo C). La aplicacin Web Bluepills, como cualquier aplicacin J2EE, est compuesta o o a por una serie de componentes Web (servlets, JSPs...) residentes en el contenedor Web del servidor de aplicaciones. El contenedor es un entorno de ejecucin que o gestiona los componentes, los cuales deben cumplir el contrato que establece el contenedor. Ese contrato no es ms que un conjunto de mtodos que debe implea e mentar el componente y que permite al contenedor interactuar con l. Adems, e a cada contenedor proporciona una serie de servicios que el componente puede utilizar. El contenedor es adems el encargado de gestionar el ciclo de vida de los a componentes y realizar la reserva de recursos.

71

 72 CAP ITULO 5. DESARROLLO DE LA APLICACION WEB BLUEPILLS Cada mdulo Web dispone de un descriptor de despliegue (ver seccin C.2.2) o o que describe cmo se deben desplegar los componentes de dicho mdulo dentro o o del servidor de aplicaciones. Existen adems varias formas de empaquetar un a mdulo Web; en este caso se ha utilizado un archivo WAR (Web Application o Archive), el cual permite empaquetar en una sola unidad una o varias aplicaciones Web completas, constituidas por servlets, pginas JSP, pginas HTML estticas, a a a imgenes y otros recursos Web. a En la gura 5.1 se muestra un diagrama de los elementos implicados en el acceso a la aplicacin Web. El usuario nal, utilizando un navegador Web, accede o a la aplicacin Web Bluepills a travs de la URL correspondiente. El servidor Web, o e por su parte, responde a travs del contenedor de aplicaciones a cada peticin e o del recurso Web solicitado, actuando en consecuencia. En caso de que el recurso sea un documento HTML esttico, como ocurre en el acceso a la pgina principal a a de la aplicacin Web, el servidor devuelve dicho documento. En caso de que el o recurso sea un servlet o una pgina JSP, el contenedor crea un hilo asociado a a la instancia del servlet y, a travs del mtodo service(), determina lo que e e ha llegado en la peticin y devuelve una respuesta dinmicamente, en forma de o a documento HTML.

Figura 5.1: Modelo de la aplicacin Web Bluepills o

 5.2. FUNCIONALIDAD DE LA APLICACION WEB

73

5.2.

Funcionalidad de la aplicacin Web o

La funcionalidad principal de la aplicacin Web Bluepills es la de registrar o los terminales mviles de los usuarios nales que, posteriormente, utilizarn el o a servicio ofrecido por la aplicacin Bluepills. o En la imagen de la gura 5.2 se muestra el aspecto que presenta la pgina a principal de la aplicacin Web. Cuando un usuario accede a la misma, sta le o e permite seleccionar dos perles distintos de acceso: de usuario (User Prole) y de administrador (Administrator Prole). Para acceder a la aplicacin con cualquieo ra de ambos perles, es necesario introducir una contrasea o clave de acceso, n distinta para cada perl. Dichas contraseas son conguradas por el gestor de la n aplicacin Web, a travs del descriptor de despliegue asociado (ver seccin C.2.2). o e o En las siguientes subsecciones se analiza la funcionalidad de la aplicacin Web o desde el punto de vista de ambos perles.

Figura 5.2: Interfaz grca de la aplicacin Web Bluepills a o

 74 CAP ITULO 5. DESARROLLO DE LA APLICACION WEB BLUEPILLS

5.2.1.

Perl de Usuario

El perl de usuario permite que los usuarios nales del sistema registren los datos de sus terminales mviles antes de utilizar el servicio Bluepills. Una vez o que el usuario ha introducido correctamente su clave de acceso (la cual es comn u para todos los usuarios del sistema), se solicita al usuario los siguientes datos que sern almacenados en el chero de usuarios (ver seccin 3.4.1): Nombre de a o Usuario (User Name) y Nombre del Dispositivo (Friendly Name). Aunque el chero de usuarios tambin almacena la Direccin F e o sica (Bluetooth Address) del dispositivo mvil, habitualmente el terminal no facilita ese dato al usuario. Es o por ello que, posteriormente, cuando se importe el chero de usuarios al utilizar la aplicacin Bluepills, sta actualizar la Direccin F o e a o sica del terminal de usuario, una vez encontrado el dispositivo (ver seccin 4.2.3). Adems, si pasado un o a tiempo el usuario cambia de terminal pero contina usando el mismo Nombre u de Dispositivo, en la siguiente sesin la aplicacin Bluepills actualizar el dato o o a de la Direccin F o sica del dispositivo. Por otro lado, si el usuario decide cambiar el Nombre del Dispositivo en su terminal, la aplicacin Bluepills actualiza ese o dato en el chero. En resumen, puede decirse que siempre y cuando el usuario nal conserve alguno de los dos identicadores de su terminal (Direccin F o sica o Nombre del Dispositivo) la aplicacin Bluepills mantiene la coherencia con el o chero de usuarios, actualizndolo convenientemente. a

Figura 5.3: Aplicacin Web Bluepills: Perl de Usuario o

 5.2. FUNCIONALIDAD DE LA APLICACION WEB

75

Adems de registrar los datos de su terminal, la aplicacin permite al usuario a o inscribirse a uno o ms grupos de usuarios. Tras cargar los datos del chero a de grupos, la aplicacin Web muestra al usuario una tabla con los nombres de o los grupos existentes y sus identicadores (ver seccin 3.4.2). El usuario puede o marcar los grupos a los que desea pertenecer, marcando uno, varios o ninguno de los grupos. Tras cumplimentar todos los datos, una vez pulsado el botn Conrm Regiso ter la aplicacin Web aadir los datos del usuario al chero de usuarios. Si por o n a el contrario el usuario decide cancelar la inscripcin pulsando Exit Register , o ningn dato quedar registrado. En caso de que alguno de los datos introducidos u a sea errneo o est en blanco, la aplicacin muestra un mensaje de error. Si al o e o registrarse un usuario no existe previamente el chero de usuarios, la aplicacin o Web lo crea.

5.2.2.

Perl de Administrador

Un usuario con perl de administrador puede acceder a la informacin conteo nida tanto en el chero de usuarios como en el chero de grupos. Tras introducir la clave de acceso correspondiente, la aplicacin Web muestra un men con las o u siguientes opciones al usuario: Registered Users: Muestra una tabla con la informacin de los usuarios o registrados en el chero de usuarios. Permite modicar cualquiera de los datos de un usuario o eliminar un usuario. Groups of Users: Muestra una tabla con la informacin de los grupos del o chero de grupos. Permite aadir un nuevo grupo, modicar cualquiera de n los datos de un grupo o eliminar un grupo. Si alguno de los datos es introducido incorrectamente, la aplicacin Web mueso tra un mensaje de error. Si al aadir un grupo no existe previamente el chero n de grupos, la aplicacin Web lo crea. o

 76 CAP ITULO 5. DESARROLLO DE LA APLICACION WEB BLUEPILLS

5.3.

Estructura de la aplicacin Web o

Como se coment al principio del cap o tulo, la aplicacin Web Bluepills o est compuesta por un conjunto de componentes Web: servlets, JSPs y docua mentos HTML. Los servlets y JSPs se han utilizado para generar dinmicamente a el contenido de las pginas Web de la aplicacin, mientras que para pginas Web a o a estticas (como la pgina de inicio de la aplicacin) se ha utilizado cdigo HTML a a o o directamente. Aunque cualquier aplicacin Web puede desarrollarse utilizando exclusivao mente servlets o JSPs, suele ser habitual utilizar servlets para procesar los datos de entrada y salida, y JSPs para construir el contenido HTML que se devuelve en cada respuesta al cliente Web. En nuestro caso, sa ha sido la solucin adoptada, e o y su descripcin y funcionamiento se describe en las siguientes subsecciones. o

5.3.1.

Dise o de servlets n

La funciones principales de los servlets dentro de la aplicacin Web Bluepills o son las siguientes: Redirigir las peticiones HTTP de los clientes Web al JSP correspondiente, en funcin de los parmetros recibidos (pulsacin de botones, contenido de o a o los campos en los formularios...). Controlar el acceso a los recursos Web de la aplicacin, limitndolo a usuao a rios y administradores autorizados. Gestionar el acceso a los cheros de usuarios y de grupos, tanto de lectura como de escritura. Cada servlet en Java contiene una unica instancia de clase, pero por cada peticin HTTP de un cliente distinto se crea un hilo de ejecucin independiente. o o A diferencia de las variables locales de mtodo, que son unicas para cada hilo, los e atributos de clase son compartidos por todos los hilos de la instancia. El servidor Web permite el acceso simultneo de varios clientes (ya sea con perl de usuario a o administrador), por lo que a n evitar inconsistencia en los datos de los cheros se ha utilizado la sincronizacin de hilos proporcionada por la tecnolog Java. o a Los servlets desarrollados son clases que heredan de la clase HttpServlet del paquete javax.servlet de Java. Implementan dos mtodos principales: e

 5.3. ESTRUCTURA DE LA APLICACION WEB

77

init(): Es invocado al instanciar el servlet cuando el primer usuario accede a la URL del mismo, una vez arrancado el servidor Web. Suele emplearse para inicializar variables o conguraciones del servlet. doPost(): El mtodo heredado service() invoca al mtodo correspondiene e te en funcin del tipo de peticin HTTP recibida. En el caso de peticiones o o POST, el mtodo service() invoca a este mtodo. En el caso de peticioe e nes GET (peticin HTTP por defecto), el mtodo service() invocar al o e a mtodo doGet(). e La aplicacin Web Bluepills consta de dos servlets, cuya funcionalidad se o describe a continuacin: o AccessServlet A travs de su mtodo doPost(), gestiona el acceso a la aplicacin Web e e o mediante una clave de acceso (de usuario o administrador) almacenada en el descriptor de despliegue, y que se obtiene previamente en su mtodo init(). e Una vez vericada dicha clave, el estado de acceso del usuario (permitido o denegado) queda almacenado en una variable de sesin compartida por todos los o servlets de la aplicacin Web, pero asociada unicamente a ese hilo de usuario. o La creacin y modicacin de variables de sesin se implementa gracias a una o o o instancia de la clase HttpSession. Una vez que el usuario sale de la aplicacin o Web a travs de la opcin correspondiente, el estado de la variable de sesin e o o cambia a estado denegado. ProcessServlet Su mtodo init() crea las estructuras de datos de usuarios y de grue pos, a partir de la lectura de los cheros correspondientes. La lectura (y escritura) de estos cheros se realiza a travs del paquete users, utilizado e tambin en la aplicacin Bluepills (ver seccin 4.4). El mtodo doPost(), e o o e por su parte, se encarga de redirigir las peticiones HTTP del cliente Web al JSP correspondiente, pasndole por parmetro los argumentos pertinentes, en a a funcin de las acciones realizadas por el usuario. Antes de redirigir la peticin, o o no obstante, se comprueba la autorizacin de acceso del usuario, a travs de la o e variable de sesin compartida con la clase AccessServlet. o

 78 CAP ITULO 5. DESARROLLO DE LA APLICACION WEB BLUEPILLS

5.3.2.

Dise o de JSPs n

La funcin principal de los JSPs es la de generar la salida HTML que se deo vuelve en la respuesta HTTP, de manera dinmica. La aplicacin Web Bluepills a o est constituida por varios cheros JSP, cada uno de los cuales muestra un cona tenido distinto en funcin de la navegacin del usuario a lo largo de la misma. La o o gura 5.4 muestra la relacin entre los servlets y los JSPs durante una secuencia o de peticiones HTTP del cliente, y que se resume en los siguientes puntos: 1. El usuario, al acceder a la URL de la aplicacin a travs del cliente Web, o e recibe como respuesta del servidor la pgina HTML de inicio: index.html a (ver gura 5.2). En esta pgina se solicita al usuario el tipo de perl y una a clave de acceso. 2. Tras seleccionar un perl, introducir la clave de acceso y seleccionar el botn HTML correspondiente, el cliente Web solicita el recurso servlet o AccessServlet mediante una peticin HTTP POST con los parmetros o a introducidos. 3. La clase AccessServlet verica el perl seleccionado y la clave de acceso, y redirige la peticin y la respuesta HTTP a la pgina JSP correspondiente. o a 4. La pgina JSP genera dinmicamente el cdigo HTML de respuesta, que a a o devuelve en la respuesta HTTP. 5. Cualquier nueva peticin HTTP solicitada a continuacin es referenciada al o o recurso ProcessServlet, que se encarga de procesarla. 6. El servlet ProcessServlet procesa la peticin, realiza las operaciones de o entrada y salida pertinentes, y redirige la peticin y la respuesta HTTP a o la pgina JSP correspondiente. a 7. Si en cualquier momento el usuario selecciona la opcin de salir de la aplio cacin, el servlet ProcessServlet redirige la peticin y la respuesta HTTP o o a la pgina HTML de inicio. a Los cheros JSP, a diferencia de los servlets, que son clases Java, son documentos planos de texto. Su contenido es similar al de un documento HTML, con la salvedad de que en determinadas zonas se incluyen etiquetas XML especiales encargadas de generar el contenido dinmico de la pgina. Este formato facilita a a el diseo grco de la aplicacin Web pero, a nivel interno, el JSP es traducido n a o por el servidor Web a un servlet. Para ms informacin sobre servlets y JSPs, a o vase [10]. e

 5.3. ESTRUCTURA DE LA APLICACION WEB

79

Figura 5.4: Diagrama de ujo de la aplicacin Web Bluepills o

 80 CAP ITULO 5. DESARROLLO DE LA APLICACION WEB BLUEPILLS

Cap tulo 6 Pruebas

En este cap tulo se muestra el resultado de las distintas pruebas realizadas al sistema Bluepills. Primeramente, se han realizado pruebas sobre la aplicacin Web o de registro, generando y modicando datos de los distintos cheros de usuarios y grupos. A continuacin, se han realizado distintas pruebas sobre la aplicacin o o Bluepills, importando los cheros creados en la aplicacin Web, y utilizando diso tintos terminales mviles. o

6.1.

Bater de pruebas de la Aplicacin Web a o Bluepills

En el caso de la Aplicacin Web Bluepills, se han realizado cuatro tipos de o pruebas: 1. Pruebas de creacin, modicacin y eliminacin de grupos de usuarios, utio o o lizando el perl de Administrador. 2. Pruebas de creacin de nuevos usuarios, utilizando el perl de Usuario. o 3. Pruebas de modicacin y eliminacin de los datos de usuarios existentes, o o utilizando el perl de Administrador. 4. Pruebas de acceso simultneo a la aplicacin Web de varios usuarios con a o distintos perles. En las siguientes tablas se muestran los resultados obtenidos en las distintas pruebas realizadas: 81

82

CAP ITULO 6. PRUEBAS

PRUEBA I: GESTION DE GRUPOS DE USUARIOS Utilizando el perl de Administrador, se realizan pruebas de creacin, modicacin y eliminacin de grupos de usuarios. o o o Se obtienen resultados satisfactorios en las siguientes pruebas: - Creacin de un grupo de usuarios. o - Visualizacin de los datos de los grupos existentes. o - Modicacin de los datos de un grupo de usuarios existente. o - Eliminacin de un grupo de usuarios existente. o - Si el chero de grupos no existe al aadir un grupo de usuarios, n la aplicacin lo crea. o - Al aadir o modicar un chero de grupos, la aplicacin comn o prueba previamente que ninguno de los datos coincide con alguno de los grupos ya existentes.

DESCRIPCION RESULTADO

OBSERVACIONES

DESCRIPCION RESULTADO OBSERVACIONES

PRUEBA II: CREACION DE NUEVOS USUARIOS Utilizando el perl de Usuario, se realizan pruebas de creacin de o nuevos usuarios. Se obtienen resultados satisfactorios en las siguientes pruebas: - Creacin de un nuevo usuario. o - Si el chero de usuarios no existe al aadir el nuevo usuario, la n aplicacin lo crea. o - Al crear el nuevo usuario, la aplicacin comprueba previamente o que ninguno de los datos coincide con alguno de los usuarios ya existentes. - La aplicacin carga correctamente los datos de los grupos exiso tentes a los que puede suscribirse el usuario.

DESCRIPCION RESULTADO

OBSERVACIONES

PRUEBA III: GESTION DE USUARIOS Utilizando el perl de Administrador, se realizan pruebas de modicacin y eliminacin de usuarios. o o Se obtienen resultados satisfactorios en las siguientes pruebas: - Visualizacin de los datos de los usuarios existentes. o - Modicacin de los datos de un usuario existente. o - Eliminacin de un usuario existente. o - Al modicar los datos de un usuario, la aplicacin comprueba o previamente que ninguno de los datos coincide con alguno de los usuarios ya existentes.

 6.1. BATER DE PRUEBAS DE LA APLICACION WEB BLUEPILLS IA

83

PRUEBA IV: ACCESO SIMULTANEO A LA APLICA CION DESCRIPCION RESULTADO Utilizando varios equipos conectados a la aplicacin Web, se reao lizan pruebas de creacin y modicacin simultnea de datos. o o a Se obtienen resultados satisfactorios en las siguientes pruebas: - Dos usuarios crean un usuario simultneamente. a - Un usuario crea un usuario mientras que el administrador modica los datos de otro usuario.

OBSERVACIONES

84

CAP ITULO 6. PRUEBAS

6.2.

Bater de pruebas de la Aplicacin Bluea o pills

A continuacin se muestran los resultados de las distintas pruebas realizadas a la Aplicacin o o Bluepills, cuyos objetivos son: Vericar el correcto funcionamiento de la aplicacin, en distintos escenarios. o Comparar las prestaciones obtenidas en terminales de distintos modelos y fabricantes. Realizar medidas aproximadas del tiempo de transmisin de los cheros a los terminales, o utilizando cheros de distintos tamaos. n Analizar cmo inuye la distancia en la transmisin de los cheros. o o PRUEBA I: SESION CON UN TERMINAL. DISTINTOS FABRICANTES Sesin de env de un chero con un unico terminal, de distintos o o modelos y fabricantes. Terminal mvil: o - Nokia 6555 - Nokia 2730 - Sony Ericsson Z750i - Samsung Omnia II Ficheros: - Imagen BMP (6KB) - La transmisin del chero se realiza con xito en todos los tero e minales. - En el caso de que el usuario rechace o interrumpa la transmisin, o se muestra el pertinente mensaje en la aplicacin. o - El mensaje de solicitud de conexin var para cada terminal. No o a obstante, en todos los casos el terminal insta al usuario a escoger entre dos opciones: aceptar o rechazar la recepcin del chero. o - En algunos terminales (Nokia), en el caso de que el usuario no responda a la solicitud de conexin, el terminal rechaza la coneo xin automticamente, pasados 45 segundos. En otros terminales o a (Sony Ericsson, Samsung), el terminal contina a la espera indeu nidamente.

DESCRIPCION ELEMENTOS

RESULTADOS

OBSERVACIONES

 6.2. BATER DE PRUEBAS DE LA APLICACION BLUEPILLS IA

85

DESCRIPCION

ELEMENTOS

RESULTADOS

OBSERVACIONES

PRUEBA II: SESION CON TRES TERMINALES. DISTINTOS MODOS DE ENV IO Sesin de env de cheros con tres terminales, utilizando las diso o tintas modalidades de env Se utiliza un chero de usuarios en o. el que algunos datos de los terminales (nombre del dispositivo o direccin f o sica) dieren de los actuales. Tambin se utiliza un e chero de grupos. Terminales mviles: o - Nokia 6555 - Nokia 2730 - Sony Ericsson Z750i Ficheros: - Fichero PDF (229KB) - Imagen BMP (6KB) - Fichero TXT (1KB) - Los cheros se reciben correctamente en los tres terminales. - El chero de usuarios se actualiza correctamente con los nuevos datos de los terminales. Varias sesiones con distintas modalidades de env o: - Usuarios registrados: Los cheros se env unicamente a los an usuarios registrados en el chero de usuarios. - Todos los dispositivos: Los cheros se env a todos los dispoan sitivos. - Grupos de usuarios: Los cheros se env unicamente a los an usuarios pertenecientes a un determinado grupo de usuarios. - En algunos terminales (Nokia), la solicitud de conexin concierne o a todos los cheros a recibir. En otros terminales (Sony Ericsson), el terminal solicita conrmacin al usuario por cada uno de los o cheros.

86

CAP ITULO 6. PRUEBAS

PRUEBA III: SESION CON VARIOS TERMINALES. FICHEROS DE GRAN TAMANO Sesin de env de un chero de gran tamao, a uno, dos y tres o o n terminales. Todos los terminales aceptan la recepcin del chero o simultneamente. a Terminales mviles: o - Nokia 6555 - Nokia 2730 - Sony Ericsson Z750i Ficheros: - Fichero MP3 (5MB) - El chero se recibe correctamente en los terminales, aunque no de manera simultnea. a Tiempo total de recepcin del chero en los terminales o (aproximado): - 1 terminal: 2 minutos, 30 segundos - 2 terminales: 5 minutos - 3 terminales: 6 minutos, 30 segundos - El tiempo de recepcin del chero en cada terminal es variable, o aunque ligeramente menor en los terminales Nokia. - En algunos terminales (Nokia), si no hay memoria suciente para almacenar el chero, la transmisin no se realiza correctamente o y la conexin debe ser interrumpida por el usuario. En otros tero minales (Sony Ericsson), el terminal comprueba previamente si dispone de memoria suciente, antes de iniciar la conexin. o

DESCRIPCION

ELEMENTOS

RESULTADOS

OBSERVACIONES

DESCRIPCION ELEMENTOS

RESULTADOS

PRUEBA IV: SESION CON VARIOS TERMINALES. FICHEROS DE TAMANO MEDIO Sesin de env de varios cheros a tres terminales. Todos los o o terminales aceptan la recepcin del chero simultneamente. o a Terminales mviles: o - Nokia 6555 - Nokia 2730 - Sony Ericsson Z750i Ficheros: - Fichero MP3 (2MB) - Imagen BMP (6KB) - Los cheros se reciben correctamente en los terminales, aunque no de manera simultnea. a Tiempo total de recepcin del chero en los terminales o (aproximado): - 3 terminales: 2 minutos

OBSERVACIONES

 6.2. BATER DE PRUEBAS DE LA APLICACION BLUEPILLS IA

87

DESCRIPCION

ELEMENTOS

RESULTADOS OBSERVACIONES

PRUEBA V: SESION CON VARIOS TERMINALES. PRUEBAS DE SESION Sesin de env de varios cheros a dos terminales, ejecutando los o o siguientes pasos: - Se inicia la sesin con unico terminal activo. o - Tras detener la sesin, se almacenan los datos de la sesin en un o o nuevo chero de sesiones. - Se arranca de nuevo la sesin, y se activa el segundo terminal. o - Se detiene la sesin y se selecciona el modo de reenv de cheros, o o seleccionando ambos terminales. - Se desactiva el primer terminal y se arranca de nuevo la sesin. o - Tras detener la sesin, se selecciona un chero de sesiones exiso tente y se almacenan los datos de la sesin. o Terminales mviles: o - Nokia 6555 - Nokia 2730 Ficheros: - Imagen BMP (6KB) - Fichero TXT (1KB) Tras ejecutar la secuencia de pasos descrita, se obtiene el resultado satisfactorio esperado. - Tras la nueva bsqueda, la aplicacin aade el segundo dispou o n sitivo a la tabla de de dispositivos, y le transmite los cheros correctamente. - El reenv de cheros se realiza satisfactoriamente sobre el seo gundo terminal; en el caso del terminal desactivado, la aplicacin o muestra el pertinente mensaje, al no poder establecer la conexin. o - Al guardar el chero de sesiones existentes, se aaden los datos n del segundo terminal.

88

CAP ITULO 6. PRUEBAS

PRUEBA VI: SESION CON UN TERMINAL. PRUEBAS DE DISTANCIA Varias sesiones de env de cheros a un terminal, a distintas diso tancias. Terminal mvil: o - Nokia 6555 - Nokia 2730 Ficheros: - Fichero MP3 (5MB) Tiempo total de recepcin del chero en el termio nal(aproximado): - 1 metro: 2 minutos, 30 segundos - 2 metros: 3 minutos - 5 metros: 3 minutos, 20 segundos - 10 metros: 3 minutos, 40 segundos - En algunos terminales (Nokia 6555), el alcance mximo es muy a reducido: 3 metros. En otros terminales (Nokia 2730), el alcance es de unos 10 metros. - La transmisin de cheros no se realiza correctamente a travs o e de paredes o muros: la aplicacin detecta al dispositivo, pero la o conexin no se establece. o

DESCRIPCION ELEMENTOS

RESULTADOS

OBSERVACIONES

Cap tulo 7 Conclusiones y trabajos futuros

7.1. Conclusiones

El objetivo principal del proyecto ha sido el desarrollo de un sistema, denominado Bluepills, que permita el env de cheros o p o ldoras docentes desde el ordenador que utiliza el profesor o ponente a los terminales mviles de los asisteno tes. Este sistema, desarrollado ntegramente en el lenguaje de programacin Java, o se ha compuesto a su vez de dos herramientas software: una aplicacin grca o a principal y una aplicacin Web de registro de usuarios. o Dentro de los objetivos propuestos a priori (ver seccin 1.2), se han obtenido o los siguientes resultados: 1. A tenor de las pruebas realizadas, se ha podido comprobar que la aplicacin o Bluepills es compatible con terminales mviles de distintas marcas y modeo los, debido a que casi todos los terminales mviles del mercado implementan o el servicio OBEX Object Push. No obstante, al ser un estndar abierto, la a implementacin del perl OBEX Object Push diere ligeramente en cada o dispositivo, lo cual no perjudica al buen funcionamiento de la aplicacin. o 2. El sistema resulta ser sencillo y transparente al usuario nal, ya que ste e no necesita instalar ningn tipo de aplicacin o librer en su terminal. u o a 3. La aplicacin Bluepills presenta una interfaz grca con ventanas, botones o a y mens que facilitan su uso. Adems, al estar desarrollado en Java, es u a compatible con distintos sistemas operativos. 4. El sistema es capaz de transmitir consecutivamente varios cheros, de distinto tipo y tamao. n 89

90

CAP ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS 5. El sistema es capaz de diferenciar a los dispositivos Bluetooth de los asistentes del resto de dispositivos, atendiendo a un determinado tipo de criterio: usuarios registrados, grupo de usuarios o seleccin manual de dispositivos. o 6. La aplicacin proporciona un mecanismo de deteccin de errores en la transo o misin de los cheros, mostrando la informacin correspondiente, en tiempo o o real, en un cuadro de texto. 7. La aplicacin realiza un seguimiento de los usuarios de cada sesin, almao o cenando los datos en un chero.

El uso del perl OBEX Object Push requiere autorizacin en lugar de auo tenticacin (ver seccin 2.1.6), lo que evita que los usuarios de ambos extremos o o (equipo y terminal Bluetooth) tengan que introducir una clave de acceso compartida. La autorizacin, por su parte, asegura que la transferencia de cheros slo o o se realiza tras recibir el consentimiento por parte del usuario nal. Adems, como a se detalla en el desarrollo de la aplicacin Bluepills (ver cap o tulo 4), el proceso de transferencia de datos entre el equipo y cada uno de los terminales Bluetooth se delega en un hilo de Java independiente, lo que permite la transmisin simultnea o a y evita posibles bloqueos o errores en la aplicacin. o Uno de los inconvenientes de utilizar OBEX Object Push frente a otros servicios Bluetooth es que su uso est dirigido a terminales mviles, excluyendo a a o otros tipos de dispositivos, como ordenadores personales. Una alternativa a OBEX Object Push es OBEX File Transfer, el cual es compatible con ordenadores personales pero, por otro lado, presenta la desventaja de requerir autenticacin en o su uso. En lo que a velocidad de transferencia se reere, el estndar Bluetooth proa porciona unos valores inferiores a otros estndares radio de proximidad, como a puede ser Wi-Fi. En la siguiente tabla se muestra un resumen de los resultados obtenidos 1 en las pruebas realizadas (ver cap tulo 6), al enviar un chero a varios terminales Bluetooth, de manera simultnea: a
Tama o de chero Terminales Tiempo Velocidad de transferencia n 5 MB 1 150 seg 273 kb/s 5 MB 2 300 seg 273 kb/s 5 MB 3 390 seg 315 kb/s 2 MB 3 120 seg 410 kb/s Cuadro 7.1: Velocidad de transferencia en funcin del nmero de o u terminales NOTA: Los resultados de la tabla 7.1 se han obtenidos de manera aproximada, tras la ejecucin de varias simulaciones o
1

7.1. CONCLUSIONES

91

Como podemos observar en los resultados de la tabla anterior, el nmero de u usuarios inuye signicativamente en la velocidad total de transferencia. En el caso particular de cada terminal, la velocidad de transferencia depende de factores intr nsecos al medio radioelctrico (ruido, obstculos...) y de la versin Bluetooth e a o implementada (ver seccin 2.1.3). En el caso del equipo Bluetooth, donde reo side la aplicacin principal, las pruebas han sido realizadas con un dispositivo o hardware Bluetooth 2.1. Por tanto, con dispositivos que implementen las ultimas versiones del estndar, podr obtenerse velocidades superiores. Para cheros a an ms pequeos, los tiempos de transmisin se reducen. a n o Por otro lado, la distancia entre los dispositivos tambin inuye en la velocidad e 2 de transmisin, como muestran los resultados de la tabla 7.2. El alcance mximo o a es de unos 10 metros, tal y como determina el estndar. a
Tama o de chero Distancia Tiempo Velocidad de transferencia n 5 MB 1 metro 150 seg 273 kb/s 5 MB 2 metros 180 seg 228 kb/s 5 MB 5 metros 200 seg 205 kb/s 5 MB 10 metros 220 seg 186 kb/s Cuadro 7.2: Velocidad de transferencia en funcin de la distancia o

Con respecto a la aplicacin Web Bluepills, sta permite a los usuarios regiso e trar sus terminales mviles en el sistema, antes de utilizar el servicio de env de o o cheros ofrecido por la aplicacin principal. Para ello, los usuarios deben coneco tarse al servidor Web donde reside la aplicacin Web a travs de Internet o de o e una red local. Una vez que los datos de la aplicacin Web son importados por o la aplicacin principal, sta es capaz de detectar a los terminales de los usuarios o e tanto por el nombre como por la direccin f o sica Bluetooth. Adems, la aplicacin a o actualiza ambos datos en cada nueva bsqueda de dispositivos, lo que permite u que los usuarios puedan, en cualquier momento, cambiar de nombre o de terminal sin necesidad de realizar un nuevo registro. En su uso en el mbito docente, el env de p a o ldoras docentes a travs de e Bluepills estar optimizado para un grupo reducido de usuarios y para cheros a no demasiado grandes. No obstante, dicho escenario no plantea unos requisitos demasiado exigentes en cuanto a velocidad de transmisin, pues la sesin Bluepills o o puede establecerse paralelamente a la imparticin de la clase. o

NOTA: Los resultados de la tabla 7.2 se han obtenidos de manera aproximada, tras la ejecucin de varias simulaciones o

92

CAP ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS

Adicionalmente, el uso de la aplicacin Bluepills podr extenderse a otros o a ambitos en los que se requiera el env de pequeos cheros a dispositivos mviles, o n o de manera local, dada la versatilidad que sta ofrece. e

7.2.

L neas de trabajo futuro

Uno de los aspectos a analizar, en estudios posteriores, es el impacto en la aplicacin Bluepills de un nmero elevado de usuarios. Como se describe en la o u seccin 2.1.2, una red piconet permite un mximo de siete dispositivos esclao a vos conectados a un unico dispositivo maestro. El equipo Bluetooth, al iniciar las conexiones, ejerce de dispositivo maestro mientras que el resto de dispositivos (terminales Bluetooth) ejercen el papel de esclavos. Sin embargo, como se especica en los parmetros del servicio (ver seccin 4.2.4), estos roles pueden a o intercambiarse, permitiendo el establecimiento de nuevas redes piconet entre el equipo y los terminales Bluetooth. Esta conguracin permitir tericamente, o a, o establecer ms de siete conexiones simultneas. a a Dentro de este mismo estudio, se podr intentar determinar el nmero ptia u o mo de dispositivos que, conectados simultneamente, minimizan el tiempo total a de transferencia. Una vez hallado este valor, podr incluirse una modicacin en a o el cdigo que evite la transmisin simultnea por encima de ese umbral, manteo o a niendo al resto de dispositivos a la espera. Otra de las l neas de trabajo futuro podr consistir en desarrollar un nuevo a mecanismo de registro de usuarios, alternativo a la aplicacin Web Bluepills. o Utilizando una aplicacin desarrollada en J2ME, los usuarios podr registrar o an sus datos a travs del terminal mvil, mediante mensajes OBEX/Bluetooth. No e o obstante, este planteamiento exigir la transmisin previa de dicha aplicacin a o o de registro. En cualquier caso, el uso de un sistema de registro o de seguridad resulta imprescindible, pues garantiza la condencialidad de los cheros utilizados en cada sesin. o

Apndice A e Presupuesto
Al nal del presente documento se adjunta el presupuesto estimado para la realizacin del presente proyecto. El proyecto se ha desarrollado en cinco fases, o descritas en la seccin 1.3. La duracin total aproximada ha sido de siete meses. o o El presupuesto total del proyecto incluye el coste de los honorarios del Ingeniero y del material empleado. En relacin a este ultimo punto, se ha dispuesto o del siguiente equipamiento: Ordenador porttil: Utilizado para el desarrollo a ntegro del proyecto, as como para la realizacin de las pruebas realizadas sobre el sistema desa o rrollado (ver cap tulo 6). Adaptador Bluetooth: Dispositivo hardware conectado al ordenador prtatil, el cual permite la comunicacin Bluetooth con otros dispositivos. o o Terminales mviles: Utilizados para la realizacin de las pruebas sobre o o el sistema desarrollado. Atribuido a otros costes directos del proyecto, se ha incluido el coste de la conexin a Internet durante los siete meses de duracin del proyecto, necesaria o o para la bsqueda de documentacin, as como el consumo elctrico de los equipos. u o e El resto de gastos, como el IVA, se encuentran incluidos dentro de los costes indirectos del proyecto.

93

94

APENDICE A. PRESUPUESTO

Apndice B e Aplicacin Bluepills: Instalacin o o y Uso

B.1. Requisitos

Bluepills es una aplicacin desarrollada o ntegramente en Java, que utiliza la librer BlueCove (ver seccin 2.3.2) para poder utilizar funciones y servicios a o Bluetooth. Toda su estructura de clases Java se encuentra compilada en un unico chero comprimido: Bluepills.jar. No obstante, antes de ejecutar la aplicacin en el equipo, es necesario satisfacer o previamente los siguientes requisitos : Instalar el entorno de ejecucin de Java o JRE (Java Runtime Environo ment), disponible en http://www.java.com/es/download/. Descargar la librer BlueCove, disponible en http://bluecove.org/. a Disponer de un dispositivo hardware Bluetooth v1.2 o superior.

B.2.

Manual de Instalacin o

Una vez satisfechos los requisitos previos, la aplicacin Bluepills no requiere o de instalacin alguna salvo disponer, en el directorio ra en el que se encuentre o z el chero Bluepills.jar, los siguientes subdirectorios: 95

96

APENDICE B. APLICACION BLUEPILLS: INSTALACION Y USO \lib: Directorio de librer as, en el que debe incluirse el chero 1 bluecove-2.1.0 , correspondiente a la librer BlueCove. a \data: Directorio de datos de usuarios, en el que deben incluirse los cheros de usuarios y de grupos de usuarios.

B.3.
B.3.1.

Manual de Uso
Inicio de la aplicacin o

Para lanzar la aplicacin, basta con ejecutar el chero Bluepills.jar. Al o hacerlo, se muestra al usuario del equipo una ventana de programa con el siguiente aspecto:

Figura B.1: Elementos grcos de la aplicacin Bluepills a o

NOTA: La librer bluecove-2.1.0 funciona con cualquiera de las versiones del Sistea ma Operativo Windows. En el caso de utilizar otros sistemas operativos, consltese http: u //bluecove.org/

B.3. MANUAL DE USO

97

Como se muestra en la gura anterior, la ventana grca de la aplicacin a o Bluepills consta de los siguientes elementos: Barra de men s: Permite gestionar sesiones y modicar los parmetros u a de las mismas. Barra de botones: Permite realizar distintas acciones relacionadas con la sesin actual o con la bsqueda rpida de dispositivos. o u a Tablas de datos: Muestra tres tablas, divididas en pestaas, con informan cin sobre los dispositivos Bluetooth encontrados, los usuarios registrados o y los grupos de usuarios. Arbol de cheros: Muestra los cheros a enviar, tras seleccionar un directorio. Cuadro de informacin: Muestra un mensaje en tiempo real de la accin o o que est realizando la aplicacin, a nivel de sesin. a o o Cuadro de mensajes: Lleva un registro de los eventos que van ocurriendo en la aplicacin, a lo largo de su ejecucin. o o Al arrancar la aplicacin, sta trata de cargar los datos del chero de usuao e rios y del chero de grupos, automticamente. Para ello, estos cheros deben a estar ubicados en el subdirectorio \data, y poseer el nombre usersFile.csv y groupsFile.csv, respectivamente. Si por algn motivo, los cheros no se cargan u correctamente, el usuario puede volver a cargarlos a travs del men Settings. e u Ntese que para que la aplicacin Bluepills funcione, es necesario que sta diso o e ponga de un chero de usuarios vlido. El chero de grupos, no obstante, es a opcional. Una vez cargados los datos del chero de usuarios (y de grupos), stos se e muestran en sus correspondientes tablas de datos. A continuacin, el usuario del o equipo puede realizar una bsqueda rpida de dispositivos Bluetooth, pulsando el u a botn Quick Search. Una vez terminada la bsqueda, los datos de los dispositio u vos encontrados se muestran en la correspondiente tabla, lo que permite al usuario conocer a priori, antes de iniciar una sesin (ver seccin 4.3.1), qu dispositivos o o e Bluetooth se encuentran a su alcance.

98

APENDICE B. APLICACION BLUEPILLS: INSTALACION Y USO

B.3.2.

Sesiones en Bluepills

- Conguracin de la sesin o o A travs del men Settings - Options pueden congurarse los parmee u a tros de la sesin: o Tamao mximo permitido (en megabytes) de todo el conjunto de cheros n a a enviar. Tiempo de espera (en segundos) entre nuevas bsquedas de dispositivos. u - Inicio de sesin o Para iniciar una sesin, los pasos a seguir son los siguientes: o 1. Seleccionar el tem Session - New Session. 2. Pulsar el botn Select Files y seleccionar el directorio de cheros a enviar. o Si el tamao de los cheros excede el valor de la conguracin, muestra un n o mensaje de advertencia y la sesin no podr iniciarse. o a 3. A travs del submen Devices - Send Files To puede seleccionarse el tipo e u de dispositivos sobre los que realizar el env de cheros: o Usuarios registrados (valor por defecto). Todos los dispositivos. Grupo de usuarios. En este caso, el usuario debe seleccionar uno de los grupos de la pestaa de grupos, situada en la barra de botones. n 4. Al pulsar el botn Run Session, la sesin de env de cheros comienza. o o o - Gestin de la sesin o o Al arrancar la sesin, la aplicacin va transmitiendo los cheros seleco o cionados a todos los dispositivos Bluetooth circundantes que cumplan el criterio escogido anteriormente. Tras esto, la sesin queda detenida durante el tiempo o establecido en la conguracin de la sesin. A continuacin, la aplicacin realiza o o o o una bsqueda de nuevos dispositivos no encontrados anteriormente y, en caso de u encontrar alguno, lo aade a la sesin y le transmite los cheros. n o

B.3. MANUAL DE USO

99

En lo que respecta a los usuarios de los terminales mviles, stos reciben un o e mensaje de peticin de conexin antes de iniciar la transferencia de cheros v o o a Bluetooth. Si el terminal no soporta el servicio OBEX Object Push o la solicitud de conexin no logra establecerse, se muestra el siguiente mensaje: o ERROR: Connection couldnt be stablished with device Por el contrario, si la solicitud de conexin se recibe correctamente, a contio nuacin pueden aparecer varios tipos de mensajes: o 1. CONNECTION with device STARTED: Indica que el usuario nal ha aceptado la solicitud de conexin y que la transmisin de cheros ha o o comenzado. 2. CONNECTION with device completed SUCCESSFULLY : Indica que la transmisin de cheros ha concluido satisfactoriamente. o 3. CONNECTION with device ABORTED: Indica que el usuario nal ha rechazado la solicitud de conexin o que la transmisin de cheros o o ha sido interrumpida antes de concluir. El proceso de bsqueda de nuevos dispositivos se repite c u clicamente hasta que el usuario pulsa el botn Stop Session. Una vez detenida la sesin, el usuario o o puede observar ciertos parmetros de los dispositivos de la sesin, a travs de la a o e correspondiente tabla: Resend : Indica que la opcin de reenv de cheros est habilitada. o o a Friendly Name: Nombre del dispositivo. BT Address: Direccin F o sica del dispositivo. User Name: Nombre del usuario asociado al dispositivo, en caso de estar registrado. Registered : Indica que el dispositivo se encuentra registrado. Request Sent: Indica que la solicitud de conexin ha sido enviada al dispoo sitivo. Session Saved : Indica que la sesin ha sido guardada en el chero de sesioo nes.

100

APENDICE B. APLICACION BLUEPILLS: INSTALACION Y USO BT Activated : Indica que el dispositivo continuaba activo en la ultima bsqueda. u

Figura B.2: Tabla de dispositivos Bluetooth A continuacin, puede arrancarse de nuevo la sesin pulsando el botn Start o o o Session. Antes de hacerlo, es posible cambiar el tipo de dispositivos de la sesin, o seleccionando el submen Devices - Send Files To. Opcionalmente, puede hau bilitarse el reenv de los cheros a uno o ms usuarios de la sesin, seleccionando o a o el submen Devices - Resend Files To - Selected Devices. u - Guardar datos de la sesin o Estando detenida la sesin, la aplicacin permite almacenar los datos de o o la sesin en un chero CSV (ver seccin 3.4.3). Para ello, el usuario debe: o o 1. Seleccionar una de las opciones del submen Session - Select Sessions u File: a) New Sessions File: Crea un nuevo chero de sesiones. b) Existing Sessions File: Selecciona un chero de sesiones existentes, al que aadir la sesin actual. n a o 2. Seleccionar el tem Session - Save Session: Guarda los datos de la sesin o (usuarios, fecha y cheros enviados) en el chero de sesiones seleccionado. - Finalizar la sesin o Para nalizar la sesin, el usuario del equipo debe pulsar el o tem Session - End Session. Al hacerlo, se perdern los datos de la sesin que no hayan a o sido guardados previamente.

Apndice C e Aplicacin Web: Instalacin y o o Uso

C.1. Manual de Instalacin de Apache Tomcat o

La aplicacin Web Bluepills est diseada en la tecnolog J2EE de Java. o a n a Su estructura de cheros est comprimida en un chero WAR, que debe ser a desplegado en un servidor Web. El servidor Web utilizado en el presente proyecto es el Apache Tomcat 6.0, cuyos pasos instalacin se describen a continuacin: o o 1. Instalar el entorno de ejecucin de Java o JRE (Java Runtime Environo ment), disponible en http://www.java.com/es/download/. 2. Descargar la distribucin binaria de Apache Tomcat 6.0, disponible en o http://tomcat.apache.org/, y descomprimirla en el directorio de programas del equipo. 3. Congurar una variable de entorno 1 en el equipo denominada JRE HOME, y asociarla a la ruta donde se encuentre instalado el JRE. Una vez instalado el servidor Apache Tomcat, ste se arranca ejecutando el e chero \bin\startup.bat. Anlogamente, para detener la ejecucin del servidor a o debe ejecutarse el chero \bin\shutdown.bat.
Las variables de entorno en Windows se conguran a travs del men Conguracin del e u o Sistema
1

101

102

APENDICE C. APLICACION WEB: INSTALACION Y USO

C.2.

Manual de Conguracin de Apache Tomo cat

Estructura de directorios de Tomcat

C.2.1.

El directorio ra donde se encuentra instalado Apache Tomcat consta de los z siguientes subdirectorios, los cuales contienen: \bin: Ficheros ejecutables de arranque y cierre. \conf: Ficheros XML de conguracin. o \logs: Ficheros de registro de eventos y errores. \webapps: Aplicaciones Web. \work: Ficheros y directorios temporales. Para que la aplicacin Web Bluepills se despliegue correctamente, es necesario o ubicar previamente el chero Bluepills webapp.war en el directorio \webapps de Apache Tomcat, antes de arrancar el servidor. Una vez arrancado el servidor, es posible acceder al gestor Tomcat a travs de e la URL http://localhost:8080/. Al hacerlo, es necesario introducir un nombre de usuario y contrasea, congurados en el chero \conf\tomcat-users.xml de n la aplicacin. o

C.2.2.

Descriptor de despliegue

El subdirectorio \WEB-INF de la aplicacin Web, adems de contener los sero a vlets de la aplicacin, contiene el chero web.xml, denominado descriptor de o despliegue. Este chero permite, entre otras cosas, declarar servlets y asignarles parmetros. En el caso de la Aplicacin Web Bluepills, el descriptor de despliegue a o contiene los siguientes parmetros congurables: a userAccessKey: Contiene la clave de acceso del perl de Usuario. adminAccessKey: Contiene la clave de acceso del perl de Administrador. usersFilePath: Contiene la ruta de ubicacin del chero de usuarios. o groupsFilePath: Contiene la ruta de ubicacin del chero de grupos. o

C.3. MANUAL DE USO

103

C.3.
C.3.1.

Manual de Uso
Acceso a la aplicacin Web o

Una vez arrancado el servidor Tomcat, los distintos usuarios de la aplicacin o Web pueden acceder a la misma a travs de la siguiente URL (siendo <host> el e nombre o direccin IP del servidor): o http://<host>:8080/Bluepills_webapp La pgina principal de la aplicacin Web solicita al usuario que escoja entre a o perl de usuario o administrador, y que introduzca su clave de acceso correspondiente.

C.3.2.

Perl de Usuario

El perl de usuario permite la creacin de un nuevo usuario en el sistema o Bluepills. Los datos que el nuevo usuario debe introducir son los siguientes: User Name: Nombre de usuario del sistema Bluepills. Identica un vocamente al usuario nal con un terminal mvil. o Friendly Name: Nombre del dispositivo mvil. Este dato debe ser cono gurado previamente en las opciones Bluetooth del terminal. Groups: Grupos a los que el usuario desea pertenecer. Puede seleccionar uno, varios o ninguno. Una vez introducidos los datos, el usuario debe pulsar el botn Conrm o Register para que los datos queden almacenados en el servidor. Si alguno de los datos introducidos es errneo o coincide con alguno de los usuarios existentes, la o aplicacin muestra un mensaje de error y el usuario deber introducir sus datos o a de nuevo.

104

APENDICE C. APLICACION WEB: INSTALACION Y USO

C.3.3.

Perl de Administrador

El perl de administrador permite visualizar los datos registrados en el sistema Bluepills, as como hacer modicaciones en los mismos. Una vez que el adminis trador accede al sistema, ste debe seleccionar una de las siguientes opciones de e men: u Show Registered Users: Muestra una tabla con los datos de los usuarios registrados en el sistema. Adicionalmente, el administrador puede modicar o eliminar algunos de los datos de los usuarios. Show Groups of Users: Muestra una tabla con los datos de los grupos registrados en el sistema. Adicionalmente, el administrador puede modicar o eliminar algunos de los datos de los grupos. Los datos de usuarios y grupos registrados se encuentran almacenados en dos cheros CSV, contenidos en la ubicacin indicada en los parmetros del descriptor o a de despliegue (ver C.2.2).

Bibliograf a
[1] Generic Object Exchange Prole Bluetooth Specication v1.1 2001. http://www.bluetooth.com/SiteCollectionDocuments/GOEP_SPEC_ V12.pdf [2] Object Push Prole Bluetooth Specication v1.1 2001. http://www.bluetooth.com/SiteCollectionDocuments/OPP_SPEC_V11. pdf [3] BlueCove http://bluecove.org [4] Bluetooth Application programming with the Java APIs Morgan Kaufmann Publishers KUMAR C Bala, KLINE P.J., THOMPSON T.J., 2004. [5] PFC: Seguridad en Bluetooth Universidad Ponticia Comillas Alberto Moreno Tablado, 2006. [6] Programacin de dispositivos Bluetooth a travs de Java o e JavaHispano. Alberto Gimeno Brieba http://www.javahispano.org/contenidos/es/jsr82_bluetooth_ desde_java/ [7] JSR 82 Bluetooth API and OBEX API http://download.oracle.com/javame/config/cldc/opt-pkgs/api/ bluetooth/jsr082/index.html

105

106

BIBLIOGRAF IA

[8] Swing y JFC (Java Foundation Classes) Programacin en castellano o http://www.programacion.com/articulo/swing_y_jfc_java_ foundation_classes_94 [9] The Java tutorials: Graphical User Interfaces http://download.oracle.com/javase/tutorial/ui/overview/intro. html [10] Beginning J2EE 1.4: From Novice to Professional Apress WEAVER James L., 2004 [11] Servlets y JSP http://distritos.telepolis.com/java/lib/manuales/servletsjsp. pdf [12] JavaTM 2 Platform Enterprise Edition 5.0 API Specication http://download.oracle.com/javaee/5/api/ [13] JavaTM 2 Platform Standard Edition 5.0 API Specication http://download.oracle.com/javase/1.5.0/docs/api/ [14] Librer Java CSV 2.1 a Bruce Dunwiddie http://www.csvreader.com [15] Sincronizacin de hilos en Java o Programacin en castellano o http://www.programacion.com/articulo/threads_de_control_100/14 [16] Introduccin a la tecnologa Bluetooth o Kioskea.net http://es.kioskea.net/contents/bluetooth/bluetooth-intro.php3 [17] Tecnologa Bluetooth Monograf as.com http://www.monografias.com/trabajos43/tecnologia-bluetooth/ tecnologia-bluetooth2.shtml [18] Diferencia entre las versiones de Bluetooth Bucfalo. Tecnolog y actualidad e a http://bucefalo.com.mx/diferencia-entre-las-versiones-de-bluetooth

A continuacin se anexa el presupuesto desglosado del proyecto, el cual asciende a la cantidad de 23.297 euros.

Legans, a 6 de julio de 2011 El ingeniero proyectista

Jorge Beca Baulenas

UNIVERSIDAD CARLOS III DE MADRID Escuela Politcnica Superior

PRESUPUESTO DE PROYECTO

1.- Autor: Jorge Beca Baulenas 2.- Departamento:

Ingeniera Telemtica

3.- Descripcin del Proyecto:

- Titulo - Duracin (meses) Tasa de costes Indirectos:
Bluepills: Envo de pldoras docentes a travs de Bluetooth 7 20%

4.- Presupuesto total del Proyecto (valores en Euros):

23.297 Euros

5.- Desglose presupuestario (costes directos)

PERSONAL N.I.F. (no rellenar solo a titulo informativo)

Apellidos y nombre

Categora
Ingeniero Senior Ingeniero Hombres mes

Dedicacin (hombres mes) a)

7 7

Coste hombre mes 4.289,54 2.694,39

Total

Coste (Euro) 0,00 18.860,73 18.860,73

Firma de conformidad

Beca Baulenas, Jorge

1050 horas
a)

1 Hombre mes = 131,25 horas. Mximo anual de dedicacin de 12 hombres mes (1575 horas) Mximo anual para PDI de la Universidad Carlos III de Madrid de 8,8 hombres mes (1.155 horas)
EQUIPOS

Descripcin Ordenador porttil - HP Pavilion Adaptador Bluetooth -Trust BT 2400P Telfono mvil - Nokia 6555 Telfono mvil - Nokia 2730 Telfono mvil - Sony Ericcson Z750i
d)

Coste (Euro) 800,00 12,00 150,00 80,00 120,00

1162

% Uso dedicado proyecto 100 100 100 100 100

Dedicacin (meses) 7 7 7 1 1

Periodo de depreciacin 60 60 60 60 60
Total

Coste imputable d) 93,33 1,40 17,50 1,33 2,00 115,57

Frmula de clculo de la Amortizacin: A = n de meses desde la fecha de facturacin en que el equipo es utilizado B = periodo de depreciacin (60 meses) C = coste del equipo (sin IVA) D = % del uso que se dedica al proyecto (habitualmente 100%) SUBCONTRATACIN DE TAREAS

A xCxD B

Descripcin

Empresa
Total

Coste imputable 0,00

OTROS COSTES DIRECTOS DEL PROYECTO

e)

Costes imputable 52,5 385,00 Total 437,50 e) Este captulo de gastos incluye todos los gastos no contemplados en los conceptos anteriores, por ejemplo: fungible, viajes y dietas,

Descripcin Consumo elctrico Conexin a Internet

Empresa Unin Fenosa Movistar

6.- Resumen de costes

Presupuesto Costes Totales Personal Amortizacin Subcontratacin de tareas Costes de funcionamiento Costes Indirectos Total
Presupuesto Costes Totales

18.861 116 0 438 3.883 23.297