Desarrollo de Aplicaciones Colab

Document Sample
Desarrollo de Aplicaciones Colab Powered By Docstoc
					Desarrollo de Aplicaciones Colaborativas con CoopTEL: El Juego del Pictionary
Juan Antonio Campos1, Mónica Pinto2
Dpto. Lenguajes y Ciencias de la Computación, Universidad de Málaga. 1 waka@ole.com, 2pinto@lcc.uma.es

Resumen. La creciente evolución en la complejidad de las aplicaciones colaborativas no ha hecho sino impulsar la utilización de nuevas tecnologías software, como las basadas en componentes y aspectos. El principal objetivo de este artículo es mostrar nuestra experiencia en el desarrollo de software basado en componentes y aspectos, especialmente en la construcción de aplicaciones colaborativas como, por ejemplo, la versión on-line del juego del Pictionary. Esta aplicación ha sido desarrollada sobre la plataforma de componentes y aspectos CoopTEL. Haremos hincapié sobre todo en las ventajas de extensibilidad, adaptabilidad y reutilización ofrecidas por CoopTEL, que facilitan la implementación de herramientas colaborativas a partir de la composición de componentes y aspectos previamente desarrollados.

1 Introducción
Hoy en día, el Desarrollo de Software Basado en Componentes (DSBC) [1] y el Desarrollo de Software Orientado a Aspectos (DSOA) [2] se están usando por separado para la construcción de sistemas más modulares, extensibles y adaptables. Mientras el objetivo principal del DSBC es descomponer cualquier sistema en una serie de entidades independientes, denominadas componentes, el DSOA tiene como objetivo solucionar el denominado problema del código enmarañado [2], separando en una nueva entidad llamada aspecto aquellas propiedades de los componentes que no se corresponden con la funcionalidad básica de la aplicación, y que se encuentran “entremezcladas” o replicadas en más de un componente. Ambas tecnologías son complementarias y, por tanto, podrían ser utilizadas de forma conjunta para obtener sistemas aún más extensibles y configurables. Sin embargo, por un lado, no existen aún muchas propuestas que aborden el desarrollo de software basado en componentes y aspectos y, por otro lado, se necesitan más experiencias que muestren las ventajas y dificultades de utilizar de forma conjunta estas tecnologías. Por tanto, el objetivo principal de este artículo es mostrar nuestra experiencia utilizando CoopTEL, una implementación Java/RMI de la plataforma de componentes y aspectos CAM/DAOP [3]. Concretamente, describiremos la implementación de una versión on-line del juego del Pictionary, haciendo hincapié sobre todo en las ventajas e inconvenientes encontrados utilizando la tecnología de componentes y aspectos en general, y CoopTEL en particular.

2 La Plataforma de Componentes y Aspectos CoopTEL
CoopTEL es una plataforma de componentes y aspectos implementada en Java/RMI, que soporta la ejecución de aplicaciones definidas conforme al modelo de componentes y aspectos CAM. Las características más relevantes de CoopTEL son: 1. Las reglas que rigen la composición entre los componentes y los aspectos en CoopTEL se definen de forma completamente separada a los componentes y a los aspectos, haciendo a las entidades del modelo independientes del contexto en el que se ejecutan. En su lugar, se definen en un fichero de configuración XML. 2. El mecanismo de composición de componentes y aspectos en CoopTEL es dinámico, pudiendo añadir en tiempo de ejecución cualquier tipo de aspecto según las necesidades del desarrollador de aplicaciones colaborativas, dando la posibilidad de definir cualquier aspecto y de dar una serie de implementaciones alternativas para cada uno de ellos. Aunque es cierto que la composición dinámica puede introducir una mayor sobrecarga en tiempo de ejecución que la composición estática, su uso permite el desarrollo de sistemas más extensibles, adaptables y reutilizables.

