Autorizada la entrega del proyecto del alumno: Carlos Cifuentes Fernández EL DIRECTOR DEL PROYECTO. David Contreras Bárcena

Transcripción

1 Autorizada la entrega del proyecto del alumno: EL DIRECTOR DEL PROYECTO David Contreras Bárcena Fdo.:. Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.:. Fecha: / /

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA SOSA BLUETOOTH MOBILE & SERVER DIRECTOR: DAVID CONTRERAS BÁRCENA AUTOR: CARLOS CIFUENTES FERNÁNDEZ MADRID, junio de 2005

3 AGRADECIMIENTOS Dedico el proyecto a todas las personas que me ha apoyado, en especial a Susana y a mi familia, que siempre me han estado motivando. También, quiero dar las gracias por todo el apoyo recibido, a mi director de proyecto David Contreras Bárcena, que en todo momento ha estado dispuesto a ayudarme en el desarrollo del mismo. I

4 RESUMEN La idea principal del proyecto nace en la optimización del proceso de control de asistencia del alumnado. Esta tarea, es realizada por cada profesor día tras día al comienzo de cada clase, acarreando grandes inconvenientes. El problema, no viene dado por el hecho de pasar lista, sino por todo el proceso posterior de registro en el PC, de las faltas y anotaciones que dicho profesor realiza en clase. Este proyecto, por lo tanto, agiliza y simplifica las tareas de pasar lista, realizar anotaciones en clase y, sobre todo, la transferencia de esa información a una base de datos centralizada en un PC, gracias a la tecnología inalámbrica Bluetooth, cada día más popular entre nosotros. Todo esto se traduce en la posibilidad de que el profesor realice sus anotaciones de clase a través de un potente interfaz gráfico en un dispositivo móvil (PDA o teléfono móvil) y cuando llegue a su ordenador personal, podrá transferir toda esa información de una forma cómoda y sin necesidad de utilizar cables. Además, el proyecto tiene un claro carácter innovador, ya que en la actualidad no existe ninguna aplicación desarrollada en Java, que sea capaz de establecer una comunicación Bluetooth mediante un dispositivo móvil (cliente) y un PC (servidor). El proyecto consta de dos aplicaciones, SOSA Bluetooth Mobile, la cual irá instalada en el dispositivo móvil y formará la aplicación cliente, y SOSA Bluetooth Server que, instalada en el PC, formará la aplicación servidor. El significado del nombre del proyecto, empezando por el acrónimo SOSA, que significa Sistema On-line de Seguimiento del Alumnado, Bluetooth, viene a decir la tecnología inalámbrica utilizada y el resto, Mobile y Server, aportan una división entre las diferentes plataformas y servicios que nos facilitan cada una de las aplicaciones. II

5 Como se ha dicho anteriormente, el proyecto se divide en dos aplicaciones: Cliente SOSA Bluetooth Mobile: permite recoger todas las incidencias, como son las faltas de asistencia, que se producen en el aula sobre un dispositivo móvil y posteriormente transferir la información a su PC a través de Bluetooth. También, facilita una gestión de las bases de datos almacenadas en el dispositivo móvil, como es la visualización de las mismas, altas de alumnos, dar de baja una base de datos y modificar los datos de un alumno. Servidor SOSA Bluetooth Server: es una herramienta capaz de ofrecer servicios de sincronización para establecer una comunicación con un dispositivo móvil, a través de la aplicación cliente. Permite, tanto mandar información de los alumnos que tenemos almacenados en la base de datos del PC al dispositivo móvil, así como recibir información de los alumnos como es le caso de las faltas, para la posterior actualización de la base de datos. También, aporta la posibilidad de obtener informes de faltas por alumno de forma personalizada. Para la implementación del proyecto se ha optado por el uso del lenguaje de programación Java, ya que es el más portable, y además, actualmente no hay ninguna aplicación en este lenguaje, en la que se comunique un dispositivo móvil con un PC, dándole así un carácter innovador: SOSA Bluetooth Mobile: basado en tecnología JAVA (plataforma J2ME). Éste módulo presentará un interfaz muy intuitivo y fácil de manejar, adaptado a las restricciones de los móviles. SOSA Bluetooth Server: basado en tecnología JAVA (plataforma J2SE 5.0), permitirá sincronizar las actualizaciones anotadas sobre el móvil de cada uno de los alumnos con la base de datos del PC del profesor. III

6 ABSTRACT The main idea of the project is born to optimize the process of control of attendance of the pupil. This task, it is carried out by each professor day after day at the beginning of each class, carrying big inconveniences. The problem, doesn't come given by the fact of passing list, but for the whole later process of registration in the PC, of the lacks and annotations that said professor carries out in class. This project, therefore, speeds up and it simplifies the tasks of passing list, to carry out annotations in class and, mainly, the transfer of that information to a database centralized in a PC, thanks to the wireless technology Bluetooth, every more popular day among us. All this is translated in that the professor carries out his class annotations through a potent graphic interfaz in a mobile device (PDA or wireless telephone) and when llegue to its personal computer, will be able to transfer all that information in a comfortable way and without necessity of using cables. Also, the project has a clear character innovation, since at the present time any application developed in Java that is able to establish a communication Bluetooth by means of a mobile device doesn't exist (client) and a PC (server). The project consists of two applications, SOSA Bluetooth Mobile, which will go installed in the mobile device and the application client, and SOSA Bluetooth will form Server that, installed in the PC, it will form the application servant. The meaning of the name of the project, beginning with the SOSA acrónimo that means On-line "System of Pursuit of the Pupil", Bluetooth, comes to the used wireless technology and the rest, Mobile and Server to say, they contribute a division among the different platforms and services that facilitate us each one of the applications. IV

7 As it has been said previously, the project is divided in two applications: Client SOSA Bluetooth Mobile: it allows to pick up all the incidences, like they are the lacks of attendance that take place in the classroom on a mobile device and later on to transfer the information to their PC through Bluetooth. It also facilitates us an administration of the databases stored in the mobile device, like it is the visualization of the same ones, high of students, to give of drop a database and to modify the data of a student. Server SOSA Bluetooth Server: it is a tool able to offer synchronization services to establish a communication with a mobile device, through the application client. It will allow us, point to send the students that we have information stored in the database from the PC to the mobile device, as well as to receive information of the alums like it is I marry him of the lacks, for the later upgrade of the database. It also contributes us the possibility to obtain reports of lacks for student in a personalized way. For the implementation of the project it has been opted by the use of the programming language Java, since it is the most portable, and also, at the moment there is not any application in this language, in which communicates a mobile device with a PC, giving this way him an innovative character: SOSA Bluetooth Mobile: based on technology JAVA (platform J2ME). This module will present a very intuitive and easy interface of managing, adapted to the restrictions of the motives. SOSA Bluetooth Server: based on technology JAVA (platform J2SE 5.0), it will allow to synchronize the logged upgrades on the motive of each one of the students with the database of the professor's PC. V

8 Capítulo ÍNDICE Página 1. INTRODUCCIÓN JUSTIFICACIÓN DEL PROYECTO QUÉ ES SOSA BLUETOOTH MOBILE Y SOSA BLUETOOTH SERVER? ANÁLISIS DE LAS ARQUITECTURAS PARA DISPOSITIVOS MÓVILES ANÁLISIS DEL MERCADO ACTUAL DE TELEFONÍA MÓVIL ARQUITECTURA DEL SISTEMA ESTUDIO DE LAS TECNOLOGÍAS BLUETOOTH INTODUCCIÓN ARQUITECTURA DE PROTOCOLOS PILA DE PROTOCOLOS PERFILES Y MODELOS DE USO BLUETOOTH J2ME INTRODUCCIÓN A J2ME MAQUINAS VIRTUALES J2ME CONFIGURACIONES PERFILES EL PERFIL MIDP API s JAVA PARA BLUETOOTH REQUISITOS OBJETIVOS FUNCIONALES OBJETIVOS TECNOLÓGICOS CASOS DE USO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER..59 VI

9 5. DISEÑO MODELO DE DOMINIO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER DIAGRAMAS DE COLABORACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER MODELO DE DATOS DISEÑO DE INTERFACES SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER IMPLEMENTACIÓN PLATAFORMAS Y ENTORNOS DE DESARROLLO FUNCIONALIDADES MÁS IMPORTANTES PROCESO DE SINCRONIZACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER IMPLANTACIÓN ESTUDIO DE LAS TECNOLOGÍAS DE COMUNICACIÓN COMM INSTALACIÓN DE LA APLICACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER CONCLUSIONES PROYECTO DE INNOVACIÓN ANÁLISIS DE TECNOLOGÍAS, PROBLEMAS Y RESULTADOS OTROS CAMPOS DE APLICACIÓN..124 VII

10 10. BIBLIOGRAFÍA ANEXOS API SOSA BLUETOOTH MOBILE API SOSA BLUETOOTH SERVER PROTOCOLOS ESPECIFICOS DE BLUETOOTH PROTOCOLOS ADOPTADOS DE BLUETOOH MANUAL DE USUARIO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER 252 VIII

11 1. INTRODUCCIÓN 1.1. JUSTIFICACIÓN DEL PROYECTO 1.2. QUÉ ES SOSA BLUETOOTH MOBILE Y SOSA BLUETOOTH SERVER? 1.3. ANÁLISIS DE LAS ARQUITECTURAS PARA DISPOSITIVOS MÓVILES 1.4. ANÁLISIS DEL MERCADO ACTUAL DE TELEFONÍA MÓVIL Pág. 1

12 1. INTRODUCCIÓN 1.1 JUSTIFICACIÓN DEL PROYECTO El proyecto a desarrollar fue elegido, en parte, por la incipiente intrusión de la tecnología móvil en nuestra sociedad, y la intención de aportar nuevas funcionalidades al uso de los mismos. Se ha optado por la utilización de nuevas tecnologías, como es el caso Bluetooth, que poco a poco se va asentando en el mercado, abriendo un gran abanico de posibilidades debido a su flexibilidad de aplicación. Con todo este proceso se evita el uso de recursos como el papel, contribuyendo a disminuir el abuso y desperdicio del mismo. La realización de este proyecto surgió de la idea de querer desarrollar una aplicación que utilizase una de las nuevas tecnologías inalámbricas, como es el caso de Bluetooth, y su posterior implantación en un dispositivo móvil. Todo esto se quería implementar en el lenguaje de programación Java, ya que de este modo podía ser implantado en un amplio número de dispositivos móviles. La idea de SOSA Bluetooth Mobile y de SOSA Bluetooth Server, surge de la intención práctica del proyecto, es decir, un proyecto que a parte de realizar un estudio sobre estas nuevas tecnologías, culminara con una aplicación útil. El desarrollo de dos aplicaciones, una cliente y otra servidor, viene dado por la intención de realizar un proyecto que abarcara todo el proceso de comunicación, tanto en una aplicación cliente como en una servidor, ya que la implementación de esta última en Java, suponía un reto debido a que no existe ningún API de Bluetooth para J2SE. Pág. 2

13 1.2 QUÉ ES SOSA BLUETOOTH MOBILE Y SOSA BLUETOOTH SERVER? "SOSA Bluetooth" es un Sistema On-line de Seguimiento del Alumnado, el cual se descompone en dos aplicaciones, una cliente y una servidor: Cliente SOSA Bluetooth Mobile: permite recoger todas las incidencias que se producen en el aula sobre un dispositivo móvil y posteriormente transferir la información a su PC a través de Bluetooth Servidor SOSA Bluetooth Server: permite mandar información de los alumnos al dispositivo y recibir información del mismo, para la actualización de la base de datos y realización de informes. Dentro de este sistema, por lo tanto, se engloban dos módulos: El módulo cliente, basado en tecnología JAVA (plataforma J2ME), gestionará, principalmente, la información asociada a la asistencia por parte del alumnado. Éste módulo presentará un interfaz muy intuitivo y fácil de manejar, adaptado a las restricciones de los móviles. El módulo servidor, basado en tecnología JAVA (plataforma J2SE 5.0), permitirá sincronizar las actualizaciones anotadas sobre el móvil de cada uno de los alumnos con la base de datos del PC del profesor. 1.3 ANÁLISIS DE LAS ARQUITECTURAS PARA DISPOSITIVOS MÓVILES El sistema operativo es el software principal que se instala sobre el hardware o dispositivo; contiene instrucciones programadas que indican al microcontrolador que hacer y sobre el que se instalan los programas que pueden ser aplicaciones finales o sistemas que permiten desarrollar otros programas. Pág. 3

14 o La familia Windows Windows CE es el Sistema Operativo que Microsoft ha desarrollado a partir de Windows 95, para dispositivos móviles, y sirve de base para el desarrollo de los sistemas específicos de cada dispositivo. Lo que los usuarios finales disfrutan, no es Windows CE tal y como ha sido desarrollado. En cada tipo de dispositivo se implementa, desde las posibilidades que permite la versión de Windows CE disponible, una interfaz y las funcionalidades requeridas. Así, el Pocket PC 2000, 2002 y 2003 se han desarrollado específicamente para los PDAs. Windows CE nació como un sistema operativo de fácil programación, sólido, transparente y que podía implantarse desde un ordenador a una lavadora, nevera, microondas incluso videoconsolas (DreamCast). De hecho, se pensó en integrarlo en todo lo que no fuera un PC. Windows CE.NET, es la evolución de Windows CE 3.0 bajo la filosofía distribuida de.net. Es pues, un escenario de trabajo que deberá ser adaptado a cada dispositivo. Esta nueva versión tiene muchas ventajas, que pueden ser aplicadas a cada uno de los sistemas operativos derivados. Según Microsoft, Windows CE.NET, incorporará la posibilidad de manejar las conexiones Bluetooth, Microsoft Internet Explorer 5.5, Windows Media 8 y DirectX y será compatible con una amplio rango de procesadores como Xscale, ARM, MIPS, SH o x86. Cada sistema operativo derivado, tomará las propiedades que le competan. Para obtener más información sobre esta familia de sistemas, véase el sitio de Microsoft. Pág. 4

15 Los dispositivos PDA que disponen de Pocket PC son dispositivos con una magnífica pantalla de 240 x 320 píxeles a todo color. Son muy potentes, con procesadores de entre 133 y 206 Mhz y 16 ó 32 Mb de RAM, por lo que son capaces de reproducir vídeo o música y ejecutar aplicaciones multimedia con gran rapidez. También disponen de altavoz y salida de audio para auriculares. Además incluyen diversos tipos de ranuras o slots de expansión, que permiten insertar tarjetas de diversos formatos (Multimedia, CompactFlash o PCMCIA) para aumentar memoria o incorporar módems, discos duros, tarjetas de red, etc. o Palm OS La primera versión fue desarrollada por el fabricante de los DCM Palm para el modelo Pilot en Actualmente son muchos los fabricantes como Oracle, Nokia, Handspring, Symbol y Sony que utilizan diversas variantes y versiones de este Sistema Operativo que en conjunto representan el 66 % de todos los sistemas instalados en computadores de mano. Según la filosofía de Palm, se intenta tratar a la computación móvil no como versiones en miniatura de los sistemas de sobremesa, sino como dispositivos y aplicaciones dedicados a tareas y usos que tienen su propia identidad y reclaman sus propios recursos y soluciones. En los últimos años, la versión más extendida ha sido la 4.1 que entre sus principales características, presenta el soporte "teórico" de de colores así como la gestión de tarjetas de memoria externa. Recientemente Palm Computing se dividió en dos empresas distintas, una de hardware y otra de software, Palm Source la cual ha presentado Palm OS 5 que es realmente un sistema diferente a los anteriores aunque esto se refiera más al funcionamiento interno que a lo relativo a su utilización externa. Para mantener la compatibilidad con la generación anterior del sistema operativo, la nueva versión incluye un emulador llamado PACE que permite ejecutar las más de aplicaciones existentes. Además, cualquiera que sea Pág. 5

16 la norma considerada, WiFi Lan, Bluetooth, GSM/GPRS, o CDMA, el sistema Palm OS 5 integra las APIs necesarias. O sea, que los dispositivos equipados con Palm OS 5 pueden comunicarse fácilmente con todos los dispositivos existentes que estén basados en esas normas tales como teléfonos móviles, impresoras, módems, etc. Las normas de seguridad incorporadas en el sistema, permiten que las transacciones sean hechas de forma segura, considerando también, el uso de firmas digitales homologadas. También ofrece servicios de encriptación para las conexiones. El sistema incluye asimismo un navegador para Internet, el NetFont que suporta entre otras normas, HTML 4.01, XHTML, los GIFs animados, el modo seguro de acceso a la red VPN (Virtual Private Network) y la interpretación de código JavaScript. Estas normas ya utilizadas en los sistemas de los computadores de sobremesa se introducen por vez primera en los equipos de mano. En cuanto a los dispositivos que contiene Palm OS, la característica más llamativa es su reducido tamaño y ligereza: pesan entre 120 y 170 gr., y son en general más pequeños que los Pocket PC. Todos tienen una pantalla de 160x160 píxeles, normalmente monocroma. Usan procesadores de Mhz que son suficientes para que el dispositivo funcione con rapidez, y disponen de 2 u 8 Mb de memoria RAM. o Linux LINUX es un sistema operativo compatible UNIX. Dos características muy peculiares lo diferencian del resto de los sistemas más extendidos en el mercado, la primera, es que es libre, esto significa que no hay costos por sus licencias, la segunda, es que el sistema viene acompañado del código fuente. LINUX se distribuye bajo la licencia pública del proyecto GNU que fue lanzado en 1984 para desarrollar el Linux de libre distribución. El sistema ha sido diseñado y programado por multitud de programadores alrededor del mundo. El Pág. 6

17 núcleo del sistema sigue en continuo desarrollo. En los últimos tiempos, ciertas casas de software comercial han empezado a distribuir sus productos para Linux y la presencia del mismo en empresas aumenta rápidamente por la excelente relación calidad-precio que se consigue. En los últimos años, algunos fabricantes de dispositivos móviles han incorporado Linux a sus productos. Se están desarrollando versiones de Embedded Linux que constituyen la tercera alternativa a Palm OS y Windows CE para los computadores de mano. Así, LinuxDevices.com, ha creado una guía de referencia para computadores de mano basados en Linux, con la que pretende mantener actualizados de manera permanente los productos Linux para pequeños dispositivos. Si bien el modelo Sharp Zaurus SL-5x00 fue el primer computador de mano con Linux pre-instalado, hay actualmente versiones de Embbeded Linux para casi todas las marcas. o Symbian OS (EPOC) El sistema operativo de Psion se llama EPOC, nombre del núcleo del antiguo sistema operativo de la Psion serie 3. Hasta 1997 Psion no comenzó a licenciar el EPOC32, la versión de 32 bytes para la serie 5. Permite realizar multitarea y pretende competir con Windows CE. El recibimiento fue frío y sólo Philips mostró algo de interés. Pero Psion reaccionó y a mediados de 1998 creó la alianza Symbian -junto con Ericsson, Nokia, Motorola y Matsushita- con el propósito de hacer de EPOC un sistema operativo único. El premio de esta apuesta es elevado: los 600 millones de usuarios de dispositivos móviles en año Symbian es un sistema operativo abierto, esta diseñado para los requerimientos específicos de los teléfonos móviles de 2G, 2.5 y 3G. En las versiones 6.X de este sistema se tiene soporte para desarrollo en C++, Java, WAP, HTML. Pág. 7

18 El SO de Symbian es el sistema operativo estándar de la industria global para los smartphones, dirigido a los fabricantes del microteléfono, que generan entorno al 85% de las ventas totales mundiales de teléfonos móviles. Versiones actuales: OS v7.0s de Symbian: El OS v7.0s de Symbian es una plataforma para el mercado 3G, ofreciendo nueva funcionalidad para permitir la conformidad 3GPP y la entrega de los servicios 3G. Las nuevas características de OS v7.0s de Symbian son: - marco multi-roscado ligero de los multimedia - ayuda para W-cdma - Java MIDP ayuda para los contextos múltiples primario/secundario PDP - ayuda para el texto bidireccional (tailandés, árabe y hebreo). OS v8.0 de Symbian: El OS v8.0 de Symbian es diseñado para resolver las necesidades de los comerciantes del OS de Symbian, de los operadores de red y de las empresas bajando el coste de la estructura del teléfono del OS de Symbian, aumentando las capacidades de Java y multimedia, así como funcionalidad avanzada del dispositivo. Pág. 8

19 UIQ v3.0: UIQ es una plataforma para el interfaz de los smartphones basados en el OS de Symbian. UIQ ofrece a usuarios que partidarios de la interacción y se diseña para ofrecer el acceso fácil a la amplia variedad de servicios de los datos en 2,5 y las redes 3G. Los teléfonos basados UIQ son de gran alcance y dan el acceso a los usos de la empresa, al , a los clips multimedia, así como la gerencia de información personal. La excelente interacción y las capacidades gráficas también proporcionan la ayuda para las posibilidades avanzadas del juego. UIQ ofrece a los fabricantes del teléfono móvil, una fundación sólida, construyendo los dispositivos eficientes, atractivos y de bajo coste. Se dan los derechos de modificar el UI para requisitos particulares al ajuste del producto. UIQ incluye la ayuda para los últimos estándares inalámbricos, con un sistema de usos esenciales y bien integrados, permitiendo la integración rápida del dispositivo. A través de la plataforma abierta de UIQ, existe una multiplicidad de usos y los servicios son ofrecidos por varias compañías de software. UIQ 3.0 UIQ 2.1 Pág. 9

20 1.4 ANÁLISIS DEL MERCADO ACTUAL DE TELEFONÍA MÓVIL A continuación se va a mostrar el estudio llevado a cabo sobre el mercado actual de la telefonía móvil. Para realizar el estudio, se han seleccionado una serie de variables, que nos van a proporcionar suficiente información, como para poder realizar un análisis de los resultados obtenidos: La información obtenida, se ha centrado en aquellos dispositivos móviles, de las marcas más conocidas del mercado, escogiendo los modelos más actuales. El precio de cada terminal, es el precio libre. MARCA MODELO PRECIO SIMBIAN J2ME BLUETOOTH Motorola V3 369 NO MIDP 2.0 SI V NO MIDP 1.0 NO V NO NO NO V NO MIDP 1.0 SI C NO NO NO Nokia NO NO NO NO NO NO NO MIDP 1.0 NO NO MIDP 1.0 NO NO MIDP 1.0 NO NO MIDP 1.0 NO NO MIDP 1.0 NO NO MIDP 2.0 SI SI MIDP 1.0 SI SI MIDP 2.0 SI 6610i 159 NO MIDP 1.0 NO NO MIDP 1.0 SI NO MIDP 1.0 SI NO MIDP 1.0 SI SI MIDP 1.0 NO NO MIDP 1.0 SI SI MIDP 1.0 SI Panasonic A NO NO NO X NO MIDP 1.0 NO X NO NO NO X NO MIDP 1.0 NO X NO MIDP 1.0 NO Siemens CX NO MIDP 1.0 NO C NO MIDP 1.0 NO CF NO MIDP 1.0 NO MC60 79 NO MIDP 1.0 NO Pág. 10

21 M NO MIDP 2.0 NO SF NO MIDP 1.0 NO SL NO MIDP 1.0 NO Sony Ericsson K700i 219 NO MIDP 1.0 SI P NO MIDP 1.0 SI T NO MIDP 1.0 NO S NO MIDP 1.0 SI T NO MIDP 1.0 SI Fuente: The Phone House Como conclusión, podemos afirmar que los dispositivos con tecnología inalámbrica Bluetooth, son los de gama alta (precio mayor a 200 euros), lo que viene a decirnos que es una tecnología nueva y en creciente expansión. También se puede resaltar, que la mayoría soportan Java, aunque sólo los más nuevos vienen con MIDP 2.0. En consecuencia, se puede comentar que la tecnología Bluetooh, acompañada del perfil de Java, MIDP 2.0, se esta implantando en los dispositivos móviles nuevos, y además si observamos el mercado actual no sólo en el campo de los dispositivos móviles, por ejemplo en los coches, nos damos cuenta la creciente expansión e importancia de esta tecnología. A continuación, podemos observar de una forma gráfica, el porcentaje de móviles que usan Bluetooth y Java. Los porcentajes se han calculado con los datos de la tabla anterior. Bluetooth JAVA 64% 36% SI NO 10 % 15% 75% MIDP 1.0 MIDP 2.0 NO Todavía hay un alto porcentaje de móviles que no usan Bluetooth ni Java. A medida que dicha tecnología se vaya abaratando, se llegará al 100%. Pág. 11

22 2. ARQUITECTURA DEL SISTEMA Pág. 12

23 2. ARQUITECTURA DEL SISTEMA A continuación se van a identificar y definir las distintas alternativas que pueden servir como soluciones viables para satisfacer los requisitos definidos y las necesidades del usuario. Las distintas alternativas, parten de una base común. Todas siguen una arquitectura cliente-servidor, ya esta nos va a proporcionar las ventajas de la arquitectura basada en componentes, destacando: Función distribuida entre cliente y servidor. Interfaz de presentación gráfica. Reutilización de componentes, como los establecidos en este tipo de arquitecturas orientadas a componentes. Los componentes del nivel de presentación en el cliente podrán desarrollarse diferentes lenguajes, aunque en este caso se desarrollara, tanto la aplicación cliente como la servidora, en Java, utilizando para la parte cliente un desarrollo en la plataforma J2ME y para la parte servidor un desarrollo en la plataforma de desarrollo J2SE. Los elementos hardware y software comunes a las alternativas, son los siguientes: Para la implantación de la aplicación cliente: o Dispositivo móvil con Java: MIDP 2.0. Para la implantación de la aplicación servidora: o Un PC con Java: JRE 5.0. o Conectividad de bases de datos (drivers ODBC). Pág. 13

24 Vamos a proponer dos alternativas que darían solución a los requisitos. Únicamente difieren en la elección de la forma de comunicación: los protocolos a seguir, el hardware adecuado Como queremos que la sincronización de los datos se realice a través de un medio inalámbrico y libre, es decir, sin coste añadido por usar el medio, podemos elegir entre una de estas dos alternativas: 1. Bluetooth. 2. Infrarrojos. Atendiendo a los factores técnicos de cada alternativa, la elección del uso de Bluetooth como medio de comunicación es mejor ya que proporciona mayor independencia del sistema servidor, nos proporciona una mejor comunicación ya que el dispositivo móvil puede estar en cualquier espacio físico siempre y cuando este dentro del radio de alcance del PC que es bastante amplio para el fin que buscamos, mientras que si se utiliza infrarrojos, deben estar en línea los dispositivos de infrarrojos de ambas aplicaciones. Desde el punto de vista de la implementación la elección de Bluetooth puede resultar más tediosa. La viabilidad económica considera la inversión o gasto del proyecto: Coste de implantación: o Los costes de desarrollo van a resultar prácticamente iguales ya que se va a ser desarrollado por una única persona, y llevaría más o menos las mismas horas de desarrollo de la aplicación. o Los costes de puesta en marcha son similares. o Costes de formación serian los mismos ya que se tratarían de unas tecnologías nuevas para el desarrollo. Costes de adquisición de tecnología: o En cuanto al coste hardware, podemos afirmar que sería un coste parecido o incluso más barato el uso de la tecnología de infrarrojos en el dispositivo móvil pero habría una gran diferencia Pág. 14

25 en el coste de adquisición del periférico de infrarrojos para el PC, ya que en el mercado actual, el rápido crecimiento de la tecnología inalámbrica Bluetooth, implica una gran competencia y una caída de precios. Por lo que en conjunto la alternativa más económica sería la adquisición de dispositivos Bluetooth. Con los datos recogidos en la especificación de cada alternativa, y estudiadas las diferentes soluciones, podemos afirmar que la alternativa de realizar la comunicación mediante la tecnología Bluetooth, es más viable ya que la independencia entre dispositivos aporta una facilidad de uso para el usuario final mucho mayor que la que aportan los infrarrojos, aparte del punto de vista económico. Conocida ya la alternativa a desarrollar, con los elementos hardware, software y de comunicaciones a utilizar, se puede definir la arquitectura de los dos módulos principales en los que se divide la aplicación, el cliente que será instalado en un dispositivo móvil y el servidor que será instalado en un PC, sigue el siguiente gráfico de alto nivel, el cual representa las características hardware y operativas que definen a la arquitectura elegida: Pág. 15

26 DATOS ALUMNOS J2ME, MIDP 2.0 CLDC 1.1, JSR-82 J2SE, Javax.comm BBDD PARTE BBDD ALUMNO BBDD SEGUIMIENTO GESTIONAR DATOS RMS ACCESS CLIENTE SERVIDOR Pág. 16

27 3. ESTUDIO DE TECNOLOGÍAS 3.1 BLUETOOTH INTODUCCIÓN ARQUITECTURA DE PROTOCOLOS PILA DE PROTOCOLOS PERFILES Y MODELOS DE USO BLUETOOTH 3.2 J2ME INTRODUCCIÓN A J2ME MAQUINAS VIRTUALES J2ME CONFIGURACIONES PERFILES EL PERFIL MIDP API s JAVA PARA BLUETOOTH Pág. 17

28 3. ESTUDIO DE TECNOLOGÍAS 3.1 BLUETOOTH Bluetooth es un estándar que identifica un conjunto de protocolos que facilitan la comunicación inalámbrica entre diferentes tipos de dispositivos remotos. Su nombre se debe al rey vikingo Harold Bluetooth (940 A.D. 981 A.D.) reconocido por su facilidad de comunicación INTRODUCCIÓN Bluetooth surge de la necesidad de las grandes empresas de telecomunicaciones e informática de crear un estándar de comunicación inalámbrica para suprimir los cables de conexión. Bluetooth es una transmisión de corto alcance por radiofrecuencia, capaz de transmitir a través de objetos sólidos no metálicos. Transmiten con una potencia nominal de salida de 0 dbm permitiendo un alcance de 10 metros en un ambiente libre de obstáculos, pero haciendo uso de amplificadores de la transmisión de energía puede alcanzar los 100 metros. Opera en la banda libre de radio ISM 1 a 2.4 Ghz. Soporta transmisiones de tres canales de voz, video y datos a una velocidad máxima de 1 Mbps, aunque la velocidad real estará comprendida alrededor de los 721 Kbps, incluyendo un canal de retorno de 56 Kbps. La banda ISM al no necesitar licencia, esta abierta a cualquiera, por lo que debe adaptarse a las pequeñas interferencias de otros aparatos. Este problema lo soluciona, 1 Industrial Scientific Medicine. Banda internacional médico-científica. Pág. 18

29 utilizando un sistema que busque la parte no utilizada del espectro o un sistema de salto de frecuencia. La técnica de salto de frecuencia es aplicada a una alta velocidad y una corta longitud de los paquetes (1600 saltos/s). Divide la banda de frecuencia en varios canales de salto, donde, los transceptores, durante la conexión van cambiando de uno a otro canal de salto de manera pseudo-aleatoria. Los paquetes de datos están protegidos por un esquema ARQ 2, en el que los paquetes perdidos son automáticamente retransmitidos. Bluetooth utiliza un sistema FH/TDD 3, en el que el canal queda dividido en intervalos slots de 625 µs, donde cada salto de frecuencia es ocupado por un slot. Dos o más unidades Bluetooth pueden compartir el mismo canal dentro de una piconet 4. Datagrama Bluetooth: La información que se intercambia entre dos unidades Bluetooth se realiza mediante un conjunto de slots que forman un paquete de datos. Cada paquete comienza con un código de acceso de 72 bits, de la identidad maestra, seguido de un paquete de datos de cabecera de 54 bits. Éste contiene información de control, 3 bits de acceso de dirección, tipo de paquete, bits de control de flujo, bits para la retransmisión automática de la pregunta, y chequeo de errores de campos de cabecera. La dirección del dispositivo es en forma hexadecimal. Finalmente, el paquete que contiene la información, que puede seguir al de la cabecera, tiene una longitud de 0 a 2745 bits. Figura 3.1. Cabecera de un datagrama Bluetooth. 2 Repetición automática de consulta. 3 Salto de frecuencia/división de tiempo duplex 4 Pequeña red que establecen automáticamente los terminales Bluetooth para comunicarse entre si Pág. 19

