Programación por Aspectos. Una IntroducciónPrimer Borrador

Pablo Figueroa y Alejandro Isaza

9 de mayo de 2006

1. Introducción

A mediados de los 90 surgió la programación orientada a aspectos (POA), un nuevo paradigmade programación que ha logrado un nivel de desarrollo interesante y que ha generado expectativasimportantes a nivel mundial. Este paradigma ofrece una nueva herramienta de modularización, elaspecto, junto con nuevas formas de relacionar módulos, por medio de los designadores de enlace;y mediante éstas herramientas provee formas novedosas de implementar aplicaciones que resultanser altamente modulares. Sus conceptos tienen similaridad con conceptos en otros paradigmas deprogramación, como programación generativa [1], metaprogramación [4] o programación declarativa[6], aunque sus seguidores han encontrado una forma de diferenciar y darle carácter propio aldesarrollo orientado por aspectos (DOA).

Este artículo es una introducción al tema de desarrollo orientado por aspectos. Este trabajo hasurgido de grupos de discusión sobre el tema y del curso de pregrado que desarrollamos en el 2005en la Universidad de los Andes, el cual está documentado en [2]. En esta introducción queremosmostrar una breve reseña histórica sobre el tema, los conceptos fundamentales alrededor de la DOA,definir sus características y proponer una forma de referirnos a sus conceptos en Castellano. Graciasa la disponibilidad de ambientes de desarrollo como AspectJ [3] es posible para cualquier lectorcon conocimientos en Java y en programación orientada por objetos desarrollar ejemplos de POAy aplicar sus conceptos fundamentales. Al final presentamos referencias adicionales al tema y unglosario de los conceptos que definimos, junto con los términos en inglés a los que correspondenen la literatura actual de aspectos. Dichos términos serán destacados durante el texto en negrita.Esperamos que esta introducción motive un estudio más profundo del tema por parte de los lectoresy la exploración de las posibilidades de esta tecnología en proyectos reales.

2. Historia

Desde los setentas, autores tan reconocidos como David Parnas han escrito sobre la importancia demodularizar un programa de software [5], y de las formas en las cuales se puede desarrollar esta

1

labor. En resumen, un programa puede dividirse en términos de las estructuras de datos que loconforman, o de acuerdo a las tareas que soporta para sus usuarios (o requerimientos no funcionalesdefinidos por sus diseñadores). Generalmente no se puede lograr ambas descomposiciones al mismotiempo, lo cual genera problemas en el producto final, dependiendo del punto de vista desde el cualse analice el software.

El término programación orientada por aspectos surgió a finales de 1995 en el grupo de trabajode Gregor Kiczales en Xerox Palo Alto Research Center (PARC), un autodidacta, empresario yactualmente profesor de la Universidad de British Columbia. En esa época trabajaban en lo queellos llamaban Open Implementations, trabajo que produjo un conjunto de lenguajes de propósitoespecífico, de los cuales salió el concepto de Aspect Decomposition and Weaving (descomposiciónaspectual y tejido), el cual se redujo posteriormente a programación orientada por aspectos. Algunasideas alrededor de este concepto fueron publicadas desde esta época, generalmente incompletas, loque dió lugar a un conjunto temprano de seguidores como también a varios detractores, los cualesnotaban claramente la debilidad e incompletitud de los conceptos.

A principios de 1998 fue liberada la primera versión (0.1) de AspectJ, como una alternativa paraPOA genérica, a diferencia de los lenguajes de propósito específico que lo precedieron. Gracias alsoporte gubernamental que recibió Kiczales el lenguaje pudo seguir evolucionando desde este mo-mento, convirtiendose en la prueba y ejemplo de los conceptos promovidos por POA. Hoy contamoscon la versión 1.5 de AspectJ, estable y madura, y con una comunidad de trabajo activa alrededordel lenguaje.

Además de AspectJ, existen otras plataformas más o menos maduras para iniciarse en el tema deaspectos. Composition Filters es un trabajo previo al de Kiczales, desarrollado por el grupo TRESEen el departamento de Ciencias de Computación de la Universidad de Twente, en Holanda. Ésteha sido adaptado a los conceptos de aspectos y es soportado sobre varios lenguajes tradicionales,como Java, C++ y Smalltalk y .NET. HyperJ es un proyecto de IBM que soporta un modelo poraspectos. Otras implementaciones son JBoss-AOP, Spring AOP, AspectC++, PHPAspect, AspectSy AspectXML1.

