Avances en Desarrollo de
Software Orientado a Aspectos
Actas del Segundo Taller de Desarrollo de
Software Orientado a Aspectos.
DSOA’04
9 de Noviembre de 2004
Málaga , Spain
En colaboración con las IX Jornadas de Ingeniería
del Software y Bases de Datos JISBD’04
Registrado como
Informe Técnico TR-23/04Escuela Politécnica Dpto. de Informática Universidad de Extremadura
Editores
Lidia Fuentes Universidad de Málaga ETSI Informática Campus de Teatinos 29071 Málaga (Spain) E-mail: [email protected] Web: http://www.lcc.uma.es/~lff I.S.B.N. 84-688-8889-3 Ana Moreira Departamento de Informática Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa 2829-516 CaparicaPortugal
E-mail: [email protected]
Web: http://ctp.di.fct.unl.pt/~amm/
Juan Manuel Murillo Universidad de Extremadura Escuela Politécnica Avda. de la Universidad, s/n 10071 Cáceres (Spain) E-mail: [email protected] Web: http://quercusseg.unex.es Impreso en España Noviembre de 2004
Impresión subvencionada por la CICYT. Contrato TIC 2002-04309-C02-01
P
rólogo
El Desarrollo de Software Orientado a Aspectos (en terminología inglesa AOSD, Aspect Oriented Software Development) es una disciplina muy prometedora que constituye una alternativa válida para mejorar el proceso de desarrollo de software, en un intento de superar la creciente complejidad de los sistemas software. Mientras que en sus inicios, esta nueva disciplina se centraba en la fase de implementación (siendo conocida como Programación Orientada a Aspectos), el Desarrollo de Software Orientado a Aspectos propugna la utilización del concepto de aspecto en todas las fases del ciclo de vida del desarrollo de software. Así, los aspectos aparecen en ingeniería de requisitos, el análisis, en el diseño y en la implementación de las aplicaciones software.
Las técnicas orientadas a aspectos extienden técnicas tradicionales como la orientación a objetos, permitiendo a los desarrolladores de software encapsular en módulos separados los aspectos, propiedades que normalmente atraviesan varios componentes de un sistema. Esta tecnología propugna la identificación, separación y modularización de los distintos aspectos que intervienen en una aplicación (ej. sincronización, coordinación, distribución, persistencia, etc.), para componerlos (tejerlos, en su terminología original) con posterioridad para construir la aplicación final. El beneficio principal de esta tecnología es una mejora en la modularización de los sistemas obteniéndose un código menos "enmarañado", evitándose la mezcla entre funcionalidad y aspectos extra-funcionales, facilitándose el mantenimiento y la evolución del código.
Sin embargo, los aspectos constituyen una disciplina emergente y por lo tanto no exenta de cuestiones y problemas aún no resueltos completamente. Por ejemplo, aun se necesitan notaciones para expresar aspectos en cada uno de los diferentes niveles de abstracción que componen el ciclo de desarrollo de software. Igualmente, son necesarios mecanismos de composición (weavers) apropiados (tanto estáticos como dinámicos) para componer aspectos independientes con las restantes entidades de la aplicación. Asimismo, es preciso disponer de plataformas que permitan desarrollar software utilizando los mecanismos propios de los aspectos.
El presente volumen recoge los trabajos seleccionados para su presentación en el Segundo Taller e Desarrollo de Software Orientado a Aspectos (DSOA 2004), desarrollado de forma conjunta con las IX Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2004) celebradas en Málaga en Noviembre de 2004. El éxito obtenido por la primera edición del taller motivo la organización de esta segunda edición. DSOA 2004 intenta proporcionar un foro de encuentro y discusión en el que los investigadores, desarrolladores y usuarios interesados en el Desarrollo de Software Orientado a Aspectos puedan intercambiar y debatir sus ideas, explorando conjuntamente posibles soluciones y propiciando colaboraciones entre los diferentes grupos.
Los principales temas de interés relativos al desarrollo de software orientado a aspectos en los que se apoyó la petición de contribuciones fueron los siguientes.
• Análisis y diseño de software orientado a aspectos.
• Arquitecturas de software orientadas a aspectos.
• Influencia y correspondencia de aspectos entre las diferentes fases del ciclo de vida.
• Relación entre aspectos y otros mecanismos de separación, como viewpoints, goals y problem frames, entre otros.
• Integración de tecnologías de componentes y aspectos.
• Mecanismos, reglas y lenguajes de composición.
• Bases de datos orientadas a aspectos.
• Ingeniería inversa y orientación a aspectos.
• Experiencias en el desarrollo de aplicaciones orientadas a aspectos.
• Trazabilidad de requisitos orientados a aspectos hasta el código.
• Herramientas de soporte para las diferentes fases de desarrollo de software orientado a aspectos.
En esta segunda edición y con el objeto de reforzar la calidad del evento se contó con un comité de programa externo constituido por investigadores de reconocido prestigio en los temas de interés. Expresamos nuestra más sincera gratitud hacia João Araújo, João Miguel Fernandes, Juan Hernández, Francisco Ortin, Mónica Pinto, Isidro Ramos, Awais Rashid y Fernando Sánchez por la ayuda prestada y labor realizada. Todas las contribuciones recibidas fueron revisadas por al menos dos miembros del comité de programa quienes finalmente decidieron aceptar doce de ellas. Todos los autores recibieron los comentarios sobre sus contribuciones y, para las aceptadas, se solicitó a los autores que confeccionaran una nueva versión de ellas teniendo en cuenta los comentarios de los revisores.
Finalmente, queremos también agradecer a los autores de todas las contribuciones, tanto aceptadas como rechazadas, el interés mostrado y el esfuerzo realizado enviado sus contribuciones al taller, sin las cuales, esta nueva edición de DSOA no sería posible. Así mismo queremos mostrar nuestro agradecimiento a la organización de JISBD 2004 por la oportunidad brindada para organizar esta segunda edición del taller y a los presidentes de Comité de Programa Juan Hernández, Comité Organizador Ernesto Pimentel y Coordinador de Talleres Fernando Sánchez por su amabilidad y la colaboración prestada en todo momento.
Lidia Fuentes, Ana Moreira, Juan Manuel Murillo Organizadores de DSOA 2004 Noviembre de 2004
Comité de Programa
João Araújo
João Miguel Fernandes
Lidia Fuentes
Juan Hernández
Ana Moreira
Juan Manuel Murillo
Francisco Ortin
Mónica Pinto
Isidro Ramos
Awais Rashid
Fernando Sánchez
Universidade Nova de Lisboa
Universidade do Minho
Universidad de Málaga
Universidad de Extremadura
Universidade Nova de Lisboa
Universidad de Extremadura
Universidad de Oviedo
Universidad de Málaga
Universidad Politécnica de Valencia
Lancaster University
Índice de Autores
Álvarez, Bárbara
35
Amaya, Pablo
49
Barrio, Manuel
57
Campos, Juan Antonio
65
Clemente, Pedro José
27
Conejero, José María
81
Cuesta, Carlos Enrique
57
De la Fuente, Pablo
57
Escalona, María J.
91, 99
Eterovic, Yadran
19
Fernandes, João Miguel 41
González, Carlos
49
Gutiérrez, Javier J.
99
Hernández, Juan
27, 81
Letelier, Patricio
35
Mejías, Manuel
99
Monteiro, Miguel Pessoa 41
Moreira, Ana
73
Murillo, Juan Manuel
19, 49
Navarro, Elena
35
Navasa, Amparo
19
Ortin, Francisco
11
Ortiz, Guadalupe
27
Palma, Karen
19
Pantoquilho, Marta
73
Pedrero, Javier
81
Pinto, Mónica
65
Ramos, Isidro
35
Reina, Antonia María
91
Romay, María del Pilar
57
Toro, Miguel
91
Torres, J.
91
Villadiego, Darío
99
Índice
Tejedor dinámico de aspectos sobre la plataforma .NET 11 L. Vinuesa, F. Ortin
Dos modelos arquitectónicos para el DSOA 19
A. Navasa, K. Palma, J. M. Murillo, Y Eterovic
Configuración de propiedades no funcionales en los servicios
web usando técnicas orientadas a aspecto 27
G. Ortiz, J. Hernández, P. J. Clemente
Orientación a Aspectos y Orientación a Objetivos: una
propuesta para su integración 35
E. Navarro, P. Letelier, I. Ramos, B. Álvarez Pitfalls of AspectJ Implementations of Some of the
Gang-of-Four Design Patterns 41
M. P. Monteiro, J. M. Fernandes
Un modelo de propiedades y dependencias para el
análisis orientado a aspectos en MDA 49
C. González, P. Amaya, J. M. Murillo
Descripción de aspectos mediante conectores UML 2.0 57 M. P. Romay, C. E. Cuesta, P. de la Fuente, M. Barrio
Desarrollo de aplicaciones colaborativas con CoopTEL:
el juego del Pictionary 65
J. A. Campos, M. Pinto
Aspect-Oriented Logical Architecture Design A Layered
Perspective Applied to Data Warehousing 73
M. Pantoquilho, A. Moreira
Definición de un perfil UML para el aspecto de
notificación en entornos distribuidos CORBA 81
J. M. Conejero, J. Hernández, J. Pedrero
Modelando aspectos con lenguajes específicos de dominio 91 A. M. Reina, J. Torres, M. Toro, M. J. Escalona
Aplicación de la programación orientada a aspectos en el
diseño e implementación de pruebas funcionales 99
TEJEDOR DINÁMICO DE ASPECTOS SOBRE LA PLATAFORMA .NET Luis Vinuesa y Francisco Ortin
Universidad de Oviedo, Departamento de Informática C\ Calvo Sotelo s/n – 33007 - Oviedo - España
{vinuesa,ortin}@lsi.uniovi.es http://www.di.uniovi.es/~{vinuesa,ortin}
Resumen. Desde la aparición del Desarrollo de Software Orientado a Aspectos
-Aspect Oriented Software Development- (AOSD) ha surgido un conjunto de herramientas con el fin de obtener los beneficios del AOSD en el desarrollo de software. En determinadas ocasiones es necesario que una aplicación sea capaz de adaptarse en tiempo de ejecución ante nuevos requerimientos que puedan surgir. Ésta es la razón por la que han aparecido algunas herramientas que per-miten el tejido dinámico de aspectos. Sin embargo, estas herramientas tienen algunas limitaciones, como la dependencia del lenguaje y un conjunto limitado de puntos de enlace, las cuales restringen su utilidad.
Este artículo muestra la investigación que estamos llevando a cabo en el campo del tejido dinámico de aspectos. Hemos seleccionado el sistema .NET como sis-tema sobre el que desarrollamos nuestro tejedor dinámico, por su independencia de lenguaje y plataforma. Aplicando técnicas de reflectividad computacional al nivel de la máquina virtual conseguimos tejido dinámico independiente del len-guaje, haciendo posible que las aplicaciones se adapten dinámicamente a con-textos surgidos en tiempo de ejecución.
1 Introducción
En muchos casos, es difícil expresar de una forma modular incumbencias -concerns- importantes de una aplicación software. Ejemplos de esto pueden ser la seguridad, sincronización o persistencia. El código que trata estas competencias se encuentra a menudo diseminado sobre muchas partes de la aplicación, con el inconveniente de es-tar enmarañado y ser más difícil de mantener, entender y reutilizar.
La Ingeniería del Software ha utilizado el principio de la separación de incumben-cias (o separación de competenincumben-cias) (SoC) -Separation of Concerns- [1][2] para ges-tionar la complejidad del desarrollo de software mediante la separación de las funcio-nalidades principales de la aplicación de otras partes con un propósito específico (típicamente ortogonales a la funcionalidad principal) – p.ej. autenticación, adminis-tración, rendimiento, logging, etc. La aplicación final se construye con el código de las funcionalidades principales más el código de propósito específico.
Este principio se ha desarrollado siguiendo múltiples aproximaciones, AOSD[3] es una de ellas. El AOSD persigue como objetivo construir programas adaptables a las competencias -concerns-. La mayoría de las herramientas existentes carecen de adap-tabilidad en tiempo de ejecución: una vez que la aplicación ha sido generada (tejida) no es capaz de adaptar sus competencias (aspectos) en ejecución. Es lo que se conoce como tejido estático de aspectos. Existen ciertos casos en los que la adaptación de la
aplicación debe ser realizada en tiempo de ejecución en respuesta a cambios en el en-torno- p.ej. aspectos de distribución de carga. Otro ejemplo de uso de AOSD de forma dinámica es lo que recientemente se ha llamado software autónomo – autonomic software: software capaz de auto repararse, gestionarse, optimizarse o recuperarse.
Para solucionar las limitaciones de las herramientas con tejido estático de aspectos han surgido diferentes aproximaciones de tejido dinámico. Unas realizan el tejido di-námico en tiempo de carga, con lo que una vez cargadas las clases no es posible mo-dificar los puntos de corte (p.ej. PROSE [4]), mientras que otras lo realizan en tiempo de ejecución (p.ej. JAsCo [5]), pudiendo modificarse los puntos de corte en cualquier momento de la ejecución del programa. Sin embargo, ambas opciones están limitadas por el conjunto de puntos de enlace que ofrecen (en comparación con las herramientas de tejido estático), restringiendo así el modo en que las aplicaciones pueden ser adap-tadas en tiempo de ejecución.
Además, la mayoría de las aproximaciones (estáticas y dinámicas) utilizan un len-guaje de programación fijo, por lo que los aspectos no son reutilizables de forma in-dependiente de su lenguaje.
La reflectividad es una técnica que consigue la adaptación dinámica de una aplica-ción, por lo que se puede utilizar para conseguir la adaptación de aspectos en tiempo de ejecución. Como trabajo previo de investigación [6][7][8] hemos aplicado reflecti-vidad computacional a una máquina virtual, obteniendo una adaptación del programa en ejecución sin restricciones y de forma neutral al lenguaje y a la plataforma.
Actualmente estamos aplicando [9] los conceptos que hemos aprendido a la plata-forma Microsoft .NET que es independiente de lenguaje y plataplata-forma y que ofrece un buen rendimiento en ejecución, siendo al mismo tiempo neutral respecto al lenguaje y hardware. Estamos desarrollando un tratamiento reflectivo de las aplicaciones .NET ofreciendo un marco de trabajo -Framework- que ofrece tejido dinámico de aspectos en ejecución.
Cuando una aplicación compilada se va a ejecutar, el sistema transforma su código (manipulándolo en su lenguaje intermedio, Microsoft Intermediate Language, MSIL), añadiendo el código necesario para permitir a otras aplicaciones el acceso y adapta-ción de la primera cuando se encuentra en ejecuadapta-ción. Para conseguir esto el sistema tiene un servidor (registro de aplicaciones) en el cual se registran todas las aplicacio-nes que se están ejecutando. Una vez que la aplicación se está ejecutando, si otra apli-cación necesita adaptarla, el servidor le ofrece la capacidad de hacerlo en ejecución siguiendo el principio de AOSD.
2 Inyector de Puntos de Enlace
La arquitectura del sistema se muestra en la Fig.1 y Fig.2 . Antes de ejecutar una apli-cación ya compilada, se procesa y se modifica por parte del sistema. El Join Point In-jector (JPI) (inyector de puntos de enlace) del sistema inserta rutinas de reflectividad computacional basadas en MOP –Meta Object Protocol- siguiendo los siguientes pa-sos:
1. La aplicación se carga en memoria mediante System.Reflection. Se utiliza este namespace para, a partir de los ficheros binarios, cargar la representación en 12 L. Vinuesa, F. Ortin
MSIL – Microsoft Intermediate Language- del programa en memoria. Una vez allí el sistema manipulará este código como si se tratase de datos, localizando los pun-tos de enlace posibles.
2. Se insertan rutinas de control por medio de la herramienta RAIL (Runtime Assem-bly Instrumentation Library) [10]. En cada punto de enlace localizado anteriormen-te se insertan rutinas que manejan una tabla con referencias a los futuros aspectos que deben ser avisados con el fin de poder invocar a sus advices (código). En un principio este código inyectado no invoca ninguna rutina, pero insertando referen-cias en la tabla posteriormente su comportamiento puede ser extendido – como ocurre en la mayoría de los sistemas de MOP.
RAIL es una herramienta que permite, de una manera sencilla, manipular e instru-mentar código MSIL antes de su ejecución. Entre las acciones que permite realizar se encuentran la sustitución de accesos a campos, propiedades y métodos, la adi-ción de código al principio y/o final de los mismos, o sustituir un método por otro. Esto permite al sistema contemplar un amplio abanico de puntos de enlace, similar al de los sistemas estáticos. Al trabajar sobre código MSIL es totalmente indepen-diente del lenguaje en que se hubiese implementado la aplicación a manipular.
Aplicación En Binario 1) Carga en memoria
.class public MyClass extends ... {
.method public MyMethod ... {
// * código del método }
// * Otros métodos y atributos }
.class public MyClass extends ... {
.method public MyMethod ... {
// * Código del método }
// * Otros métodos y atributos }
Before Method-Execution JoinPoint After Method-Execution JoinPoint
2) Inyección JoinPoint
3) Inyección de IPoinCut, IReflection y de código de registro
Código de IPointCut, IReflection Y registro de la aplicación
4) Salvar a Disco
Aplicación Original
Aplicación con MOP inyectado
JoinPoint Injector (JPI) Inyector de Puntos de Enlace
Aplicación En Binario
Fig. 1. Arquitectura del sistema A
3. Se inyecta el código de los interfaces IPointCut e IReflection así como el código necesario para que la aplicación se registre en el servidor. IPointCut provee el interfaz para definir diferentes puntos de enlace que se usarán en las adaptaciones futuras. Esta funcionalidad es la misma que los pointcut designators (o simplemente pointcut) de AspectJ.
Mediante el uso de IPointCut, los aspectos, a través del servidor, podrán selec-cionar un conjunto de puntos de enlace específicos de una aplicación para ser noti-ficados cada vez que se alcance alguno de ellos (en la invocación de un método, acceso a un campo, etc.). Esto se consigue insertando en las tablas de las rutinas inyectadas en el segundo punto referencias a los aspectos que han solicitado ser no-tificados, provocando por tanto las invocaciones al código de los aspectos (advice). El interfaz IReflection permite a otras aplicaciones el acceso a la información de la aplicación (es decir, introspección intra aplicaciones, outward) –por razones de seguridad, en la plataforma .NET una aplicación sólo se puede inspeccionar a sí misma, no puede inspeccionar a otra aplicación. Cuando se están desarrollando los aspectos, normalmente es necesario acceder a la estructura de la aplicación que se va a adaptar: ésta es exactamente la principal funcionalidad ofrecida por IRe-flection. Este interfaz hace uso principalmente de System.Reflection,
13 Tejedor dinámico de aspectos sobre la plataforma .NET
permitiendo que los aspectos puedan tener acceso a la información de la aplica-ción, puedan invocar un método, o incluso puedan crear un objeto.
Por último, se inyecta el código necesario para conseguir que la aplicación se regis-tre por sí misma en el servidor en el momento de arranque (el funcionamiento se explica más adelante).
4. Se guarda en disco la aplicación modificada
3 Adaptación Dinámica de Aplicaciones
Al iniciar la ejecución, la aplicación modificada se registra a sí misma, gracias al código inyectado anteriormente, con un GUID (identificador único global, Globally unique identifier) en el servidor, con el objetivo de permitir a los aspectos que interac-túen con ella. Para adaptar una aplicación en ejecución se siguen los siguientes pasos:
Aplicación 1 Ejecutándose Registro <<Server>> Aplicación 2 Ejecutándose Aplicación 3 (Aspecto) IRegistry IPointCut IReflection IPointCut IReflection
Acceso a la aplicación en ejecución
Adaptación de la aplicación ejecución
IPropertyFieldAccess IMethodCallExecution
IStaticInitializer
* Notificación al aspecto de alcance de puntos de enlace
* *
Fig. 2. Arquitectura del sistema B
1. El aspecto accede al servidor, le pasa una referencia a sí mismo y le informa acerca de los puntos de enlace de la aplicación destino (aquélla a adaptar) en los que está interesado, con el fin de ser notificado cuando se alcancen. La especificación de es-tos punes-tos de enlace (punes-tos de corte) se hace mediante un archivo XML que des-cribe cómo debe hacerse el tejido de código. La sintaxis del archivo se valida co-ntra un esquema XML que es una simplificación del utilizado en Weave.Net [11]. La especificación se realiza de forma similar a los puntos de corte de AspectJ, pu-diendo el aspecto especificar explícitamente los puntos de enlace que desea contro-lar (p.ej. la ejecución del método foo) o mediante reglas (p.ej. la ejecución de cual-quier método público que reciba un parámetro de un tipo determinado).
Mediante este sistema se separa por completo el código del aspecto (advice) de las reglas de tejido, con lo que se logra que no sea necesario añadir ninguna extensión al lenguaje en el que se implementen los aspectos, así como que el lenguaje en el que se implementen sea irrelevante. Asimismo se pueden cambiar las reglas de te-jido sin tener que modificar el código del aspecto, lo que ofrece una mayor flexibi-lidad y permite distintas formas de utilizar el mismo aspecto con la misma aplica-ción o con otras, simplemente cambiando las reglas de tejido en el archivo XML. El aspecto debe haber implementado uno o varios de los interfaces IMethodCa-llExecution (para ejecuciones y llamadas a métodos y constructores), IPro-pertyFieldAccess (para accesos de lectura o escritura a campos y propieda-14 L. Vinuesa, F. Ortin
des) o IStaticInitializer (para la inicialización estática), los cuales permi-tirán a la aplicación destino poder notificar al aspecto, mediante las rutinas que se le inyectaron, cuando alcance los puntos de enlace solicitados.
2. El servidor, mediante el interfaz IReflection, examina la aplicación destino (la que va a ser adaptada) y en función de los puntos de corte recibidos en el archivo XML, solicita a la aplicación, mediante el interfaz IPointCut, que notifique al aspecto cuando se alcancen los puntos de enlace especificados. Lo que hace inter-namente este interfaz es insertar en las tablas inyectadas anteriormente una refe-rencia al aspecto, de modo que cuando se alcancen los puntos de enlace, la aplica-ción sepa si debe notificar tal evento o no. Esto sirve para obtener un mejor rendimiento de ejecución (sólo los puntos de enlace solicitados generan llamadas). Con estos dos primeros pasos el aspecto ha designado los puntos de corte.
3. Cuando se alcanza en la aplicación destino alguno de los puntos de enlace solicita-dos, ésta invoca al aspecto o aspectos cuyas referencias están en la tabla asociada, enviándole una referencia de sí misma.
4. Mediante el uso de la referencia recibida y del interfaz IReflection, imple-mentado por la aplicación destino, el aspecto puede acceder a la aplicación, obtener su estructura, invocar código de la aplicación, o ejecutar sus propias rutinas. 5. Si un aspecto ya no se necesita más, informa al servidor de esta circunstancia para
no seguir siendo notificado. En este caso el servidor, mediante el interfaz IPointCut de la aplicación, elimina las referencias al aspecto en las tablas co-rrespondientes, con lo que la aplicación deja de informar al aspecto.
De este modo el servidor puede llevar un registro de qué aplicaciones fueron adap-tadas, por parte de qué aspectos y de qué forma, y cuándo dejaron de ser adaptadas. Como todo el trabajo se realiza sobre código en lenguaje intermedio, MSIL, se ob-tienen dos beneficios principales: independencia del lenguaje y de la plataforma en la aplicación que va a ser adaptada y en los aspectos que la adaptan. Además, no es ne-cesario conocer en el momento del diseño si la aplicación va a ser adaptada o no.
Con estesistema, también es posible destejer (borrar, eliminar) un aspecto cuando ya no se necesite más. Un ejemplo sencillo pueden ser las métricas de tiempo de eje-cución: 1) cuando se necesita obtener alguna medida en una aplicación que está ejecu-tándose se le añade un aspecto que realice esta operación, 2) una vez que el aspecto ha adaptado a la aplicación se pueden obtener las métricas deseadas, y 3) cuando ya no se necesita la métrica se puede destejer el aspecto con lo que la aplicación vuelve al estado inicial.
De igual manera una aplicación puede ser adaptada por uno o varios aspectos si-multáneamente, y estos aspectos pueden interactuar entre sí. Un aspecto es una apli-cación normal y, como tal, al ejecutarse en el sistema puede ser modificada dinámi-camente por medio de otro aspecto. Aunque es muy atrayente la idea de que una aplicación se descomponga en una serie de aspectos totalmente independientes entre sí, esto, en la práctica, no suele ocurrir.
Otro importante beneficio que se consigue es que no es necesario el código fuente de una aplicación para poder modificarla, ya que todo el proceso se realiza partiendo del código binario que se traduce a MSIL. Además, el sistema no necesita modificar la máquina abstracta con lo que se puede usar con cualquier aplicación estándar.
15 Tejedor dinámico de aspectos sobre la plataforma .NET
4 Ventajas del Sistema y Conclusiones
El trabajo que estamos llevando a cabo establece que, mediante la aplicación de técnicas de reflectividad computacional sobre una máquina virtual independiente del lenguaje y plataforma, es factible implementar un tejedor realmente dinámico de as-pectos con un amplio conjunto de puntos de enlace. Mediante el uso de la plataforma .NET este sistema presenta las siguientes ventajas:
1. Independencia del lenguaje. Tanto la aplicación a adaptar como los aspectos que la adaptan se pueden escribir en cualquier lenguaje, ya que todo el proceso se realiza sobre código traducido al lenguaje intermedio MSIL.
2. Los aspectos y la funcionalidad principal siguen ciclos de vida completamente in-dependientes. Gracias a esto se obtiene una mayor reusabilidad de ambos y una mayor facilidad de depuración al no estar el código enmarañado.
3. Independencia de la plataforma. Al realizar todo el proceso al nivel de la máquina virtual se obtiene total independencia de la plataforma sobre la que se implementa. 4. No es necesario disponer del código fuente de una aplicación para poder adaptarla, puesto que todo el proceso se lleva a cabo sobre código MSIL. Esto puede ser muy útil en el caso de tener que modificar una aplicación de terceros.
5. Utilización de máquina virtual estándar. El sistema no necesita modificar la má-quina virtual, por lo que cumple la especificación ECMA. Por tanto, se puede utili-zar el sistema con cualquier aplicación que funcione sobre el CLR estándar. 6. El sistema ofrece un amplio conjunto de puntos de enlace. El mecanismo que
utili-za el sistema no limita el rango de puntos de enlace que puede capturar cualquier aplicación. De este modo se pueden desarrollar aspectos de la misma forma que en AspectJ, pero tejiéndolos en tiempo de ejecución. En esta versión el sistema puede controlar ejecuciones e invocaciones a métodos y/o constructores, accesos de cual-quier tipo (lectura –reference- o escritura -set-) a campos (field) y a propiedades (property) y la inicialización estática, todo ello con los modificadores de tiempo before, after y around.
7. Un aspecto se puede adaptar por medio de otro aspecto. Los aspectos son aplica-ciones normales que trabajan dentro del sistema, por lo que siguen los mismos pa-sos que el resto de las aplicaciones y pueden ser adaptados de igual manera. Esto abre la posibilidad de descomponer una aplicación en varios aspectos que interac-túen entre ellos, tal y como ocurre en la práctica, donde es difícil encontrar aspec-tos totalmente independientes entre sí.
8. Al realizarse el proceso de composición en tiempo de ejecución y no de carga, es posible destejer aspectos que ya no se necesiten. Cuando un aspecto deja de ser ne-cesario informa al servidor de esto con lo que deja de ser notificado, no incurriendo en una penalización innecesaria en el rendimiento.
Referencias
1. Parnas, D., 1972. On the Criteria to be Used in Decomposing Systems into Modules. Com-munications of the ACM, Vol. 15, No. 12.
2. Hürsch, W.L., Lopes, C.V., 1995. Separation of Concerns, Technical Report UN-CCS-95-03, Northeastern University, Boston, USA.
3. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C.V., Loingtier, J.M., Irwin, J., 1997. Aspect Oriented Programming. In: Proceedings of European Conference on Ob-ject-Oriented Programming (ECOOP), vol. 1241 of Lecture Notes in Computer Science. 4. Popovici, A., Gross, Th., Alonso, G., 2001. Dynamic Homogenous AOP with PROSE,
Technical Report, Department of Computer Science, ETH Zürich, Switzerland.
5. Suvée, D., Vanderperren, W., and Jonckers, V. JAsCo: an Aspect-Oriented approach tai-lored for Component Based Software Development.In Proc of international conference on aspect-oriented software development (AOSD), Boston, USA, march 2003.
6. Ortin, F., and Cueva, J. M. Building a Completely Adaptable Reflective System. 2001. Eu-ropean Conference on Object Oriented Programming ECOOP'2001. Workshop on Adaptive Object-Models and Metamodeling Techniques, Budapest, Hungary, June 2001.
7. Francisco Ortin and Juan Manuel Cueva. Non-Restrictive Computational Reflection. Else-vier Computer Software & Interfaces. Volume 25, Issue 3, Pages 241-251. June 2003. 8. Francisco Ortin, Juan Manuel Cueva. Implementing a real computational-environment jump
in order to develop a runtime-adaptable reflective platform. ACM SIGPLAN Notices, Vo-lume 37, Issue 8, August 2002
9. Luis Vinuesa, Francisco Ortin. A Dynamic Aspect Weaver over the .NET Platform. Revised Papers of Metainformatics International Symposium, MIS 2003. Graz, Austria, September 2003. Vol. 3002 of Lecture Notes in Computer Science.
10. Bruno Cabral, Paulo Marques, Luís Silva, "IL Code Instrumentation with RAIL", .NET Developers Journal, Vol. 2, #1, pp. 34, January-2004
11. Donal Lafferty, Vinny Cahill. Language-Independent Aspect-Oriented Programming.
OOPSLA’03, October 26–30, 2003, Anaheim, California, USA.
17 Tejedor dinámico de aspectos sobre la plataforma .NET
Dos modelos arquitectónicos para el DSOA
1A. Navasa*, K. Palma+, J.M. Murillo*, Y. Eterovic+
[email protected], [email protected], [email protected], [email protected] Quercus Software Engineering Group
*Universidad de Extremadura. España +Pontificia Universidad Católica. Chile
Abstract.
El desarrollo software de grandes sistemas presenta dificultades debido a su complejidad. Dentro del proceso de desarrollo, la arquitectura del software está adquiriendo gran importancia tanto en cuanto permite afrontar la construcción de los sistemas desde un punto de vista estructural, reduciendo la complejidad de los mismos y facilitando su mantenimiento. Por otra parte técnicas de separación de aspectos facilitan igualmente la evolución de estos sistemas al proponer diseños limpios y código altamente cohesivo. En este artículo el grupo Quercus presenta cómo afrontar el desarrollo de sistemas orientados a aspecto desde el punto de vista de la arquitectura del software, aportando dos propuestas metodológicas.
Palabras clave: DSOA, Arquitectura Software, LDA
1. Introducción
Las necesidades cada vez más restrictivas del mercado del software y el hecho de que cada día se amplíe más el ámbito de las aplicaciones software así como el número de campos en los que son requeridas hacen que, hoy día, la construcción de software sea una tarea realmente compleja. A menudo esto desemboca en la construcción de software de forma apresurada, con poca calidad y cuya evolución y mantenimiento es muy costosa. Nuevas técnicas como la Programación Orientada a Aspectos han incidido directamente en estos problemas permitiendo disminuir los problemas de enmarañamiento y dispersión del código. Sin embargo, ello se consigue desplazando la responsabilidad de la obtención de un código limpio a los programadores [1]. Para evitar esta sobrecarga del trabajo de los programadores las nuevas tendencias en desarrollo software proponen gestionar la complejidad durante la fase de diseño arquitectónico. Una corriente importante dentro del DSOA propone una identificación y separación temprana de aspectos [2], liberando parcialmente a los programadores de dicha responsabilidad, y obligando a los ingenieros de software y diseñadores a producir sistemas con diseños limpios y código con alta consistencia.
El objeto de este artículo es presentar algunas de las líneas de investigación que el grupo Quercus [3] está desarrollando dentro del DSOA, concretamente trabajando en
la fase de arquitectura del software. En los próximos puntos se presentan dos de las líneas de trabajo que se están desarrollando y que se refieren a dos formas diferentes de afrontar la arquitectura del software para sistemas Orientados a Aspecto. Se presentan dos aproximaciones metodológicas que tienen como nexo común el de considerar el problema de la separación de aspectos como uno de coordinación.
El artículo se estructura como sigue: en la sección 2 se presenta el problema de la separación de aspectos a nivel arquitectónico, y cómo la investigación en curso lo afronta desde dos puntos de vista. En las secciones 3 y 4 se presentan ambas propuestas. En las secciones 5 y 6 se mencionan algunos trabajos relacionados, algunas consideraciones finales y trabajos futuros.
2. Problemática de la separación de aspectos a nivel arquitectónico.
La estructura de los sistemas software no es estática sino que cambia y evoluciona para adaptarse a nuevas circunstancias. Por ello, cada vez es más importante que los desarrollos sean fácilmente adaptables y que su evolución suponga un esfuerzo reducido.
La reutilización de componentes ha abaratado los costes de desarrollo y mantenimiento, pero no siempre es sencillo cambiar un sistema heredado debido diversas causas: los componentes son de caja negra, los cambios no son compatibles con los componentes iniciales o son cambios no previstos, etc. Las técnicas de separación de aspectos aplicadas durante las distintas fases del ciclo de vida han mejorado las posibilidades de evolución y adaptación de los sistemas al permitir la obtención de código no mezclado, altamente cohesivo y módulos con bajo acoplamiento. Estas técnicas, junto con la reutilización de componentes comerciales o de diseño propio facilitarán el mantenimiento de los sistemas.
Cuando se estudia el desarrollo de sistemas durante la fase de diseño arquitectónico, los elementos que se consideran son componentes y conectores, obteniéndose su definición estructural. Con respecto al diseño arquitectónico, el DSOA propone considerar durante la arquitectura del software los aspectos como entidades de primera clase (aspectos arquitectónicos) que matizan el comportamiento del sistema [4]. Así, se extraen y encapsulan anticipadamente una serie de propiedades que de otro modo resultarían más tarde en un código disperso en diversos componentes. Sin embargo, los nuevos elementos introducidos en el sistema tienen que integrarse en él. Para ello, deben especificarse los nuevos aspectos como componentes de diseño y definirse para ellos sus relaciones con el resto del sistema.
La especificación de los sistemas a nivel arquitectónico se realiza con los llamados lenguajes de descripción arquitectónica (LDA), que definen de un modo formal los componentes de diseño y su interacción. Sin embargo estos lenguajes no son adecuados para tratar los sistemas orientados a aspectos [5], siendo necesario definir LDAs específicos [6], o adaptar los lenguajes de propósito general a las nuevas necesidades. Las dos líneas de investigación que aquí se presentan han optado por esta última vía.
Ambas líneas de trabajo consideran LDA genéricos (LEDA [7] y Rapide [8]), dinámicos y ejecutables, que van a ser ampliados con nuevos juegos de instrucciones para aplicarlos al diseño de sistemas orientados a aspectos. En ambas propuestas, la
separación se aspectos a nivel arquitectónico se trata como un problema de coordinación siguiendo la línea establecida en algunos trabajos previos [1, 5]. Para ello se están aplicando modelos de coordinación exógenos [9].
En los dos próximos puntos se describen someramente las dos líneas de trabajo. Ambas, aunque con enfoques distintos, tratan de resolver el problema que, de modo general, se puede enunciar así: Desarrollar sistemas orientados a aspectos, usando un
enfoque metodológico, trabajando desde el diseño arquitectónico, utilizando lenguajes de descripción arquitectónica de propósito general dinámicos y ejecutables, y aplicando modelos de coordinación exógenos.
3. Un modelo arquitectónico para el diseño orientado a aspectos.
En la primera de las líneas mencionadas, se propone una aproximación metodológica en la que nuevos aspectos se integran en un sistema de un modo coordinado, se definen 2 niveles arquitectónicos, se utiliza un LDA genérico (LEDA), y un modelo de coordinación (Coordinated Roles [10]) para gestionar la interacción de componentes funcionales y de aspecto.
La propuesta se desglosa en una serie de pasos (Figura 1) en los que se destaca la necesidad de hacer una identificación temprana de los aspectos. Se propone hacer una especificación inicial detallada del sistema sin considerar aspectos (paso 1), creando el modelo de diseño
corres-pondiente (paso 2), y des-cribiendo el modelo en el LDA (en este caso LEDA). A continuación, se propone una iteración en la que se añaden los aspectos al modelo obtenido, consi-derados como componen-tes de diseño (paso 3). Para ello, se propone definir una arquitectura con 2 niveles (paso 4). El nivel inferior considera el sistema básico (sin aspectos), y el segundo (nivel de aspecto), definido sobre él, considera los elementos necesarios para
incluir los aspectos. Figura 1 Pasos de la propuesta.
La Figura 2 muestra la estructura del sistema extendido con ambos niveles. Por falta de espacio no se detallan los elementos del nivel de aspecto, sólo se da una breve descripción de su contenido:
Conjunto A de componentes de aspecto.
Conjunto Items-Comunes: estructura estática que contiene el conjunto de informaciones que describen cómo son las nuevas interacciones entre los compo-nentes funcionales (Comp) y de aspecto (A), así como sus condiciones de aplicación
1 E s p e c ific a r e l s is te m a c o n D . d e C a s o s d e U s o . S is te m a b á s ic o . S in a s p e c to s 2 . C r e a r e l m o d e lo d e d is e ñ o E x te n s io n c o n a s p e c to s n o D e fin ir e l s is te m a e n A D L y g e n e ra r e l p r o t o tip o s i 3 A ñ a d ir u n a s p e c to 4 D e fin ir u n a A r q u ite c tu r a O A 5 E x p r e s a r e l s is te m a e x te n d id o e n e l A D L 6 G e n e r a r u n p r o to tip o e n e l A D L p a r a e l s is te m a e x te n d id o A ñ a d ir m á s a s p e c to s s i n o E je c u ta r p r o to tip o 2 .1 C o n s tru ir lo s D . d e S e c u e n c ia p a r a c a d a C .U . 2 .2 D e s c o m p o n e r e l s is te m a e n c o m p o n e n te s d e d is e ñ o . 2 .3 D e s c r ib ir la a r q u ite c tu r a d e l s is te m a 2 . C r e a r e l m o d e lo d e d is e ñ o 3 .1 D e fin ir u n a e x te n s ió n , id e n tific a r e x te n s io n p o in t 3 .2 R e d e fin ir D . d e s e c u e n c ia im p lic a d o s e n la e x te n s ió n . 3 . A ñ a d ir u n A s p e c t o 4 .1 D e fin ir C o m m o n -Ite m s 4 .2 D e fin ir la s r e g la s R 4 .3 D e fin ir d e B la c k B o a rd 4 .4 D e fin ir C o n tr o l P r o c e s s 4 . D e fin ir u n a a r q u it e c t u r a O A 4 .5 D e fin ir e l c o n ju n to A Dos modelos arquitectónicos para el DSOA 21
(Cla_Wh cond). Así mismo contiene los puntos de corte (IP) de los aspectos sobre los componentes funcionales y el evento que desencadena la aplicación del aspecto (Ev). - El conjunto R de reglas
representa cómo es la interacción de los com-ponentes de aspecto del
nivel de aspecto con los
componentes del inferior. Expresan las acciones a ejecutar cuando se den las condiciones de aplica-ción. Esta información se deduce de la almacenada en el conjunto
Items-Comunes. Figura 2. S extendido: N. de componente y nivel de aspecto
El formato genérico de una regla es:
IF event | IP OF Comp | cond THEN
DO [Aspect_Op_Name(Param)] WHEN when_condition.
- BlackBoard es una estructura dinámica que almacena los eventos que se producen en el sistema en tiempo de ejecución, junto con otra información de interés.
- Proceso de Control (CP): Proceso que gestiona la ejecución coordinada del
sistema extendido a partir de las reglas. Este es un proceso complejo, que debe
gestionar las interacciones de los nuevos elementos añadidos al sistema. Por esta razón, se descompone en un conjunto de componentes coordinadores (en el sentido de
Coordinated Roles2), cuya definición depende de los aspectos, y los puntos de corte, y
un coordinador de coordinadores (Supercoordinador o SC). Los eventos que pueden desencadenar la actuación del proceso de control son: la recepción de mensajes síncronos y asíncronos, y que un componente alcance un cierto estado. La Figura 3 describe el funcionamiento de CP cuando se recibe un mensaje síncrono.
Realizada la descripción detallada del sistema extendido con los elementos anteriores, se expresa en un LDA -en nuestro caso LEDA-(paso 5 de Figura 1), donde los elementos definidos se convierten en componentes del lenguaje. Esta descripción se puede generar automáticamente de un modo parcial a partir de la descripción LEDA del
sistema básico y las informaciones
del conjunto de items comunes. Figura 3. Descripción del funcionamiento de CP.
Finalmente se puede ejecutar un prototipo del sistema extendido (paso 6), conociendo así su comportamiento en tiempo de diseño. Además, la propuesta
2 Coordinated Roles es un modelo de coordinación que se basa en la definición de un Protocolo
de Notificación de Eventos que permite coordinar elementos que no han sido definidos para ello. Servidor CO-i Cliente SC BB (3) (3’) (4) (5) CP Aspecto-i Meta nivel-ML Nivel de componente (1) (6) (2) (5’) Common Items (C-I) C-Ii(IP)={IPi_id, Com_id, Ev, Cond, when_Cla A Reglas R Proceso de control CP (coordinador) C1 C2 C3 Nivel de componente
Arquitectura Orientada a Aspecto
BlackBoard (Eventos detectados)
Nivel de aspecto 22 A. Navasa, K. Palma, J. M. Murillo, Y Eterovic
permite añadir o eliminar aspectos de un modo sencillo, repitiendo los pasos 3 a 6 de la Figura 1.
4. AO-Rapide
En la segunda línea de trabajo se propone definir una ampliación a Rapide (AO-Rapide) que soporte la especificación de arquitecturas orientadas a aspecto formalizando la interacción entre componentes funcionales y de aspecto. En este caso se hace uso del modelo de coordinación Reo [11], basándose en él las primitivas de coordinación que extienden Rapide. Este es un modelo de coordinación que permite definir un conjunto de operaciones para especificar los protocolos de coordinación mediante un conjunto de canales con un comportamiento bien definido y que se pueden componer.
Rapide es un lenguaje orientado a objetos concurrente basado en eventos diseñado para simular y analizar el comportamiento de arquitecturas de sistemas distribuidos. En Rapide una arquitectura consiste de un conjunto de especificaciones de módulos (llamadas interfaces), un conjunto de reglas de conexión que definen la comunicación directa entre las interfaces y un conjunto de restricciones formales que definen los patrones legales y / o ilegales de comunicación.
Reo es un modelo de coordinación exógeno basado en canales, donde
coordinadores complejos llamados conectores son construidos a través de la composición de otros más simples. Cada conector en Reo impone un patrón de coordinación específico sobre los componentes que realizan operaciones de E/S a través de él, sin el conocimiento de estos componentes.
En AO-Rapide, una arquitectura orientada a aspectos puede ser especificada en términos de componentes funcionales, componentes de aspecto y conectores. Estos últimos permiten especificar la interacción sincronizada entre componentes funcionales y de aspecto (Figura 4).
Tanto los componentes funcionales como los de aspecto son tratados como componentes Rapide convencionales. Cada componente funcional posee un wrapper cuya misión es comunicar a los conectores la ocurrencia de join points3 (eventos). La existencia de un wrapper permite preservar el principio de la inconsciencia [12] - ya que los diseñadores no deben especificar los join points directamente en los componentes funcionales- e incorporar o eliminar aspectos sin impacto sobre los componentes funcionales.
Los conectores son los encargados de establecer las reglas de coordinación que determinan cuándo y cómo la especificación de los aspectos debe ser tratada. Los conectores tienen tres partes (Figura 4):
- El coordinador. Es un conector Reo, especificado como un componente Rapide. - El enlace entre el wrapper del componente funcional y el coordinador, llamado
wrapper linker. Debe ser construido para cada conexión entre el wrapper de un
componente funcional y un coordinador. Este componente solicita los join points de
3 Llamadas a funciones o retornos de funciones que pertenecen al componente funcional
asociado al wrapper.
23 Dos modelos arquitectónicos para el DSOADos modelos arquitectónicos para el DSOA
interés al wrapper. Una vez alcanzado un join point, este componente actúa produciendo operaciones de E/S sobre el coordinador.
- El enlace entre el coordinador y el componente de aspecto, llamado
aspect linker. Debe ser construido
para cada conexión entre un coordinador y un componente de aspecto. Su propósito es traducir las operaciones de E/S realizadas sobre el coordinador a las invocaciones de los servicios correspondientes del componente de aspecto.
Figura 4. Conexión entre un C. funcional y uno de aspecto.
El objetivo de dividir los conectores en tres partes es proporcionar al diseñador coordinadores genéricos que no hagan referencia en su especificación a ningún componente y que impongan patrones de coordinación de uso común en la orientación a aspecto. Esto también permite que el diseñador pueda crear y reusar sus propios coordinadores.
Una vez que el diseñador ha identificado los componentes funcionales y los aspectos de su sistema, se puede especificar la arquitectura del sistema a través de la siguiente lista de pasos:
1. Especificar cada componente funcional y de aspecto como un componente Rapide. 2. Identificar aquellos componentes funcionales a los que se quieren asociar aspectos. 3. Para cada componente funcional identificado en el punto anterior, se debe determinar cuáles son los join point específicos en los que hay que asociar el o los componentes de aspecto.
4. Determinar cuales son las reglas de composición, que corresponden a las reglas de coordinación que gobernarán la interacción entre un join point de un componente funcional y el o los componentes de aspecto asociados a este join point.
5. Construir (a partir de la especificación de Reo y sus reglas de composición) los componentes coordinadores que implementan las reglas de coordinación estipuladas en el punto anterior o utilizar alguno de los proporcionados por AO-Rapide.
6. Conectar cada wrapper de un componente funcional a su correspondiente coordinador, a través del wrapper linker apropiado. Especificando los join point identificados en el paso tres y los efectos asociados a cada join point.
7. Conectar cada coordinador al aspecto correspondiente, a través del aspect linker apropiado.
5. Trabajos relacionados.
En esta sección se comentan algunos de los trabajos que se están desarrollando actualmente y que proponen separar aspectos en etapas tempranas del ciclo de vida. .
ASAAM, dentro del proyecto AOSAD [4], estudia la especificación de aspectos arquitectónicos, mediante reglas que permitan deducirlos, así como identificar los componentes que cruzan, desde la utilización de escenarios. [13] estudia los aspectos en un entorno de DSBC, retrasa el estudio de los requisitos de los componentes
orientados a aspecto al nivel de diseño. MDSoC [14] introduce el concepto de
hyperslice, para encapsular y gestionar la relación e integración de aspectos. Usa
HiperJ como herramienta, pero este modelo está más próximo a la implementación. Otros, como [15] o [16] también están próximos a la implementación. Por su parte, [17, 18, 19] se refieren a la identificación temprana de aspectos según diversos procedimientos, pero no especifican cómo se puede ejecutar el sistema así definido. [20, 21] consideran el DSOA desde el punto de vista de la arquitectura del software. Ninguno de ellos propone la utilización de un LDA para describir los sistemas orientados a aspecto a nivel de diseño, ni la utilización de un modelo de coordinación para tratar su interacción con los componentes funcionales. En [6] se describe un LDA para desarrollar sistemas orientados a aspectos. Sin embargo, este lenguaje se basa en XML con las ventajas que ello supone, pero carece de una base formal fuerte.
6. Conclusiones y trabajos futuros.
Los dos trabajos presentados tratan el problema de la separación de aspectos desde le punto de vista estructural, afrontando el problema como uno de coordinación. Los sistemas diseñados bajo estas propuestas tienen diseños limpios, componentes altamente cohesivos al separar componentes funcionales y de aspecto, y son de fácil mantenimiento. Ambas líneas de trabajo utilizan LDAs que facilitan el análisis y la simulación de la ejecución de un sistema en fase de diseño. Los lenguajes han de ser ampliados para adaptarse al desarrollo de sistemas orientados a aspecto. El carácter de las ampliaciones es permitir la ejecución coordinada de los aspectos, considerados como componentes de diseño, y los componentes funcionales sobre los que se aplican. Los dos modelos de coordinación que se aplican (Coordinated Roles y Reo) son exógenos, lo que significa que los elementos a coordinar preservan el principio de inconsciencia [12]. Esto permite mantener separada la funcionalidad del sistema de los componentes de aspecto, y además que los componentes funcionales no tengan que modificarse para modificar el sistema.
Ambas propuestas difieren en la forma de integrar los aspectos en el sistema dado que los lenguajes en los que se apoyan son conceptualmente distintos. LEDA trabaja sobre el concepto de conector, que es una entidad de primera clase, Sin embargo, en Rapide es necesario definir los wrapper para integrar los aspectos al sistema.
Los sistemas diseñados con estos modelos arquitectónicos son de fácil evolución y fácilmente adaptables. Evolución y adaptación se consiguen considerando los nuevos requisitos como nuevos aspectos a incorporar al sistema.
Actualmente los trabajos en curso son:
- Se están desarrollando sendas herramientas que permitan generar del modo más
automático posible el nuevo sistema.
- Se está completando la formalización de las ampliaciones de LEDA y Rapide.
- Se están estudiando otros lenguajes, como ArchJava [22] y Acme [23], en los que
expresar las propuestas.
- Estamos estudiando diversificar el tipo de eventos detectables.
- Consideramos como expresar el dinamismo como un aspecto.
- Nos proponemos evaluar las consecuencias de elegir diferentes lenguajes y
modelos de coordinación a la hora de diseñar sistemas orientados a aspectos.
7. Bibliografía
[1] Navasa, A., Pérez, M.A., Murillo, J.M., Hernández, J. “Aspect Oriented Software Architecture: A structural Perspective”. Workshop on Early Aspect. AOSD Conference 2002. http://trese.cs.utwente.nl/AOSDEarlyAspectsWS/workshop_papers.htm. Holanda. [2] Early Aspects home page http://www.early-aspects.net/
[3] Quercus Software Engineering Group home page http://quercusseg.unex.es/QuercusProy/ [4] Aspect-Oriented Software Architecture Design Portal http://trese.cs.utwente.nl/taosad/ [5] Navasa, A., Pérez, M.A., Murillo, J.M. “Using an ADL to Design Aspect Oriented
Systems”.13th Workshop PHDOOS. ECOOP 2003.
[6] Pinto,M.,Fuentes,L.,Troya,J.M.“DAOP-ADL:an Architecture Description Languae for Dynamic Component and Aspect-Based Development”. Proc. of 2nd Int. Conf. on GPCE, vol.
2830 Lecture Notes in Computer Science, pp. 118-137, Germany. Springer-Verlag. 2003. [7] Canal, C, Pimentel, E., Troya, M. “Compatibility and Inheritance in Software Architcture”.
Review Scene and Computing Programming, vol. 41 no. 2, pp. 105-130. 2001.
[8] Luckman, D.C., Kenney, J.J., Augustin L.M., Vera, J., Bryan, D., Mann, W., “Specification and Analysis of Systems Architecture Using Rapide”. IEEE transaction on Software Engineering. Special Issue on Software Architecture, vol. 21, no. 4, april 1995, pp. 336-355. [9] Arbab F., “What Do You Mean Coordination?”. Bulletin of the Duth Association’96. LNCS
1061. Springer-Verlag. Cesena. Abril 1996.
[10] Murillo, J.M., Hernandez, J.,Sánchez, F., Alverez, L. “Coordinated Roles: Promoting Re-Usability of Coordinated Active Objects Using Event Notification Protocol”. Coordination Proceeding, pp. 53-68, 1999.
[11] Arbab, F., Reo: A Channel-based Coordination Model for Component Composition. Mathematical Structures in Computer Science, vol. 14, Issue 3, June 2004, pp. 29-366.
[12] Filman, R.E., Friedman, D.P. “Aspect-Oriented Programming is Quantification and Obliviousness”. Workshop on Advanced Separation of Concerns. OOPSLA 2000, USA. [13] Grundy, J. “Aspect-Oriented Requirements Engineering for Components-based Software
Systems”. 4th IEEE International Symposium on Requirements Engineering. IEEE Computer
Society, Limerick, Ireland, 1999, pp.84-91
[14] Tarr, P. ,Ossher, H. “Multidemensional Separation of Concern and Hyperslices Approach”. Proceeding of Symposium on Software Architecture and Component Technology: the State of the Art in Software Development. Kluwer. Jan 2000.
[15] Clarke, S., Walker, R. “Towards a Standard Design Language for Aspect Oriented Development”. AOSD Conference. Enschede, Holanda, 2002.
[16] Sureé, D., Vanderperren, W., Jonkers, V. “JasCo: an Aspect Oriented Approach Taylored for CBSD”. AOSD Conference. Boston, USA, 2003.
[17] Sutton,S.M.,Rouvellow,I. “Modeling sotftware concerns in Comos”. AOSD’02 Conf. [18] Rashid, A., Moreira, A. Araujo, J. “Modularisation and Composition of Aspect
Requirements”. AOSD Conference. Boston USA, 2003
[19] Brito, I., Moreira. A., “Towards a Composition Process for Aspect-Oriented Requirements”. Workshop on Early Aspects 2003. AOSD conference. Boston USA. [20] Katara, M., Katz, S. “Architecture Views of Aspects”. AOSD Conference., USA, 2003. [21] Kande, M. M. “A Concern-Oriented Approach to Software Architecture”. Tesis Doctoral
nº2796 Lausane, EPFL, 2003.
[22] Aldrich, J., Chambers, C., Notkin, D., “Architectural reasoning in ArchJava”. ECOOP’02, June 2002 Malaga, Spain.
[23] Garlan, D., Monrie, R.T., Wie, D. “Acme: An Architecture Description Interchange Language”. Proceeding of CASCON'97. Ontario, Canada 1997.
Configuración de Propiedades No Funcionales en los
Servicios Web Usando Técnicas de Orientación a
Aspectos
1Guadalupe Ortiz, Juan Hernández, Pedro J. Clemente
Quercus Software Engineering Group Universidad de Extremadura Departamento de Informática
Avda. de la Universidad s/n. 10071 Cáceres, Spain
http://quercuseg.unex.es
{gobellot, juanher, jclemente}@unex.es
Abstract. Las tecnologías de Servicios Web han alcanzado un gran éxito,
convirtiéndose en la mejor forma de integrar aplicaciones Web. Sin embargo, las propuestas actuales no proporcionan ningún método aceptable para desacoplar las propiedades no funcionales de las implementaciones de los Servicios Web, con la consecuente aparición de código mezclado y disperso a lo largo de la aplicación, surgiendo, por tanto, problemas de diseño, implementación, mantenimiento y evolución. Las técnicas de orientación a aspectos permiten desacoplar, modularizar y reutilizar dichas propiedades, siendo éste el propósito de este artículo. Además, y siguiendo el estándar de la W3C, el documento WSDL se utiliza para mostrar información sobre las propiedades aplicadas en el servicio, así como, aquellas que el cliente puede elegir añadir para su ejecución de forma transparente, generando automáticamente los cambios necesarios en la codificación del éste de forma modularizada y desacoplada.
1. Introducción
Los Servicios Web se han situado como uno de los más importantes puntos de mira del mercado del software hoy en día, proporcionando una nueva tecnología mediante la cual las aplicaciones Web pueden interactuar fácilmente entre ellas, y convirtiéndose en la mejor manera de integrar aportaciones de terceros [1]. Sin embargo, debido a la relativa juventud de esta tecnología, aún no se han afrontado algunos puntos importantes tales como la adición de propiedades no funcionales a los servicios, siendo un factor fundamental al considerar la rápida evolución hacia servicios cada vez más amplios y complejos.
En el ámbito de la programación basada en componentes [2], existen muchos trabajos en los que se afronta con éxito este problema, bien mediante el uso de
contenedores [3] o bien mediante la aplicación de técnicas orientadas a aspectos [4][5][6][7][8][9]. Debido a que en el ámbito de los Servicios Web no disponemos de la figura del contenedor, proponemos el uso de técnicas orientadas a aspectos para la adición de propiedades no funcionales a dichos servicios [10], siendo ésta la principal contribución de este artículo. Asimismo, en el archivo WSDL (Web Service Description Language) se incluye la información relativa a las propiedades no funcionales aplicadas en el servicio. En este sentido, algunas propiedades son exclusivas del servicio (por ejemplo un servicio de log), es decir, no afectan a los clientes. Sin embargo, otras propiedades no funcionales en el servicio, que sí afectan al cliente, bien en el resultado de la operación o implicando cambios en su codificación, pueden ser aprovechadas de forma opcional por éstos (por ejemplo, la encriptación de datos). Además, la información sobre las propiedades en el servicio se ha incluido en la etiqueta de documentación del archivo WSDL, de este modo el cliente que desconoce su propósito puede realizar su invocación normalmente.
El resto del artículo se estructura como sigue. La segunda sección revela cómo AOP permite añadir propiedades no funcionales a los Servicios Web de manera automática y transparente; así como la forma en que los clientes pueden elegir qué propiedades se aplican en su invocación. Comentamos otras propuestas relacionadas en la sección 3 y, finalizamos este artículo con las conclusiones principales.
2. Adición de Propiedades No Funcionales a los Servicios Web
Los Servicios Web han evolucionado rápidamente desde su aparición, implementando funcionalidades cada vez más complejas; es por esta razón, por la que debemos modelar las propiedades no funcionales de manera bien encapsulada, de modo que no interfieran con el resto de la aplicación. Como demostramos en esta sección, dichas propiedades se pueden añadir mediante el uso de técnicas de orientación a aspectos, permaneciendo encapsuladas y bien modularizadas, facilitando así el mantenimiento y evolución de los servicios. Las propiedades no funcionales se añaden siempre en el servicio. Sin embargo, a veces la adición de una propiedad al servicio puede afectar al cliente e incluso implicar cambios en la codificación de éste, caso que estudiaremos posteriormente en la subsección 2.1, centrándonos ahora sólo en la parte del servicio.Para el desarrollo de los ejemplos hemos hecho uso de una herramienta de propósito general llamada Java Web Service Development Pack (JWSDP), entorno gratuito proporcionado por Sun Microsystems para la construcción de Servicios Web. Relativo al uso de la programación orientada a aspectos, hemos elegido AspectJ entre los diferentes lenguajes existentes en el mercado, tanto por su proximidad al lenguaje Java como por sus múltiples posibilidades con herramientas de desarrollo gratuitas.
La herramienta JWSDP proporciona una serie de directivas para la construcción y el despliegue de los servicios, que son interpretadas por la herramienta ant. Las directivas necesarias para la construcción del servicio pueden verse en la Figura 1.a) Con la intención de hacer transparente al programador la adición de propiedades no 28 G. Ortiz, J. Hernández, P. J. Clemente
funcionales con AspectJ, además de sustituir la compilación Java por el weaving de AspectJ, hemos añadido nuevas directivas y un proceso de generación de código que serán invocados durante la construcción del servicio, como puede verse en la Figura 1.b). En primer lugar, hemos incluido un proceso de generación automática del aspecto que queremos aplicar, por ejemplo sobre unos métodos específicos (Create_Timing_Aspect); a continuación, se incluye el aspecto en el archivo de configuración de la compilación (Add_timing_toConf); y, finalmente, se incorpora al documento WSDL la información relativa al aspecto que se ha añadido (Add_timing_ToWSDL). Respecto a las nuevas directivas de compilación, su funcionalidad es compilar y ejecutar el proceso de generación de código que acabamos de describir.
Fig. 1. Directivas para la construcción de un servicio con y sin el uso de AOP
A modo de ejemplo, la propiedad timing se puede modelar como un aspecto de AspectJ. Esta propiedad es de gran interés en el ámbito de los Servicio Web al haber muchos servicios facturables en función del tiempo de uso, y solamente afecta al servidor, ya que el cliente obtiene la misma información de la operación invocada independientemente de que se esté controlando el tiempo de uso. Así pues, para hacer uso de ella, incluimos la directiva correspondiente a esta propiedad en la compilación, con lo cual se genera el aspecto correspondiente y se añade a la lista de ficheros a compilar automáticamente en tiempo de compilación y, de forma igualmente transparente, se agrega a la etiqueta de documentación del archivo WSDL la
a) Directivas para la construcción del servicio sin la adición de propiedades como aspectos
b) Directivas para la construcción del servicio con la adición de propiedades como aspectos
Clean (elimina los archivos fruto de la compilación anterior)
Compile-service (compila el interfaz del servicio y su implementación) Generate-service (genera el documento WSDL y algunas clases necesarias) Compile-server (compila los nuevos archivos generados)
Create-raw-war (empaqueta los archivos necesarios para la invocación remota) Build-war (prepara el paquete anterior para su despliegue y lo empaqueta de nuevo)
Clean (elimina los archivos fruto de la compilación anterior)
Add timing (Genera el aspecto timing y lo añade al
archivo de configuración de la compilación)
Compile-service-with AspectJ (compila el interfaz del servicio, su implementación y
los aspectos generados)
Generate-service (genera el documento WSDL y algunas clases necesarias) Add_Timig_ToWSDL (añade la información del aspecto timing al WSDL) Compile-server-with AspectJ (compila los nuevos archivos generados) Create-raw-war (empaqueta los archivos necesarios para la invocación remota) Build-war (prepara el paquete anterior para su despliegue y lo empaqueta de nuevo)
Create_Timing_Aspect Add Timing ToConf
29 Configuración de propiedades no funcionales...
información relativa a la propiedad añadida, tal como describimos previamente en la Figura 1.b).
El documento WSDL está formado por diversas etiquetas relativas al interfaz, operaciones, parámetros, puerto…, del servicio; y es utilizado por el cliente para crear los objetos locales para la invocación de dicho servicio. La información que hemos añadido al archivo WSDL tiene la función de informar al cliente de las nuevas propiedades agregadas al servicio, facilitando su descripción y las operaciones del servicio sobre las que se han aplicado las propiedades, así como si la propiedad se aplica siempre que se invoca el servicio o es opcional, tal como muestra la Figura 2. Dicha información se ha incluido en una etiqueta de documentación, respetando el estándar de la W3C, de modo que el cliente que desconozca su función no se ve afectado en su invocación.
Fig. 2. Propiedad de control de tiempo timing
Así pues, el programador elige qué propiedad quiere aplicar y, de forma absolutamente transparente, se crea el aspecto y se añade la información al fichero WSDL en tiempo de compilación. De este modo, al realizar el diseño, el desarrollador puede centrarse en la funcionalidad de la aplicación, agregando las propiedades, de entre un pool de propiedades disponibles. Por ejemplo, ahora podríamos añadir la propiedad logging a la aplicación ya desarrollada de forma totalmente transparente. 2.1 Propiedades Elegidas por el Cliente
Dado que mostramos información sobre las propiedades añadidas en el archivo WSDL, también podemos emplear esta información para ofrecer al cliente la posibilidad de elegir qué propiedades del servicio quiere que sean aplicadas. En este sentido, vamos a diferenciar dos casos: en primer lugar, aquellas propiedades que se pueden elegir sin necesidad de realizar cambios en la codificación del cliente, y en segundo lugar, aquellas que sí implican dichos cambios. En ambos casos se han incluido dos procesos: uno en el cliente, que intercepta el mensaje saliente SOAP para añadir información sobre qué propiedades desea aplicar éste; y otro en el servicio, que intercepta el mensaje SOAP entrante para determinar qué propiedades ha elegido añadir el cliente.
<documentation>
<property name=”Timing”>
<description=” Timing property : Measures the operations execution time/> <optional=”no”> <applied to> <operation name=”touristInformation></operation> <operation name=”housingInformation></operation> </applied to> </property> </documentation>
Como ejemplo del primer caso, supongamos un servicio que nos ofrece las cotizaciones en bolsa. El servicio puede ofrecer la misma operación, según el tipo de clientes, con las cotizaciones en tiempo real o con un cierto tiempo diferido. El cliente, al ser la misma operación, no ha de realizar cambios en la codificación de la invocación, pero sí se ve afectado por el resultado. Normalmente la operación devuelve el resultado diferido (clientes normales), pero mediante la aplicación de la propiedad Real Time, puede devolver el resultado en tiempo real (clientes avanzados). El desarrollador del cliente avanzado incluirá la directiva relativa a la propiedad Real Time en su compilación. Esta directiva modificará la clase que intercepta el mensaje saliente para incluir dicha propiedad y la incluirá en la lista de archivos a compilar. En el servicio, por otra parte, se incluye la clase que intercepta el mensaje entrante para determinar qué propiedades ha decidido añadir el cliente. En función de las propiedades añadidas se ejecuta o no el aspecto correspondiente a dichas propiedades. Para el estudio del segundo caso podemos tomar como ejemplo la propiedad de encriptación. El cliente debe realizar cambios en la codificación de las invocaciones, ya que los parámetros deben enviarse encriptados. El servicio ofrece la operación normalmente sin encriptación, pero aquellos clientes que quieran invocar las operaciones con sus datos encriptados tienen la opción de hacerlo. El programador, incluirá la directiva relativa a la propiedad Encriptation y automáticamente se modificará la clase interceptora del mensaje saliente para incluir dicha propiedad, así como el aspecto encargado de encriptar los parámetros. Las modificaciones relativas al servicio serían las mismas que en el caso anterior. Así pues, todo el código se genera de manera transparente, tanto en el cliente como en el servicio. No debemos olvidar que al seguir el estándar de la W3C añadiendo la información en una etiqueta de documentación, no estamos afectando al cliente que desconozca su funcionalidad.
3. Trabajos Relacionados
El desarrollo de los Servicios Web es un área muy en voga hoy en día; y, a pesar de que podemos encontrar múltiples estudios en dicho contexto, no parece haber mucha discusión sobre cómo añadir propiedades no funcionales a los servicios o sobre el uso de AOP. Aún así, podemos destacar algunas propuestas relacionadas con este tema.
En primer lugar, podemos destacar una contribución de S. Göbel et al., en la que se señala la importancia de las propiedades no funcionales en los modelos de componentes, y se especifican, mediante el uso de aspectos, propiedades de seguridad y precisión, así como otras relacionadas con la calidad de servicio [11]. También se sugiere que el cliente pueda establecer sus necesidades no funcionales. Nosotros damos un paso más hacia delante utilizando esta tecnología sobre los Servicios Web.
Por otra parte, podemos subrayar las contribuciones de G. Piccinelly et al. sobre la administración de interacciones en sistemas de Servicios Web mediante la definición de roles de procesos[12][13]. Sugieren el uso de AOP para modelar el crosscutting nacido en la interacción de los sistemas de negocios [12], especificando el aspecto 31 Configuración de propiedades no funcionales...