30 Los receptores de la piconet comparan las señales que reciben con el código de acceso, si éstas no coinciden, el paquete recibido no es considerado como válido en el canal y el resto de su contenido es ignorado. Además de los canales de datos, están habilitados tres canales de voz de 64 kbit/s por piconet. Las conexiones son uno a uno con un rango máximo de diez metros, aunque utilizando amplificadores se puede llegar hasta los 100 metros, pero en este caso se introduce alguna distorsión. Piconets: Si un equipo se encuentra dentro del radio de cobertura de otro, éstos pueden establecer conexión entre ellos. Cada dispositivo tiene una dirección única de 48 bits, basada en el estándar IEEE para WLAN. En principio sólo son necesarias un par de unidades con las mismas características de hardware para establecer un enlace. Dos o más unidades Bluetooth que comparten un mismo canal forman una piconet. Para regular el tráfico en el canal, una de las unidades participantes se convertirá en maestra, por defecto es la que establece la piconet y todos los demás serán esclavos. Los participantes podrían intercambiar los papeles si una unidad esclava quisiera asumir el papel de maestra. Sólo puede haber un maestro en la piconet al mismo tiempo. Hasta ocho dispositivos pueden formar parte de una piconet y hasta diez piconets pueden coexistir en una misma área de cobertura. Figura 3.2. Piconet. Pág. 20

31 Scatternet: Los equipos que comparten un mismo canal sólo pueden utilizar una parte de su capacidad. Aunque los canales tienen un ancho de banda de un 1Mbit, cuantos más usuarios hay en la piconet, disminuye la capacidad hasta unos 10 kbit/s más o menos. Para poder solucionar este problema se adoptó una solución de la que nace el concepto de scatternet. Figura 3.3. Scatternet. Las unidades que se encuentran en el mismo radio de cobertura pueden establecer comunicaciones entre ellas. Sin embargo, sólo aquellas unidades que realmente quieran intercambiar información comparten un mismo canal creando la piconet. Este hecho permite que se creen varias piconets en áreas de cobertura superpuestas. A un grupo de piconets se le llama scatternet. El rendimiento, en conjunto e individualmente de los usuarios de una scatternet es mayor que el que tiene cada usuario cuando participa en un mismo canal de 1 Mbit. Además, estadísticamente se obtienen ganancias por multiplexación y rechazo de canales salto. Debido a que individualmente cada piconet tiene un salto de frecuencia diferente, diferentes piconets pueden usar simultáneamente diferentes canales de salto. Pág. 21

32 En la siguiente tabla se muestran de forma genérica las especificaciones de la tecnología Bluetooth: Especificaciones Banda de frecuencia Potencia del transmisor Tecnología RF Velocidad de datos Rango esperado del sistema 2.4 GHz 1 mw (0 dbm) Espectro Ensanchado por Secuencia Directa Híbrida y Saltos en Frecuencia (FH-SS) 721 Kbps por piconet 10 metros. Extensión a 100 metros. Nº máximo de dispositivos 8 por piconet. 10 piconets en un área de cobertura1 (scatternet) Nº máximo canales de voz 3 por piconet Nº máximo canales de datos 7 por piconet Seguridad Alimentación Sí, en la capa de enlace 2.7 Voltios Consumo de potencia: Sleep 30 µa Hold 60 µa Standby 300 µa Transmitiendo Tamaño del módulo Interferencias 8 30 ma 0.5 pulgadas cuadradas ( mm2) Bluetooth minimiza la interferencia potencial al emplear saltos rápidos en frecuencia de 1600 veces por segundo Tabla 3.1. Especificaciones generales Bluetooth. Pág. 22

33 3.1.2 ARQUITECTURA DE PROTOCOLOS PILA DE PROTOCOLOS Para conseguir esta interoperabilidad, las aplicaciones en dispositivos remotos deben ejecutarse sobre una pila de protocolos idénticos. En el siguiente esquema se muestra la pila de protocolos de la especificación: Figura 3.4. Pila de protocolos Bluetooth. Las aplicaciones no hacen uso de todos los protocolos que conforman la pila, y algunas aplicaciones se ejecutan sobre una o más columnas de la pila. Como se puede observar la pila completa se compone tanto de protocolos específicos de Bluetooth (LMP y L2CAP) como de protocolos no específicos como son OBEX (Objects Exchange Protocol), UDP (User Datagram Protocol), TCP, IP, etc. Esto es así porque el objetivo principal ha sido la maximizar el número de protocolos existentes que se puedan reutilizar en las capas más altas para diferentes propósitos. Esto hace que las diferentes aplicaciones comerciales que utilicen estos protocolos, puedan interoperar con Bluetooth además de desarrollar con esta tecnología. Pág. 23

34 siguiente: La pila de protocolos se puede dividir en cuatro capas lógicas. La división es la Capa de protocolo Núcleo de Bluetooth Sustitución del cable Control de Telefonía Protocolos adoptados Protocolos de la pila BaseBand, LMP, L2CAP, SDP RFCOMM TCS Binary, AT-Commands PPP, UDP/TCP/IP, OBEX, WAP, vcard, VCal, IRMC, WAE Tabla 3.2. Clasificación protocolos Bluetooth PERFILES Y MODELOS DE USO BLUETOOTH PERFILES Hay cuatro perfiles generales que son ampliamente utilizados por todo tipo de aplicaciones y que describiremos brevemente a continuación: GAP: Generic Application Profile Figura Pila de protocolos GAP Pág. 24

35 El propósito de este perfil es describir el uso de las capas más bajas de la pila de protocolos Bluetooth (LC y LMP), aunque también incluye la descripción de los aspectos de seguridad necesarios y las capas de protocolos más altas (L2CAP, RFCOMM, OBEX, etc.). Se trata del perfil más importante de todos los definidos por el SIG ya que ha de ser implementado prácticamente por la totalidad de los dispositivos Bluetooth, sea cual sea su aplicación. Se definen los siguientes papeles en el perfil: A-Party : se trata del dispositivo que inicia la búsqueda, en el caso del establecimiento de enlace, o el iniciador en aquellos casos en los que ya está establecido el enlace y hay que iniciar algún procedimiento. B-Party : se trata del dispositivo buscado en el establecimiento de enlace, o el que acepta en el resto de procedimientos. Este perfil maneja diferentes procedimientos entre dos dispositivos referentes al descubrimiento y conexión tanto para el caso en que ninguno de los dos dispositivos tenga establecido un enlace, como para aquellos casos en que uno de los dos tiene ya establecido un enlace (posiblemente con un tercero: C-Party ). Figura Procedimientos iniciados por un dispositivo (A) hacia otro (B) que puede tener o no un enlace Bluetooth activo. En principio, un usuario Bluetooth debe ser capaz de conectar un dispositivo Bluetooth a otro. Incluso si los dos dispositivos no comparten ninguna aplicación común, esta conexión debe ser posible usando las capacidades básicas Bluetooth. Pág. 25

36 Cuando los dos dispositivos sí comparten la misma aplicación pero son de diferentes fabricantes, la conexión entre ambos ha de ser posible aunque los nombres dados a las capacidades básicas Bluetooth por cada fabricante sean diferentes, ya que habrá que ejecutar una serie de procedimientos básicos que serán conocidos por ambos. Este perfil define modos de operación genéricos que pueden ser usados por diferentes perfiles que hagan referencia al GAP, y por dispositivos que implementen múltiples perfiles. Así, el GAP define procedimientos generales para descubrir identidades, nombres, capacidades básicas de otros dispositivos Bluetooth que estén en un modo operativo y cómo intercambiar las claves de enlace entre dispositivos. SPP: Serial Port Profile La siguiente figura muestra los protocolos y entidades usados en este perfil. Figura Modelo de protocolos SPP La capa de emulación de puerto es la entidad encargada de simular el puerto serie y de proporcionar un API a las aplicaciones que corren por encima. Dichas aplicaciones A y B en ambos extremos son las típicas aplicaciones que se comunican sobre un cable serie (y que en este caso se va a emular). A continuación mostramos una posible configuración de dispositivos para este perfil: Pág. 26

37 Figura Ejemplo SPP con dos notebooks. Se definen los siguientes papeles en el perfil: Dispositivo A (DevA): se trata del dispositivo que toma la iniciativa para conectarse a otro dispositivo. El nombre técnico que se le da es iniciador. Dispositivo B (DevB): dispositivo que espera que otro tome la iniciativa de la conexión. Su nombre técnico es aceptante. Si quisiéramos establecer una correspondencia entre SPP y una arquitectura de puerto serie convencional, tanto el dispositivo A como el B pueden ser un DCE 5 o un DTE 6, ya que el protocolo RFCOMM ha sido diseñado para ser independiente de las relaciones DTE-DCE o DTE-DTE. El escenario que cubre este perfil es el siguiente: establecimiento de puertos serie virtuales (o equivalentes) sobre dos dispositivos (por ejemplo, dos PCs) y conectarlos mediante Bluetooth realizando por tanto una emulación del cable serie entre ambos dispositivos. El perfil sólo soporta paquetes de slot único, lo que limita el régimen de datos a 128 Kbps, y permite únicamente configuraciones punto a punto. Sin embargo, es posible tener múltiples ejecuciones de este perfil en el mismo dispositivo. Aspectos de seguridad, como la autorización y autenticación son obligatorios, mientras que los procedimientos de cifrado son opcionales. En cuanto a los papeles de maestro y esclavo no son fijos, es decir, permite el intercambio de papeles en un dispositivo. El protocolo 5 Data Circuit Endpoint 6 Data Terminal Endpoint Pág. 27

38 RFCOMM es usado para el transporte de los datos, señales módem de control y comandos de configuración. SDAP: Service Discovery Application Profile La siguiente figura muestra los protocolos y entidades usados en este perfil: Figura Pila de protocolos SDAP. Se definen los siguientes papeles en el perfil: Dispositivo local (LocDev): dispositivo que inicializa el procedimiento de descubrimiento de servicio. Debe contener al menos la entidad cliente de la arquitectura Bluetooth SDP. Además, posee una aplicación de descubrimiento de servicios (SrvDscApp) usada por el usuario para iniciar los descubrimientos y visualizar los resultados obtenidos y una entidad BT_module_Cntrl que tiene como misión comunicarse con el protocolo BaseBand y dar diferentes órdenes de búsqueda cuando el dispositivo entra en diferentes modos de operación. Dispositivo(s) remoto(s) (RemDev(s)): cualquier dispositivo que participa en el proceso de descubrimiento de servicios respondiendo a las preguntas de servicio generadas por un dispositivo local. Debe contener al menos la entidad servidor de la arquitectura Bluetooth SDP. Posee una base de datos Pág. 28

39 de información relacionada con los servicios, la cual es consultada para crear las respuestas a las peticiones de descubrimiento de servicio. El papel de dispositivo local o remoto no es permanente ni exclusivo. Un dispositivo remoto puede tener instalada una aplicación SrvDscApp, al igual que puede poseer una entidad cliente, y viceversa. Así, un dispositivo puede ser un dispositivo local para una transacción SDP concreta a la vez que es un dispositivo remoto para otra transacción SDP. La siguiente figura muestra un ejemplo SDAP: un dispositivo local (notebook) realizando petición de servicios entre un conjunto de dispositivos remotos. Los escenarios que cubre este perfil son: Figura Ejemplo de aplicación SDAP. Búsqueda de servicios por clase de servicio. Búsqueda de servicios por atributos de servicio. Navegación de servicios. Los dos primeros casos representan la búsqueda de servicios específicos, mientras que en el último, trata de una búsqueda genérica de servicios, es decir, ver qué servicios están disponibles. Antes de que dos dispositivos equipados con Bluetooth se puedan comunicar en este perfil es necesario que se realicen las siguientes acciones: Pág. 29

40 Los dispositivos necesitan ser inicializados. La inicialización puede requerir la introducción de un PIN para crear una clave de enlace, para la autorización y el cifrado de los datos. Se tiene que crear un enlace Bluetooth, lo cual puede requerir el descubrimiento de la dirección BD_ADDR de otro dispositivo a través de los procedimientos de búsqueda y pregunta. El descubrimiento de servicios puede ser iniciado tanto por un maestro como por un esclavo de la piconet. Además, un esclavo en una piconet puede iniciar el descubrimiento de servicios en una nueva piconet, en el caso de que el maestro de la piconet original indique que no está disponible. GOEP: Generic Object Exchange Profile La siguiente figura muestra los protocolos y entidades usados en este perfil. Figura Pila de protocolos GOEP La capa de aplicación cliente es la entidad encargada de enviar y recuperar los objetos de datos del servidor mediante operaciones OBEX. La aplicación servidora realiza el almacenamiento de datos y responde a las peticiones del cliente. Pág. 30

41 Se definen los siguientes papeles en el perfil: Servidor: se trata del dispositivo que proporciona intercambio de objetos con el dispositivo cliente. Cliente: dispositivo que introduce objetos (pushing) en el servidor o los saca (pulling). Los escenarios cubiertos por este perfil son: El cliente pide al servidor la introducción de objetos. El cliente pide al servidor la recuperación de objetos. Los requisitos del perfil son: a) Antes de que un servidor sea usado con un cliente por primera vez, se debe realizar un procedimiento de intercambio de claves. El uso concreto de este procedimiento depende de los perfiles de aplicación. Generalmente se trata de introducir un código PIN Bluetooth en los teclados de los dispositivos cliente y servidor. b) También se debe realizar un procedimiento de inicialización OBEX antes de usar el servidor por primera vez. c) La seguridad se puede conseguir mediante la autenticación de a la otra parte durante el establecimiento de la conexión y mediante el cifrado de todos los datos de usuario en el nivel de enlace, para lo cual la autenticación y el cifrado deberán ser soportados por todos los dispositivos. d) El establecimiento de enlace y canal debe realizarse de acuerdo a los procedimientos definidos en el GAP. e) No hay papeles fijos para el maestro y esclavos. f) Este perfil no requiere el uso de los modos de bajo consumo. Pág. 31

42 Hay que tener en cuenta las restricciones: a) Para el dispositivo que contenga al servidor, puede que el usuario tenga que ponerlo en modo de conexión o descubrimiento cuando los procedimientos de establecimiento de enlace y pregunta se están procesando en el cliente. b) El perfil soporta únicamente configuraciones punto a punto, por lo que el servidor sólo puede ofrecer sus servicios a un cliente a la vez. MODELOS DE USO BLUETOOTH A continuación se realiza una breve descripción de algunos ejemplos de modelos de uso Bluetooth. Transferencia de ficheros Este modelo de uso nos ofrece la capacidad de poder transferir objetos de datos de un dispositivo a otro (PCs, PDAs, smart-phones, etc.). Los tipos de los objetos incluyen ficheros.xls,.ppt,.wav,.jpg,.doc, directorios completos, tarjetas de negocios (cuyo formato está especificado con vcard), aunque en el futuro se espera poder aumentar el número de formatos de fichero que se puedan transferir. Además, se ofrece la posibilidad de navegar por los contenidos de diferentes carpetas en un dispositivo remoto. Para la implementación de este modelo de uso se emplean los siguientes perfiles: Perfil de transferencia de ficheros (file transfer & browsing) Perfil de introducción de objetos (object push) En la siguiente figura se presenta la pila de protocolos necesaria para este modelo de uso, destacando el uso del protocolo OBEX de intercambio de objetos, básico para esta aplicación. Pág. 32

43 Figura Pila de protocolos para aplicaciones de transferencia de ficheros. Internet bridge Gracias a este modelo de uso, los teléfonos móviles o módems inalámbricos pueden actuar como el módem de un PC, proporcionando capacidades de fax y establecimiento de llamadas en red sin necesidad de conexiones físicas al PC. En la siguiente figura se muestra la pila de protocolos necesaria para el establecimiento de llamada. Por un lado, los comandos AT son necesarios para controlar el teléfono móvil o el módem, y por otro, es necesaria otra pila, PPP sobre RFCOMM por ejemplo, para transferir los datos de pago. Figura Pila protocolos para Internet Bridge. En el caso del fax, la pila de protocolos es muy similar pero PPP y los protocolos de red sobre PPP no se usan y el software de aplicación envía un facsímile directamente sobre RFCOMM. Pág. 33

44 Acceso a una LAN En este modelo de uso, los DTs 7 usan un punto de acceso LAN (LAP) inalámbrico como conexión a la red de área local. Una vez conectados, los DTs operan como si ellos estuvieran conectados a la LAN con una conexión telefónica de red. Así, los DTs pueden acceder a todos los servicios proporcionados por la LAN. La pila de protocolos es muy similar a la del modelo de uso de Internet Bridge exceptuando que no se emplean los comandos AT. Figura Pila de protocolos para acceso a LAN. Sincronización Este modelo de uso proporciona una sincronización dispositivo-dispositivo de la información PIM 8, típicamente agendas de teléfonos, calendarios, mensajes, pequeñas anotaciones. La sincronización requiere que la información de tarjetas, calendarios y tareas sea transferida y procesada por ordenadores, teléfonos celulares y PDAs usando protocolos comunes e igual formato. A continuación se muestra la pila de protocolos: 7 terminales de múltiples datos 8 Personal Information Management Pág. 34

45 Figura Pila de protocolos para sincronización. 3.2 J2ME INTRODUCCIÓN A J2ME Es una versión de Java orientada a dispositivos electrónicos con capacidades computacionales y graficas muy reducidas, como teléfonos móviles, PDAs o electrodomésticos. La maquina virtual es la KVM 9, que solo necesita unos Kilobytes de memoria para funcionar, en vez de la JVM Kilo Virtual Machine. 10 Java Virtual Machine. Pág. 35

46 Figura Arquitectura de la plataforma Java Sun Java no es un simple lenguaje de programación, sino un conjunto de tecnologías que abarca a todos los ámbitos de la computación, con dos elementos comunes: El código intermedio es interpretado por la Virtual Machina Todas las tecnologías comparten una serie de APIs básicas como la java.lang y java.io. J2ME contiene una parte reducida de las APIs que contiene J2SE, debido a que estas ocupan alrededor de 20 Mb. Utiliza 37 clases de los paquetes java.lang, java.io y java.util, de la plataforma J2SE, que forman parte de la llamada configuración. Pág. 36

47 Figura Relación entre las APIs de las plataformas Java MÁQUINAS VIRTUALES J2ME La máquina virtual es la encargada de interpretar código intermedio (bytecode) de las aplicaciones Java precompiladas a código máquina ejecutable por la plataforma, efectuando llamadas al SO. Proporciona independencia de la plataforma con respecto al hardware y al SO. J2ME define varias VMs, adecuándose a los distintos dispositivos según sus exigencias. Existen dos configuraciones CLDC y CDC, cada una de ellas con características propias por lo que cada una requiere su propia maquina virtual. La configuración CLDC se denomina KVM y la de la configuración CDC se denomina CVM. Entraremos a ver en profundidad la KVM que es la que se va a utilizar. Figura Entorno de ejecución. Pág. 37

48 KVM Figura Arquitectura MIDP/CLDC/KVM Es maquina virtual mas pequeña desarrollada por Sun. Ocupa entre 40Kb y 80Kb. Esta orientada a dispositivos con bajas capacidades computacionales y de memoria. Esta escrita en lenguaje C en unas líneas de código. Limitaciones respecto a la JVM, no existen: Tipos en coma flotante, es decir no existe double ni float. Es debido al que el hardware de los dispositivos no lo soportan. Soporte JNI 11 debido a los recursos limitados de memoria. class loaders 12 definidos por el usuario, sólo predefinidos. Hilos deamon 13. Finalización de instancias de clases. Método Object.finalize(). Referencias débiles 14. Limitación de excepciones debido a las APIs. Reflexión Java Native Interface. 12 cargadores de clase. 13 grupos de hilos. 14 Un objeto que está siendo apuntado mediante una referencia débil es un candidato para la recolección de basura. Estas referencias están permitidas en J2SE, pero no en J2ME. 15 La reflexión es el mecanismo por el cual los objetos pueden obtener información de otros objetos en tiempo de ejecución como, por ejemplo, los archivos de clases cargados o sus campos y métodos. Pág. 38

49 A parte de los citados, la verificación de clases tampoco esta incluida ya que es demasiado grande para la KVM, incluso mas grande que esta y un consumo de memoria excesivo (100Kb para aplicaciones típicas). Tiene como función de rechazar las clases no válidas en tiempo de ejecución. Los dispositivos con CLDC y KVM tienen un algoritmo de verificación de clases en dos pasos: Figura Preverificación de clases en CDLC/KVM CONFIGURACIONES Una configuración es un conjunto de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Describen las características básicas comunes a todos los dispositivos: Características soportadas del lenguaje de programación Java. Características soportadas por la Maquina Virtual Java. Bibliotecas básicas de Java y APIs soportadas. Existen dos configuraciones para J2ME: CLDC y CDC para dispositivos con menos limitaciones. Pág. 39

50 A continuación explicaremos en profundidad la configuración CLDC que es la utilizada en el proyecto: CLDC, configuración de dispositivos limitados con conexión. Está orientada a dispositivos con conexión y limitaciones en cuanto a capacidad gráfica, cómputo y memoria, como teléfonos móviles, PDAs Algunas de estas limitaciones vienen dadas por la KVM, necesaria para CLDC por su pequeño tamaño. Los dispositivos que usan CLDC deben cumplir una serie de requisitos: Memoria total disponible entre 160Kb/512Kb. Un mínimo de 128Kb de memoria no volátil para la KVM y CLDC, y 32Kb de memora volátil para la KVM en tiempo de ejecución. Procesador de 16/32 bits con un mínimo de 25Mhz de velocidad. Bajo consumo. Conexión a algún tipo de red. La configuración CLDC aporta una serie de funcionalidades a los dispositivos: Subconjunto del lenguaje Java y limitaciones de la KVM. Subconjunto de bibliotecas Java del núcleo. Soporte para E/S básica. Soporte para acceso a redes. Seguridad. Pág. 40

51 Librerías incluidas en CLDC: Nombre del paquete CLDC java.io java.lang java.util javax.microedition.io Descripción Clases y paquetes estándar de E/S. Subconjunto de J2SE. Clases e interfaces de la MV. Subconjunto de J2SE. Clases, interfaces y utilidades estándar. Subconjunto de J2SE Clases e interfaces de conexión genérica CLDC. Tabla Librerías de configuración CLDC PERFILES Este nivel es el más visible a los usuarios y programadores de aplicaciones. Las aplicaciones se desarrollan sobre un determinado perfil que a su vez está implementado sobre una determinada configuración. Un perfil define un conjunto de APIs y características comunes para una serie de dispositivos. Las clases de un perfil permiten el acceso a funciones específicas de los dispositivos como la interfaz gráfica, funciones de red, almacenamiento persistente, etc. Las aplicaciones desarrolladas sobre un determinado perfil van a ser portables a cualquier dispositivo que soporte ese perfil, cabe destacar que un dispositivo puede soportar varios perfiles y que sobre una configuración pueden existir diversos perfiles. De igual forma, un perfil define las APIs que controlan el ciclo de vida de la aplicación, interfaz de usuario, etc. Más concretamente, un perfil es un conjunto de APIs orientado a un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y el tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un componente muy importante en la definición de un perfil. Aquí se pueden encontrar grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de los PDAs. Pág. 41

52 El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicación se cuente tanto con las APIs del perfil como de la configuración. Se debe tener en cuenta que un perfil siempre se construye sobre una configuración determinada, de este modo, podemos pensar en un perfil como un conjunto de APIs que dotan a una configuración de funcionalidad específica. En J2ME se han definido los siguientes perfiles: Foundation Profile: Este perfil define una serie de APIs sobre la CDC orientadas a dispositivos que carecen de interfaz gráfica como, por ejemplo, decodificadores de televisión digital. Este perfil incluye gran parte de los paquetes de J2SE, pero excluye totalmente los paquetes java.awt Abstract Windows Toolkit (AWT) y java.swing que conforman la interfaz gráfica de usuario (GUI) de J2SE. Si una aplicación requiriera una GUI, entonces sería necesario un perfil adicional. Personal Profile: El Personal Profile está construido sobre la CDC y es un subconjunto de la plataforma J2SE v1.3, que proporciona un entorno con un completo soporte gráfico AWT. El objetivo es el de dotar a la configuración CDC de una interfaz gráfica completa, con capacidades Web y soporte de applets Java. Este perfil requiere una implementación del Foundation Profile. RMI Profile: Este perfil también está construido sobre la CDC y requiere que una implementación del Foundation Profile se construya debajo de él. El perfil RMI soporta un subconjunto de las APIs J2SE v1.3 RMI, debido a que algunas características de estas APIs se han eliminado del perfil RMI debido a las limitaciones computacionales y de memoria de los dispositivos. PDA Profile: El PDA Profile está construido sobre CLDC. Pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y algún tipo de puntero (ratón o lápiz) y una resolución de al menos píxeles (al menos 200x 100 píxeles) con un factor 2:1. Pág. 42

53 MID Profile: Este perfil esta construido sobre la CLDC y es el perfil más usado actualmente para el desarrollo de aplicaciones EL PERFIL MIDP El primer perfil desarrollado se denomina MIDP, que en conjunto está diseñado para operar con el CDLC y permitir la ejecución de aplicaciones java en dispositivos móviles MID 16. En el desarrollo de este perfil participan empresas tales como Ericcson, Motorola, Nokia, NTT DoCoMo, Palm Computing, Sony, Siemens y Sun Microsystems, entre otros e incluye teléfonos celulares y PDAs. Se han definido dos perfiles, el MIDP 1.0 y el MIDP 2.0, cuyas especificaciones finales salieron en Septiembre de 2000 y Noviembre de 2002 respectivamente. MIDP 1.0 Está construido sobre la configuración CLDC. a) Hardware Este perfil está orientado para dispositivos con las siguientes características: Reducida capacidad computacional y de memoria. Conectividad limitada (en torno a 9600bps). Capacidad gráfica muy reducida (mínimo un display de 96x54 píxeles monocromo). Entrada de datos alfanumérica reducida. 128Kb de memoria no volátil para componentes MIDP. 8Kb de memoria no volátil para datos persistentes de aplicaciones. 32Kb de memoria volátil en tiempo de ejecución para la pila Java. 16 Mobile Information Devices Pág. 43

54 b) Capacidades de las APIs El MIDP 1.0 incluyó solo las APIs que eran consideradas como requerimiento absoluto para alcanzar una amplia portabilidad, estas APIs están relacionadas con: Aplicación (Definición de la semántica y control de la aplicación MIDP) Interfaz de usuario (manejo de entradas y Despliegues) Almacenamiento persistente Comunicaciones en red. Temporizadores (Timers) MIDP 2.0 La versión 2.0 del MIDP introduce mejoras respecto a la versión anterior, principalmente en los paquetes de interfaces graficas de usuario, conectividad a redes y seguridad. La evolución tecnológica que se ha dado en los dispositivos móviles modernos, los cuales proporcionan mas memoria, pantallas a color mejoradas, soporte para multimedia (video, MP3) y cámara fotográfica incorporada también se ve reflejada en la versión 2.0 del MIDP, la cual mejora las capacidades de la plataforma de Java para los dispositivos móviles. a) Hardware Para poder ejecutar aplicaciones MIDP 2.0, los dispositivos deberían tener las siguientes características mínimas: Despliegue: o Tamaño de Pantalla: 96x54 píxeles o Profundidad de despliegue: 1-bit Entradas: o Teclado o Pantalla de tacto Pág. 44

55 Memoria: o 256 Kb de memoria no volátil para la aplicación MIDP, más de la que requiere CLDC. o 8 Kb de memoria no volátil para datos persistentes creados en la aplicación. o 128 Kb de memoria volátil para el ambiente de ejecución Java. Conexión a redes: o Dos vías, acceso inalámbrico posiblemente intermitente con ancho de banda limitado. Sonido: o Capacidad para reproducir tonos, vía hardware o software. b) Capacidades de las APIs Al igual que MIDP 1.0, la versión 2.0 de este perfil solo incluyó las APIs consideradas como requerimiento indispensable para asegurar la portabilidad de las aplicaciones. El MIDP 2.0 proporciona APIs para: Manejo del ciclo de vida de las Aplicaciones (definición de la semántica de una aplicación MIDP y cómo ésta es controlada). Firmado de aplicaciones y seguridad para dominios privilegiados. Transacciones seguras entre usuarios finales (https) Registro de aplicaciones push (modelo de servidor push) Interconexión a redes. Almacenamiento persistente. Sonido Temporizadores Interfaces de usuario mejoradas (que incluye despliegue, entradas y soporte para juegos). Pág. 45

56 COMPARACIÓN ENTRE LOS PERFILES MID1.0 Y MID2.0 A continuación se tratarán las diferencias a nivel de software, tomando como punto de comparación los tipos de paquetes que define cada perfil. La especificación del MIDP 2.0 ha determinado la existencia de 8 tipos de paquetes, incluyendo los paquetes del núcleo, mientras que MIDP 1.0 define la existencia de 4 tipos de paquetes, incluyendo también los paquetes del núcleo. En la siguiente tabla se muestran los paquetes incluidos en cada uno de los perfiles indicando el tipo de paquete al que hacen referencia. Pág. 46

57 Tipo de paquete Interfaz de Usuario Paquete MID2.0 javax.microedition.lcdui Paquetes MID1.0 javax.microedition.lcdui Juegos javax.microedition.lcdui.game Ciclo de vida javax.microedition.midlet javax.microedition.midlet Interconexión a Redes javax.microedition.io javax.microedition.io Seguridad javax.microedition.pki Sonido javax.microedition.media javax.microedition.media.control Persistencia de datos javax.microedition.rms javax.microedition.rms Básicos java.io java.io o del java.lang java.lang Núcleo java.util java.util Tabla Paquetes y tipos de paquetes en MIDP 1.0 y MIDP APIs JAVA para BLUETOOTH No se podía desarrollar aplicaciones Java Bluetooth hasta que apareció el estándar JSR 82, escondiendo la complejidad del protocolo Bluetooth con unos APIs que permiten centrarse en el desarrollo en vez de los detalles de bajo nivel del Bluetooth. Pág. 47

58 Estos APIs están orientados para dispositivos que cumplan las siguientes características: Al menos 512K de memoria libre (ROM y RAM) (las aplicaciones necesitan memoria adicional). Conectividad a la red inalámbrica Bluetooth. Que tengan una implementación del J2ME CLDC. JSR 82 El objetivo de ésta especificación era definir un API estándar abierto, que pudiera ser usado en todos los dispositivos que implementen J2ME. Fue diseñado usando los APIs J2ME y el entorno de trabajo CLDC/MIDP. Los APIs JSR 82 son muy flexibles, ya que permiten trabajar tanto con aplicaciones nativas Bluetooth como con aplicaciones Java Bluetooth. El API intenta ofrecer las siguientes capacidades: Registro de servicios. Descubrimiento de dispositivos y servicios. Establecer conexiones RFCOMM, L2CAP y OBEX entre dispositivos. Mandar y recibir datos (comunicaciones de voz no soportadas). Manejar y controlar las conexiones de comunicación. Seguridad. Los APIs Java para Bluetooth definen dos paquetes que dependen del paquete CLDC javax.microedition.io: javax.bluetooth javax.obex Pág. 48

