Resumen del proyecto 4




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

2.3Control remoto del robot

2.3.1Introducción


El robot, al tratarse de un sistema autónomo y no poseer una consola de control integrada, ni un monitor visual, necesita un sistema con interfaz gráfica, que permita controlarlo remotamente.

Con el nuevo control remoto del robot se pretende mejorar la comunicación existente entre este y el robot, para ello debíamos abordar los siguientes problemas:

  • Perdida de paquetes de datos en la conexión y por lo tanto la perdida de envío de algunos comandos.

  • Perdida frecuente de la conexión establecida.

  • Tratamiento de la información enviada por el Robot al control remoto

  • Posibilidad de control remoto multiplataforma, de modo que pueda ejecutarse tanto en PC’s normales como en dispositivos móviles.

    No debemos olvidar, que el control remoto no es más que un mero sistema de dirección, con lo cual, se pretende imitar la funcionalidad de un Joystic, pero siempre pendientes de la posibilidad de añadir nuevas funcionalidades, es decir, de hacer el control remoto extensible.



En el proyecto heredado de anteriores cursos se había desarrollado un pequeño servidor de Sockets en C, pero no resultó ser realmente operativo, ya que la conexión se desconectaba con demasiada frecuencia. Por esto, decidimos realizar un sistema robusto a la vez que flexible en Java que permitiese conectar con el robot y ejecutar distintos servicios del mismo desde un terminal remoto.

Para llegar a este fin, surgieron dos nuevos objetivos: realizar una aplicación cliente – servidor en Java, y crear un módulo dentro de la arquitectura del robot que atendiese las peticiones del cliente.

Se barajaron varias posibilidades para el diseño e implementación del nuevo servicio. En la siguiente ilustración se muestran dichas opciones:



Se partía de la opción número uno, ya que era el trabajo implementado anteriormente y que debíamos sustituir.

Las opciones restantes suponían la construcción de un servicio Web en Java, utilizando la tecnología AJAX. Este punto se tuvo claro desde el principio, ya que permitiría tener control absoluto del robot de una manera limpia mediante cualquier dispositivo conectado de manera inalámbrica con el robot: esto incluye tanto a un PC como a una PDA o cualquier dispositivo móvil con tecnología WiFi y un navegador Web integrados, siendo además Java independiente de la plataforma, pudiendo instalar el servicio web en cualquier sistema operativo. De este modo se continúa el requisito del proyecto de partida, en el que se especificaba que el sistema debía ser multiplataforma.

Tan sólo quedaba decidir cómo se interconectarían de forma local, la aplicación servidor Java y el software de alto nivel del robot en C++.

La opción dos era la más sencilla, ya que suponía realizar la comunicación vía Sockets de forma local entre un cliente Java y un servidor C++. Además minimizaba los riesgos tecnológicos, al ser una tecnología conocida por los integrantes del proyecto y realizarse de forma local, suponiendo una conexión más fiable que la primera opción.

La opción tres suponía la implementación de una aplicación intermedia en Java con conexión directa a un módulo del robot utilizando JNI (Java Native Interface) y la comunicación a través de la máquina virtual de java del servicio Web con dicha aplicación. Desconocíamos la posibilidad de comunicar dos aplicaciones Java mediante la máquina virtual utilizando memoria compartida, y la línea de investigación sobre esta posibilidad derivó a la comunicación de las dos aplicaciones Java con Sockets. De esta nueva idea surgió la cuarta opción.

Finalmente se eligió la segunda opción, ya que se obtenía una mayor independencia del código Java y C++, y evitábamos riesgos tecnológicos.

El diseño de esta arquitectura permite ampliar fácilmente la funcionalidad del servicio Web, dotando de una gran flexibilidad al uso del robot.

2.3.2Aplicación cliente-servidor


Para la realización de esta aplicación, nos hemos apoyado en la arquitectura cliente-servidor, utilizando una metodología de diseño basada en capas. Los casos de uso se han ido desarrollando a medida que surgían nuevas necesidades o nuevas ideas para el uso de robot.

2.3.2.1Arquitectura cliente-servidor


Esta arquitectura consiste básicamente en que un programa –el cliente- realiza peticiones a otro programa -el servidor- que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora, es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras, aumentando así el grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

2.3.2.2Diseño basado en capas


La calidad tan especial de la arquitectura basada en capas consiste en aislar la lógica de la aplicación y en convertirla en una capa intermedia bien definida.

En el sistema del servicio Web se han definido tres capas claramente diferenciadas:

  • Capa de presentación

  • Capa de negocio

  • Capa de datos