3. Aproximaciones a los Aspectos

En esta sección se incluyen varias formas complementarias de comprender el tema de programaciónorientada a aspectos. Empezamos con un ejemplo y complementamos esta visión con una descripciónde los términos utilizados. Más adelante, comparamos el desarrollo por aspectos con el desarrollode proyectos en organizaciones matriciales y con los conceptos de programación por objetos.

3.1. Un ejemplo de programa

Un uso clásico de los conceptos en POA es la implementación de la funcionalidad de traza, lacual busca dejar un registro de las actividades desarrolladas en la ejecución de la aplicación, con

1Una lista más completa puede ser encontrada en http://www.aosd.net/wiki/index.php?title=Tools_for_Developers

2

propósitos de auditoría o de depuración. Supongamos que el programa consta de las clases de laFigura 1.

Figura 1: Clases en programa de ejemplo

El programa principal hace uso de todos los servicios en las clases. Supongamos que deseamosgenerar un registro de auditoría como el que se muestra en el siguiente listado:

Estoy en el metodo m1 de la clase ClaseAEstoy en el metodo m4 de la clase ClaseD...Estoy en el metodo m5 de la clase ClaseE

Si queremos agregar esta funcionalidad siguiendo el paradigma orientado por objetos (OO), esnecesario tener acceso al código fuente del programa y cambiar el código en los métodos involucradosde tal manera que se genere el mensaje deseado. En el mejor de los casos, se puede utilizar algunalibrería diseñada para generación de trazas, como java.util.logging o log4java. Un esquema de loscambios generados al código se pueden observar en la Figura 2, en donde las líneas punteadas llevana un código de ejemplo que debe ser agregado en cada método.

Este método de agregar traza es complejo y dificil de mantener, por diversas razones: el código detraza queda disperso por toda la aplicación, no se puede apagar dicha funcionalidad fácilmente,y es muy fácil olvidar el código adicional en nuevos métodos. Se dice que el código resultante esenmarañado, ya que cada método encapsula preocupaciones distintas: en este caso, el códigoque ya estaba ejecutando y el nuevo código para generar la traza.

Un lenguaje orientado por aspectos permite hacer este tipo de cambios de una manera muy eficiente,sin tocar el código del programa original. Adicionalmente, en lenguajes como AspectJ, se puedenaplicar los cambios aún cuando no se tenga acceso al código fuente de las clases a las que se deseaagregar traza. Utilizando las capacidades de la POA, es posible crear dos cosas: un consejo queencapsule el código que se quiere ejecutar en cada uno de los puntos donde se desee generar trazay un designador de enlace, que identifique en qué lugares se debe agregar el código del consejo.El código queda como se muestra en la Figura 3, en donde las líneas punteadas muestran en quélugares se agrega el código del consejo de una manera automática.

En este caso se puede observar las siguientes ventajas:

3

Figura 2: Cambios generados, paradigma OO

Figura 3: Cambios generados, paradigma OA

4

No hay que modificar el código ya existente, para agregar algo que no está directamenterelacionado con su funcionamiento actual.

No es necesario contar con el código fuente del programa.

Si se agregan nuevas clases o métodos al programa, sólo se debe cambiar el designador deenlace para que dichos métodos también generen traza.

Sólo debe modificarse el consejo si se desea generar traza de una manera distinta. El códigorelacionado con la traza queda concentrado en un solo lugar, lo cual cumple con la filosofiá demodularidad básica.

Se puede eliminar fácilmente la funcionalidad de traza, eliminando el aspecto.

La ejecución del programa por aspectos es idéntica a la del programa por objetos, con la diferenciaque el trabajo del desarrollador es mucho más eficiente y no se tiene que replicar código en variaspartes del programa. El ambiente de programación por aspectos se encarga del proceso de tejido,el cual agrega la funcionalidad de traza al resto del código, aliviando al programador de dicha tarea.

3.2. Conceptos fundamentales

