Programación orientada a Aspectos.
La programación orientada a aspectos pretende dar solución a las tareas o eventos repetitivos que pueden, en un momento dado, retrasan la construcción de un software.
La Programación orientada a Aspectos constituye uno los avances más importantes de los últimos años en la ingeniería del software para edificar sistemas complejos empleando el principio de descomposición, ya que el modelo de objetos subyacente se ajusta mejor a los problemas del dominio real que la descomposición funcional.
La ventaja que tiene es que es fácil la integración de nuevos datos, aunque también quedan las funciones esparcidas por todo el código, y tiene los inconvenientes de que, con frecuencia, para realizar la integración de nuevas funciones hay que modificar varios objetos, y de que se produce un enmarañamiento de los objetos en funciones de alto nivel que involucran a varias clases.
La POA es una nueva metodología de programación que aspira a soportar la separación de las propiedades para los aspectos antes mencionados. Esto implica separar la funcionalidad básica y los aspectos, y los aspectos entre sí, a través de mecanismos que permitan abstraerlos y componerlos para formar todo el sistema.
La POA es un desarrollo que sigue a la POO, y como tal, soporta la descomposición orientada a objetos, además de la procedimental y la funcional. Sin embargo, la programación orientada a aspectos no es una extensión de la POO, ya que puede utilizarse con los diferentes estilos de programación mencionados anteriormente.
Aplicando POA se puede escribir una funcionalidad básica “pura”, y especificar cada aspecto por separado.
Luego, existe un proceso de combinación que compondrá el sistema final.
La POA permite a los desarrolladores escribir, ver, y editar un aspecto diseminado por todo el sistema como una entidad por separado, de una manera inteligente, eficiente e intuitiva.
En este artículo mostraré la aplicación, metodología utilizada para convertir una implementación tradicional en una que considere aspectos basándome en los principios de la POA.
Entre los principales objetivos de la Programación Orientada a Aspectos tenemos:
- Separar las funcionalidades comunes utilizadas en toda la aplicación como: algunos eventos, validaciones, mensajes, etc.
- Separar las funcionalidades propias de cada modulo que no hacen parte de las anteriores como por ejemplo en calculo de alguna fórmula en un modulo especifico o lo que se podría llamar las reglas del negocio o la capa BL , por sus siglas en Ingles.
El aporte aquí seria que cuando se inicia la construcción de un proyecto de software o un modulo se deben pensaren aquellos eventos, validaciones o métodos que podrán ser reutilizados o llamados de diferentes instancias del aplicativo, para con esto poder crear librerías, frameworks, Dlls, Componente, etc.
El concepto de programación orientada a aspectos fue introducido por Gregor Kiczales y su grupo, aunque el equipo Demeter 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 adaptativa, que no es más que una instancia temprana de la programación orientada a aspectos. La programación adaptativa se introdujo alrededor de 1991.
Aquí los programas se dividían 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. No fue hasta 1995 cuando se publicó la primera definición temprana del concepto de aspecto realizada también por el grupo Demeter. Gracias a la colaboración de Cristina Lopes y Karl J. Lieberherr con Gregor Kiczales y su grupo se introdujo el término de programación orientada a aspectos.
La idea central que pretende la POA es admitir que un programa sea construido describiendo cada concepto separadamente. La POA muestra la separación de conceptos a través de mecanismos, que permiten abstraer y componer estos conceptos a lo largo del sistema.
Mediante una clase especial de lenguajes, llamados lenguajes orientados a aspectos (LOA), los cuales nos muestran mecanismos y constructores para la captura de los elementos que se diseminan por todos el sistema; lo cual logró ser el soporte fundamental para este nuevo paradigma POA.
A estos elementos se los denomina aspectos, cuya definición sería que un aspecto es un concepto que no es posible encapsularlo claramente, y que resulta diseminado por todo el código. Los LOA dar cumplimiento a las siguientes propiedades:
- Cada aspecto debe ser claramente identificable.
- Cada aspecto debe auto-contenerse.
- Los aspectos deben ser fácilmente intercambiables.
- Los aspectos no deben interferir entre ellos.
- Los aspectos no deben interferir con los mecanismos usados para definir y evolucionar la funcionalidad, como la herencia.
Aplicando POA se puede escribir una funcionalidad básica “pura”, y especificar cada aspecto por separado. Luego, existe un proceso de combinación que compondrá el sistema final.
Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del código donde es posible agregar comportamiento adicional.
El comportamiento adicional puede agregarse en tres momentos particulares: antes, después, en lugar de.
El encargado de la composición es llamado Weaver. Guiado por los puntos de enlace teje el código base con el código de los aspectos.
Los tres principales requerimientos de la POA son:
- Un lenguaje para definir la funcionalidad básica, conocido como lenguaje base o componente. Podría ser un lenguaje imperativo, o un lenguaje no imperativo (C++, Java, Lisp, ML).
- Uno o varios lenguajes de aspectos, para especificar el comportamiento de los aspectos. (COOL, para sincronización, RIDL, para distribución, AspectJ, de propósito general.)
- Un tejedor de aspectos (Weaver), que se encargará de combinar los lenguajes. Tal proceso se puede retrasar para hacerse en tiempo de ejecución o en tiempo de compilación.
Los lenguajes orientados a aspectos muestran una manera diferente de programación de software para encapsular aquellos conceptos que cruzan todo el código.
Para que los aspectos y componentes se puedan mezclar, deben tener algunos puntos comunes, que son los que se conocen como puntos de enlace.
Los puntos de enlace brindan la interfaz entre aspectos y componentes; son lugares dentro del código donde es posible agregar el comportamiento adicional que destaca a la POA. Dicho comportamiento adicional es especificado en los aspectos.
A quien realiza el proceso de tejer se lo denomina tejedor (weaver), que es quien se encarga de mezclar los diferentes mecanismos de abstracción y composición que surgen en los lenguajes de aspectos y componentes ayudándose de los puntos de enlace.
La estructura de una implementación basada en aspectos es análoga con relación a la estructura de una implementación basada en los LPG. Una implementación basada en LPG consiste en:
- Un lenguaje.
- Un compilador o intérprete para ese lenguaje.
- Un programa escrito en ese lenguaje que implemente la aplicación.
Una implementación basada en POA consiste en:
- El lenguaje base o componente para programar la funcionalidad básica.
- Uno o más lenguajes de aspectos para especificar los aspectos.
- Un tejedor de aspectos para la combinación de los lenguajes.
- El programa escrito en el lenguaje componente que implementa los componentes.
- Uno o más programas de aspectos que implementan los aspectos.
- Gráficamente, se tiene una estructura como la siguiente:
Describiré algunos conceptos de los lenguajes de mayor funcionalidad en la actualidad:
• JPAL.- Permite separar los puntos de enlace, que son independientes del lenguaje base, de sus acciones asociadas que dependen de decisiones de implementación. Permite generar un Esquema de
Tejedor (brinda un puente entre el control de la ejecución y la ejecución de la acción). Su principal aplicación es para la implementación de sistemas distribuidos.
• D.- Denominado ambiente de lenguajes, en vez de solamente lenguaje, porque consiste en realidad de dos lenguajes: COOL, para controlar la sincronización de hilos (threads), y RIDL, para programar la interacción entre componentes remotos. El diseño deD es semi-independiente del lenguaje componente, ya que D impone requerimientos sobre el lenguaje componente que satisfacen naturalmente los lenguajes orientados a objetos.
• COOL.- COOL (COOrdination aspect Language) es un lenguaje de aspectos de dominio específico para tratar con la exclusión mutua de hilos, sincronización, suspensión y reactivación de hilos.
• RIDL.- RIDL (Remote Interaction and Data transfers aspect Language) es un lenguaje de aspectos de dominio específico que maneja la transferencia de datos entre diferentes espacios de ejecución.Un programa RIDL consiste de un conjunto de módulos de portales. Los módulos de portales o directamente portales se asocian con las clases por el nombre.
• ASPECTC.- AspectC es un simple lenguaje de aspectos de propósito general que extiende C, es un subconjunto de AspectJ sin ningún soporte para la programación orientada a objetos o módulos explícitos.
• ASPECTS.- AspectS, un lenguaje de aspectos de propósito general, utiliza el modelo de lenguaje de spectJ y ayuda a descubrir la relación que hay entre los aspectos y los ambientes dinámicos. Soporta programación en un metanivel, manejando el fenómeno de Código Mezclado a través de módulos de aspectos relacionados. Está implementado en Squeak sin cambiar la sintaxis, ni la máquina virtual.
• ASPECTC++.- AspectC++[29] es un lenguaje de aspectos de propósito general que extiende el lenguaje C++ para soportar el manejo de aspectos. En este lenguaje los puntos de enlace son puntos en el código componente donde los aspectos pueden interferir. Los puntos de enlaces son capaces de referir a código, tipos, objetos, y flujos de control.
• MALAJ.- Malaj es un sistema que soporta la programación orientada a aspectos. Define constructores lingüísticos separados para cada aspecto de dominio específico, donde el código de los aspectos tiene una visibilidad limitada del código funcional, reduciendo los posibles conflictos con las características lingüísticas tradicionales y también, con el principio de encapsulación.
• ASPECJ.- AspectJ es un lenguaje orientado a aspectos de propósito general, cuya primera versión fue lanzada en 1998 por el equipo conformado por Gregor Kickzales (líder del proyecto), Ron Bodkin, Bill Griswold, Erik Hilsdale, Jim Hugunin, WesIsberg y Mik Kersten. Es una herramienta que está en desarrollo y las nuevas versiones pueden tanto corregir errores de su versión predecesora como modificar el lenguaje.