PROGRAMACIN ORIENTADA A ASPECTOS

Eric RUIZ CAMPOS Eduardo RODRIGUEZ MAYSUNDO Heider Ysaias SANCHEZ ENRIQUEZ
Universidad Nacional de Trujillo Escuela Acadmico Profesional de Informtica www.inf.unitru.edu.pe Av. Juan Pablo II-Trujillo-Per

Resumen: La Programacin tradicional carece actualmente de mecanismos adecuados para abstraer, y encapsular conceptos que no forman parte de la funcionalidad bsica de los sistemas, tales como debugging, sincronizacin, distribucin, seguridad, administracin de memoria, y otros. El resultado de esta insuficiente abstraccin es una notable disminucin de la calidad del software final. Una de las alternativas ms prometedoras para resolver este problema es la Programacin Orientada a Aspectos (POA). En este trabajo damos una visin informativa acerca de este nuevo Paradigma en la programacin, su historia, ventajas y desventajas, analizaremos una aplicacin basada en la POA y los lenguajes que desarrollan aplicaciones con la POA. Palabras claves: Programacin, Aspecto, Programacin Orientada a Aspectos, sincronizacin, distribucin, manejo de errores, optimizacin de memoria, gestin de seguridad, persistencia.

1. Introduccin: 2. Historia:
La primera pregunta que surge en la humanidad es: De dnde venimos?; pues esta pregunta la resolveremos para nuestro caso, De dnde viene la POA?, a continuacin definimos un poco de historia: Muchos observan la programacin orientada a aspectos como el siguiente paso en la evolucin de la Programacin e intentan hacer ver como sta supondr, como lo hizo en su momento la POO, un cambio importante en el diseo de aplicaciones. No obstante, recordemos que fue sobre 1960 cuando apareci la primera implementacin usable de los conceptos de orientacin a objetos con el lenguaje Simula-68, mientras que no fue hasta 1980, veinte aos despus, cuando de vers se empezaron a usar de manera comercial en proyectos reales, dichas tcnicas, es decir, con mucho dinero por medio. Fue entonces el boom de las telecomunicaciones y el crecimiento de C++ frente a C y COBOL. El concepto de POA fue introducido por Gregor Kiczales y su grupo, aunque el equipo Demeter [1] haba estado utilizando ideas orientadas a aspectos antes incluso de que se acuara el trmino. El trabajo del grupo Remeter estaba centrado en la programacin adaptiva, que puede verse como una instancia temprana de la POA. Dicha metodologa de programacin se introdujo alrededor de 1991. Consiste en dividir los programas en varios bloques de cortes. Inicialmente, se separaban la representacin de los objetos del sistema de cortes; luego se aadieron comportamientos de estructuras y estructuras de clases como bloques constructores de cortes. Cristina Lopes propuso la sincronizacin y la invocacin remota como nuevos

bloques [2]. No fue hasta 1995 cuando se public la primera definicin temprana del concepto de aspecto, realizada tambin por el grupo Demeter y que sera la siguiente: Un aspecto es una unidad que se define en trminos de informacin parcial de otras unidades. Por suerte las definiciones cambian con el tiempo y se hacen ms comprensibles y precisas. Actualmente es ms apropiado hablar de la siguiente definicin de Gregor Kiczales: Un aspecto es una unidad modular que se dispersa por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseo como en la de implementacin. Un aspecto de diseo es una unidad modular del diseo que se entremezcla en la estructura de otras partes del diseo. Un aspecto de programa o de cdigo es una unidad modular del programa que aparece en otras unidades modulares del programa.

3. Qu es POA?:
3.1 Qu es un Aspecto?: 3.2 Qu es la Programacin Orientada a Aspectos?:

4. Fundamentos de la POA:
Con todo lo visto en las secciones anteriores, se puede decir que con las clases se implementa la funcionalidad principal de una aplicacin (como por ejemplo, la gestin de un almacn), mientras que con los aspectos se capturan conceptos tcnicos tales como la persistencia, la gestin de errores, la sincronizacin o la comunicacin de procesos. Estos aspectos se escriben utilizando lenguajes de descripcin de aspectos especiales [4]. Los lenguajes orientados a aspectos definen una nueva unidad de programacin de software para encapsular las funcionalidades que cruzan todo el cdigo. Adems, estos lenguajes deben soportar la separacin de aspectos como la sincronizacin, la distribucin, el manejo de errores, la optimizacin de memoria, la gestin de seguridad, la persistencia. De todas formas, estos conceptos no son totalmente independientes, y est claro que hay una relacin entre los componentes y los aspectos, y que por lo tanto, el cdigo de los componentes y de estas nuevas unidades de programacin tienen que interactuar de alguna manera. Para que ambos (aspectos y componentes) se puedan mezclar, deben tener algunos puntos comunes, que son los que se conocen como puntos de enlace, y debe haber algn modo de mezclarlos. Los puntos de enlace son una clase especial de interfaz entre los aspectos y los mdulos del lenguaje de componentes. Son los lugares del cdigo en los que ste se puede aumentar con comportamientos adicionales. Estos comportamientos se especifican en los aspectos. El encargado de realizar este proceso de mezcla se conoce como tejedor (del trmino ingls weaver). El tejedor se encarga de mezclar los diferentes mecanismos de abstraccin y composicin que aparecen en los lenguajes de aspectos y componentes ayudndose de los puntos de enlace. Para tener un programa orientado a aspectos necesitamos definir los siguientes elementos: Un lenguaje para definir la funcionalidad bsica. Este lenguaje se conoce como lenguaje base. Suele ser un lenguaje de propsito general, tal como C++ o Java. En general, se podran utilizar tambin lenguajes no imperativos. Uno o varios lenguajes de aspectos. El lenguaje de aspectos define la forma de los aspectos por ejemplo, los aspectos de AspectJ se programan de forma muy parecida a las clases. Un tejedor de aspectos. El tejedor se encargar de combinar los lenguajes. El proceso de mezcla se puede retrasar para hacerse en tiempo de ejecucin, o hacerse en tiempo de compilacin.

En la Figura 5 se aprecia la forma en la que se trabaja con las aplicaciones tradicionales, y cmo ser esta forma de operar en una aplicacin orientada a aspectos en la Figura 6.

Figura 5. Estructura de una implementacin en los lenguajes

tradicionales.
En las aplicaciones tradicionales, bastaba con un compilador o intrprete que tradujera nuestro programa escrito en un lenguaje de alto nivel a un cdigo directamente entendible por la mquina. En las aplicaciones orientadas a aspectos, sin embargo, adems del compilador, hemos de tener el tejedor, que nos combine el cdigo que implementa la funcionalidad bsica, con los distintos mdulos que implementan los aspectos, pudiendo estar cada aspecto codificado con un lenguaje distinto. Para el lenguaje de aspectos AspectJ, por ejemplo, hay un compilador llamado ajc, que tiene una opcin de preprocesado que permite generar cdigo java, para ser utilizado directamente por un compilador Java compatible con JDK, y tambin tiene una opcin para generar archivos .class, encargndose l de llamar al compilador Java.

Figura 6. Estructura de una implementacin en los lenguajes de aspectos.

5. Tejiendo clases y aspectos:

Los aspectos describen apndices al comportamiento de los objetos. Hacen referencia a las clases de los objetos y definen en qu punto se han de colocar estos apndices. Puntos de enlace que pueden ser tanto mtodos como asignaciones de variables. Las clases y los aspectos se pueden entrelazar de dos formas distintas: de manera esttica o bien de manera dinmica.

