Programación Orientada a Aspectos

[marcoszorrilla]

Una conocida Revista de Informática, que a juzgar por su título no es apta para los no programadores, publica un interesante artículo Programación Orientada a Aspectos (I)


- Un aspecto es un concepto de programación similar al de clase, pero un nivel superior de abstracción.

- En AOP (Aspect Oriented Programming) se alcanza una mayor modularidad agrupando el código entrecruzado en aspectos.


- El principal beneficio que impulsó la creación de esta metodología, es el de evitar la presencia de código entrecruzado....


Esto no es más que un brevísimo resumen.

Bueno a ver si os animais y escribis algo al respecto.


Un Saludo.

[roman]

Esteee, bueno, es que decir que un aspecto es más abstracto que una clase no es decir mucho.

:confused:

¿No podrías poner el enlace al artículo?

// Saludos

[marcoszorrilla]

Pues no porque se trata de la Revista "Solo programadores nº-111", que estado leyendo este fin de semana y viene un interesante artículo de 5 páginas.

Aquí voy a poner un enlace que viene en la revista pero no se trata de este artículo sino "AspectJ" ya que en un principio parece ser que se aplicará fundamentalmente al Java.

http://eclipse.org/aspectj/

Un Saludo.

[santana]

Hola.

Hace un par de días que estuve mirando por la Red al respecto (también yo tengo la susodicha revista....). Os dejo un par de enlaces para quien no haya leido nada todavia sobre AOP y sobre AspectJ

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=aspectj

http://webepcc.unex.es/juan/jisbd03/tutorial/

Mi opinión aun no la puedo dejar porque no he tenido tiempo de investigarlo a fondo.

Saludos !!