En DOA, se supone que se puede dividir el software en preocupaciones, o asuntos que se deseanresolver y que son claramente distinguibles: el almacenamiento de datos, una tarea del usuario, eltratamiento de seguridad, por ejemplo. El objetivo principal en DOA es expresar las distintas preo-cupaciones de una manera independiente y modular, aumentando los mecanismos de modularizaciónexistentes. Otro objetivo busca que se puedan agregar nuevos aspectos no previstos al código, locual denominamos transparencia. Se denominan puntos de enlace a todos aquellos elementos enun módulo que pueden relacionarse con otro. Algunos ejemplos de puntos de enlace son la entradao salida de un método, la consulta o modificación de un atributo, la inicialización de un objeto o lageneración de una excepción, aunque el conjunto de puntos varía dependiendo del lenguaje usado.

Una lenguaje orientado a aspectos permite modularizar el código en términos de preocupaciones.Una preocupación en código se denomina un aspecto el cual define dónde se quiere agregar pedazosde código, denominados consejos, mediante designadores de enlace. Un designador de enlacepermite generalmente cuantificar puntos de enlace por extensión, nombrando cada punto de enlacedeseado, o por comprensión, describiendo una expresión que puede designar varios puntos de enlace.

Hay ambientes de POA que consideran que todas las preocupaciones se aplican a un modulo domi-nante, el cual se denomina la descomposición dominante. Hay otros que consideran este esquemauna tiranía, y consideran todas las preocupaciones al mismo nivel. Una vez se deciden los aspectosque hacen parte de una aplicación se procede a ejecutar su tejido, el cual es el proceso de com-poner el código de los distintos aspectos para poderlo ejecutar de una manera secuencial, como encualquier programa procedimental. El proceso de tejido es generalmente en tiempo de compilación,aunque hay ambientes de desarrollo que hacen operaciones de tejido en ejecución. El proceso detejido genera un código enmarañado, el cual se esconde del programador por aspectos.

5

3.3. Una interpretación organizacional

Una forma de comprender lo que agrega la POA a metodos tradicionales de programación como laprogramación orientada por objetos es observando las caracterísiticas de estructuras organizacionalesmatriciales. En dichas organizaciones, coexisten jerarquias por proyectos y por áreas de produccióno de servicio, como una manera de atender mejor a los clientes a la vez que se optimizan costos yprocedimientos. Los recursos se organizan dentro de la matriz proyectos versus áreas, y cada recursopuede ser requerido en varios proyectos como en varias áreas. Un empleado de dicha organizacióndebe preocuparse por tareas en varios aspectos, bien sea relacionados a un proyecto o relacionadosa un área del negocio.

Los aspectos en software pueden asemejarse a recursos especializados en áreas del negocio, los cualespueden desempeñarse en varias aplicaciones, o "proyectos". Estos recursos pueden utilizarse ennuevos proyectos, y su conocimiento no depende de ningún proyecto en particular. Su intervención encada proyecto está dada por su flujo de trabajo, el cual determina en qué momento es indispensablela intervención de dicho recurso. La posibilidad de tener recursos que atienden un mismo aspectoen varios proyectos ha probado ser benéfica en este tipo de aplicaciones.

3.4. Una interpretación evolutiva desde objetos

El concepto de modularidad es fundamental en la programación orientada por objetos (POO),implementado mediante el concepto de clase, como también lo son las formas de combinar dichosmódulos. La POO ofrece dos formas fundamentales de relación entre clases: delegación y herencia.En delegación, una clase contiene objetos de otras clases, a los cuales puede delegar parte o latotalidad de sus responsabilidades. En herencia, la definición de una clase B puede agregar atributoso métodos a la definición de otra clase A, siendo posible además reemplazar instancias de A porinstancias de B.

La POA crea un nuevo concepto de módulo (el aspecto) y formas de relacionar estos nuevos móduloscon clases, mediante el concepto de puntos de enlace. En lenguajes como AspectJ se cuenta con unagran variedad de puntos de enlace, que permiten agregar código antes y despues de métodos, tantoen su llamado como en su ejecución, agregar atributos y métodos a una clase o agregar código aciertos métodos dentro del flujo de ejecución. Aunque existen implementaciones de ambientes paraPOA que no son orientados por objetos, los que están implementados sobre ambientes de POOpermiten una gran variedad de formas para modularizar y componer código.