59 MIDP y Bluetooth API Los dispositivos MIDP, son los primeros que incorporan esta especificación, la cual permite la coexistencia entre MIDP y Bluetooth APIs. La siguiente figura es un ejemplo de la arquitectura CLDC+MIDP. El API Bluetooth y las API s MIDP pueden coexistir en un dispositivo MIDP+Bluetooth. En un dispositivo CLDC+Bluetooth, no existen las porciones MIDP del diagrama. Figura CLDC+MIDP+Bluetooth Architecture Diagram Sobre el API JSR-82 Este API está dividida en dos partes: el paquete javax.bluetooth y el paquete javax.obex. Los dos paquetes son totalmente independientes. El primero de ellos define clases e interfaces básicas para el descubrimiento de dispositivos, descubrimiento de servicios, conexión y comunicación. La comunicación a través de javax.bluetooth es a bajo nivel: mediante flujos de datos o mediante la transmisión de arrays de bytes. Por el contrario el paquete javax.obex permite manejar el protocolo de alto nivel OBEX (OBject EXchange). Este protocolo es muy similar a HTTP y es utilizado sobre todo para el intercambio de archivos. El protocolo OBEX es un estándar desarrollado por IrDA y es utilizado también sobre otras tecnologías inalámbricas distintas de Bluetooth. Pág. 49

60 La plataforma principal de desarrollo del API JSR-82 es J2ME. El API ha sido diseñado para depender de la configuración CLDC. Sin embargo existen implementaciones para poder hacer uso de este API en J2SE. El paquete javax.bluetooth En una comunicación Bluetooth existe un dispositivo que ofrece un servicio (servidor) y otros dispositivos acceden a él (clientes). Dependiendo de qué parte de la comunicación debamos programar deberemos realizar una serie de acciones diferentes. Un cliente Bluetooth deberá realizar las siguientes: Búsqueda de dispositivos. La aplicación realizará una búsqueda de los dispositivos Bluetooth a su alcance que estén en modo conectable. Búsqueda de servicios. La aplicación realizará una búsqueda de servicios por cada dispositivo. Establecimiento de la conexión. Una vez encontrado un dispositivo que ofrece el servicio deseado nos conectaremos a él. Comunicación. Ya establecida la conexión podremos leer y escribir en ella. Por otro lado, un servidor Bluetooth deberá hacer las siguientes operaciones: Crear una conexión servidora Especificar los atributos de servicio Abrir las conexiones clientes Pág. 50

61 El paquete javax.obex Este paquete es totalmente independiente del paquete javax.bluetooth, es decir, cuando hagamos una aplicación utilizando el protocolo OBEX no usaremos ninguna de las clases del paquete javax.bluetooth. OBEX es un protocolo que se usa generalmente para la transferencia de archivos. Es muy similar a HTTP: consiste en el intercambio de mensajes entre el cliente y el servidor. Tales mensajes consisten en un conjunto de cabeceras de mensaje y opcionalmente un cuerpo de mensaje. En este protocolo el cliente envía comandos al servidor (CONNECT, PUT, GET, DELETE, SETPATH, DISCONNECT) junto con algunas cabeceras de mensaje y en ocasiones (comando PUT) un cuerpo de mensaje. Las cabeceras de mensaje están encapsuladas en un objeto HeaderSet y el cuerpo de mensaje se lee/escribe mediante un Input/OutputStream. El servidor por su parte recibirá los comandos del cliente y responderá con un código de respuesta indicando el éxito o no de la petición. Enviará además una serie de cabeceras de mensaje con información adicional y un cuerpo de mensaje en caso de tratarse de una respuesta al comando GET. El comando CONNECT es necesario para completar el inicio de la sesión. El comando PUT envía datos del cliente al servidor y el comando GET envía datos del servidor al cliente. El comando DELETE sirve para eliminar un recurso del servidor. El comando SETPATH sirve para crear directorios y navegar por ellos, y finalmente el comando DISCONNECT sirve para cerrar la conexión. Pág. 51

62 4. REQUISITOS 4.1 OBJETIVOS FUNCIONALES 4.2 OBJETIVOS TECNOLÓGICOS 4.3 CASOS DE USO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER Pág. 52

63 4. REQUISITOS 4.1 OBJETIVOS FUNCIONALES Se pretende implementar una aplicación cliente/servidor donde un dispositivo móvil formará la parte cliente, y un PC que hará de servidor, entre ambas partes se establece una conexión remota a partir de la tecnología inalámbrica Bluetooth. La parte cliente será implementada en Java J2ME y será la encargada de gestionar los datos que le sean introducidos de los alumnos mediante un interfaz sencillo y rápido de manejar, obteniendo como producto el almacenamiento persistente de estos datos en una base de datos RMS, durante un periodo de tiempo que será el que se corresponde desde su almacenamiento hasta su posterior transferencia de los datos al ordenado, siendo liberados del dispositivo móvil ya que este tiene los recursos limitados. Los datos y funcionalidades que se van a introducir a la aplicación permanecerán abiertas a posibles cambios y mejoras en función de los resultados obtenidos y partiendo de una base que será el control de asistencia de los alumnos. La parte servidor, será implementada en Java J2SE 5.0 será la encargada de la recepción de los datos y su posterior gestión, ya que estos han de actualizar las bases de datos correspondientes. También tendrá que implementar la transmisión de datos, por si es necesario el paso de información del PC al dispositivo móvil. En la siguiente tabla se especifican los diferentes módulos a utilizar en la aplicación, son los siguientes: Pág. 53

64 MÓDULOS CLIENTE MÓDULOS SERVIDOR GUI sencilla. Gestión BBDD Móvil. Búsqueda de dispositivos. Crear una conexión servidora. Especificar los atributos de servicio. Abrir las conexiones clientes. Búsqueda de servicios. Establecimiento de la conexión. Comunicación. Gestión de Faltas. Gestión de Notas. Tabla 4.1. Módulos del proyecto. A continuación se va a mostrar otra tabla que recoge los posibles módulos de expansión de la aplicación, tanto en la parte cliente como en el servidor: EXPANSIÓN CLIENTE EXPANSIÓN SERVIDOR GUI avanzado. Gestión de Alumnos. GUI. Gestión BBDD. Gestión BBDD Móvil. (insertar alumnos) Tabla 4.2. Módulos de expansión del proyecto. Pág. 54

65 La siguiente figura va a dar una visión gráfica de los módulos iniciales (sin la expansión), para una mejor comprensión del funcionamiento de la aplicación: CLIENTE SERVIDOR Datos alumnos GUI sencilla. Gestión BBDD Móvil. Actualizar BBDD Gestión de Faltas Búsqueda de dispositivos. Crear una conexión servidora. Gestión de Alumnos Establecimiento de la conexión. Comunicación. Especificar los atributos de servicio. Abrir las conexiones clientes Figura 4.1. Módulos del proyecto. Pág. 55

66 4.2 OBJETIVOS TECNOLÓGICOS Se pretende utilizar dispositivos móviles, que tengan implantado la tecnología necesaria para poder soportar la aplicación cliente, como es KVM, MIDP 2.0, CLDC 1.1 y Bluetooth. Al igual sucede con la parte servidor ya que el ordenador necesitara soportar J2SE y tener un dispositivo Bluetooth. Con este proyecto se pretende afianzar los conocimientos adquiridos en el campo de la programación en Java, además de la ampliación de los mismos, contribuyendo a esto la implementación de la aplicación cliente en J2ME. También es interesante el aprendizaje en la implementación y utilización de nuevas tecnologías, como sucede con la utilización de la tecnología inalámbrica Bluetooth. 4.3 CASOS DE USO Existen dos actores por aplicación, es decir, en el caso del cliente: SOSA Bluetooth Mobile, tenemos al Profesor y al servidor, y en el caso del servidor: SOSA Bluetooth Server, nos encontramos con el profesor y la aplicación cliente El profesor va a manejar tanto la aplicación cliente como la servidora, ya que ambas son empleadas para la gestión de su base de datos de alumnos. Las principales operaciones que se van a desarrollar en el sistema cliente son: Pasar lista Ver Record Store. Dar de baja un Record Store. Dar de alta un alumno. Modificar un alumno. Modificar contraseña. Pág. 56

67 Recibir datos. Enviar datos. Las principales operaciones que se van a desarrollar en el sistema servidor son: Ver base de datos. Informe de faltas. Actualizar base de datos. Recibir datos. Enviar datos. El siguiente diagrama de casos de uso nos aportará una visión gráfica del comportamiento del sistema desde el punto de vista del usuario: Pág. 57

68 SOSA BLUETOOTH MOBILE Cliente SOSA Bluetooth Mobile Pasar lista Ver Record Store Dar de baja un Record Store Dar de alta un alumno Profesor Modificar un alumno Modificar contraseña SOSA Bluetooth Mobile Servidor Sincronización Figura 4.2. Casos de uso de SOSA Bluetooth Mobile. Pág. 58

69 SOSA BLUETOOTH SERVER Servidor - SOSA Bluetooth Mobile Servidor Ver base de datos Informe de faltas Actualizar base de datos Profesor Recibir SOSA Bluetooth Mobile Enviar Figura 4.3. Casos de uso de SOSA Bluetooth Mobile. Pág. 59

70 5. DISEÑO 5.1 MODELO DE DOMINIO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER 5.2 DIAGRAMAS DE COLABORACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER 5.3 MODELO DE DATOS Pág. 60

71 5. DISEÑO 5.1 MODELO DE DOMINIO SOSA BLUETOOTH MOBILE ConexionBD + conectarmaccess + informacionconexion + cerrarconexion + iniciarbloque + insertarcampo + cerrarbloque + existecampo + buscarcampo + actualizarcampo + eliminarcampo + Select + getconexion + getrs + IniciarTransaccion + CancelarTransaccion + ConfirmarTransaccion + ejecutaconsulta + ejecutapreparedst + getconsulta Alumno - nombreapellidos : String - asignatura : String - curso : String - clave : String + getnombre + getclave + getasignatura + getcurso + setnombre + setclave + setasignatura + setcurso + tostring Main titulo : String Comunicacion - nombrepuerto : String - main : Main + open + read + write + close + cargarpuertos + setfin + actionperformed + gettexarea + settextarea + settexto + run + cargarcurso + cargarasignatura + cargaralumno + mostrarbd + actualizarbd + eliminarrepetidos + mostraralarma + actualizarpb + setmaximopb Pág. 61

72 APP ALUMNO COMUNICACION RMS SOSA BLUETOOTH SERVER Rms + abrirrs + escribiralumnors + escribirfaltasrs + sustituirdators + leeralumnors + leerfaltasrs + cerrarrs + destruirrs + compare + escribircontraseñars + leercontraseñars + modificaralumno + gemid + getfecha Alumno - nombreapellidos : String - asignatura : String - curso : String - clave : String + getnombre + getclave + getasignatura + getcurso + setnombre + setclave + setasignatura + setcurso + tostring Pág. 62

73 Comunicacion - app : App App + getpantalla + volverapp - pantallaprincipal - pantallatext - pantallaenviar - pantallarecibir + commandaction + mostraralarma + escribir + leer + run + mostrardispositivos + mostrarservicios + DiscoveryListener + startapp + pauseapp + destroyapp + commandaction + buscarrs + mostrarrs + ordenarv + mostraralarma + volverlismenu + setopciover + getfecha MAIN ALUMNO COMUNICACION CONEXIONBD Pág. 63

74 5.2 DIAGRAMAS DE COLABORACIÓN SOSA BLUETOOTH MOBILE Pasar Lista: App 1: commandaction(lismenu, cmdseleccionar) 2: buscar(lisrs) 3: commandaction(lisrs, cmdseleccionar) 4: mostrarrs(lispasarl, nombrers) 5: commandaction(lispasarl, cmdguardar) 6: commandaction(tesalumno, cmdguardarfaltas) [guardaren.equals("")] 6.2 : mostraralarma("debe introducir el nombre para guardar los [!guardaren.equals("")] 6.1: abrirrs(guardaren) [enu.hasmoreelements()] 6.1.1: escribirfaltasrs(alaux,rsaux) 6.1.2: cerrarrs(rsaux) Rms Resultado : alumno.getnombre() : alumno.getclave() : alumno.getasignatura() : alumno.getcurso() Alumno Ver Record Store App 1: commandaction(lisdatos, cmdseleccionar) 2: commandaction(lisver, cmdseleccionar) 3: buscar(lisrs) 4: commandaction(lisrs, cmdseleccionard) 5: mostrarrs(lisdatop, nombrers) Pág. 64

75 Dar de alta un alumno App 1: commandaction(lisdatos, cmdseleccionar) 2: buscar(lisrs) 3: commandaction(texalumno, cmdsiguiente) [nombre.equals("")] 3.1: mostraralarma("debe introducir un nombre", texalumno) [!nombre.equals("")] 3.2: commandaction (texalumno, cmdsiguienteapell) [nombreapellidos.equals("")] 3.2.1: mostraralarma ("Debe introducir los apellidos de " + nombre, texalumno) [!nombreapellidos.equals("")] 3.2.2: commandaction (texalumno, cmdsiguienteclave) [claveal.equals("")] : mostraralarma ("Debe introducir la clave de " + nombreapellidos, texalumno) [!claveal.equals("")] : commandaction (texalumno, cmdsiguienteasig) [asignatura.equals("")] : mostraralarma ("Debe introducir la asignatura a la que pertenece " + nombreapellidos, texalumno) [!asignatura.equals("")] : commandaction (texalumno, cmdsiguientecurso) [curso.equals("")] : mostraralarma "Debe introducir el curso y grupo al que pertenece " + nombreapellidos, texalumno) [!curso.equals("")] : commandaction (lisrs, cmdguardar) Alumno : new Alumno (nombreapellidos, claveal, asignatura, curso) : abrirrs(guardaren) : escribirfaltasrs (alumno, rsaux) : cerrarrs(rsaux) Resultado Rms : alumno.getnombre() : alumno.getclave() : alumno.getasignatura() : alumno.getcurso() Pág. 65

76 Dar de baja un Record Store App 1: commandaction(lisdatos, cmdseleccionar) 2: buscar(lisrs) 3: commandaction(lisver, cmdseleccionar) 4: buscar(lisrs) 5: commandaction(lisrs, cmdbajars) 6.1: commandaction(forpregunta, cmdsi) 6.2: commandaction(forpregunta, cmdno) 6.1.2: mostraralarma("el Record Store " + nombrers + " ha sido dado de baja correctamente", lismenu) 6.1.1: deleterecordstore(nombrers) [enu.hasmoreelements()] 6.1.1: escribirfaltasrs(alaux,rsaux) 6.1.2: cerrarrs(rsaux) Rms Modificar la contraseña App 1: commandaction(lismenu, cmdseleccionar) 2: commandaction(texmodificarc1, cmdsiguiente) [texmodificarc1.getstring().equals(sclavecomp)] 3: commandaction(texmodificarc2, cmdsiguiente) 4: commandaction(texmodificarc3, cmdmodificar) [texmodificarc3.getstring().equals(sclavenueva)] 5.1: destruirrs("contraseña") 5.2: abrirrs("contraseña") 5.3: escribircontraseñars(sclavenueva,rsclave) 5.4: cerrarrs(rsclave) Rms Pág. 66

77 Modificar un alumno App 8: almod.getnombre() 9: almod.getclave() 10: almod.getasignatura() 11: almod.getcurso() 1: commandaction(lisdatos, cmdseleccionar) 2: buscar(lisrs) 3: commandaction(lisver, cmdsiguiente) 4: buscarrs(lisrs) 5: commandaction(lisrs, cmdsiguiente) 6: mostrarrs(lisdatop,nombrers) 7: commandaction(lisdatop, cmdseleccionard) 12: commandaction (texalumno, cmdsiguienteapell) [nombreapellidos.equals("")] 12.1: mostraralarma ("Debe introducir el nombre y apellidos", texalumno) [!nombreapellidos.equals("")] 12.2: commandaction (texalumno, cmdsiguienteclave) [claveal.equals("")] : mostraralarma ("Debe introducir la clave de " + nombreapellidos, texalumno) [!claveal.equals("")] : commandaction (texalumno, cmdsiguienteasig) [asignatura.equals("")] : mostraralarma ("Debe introducir la asignatura a la que pertenece " + nombreapellidos, texalumno) [!asignatura.equals("")] : commandaction (texalumno, cmdsiguientecurso) [curso.equals("")] : mostraralarma "Debe introducir el curso y grupo al que pertenece " + nombreapellidos, texalumno) [!curso.equals("")] : commandaction (forpregunta, cmdguardar) Alumno : new Alumno (nombreapellidos, claveal, asignatura, curso) : abrirrs(guardaren) : modificaralumno(nombrers,idal,alumno) : cerrarrs(rsaux) Resultado Rms : almod.getnombre() : almod.getclave() : almod.getasignatura() : almod.getcurso() Pág. 67

78 Sincronización: App 1: commandaction(lismenu, cmdseleccionar) : buscarrs(lise) : mostrarrs(lise, nombrers) : getfecha() Rms Resultado Alumno Resultado Comunicacion : abrirrs(guardaren) [e.hasmoreelements()] : escribiralumnors(a,rsaux) : cerrarrs(rsaux) 2: new Comunicacion(this) : a.getnombre() : a.getclave() : a.getasignatura() : a.getcurso() [(int i=0; i< dis. readint() ; i++ ) ] : new Alumno(dis.readU TF (),dis.readutf (),dis.readutf (),dis.readutf ()) 3: pantallaprincipal() 4: commandaction(lisp, cmdbuscardisp) 5: devicediscovered(remotedevice dispositivoremoto, DeviceClass clase) 6: inquirycompleted(int completado) [dispositivos_encontrados.size()==0] 6.1: commandaction(lisp, cmdbuscardisp) [!dispositivos_encontrados.size()==0] 6.2: mostrardispositivos() 6.2.1: commandaction(lisp, cmdbuscarserv) : servicesdiscovered(int transid, ServiceRecord[] servrecord) : servicesearchcompleted(int transid, int respcode) [servicios_encontrados.size()>0] : mostrarservicios() [!servicios_encontrados.size()>0] : mostrardispositivos() : commandaction(lisp, cmdbuscardisp) : commandaction(lisp, cmdenviar) : commandaction(lisp, cmdrecibir) : pantallaenviar() [swenv] : commandaction(lise, cmdsiguiente) : commandaction(lise, cmdenviarrs) : escribir () : pantallarecibir() : run() : leer() : commandaction(text, cmdguardar) : alumno.getnombre() : alumno.getclave() : alumno.getasignatura() : alumno.getcurso() Pág. 68

79 5.2.2 SOSA BLUETOOTH SERVER Ver base de datos: Main 1: cargarcurso() 1.4: eliminarrepetidos(vaux, vcurso) 2: cargarasignatura() 2.4: eliminarrepetidos(vaux2, vasignatura) 3: actionperformed(e.getsource() == jcbcurso) 4: actionperformed(e.getsource() == jcbasignatura) 5: actionperformed(e.getsource() == jbmostrar) [!jrbinfofaltas.isselected()] 6: mostrarbd() 6.3.2: settextarea(s) Resultado ConexionBD 1.1: new ConexionBD() 1.2: conectarmaccess("sosabm.mdb") 1.3: Select("SELECT Curso FROM Alumnos ORDER BY Curso") 1.5: cerrarconexion() 2.1: new ConexionBD() 2.2: conectarmaccess("sosabm.mdb") 2.3: Select("SELECT Asignatura FROM Alumnos ORDER BY Asignatura") 2.5: cerrarconexion() 6.1: new ConexionBD() 6.2: conectarmaccess("sosabm.mdb") [!jrbinfofaltas.isselected()] 6.3: Select("SELECT * FROM Alumnos WHERE Curso='"+ jcbcurso.getselecteditem().tostring() + "' AND " + "Asignatura='" + jcbasignatura.getselecteditem().tostring() + "' ORDER BY NombreApellidos") 6.3.3: cerrarconexion() Resultado [rs.next()] 6.3.1: new Alumno(rs.getString("NombreApellidos"), rs.getstring("clave"), rs.getstring ("Asignatura"), rs.getstring("curso")) Alumno Pág. 69

80 Informe de faltas: Main 1: cargarcurso() 1.4: eliminarrepetidos(vaux, vcurso) 2: cargarasignatura() 2.4: eliminarrepetidos(vaux2, vasignatura) 3: actionperformed(e.getsource() == jcbcurso) 4: actionperformed(e.getsource() == jcbasignatura) 5: cargaralumno() [!noalumnos] 5.4: eliminarrepetidos(vaux4, valumno) 6: actionperformed(e.getsource() == jbmostrar) 7: actionperformed(e.getsource() == jrbinfofaltas) [jrbinfofaltas.isselected()] 8: mostrarbd() 8.3.2: settextarea(s) Resultado ConexionBD 1.1: new ConexionBD() 1.2: conectarmaccess("sosabm.mdb") 1.3: Select("SELECT Curso FROM Alumnos ORDER BY Curso") 1.5: cerrarconexion() 2.1: new ConexionBD() 2.2: conectarmaccess("sosabm.mdb") 2.3: Select("SELECT Asignatura FROM Alumnos ORDER BY Asignatura") 2.5: cerrarconexion() 5.1: new ConexionBD() 5.2: conectarmaccess("sosabm.mdb") 5.3: Select("SELECT NombreApellidos FROM Alumnos " + "WHERE Asignatura='" + asig + "' " + "AND Curso='" + cur + "' " + "ORDER BY NombreApellidos") 5.5: cerrarconexion() 8.1: new ConexionBD() 8.2: conectarmaccess("sosabm.mdb") [jrbinfofaltas.isselected()] 8.3: Select("SELECT Clave FROM Alumnos " + "WHERE Asignatura='" + asig + "' " + "AND Curso='" + cur + "AND NombreApellidos='" + nom + "'") 8.3.1: Select("SELECT * FROM Faltas " + "WHERE Clave='" + clave + "'" + " ORDER BY Fecha") 8.3.3: cerrarconexion() Pág. 70

81 Actualizar base de datos: Main 1: actionperformed(e.getsource() == jbactualizar) [n2 == JOptionPane.YES_OPTION] 2: actualizarbd() Resultado 2.1: getfecha() 2.2: new ConexionBD() 2.3: conectarmaccess("sosabm.mdb") [e.hasmoreelements()] 2.4: ejecutaconsulta(sql) 2.5: cerrarconexion() ConexionBD Pág. 71

82 Recibir: Main Resultado 1: actionperformed(e.getsource() == jcbpuerto) 2: actionperformed(e.getsource() == jbiniciar) [op == -1] 3.2: mostraralarma("el puerto " + jcbpuerto.getselecteditem().tostring() + " esta siendo utilizado.") 4: actionperformed(e.getsource() == jbrecibir) 5: settextarea("") 6: start () 7.2: setmaximopb(max) 7.3.1: actualizarpb(i) 7.4: actualizarpb(max) [n == JOptionPane.YES_OPTION] 3: new Comunicacion (this, jcbpuerto.getselecteditem().tostring()) 3.1: open() 7.5: close() ConexionBD 7.1: new Alumno() [int i=0;i<max;i++] 7.3: new Alumno(dis.readUTF (),dis.readutf (),dis.readutf (),dis.readutf ()) [e.hasmoreelements()] 7.6: a.getnombre() Alumno Resultado [modo==0] 7: read() Comunicacion Pág. 72

83 Enviar: Main 1: actionperformed(e.getsource() == jcbpuerto) 2: actionperformed(e.getsource() == jbiniciar) [op == -1] 3.2: mostraralarma("el puerto " + jcbpuerto.getselecteditem().tostring() + " esta siendo utilizado.") 4: actionperformed(e.getsource() == jbenviar) 5.1: setmaximopb(val.size()) 5.2.4: actualizarpb(valor) 5.3: actualizarpb(val.size()) Resultado [n == JOptionPane.YES_OPTION] 3: new Comunicacion (this, jcbpuerto.getselecteditem().tostring()) 3.1: open() 5.4: close() ConexionBD [e.hasmoreelements() &&!fin] 5.2: a.getnombre() 5.2.1: a.getclave() 5.2.2: a.getasignatura() 5.2.3: a.getcurso() Alumno [modo==1] 5: write(valumnosenv, fin) 6: close () Comunicacion Pág. 73

84 5.3 MODELO DE DATOS Se quiere diseñar una Base de Datos que almacene los datos referentes a los alumnos y las faltas de asistencia de los mismos. Para ello se han definido una serie de atributos: (Clave, Asignatura, NombreApellidos, DNI, Curso, Titulacion, Fecha) Clave: clave que identifica de forma unívoca a cada alumno. Asignatura: asignatura a la que pertenece el alumno. NombreApellidos: nombre y apellidos del alumno. DNI: DNI del alumno. Curso: Curso al que pertenece el alumno. Titulacion: titulación a la que pertenece el alumno. Fecha: fecha en la que el alumno ha faltado. Para conseguir el diseño de la Base de Datos, se va a seguir un Modelo Relacional de Entidades y Relaciones. En el se van a definir las relaciones (entidades) que la componen y las interrelaciones que existen, aportándonos una visión o modelo conceptual de datos. Al final del proceso, se van a obtener las tablas, obtenidas de la aplicación de reglas que forman un método formal. Para conseguir el diseño, se van a poner una serie de restricciones al diseño: 1. Un DNI, sólo pertenece a un alumno (clave). 2. El nombre y apellidos de un alumno sólo se corresponde con una clave. 3. Un alumno pertenece sólo a un curso y a una titulación a través de la clave y la asignatura. 4. Se quiere guardar los días que un alumno ha faltado en cada asignatura. Pág. 74

85 DNI R1 NombreApellidos R2 Clave m (Clave, Asignatura, Fecha) m m Titulación R3 (Clave, Asignatura) m R3 Curso Fecha Asignatura Una vez obtenido el diagrama inicial, se van a aplicar las reglas de transformación a las asociaciones explicitas: (Clave, NombreApellidos, DNI) m (Clave, Asignatura, Fecha) m m (Clave, Asignatura, Curso, Titulacion) m Fecha Asignatura Pág. 75

86 A continuación se van a aplicar las reglas de transformación a las asociaciones implícitas: Alumnos (Clave, Asignatura, NombreApellidos, DNI, Curso, Titulacion) Faltas m (Clave, Asignatura, Fecha) Pág. 76

87 6. DISEÑO DE INTERFACES 6.1 SOSA BLUETOOTH MOBILE 6.2 SOSA BLUETOOTH SERVER Pág. 77

88 6. DISEÑO DE INTERFACES Para realizar el diseño de los interfaces, se va a proceder a realizar una navegación por las ventanas de cada aplicación: 6.1 SOSA BLUETOOTH MOBILE Al iniciar la aplicación cliente, se va a mostrar una imagen con el nombre de la aplicación: INICIAR SALIR Introduce la contaseña: **** ENTRAR SALIR 1 2 Pág. 78

89 1 2 ENTRAR Menú Principal Pasar lista Conectar con el PC Calendario Contraseña Gestión de datos Acerca de SELECCIONAR SALIR Primero, desarrollamos la navegación por el submenú Pasar lista. Muestra los Record Stores disponibles en el dispositivo móvil Record Stores BBDD3A Redes2C VOLVER SELECCIONAR Muestra el contenido del Record Store seleccionado, para pasar lista GUARDAR Pasar Lista Cifuentes, Carlos Zapata, Susana Díaz,Pablo VOLVER Pág. 79

