PROGRAMACIN ORIENTADA A ASPECTOS

INTRODUCCION

La mayora de los sistemas software tienen propiedades que no necesariamente se linean

con los componentes funcionales de un sistema. Manejo de fallas, persistencia,
comunicacin, replicacin, coordinacin, registro de actividades, login, traza, entre
otros, son aspectos del comportamiento de un sistema que tienden a cortar
transversalmente a grupos de componentes funcionales. Aunque sea posible analizar
estos aspectos por separado de la funcionalidad bsica de una aplicacin, su
implementacin, usando los actuales lenguajes orientados a componentes, tiene como
resultado que el cdigo de estos aspectos se repite y esparce en muchos componentes
funcionales. En consecuencia, el cdigo fuente se convierte en una maraa o enredo
de instrucciones de diferentes propsitos. [1]

La POA es un nuevo paradigma de programacin que aspira a soportar la separacin de

los aspectos antes mencionados. Es decir, la POA intenta separar los componentes
(clases, mtodos y/o objetos de funcionalidad bsica) y los aspectos unos de otros,
proporcionando mecanismos que posibiliten abstraerlos y componerlos para formar todo
el sistema. [1]

Una herramienta POA consiste de tres componentes principales: un lenguaje de

programacin base, un lenguaje de programacin orientado a aspectos (LOA) y un
tejedor de aspectos (weaver). [1]

Disear un sistema basado en aspectos requiere entender qu se debe incluir en el

lenguaje base, qu se debe incluir dentro de los lenguajes de aspectos y qu debe
compartirse entre ambos lenguajes. El lenguaje componente debe proveer la forma de
implementar la funcionalidad bsica y asegurar que los programas escritos en ese
lenguaje componente no interfieran con los aspectos. Los lenguajes de aspectos tienen

que proveer los medios para implementar los aspectos deseados de una manera intuitiva,
natural y concisa.
ANTECEDENTES
Los conceptos y tecnologas reunidos bajo el nombre "programacin orientada a
aspectos" (AOP, por las siglas de Aspect-Oriented Programming) buscan resolver un
problema identificado hace tiempo en el desarrollo de software. Se trata del problema de
la separacin de incumbencias (separation of concerns). AOP no es el nico intento por
solucionar este problema, hay varias propuestas, muchas de las cuales se agrupan (junto
con AOP) en el campo de estudio denominado ASoC (Advanced Separation of
Concerns) [1].
El principio de separacin de incumbencias fue identificado en la dcada de 1970,
plantea que un problema dado involucra varias incumbencias que deben ser identificadas
y separadas. Las incumbencias son los diferentes temas o asuntos de los que es necesario
ocuparse para resolver el problema. Una de ellas es la funcin especfica que debe
realizar una aplicacin, pero tambin surgen otras como por ejemplo distribucin,
persistencia, replicacin, sincronizacin, etc. Separando las incumbencias, se disminuye
la complejidad a la hora de tratarlas y se puede cumplir con requerimientos relacionados
con la calidad como adaptabilidad, mantenibilidad, extensibilidad y reusabilidad [1].
El principio puede aplicarse de distintas maneras. Por ejemplo, separar las fases del
proceso de desarrollo puede verse como una separacin de actividades de ingeniera en
el tiempo y por su objetivo. Definir subsistemas, objetos y componentes son otras
formas de poner en prctica el principio de separacin de incumbencias. Por eso
podemos decir que se trata de un principio rector omnipresente en el proceso de
desarrollo de software [1].
Las tcnicas de modelado que se usan en la etapa de diseo de un sistema se basan en
partirlo en varios subsistemas que resuelvan parte del problema o correspondan a una
parte del dominio sobre el que trata. Estas tcnicas sufren en su mayora la llamada

"tirana de la descomposicin dominante" que consiste en guiarse al modelar, implcita o

