Hacia una mejor experiencia de debugging en desarrollos AOP

Transcripción

1 TESIS DE GRADO EN INGENIERÍA INFORMÁTICA Hacia una mejor experiencia de debugging en desarrollos AOP FACULTAD DE INGENIERÍA UNIVERSIDAD DE BUENOS AIRES TESISTA: Adrián EIDELMAN DIRECTORA: Lic. Rosa WACHENCHAUZER CO-DIRECTOR: Lic. Alan CYMENT NOVIEMBRE 2006

2 Resumen Las limitaciones que presenta la Programación Orientada a Objetos para encapsular las incumbencias transversales en un desarrollo de software han dado origen a nuevas técnicas de programación, entre las cuales se ha destacado en los últimos años la Programación Orientada a Aspectos (AOP). AOP introduce una nueva unidad de modularización denominada aspecto, que tiene el fin de encapsular estas funcionalidades transversales y mejorar así la comprensión y mantenibilidad de las aplicaciones. A partir de la introducción del aspecto como unidad de modularización, AOP a su vez incorpora nuevas fuentes de fallas y por lo tanto nuevos desafíos en lo que respecta al testing en desarrollos de este tipo. A pesar de esto, el aseguramiento de la calidad no ha sido objeto de atención dentro de la comunidad AOP y el escaso desarrollo de esta disciplina se manifiesta particularmente en una actividad: el debugging de aplicaciones. El objetivo de la presente tesis es exponer las fallas características que pueden presentarse en desarrollos AOP y las limitaciones en cuanto al soporte a las tareas de debugging que presentan en general las herramientas para desarrollos orientados a aspectos, para luego presentar una propuesta de solución y plasmar la misma dentro del framework conocido como SetPoint. Adrián Eidelman 2/148

3 Agradecimientos A Rosita y a Alan, directora y co-director de esta tesis, por su confianza y ayuda incondicional desde el primero hasta el último día de trabajo. A Rubén, por sus aportes, comentarios y sugerencias desde el viejo continente. A Silvina por su apoyo y compañía constantes durante todos estos años de carrera. A mis padres, Alicia y Mario, y mis hermanos Gabriel y Nadia. A todos aquellos que ayudaron desinteresadamente desde algún lugar del cyberespacio. A profesores, compañeros, amigos y todos los que me permitieron llegar a este momento. Adrián Eidelman 3/148

4 Tabla de Contenidos RESUMEN...2 AGRADECIMIENTOS...3 TABLA DE CONTENIDOS INTRODUCCIÓN...7 ORGANIZACIÓN DE LA TESIS LA PROGRAMACIÓN ORIENTADA A ASPECTOS...12 EL PROBLEMA DE LAS INCUMBENCIAS TRANSVERSALES...12 Ejemplificando el problema...13 UNA PROPUESTA DE SOLUCIÓN: AOP...15 Elementos distintivos del paradigma AOP...16 Otras ventajas que ofrece AOP...20 AOP vs. POO...20 RESUMEN EL PROYECTO SETPOINT...22 SETPOINT, LECTOR LECTOR, SETPOINT...22 UNA MOTIVACIÓN PARA SETPOINT: LA PARADOJA DE LA PROGRAMACIÓN AOP...23 SEMANTIC POINTCUTS Y CONCEPTOS DE LA WEB SEMÁNTICA...25 Conceptos de la Web semántica...26 Armando el rompecabezas hacia la implementación de setpoints...30 MODELO DE JOINPOINTS Y WEAVING...32 Completando el universo semántico de la aplicación...33 DECLARACIÓN DE ASPECTOS, ADVICES Y POINTCUTS...34 Pointcuts...35 Aspectos...36 Advices...37 ARQUITECTURA SETPOINT...38 RESUMEN ANTES DE CONTINUAR... QUÉ ENTENDEMOS EXACTAMENTE POR DEBUGGING?...40 BUGS, DEFECTOS Y FALLOS...40 DEBUGGING...41 DEBUGGERS...42 Estado del arte...43 ALGUNAS ACLARACIONES RELACIONADAS CON EL DEBUGGING...44 RESUMEN ESTADO DEL ARTE: INVESTIGACIONES SOBRE EL TEMA...46 TRABAJOS RELACIONADOS...46 TEMAS PENDIENTES DE INVESTIGACIÓN...48 RESUMEN DEFINICIÓN DEL PROBLEMA Y OBJETIVOS...51 POR QUÉ TESTEAR DESARROLLOS AOP ES DIFERENTE?...51 UN MODELO DE FALLAS PARA AOP...52 La naturaleza de las fallas en desarrollos AOP...53 Modelo de fallas candidato...54 DEBUGGEANDO APLICACIONES EN SETPOINT...56 Modelos de weaving...56 Información de debugging...59 Adrián Eidelman 4/148