Entrelazado esttico: El entrelazado esttico implica modificar el cdigo fuente de una clase insertando sentencias en estos puntos de enlace. Es decir, que el cdigo del aspecto se introduce en el de la clase. Un ejemplo de este tipo de tejedor es el Tejedor de Aspectos de AspectJ [5]. La principal ventaja de esta forma de entrelazado es que se evita que el nivel de abstraccin que se introduce con la programacin orientada a aspectos se derive en un impacto negativo en el rendimiento de la aplicacin. Pero, por el contrario, es bastante difcil identificar los aspectos en el cdigo una vez que ste ya se ha tejido, lo cual implica que si se desea adaptar o reemplazar los aspectos de forma dinmica en tiempo de ejecucin nos encontremos con un problema de eficiencia, e incluso imposible de resolver a veces. Entrelazado dinmico: Una precondicin o requisito para que se pueda realizar un entrelazado dinmico es que los aspectos existan de forma explcita tanto en tiempo de compilacin como en tiempo de ejecucin [6]. Para conseguir esto, tanto los aspectos como las estructuras entrelazadas se deben modelar como objetos y deben mantenerse en el ejecutable. Dado un interfaz de reflexin, el tejedor es capaz de aadir, adaptar y borrar aspectos de forma dinmica, si as se desea, durante la ejecucin. Un ejemplo de este tipo de tejedores es el Tejedor AOP/ST [7], que no modifica el cdigo fuente de las clases mientras se entrelazan los aspectos. En su lugar utiliza la herencia para aadir el cdigo especfico del aspecto a sus clases. El principal inconveniente subyacente bajo este enfoque es el rendimiento y que se utiliza ms memoria con la generacin de todas estas subclases. Una de las primeras clasificaciones de las formas de combinar el comportamiento de los componentes y los aspectos fue dada por John Lamping [8]: 1. Yuxtaposicin. Consiste en la intercalacin del cdigo de los aspectos en el de los componentes. La estructura del cdigo mezclado quedara como el cdigo base con el cdigo de los aspectos aadidos en los puntos de enlace. En este caso, el tejedor sera bastante simple. 2. Mezcla. Es lo opuesto a la yuxtaposicin, todo el cdigo queda mezclado con una combinacin de descripciones de componentes y aspectos. 3. Fusin. En este caso, los puntos de enlace no se tratan de manera independiente, se fusionan varios niveles de componentes y de descripciones de aspectos en una accin simple.

6. Aplicacines de la POA:
6.1 Lenguajes orientados a la POA: Para desarrollar aplicaciones basados en la POA, necesitamos ciertos lenguajes especial es denominados Lenguajes de Aspectos. Hasta nuestro tiempo se han distinguido dos enfoques diferentes en el diseo de los lenguajes de aspectos: los lenguajes de aspectos de dominio especfico y los lenguajes de aspectos de propsito general. a. Lenguajes de aspectos de dominio especfico: Estos lenguajes soportan uno o ms de estos sistemas de aspectos que se han ido mencionando en las secciones anteriores (distribucin, coordinacin, manejo de errores, ...), pero no pueden soportar otros aspectos distintos de aquellos para los que fueron diseados. Los lenguajes de aspectos de dominio especfico normalmente tienen un nivel de abstraccin mayor que el lenguaje base y, por tanto, expresan los conceptos del dominio especfico del aspecto en un nivel de representacin ms alto.