3 Diseño e Implementación de la Aplicación del Pictionary
El desarrollo de aplicaciones utilizando la plataforma CoopTEL se parece a la construcción de un puzzle. Primero se diseñan por separado las piezas (componentes y aspectos necesarios) y después se implementan y se entrelazan en tiempo de ejecución de acuerdo a la información proporcionada por las reglas de composición. Siguiendo la traza del juego es posible entender el conjunto de componentes y aspectos que lo forman, así como la forma en la que estos tienen que componerse. 3.1 Inicio del juego Cuando un usuario desea entrar en el juego, el primer paso será crear una instancia del usuario en el sistema. Sin embargo, antes de unirse el usuario tiene que autenticarse, por lo que en primer lugar será necesario aplicar el aspecto de Autenticación. Este aspecto se implementa como una ventana de diálogo en la que el usuario inserta el par usuario/palabra de paso, comprobándose si está o no registrado. Una vez autenticado, y antes de que se creen el resto de componentes del sistema, se evaluará otro aspecto, el de Configuración. Hemos separado esta propiedad como un aspecto ya que consideramos que no forma parte de la funcionalidad de un componente concreto, sino que afecta a todos los componentes con interfaz gráfica. El usuario dialoga con la ventana de configuración y elige sus preferencias (nombre y color de su equipo), encargándose el aspecto de almacenar los datos insertados. Después de que ambos aspectos sean evaluados correctamente, se crea el componente Pictionary, que será el encargado de crear el resto de componentes. Los componentes al crearse, si son gráficos, aportan un panel a la ventana del juego, quedando el juego inicializado a la espera de recibir eventos de usuario. La ventana

del juego se muestra en la figura 1, formada por los paneles de los distintos componentes bien diferenciados. De izquierda a derecha y de arriba abajo tenemos los componentes Tablero, Pizarra, Dado, Baraja, Usuarios, Crono, Chat y Status. El juego comienza cuando han entrado como mínimo cuatro jugadores en el sistema y se reparten en equipos de dos en dos. Después de entrar el usuario en el sistema se debe informar al resto de usuarios para que tengan constancia de la nueva incorporación al juego. Esta propiedad de presencia (awareness) no es aplicable a una funcionalidad concreta dentro de algún componente, por lo que se implementa como un aspecto aplicable cuando el usuario entra o sale del sistema. Se trata del aspecto de Presencia, que envía mensajes a todos los componentes informativos del sistema (se denominan así a los componentes que muestran información útil al usuario). En el Pictionary hay dos componentes informativos, el componente Usuarios que modela una lista de presencia con todos los jugadores agrupados en equipos, y el componente Status, que representa la barra informativa inferior de la ventana.

Fig 1. Interfaz Gráfica del Juego del Pictionary

3.2 Comienzo del turno Una vez que los usuarios se han conectado al juego, el usuario que posee el turno empieza a jugar lanzando el dado (componente Dado). Tras lanzar el dado cada usuario debe poder visualizar el resultado de la tirada. Ello conlleva a que este componente tenga “estado”, y a que el estado del componente deba ser distribuido a los componentes del mismo tipo, creados por el resto de usuarios conectados a la aplicación colaborativa. Es decir, cada usuario tendrá un dado y el valor mostrado

