Programacin Orientada a Aspectos. Qu es?

(Parte 1)
Para explicar la programacin orientada a aspectos, quizs lo ideal sera comenzar con una breve descripcin de la historia de la ingeniera de software, como lo hacen la mayora de los artculos o PDFs que podemos encontrar en la web, pero como justamente la mayora lo hace as, yo no. Quien quiera verlo as, busque en la web el tema y ah van a tener mucho para leer (y no est dems). Pero yo prefiero comenzar yendo al grano. La programacin orientada a objetos trata la manera de modularizar "conceptos comunes" de software. Sin embargo, existen otros conceptos o asuntos que se extienden a lo largo de estos "conceptos comunes" y que no pueden ser modularizados con el diseo orientado a objetos. En un intento ms de subsanar lo que la orientacin a objetos no puede, aparece una nueva solucin: la Programacin Orientada a Aspectos (y su consecuente Diseo Orientado a Aspectos). La programacin orientada a aspectos se ha planteado como un nuevo paradigma de programacin (con lo que no estoy de acuerdo), el cual consiste en separar los conceptos que entrecruzan varias clases y se extienden a lo largo de stas, pero que no pertenecen a esas clase en s mismas. Incluso, los conceptos pueden aparecer no slo en varias clases, sino de una sola. Ahora la pregunta: de qu tipo de conceptos hablamos? Pensemos como ejemplo, en una aplicacin que requiere del registro (logging) de las acciones que realiza. Bien, estos registros "alguien" tiene que llevarlos a cabo, y es normal cargar a muchas clases con la responsabilidad de hacerlo cuando, seguramente, no sea la funcin principal de esas clases hacer dicha tarea. Como vemos, se trata de una misma funcionalidad (registrar acciones) que se encuentra entrecruzada en varias clases, pero que a la vez no es parte de ninguna. Otro ejemplo, simple de entender, es el manejo de errores. Los errores hay que tratarlos s o si en una aplicacin. Pero, desde un punto de vista "purista" de objetos, no tenemos clases que traten los errores por s solos. Siempre las clases que definen la funcionalidad de la aplicacin van a tener que lidiar con los errores, y esa no es su funcin principal. En cierta forma, esto hace a dichas clases menos cohesivas. Un tercer ejemplo puede ser el manejo de la sincronizacin. Nuevamente, los objetos del negocio deben tratar la sincronizacin adems de su funcin principal. En todo los ejemplos estanos viendo que hay ciertos asuntos que no pertenecen al negocio pero que sin embargo, deben ser tratados. Y lo negativo de esto, es que segn el paradigma de objetos, son los objetos del negocio quienes deben tratar estos asuntos y, como si fura poco que hagan tareas que no les corresponden, estas tareas se esparcen a lo largo de toda la aplicacin, llevando a dispersar cdigo y enredarlo por la misma (a esto ltimo se llama Code Tangling y Code Scattering).

Entonces, para darle ms sentido a la POA, veamos en qu se afecta el desarrollo de aplicaciones cuando surgen estos asuntos: Baja cohesin: las clases realizan tareas que no le corresponden especficamente a ellas. Baja reusabilidad: Cuando una clase trata un asunto que no le corresponde, esta clase probablemente sea difcil de re usar en otro sistema. Peor calidad de cdigo: El cdigo se complica, y cuesta ms entenderlo y mantenerlo. Evolucin dificultosa: Se vuelve ms costoso que el sistema evoluciones al tener cdigo disperso y enredado por toda la aplicacin. Estos asuntos son denominados "conceptos transversales". La POA viene para tratar de separar y encapsularlos en una aplicacin y aislarlos para independizar a los objetos del negocio de stos conceptos. Este aislamiento se encapsula en "aspectos". Por lo tanto, la POA permite la separacin de conceptos transversales a travs de mecanismos que permiten abstraer y encapsular estos conceptos en un sistema. Un aspecto es la unidad que encapsula uno o ms conceptos transversales, y que con la programacin orientada a objetos no es posible diferenciarlo de forma clara. La definicin actual de aspecto dice: "Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseo como en la de implementacin. Un aspecto de diseo es una unidad modular del diseo que se entremezcla en la estructura de otras partes del diseo. Un aspecto de programa o de cdigo es una unidad modular del programa que aparece en otras unidades modulares del programa. La principal ventaja de la POA es que permite tratar la funcionalidad pura por un lado, y los aspectos por otro, de forma separada. Luego ambos se combinan con un tipo de programa llamado 'Weaver') para dar por resultado el sistema final. Hay mucho ms por hablar de POA an. En la prxima parte (parte 2), voy a mostrar un ejemplo muy claro, para asentar toda esta teora en algo ms palpable, as que a no abandonar si esta pequea introduccin a resultado medio difcil de entender, en el ejemplo de la Parte 2 quedar muy claro de que se trata.