Estos lenguajes normalmente imponen restricciones en la utilizacin del lenguaje base. Esto se hace para garantizar que los conceptos del dominio del aspecto se programen utilizando el lenguaje diseado para este fin y evitar as interferencias entre ambos. Se quiere evitar que los aspectos se programen en ambos lenguajes lo cual podra conducir a un conflicto. Como ejemplos de lenguajes de dominio especfico estn COOL [9], que trata el aspecto de sincronizacin, y RIDL [9], para el aspecto de distribucin. Qu es COOL?: COOL Es un lenguaje de dominio especfico creado por Xerox [2] cuya finalidad es la sincronizacin de hilos concurrentes. El lenguaje base que utiliza es una versin restringida de Java, ya que se han de eliminar los mtodos wait, notify y notifyAll, y la palabra clave synchronized para evitar que se produzcan situaciones de duplicidad al intentar sincronizar los hilos en el aspecto y en la clase. En COOL, la sincronizacin de los hilos se especifica de forma declarativa y, por lo tanto, ms abstracta que la correspondiente codificacin en Java. Un programa COOL est formado por un conjunto de mdulos coordinadores. En cada coordinador se define una estrategia de sincronizacin, en la cual pueden intervenir varias clases. Aunque estn asociados con las clases, los coordinadores no son clases. b. lenguajes de aspectos de propsito general: Estos lenguajes se disearon para ser utilizados con cualquier clase de aspecto, no solamente con aspectos especficos. Por lo tanto, no pueden imponer restricciones en el lenguaje base. Principalmente soportan la definicin separada de los aspectos proporcionando unidades de aspectos. Normalmente tienen el mismo nivel de abstraccin que el lenguaje base y tambin el mismo conjunto de instrucciones, ya que debera ser posible expresar cualquier cdigo en las unidades de aspectos. Un ejemplo de este tipo de lenguajes es AspectJ, que utiliza Java como base, y las instrucciones de los aspectos tambin se escriben en Java. Qu es AspectJ?: AspectJ es una extensin a JavaTM orientada a aspectos y de propsito general [10]. AspectJ extiende Java con una nueva clase de mdulos llamado aspecto. Los aspectos cortan las clases, las interfaces y a otros aspectos. Los aspectos mejoran la separacin de competencias haciendo posible localizar de forma limpia los conceptos de diseo del corte. En AspectJ, un aspecto es una clase, exactamente igual que las clases Java, pero con una particularidad, que pueden contener unos constructores de corte, que no existen en Java. Los cortes de AspectJ capturan colecciones de eventos en la ejecucin de un programa. Estos eventos pueden ser invocaciones de mtodos, invocaciones de constructores, y excepciones de seales y gestin. Los cortes no definen acciones, sino que describen eventos. Si contrastamos estos dos enfoques, propsito general versus propsito especfico, se tiene que los lenguajes de aspectos de propsito general no pueden cubrir completamente las necesidades. Tienen un severo inconveniente: Permiten la separacin del cdigo, pero no garantizan la separacin de funcionalidades, es decir, que la unidad de aspecto solamente se utiliza para programar el aspecto. Sin embargo, esta es la idea central de la programacin orientada a aspectos. En comparacin con los lenguajes de aspectos de propsito general, los lenguajes de aspectos de dominio especfico fuerzan la separacin de funcionalidades. Si hacemos esta comparacin desde el punto de vista empresarial, siempre les ser ms fcil a los programadores el aprender un lenguaje de propsito general, que el tener que estudiar varios lenguajes distintos de propsito especfico, uno para tratar cada uno de los aspectos del sistema.

6.2 Una aplicacin (Una Cola Circular): Despus de conocer una pautas de los dos enfoques diferentes existentes a la hora de disear los lenguajes de aspectos, se ver con un ejemplo prctico de cmo se reflejan estas caractersticas en el cdigo de las aplicaciones. En primer lugar, se implementar la cola circular en Java sin el aspecto de sincronizacin. Luego, se le aadirn las lneas de cdigo necesarias para gestionar este aspecto, y se podr apreciar claramente cmo estas se diseminan por todo el programa, quedando un cdigo poco claro. Despus el mismo ejemplo se implementar con COOL, y por ltimo con Aspect J. En la Figura 11, se muestra el cdigo Java de una lista circular, en principio, sin restricciones de sincronizacin. La clase ColaCircular se representa con un array de elementos. Los elementos se van aadiendo en la posicin ptrCola (por atrs), y se van borrando en la posicin apuntada por ptrCabeza (la parte de delante). Estos dos ndices se ponen a cero al alcanzar la capacidad mxima del array. Esta inicializacin se consigue utilizando el resto obtenido al dividir la posicin a tratar entre el nmero total de elementos del array. Esta clase solamente contiene un constructor y dos mtodos: Insertar para introducir elementos en la cola, y Extraer, para sacarlos. El problema del cdigo de la Figura 11 es que si varios hilos solicitan ejecutar mtodos del objeto ColaCircular, stos no estn sincronizados, pudindose dar el caso de que la cola haya cubierto su capacidad, y se sigan haciendo peticiones de insercin de elementos, y al contrario, es decir, que la cola est vaca y se hagan peticiones de extraccin de elementos. En estos casos, el hilo que hace la solicitud debera esperar a que se extraiga algn elemento, en el primer caso, o a que se inserte alguno en el segundo. Es decir, que se necesita cdigo adicional para eliminar estas inconsistencias. Java permite coordinar las acciones de hilos de ejecucin utilizando mtodos einstrucciones sincronizadas.