90 1 3 4 GUARDAR Introduce el nombre del Record Store Redes01 VOLVER Faltas guardadas GUARDAR en Faltas_Redes01 A continuación, desarrollamos la navegación por el submenú Conectar con PC. Conectar con PC (vacía) VOLVER BUSCAR DISP Conectar con PC Dispositivos: CCF 6600 Búsqueda finalizada VOLVER BUSCAR SERV Conectar con PC Servicios: [ICOM.nokia.mid Búsqueda finalizada VOLVER ENVIAR RECIBIR Pág. 80

91 ENVIAR Enviar BBDD3A Redes2C VOLVER SIGUIENTE Enviar Cifuentes, Carlos Zapata, Susana Díaz, Pablo VOLVER 7 RECIBIR Recibir (vacía) VOLVER Guardar como: Redes02 VOLVER 1 Datos guardados en: 4 Asignaturas_Redes02 Pág. 81

92 1 4 A continuación, desarrollamos la navegación por el submenú Calendario. Calendario [22/05/2005] [11:52] VOLVER A continuación, desarrollamos la navegación por el submenú Contraseña. Introduce la contraseña actual: **** VOLVER SIGUIENTE Introduce la nueva contraseña: **** VOLVER SIGUIENTE Vuelva a introducir la nueva contraseña: MODIFICAR **** VOLVER 4 Pág. 82

93 4 A continuación, desarrollamos la navegación por el submenú Gestión de Datos. Gestión de datos: Ver Altas Bajas Modificaciones VOLVER SELECCIONAR A continuación, desarrollamos la navegación por el submenú Ver de Gestión de Datos. Ver: Asignaturas Faltas VOLVER SELECCIONAR 4 Pág. 83

94 A continuación, desarrollamos la navegación por el submenú Asignaturas de Ver de Gestión de Datos. 4 Record Stores: Asignaturas_Redes Asignaturas_BBDD VOLVER SELECCIONAR Ver: Pérez Casas, Antonio Díaz Mellado, Pablo VOLVER A continuación, desarrollamos la navegación por el submenú Asignaturas de Ver de Gestión de Datos. Record Stores: Faltas_Redes01 Faltas_Redes02 Faltas_BBDD01 VOLVER SELECCIONAR Ver: Pérez Casas, Antonio Díaz Mellado, Pablo 4 Pág. 84

95 A continuación, desarrollamos la navegación por el submenú Altas de Gestión de Datos. 4 Introduce el nombre del alumno: Carlos VOLVER SIGUIENTE Introduce los apellidos de: Carlos López García VOLVER SIGUIENTE Introduce la clave de: López García, Carlos VOLVER SIGUIENTE Introduce la asignatura de: López García, Carlos Seguridad Inf. VOLVER SIGUIENTE 8 4 Pág. 85

96 4 Introduce el curso y grupo de: López García, Carlos 3A VOLVER SIGUIENTE Record Stores: Asignaturas_Redes Asignaturas_BBDD VOLVER GUARDAR Atención Añadido: López García, Carlos Seguridad Inf. 3A en: Asignaturas_Redes Pág. 86

97 A continuación, desarrollamos la navegación por el submenú Bajas de Gestión de Datos. 4 Ver: Asignaturas Faltas VOLVER SELECCIONAR Record Stores: Asignaturas_Redes Asignaturas_BBDD VOLVER DAR BAJA RS Confirmación Desea dar de baja el Record Store: Asignaturas_Redes? NO SI Atención El Record Store Asignaturas_Redes ha sido dado de baja correctamente 4 Pág. 87

98 A continuación, desarrollamos la navegación por el submenú Modificaciones de Gestión de Datos. 4 Ver: Asignaturas Faltas SELECCIONAR Record Stores: Asignaturas_Redes Asignaturas_BBDD VOLVER SELECCIONAR Modificaciones López García, Carlos Zapata Osorio, Susana Pérez Díaz, Luis VOLVER SELECCIONAR Nombre del alumno: López García, Carlos VOLVER 4 Pág. 88

99 SIGUIENTE 4 Clave de: López García, Carlos VOLVER SIGUIENTE Asignatura de: López García, Carlos Seguridad Inf. VOLVER SIGUIENTE Curso y grupo de: López García, Carlos 3A VOLVER SIGUIENTE Confirmación Desea guardar al alumno con estos nuevos datos:? Nombre y apellidos: López García, Carlos Clave: Asignatura: Seguridad Inf. Curso: 3A NO SI 4 Pág. 89

100 A continuación, desarrollamos la navegación por el submenú Acerca de... 4 Acerca de SOSA Bluetooth Mobile versión 1.0 Proyecto Fín de Carrera 2004/2005 ITIG Dirigido y coordinado por: David Contreras Bárcena. Realizado por: Carlos Cifuentes Fernández. Para más información contacte a través del siguiente SOSAbm@gmail.com VOLVER Pág. 90

101 6.2 SOSA BLUETOOTH SERVER Al iniciar la aplicación se mostrará una pantalla como la siguiente: Figura 6.1. Pantalla inicial. Si pulsamos el botón de Iniciar sesión se mostrará el siguiente mensaje: Figura 6.2. Pantalla inicio sesión. Pág. 91

102 Si pulsamos el botón de cancelar volvemos a la pantalla anterior, en cambio si pulsamos el botón de iniciar saldrá la siguiente pantalla, en la cual se ha pulsado el botón de Enviar datos: Figura 6.3. Pantalla enviar datos. Si por el contrario pulsamos el botón de Recibir, se mostrará la siguiente pantalla: Figura 6.4. Pantalla recibir. Pág. 92

103 Si pulsamos el botón Cerrar conexión, volvemos al inicio de la aplicación. Si seleccionamos un curso y una asignatura y pulsamos el botón Mostrar, visualizaremos la siguiente pantalla: Figura 6.5. Pantalla mostrar. Si pulsamos el botón de Actualizar, después de recibir datos, visualizaremos la siguiente pantalla: Figura 6.6. Pantalla inicio sesión. Pág. 93

104 Si pulsamos el botón de Actualizar, actualizaremos la base de datos, si por el contrario pulsamos el botón de Cancelar, volveremos a la pantalla anterior. Si queremos obtener un informe de faltas pulsaremos el check box Informe de faltas, y a continuación elegir el alumno y pulsar Mostrar, visualizando lo siguiente: Pág. 94

105 7. IMPLEMENTACIÓN 7.1 PLATAFORMAS Y ENTORNOS DE DESARROLLO 7.2 FUNCIONALIDADES MÁS IMPORTANTES PROCESO DE SINCRONIZACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER Pág. 95

106 7. IMPLEMENTACIÓN 7.1 PLATAFORMAS Y ENTORNOS DE DESARROLLO La JRE que se ha utilizado ha sido la JRE 5.0, ya que proporciona nuevas funcionalidades interesantes, a parte de J2ME Wireless Toolkit 2.2, para el desarrollo de la aplicación cliente. Para la ejecución y compilación de ambas aplicaciones, se ha utilizado el IDE NetBeans 4.0, junto con el NetBeans Mobility 4.0. que habilita la posibilidad trabajar con dispositivos móviles, tanto compilando como emulando la ejecución. La elección de este IDE se debe a que en el, se pueden desarrollar cualquier tipo de aplicaciones Java en cualquiera de sus plataformas como, por ejemplo, J2SE y J2ME. Otra razón es que el software es libre. 7.2 FUNCIONALIDADES MÁS IMPORTANTES PROCESO DE SINCRONIZACIÓN El proceso de sincronización es el encargado de establecer una vía de comunicación entre el dispositivo móvil y el PC y la posterior transmisión de los datos de una aplicación a otra. Para realizar dichos procesos se han diseñado la clase Comunicacion, en ambas aplicaciones, pero con una implementación diferente: SOSA BLUETOOTH MOBILE Implementación de la clase Comunicacion en la aplicación cliente: clase: A continuación se van a explicar los principales métodos que implementa dicha Pág. 96

107 Esta clase va a controlar todo el proceso de comunicación, controlando sus propios eventos. El control de los eventos de esta clase es el siguiente: public void commandaction(command c, Displayable d) { String label = c.getlabel(); if (label.equals("volver")) { app.volverlismenu(); } else if (d==lisp && c==cmdbuscardisp) { //Limpiamos la lista dispositivos_encontrados.removeallelements(); servicios_encontrados.removeallelements(); try{ //inicializamos... dispositivolocal = LocalDevice.getLocalDevice(); dispositivolocal.setdiscoverable(discoveryagent. GIAC); //sin límite de tiempo da = dispositivolocal.getdiscoveryagent(); lisp.deleteall(); lisp.append("dispositivos:",null); da.startinquiry(discoveryagent.giac,new Listener()); //Para recivir las notificacinoes del //DiscoveryAgent, debemos //implementar el interface DiscoveryListener... } catch(bluetoothstateexception bse){ System.out.println(bse.toString()); } } else if (d==lisp && c==cmdbuscarserv) { dispositivo_seleccionado = lisp.getselectedindex() - 1; servicios_encontrados.removeallelements(); //Buscamos el servicio de puerto serie en el //dispositivo seleccionado Pág. 97

108 System.out.println("Dispositovo seleccionado: " + dispositivo_seleccionado); RemoteDevice dispositivo_remoto =(RemoteDevice)dispositivos_encontrados.elementAt (dispositivo_seleccionado); try{ //Buscamos en el puerto serie 0x1101 da.searchservices(null,new UUID[]{new UUID(0x1101)},dispositivo_remoto,new Listener()); System.out.println("Dispositovo remoto: " + dispositivo_remoto.getbluetoothaddress().tostring( )); } catch(bluetoothstateexception bse){ System.out.println(bse.toString()); } } else if (d==lisp && c==cmdenviar) { this.pantallaenviar(); } else if (d==lise && c==cmdenviarrs) { this.escribir (); } else if (d==lisp && c==cmdrecibir) { this.pantallarecibir(); //iniciamos el hilo de la comunicación: hilo = new Thread (Comunicacion.this); hilo.start (); } else if(d==lise && c==cmdsiguiente) { nombrers = lise.getstring(lise.getselectedindex()); venviar = app.mostrarrs(lise, nombrers); fecha = app.getfecha(); lise.removecommand(cmdsiguiente); lise.addcommand(cmdenviarrs); } else if(d==lisr && c==cmdsiguiente) { lisr.removecommand(cmdsiguiente); } else if(d==text && c==cmdguardar){ guardaren = text.getstring(); if(guardaren!= "") { //añadimos al nombre el sufijo Asignaturas Pág. 98

109 guardaren = "Asignaturas_" + guardaren; rsaux = apps.rms.abrirrs(guardaren); Alumno a; Enumeration e = valumnosrec.elements(); while(e.hasmoreelements()){ a = (Alumno)e.nextElement(); apps.rms.escribiralumnors(a,rsaux); } apps.rms.cerrarrs(rsaux); this.mostraralarma("datos guardados en: " + guardaren, lisp); text.removecommand(cmdguardar); } else{ this.mostraralarma("debes introducir un nombre para guardar los datos.", text); } guardaren = ""; } } Para enviar la información al PC, se utiliza el método escribir(), antes de ejecutar dicho método se deben ejecutar los siguientes métodos: buscardispositivos() buscarservicios() Esto se debe a que para poder escribir, se necesita tener un dispositivo y un servicio del que obtener el URL. También necesita tener cargado el vector de alumnos a enviar: public void escribir () { //servicerec String URL = record.getconnectionurl( ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false); System.out.println ("URL: " + URL); try { StreamConnection con = ( StreamConnection)Connector.open (URL); DataOutputStream dos = con.opendataoutputstream (); Pág. 99

110 Alumno a; Enumeration e = venviar.elements(); while(e.hasmoreelements()){ a = (Alumno)e.nextElement(); dos.writeint(venviar.size()); dos.writeutf (a.getnombre()); dos.writeutf (a.getclave()); dos.writeutf (a.getasignatura()); dos.writeutf (a.getcurso()); dos.writeutf(fecha); } dos.close (); con.close (); } catch(exception e) { lisp.append("error al escribir los datos: " + e.tostring(), null); } } Para recibir la información que envía el PC, se ha implementado el método leer(). Para recibir la información del PC, antes de ejecutar este método se deben ejecutar los siguientes métodos: buscardispositivos() buscarservicios() Esto se debe a que para poder recibir, se necesita tener un dispositivo y un servicio del que obtener el URL. También necesita tener cargado el vector de alumnos a enviar. La información que recibe se ira encapsulando en un objeto Alumno y añadiéndolo al vector de alumnos que será lo que devuelva el método: public Vector leer() { //servicerec String URL = record.getconnectionurl (ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false); System.out.println ("URL: " + URL); //objeto de retorno Vector val = new Vector(); try { Pág. 100

111 //se crea un flujo de entrada de datos asociado al flujo de entrada //abierto al iniciar la conexión. StreamConnection con = (StreamConnection)Connector.open (URL); DataInputStream dis = con.opendatainputstream(); //se leen los datos procedentes del móvil, para ello se recorre el //bucle, tantas veces como sea la longitud del vector que se manda. for(int i=0;i<dis.readint();i++){ val.addelement(new Alumno(dis.readUTF (),dis.readutf (),dis.readutf (),dis.readutf ())); } //cerramos el flujo de datos. System.out.println("Flujo de entrada cerrado"); dis.close(); } catch (IOException e) { System.out.println("Error al leer los datos: " + e.tostring()); } } return val; La implementación del método run () sirve para ejecutarlo cada vez que se inicia un hilo. En este caso va a se utilizado para recibir los datos del PC: public void run () { System.out.println("Esperando datos"); valumnosrec = this.leer(); System.out.println("Lectura finalizada."); Alumno a; Enumeration e = valumnosrec.elements(); lisr.deleteall(); while(e.hasmoreelements()){ a = (Alumno)e.nextElement(); lisr.append(a.getnombre(),null); } this.pantallatext("guardar como:"); Pág. 101

112 text.addcommand(cmdguardar); Display.getDisplay(app).setCurrent(text); lisr.removecommand(cmdparar); } El siguiente método nos va a permitir mostrar el nombre de los dispositivos que se han encontrado en el radio de alcance de nuestro dispositivo móvil: public void mostrardispositivos(){ if(dispositivos_encontrados.size()>0){ for(int i=0;i<dispositivos_encontrados.size();i++){ try{ RemoteDevice dispositivoremoto = (RemoteDevice) dispositivos_encontrados.elementat(i); lisp.append(dispositivoremoto.getfriend lyname(false),null); }catch(exception e){ } } System.out.println("Se ha producido una excepcion"); } lisp.removecommand(cmdbuscardisp); lisp.addcommand(cmdbuscarserv); } else lisp.append("pulse busqueda de dipositivos", null); Este método, muestra el primer servicio encontrado, ya que es lo que nos interesa en este caso debido a que sólo buscamos el servicio que ofrece la aplicación servidor. public void mostrarservicios(){ lisp.deleteall(); if(servicios_encontrados.size()>0){ lisp.append("servicios:",null); lisp.append(servicios_encontrados.elementat(0).t ostring(),null); lisp.append("busqueda finalizada",null); Pág. 102

113 lisp.addcommand(cmdenviar); lisp.addcommand(cmdrecibir); lisp.removecommand(cmdbuscarserv); } } else lisp.append("pulse buscar servicios",null); El siguiente método se va a encargar de permanecer a la escucha de los eventos que se produzcan en cuanto al descubrimiento de dispositivos y servicios: public class Listener implements DiscoveryListener{ //Implementamos los metodos del interfaz DiscoveryListener /** *devicediscovered() es llamado por DiscoveryAgent() *cuando este *descubre un dispositivo duranre la inquiry. */ public void devicediscovered(remotedevice dispositivoremoto, DeviceClass clase){ System.out.println("Se ha encontrado un dspositivo Bluetooth"); dispositivos_encontrados.addelement(dispositivoremot o); } /** *inquirycompleted() es llamado por DiscoveryAgent *cuando el *descubrimiento de dispositivos a finalizado. */ public void inquirycompleted(int completado){ System.out.println("Se ha completado la busqueda de dispositivos"); if(dispositivos_encontrados.size()==0){ Alert alerta = new Alert("Problema"," No se han encontrado dispositivos",null, AlertType.INFO); alerta.settimeout(3000); lisp.deleteall(); lisp.append("presione descubrir dispositivos",null); Display.getDisplay(app).setCurrent(alerta,lisP); } else{ } mostrardispositivos(); lisp.append("busqueda finalizada",null); Pág. 103

114 } public void servicesdiscovered(int transid, ServiceRecord[] servrecord){ System.out.println("Se ha encontrado un servicio remoto"); } record = servrecord[0]; servicios_encontrados.addelement(servrecord); public void servicesearchcompleted(int transid, int respcode){ System.out.println("Terminada la busqueda de servicios"); System.out.println("Número de servicios: " + servicios_encontrados.size()); //Si encontramos un servicio, lo usamos para mandar el mensaje(todos los //servicios que hemos buscado son de puerto serie) if(servicios_encontrados.size()>0){ mostrarservicios(); } } else{ //Si no encontramos ningun servicio de puerto serie System.out.println("No hay servicio de puerto serie"); mostrardispositivos(); Display.getDisplay(app).setCurrent(lisP); } } } SOSA BLUETOOTH SERVER Implementación de la clase Comunicacion en la aplicación servidor: El siguiente método permite abrir una conexión con el puerto deseado, identificándolo mediante el nombre del puerto COM. public int open () { Pág. 104

115 //valor de retorno int ok = 0; //enumeration donde se va a almacenar la lista de puertos Enumeration portlist; CommPortIdentifier portid; //obtenemos las listas de puertos portlist = CommPortIdentifier.getPortIdentifiers (); //recorremos la enumeration buscando el puerto deseado while (portlist.hasmoreelements ()) { //obtenemos el identificador del puerto portid = (CommPortIdentifier) portlist.nextelement (); if (portid.getporttype () == CommPortIdentifier.PORT_SERIAL) { //comprobamos si el puerto obtenido es el que buscamos if (portid.getname ().equals (nombrepuerto)) { try { //abrimos la conexión del puerto serie buscado serialport = (SerialPort) portid.open ("SOSA Bluetooth " + "Server", 2000); ok = 1; //establecemos las características del puerto serialport.setserialportparams (9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //abrimos dos flujos de datos, uno de salida y uno de entrada. //flujo de salida outputstream = serialport.getoutputstream (); //flujo de entrada inputstream = serialport.getinputstream (); } catch (PortInUseException e) { Pág. 105

116 System.out.println ("ERROR: Puerto en uso"); ok = -1; } catch (UnsupportedCommOperationException e) { //cerramos la conexión abierta serialport.close (); System.out.println ("ERROR: No soportado"); ok = -2; } catch (IOException e) { //cerramos la conexión abierta serialport.close (); } System.out.println ("ERROR: No se pudo crear el stream"); ok = -3; } } } } return ok; El siguiente método, nos va a servir para leer los datos recibidos que van siendo encapsulados en un objeto alumno y añadidos a un vector de alumnos. Tiene los mismos efectos que el método leer() de la aplicación cliente, pero internamente trabaja diferente ya que utiliza el API javax.comm. public Vector read() { //atributos de un objeto Alumno String nombreapellido; String clave; String asignatura; String curso; //objeto de retorno Alumno a = new Alumno(); Vector val = new Vector(); try Pág. 106

117 { //se crea un flujo de entrada de datos asociado al flujo de entrada //abierto al iniciar la conexión. DataInputStream dis = new DataInputStream (inputstream); //se leen los datos procedentes del movil, para ello se recorre el //bucle, tantas veces como sea la longitud del vector que se manda. int max = dis.readint(); //establecemos el valor máximo de la barra de progreso main.setmaximopb(max); for(int i=0;i<max;i++){ val.addelement(new Alumno(dis.readUTF (),dis.readutf (),dis.readutf (),dis.readutf ())); fecha = dis.readutf (); dis.readint(); } //actualizamos la barra de progreso main.actualizarpb(i); main.settexto("datos recibidos"); //actualizamos la barra de progreso hasta el máximo main.actualizarpb(max); Enumeration enu = val.elements(); System.out.println("num elem: " + val.size()); while(enu.hasmoreelements()){ a = (Alumno)enu.nextElement(); System.out.println("Recibido: " + a.getnombre()); } //cerramos el flujo de datos. System.out.println("Flujo de entrada cerrado"); dis.close(); } catch (IOException e) { System.out.println("'read'"); } serialport.close (); Pág. 107

118 } return val; El siguiente método nos va a permitir la escritura de datos, es decir, nos va a servir para enviar al dispositivo móvil los datos de los alumnos de la base de datos: public void write (Vector val, boolean fin) { try { //establecemos el valor máximo de la barra de progreso main.setmaximopb(val.size()); System.out.println("1"); //creamos un flujo de salida de datos asociado al flujo creado //al iniciar la conexión. DataOutputStream dos = new DataOutputStream (outputstream); //os System.out.println("2"); //pasamos el vector de Alumnos a mandar a una enumeratión //para facilitar su manipulación: Enumeration e = val.elements(); System.out.println("3"); //creamos un objeto Alumno Alumno a; while(e.hasmoreelements() &&!fin){ int valor = 0; System.out.println("4"); a = (Alumno)e.nextElement(); System.out.println("Tamaño del vector: " + val.size()); dos.writeint(val.size()); System.out.println(a.getNombre()); dos.writeutf (a.getnombre()); dos.writeutf (a.getclave()); dos.writeutf (a.getasignatura()); dos.writeutf (a.getcurso()); valor++; } //actualizamos la barra de progreso main.actualizarpb(valor); Pág. 108

119 main.settexto("datos enviados"); //actualizamos la barra de progreso hasta el máximo main.actualizarpb(val.size()); System.out.println("5"); //cerramos el flujo de datos abierto: dos.close(); System.out.println("6"); } catch (IOException e) { System.out.println("'write'"); } } //cerramos la conexión al puerto serie: serialport.close (); El método close () nos va a permitir el cierre del puerto que ha sido abierto. Esto es muy importante ya que si no cerramos el puerto y otra aplicación quiere hacer uso del mismo, no podrá hacerlo ya que este estará siendo utilizado por nuestra aplicación: public void close () { try { //cerramos tanto los flujos como la conexión: outputstream.close (); System.out.println("OutputStream cerrado"); inputstream.close (); System.out.println("InputStream cerrado"); serialport.close (); System.out.println("Puerto serie cerrado"); } catch (IOException e) { //cerramos la conexión al puerto serie: serialport.close (); System.out.println("Puerto serie cerrado"); } } Este otro método nos va a permitir cargar en un vector, todos los puertos COM que en ese momento están siendo utilizados en nuestro PC: public void cargarpuertos( Vector v){ Pág. 109

120 //para controlar si se ha encontrado algún puerto COM: boolean puertoencontrado = false; System.out.println("Cargando lista puertos..."); //obtenemos la lista de puertos COM: portlist = CommPortIdentifier.getPortIdentifiers(); System.out.println("Lista finalizada..."); //recorremos la lista y obtenemos el identificador del puerto COM: while(portlist.hasmoreelements()){ } portid = (CommPortIdentifier) portlist.nextelement(); //comprobamos si el puerto encontrado es un puerto serie, si es así //añadimos el nombre de este al vector: if (portid.getporttype() == CommPortIdentifier.PORT_SERIAL) { puertoencontrado = true; v.add(portid.getname()); } if(!puertoencontrado){ System.out.println("No se han encontrado puertos."); } } Pág. 110

121 8. IMPLANTACIÓN 8.1 ESTUDIO DE LAS TECNOLOGÍAS DE COMUNICACIÓN COMM 8.2 INSTALACIÓN DE LA APLICACIÓN SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER Pág. 111

122 8. IMPLANTACIÓN 8.1 ESTUDIO DE LAS TECNOLOGÍAS DE COMUNICACIÓN COMM La comunicación por puerto serie, permite al ordenador comunicarse con todo tipo de dispositivos periféricos: módems, impresoras, escáneres, lectores de código de barras, etc. El API de Comunicaciones Java, constituido por el paquete javax.comm, que proporciona JavaSoft, no forma parte del JDK, pero añade soporte a Java para dispositivos serie y paralelo. El paquete proporciona soporte para dispositivos serie y paralelo al estilo Java, es decir, utilizando una semántica semejante a la que se usa con streams y eventos. Para comunicarse con un dispositivo serie a través de uno de los puertos serie de un ordenador, desde una aplicación Java o un applet, es necesario un interfaz. El API de Comunicaciones Java, permite transmitir y recibir datos a través de dispositivos conectados al puerto serie; proporcionando además un conjunto de opciones que permiten la configuración de todos los parámetros asociados a los puertos serie y paralelo. Este API es una proposición para establecer un método estándar de acceso a los puertos de comunicaciones, que permita escribir programas Java independientes de la plataforma. Así se pueden escribir programas para emulación de terminales, programas de fax, lectores de tarjetas, etc. El desarrollo de buenos programas normalmente pasa por construir unos cuantos interfaces claramente definidos. El diagrama de alto nivel de las capas que componen el API de comunicaciones Java es el que se reproduce en la figura: Pág. 112

123 Figura 8.1. Capas del API. El diagrama que muestra la figura siguiente describe los objetos involucrados en la lectura o escritura de datos en un puerto serie desde Java. Figura 8.2. Lectura/escritura. Pág. 113

124 8.2 INSTALACIÓN DE LA APLICACIÓN SOSA BLUETOOTH MOBILE Dependiendo del dispositivo móvil del que dispongamos, varía la forma de instalación de la aplicación. A continuación vamos a explicar dos casos reales de instalación, para distintos dispositivos: Nokia 6600: Se seleccionar el archivo SOSA_Bluetooth_Mobile.jar y se envía vía Bluetooth. El dispositivo móvil, lo recibe como si fuera un mensaje, por lo que abrimos dicho mensaje y pulsamos la opción de instalar. Escogemos donde deseamos que sea instalado y continuamos con el proceso. Una vez instalado, vamos a la ubicación donde ha sido instalado y ya esta listo para ser ejecutado. Nokia 6230: Mediante la aplicación Nokia PC Suite, escogemos la opción de Instalar aplicaciones (Nokia Application Installer). Una vez arrancada dicha aplicación, seleccionamos buscamos el archivo SOSA_Bluetooth_Mobile.jar y hacemos clic en instalar. La aplicación será instalada el apartado de aplicaciones del dispositivo y estará lista para ser ejecutada. Si disponemos de cualquier otro dispositivo móvil, consultar el manual de usuario del mismo para realizar la instalación de cualquier aplicación Java SOSA BLUETOOTH SERVER Para llevar a cabo la instalación, será necesario seguir todos y cada uno de los siguientes pasos: 1. Instalar la JRE 5.0 si no la tienes. 2. Necesitas copiar la librería compartida al directorio bin, y el fichero javax.comm.properties al directorio lib del entorno de ejecución: Pág. 114

125 a. Copiar el fichero comm.jar a la carpeta \jdk1.5\jre\lib\ext b. Copiar el fichero win32com.dll a la carpeta \jdk1.5\bin c. Copiar el fichero javax.comm.properties a la carpeta \jdk1.5\jre\lib 3. Para que la aplicación pueda manejar la Base de Datos, se debe configurar el Microsoft Access Driver. Proceso de configuración para Windows XP: a. Inicio. b. Panel de control. c. Herramientas administrativas. d. Orígenes de datos (ODBC). i. En la pestaña DSN Usuarios pulsamos Agregar Pág. 115

126 ii. Seleccionamos Microsoft Access Driver (*.mdb) iii. Introducimos el nombre: MS Access Database iv. Pulsamos Aceptar. v. Pulsamos Finalizar. 4. Configuración Bluetooth: Para que nuestra aplicación cliente SOSA Bluetooth Mobile, pueda descubrir el dispositivo Bluetooth de nuestro PC, necesitamos que este visible. Para ello debemos seguir el siguiente proceso de configuración: Pág. 116

127 Proceso de configuración para Windows XP: a. Hacemos doble clic sobre el icono Bluetooth que aparece en la barra de tareas del escritorio: b. Una vez abierta la ventana, hacemos clic sobre la pestaña de Opciones y establecemos las opciones como en la siguiente pantalla: c. Pulsamos Aceptar. d. Para conocer cual es el puerto COM asociado a nuestro dispositivo Bluetooth, debemos hacer clic sobre la pestaña Puertos COM y el que necesitamos para nuestra aplicación es el Entrante. Pág. 117

128 5. Una vez realizados los paso anteriores, la aplicación ya está lista para ejecutarse, haciendo doble clic sobre el fichero de la aplicación. Pág. 118

129 9. CONCLUSIONES 9.1 PROYECTO DE INNOVACIÓN 9.2 ANÁLISIS DE TECNOLOGÍAS, PROBLEMAS Y RESULTADOS 9.3 OTROS CAMPOS DE APLICACIÓN Pág. 119

130 9. CONCLUSIONES 9.1 PROYECTO DE INNOVACIÓN Durante el desarrollo del proyecto, se ha podido observar como se trataba de un proyecto de innovación, ya que hasta la realización del mismo no existía ninguna aplicación desarrollada en J2SE que dialogara, mediante la tecnología inalámbrica Bluetooth, con una desarrollada en J2ME. Sólo existían desarrollos que permitían la comunicación entre dispositivos móviles. 9.2 ANÁLISIS DE TECNOLOGÍAS, PROBLEMAS Y RESULTADOS El desarrollo de esta parte del proyecto ha sido costoso en lo que se refiere al aprendizaje de nuevas tecnologías como es el uso de Bluetooth con Java. También el aprendizaje de J2ME para el desarrollo de la aplicación móvil. El desarrollo de este tipo de aplicaciones, es decir, una aplicación que ha requerido un estudio sobre las tecnologías a utilizar, una aplicación que trabaja con tecnologías nuevas como el uso del Bluetooth para la comunicación y sobre las que hoy en día, hay poca documentación y soporte al desarrollo, supone un mayor esfuerzo ya que implica el uso de tecnología de última generación para realizar las pruebas de la misma. Una vez entendido el funcionamiento de Bluetooth, hay que aprender el manejo del entorno en el que vamos a desarrollar y una vez familiarizado con el mismo, se lleva a cabo la parte gráfica de la aplicación cliente. Pág. 120

131 A lo largo del desarrollo de la aplicación cliente, se ha tenido una serie de problemas, en los que cabe destacar todo lo que comprende la sincronización con el PC. Esta parte es la más delicada de la aplicación tanto en la parte cliente como en la servidora, ya que si esta parte no funciona correctamente, no se podrán realizar simulaciones entre ambos para probar el correcto funcionamiento de la aplicación. La parte de la sincronización con el PC ha sido, aparte de la más costosa, la que a acaparado el mayor tiempo, tanto en desarrollo como en búsqueda de documentación, y como era de esperar la que más problemas a dado. DESARROLLO DE LA APLICACIÓN MOVIL Primero se desarrolló la comunicación mediante SPP (serial protocol profile), es decir, comunicación mediante el puerto serie. Este tipo de comunicación, implicaba un desarrollo en dos fases, una primera fase, en la que se buscaban los dispositivos cercanos con la tecnología inalámbrica Bluetooth, y una vez encontrados estos, se mostraban por pantalla y se decidía sobre cual de ellos se realizaría la búsqueda de servicios. Entre estos dispositivos encontrados, debería encontrarse nuestro PC, y sobre éste, se llevaría a cabo la búsqueda de servicios. Esta parte dio muchos problemas ya que se encontraba el dispositivo, pero no se encontraba el servicio ofrecido por el PC, es decir, por el servidor. En esta parte había mucha incertidumbre, ya que la simulación entre ambas aplicaciones no se podía hacer, lo que llevo a realizar un servidor que ofreciera un servicio SPP al igual que en el PC, pero sobre un dispositivo móvil, ya que el IDE, si permitía la simulación de una comunicación Bluetooth entre dispositivos móviles. Una vez acabado el servidor para el móvil, se llevo a cabo la simulación, y se comprobó que entre ambos se podía mandar un Stream, por lo que la implementación de Pág. 121

132 la parte móvil era correcta, lo que fallaba era el servidor en el PC, de esto se hablará de forma más detallada en el siguiente apartado. Tras múltiples pruebas, se decidió realizar la comunicación mediante el protocolo Obex, ya que este protocolo permitía elegir el puerto de comunicación entre ambos dispositivos y cambiaba totalmente la forma de trabajar de SPP. No necesitaba ni búsqueda de dispositivos ni de servicios, lo cual era una pena ya que había llevado un tiempo el desarrollo de esto, pero merecía la pena intentarlo por el mero hecho de pensar que había una posibilidad de que esto funcionara. Una vez implementada la comunicación Obex en ambas partes, se llevo a cabo la simulación, cargando la aplicación móvil en un Nokia El resultado fue el mismo, no detectaba el servidor del PC. Se probó como en la vez anterior, una simulación entre dispositivos móviles y funcionó. Esto demostró definitivamente, que el error se encontraba en el entorno servidor del PC. DESARROLLO DE LA APLICACIÓN SERVIDOR Como se ha dicho anteriormente, el desarrollo de la comunicación entre cliente y servidor es la más elaborada y la que ha ocupado el mayor tiempo en desarrollo. El problema en el desarrollo de este modulo, radica en la imposibilidad de emulación del mismo. Las pruebas se realizaban de forma real, cargando la parte cliente en el móvil y arrancando la aplicación servidor en el PC. Se realizaron bastantes pruebas, implementando todas las posibles maneras de comunicación con la parte cliente. Tanto con una comunicación SPP como con una Pág. 122

133 Obex, se seguían repitiendo los mismos resultados (con L2CAP no se probó ya que el establecimiento de la conexión, que era lo que fallaba, es el misma). En la implementación de la comunicación con SPP, no se podía utilizar el API de Bluetooth JSR-82, ya que daba error en la compilación a la hora de reconocer el dispositivo local (este API esta implementada para el uso en aplicaciones móviles). Documentándome por Internet, encontré una API en Benhui, que era una modificación de la JSR-82 para el correcto funcionamiento en una aplicación servidora en un PC. Esta API tenía una serie de pegas, a parte de llevar unos drivers, sólo permitía a la aplicación ser utilizada bajo Windows XP con Service Pack 2. Con la misma implementación que tenía pero utilizando el API de Benhui, no me daba el fallo antes mencionado, pero a la hora de realizar las pruebas con el móvil, seguían sin verse. A continuación se llevó a cabo la implantación de la comunicación mediante Obex. Esta daba un cambio radical a la aplicación por lo que mantenía las esperanzas de que funcionara. Una vez realizados todos los cambios pertinentes, se llevaron a cabo una serie de pruebas pero desgraciadamente se obtuvieron los mismos resultados. Seguía sin funcionar. Finalmente, hablando con mi director, me comento la posibilidad de realizar la comunicación mediante la emulación del dispositivo Bluetooth como un puerto COM. Se llevó a cabo el desarrollo del mismo, esta forma de comunicación era más cómoda y eficiente ya que aportaba un código más limpio y mucho más reducido que con cualquiera de las técnicas anteriores. Se comenzó realizando una comunicación simple, es decir, mandando simplemente un String, para comprobar si había comunicación entre el cliente y el servidor. Las primeras pruebas realizadas no funcionaron, lo que ya era de Pág. 123

134 esperar, pero finalmente se consiguió mandar un String del cliente al servidor, esto fue un gran avance tanto funcional como emocional ya que después de tantas horas dedicadas al proyecto era duro pensar que no se podía realizar. Bueno tras este éxito, se probó a llevar a cabo la transferencia de una base de dato de alumnos. Esto daba más complejidad a la aplicación pero la comunicación se supone que era igual que la anterior y tras algunos intentos fallidos, se consiguió realizar la comunicación satisfactoriamente. 9.3 OTROS CAMPOS DE APLICACIÓN El uso de la tecnología inalámbrica Bluetooth, se está extendiendo cada vez más en nuestros días, esto da pie, a que cada vez más dispositivos lleven integrada esta tecnología, y como consecuencia se realicen aplicaciones con el uso de la misma. Otro tipo de aplicaciones que se pueden llevar a cabo con Bluetooth pueden ser: Control de calidad en una planta de fabricación. Cuestionarios a pie de calle para sincronizar la información posteriormente de forma automática. Presentación de la carta de un restaurante en el dispositivo móvil, a la entrada en el mismo. Pág. 124

135 10. BIBLIOGRAFÍA Pág. 125

136 [GALV] Gálvez Rojas, Sergio. Ortega Díaz, Lucas. Java a Tope. Java 2 Micro Edition. Universidad de Málaga [FROU] Froufe, Agustín. Cárdenas Nennetti, Jorge. J2ME. Java 2 Micro Edition + CDROM. Ra-Ma. [MUCH] Mochow, John W. Core J2ME Technology. Sun Microsystems Press, Prentice Hall [ALVA] Alvarez Garcia, Alonso. Morales Grela, Jose Ángel. J2ME (guías prácticas). Anaya Multimedia-Anaya Interactiva. [VAND] PTR. van der Liden, Meter. Just Java 2: J2SE 1.5 Edition. Prentice Hall : Bruce Eckel s Free Electronic Books : Página sobre desarrollo de aplicaciones Bluetooth. : Sitio web oficial de Bluetooth. : Sitio web de Sun. : Sitio web de programación. : Sitio web de Sun para el desarrollo de aplicaciones en Java. : Sitio web para el desarrollo de aplicaciones con Bluetooth : Sitio web para el desarrollo de aplicaciones móviles. : Sitio web de programación en Java. : Sitio web dedicado a Java. Pág. 126

137 11. ANEXOS 11.1 API SOSA BLUETOOTH MOBILE 11.2 API SOSA BLUETOOTH SERVER 11.3 PROTOCOLOS ESPECÍFICOS DE BLUETOOTH 11.4 PROTOCOLOS ADOPTADOS DE BLUETOOTH 11.5 MANUAL DE USUARIO SOSA BLUETOOTH MOBILE SOSA BLUETOOTH SERVER Pág. 127

138 11.1 API SOSA BLUETOOTH MOBILE Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD sosa_bluetooth_server Class Main java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe sosa_bluetooth_server.main All Implemented Interfaces: java.awt.event.actionlistener, java.awt.image.imageobserver, java.awt.menucontainer, java.io.serializable, java.lang.runnable, java.util.eventlistener, javax.accessibility.accessible, javax.swing.rootpanecontainer, javax.swing.windowconstants public class Main extends javax.swing.jframe implements java.awt.event.actionlistener, java.lang.runnable See Also: Serialized Form Nested Class Summary Pág. 128

139 Nested classes/interfaces inherited from class javax.swing.jframe javax.swing.jframe.accessiblejframe Nested classes/interfaces inherited from class java.awt.frame java.awt.frame.accessibleawtframe Nested classes/interfaces inherited from class java.awt.window java.awt.window.accessibleawtwindow Nested classes/interfaces inherited from class java.awt.container java.awt.container.accessibleawtcontainer Nested classes/interfaces inherited from class java.awt.component java.awt.component.accessibleawtcomponent, java.awt.component.bltbufferstrategy, java.awt.component.flipbufferstrategy Field Summary Fields inherited from class javax.swing.jframe accessiblecontext, EXIT_ON_CLOSE, rootpane, rootpanecheckingenabled Pág. 129

140 Fields inherited from class java.awt.frame CROSSHAIR_CURSOR, DEFAULT_CURSOR, E_RESIZE_CURSOR, HAND_CURSOR, ICONIFIED, MAXIMIZED_BOTH, MAXIMIZED_HORIZ, MAXIMIZED_VERT, MOVE_CURSOR, N_RESIZE_CURSOR, NE_RESIZE_CURSOR, NORMAL, NW_RESIZE_CURSOR, S_RESIZE_CURSOR, SE_RESIZE_CURSOR, SW_RESIZE_CURSOR, TEXT_CURSOR, W_RESIZE_CURSOR, WAIT_CURSOR Fields inherited from class java.awt.component BOTTOM_ALIGNMENT, CENTER_ALIGNMENT, LEFT_ALIGNMENT, RIGHT_ALIGNMENT, TOP_ALIGNMENT Fields inherited from interface javax.swing.windowconstants DISPOSE_ON_CLOSE, DO_NOTHING_ON_CLOSE, HIDE_ON_CLOSE Fields inherited from interface java.awt.image.imageobserver ABORT, ALLBITS, ERROR, FRAMEBITS, HEIGHT, PROPERTIES, SOMEBITS, WIDTH Constructor Summary Main(java.lang.String titulo) Constructor, para crear una nueva instancia de Main Method Summary void actionperformed(java.awt.event.actionevent e) Implementación del interfaz ActionListener para el Pág. 130

141 manejo de los eventos. void actualizarbd() Este método será llamado para actualizar el contenido de la base de datos, con la información recibida. void actualizarpb(int valor) Permite actualizar la barra de progreso. void cargaralumno() Este método será llamado para cargar la combo de alumnos. void cargarasignatura() Este método será llamado para cargar la combo de asignaturas. void cargarcurso() Este método será llamado para cargar la combo de cursos. void eliminarrepetidos(java.util.vector vaux, java.util.vector v) Este método será llamado para guardar en un vector los elementos de otro vector pero sin elementos repetidos javax.swing.jtextarea gettexarea() Este método devuelve el JTextArea de la ventana principal. static void main(java.lang.string[] args) Método principal. void mostraralarma(java.lang.string s) Este método será llamado para mostrar una pantalla con un mensaje. void mostrarbd() Este método será llamado para mostrar el contenido de la base de datos, según los parametros seleccionados en las combos de curso y asignatura. void run() Pág. 131

142 Implementación del interfaz Runnable. void setmaximopb(int valor) Permite establecer el valor máximo de la barra de progreso. void settextarea(java.lang.string texto) Este método escribe en el JTextArea de la ventana principal. void settexto(java.lang.string texto) Este método escribe en el JLabel de incidencias de la ventana principal. Methods inherited from class javax.swing.jframe addimpl, createrootpane, frameinit, getaccessiblecontext, getcontentpane, getdefaultcloseoperation, getglasspane, getjmenubar, getlayeredpane, getrootpane, isdefaultlookandfeeldecorated, isrootpanecheckingenabled, paramstring, processwindowevent, remove, setcontentpane, setdefaultcloseoperation, setdefaultlookandfeeldecorated, setglasspane, seticonimage, setjmenubar, setlayeredpane, setlayout, setrootpane, setrootpanecheckingenabled, update Methods inherited from class java.awt.frame addnotify, finalize, getcursortype, getextendedstate, getframes, geticonimage, getmaximizedbounds, getmenubar, getstate, gettitle, isresizable, isundecorated, remove, removenotify, setcursor, setextendedstate, setmaximizedbounds, setmenubar, setresizable, setstate, settitle, setundecorated Pág. 132

143 Methods inherited from class java.awt.window addpropertychangelistener, addpropertychangelistener, addwindowfocuslistener, addwindowlistener, addwindowstatelistener, applyresourcebundle, applyresourcebundle, createbufferstrategy, createbufferstrategy, dispose, getbufferstrategy, getfocusablewindowstate, getfocuscyclerootancestor, getfocusowner, getfocustraversalkeys, getgraphicsconfiguration, getinputcontext, getlisteners, getlocale, getmostrecentfocusowner, getownedwindows, getowner, gettoolkit, getwarningstring, getwindowfocuslisteners, getwindowlisteners, getwindowstatelisteners, hide, isactive, isalwaysontop, isfocusablewindow, isfocuscycleroot, isfocused, islocationbyplatform, isshowing, pack, postevent, processevent, processwindowfocusevent, processwindowstateevent, removewindowfocuslistener, removewindowlistener, removewindowstatelistener, setalwaysontop, setbounds, setcursor, setfocusablewindowstate, setfocuscycleroot, setlocationbyplatform, setlocationrelativeto, show, toback, tofront Methods inherited from class java.awt.container add, add, add, add, add, addcontainerlistener, applycomponentorientation, arefocustraversalkeysset, countcomponents, deliverevent, dolayout, findcomponentat, findcomponentat, getalignmentx, getalignmenty, getcomponent, getcomponentat, getcomponentat, getcomponentcount, getcomponents, getcomponentzorder, getcontainerlisteners, getfocustraversalpolicy, getinsets, getlayout, getmaximumsize, getminimumsize, getmouseposition, getpreferredsize, insets, invalidate, isancestorof, isfocuscycleroot, isfocustraversalpolicyprovider, isfocustraversalpolicyset, layout, list, list, locate, minimumsize, paint, paintcomponents, preferredsize, print, printcomponents, processcontainerevent, remove, removeall, removecontainerlistener, setcomponentzorder, setfocustraversalkeys, setfocustraversalpolicy, setfocustraversalpolicyprovider, setfont, transferfocusbackward, transferfocusdowncycle, validate, validatetree Pág. 133

144 Methods inherited from class java.awt.component action, add, addcomponentlistener, addfocuslistener, addhierarchyboundslistener, addhierarchylistener, addinputmethodlistener, addkeylistener, addmouselistener, addmousemotionlistener, addmousewheellistener, bounds, checkimage, checkimage, coalesceevents, contains, contains, createimage, createimage, createvolatileimage, createvolatileimage, disable, disableevents, dispatchevent, enable, enable, enableevents, enableinputmethods, firepropertychange, firepropertychange, firepropertychange, firepropertychange, firepropertychange, firepropertychange, firepropertychange, firepropertychange, firepropertychange, getbackground, getbounds, getbounds, getcolormodel, getcomponentlisteners, getcomponentorientation, getcursor, getdroptarget, getfocuslisteners, getfocustraversalkeysenabled, getfont, getfontmetrics, getforeground, getgraphics, getheight, gethierarchyboundslisteners, gethierarchylisteners, getignorerepaint, getinputmethodlisteners, getinputmethodrequests, getkeylisteners, getlocation, getlocation, getlocationonscreen, getmouselisteners, getmousemotionlisteners, getmouseposition, getmousewheellisteners, getname, getparent, getpeer, getpropertychangelisteners, getpropertychangelisteners, getsize, getsize, gettreelock, getwidth, getx, gety, gotfocus, handleevent, hasfocus, imageupdate, inside, isbackgroundset, iscursorset, isdisplayable, isdoublebuffered, isenabled, isfocusable, isfocusowner, isfocustraversable, isfontset, isforegroundset, islightweight, ismaximumsizeset, isminimumsizeset, isopaque, ispreferredsizeset, isvalid, isvisible, keydown, keyup, list, list, list, location, lostfocus, mousedown, mousedrag, mouseenter, mouseexit, mousemove, mouseup, move, nextfocus, paintall, prepareimage, prepareimage, printall, processcomponentevent, processfocusevent, processhierarchyboundsevent, processhierarchyevent, processinputmethodevent, processkeyevent, processmouseevent, processmousemotionevent, processmousewheelevent, removecomponentlistener, removefocuslistener, removehierarchyboundslistener, removehierarchylistener, removeinputmethodlistener, removekeylistener, removemouselistener, removemousemotionlistener, removemousewheellistener, removepropertychangelistener, removepropertychangelistener, repaint, repaint, repaint, repaint, requestfocus, requestfocus, requestfocusinwindow, requestfocusinwindow, reshape, resize, resize, Pág. 134

145 setbackground, setbounds, setcomponentorientation, setdroptarget, setenabled, setfocusable, setfocustraversalkeysenabled, setforeground, setignorerepaint, setlocale, setlocation, setlocation, setmaximumsize, setminimumsize, setname, setpreferredsize, setsize, setsize, setvisible, show, size, tostring, transferfocus, transferfocusupcycle Methods inherited from class java.lang.object clone, equals, getclass, hashcode, notify, notifyall, wait, wait, wait Methods inherited from interface java.awt.menucontainer getfont, postevent Constructor Detail Main public Main(java.lang.String titulo) Constructor, para crear una nueva instancia de Main Method Detail main public static void main(java.lang.string[] args) Método principal. actionperformed public void actionperformed(java.awt.event.actionevent e) Implementación del interfaz ActionListener para el manejo de los eventos. Specified by: actionperformed in interface java.awt.event.actionlistener Pág. 135

146 Parameters: e - evento producido. gettexarea public javax.swing.jtextarea gettexarea() Este método devuelve el JTextArea de la ventana principal. Returns: devuelve el area de texto de la ventana principal. settextarea public void settextarea(java.lang.string texto) Este método escribe en el JTextArea de la ventana principal. Parameters: texto - es el string que va a ser mostrado settexto public void settexto(java.lang.string texto) Este método escribe en el JLabel de incidencias de la ventana principal. Parameters: texto - es el string que va a ser mostrado run public void run() Implementación del interfaz Runnable. Este método será llamado al iniciar el hilo de la comunicación. Specified by: run in interface java.lang.runnable cargarcurso public void cargarcurso() Pág. 136

147 Este método será llamado para cargar la combo de cursos. cargarasignatura public void cargarasignatura() Este método será llamado para cargar la combo de asignaturas. cargaralumno public void cargaralumno() Este método será llamado para cargar la combo de alumnos. mostrarbd public void mostrarbd() Este método será llamado para mostrar el contenido de la base de datos, según los parametros seleccionados en las combos de curso y asignatura. actualizarbd public void actualizarbd() Este método será llamado para actualizar el contenido de la base de datos, con la información recibida. eliminarrepetidos public void eliminarrepetidos(java.util.vector vaux, java.util.vector v) Este método será llamado para guardar en un vector los elementos de otro vector pero sin elementos repetidos Parameters: vaux - vector con repetidos. v - vector en el que se va guardar la información sin repetidos. mostraralarma Pág. 137

148 public void mostraralarma(java.lang.string s) Este método será llamado para mostrar una pantalla con un mensaje. Parameters: s - String que va a mostrar el mensaje de la alarma. actualizarpb public void actualizarpb(int valor) Permite actualizar la barra de progreso. Parameters: valor - valor con el que se ha de actualizar. setmaximopb public void setmaximopb(int valor) Permite establecer el valor máximo de la barra de progreso. Parameters: valor - valor que va a fijar el valor máximo de la barra de progreso. Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD Pág. 138

149 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD sosa_bluetooth_server Class Alumno java.lang.object sosa_bluetooth_server.alumno public class Alumno extends java.lang.object Constructor Summary Alumno() Crea una nueva instancia de Alumno sin atributos Alumno(java.lang.String nombreapellidos_, java.lang.string clave_, java.lang.string asignatura_, java.lang.string curso_) Crea una nueva instancia de Alumno con todos los atributos del alumno. Method Summary java.lang.string getasignatura() Permite obtener la asignatura de un alumno. java.lang.string getclave() ermite obtener la clave de un alumno. java.lang.string getcurso() Permite obtener el curso de un alumno. java.lang.string getnombre() Permite obtener el nombre de un alumno. void setasignatura(java.lang.string asignatura_) Pág. 139

150 Permite escribir la asignatura de un alumno. void setclave(java.lang.string clave_) Permite escribir la clave de un alumno. void setcurso(java.lang.string curso_) Permite escribir el curso de un alumno. void setnombre(java.lang.string nombreapellidos_) Permite escribir el nombre de un alumno. java.lang.string tostring() Permite obtener todos los atributos de un alumno, en forma de String. Methods inherited from class java.lang.object clone, equals, finalize, getclass, hashcode, notify, notifyall, wait, wait, wait Constructor Detail Alumno public Alumno() Crea una nueva instancia de Alumno sin atributos Alumno public Alumno(java.lang.String nombreapellidos_, java.lang.string clave_, java.lang.string asignatura_, java.lang.string curso_) Crea una nueva instancia de Alumno con todos los atributos del alumno. Parameters: nombreapellidos_ - nombre y apellidos del alumno. Pág. 140

151 clave_ - clave que diferencia a cada alumno. asignatura_ - asignatura a la que pertenece el alumno. curso_ - curso al que pertenece el alumno. Method Detail getnombre public java.lang.string getnombre() Permite obtener el nombre de un alumno. Returns: devuelve el nombre de un alumno en forma de String. getclave public java.lang.string getclave() ermite obtener la clave de un alumno. Returns: devuelve la clave de un alumno en forma de String. getasignatura public java.lang.string getasignatura() Permite obtener la asignatura de un alumno. Returns: devuelve la asignatura de un alumno en forma de String. getcurso public java.lang.string getcurso() Permite obtener el curso de un alumno. Returns: devuelve el curso de un alumno en forma de String. setnombre Pág. 141

152 public void setnombre(java.lang.string nombreapellidos_) Permite escribir el nombre de un alumno. Parameters: nombreapellidos_ - nombre y apellidos del alumno. setclave public void setclave(java.lang.string clave_) Permite escribir la clave de un alumno. Parameters: clave_ - clave del alumno. setasignatura public void setasignatura(java.lang.string asignatura_) Permite escribir la asignatura de un alumno. Parameters: asignatura_ - asignatura del alumno. setcurso public void setcurso(java.lang.string curso_) Permite escribir el curso de un alumno. Parameters: curso_ - curso del alumno. tostring public java.lang.string tostring() Permite obtener todos los atributos de un alumno, en forma de String. Overrides: tostring in class java.lang.object Returns: devuelve toda la información de un alumno en forma de String. Pág. 142

153 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD comunicaion Class Comunicacion java.lang.object comunicaion.comunicacion public class Comunicacion extends java.lang.object Constructor Summary Comunicacion() Constructor, para crear una nueva instancia de Comunicación. Comunicacion(Main main_, java.lang.string puerto) Constructor, para crear una nueva instancia de Comunicación Method Summary void cargarpuertos(java.util.vector v) Sirve para cargar los puertos COM habilitados en el PC en un vector. void close() Sirve para cerrar la conexión al puerto serie. static java.lang.string getfecha() Permite obtener la fecha que se pasa. int open() Sirve para abrir una conexión con el puerto deseado, identificandolo mediante el nombre del puerto Pág. 143

154 que ha sido pasado en el constructor. java.util.vector read() Sirve para leer los datos recividos que van siendo encapsulados en un objeto Alumno según se van recibiendo y se van añadiendo a un vector de alumnos. void setfin(boolean fin_) Permite actualizar el valor de la variable fin void write(java.util.vector val, boolean fin) Sirve para enviar al móvil los datos de la base de datos, que han sido mostrados en la caja de texto y cargados en un vector. Methods inherited from class java.lang.object clone, equals, finalize, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Constructor Detail Comunicacion public Comunicacion(Main main_, java.lang.string puerto) Constructor, para crear una nueva instancia de Comunicación Parameters: main_ - para guardar la referencia a la clase principal puerto - nombre del puerto con el que se desea abrir la conexión. Comunicacion public Comunicacion() Constructor, para crear una nueva instancia de Comunicación. Pág. 144

155 Method Detail open public int open() Sirve para abrir una conexión con el puerto deseado, identificandolo mediante el nombre del puerto que ha sido pasado en el constructor. Returns: valor entero que devuelve un valor >0 si la conexión ha sido realizada correctamente, o un valor <0 si ha fallado. read public java.util.vector read() Sirve para leer los datos recividos que van siendo encapsulados en un objeto Alumno según se van recibiendo y se van añadiendo a un vector de alumnos. Returns: devuelve un vector con los alumnos recibidos. write public void write(java.util.vector val, boolean fin) Sirve para enviar al móvil los datos de la base de datos, que han sido mostrados en la caja de texto y cargados en un vector. Parameters: val - vector con los alumnos que se quieren mandar. fin - variable de control. close public void close() Sirve para cerrar la conexión al puerto serie. cargarpuertos Pág. 145

156 public void cargarpuertos(java.util.vector v) Sirve para cargar los puertos COM habilitados en el PC en un vector. Parameters: v - vector en el que se van a cargar los puertos encontrados. setfin public void setfin(boolean fin_) Permite actualizar el valor de la variable fin Parameters: fin_ - valor que va a tomar la variable fin. getfecha public static java.lang.string getfecha() Permite obtener la fecha que se pasa. Returns: fecha valor de la fecha leida en un Record Store de faltas. Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD Pág. 146

157 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD accesobd Class ConexionBD java.lang.object accesobd.conexionbd public class ConexionBD extends java.lang.object Constructor Summary ConexionBD() Crea un objeto ConexionBD necesario para realizar la conexion y otras tareas sencillas. Method Summary void actualizarcampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampoactual, java.lang.object nombrecamponuevo) Actualiza un solo campo de la tabla especificada. long buscarcampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampobuscado) Realiza una busqueda en una tabla de la BD; por cada campo que coincida con el campo que se esta buscando, se incrementa una variable de tipo long, al final devuelve el numero de campos iguales que encontro. Pág. 147

158 void CancelarTransaccion() Permite al programador poder descartar los cambios realizados hasta el momento por cualquier razon. void cerrarbloque() Necesario para poder guardar el registro a la BD. void cerrarconexion() libera la memoria usada por el objeto. void conectarmaccess(java.lang.string nombrebd) Realiza la coenxion a una BD Microsoft Access. void ConfirmarTransaccion() Permite al programador aceptar los cambios realizados hasta el momento en las tablas de la base de datos. void ejecutaconsulta(java.lang.string sql) Permite al programador ejecutar sentencias SQL INSERT, UPDATE, o DELETE directamente, solo ha de pasar la sentencia SQL correctamente formada. void ejecutapreparedst(java.lang.string sql) Permite al programador ejecutar sentencias PreparedStatement directamente, solo ha de pasar la sentencia SQL correctamente formada. void eliminarcampo(java.lang.string nombretabla, java.lang.string nombrecolumnallave, java.lang.object nombrecampo) Elimina un registro dentro la tabla especificada. boolean existecampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampobuscado) Realiza una busqueda en una tabla de la BD, en caso de haber encontrado el campo requerido devuelve true, en caso contrario devolvera false. java.sql.connection getconexion() Permite al programador poder usar la conexion que ya se ha abierto. Pág. 148