explcitamente, por una visin jerrquica determinada de la organizacin del sistema. La
desventaja de estas particiones es que muchas de las incumbencias a tener en cuenta para
cumplir con los requerimientos (en particular, habitualmente, las incumbencias no
funcionales) no suelen adaptarse bien a esa descomposicin [1].
Las construcciones provistas por los lenguajes de programacin, que fueron creados para
implementar los modelos generados por las tcnicas de diseo existentes, reproducen las
jerarquas y, por lo tanto, comparten el defecto explicado en el prrafo anterior. En el
paradigma de programacin imperativa, la descomposicin consiste en identificar
procedimientos que resuelvan parte del problema, y la jerarqua se da en el rbol de
ejecucin, segn el cual los procedimientos se invocan unos a otros. En el caso de la
programacin orientada a objetos, la jerarqua generada en la etapa de diseo suele
plasmarse en las relaciones de herencia o de composicin entre objetos. Por ejemplo,
algunos patrones de diseo de uso habitual como observador, visitante y mediador
exhiben estos problemas, ya que para aplicarlos es necesario adaptar a ellos ms de una
clase [1].
El problema aparece cuando una incumbencia afecta a distintas partes del sistema que no
aparecen relacionadas en la jerarqua. En ese caso, la nica solucin suele ser escribir
cdigo repetido que resuelva esa incumbencia para cada subsistema [1].
El trmino programacin orientada por aspectos surgi a finales de 1995 en el grupo de
trabajo de Gregor Kiczales en Xerox Palo Alto Research Center (PARC), un
autodidacta, empresario y actualmente profesor de la Universidad de British Columbia.
En esa poca trabajaban en lo que ellos llamaban Open Implementations, trabajo que
produjo un conjunto de lenguajes de propsito especfico, de los cuales sali el concepto
de Aspect Decomposition and Weaving (descomposicin aspectual y tejido), el cual se
redujo posteriormente a programacin orientada por aspectos. Algunas ideas alrededor
de este concepto fueron publicadas desde esta poca, generalmente incompletas, lo que

dio lugar a un conjunto temprano de seguidores como tambin a varios detractores, los
cuales notaban claramente la debilidad e incompletitud de los conceptos [1].
A principios de 1998 fue liberada la primera versin (0.1) de AspectJ, como una
alternativa para POA genrica, a diferencia de los lenguajes de propsito especfico que
lo precedieron. Gracias al soporte gubernamental que recibi Kiczales el lenguaje pudo
seguir evolucionando desde este momento, convirtindose en la prueba y ejemplo de los
conceptos promovidos por POA. Hoy contamos con la versin 1.5 de AspectJ, estable y
madura, y con una comunidad de trabajo activa alrededor del lenguaje [1].
Adems de AspectJ, existen otras plataformas ms o menos maduras para iniciarse en el
tema de aspectos. Composition Filters es un trabajo previo al de Kiczales, desarrollado
por el grupo TRESE en el departamento de Ciencias de Computacin de la Universidad
de Twente, en Holanda. ste ha 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 por aspectos. Otras
implementaciones son JBoss-AOP, Spring AOP, Aspecto++, PHPAspect, AspectS y
AspectXML1 [1].
La POA es un paradigma que recin est naciendo. Se estn realizando las primeras
experiencias prcticas para mostrar su aplicabilidad, y obtener datos empricos que
estimulen la investigacin en el tema. La POA est en su primera etapa, donde
constantemente surgen nuevos problemas, nuevas herramientas, nuevos contextos en los
cuales es posible aplicar aspectos. Este panorama hace pensar que la programacin
orientada a aspectos se encuentra en mismo lugar que se encontraba la POO hace veinte
aos [1].

DESARROLLO
Historia

El concepto de programacin orientada a aspectos fue introducido por Gregor Kiczales y

su grupo, aunque el equipo Demeter haba estado utilizando ideas orientadas a aspectos
antes incluso de que se acuara el trmino [2].

El trabajo del grupo Remeter estaba centrado en la programacin adaptativa, que no es

ms que una instancia temprana de la programacin orientada a aspectos. La
programacin adaptativa se introdujo alrededor de 1991. Aqu los programas se dividan
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, a la que se hace referencia en el
apartado siguiente [2].

Gracias a la colaboracin de Cristina Lopes y Karl J. Lieberherr con Gregor Kiczales y

su grupo se introdujo el trmino de programacin orientada a aspectos. 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 [2].

Programacin orientada a aspecto (POA)

La (POA) es una nueva metodologa de programacin que aspira a soportar la

separacin de competencias. Es decir, que intenta separar los componentes y los
aspectos unos de otros, proporcionando mecanismos que hagan posible abstraerlos y
componerlos para formar todo el sistema. En definitiva, lo que se persigue es
implementar una aplicacin de forma eficiente y fcil de entender [2].
POA es un desarrollo que sigue al paradigma de la orientacin a objetos, y como tal,
soporta la descomposicin orientada a objetos, adems de la procedimental y la
descomposicin funcional [2].

Aspecto

Un aspecto es una unidad modular que se disemina 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 [2].

De manera ms informal podemos decir que los aspectos son la unidad bsica de la
POA, y pueden definirse como las partes de una aplicacin que describen las cuestiones
claves relacionadas con la semntica esencial o el rendimiento. Tambin pueden verse
como los elementos que se diseminan por todo el cdigo y que son difciles de describir
localmente con respecto a otros componentes [2].

Desarrollo orientado a Aspectos

El desarrollo de una aplicacin basada en aspectos consiste de tres pasos:

Descomposicin de aspectos: es descomponer los requerimientos para distinguir
aquellos que son componentes de los que son aspectos [3].

Implementacin de requerimientos: implementar cada requerimiento por separado [3].

Recomposicin: dar las reglas de recomposicin que permitan combinar el sistema

completo [3].
Composicin de un Aspecto

Un Aspecto se compone de su declaracin, la definicin de sus puntos de corte

(Pointcut) y de sus puntos de ejecucin (Advice) [4].

Declaracin del Aspecto (Aspect): permite indicar las caractersticas del aspecto. Si
permite acceder a campos privados, si extiende una clase o otro aspecto abstracto, si
implementa un interfase o si es aplicable slo para unos determinados puntos de corte
(Pointcut)[4].

Puntos de corte(Pointcut definitions): permite capturar o identificar puntos de unin en

el flujo de un programa[4].

Declaracin de puntos de ejecucin (Advice): permite definir las acciones a tomar en el

flujo del programa [4].

Concern (Incumbencia): Se define como una propiedad o punto de inters de un sistema.

La IEEE define los concerns para un sistema como aquellos intereses que pertenecen al
desarrollo del sistema y su operacin, o dems aspectos que son crticos; o importantes
para uno o varios stakeholders. Los concerns incluyen consideraciones asociadas a

requisitos No funcionales o propiedades de calidad tales como: performance,

confiabilidad, seguridad, distribucin entre otros.
Crosscutting Concerns (Incumbencias Transversales): son aquellas propiedades que se
reparten a lo largo de todo el cdigo de una aplicacin, son conceptos que no pueden
encapsularse dentro de una unidad funcional, debido a que atraviesan todo el sistema.

Puntos de Unin(Join Point): es una posicin bien definida dentro del cdigo principal.
Un Join Point puede ser la llamada a un mtodo, la ejecucin de un constructor o la
asignacin de un miembro de un objeto [4].

Fundamentos POA

Los tres principales requerimientos de la POA son:

Un lenguaje para definir la funcionalidad bsica, conocido como lenguaje base o

componente. Podra ser un lenguaje imperativo, o un lenguaje no imperativo (C++, Java,
Lisp, ML) [5].

Uno o varios lenguajes de aspectos, para especificar el comportamiento de los aspectos.

(COOL, para sincronizacin, RIDL, para distribucin, AspectJ, de propsito general)
[5].

Un tejedor de aspectos (Weaver), que se encargar de combinar los lenguajes. Tal

proceso se puede retrasar para hacerse en tiempo de ejecucin o en tiempo de
compilacin [5].

Los lenguajes orientados a aspectos definen una nueva unidad de programacin de

software para encapsular aquellos conceptos que cruzan todo el cdigo [5].

A la hora de tejer los componentes y los aspectos para formar el sistema final, es claro
que se necesita una interaccin entre el cdigo de los componentes y el cdigo de los
aspectos. Tambin es claro que esta interaccin no es la misma interaccin que ocurre
entre los mdulos del lenguaje base, donde la comunicacin est basada en
declaraciones de tipo y llamadas a procedimientos y funciones. La POA define entonces
una nueva forma de interaccin, provista a travs de los puntos de enlace (join points)
[5].
Los puntos de enlace brindan la interfaz entre aspectos y componentes; son lugares
dentro del cdigo donde es posible agregar el comportamiento adicional que destaca a la
POA. Dicho comportamiento adicional es especificado en los aspectos [5].

An nos falta introducir el encargado principal en el proceso de la POA. Este encargado

principal conocido como tejedor debe realizar la parte final y ms importante: tejer los
diferentes mecanismos de abstraccin y composicin que aparecen tanto en los lenguajes
de aspectos como en los lenguajes de componentes, guiado por los puntos de enlace [5].

Tejiendo clases y aspectos

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.
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

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.

Lenguajes de Aspectos de Propsito General vs. Dominio Especfico

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.
Los lenguajes de aspectos de propsito general 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.

Lenguajes orientados a aspectos

A continuacin describiremos informalmente algunos lenguajes orientados a aspectos
disponibles actualmente.
ASPECTC

AspectC es un simple lenguaje de aspectos de propsito general que extiende C, es un

subconjunto de AspectJ sin ningn soporte para la programacin orientada a objetos o
mdulos explcitos.

ASPECTC++

AspectC++ es un lenguaje de aspectos de propsito general que extiende el lenguaje

C++ para soportar el manejo de aspectos. En este lenguaje los puntos de enlace son
puntos en el cdigo componente donde los aspectos pueden interferir. Los puntos de
enlaces son capaces de referir a cdigo, tipos, objetos, y flujos de control. Las
expresiones de corte son utilizadas para identificar un conjunto de puntos de enlaces. Se
componen a partir de los designadores de corte y un conjunto de operadores algebraicos.
La declaracin de los avisos es utilizada para especificar cdigo que debe ejecutarse en
los puntos de enlace determinados por la expresin de corte.

CONCLUSIONES

La POA es una prometedora alternativa para solucionar los problemas actuales de la

seguridad en el software.

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.

Se tiene un cdigo ms reusable y que se puede acoplar y desacoplar cuando sea

necesario.

Bibliografa
[1] Gesto, E. 2006. Mquina de Aspectos: un enfoque alternativo para la
implementacin de aspectos. < http://ficcte.unimoron.edu.ar/wicc/Trabajos/III%20%20isbd/595-Maquina_de_Aspectos.pdf>. (27/03/07)
[2] Quintero, A. 2000. Visin General de la Programacin Orientada a Aspectos
<http://www.lsi.us.es/docs/informes/aopv3.pdf>. (17/04/07)
[3] Asteasuain, F. 2005. Desarrollo orientado a Aspectos.
<http://www.programemos.com/index.php?option=com_content&task=view&id=164&I
temid=73>.(17/04/07)
[4] Lorente M. 2005 Introduccin AspectJ.
<http://www.programemos.com/index.php?option=com_content&task=view&id=12&It
emid=28>.(17/04/07)
[5] Asteasuain, F. 2005. Fundamentos POA.
<http://www.programemos.com/index.php?option=com_content&task=view&id=163&I
temid=74>. (17/04/07).