Resumen del proyecto 4




descargar 419.67 Kb.
títuloResumen del proyecto 4
página8/14
fecha de publicación28.11.2015
tamaño419.67 Kb.
tipoResumen
med.se-todo.com > Derecho > Resumen
1   ...   4   5   6   7   8   9   10   11   ...   14

3Implementación.

3.1Control remoto del robot

3.1.1Aplicación cliente – servidor

3.1.1.1Servidor de Sockets en el Robot


La implementación del servidor de Sockets, se ha realizado siguiendo la arquitectura modular de la aplicación del Robot.

Para ello se ha creado un módulo nuevo “Servidor” heredando la clase “Modulo” e implementando los métodos virtuales pertinentes.



El módulo tiene una conexión entrante y una conexión saliente, por lo tanto, una cola de entrada y otra de salida respectivamente.

La cola de salida envía los comandos recibidos del servicio Web al módulo “Interprete WiFi”, que interpreta los comandos y los envía al cerebro.

La cola de entrada sirve para que el módulo “Robot Posición” escriba la posición y orientación en cada momento, y el modulo “Servidor” mantenga actualizadas las variables de clase asociadas.

El módulo “Servidor” contiene dos hilos activos en todo el ciclo de ejecución. Uno de ellos se encarga de monitorizar el servidor de Sockets, recogiendo los comandos que llegan del servicio Web y escribiéndolos en la cola de salida. El otro hilo recoge los datos del puerto de entrada y se encarga de mantener actualizadas en el “Servidor” la posición y orientación.

Para gestionar la comunicación, se ha hecho uso de la librería de Sockets que se utilizó en el proyecto anterior, pero ampliando su funcionalidad para recibir y enviar cadenas de texto con una longitud determinada.

Se ha realizado esta ampliación de la librería, ya que se debía tratar la incompatibilidad de tipos de datos entre Java y C++.

A la librería, se han incorporado los siguientes métodos:

  • int Escribe_Socket (char *Datos, int Longitud)

    Escribe en el socket una cadena de caracteres “Datos” de longitud “Longitud”.

  • int Lee_Socket (int fd, char *Datos, int Longitud)

    Lee del socket una cadena de caracteres “Datos” de longitude “Longitud”.

    La explicación de la incompatibilidad de los tipos de datos entre Java y C++, es sencilla. El código C++ compilado se ejecuta directamente sobre el procesador (Intel en nuestro caso), y su organización de memoria es “Little endian” (los bytes menos significativos ocupan la direcciones más bajas de memoria). A diferencia de Intel, la máquina virtual de Java utiliza una organización de memoria “Big endian” (los bytes menos significativos ocupan la direcciones más altas de memoria).

    Por lo tanto, se debe traducir la representación de los datos recibidos o enviados a un formato común utilizando el formato estándar de red.

El formato estándar de red utiliza la organización “Big Endian”, al igual que Java, con lo cual, en el servidor de Sockets de C++ se deben invertir los bytes antes de ser recibidos o enviados.

Afortunadamente, tanto en C de Linux como de Windows, tenemos la familia de funciones htonl().

  • htonl() pasa un entero de formato hardware a formato red (Hardware TO Network).

  • ntohl() pasa un entero de formato red a formato hardware.

    El tamaño de los tipos de datos de C++ no difiere del estándar de Red, pero en Java, la representación de caracteres con UNICODE, de dos bytes, difiere del estándar de red (un byte). El tratamiento de este problema lo explicaremos en la parte cliente.

3.1.1.2Servicio Web Java

3.1.1.2.1Introducción

La arquitectura que se definió (Cliente – Servidor), y el carácter esporádico de los datos y peticiones que debían enviarse al Robot, hizo que nos decidiéramos por la utilización del compendio de tecnologías conocido como AJAX (Asynchronous JavaScript And XML). Para conocer más sobre esta tecnología, diríjase al apéndice E.

Resulta un tanto engorroso programar y depurar código JavaScript directamente, ya que no existen buenos depuradores en la actualidad, no obstante, Google ha desarrollado un framework para aplicaciones Web con tecnología AJAX denominado “GWT” (Google Web Toolkit). Este framework, permite generar aplicaciones con la arquitectura Cliente – Servidor, enteramente escritas en Java. Durante la construcción del proyecto, GWT preprocesa el código de la parte cliente traduciéndolo a JavaScript.