será el mismo para todos. Para que el estado de los componentes se mantenga consistente, cada vez que se cambie de estado es necesario informar de este cambio, y además el estado debe estar disponible para nuevos usuarios (latecomer users). La necesidad de mantener el estado de los componentes de la aplicación entre los distintos usuarios se repite para varios componentes, por lo que esta tarea se modela mediante aspectos. Por un lado, la comunicación con el resto de componentes del mismo tipo, informando de un cambio en su estado, es realizada por el aspecto de Colaboración. Por otro lado, el trabajo de almacenar globalmente el nuevo estado lo realiza el aspecto de Persistencia. Así, al tirar el dado se evalúan ambos aspectos, mostrando para cada usuario el valor de la nueva tirada y permitiendo que un jugador al entrar visualice también el nuevo valor (aplicando el aspecto de Persistencia al crear el componente Dado). Además, al lanzar el dado, se reproduce un archivo de sonido característico de la acción, que es escuchado por todos los usuarios en juego. Ésta característica (que se repetirá en más componentes) la englobaremos en el aspecto de Sonido, definido como la propiedad de activar un recurso (de sonido) cuando el componente ejecuta una determinada acción. Este aspecto podría generalizarse para la activación de todo tipo de recursos (ventanas popup, imágenes...) Una vez lanzado el dado, el valor de la tirada es enviado al componente Juego, que se encarga de controlar la traza para un determinado turno, sabiendo siempre a que componente le toca actuar. Este componente actúa como un intermediario, evitando que el resto de componentes tengan que “conocerse” y comunicarse directamente entre sí. De esta forma, es el componente Juego el que le indica al componente Tablero que mueva la ficha del equipo que lanzó el dado. Una vez movida las ficha, el componente Tablero le vuelve a dar el control al componente Juego, que recibe la casilla en la que reside la ficha. Interesa saber el color de la casilla pues el siguiente componente es la Baraja de cartas donde el usuario saca una carta de forma aleatoria del mismo color que el de la casilla. Los componentes Tablero y Bajara son también componentes que mantienen un estado (la posición de las fichas y la carta seleccionada) y a los que se les aplican los aspectos de Persistencia y Colaboración, haciendo posible que todos los usuarios vean moverse las fichas y conozcan la carta seleccionada, respectivamente. 3.3 Pintar y acertar En éste punto el usuario debe lanzar el crono para empezar el proceso de dibujo. Al pulsar el botón del panel del componente Crono se lanza no sólo el suyo, sino también el del resto de usuarios, y el componente Juego habilita diversos componentes para controlar el dibujo y las respuestas. Por un lado, habilita el componente Pizarra para recibir los eventos de usuario, y así poder dibujar aquello que se le indica en la carta. Por otro lado habilita el envío de respuestas en los componentes de rol Chat para aquellos jugadores que deban acertar, es decir, el compañero de equipo, o bien el resto de jugadores en el caso de haber sacado una carta de “todos juegan”. El componente Chat permite la comunicación entre jugadores y el envío de respuestas en el caso de jugar. Para saber que respuesta salió antes del origen, el componente Chat le añade un sello temporal al mensaje obtenido del componente Crono. El “timestamping” es una propiedad típica para este tipo de sistemas, por lo

que se implementa como un aspecto, llamado TimeStamp. Cada vez que se envía una respuesta el aspecto se evalúa y añade al mensaje el sello temporal actual facilitando al componente Juego la tarea de discernir sobre el ganador del nuevo turno en el caso que lleguen múltiples respuestas certeras. El componente Pizarra permite al usuario desarrollar sus capacidades artísticas con varias opciones configurables como el color o el grosor del trazo. Como estado mantiene el dibujo actual y cada cierto tiempo se evalúa el aspecto de Colaboración para que los demás usuarios puedan ver la elaboración paulatina del dibujo. Cuando se conoce el ganador, o bien cuando finaliza el tiempo del crono, el componente Juego muestra en todas las ventanas el resultado y provoca el cambio del turno al usuario que le toque, empezando de nuevo el proceso, a no ser que el equipo acertante se encontrara en la última casilla, obteniendo en este caso la victoria. 3.4 Componentes y aspectos La figura 2 presenta un resumen de los componentes que forman la aplicación, su interacción y los aspectos que son evaluados al ejecutarse determinados métodos.

Fig 2. Clasificación de los Componentes y Aspectos que se evalúan durante la aplicación

En ella se encuentran clasificados todos los componentes usados en el Pictionary y la relación entre ellos esquematizada. Además por cada componente, se muestran los aspectos que le son evaluados en determinados métodos. Por ejemplo, después de ejecutarse el método LanzarDado se aplica Persistencia, Colaboración y Sonido. O Antes de crear el componente Pictionary, se evalúan los aspectos de Autenticación y Colaboración.