5 Desentendimiento de las actividades propias de AOP...61 OBJETIVOS DE LA TESIS...64 RESUMEN MEJORANDO LA EXPERIENCIA DE DEBUGGING EN DESARROLLOS AOP...66 PROPIEDADES DE UNA SOLUCIÓN IDEAL DE DEBUGGING...67 Idempotencia...67 Desentendimiento...69 Intimidad...72 Dinamismo...73 Introducción de aspectos...74 Modificaciones en tiempo de ejecución...75 Aislamiento de fallas...76 Conocimiento del flujo de ejecución...77 Inmediatez...77 LA SITUACIÓN DE SETPOINT Y LAS RESTANTES PLATAFORMAS AOP...78 RESUMEN NUESTRO GRANO DE ARENA: DISEÑO E IMPLEMENTACIÓN DE LA SOLUCIÓN EN SETPOINT...82 DEFINIENDO EL ALCANCE DEL TRABAJO...82 Las propiedades a implementar...82 Debugger...83 SETPOINT V1.1: UN PRIMER ACERCAMIENTO...84 Idempotencia...85 Desentendimiento...88 Dinamismo...90 Conocimiento del flujo de ejecución...95 Síntesis de la primera experiencia...97 SETPOINT V2.0: PROPUESTA FINAL PARA ESTE TRABAJO...98 Idempotencia...98 Desentendimiento e Intimidad Conocimiento del flujo de ejecución Inmediatez Síntesis de la segunda experiencia RESUMEN UNIFICANDO CONCEPTOS: UN EJEMPLO DE APLICACIÓN DESCRIPCIÓN DE LA APLICACIÓN AOP Dimensión base y aspectos Implementación de los aspectos REALIZANDO EL DEBUGGING DE LA APLICACIÓN Debugging a nivel código fuente Controlando la dinámica de la aplicación Flujo de ejecución de aspectos Determinando el origen de la falla RESUMEN CONCLUSIONES ANEXO A EL FRAMEWORK PHOENIX VISIÓN GENERAL ARQUITECTURA DE PHOENIX MODO DUAL JERARQUÍA DE UNIDADES RESUMEN ANEXO B DIAGRAMAS DE SECUENCIA SETPOINT El algoritmo del weaver Obtención de matchpoint y política de weaving Adrián Eidelman 5/148

6 Ejecución de la RandomWeavingPolicy ANEXO C EJEMPLOS DE REPRESENTACIONES SEMÁNTICAS REPRESENTACIÓN SEMÁNTICA DE LA APLICACIÓN DOTSTACK REPRESENTACIÓN SEMÁNTICA DEL COMMON TYPE SYSTEM REFERENCIAS Adrián Eidelman 6/148

7 1. Introducción A partir de la mitad de la década de 1980 y hasta la actualidad, la POO o Programación Orientada a Objetos se ha constituido como uno de los paradigmas de programación más importantes. Las características de la POO han permitido modelar problemas complejos con gran facilidad, y hoy día el paradigma de objetos es probablemente el más utilizado a la hora de construir soluciones de software. Sin embargo, como todos los paradigmas de programación existentes, éste posee también sus puntos débiles. Este hecho ha dado lugar a la aparición de nuevas técnicas de programación, dentro de las cuales se destaca principalmente la Programación Orientada a Aspectos, también conocida como AOP por sus siglas en inglés (Aspect Oriented Programming). La Programación Orientada a Aspectos aparece como una propuesta para solucionar el problema de la separación de incumbencias transversales o crosscuting concerns, es decir, aquellas funcionalidades o cualidades del sistema que afectan a más de una clase u objeto [Kiczales et al., 1997]. Ejemplos típicos de crosscuting concerns son tracing, logging y seguridad, entre muchos otros. Generalmente, estos crosscuting concerns constituyen requerimientos no funcionales del sistema y se dispersan a lo largo de todo el código fuente 1. En la programación tradicional, ya sea mediante POO o programación procedural, la lógica principal de la aplicación se entremezcla con aspectos suplementarios o no funcionales, como los mencionados anteriormente. La propuesta de AOP se basa en permitir la modularización de estos aspectos, permitiendo a los desarrolladores construir la lógica del negocio de forma independiente a las restantes incumbencias, y luego poder relacionarlas con la ayuda automática de herramientas especialmente diseñadas para tal fin. En definitiva, lo que AOP ofrece desde la teoría- es una verdadera separación de incumbencias. Debido a la corta edad que registra la programación orientada a aspectos, y su inmadurez como técnica de desarrollo, ésta aún presenta varios desafíos que será necesario afrontar para pasar de ser una tecnología promisoria a una tecnología que se pueda utilizar en la práctica y de manera masiva a nivel industrial. Hoy 1 Algunos trabajos realizados denominan crosscuting concern a cualquier incumbencia transversal independientemente de su carácter funcional o no funcional. Consideramos que las ventajas de AOP se presentan principalmente al tomar como crosscuting concerns a los aspectos no funcionales de un sistema. Queda fuera del alcance de este trabajo entrar en una discusión sobre este tema. Adrián Eidelman 7/148

