Join Point

Nuevo artículo en AOP@Work: Rompiendo mitos

  El 14 de febrero los "enamorados" de la Programación Orientada a Aspectos recibimos otro regalo de manos de Ramnivas Laddad. Laddad es un nombre bien conocido en los círculos de la AOP, autor de AspectJ in Action, un gran libro, y ponente en la mayoría de los "saraos" relacionados con Java, como muestra, su magnifica conferencia Practical AOP en JavaPolis 2005

  Y es que parece que 2006, y esta vez sí, va a ser el año de la AOP. Desgraciadamente, se lleva mucho tiempo hablando de ella y se ha convertido en tema "hype". Realidades como las de Spring, JBoss, y artículos como AOP myths and realities - Beyond hype and misunderstandings pueden ayudar a ver la AOP como una solución factible y no como un tema más de los debates sin sentido tan habituales en el mundo informático y la presa del corazón.

  El artículo, que ocupa impreso unas 15 páginas A4, trata de desmontar 15 mitos habituales de la AOP. A continuación comentaré muy brevemente mi primera impresión sobre ellos.

Mito 1: AOP es buena solamente para trazas y logs

Realidad: AOP es idónea para muchas otras preocupaciones transversales (crosscutting concers)

Como dice el artículo, son los ejemplos clásicos que aparecen siempre, son el "hola mundo" de la AOP. Ambos problemas son padecidos por cualquier programador y sirven de forma estupenda para mostrar el potencial y la problemática que intenta solucionar la AOP.

Mito 2: AOP no resuelve ningún problema nuevo

Realidad: Es cierto, no lo hace

¿Que problemas resuelve la OOP frente a la programación estructurada?. El objetivo de la AOP es mejorar la modularidad del software, y por tanto, mejorar la reutilización, la evolución y dinamicidad de los sistemas software, y un largo etcétera.

Resumiendo, se puede decir que la "revolución" que plantea la Programación Orientada a Aspectos, es en el cómo solucionar los problemas. Además, considero que con este paradigma por fin se puede tratar los requisitos no funcionales a la altura que merecen y que es necesaria para que nuestra Ingeniería de Software sea algo real.

Mito 3: Interfaces bien diseñadas no hacen necesaria la AOP

Realidad: Las buenas interfaces son estupendas, pero no reemplazan a los aspectos

Pues si, un buen diseño de las interfaces esta muy bien, pero no sustituye las ventajas/necesidad de usar aspectos.

Mito 4: Los patrones de diseño hacen innecesaria la AOP

Realidad: Los patrones de diseño pueden introducir complejidad no existente en AOP

Muchas veces he oído comentar que lo que hace la AOP podría solucionarse con un par de patrones (mediator, visitor, etc, etc). Primero, no estoy de acuerdo, y segundo, lo que sale es un churro tremendamente complejo. En el imperio de los POJO soluciones como AOP e IoC se imponen a complejos patrones que necesitan de infinitas clases auxiliares e interfaces.

El artículo hace una crítica muy bien fundamentada del abuso del patrón Chain of Responsability (CoR) para solucionar problemas propios de la AOP. Recomendable leer todo el punto de artículo con los ejemplos para comprender mejor el potencial de la AOP en los problemas cotidianos.

Mito 5: Los proxies dinámicos hacen innecesaria la AOP

Realidad: AOP proporciona una solución más simple que los proxies dinámicos

Cuando leí el título de este punto me sorprendió. Lo que Laddad trata de decir es que usar los proxies dinámicos directamente es una mala solución. Sin embargo, hay que recordar que los proxies dinámicos son utilizados por numerosos frameworks AOP y es que hasta donde yo sé es de las únicas formas de tener AOP verdaderamente en tiempo de ejecución. Si alguien conoce más alternativas me gustaría saberlas.

Mito 6: Los frameworks de aplicación (application frameworks) hacen innecesaria la AOP

Realidad: Los frameworks introducen limitaciones no existentes en AOP

Frameworks de aplicación, como EJB, tienen una curva de aprendizaje muy elevada, sin embargo, en AOP hay muy pocos conceptos y una vez que les dominas no tienes limitaciones de ningún tipo. Si bien es cierto, que los servicios los tienes que implementar tu

Mito 7: Las anotaciones hacen innecesaria la AOP

Realidad: Anotaciones y AOP son altamente complementarias

