Programación orientada a aspectos
| ||||
La Programación Orientada a Aspectos (POA): es un paradigma de programación relativamente reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de conceptos. Gracias a la POA se pueden capturar los diferentes conceptos que componen una aplicación en entidades bien definidas, de manera apropiada en cada uno de los casos y eliminando las dependencias inherentes entre cada uno de los módulos.
De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas como los métodos adaptivos, los filtros de composición, la programación orientada a sujetos o la separación multidimensional de competencias.
Sumario
Un poco de Historia
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 dicen 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 lo que queremos dotar nuestra aplicación. Así mismo, la programación procedural tampoco nos soluciona el problema. Por lo que ante tales problemas, se utiliza la POA.
Los conceptos y tecnologías reunidos bajo el nombre "programación orientada a aspectos" (AOP, por las siglas de Aspect-OrientedProgramming; o AOSD, por Aspect-Oriented Software Development) buscan resolver un problema identificado hace tiempo en el desarrollo de software. Se trata del problema de la separación de incumbencias (separation of concerns). AOP no es el único intento por solucionar este problema, del que se habla a continuación: hay varias propuestas, muchas de las cuales se agrupan (junto con AOP) en el campo de estudio denominado ASoC (Advanced Separationof Concerns).
La programación orientada a aspectos (POA) es una nueva metodología de programación que aspira a soportar la separación 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 aplicación de forma eficiente y fácil de entender.
POA es un desarrollo que sigue al paradigma de la orientación a objetos, y como tal, soporta la descomposición orientada a objetos, además de la procedimental y la descomposición funcional. Pero, a pesar de esto, POA no se puede considerar como una extensión de la POO, ya que puede utilizarse con los diferentes estilos de programación ya mencionados.
Principio Separación de Incumbencias
El principio de separación de incumbencias fue identificado en la década de 1970, plantea que un problema dado involucra varias incumbencias que deben ser identificadas y separadas. Las incumbencias son los diferentes temas o asuntos de los que es necesario ocuparse para resolver el problema. Una de ellas es la función específica que debe realizar una aplicación, pero también surgen otras como por ejemplo distribución, persistencia, replicación, sincronización, etc. Separando las incumbencias, se disminuye la complejidad a la hora de tratarlas y se puede cumplir con requerimientos relacionados con la calidad como adaptabilidad, mantenibilidad, extensibilidad y reusabilidad.
El principio puede aplicarse de distintas maneras. Por ejemplo, separar las fases del proceso de desarrollo puede verse como una separación de actividades de ingeniería en el tiempo y por su objetivo. Definir subsistemas, objetos y componentes son otras formas de poner en práctica el principio de separación de incumbencias. Por eso podemos decir que se trata de un principio rector omnipresente en el proceso de desarrollo de software.
Las técnicas de modelado que se usan en la etapa de diseño de un sistema se basan en partirlo en varios subsistemas que resuelvan parte del problema o correspondan a una parte del dominio sobre el que trata. Estas técnicas sufren en su mayoría la llamada "tiranía de la descomposición dominante" que consiste en guiarse al modelar, implícita o explícitamente, por una visión jerárquica determinada de la organización del sistema. La desventaja de estas particiones es que muchas de las incumbencias a tener en cuenta para cumplir con los requerimientos (en particular, habitualmente, las incumbencias no funcionales) no suelen adaptarse bien a esa descomposición, como veremos más adelante.
Las construcciones provistas por los lenguajes de programación, que fueron creados para implementar los modelos generados por las técnicas de diseño existentes, reproducen las jerarquías y, por lo tanto, comparten el defecto explicado en el párrafo anterior. En el paradigma de programación imperativa, la descomposición consiste en identificar procedimientos que resuelvan parte del problema, y la jerarquía se da en el árbol de ejecución, según el cual los procedimientos se invocan unos a otros. En el caso de la programación orientada a objetos, la jerarquía generada en la etapa de diseño suele plasmarse en las relaciones de herencia o de composición entre objetos. Por ejemplo, algunos patrones de diseño de uso habitual como observador (observer), visitante (visitor) y mediador (mediator) exhiben estos problemas, ya que para aplicarlos es necesario adaptar a ellos más de una clase.
El problema aparece cuando una incumbencia afecta a distintas partes del sistema que no aparecen relacionadas en la jerarquía. En ese caso, la única solución suele ser escribir código repetido que resuelva esa incumbencia para cada subsistema.
Fundamentos de la Programación Orientada a Aspectos
Para tener un programa orientado a aspectos necesitamos definir los siguientes elementos:
- Un lenguaje para definir la funcionalidad básica. Este lenguaje se conoce como lenguaje base. Suele ser un lenguaje de propósito general, tal como C++ o Java. En general, se podrían utilizar también lenguajes no imperativos.
- El lenguaje de aspectos define la forma de los aspectos – por ejemplo, los aspectos de AspectJ se programan de forma muy parecida a las clases.
- El tejedor se encargará de combinar los lenguajes. El proceso de mezcla se puede retrasar para hacerse en tiempo de ejecución, o hacerse en tiempo de compilación.
Caracteristicas de POA
De la consecución de estos objetivos se pueden obtener las siguientes ventajas:
- Un código menos enmarañado, más natural y más reducido.
- Una mayor facilidad para razonar sobre las materias, ya que están separadas y tienen una dependencia mínima.
- Más facilidad para depurar y hacer modificaciones en el código.
- 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.
Fuentes
- Juan Manuel Nieto Moreno, Introducción a la Programación Orientada a Aspectos. Escuela Técnica Superior de Ingeniería Informática, Universidad de Sevilla, España.
- Visión General de la programación Orientada a Aspectos. Departamento de Lenguajesy Sistemas Informáticos, Facultad de Informática y Estadística, Universidad de Sevilla, España.
- Gregory T. Sullivan. Aspect-Oriented Programming using Reflection. Artificial Intelligence Laboratory, Massachusetts Institute of Technology.