8 día, los mayores esfuerzos en investigación de este paradigma se centran en las disciplinas de análisis, diseño e implementación, y en ese sentido otras áreas de investigación han quedado relegadas. Quizás el ejemplo más concreto sea el testing. A pesar de la sabida importancia que tiene el testing en el desarrollo de soluciones informatizadas, esencial para asegurar la calidad del software, aún no se le ha prestado la atención debida en el mundo AOP y los trabajos relacionados con esta disciplina son realmente escasos. Ciertas características propias de la programación orientada a aspectos que serán abordadas a lo largo de este trabajo- hacen que las técnicas y herramientas de testing existentes en la actualidad no sean las más adecuadas para este tipo de soluciones. Encontrar técnicas y herramientas adecuadas para el desarrollo de aplicaciones AOP será sin dudas un paso fundamental e ineludible para poder construir exitosamente este tipo de soluciones. Teniendo en cuenta esta situación, con la esperanza de contribuir a la madurez de esta tecnología y conseguir herramientas prácticas que permitan desarrollar software de alta calidad, la presente tesis abordará el estudio de un tema específico dentro de la disciplina de testing: el debugging de aplicaciones. Es sabido que las herramientas modernas de debugging constituyen una parte fundamental en el desarrollo de software y seguramente son pocas las necesidades que puedan surgir al debuggear aplicaciones procedurales u orientadas a objetos y que estas herramientas no nos provean. No sucede lo mismo para AOP: las características particulares de la programación orientada a aspectos -relacionadas con la introducción del aspecto como una nueva entidad de programación, la relación e interacción entre los aspectos y los módulos tradicionales, entre otras cosas- dan lugar a nuevas fuentes de fallas en los programas, y por lo tanto resultarán en sistemas con nuevos desafíos de testing y diferentes necesidades de debugging. La gran mayoría de las herramientas AOP en la actualidad carecen de un adecuado soporte al debugging, dificultando así la tarea de diagnosticar fallas y comprender la estructura y flujo de ejecución de los programas. La posibilidad de debuggear aplicaciones AOP es crítica para la adopción de este paradigma. La intención de la presente tesis es presentar una propuesta de solución basada en propiedades de debugging que idealmente debería soportar una herramienta para desarrollos AOP, y realizar una experiencia práctica implementando aquellas Adrián Eidelman 8/148

9 funcionalidades que sean posibles de acuerdo a un análisis previo de factibilidad- dentro del framework de AOP SetPoint [Cyment & Altman, 2004] 2. Los pasos que se realizarán a lo largo del trabajo serán: 1. Se analizarán las fuentes de fallas que introduce la programación orientada a aspectos, particulares de este paradigma. 2. A partir del modelo de fallas planteado, y a los trabajos existentes sobre el tema, se presentarán las propiedades de debugging que debería brindar idealmente cualquier herramienta para desarrollos AOP. 3. En base a los dos puntos anteriores, se analizará qué facilidades de debugging ofrece hoy en día el framework para AOP SetPoint, y se establecerá una meta previo análisis de factibilidad- para mejorar la situación actual. 4. Se diseñaran y construirán las propiedades propuestas para el framework AOP SetPoint, describiendo de qué manera estas nuevas funcionalidades del framework facilitan la experiencia de debugging. 5. Finalmente, se expondrán las conclusiones del trabajo, intentando sentar las bases para nuevas técnicas de debugging para herramientas AOP. Organización de la tesis El trabajo se encuentra dividido en una serie de capítulos, los cuales se describen brevemente a continuación: 1. Introducción: presenta el problema y temas a ser tratados en el trabajo. 2. La Programación Orientada a Aspectos: realiza una introducción al paradigma AOP, sus conceptos principales y objetivos. 3. El proyecto SetPoint: introduce el proyecto SetPoint y sus características salientes, destacando aquellos que estén directamente relacionados con el tema de esta tesis. 4. Antes de continuar qué entendemos exactamente por debugging?: explica qué es el debugging y las diferentes técnicas existentes. Presenta 2 El proyecto SetPoint será descrito en profundidad más adelante en este trabajo. Adrián Eidelman 9/148

