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

...