En este trabajo se introduce la problemática de conflictos entre aspectos circunscripta al paradigma de programación orientada a aspectos. En base a una taxonomía para la resolución de conflictos se analizan brevemente algunas lenguajes orientados a aspectos. El análisis nos permite establecer algunos requisitos para diseñar e implementar herramientas mas abarcativas y seguras para el desarrollo de aplicaciones bajo este enfoque, en lo que respecta al manejo de conflictos entre aspectos.Eje: Programacion, LenguajesRed de Universidades con Carreras en Informática (RedUNCI

Casas, Sandra

Pryor, Jane

Reinaga, Héctor

Saldivia, Claudio

Sierpe, Luis

Vanoli, Verónica

SEDICI - Repositorio de la UNLP

Clasificación y Resolución de Conflictos entre Aspectos
Sandra Casas1 Héctor Reinaga1 Luis Sierpe1 Verónica Vanoli1 Claudio Saldivia1 Jane Pryor2
1Unidad Académica Río Gallegos - Universidad Nacional de la Patagonia Austral.
Río Gallegos - Santa Cruz - Argentina. E-mail: {lis, vvanoli}@uarg.unpa.edu.ar
2ISISTAN Research Institute - Facultad de Ciencias Exactas, UNICEN.
Tandil - Buenos Aires - Argentina. E-mail: jpryor@exa.unicen.edu.ar
Resumen: En este trabajo se introduce la problemática de conflictos entre aspectos
circunscripta al paradigma de programación orientada a aspectos. En base a una taxonomía
para la resolución de conflictos se analizan brevemente algunas lenguajes orientados a
aspectos. El análisis nos permite establecer algunos requisitos para diseñar e implementar
herramientas mas abarcativas y seguras para el desarrollo de aplicaciones bajo este enfoque,
en lo que respecta al manejo de conflictos entre aspectos.
1. Introducción
La Programación Orientada a Aspectos[1]
(POA) es un nuevo paradigma de programación
que soporta la separación de los componentes
funcionales respecto de las competencias técni-
cas de un sistema, tales como la sincronización
de procesos concurrentes, la gestión de errores,
la distribución, la persistencia, el logging, la
seguridad, la traza, etc. Estas competencias
técnicas son propiedades circunstanciales que
afectan a la performance de los componentes
funcionales; cuando se encapsulan en módulos
se denominan aspectos. El objetivo de la POA
es el desarrollo de aplicaciones de software más
fáciles de diseñar, codificar, mantener y reusar,
superando los problemas de código mezclado y
código diseminado[2].
La POA permite a los programadores codificar
los aspectos de una aplicación de manera
separada respecto de la funcionalidad básica.
Los tres componentes fundamentales para desa-
rrollar una aplicación POA son: un lenguaje de
programación de propósito general que se
utiliza para desarrollar los componentes de fun-
cionalidad básica; un lenguaje de programación
orientada a aspectos (LOA), y un tejedor (wea-
ver). Los LOA son extensiones de lenguajes de
programación existentes que incorporan los
mecanismos necesarios para dar soporte a los
aspectos. El  proceso de tejido (realizado por un
nuevo tipo de compilador o intérprete) combina
los componentes de funcionalidad básica con
los aspectos para generar la aplicación ejecuta-
ble[3].
El tejedor de aspectos permite que en ciertos
puntos de la ejecución de los componentes
funcionales se inserte el código de los aspectos.
Estos puntos se denominan puntos de unión
(join-points) y podrían interpretarse como
eventos, que al ocurrir, activan la ejecución de
un aspecto. Desde la perspectiva de los
aspectos, éstos incluyen puntos de corte
(pointcuts) que se asocian a los puntos de unión
del código funcional.
En la mayoría de los LOA, es posible definir
entidades de primera clase que representen a los
aspectos. Esta construcción es una clase o una
entidad muy parecida a una clase, en esencia es
una unidad de código con un nombre y con
variables y métodos propios.
En general, los aspectos cortan los componen-
tes de funcionalidad básica para comunicar que
cierto código se ejecutará antes o después o
durante la ejecución de un evento (método,
excepción, acceso a atributos, ...); introducir
atributos y métodos; modificar la estructura
jerárquica; etc. Estas características se pueden
encontrar en AspectJ[4], y todos aquellos LOA
que se basan en un este tipo de modelo, como
AspectS[5], AspectC++[6], AspectC[7],
Aurelia[8], Pythius[9], AspectR[10], etc.
En el desarrollo de una aplicación POA es
frecuente encontrar situaciones en las que un
componente de funcionalidad básica esta afec-
tado por más de un aspecto. Cada uno de éstos
le adiciona diferente comportamiento. Los
conflictos surgen cuando se ejecutan dos o más
aspectos que están asociados a un mismo
componente funcional, dado que esta situación
puede provocar un comportamiento imprede-
cible o indeseado del sistema.
2.  Conflictos
Una primera aproximación a una definición de
conflicto sería:
Un conflicto ocurre cuando dos o más aspectos
compiten por su activación[11].
mensajeX
asp2
objeto2objeto1
asp1
Conflicto entre asp1 y asp2
En forma similar, se puede referir a los
conflictos como interacciones de aspectos[12].
Como se dijo, un objeto de funcionalidad
básica puede ser asociado a más de un aspecto,
donde cada uno de estos tiene su propio
objetivo de comportamiento. Si las tareas a
realizar por cada aspecto son totalmente
independientes del resto o entre sí, el sistema se
ejecutará sin problemas. Pero el comportamien-
to del sistema se torna impredecible si los as-
pectos que compiten no son independientes. Por
ejemplo, un aspecto específico debe ser ejecu-
tado antes que otros, o la ejecución de dos as-
pectos producen inconsistencia de tal manera
que se requiera la ejecución de sólo uno. En
estos y en otros casos, el desarrollador debe
poder especificar las potenciales situaciones y
la ejecución deseada de acuerdo al tipo de con-
flicto y/o el dominio de la aplicación, deter-
minando las prioridades y políticas de activa-
ción de los aspectos.
En un contexto más amplio, en el cual para
cada elemento de programa (clase, objeto,
método e instancia) se pueden asociar aspectos
en forma independiente, existe una posible
situación conflictiva que puede o no ser tratada.
Dados dos aspectos asp1 y asp2, existe un
conflicto potencial sí:
· asp1 y asp2 son asociados a la misma clase
base.
· asp1 y asp2 son asociados al mismo méto-
do y clase base.
· asp1 y asp2 son asociados al mismo objeto
base.
· asp1 y asp2 son asociados al mismo par
objeto-método base.
· asp1 es asociado a una clase y asp2 es
asociado a un método de la misma clase.
· asp1 es asociado a una clase y asp2 es
asociado a un objeto de la misma clase.
· asp1 es asociado a una clase y asp2 es
asociado a un objeto-método de una instancia
de la  clase.
· asp1 es asociado a un método y asp2 es
asociado a una instancia de la clase a la cual el
método pertenece.
· asp1 es asociado a un método y asp2 es
asociado a un objeto-método del mismo método
e instancia de la clase.
· asp1 es asociado a un objeto y asp2 es
asociado a un objeto-método del mismo objeto.
En este sentido, y según las propiedades que
deben cumplir los LOA definidas en[13], los
conflictos entre aspectos suponen una posible
violación del principio que denota que “los
aspectos no deben interferir entre ellos”.
En general el manejo de conflictos es respon-
sabilidad del programador, ya que las herra-
mientas POA existentes brindan un escaso
soporte para la evaluación o inspección antici-
pada de conflictos. Por ejemplo, en una apli-
cación en las que se codifican varios aspectos,
es el programador el que debe llevar el registro
y control de los posibles conflictos, y en
consecuencia, aplicar los mecanismos que le
ofrezca la herramienta para su resolución. La
situación es más engorrosa y complicada en los
casos que tratan de una aplicación existente,
que ante nuevos requerimientos demanda la
adición o remoción de aspectos, circunstancia
que requiere del análisis de toda la arquitectura
en búsqueda de los posibles nuevos conflictos.
En todos estos casos, se advierte que sería
beneficioso y de gran ayuda que la tarea de
detectar conflictos fuera automática. Esta fun-
ción puede añadirse al tejedor de la herramienta
o como un proceso anterior que se respon-
sabilice de buscar y hallar potenciales conflic-
tos antes de la compilación o ejecución de la
aplicación.
3. Taxonomía de conflictos
La acción a realizar cuando un conflicto es
detectado depende de las características de la
aplicación. En algunos casos será necesario
indicar un orden específico de ejecución de los
aspectos involucrados. En otros casos, un
conflicto puede requerir que uno o ambos as-
pectos no sean activados. Se han identificado
seis categorías de conflictos para la activación
de políticas cuando un conflicto es identificado:
de Orden, de Orden Inverso, Opcional, Exclu-
sivo, Nulo y Dependiente del Contexto, confor-
mando una taxonomía para la resolución de
conflictos[14].
A continuación cada una de estas estrategias se
presenta:
· de Orden: en este tipo de conflicto, se
establece un orden de ejecución para los
aspectos involucrados en él.
· de Orden Inverso: en este tipo de conflicto,
se establece un orden inverso de ejecución para
los aspectos involucrados en él.
· Opcional: en algunos casos puede ser
necesario que el sistema tome la decisión de
qué aspecto ejecutar - en casos de haber varios
compitiendo por ser activados -, dependiendo
de alguna política interna o aleatoria.
· de Exclusión: resulta imprescindible contar
con un tipo de conflicto cuando los aspectos en
cuestión tienen una funcionalidad contradic-
toria, en este caso es necesario que sólo se
ejecute uno de ellos, pero no ambos.
· de Nulidad: mediante este mecanismo se
anula la ejecución de ambos competidores.
· Dependiente del Contexto: a diferencia de
los mecanismos anteriores, el funcionamiento
de este tipo de conflicto brinda la posibilidad de
determinar los objetos que se van a ejecutar y
en qué orden, dependiendo del contexto en el
que se encuentran.
Según nuestra opinión, la taxonomía descripta
es la manera más amplia y flexible porque
ofrece la máxima cantidad de alternativas de
resolución posible. En la realidad, la forma de
resolución de conflictos depende en gran medi-
da de los mecanismos que ofrezca el LOA,
siendo en general muy pobres y restringidos,
como se describe a continuación.
4.  Resolución de Conflictos en POA
En la presente sección se analiza brevemente
los dispositivos que proporcionan algunas he-
rramientas POA con el propósito de resolver
conflictos entre aspectos.
AspectJ
AspectJ[4] es una extensión de Java[15], de
propósito general, considerada la herramienta
POA de mayor popularidad y difusión. En
AspectJ un aspecto puede declarar que los avi-
sos (advices) que define, dominen sobre los
avisos de otros aspectos, lo que implica que el
aviso dominante tiene mayor precedencia que
los especificados en los otros aspectos. Por
defecto, en AspectJ no existe ningún orden
definido, por lo que, si se precisa ejecutar los
avisos en determinado orden, es necesario espe-
cificarlo con la cláusula dominates. La semán-
tica es que si un aspecto A domina sobre un
aspecto B, entonces los avisos de A tienen más
prioridad y se ejecutan antes que los de B. Por
lo tanto, AspectJ sólo cubre la categoría de
orden de resolución de conflictos. En la versión
1.1 de AspectJ la sintaxis de dominates se ha
reemplazado por: declare precedence: A, B;
(los avisos del aspecto A tienen precedencia
sobre los avisos del aspecto B).
DJ Aspect
DJ Aspect[16] es un prototipo desarrollado para
el soporte de POA. Fue diseñado bajo una
arquitectura reflexiva, utilizando para ello
JMOP[17], un framework reflexivo construido
en Java. DJ Aspect trata los conflictos de una
manera simple, a través de la asignación de
prioridades a los aspectos utilizando la instruc-
ción dominates. De esta manera, si se desea dar
precedencia a un aspecto de otro, se le asigna
una prioridad más alta al primero (regla de
precedencia).
Este esquema lo maneja el AspectManager a
través del orden de la colección de aspectos que
se le envía a activateMetaObjets(). Este orden
es:
1. Se ejecutan los métodos before enviándolos a
los aspectos ordenados por mayor prioridad.
2. Se ejecuta el mensaje interceptado.
3. Se ejecutan los métodos after enviándolos a
los aspectos ordenados por menor prioridad.
4. Opcionalmente, se ejecutan los métodos
exception ordenados por mayor prioridad.
Alpheus
Alpheus[14] es una herramienta visual diseñada
para ayudar a los usuarios en el desarrollo de
aplicaciones orientadas a aspectos. Aquí es
importante el concepto de abstracción de
conflictos al mas alto nivel de granularidad,
permitiendo declaraciones en niveles de funcio-
nalidad y no sólo entre aspectos. Soporta un
manejo flexible de conflictos con la intro-
ducción de los planos, otorgándole facilidad en
la definición y mantenimiento, siendo los nive-
les de granularidad de conflictos soportados: de
aspecto-aspecto (determina un conflicto entre
dos aspectos específicos); de aspecto-plano
(establece conflictos entre un aspecto y plano);
de plano-plano (especifica un conflicto entre
todos los aspectos de un plano con respecto a
todos los aspectos de otro plano); y de aspecto-
todos (permite la especificación de conflictos
“uno a muchos”, donde un aspecto específico
tiene un conflicto con todos los otros aspectos).
Alpheus soporta un manejo amplio de con-
flictos que son clasificados en: de orden, op-
cional, exclusivo, nulo o dependiendo del con-
texto. Permite que el usuario defina los
conflictos potenciales entre aspectos o planos,
especificando la política a seguir si el conflicto
es detectado; esto se realiza identificando los
componentes involucrados (por ejemplo,
aspecto-aspecto, aspecto-plano), el tipo de
conflicto (por ejemplo, en orden) y, en el caso
de conflictos dependientes del contexto, el
código específico según el conflicto detectado.
Esta última característica sólo existe en
Alpheus.
Para facilitar el diseño y especificación de los
componentes de aplicación, sus asociaciones y
conflictos, Alpheus ofrece diferentes vistas del
sistema, posibilitando identificar dos grupos
principales de diagramas: los relacionados a los
planos, conflictos y niveles de asociación; y los
relacionados a diagramas UML.
AspectC/C++
AspectC++[18] es una extensión de C++[19],
de propósito general, muy similar a AspectJ. La
precedencia es usada para determinar el orden
de ejecución en el caso de que más de un
aspecto afecte al mismo punto de unión. El
compilador chequea las siguientes condiciones
para determinar la precedencia de aspectos:
- Orden de declaración: el programador provee
un orden de declaración que define la relación
de precedencia entre dos aspectos para un punto
de unión. La sintaxis de orden de declaración es
la siguiente: advice pointcut-expr : order (high,
..., low). La lista de argumentos debe contener
al menos dos elementos. Cada aspecto en una
lista de argumentos tiene una precedencia
mayor que los demás, por ejemplo, ‘(“A1” ||
“A2”, “A3” || “A4”)’, significa que A1 tiene
una precedencia sobre A3 y A4, como así A2
tiene una precedencia sobre A3 y A4.
- Relación de herencia: mediante una relación
de herencia se define que el aspecto derivado
tiene una mayor precedencia sobre el aspecto
base.
La precedencia de avisos es determinada a
través de un esquema simple:
- si dos declaraciones de avisos pertenecen
a distintos aspectos, se asumirá la misma rela-
ción de precedencia entre aspectos.
- si dos declaraciones de avisos pertenecen
al mismo aspecto, entonces el primer aviso
declarado tiene la mayor precedencia.
AOP/ST
AOP/ST[20] es una extensión de VisualWorks
(SmallTalk) que soporta una limitada cantidad
de puntos de unión. El autor hace referencia a
las relaciones entre aspectos y define tres
posibles formas:
1. Pre-requisito: un aspecto puede requerir de
otro aspecto para ser tejido primero.
2. Orden de composición: los aspectos nece-
sitan ser tejidos en un orden específico.
3. Validación de composición: algunas combi-
naciones de aspectos pueden no ser permitidas.
AOP/ST solo maneja la relación de orden,
mediante un mecanismo sencillo por el cual se
establecen las prioridades de composición/eje-
cución asignando un valor numérico a cada
aspecto, así los aspectos con alta precedencia
son ejecutados primero.
5. Conclusiones y trabajo futuro
La POA resulta ser una técnica muy prome-
tedora para desarrollar aplicaciones de software
más modulares. Pero la realidad es que aún se
encuentra en un ciclo temprano en cuanto a su
investigación y experimentación. Se destaca
una considerable y explosiva aparición de los
LOA, a la vez que la principal discusión se
encuentra focalizada en los tipos de tejedo-
res[3]. Es por este motivo, que aun no se ha
profundizado sobre la problemática de conflic-
tos entre aspectos.
Se observa en primer lugar, que la mayoría de
las herramientas POA ofrecen mecanismos muy
restringidos y pobres para la resolución de
conflictos, comparados con la taxonomía pro-
puesta. Concretamente, la mayoría de éstos
ofrece la resolución que responde a la categoría
de Orden.
En segundo lugar, detectar la presencia y
existencia de conflictos es una tarea prácti-
camente manual, por estar ausente en la mayo-
ría de las herramientas de forma automática,
principalmente en aquellas de mayor uso y
difusión.
El objetivo es el estudio de estrategias tendien-
tes a la resolución de conflictos y su implemen-
tación en herramientas. En esta primer etapa el
trabajo se centra en particular en el estudio de
AspectJ, con el propósito de dotarlo de meca-
nismos automáticos para la especificación,
detección y resolución de conflictos entre
aspectos.
El presente trabajo fue parcialmente financiado
por la UNPA, Santa Cruz, Argentina.
6. Referencias
[1] Mens K., Lopes C., Tekinerdogan B.,
Kiczales G. “Aspect-Oriented Programming”.
Workshop Report ECOOP. 11th. Finland. 1997.
[2]  Laddad R. “I want my AOP”. Part 1,2,3
from JavaWorld. 2002.
[3] Piveta E., Zancanela L. “Aspect Weaving
Strategies”. Journal of Universal Computer
Sciencie. Vol.9. Num.8. 2003.
[4] Kiczales G., Hilsdale E., Hugunin J.,
Kersten M. , Palm J., Griswold W. “An
Overview of AspectJ”. ECOOP 2001.
[5] Hirschfeld R. “AspectS - AOP with
Squeak”. In Proceedings of OOPSLA. Work-
shop on Advanced Separation of Concerns in
Object-Oriented System. USA. 2001.
[6] Sitio Web de AspectC++:
http://www.aspectc.org/
[7] Sitio Web de AspectC:
www.cs.ubc.ca/labs/spl/projects/aspectc.html
[8] Piveta E., Zancanela L. “Aurelia: Aspect
oriented programming using reflective
approach”. Workshop on Advanced Separation
of Concers ECOOP. 2001.
[9] Sitio Web de Pythius:
http://sourceforge.net/projects/pythius/
[10] Sitio Web de AspectR:
http://aspectr.sourceforge.net/
[11] Pryor J., Diaz Pace A., Campo M.
“Reflection on Separation of Concerns”. RITA.
Vol.9. Num.1. 2002.
[12] Douence R., Fradet P., Südholt M. “A
Framework for the Detection and Resolution of
Aspect Interactions”. Proceedings of the ACM
SIGPLAN SIGSOFT Conference on GPCE.
2002.
[13] Cugola G., Ghezzi C., Monga M. “Coding
Different Design Paradigms for Distributed
Applications with Aspect-Oriented Progra-
mming”. WSDAAL. 1999.
[14] Pryor J., Marcos C. “Solving Conflicts in
Aspect-Oriented Applications”. Proceedings of
the Fourth ASSE. 32 JAIIO. Argentina. 2003.
[15] Gosling J., Joy B., Steel G. “The Java
Languaje Specification”. Addison-Wesley.
1996.
[16] Pryor J., Bastán N., Campo M. “A
Reflective Approach to Support Aspect
Oriented Programming in Java”. In Proceedings
of the ASSE. 29 JAIIO. Argentina. 2000.
[17] Zunino A. “Brainstorm/J: un framework
para agentes inteligentes”. Master's Degree
Dissertation. UNICEN. ISISTAN. 2000.
[18] Gal A., Scroder-Preikschat W., Spinczyk
O. “AspectC++: Language Proposal and
Prototype Implementation”. ACM International
Conference Proceeding Series Proceedings of
the Fortieth International Confernece on Tools
Pacific. Vol.10. Australia. 2002.
[19] Stroustrup B. “The C++ Programming
Languaje”. Addison-Wessley. 1991.
[20] Boellert K. “On Weaving Aspects”.
Proceeding of the AOP Workshop at ECOOP.
1999.


Spanish

Clasificación y resolución de conflictos entre aspectos

Servicio de Difusión de la Creación Intelectual

Clasificación y Resolución de Conflictos entre AspectosSandra Casas1 Héctor Reinaga1 Luis Sierpe1 Verónica Vanoli1 Claudio Saldivia1 Jane Pryor21Unidad Académica Río Gallegos - Universidad Nacional de la Patagonia Austral.Río Gallegos - Santa Cruz - Argentina. E-mail: {lis, vvanoli}@uarg.unpa.edu.ar2ISISTAN Research Institute - Facultad de Ciencias Exactas, UNICEN.Tandil - Buenos Aires - Argentina. E-mail: jpryor@exa.unicen.edu.arResumen: En este trabajo se introduce la problemática de conflictos entre aspectoscircunscripta al paradigma de programación orientada a aspectos. En base a una taxonomíapara la resolución de conflictos se analizan brevemente algunas lenguajes orientados aaspectos. El análisis nos permite establecer algunos requisitos para diseñar e implementarherramientas mas abarcativas y seguras para el desarrollo de aplicaciones bajo este enfoque,en lo que respecta al manejo de conflictos entre aspectos.1. IntroducciónLa Programación Orientada a Aspectos[1](POA) es un nuevo paradigma de programaciónque soporta la separación de los componentesfuncionales respecto de las competencias técni-cas de un sistema, tales como la sincronizaciónde procesos concurrentes, la gestión de errores,la distribución, la persistencia, el logging, laseguridad, la traza, etc. Estas competenciastécnicas son propiedades circunstanciales queafectan a la performance de los componentesfuncionales; cuando se encapsulan en módulosse denominan aspectos. El objetivo de la POAes el desarrollo de aplicaciones de software másfáciles de diseñar, codificar, mantener y reusar,superando los problemas de código mezclado ycódigo diseminado[2].La POA permite a los programadores codificarlos aspectos de una aplicación de maneraseparada respecto de la funcionalidad básica.Los tres componentes fundamentales para desa-rrollar una aplicación POA son: un lenguaje deprogramación de propósito general que seutiliza para desarrollar los componentes de fun-cionalidad básica; un lenguaje de programaciónorientada a aspectos (LOA), y un tejedor (wea-ver). Los LOA son extensiones de lenguajes deprogramación existentes que incorporan losmecanismos necesarios para dar soporte a losaspectos. El  proceso de tejido (realizado por unnuevo tipo de compilador o intérprete) combinalos componentes de funcionalidad básica conlos aspectos para generar la aplicación ejecuta-ble[3].El tejedor de aspectos permite que en ciertospuntos de la ejecución de los componentesfuncionales se inserte el código de los aspectos.Estos puntos se denominan puntos de unión(join-points) y podrían interpretarse comoeventos, que al ocurrir, activan la ejecución deun aspecto. Desde la perspectiva de losaspectos, éstos incluyen puntos de corte(pointcuts) que se asocian a los puntos de unióndel código funcional.En la mayoría de los LOA, es posible definirentidades de primera clase que representen a losaspectos. Esta construcción es una clase o unaentidad muy parecida a una clase, en esencia esuna unidad de código con un nombre y convariables y métodos propios.En general, los aspectos cortan los componen-tes de funcionalidad básica para comunicar quecierto código se ejecutará antes o después odurante la ejecución de un evento (método,excepción, acceso a atributos, ...); introduciratributos y métodos; modificar la estructurajerárquica; etc. Estas características se puedenencontrar en AspectJ[4], y todos aquellos LOAque se basan en un este tipo de modelo, comoAspectS[5], AspectC++[6], AspectC[7],Aurelia[8], Pythius[9], AspectR[10], etc.En el desarrollo de una aplicación POA esfrecuente encontrar situaciones en las que uncomponente de funcionalidad básica esta afec-tado por más de un aspecto. Cada uno de éstosle adiciona diferente comportamiento. Losconflictos surgen cuando se ejecutan dos o másaspectos que están asociados a un mismocomponente funcional, dado que esta situaciónpuede provocar un comportamiento imprede-cible o indeseado del sistema.2.  ConflictosUna primera aproximación a una definición deconflicto sería:Un conflicto ocurre cuando dos o más aspectoscompiten por su activación[11].mensajeXasp2objeto2objeto1asp1Conflicto entre asp1 y asp2En forma similar, se puede referir a losconflictos como interacciones de aspectos[12].Como se dijo, un objeto de funcionalidadbásica puede ser asociado a más de un aspecto,donde cada uno de estos tiene su propioobjetivo de comportamiento. Si las tareas arealizar por cada aspecto son totalmenteindependientes del resto o entre sí, el sistema seejecutará sin problemas. Pero el comportamien-to del sistema se torna impredecible si los as-pectos que compiten no son independientes. Porejemplo, un aspecto específico debe ser ejecu-tado antes que otros, o la ejecución de dos as-pectos producen inconsistencia de tal maneraque se requiera la ejecución de sólo uno. Enestos y en otros casos, el desarrollador debepoder especificar las potenciales situaciones yla ejecución deseada de acuerdo al tipo de con-flicto y/o el dominio de la aplicación, deter-minando las prioridades y políticas de activa-ción de los aspectos.En un contexto más amplio, en el cual paracada elemento de programa (clase, objeto,método e instancia) se pueden asociar aspectosen forma independiente, existe una posiblesituación conflictiva que puede o no ser tratada.Dados dos aspectos asp1 y asp2, existe unconflicto potencial sí:· asp1 y asp2 son asociados a la misma clasebase.· asp1 y asp2 son asociados al mismo méto-do y clase base.· asp1 y asp2 son asociados al mismo objetobase.· asp1 y asp2 son asociados al mismo parobjeto-método base.· asp1 es asociado a una clase y asp2 esasociado a un método de la misma clase.· asp1 es asociado a una clase y asp2 esasociado a un objeto de la misma clase.· asp1 es asociado a una clase y asp2 esasociado a un objeto-método de una instanciade la  clase.· asp1 es asociado a un método y asp2 esasociado a una instancia de la clase a la cual elmétodo pertenece.· asp1 es asociado a un método y asp2 esasociado a un objeto-método del mismo métodoe instancia de la clase.· asp1 es asociado a un objeto y asp2 esasociado a un objeto-método del mismo objeto.En este sentido, y según las propiedades quedeben cumplir los LOA definidas en[13], losconflictos entre aspectos suponen una posibleviolación del principio que denota que “losaspectos no deben interferir entre ellos”.En general el manejo de conflictos es respon-sabilidad del programador, ya que las herra-mientas POA existentes brindan un escasosoporte para la evaluación o inspección antici-pada de conflictos. Por ejemplo, en una apli-cación en las que se codifican varios aspectos,es el programador el que debe llevar el registroy control de los posibles conflictos, y enconsecuencia, aplicar los mecanismos que leofrezca la herramienta para su resolución. Lasituación es más engorrosa y complicada en loscasos que tratan de una aplicación existente,que ante nuevos requerimientos demanda laadición o remoción de aspectos, circunstanciaque requiere del análisis de toda la arquitecturaen búsqueda de los posibles nuevos conflictos.En todos estos casos, se advierte que seríabeneficioso y de gran ayuda que la tarea dedetectar conflictos fuera automática. Esta fun-ción puede añadirse al tejedor de la herramientao como un proceso anterior que se respon-sabilice de buscar y hallar potenciales conflic-tos antes de la compilación o ejecución de laaplicación.3. Taxonomía de conflictosLa acción a realizar cuando un conflicto esdetectado depende de las características de laaplicación. En algunos casos será necesarioindicar un orden específico de ejecución de losaspectos involucrados. En otros casos, unconflicto puede requerir que uno o ambos as-pectos no sean activados. Se han identificadoseis categorías de conflictos para la activaciónde políticas cuando un conflicto es identificado:de Orden, de Orden Inverso, Opcional, Exclu-sivo, Nulo y Dependiente del Contexto, confor-mando una taxonomía para la resolución deconflictos[14].A continuación cada una de estas estrategias sepresenta:· de Orden: en este tipo de conflicto, seestablece un orden de ejecución para losaspectos involucrados en él.· de Orden Inverso: en este tipo de conflicto,se establece un orden inverso de ejecución paralos aspectos involucrados en él.· Opcional: en algunos casos puede sernecesario que el sistema tome la decisión dequé aspecto ejecutar - en casos de haber varioscompitiendo por ser activados -, dependiendode alguna política interna o aleatoria.· de Exclusión: resulta imprescindible contarcon un tipo de conflicto cuando los aspectos encuestión tienen una funcionalidad contradic-toria, en este caso es necesario que sólo seejecute uno de ellos, pero no ambos.· de Nulidad: mediante este mecanismo seanula la ejecución de ambos competidores.· Dependiente del Contexto: a diferencia delos mecanismos anteriores, el funcionamientode este tipo de conflicto brinda la posibilidad dedeterminar los objetos que se van a ejecutar yen qué orden, dependiendo del contexto en elque se encuentran.Según nuestra opinión, la taxonomía descriptaes la manera más amplia y flexible porqueofrece la máxima cantidad de alternativas deresolución posible. En la realidad, la forma deresolución de conflictos depende en gran medi-da de los mecanismos que ofrezca el LOA,siendo en general muy pobres y restringidos,como se describe a continuación.4.  Resolución de Conflictos en POAEn la presente sección se analiza brevementelos dispositivos que proporcionan algunas he-rramientas POA con el propósito de resolverconflictos entre aspectos.AspectJAspectJ[4] es una extensión de Java[15], depropósito general, considerada la herramientaPOA de mayor popularidad y difusión. EnAspectJ un aspecto puede declarar que los avi-sos (advices) que define, dominen sobre losavisos de otros aspectos, lo que implica que elaviso dominante tiene mayor precedencia quelos especificados en los otros aspectos. Pordefecto, en AspectJ no existe ningún ordendefinido, por lo que, si se precisa ejecutar losavisos en determinado orden, es necesario espe-cificarlo con la cláusula dominates. La semán-tica es que si un aspecto A domina sobre unaspecto B, entonces los avisos de A tienen másprioridad y se ejecutan antes que los de B. Porlo tanto, AspectJ sólo cubre la categoría deorden de resolución de conflictos. En la versión1.1 de AspectJ la sintaxis de dominates se hareemplazado por: declare precedence: A, B;(los avisos del aspecto A tienen precedenciasobre los avisos del aspecto B).DJ AspectDJ Aspect[16] es un prototipo desarrollado parael soporte de POA. Fue diseñado bajo unaarquitectura reflexiva, utilizando para elloJMOP[17], un framework reflexivo construidoen Java. DJ Aspect trata los conflictos de unamanera simple, a través de la asignación deprioridades a los aspectos utilizando la instruc-ción dominates. De esta manera, si se desea darprecedencia a un aspecto de otro, se le asignauna prioridad más alta al primero (regla deprecedencia).Este esquema lo maneja el AspectManager através del orden de la colección de aspectos quese le envía a activateMetaObjets(). Este ordenes:1. Se ejecutan los métodos before enviándolos alos aspectos ordenados por mayor prioridad.2. Se ejecuta el mensaje interceptado.3. Se ejecutan los métodos after enviándolos alos aspectos ordenados por menor prioridad.4. Opcionalmente, se ejecutan los métodosexception ordenados por mayor prioridad.AlpheusAlpheus[14] es una herramienta visual diseñadapara ayudar a los usuarios en el desarrollo deaplicaciones orientadas a aspectos. Aquí esimportante el concepto de abstracción deconflictos al mas alto nivel de granularidad,permitiendo declaraciones en niveles de funcio-nalidad y no sólo entre aspectos. Soporta unmanejo flexible de conflictos con la intro-ducción de los planos, otorgándole facilidad enla definición y mantenimiento, siendo los nive-les de granularidad de conflictos soportados: deaspecto-aspecto (determina un conflicto entredos aspectos específicos); de aspecto-plano(establece conflictos entre un aspecto y plano);de plano-plano (especifica un conflicto entretodos los aspectos de un plano con respecto atodos los aspectos de otro plano); y de aspecto-todos (permite la especificación de conflictos“uno a muchos”, donde un aspecto específicotiene un conflicto con todos los otros aspectos).Alpheus soporta un manejo amplio de con-flictos que son clasificados en: de orden, op-cional, exclusivo, nulo o dependiendo del con-texto. Permite que el usuario defina losconflictos potenciales entre aspectos o planos,especificando la política a seguir si el conflictoes detectado; esto se realiza identificando loscomponentes involucrados (por ejemplo,aspecto-aspecto, aspecto-plano), el tipo deconflicto (por ejemplo, en orden) y, en el casode conflictos dependientes del contexto, elcódigo específico según el conflicto detectado.Esta última característica sólo existe enAlpheus.Para facilitar el diseño y especificación de loscomponentes de aplicación, sus asociaciones yconflictos, Alpheus ofrece diferentes vistas delsistema, posibilitando identificar dos gruposprincipales de diagramas: los relacionados a losplanos, conflictos y niveles de asociación; y losrelacionados a diagramas UML.AspectC/C++AspectC++[18] es una extensión de C++[19],de propósito general, muy similar a AspectJ. Laprecedencia es usada para determinar el ordende ejecución en el caso de que más de unaspecto afecte al mismo punto de unión. Elcompilador chequea las siguientes condicionespara determinar la precedencia de aspectos:- Orden de declaración: el programador proveeun orden de declaración que define la relaciónde precedencia entre dos aspectos para un puntode unión. La sintaxis de orden de declaración esla siguiente: advice pointcut-expr : order (high,..., low). La lista de argumentos debe conteneral menos dos elementos. Cada aspecto en unalista de argumentos tiene una precedenciamayor que los demás, por ejemplo, ‘(“A1” ||“A2”, “A3” || “A4”)’, significa que A1 tieneuna precedencia sobre A3 y A4, como así A2tiene una precedencia sobre A3 y A4.- Relación de herencia: mediante una relaciónde herencia se define que el aspecto derivadotiene una mayor precedencia sobre el aspectobase.La precedencia de avisos es determinada através de un esquema simple:- si dos declaraciones de avisos pertenecena distintos aspectos, se asumirá la misma rela-ción de precedencia entre aspectos.- si dos declaraciones de avisos pertenecenal mismo aspecto, entonces el primer avisodeclarado tiene la mayor precedencia.AOP/STAOP/ST[20] es una extensión de VisualWorks(SmallTalk) que soporta una limitada cantidadde puntos de unión. El autor hace referencia alas relaciones entre aspectos y define tresposibles formas:1. Pre-requisito: un aspecto puede requerir deotro aspecto para ser tejido primero.2. Orden de composición: los aspectos nece-sitan ser tejidos en un orden específico.3. Validación de composición: algunas combi-naciones de aspectos pueden no ser permitidas.AOP/ST solo maneja la relación de orden,mediante un mecanismo sencillo por el cual seestablecen las prioridades de composición/eje-cución asignando un valor numérico a cadaaspecto, así los aspectos con alta precedenciason ejecutados primero.5. Conclusiones y trabajo futuroLa POA resulta ser una técnica muy prome-tedora para desarrollar aplicaciones de softwaremás modulares. Pero la realidad es que aún seencuentra en un ciclo temprano en cuanto a suinvestigación y experimentación. Se destacauna considerable y explosiva aparición de losLOA, a la vez que la principal discusión seencuentra focalizada en los tipos de tejedo-res[3]. Es por este motivo, que aun no se haprofundizado sobre la problemática de conflic-tos entre aspectos.Se observa en primer lugar, que la mayoría delas herramientas POA ofrecen mecanismos muyrestringidos y pobres para la resolución deconflictos, comparados con la taxonomía pro-puesta. Concretamente, la mayoría de éstosofrece la resolución que responde a la categoríade Orden.En segundo lugar, detectar la presencia yexistencia de conflictos es una tarea prácti-camente manual, por estar ausente en la mayo-ría de las herramientas de forma automática,principalmente en aquellas de mayor uso ydifusión.El objetivo es el estudio de estrategias tendien-tes a la resolución de conflictos y su implemen-tación en herramientas. En esta primer etapa eltrabajo se centra en particular en el estudio deAspectJ, con el propósito de dotarlo de meca-nismos automáticos para la especificación,detección y resolución de conflictos entreaspectos.El presente trabajo fue parcialmente financiadopor la UNPA, Santa Cruz, Argentina.6. Referencias[1] Mens K., Lopes C., Tekinerdogan B.,Kiczales G. “Aspect-Oriented Programming”.Workshop Report ECOOP. 11th. Finland. 1997.[2]  Laddad R. “I want my AOP”. Part 1,2,3from JavaWorld. 2002.[3] Piveta E., Zancanela L. “Aspect WeavingStrategies”. Journal of Universal ComputerSciencie. Vol.9. Num.8. 2003.[4] Kiczales G., Hilsdale E., Hugunin J.,Kersten M. , Palm J., Griswold W. “AnOverview of AspectJ”. ECOOP 2001.[5] Hirschfeld R. “AspectS - AOP withSqueak”. In Proceedings of OOPSLA. Work-shop on Advanced Separation of Concerns inObject-Oriented System. USA. 2001.[6] Sitio Web de AspectC++:http://www.aspectc.org/[7] Sitio Web de AspectC:www.cs.ubc.ca/labs/spl/projects/aspectc.html[8] Piveta E., Zancanela L. “Aurelia: Aspectoriented programming using reflectiveapproach”. Workshop on Advanced Separationof Concers ECOOP. 2001.[9] Sitio Web de Pythius:http://sourceforge.net/projects/pythius/[10] Sitio Web de AspectR:http://aspectr.sourceforge.net/[11] Pryor J., Diaz Pace A., Campo M.“Reflection on Separation of Concerns”. RITA.Vol.9. Num.1. 2002.[12] Douence R., Fradet P., Südholt M. “AFramework for the Detection and Resolution ofAspect Interactions”. Proceedings of the ACMSIGPLAN SIGSOFT Conference on GPCE.2002.[13] Cugola G., Ghezzi C., Monga M. “CodingDifferent Design Paradigms for DistributedApplications with Aspect-Oriented Progra-mming”. WSDAAL. 1999.[14] Pryor J., Marcos C. “Solving Conflicts inAspect-Oriented Applications”. Proceedings ofthe Fourth ASSE. 32 JAIIO. Argentina. 2003.[15] Gosling J., Joy B., Steel G. “The JavaLanguaje Specification”. Addison-Wesley.1996.[16] Pryor J., Bastán N., Campo M. “AReflective Approach to Support AspectOriented Programming in Java”. In Proceedingsof the ASSE. 29 JAIIO. Argentina. 2000.[17] Zunino A. “Brainstorm/J: un frameworkpara agentes inteligentes”. Master's DegreeDissertation. UNICEN. ISISTAN. 2000.[18] Gal A., Scroder-Preikschat W., SpinczykO. “AspectC++: Language Proposal andPrototype Implementation”. ACM InternationalConference Proceeding Series Proceedings ofthe Fortieth International Confernece on ToolsPacific. Vol.10. Australia. 2002.[19] Stroustrup B. “The C++ ProgrammingLanguaje”. Addison-Wessley. 1991.[20] Boellert K. “On Weaving Aspects”.Proceeding of the AOP Workshop at ECOOP.1999.

http://sedici.unlp.edu.ar/bitstream/handle/10915/21199/Documento_completo.pdf?sequence=1

Clasificación y resolución de conflictos entre aspectos

Abstract

Similar works

Full text

Available Versions

SEDICI - Repositorio de la UNLP

Servicio de Difusión de la Creación Intelectual