GWT provee a la parte servidor de una interfaz de llamadas asíncronas, para la utilización de sus servicios por parte de los diferentes clientes.

Este hecho, unido a la facilidad de depuración de la parte cliente, ya que queda enteramente escrita en Java, nos hizo decidirnos por la utilización de esta tecnología para la implementación del servicio Web, por lo tanto, se implementaron las capas que comentamos a continuación.
3.1.1.2.2Parte Cliente – Capa de Presentación

Para la parte cliente, se ha hecho utilización enteramente de la arquitectura provista por GWT.

Toda la interfaz está basada en contenedores y widgets, con lo cual se ha hecho utilización de un patrón de diseño “Composite”.

Se ha creído conveniente la separación de los oyentes de la interfaz, ya que estos principalmente son quienes realizan las peticiones asíncronas al servidor, es decir, actúan de capa intermedia entre la interfaz gráfica y el servidor, con lo cual podríamos hablar también de un MVC con mediador, quedando el modelo encapsulado por el servidor, siendo la vista la interfaz basada en paneles y el controlador – mediador los oyentes agrupados en el paquete “listeners”.



Cabe destacar la importancia de la clase principal “MainView”, que implementa la interfaz “EntryPoint”, pilar de la arquitectura de la parte cliente en GWT, ya que es el contenedor raíz.

Una parte muy importante de la parte cliente es la generación de comandos para ser enviados de forma asíncrona al servidor, para que este a su vez los envíe vía Socket al Robot y más tarde devuelva una respuesta a la Interfaz. Ya que para solicitar una misma acción, siempre se debe enviar un mismo comando y hay una cantidad limitada y fija de estos, se ha implementado una factoría de prototipos de comandos.



Por último comentar que se ha utilizado una clase que implementa un patrón “Singleton” para gestionar posibles errores en la comunicación, y traducir estos a la interfaz, cargando el panel de controles del modo autónomo por defecto, ya que es este modo en el que se inicia la aplicación del robot. Se ha implementado así ya que son varios los oyentes que realizan peticiones asíncronas, y resulta cómodo el acceso a una clase única que gestione los errores.

Al ser la clase “ForzarAutonomo” un Singleton, se ha sincronizado la constructora y el uso de los métodos públicos, con el fin de evitar instanciación y utilización múltiple de los recursos de la clase, ya que la interfaz no se bloquea al realizar las peticiones, al ser estas asíncronas.



Siendo la responsabilidad de esta clase la de gestionar los errores de comunicación de los sockets reportados por el servicio Web, es usada por los distintos oyentes de la interfaz que realizan la comunicación asíncrona con el servicio.
3.1.1.2.3Parte Servidor – Capa de Negocio y Acceso a Datos

En este apartado, podemos hablar de cuatro subcomponentes principales, aparte de la implementación de la interfaz para el servicio asíncrono proviso a los clientes, que gestiona las llamadas del cliente a dichos subcomponentes.



Estos subcomponentes se detallan a continuación:
3.1.1.2.3.1Cliente de Sockets

El Cliente de Sockets se compone de tan solo dos clases:



Ya que solo tenemos un cliente que debe ser “invocado” desde la interfaz de servicios asíncronos y por lo tanto ser accesible por varios clientes simultáneamente, se ha creído conveniente realizar la implementación con un patrón de diseño Singleton con constructora y métodos públicos sincronizados.

Cuando se desea enviar un comando, se debe utilizar el método “enviarComandoSocket (String comando)”. Como podemos observar, se pide un parámetro de tipo “String”, que es lo que finalmente se enviará al Robot. Este hecho hace que se pueda reutilizar el cliente en cualquier servicio Web o aplicación, ya que no depende de la implementación del sistema de comandos; tan solo se deben enviar comandos con el mismo formato.

En cuanto a la incompatibilidad del tipo de dato “char” de Java con el formato de red estándar, puesto que Java utiliza dos bytes, se ha optado por hacer que sea el cliente quien convierta esos caracteres a un único byte antes de enviar y los reconvierta a dos cuando los recibe. La clase String de Java tiene métodos que permiten realizar esta acción.
3.1.1.2.3.2Control de la Batería

Para la implementación de esta funcionalidad, se reutilizó un componente diseñado precisamente para poder adaptarlo a cualquier arquitectura. Su especificación y diseño se explican en el punto 2.3.3.2, mientras que los detalles de implementación se ofrecen en el punto 3.1.2.1. Para consultar los detalles de configuración por XML en esta aplicación, es necesario leer el apartado 3.1.2.3.
3.1.1.2.3.3Servicio de Comunicación