Figura 11 Cdigo de la clase cola circular sin restricciones de sincronizacin.

Una cola circular usando COOL La versin sincronizada del ejemplo de la Figura 11 se muestra en la Figura 12 . Aqu se ha introducido la exclusin mutua y condiciones con guardas. El cdigo que se introduce para la sincronizacin es el sombreado.

Figura 12. Objeto cola circular con restricciones de sincronizacin.

Como se puede observar los mtodos Insertar y Extraer se han regado con el cdigo correspondiente a la sincronizacin de los hilos. Adems el cdigo aadido se esparce por todo el mtodo, no est localizado en una sola parte del cdigo. Si el mismo ejemplo de la cola circular con sincronizacin se implementa en COOL (Figura 13 y Figura 14) se tiene que lo nico que hay que aadirle es el mdulo coordinador. La clase ColaCircular se escribe en el lenguaje base (Java), y lo nico que habra que hacer para poner en funcionamiento la sincronizacin sera entrelazar los dos mdulos juntos (el coordinador y la clase).

Figura 13. Clase ColaCircular definida en el lenguaje base de COOL.

Figura 14. Implementacin de la cola circular utilizando un coordinador COOL.

Si se compara el cdigo sombreado de la Figura 12 con el coordinador que se ha aadido en COOL (tambin sombreado en la Figura 14), se puede ver claramente, que en el caso Java, el tratamiento de la sincronizacin queda distribuido por todo el cdigo de la clase, mientras que con COOL, el aspecto de sincronizacin est perfectamente localizado. Una cola circular usando Aspecto En la Figura 15 se presenta un aspecto para tratar la sincronizacin de la clase ColaCircular. En la Figura 16 se representa la clase a la que est asociado este aspecto. Ntese que esta versin difiere un poco de la de COOL, ya que el atributo eltosRellenos se ha pasado al aspecto, ya que es una informacin que solamente interesa para sincronizar. La ColaCircular solamente ha de conocer por dnde se inserta y por dnde se extrae.

Figura 15 Aspecto para definir estrategia de sincronizacin mediante AspectJ.

Figura 16. Clase ColaCircular para un aspecto en AspectJ

7. Ventajas y Desventajas:
7.1 Ventajas: Entre los objetivos que se ha propuesto la programacin orientada a aspectos estn principalmente el de separar conceptos y el de minimizar las dependencias entre ellos. Con el primer objetivo se consigue que cada cosa est en su sitio, es decir, que cada decisin se tome en un lugar concreto, con el segundo se tiene una prdida del acoplamiento entre los distintos elementos. De la consecucin de estos objetivos se pueden obtener las siguientes ventajas: Un cdigo menos enmaraado, ms natural y ms reducido. Una mayor facilidad para razonar sobre las materias, ya que estn separadas y tienen una dependencia mnima. Ms facilidad para depurar y hacer modificaciones en el cdigo. Se consigue que un conjunto grande de modificaciones en la definicin de una materia tenga un impacto mnimo en las otras. Permite la separacin de conceptos y agregar nuevos aspectos, modificar y / o remover aspectos existentes fcilmente. Se tiene un cdigo ms reusable y que se puede acoplar y desacoplar cuando sea necesario. Durante el diseo, el desarrollador se ve beneficiado ya que puede retrasar las decisiones sobre requerimientos actuales o futuros, debido a que permite, luego, implementarlos separadamente e incluirlos automticamente en el sistema, esto resuelve el dilema del arquitecto sobre cuantos recursos invertir en la etapa de diseo, cundo la cuestin planteada es demasiado diseo. 7.2 Desventajas: Las desventajas del paradigma surgen del hecho de que la POA est en su infancia, En el anlisis de Guezzi et.al.[3] sobre la POA se mencionan tres falencias: La primera remarca posibles choques entre el cdigo funcional, expresado en el lenguaje base, y el cdigo de aspectos expresado en los lenguajes de aspectos. Usualmente, estos choques nacen de la necesidad de violar el encapsulamiento para implementar los diferentes aspectos, sabiendo de antemano el riesgo potencial que se corre al utilizar estas prcticas. La segunda es la posibilidad de choques entre los aspectos. El ejemplo clsico es tener dos aspectos que trabajan perfectamente por separado, pero al aplicarlos conjuntamente resultan en un comportamiento anormal. La tercera, trata con posibles choques entre el cdigo de aspectos y los mecanismos del lenguaje. Uno de los ejemplos ms conocidos de este problema es la anomala de herencia. Dentro del contexto de la POA, el trmino puede ser usado para indicar la dificultad de heredar el cdigo de un aspecto en la presencia de herencia.