159 java.sql.resultset getconsulta(java.lang.string sql) Permite al programador ejecutar sentencias SQL SELECT directamente, solo ha de pasar la sentencia SQL correctamente formada. java.sql.resultset getrs() Dá acceso al ResultSet. void informacionconexion() Da informacion basica acerca de la conexion. void iniciarbloque(java.lang.string nombretabla) Necesario para poder insertar datos a la tabla. void IniciarTransaccion() Permite al programador poder usar transacciones con la base de datos, es decir, que hasta que no confirmemos los cambios realizados en las tablas, dichos cambios no seran guardados en la tabla. void insertarcampo(java.lang.string nombrecolumna, java.lang.object valorcolumna) Permite insertar campos a la BD. java.sql.resultset Select(java.lang.String select) Este metodo permite al programador realizar una consulta sql a la BD. Methods inherited from class java.lang.object clone, equals, finalize, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Pág. 149

160 Constructor Detail ConexionBD public ConexionBD() Crea un objeto ConexionBD necesario para realizar la conexion y otras tareas sencillas. Method Detail conectarmaccess public void conectarmaccess(java.lang.string nombrebd) Realiza la coenxion a una BD Microsoft Access. Para su correcto funcionamiento debe configurar el origen de datos en Windows. PanelDeControl->OrigenDeDatos(ODBC)->DSNdeSistema. Parameters: nombrebd - Nombre de la BD. informacionconexion public void informacionconexion() Da informacion basica acerca de la conexion. La informacion la arroja por consola. cerrarconexion public void cerrarconexion() libera la memoria usada por el objeto. Ademas libera cualquier otro recurso de la BD que se este utilizando. iniciarbloque public void iniciarbloque(java.lang.string nombretabla) Necesario para poder insertar datos a la tabla. Este metodo debe de ir antes de utilizar el metodo insertarcampo(string nombrecolumna,object valorcolumna). Pág. 150

161 Al terminar de insertar todos los datos deseados a la Tabla 'nombretabla' se debe terminar con el metodo cerrarbloque(). Parameters: nombretabla - Nombre de la tabla en la cual se va a introducir el registro. insertarcampo public void insertarcampo(java.lang.string nombrecolumna, java.lang.object valorcolumna) Permite insertar campos a la BD. Este/os metodo/s debe/n ir entre los metodos iniciarbloque(string nombretabla) y cerrarbloque(). Parameters: nombrecolumna - Nombre de la columna en la cual se desea insertar el dato. valorcolumna - valor que se desea insertar. cerrarbloque public void cerrarbloque() Necesario para poder guardar el registro a la BD. Este metodo debe ir despues del/os metodo/s insertarcampo(string nombrecolumna,object valorcolumna). existecampo public boolean existecampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampobuscado) Realiza una busqueda en una tabla de la BD, en caso de haber encontrado el campo requerido devuelve true, en caso contrario devolvera false. Parameters: nombretabla - Nombre de la tabla donde se busca. nombrecolumna - Nombre de la columna donde se lleva a cabo la busqueda, dentro de la tabla 'nombretabla'. nombrecampobuscado - Campo que se quiere buscar dentro de la tabla especificada. Returns: Pág. 151

162 true en caso de que se encuentre el campo buscado, de lo contrario devuelve false. buscarcampo public long buscarcampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampobuscado) Realiza una busqueda en una tabla de la BD; por cada campo que coincida con el campo que se esta buscando, se incrementa una variable de tipo long, al final devuelve el numero de campos iguales que encontro. Parameters: nombretabla - Nombre de la tabla donde se busca. nombrecolumna - Nombre de la columna donde se lleva a cabo la busqueda, dentro de la tabla 'nombretabla'. nombrecampobuscado - Campo que se quiere buscar dentro de la tabla especificada. Returns: El numero de coincidencias que se encontro. actualizarcampo public void actualizarcampo(java.lang.string nombretabla, java.lang.string nombrecolumna, java.lang.object nombrecampoactual, java.lang.object nombrecamponuevo) Actualiza un solo campo de la tabla especificada. Parameters: nombretabla - Nombre de la tabla donde se realizara la actualizacion. nombrecolumna - Nombre de la columna donde se lleva a cabo la actualizacion, dentro de la tabla 'nombretabla'. nombrecampoactual - Nombre del campo que se quiere remplazar. nombrecamponuevo - Campo nuevo que reemplazará al campo actual. Pág. 152

163 eliminarcampo public void eliminarcampo(java.lang.string nombretabla, java.lang.string nombrecolumnallave, java.lang.object nombrecampo) Elimina un registro dentro la tabla especificada. El campo que se desea eliminar debe ser la llave de la tabla Parameters: nombretabla - Nombre de la tabla dentro de la cual se llevara a cabo la eliminacion. nombrecolumnallave - Nombre de la columna llave donde se buscara el campo a eliminar. nombrecampo - campo que se desea eliminar Select public java.sql.resultset Select(java.lang.String select) Este metodo permite al programador realizar una consulta sql a la BD. La sentencia SELECT que se pase debe ir sin punto y coma(;). Luego el programador sabra que hacer con la variable ResultSet que retorna este metodo. En el caso de que ocurra un error al intentar de realizar la consulta el metodo retornara null. Parameters: select - sentencia sql que se quiere ejecutar Returns: una variable ResultSet getconexion public java.sql.connection getconexion() Permite al programador poder usar la conexion que ya se ha abierto. Esto le evita al programador tener que abrir una nueva conexion. Esto podria ser necesaria en caso de que sea necesario por parte del programador realizar algunas tareas que no son posibles llevar a cabo con esta clase. Returns: Pág. 153

164 la conexion getrs public java.sql.resultset getrs() Dá acceso al ResultSet. Returns: la variable ResultSet IniciarTransaccion public void IniciarTransaccion() throws java.sql.sqlexception Permite al programador poder usar transacciones con la base de datos, es decir, que hasta que no confirmemos los cambios realizados en las tablas, dichos cambios no seran guardados en la tabla. Si no se confirma la transaccion, los cambios seran descartados. Throws: java.sql.sqlexception CancelarTransaccion public void CancelarTransaccion() throws java.sql.sqlexception Permite al programador poder descartar los cambios realizados hasta el momento por cualquier razon. Throws: java.sql.sqlexception ConfirmarTransaccion public void ConfirmarTransaccion() throws java.sql.sqlexception Permite al programador aceptar los cambios realizados hasta el momento en las tablas de la base de datos. Throws: Pág. 154

165 java.sql.sqlexception ejecutaconsulta public void ejecutaconsulta(java.lang.string sql) throws java.sql.sqlexception Permite al programador ejecutar sentencias SQL INSERT, UPDATE, o DELETE directamente, solo ha de pasar la sentencia SQL correctamente formada. Este método no devolvera nada. Throws: java.sql.sqlexception ejecutapreparedst public void ejecutapreparedst(java.lang.string sql) throws java.sql.sqlexception Permite al programador ejecutar sentencias PreparedStatement directamente, solo ha de pasar la sentencia SQL correctamente formada. Este método no devolvera nada. Parameters: sql - sentencia sql que se quiere ejecutar. Throws: java.sql.sqlexception getconsulta public java.sql.resultset getconsulta(java.lang.string sql) throws java.sql.sqlexception Permite al programador ejecutar sentencias SQL SELECT directamente, solo ha de pasar la sentencia SQL correctamente formada. Este metodo devolvera un objeto ResultSet sin posicionar, para posicionarse usar el metodo next(). Parameters: sql - sentencia sql a ejecutar. Throws: java.sql.sqlexception Pág. 155

166 11.2 API SOSA BLUETOOTH SERVER Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD apps Class Alumno java.lang.object apps.alumno public class Alumno extends java.lang.object Constructor Summary Alumno() Crea una nueva instancia de Alumno sin atributos Alumno(java.lang.String nombreapellidos_, java.lang.string clave_, java.lang.string asignatura_, java.lang.string curso_) Crea una nueva instancia de Alumno con todos los atributos del alumno. Method Summary java.lang.string getasignatura() Permite obtener la asignatura de un alumno. java.lang.string getclave() ermite obtener la clave de un alumno. java.lang.string getcurso() Permite obtener el curso de un alumno. java.lang.string getnombre() Permite obtener el nombre de un alumno. Pág. 156

167 void setasignatura(java.lang.string asignatura_) Permite escribir la asignatura de un alumno. void setclave(java.lang.string clave_) Permite escribir la clave de un alumno. void setcurso(java.lang.string curso_) Permite escribir el curso de un alumno. void setnombre(java.lang.string nombreapellidos_) Permite escribir el nombre de un alumno. java.lang.string tostring() Permite obtener todos los atributos de un alumno, en forma de String. Methods inherited from class java.lang.object equals, getclass, hashcode, notify, notifyall, wait, wait, wait Constructor Detail Alumno public Alumno() Crea una nueva instancia de Alumno sin atributos Alumno public Alumno(java.lang.String nombreapellidos_, java.lang.string clave_, java.lang.string asignatura_, java.lang.string curso_) Crea una nueva instancia de Alumno con todos los atributos del alumno. Parameters: nombreapellidos_ - nombre y apellidos del alumno. Pág. 157

