Programacion Orientado A Aspectos

CONTENIDOS

INTRODUCCION ----------------------------------------------------------------------------- III

¿NECESITAMOS ASPECTOS?------------------------------------------------------------ IV

HISTORIA----------------------------------------------------------------------------------------- V

UN PROCESADOR DE IMÁGENES------------------------------------------------------- VI

DEFINICION DEL PROBLEMA------------------------------------------------------------- VII

OPTIMIZANDO LA MEMORIA--------------------------------------------------------------- IX

COMO SE ENTRELAZA EL CODIGO----------------------------------------------------- XI

COMO HACERLO CON POA----------------------------------------------------------------XIV

EL LENGUAJE DE COMPONENTES----------------------------------------------------- XV

EL LENGUAJE DE ASPECTOS------------------------------------------------------------ XV

PROCESO DE ENTRELAZADO------------------------------------------------------------XVI

RESULTADO FINAL------------------------------------------------------------------------- XVIII

CONCLUSIONES------------------------------------------------------------------------------- XX

RECOMENDACIONES------------------------------------------------------------------------XXI

BIBLIOGRAFIA-------------------------------------------------------------------------------- XXII

INTRODUCCIÓN

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

¿NECESITAMOS ASPECTOS?

En muchas situaciones la programación orientada a objetos deja de ser útil y se convierte en un proceso insostenible. Por un lado, hay modelos orientados a objetos que están muy especializados en un determinado dominio de problemas y que no son convenientes para los demás. También hay cuestiones a resolver que no están vinculadas con ningún problema en particular, sino que nos las encontramos por toda la aplicación, afectando a gran parte de ella y que nos obligan a escribir el mismo código por muchos sitios diferentes para poder solucionarlas. Este es el código que hace que nuestra aplicación orientada a objetos bien diseñada vaya siendo cada vez menos legible y delicada.

Por otro lado, están las interfaces de los objetos, clara debilidad en la evolución de los mismos, ya que deben ser definidas desde el principio. Mientras las necesidades del problema no cambien, el diseño con interfaces funciona bien. Pero eso no es lo habitual, sino que los negocios cambian, lo hace el dominio o bien aparecen nuevas necesidades. En tal caso, hay que cambiar las interfaces y ello supone también cambiar mucho código en todas las clases que las implementan.

Para realizar tales cambios, el programador se ve obligado a analizar detalladamente la implementación actual, navegando por las diferentes clases para obtener una visión global del problema al que se enfrenta.

Veremos en el ejemplo que acompaña a este documento en qué pueden ayudarnos los aspectos y si ciertamente la orientación a aspectos traerá tantos beneficios como los más optimistas auguran.

HISTORIA

Muchos observan la programación orientada a aspectos como el siguiente paso en la evolución de la ingeniería del software e intentan hacer ver como ésta supondrá, como lo hizo en su momento la POO, un cambio importante en el diseño de aplicaciones. No obstante, recordemos que fue sobre 1960 cuando apareció la primera implementación usable de los conceptos de orientación a objetos con el lenguaje Simula-68, mientras que no fue hasta 1980, veinte años después, cuando de verás se empezaron a usar de manera comercial en proyectos reales, dichas técnicas, es decir, con mucho dinero por medio. Fue entonces el boom de las telecomunicaciones y el crecimiento de C++ frente a C y

COBOL.

El concepto de POA fue introducido por Gregor Kiczales [3] y su grupo, aunque el equipo Demeter [3] había estado utilizando ideas orientadas a aspectos antes incluso de que se acuñara el término. El trabajo del grupo Demeter estaba centrado en la programación adaptiva, que puede verse como una instancia temprana de la POA. Dicha metodología de programación se introdujo alrededor de 1991. Consiste en dividir los programas en varios bloques de cortes. Inicialmente, se separaban la representación de los objetos del sistema de cortes; luego se añadieron comportamientos de estructuras y estructuras de clases como bloques constructores de cortes. Cristina Lopes propuso la sincronización y la invocación remota como nuevos bloques [4]. No fue hasta 1995 cuando se publicó la primera definición temprana del concepto de aspecto, realizada también por el grupo Demeter y que sería la siguiente:

“Un aspecto es una unidad que se define en términos de información parcial de otras unidades”.

Por suerte las definiciones cambian con el tiempo y se hacen más comprensibles y precisas. Actualmente es más apropiado hablar de la siguiente definición de Gregor Kiczales:

“Un aspecto es una unidad modular que se dispersa por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa”.

UN PROCESADOR DE IMÁGENES

El siguiente ejemplo está sacado del trabajo publicado en 1997 para la European Conference on Object- Oriented Programming (ECOOP) celebrada en Finlandia [2]. Supongamos una aplicación de procesamiento de imágenes en blanco y negro. El dominio del problema son las imágenes que deben pasar por una serie de filtros para obtener el resultado deseado. Se podrían hacer tres implementaciones: una que fuese fácil de entender pero ineficiente, una eficiente pero difícil de entender y una tercera,

...