[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
...

[marcoszorrilla]

...

en la construcción de un programa sería el siguiente:

• En primer lugar, se construye una clase o componente mediante el empleo de un lenguaje de propósito general, del tipo de Java, C#, etc. en el que se modelan los atributos y funciones de negocio de la clase.

• Seguidamente, se construyen tantos aspectos como sean necesarios, mediante el empleo de un lenguaje de aspectos. Los lenguajes de aspectos permiten representar conceptos específicos de esta metodología de programación, como los puntos de unión, y pueden ser específicos o de propósito general. Un ejemplo de lenguaje de aspectos de propósito general es AspectJ, extensión de Java para programar con aspectos. También existen lenguajes de aspectos específicos, que sólo permiten crear un tipo de aspecto determinado. Tal es el caso del lenguaje COOL, desarrollado por Xerox cuya finalidad es el control de concurrencia en aplicaciones multitarea. Recientemente, incluso el excelente servidor de aplicaciones de carácter libre JBoss ha incluido una extensión para soportar programación orientada a aspectos. Esta extensión se basa en los mismos conceptos que AspecJ: pointcuts, advices, interceptors, introductions, etc.


La descomposición en aspectos que ofrece la programación orientada a aspectos
puede representarse Tróficamente como en la figura, Un aspecto es un concepto
de programación similar al de clase, pero a un nivel superior de abstracción
El lector podrá encontrar en el CD-ROM el Aspecto la principal implementación
de la programación orientada a aspectos.

En OOP se entremezcla código de negocio con código de soporte (errores, logging,
seguridad, etc.)

Por ultimo, hay que enlazar clases y aspectos, para construir una unidad compacta. Este proceso es realizado por el enlazador tal y como hemos comentado anteriormente.

Como paso previo al enlazado, hay que compilar las diferentes clases y aspectos en función de los lenguajes y enlazadores utilizados.
En principio, tanto clases como aspectos pueden escribirse con diferentes lenguajes.

El proceso de enlazado

El enlazado entre clases y aspectos para constituir un todo se puede realizar de dos formas distintas: estática y dinámica.

El enlazado estático implica la modificación del código fuente de una clase, mediante la inserción en sus puntos de unión de sentencias que permitan cubrir la funcionalidad representada
por el aspecto referenciado. Un ejemplo de enlazadores que trabajan de esta manera es el preprocesador de aspectos de AspecJ.

La principal ventaja de esta forma de enlazado es que no afecta al rendimiento del código ejecutable generado. La estructuración en aspectos pasa a ser un recurso para incrementar la legibilidad del código concentrando todas las sentencias de una determinada lógica bajo un mismo aspecto. Sin embargo, a la hora de ejecutar la aplicación, el enlazador genera los mismos archivos binarios que si hubiéramos empleado el paradigma orientado a objetos convencional.

El principal inconveniente de esta forma de trabajar es el hecho de que una vez enlazadas clases y aspectos, se pierde cualquier conocimiento sobre los aspectos puestos en juego, ya que estos han pasado a confundirse dentro del código de
las clases. Esto haría que la ligadura dinámica o el polimorfismo entre aspectos fuesen altamente ineficientes, por no decir imposibles de conseguir.
El enlazado dinámico, como se puede deducir fácilmente de su nombre, implica la ligadura entre clases y aspectos en tiempo de ejecución.
Esto implica que debe existir un conocimiento explícito de los aspectos, tanto en los procesos de compilación como de ejecución. Existen diferentes estrategias para alcanzar este fin, aunque la mayoría pasan por la composición de clases y
objetos en tiempo de ejecución.

Los aspectos en el diseño

Hasta este momento sólo nos hemos centrado en la influencia que tiene el paradigma orientado a aspectos sobre la fase de codificación, permitiendo un mayor grado de reutilización del código y una mayor legibilidad del mismo. No obstante, la orientación a aspectos también se puede llevar a fases anteriores, de forma que los aspectos pasen a ser considerados como soluciones de diseño. Esto permite realizar diseños con un mayor grado de abstracción, en el que interfaces y aspectos garanticen un mayor grado de independencia de las clases desarrolladas.

Para ello, es necesario incluir en el lenguaje UML elementos para representar aspectos (considerándolos como abstracciones del mismo nivel que las clases y las interfaces), asociaciones de generalización entre clases y aspectos (herencia de aspecto) y clases enlazadas con aspectos.

El siguiente paso natural sería la aparición de patrones de diseño de programación orientada a aspectos. En el cuadro "Enlaces de interés" podemos encontrar referencias a trabajos que tratan sobre este tema.

Beneficios adicionales de la orientación a aspectos Llegados a este punto, y antes de seguir profundizando en las características de la programación orientada a aspectos, ya nos encontramos en circunstancias de apuntar algunos de los beneficios de esta nueva metodología:

•El principal beneficio, que impulsó la creación de esta metodología, es el de evitar la presencia de código entrecruzado. La orientación a aspectos agrupa toda la funcionalidad que persigue un mismo fin bajo un mismo aspecto, obteniéndose implementaciones altamente modulares, aumentándose la cohesión y
reduciéndose el acoplamiento entre los módulos de código del sistema.

• Una consecuencia derivada es que se obtienen sistemas más fáciles de extender. Puesto que los aspectos están libres de código entrecruzado, cada vez que queramos extender la funcionalidad del sistema tan solo tendremos que crear nuevos aspectos, y asegurarnos de que se produce el enlazado con las clases a las que afecten durante la fase de compilación.

• Permite posponer algunas decisiones de diseño. Durante la fase de diseño, el analista se puede encontrar con dilemas que le obliguen a tomar decisiones sobre las que no se encuentra totalmente seguro. Por medio de la orientación a aspectos, estas decisiones se pueden retrasar hasta que lleguen nuevos
requerimientos que justifiquen la toma de estas decisiones. Hasta que llegue ese
momento, puede utilizar aspectos para modelar aquellos puntos de mayor incertidumbre.
Mayor reutilización del código. Puesto que los desarrollos con aspectos tienen una mayor medularidad, y están menos acoplados, resulta más fácil su reutilización, reduciéndose el número de líneas de código que forman el sistema.

Una implementación orientada a aspectos:

Aspectj


...

[__cadetill]

...le doy las gracias a un amigo solamente pongo las iniciales O.C.R., ...
Esta vez sí que lo he entendido :D :p

Referente al artículo,..... si ya me cuesta la OOP, sólo me faltaba la OAP :s
Pero bueno, el tema parece interesante, voy a ver si encuentro algo por los interneses......

[__cadetill]

Bueno, he encontrado un documento en PDF de la Universidad de Sevilla de 42 páginas donde explica bastante bien el tema.

Aquí os dejo el enlace http://www.lsi.us.es/~informes/aopv3.pdf

En el último punto del documento encontrareis más referencias al respecto

Sigo sin poder dar mi opinión al respecto, todabía no lo veo demasiado claro el tema :p

[Julián]

Jau!
¿hasta que punto es arriesgado poner un artículo escaneado de una revista?
¿podrían enfadarse y denunciar por ello?
¿sería mejor poner el artículo en otro sitio y aquí sólo un enlace?

De toas maneras, el artículo en cuestión es un rollazo insoportable.

¡saludos!

[roman]

Dejaré para el fin de semana la lectura detenida y quizá hasta le eche un ojo a las 42 páginas de cadetill. Pero, 'a ojo de buen cubero', no me parece nada que aporte algo nuevo sino que más bien da la impresión de ponerle un nombre pomposo a lo que todos debiéramos hacer: programar bien. Frases como


En OOP se entremezcla código de negocio con código de soporte


me parecen falacias. Si el código 'de negocios' -- horrible nombre por cierto -- se mezcla con 'código de soporte' es porque no diseñamos correctamene nuestras clases.

Ya se ha comentado en estos foros anteriormente acerca de la separación de los objetos de negocio de la interfaz de usuario por ejemplo. Lograr una separación así puede hacerse tan sólo con una programación orientada a objetos bien planificada.

En fin, quizá es que no he entendido 'ni pío' pero a leeré con más calma.

// Saludos

[marcoszorrilla]

•El principal beneficio, que impulsó la creación de esta metodología, es el de evitar la presencia de código entrecruzado. La orientación a aspectos agrupa toda la funcionalidad que persigue un mismo fin bajo un mismo aspecto, obteniéndose implementaciones altamente modulares, aumentándose la cohesión y reduciéndose el acoplamiento entre los módulos de código del sistema.

• Una consecuencia derivada es que se obtienen sistemas más fáciles de extender. Puesto que los aspectos están libres de código entrecruzado, cada vez que queramos extender la funcionalidad del sistema tan solo tendremos que crear nuevos aspectos, y asegurarnos de que se produce el enlazado con las clases a las que afecten durante la fase de compilación.

Par mi entender esto que señalo es lo más importante.

Un Saludo.

[marcoszorrilla]

De toas maneras, el artículo en cuestión es un rollazo insoportable.

Julián acabo de escribir a Bayern, para ver si me dejan escanear una caja de aspirinas.

Que conste que me quedaban todavía 3 páginas de pegar, pero desistí, porque preví que el articulito en cuestión no iba a tener mucho éxito.

Un Saludo.

A ver si sale algo sobre LOP (Lazy Oriented Programming) eso si que estaría bueno que nos haga el programa otro y nosotros a cobrar.

[marto]

De toas maneras, el artículo en cuestión es un rollazo insoportable
... Pues a mi me ha gustado


Lograr una separación así puede hacerse tan sólo con una programación orientada a objetos bien planificada.
De hecho, se puede conseguir con programación estructurada. Las nuevas metodologías no acostumbran a conseguir que se pueda hacer algo que antes no se podía. Con OO consigues hacer lo mismo de manera más fácil, es más fácil que la cosa quede bonita y mantenible, pero no es la única manera de hacerlo. Yo he visto propgramas en clipper impresionantes y muy bien estructurados. Sin conocer la PO[LL]A :D , cabe esperar que su buen uso consiga que aun sea más facil conseguir proyectos con cara y ojos.


A ver si sale algo sobre LOP (Lazy Oriented Programming) eso si que estaría bueno que nos haga el programa otro y nosotros a cobrar.

Esa mi jefe la invento hace tiempo...

[Julián]

dice Roman:

... más bien da la impresión de ponerle un nombre pomposo a lo que todos debiéramos hacer: programar bien.

Y yo opino lo mismo.

¡Saludos!

[Al González]

¡Hola a todos!

Hubiese sido magnífico que el autor escribiese en un lenguaje claro a qué se refiere con código entrecruzado (¿repetido?), y expusiera un ejemplo sencillo de eso.

Algo me dice que mis teorías de la Programación Orientada a Cero (http://groups.msn.com/ce77cj5fut58ai6vahamsb3nb1/poc.msnw) y Herencia Insertada (Delphi.com.ar me comprende en éste último aspecto), de alguna manera se entrecruzan ;) con la POA.

De cualquier forma sugiero darle a dicha metodología el beneficio de la duda. Analicemos su practicidad real, haciendo a un lado las frases "pomposas" como "paradigma de abastracción cósmica cabalística del parteaguas conceptual de la ingeniería de software".

Estoy seguro que algo bueno tiene.

Un abrazo.

Al González :).

[PepeLolo]

To este toston, me recuerda muy mucho a algo que desarrolle en clipper en 1990 que consistia en programación algo así como DataDriver, alguien lo llamo de ese modo o lo llamaban no se :confused:

Toda el código fuera del programa. Toda la programación estaba en tablas y en ficheros de texto (formato binario). en el cliente para que este no pudiera tocarlo.

Solo unas cuantas funciones para mostrar componer el menú, otro que contenia las pantallas y otras cuantas para la nevagación.

Creo que el árticulo se refiere a eso. Menudo invento de los año 95. ;)

Saludos

[delphi.com.ar]

M$ ya esta pensando en arruinar esta teoría :D : http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art152.asp


Saludos!

[Dhampir]

Cuando se habla de orientado a aspectos, se tiende a pensar que será un reemplazo de la programación orientada a objetos, en realiad no es así, pues los paradigmas que se han estudiado y desglosado de OO son esenciales para continuar con la POA, pero tampoco se debe entender como una extensión del OO, ya que lo que se hace con OA es corregir unas dislexias en la estrcutura de la OO, como en el manejo de datos continuos y similares.
Esta es la opinion de una amigo ke ha investigado mas enl la materia :rolleyes: