Tejedor de aspectos

Un tejedor de aspectos es una utilidad de metaprogramación para lenguajes orientados a aspectos diseñada para tomar instrucciones especificadas por aspectos (representaciones aisladas de conceptos significativos en un programa) y generar el código de implementación final . El tejedor integra aspectos en las ubicaciones especificadas por el software como un paso de precompilación. Al fusionar aspectos y clases ( representaciones de la estructura de entidades en el programa), el tejedor genera una clase tejida.

Los tejedores de aspectos toman instrucciones conocidas como consejos especificados mediante el uso de puntos de corte y puntos de unión , segmentos especiales de código que indican qué métodos deben ser manejados por el código de aspecto. La implementación del aspecto luego especifica si el código relacionado debe agregarse antes, después o a lo largo de los métodos relacionados. Al hacer esto, los tejedores de aspectos mejoran la modularidad , manteniendo el código en un solo lugar que de otra manera habría estado intercalado en varias clases no relacionadas.

Muchos lenguajes de programación ya son ampliamente aceptados y comprendidos. Sin embargo, no existe un deseo significativo de crear lenguajes de programación radicalmente diferentes para respaldar el paradigma de programación orientada a aspectos debido a los riesgos comerciales asociados con la adopción de nuevas tecnologías. ^[1] El uso de un lenguaje completamente nuevo depende de la capacidad de una empresa para adquirir nuevos desarrolladores. Además, sería necesario descartar la base de código existente de una empresa. Finalmente, una empresa necesitaría adquirir una nueva cadena de herramientas (conjunto de herramientas) para el desarrollo, lo que a menudo es costoso tanto en dinero como en tiempo. ^[2] Las principales preocupaciones sobre las hojas de ruta para la adopción de nuevas tecnologías incluyen la necesidad de capacitar a nuevos desarrolladores y adaptar los procesos existentes a la nueva tecnología. ^[3]

Para abordar estas preocupaciones comerciales, un tejedor de aspectos permite el uso de lenguajes ampliamente adoptados como Java con programación orientada a aspectos a través de adaptaciones menores como AspectJ que funcionan con herramientas existentes. ^[4] En lugar de desarrollar un lenguaje completamente nuevo, el tejedor de aspectos interpreta las extensiones definidas por AspectJ y crea código Java "tejido" que luego puede ser utilizado por cualquier compilador Java existente. Esto garantiza que cualquier código orientado a objetos existente seguirá siendo un código orientado a aspectos válido y que el desarrollo se sentirá como una extensión natural del lenguaje orientado a objetos. ^[5] El lenguaje de programación AspectC++ extiende C++ a través del uso de un tejedor de aspectos, ofreciendo la eficiencia adicional sobre AspectJ que se necesita para los sistemas integrados mientras se conservan los beneficios de la programación orientada a aspectos. ^[6]

Los tejedores de aspectos funcionan tomando instrucciones especificadas por aspectos , conocidas como consejos , y distribuyéndolas automáticamente a través de las distintas clases del programa. El resultado del proceso de tejedura es un conjunto de clases con los mismos nombres que las clases originales pero con código adicional inyectado automáticamente en las funciones de las clases . Los consejos especifican la ubicación exacta y la funcionalidad del código inyectado. ^[7]

A través de este proceso de entrelazado, los tejedores de aspectos permiten un código que de otra manera se habría duplicado en las clases. Al eliminar esta duplicación, los tejedores de aspectos promueven la modularidad de las preocupaciones transversales . ^[8] Los aspectos definen el código de implementación que de otra manera se habría duplicado y luego usan puntos de corte y puntos de unión para definir el consejo. Durante el entrelazado, el tejedor de aspectos usa los puntos de corte y los puntos de unión, conocidos como designadores de puntos de corte , para identificar las posiciones en las clases candidatas en las que se debe inyectar la implementación. ^[9] Luego, la implementación se inyecta en las clases en los puntos identificados, lo que permite que el código se ejecute en los momentos apropiados sin depender de la duplicación manual por parte del programador . ^[10]

En el lenguaje de programación AspectJ , los puntos de corte, los puntos de unión y el código modularizado se definen en un bloque de aspecto similar al de las clases Java . Las clases se definen utilizando la sintaxis de Java. El proceso de entrelazado consiste en ejecutar el consejo de aspecto para producir solo un conjunto de clases generadas que tienen el código de implementación de aspecto entrelazado en él. ^[11]

El ejemplo de la derecha muestra una posible implementación de un aspecto que registra la entrada y salida de todos los métodos . Sin un tejedor de aspectos, esta función requeriría la duplicación de código en la clase para cada método. En cambio, el código de entrada y salida se define únicamente dentro del aspecto. ^[12]

