<PROGRAMACIÓN ORIENTADA A ASPECTOS/>

La Programación Orientada a Aspectos fue el tema de mi proyecto final de carrera. En lugar de publicar todo el proyecto, que sería demasiado pesado, he creado cuatro pequeños documentos con los capítulos que he considerado fundamentales en mi proyecto. El contenido de cada uno de los apartados no han sido modificado, por lo que deberás entenderlos como las partes de un todo, y no como documentos completos y consistentes. Si estás interesado en leer el proyecto completo, ponte en contacto conmigo en mi dirección de correo (nulain@yahoo.es). Sin embargo, no creo que pueda responder a preguntas, ya que desde que lo escribí, no he vuelto a trabajar con el tema.

Introducción a la POA.pdf 138Kb
AspectJ en la Programación Orientada a Aspectos.pdf 552Kb
HyperJ.pdf 113Kb
Los Aspectos en el diseño.pdf 122Kb

Antes de leer estos documentos quizás quieras hacerte una idea de qué es la Programación Orientada a Aspectos...

La Programación Orientada a Aspectos (POA) es un paradigma de programación relativamente reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a la POA se pueden capturar los diferentes conceptos que componen una aplicación en entidades bien definidas, de manera apropiada en cada uno de los casos y eliminado las dependencias inherentes entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas -como los métodos adaptivos, los filtros de composición, la programación orientada a sujetos o la separación multidimensional de competencias.

Muchas veces nos encontramos, a la hora de programar, con problemas que no podemos resolver de una manera adecuada con las técnicas habituales usadas en la programación procedural o en la orientada a objetos. Con éstas, nos vemos forzados a tomar decisiones de diseño que repercuten de manera importante en el desarrollo de la aplicación y que nos alejan con frecuencia de otras posibilidades. Por otro lado, la implementación de dichas decisiones a menudo implica escribir líneas de código que están distribuidas por toda, o gran parte, de la aplicación para definir la lógica de cierta propiedad o comportamiento del sistema, con las consecuentes dificultades de mantenimiento y desarrollo que ello implica. En inglés este problema se conoce como tangled code, que podríamos traducir como "código enredado". El hecho es que hay ciertas decisiones de diseño que son difíciles de capturar con las técnicas antes citadas, debiéndose al hecho de que ciertos problemas no se dejan encapsular de igual forma que los que habitualmente se han resuelto con funciones u objetos. La resolución de éstos supone o bien la utilización de repetidas líneas de código por diferentes componentes del sistema, o bien la superposición dentro de un componente de funcionalidades dispares. La programación orientada a aspectos, permite, de una manera comprensible y clara, definir nuestras aplicaciones considerando estos problemas. Por aspectos se entiende dichos problemas que afectan a la aplicación de manera horizontal y que la programación orientada a aspectos persigue poder tenerlos de manera aislada de forma adecuada y comprensible, dándonos la posibilidad de poder construir el sistema componiéndolos junto con el resto de componentes.

La programación orientada a objetos (POO) supuso un gran paso en la ingeniería del software, ya que presentaba un modelo de objetos que parecía encajar de manera adecuada con los problemas reales. La cuestión era saber descomponer de la mejor manera el dominio del problema al que nos enfrentáramos, encapsulando cada concepto en lo que se dio en llamar objetos y haciéndoles interactuar entre ellos, habiéndoles dotado de una serie de propiedades. Surgieron así numerosas metodologías para ayudar en tal proceso de descomposición y aparecieron herramientas que incluso automatizaban parte del proceso. Esto no ha cambiado y se sigue haciendo en el proceso de desarrollo del software. Sin embargo, frecuentemente la relación entre la complejidad de la solución y el problema resuelto hace pensar en la necesidad de un nuevo cambio. Así pues, nos encontramos con muchos problemas donde la POO no es suficiente para capturar de una manera clara todas las propiedades y comportamientos de los que queremos dotar a nuestra aplicación. Así mismo, la programación procedural tampoco nos soluciona el problema.

Entre los objetivos que se ha propuesto la POA están, principalmente, el de separar conceptos y el de minimizar las dependencias entre ellos. Con el primer objetivo se persigue que cada decisión se tome en un lugar concreto y no diseminada por la aplicación. Con el segundo, se pretende desacoplar los distintos elementos que intervienen en un programa. Su consecución implicaría las siguientes ventajas:

- Un código menos enmarañado, más natural y más reducido.
- Mayor facilidad para razonar sobre los conceptos, ya que están separados y las dependencias entre ellos son mínimas.
- Un código más fácil de depurar y más fácil de mantener.
- Se consigue que un conjunto grande de modificaciones en la definición de una materia tenga un impacto mínimo en las otras.
- Se tiene un código más reusable y que se puede acoplar y desacoplar cuando sea necesario.

 

<Publicaciones/>

Basado en la experiencia de mi proyecto y el trabajo de investigación de Antonia Reina (mi tutora de proyecto) se presentó en las VIII Jornadas de Ingeniería del Software y Bases de Datos (JISBD) celebradas en Alicante en Noviembre de 2003 un trabajo sobre reutilización de aspectos, donde entre otras cosas, se plantea la necesidad de hacer una clasificación de aspectos según su utilidad (aspectos de rendimiento, útiles al desarrollo, etc) o las fases del ciclo de vida donde han de ser identificados (fase de requisitos, etc.). Se plantea que sería interesante hacer una caracterización de los aspectos más frecuentes para facilitar su identificación en diversas aplicaciones y promover su reutilización. En general en las jornadas se planteó una discusión sobre la dificultad de identificar aspectos, y del peligro de considerar qué casi todo se modele como aspectos, algo calificado por Miguel Pessoa Monteiro como el peligro de caer en el “aspect esquizofrenia”.

Una experiencia práctica reutilizando aspectos, 84Kb (A. M. Reina, J. Torres, M. Toro, J. A. Álvarez, and Juan M. Nieto)

---

<LINKS/>

El sitio de AspectJ: www.aspectj.org
La página de Gregor Kiczales: www2.parc.com/csl/members/gregor/
La página de Mira Mezini: www.informatik.uni-siegen.de/~mira/
La página de Cristina Videira Lopes: www.ics.uci.edu/~lopes/
Página de Karl Lieberherr: www.ccs.neu.edu/home/lieber/
Página del grupo Demeter: www.ccs.neu.edu/research/demeter/
Sitio para el Desarrollo de Software Orientado a Aspectos: www.aosd.net
Sitio que reúne varios links sobre la POA: www.iturls.com/english/techhotspot/TH_e.asp
Sitio en Español sobre Aspectos y AspectJ: www.programemos.com

<back to the main page/>