10 aclaraciones acerca de conceptos erróneos comúnmente utilizados sobre la actividad. 5. Estado del arte: Investigaciones sobre el tema: describe los trabajos de investigación relacionados con el tema abordado en la presente tesis y presenta los temas pendientes de resolución relacionados con el aseguramiento de la calidad en desarrollos orientados a aspectos. 6. Definición del problema y objetivos: describe en detalle un modelo de fallas para AOP y las limitaciones al debugging existentes en SetPoint muchas veces presentes en otras plataformas-, los cuales sientan las bases para determinar las necesidades de debugging de para una herramienta de desarrollo AOP. De acuerdo al problema planteado se definen formalmente en este capítulo los objetivos de la tesis. 7. Mejorando la experiencia de debugging en desarrollos AOP: presenta una propuesta de mejora basada en una serie de propiedades que debería brindar una solución ideal de debugging para AOP. En base a las propiedades planteadas se presenta la situación de SetPoint y otras herramientas de desarrollo, reflejando el estado de situación actual en relación al soporte de debugging. 8. Nuestro grano de arena: diseño e implementación de la solución en SetPoint: describe la implementación en SetPoint de cada una de las funcionalidades construidas para dar soporte a las propiedades alcanzadas dentro del trabajo, presentando los problemas y limitaciones encontradas. Compara la situación final de la herramienta en relación a su versión anterior. 9. Unificando conceptos: un ejemplo de aplicación: presenta mediante un ejemplo sencillo cómo se puede realizar la actividad de debugging en SetPoint haciendo uso de los avances alcanzados en este trabajo 10. Conclusiones: presenta los aspectos salientes del trabajo realizado proponiendo a la vez futuras líneas de investigación relacionadas. 11. Anexo A El framework Phoenix: introduce las características más importantes de la herramienta. 12. Anexo B Diagramas de secuencia SetPoint: presenta los diagramas de secuencia actualizados correspondientes a las actividades de weaving en SetPoint. Adrián Eidelman 10/148

11 13. Anexo C Ejemplos de representaciones semánticas: presenta ejemplos de ontologías con el fin de profundizar el concepto de pointcuts semánticos. Adrián Eidelman 11/148

12 2. La Programación Orientada a Aspectos La Programación Orientada a Aspectos como nueva técnica de programación se encuadra dentro de lo que se conoce de manera genérica como POP o Post-Object Programming [Elrad et al., 2001b]. La Programación Orientada a Objetos, a pesar de ser el paradigma de programación dominante en la actualidad, posee limitaciones que han dado origen a esta nueva generación de técnicas. Hemos mencionado que AOP propone desde la teoría una real separación de incumbencias. Ahora bien... cuál es el problema con POO? Qué es en definitiva AOP? Cómo propone solucionar el problema de las incumbencias transversales? AOP reemplaza POO? El presente capítulo intentará aclarar todas estas preguntas. El problema de las incumbencias transversales La programación orientada a objetos nos ha permitido desarrollar aplicaciones complejas: interfaces gráficas, sistemas operativos y aplicaciones distribuidas son sólo unos pocos ejemplos de lo que se ha podido construir utilizando POO. Sin embargo, el éxito en desarrollar este tipo de sistemas nos lleva a querer desarrollar sistemas aún más complejos, y es ahí donde surgen necesidades de nuevas técnicas y herramientas que nos permitan hacerlo. POO es una excelente idea, pero también tiene sus limitaciones: si uno se detiene a analizar la implementación en código de una solución, es posible observar que muchos requerimientos no se descomponen claramente en una unidad que agrupe esos comportamientos. La orientación a objetos presenta dificultades al intentar agrupar o localizar estos requerimientos [Kiczales et al., 1997; Elrad et al., 2001b], que en la generalidad de los casos tienden a ser requerimientos suplementarios o no funcionales. Por el contrario, estos requerimientos se encuentran dispersos a lo largo de todo el código, de forma transversal, generando de esta forma un código de mayor complejidad y más difícil comprensión. Adrián Eidelman 12/148

