viernes diciembre 30, 2005
viernes diciembre 30, 2005
¿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:
- Utilizar conjuntamente programación orientada a objetos y a aspectos para desarrollar un sistema software.
- 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]