Programacin Orientada a Aspectos. Por qu usar POA? (Parte 2)

En la parte 1, di una introduccin a lo que es la programacin orientada a aspectos de una forma bastante terica. En esta segunda parte, voy a mostrar un ejemplo prctico muy simplificado para poder asentar un poco ms el concepto. Para el ejemplo utilic el lenguaje Java, y la extensin del lenguaje Java que implementa

aspectos AspectJ. Ya he contado como compilar con AspectJ en NetBeans. Bueno, en qu consiste la POA? Voy a poner un ejemplo muy fcil que ilustra el potencial que nos ofrece la POA Supongamos una aplicacin de transacciones bancarias. (Este es el tpico ejemplo que se menciona en todos lados, y lo voy a poner en mi versin porque es muy ilustrativo). Vamos a tener una clase cuyo nombre es Cuenta y es una versin muy simplificada de una cuenta de un banco. Esta clase, tiene un atributo llamado saldo de tipo Double que indica el saldo en la cuenta. Y vamos a tener tres mtodos: Uno que llamado hacerDeposito() con un nico parmetro de tipo Double que indica la cantidad a depositar en la cuenta. Otro llamado hacerExtraccion() que cuenta con un solo parmetro que indica la cantidad de dinero que se quiere extraer de la cuenta. El mtodo restante se llama hacerTransferencia() y tiene dos parmetros: uno indica la cantidad de dinero y el otro es la cuenta a la que se quiere hacer la transferencia. Adems tendremos una tpica -y muy simplificada- clase que representa un cliente del supuesto "banco" llamada Cliente. Para seguir simplificando (cosa que se me est haciendo mala costumbre ya) un cliente slo puede tener una cuenta. Ilustremos con UML: Los getter y los setters porque son muy triviales. Introduccin Si se echa un vistazo a la historia de la ingeniera del software, prestando particular atencin a cmo ha evolucionado, se puede observar que los progresos ms significativos se han obtenido gracias a la aplicacin de uno de los principios fundamentales a la hora de resolver cualquier problema, incluso de la vida cotidiana, la descomposicin de un sistema complejo en partes que sean ms fciles de manejar, es decir, gracias a la aplicacin del dicho popular conocido como divide y vencers. En los primeros estadios de desarrollo de los lenguajes de programacin se tena un cdigo en el que no haba separacin de conceptos, datos y funcionalidad se mezclaban sin una lnea divisoria clara. A esta etapa se la conoce como la del cdigo spaghetti, ya que se tena una maraa entre datos y funcionalidad que recuerda a la que se forma cuando comemos un plato de esta pasta italiana. En la siguiente etapa se pas a aplicar la llamada descomposicin funcional, que pone en prctica el principio de divide y vencers identificando las partes ms manejables como funciones que se definen en el dominio del problema. La principal ventaja que proporciona esta descomposicin es la facilidad de integracin de nuevas funciones, aunque tambin tiene grandes inconvenientes, como son el hecho de que las funciones quedan algunas veces poco claras debido