Realmente las anotaciones van a incrementar el uso de AOP. Uno de los problemas que había para la adopción de la AOP es que necesitábamos un nuevo lenguaje. Las anotaciones y la definición de aspectos mediante XML dará menos miedo a la hora de apostar por la AOP. Además los programadores, en un futuro no muy lejano, nos vamos a tener que acostumbrar a tener muchas arrobas en nuestro código.

Yo personalmente prefiero las definiciones en XML, aunque luego sea un infierno, pero es la mejor forma de sacar esas definiciones fuera del código.

Mito 8: Los aspectos oscurecen el flujo del programa

Realidad: AOP aumenta el nivel de abstracción

La verdad es que este mito tiene parte de verdad y es que a medida que vamos añadiendo abstracción y alteramos el flujo normal del sistema, perdemos un poco la trazabilidad de la ejecución. Lo mismo pasa cuando usamos IoC y otras muchas cosas pero también es cierto que ganamos modularidad y otras cosas. Al final compensa.

Mito 9: Depurar con aspectos es duro

Realidad: AOP simplifica la depuración de la funcionalidad transversal

Al hilo del mito anterior, es cierto que en algún momento pueda parecer más difícil ya que añadimos capas pero es que la propia depuración es una preocupación transversal que puede ser tratada por la AOP como la tarea de realizar logs.

La AOP es en si misma una herramienta para facilitar la depuración. Incluso es el pilar para los sistemas software capaces de "autocurarse".

Mito 10: Los aspectos pueden romperse si las clases evolucionan

Realidad: Aspectos escritos pobremente puede romperse si las clases evolucionan

Pues es evidente que si la definición de aspectos no es la más adecuada, cuando modifiquemos las clases se va a ver alterada. El artículo ofrece algunas pistas para minimizar ese riesgo. Lo mejor de todo: hacer PRUEBAS!.

Mito 11: Los aspectos no pueden ser unidades testeables

Realidad: Los aspectos pueden ser unidades testeables tan fácilmente como las clases

Nada más alejado de la realidad, AOP es un mecanismo potentísimo para hacer pruebas y no tiene grandes problemas para ser sometido a ellas.

Como comentaba en una entrada anterior, existen herramientas de pruebas, al estilo JUnit, específicas para AOP como aUnit, artículos como Unit test your aspects, ...
Para más información ver http://www.csc.ncsu.edu/faculty/xie/aoptv.html

Mito 12: Las implementaciones de AOP no requieren un nuevo lenguaje

Realidad: Todas las implementaciones de AOP usan un nuevo lenguaje

Como comentaba unas líneas más arriba yo creo que el uso de anotaciones se va a terminar imponiendo aunque personalmente soy bastante más partidario de las definiciones en XML. Pero bueno, ya se verá. Lo que es cierto es que esto no puede ser utilizado como excusa.

Mito 13: AOP es simplemente demasiado compleja

Realidad: Si, pero aún más simple que las alternativas

El título lo dice todo .

Mito 14: AOP promueve diseño descuidado

Realidad: Se necesita experiencia para usar cualquier tecnología óptimamente

Ciertamente se puede hacer un mal uso de la AOP. Todavía es necesario un mayor rodaje de la AOP y sobre todo de los profesionales que la utilizan. Lo mismo sucedió en su tiempo con el paradigma de la Programación Orientada a Objetos.

Mito 15: La adopción de AOP es todo o nada

Realidad: AOP puede ser adoptado incrementalmente

Es algo que vengo comentando desde siempre. Hay muchas formas de usar AOP, lo importante es ir incorporándolo poco a poco en nuestro software y cada vez de forma más explícita. Valga esta última frase como conclusión de esta entrada.

Posted at 05:52PM feb 18, 2006 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[1]

Librería de aspectos con AspectJ 5

Hace menos de un mes se publico el interesantísimo artículo Check out library aspects with AspectJ 5 en la serie de artículos sobre AOP de developerWorks: AOP@Work. Este artículo, escrito por Wes Isberg, ofrece una visión muy clara de las distintas posibilidades que nos ofrece usar AOP.

En entradas anteriores he comentado mi cierto escepticismo por el uso real de AOP/AOSD tal cual. Sigo pensando que la gran implantación se centrará en servidores de aplicaciones, contenedores de servicios, frameworks, etc. Mientras que a corto plazo veo muy difícil que un ingeniero desde el análisis tenga en mente los aspectos.