Se ha integrado la interfaz web y el modelo en un mismo servidor aunque conservando su independencia funcional. Ésta es la distribución en capas más común en las aplicaciones web.



La capa de presentación, al tratarse de una aplicación con la utilización de la tecnología AJAX, aprovecha la potencia de procesamiento de las máquinas cliente, sin sobrecargar el servidor, haciendo peticiones asíncronas cuando necesita realizar cambios u obtener información del modelo de datos, a través de la interfaz de servicios asíncronos de la capa de negocio.

La capa de presentación por lo tanto, gestiona en la máquina del cliente todas las actualizaciones entre las diferentes vistas, sin necesidad de intervención de la capacidad de procesamiento del servidor.

La capa de datos en sí, puede parecer inexistente en nuestra arquitectura, al no tratarse de una base de datos con un modelo de persistencia en la capa de negocio. No obstante, se considera el software de alto nivel del robot como el “ente” que aporta la información al modelo a través del servicio de Sockets.

Decir también, que cada una de las funcionalidades añadidas al servicio web, tales como el control de carga de la batería, la funcionalidad de alertas, o la configuración con ficheros XML, aportan su propia capa de datos, ya sea remota, local o aportada por el propio sistema operativo, con lo cual, podemos hablar de una capa de datos múltiple.

Tal y como muestra la ilustración del diseño basado en capas y como es característica habitual en un servicio Web, se permiten varias conexiones simultaneas, con lo cual en este caso, podría haber varios clientes remotos controlando el Robot en un momento determinado. Esto podría suponer un problema, ya que un usuario podría observar comportamientos anómalos provocados por el control de otra consola sin tener conocimiento de su existencia. No obstante la consola remota diseñada en nuestro proyecto, partía de la precondición de mantener tan sólo un cliente que debía estar en presencia del robot.

En el apartado de trabajo futuro, se muestran las ventajas, potencia y posibles ampliaciones de funcionalidad habiendo utilizado para el control remoto un servicio Web.

2.3.2.3Casos de uso de la aplicación


Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final.

En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Los casos de uso para esta aplicación se han pensado por entero para interactuar con el robot guía, aunque algunos de ellos podrían ser ejecutados en un terminal cualquiera. Pasamos a continuación a ver la descripción de cada uno de los casos de uso contemplados.

  • [CASO DE USO - 1]: OBTENER EL ESTADO DE LA BATERÍA

  • Objetivo: Obtener un informe sobre el estado de la batería del robot

  • Entradas: Ninguna

  • Precondiciones: Ninguna

  • Salidas: Mensaje informativo con el estado de la batería, además de un sonido

  • Postcondición si éxito: Ninguna

  • Postcondición si fallo: Ninguna

  • Actores: Cliente y Servidor

  • Secuencia normal:

El actor selecciona la opción de consultar estado de batería

Aparece un mensaje informando acerca del estado de la batería y un sonido

  • Secuencia alternativa:

El actor selecciona la opción de consultar estado de batería

Aparece un mensaje indicando que no ha sido posible conectar, en caso de error

  • Requisitos no funcionales: conectividad entre el cliente y el servidor. Además, la consulta sobre el estado de la batería debe ser compatible con el terminal donde esté alojado el servidor.



  • [CASO DE USO - 2]: COMUNICARSE CON EL TÉCNICO RESPONSABLE

  • Objetivo: Comunicarse con el técnico responsable, enviándole un mensaje vía e-mail y/o sms a su móvil

  • Entradas: Elección de envío del mensaje a través de email y/o sms, y elección del asunto del mensaje

  • Precondiciones: La cuenta de GMail del técnico debe haberse configurado correctamente en el fichero XML. Si desea poder recibir SMS a su número de móvil, debe configurar además su cuenta de GCalendar. Se dan detalles más concretos acerca de esto en 3.1.2.2.3.

  • Salidas: Mensaje para elegir la forma y el asunto de envío del mensaje

  • Postcondición si éxito: El técnico recibe el mensaje en forma de mail y/o sms

  • Postcondición si fallo: El técnico no recibe el mensaje

  • Actores: Cliente, Servidor y Técnico

  • Secuencia normal:

El actor selecciona la opción de enviar un mensaje al técnico

Aparece una ventana para seleccionar el tipo de mensaje

Se pulsa el botón “Enviar”

Aparecen ventanas confirmando los envíos junto a unos sonidos

El técnico recibe los avisos

  • Secuencia alternativa:

El actor selecciona la opción de enviar un mensaje al técnico

Aparece una ventana para seleccionar el tipo de mensaje

Se pulsa el botón “Enviar”

Aparecen ventanas indicando que no se han podido realizar el envío, junto a unos sonidos

El técnico no recibe el aviso

  • Requisitos no funcionales: conectividad entre cliente y servidor. El técnico debe tener su cuenta de correo de GMail configurada correctamente para recibir avisos por sms. Además esta cuenta debe aparecer en el XML de configuración.



  • [CASO DE USO - 3]: CAMBIAR EL MODO DE EJECUCIÓN DEL ROBOT

  • Objetivo: Alternar entre el modo Usuario y el modo Autónomo de ejecución del robot.

  • Entradas: Modo al que se desea cambiar.

  • Precondiciones: Ninguna

  • Salidas: Mensaje informativo con el resultado del cambio.

  • Postcondición si éxito: Se cambia al modo deseado.

  • Postcondición si fallo: Si no hay conexión WiFi, ninguna. Si hay conexión WiFi pero no Socket, se fuerza el modo autónomo.

  • Actores: Cliente, Servidor y Robot.

  • Secuencia normal:

El Actor Cliente selecciona el modo de ejecución nuevo.

Se envía en forma de comando el modo nuevo por Sockets al Robot.

El Robot responde con el comando que se le envió y ejecuta la acción pertinente.

El Servidor comprueba que la cadena recibida es igual a la que se envió y se muestra el mensaje en consecuencia.

Se conmuta a la interfaz de usuario para el modo nuevo.

  • Secuencia alternativa:

El Actor Cliente selecciona el modo de ejecución nuevo.

Si no se puede comunicar el Servidor, se muestra un mensaje de error.

Si se conecta con el Servidor pero no con el Robot, se supone que este no está en ejecución, y se fuerza la interfaz de usuario en modo automático mostrando un mensaje, ya que será el estado inicial del Robot al ser reiniciado.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor y entre el servidor y el robot.



  • [CASO DE USO - 4]: ENVIAR COMANDOS EN MODO AUTÓNOMO AL ROBOT

  • Objetivo: Enviar los comandos de ejecución en modo automático al robot.

  • Entradas: Comando que se desea enviar. Este comando podrá ser: Terminar, Presentación, Guía, Posición u Orientación.

  • Precondiciones: El robot debe encontrarse en modo autónomo.

  • Salidas: Mensaje informativo con el resultado del envío del comando.

  • Postcondición si éxito: El Robot ejecuta el comando enviado.

  • Postcondición si fallo: Se muestra un mensaje de error en la consola.

  • Actores: Cliente, Servidor y Robot.

  • Secuencia normal:

El Actor Cliente selecciona el comando a enviar, rellenando la información pertinente.

Se envía el comando por Sockets al Robot.

El Robot responde con el comando que se le envió y ejecuta la acción pertinente.

El Servidor comprueba que la cadena recibida es igual a la que se envió y se muestra el mensaje en consecuencia.

  • Secuencia alternativa:

El Actor Cliente selecciona el comando a enviar, rellenando la información pertinente.

Si no hay conexión con el servidor o con el robot, se muestra un mensaje de error.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor y entre el servidor y el robot.



  • [CASO DE USO - 5]: ENVIAR COMANDOS EN MODO USUARIO AL ROBOT

  • Objetivo: Enviar los comandos de ejecución en modo usuario o manual al robot.

  • Entradas: Comando direccional que se desea enviar (Avanzar, Retroceder, Girar, Rotar, etc.).

  • Precondiciones: El robot debe encontrarse en modo usuario.

  • Salidas: Mensaje informativo con el resultado del envío del comando.

  • Postcondición si éxito: El Robot ejecuta el comando enviado.

  • Postcondición si fallo: Se muestra un mensaje de error en la consola.

  • Actores: Cliente, Servidor y Robot.

  • Secuencia normal:

El Actor Cliente selecciona el comando a enviar.

Se envía el comando por Sockets al Robot.

El Robot responde con el comando que se le envió y ejecuta la acción pertinente.

El Servidor comprueba que la cadena recibida es igual a la que se envió y se muestra el mensaje en consecuencia.

  • Secuencia alternativa:

El Actor Cliente selecciona el comando a enviar.

Si no hay conexión con el servidor se muestra un mensaje de error.