El tejedor de aspectos analiza el consejo especificado por el punto de corte en el aspecto y utiliza ese consejo para distribuir el código de implementación en la clase definida. El código difiere ligeramente en cada método debido a pequeñas variaciones en los requisitos para el método (ya que el identificador del método ha cambiado). El tejedor de aspectos determina el código apropiado para generar en cada situación según lo definido por el consejo de implementación y luego lo inyecta en los métodos que coinciden con el punto de corte especificado. ^[13]

En lugar de generar un conjunto de código fuente entrelazado , algunos tejedores de AspectJ entrelazan los aspectos y las clases directamente en bytecode , actuando como tejedores de aspectos y compiladores . ^{[14] [15]} Se espera que el rendimiento de los tejedores de aspectos que también realizan el proceso de compilación requiera más tiempo de cálculo debido al proceso de entrelazado involucrado. Sin embargo, el proceso de entrelazado de bytecode produce un código en tiempo de ejecución más eficiente que el que normalmente se lograría a través de una fuente entrelazada compilada.

Los avances en AspectJ han revelado el potencial de incorporar la compilación justo a tiempo en la ejecución de código orientado a aspectos para abordar las demandas de rendimiento. ^[16] En tiempo de ejecución , un entrelazador de aspectos podría traducir aspectos de una manera más eficiente que los enfoques de entrelazado estático tradicionales. Al usar AspectJ en una máquina virtual Java , se ha demostrado que el entrelazado dinámico de aspectos en tiempo de ejecución mejora el rendimiento del código en un 26%. ^[17] Si bien algunas implementaciones de máquinas virtuales justo a tiempo implementan esta capacidad a través de una nueva máquina virtual, algunas implementaciones pueden diseñarse para usar características que ya existen en las máquinas virtuales actuales. ^{[18] [19]} El requisito de una nueva máquina virtual es contrario a uno de los objetivos de diseño originales de AspectJ. ^[5]

Para lograr el entrelazado justo a tiempo, se necesita un cambio en la máquina virtual que ejecuta el bytecode compilado . Una solución propuesta para AspectJ utiliza un enfoque en capas que se basa en la máquina virtual Java existente para agregar soporte para la gestión de puntos de unión y devoluciones de llamadas a un motor de programación orientado a aspectos dinámico . ^[19] Una implementación alternativa utiliza un motor de entrelazado que utiliza puntos de interrupción para detener la ejecución en el punto de corte, seleccionar un método apropiado, incrustarlo en la aplicación y continuar. ^[20] Se ha demostrado que el uso de puntos de interrupción de esta manera reduce el rendimiento debido a una gran cantidad de cambios de contexto . ^[17]

El rendimiento de los tejedores de aspectos, así como el rendimiento del código que producen, ha sido objeto de análisis. Es preferible que la mejora en la modularidad proporcionada por el tejedor de aspectos no afecte al rendimiento en tiempo de ejecución. Los tejedores de aspectos pueden realizar optimizaciones específicas de aspecto. ^[21] Si bien las optimizaciones tradicionales, como la eliminación de variables especiales no utilizadas del código de aspecto, se pueden realizar en tiempo de compilación , algunas optimizaciones solo pueden ser realizadas por el tejedor de aspectos. Por ejemplo, AspectJ contiene dos palabras clave similares pero distintas, thisJoinPoint, que contiene información sobre esta instancia particular de código entretejido, y thisJoinPointStaticPart, que contiene información común a todas las instancias de código relevantes para ese conjunto de consejos. La optimización de reemplazar con la palabra clave thisJoinPointmás eficiente y estática solo puede ser realizada por el tejedor de aspectos. Al realizar este reemplazo, el programa entretejido evita la creación de un objetothisJoinPointStaticPart de punto de unión en cada ejecución. ^[14] Los estudios han demostrado que la creación innecesaria de objetos de punto de unión en AspectJ puede generar una sobrecarga de rendimiento del 5 % en tiempo de ejecución, mientras que la degradación del rendimiento es solo de aproximadamente el 1 % cuando no se crea este objeto. ^[22]

El rendimiento en tiempo de compilación es generalmente peor en los compiladores de aspecto que en sus contrapartes de compiladores tradicionales debido al trabajo adicional necesario para localizar métodos que coincidan con los puntos de corte especificados. Un estudio mostró que el compilador AspectJ ajc es aproximadamente un 34% más lento que el compilador Java 1.3 de Sun Microsystems y aproximadamente un 62% más lento que el compilador Java 1.4 . ^[23]

• Programación orientada a aspectos
• Preprocesador
• Compilador

• Suzuki, Junichi; Yamamoto, Yoshikazu (junio de 1999). Moreira, AM; Demeyer, Moreira (eds.). "Extending UML with Aspects: Aspect Support in the Design Phase" (PDF) . Actas del Taller sobre Tecnología Orientada a Objetos . 1743 : 299–300. Archivado desde el original (PDF) el 22 de julio de 2011 . Consultado el 4 de enero de 2010 .