13 Ejemplificando el problema Supongamos que nos piden construir un sistema para un estudio jurídico y, como parte de éste, modelamos utilizando los conceptos de la orientación a objetoslas siguientes clases: Abogado, Pasante y Secretaria. Entre los tantos requerimientos que nos solicitan deberemos brindar la posibilidad de enviar mensajes entre estos tres actores. Una modelización posible es la que muestra la Figura 2-1. Empleado Abogado Secretaria Pasante -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-1: Modelo de la solución para el estudio jurídico Dado que los mensajes enviados por abogados y secretarias pueden contener información crítica, nos solicitan además que todo mensaje enviado por alguno de estos actores deberá ser encriptado previo a su envío. Por supuesto accedemos al pedido y, dentro de la operación enviarmensaje de las clases Abogado y Secretaria, agregamos la siguiente línea de código: private void Abogado.enviarMensaje(string mensaje) {... string mensajeencriptado = encriptar(mensaje);... } Por supuesto nuestro modelo no ha sido alterado, pero ahora existe una particularidad en el código: las operaciones de envío de mensaje de las clases Abogado y Secretaria incluyen la encriptación de los mismos y, como se ilustra en la Figura 2-2, esta funcionalidad de encriptación se encuentra ahora dispersa a lo Adrián Eidelman 13/148

14 largo de más de una clase. En conclusión: la encriptación, en este modelo, constituye una incumbencia transversal o crosscuting concern [Kiczales et al., 1997]. Empleado Abogado Secretaria Pasante Encriptación -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-2: La encriptación de datos constituye una incumbencia transversal Existe además otra característica, producida por la aparición de esta incumbencia transversal, que no hemos mencionado aún. Las clases Abogado y Secretaria, que originalmente fueron diseñadas para resolver aspectos funcionales del estudio jurídico, se entremezclan ahora con aspectos secundarios al dominio del problema, como es en este caso la funcionalidad de encriptación. En resumen, son dos los efectos no deseables producto de la existencia de incumbencias transversales: el primero de los efectos mencionados, en donde el código correspondiente a una incumbencia no es encapsulado en un único módulo sino que se dispersa en varios puntos del programa, es conocido como Code Scattering. El segundo de los efectos, en donde en un mismo módulo encontramos código correspondiente a distintas incumbencias, se conoce con el nombre de Code Tangling [Kiczales et al., 1997] (Figura 2-3). El code scattering y el code tangling producen como consecuencia un código más complejo y complicado de entender y mantener. Puede argumentarse que la solución planteada en este ejemplo puede no ser la mejor. Es cierto que existen soluciones más elegantes al problema, probablemente mediante la especialización de las clases o el uso de patrones de diseño. No es intención del presente trabajo profundizar en esta discusión, sin embargo, como se explica en diversos trabajos relacionados, el problema sigue Adrián Eidelman 14/148

15 existiendo más allá del ejemplo que se utilice [Dedecker, 2002; Cyment & Altman, 2004]. Empleado Code Tangling Abogado Secretaria Pasante Code Scattering -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-3: Code Scattering y Code Tangling Una propuesta de solución: AOP La programación orientada a aspectos centra su propuesta en la idea de que es conveniente construir un sistema especificando las diferentes incumbencias del problema de manera separada e independientes unas de otras, y luego utilizar mecanismos propios del entorno de desarrollo para relacionarlas de forma de obtener un programa coherente. AOP introduce para esto una nueva unidad de modularización, denominada aspecto, la cual tiene como objetivo encapsular las incumbencias transversales. Basándose en esta propuesta, existirá una dimensión base del problema y otras que la cruzan, representadas por estos aspectos [Cyment & Altman, 2004]. Si suscribimos a la idea de asociar los aspectos con requerimientos no funcionales del sistema como puede ser logging, persistencia, transaccionabilidad, entre otros- entonces la dimensión base se corresponderá con la lógica del negocio, mientras que la dimensión de aspectos conformará los requerimientos suplementarios del sistema. Si logramos modularizar por un lado al negocio, y por separado a cada una de las incumbencias transversales, entonces desde la teoría- estaremos solucionando el problema del code scattering y el code tangling. Más aún, el programador de una dimensión del problema podrá ser capaz de desentenderse de las demás dimensiones y concentrarse sólo en aquella Adrián Eidelman 15/148

