Universidad de las Ciencias Informáticas
“Framework para la creación de aplicaciones destinadas a dispositivos móviles que utilicen Bluetooth con J2ME.”
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas.
Autor(es): Armando Sánchez Pérez Héctor Veitía Vila
Tutor(es): Ing. Dayron Agüero Jiménez Ing. Darién J. Álvares
Ciudad de la Habana. Junio de 2010
Año del 51 Aniversario del Triunfo de la Revolución
DECLARACIÓN DE AUTORÍA
II
Declaramos que somos los únicos autores de este trabajo y autorizamos a la Facultad 2 de la Universidad de las Ciencias Informáticas; así como al Centro de Telemática perteneciente a dicha facultad para que hagan el uso que estimen pertinente con este trabajo.Para que así conste firmamos la presente a los ____ días del mes de junio del 2010.
_____________ ______________ ______________ _____________
Firma de Autor Firma de Autor
Firma de Tutor
Firma de Tutor
Armando Sánchez Pérez
Héctor Veitía Vila Dayron Agüero Jiménez Darién J. Álvarez
III
Dedicatoria
A esas dos personas que han hecho posible que haya llegado hoy hasta aquí, con su paciencia, apoyo incondicional y amor, a ustedes mis padres, las personas más importantes de mi vida. A mi novia Oslaidy por estar a mi lado siempre y por regalarme su amor. A mis hermanos Marialis y Ariam que me han apoyado todo este tiempo, a mis otros hermanos que no necesitan ser de sangre para que los vea como tal, Yosvani, Henry, Pedro, Alberto, Yuniesky, Sergio, etc. Al resto de mi familia, a los del grupo, a los amigos que he conocido en todo este tiempo, a los del proyecto y todo el que haya tenido de una forma u otra que ver conmigo.
Armando Sánchez Pérez
A mi dios con forma de mujer quien me dio la vida, mi estrella, mi gran amor, mi confidente, en fin, mi todo; mi madre: Miriam Vila Pentón. A mi otra madre y abuela Nadia G. Pentón Jiménez. A mi abuelo Juan por siempre estar cuando lo necesito. A mi papa Héctor, que a su forma, pero yo sé que me quiere mucho. A mis tres hermanos, Sady, Sandy y Andy que son muy especiales en mi vida. A mis padrinos, tío Eduardo y tía Clarita que me quieren como un hijo más. A mi tío Juanito. A todas la amistades que siempre están a mi lado, los viejos de Santa Clara y los nuevos de la UCI. En fin a todas aquellas personas que me quieren de verdad y de una forma u otra han hecho posible que hoy este aquí.
Héctor Veitía Vila.
IV
Agradecimientos
Agradezco de todo corazón a mis padres, sin ellos no hubiese sido posible llegar hasta aquí, gracias por su apoyo, amor, confianza, dedicación, paciencia y todos esos sentimientos buenos de ustedes hacia mí, espero que hoy estén orgullosos. Le agradezco a mi familia, a mi novia Oslaidy, a los amigos del barrio, a los eternos amigos de la escuela, a los que he conocido aquí, a todo aquel que me ha ayudado y a aportado su granito de arena para que hoy pueda hacer mi sueño realidad.
Gracias.
Armando Sánchez Pérez
Primeramente quiero agradecer a mi madre porque sin ella hoy yo no estaría aquí, a la vida por darles salud a mis abuelos maternos para que me puedan ver graduado, agradezco a todos los profesores y amistades que me hicieron algún bien durante el transcurso de la carrera. En fin, a todos los que de una forma u otra formaron parte de este sueño que hoy hago realidad.
Héctor Veitía Vila.
V
Resumen
El presente trabajo consiste en explicar de forma detallada las características, como ha sido desarrollado y como utilizar BlueConnect, un framework para la creación de aplicaciones para dispositivos móviles que se comuniquen vía Bluetooth. Facilita el trabajo de los desarrolladores de aplicaciones basadas en este protocolo de comunicación. Como aplicación de prueba fue implementado un pequeño juego de beisbol.
Mediante él se explica de forma detallada como utilizar BlueConnect, así como las pautas a seguir a la hora de implementar una aplicación que utilice este framework.
VI Índice
Introducción ... 1
Capitulo 1: Fundamentación Teórica ... 5
1.1 Introducción ... 5
1.2 La telefonía móvil ... 5
1.3Protocolo de comunicación Bluetooth ... 6
1.4 Técnicas de reutilización ... 9
1.5 Estado del Arte ... 10
1.5.1 Avetana ... 10
1.5.2 32feet.Net ... 10
1.5.3 Bluetooth Framework VCL Personal ... 10
1.5.4 JBGames ... 11
1.6 Proceso de desarrollo ... 11
1.6.1 Metodología de desarrollo de software ... 11
1.6.1 Metodología Utilizada. Rational Unified Process (RUP) ... 11
1.6.2 Lenguaje de modelado. Unified Modeling Language (UML) ... 12
1.6.3 Herramienta Case. Visual Paradigm ... 12
1.6.4 IDE de desarrollo Eclipse... 13
1.6.5 Emulador Sony Ericsson... 13
1.6.6 Sistema de control de versiones ... 14
1.7 Conclusiones ... 14
Capítulo 2 Características del sistema... 15
2.1Introducción ... 15
2.2 ¿Por qué un framework? ... 15
2.2 ¿Cómo debería funcionar? ... 15
2.2.1 Envío/Recepción de datos asíncronos. ... 15
2.2.2 Flujo de datos delimitados por paquetes ... 16
2.2.3 Programación orientada por eventos ... 16
VII
2.2.4 Modelo Cliente – Servidor... 16
2.2.5 Propuesta de Sistema ... 16
2.2.6 Seguridad ... 17
2.2.6.3 Solicitudes de servidor para autorización ... 18
2.3 Análisis del Dominio ... 19
2.4 Requerimientos ... 20
2.4.1 Requerimientos funcionales... 20
2.4.2 Requerimientos no funcionales ... 20
2.5 Modelo de Casos de Uso del Sistema ... 22
2.5.1 Actores del Sistema ... 22
2.5.2 Casos de Uso del Sistema... 22
2.5.3 Diagrama de Casos de Uso del Sistema ... 24
2.6 Descripción de Casos de Uso ... 24
2.7 Conclusiones ... 24
Capítulo 3 Análisis y diseño del sistema. ... 25
3.1 Introducción ... 25
3.2 Definición del modelo de análisis ... 25
3.3 Diseño ... 25
3.3.1 Diagrama de clases del Diseño ... 25
3.3.2 Interfaz BluetoothListener ... 26
3.3.3 Clase BluetoothoBase ... 27
3.3.4 Clase Server ... 27
3.3.5 Clase Client ... 28
3.3.6 Clase EndPoint ... 29
3.3.7 Clase Reader ... 29
3.3.8 Clase Sender ... 30
3.3.9 Clase NotificacionPacket ... 30
VIII
3.4 Descripción de la arquitectura ... 31
3.4.1 Patrones utlizados ... 31
3.4.2 Patrón arquitectónico ... 31
3.4.3 Patrones de diseño. Patrones GRASP ... 31
3.4.4 Patrones de diseño. Patrones GOF ... 32
3.5 Conclusiones ... 32
Capítulo 4 Instalación ... 33
4.1 Introducción ... 33
4.2 Modelo de Implementación de framework ... 33
4.2.1 Diagrama de Despliegue ... 33
4.2.2. Diagrama de Componentes ... 34
4.3 Reglas para el uso de BlueConnect ... 34
4.3.1 Descripción del juego de Beisbol ... 35
4.3.2 Implementación del juego de Beisbol ... 35
4.4 Uso de BlueConnect ... 42
4.5Conclusiones ... 44
Capítulo 5 Estudio de la factibilidad ... 45
5.1Introducción ... 45
5.2Análisis de Puntos de Casos de Uso ... 45
5.2.1 Cálculo de Puntos de Casos de Uso sin ajustar ... 45
5.4 Cálculo de Puntos de Casos de Uso ajustados... 47
5.5 De los Puntos de Casos de Uso a la estimación del esfuerzo ... 49
Resultados alcanzados ... 50
5.6 Análisis de los costos y beneficios tangibles e intangibles ... 50
5.7 Conclusiones ... 51
Conclusiones Generales ... 52
Recomendaciones ... 53
IX
Referencias ... 54
Anexos ... 56
Anexo1: Descripción textual de Casos de Uso. ... 56
Anexo2: Diagramas de secuencias del diseño. ... 60
GLOSARIO DE TÉRMINOS Y SIGLAS ... 64
1
Introducción
En la actualidad existen tres tendencias fundamentales hacia las cuales el mundo viaja constantemente, estas son: conectividad, movilidad y seguridad. Cada día que pasa es mayor el número de personas conectadas en la red, publicándose diariamente miles de documentos nuevos y mejorándose los canales de comunicación con el fin de aumentar la rapidez en el envío y recepción de datos. Las altas cifras de usuarios conectados en la red indican que en este siglo este número sea igual al número de usuarios que ven la televisión. Se piensa que un futuro no muy lejano los usuarios no tengan sus archivos en sus PC sino que todo esté hosteado en grandes servidores, esto trae consigo que la seguridad informática sea un área clave en el mundo interconectado de hoy debido a la gran cantidad de información que se maneja en la red. Día a día, en los principales medios de comunicación se repiten los ataques de virus, hackers y otros peligros tecnológicos. En el caso específico de la movilidad el uso de las tecnologías inalámbricas tienen un constante avance debido a su bajo nivel de inversión inicial, escalabilidad, estándares abiertos y su adaptabilidad a requisitos de voz y datos. Las mismas han permitido el surgimiento de nuevos dispositivos y aplicaciones que ofrecen todo tipo de funciones, lo que propicia que el número de usuarios de la telefonía celular sea cada vez mayor, convirtiéndose en parte esencial de la vida de los seres humanos.
Una de las principales líneas de trabajo de las empresas desarrolladoras de software para dispositivos móviles es el desarrollo de contenidos, debido a que estos dispositivos ya no solamente cuentan con funciones básicas de recepción y envió de llamadas, también tienen nuevas funcionalidades como son MP3, navegación por Internet, envío y recibo de correo electrónico, mensajería de texto, discado por comando de voz, radio FM, mensajería multimedia, cámara integrada, además de permitir la conexión entre dos móviles que se encuentren a corta distancia para transferir de archivos o ejecutar juegos.
La telefonía móvil, brinda a sus usuarios la posibilidad de realizar descargas de contenidos con el fin de personalizar sus celulares, ganando mayor popularidad entre las descargas, los ringtones, la música y los juegos, estos últimos se clasifican según el tipo de adversario con el que los usuarios interactúan, en simple o multi-jugador. Entre estas dos clasificaciones los juegos multi-jugador tienen una mayor demanda por parte de los usuarios, estos son más atractivos y emocionantes por promover la competencia entre ellos.
2
Cuba no está ajena al cambio y se acerca cada vez más a dichas tendencias. En nuestro país se ha incrementado sustancialmente las personas que disfrutan de los servicios que brindan la telefonía celular, en la actualidad Cuba cuenta con más de 140 000 usuarios prepago y más de 15 000 usuarios pos pago, dichos usuarios disponen de servicios agregados mediante mensajes de texto, ahora los cubanos podrán consultar desde sus móviles las carteleras de las salas de cine, la ubicación de las embajadas, el estado del tiempo y el curso de un huracán, entre otros datos (2). Además se podrá disfrutar de las facilidades de los móviles actuales tales como, captura de fotos y videos, música mp3, radio y juegos. A los usuarios les atrae establecer comunicación con otro dispositivo móvil sin necesidad de tener que solicitar un servicio para ello, ya sea para enviar archivos, listas de contactos, poder jugar, etc. Para lograr esto existen diversas formas de comunicación como infrarrojo, Bluetooth, entre otros. Por tal motivo se hace necesario tener un mayor número de aplicaciones con vía de comunicación Bluetooth en el menor tiempo posible, para intentar satisfacer las necesidades en el mercado a nivel nacional e internacional.La forma de comunicación entre los dispositivos y diseño de las pantallas (presentación y estilos de los menús), son características comunes en las aplicaciones de dispositivos móviles que utilizan como vía de comunicación Bluetooth, lo cual hace del diseño e implementación una tarea repetitiva. Para cumplir con la demanda de productos terminados no es suficiente la reutilización de códigos realizados con anterioridad, mucho menos si se cuenta con poco personal capacitado, poca experiencia en esta esfera y corto plazo de tiempo. Investigaciones realizadas a soluciones anteriormente dadas a problemas similares, dieron el siguiente resultado: La reutilización solo de código produce pocas ganancias, poca productividad y no es totalmente confiable, se alcanzan mejores resultados al reutilizar diseños, componentes, modelos y frameworks.
Esto crea el siguiente Problema científico: ¿Cómo facilitar el trabajo de los desarrolladores de aplicaciones basadas en el protocolo de comunicación Bluetooth?
Se define como Objeto de estudio: Las aplicaciones para móviles que utilicen como vía de comunicación Bluetooth.
Enmarcándose en el Campo de acción, los frameworks para el desarrollo de aplicaciones para dispositivos móviles con el tipo de tecnología inalámbrica Bluetooth.
Como objetivo general se ha planteado desarrollar un framework para realizar aplicaciones sobre J2ME para dispositivos móviles que se comuniquen vía Bluetooth.
3
Preguntas Científicas:¿Cómo funciona el protocolo de comunicación Bluetooth?
¿Cómo relacionar aplicaciones sobre J2ME con el protocolo de comunicación Bluetooth?
¿Cómo implementar un framework con todas las funcionalidades del protocolo de comunicación Bluetooth?
Centrándose los Objetivos específicos en:
1. Analizar el protocolo de comunicación Bluetooth.
2. Implementar y documentar un framework que permita desarrollar aplicaciones que se conecten vía Bluetooth.
Se llevaron a cabo las siguientes Tareas de la Investigación:
1. Analizar las características y el funcionamiento del protocolo de comunicación Bluetooth.
2. Analizar el desarrollo de aplicaciones a nivel mundial que utilizan esta vía de comunicación.
3. Estudiar la utilización de frameworks para la creación de juegos, principalmente multi-jugador.
4. Estudiar como relacionar el protocolo de comunicación Bluetooth con aplicaciones sobre J2ME.
5. Implementar un framework con todas las funciones del protocolo Bluetooth.
6. Documentar todos los métodos y clases del framework a implementar.
Los Métodos Teóricos que se utilizan en el proceso de investigación son: analítico sintético que permiten buscar la esencia de los fenómenos, los rasgos que lo caracterizan y los distinguen, mediante el análisis de las teorías, documentos, etc., permitiendo la extracción de los elementos más importantes que se relacionan con el objeto de estudio. El histórico lógico que permite estudiar de forma analítica la trayectoria histórica real de los fenómenos, su evolución y desarrollo, constatar teóricamente cómo ha evolucionado un determinado fenómeno en un periodo de tiempo, en toda su trayectoria o en un fragmento temporal de la lógica de su desarrollo.
La presente tesis contribuye a minimizar en el Centro de Telemática de la Universidad de las Ciencias Informáticas los esfuerzos en la producción de aplicaciones que utilicen Bluetooth como vía de comunicación.
4
Estructura del DocumentoEl presente trabajo está estructurado en cinco capítulos.
Capítulo 1
Se hace referencia a la situación problémica y las vías existentes para darle solución, así como el análisis crítico de las técnicas de reutilización Orientadas a Objetos, además se realiza un estudio del estado del arte y de las tecnologías involucradas en el desarrollo del mismo.
Capítulo 2
Se analiza la manera en que se va a desarrollar el sistema propuesto, explicando las principales características que debe tener. Se realiza además, el análisis del dominio y la captura de los principales requerimientos de la solución modelando dicha solución en casos de uso de sistema.
Capítulo 3
Aborda aspectos relacionados con la construcción de la solución del sistema propuesto. Se realiza una descripción de cada una de la clases a desarrollar y de la arquitectura del sistema, haciendo énfasis en el patrón arquitectónico utilizado y en los patrones de diseño GRASP y GOF.
Capítulo 4
En este capítulo se muestran las reglas para el correcto empleo de BlueConnect en la construcción de una aplicación. Además se describen las clases del juego utilizado como ejemplo, mostrándose los fragmentos de código fundamentales donde es utilizado BlueConnect.
Capítulo 5
Se realiza un análisis exhaustivo de la factibilidad del sistema.
5
Capitulo 1: Fundamentación Teórica
1.1 Introducción
En el siguiente capítulo se hace referencia al estado actual de algunos frameworks y APIs para la comunicación por Bluetooth, tanto nacional como internacional. Así como el estudio del ambiente de desarrollo, brindando las principales características de la metodología, lenguaje y herramientas que se utilizarán en la implementación de la solución.
1.2 La telefonía móvil
Se define como telefonía móvil al servicio de telecomunicaciones que mediante una red de antenas situadas en estaciones base permite recibir y realizar llamadas desde terminales móviles por medio de ondas electromagnéticas de radiofrecuencia (señales de mayor frecuencia que las utilizadas en radiotelevisión, pero con una menor potencia).
Elteléfono móviles un dispositivo inalámbrico electrónico que permite tener acceso a la red de telefonía celular o móvil. Se denomina celular debido a las antenas repetidoras que conforman la red, cad a una de las cuales es una célula, si bien existen redes telefónicas móviles satelitales. Su principal característica es su portabilidad, que permite comunicarse desde casi cualquier lugar.
Los teléfonos celulares surgieron en 1947 por invención de Martín Cooper cuando en Estados Unidos los investigadores de los Laboratorios Bell pusieron su atención en los primitivos teléfonos de radio frecuencias usados en los móviles policiales (3).
En la actualidad los teléfonos celulares han tenido una gran avance, estos han evolucionado mucho en cuanto a sus funcionalidades llegándose a convertir en casi una computadora.
La telefonía móvil es uno de los principales negocios en la actualidad, por lo que el desarrollo de contenido y aplicaciones para móviles es uno es uno de los aspectos fundamentales en el negocio de las telecomunicaciones.Aunque la principal función de los teléfonos celulares es la comunicación de voz, su rápido desarrollo ha incorporado otras funciones como son cámara fotográfica, agenda, acceso a Internet, reproducción de vídeo, GPS, reproductor mp3, incluso es posible la conexión de varios dispositivos para intercambiar ficheros o ejecutar juegos.
6
La conexión entre dispositivos móviles puede establecerse de diversas maneras. Dentro de las más usuales están GPRS donde el mayor inconveniente es la obligatoria existencia de un servidor, lo cual incluye un precio, para poder efectuar una partida del juego, pero permite la comunicación a largas distancias; infrarrojo, con poca velocidad de transmisión y probabilidad de pérdida de la conexión y Bluetooth que a diferencia de GPRS no acarrea costos pero está diseñado para cortas distancias, además no requiere enfrentamiento visual de los dispositivos por ser omnidireccional y tiene un rango mayor que el infrarrojo.1.3Protocolo de comunicación Bluetooth
Bluetooth es una tecnología de radio de corto alcance, que permite conectividad inalámbrica entre dispositivos remotos, al igual que la tecnología Wi-Fi o los infrarrojos. Se diseñó pensando básicamente en tres objetivos: pequeño tamaño, mínimo consumo y bajo precio. Opera en la banda libre de radio ISM1 a 2.4 GHz Su máxima velocidad de transmisión de datos es de 1 Mbps. El rango de alcance Bluetooth depende de la potencia empleada en la transmisión. La mayor parte de los dispositivos que usan Bluetooth transmiten con una potencia nominal de salida de 0 dBm, lo que permite un alcance de unos 10 metros en un ambiente libre de obstáculos (4). Bluetooth es una tecnología ideal para la conexión de dispositivos de bajas prestaciones (móviles, cámaras de fotos, auriculares manos libres, impresoras, entre otros).
El sistema de radio Bluetooth deberá estar preparado para evitar las múltiples interferencias que se pudieran producir. Éstas pueden ser evitadas utilizando un sistema que busque una parte no utilizada del espectro o un sistema de salto de frecuencia. En este caso la técnica de salto de frecuencia es aplicada a una alta velocidad y una corta longitud de los paquetes (1600 saltos/segundo). Con este sistema se 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 (repetición automática de consulta), en el cual los paquetes perdidos son automáticamente retransmitidos.
Bluetooth utiliza un sistema FH/TDD (salto de frecuencia/división de tiempo duplex), en el que el canal queda dividido en intervalos de 625 μs, llamados slots, donde cada salto de frecuencia es ocupado por un slot.
7
Dos o más unidades Bluetooth pueden compartir el mismo canal dentro de una piconet (pequeña red que establecen automáticamente los terminales Bluetooth para comunicarse entre sí), donde una unidad actúa como maestra, controlando el tráfico de datos en la piconet que se genera entre las demás unidades que actúan como esclavas enviando y recibiendo señales hacia el maestro.El salto de frecuencia del canal está determinado por la secuencia de la señal, es decir, el orden en que llegan los saltos y por la fase de esta secuencia. En Bluetooth, la secuencia queda fijada por la identidad de la unidad maestra de la piconet (un código único para cada equipo), y por su frecuencia de reloj.
El hardware Bluetooth había avanzado pero no había manera de desarrollar aplicaciones java Bluetooth, se hizo necesario un recurso que les permitiera a los programadores centrarse en el desarrollo de las aplicaciones y no en los detalles de bajo nivel del mismo, para ello se creó JSR-82. Esta API se utiliza básicamente para la programación de alto nivel de dispositivos Bluetooth. Estandarizó la forma de desarrollar aplicaciones Bluetooth usando Java. El objetivo de ésta especificación era definir un API estándar abierto no propietario, que pudiera ser usado en todos los dispositivos que implementen J2ME.
Por consiguiente 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 (5; 6).
El JSR-82 depende de la configuración CLDC de J2ME y se divide en dos paquetes: javax.Bluetooth y javax.obex. El primer paquete provee la funcionalidad para la realización de búsquedas de dispositivos, búsquedas de servicios y comunicación mediante flujos de datos (streams) o arrays de bytes. Por otro lado el paquete javax.obex permite la comunicación mediante el protocolo OBEX (OBject Exchange); se trata de un protocolo de alto nivel muy similar a HTTP y es utilizado sobre todo para el intercambio de archivos (7). No se profundizará en su estudio porque no será utilizado en el desarrollo de las aplicaciones que le conciernen al presente trabajo.
De forma general, en una comunicación Bluetooth existe un dispositivo que ofrece un servicio (servidor) y otros que acceden a él (clientes). Dependiendo de que parte de comunicación va a ser programada se deberá realizar una serie de acciones que se enumeran a continuación.
Los pasos que debe realizar un servidor Bluetooth son:
Crear una conexión servidora.
8
Especificar los atributos de servicio.Abrir las conexiones cliente.
Por otro lado, un cliente Bluetooth deberá realizar las operaciones siguientes:
Búsqueda de dispositivos Búsqueda de servicios
Establecimiento de la conexión
Comunicación: Para usar un servicio en un dispositivo Bluetooth remoto, el dispositivo local debe comunicarse usando el mismo protocolo que el servicio remoto. Los APIs permiten usar L2CAP y RFCOMM.
El protocolo de adaptación y control lógico del enlace L2CAP (Logical Link Control and Adaptation Protocol), soporta dos tipos de conexiones, orientadas a conexión (bidireccionales) y no orientadas a conexión (unidireccionales). Todas las conexiones hechas usando la primitiva de servicio connect de la capa L2CAP son orientadas a conexión, este API no soporta comunicaciones en grupo, y por lo tanto no soporta canales no orientados a conexión (4). L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud. L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base.
Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel (8).
El protocolo RFCOMM (Radio Frequency Communication) emula los parámetros de un cable de serie y el estado de un puerto RS-232 para transmitir datos en serie. El RFCOMM se conecta a las capas inferiores de la pila de protocolos Bluetooth a través de la capa L2CAP. RFCOMM se destina a aplicaciones que utilizan los puertos de serie de los dispositivos en los que residen. En configuración sencilla, el segmento de comunicación es un enlace Bluetooth de un dispositivo a otro (conexión directa) (8). Las direcciones Bluetooth de los dos puntos terminales definen una sesión RFCOMM. Una sesión puede tener más de una conexión, el número de conexiones dependerá de la implementación. Un dispositivo podrá tener más de una sesión RFCOMM en tanto que esté conectado a más de un dispositivo.
9
Cliente y servidor residen en los extremos de una sesión RFCOMM. Cada cliente accede al mismo registro de servicio y se conecta al servicio usando el mismo canal servidor RFCOMM (8).Se analizaron una serie de documentos durante el estudio realizado acerca de Bluetooth y su vinculación con J2ME a través del API, con el propósito de reutilizar código fuente.
1.4 Técnicas de reutilización
Se define la reutilización de software como el uso de cualquier tipo de artefacto (también llamado activo), o parte del mismo, creado con anterioridad, en un nuevo proyecto (9). Entre las técnicas reutilizables están: La Ingeniería de dominios, Líneas de productos, Patrones de Diseño y frameworks (10). La reutilización de software reduce los costes de diseño, codificación y comprobación, un aumento de la calidad de los productos y de la productividad, mediante la mejora de los tiempos en los que se desarrollan los nuevos proyectos informáticos, mejoras en las actividades de mantenimiento y soporte de aplicación y en las actividades de control y planificación por la reducción de desviaciones en los desarrollos (10; 11).
Como se mencionó anteriormente, una de las técnicas reutilizables son los frameworks, una estructura de software compuesta de componentes personalizables e intercambiables para el desarrollo de una aplicación. En otras palabras, un framework se puede considerar como una aplicación genérica incompleta y configurable a la que se le pueden añadir las últimas piezas para construir una aplicación concreta (12). Estos no definen una estructura para una aplicación completa sino que se centran en una parte de ella. La utilización de frameworks tiene entre sus ventajas fundamentales, que el programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que "rellenar", además facilita la colaboración a la hora de entender y modificar código.
Actualmente el Centro de Telemática de la Universidad de Ciencias Informáticas no cuenta con ningún framework para la creación de aplicaciones con vía de comunicación Bluetooth. El propósito principal de este trabajo es la creación de dicho framework con su respectiva documentación.
10 1.5 Estado del Arte
A nivel mundial existen diversas empresas que han desarrollado APIs o frameworks destinadas a la creación de diferentes aplicaciones Bluetooth, algunas para el manejo de dispositivos en sistemas operativos como son Avetana y 32feet.Net, además existen bibliotecas de comunicaciones como es el caso de Bluetooth Framework VCL Personal que son útiles para establecer contacto entre computadoras y teléfonos móviles vía puertos Bluetooth, IrDA y COM.
En nuestro país la creación de APIs o frameworks no ha tenido un gran desarrollo. La empresa Procyon Soluciones desarrolló JBGames, un Frameworks especializado en la creación de juegos.
1.5.1 Avetana
Ofrece funcionalidades Bluetooth en una forma estandarizada. Al utilizar Avetana un software puede ofrecer algunos servicios Bluetooth como son, la búsqueda de dispositivos remotos o conectarse a dispositivos remotos de servicios, utilizando la interfaz Java (JSR-82). Esta API tiene como tiene como inconveniente que es privativo por lo que su uso trae consigo un gasto de dinero adicional.
1.5.2 32feet.Net
Ofrece funcionalidades para hacer aplicaciones de escritorio, móviles y sistemas embebidos. Puede ser utilizado para proyectos con tecnología Bluetooth e IrDA. Su limitación fundamental es que requiere un dispositivo con Microsoft. NET Compact Framework v2.0 o superior y Windows CE.NET 4.2 o superior, o.
NET Framework v2.0 para el escritorio de Windows XP y Vista, ya que no implementa (JSR-82) (13).
1.5.3 Bluetooth Framework VCL Personal
Brinda la posibilidad de descubrir otros dispositivos Bluetooth e IrDA activados en los alrededores, extraer información acerca de estos, manejar pedidos de autenticación, manejo de puertos COM virtuales, envío y recepción de archivos, manejo de archivos en un dispositivo remoto. Sin embargo, la característica principal del VCL es la habilidad de enviar archivos a muchos dispositivos al mismo tiempo, además que está destinado a programadores de Delphi y CBuilder (14).
11 1.5.4 JBGames
Permite realizar juegos sobre J2ME para dispositivos móviles que se comuniquen vía Bluetooth;
permitiéndole a los desarrolladores configurar el diseño de las pantallas; agregar elementos al menú;
incorporar interfaces de usuario y abstraerse de la comunicación (capa en la que se establece la misma, detección de dispositivos y servicios, entre otros); centrándose así, sólo en el desarrollo de la lógica del juego.
1.6 Proceso de desarrollo
1.6.1 Metodología de desarrollo de software
Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar un software. Imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar. En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo. Una metodología es un proceso. No existe una metodología de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable. En la actualidad existen varias metodologías OO basadas en UML:
Rational Unified Process (RUP) OPEN
MÉTRICA 3
1.6.1 Metodología Utilizada. Rational Unified Process (RUP)
El Proceso Unificado de Desarrollo (Rational Unified Process en inglés) es uno de los procesos más generales que existen actualmente, su finalidad no está restringida a guiar el desarrollo de software, sino a cualquier tipo de proyecto. Es ampliamente usado por el personal de administración en procesos productivos pues intenta conseguir el objetivo común por medio del orden y la documentación. Esta metodología está definida por tres características fundamentales:
12
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a través de los requisitos. A partir de aquí los casos de uso guían el proceso de desarrollo, ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso.Centrado en la arquitectura: La arquitectura muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente.
RUP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura. El modelo de arquitectura se representa a través de vistas(4+1), o sea perspectivas del sistema, que logran una abstracción particular en cada uno de los casos, en otras palabras, se trata de que en cada una de las llamadas vistas se represente el sistema en su totalidad teniendo en cuenta solo determinados aspectos.
Iterativo e incremental: RUP propone que cada fase se desarrolle en iteraciones. Una iteración involucra actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos más que otros. Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto.
1.6.2 Lenguaje de modelado. Unified Modeling Language (UML)
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Permite visualizar, especificar, construir y documentar los artefactos de un sistema. El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas, debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos (15; 16).
1.6.3 Herramienta Case. Visual Paradigm
Las herramientas CASE son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas
13
herramientas permitirán organizar y manejar la información de un proyecto informático. Permitiéndole a los participantes de un proyecto, que los sistemas (especialmente los complejos), se tornen más flexibles, más comprensibles y además mejorar la comunicación entre los participantes.Visual Paradigm es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. El software de modelado UML ayuda a una más rápida construcción de aplicaciones de calidad, mejores y a un menor coste. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. Además produce la documentación del sistema en formatos PDF, HTML y MS Word. Visual Paradigm es Multiplataforma, genera código para Java, exporta en formato HTML y se integra con herramientas Java como Eclipse (17).
1.6.4 IDE de desarrollo Eclipse
UN IDE (Integrated Development Environment) es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI).
Los IDEs son un conjunto de herramientas para el programador, que suelen incluir en una misma suite, un buen editor de código, administrador de proyectos y archivos, enlace transparente a compiladores y debuggers e integración con sistemas controladores de versiones o repositorios.
El IDE de desarrollo utilizado es Eclipse porque es un entorno de desarrollo integrado para diferentes lenguajes de programación. Está escrito en Java y es software libre. Es un desarrollo de IBM cuyo código fuente fue puesto a disposición de los usuarios. En sí mismo Eclipse es un marco y un conjunto de servicios para construir un entorno de desarrollo a partir de componentes conectados (plug-in). Con Eclipse es posible desarrollar aplicaciones Java para dispositivos móviles, llamadas Midlets, que se ejecutan sobre el entorno J2ME.
1.6.5 Emulador Sony Ericsson
Está formado por todo lo necesario para poder desarrollar y probar aplicaciones J2ME para dispositivos móviles.
Básicamente incluye:
14
Una versión reducida de la máquina virtual java y de la colección de clases.Una versión adecuada del compilador javac.
Un emulador de dispositivos móviles en el que se pueden ejecutar las aplicaciones desarrolladas.
1.6.6 Sistema de control de versiones
Subversion es uno de los sistemas de control de versiones más modernos y utiliza un sistema con repositorio centralizado. El control de versiones se basa en una serie de acciones más o menos estándar UCI | Plataforma de Gestión de Contenidos para Dispositivos Móviles de comunicación entre la copia de trabajo y el repositorio. Estas acciones son precisamente las que permite el cliente Subversion.
Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también como svn por ser ese el nombre de la herramienta de línea de comandos. Una característica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un número de revisión independiente. En cambio, todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en cierto punto del tiempo. Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se puede progresar más rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer porque la calidad del mismo vaya a verse afectada por la pérdida de ese conducto único si se ha hecho un cambio incorrecto a los datos, simplemente se deshace dicho cambio.
1.7 Conclusiones
En el presente capítulo se ha abordado sobre algunos aspectos importantes de la telefonía móvil. Se realizó un estudio del arte de algunas APIs y frameworks para la comunicación por Bluetooth. La metodología, herramientas a utilizar y las tecnologías necesarias para la creación del futuro sistema fueron definidas. A continuación se ampliará sobre las características principales y requerimientos los frameworks, así como la propuesta de solución.
15
Capítulo 2 Características del sistema
2.1Introducción
En el presente capítulo se describe la propuesta de solución, se presenta un modelo de dominio para un mejor entendimiento de la solución planteada. Posteriormente se detallan los requisitos funcionales y no funcionales de la solución a desarrollar y se modela la misma en términos de casos de uso de sistema.
2.2 ¿Por qué un framework?
La decisión de desarrollar un framework está sustentada en diversas dificultades que afrontan los programadores a la hora de desarrollar una aplicación. Es necesario que estos tengan un conocimiento previo del protocolo de comunicación Bluetooth, además deben emplear tiempo en implementar las clases necesarias para dotar a las aplicaciones de estas funcionalidades. Con el uso de un framework se pueden generalizar dichas funcionalidades que son comunes en varias aplicaciones, como por ejemplo la creación de servicios Bluetooth, encontrar y conectarse a un servidor previamente creado, envío y recepción de paquetes, así como pausar o detener la conexión. Esto trae consigo que se fomente la reutilización de código, disminuyendo así el tiempo de desarrollo de dichas aplicaciones.
El sistema propuesto constituye un framework para el desarrollo de aplicaciones para móviles que utilicen Bluetooth, el mismo tiene como objetivo abstraer al programador de detalles del API especificado en el documento jsr-82 y ofrecerle las siguientes características:
1. Envío/Recepción de datos asíncronos.
2. Flujo de datos delimitados por paquetes.
3. Programación orientada por eventos.
4. Modelo Cliente - Servidor.
2.2 ¿Cómo debería funcionar?
2.2.1 Envío/Recepción de datos asíncronos.
Para el envío y recepción de datos se utilizaron los flujos de lectura y escritura, utilizando funciones que brindan el objeto StreamConecction del API de Bluetooth (jsr-82). Además BlueConnect cuenta con hebras para paralelizar las operaciones de lectura y escritura, de este modo cada vez que se disponga de un dato listo el mismo podrá ser enviado. (1)
16
Figura 2.1 Esquema del envío y recepción de datos.2.2.2 Flujo de datos delimitados por paquetes
Como la comunicación entre dispositivos no está basada en bytes, donde cada byte es un paquete de datos que contiene información suficiente, sino que normalmente las aplicaciones se comunican a través de paquetes de tamaño mayor que 1 y normalmente variables, BlueConnect cuenta con un formato genérico de paquetes que sirve de estándar en el contexto de una aplicación determinada, el mismo sirve de base para la comunicación en distintos contextos.
2.2.3 Programación orientada por eventos
BlueConnect permite la programación orientada por eventos, ya que este cuenta una Interfaz que se encarga de manipular los diferentes eventos que se suceden durante el curso de la aplicación. De esta manera se hace necesario que se implementen los métodos asociados a cada evento que pueda surgir.
2.2.4 Modelo Cliente – Servidor
Entre las principales clases implementadas en BlueConnect se encuentran Server y Client.
Server: Esta entidad puede crear un servicio Bluetooth con identificador y atributos arbitrarios. Una vez creado el servicio, la aplicación recibe nuevos clientes que deseen conectarse, y permite el intercambio de información.
Client: Esta entidad puede conectarse a un servidor creado e intercambiar información.
2.2.5 Propuesta de Sistema
BlueConnect constituye una capa intermedia entre una aplicación y el API de Bluetooth. En la figura se muestra el papel jugado por BlueConnect en una aplicación en la cual sea utilizado.
17 2.2.6 Seguridad
Las aplicaciones cliente servidor opcionalmente pueden añadir parámetros a la cadena de conexión para especificar la seguridad requerida. Los parámetros en la cadena de conexión pueden ser usados para establecer medidas de seguridad al mismo tiempo que se establece la conexión. Para un servidor los componentes de la cadena de conexión proporcionan suficiente información para crear un objeto de la clase apropiada de notificador, y para crear un registro del servicio apropiado. Sin embargo parámetros opcionales pueden añadirse a la cadena de conexión para especificar los requisitos del servidor para conexiones con clientes. Estos parámetros son para autenticación, encriptación y autorización.
2.2.6.1 Solicitud de servicio para autenticación
Autenticación Bluetooth, significa la verificación de integridad del dispositivo remoto. La autenticación consiste en un esquema de reto y respuesta entre dispositivos que requiera una llave de 128 bit generada a partir de un código PIN compartido por ambos dispositivos. Si los códigos PIN entre ambos dispositivos no concuerdan el proceso de autenticación falla.
Aplicación
Framework
API Bluetooth
Instrucciones Eventos
Figura 2.2 Papel de BlueConnect en una aplicación.
18
El parámetro authenticate tiene la siguiente interpretación cuando se usa en la cadena de conexión de una aplicación servidora.Si authenticate = true se intenta verificar la identidad de cada dispositivo cliente.
Si authenticate = false no se intenta verificar la identidad de los dispositivos clientes que intentan conectar al servicio.
Si el parámetro authenticate no está presente en la cadena de conexión, entonces no se intenta verificar la identidad de los dispositivos que intentan conectarse a menos que otros parámetros presentes en la cadena requieran este chequeo de identidad.
2.2.6.2 Solicitudes de servidor para encriptación
La encriptación puede ser aplicada a las aplicaciones sobre un enlace de datos dos dispositivos Bluetooth.
Cuando esta activada la encriptación se aplica a toda la transferencia de datos en ambas direcciones sobre este enlace.
El parámetro encrypt tiene la siguiente interpretación cuando se usa en la cadena de conexión de una aplicación servidora.
Si encrypt = true se encripta la información desde y para este servicio.
Si encrypt = false no se requiere encriptación por la aplicación servidora pero puede si el dispositivo cliente u otras conexiones existentes en el enlace de datos entre estos dispositivos requieren encriptación.
Si el parámetro encrypt no está presente en la cadena de conexión, es similar a encrypt = false.
Debido a que la encriptación requiere una llave de enlace compartida requiere autenticación. Esto quiere decir que la combinación authenticate = false y encrypt = true no es válida y generará una excepción.
2.2.6.3 Solicitudes de servidor para autorización
La autorización es un procedimiento por el cual el usuario de un dispositivo servidor concede acceso a un servicio específico. La implementación de la autorización de involucrar que se pregunte al usuario del dispositivo servidor si el dispositivo cliente debería permitirse acceder al servicio. También puede involucrar la consulta de una lista de dispositivos que son confiables y por tanto se les permite el acceso a todos los servicios.
El parámetro authorize tiene la siguiente interpretación cuando se usa en la cadena de conexión de una aplicación servidora.
19
Si authorize = true se consulta al BCC para determinar si el dispositivo cliente que solicita unaconexión se le permite acceso al servicio.
Si authorize = false se le permite a todos los clientes acceder al servicio.
Si no existe el parámetro authorize se asume que authorize = false.
Al igual que la encriptación, la autorización implica que la identidad del cliente puede ser verificada a través de autenticación, por lo que la combinación authenticate = false y authorize = true no es válida y generará una excepción.
2.2.6.4 Solicitudes en la cadena de conexión para el cliente
Las aplicaciones cliente también pueden usar los parámetros encrypt y authenticate en la cadena de conexión. Cuando se usan estos parámetros tienen la siguiente interpretación.
Cuando authenticate = true se intenta verificar la identidad del dispositivo servidor.
Cuando encrypt = true se encriptan todas las comunicaciones desde y hacia este servicio. Al igual que con el servidor encrypt = true implica authenticate = true.
2.3 Análisis del Dominio
El análisis de dominio es el estudio del campo de acción en el que se desarrolla BlueConnect, utiliza las mismas técnicas de abstracción, composición, generalización y especialización que se emplea en el análisis OO, pero no trata aplicaciones en particular. Un modelo de dominio sirve como base para diseñar y construir objetos del ámbito en el que se enmarca.
20
Figura 2.3 Modelo de Dominio.2.4 Requerimientos
2.4.1 Requerimientos funcionales
1. RF1. Crear servidor Bluetooth 2. RF2. Unirse a un servidor creado
2.1. Realizar búsqueda de dispositivos 2.2. Conectarse a un dispositivo encontrado 3. RF3. Chequear estado de la conexión 4. RF4. Intercambiar Información
5. RF5. Pausar conexión
2.4.2 Requerimientos no funcionales
21
Restricciones de diseño e implementación1. RNF.1 Implementar el framework utilizando J2ME con configuración CLDC 1.0, perfil MIDP 2.0, el API Bluetooth JSR-82.
Soporte
2. RNF.2 El framework debe estar acompañado de una documentación que especifique claramente las reglas para su uso.
3. RNF.3 Las clases deben estar comentadas con el propósito de guiar a los programadores y posibilitarles una familiarización con el ambiente de desarrollo.
4. RNF.4 El framework debe estar acompañado de la documentación del código mediante el javadoc, según lo propuesto por los Estándares de Código de Java.
Portabilidad
5. RNF.6 El framework debe ser portable a los modelos de teléfonos móviles que soporten la especificación JSR-82, por lo que el diseño y la implementación no deben ser dependientes del dispositivo hardware en el que se implante.
Apariencia o Interfaz interna
6. RNF 7.La implementación de las funcionalidades debe seguir los lineamientos de código establecidos por la dirección del proyecto, para garantizar la comprensión del código por desarrolladores de futuras versiones.
Seguridad
7. RNF 8.El sistema debe ser capaz de permitir que acceda solamente al contenido el cliente que lo solicitó.
8. RNF 9.Se garantizará el tratamiento adecuado de las excepciones y validaciones de las entradas del usuario.
22 2.5 Modelo de Casos de Uso del Sistema
2.5.1 Actores del Sistema
Los actores de un sistema son agentes externos: aquellas personas o sistemas que interactúan con él. En la siguiente tabla se describen los actores de la solución propuesta.
Tabla 1. Actores del Sistema.
Actores Justificación
Aplicación Actor encargado de ejecutar las operaciones del
framework.
2.5.2 Casos de Uso del Sistema
Los casos de uso son funcionalidades, o fragmentos de ellas, correspondientes a los procesos automatizados. En ellos se describe la secuencia determinada de eventos que realiza un actor en interacción con la aplicación. En la figura 2 se muestra la representación de los Casos de Uso de la propuesta de solución.
Caso de Uso CrearServidor
Actor Aplicación
Descripción Permite crear un servidor Bluetooth.
Referencia RF1
Caso de Uso UnirseServidor
Actor Aplicación
Descripción Permite unirse a un servidor Bluetooth creado.
Referencia RF2
23
Caso de Uso EnviarNotificación
Actor Aplicación
Descripción Permite a la aplicación recibir notificaciones del sistema.
Referencia RF3,RF4
Caso de Uso RecibirNotificación
Actor Permite a la aplicación enviar las notificaciones al
sistema.
Descripción Permite a la aplicación
Referencia RF3,RF4
Caso de Uso GestionarLlamadaEntrante
Actor Aplicación
Descripción Permite a la aplicación pausar y reanudar la
conexión al entrar una llamada.
Referencia RF5
24 2.5.3 Diagrama de Casos de Uso del Sistema
Figura 2.4 Diagrama de Casos de Uso del Sistema.
2.6 Descripción de Casos de Uso
La descripción detallada de los Casos de Uso se encuentra en el Anexo 1: Descripción textual de Casos de Uso.
2.7 Conclusiones
En el presente capítulo se abordaron las características principales de los frameworks definiéndose porque debe ser un framework, como sería su funcionamiento, se tiene en cuenta además el tema de la seguridad en el mismo. Se realizó un análisis del dominio y se definieron los requerimientos funcionales con los que debe cumplir. El capitulo a continuación muestra la propuesta de solución.
25
Capítulo 3 Análisis y diseño del sistema.
3.1 Introducción
En este capítulo se muestra el diseño de BlueConnect mostrando cómo solucionar los requisitos funcionales. Se realiza el análisis de la aplicación a desarrollar y finalmente se expone el diseño de la solución propuesta.
3.2 Definición del modelo de análisis
Durante el análisis se describe lo que requiere el cliente, se establece la base para la creación de un diseño de software y se definen un conjunto de requisitos que puedan ser validados, obteniendo una visión del sistema que se preocupa de dar cumplimiento a los requisitos funcionales del mismo.
3.3 Diseño
3.3.1 Diagrama de clases del Diseño
Los diagramas de clases del diseño describen gráficamente las especificaciones de las clases del software y contienen los atributos, métodos, navegabilidad y dependencias existentes entre ellas. Muestra un conjunto de interfaces colaboraciones y sus relaciones. Contienen normalmente los siguientes elementos:
Clases.
Interfaces.
Colaboraciones.
Relaciones de dependencia.
Relaciones de generalización y especialización.
Relaciones de asociación.
26
Figura 3.1 Diagrama de Clases del Diseño.3.3.2 Interfaz BluetoothListener
Es la interfaz que se debe implementar en la clase controladora de la aplicación. En ella se definen los diferentes eventos que pueden ser lanzados durante la ejecución de la aplicación, y los métodos manageConections ( String action, EndPoint endpt ) y manageSending (NotificacionPacket msg) que se ejecutan en la clase que implementa dicha interfaz cuando ocurre determinada acción durante la ejecución de la aplicación (18).
27
Figura 3.2 Diagrama UML Interfaz BluetoothListener.3.3.3 Clase BluetoothoBase
Clase fundamental de BlueConnect, tiene entre sus atributos el UUID*, además cuenta con, localDevice*, serviceRecord*, streamConection*, que son objetos necesarios para establecer la comunicación y una instancia de la interfaz BluetoothListener que es la encargada de manejar los diferentes eventos de la aplicación. De ella heredan las clases Server y Client (18).
Figura 3.3 Diagrama UML Clase BluetoothBase.
3.3.4 Clase Server
Es la clase encargada que realizar las rutinas referentes a la creación de un servidor bluetooth. Cuenta con un atributo cantConexiones de tipo int que indica la cantidad de conexiones que serán aceptadas por el servidor, además como atributo tiene un vector donde almacena todos los dispositivos clientes (18).
28
Figura 3.4 Diagrama UML Clase Server.3.3.5 Clase Client
Es la clase encargada de realizar la búsqueda de dispositivos y conectarse a uno de ellos. Implementa la interfaz DiscoveryListener*, por lo que es necesario redefinir los métodos inquiryCompleted(int)*, serviceSearchCompleted( int, int )*, servicesDiscovered(int, ServiceRecord[])* y servicesDiscovered(int transID, ServiceRecord[])*, que son los encargados de manejar los diferentes eventos durante la búsqueda y la conexión (18).
Figura 3.5 Diagrama UML Clase Client.
29 3.3.6 Clase EndPoint
Es la clase que representa un dispositivo remoto, es la encargada de realizar las rutinas necesarias para el envío de notificaciones (18).
Figura 3.6 Diagrama UML Clase EndPoint.
3.3.7 Clase Reader
Es la clase es la encargada de encapsular las notificaciones recibidas y enviarlas hacia la aplicación (18).
30
Figura 3.7 Diagrama UML Clase Reader.3.3.8 Clase Sender
Es la clase encargada del envío de notificaciones (18).
Figura 3.8 Diagrama UML Clase Sender.
3.3.9 Clase NotificacionPacket
Es la clase que encapsula las notificaciones, entre sus atributos cuenta con uno de tipo int que indica de que tipo es dicha notificación y otro de tipo String que representan los datos a enviar (18).
Figura 3.9 Diagrama UML Clase NotificacionPacket.
31 3.4 Descripción de la arquitectura
3.4.1 Patrones utlizados
En ingeniería del software, un patrón es una solución ya probada y aplicable a un problema que se presenta una y otra vez en el desarrollo de distintas aplicaciones y en distintos contextos. Es importante mencionar que un patrón no es en general una solución en forma de código directamente, sino una descripción de cómo resolver el problema y ante qué circunstancias es aplicable.
Patrones arquitectónicos: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas software.
Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software.
3.4.2 Patrón arquitectónico
El desarrollo de BlueConnect se basó en la arquitectura monolítica, la cual plantea el diseño del software mediante la creación de una estructura única, la cual no tiene interfaz y corresponde a una parte de un sistema, generalmente en la implementación de un proceso de negocio. Por las características de la propuesta de solución es que se utiliza esta arquitectura como base.
3.4.3 Patrones de diseño. Patrones GRASP
Directrices y principios estructurados que describen un problema común y entregan una buena solución ya probada a la que le dan un nombre (1).
Patrones GRASP (General Responsibility Assignment Software Patterns): Los patrones GRASP son patrones de diseño que describen los principios generales para asignar responsabilidades a objetos, expresados en forma de patrón.
32
Experto: Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.Creador: El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos, tarea muy frecuente en los sistemas orientados a objetos.
Bajo Acoplamiento: Acoplamiento bajo significa que una clase no depende de muchas clases.
Alta Cohesión: La cohesión es una medida de cuán relacionadas y enfocadas están las responsabilidades de una clase.
Una alta cohesión caracteriza a las clases con responsabilidades estrechamente relacionadas que no realicen un trabajo enorme.
Controlador: Un Controlador es un objeto de interfaz no destinada al usuario que se encarga de manejar un evento del sistema. Define además el método de su operación.
3.4.4 Patrones de diseño. Patrones GOF
Observador Promueve el poco acoplamiento entre un objeto sujeto y objetos observadores; un sujeto notifica a los observadores cuando éste cambia de estado. Al ser notificados, los observadores cambian en respuesta al cambio del sujeto (1; 15).
3.5 Conclusiones
En este capítulo se mostró el diagrama de clases del diseño de BlueConnect, además se hizo una descripción de las clases que lo conforman, mostrando un diagrama UML por cada una, de ellas. Se realizó la descripción de la arquitectura utilizada, haciendo énfasis en el patrón arquitectónico empleado, así como los patrones de diseño GRASP y GOF puestos en práctica. En el siguiente capítulo se explicará cómo utilizar BlueConnect, a través de un ejemplo.
33
Capítulo 4 Instalación
4.1 Introducción
En este capítulo se muestra los diagramas de componentes y de despliegue del sistema. Se describe de forma general los pasos a seguir para la utilización del BlueConnect, mostrando las normas para su uso a través de cómo ejemplo un pequeño juego de beisbol implementado con la ayuda de BlueConnect.
4.2 Modelo de Implementación de framework
El modelo de implementación describe cómo los elementos del modelo del diseño se implementan en términos de componentes y cómo estos se organizan de acuerdo a los nodos específicos en el modelo de despliegue.
4.2.1 Diagrama de Despliegue
El diagrama de despliegue muestra la distribución de los componentes de software desarrollados en el entorno donde será aplicada la solución. La siguiente figura muestra cómo será desplegado el framework en un teléfono celular para que entre ellos se pueda establecer una comunicación bluetooth.
Figura 4.1 diagrama de despliegue.
34 4.2.2. Diagrama de Componentes
El diagrama de componentes muestra las relaciones de dependencia entre las partes modulares del sistema desarrollado y encapsula la implementación. A continuación se muestran los componentes identificados y sus relaciones.
Figura 4.2 Diagrama de componentes.
4.3 Reglas para el uso de BlueConnect
Para usar correctamente el framework es necesario cumplir con ciertas reglas. A continuación se explicarán las que son fundamentales y para concluir se hará la descripción del juego de beisbol.
Una vez agregado el framework en el proyecto J2ME, la clase que hereda de MIDlet* debe implementar la interfaz BluetoothListener, al implementar dicha interfaz hay que redefinir dos métodos fundamentales que son manageConections(String action, EndPoint endpt) y manageSending(NotificacionPacket msg). El primero de ellos es el encargado de manejar los eventos referentes a la conexión de nuevos dispositivos y
35
la desconexión de los mismos, el primero se sus parámetros es el String action que indica que tipo de evento se sucedió y el segundo, EndPoint endpt es el objeto de tipo EndPoint que desencadena el evento. El otro método se invoca cuando llega una notificación, su parámetro NotificacionPacket msg es la notificación recibida.4.3.1 Descripción del juego de Beisbol
El juego de Beisbol es una variante reducida del beisbol tradicional, esta variante se juega de manera que el lanzador selecciona una de cuatro posibilidades de lanzamientos y realiza su movimiento luego el bateador selecciona una de las cuatro posibilidades de bateo y realiza también su movimiento si la selección del bateador coincide con la del pitcher entonces se le anota una carrera al bateador de lo contrario se le anota out, el ganador será el que más carreras acumule al término de una cantidad de inning previamente fijados.
4.3.2 Implementación del juego de Beisbol
El juego de beisbol que se implemento es un juego por turno. Para comenzar su implementación se crea un nuevo proyecto J2ME llamado BeisbolV1.0 al cual se le incorpora el paquete de BlueConnect. Además para el desarrollo de la lógica del juego se implementan una serie de clases que a continuación de describen:
Pantallas
Conjunto de clases que heredan de GameCanvas, tienen como objetivo mostrar información gráfica.
SplashScreen:Clase encargada de mostrar la animación de presentación del juego.
36
Figura 4.3 Diagrama UML clase SplashScreen.MenuScreen: Pantalla que muestra el menú del juego.
Figura 4.4 Diagrama UML clase MenuScreen.
MultiplayerOptions: Pantalla que muestra las opciones para el juego multiplayer, crear juego o unirse a un juego creado.
37
Figura 4.5 Diagrama UML clase MultiplayerOptions.WaitConexion: Pantalla que indica que se está esperando por las conexiones.
Figura 4.6 Diagrama UML clase WaitConexion.
JoinGame: Pantalla que indica que se está haciendo la búsqueda de dispositivos.
38
Figura 4.7 Diagrama UML clase JoinGame.FindCompleted: Pantalla que muestra el resultado de la búsqueda de dispositivos.
Figura 4.8 Diagrama UML clase FindCompleted.
BeisbolScreenLogicGame: Pantalla fundamental del juego en ella se realiza todas las operaciones del juego y se muestra el estado y estadísticas acumuladas del mismo.
39
Figura 4.9 Diagrama UML clase BeisbolScreenLogicGame.Clases que no son pantallas.
Conjunto de clases que no muestran información gráfica estas son las encargadas de ejecutar las rutinas referentes a la lógica del juego de beisbol.
SpriteLibrary: Clase que gestiona un conjunto de imágenes utilizadas para las animaciones del juego de beisbol.