4. Comparación con otros paradigmas

Existen varias ideas en el área de desarrollo de software que dieron origen o que se relacionan conel concepto de aspectos. Acá analizamos las siguientes: programación por objetos, programacióngenerativa, metalenguajes y programación declarativa.

Como ya describimos en la sección 3.4, la POA agrega nuevas formas de modularización y compo-

6

sición. Algunas de estas nuevas oportunidades son:

Agregar código a ciertos métodos. Es posible agregar consejos a uno o más métodos a la vez,independientemente de las relaciones de herencia existentes entre las clases de dichos métodos.

Modificar una clase. Es posible agregar métodos y atributos a una clase sin crear nuevos tipos.Esto permite modularizar responsabilidades disyuntas dentro de una clase, sin tener que crearmuchos tipos en el programa (este problema es generalmente denominado explosión de clases).

Agregar código y comportamiento sin tener que prever con anterioridad dónde, lo cual hacemás comprensible el código de la descomposición dominante.

La programación generativa busca, como su nombre lo indica, generar código desde descripcionesde alto nivel, concepto relacionado con el de lenguajes de dominio específico [1]. Existen muchospuntos comunes entre programación generativa y aspectos. Es posible, por ejemplo, describir losmecanismos de un lenguaje de aspectos en un lenguaje de dominio específico (el dominio de losaspectos) y generar el código correspondiente en un lenguaje convencional (de hecho, hay variasimplementaciones de lenguajes de aspectos que funcionan de esta manera). Hay también variasdiferencias: algunos lenguajes de POA permiten hacer tejido en tiempo de ejecución, lo cual noes posible en programación generativa. Es tambien importante en un lenguaje de POA definir unconjunto claro de mecanismos de modularización y esconder los mecanismos de tejido, los cualesson visibles en un ambiente generativo. En general, la programación generativa es un mecanismode implementación para ambientes de POA (no es único), y un ambiente de POA es mucho masespecífico en sus métodos de composición y modularización que un ambiente generativo.

Existe también una relación estrecha entre el paradigma de POA y los metalenguajes. Un lenguajede programación con caracterísiticas de metalenguaje permite escribir sentencias que se refieren alcódigo escrito, o en otras palabras a las mismas estructuras de programación o sentencias utiliza-das. Existen muchos lenguajes de programación que tienen capacidades de metalenguajes, como porejemplo Smalltalk y Java, con sus capacidades de introspección. Es posible en general describir losmecanismos de aspectos mediante metalenguajes, debido a la gran versatilidad de dichos ambientes.Sin embargo, existen dos problemas con este esquema: lo enmarañado del codigo y las amplias posi-bilidades existentes en los metalenguajes. Aunque se pueden implementar los mecanismos de POAmediante un metalenguaje, en general el código resultante es complicado de escribir y compren-der, por lo que un lenguaje de POA generalmente ofrece nueva sintaxis específica a sus propósitos.Por otra parte, un metalenguaje puede hacer muchas otras cosas adicionales a las incluidas comoconceptos de POA, lo cual los hace ambientes de propósito general. POA puede verse como unaaplicación limitada de las capacidades de un metalenguaje, aunque con una sintaxis que le facilitasu utilización a un programador.

5. Referencias Adicionales

Por completar

7

6. Conclusiones

De la misma manera como Smalltalk generó un gran interés por la programación orientada por obje-tos a principios de los 70, AspectJ ha movido la comunidad internacional alrededor de los conceptosde orientación por aspectos. La programación por aspectos ofrece un conjunto de herramientas adi-cionales que permiten modularizar software mediante varios criterios, no únicamente los dominantes,lo cual permite separar mejor las distintas facetas del software. El ambiente provisto por AspectJes lo suficientemente maduro para que programadores en Java lo incluyan en sus desarrollos. Cree-mos que el uso de este tipo de herramientas pueden facilitar el desarrollo de aplicaciones, e influirpositivamente en la calidad del producto final.

7. Glosario

Aspecto (aspect). Un aspecto es la descripción en un lenguaje de programación de una preocu-pación en el software.