16 que le interesa, propiedad que se conoce con el nombre de obliviousness [Filman & Friedman, 2000]. Volviendo por un momento al ejemplo del abogado y la secretaria, quizás la tendencia en POO hubiese sido la de agrupar las funcionalidades comunes entre las clases en este caso la funcionalidad de encriptación- y empujarlas hacia arriba en el diagrama de clases, de forma de localizar el código de encriptar exclusivamente en la clase Empleado 3. AOP en cambio intenta tomar la incumbencia como un elemento de primera clase, y expulsarla horizontalmente de la estructura de clases, tal como se ilustra en la Figura 2-4. Empleado Encriptación Aspecto de Encriptación Abogado Secretaria Pasante -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-4: AOP modulariza las incumbencias transversales en unidades llamadas aspectos Modularizando las incumbencias de esta forma, AOP ofrece -desde la teoría- una real separación de incumbencias. Elementos distintivos del paradigma AOP 4 Hemos visto hasta el momento qué propone AOP como objetivo principal, analizando el problema de las incumbencias transversales. Esto no aclara de todas maneras de qué forma la programación orientada a aspectos lo trata de solucionar. Intentaremos comprender, mediante la presentación de los elementos 3 Si se analiza un poco más en detalle esta solución, llegará a la conclusión que el problema de code tangling no se resuelve de esta manera. 4 No existe un real consenso dentro de la comunidad sobre si AOP es en realidad un nuevo paradigma o no. Sí existe una visión común acerca de que constituye una evolución lógica en el desarrollo de software, especialmente para desarrollos orientados a objetos. Esta discusión escapa los alcances de este trabajo, a pesar que utilizaremos el término a lo largo del mismo. Adrián Eidelman 16/148

17 distintivos del paradigma, cómo es que AOP logra modularizar estas incumbencias. JoinPoints, Pointcuts y Advices Mediante el uso de AOP podemos modularizar las incumbencias transversales de forma independiente, y así contar con una dimensión base del problema por un lado y otras dimensiones que lo cruzan por otro lado. En dónde se intersecan estos dos mundos? Los puntos en la ejecución de un programa donde es posible aplicar la lógica de un aspecto se denominan joinpoints. Cada plataforma AOP posee su definición particular de cuáles son los puntos de ejecución que pueden conformar un joinpoint, aunque generalmente éstos están constituidos por llamadas a métodos, accesos a propiedades de un objeto o creaciones de objetos. La definición de joinpoint no basta para completar el modelo. Es necesario contar con algún mecanismo que nos permita decir qué aspecto se debe aplicar en determinado joinpoint. Expresándolo de una manera un poco más formal, necesitamos poder predicar sobre los joinpoints para definir su pertenencia o no a un conjunto, y así definir los aspectos que deben ejecutarse en tales puntos del programa. La forma que tenemos de predicar sobre los joinpoints es denominada cuantificación [Filman & Friedman, 2000] y su implementación será también particular de cada plataforma. Mediante la facilidad de cuantificación que nos provea la herramienta AOP que utilicemos será posible definir una serie de joinpoints para luego aplicar aspectos sobre tal conjunto. El nombre que se le da a un conjunto definido de joinpoints es pointcut. Finalmente, se denomina advice a la entidad que permite definir qué aspecto se debe ejecutar en todos los joinpoints pertenecientes a un pointcut. A partir de estas tres entidades presentadas, la idea de cómo funciona AOP empieza a quedar un poco más clara. Trataremos de aplicar estos nuevos conceptos al ejemplo antes presentado 5 : De acuerdo a lo expresado anteriormente, tenemos una dimensión base del problema compuesta por la lógica de negocio del estudio jurídico y otra dimensión 5 El ejemplo utiliza los conceptos de forma general, sin entrar en detalles de implementación o referenciando a alguna herramienta AOP en particular. Adrián Eidelman 17/148