4 Nuestra Experiencia
El desarrollo del Pictionary nos ha permitido comprobar las ventajas del modelado basado en componentes y aspectos, pero también las dificultades que presenta. Entre las ventajas encontradas destaca el incremento en la adaptabilidad del sistema gracias a la separación de aspectos. Además, gracias a que en CoopTEL las reglas de composición entre componentes y aspectos se describen de forma externa, el juego puede ser fácilmente configurable. Por ejemplo, si se decidiera desplegar la aplicación sin realizar autenticación, sólo habría que eliminar la regla de composición que lanza el aspecto de Autenticación. Se podría también definir otra implementación del mismo aspecto que reduzca el nivel de seguridad y elegir entre distintas implementaciones, incluso en tiempo de ejecución. Si se decidiera guardar los estados globales de los componentes en bases de datos externas, es posible redefinir una nueva implementación del aspecto de Persistencia, sin que después haya que tocar nada del código para integrar el nuevo aspecto (sólo habría que modificar el fichero XML en donde se encuentran las reglas de composición entre aspectos y componentes). Son solo ejemplos de la infinitud de posibilidades de configuración del sistema, añadiendo, eliminando o cambiando aspectos. Por otro lado, la separación de aspectos transforma a los componentes en entidades más independientes, y por tanto con más posibilidades de reutilización. Gracias a la separación de aspectos hemos eliminado casi por completo la comunicación directa entre componentes. Por ejemplo, se delega en el aspecto de Colaboración la comunicación entre componentes del mismo tipo para mantener consistente su estado. También, gracias al aspecto de Presencia se evita que los componentes tengan que ser conscientes de la información de presencia que tienen que generar y de a quién tienen que enviarla. Así, en nuestra aplicación, los componentes no se comunican entre sí, sólo con el componente Juego, que como mencionamos anteriormente actúa como control de la aplicación. Además, para hacerlos totalmente independientes estamos trabajando actualmente en la incorporación de un aspecto de Coordinación, que se encargará de coordinar las interacciones entre los componentes de forma transparente a ellos, eliminando el componente intermedio Juego. Éste componente recogería eventos lanzados por los componentes que completen una determinada acción y como el componente que lanza el evento no sabe que elemento lo va a recoger nunca debe indicar el destino de los mensajes. De todas formas, componentes que no realizan éste tipo de comunicación (Pizarra, Usuarios) son ya totalmente independientes y reutilizables en otros sistemas. Aunque se podría pensar que el aspecto de Coordinación sería una simple sustitución de la funcionalidad de control del componente Juego, la realidad es que presenta un mayor número de ventajas. La principal ventaja es que elimina cualquier interacción entre componentes. La principal desventaja descansa en el hecho que el aspecto de Coordinación sería propio de ésta aplicación, y estaríamos construyendo un aspecto no reutilizable, pero no debería importar pues constituye una sustitución del componente de control Juego, que tampoco es reutilizable en otros sistemas (por lo que no origina una pérdida en éste sentido).