168 clave_ - clave que diferencia a cada alumno. asignatura_ - asignatura a la que pertenece el alumno. curso_ - curso al que pertenece el alumno. Method Detail getnombre public java.lang.string getnombre() Permite obtener el nombre de un alumno. Returns: devuelve el nombre de un alumno en forma de String. getclave public java.lang.string getclave() ermite obtener la clave de un alumno. Returns: devuelve la clave de un alumno en forma de String. getasignatura public java.lang.string getasignatura() Permite obtener la asignatura de un alumno. Returns: devuelve la asignatura de un alumno en forma de String. getcurso public java.lang.string getcurso() Permite obtener el curso de un alumno. Returns: devuelve el curso de un alumno en forma de String. setnombre Pág. 158

169 public void setnombre(java.lang.string nombreapellidos_) Permite escribir el nombre de un alumno. Parameters: nombreapellidos_ - nombre y apellidos del alumno. setclave public void setclave(java.lang.string clave_) Permite escribir la clave de un alumno. Parameters: clave_ - clave del alumno. setasignatura public void setasignatura(java.lang.string asignatura_) Permite escribir la asignatura de un alumno. Parameters: asignatura_ - asignatura del alumno. setcurso public void setcurso(java.lang.string curso_) Permite escribir el curso de un alumno. Parameters: curso_ - curso del alumno. tostring public java.lang.string tostring() Permite obtener todos los atributos de un alumno, en forma de String. Overrides: tostring in class java.lang.object Returns: devuelve toda la información de un alumno en forma de String. Pág. 159

170 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD apps Class Rms java.lang.object apps.rms All Implemented Interfaces: javax.microedition.rms.recordcomparator public abstract class Rms extends java.lang.object implements javax.microedition.rms.recordcomparator Field Summary static java.lang.string fecha_ static javax.microedition.rms.recordstore rs Fields inherited from interface javax.microedition.rms.recordcomparator EQUIVALENT, FOLLOWS, PRECEDES Constructor Summary Rms() Crea una nueva instancia de Rms Pág. 160

171 Method Summary static javax.microed ition.rms.recordstor e abrirrs(java.lang.string nombre) pasa. Permite abrir un Record Store con el nombre que se le static void cerrarrs(javax.microedition.rms.recordstore rs) Permite cerrar un Record Store int compare(byte[] reg1, byte[] reg2) Permite comparar dos registros y devulve la relación entre ambos static void destruirrs(java.lang.string nombre) Permite eliminar un RecordStore static void escribiralumnors(alumno alumno, javax.microedition.rms.recordstore rs) Permite escribir un objeto Alumno, en el RecordStore que se especifica static void escribircontraseñars(java.lang.string pass, javax.microedition.rms.recordstore rs) Permite escribir un String en el RecordStore indicado. static void escribirfaltasrs(alumno alumno, javax.microedition.rms.recordstore rs) Permite escribir un objeto Alumno y la fecha del dia, en el RecordStore que se especifica static java.lang.str ing getfecha() de faltas. Permite obtener la fecha de un Record Store static int getid(java.lang.string nombrers, Alumno alid) Permite obtener el id de un alumno del Record Store deseado. static Alumno leeralumnors(int id, javax.microedition.rms.recordstore rs) Permite leer un objeto Alumno Pág. 161

172 static java.lang.str ing leercontraseñars(int id, javax.microedition.rms.recordstore rs) Permite leer un String del Record Strore deseado. static Alumno leerfaltasrs(int id, javax.microedition.rms.recordstore rs) Permite leer un objeto Alumno correspondiente a las faltas. static int modificaralumno(java.lang.string nombrers, int idmod, Alumno almod) Permite modificar un alumno del Record Store deseado. static void sustituirdators(java.lang.string dato, int id, javax.microedition.rms.recordstore rs) Permite sustituir un String de la posición indicada Methods inherited from class java.lang.object equals, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Field Detail rs public static javax.microedition.rms.recordstore rs fecha_ public static java.lang.string fecha_ Pág. 162

173 Constructor Detail Rms public Rms() Crea una nueva instancia de Rms Method Detail abrirrs public static javax.microedition.rms.recordstore abrirrs(java.lang.string nombre) Permite abrir un Record Store con el nombre que se le pasa. Parameters: nombre - nombre del Record Store que se desea abrir. Returns: devuelve el Record Store abierto. escribiralumnors public static void escribiralumnors(alumno alumno, javax.microedition.rms.recordstore rs) Permite escribir un objeto Alumno, en el RecordStore que se especifica Parameters: alumno - Objeto Alumno que se quiere insertar. rs - Record Store en el cual se quiere insertar el alumno. escribirfaltasrs public static void escribirfaltasrs(alumno alumno, javax.microedition.rms.recordstore rs) Permite escribir un objeto Alumno y la fecha del dia, en el RecordStore que se especifica Parameters: alumno - Objeto Alumno que se quiere insertar. Pág. 163

174 rs - Record Store en el cual se quiere insertar el alumno. sustituirdators public static void sustituirdators(java.lang.string dato, int id, javax.microedition.rms.recordstore rs) Permite sustituir un String de la posición indicada Parameters: dato - String que se desea sustituir id - identificador del registro en el cual se quiere sustituir el dato. rs - Record Store en el cual se quiere sustituir el dato. leeralumnors public static Alumno leeralumnors(int id, javax.microedition.rms.recordstore rs) Permite leer un objeto Alumno Parameters: id - identificador del registro en el cual se quiere leer el dato. rs - Record Store del cual se quiere leer el objeto Alumno. Returns: devuelve el objeto Alumno que se corresponde con el id leerfaltasrs public static Alumno leerfaltasrs(int id, javax.microedition.rms.recordstore rs) Permite leer un objeto Alumno correspondiente a las faltas. Parameters: id - identificador del registro en el cual se quiere leer el dato. rs - Record Store del cual se quiere leer el objeto Alumno. Returns: devuelve el objeto Alumno que se corresponde con el id Pág. 164

175 cerrarrs public static void cerrarrs(javax.microedition.rms.recordstore rs) Permite cerrar un Record Store Parameters: rs - Record Store que se quiere cerrar. destruirrs public static void destruirrs(java.lang.string nombre) Permite eliminar un RecordStore Parameters: nombre - nombre del Record Store que se desea eliminar. compare public int compare(byte[] reg1, byte[] reg2) Permite comparar dos registros y devulve la relación entre ambos Specified by: compare in interface javax.microedition.rms.recordcomparator Parameters: reg1 - array de bytes que se desea comparar. reg2 - array de bytes con el que se compara reg1. Returns: Si el resultado devuelto es: =0 => RecordComparator.EQUIVALENT <0 => RecordComparator.PRECEDES >0 => RecordComparator.FOLLOWS escribircontraseñars public static void escribircontraseñars(java.lang.string pass, javax.microedition.rms.recordstore rs) Permite escribir un String en el RecordStore indicado. Parameters: pass - valor del String que se quiere almacenar. rs - Record Store en el cual se quiere almacenar el String. Pág. 165

176 leercontraseñars public static java.lang.string leercontraseñars(int id, javax.microedition.rms.recordstore rs) Permite leer un String del Record Strore deseado. Parameters: id - identificador del registro al cual se quiere acceder. rs - Record Store del que se quiere leer el String. modificaralumno public static int modificaralumno(java.lang.string nombrers, int idmod, Alumno almod) Permite modificar un alumno del Record Store deseado. Parameters: nombrers - nombre del Record Store donde se encuentra el alumno a modificar. idmod - id del alumno a modificar. almod - objeto alumno con los nuevos datos. Returns: devuelve un entero para confirmar la operación, cuyos valores son: 0 si se ha modificado y distinto de 0 si no se ha dado. getid public static int getid(java.lang.string nombrers, Alumno alid) Permite obtener el id de un alumno del Record Store deseado. Parameters: nombrers - nombre del Record Store donde se encuentra el alumno. alid - alumno del que se quiere obtener el id. Returns: devuelve el id del alumno o en su defecto un número negativo. Pág. 166

177 getfecha public static java.lang.string getfecha() Permite obtener la fecha de un Record Store de faltas. Returns: devuelve la fecha en forma de String. Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD Pág. 167

178 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD apps Class App java.lang.object javax.microedition.midlet.midlet apps.app All Implemented Interfaces: javax.microedition.lcdui.commandlistener public class App extends javax.microedition.midlet.midlet implements javax.microedition.lcdui.commandlistener Field Summary javax.microedition.lcdui.alert alertaalumno javax.microedition.lcdui.alert alertacambioclave javax.microedition.lcdui.alert alertacontraseña javax.microedition.lcdui.alert alertaerror javax.microedition.lcdui.alert alertaini java.lang.string alumnobaja java.lang.string asignatura Pág. 168

179 java.lang.string claveal javax.microedition.lcdui.command cmdbajars javax.microedition.lcdui.command cmdbuscar javax.microedition.lcdui.command cmdcambiar javax.microedition.lcdui.command cmdguardar javax.microedition.lcdui.command cmdguardarfaltas javax.microedition.lcdui.command cmdiniciar javax.microedition.lcdui.command cmdmodificar javax.microedition.lcdui.command cmdmostrar javax.microedition.lcdui.command cmdno javax.microedition.lcdui.command cmdnuevors javax.microedition.lcdui.command cmdok javax.microedition.lcdui.command cmdsalir javax.microedition.lcdui.command cmdseldisp javax.microedition.lcdui.command cmdseleccionar javax.microedition.lcdui.command cmdseleccionard Pág. 169

180 javax.microedition.lcdui.command cmdsi javax.microedition.lcdui.command cmdsiguiente javax.microedition.lcdui.command cmdsiguienteapell javax.microedition.lcdui.command cmdsiguienteasig javax.microedition.lcdui.command cmdsiguienteclave javax.microedition.lcdui.command cmdsiguientecurso javax.microedition.lcdui.command cmdvolver java.lang.string curso java.lang.string fecha javax.microedition.lcdui.form foracercade javax.microedition.lcdui.form forcalendario javax.microedition.lcdui.form forpregunta java.lang.string guardaren int id javax.microedition.lcdui.list liscp javax.microedition.lcdui.list lisdatop Pág. 170

181 javax.microedition.lcdui.list lisdatos javax.microedition.lcdui.list lisdisp javax.microedition.lcdui.list lismenu javax.microedition.lcdui.list lispasarl javax.microedition.lcdui.list lisrs javax.microedition.lcdui.list lisver java.lang.string nombre java.lang.string nombreapellidos java.lang.string nombrers int opcionver int pant javax.microedition.lcdui.display pantalla javax.microedition.lcdui.form pantallainicial javax.microedition.rms.recordstore rsaux java.lang.string rsbaja javax.microedition.rms.recordstore rsclave Pág. 171

182 java.lang.string sclave java.lang.string sclavecomp java.lang.string sclavenueva static javax.microedition.lcdui.list slismenu static javax.microedition.lcdui.display spantalla javax.microedition.lcdui.stringitem striacercade javax.microedition.lcdui.textbox texalumno javax.microedition.lcdui.textbox texcontraseña javax.microedition.lcdui.textbox texmodificarc1 javax.microedition.lcdui.textbox texmodificarc2 javax.microedition.lcdui.textbox texmodificarc3 javax.microedition.lcdui.ticker tickmodificar int tipoop Constructor Summary App() Permite crear una instancia de App Pág. 172

183 Method Summary boolean buscarrs(javax.microedition.lcdui.list list) Permite mostrar los Record Store del dispositivo correspondientes a la aplicación, exceptuando el que corresponde a la contraseña, ya que no debe ser manipulado por el usuario. void commandaction(javax.microedition.lcdui. Command c, javax.microedition.lcdui.displayable d) Implementación del interfaz CommandListener. void destroyapp(boolean unconditional) java.lang.string getfecha() Permite dar un valor a la variable fecha. static javax.microedi tion.lcdui.display getpantalla() principal Permite devolver la referencia a la pantalla void mostraralarma(java.lang.string s, javax.microedition.lcdui.displayable disp) Permite mostrar una pantalla con un texto durante un determinado periodo de tiempo y volver a mostrar la pantalla deseada. java.util.vector mostrarrs(javax.microedition.lcdui.list lis, java.lang.string nombrers) Permite mostrar el contenido del Record Store seleccionado ordenado alfabeticamente por nombre void ordenarv(java.util.vector v) Permite ordenar alfabéticamente un vector. void pauseapp() Pág. 173

184 void setopciover(int valor) Permite dar un valor a la variable opcionver. void startapp() Implementación de la clase MIDlet static void volverapp() Permite volver a la pantalla del menú principal del midlet void volverlismenu() Permite mostrar al menú principal de la aplicación. Methods inherited from class javax.microedition.midlet.midlet checkpermission, getappproperty, notifydestroyed, notifypaused, platformrequest, resumerequest Methods inherited from class java.lang.object equals, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Field Detail lismenu public javax.microedition.lcdui.list lismenu lispasarl public javax.microedition.lcdui.list lispasarl Pág. 174

185 lisrs public javax.microedition.lcdui.list lisrs liscp public javax.microedition.lcdui.list liscp lisdatos public javax.microedition.lcdui.list lisdatos lisdatop public javax.microedition.lcdui.list lisdatop lisdisp public javax.microedition.lcdui.list lisdisp lisver public javax.microedition.lcdui.list lisver texcontraseña public javax.microedition.lcdui.textbox texcontraseña texmodificarc1 public javax.microedition.lcdui.textbox texmodificarc1 texmodificarc2 public javax.microedition.lcdui.textbox texmodificarc2 texmodificarc3 Pág. 175

186 public javax.microedition.lcdui.textbox texmodificarc3 texalumno public javax.microedition.lcdui.textbox texalumno pantallainicial public javax.microedition.lcdui.form pantallainicial forcalendario public javax.microedition.lcdui.form forcalendario foracercade public javax.microedition.lcdui.form foracercade forpregunta public javax.microedition.lcdui.form forpregunta striacercade public javax.microedition.lcdui.stringitem striacercade alertaini public javax.microedition.lcdui.alert alertaini alertacontraseña public javax.microedition.lcdui.alert alertacontraseña alertaerror public javax.microedition.lcdui.alert alertaerror Pág. 176

187 alertacambioclave public javax.microedition.lcdui.alert alertacambioclave alertaalumno public javax.microedition.lcdui.alert alertaalumno cmdiniciar public javax.microedition.lcdui.command cmdiniciar cmdsalir public javax.microedition.lcdui.command cmdsalir cmdok public javax.microedition.lcdui.command cmdok cmdvolver public javax.microedition.lcdui.command cmdvolver cmdseleccionar public javax.microedition.lcdui.command cmdseleccionar cmdcambiar public javax.microedition.lcdui.command cmdcambiar cmdsiguiente public javax.microedition.lcdui.command cmdsiguiente Pág. 177

188 cmdmodificar public javax.microedition.lcdui.command cmdmodificar cmdguardar public javax.microedition.lcdui.command cmdguardar cmdseleccionard public javax.microedition.lcdui.command cmdseleccionard cmdmostrar public javax.microedition.lcdui.command cmdmostrar cmdsiguienteapell public javax.microedition.lcdui.command cmdsiguienteapell cmdsiguienteclave public javax.microedition.lcdui.command cmdsiguienteclave cmdsiguienteasig public javax.microedition.lcdui.command cmdsiguienteasig cmdsiguientecurso public javax.microedition.lcdui.command cmdsiguientecurso cmdnuevors public javax.microedition.lcdui.command cmdnuevors cmdbuscar Pág. 178

189 public javax.microedition.lcdui.command cmdbuscar cmdseldisp public javax.microedition.lcdui.command cmdseldisp cmdguardarfaltas public javax.microedition.lcdui.command cmdguardarfaltas cmdsi public javax.microedition.lcdui.command cmdsi cmdno public javax.microedition.lcdui.command cmdno cmdbajars public javax.microedition.lcdui.command cmdbajars pantalla public javax.microedition.lcdui.display pantalla spantalla public static javax.microedition.lcdui.display spantalla sclave public java.lang.string sclave sclavecomp public java.lang.string sclavecomp Pág. 179

190 sclavenueva public java.lang.string sclavenueva tickmodificar public javax.microedition.lcdui.ticker tickmodificar rsclave public javax.microedition.rms.recordstore rsclave rsaux public javax.microedition.rms.recordstore rsaux nombreapellidos public java.lang.string nombreapellidos claveal public java.lang.string claveal asignatura public java.lang.string asignatura curso public java.lang.string curso nombre public java.lang.string nombre Pág. 180

191 guardaren public java.lang.string guardaren nombrers public java.lang.string nombrers alumnobaja public java.lang.string alumnobaja rsbaja public java.lang.string rsbaja fecha public java.lang.string fecha id public int id tipoop public int tipoop pant public int pant opcionver public int opcionver slismenu Pág. 181

192 public static javax.microedition.lcdui.list slismenu Constructor Detail App public App() Permite crear una instancia de App Method Detail startapp public void startapp() Implementación de la clase MIDlet Specified by: startapp in class javax.microedition.midlet.midlet pauseapp public void pauseapp() Specified by: pauseapp in class javax.microedition.midlet.midlet destroyapp public void destroyapp(boolean unconditional) Specified by: destroyapp in class javax.microedition.midlet.midlet commandaction public void commandaction(javax.microedition.lcdui.command c, javax.microedition.lcdui.displayable d) Implementación del interfaz CommandListener. Nos permite manejar los eventos que se produzcan. Specified by: commandaction in interface javax.microedition.lcdui.commandlistener Pág. 182

193 Parameters: c - comando que ha ocasionado el evento. d - pantalla en la que se ha producido el evento. getpantalla public static javax.microedition.lcdui.display getpantalla() Permite devolver la referencia a la pantalla principal Returns: devuelve el objeto que hace referencia a la ventana principal del midlet volverapp public static void volverapp() Permite volver a la pantalla del menú principal del midlet buscarrs public boolean buscarrs(javax.microedition.lcdui.list list) Permite mostrar los Record Store del dispositivo correspondientes a la aplicación, exceptuando el que corresponde a la contraseña, ya que no debe ser manipulado por el usuario. Parameters: list - ventana lista, en la que se quiere mostrar el nombre de los Record Store encontrados. Returns: devuelve cierto si ha encontrado Record Stores que no sean el de la contraseña. mostrarrs public java.util.vector mostrarrs(javax.microedition.lcdui.list lis, java.lang.string nombrers) Permite mostrar el contenido del Record Store seleccionado ordenado alfabeticamente por nombre Parameters: Pág. 183

194 lis - ventana lista, en la cual se quiere mostrar el contenido del Record Store. nombrers - nombre del Record Store del cual se quiere mostrar el contenido. Returns: devuelve un vector con el contenido ordenado del Record Store. ordenarv public void ordenarv(java.util.vector v) Permite ordenar alfabéticamente un vector. Parameters: v - vector que va a ser ordenado. mostraralarma public void mostraralarma(java.lang.string s, javax.microedition.lcdui.displayable disp) Permite mostrar una pantalla con un texto durante un determinado periodo de tiempo y volver a mostrar la pantalla deseada. Parameters: s - texto que va a mostrar la ventana. disp - ventana que va a ser mostrada una vez transcurrido el tiempo. volverlismenu public void volverlismenu() Permite mostrar al menú principal de la aplicación. setopciover public void setopciover(int valor) Permite dar un valor a la variable opcionver. Parameters: valor - valor que será asignado a la variable opcionver. Pág. 184

195 getfecha public java.lang.string getfecha() Permite dar un valor a la variable fecha. Returns: fecha valor de la fecha leida en un Record Store de faltas. Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD Pág. 185

196 Overview Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes SUMMARY: NESTED FIELD CONSTR METHOD DETAIL: FIELD CONSTR METHOD comunicacion Class Comunicacion java.lang.object comunicacion.comunicacion All Implemented Interfaces: java.lang.runnable, javax.microedition.lcdui.commandlistener public class Comunicacion extends java.lang.object implements javax.microedition.lcdui.commandlistener, java.lang.runnable Nested Class Summary class Comunicacion.Listener Implementación del interfaz DiscoveryListener. Field Summary javax.microedition.lcdui.list lise javax.microedition.lcdui.list lisp javax.microedition.lcdui.list lisr javax.microedition.rms.recordstore rsaux javax.microedition.lcdui.textbox text Pág. 186

197 Constructor Summary Comunicacion(App app_) Crea una nueva instancia de Comunicacion Method Summary void commandaction(javax.microedition.lcdui.command c, javax.microedition.lcdui.displayable d) Implementación del interfaz CommandListener, el cual no va a permitir el control de los eventos. void escribir() Permite mandar información, en este caso datos de un alumno, a un dispositivo remoto bluetooth. java.util.vector leer() Permite leer información, en este caso datos de un alumno, de un dispositivo remoto bluetooth. void mostraralarma(java.lang.string s, javax.microedition.lcdui.displayable disp) Permite mostrar una pantalla con un texto durante un determinado periodo de tiempo y volver a mostrar la pantalla deseada. void mostrardispositivos() Permite mostrar los "friendly names" de los dispositivos remotos void mostrarservicios() Permite mostrar los "servicios encontrados void run() Pág. 187

198 Implementación del interfaz Runnable, el cual se va a ejecutar cada vez que iniciemos un thread. Methods inherited from class java.lang.object equals, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Field Detail lisr public javax.microedition.lcdui.list lisr lise public javax.microedition.lcdui.list lise lisp public javax.microedition.lcdui.list lisp text public javax.microedition.lcdui.textbox text rsaux public javax.microedition.rms.recordstore rsaux Pág. 188

199 Constructor Detail Comunicacion public Comunicacion(App app_) Crea una nueva instancia de Comunicacion Parameters: app_ - referencia al objeto App de la clase principal, que nos servirá para mostrar ventanas. Method Detail commandaction public void commandaction(javax.microedition.lcdui.command c, javax.microedition.lcdui.displayable d) Implementación del interfaz CommandListener, el cual no va a permitir el control de los eventos. Specified by: commandaction in interface javax.microedition.lcdui.commandlistener Parameters: c - comando que ha probocado el evento. d - pantalla en la cual se ha producido el evento. mostraralarma public void mostraralarma(java.lang.string s, javax.microedition.lcdui.displayable disp) Permite mostrar una pantalla con un texto durante un determinado periodo de tiempo y volver a mostrar la pantalla deseada. Parameters: s - texto que va a mostrar la ventana. disp - ventana que va a ser mostrada una vez transcurrido el tiempo. escribir Pág. 189

200 public void escribir() Permite mandar información, en este caso datos de un alumno, a un dispositivo remoto bluetooth. Antes de ejecutarlo, se debe ejecutar buscardispositivos() y a continuación buscarservicios(), ya que necesita tener un dispositivo y un servicio sobre el que obtener el URL. También necesita tener cargado antes de ejecutarlo, un vector con objetos alumno (venviar). leer public java.util.vector leer() Permite leer información, en este caso datos de un alumno, de un dispositivo remoto bluetooth. Antes de ejecutarlo, se debe ejecutar buscardispositivos() y a continuación buscarservicios(), ya que necesita tener un dispositivo y un servicio sobre el que obtener el URL. Returns: devuelve un Vector de con objetos Alumno, los cuales se han encapsulado según se iban recibiendo los datos del alumno. run public void run() Implementación del interfaz Runnable, el cual se va a ejecutar cada vez que iniciemos un thread. Specified by: run in interface java.lang.runnable mostrardispositivos public void mostrardispositivos() Permite mostrar los "friendly names" de los dispositivos remotos mostrarservicios public void mostrarservicios() Permite mostrar los "servicios encontrados Pág. 190

201 11.3 PROTOCOLOS ESPECÍFICOS DE BLUETOOTH BLUETOOTH RADIO Bandas de frecuencia empleadas Bluetooth trabaja en la banda ISM de 2.4 Ghz, precisa de una frecuencia de salto de 79 en 1 MHz. Las frecuencias de operación del SIG 17 son las siguientes: Zona geográfica Rango de frecuencias Canales RF Mayoría de los países GHz f = k MHz k=0..78 España GHz f = k MHz k=0..22 Francia GHz f = k MHz k=0..22 frecuencias Canales Tabla Frecuencias Bluetooth. Zona geográfica Rango de frecuencias Canales RF En España y Francia la banda esta reducida de forma temporal, usando 23 saltos de frecuencia a falta de completar las regulaciones de banda de cada país. Supone un problema de compatibilidades entre equipos de distintos países. En todos los casos el espacio entre canales es de 1 MHz y para tener en cuenta las emisiones fuera de banda se establecen los siguientes anchos de banda de salvaguarda al principio y al final de la banda de frecuencias de trabajo: Zona geográfica Guarda inferior Guarda superior USA 2 MHz 3.5 MHz Europa 2 MHz 3.5 MHz 17 Bluetooth Special Interest Group: 3Com, Ericsson, Intel, IBM, Agere, Microsoft, Motorola, Nokia and Toshiba. Pág. 191

202 (menos España y Francia) España 4 MHz 26 MHz Francia 7.5 MHz 7.5 MHz Japón 2 MHz 2 MHz Tabla Bandas de salvaguarda Características del dispositivo transmisor Los requisitos se indican como niveles de potencia en la antena conectora del equipo. Si el equipo no tuviera un conector se asume una antena de ganancia 0 dbi (con respecto a la antena isótropa). Si se utilizan antenas direccionales de ganancia superior a 0 dbi se deben aplicar las normas de la FCc y ka ETSI Los equipos se clasifican en los siguientes de acuerdo a los niveles de potencia: Clase de Potencia máx. Potencia Potencia mín. potencia de salida nominal de salida Control de salida potencia mw (20 dbm) N/A 1 mw (0 dbm) 4 a +20 dbm -30 a 0 dbm, opcional mw (4 dbm) 1 mw (0 dbm) 0.25 mw (-6 dbm) -30 a 0 dbm, opcional 3 1 mw (0 dbm) N/A N/A -30 a 0 dbm, opcional lase de Tabla 11.3 Clases de potencia equipos Bluetooth. El control de potencia se aplica a todos los equipos de tipo 1, y consiste en limitar todas las potencias transmitidas por encima de los 0 dbm. El control de potencia por debajo de los 0 dbm es opcional pero ha de ser tenido en cuenta para optimizar el consumo de potencia y los niveles de interferencia. Pág. 192

203 Características de la modulación La modulación que emplea Bluetooth es GFSK 18 banda por tiempo BT=0.5. con un producto ancho de Características: El índice de modulación debe estar entre 0.28 y Un uno binario se representa por una desviación positiva de frecuencia y un cero binario como una desviación negativa. La desviación mínima no ha de ser menor de 115 KHz. El error de los pasos por cero (diferencia de tiempo entre el período de símbolo ideal y el tiempo de cruce medido) debe ser menor de ±1/8 del período de símbolo. Figura 11.1 Modulación GFSK. Emisiones espúreas 19 Para medir las emisiones espúreas dentro y fuera de la banda de transmisión se utiliza un transmisor que debe cambiar de frecuencia entre el slot de transmisión y el de recepción, pero siempre vuelve a la misma frecuencia. Estas emisiones espúreas vienen reguladas por diversos organismos en función del país. 18 Gaussian Frequency Shift Keying 19 Las frecuencias donde no se satisfacen los requisitos se llaman frecuencias espúreas. Pág. 193

204 Dentro de la banda de transmisión El transmisor debe pasar por una máscara espectral definida por la siguiente tabla donde se supone que el transmisor transmite en el canal M, y N es el número de canal adyacente donde se mide el nivel de potencia: Desplazamiento en frecuencia Potencia transmitida ±550 KHz -20 dbm M-N =2-20 dbm M-N 3-40 dbm Tabla Máscara de espectro transmitido Fuera de banda La frecuencia central inicial del transmisor ha de estar centrada con una precisión de ± 75 KHz. Esta precisión ha de ser tenida en cuenta antes de cualquier tipo de transmisión de datos. Modo de operación Modo de de espera 30 MHz- 1GHz -36 dbm -57 dbm 1GHz-12.75GHz -30 dbm -47 dbm 1.8GHz-1.9GHz -47 dbm -47 dbm 5.15GHz-5.3GHz -47 dbm -47 dbm Tabla Requisitos de los espúreos fuera de banda. Pág. 194

205 Características del dispositivo receptor Nivel real de sensibilidad: para poder medir una tasa de error de bit, el equipo receptor envía de vuelta la información decodificada. Para una BER del 0.1% se define el nivel de sensibilidad de un receptor Bluetooth 70dBm. Interferencias: el comportamiento frente a interferencias cocanales (de la misma frecuencia que la señal deseada) y de canales adyacentes de 1 y 2 MHz se mide con una señal deseada 10 db mayor que el nivel de sensibilidad de referencia. Para canales adyacentes de otras frecuencias, la señal deseada será 3 db mayor que el nivel de sensibilidad de referencia. Con estas condiciones, la tasa de error de bit será menor del 0.1%. La relación entre la señal transmitida y la señal que causa la interferencias C/I, será la siguiente según el tipo de interferencia: Requisito Ratio (C/I) Interferencia cocanal Interferencia adyacente1 MHz Interferencia adyacente 2MHz Interferencia adyacente a más de 2 MHz 11 db 0 db -30 db -40 db Tabla 11.5 Interferencias. Sólo se permiten cinco frecuencias espúreas a una distancia mayor de 2 MHz respecto de la señal deseada. Estas frecuencias espúreas deben satisfacer una C/I=- 17dB. Bloqueo fuera de banda: se mide con la señal bajo estudio a 3 db sobre el nivel de referencia. Esta señal interferente ha de ser continua y debe cumplir los siguientes requisitos para obtener la BER deseada: Pág. 195

206 Frecuencia señal iterferente Nivel potencia interferente 30 MHz 2 GHz -10 dbm 2 GHz GHz -27 dbm GHz -27 dbm 3 GHz GHz -10 dbm Tabla 11.6 Bloqueo fuera de banda. Intermodulación: se han de cumplir las siguientes condiciones para que la BER sea del 0.1%: a) La señal deseada en la frecuencia f0 debe ser 6 db mayor que el nivel de sensibilidad de referencia. b) Una señal sinusoidal en la frecuencia f1 con un nivel de potencia de 39 dbm. c) Una señal modulada Bluetooth, en la frecuencia f2 con un nivel de potencia de 39 dbm. Donde f0 = 2f1 f2 y f1 f2 =n MHz con n =3,4 ó 5. Nivel máximo utilizable: el receptor debe operar a un nivel de entrada máximo utilizable mejor que 20 dbm. La tasa de error de bit es menor o igual al 0.1% si la potencia de entrada es de 20 dbm. RSSI 20 : indica si un dispositivo puede conseguir una referencia de la potencia recibida en un enlace, pudiendo determinar así si el transmisor debe o no incrementar la potencia transmitida BLUETOOTH BASEBAND Controla los canales físicos y enlaza con otros servicios tales como errores de corrección, fallos en los datos o seguridad en Bluetooth. Este protocolo está implementado como un controlador de enlace, que con el administrador de enlaces para 20 Receiver Signal Strengh Indicator Pág. 196

207 suministrar rutinas de enlace tales como conexiones de enlace o control de potencia. El transmisor de banda base emplea un esquema TDD 21. En este nivel, el sistema Bluetooth consiste en una unidad de radio, una unidad de control del enlace y una unidad de apoyo para la gestión del enlace y para las funciones de interfaz del terminal. Figura 11.2 Diferentes bloques funcionales. Canales físicos El canal está representado por una secuencia pseudoaletoria de 79 ó 23 canales RF, determinante para el dispositivo de direcciones de Bluetooth y es determinada por el reloj Bluetooth del maestro. El canal está dividido slots 22 donde cada uno corresponde a un salto de frecuencia RF. Saltos consecutivos corresponden a diferentes frecuencias de saltos RF. La tasa de saltos nominal es de 1600 saltos/seg. Este protocolo de Bluetooth emplea una combinación de conmutación de circuitos y paquetes. Se pueden reservar slots para los paquetes asíncronos. Bluetooth puede soportar un canal de datos asíncrono, hasta tres canales de voz simultáneos o un canal que soporte simultáneamente datos asíncronos y voz. Cada canal de voz soporta un canal asíncrono de 64 Kbps en cada dirección. El canal asíncrono puede soportar una tasa asimétrica de 721 Kbps con 57.6 Kbps en la dirección contraria, o si es simétrico, Kbps. 21 dúplex por división en el tiempo. 22 fragmentos de tiempo Pág. 197