8. Conclusiones:
La separacin de conceptos es una herramienta de ingeniera del software que reduce la complejidad de las aplicaciones a niveles manejables para las personas y permite a los desarrolladores centrarse en problemas concretos, ignorando otros que en determinado momento no sean tan importantes.

10

Hasta antes de la POA, los paradigmas de programacin se han basado en una nica y dominante manera de descomposicin del software (clases, funciones, reglas...) La POA persigue la eliminacin de lo que se conoce como tirana de descomposicin del software. Actualmente existen diferentes implementaciones que, con ms o menos xito, persiguen este objetivo. La que actualmente goza de mayor difusin es AspectJ [10], una extensin orientada a aspectos de Java, en la que se distinguen entre clases, que encapsulan los requisitos funcionales del sistema, y aspectos, que encapsulan los requisitos de corte no funcionales. Los lenguajes de aspectos de dominio especfico juegan un papel crucial en la programacin orientada a aspectos y que son preferibles a los lenguajes de aspectos de propsito general, porque soportan mejor la separacin de funcionalidades. Pero an no tenemos experiencia suficiente con los lenguajes de aspectos. El campo de la orientacin a aspectos es un campo de investigacin muy joven, en el que se abre un horizonte bastante amplio. Desde la definicin de los distintos aspectos mediante lenguajes de propsito especfico, hasta middlewares orientados a aspectos, pasando por las etapas de anlisis y diseo orientadas a aspectos, an quedan muchos campos que abonar, por lo que se cree interesante el abrir nuevas lneas de investigacin en esta parcela.

9. Referencias:
[1]. KARL J. LIEBERHERR. Adaptive Object-Oriented Software. The Demeter Method. Northeastern University Boston. [2]. CRISTINA LOPES, A Language Framework for Distributed Programming, Ph.D.thesis, Northeastern University, noviembre 1997. [3]. GIANPAOLO CUGOLA, CARLO GHEZZI, MATTIA MONGA. Language Support for Evolvable Software: An Initial Assessment of Aspect-Oriented Programming. Proceedings of the International Workshop on the Principles of Software Evolution, IWPSE99, Julio 1999. [4]. G. KICZALES, J. LAMPING, A. MENDHEKAR, C. MAEDA, C. LOPES, J. LOINGTIER AND J. IRWIN. Aspect-Oriented Programming, Xerox Palo Alto Research Center, 1997 [5]. AspectJ Home Page: http://www.parc.xerox.com/aop/aspectj/ [6]. F. MATTHIJS, W. JOOSEN, B. VANHAUTE, B. ROBBEN, P. VERBAETEN. Aspects should not die. In European Conference on Object-Oriented Programming, Workshop on AspectOriented Programming. 1997. [7]. AOP/ST Home Page: http://www.germany.net/teilnehmer/101,199268/ [8]. J. LAMPING. The Interaction of Components and Aspects. Position paper at the ECOOP97 workshop on Aspect Oriented Programming, 1997. [9]. J. JAWORSKI. JavaTM. Gua de Desarrollo. Prentice Hall, 1996. [10]. Xerox Parc Corporation. AspectJTM : Users Guide. http://www.aspectj.org.

11