Programación orientada a aspectos




              Abdiel E. Cáceres González
Centro de Investigación y de Estudios Avanz...
Introducción
Introducción


Los conceptos y tecnologías reunidos bajo el nombre
quot;programación orientada a aspectosquot; (AOP, por l...
Separación de asuntos



 El principio de separación de asuntos
fue identificado en la década de 1970,
plantea que un prob...
Separación de asuntos


El principio puede aplicarse de distintas maneras. Por
ejemplo, separar las fases del proceso de d...
Separación de asuntos


Las técnicas de modelado que se usan en la etapa de diseño de
un sistema se basan en partirlo en v...
Separación de asuntos




Las   construcciones   provistas   por   los   lenguajes   de
programación, que fueron creados p...
Separación de asuntos


El problema aparece cuando un asunto afecta a distintas
partes del sistema que no aparecen relacio...
Separación de asuntos




Un ejemplo clásico de la
programación orientada a
       aspectos es el de
 distintos métodos de...
Separación de asuntos


Estas responsabilidades, que aparecen diseminadas en el
código atravesando partes del sistema no r...
Asuntos transversales


Otro ejemplo, también clásico, de asuntos transversales es el
logging o registro de la actividad d...
Asuntos transversales



Las consecuencias directas de estas asuntos transversales son
el código disperso y enredado (scat...
Asuntos transversales



Si una misma operación tiene que acceder a varios servicios
(logging, locking, presentación, tran...
Asuntos transversales



Si una misma operación tiene que acceder a varios servicios
(logging, locking, presentación, tran...
Asuntos transversales



La fuente de estos problemas es que en realidad cada
aplicación tiene una política sobre dónde se...
Asuntos transversales




La solución que propone la comunidad de AOP es modularizar
las asuntos transversales, justamente...
Aspectos



Ya sabemos cuál es la idea detrás de un aspecto, veamos ahora
cómo se llevan a la práctica. Empecemos por ver ...
Aspectos



Lo que se hizo fue definir un aspecto (pronto hablaremos de
las partes que lo conforman) que indica que se deb...
Aspectos



Lo que se hizo fue definir un aspecto (pronto hablaremos de
las partes que lo conforman) que indica que se deb...
Aspectos




Para entender cómo se aplica un aspecto, tenemos que empezar
por el concepto de punto de unión (join point). ...
Aspectos


La frase anterior habla de la cuarta invocación de un método
en una ejecución, y esto no corresponde a un punto...
Aspectos



Ahora pasemos a hablar de un concepto un poco más complicado
que el de punto de unión, que es el de pointcut. ...
Aspectos


call(void FigureElement+.set*(..)) significa quot;al invocar
(call) cualquier método de la clase FigureElement ...
Aspectos


El siguiente fragmento es fácil de comprender: call(void
FigureElement.moveBy(int, int)). El operador de disyun...
Aspectos




Además de call hay otros constructores de pointcuts, como

get (al leer el valor de una variable),

set (al m...
Aspectos




Los pointcuts son parte de un aspecto, indican
dónde (en qué puntos de unión) se va a aplicar.

La otra parte...
Aspectos


En la Figura, el consejo dice que hay que agregar la
instrucción Display.Update(); después (after) de cada uno ...
Aspectos



El mecanismo por el cual se combinan los aspectos con el
código base se llama entretejido (weaving), y puede h...
Aspectos




En este ejemplo tan sencillo que vimos, aparecen ya las dos
ideas más poderosas que hay detrás de los aspecto...
Prescindencia y Cuantificación




La   prescindencia se   corresponde  con  el  principio  de
abstracción y encapsulamien...
Prescindencia y Cuantificación




La cuantificación    también     es    esencial      al   trabajar   con
aspectos.

Rec...
Prescindencia y Cuantificación




En algunas supuestas implementaciones de AOP, se requiere que
el programador del código...
Prescindencia y Cuantificación




Otras implementaciones brindan herramientas para que, por
fuera del código, se señale e...
Implicaciones en el uso de aspectos




El desarrollo de software orientado a aspectos todavía se
encuentra en un estado i...
Implicaciones en el uso de aspectos




Una de las razones para la falta de adopción puede
encontrarse en la dificultad qu...
Implicaciones en el uso de aspectos




Existen algunas propuestas para solucionar este problema de
AOP   y   proyectos  c...
Implicaciones en el uso de aspectos




Otro inconveniente que atenta contra la adopción generalizada
de AOP es la reutili...
Implicaciones en el uso de aspectos


Siguiendo el ejemplo de la Figura, los programadores estarían
obligados a poner nomb...
Implicaciones en el uso de aspectos


O, alternativamente, haría falta modificar la definición del
pointcut para adaptarla...
Contacto:

acaceres@computacion.cs.cinvestav.mx
       abdiel@mazatlan.udo.mx


              Abdiel E. Cáceres González
C...
Próxima SlideShare
Cargando en…5
×

Poa 01

1.763 visualizaciones

Publicado el

0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
1.763
En SlideShare
0
De insertados
0
Número de insertados
81
Acciones
Compartido
0
Descargas
13
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Poa 01

  1. 1. Programación orientada a aspectos Abdiel E. Cáceres González Centro de Investigación y de Estudios Avanzados - IPN México D.F., México. 2004
  2. 2. Introducción
  3. 3. Introducción Los conceptos y tecnologías reunidos bajo el nombre quot;programación orientada a aspectosquot; (AOP, por las siglas de Aspect-Oriented Programming; o AOSD, por Aspect-Oriented Software Development) buscan resolver un problema identificado hace tiempo en el desarrollo de software. Se trata del problema de la separación de asuntos (separation of concerns). AOP no es el único intento por solucionar este problema, del que voy a hablar a continuación: hay varias propuestas, muchas de las cuales se agrupan (junto con AOP) en el campo de estudio denominado ASoC (Advanced Separation of Concerns).
  4. 4. Separación de asuntos El principio de separación de asuntos fue identificado en la década de 1970, plantea que un problema dado involucra varias asuntos que deben ser identificadas y separadas. Las asuntos son los diferentes temas o asuntos de los que es necesario ocuparse para resolver el problema. Una de ellas es la función específica que debe realizar una aplicación, pero también surgen otras como por ejemplo distribución, persistencia, replicación, sincronización, etc. Separando las asuntos, se disminuye la complejidad a la hora de tratarlas y se puede cumplir con requerimientos relacionados con la calidad como adaptabilidad, mantenibilidad, extensibilidad y reutilizabilidad.
  5. 5. Separación de asuntos El principio puede aplicarse de distintas maneras. Por ejemplo, separar las fases del proceso de desarrollo puede verse como una separación de actividades de ingeniería en el tiempo y por su objetivo. Definir subsistemas, objetos y componentes son otras formas de poner en práctica el principio de separación de asuntos. Por eso podemos decir que se trata de un principio rector omnipresente en el proceso de desarrollo de software.
  6. 6. Separación de asuntos Las técnicas de modelado que se usan en la etapa de diseño 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 técnicas sufren en su mayoría la llamada quot;tiranía de la descomposición dominantequot; que consiste en guiarse al modelar, implícita o explícitamente, por una visión jerárquica determinada de la organización del sistema. La desventaja de estas particiones es que muchas de las asuntos a tener en cuenta para cumplir con los requerimientos (en particular, habitualmente, las asuntos no funcionales) no suelen adaptarse bien a esa descomposición, como veremos más adelante.
  7. 7. Separación de asuntos Las construcciones provistas por los lenguajes de programación, que fueron creados para implementar los modelos generados por las técnicas de diseño existentes, reproducen las jerarquías y, por lo tanto, comparten el defecto explicado en el párrafo anterior. En el paradigma de programación imperativa, la descomposición consiste en identificar procedimientos que resuelvan parte del problema, y la jerarquía se da en el árbol de ejecución, según el cual los procedimientos se invocan unos a otros. En el caso de la programación orientada a objetos, la jerarquía generada en la etapa de diseño suele plasmarse en las relaciones de herencia o de composición entre objetos. Por ejemplo, algunos patrones de diseño de uso habitual como observador (observer), visitante (visitor) y mediador (mediator) exhiben estos problemas, ya que para aplicarlos es necesario adaptar a ellos más de una clase.
  8. 8. Separación de asuntos El problema aparece cuando un asunto afecta a distintas partes del sistema que no aparecen relacionadas en la jerarquía. En ese caso, la única solución suele ser escribir código repetido que resuelva ese asunto para cada subsistema.
  9. 9. Separación de asuntos Un ejemplo clásico de la programación orientada a aspectos es el de distintos métodos de un sistema de edición de gráficos que, luego de modificar la representación interna, terminan actualizando su vista en pantalla. Asuntos diseminados
  10. 10. Separación de asuntos Estas responsabilidades, que aparecen diseminadas en el código atravesando partes del sistema no relacionadas en el modelo, se denominan asuntos transversales (crosscutting concerns).
  11. 11. Asuntos transversales Otro ejemplo, también clásico, de asuntos transversales es el logging o registro de la actividad de una aplicación. En varios puntos de ejecución, que podrían pertenecer a elementos del programa disconexos, queremos invocar un método que registra en un archivo de texto o en una base de datos el hecho de que se ha llegado a ese punto.
  12. 12. Asuntos transversales Las consecuencias directas de estas asuntos transversales son el código disperso y enredado (scattering and tangling). Se habla de código disperso cuando un mismo servicio es invocado de manera similar desde muchas partes del programa, como en el ejemplo que vemos en la Figura. Aquí cada barra representa un módulo del sistema, las líneas de código que invocan el servicio de logging están en rojo.
  13. 13. Asuntos transversales Si una misma operación tiene que acceder a varios servicios (logging, locking, presentación, transporte, autenticación, seguridad, etc), además de cumplir con su función específica, estamos ante una muestra de código enredado.
  14. 14. Asuntos transversales Si una misma operación tiene que acceder a varios servicios (logging, locking, presentación, transporte, autenticación, seguridad, etc), además de cumplir con su función específica, estamos ante una muestra de código enredado.
  15. 15. Asuntos transversales La fuente de estos problemas es que en realidad cada aplicación tiene una política sobre dónde se requiere cada uno de estos servicios; pero esa política no es explícita, está oculta como parte de la estructura del programa. Esto hace que sea difícil de entender, razonar sobre ella y mantenerla.
  16. 16. Asuntos transversales La solución que propone la comunidad de AOP es modularizar las asuntos transversales, justamente esa es la definición de aspecto: una incumbencia transversal modularizada.
  17. 17. Aspectos Ya sabemos cuál es la idea detrás de un aspecto, veamos ahora cómo se llevan a la práctica. Empecemos por ver la propuesta de AOP para resolver la dispersión de la Figura A, que se muestra en la Figura B. A B
  18. 18. Aspectos Lo que se hizo fue definir un aspecto (pronto hablaremos de las partes que lo conforman) que indica que se debe ejecutar la instrucción Display.update(); al terminar la invocación a cualquier método cuyo nombre comienze con set, de una subclase de FigureElement. La notación usada está basada en AspectJ.
  19. 19. Aspectos Lo que se hizo fue definir un aspecto (pronto hablaremos de las partes que lo conforman) que indica que se debe ejecutar la instrucción Display.update(); al terminar la invocación a cualquier método cuyo nombre comienze con set, de una subclase de FigureElement. La notación usada está basada en AspectJ.
  20. 20. Aspectos Para entender cómo se aplica un aspecto, tenemos que empezar por el concepto de punto de unión (join point). Los puntos de unión son puntos en la ejecución de un programa. Por ejemplo, quot;al invocar al método Line.getP1() por cuarta vezquot;. Es importante recalcar que los puntos de unión no son posiciones en el código fuente (ni dentro de una instrucción, ni entre instrucciones), sino en la ejecución del programa.
  21. 21. Aspectos La frase anterior habla de la cuarta invocación de un método en una ejecución, y esto no corresponde a un punto en el código. En distintas ejecuciones podría variar qué instrucción es la que invoca por cuarta vez a Line.getP1(), por ejemplo, se podría llamar a este método dentro de un ciclo while (i<j) Line.getP1(); Dependiendo de los valores de i y j, y de lo que haya pasado antes en esta ejecución, la cuarta llamada a este método podría ser en esta instrucción o en otra.
  22. 22. Aspectos Ahora pasemos a hablar de un concepto un poco más complicado que el de punto de unión, que es el de pointcut. Un pointcut es un predicado, una afirmación que es cumplida por un conjunto de puntos de unión. En nuestro ejemplo de la Figura 3, aparece un pointcut: que vamos a analizar por partes.
  23. 23. Aspectos call(void FigureElement+.set*(..)) significa quot;al invocar (call) cualquier método de la clase FigureElement o de una sublclase (+), cuyo nombre comience con set (set*), que tenga void como tipo de retorno y cualquier cantidad de parámetros (..)quot;.
  24. 24. Aspectos El siguiente fragmento es fácil de comprender: call(void FigureElement.moveBy(int, int)). El operador de disyunción (||) se usa para unir estos dos pointcuts y formar uno nuevo. Los puntos de unión que cumplan el pointcut compuesto serán aquellos que cumplan uno u otro de los dos.
  25. 25. Aspectos Además de call hay otros constructores de pointcuts, como get (al leer el valor de una variable), set (al modificarlo), cflowbelow (dentro del flujo de control), initialization (al inicializar un objeto), etc. Y también formas de acceder al contexto como target (clase que recibe el mensaje), args (argumentos de una llamada), etc.
  26. 26. Aspectos Los pointcuts son parte de un aspecto, indican dónde (en qué puntos de unión) se va a aplicar. La otra parte es lo que se llama un consejo (advice), que indica qué es lo que hay que hacer en esos puntos de unión.
  27. 27. Aspectos En la Figura, el consejo dice que hay que agregar la instrucción Display.Update(); después (after) de cada uno de los puntos de unión indicados por el pointcut. En vez de after, se podría haber puesto before (antes), after returning (después de ejecutar un método en forma normal), after throwing (después de arrojar una excepción) o around (en lugar de ejecutar el punto de unión).
  28. 28. Aspectos El mecanismo por el cual se combinan los aspectos con el código base se llama entretejido (weaving), y puede hacerse en distintos momentos de la vida de un programa. Una posibilidad es llevar a cabo el entretejido en una etapa de precompilación: se toma el código base y los aspectos, y se produce nuevo código fuente con el resultado del entretejido, insertando los consejos en los puntos de unión correspondiente. También se puede hacer durante la compilación, generando código objeto que cumpla la funcionalidad base más la de los aspectos. Y otra alternativa es el llamado entretejido dinámico, por el cual se controla la ejecución del programa y, cada vez que se llega a un punto de unión incluido en un pointcut de un aspecto, se ejecuta el consejo asociado.
  29. 29. Aspectos En este ejemplo tan sencillo que vimos, aparecen ya las dos ideas más poderosas que hay detrás de los aspectos: a) prescindencia (obliviousness) y b) cuantificación (quantification). Ambas están asociadas al mecanismo de construcción de pointcuts. La prescindencia se refiere a que el programador encargado de implementar una funcionalidad específica no debería estar al tanto de las otras dimensiones que pueden afectar su código. La cuantificación es la posibilidad de indicar en qué puntos de unión se aplicará un aspecto, sin necesidad de enumerarlos uno por uno.
  30. 30. Prescindencia y Cuantificación La prescindencia se corresponde con el principio de abstracción y encapsulamiento omnipresente en la ingeniería de software, es básica para poder mantener la separación de asuntos. Si se hiciera necesario que un programador tuviera en cuenta, al escribir su código, cuáles serán los aspectos que se le aplicarán, no estaríamos logrando la separación de asuntos que planteamos como objetivo inicial. Por ejemplo, no podríamos cambiar a qué puntos de unión afectará un aspecto, sin modificar el código base.
  31. 31. Prescindencia y Cuantificación La cuantificación también es esencial al trabajar con aspectos. Recuerden que hablando de asuntos transversales dijimos que cada sistema tenía una política sobre dónde se requería entrelazar un servicio. Como los aspectos pretenden modularizar los asuntos transversales, la política debe hacerse explícita y formar parte del aspecto. En la notación que vimos, la cuantificación está dada por el lenguaje de definición de pointcuts y, en particular, por los comodines (*, +, ..), que permiten referirse de forma genérica un grupo de puntos de unión. Es el equivalente a definir un conjunto por comprensión.
  32. 32. Prescindencia y Cuantificación En algunas supuestas implementaciones de AOP, se requiere que el programador del código base indique de alguna forma en su programa, en cada punto de unión, qué aspectos deben insertarse en ese lugar. Este mecanismo viola tanto la prescindencia como la cuantificación, porque el programador no puede ignorar los aspectos y debe enumerar los puntos de unión.
  33. 33. Prescindencia y Cuantificación Otras implementaciones brindan herramientas para que, por fuera del código, se señale en forma interactiva dónde se espera que se entrelace un aspecto. Este método es más limpio que el anterior desde el punto de vista de la prescindencia, porque la tarea puede llevarse a cabo independientemente de la escritura del programa. Pero comparte con el anterior la violación del principio de cuantificación: la política no se hace explícita ni se modulariza como parte de los aspectos, está dada por las acciones del encargado de marcar a mano los puntos de unión. Incluso si el resultado de esas acciones se almacena en algún formato, los puntos de unión aparecen listados y no definidos por sus propiedades.
  34. 34. Implicaciones en el uso de aspectos El desarrollo de software orientado a aspectos todavía se encuentra en un estado incipiente. La mayoría de las implementaciones es de carácter experimental. La tecnología no ha sido hasta ahora claramente adoptada por la industria, aunque importantes empresas relacionadas con el desarrollo de software están financiando proyectos ambiciosos de AOP.
  35. 35. Implicaciones en el uso de aspectos Una de las razones para la falta de adopción puede encontrarse en la dificultad que introducen los aspectos para razonar sobre los programas. Muchas de las técnicas de diseño y de las buenas prácticas de codificación actuales tienen por objetivo garantizar la composicionalidad del razonamiento sobre programas: no hace falta leer el código entero para entender qué es lo que hace un fragmento, se pueden extraes conclusiones sobre el comportamiento local y esas conclusiones siguen siendo válidas sin importar cómo se inserte el fragmento en un sistema mayor. Pero los aspectos pueden invalidar esta premisa, ya que permiten modificar quot;desde afueraquot; el comportamiento de una parte del programa.
  36. 36. Implicaciones en el uso de aspectos Existen algunas propuestas para solucionar este problema de AOP y proyectos completos de ASoC que constituyen alternativas al enfoque de aspectos, creadas con el objetivo específico de evitar alterar el comportamiento local o de hacerlo en forma predecible. Hasta el momento ninguna de estas variantes ha cobrado la relevancia suficiente como para mover a la comunidad de AOSD en esa dirección.
  37. 37. Implicaciones en el uso de aspectos Otro inconveniente que atenta contra la adopción generalizada de AOP es la reutilizabilidad reducida. El principio de prescindencia garantiza el desacoplamiento en un solo sentido: el código base no depende de los aspectos. Pero las notaciones de cuantificación y acceso al contexto como las que vimos atan los aspectos a una aplicación en particular u obligan al programador a seguir convenciones de codificación, lo cual va en contra de la prescindencia. Esto se debe al uso de comodines basados en el nombre que tienen los identificadores del código base.
  38. 38. Implicaciones en el uso de aspectos Siguiendo el ejemplo de la Figura, los programadores estarían obligados a poner nombres que comenzaran con set a todos los métodos cuya tarea fuera la de cambiar el valor de una propiedad que alterara la presentación en pantalla.
  39. 39. Implicaciones en el uso de aspectos O, alternativamente, haría falta modificar la definición del pointcut para adaptarla a otra convención (por ejemplo, si en una aplicación el nombre de estos métodos comenzara con update).
  40. 40. Contacto: acaceres@computacion.cs.cinvestav.mx abdiel@mazatlan.udo.mx Abdiel E. Cáceres González Centro de Investigación y de Estudios Avanzados - IPN México D.F., México. 2004

×