[marcoszorrilla]

Bueno pues aquí está el artículo, le doy las gracias a un amigo solamente pongo las iniciales O.C.R., aunque veo que algún pequeño desaguisado me ha causado creo que queda bastante legible el texto.

Programación orientada a aspectos (l)
ALVARO ZABALA ORDÓÑEZ
En la presente serie de artículos introduciremos al lector en un nuevo
paradigma de programación que trata de erigirse en el sustituto natural del
paradigma orientado a objetos: la programación orientada a aspectos.

Introducción

Este concepto, la orientación a aspectos, aunque pueda parecer nuevo, fue acuñado ya en el año 1995 ([una eternidad en el mundo de la programación!).

No obstante, está tomando un auge cada vez mayor, como demuestra la existencia del proyecto AspectJ), extensión del lenguaje Java para contemplar la orientación a aspectos, o la aparición de numerosas referencias a este paradigma en publicaciones electrónicas tan prestigiosas como "The Server Side".

En este articulo, primera entrega de la serie, veremos los conceptos básicos de la programación orientada a aspectos y haremos una breve introducción a AspecJ, la principal implementación existente hoy en día de la programación orientada a aspectos. En el próximo número haremos una revisión mas detallada de este producto, que pretende extender el lenguaje Java para que sea un lenguaje de programación orientado a aspectos.


Un poco de historia

A lo largo de la historia de la ingeniería del software, los mayores avances se han producido mediante la aplicación a la resolución de problemas de uno de los viejos preceptos del método cartesiano: la descomposición en partes simples.
En los primeros tiempos de la programación se creaba un código en el que se mezclaban conceptos, apareciendo datos y funciones de forma desperdigada. Este código era muy difícil de entender y de modificar, y por tanto de mantener, Se denominaba código en espagueti.

En la siguiente etapa, con el paradigma estructurado, se aplicó una descomposición del código en funciones, de forma que resultaba mucho
más sencilla su lectura así como la incorporación de nuevas funciones. No obstante, esta aproximación tampoco estaba exenta de inconvenientes. Los datos estaban dispersos por todo el código, por lo que la modificación de una estructura implicaba la modificación de varias funciones.
Además, no existía un nexo de unión entre datos y funciones, constituyendo una abstracción difícil de manejar para las personas, que estamos
mas acostumbradas a pensar en términos de objetos.

Para solventar esto, surgió un nuevo paradigma de programación, que es el paradigma dominante en la actualidad: la programación orientada 3 objetos. Este paradigma se aproxima más a la forma de pensar humana, agrupando datos y
funciones bajo el concepto de objeto, Sin embargo, y pese a que ha supuesto un
importantísimo avance en el campo de la ingeniería del software, la orientación a objetos también presenta un inconveniente: la aparición de código entrecruzado [cross-cutting code}. Éste es un código de funcionalidad común que aparece disperso a lo largo de diferentes clases.

En un desarrollo orientado a objetos, además del diseño e implementación de los requisitos de negocio, específicos de cada proyecto, aparecen requisitos genéricos comunes a todos los proyectos, como comprobación y control de errores, sincronización, optimización de memoria, seguimiento de mensajes, restricciones de tiempo real, etc.

El paradigma orientado a objetos no contempla bien esta multiplicidad de aspectos de programación adicionales a los aspectos de negocio, haciendo que el código que implementa la lógica del negocio aparezca enmarañado por el código encargado de tratar el resto de aspectos, que aparecen diseminados por éste. En la figura 1 se muestra la mezcla de conceptos realizadas por las diferentes metodologías de programación mencionadas.

En ésta, las formas (triángulos, circuitos, etc. representan estructuras de datos y los colores categorías de funciones (asuntos, aspectos). Se puede observar cómo con la orientación a objetos aparecen funciones del mismo aspecto
(mismo color) repartidas por las diferentes estructuras de datos. Esta situación tiene claramente un impacto negativo en la calidad de software, y es a la que trata de dar solución el paradigma de la orientación a Aspectos.

La programación orientada a aspectos: AOP

La programación orientada a aspectos constituye una nueva metodología que trata de ofrecer soluciones para gestionar la separación entre funciones dedicadas a una misma temática o asunto y componentes de software. Para ello, introduce una nueva abstracción que da nombre a la metodología, el aspecto, y proporciona una
serie de mecanismos que permitan componer objetos y aspectos para construir el sistema final. La programación orientada a aspectos es compatible tanto con descomposiciones orientadas a objetos como con descomposiciones
estructuradas, por lo que viene a ser una extensión de ambas metodologías. En la figura 2, que sigue el mismo criterio que la figura anterior para representar estructuras de datos y asuntos o aspectos de programación, se puede ver la
forma en que este nuevo paradigma descompone los sistemas en aspectos.

Concepto de aspecto

Un aspecto es un concepto de programación similar a! de clase, pero a un nivel superior de abstracción. Su finalidad es encapsular aspectos de programación que pueden incumbir a varias clases, pero que serían muy difíciles o imposibles
de separar en una clase independiente. Un sistema modelado según este nuevo paradigma, estaría formado por un conjunto de objetos, que representan la lógica de negocio del sistema, y por una serie de aspectos que reflejan funcionalidades como gestión de memoria, logging, gestión de errores, persistencia, comunicación de procesos, etc.

Puntos de unión y enlazadores

No obstante, esta separación entre aspectos y componentes no es total, ya que debe existir una interacción entre ellos. Esto se realiza a través de los puntos de unión [join points). Los puntos de unión son los lugares, dentro del código de un objeto, en que se puede incrementar la funcionalidad de éste mediante el comportamiento representado por un aspecto. De esta forma, cualquier clase que quiera utilizar la funcionalidad de un aspecto, tan solo tendrá que contener
un punto de unión con éste, consiguiéndose una estructuración más clara y compacta del código.
Además de los puntos de unión, que indican dónde la clase se ve extendida por un aspecto, es necesaria la existencia de un enlazador. El enlazador será el encargado de realizar esta mezcla entre clases y aspectos, ayudándose de los puntos de unión, que le indican el lugar donde se debe realizar la juntura.

Proceso de construcción de un programa orientado a aspectos

El proceso general para aplicar esta metodología

...