a la utilizacin de datos compartidos, y el que los datos quedan esparcidos por todo el cdigo, con lo cual, normalmente el integrar un nuevo tipo de datos implica que se tengan que modificar varias funciones. Intentando solventar estas desventajas con respecto a los datos, se dio otro paso en el desarrollo de los sistemas software. La programacin orientada a objetos (POO) ha supuesto uno de los avances ms importantes de los ltimos aos en la ingeniera del software para construir sistemas complejos utilizando el principio de descomposicin, ya que el modelo de objetos subyacente se ajusta mejor a los problemas del dominio real que la descomposicin funcional. La ventaja que tiene es que es fcil la integracin de nuevos datos, aunque tambin quedan las funciones esparcidas por todo el cdigo, y tiene los inconvenientes de que, con frecuencia, para realizar la integracin de nuevas funciones hay que modificar varios objetos, y de que se produce un enmaraamiento de los objetos en funciones de alto nivel que involucran a varias clases. En la Figura 1 se representa mediante un esquema los distintos estadios en la evolucin de los sistemas software. En este esquema se refleja de forma clara la mezcla de conceptos que se produce en cada una de las etapas de la evolucin (etapas comnmente conocidas como generaciones). Si cada una de las distintas formas que aparecen dibujadas (tringulo, cuadrado, trapecio, elipse) representa a un tipo de datos distinto, y cada color o tonalidad representa a una funcin distinta, se tiene que en la primera generacin de los sistemas software funciones y datos se entremezclaban. En la segunda y tercera generacin se tienen conjuntos de elementos agrupados por tonalidades, y en cada conjunto conviven distintas formas, lo que nos indica que la descomposicin del sistema se hace en base a las funciones (tonalidades), y que los datos quedan esparcidos por todos los conjuntos. En la cuarta generacin, sin embargo, esta agrupacin se realiza en base a las formas (datos), pero como se puede observar, en cada conjunto tenemos representadas distintas funcionalidades (tonalidades), con lo cual stas tambin se nos dispersan por todo el sistema. Uno de los principales inconvenientes con el que nos encontramos al aplicar estas descomposiciones ya tradicionales es que muchas veces se tienen ejecuciones ineficientes debido a que las unidades de descomposicin no siempre van acompaadas de un buen tratamiento de aspectos tales como la gestin de memoria, la coordinacin, la distribucin, las restricciones de tiempo real. En el desarrollo de un sistema software adems del diseo y la implementacin de la funcionalidad bsica, se recogen otros aspectos tales como la sincronizacin, la distribucin, el manejo de errores, la optimizacin de la memoria, la gestin de seguridad, etc. Mientras que las descomposiciones funcional y orientada a objetos no nos plantean ningn problema con respecto al diseo y la implementacin de la funcionalidad bsica, estas tcnicas no se comportan bien con los otros aspectos. Es decir, que nos encontramos con problemas de programacin en los cuales ni las tcnicas funcionales, ni las orientadas a objeto son suficientes para capturar todas las decisiones de diseo que el programa debe implementar. Con las descomposiciones tradicionales no se aislan bien estos otros aspectos, sino que quedan diseminados por todo el sistema enmaraando el cdigo que

implementa la funcionalidad bsica, y yendo en contra de la claridad del mismo. Se puede afirmar entonces que las tcnicas tradicionales no soportan bien la separacin de competencias para aspectos distintos de la funcionalidad bsica de un sistema, y que esta situacin claramente tiene un impacto negativo en la calidad del software. La programacin orientada a aspectos (POA) es una nueva metodologa de programacin que aspira a soportar la separacin de competencias para los aspectos antes mencionados. Es decir, que intenta separar los componentes y los aspectos unos de otros, proporcionando mecanismos que hagan posible abstraerlos y componerlos para formar todo el sistema. En definitiva, lo que se persigue es implementar una aplicacin de forma eficiente y fcil de entender. POA es un desarrollo que sigue al paradigma de la orientacin a objetos, y como tal, soporta la descomposicin orientada a objetos, adems de la procedimental y la descomposicin funcional. Pero, a pesar de esto, POA no se puede considerar como una extensin de la POO, ya que puede utilizarse con los diferentes estilos de programacin ya mencionados. El estado actual de la investigacin en POA es anlogo al que haba hace veinte aos en la programacin orientada a objetos. En la Figura 2 se representa la forma en que la programacin orientada a aspectos descompone los sistemas. Se sigue el razonamiento empleado en la Figura 1, donde los datos se identificaban con la forma de las figuras y las funcionalidades con el color o la tonalidad. En este esquema se observa que la disociacin de los de los distintos conjuntos se realiza tanto en base a la forma (datos) como a las tonalidades (funciones). Adems, se indica que las distintas funcionalidades estn relacionadas de alguna manera. Esto se representa utilizando figuras transparentes para indicar este tipo de relacin. QUE ES POA? Nuevo paradigma de programacin con enfoque estructurado, procedimientos o acciones. Enfoque orientado a objetos, datos encapsulados en clases. PORQUE POA? Existen conceptos que no pueden encapsularse dentro de una unidad funcional, debido a que atraviesan todo el sistema o varias partes de el, como lo son la sincronizacin, el manejo de memoria, el manejo de errores, perfiles, seguridad o redes.