18 transversal compuesta por el aspecto de encriptación 6. Necesitamos, de acuerdo a lo solicitado por nuestro cliente, que los envíos de mensaje que realizan tanto un abogado como una secretaria sean encriptados previos a su transmisión. Suponiendo que contamos con una plataforma AOP en la que las llamadas a métodos pueden constituir un joinpoint deben ser contados los casos de herramientas en los cuales esto no es así, si efectivamente existe alguna que no lo permita- podríamos decidir aplicar el aspecto de encriptación a todas las llamadas al método enviarmensaje de instancias de las clases Abogado y Secretaria. Para eso debemos definir el pointcut que incluya a todos esos puntos de ejecución, por ejemplo de la siguiente manera: Pointcut mensajessensibles { todas las llamadas al método enviarmensaje de instancias de las clases Abogado o Secretaria } Resta definir un advice que indique que se debe aplicar el aspecto de encriptación en todos los joinpoints del pointcut mensajessensibles. Esto podría realizarse de la siguiente manera: Advice encriptarmensajessensibles { aplicar el aspecto Encriptación al pointcut mensajessensibles } De acuerdo a las definiciones de pointcuts, aspectos y advices que se realicen, la plataforma AOP deberá encargarse de relacionar todos estos elementos con el objetivo de obtener como resultado un sistema que funcione idénticamente a como lo haría si hubiésemos optado por mecanismos tradicionales de programación. En definitiva, esta modularización en aspectos tiene por objetivo facilitar la construcción y entendimiento del software, mientras que el resultado que deseamos obtener desde un punto de vista de la ejecución del mismo no 6 Lógicamente podrán existir más aspectos aparte del de encriptación. Se toma este solo para simplificar el ejemplo. Adrián Eidelman 18/148

19 varía con respecto a los restantes paradigmas. El proceso por el cual se combinan la dimensión base con las restantes dimensiones del problema se denomina weaving, término que en castellano significa entretejido. Weaving El weaving es el proceso que se encarga de que se ejecuten los aspectos que corresponden durante la ejecución del programa, de acuerdo a los advices que se hayan definido. Denominaremos al componente que realiza el proceso de weaving con el nombre de weaver. Lógicamente este proceso debe valerse de mecanismos automáticos provistos por la plataforma AOP, de forma que sea, en la mayor medida posible, invisible para el programador. Como ejemplifica la Figura 2-5, el proceso de weaving integra la dimensión base en este caso la lógica de negocio del estudio jurídico- con las dimensiones transversales encapsuladas en aspectos. SISTEMA DE ESTUDIO JURÍDICO Encriptación Visualización... weaving weaving weaving Logging weaving Abogados, Secretarias, Legajos, Escritos... weaving Persistencia weaving weaving weaving Caching Tracing Seguridad Figura 2-5: El proceso de weaving Adrián Eidelman 19/148

20 El proceso de weaving es un tema central no sólo a la programación orientada a aspectos, sino también en particular al debugging en plataformas AOP por lo que será abordado en mayor detalle a lo largo del trabajo. Otras ventajas que ofrece AOP Además de la claridad en el desarrollo que persigue la programación orientada a aspectos, podemos mencionar otras ventajas que ofrece esta técnica de programación: Reutilización de aspectos: el tener las incumbencias transversales modularizadas nos da la posibilidad de reutilizar la lógica de los aspectos en otros desarrollos. Esto se puede tornar sumamente complicado si las funcionalidades se encuentran dispersas a lo largo del código fuente. Utilización de aspectos en sistemas legacy: la independencia que poseen los aspectos de la dimensión base facilitan la incorporación de funcionalidades a sistemas de los cuales no se posee conocimiento y por lo tanto sería sumamente complicado modificar el código para lograrlo. Incluso en plataformas AOP que no se valen del código fuente para lograr el weaving, esto es posible de realizar precisamente sin la existencia del código. AOP vs. POO Es importante, para cerrar la idea de la programación orientada a aspectos, entender un último concepto: el objetivo de AOP no es reemplazar POO. Todo lo contrario, AOP se construye por sobre POO, tratando de conseguir la separación de las incumbencias que POO no logra modularizar. Al programar en AOP, se siguen utilizando objetos, métodos, atributos y todos los elementos distintivos de la programación orientada a objetos. Es cierto también que las ideas centrales que propone el paradigma pueden aplicarse de la misma manera a otros paradigmas como el imperativo o el funcional, sin embargo existe una relación mucho más cercana con POO, básicamente por el uso de clases y objetos o la asociación de joinpoints con llamadas a métodos, entre otros. Adrián Eidelman 20/148