Para este servicio se utilizó el componente “Comunicador”, diseñado de igual forma para poder reutilizarlo e integrarlo en cualquier sistema de manera fácil. Su especificación y diseño se puede consultar en el punto 2.3.3.3, mientras que los detalles de implementación se pueden ver en 3.1.2.2.

Para consultar los detalles de configuración por XML en esta aplicación, es necesario leer el apartado 3.1.2.3.
3.1.1.2.3.4Reproducción de Sonidos

3.1.1.2.3.4.1Funcionalidad

Este componente también es completamente reutilizable e integrable, y su funcionalidad viene dada por la implementación de la siguiente interfaz:



Este componente se utiliza para reproducir sonidos en la interfaz gráfica al pulsar ciertos botones, lo que la hace más intuitiva.

A continuación pasamos a definir cada una de las operaciones:

  • play

  • Entradas: ninguna

  • Salidas: ninguna

  • Efecto: reproduce el sonido que ha sido previamente cargado

  • stop

  • Entradas: ninguna

  • Salidas: ninguna

  • Efecto: detiene completamente el sonido que ha sido previamente cargado

  • pause

  • Entradas: ninguna

  • Salidas: ninguna

  • Efecto: detiene el sonido que ha sido previamente cargado en el instante de reproducción

  • resume

  • Entradas: ninguna

  • Salidas: ninguna

  • Efecto: vuelve a reproducir el sonido, que ha sido previamente cargado y pausado, en el punto donde se detuvo

  • loadFile

  • Entradas: un String con la ruta donde se halla el fichero mp3, wav o ogm

  • Salidas: ninguna

  • Efecto: carga el archivo de sonido en el componente, permitiendo la manipulación del mismo a través de las operaciones anteriores

3.1.1.2.3.4.2Implementación

El diagrama de clases del diseño es muy básico: consta únicamente de una clase que implementa la interfaz recién definida, ayudándose de la API de una librería.



3.1.1.2.3.4.3Librerías utilizadas

Para este componente se ha usado la librería “JLGUI”, que permite manipular sonidos a través de su clase “BasicPlayer”. Se realizaron también diversos prototipos antes de crear el componente. Se puede encontrar información acerca de su API en http://www.javazoom.net/jlgui/api.html.

3.1.2Aplicación para alertar al técnico en caso de nivel bajo de batería.

3.1.2.1Componente “Batería”

3.1.2.1.1Funcionalidad

Ya en el diseño hemos descrito la interfaz implementada por este componente. En este apartado vamos a describir las distintas operaciones:

  • getEstadoBateria

  • Entradas: ninguna

  • Salidas: un String cuyo contenido indica en qué rango se encuentra el nivel de batería

  • Efecto: realiza una consulta sobre el nivel de la batería

  • getPorcentajeBateria

  • Entradas: ninguna

  • Salidas: un entero entre [0,100] que indica el nivel de la batería en tanto por ciento

  • Efecto: realiza una consulta sobre el nivel de la batería
3.1.2.1.2Implementación

El diagrama de clases que ilustra la implementación seguida para este componente es el siguiente:



La implementación se basa en el uso de una clase llamada “Kernel32” y una clase interna llamada “SYSTEM_POWER_STATUS”. Básicamente la clase “Kernel32” maneja la librería dinámica con el mismo nombre, permitiendo de esta forma hacer llamadas a la dll (Dynamic Linking Library) mediante código nativo Java.

La clase “SYSTEM_POWER_STATUS” es la clave de este componente. Emula la estructura interna donde reside toda la información acerca de la batería y su estado:



Todos estos campos poseen información sobre el estado del nivel de carga. Esta información es la que obtienen los métodos implementados por el componente “Batería”. Por ejemplo, el atributo “BatteryLifePercent” posee la información en tanto por ciento de la capacidad restante para la batería.
3.1.2.1.3Librerías utilizadas

Todo esto se realiza mediante la librería JNA (Java Native Access), que permite accesos a librerías nativas, pero manejando código puramente en Java. Es necesario decir que las pruebas realizadas en ordenadores portátiles han sido totalmente satisfactorias; sin embargo, en el PCBox del robot no ha sido así, debido seguramente a un distinto control de la placa base de este tipo de ordenador para obtener los datos sobre la batería disponible.