208 El sistema Bluetooth proporciona una conexión punto a punto, o multipunto. En este último caso, el canal es compartido por varias unidades Bluetooth. Dos o más unidades que comparten el mismo canal forman una piconet. Una unidad Bluetooth actúa como el maestro de la piconet, mientras que el resto de unidades actúan como esclavos. Como máximo pueden estar activos siete esclavos en una piconet. Además, muchos más esclavos pueden permanecer bloqueados para el maestro, quedando así en un estado aparcado. Estos esclavos aparcados no pueden estar activos en el canal, pero se quedan sincronizados con el maestro. Tanto para los esclavos activos como para los aparcados, el acceso al canal es controlado por el maestro. Múltiples piconets con áreas de cobertura solapadas forman una scatternet. Cada piconet sólo puede tener un maestro. Sin embargo, los esclavos pueden participar en piconets diferentes sobre la base de una multiplexación por división en el tiempo. Además, el maestro de una piconet puede ser el esclavo de otra piconet. Las piconets no estarán sincronizadas en el tiempo o en frecuencia. Cada piconet tiene su propio canal con sus correspondientes saltos en frecuencia. Slots de tiempo: Cada slot corresponde a 625µseg. La numeración de los slots se realiza conforme al reloj del maestro de la piconet. El rango de numeración de los slots está entre 0 y y es cíclico. El maestro y el esclavo pueden transmitir alternativamente según un esquema TDD. El maestro comienza su transmisión en los slots pares, mientras que los esclavos lo hacen en los impares, tal y como se refleja en la siguiente figura. El comienzo de transmisión del paquete coincide con comienzo del slot durante el cual la frecuencia de salto ha de permanecer fija. Pág. 198

209 Figura 11.3 TDD y temporización. Un paquete puede tener una duración mayor que un slot de forma que la frecuencia de salto permanece fija durante la transmisión del paquete. Una vez finalizada volverá a ser la misma que si cada paquete tuviese duración de un slot. La frecuencia de salto viene determinada por el reloj del maestro en ese momento, tal y como marca la siguiente figura. Enlace físicos Figura 11.4 Paquetes multi-slot. Existen dos tipos diferentes de enlace físico en banda base: SCO 23 y ACL 24 que pueden ser multiplexados en el mismo enlace RF. El enlace SCO es simétrico punto a punto entre un maestro y un esclavo. El maestro mantiene el enlace SCO mediante el uso de slots reservados para intervalos regulares. El enlace SCO normalmente lleva la información de voz, aunque puede llevar una combinación de audio y datos. El maestro puede soportar hasta tres enlaces SCO 23 conexión orientada síncrona 24 no orientada asíncrona Pág. 199

210 simultáneos, mientras que los esclavos pueden soportar dos o tres enlaces SCO. Los paquetes SCO usan transmisión de 64 Kbps. El enlace ACL es un enlace punto-multipunto entre el maestro y todos los esclavos. En los slots no reservados para los enlaces SCO, el maestro puede establecer un enlace ACL para cualquier esclavo, incluyendo el esclavo listo en un enlace SCO. Sólo podemos tener un enlace sencillo ACL. El modo ACL se usa únicamente para transmitir datos y se aplica retransmisión. Paquetes Formato de los paquetes del protocolo BaseBand: Figura 11.5 Formato de los paquetes BaseBand. Código de acceso: 72 bits si va precedido de la cabecera y en caso contrario 68 bits. Se utiliza para sincronización, compensación e identificación. Se compone de un preámbulo para compensar el offset, una palabra de sincronización y un campo trailer que se añade si le sigue la parte de cabecera. Cabecera del paquete: ejerce funciones de control de enlace con 6 ampos: - AM_ADDR: dirección temporal de 3 bits de los dispositivos activos dentro de una piconet asignada por el maestro, siendo 000 la de broadcast. - TYPE: distingue los tipos de paquete y su interpretación depende de si el enlace es SCO o ACL. También indica los slots que va a ocupar el paquete. - FLOW: para control de flujo. Si es 0 se deja de transmitir. Pág. 200

211 - ARQN: bit de asentimiento. Si es 1 es un ACK, y con 0 un NAK. - SEQN: bit que se va invirtiendo para evitar retransmisiones en el receptor. - HEC: palabra generada para comprobar la integridad de la cabecera. Payload: datos. Corrección de errores Bluetooth define tres tipos de esquemas de corrección de errores: FEC tasa 1/3, donde cada bit se repite tres veces. FEC tasa 1/2, donde se usa un polinomio generador para codificar. Método ARQ, donde se transmite un paquete hasta que se recibe un acuse de recibe o se exceda de un límite de tiempo. Bluetooth emplea acuses de recibos rápidos y no numerados donde hay acuses de recibos positivos y negativos estableciendo valores ARQN adecuados. Si se excede el contador, Bluetooth marca el paquete y continúa con el siguiente. Canales lógicos Tiene cinco canales lógicos para transferir diferentes tipos de información: 1) Canal LC 25 Información de control a nivel de enlace como ARQ, control de flujo. Cada paquete lleva un canal LC sobre su cabecera, a excepción del paquete ID que no posee cabecera. 2) Canal LM 26 Información de control que se intercambian los gestores de enlace del maestro y el esclavo. Típicamente este canal usa paquetes DM protegidos. 25 Link Control 26 Link Manager Pág. 201

212 3) Canal UA 27 Transporta datos de usuario asíncronos transparentes correspondientes al protocolo L2CAP. 4) Canal UI 28 Transporta datos de usuario isócronos transparentes, y es soportado por los paquetes de comienzo de temporización en los niveles más altos. 5) Canal US 29 Transporta los datos de usuario síncronos transparentes. Este canal se hace corresponder con un enlace SCO. Rutinas de transmisión y recepción Antes de que la información del usuario se mande a través del interfaz aire, se realizan unas manipulaciones en los bits de la cabecera y en el payload con el fin de incrementar la calidad final y la seguridad. En la cabecera se debe generar la redundancia de cabecera (HEC), realizar el blanqueo y la codificación HEC. En los datos se puede llevar a cabo un CRC junto con el cifrado y blanqueo de los datos, para volver a codificarlos. Todas las operaciones menos la de blanqueo, son optativas. El blanqueo consiste en la generación de un polinomio al que se le hace un x-or con la cabecera y el payload de manera que se minimiza el offset DC que se pueda producir en el paquete al convertir los patrones altamente redundantes en aleatorios. La rutina de transmisión se realiza de manera separada para el enlace ACL (el maestro tiene un buffer para cada esclavo) y el SCO (varios buffers por cada esclavo). 27 User Asynchronous data 28 User Isochronous data 29 User Synchronous data Pág. 202

213 Tanto el buffer ACL como el SCO consta de dos registros FIFO. Uno puede ser accedido y leído por el controlador de Bluetooth para componer los diferentes paquetes mientras que el otro registro tan sólo puede ser accedido por LMP para cargar nueva información. La rutina de recepción también se realiza de manera separada para los enlaces ACL y SCO. Para el ACL solamente existe un buffer de recepción que es compartido por todos los esclavos, mientras que para el SCO se utilizan uno o más buffers. El buffer ACL consiste en dos registros FIFO, uno al que puede acceder y cargar la información el controlador de Bluetooth para acceder al payload, y otro registro, únicamente accesible por LMP para leer la información previa al payload. Por su parte, el buffer SCO consta de dos registros FIFO, uno de los cuales se llena de información de voz, mientras que el otro registro sólo puede acceder a la unidad de procesado de voz. Modos de conexión Hay cuatro modos de descubrir un dispositivo Bluetooth: Active: La unidad Bluetooth participa activamente en el canal. El maestro planifica la transmisión basada en las demandas de tráfico desde y hacia los esclavos. Se soportan transmisiones regulares para mantener a los esclavos sincronizados al canal. Los esclavos activos escuchan esperando paquetes. Si un esclavo activo no es direccionado, podría dormir hasta la próxima transmisión del nuevo maestro. Park: En el modo aparcado un dispositivo se encuentra aún sincronizado a la piconet, pero no participa en el tráfico. Los dispositivos han abandonado sus direcciones MAC y ocasionalmente escuchan el tráfico del maestro para volverse a sincronizar y comprobar los mensajes broadcast. Tiene el ciclo de trabajo más corto de los tres modos de ahorro de energía, que son el park, sniff y hold. Sniff: Un dispositivo esclavo escucha la piconet a una tasa reducida, disminuyendo así su ciclo de trabajo. El intervalo SMIFF es programable Pág. 203

214 y depende de la aplicación. Tiene el mayor ciclo de vida de los tres modos de ahorro de energía. Hold: El maestro puede poner a los esclavos en modo hold, en el cual sólo está funcionando un contador interno. Los esclavos también pueden pedir que se active este modo. En cuanto se abandona el modo la transferencia de datos se reanuda de forma instantánea. Tiene un ciclo de trabajo intermedio entre los tres modos de ahorro de energía. Direccionamiento Hay cuatro posibles tipos de direcciones para cada terminal. La dirección básica viene dada por BD_ADDR, secuencia de 48 bits para identificar de forma única un dispositivo. Se divide en 3 partes y nos permite usar 232 direcciones: LAP 30 : 24 bits UAP 31 : 12 bits NAP 32 : 12 bits Figura 11.6 BD_ADDR Además de la dirección BD_ADDR a cada dispositivo se le puede asignar una de las siguientes: AM_ADDR: Dirección de miembro (3 bits). Se asigna si el esclavo dentro de una piconet se encuentra activo. PM_ADDR: Dirección de miembro aparcado (8bits). Se asigna si el esclavo se encuentra en modo aparcado. AR_ADDR: Dirección de Acceso Requerida. Asignación cuando el esclavo entra en modo aparcado y determina la segunda mitad del slot de ventana de acceso para mandar mensajes de petición. Procedimientos de acceso 30 Lower Address Part 31 Upper Address Part 32 Non-significant Address Part Pág. 204

215 Para establecer nuevas conexiones se utilizan los procedimientos de acceso que son los de búsqueda o paging y los de pregunta o inquiry. Si no se conoce nada sobre el dispositivo remoto debe seguirse tanto el procedimiento inquiry como el de paging. Si se conocen algunos detalles del dispositivo remoto sólo será necesario el procedimiento de paging. Búsqueda (Paging): Pregunta por la dirección de un dispositivo Bluetooth con el que queremos establecer la conexión. En este caso el conocimiento del reloj acelerará el proceso y la unidad que lo inicie será el maestro de la piconet. El maestro, para intentar capturar al esclavo, como sus relojes no están sincronizados, transmite el DAC 33 del esclavo en diferentes frecuencias de salto y escucha entre los diversos intervalos de transmisión hasta recibir respuesta del esclavo. Tras mandar el mensaje de respuesta, el esclavo está activado y espera hasta la llegada de un paquete FHS 34, respondiendo con un ACK a la vez que cambia el código de acceso del canal y su reloj, tomando los del maestro incluidos en el paquete FHS. El esclavo establece la conexión usando para ello el reloj y la BD_ADDR del maestro para determinar la secuencia de salto del canal y el código de acceso. Una vez que el maestro ha enviado su paquete FHS, espera el ACK del esclavo y paraliza su reloj para permitir la correcta sincronización. Si no recibe ninguna respuesta vuelve a transmitir el FHS con el reloj actualizado. Con el ACK maestro entra en modo de conexión establecida y usa su BD_ADDR para cambiar a una nueva secuencia. Pregunta (Inquiry): se usa en aplicaciones donde la dirección del dispositivo remoto se desconoce. El transmisor recolecta las direcciones y los relojes de los dispositivos de todas las unidades que respondan al mensaje de pregunta, pudiendo luego, si lo desea, establecer la conexión por el procedimiento anterior. El mensaje de pregunta no contiene ningún tipo de información, aunque puede indicar la clase de dispositivos que deben responder. Existe 33 Device Access Code 34 Frequency Hop Synchronization Pág. 205

216 GIAC 35 para preguntar por algún tipo de dispositivo en especial, y DIAC 36 para tipos de dispositivos. Una unidad que quiera descubrir un determinado dispositivo entra en el subestado de pregunta, y continuamente transmite el mensaje GIAC en diferentes frecuencias de salto. La secuencia de saltos está determinada en el LAP del GIAC, incluso cuando se utilizan los DIAC. Un terminal que quiera ser descubierto, cada cierto tiempo entrará en el estado de escaneo de pregunta para responder a estos mensajes. Para la operación de pregunta, sólo va a existir respuesta por parte del esclavo, mientras, el maestro escucha las diferentes respuestas, pero nada más leer una respuesta continua escaneando. En el caso de que exista contienda entre diferentes dispositivos, éstos, al no recibir respuesta del maestro, esperan un número aleatorio de slots y se mantienen a la escucha de un nuevo mensaje de pregunta. El mensaje de respuesta consiste en un paquete FHS que tiene los parámetros del dispositivo LMP: LINK MANAGEMENT PROTOCOL Responsable de: Establecer el enlace entre dispositivos Bluetooth. Aspectos de seguridad como autenticación y cifrado mediante la generación, cambio y comprobación de unas claves de cifrado. Control del tamaño de los paquetes. Control de la potencia y los ciclos de trabajo en la transmisión radio. Supervisión de la temporización de enlace. Control de la calidad de servicio (QoS). Conmutación maestro-esclavo Los mensajes LMP se transfieren en el campo payload y se distinguen de L2CAP gracias al valor del campo L_CH en la cabecera de los datos. Estos mensajes LMP son filtrados e interpretados por el LM 37 en el extremo receptor y no se propagan a capas más altas. 35 un código de acceso de pregunta 36 una serie de códigos de acceso de pregunta dedicados 37 Gestor de Enlace Pág. 206

217 Figura 11.7 Gestores de Enlace comunicándose mediante LMP. Los mensajes del LM tienen mayor prioridad que los datos de usuario, es decir, que si la entidad LM necesita enviar un mensaje, no deberá retrasarse debido al tráfico L2CAP, aunque podría retrasarse en el caso de que tuviéramos numerosas retransmisiones de paquetes BaseBand. Según las especificaciones, LC nos debe proporcionar un enlace fiable. El tiempo entre la recepción de un paquete BaseBand que lleva una PDU LMP y el envío de un paquete que lleve una PDU de respuesta debe ser menor que el valor del temporizador de respuesta que está establecido en 30 segundos. Formato de LMP Las PDUs LM son siempre enviadas como paquetes de un único slot, y la cabecera de datos es de 1 byte, siendo los dos bits menos significativos (L_CH) los que determinan el canal. Figura 11.8 Cabecera de datos paquete slot simple. El bit de FLOW siempre se pone a 1 y es ignorado en el extremo receptor. Cada una de las PDUs LM tiene asignado un código de operación de 7 bits que se usa Pág. 207

218 para identificar de forma unívoca los diferentes tipos de PDUs. Este código de operación y un identificador de transacción de longitud un bit van en el primer byte del campo payload (este bit de transacción va en el LSB). Bit de transacción = 0 La PDU corresponde a una transacción iniciada por el maestro. Bit de transacción = 1 Transacción iniciada por el esclavo. Figura 11.9 Campo payload de las PDUs LM. Si la PDU contiene uno o más parámetros se colocan en el campo payload comenzando por el segundo byte. El número de bytes usados depende de la longitud de los parámetros. Si un enlace SCO está presente usando paquetes HV1 y la longitud del campo content es menor de 9 bytes, las PDUs se pueden transmitir en paquetes DV. En caso contrario, se usarán paquetes DM1. Todos los parámetros tienen formato littleendian, es decir, el byte menos significativo es el primero que se transmite. No todas las PDUs son obligatorias, sino que existe un conjunto de éstas que son opcionales. En este caso, la entidad LM no tiene por qué ser capaz de transmitir una PDU opcional. Debe reconocer todas las PDUs opcionales que reciba, y si se requiere respuesta, responder de acuerdo a los procedimientos indicados en las especificaciones. El destino y origen de una PDU se determinan gracias a la dirección AM_ADDR, se trata de 3 bits que indican el número de esclavo activo dentro de la piconet. Pág. 208

219 Procedimientos LMP LMP realiza un elevado número de procedimientos relacionados con la gestión de las piconets y la seguridad. Cada procedimiento específico posee sus propias PDUs, que son intercambiadas entre las dos entidades LM. Figura Intercambio de PDUs entre entidades LM. Las líneas discontinuas indican PDUs opcionales y las continuas PDUs obligatorias. La especificación de Bluetooth realiza un listado de todos los procedimientos con el correspondiente diagrama de intercambio de PDUs entre las entidades LM. Los procedimientos estructurados de LMP son: 1. Autenticación. 2. Pairing Cambio de la clave de enlace. 4. Cambio de la clave de enlace actual. 5. Cifrado. 6. Petición del offset del reloj. 7. Información del offset de slot. 8. Petición de información de temporización. 9. Información de la versión LMP. 38 proceso mediante el cual dos dispositivos intercambian una clave privada para el encriptado. Pág. 209

220 10. Información de las características soportadas. 11. Conmutación del papel esclavo-maestro. 12. Petición de nombre. 13. Desconexión. 14. Control de potencia. 15. Petición modo hold. 16. Petición modo sniff. 17. Petición modo park. 18. Petición calidad de servicio. 19. Establecimiento enlaces SCO. 20. Control de paquetes multi-slot. 21. Supervisión del enlace. Existen unos mensajes genéricos de respuesta, constituidos por las PDUs LMP_accepted y LMP_not_accepted, usados como respuesta para la mayoría de los procedimientos listados. La PDU LMP_accepted incluye el código de operación del mensaje, mientras que la PDU LMP_not_accepted debe incluir, además del código de operación la razón por la cual ha sido rechazado. Establecimiento de conexión Después de que se ha realizado un procedimiento de búsqueda o paging, el maestro debe realizar polling 39 del esclavo enviándole paquetes POLL o NULL (el intervalo máximo de polling está establecido en 40, pero en las especificaciones no dejan claro en qué subunidad de segundo está expresado). 39 comprobación periódica del estado. Pág. 210

221 Figura Establecimiento de conexión. Cuando el dispositivo que inicia la búsqueda y desea crear una conexión, envía una primitiva LMP_host_connection_req. El otro extremo recibe el mensaje y obtiene información sobre la conexión que se va a abrir. El dispositivo remoto puede aceptar o rechazar esa petición de conexión mediante el envío de una primitiva LMP_accepted o LMP_not_accepted, respectivamente. Cuando un dispositivo ya no necesita realizar más establecimientos de enlace, envía la primitiva LMP_setup_complete, pero sigue respondiendo a las peticiones que le lleguen del otro extremo. Cuando el otro dispositivo vea que ya ha completado el establecimiento de enlace, nos envía igualmente la primitiva LMP_setup_complete. Después de esto, se procederá a la transmisión de los paquetes de los diferentes canales lógicos que emplea LMP L2CAP: LOGICAL LINK CONTROL AND ADAPTION PROTOCOL Características generales Este protocolo se encarga de adaptar los protocolos de niveles superiores al protocolo BaseBand. Trabaja en paralelo con LMP, ofreciendo servicios a niveles superiores e incluso cuando no se transfieren datos a LMP. Pág. 211

222 Proporciona servicios orientados y no orientados a conexión con capacidades de multiplexación, segmentación y reensamblaje de paquetes de hasta 64 Kbytes de longitud. Figura Localización de L2CAP en la torre de protocolos. Recordemos que en el protocolo BaseBand se habían definido dos tipos de enlaces: SCO (voz y datos) y ACL (datos). L2CAP se define sólo para enlaces ACL. En estos enlaces, se prohíbe el uso de paquetes AUX1, un tipo de paquete que no soporta CRC. Debido a que L2CAP depende de las comprobaciones de integridad en el protocolo BaseBand para proteger la información transmitida, los paquetes AUX1 nunca se deberán usar para transportar paquetes L2CAP. El protocolo L2CAP se basa en los siguientes supuestos: El único enlace ACL que puede existir entre dos dispositivos se establece mediante el protocolo LMP, y BaseBand provee un reparto ordenado de los paquetes de datos, pudiendo existir duplicados y paquetes dañados. BaseBand provee la impresión de una comunicación full-dúplex, lo que no implica que todas las comunicaciones L2CAP sean bidireccionales. L2CAP provee un canal fiable usando los mecanismos de BaseBand. Pág. 212

223 Paquetes La figura nos muestra el formato de la cabecera de los paquetes ACL, tanto para paquetes de un único slot como para paquetes multi-slot: Figura Cabecera paquetes ACL. La única diferencia entre ambos paquetes se encuentra en la longitud del campo length, y para distinguirlos se emplea una cabecera de tipo paquete a nivel de cabecera BaseBand. L_CH: distingue los paquetes L2CAP de los paquetes LMP. La codificación es la siguiente: Código L_CH Canal lógico Información 00 Reservado Reservado para uso futuro 01 L2CAP (UA/I) Continuación de un paquete L2CAP 10 L2CAP (UA/I) Comienzo de un paquete L2CAP 11 LMP (LM) Paquete LMP Tabla 11.7 Campo L_CH Pág. 213

224 FLOW: campo gestionado por el LC 40, una entidad implementada en BaseBand. Si se encuentra a 1, flujo activado, y si es 0, flujo desactivado, para el caso en que ya no se vaya a enviar más tráfico por el enlace ACL. Requisitos y funcionalidades L2CAP L2CAP se encuentra por encima del protocolo BaseBand y actúa como interfaz con otros protocolos de comunicación. Los canales de voz para aplicaciones de audio y telefonía corren sobre enlaces BaseBand SCO, mientras que los datos de audio en paquetes, como voz sobre IP, pueden ser enviados usando protocolos de comunicación que corran sobre L2CAP. Figura Interfaz L2CAP con resto de protocolos. Los requisitos esenciales para L2CAP incluyen simplicidad y que tenga bajo overhead. Las implementaciones de L2CAP deben ser aplicables a dispositivos que tengan una limitación razonable de recursos computacionales. L2CAP no debería consumir excesiva potencia ya que esto supondría un malgasto de la eficiencia en potencia que se había logrado con el módulo de Bluetooth Radio. Además, se debe intentar minimizar la memoria que use este protocolo. Las principales funciones realizadas por L2CAP son las siguientes: 40 Controlador de Enlace Pág. 214

225 Multiplexación de protocolos: L2CAP debe soportar multiplexación de protocolos, debido a que el protocolo BaseBand no soporta ningún campo de tipo que identifique las capas altas de protocolos. L2CAP debe ser capaz de distinguir entre los protocolos de capa superior SDP, RFCOMM y TCS. Segmentación y ensamblaje: En comparación con otros medios físicos cableados, los paquetes de datos definidos por el protocolo BaseBand están limitados en tamaño. Exportar una MTU 41 asociada con el mayor número de datos BaseBand (341 bytes) limita el uso eficiente del ancho de banda para protocolos de capa superior que han sido diseñados para usar paquetes de tamaño grande. Los paquetes grandes L2CAP deben ser segmentados en paquetes BaseBand más pequeños antes de que sean transmitidos por el interfaz aire. Por lo tanto, los múltiples paquetes BaseBand que sean recibidos deben ser ensamblados en un paquete L2CAP siguiendo una simple comprobación de integridad. La segmentación y ensamblaje son necesarios para poder soportar otros protocolos que usen paquetes más grandes que los soportados por BaseBand. Calidad de servicio: El proceso de establecimiento de una conexión L2CAP permite el intercambio de información teniendo en cuenta la calidad de servicio (QoS) esperada entre dos unidades Bluetooth. Cada implementación L2CAP debe monitorizar los recursos usados por el protocolo y asegurarse de que la QoS contratada se cumple. Grupos: Muchos protocolos incluyen el concepto de un grupo de direcciones. El protocolo BaseBand soporta el concepto de piconet, un grupo de dispositivos que realizan juntos saltos de frecuencia sincronizadamente usando el mismo reloj. La abstracción de grupo L2CAP posibilita implementaciones para asociar grupos de protocolos con piconets. Sin una abstracción de grupo, los protocolos 41 Maximum Unit Transmission Pág. 215

226 de niveles superiores necesitarían solicitar al protocolo BaseBand el poder manejar sus grupos eficientemente, cosa que hace L2CAP como intermediario. Los siguientes objetivos quedan fuera de L2CAP: No ofrece transporte de audio para enlaces SCO. No implica un canal fiable o asegura la integridad de los datos. No soporta un canal multicast fiable ni nombre de grupo global. CID: identificadores de canal La forma de operar de L2CAP se basa en el concepto de canales. Cada uno de los puntos terminales de un canal L2CAP se denomina identificador de canal. Los identificadores de canales son nombres locales que representan un canal lógico (32 bits). El mismo CID no puede reutilizarse como un canal local L2CAP para múltiples canales simultáneos L2CAP entre un dispositivo local y uno remoto. La siguiente tabla muestra los CIDs que se pueden usar. CID Descripción CID Descripción 0x0000 0x0001 0x0002 0x0003-0x003F 0x0040-0xFFFF Identificador nulo Canal de señalización Canal de recepción CL Reservado Asignación dinámica Tabla 11.8 Descripción CIDs. La asignación del CID es relativa a un dispositivo particular y un dispositivo puede asignar CIDs independientemente de otros dispositivos (a menos que necesite usar algunos de los CIDs reservados que aparecen en la tabla). Pág. 216

227 SDP: SERVICE DISCOVERY PROTOCOL Características generales Este protocolo se encarga de descubrir qué servicios están disponibles y determinar las características de dichos servicios. El descubrimiento de servicios en el entorno Bluetooth, donde el conjunto de servicios que están disponibles cambia dinámicamente basándose en la proximidad de los dispositivos en movimiento, es diferente del existente en los entornos de red tradicionales. El protocolo deberá desarrollar las siguientes funcionalidades de acuerdo a las especificaciones de la versión 1.0b: SDP debe proporcionar a los clientes la capacidad de buscar servicios basados en atributos específicos. SDP debe permitir que los servicios sean descubiertos basándose en la clase de servicio. SDP debe ser capaz de realizar una navegación a través de los servicios sin necesidad de tener conocimientos de las características específicas de dichos servicios. SDP debe proporcionar el medio de descubrir nuevos servicios que vayan a estar disponibles cuando los dispositivos entren en un área de proximidad RF con un dispositivo cliente. SDP debe proporcionar un mecanismo para determinar cuando un servicio pasa al estado de indisponibilidad cuando los dispositivos abandonen esa área RF de proximidad de un dispositivo cliente. SDP debe suministrar los servicios, clases de servicio y atributos de servicios para conseguir una identificación de forma única. SDP debe permitir a un cliente en un dispositivo, descubrir un servicio en otro dispositivo sin tener que consultar un tercer dispositivo. Pág. 217

228 La implementación de SDP debe ser tal que nos permita usarlo en dispositivos de complejidad limitada. SDP debe suministrar un mecanismo para descubrir información de forma gradual sobre los servicios que nos ofrezca un dispositivo. Así, se pretende minimizar la cantidad de datos que deben ser intercambiados para que un cliente pueda determinar si un determinado servicio no le es necesario. SDP debe soportar agentes intermediarios que mejoren la velocidad o eficiencia del proceso de descubrimiento. SDP debe ser independiente del protocolo de transporte, y por tanto si usamos L2CAP como tal, SDP debe funcionar perfectamente. SDP debe permitir el descubrimiento y uso de servicios que proporcionen acceso a otros protocolos de descubrimiento de servicios. SDP debe soportar la creación y definición de nuevos servicios sin que se necesite registrarse en una autoridad central. Todas las funcionalidades descritas están reconocidas por el grupo SIG en la versión 1.0. Interacción SDP cliente-servidor El mecanismo de descubrimiento de servicios proporciona a las aplicaciones cliente un medio de descubrir la existencia de los servicios ofrecidos por aplicaciones servidoras, y también conocer cuáles son los atributos de dichos servicios. Los atributos son importantes ya que nos indican el tipo o clase de servicio ofrecido y la información necesaria para poder utilizar dicho servicio. Pág. 218

229 Figura Interacción cliente-servidor Como se puede observar en la figura, SDP implica comunicación entre un servidor SDP y un cliente SDP. El servidor mantiene una lista de servicios que describe las características de los servicios asociados con dicho servidor. Cada registro de servicio contiene información sobre un dispositivo único. Un cliente puede recuperar información de un registro de servicio que mantiene el servidor SDP mediante una PDU de petición SDP. Si el cliente, o una aplicación asociada con el cliente, deciden usar un servicio, deben abrir una conexión separada con el proveedor de servicio. Existe un máximo de un servidor SDP por dispositivo Bluetooth (si un dispositivo Bluetooth actúa solamente como cliente, no necesita servidor SDP). Un dispositivo Bluetooth puede funcionar tanto como cliente SDP como servidor SDP. Si múltiples aplicaciones en un dispositivo proporcionan servicios, un servidor SDP puede actuar en nombre de los proveedores de servicios para manejar peticiones de información sobre los servicios. De forma similar, múltiples aplicaciones clientes pueden utilizar un cliente SDP que actúe en su nombre para poder realizar las peticiones al servidor. El conjunto de servidores DSP que están disponibles para un cliente SDP cambia dinámicamente de acuerdo a la proximidad RF de éstos al cliente. Cuando el servidor se Pág. 219

230 encuentra disponible, esto se debe notificar al potencial cliente para indicarle que use SDP y pregunte al servidor por sus servicios. De forma similar, cuando el servidor se aleja y deja de estar disponible, no hay notificación vía SDP. Sin embargo, el cliente puede seguir usando SDP para hacer peticiones y podrá deducir que el servidor no está disponible si ya no responde a dichas peticiones RFCOMM Características generales El protocolo RFCOMM proporciona emulación de los puertos serie sobre el protocolo L2CAP. Se basa en el estándar ETSI TS 07.10, tomando de éste un subconjunto con las partes más relevantes y realizando algunas adaptaciones. RFCOMM es simplemente un protocolo de transporte con elementos adicionales para la emulación de los 9 circuitos de los puertos serie RS-232 (EIATIA-232-E). Soporta hasta 60 conexiones simultáneas entre dos dispositivos Bluetooth. El número de conexiones que pueden ser usadas simultáneamente en un dispositivo Bluetooth es específico de la implementación. Para los propósitos de RFCOMM, un camino completo de comunicaciones implica dos aplicaciones ejecutándose en dispositivos diferentes (puntos terminales de la comunicación) con un segmento de comunicación entre ellos. La siguiente figura ilustra este concepto. Hay que tener en cuenta que el término aplicación, puede tener significados distintos al de aplicación final del usuario, pudiendo corresponder, por ejemplo, a protocolos de capas altas u otros servicios que actúen en nombre de las aplicaciones de usuario. Figura Camino de comunicación RFCOMM. Pág. 220