El artículo se posiciona en el no tan cómodo término medio. Usar aspectos de forma consciente para ciertas tareas. Si atendemos a las cifras de descargas de AspectJ Development Tools (AJDT), un interfaz gráfico para AOP que se integra perfectamente en Eclipse, como comenta Ron Bodkin en su blog, esto no es en absoluto descabellado.

Además del artículo en si, su código fuente nos ofrece una colección de ejemplos, siempre bienvenida para los que nos iniciamos en el uso de AspectJ 5.

Recomiendo encarecidamente la lectura de este articulo que intenta ser ameno, a la par que educativo y práctico. Y por supuesto, recomiendo empezar a desarrollar nuestras propias librerías (bibliotecas) de aspectos, y a compartirlas con los demás. Utilizar aspectos puede ser MUY PRÁCTICO en infinidad de casos,

Una vez más, y no me cansaré de repetirlo, animar a la gente que lea esto, a escribir algún comentario y poder intercambiar impresiones. De todas formas, amigo lector, gracias por invertir tu tiempo con esto.

Posted at 01:13PM feb 05, 2006 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]

¿Esta lista la Programación Orientada a Aspectos?

Después de haber estado durante todo este año, que ya se nos acaba, "evangelizando" sobre la AOP no tengo intención de retractarme, más aún cuando parece que los "visionarios" de M$ se están interesando por el tema . Sin embargo, considero que existen todavía algunas lagunas en este campo.

Hay diferentes formas de usar AOP pero creo que se puede distinguir dos tendencias:

1. Utilizar conjuntamente programación orientada a objetos y a aspectos para desarrollar un sistema software.
   
   
2. Utilizar programación orientada a objetos como hasta ahora junto con otros elementos como: frameworks (persistencia, loggin, pruebas) contenedores de aplicaciones (Jboss), contenedores ligeros (Spring), metaprogramación,... que actúen usando el paradigma AOP.

El enfoque con el que se parte en estas dos tendencias es tan diferente como su grado de implantación. Mientras que la informática práctica esta apostando por la segunda tendencia, los más teóricos, lógicamente, siguen con la primera, a la que nos referiremos desde ahora.

Superado el razonable miedo inicial a las nuevas siglas, últimamente omnipresentes, y empezando a ver los primeros resultados, por ejemplo en Spring o en JBoss, sería interesante empezar a desarrollar software con el paradigma AOP en la cabeza. Bueno, pues... ¡todos a seguir la primera tendencia!, ¿o no?. Veamos una situación ficticia... pero podría suceder.

"Yo trabajo en la empresa X, seguro que a alguno le suena esa empresa, y quiero hacer mi aplicación usando AOP porque soy un tío que ha leído mucho, que apuesto por innovar y que quiero lo mejor para mi empresa. Además tengo en mente reutilizar gran parte de esa aplicación para otro proyecto y no quiero comerme los marrones después. Pero estoy mosqueado porque el otro día vino un compañero y me dijo que no estaba conforme con lo que plantea la AOP. Ese ca... que no sabe nada, lo más seguro es que tenga envidia o no ame tanto a la empresa como yo. Como soy persona razonable, le estuve argumentando que mejoraba la modularidad, que permitía la separación de preocupaciones (SoC) lo que nos iba a mejorar la reutilización, ese gran palabro, e incluso la reconfiguración dinámica."

Sin duda alguna, nuestro amigo y gran profesional al poco tiempo en el proyecto, lamentaría la decisión. No hay que mal interpretar esto, AOP es buena, tan buena como la SoC, la modularidad, y todas esas cosas. Y es más, me atrevería a decir que la AOP es lo suficientemente madura como para trabajar con ella pero a no ser que hagamos software artesano de momento la cosa esta verde.

Esta verde porque le falta integrarse en los métodos ingenieriles de desarrollo software. Realmente el problema viene dado en gran medida porque la AOP trata los requisitos no funcionales del sistema como elementos a modelar y que luego tendrán su reflejo en uno o más artefactos llamados aspectos. En mi opinión, a los requisitos no funcionales desde el punto de vista de la ingeniería del software no se les ha dado la importancia que merecen.

Sintentizando un poco, considero que antes de plantearnos utilizar la AOP de forma conjunta con la OOP deberían resolverse los siguientes puntos, algunos de ellos vinculados entre si:

• Delimitar perfectamente lo que es requisito funcional y no funcional (-ilities, etc). Si, ya, si todos lo sabemos, ¡pero que listos somos! .
  
  
• Adecuar los métodos de la ingeniería del software, desde la captura de requisitos hasta la codificación. Bueno, a lo que representa la AOP también se la llama AOSD por algo . Ver Survey of Aspect-Oriented Analysis and Design Approaches
  
  
• Establecer pautas de modularidad de los aspectos. La AOP hace el código funcional más modular pero hay que tener cuidado con el acoplamiento y la cohesión de los aspectos. No existe una forma más o menos formal para determinar si una preocupación (concern) se traduce en uno o varios aspectos. Los aspectos, incluso de preocupaciones distintas, pueden tener "interferencias".
  
  
• Proporcionar una visión más abstracta de la AOP. Los lenguajes de aspectos actuales como AspectJ son demasiado "de bajo nivel".
  
  
• Falta de elementos de representación y notación como en UML. Existen numerosas propuestas pero ninguna definitiva.
  
  
• Herramienta de pruebas, al estilo JUnit, específicas para AOP. Actualmente hay en desarrollo varias propuestas como aUnit. Hay un artículo bastante interesante en http://www-128.ibm.com/developerworks/java/library/j-aopwork11 y enlaces de interés en http://www.csc.ncsu.edu/faculty/xie/aoptv.html

Se habrán quedado muchas cosas en el tintero y probablemente sobrarán otras tantas pero por ahora solamente os invitaré a que disfrutéis de las nuevas posibilidades de la AOP de la mano de AspectJ 5 y AJDT.

Posted at 09:00PM dic 30, 2005 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]

AspectJ 5: Un nuevo pasito en la AOP

Algunos afirman que el día de hoy entrará en la historia de la Programación Orientada a Aspectos. Esta afirmación puede parecer un tanto excesiva sobre todo porque, aunque parece algo novedoso, este paradigma ya tiene un tiempo. Sin embargo, esta release tiene gran trascendencia.

AspectJ es el framework-herramienta AOP estándar de facto. Sin ánimo de comparar la velocidad con el tocino , no sería descabellado decir que es el Struts de hace unos años. Pero AspectJ no esta solo, hay más jugadores compitiendo por hacerse un hueco en este mundillo. Hay dos artículos muy interesantes: AOP tools comparison (1) (2) a este respecto. Resumiendo muy brevemente podríamos decir que los jugadores son: AspectJ, AspectWerkz, JBoss AOP, Spring AOP y algunos otros como el proyecto JAC (actualmente dentro de JACQUARD).

AspectWerkz 2.0 es, o mejor dicho, era una herramienta magnífica con unas grandes capacidades, especialmente en LTW y definición de aspectos mediante XML. Este proyecto, bajo el paraguas de BEA, afortunadamente se ha fusionado con en el proyecto AspectJ. Algo parecido sucede con Spring AOP donde la integración con AspectJ es prácticamente un hecho.

Supongo que esta clara la posición de AspectJ en el mundo AOP, pero ¿qué tiene de especial esta realease?. Pues "simplemente" que es el paso de la prehistoria al presente. Algunas de las novedades son las siguientes:

• Soporte completo para Java 5 (generics, autoboxing y unboxing,...)
• Integración con anotaciones
• Definición de aspectos mediante XML
• Entretejido en tiempo de carga LTW
• Nueva API para la reflexión
• ...

Dejaré para otro día con más tiempo un análisis más detallado. Pero si me gustaría terminar con una llamada de atención. En mi muy modesta opinión, básicamente las grandes bazas de la AOP son la SoC, es decir, la mejora de la modularidad, y la posibilidad de tener sistemas dinámicos en los que los aspectos puedan añadirse, eliminar,... En esto último todavía hace falta mucho trabajo puesto que el uso de proxies dinámicos no es flexible ni satisfactorio y el uso de instrumentación del bytecode (JVMTI) tiene grandes limitaciones. Tal vez los próximos avances en la AOP deberían centrarse en la JVM como parece que se esta intentando hacer con JRockit. ¿Donará BEA JRockit a Harmony?. Nos aguarda un futuro interesante .

Posted at 09:40PM dic 20, 2005 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[0]