Más información al respecto de estas librerías en https://jna.dev.java.net/.

3.1.2.2Componente “Comunicador”

3.1.2.2.1Funcionalidad

Al haber visto el diseño en apartados anteriores, pasamos a describir detalladamente las operaciones:

  • enviarSMS

  • Entradas: un String para el nombre de usuario, otro String para la contraseña y otro String para el mensaje corto (máximo 60 caracteres)

  • Salidas: un entero que indica si se envió correctamente el sms (0) o si hubo algún problema en el envío (-1)

  • Efecto: la aplicación se conecta con el servicio de Google, verifica el usuario y contraseña y realiza el envío al número de teléfono móvil configurado en Google Calendar

  • enviarMail

  • Entradas: un String para la dirección de correo origen, otro String para la contraseña, otro String con el contenido del e-mail, otro String con la dirección de correo destino y un último String con el asunto del mensaje

  • Salidas: un entero que indica si se envió correctamente el sms (0) o si hubo algún problema en el envío (-1)

  • Efecto: la aplicación se conecta con el servidor adecuado, verifica el usuario y contraseña y realiza el envío a la dirección de correo especificada
3.1.2.2.2Implementación

A continuación se muestra el diagrama de clases para la implementación interna de este componente:



Como se puede observar, la clase que implementa la interfaz descrita, define las operaciones de ésta utilizando dos APIs que se pasan a explicar a continuación.
3.1.2.2.3Librerías utilizadas