231 RFCOMM pretende cubrir aplicaciones que usen los puertos serie de los dispositivos en los que residen. En una configuración simple, el segmento de comunicación es un enlace Bluetooth entre un dispositivo y otro (conexión directa), como se observa en la figura: Figura Conexión directa RFCOMM (interfaz radio) En aquellos casos en los que el segmento de comunicación sea otra red, se usa Bluetooth para el camino entre un dispositivo y otro de conexión de red, como un módem. RFCOMM sólo se ocupa de la conexión entre los dispositivos en el caso de que ésta sea directa, o entre el dispositivo y un módem en el caso de una red. Sin embargo, RFCOMM puede soportar otras configuraciones, tales como módulos que se comuniquen vía Bluetooth por un extremo y que estén provistos de un interfaz cable en el otro extremo, como se muestra en la figura (en realidad, estos dispositivos no son módems pero ofrecen un servicio similar). Figura RFCOMM con interfaz radio y cable en los extremos. Básicamente, nos encontramos con dos tipos de dispositivos: Tipo 1: Se trata de puntos terminales de comunicación, como ordenadores e impresoras. Pág. 221

232 Tipo 2: Son aquellos que forman parte de un segmento de comunicación, como por ejemplo, los módems. RFCOMM no hace distinción entre ambos tipos, pero el acomodarse a ellos tiene sus consecuencias en el protocolo. Por lo tanto, la transferencia de información entre dos entidades RFCOMM se define tanto para los dispositivos tipo 1 y 2. Una parte de la información sólo se necesitará para el segundo tipo, mientras que otra se pretende que sea usada por ambos. Debido a que un dispositivo no es consciente del tipo del otro dispositivo en el camino de comunicación, cada uno debe pasar toda la información disponible especificada por el protocolo. La ordenación de bytes utilizada, es la descrita en la especificación TS 07.10: todos los números binarios se encuentran ordenados desde el LSB 42 hasta el MSB 43, leídos de izquierda a derecha. Como ya hemos indicado, RFCOMM emula puertos serie RS-232. La emulación incluye la transferencia de circuitos sin datos, y posee un esquema para la emulación de módem nulo. Se soporta la emulación de múltiples puertos serie tanto entre dos dispositivos como entre múltiples dispositivos. Además, en el caso en que tengamos un determinado régimen binario para los datos en un puerto determinado, el protocolo RFCOMM no va a afectar a éste. 42 bit menos significativo. 43 bit más significativo. Pág. 222

233 Señales de control RS-232 Los 9 circuitos de un interfaz RS-232 que son emulados, son los siguientes: Pin Nombre de circuito 102 Signal Common 103 Transmit Data (TD) 104 Received Data (RD) 105 Request to Send (RTS) 106 Clear to Send (CTS) 107 Data Set Ready (DSR) 108 Data Terminal Ready (DTR) 109 Data Carrier Detect (CD) 125 Ring Indicator (RI) Tabla 11.9 Circuitos RS-232 emulado en RFCOMM. Emulación de módem nulo Cuando se tienen que transferir los estados de circuitos (pines) sin datos, TS no distingue entre dispositivos DTE y DCE. En ese caso, las señales de control RS-232 son enviadas como un número de señales DTE/DCE independientes. RTC RTC IC DV Señales TS Correspondientes señales de control RS-233 DSR, DTR RTS, CTSD IR DCD Tabla Señales de control TS puerto serie La forma en que TS transfiere las señales de control RS-232 crea implícitamente un módem nulo cuando dos dispositivos de la misma clase se conectan juntos. En la siguiente figura se muestra el módem nulo en el caso de que dos DTE se conecten vía RFCOMM. Pág. 223

234 Figura Emulación de módem nulo. Emulación de múltiples puertos serie Entre dos dispositivos: Dos dispositivos Bluetooth usando RFCOMM en su comunicación pueden abrir múltiples puertos serie. RFCOMM soporta hasta 60 puertos emulados abiertos, aunque esto es fuertemente dependiente de la implementación específica. El DLCI 44 será el encargado de identificar la conexión entre una aplicación cliente y una servidora. El DLCI se representa con 6 bits pero su rango útil es [2,61], debido a que en TS DLCI=0 es el canal de control dedicado, DLCI=1 no es útil y DLCI=62-63 se encuentran reservados. El DLCI es único para una sesión RFCOMM establecida entre dos dispositivos. Para tener en cuenta que tanto la aplicación cliente como la servidora pueden residir en ambos lados de una sesión RFCOMM, con clientes en cualquier extremo realizando conexiones independientes, el valor del DLCI se divide entre los dos dispositivos que se comunican. 44 Identificador de Conexión de Datos de Enlace. Pág. 224

235 Figura Múltiples puertos serie emulados. Con múltiples dispositivos Bluetooth: Si un dispositivo Bluetooth soporta emulación de múltiples puertos serie y las conexiones realizadas son con puntos terminales en diferentes dispositivos Bluetooth, entonces la entidad que implementa RFCOMM debe ser capaz de correr múltiples sesiones TS multiplexadas, cada una con su propio identificador de canal L2CAP. Esta capacidad de multiplexación es un elemento opcional a la hora de implementar RFCOMM, según la Especificación de Bluetooth. Figura Emulando puertos serie para múltiples dispositivos Bluetooth. Pág. 225

236 TCS BINARY: TELEPHONY CONTROL PROTOCOL Características generales Este protocolo se encuentra basado en la recomendación ITU-T Q , y en especial hace uso del anexo D de dicha recomendación. La Especificación de Bluetooth pretende introducir el menor número de cambios posibles para poder reutilizar al máximo la recomendación Q.931. En la siguiente figura se muestra la ubicación de TCS dentro de los niveles medios y bajos de la torre de protocolos Bluetooth, donde es necesario diferenciar entre la parte que origina la llamada y la parte en que ésta es terminada. Figura TCS dentro de la pila de protocolos Bluetooth. El protocolo TCS realiza las siguientes funciones: Control de llamada (CC): señalización para el establecimiento y liberación de las llamadas de voz y datos entre dispositivos Bluetooth. Gestión de grupos (GM): señalización para facilitar el manejo de grupos de dispositivos Bluetooth. TCS no orientado a conexión (CL): intercambio de información de señalización que no esté relacionada con llamadas entrantes. 45 Este protocolo es definido para la señalización en accesos ISDN básico. Pág. 226

237 Operación entre dispositivos TCS usa señalización punto-punto y puede usar punto-multipunto. La señalización punto-punto se usa cuando se conoce en qué lado (dispositivo Bluetooth) se necesita establecer una llamada. La señalización punto-multipunto se puede usar cuando hay más de un dispositivo disponible para establecer una llamada. Como ejemplo de esto último, podemos citar el caso en el que para una llamada entrante la estación base necesite alertar a todos los móviles que se encuentren en su área de cobertura. La señalización punto-punto se traduce en un canal L2CAP orientado a conexión, mientras que en el caso punto-multipunto es con un canal L2CAP también, pero no orientado a conexión, el cual es enviado como información de broadcast en la piconet. A continuación, se muestra un caso de señalización punto a punto para llamadas tanto de voz como de datos. En primer lugar, se notifica la petición de llamada al dispositivo llamado usando un canal de señalización punto a punto (A). Después, este canal de señalización se empleará para establecer el canal de voz o datos (B). Figura Señalización en una configuración punto a punto. Ahora ilustraremos cómo se usa la señalización punto-multipunto y la punto a punto para establecer una llamada de datos o voz en una configuración multipunto. Primero, se notifica a todos los dispositivos de la petición de llamada usando canales de señalización punto-multipunto (A). Entonces, cada uno de los dispositivos contesta en Pág. 227

238 un canal de señalización punto a punto (B), y este canal será usado más tarde para establecer el canal de voz o datos (C). Figura Señalización en una configuración punto-multipunto. Operación entre capas Las implementaciones TCS deben seguir la siguiente arquitectura genérica: Figura Arquitectura TCS. Pág. 228

239 La estructura interna de TCS Binary contiene las entidades funcionales CC 46, GM 47 y CL 48, complementadas con el Protocolo de Discriminación el cual se encarga de canalizar el tráfico a la entidad funcional adecuada. Para manejar varias llamadas simultáneamente, pueden existir a la vez múltiples instancias TCS Binary. La discriminación entre estas instancias se basa en el identificador de canal L2CAP. TCS Binary presenta interfaces con otras entidades Bluetooth, para proporcionar sus servicios a las aplicaciones. La información que se intercambia a través de los interfaces tiene los siguientes propósitos: A: La entidad CC proporciona información para controlar la sincronización de la conversación, en especial cuando se establecen o se liberan los canales de voz. Esta información está basada en mensajes de control de llamada (ejemplos: CONNECT ACKNOWLEDGE, DISCONNECT, etc.). B: Este interfaz se usa para enviar un mensaje de SETUP al protocolo L2CAP, usando señalización punto-multipunto en un canal no orientado a conexión. L2CAP utilizará este interfaz para informar a TCS que dicho mensaje de SETUP ha sido recibido en su canal no orientado a conexión. C: Interfaz para el envío de mensajes TCS en canales orientados a conexión. Durante el establecimiento de un canal se tiene que indicar cuál va a ser la calidad de servicio específica que se va a usar en la conexión, y en particular si se van a usar modos de bajo consumo (L2CAP informará de esto a LMP) D: La entidad CC controla directamente LMP para establecer y liberar enlaces SCO. E, G: La entidad GM controla los protocolos LMP y LC/BandaBase durante la inicialización de los procedimientos de búsqueda (paging), pregunta (inquiry) e intercambio de clave privada (pairing). 46 Call Control 47 Group Management 48 ConnectionLess Pág. 229

240 HCI: HOST CONTROLLER INTERFACE Introducción HCI proporciona un interfaz uniforme para acceder a las capacidades hardware Bluetooth. En la siguiente figura aparecen las capas SW bajas. El firmware HCI implementa los comandos hardware HCI mediante el acceso a los comandos de gestión a nivel de enlace, a los registros hardware de estado, registros de control y de eventos. Figura Esquema de las capas SW bajas Entre el driver residente HCI y el firmware HCI pueden existir varias capas. Estas capas intermedias son las que proporcionan la capacidad de transferir datos sin tener que conocer éstos perfectamente, es decir, transferencia pura y dura. La figura que aparece a continuación ilustra el camino de una transferencia de datos de un dispositivo Bluetooth a otro. El driver HCI en el host intercambia datos y comandos con el firmware HCI en el hardware Bluetooth. El driver de la capa de transporte proporciona a ambas capas HCI la capacidad de intercambio mutuo de información. Pág. 230

241 Figura Transferencia de datos entre capas SW bajas El host recibirá notificaciones asíncronas de los eventos HCI independientemente de qué capa de transporte se esté usando. HCI usa eventos para notificar al host qué sucede si es muy relevante. Cuando el host descubre que ha ocurrido un evento, chequea el paquete de eventos recibido para poder determinar de qué evento concreto se trata. Bloques hardware Bluetooth La siguiente figura muestra un diagrama de bloques hardware Bluetooth. Tenemos una parte analógica, constituida por Bluetooth radio; y otra digital, el HC 49. A su vez, el HC posee hardware de procesado digital de señal, denominado LC 50, una CPU y necesita unas interfaces con el entorno del host. 49 Host Controller 50 Link Controller Pág. 231

242 Figura Esquemático de la arquitectura hardware Bluetooth. Controlador de enlace (LC) Compuesto por una parte hardware y una software, es el encargado de realizar el procesado bandabase y de implementar los protocolos de capa física, tales como el ARQ y la codificación FEC. Sus funciones más relevantes son las siguientes: Transferencia de acuerdos a los parámetros de calidad de servicio (QoS) seleccionados. Transferencia asíncrona con garantía usando el protocolo faqr 51 implementado sobre hardware. Transferencia síncrona. Codificación de audio. Se realiza una implementación hardware bastante potente de la codificación CVSD 52 a 64 Kbps. También soporta codificación 64Kbps log-pcm. Cifrado. CPU El núcleo CPU permite manejar preguntas y filtrar las peticiones de búsqueda de un dispositivo (paging) sin implicar al host. El HC puede ser programado para contestar determinados mensajes de búsqueda y para autenticar enlaces remotos. El software LM corre en la CPU. El LM descubre otros LMs remotos y se comunica con ellos vía LMP, como ya vimos en la sección dedicada a este protocolo. 51 fast ARQ 52 Continuous Variable Slope Delta Pág. 232

243 Posibles arquitecturas de bus Los dispositivos Bluetooth tienen varias interfaces de bus que pueden ser usadas para conectar con el hardware Bluetooth. Estos buses pueden tener diferentes arquitecturas y diferentes parámetros. HC Bluetooth inicialmente soportará dos de estas arquitecturas, USB y PC Card. a) Arquitectura USB HCI El siguiente diagrama de bloques muestra la conexión Bluetooth al host PC vía USB HCI. USB puede manejar varios canales lógicos sobre el mismo canal físico. Por lo tanto, los canales de voz, datos y control no requieren ningún interfaz físico adicional. Hay que reseñar que en esta arquitectura no hay acceso directo a los registros y memoria del módulo Bluetooth sobre USB, por lo que la comunicación se realiza a través de comandos HCI y de la capa de transporte HCI. Figura11.29 Diagrama de bloques arquitectura USB HCI b) Arquitectura PC Card HCI A diferencia de USB, todo el tráfico entre el host y el módulo Bluetooth va a través del bus PC Card. Las comunicaciones entre el host PC y el módulo Bluetooth se realizan directamente a través de los registros y memoria. Pág. 233

244 Capa de transporte HC Esta capa de transporte se sitúa entre el driver HC y la propia entidad HC. El principal propósito de esta capa es la transparencia, por lo cual no debe importar que el driver HCI corra sobre USB o una PC Card. La gran ventaja que nos presenta la transparencia es la facilidad de actualización del HCI sin que afecte a la capa de transporte. La capa de transporte HC se describe de forma separada para RS232, UART, USB y PC Card. a) Capa de transporte HCI RS232. El objetivo de esta capa es posibilitar el uso del HCI sobre una interfaz física RS232 entre el host Bluetooth y el controlador del host. Figura Función de la capa de transporte HCI RS232. Existen cuatro tipos de paquetes HCI que se pueden enviar a través de la capa de transporte RS232: HCI Command Packet, HCI Event Packet, HCI ACL Data Packet y HCI SCO Data Packet. Los primeros sólo pueden ser enviados hacia controlador del host (HC), los segundos sólo los puede enviar el HC, y los dos últimos tipos pueden ser tanto enviados como recibidos por el HC. Pág. 234

245 Sin embargo, HCI no nos permite diferenciar entre los cuatro tipos de paquetes. Por lo tanto, si los paquetes son enviados a través de una interfaz física común, se tiene que añadir un identificador de paquete HCI, tal y como aparece en la siguiente tabla: Tipo de paquete C Identificador Tipo de paquete HCI HCI Command Packet 0x01 Identificador Paquete HCI HCI ACL Data Packet 0x02 HCI SCO Data Packet 0x03 HCI Event Packet 0x04 Error Message Packet 0x05 Negotiation Packet 0x06 Paquete HC Tabla Identificación paquetes HCI RS232. Como podemos observar, se han añadido a los cuatro tipos básicos dos nuevos tipos para poder soportar la negociación de las características de la comunicación (0x05) y los mensajes de error (0x06). Al identificador de paquete HCI le sigue una secuencia de 8 bits que se incrementa en uno cada vez que se envía un paquete de los tipos arriba indicados, excepto que la retransmisión de paquetes forme parte de un procedimiento de recuperación de errores. Los cuatro primeros tipos de paquetes HCI tienen un campo de longitud que se usa para determinar cuántos bits se espera que tenga el paquete. Los paquetes de mensajes de error y el de negociación son de longitud fija, aunque este último puede extenderse 7 bytes adicionales basándose en un campo de extensión. Figura Paquete básico HCI RS232. Pág. 235

246 b) Capa de transporte HCI UART El principal objetivo de esta capa es posibilitar el uso del HCI sobre una interfaz serie entre dos UARTs en el mismo PCB. Figura Función de la capa de transporte HCI UART. Tenemos nuevamente los cuatro tipos de paquetes básicos de HCI que han de ser diferenciados gracias al identificador de paquete HCI. Sin embargo, no contamos con paquetes de negociación y de mensajes de error (en este caso, esta capa de transporte asume que la comunicación UART está libre de errores) c) Capa de transporte HCI USB Según las especificaciones, es muy recomendable que el dispositivo USB sea de alta velocidad. Nos encontramos con dos interfaces: 1) Interfaz cero: sin opciones de configuración. Envío hacia un punto terminal sin modificar el ancho de banda. 2) Interfaz uno: proporciona un ancho de banda escalable. Tiene cuatro opciones de configuración basadas en los requisitos del ancho de banda. Una trama HCI, consistente en una cabecera y los datos, debe estar presente en una transacción USB, la cual se define como una o más tramas USB que contienen los datos procedentes de una petición IO. Por ejemplo, un paquete de datos ACL que contenga 256 bytes en total se podría enviar sobre el interfaz cero hacia un punto terminal en una petición IO. Esa petición requeriría cuatro tramas USB de 64 bytes y formaría por tanto una transacción. Pág. 236

247 d) Capa de transporte PC Card Bluetooth d.1) Introducción Como hemos visto, el SIG ha definido varias alternativas para que un módulo Bluetooth se pueda conectar a un PC (host): USB, RS232 (cable serie), UART y las Tarjetas PC. Se especifican interfaces estandarizados para USB, RS232 y UART, pero la interfaz con PC Card no está estandarizada. Existen diversas razones por las cuales no se haya definido un estándar, entre las que se encuentra la idea que tiene el SIG de no querer restringir esta tecnología. La siguiente figura muestra los componentes del host Bluetooth y del módulo Bluetooth en los casos de dispositivos USB, RS232 y PC Card, que es la que nos interesa en este subapartado: Figura Capas de transporte USB, RS232 y PC Card. La interfaz superior del minidriver PC Card es la encargada de conectar la capa de transporte al resto de la pila de protocolos SW de Bluetooth. Esta interfaz intercambia información con el driver HC, aunque este driver no tenga conocimiento de qué capa de transporte conecta el host, es decir, le es transparente si el una capa de transporte RS232, USB, UART o PC Card. Pág. 237

248 d.2) Funcionalidad de transporte La capa de transporte PC Card indica y transfiere los diferentes tipos de paquetes HC 53 usando el bus físico desde el host al módulo Bluetooth (PC Card) y viceversa. Así, el extremo receptor es capaz de separar los diferentes tipos de paquetes. La siguiente figura describe este procedimiento. Figura Funcionalidad de la capa de transporte para PC Card. Los tipos de paquetes son los cuatro tipos básicos HCI, ya vistos anteriormente (ver Tabla 15). d.3) Requisitos del minidriver PC Card El objetivo del minidriver Bluetooth PC Card es proporcionar la posibilidad de enviar y recibir los mensajes HCI desde y hacia el módulo PC Card. El minidriver tiene que proveernos de dos interfaces para posibilitar esta comunicación, que son los siguientes: Interfaz con el driver del HCI: si el minidriver Bluetooth PC Card implementa el resto de la pila de protocolos SW Bluetooth no hay que añadir requisitos a la implementación del fabricante. Si el fabricante no nos 53 Host Controller Pág. 238

249 implementa toda la pila, es necesario que el minidriver tenga interfaz con el driver del HCI. Interfaz con el bus físico: no hay requisitos especiales para el interfaz inferior del minidriver PC Card. Lo más común es que el módulo Bluetooth PC Card de un fabricante ya nos incluya el firmware y el minidriver, por lo cual no debe haber problemas de interoperabilidad con las comunicaciones entre el firmware y el minidriver PROTOCOLOS ADOPTADOS DE BLUETOOTH Se trata de un protocolo a nivel de red que en la tecnología Bluetooth es diseñado para correr sobre RFCOMM y poder así llevar a cabo conexiones punto a punto. Los paquetes enviados y recibidos son paquetes IP. TCP/UDP/IP Estos protocolos están definidos por el IETF 54 y son ampliamente usados para comunicación a través de Internet. Actualmente constituyen la familia de protocolos más extendida en el mundo. El acceso a estos protocolos es independiente del sistema operativo aunque tradicionalmente se han implementado usando modelos de programación con sockets. La implementación de estos protocolos en dispositivos Bluetooth permite la comunicación con otro dispositivo que se encuentre conectado a Internet. Además el dispositivo Bluetooth podría ser usado como un bridge a Internet. OBEX Es un protocolo de sesión desarrollado por IrDA para intercambiar objetos de una forma simple. OBEX, que proporciona la misma funcionalidad básica que HTTP pero de una forma más ligera, usa un modelo cliente- servidor y es independiente del mecanismo de transporte, dado que realiza un transporte de base fiable. También nos proporciona un modelo para representar objetos, operaciones, y define un objeto de 54 Internet Engineering Task Force Pág. 239

250 listado de carpetas que se usa para poder navegar por los contenidos de las carpetas situadas en dispositivos remotos. Formatos de contenido vcard y vcalendar son especificaciones abiertas desarrolladas por The Versit Consortium y actualmente controladas por The Internet Mail Consortium. Estas especificaciones definen respectivamente el formato de una tarjeta de negocios electrónica y un calendario personal con opciones para poder anotar diferentes eventos (una agenda electrónica). vcard y vcalendar no definen ningún mecanismo de transporte, únicamente el formato de los datos que tienen que ser transportados. Gracias a la adopción de estos dos formatos, el SIG pretende promocionar el intercambio de información personal a través de Bluetooth. Otros formatos de contenido OBEX, que también se están adoptando en Bluetooth son vmessage y vnote. También se trata de estándares abiertos y son usados para el intercambio de mensajes y notas. Se encuentran definidos en la especificación IrMC, la cual también define un formato para los ficheros log que se necesitan cuando se sincronizan datos entre dispositivos. WAP El propósito del protocolo WAP 55 es proporcionar contenidos y servicios de Internet a teléfonos móviles celulares y otros dispositivos inalámbricos. La idea de Bluetooth de adoptar WAP se basa en querer reutilizar las aplicaciones software desarrollados para el WAE 56, entre las que se incluye navegadores WML que puedan interactuar con aplicaciones en el PC. Los formatos de contenido WAP sobre Bluetooth son WML, WMLScript, WTAevent y WBMP. 55 Wireless Application Protocol 56 WAP Applicaiton Environment Pág. 240

251 11. MANUAL DE USUARIO 11.1 SOSA BLUETOOTH MOBILE MANUAL USUARIO Pág. 241

252 ÍNDICE 1. Información general 243 a. Código de acceso b. Descripción general Conceptos básicos Utilización del menú.246 a. Acceso a funciones de menú..246 b. Lista de funciones de menú Funciones del menú a. Pasar lista 247 b. Conectar con el PC..247 c. Calendario 249 d. Contraseña e. Gestión de datos..250 f. Acerca de.251 Pág. 242

253 1. Información general a. Código de acceso: El código de seguridad protege a la aplicación de usos no autorizados. El código preestablecido es Para cambiar el código, véase Contraseña en la página 176. b. Descripción general: "SOSA Bluetooth Mobile" es un Sistema On-line de Seguimiento del Alumnado que permite recoger todas las incidencias que se producen en el aula sobre un dispositivo móvil y posteriormente transferir la información a su PC a través de Bluetooth. Dentro de este sistema, por lo tanto, se engloban dos módulos: El módulo cliente, basado en tecnología JAVA (plataforma J2ME), gestionará, principalmente, la información asociada a la asistencia por parte del alumnado. Éste módulo presentará un interfaz muy intuitivo y fácil de manejar, adaptado a las restricciones de los móviles. El módulo servidor, basado en tecnología JAVA (plataforma J2SE 5.0), permitirá sincronizar las actualizaciones anotadas sobre el móvil de cada uno de los alumnos con la base de datos del PC del profesor. Pág. 243

254 2. Conceptos básicos Una vez iniciada la misma, saldrá una pantalla de bienvenida, como se muestra a continuación: Para acceder a la aplicación, pulse Iniciar. Para salir de la aplicación pulse Salir. Si ha pulsado Iniciar, saldrá la pantalla de Contraseña, en la que deberá introducir el código preestablecido (véase Código de acceso en Información general, en la página 170) si es la primera vez que ha iniciado la aplicación o todavía no a cambiado la contraseña. La pantalla será la siguiente: Pág. 244

255 Si la contraseña introducida no es la correcta, se mostrará una pantalla de aviso como la siguiente: Una vez leído el mensaje de aviso, pulse el botón que le devolverá a la pantalla anterior, donde se le pedirá de nuevo la contraseña. Una vez introducida esta, accederá al menú principal de la aplicación (véase Utilización del menú, en la página 173). Pág. 245

256 3. Utilización del menú La aplicación ofrece una serie de funciones que se agrupan en menús. a. Acceso a funciones del menú: Mediante desplazamiento: 1. Para acceder al menú, pulse Seleccionar. 2. Desplácese con las teclas o por el menú y seleccione, por ejemplo, Gestión de datos, pulsando para ello Seleccionar. 3. Si el menú contiene submenús, seleccione el que desee, por ejemplo Ver. 4. Si el submenú contiene a su vez otros submenús, repita el paso Pulse Volver para volver al nivel del menú principal y Salir para salir de la aplicación. b. Lista de funciones de menú: Pasar lista Conectar con el PC Calendario Contraseña Gestión de datos Acerca de Pág. 246

257 4. Funciones de menú a. Pasar lista Pude pasar lista a los alumnos que, anteriormente a tenido que almacenar (véase Conectar con el PC en Funciones de menú, en la página 174). Si no ha almacenado ningún Record Store, al entrar en este menú, le saldrá una lista vacía ya que la aplicación no encuentra ninguno. b. Conectar con el PC Puede conectar con el PC para enviar y recibir datos entre el dispositivo móvil y el PC. Para buscar el PC, debe pulsar Buscar Disp. Si no se encuentra el dispositivo del PC, asegurase de que en el dispositivo del PC está activada la opción Activar la detección, para ello debe dirigirse a las opciones de Bluetooth del PC. Pág. 247

258 Si esta está activada y sigue sin encontrar el dispositivo del PC, asegurase de que el dispositivo móvil, no tiene activa la vinculación con el dispositivo del PC, para verificarlo tendrá que salir de la aplicación y comprobarlo por medio del menú Bluetooth del dispositivo móvil, si esta activa, desactivarlo y volver a iniciar la aplicación. Una vez encontrado el dispositivo del PC, pulse Buscar Serv. Una vez encontrado el servicio ofrecido por el PC (para que encuentre el servicio, deberá haber iniciado una conexión con la aplicación del PC SOSA Bluetooth Server ), tendrá dos opciones: Pulse Recibir si desea recibir una lista de alumnos del PC. Pulse Enviar si desea enviar un Record Store de faltas. Si ha pulsado Recibir se mostrará una pantalla vacía, a la espera de recibir los datos procedentes del PC. Una vez recibidos, se mostrará la pantalla Guardar como en la que puede pulsar Volver para volver al menú principal o pulsar Guardar si ha introducido el nombre con el que va a guardar el Record Store. Si ha pulsado Enviar se mostrará una lista con los Record Stores almacenados en el dispositivo móvil, muévase hasta posicionarse sobre el Record Store que desea enviar y a continuación pulse Siguiente. Se le mostrará una lista con todos los alumnos que contiene el Record Store elegido. Si los datos que desea enviar son los que aparecen en la lista, pulse Enviar (si la transferencia no se ha realizado, es decir, no aparecen los alumnos en la pantalla de la aplicación del PC, vuelva a pulsar Enviar). Pág. 248

259 c. Calendario Puede ver la hora y la fecha del día. d. Contraseña Puede cambiar la contraseña que está actualmente activa, es aconsejable cambiar cada cierto tiempo la contraseña por cuestiones de seguridad. Una vez seleccionada esta opción, se le mostrará una pantalla donde se el pedirá que introduzca la contraseña actual, una vez introducida esta, pulsara Siguiente, a continuación se le pedirá que introduzca la nueva contraseña, una vez introducida esta, pulsara Siguiente, a continuación se le pedirá que vuelva a introducir la nueva contraseña y finalmente pulse Pág. 249

260 Modificar, para guardar los cambios. Si las contraseñas nuevas introducidas no coinciden o no introduce nada, volverá al inicio de la operación de cambio. Una vez finalizado el proceso, la aplicación le pedirá que vuelva a entrar en la aplicación con la nueva clave de acceso, volviendo al menú principal si está bien introducida. Puede pulsar en todo momento Volver para volver al menú principal. e. Gestión de datos Puede gestionar los Record Stores que la aplicación tiene almacenados en el dispositivo móvil. Dispone de una serie de opciones: Ver Altas Bajas Modificaciones Si la opción seleccionada es Ver, se le mostrará todos los Record Stores que la aplicación tiene almacenados, si no tiene se mostrará una lista vacía y deberá pulsar Volver para salir al menú principal. Si hay Record Stores, deberá posicionarse sobre la que desea ver y a continuación pulsar Seleccionar, mostrándose así el contenido del Record Store elegido. Si la opción seleccionada es Altas, podrá dar de alta a un alumno en cualquiera de los Record Stores que la aplicación tiene almacenados en el dispositivo móvil. Para ello, se le pedirá que introduzca el nombre del nuevo alumno y una vez introducido, deberá pulsar Siguiente, y así sucesivamente hasta completar los datos necesarios del alumno y una vez completados estos, se mostraran los Record Stores disponibles y deberá posicionarse sobre el que desea almacenar al alumno y a continuación pulsar Guardar. Pág. 250

261 Si la opción seleccionada es Bajas, se mostrará una lista de los Record Stores que la aplicación tiene almacenados en el dispositivo móvil, a continuación nos posicionaremos sobre el Record Store que deseamos dar de baja y pulsamos Dar baja RS y a continuación se le preguntará si desea dar de baja el Record Store escogido, si pulsa Si será eliminado de forma irreversible, si por el contrario pulsa no, volverá a la lista de Record Stores. Si la opción seleccionada es Modificaciones, f. Acerca de Pede ver la información referente a la aplicación: nombre, versión, propósito de creación, y datos de los autores de la creación de la misma. Pág. 251

262 11.2 SOSA BLUETOOTH SERVER MANUAL USUARIO Pág. 252

263 ÍNDICE 1. Información general a. Configuración Base de Datos b. Configuración Bluetooth. 255 c. Descripción general Conexión Bluetooth a. Iniciar b. Enviar c. Recibir Gestión de la Base de Datos 262 a. A tener en cuenta 262 b. Mostrar 262 c. Actualizar 263 d. Informes faltas. 265 Pág. 253

264 1. Información general a. Configuración de la Base de Datos: Para que la aplicación pueda manejar la Base de Datos, se debe configurar el Microsoft Access Driver. Proceso de configuración para Windows XP: e. Inicio. f. Panel de control. g. Herramientas administrativas. h. Orígenes de datos (ODBC). II. En la pestaña DSN Usuarios pulsamos Agregar Pág. 254

265 III. Seleccionamos Microsoft Access Driver (*.mdb) IV. Pulsamos Finalizar. b. Configuración Bluetooth: Para que nuestra aplicación cliente SOSA Bluetooth Mobile, pueda descubrir el dispositivo Bluetooth de nuestro PC, necesitamos que este visible. Para ello debemos seguir el siguiente proceso de configuración: Proceso de configuración para Windows XP: e. Hacemos doble clic sobre el icono Bluetooth que aparece en la barra de tareas del escritorio: Pág. 255

266 f. Una vez abierta la ventana, hacemos clic sobre la pestaña de Opciones y establecemos las opciones como en la siguiente pantalla: g. Pulsamos Aceptar. h. Para conocer cual es el puerto COM asociado a nuestro dispositivo Bluetooth, debemos hacer clic sobre la pestaña Puertos COM y el que necesitamos para nuestra aplicación es el Entrante. Pág. 256