Si se conecta con el Servidor pero no con el Robot, se supone que este no está en ejecución, y se fuerza la interfaz de usuario en modo automático mostrando un mensaje, ya que será el estado inicial del Robot al ser reiniciado.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor y entre el servidor y el robot.



  • [CASO DE USO - 6]: CONOCER LA POSICIÓN U ORIENTACIÓN ACTUAL DEL ROBOT

  • Objetivo: Conocer la posición o la orientación actuales del robot.

  • Entradas: Comando especial que no requiere ACK, sino la información requerida del Robot.

  • Precondiciones: ninguna.

  • Salidas: Mensaje informativo con la información requerida.

  • Postcondición si éxito: Se muestra la posición o la orientación en la consola.

  • Postcondición si fallo: Se muestra un mensaje de error en la consola.

  • Actores: Cliente, Servidor y Robot.

  • Secuencia normal:

El Actor Cliente selecciona el comando a enviar (Orientación o Posición).

Se envía el comando por Sockets al Robot.

El Robot responde con la información pertinente dependiendo del comando enviado.

El Servidor muestra por pantalla dicha información.

  • Secuencia alternativa:

El Actor Cliente selecciona el comando a enviar (Orientación o Posición).

Si no hay conexión con el servidor o con el robot, se muestra un mensaje de error.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor y entre el servidor y el robot.



  • [CASO DE USO - 7]: REALIZAR UN TEST DE LAS CONEXIONES

  • Objetivo: Conocer el estado de las conexiones, tanto WiFi como Socket.

  • Entradas: Comando especial de test de conexión.

  • Precondiciones: ninguna.

  • Salidas: Mensaje informativo la información del estado de cada una de las conexiones.

  • Postcondición si éxito: Se muestra un mensaje del estado de las conexiones OK.

  • Postcondición si fallo: Se muestra un mensaje con la causa de no funcionamiento del WiFi o los Sockets.

  • Actores: Cliente, Servidor y Robot.

  • Secuencia normal:

El Actor Cliente selecciona el comando “test”.

Se envía el comando por Sockets al Robot.

El Robot responde con un ACK igual al comando enviado.

El Servidor Envía al cliente WiFi: OK; Sockets OK.

  • Secuencia alternativa:

El Actor Cliente selecciona el comando “test”.

Si no hay conexión con el servidor se muestra un mensaje informativo de que no hay conexión WiFi.

Si no hay conexión con el robot, se muestra “WiFi: OK” y se informa de la causa de error de la conexión Socket.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor y entre el servidor y el robot.



  • [CASO DE USO - 8]: MOSTRAR AYUDA DEL SERVICIO WEB EN EL CLIENTE

  • Objetivo: Mostrar una breve ayuda sobre la utilización del servicio Web.

  • Entradas: ninguna.

  • Precondiciones: ninguna.

  • Salidas: Mensaje informativo en consola de los comandos de modo autónomo, así como un panel con la ayuda extendida.

  • Postcondición si éxito: Se muestra la ayuda en consola y en un panel externo.

  • Postcondición si fallo: ninguna.

  • Actores: Cliente.

  • Secuencia normal:

El Actor Cliente pulsa el botón de ayuda.

Se muestra un panel con la ayuda en HTML y un resumen de los comandos automáticos en la consola.

  • Secuencia alternativa: Ninguna.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor.



  • [CASO DE USO - 9]: LIMPIAR LA CONSOLA DE MENSAJES

  • Objetivo: Resetear la consola de información del servicio Web, eliminando todos los mensajes antiguos.

  • Entradas: ninguna.

  • Precondiciones: ninguna.

  • Salidas: Consola vacía.

  • Postcondición si éxito: Se borra la consola.

  • Postcondición si fallo: ninguna.

  • Actores: Cliente.

  • Secuencia normal:

El Actor Cliente pulsa el botón de limpiar.

Se resetea la consola, borrando todos los mensajes anteriores.

  • Secuencia alternativa: Ninguna.

  • Requisitos no funcionales: conectividad entre el cliente y el servidor.

2.3.2.4La interfaz gráfica


El diseño de una interfaz gráfica debe conllevar un uso sencillo, amigable, intuitivo y accesible, a la par de ser usable e implementar toda la funcionalidad que se le requiere.

Para la capa de presentación del servicio Web, se ideó una interfaz dividida en paneles, con funcionalidades claramente diferenciadas.

Los casos de uso especifican el envío de comandos en modo autónomo o en modo usuario, la utilización de una consola con herramientas para su gestión y comandos que pueden enviarse en cualquier momento, como los controles de batería, la consulta de la posición, etc. Por lo tanto se ha diseñado una interfaz dividida en 4 partes:

La mitad izquierda contiene un panel de pestañas, en el que eligiendo una u otra, se alterna entre los modos “Autónomo” y “Usuario”, cada uno con su funcionalidad específica.

La mitad derecha, queda dividida en tres partes. La parte superior, Se utiliza como consola de texto para “logging”, la parte intermedia para los controles que manipulan directamente dicha consola, y la parte inferior para los comandos especiales.

Además, se incluye un titulo en la parte superior, y una barra de estado en la parte inferior de la interfaz.



Se ha obtenido un diseño amigable y accesible, gracias a la utilización de textos alternativos en cada uno de los paneles y componentes de la interfaz. Esta cualidad hace que la interfaz, puramente gráfica, pueda ser interpretada por lectores de pantalla y por consiguiente utilizada por personas con visibilidad reducida.



La interfaz es usable gracias a la consola de texto y una correcta gestión de errores, ya que en ella se muestra toda la información acerca del estado de la interfaz, con lo cual el usuario en todo momento sabe lo que está sucediendo, quedando oculto todo detalle interno del servidor.

Otro aspecto muy importante de las interfaces gráficas, es una elección correcta de los colores, ya que debe ser igualmente usable y correctamente interpretada tanto en color, como en blanco y negro. Nuestra aplicación sería perfectamente usable sin color, ya que las ilustraciones con texto alternativo identifican perfectamente cada una de las funcionalidades.

Por último, se debe mencionar, que los controles que activan las funcionalidades más usadas, se encuentran en las zonas externas o alejadas del centro de la interfaz, ya que es en dichos lugares, donde los usuarios tienen más facilidad de dirigir el puntero del ratón. Si no es así, como en el caso del botón “Enviar Comando” del panel de controles del modo automático, se ha aumentado considerablemente el tamaño del control para un acceso más sencillo a dicho botón.

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


Además de realizar una aplicación cliente – servidor que hiciera las funciones de un mando a distancia para el robot, decidimos realizar una aplicación extra, que dota de más independencia a su gestión.

La aplicación comprueba constantemente y cada cierto tiempo el estado de la batería en el terminal, y cuando detecta que ésta presenta un nivel de carga inferior al permitido (parámetro configurable por XML), envía un sms y un mail al técnico responsable, cuya dirección de correo electrónico es también configurada por XML. Además, emite un sonido de alarma por si surgiera algún problema en el envío. Vemos un intuitivo gráfico que nos aclara el funcionamiento de esta aplicación de alertas:



Como se puede intuir, en esta aplicación se reutilizan algunos servicios de la aplicación web basada en la arquitectura cliente – servidor explicada en el punto anterior 2.3.2, como la consulta de batería disponible o el envío de mensaje. Esto ha sido posible debido al buen diseño realizado, basado en componentes y servicios claramente definidos a través de las distintas interfaces.

Es digno de mencionar, igualmente, que esta aplicación es perfectamente operativa en cualquier otro terminal. Un usuario normal puede utilizarla para su ordenador portátil, siendo notificado via mail y sms el estado de la batería cuando alcanza un límite, también configurado por XML. Todos estos detalles de configuraciones se detallan en el punto 3.1.2.3.

2.3.3.1Componentes


Algunos criterios técnicos para un buen diseño son:

  • Un diseño debe presentar una estructura arquitectónica que

  • Se haya creado mediante patrones de diseño reconocibles.

  • La integren componentes que exhiban buenas características de diseño.

  • Que pueda implementarse de manera evolutiva para que de estar forma facilite la implementación y las pruebas.

  • Un diseño debe ser modular.

  • Un diseño debe conducir a componentes que representan características funcionales independientes.

El diseño del proyecto en general, y de esta aplicación en particular, se ha basado en estas características. Este diseño basado en componentes nos permite, por un lado, realizar una implementación fácil de depurar y, por otro, al ser entidades funcionales independientes, reutilizarlos en otras aplicaciones (como ocurre en este caso). En el siguiente diagrama vemos la relación entre los componentes de la aplicación:



Pasamos a continuación a describir el aspecto de los componentes reutilizados en esta aplicación, que a la vez se usan en el servicio web descrito en el apartado 2.3.2:

2.3.3.2El componente “Bateria”


  • Aspecto del módulo



Como se puede observar en el siguiente gráfico, el componente implementa una funcionalidad definida según la interfaz “ItfBateria”.

  • Funcionalidad

El componente posee la funcionalidad especificada por su interfaz “itfBateria”, la cual posee las siguientes operaciones:



Ambas operaciones son necesarias para controlar en todo momento el estado de la batería del terminal que las invoca. Este componente es perfectamente reutilizable, ampliable e integrable en cualquier arquitectura modular.

2.3.3.3El componente “Comunicador”


  • Aspecto del módulo

El aspecto de este módulo es muy similar al del anterior:



La diferencia principal radica en la interfaz implementada ItfComunicador.

  • Funcionalidad

La funcionalidad de este módulo permite enviar un correo electrónico o un mensaje de texto según los parámetros requeridos. Los detalles de implementación se facilitarán en el apartado 3. Las operaciones ofrecidas por la interfaz son:



El diseño realizado en este módulo también ha sido pensado para que pueda ser reutilizado, ampliado o perfectamente integrado en cualquier arquitectura, como ocurre en este mismo proyecto.

2.3.1Sockets


El diseño de los Sockets, incluye tanto el diseño de un cliente en la parte del servicio Web como el rediseño y la implementación de un servidor de Sockets en el sistema de alto nivel del robot.

2.3.1.1El componente servidor Socket en el Robot


El servidor existente y que debíamos mejorar, utilizaba dos servidores de Sockets, uno de recepción y uno de envío, y mantenía una conexión durante todo el ciclo de ejecución con la consola remota que se utilizaba.

En nuestro caso, dados los requisitos funcionales y los casos de uso que se desprenden de ellos, tan sólo era necesaria una conexión entrante con respuestas atómicas a las peticiones, y dado el caracter esporádico de los comandos que se recibían, no resultaba interesante mantener una conexión activa.

Una conexión activa permanente es más robusta y eficiente, pero no se adaptaba a los requerimientos de nuestros casos de uso, además de suponer un inconveniente la recuperación de la conexión, si ocurre algún problema en alguno de los componentes del sistema.

Desde otro punto de vista, una conexión activa también permitiría enviar datos de forma asíncrona del servidor de Sockets del Robot al cliente de Sockets de Java y por lo tanto a los diferentes clientes web que pudieran estar conectados al servicio. Esto sería interesante de cara a un control remoto desatendido, es decir, sin estar personado ante el propio robot. No obstante el objetivo del proyecto era mejorar la comunicación de la consola remota existente, implementándola de modo que la conexión fuera más fiable.

Además, con la implementación actual no sería necesario un envío de datos asíncrono por parte del Robot, ya que al estar en presencia del robot, siempre se debería conocer donde está. A pesar de ello, se han integrado dos opciones en el Servicio Web para conocer la orientación y posición del Robot en cada momento.

En el apartado de trabajo futuro se explican detalladamente las ventajas de un servicio de Sockets orientado a conexión.

Con el diseño seguido, si termina la ejecución del Servicio Web que contiene el cliente de Sockets, no supone ningún problema para el ciclo de ejecución del Robot.

Con lo cual, el servidor esta diseñado para, una vez activado, quedar a la espera de comandos entrantes. Una vez llega un comando, se crea una conexión, se procesa, se envía la respuesta y se desconecta, quedando a la espera de nuevos comandos.

Existen dos comandos que requieren respuesta especial, tales como la consulta de posición y orientación actuales del robot. Para ello, se ha hecho utilización de la arquitectura del Robot para crear una conexión con el módulo “Robot Posición” con el fin de mantener actualizada en varias variables la información requerida por dichos comandos.

2.3.1.2El componente cliente Socket en el Servicio Web


El cliente de Sockets, debe ser acorde al diseño del servidor de Sockets, aunque con el nuevo diseño de este, son prácticamente independientes, pudiendo sustituir fácilmente tanto el cliente como el módulo servidor en el robot, siempre que los comandos enviados sean los mismos.

En el diseño heredado eran mucho más dependientes los módulos cliente y servidor entre si, ya que debían mantener una conexión activa con dos clientes Socket y dos Servidores Socket (uno de recepción y uno de envío) respectivamente.

De forma análoga al Servidor, el cliente conecta con el servidor, envía un comando, recoge la respuesta y cierra la conexión. Si el programa del Robot finaliza por cualquier causa y se intentan enviar comandos, al no poder establecer la conexión con el servidor de Sockets, se muestra por consola el mensaje de error pertinente, con lo que el usuario podrá avisar a un técnico de la anomalía en el funcionamiento del sistema, utilizando por ejemplo, la funcionalidad de alertas por correo electrónico o SMS.
1   2   3   4   5   6   7   8   9   ...   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