En la implementación de este componente se hace uso de dos librerías:

  • JavaMail: se trata de una librería que ofrece servicios para gestionar cuentas de correo. Por simplicidad, el único servidor disponible para enviar mails es el de GMail, aunque modificando la implementación esto se puede hacer extensible a otros servidores. Esto supone que la cuenta de correo del remitente, así como la contraseña asociada, deben aparecer en el XML de configuración con valores válidos para una cuenta de GMail. Más información sobre su API en http://java.sun.com/products/javamail/

  • API Google: Google pone a disposición de los desarrolladores su API (http://code.google.com/apis/). Entre todos los servicios, decidimos utilizar la API de Google Calendar, ya que posee un servicio de alertas para teléfonos móviles. Desde Google Calendar es necesario configurar el número de teléfono móvil asociado a la cuenta Google. Esta cuenta es la que debe aparecer definida en el fichero de configuración XML para el técnico.


3.1.2.3Configuración


Como ya se ha explicado, tanto en la aplicación cliente – servidor para controlar el robot remotamente como en la aplicación de alertas, es necesaria una configuración por XML para permitir el cambio de ciertos parámetros sin necesidad de recompilar el proyecto entero. A continuación vemos la configuración XML para cada aplicación:
3.1.2.3.1Aplicación cliente – servidor



  • En primer lugar, vemos que se debe configurar el mail del técnico. Este mail puede estar alojado en cualquier servidor. A él llegarán todos los avisos emitidos a través de la aplicación de control remoto del robot.

  • En segundo lugar, es necesario tener creada una cuenta en GMail si se desean recibir los avisos a través de SMS. Esto es debido a que se utiliza el servicio GCalendar con alertas via SMS. Se dan más detalles acerca de esto en el punto 3.1.2.3.3. Como se puede observar, es necesario indicar en la configuración tanto el nombre de la cuenta GMail como la contraseña.

  • Finalmente, para esta aplicación es necesario especificar el puerto usado por la aplicación para habilitar la conectividad. Es un parámetro de desarrollo, principalmente.
3.1.2.3.2Aplicación de alertas



  • En primer lugar, vemos que se debe configurar el mail del técnico. Este mail puede estar alojado en cualquier servidor. A él llegarán todos los avisos emitidos a través de la aplicación de control remoto del robot.

  • En segundo lugar, es necesario tener creada una cuenta en GMail si se desean recibir los avisos a través de SMS. Esto es debido a que se utiliza el servicio GCalendar con alertas via SMS. Se dan más detalles acerca de esto en el punto 3.1.2.3.3. Como se puede observar, es necesario indicar en la configuración tanto el nombre de la cuenta GMail como la contraseña.

  • Finalmente, para esta aplicación es necesario especificar el límite para el nivel de la batería en tanto por ciento. De esta manera, podremos recibir las alertas cuando el robot alcance el límite deseado.
3.1.2.3.3Configuración de alertas para móviles

En los puntos anteriores se ha comprobado que en la configuración es necesario declarar una cuenta de GMail y su contraseña asociada si se desea recibir alertas via SMS. Esto es debido al uso que se hace del servicio GCalendar de Google.

Este servicio permite añadir “notas de aviso” personales, y configurar avisos para recibir SMS cuando llegue la fecha anotada. Lo que nuestro componente “Comunicador” hace es utilizar esta funcionalidad para guardar un nuevo aviso en GCalendar un minuto después de la hora a la que se ha realizado la petición.

Así, unos instantes después, si se han configurado correctamente las alertas para móviles en GCalendar, se recibe el mensaje corto en el móvil con el asunto de la tarea anotada.

Mostramos a continuación una sencilla guía para configurar correctamente nuestro número de teléfono móvil en el servicio GCalendar:



  • Al acceder a la página, obtendremos una pantalla como esta:



Pincharemos entonces sobre la pestaña “Configuración” de la parte superior (marcada en rojo) y obtendremos la siguiente página en la secuencia:



Pincharemos entonces sobre la pestaña “Configuración para móviles” (marcada en rojo) para configurar nuestros avisos de GCalendar, de forma que podamos recibir las notificaciones en nuestro teléfono via SMS.

  • En esta página deberemos completar la información requerida, en el siguiente orden (secuencia marcada en rojo):



  • Primero introducimos el número de teléfono donde queremos recibir las alertas (1).

  • Después pulsamos el botón “Enviar código de verificación” (2). Tras unos instantes, recibiremos dicho código en nuestro móvil.

  • Introducimos el código recibido en el campo habilitado para ello (3).

  • Pulsamos el botón “Finalizar configuración” (4), que se iluminará cuando el código introducido sea auténtico.

  • Finalmente pulsamos el botón “Guardar” (5), que mantendrá los cambios realizados.

Con estos sencillos pasos, por lo tanto, habremos configurado nuestro teléfono móvil para la recepción de alertas a través del servicio de GCalendar y, consecuentemente, podremos recibir los mensajes emitidos por las aplicaciones que utilicen el componente “Comunicador”.

3.1.3Problemas encontrados


El principal problema fue la familiarización con tecnologías y librerías nuevas para la realización de pruebas. Una vez hechas algunas probatinas, se realizó un diseño de forma que se crearan los dos componentes descritos. De esta manera, se permitiría su reutilización, así como una gran flexibilidad a la hora de aumentar su funcionalidad.

Es necesario indicar que el componente “Batería” funciona sobre cualquier ordenador portátil; sin embargo, la funcionalidad no se mantiene sobre el PCBox del robot debido, seguramente, a diferencias sustanciales en las distintas placas base.

Además, el componente “Comunicador” a veces no funcionó dentro de la Facultad de Informática, debido a un problema de infraestructura, ya que en la Facultad la conexión WiFi es muy inestable. Esto no permite conectar de manera robusta con los servicios remotos. Las pruebas realizadas con conexiones fiables han resultado satisfactorias en un 100% de los casos.

Se llevaron a cabo dos prototipos en paralelo, uno para el uso del componente “Batería” y otro para el componente “Comunicador”. Una vez hecho esto, la integración tanto dentro del servidor como dentro de esta aplicación de alertas fue trivial.

En cuanto a la comunicación Socket, surgieron problemas a la hora de integrar una librería de Sockets de alto nivel (Solar Sockets) con la arquitectura del robot, que finalmente no se utilizó, realizando una implementación propia, ampliando la funcionalidad de la libraría de Sockets del proyecto anterior.
1   ...   4   5   6   7   8   9   10   11   ...   14

similar:

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResumen del proyecto

Resumen del proyecto 4 iconResúmen del Proyecto

Resumen del proyecto 4 iconResumen ejecutivo del proyecto 7

Resumen del proyecto 4 iconResumen del proyecto y caracteristicas del sitio

Resumen del proyecto 4 iconResumen el proyecto de investigación se centró en el estudio del aceite esencial de

Resumen del proyecto 4 iconResumen El diseño, desarrollo y divulgación de cocinas solares de...

Resumen del proyecto 4 iconEsquema de proyecto feria de ciencias denominación del proyecto (nombre)

Resumen del proyecto 4 iconResumen El presente proyecto surge como una necesidad de aplicar...


Medicina



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