Una vez decidido qué componentes y aspectos convivirán en la aplicación, y las reglas de composición que se aplicarán, el resto de dificultades vienen en los detalles de implementación de los distintos elementos. Por un lado, para que los aspectos de Colaboración y Persistencia puedan ser aplicados, los componentes deberán seguir un patrón específico (implementar un interfaz) para que puedan manejar su estado. Esto se reduce a declarar un tipo de datos específico que englobará el estado, e implementar métodos que lo maneje (guardar, actualizar...). Por otro lado, hay que tener en cuenta que éste estado debe ser lo más sencillo posible pues el aspecto de Colaboración lo transmitirá por la red, y a mayor número de datos a transmitir mayor ralentización en el sistema. Especialmente conflictivo es el estado del componente Pizarra, pues para que se conserve la consistencia e integridad en todos los dibujos, la transmisión de datos debe ser rápida y regular. Otro problema con el que nos encontramos es el orden de llegada de las respuestas desde los distintos terminales, pues puede ocurrir que respuestas certeras que salieron antes del origen lleguen más tarde al destino que otras que salieron después. Por ello, y ante la ausencia de un reloj global se decidió implementar el aspecto de TimeStamp que añadiera un sello temporal a cada respuesta. Esto evita que los componentes Crono se tengan que sincronizar entre sí y que el orden de llegada de las respuestas carezca de importancia (sólo importa el instante de tiempo en el que salga un mensaje desde cada terminal). Las dificultades que nos encontramos a la hora de diseñar el sistema tienen su base en la escasa documentación que existe en el desarrollo sobre plataformas de componentes y aspectos y el hecho de que el desarrollo basado en aspectos es aún una tecnología muy novedosa. De nuestra experiencia podemos concluir que no ha sido complicado detectar como descomponer la funcionalidad de la aplicación en componentes. La dificultad empieza cuando queremos separar aquellas propiedades que no pertenecen a la funcionalidad propia de los componentes. Quizás sería de mucha ayuda la existencia de librerías de aspectos, que proporcionaran información sobre las propiedades que son comúnmente entendidas como aspectos en diversas aplicaciones (autenticación, persistencia, colaboración...), así como su implementación. En este sentido, el Pictionary comparte, con una aplicación de Oficina Virtual [4] desarrollada anteriormente con CoopTEL, algunos aspectos como el de Autenticación y Persistencia entre otros, por lo que esto nos ha servido como punto de partida para el desarrollo de la nueva aplicación. Incluso algunos de los aspectos implementados para la oficina virtual han podido ser reutilizados o extendidos en la nueva aplicación.

5 Conclusiones
El desarrollo de esta aplicación ha servido sobre todo como ejemplo del desarrollo de aplicaciones colaborativas complejas sobre componentes y aspectos. Por diversas razones, como por ejemplo el escaso tiempo de vida de esta disciplina que la transforma en desconocida para gran parte de los desarrolladores, o el miedo de adaptarse a las nuevas ideas, sobre todo en entornos donde el desarrollo orientado a objetos parece haberse asentado definitivamente, resulta complicado encontrar aplicaciones que sirvan de modelo para futuros desarrollos. No pretendemos que sirva

como patrón de otras aplicaciones, pero es innegable que la existencia de otros diseños ya completados y analizados puede servir como punto de apoyo para iniciarse en ésta disciplina. Las posibilidades de configuración del sistema, y la posibilidad de reutilización de sus componentes y aspectos son sólo algunas de las ventajas que la implementación de este tipo de aplicaciones ofrece. Transformar los componentes en entidades totalmente independientes facilita la construcción de futuras aplicaciones, obteniendo bibliotecas de componentes con funcionalidad bien definida, dejando como responsabilidad de nuevos desarrolladores el entretejerlos y aplicar los aspectos que completen la funcionalidad del sistema. Mientras que actualmente se están mejorando las diversas propuestas para desarrollar aplicaciones basadas en aspectos, así como los mecanismos de composición tanto estáticos como dinámicos, en paralelo deberían implementarse nuevas aplicaciones que nos ayuden a definir procesos de desarrollo basados en componentes y aspectos que cubran las distintas fases del desarrollo, como por ejemplo, el análisis de requisitos, el diseño y la implementación. Por ello consideramos nuestra propuesta útil e interesante, y de carácter pedagógico.

Referencias
[1].A. W. Brown, K. Wallnau, “The current state of CBSE”, IEEE Software, 15(5):37-46, 1998 [2].G. Kiczales et al.,“Aspect-Oriented Programming”. Actas de ECOOP’97, LNCS 1241, Springer Verlag, 1997. [3].M. Pinto, L. Fuentes, J.M. Troya, “Plataforma para la Composición Dinámica de Componentes y Aspectos”, Actas de JISBD’02, El Escorial, Madrid, 2002. [4] M. Pinto, M. Amor, L. Fuentes, J.M. Troya, “Supporting Heterogeneous Users in CVEs Using AOP”, Actas de CoopPIS’01, LNCS 2172, 2001


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:10
posted:12/21/2009
language:Spanish
pages:8