Código enmarañado (code tangling). El resultado en código de tener preocupaciones disper-sas.

Composición (composition). Es el proceso de unir componentes de alguna manera. Los lengua-jes como AspectJ agregan nuevos métodos para crear composiciones sobre los existentes enlenguajes orientados por objetos.

Consejo (advice). Cada uno de los “métodos” de un aspecto.

Cuantificación por extensión/comprensión (quantification). Un designador de enlace pue-de nombrar puntos de enlace bien sea por extensión o comprensión. Por extensión significaque deben nombrarse uno a uno todos los puntos de enlace. Por comprensión significa quepueden utilizarse reglas o patrones para que el sistema busque todos los puntos de enlace quecumplen con dicho patrón. Un ejemplo de regla en AspectJ es public * *.set*(..), la cualva a incluir todos los métodos públicos que comiencen con set.

Descomposición dominante (dominant decomposition). En un programa orientado por ob-jetos existe solo una descomposición. Una descomposición dominante en un lenguaje por as-pectos corresponde generalmente al conjunto de módulos a los cuales se unen los aspectos.Dichos módulos son importantes porque definen en cierta medida la estructura dominante delprograma.

Designador de enlace (point cut designator). Es la forma en la cual un aspecto se refiere alos puntos de enlace en los cuales quiere agregar funcionalidad.

Envolver antes/despues (wrapping, before/after). Un método para agregar código alrededorde un método.

Preocupación (concern). Es una característica del software. Puede corresponder a un requeri-miento funcional o no funcional, o a alguna labor interna que debe desarrollar el software paracumplir con su funcionalidad. Un ejemplo de preocupación es la persistencia de los datos enel programa, o la autenticación de usuarios.

8

Preocupaciones dispersas (crosscutting concerns). Es la característica del software tradicio-nal de tener mezclado el código que soluciona diversas preocupaciones.

Programación generativa (Generative programming). Transforma representaciones de altonivel de un programa a código de “bajo” nivel.

Puntos de enlace (join points). Son los lugares en los cuales se puede agregar funcionalidad,correspondiente a preocupaciones no planeadas previamente. Cada lenguaje de programaciónpor aspectos define un conjunto de puntos de enlace, los cuales pueden ser estáticos (parte dela sintaxis del programa) o dinámicos (parte del estado en ejecución del programa). Ejemplosde puntos de enlace estáticos son cualquier método en una clase (paint() en un Applet, porejemplo). Ejemplos de puntos de enlace dinámicos son el cambio de una variable a un valoren un rango, o la llamada de un método dentro de otro.

Tejido (weaving). Es el proceso que realiza el compilador (o ambiente de ejecución) de un lenguajepor aspectos para agregar los consejos a los puntos de enlace correspondientes.

Transparencia (obliviousness). Se refiere al hecho de no identificar dónde se agrega el códigode los aspectos. El objetivo principal es poder agregar funcionalidad en el futuro sin tenerque planearla por anticipado. Por ejemplo, un mecanismo de listeners permite agregar códigoa una clase, pero hay que planearlo por anticipado, y se nota en el código por los métodosnecesarios para agregar y eliminar listeners (por lo tanto no es transparente). Un mecanismotransparente, como los usados en AspectJ, permiten agregar funcionalidad de una maneratransparente.

Traza (log, trace) . Registro de las actividades desarrolladas en la ejecución de la aplicación, conpropósitos de auditoría o de depuración.

Referencias

[1] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming: Methods, Tools, andApplications. Addison–Wesley, 2000.

[2] Pablo Figueroa. Teaching aspects to undergraduates. In AOSD 2006 Workshop. Aspects inTeaching, 2006.

[3] AspectJ Group. The aspectj project at eclipse.org. http://www.eclipse.org/aspectj/, 2006.

[4] Gregor Kiczales, Jim des Rivières, and Daniel G. Bobrow. The Art of the Metaobject Protocol.MIT Press, 1991.

[5] D. L. Parnas. On the criteria to be used in decomposing systems into modules. Commun. ACM,15(12):1053–1058, 1972.

[6] Leon Sterling and Ehud Shapiro. The Art of Prolog. MIT Press, 1994.

9