Hacia Una Mejor Experiencia de Debugging en Desarrollos AOP

TESIS DE GRADO EN INGENIERA INFORMTICA
Hacia una mejor experiencia de debugging en desarrollos AOP
FACULTAD DE INGENIERA UNIVERSIDAD DE BUENOS AIRES
TESISTA: Adrin EIDELMAN DIRECTORA: Lic. Rosa WACHENCHAUZER CO-DIRECTOR: Lic. Alan CYMENT
NOVIEMBRE 2006
FIUBA
Resumen
Las limitaciones que presenta la Programacin Orientada a Objetos para encapsular las incumbencias transversales en un desarrollo de software han dado origen a nuevas tcnicas de programacin, entre las cuales se ha destacado en los ltimos aos la Programacin Orientada a Aspectos (AOP). AOP introduce una nueva unidad de modularizacin denominada aspecto, que tiene el fin de encapsular estas funcionalidades transversales y mejorar as la comprensin y mantenibilidad de las aplicaciones. A partir de la introduccin del aspecto como unidad de modularizacin, AOP a su vez incorpora nuevas fuentes de fallas y por lo tanto nuevos desafos 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 atencin 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 caractersticas 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 solucin y plasmar la misma dentro del framework conocido como SetPoint.
Adrin Eidelman
2/148
FIUBA
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 da de trabajo. A Rubn, por sus aportes, comentarios y sugerencias desde el viejo continente. A Silvina por su apoyo y compaa constantes durante todos estos aos de carrera. A mis padres, Alicia y Mario, y mis hermanos Gabriel y Nadia. A todos aquellos que ayudaron desinteresadamente desde algn lugar del cyberespacio. A profesores, compaeros, amigos y todos los que me permitieron llegar a este momento.
Adrin Eidelman
3/148
FIUBA
Tabla de Contenidos
RESUMEN ..............................................................................................................................................2 AGRADECIMIENTOS .........................................................................................................................3 TABLA DE CONTENIDOS ..................................................................................................................4 1. 2. INTRODUCCIN ........................................................................................................................7 ORGANIZACIN DE LA TESIS .................................................................................................................9 LA PROGRAMACIN ORIENTADA A ASPECTOS...........................................................12 EL PROBLEMA DE LAS INCUMBENCIAS TRANSVERSALES.....................................................................12 Ejemplificando el problema ..........................................................................................................13 UNA PROPUESTA DE SOLUCIN: AOP.................................................................................................15 Elementos distintivos del paradigma AOP ...................................................................................16 Otras ventajas que ofrece AOP.....................................................................................................20 AOP vs. POO ................................................................................................................................20 RESUMEN ...........................................................................................................................................21 3. EL PROYECTO SETPOINT ....................................................................................................22 SETPOINT, LECTOR LECTOR, SETPOINT ......................................................................................22 UNA MOTIVACIN PARA SETPOINT: LA PARADOJA DE LA PROGRAMACIN AOP ...............................23 SEMANTIC POINTCUTS Y CONCEPTOS DE LA WEB SEMNTICA ............................................................25 Conceptos de la Web semntica....................................................................................................26 Armando el rompecabezas hacia la implementacin de setpoints................................................30 MODELO DE JOINPOINTS Y WEAVING .................................................................................................32 Completando el universo semntico de la aplicacin...................................................................33 DECLARACIN DE ASPECTOS, ADVICES Y POINTCUTS .........................................................................34 Pointcuts .......................................................................................................................................35 Aspectos ........................................................................................................................................36 Advices ..........................................................................................................................................37 ARQUITECTURA SETPOINT .................................................................................................................38 RESUMEN ...........................................................................................................................................39 4. 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 ...........................................................................................................................................45 5. ESTADO DEL ARTE: INVESTIGACIONES SOBRE EL TEMA .......................................46 TRABAJOS RELACIONADOS .................................................................................................................46 TEMAS PENDIENTES DE INVESTIGACIN .............................................................................................48 RESUMEN ...........................................................................................................................................50 6. DEFINICIN 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 Informacin de debugging ............................................................................................................59
Adrin Eidelman
4/148
FIUBA
Desentendimiento de las actividades propias de AOP..................................................................61 OBJETIVOS DE LA TESIS ......................................................................................................................64 RESUMEN ...........................................................................................................................................64 7. MEJORANDO LA EXPERIENCIA DE DEBUGGING EN DESARROLLOS AOP ..........66 PROPIEDADES DE UNA SOLUCIN IDEAL DE DEBUGGING.....................................................................67 Idempotencia.................................................................................................................................67 Desentendimiento..........................................................................................................................69 Intimidad.......................................................................................................................................72 Dinamismo ....................................................................................................................................73 Introduccin de aspectos ..............................................................................................................74 Modificaciones en tiempo de ejecucin ........................................................................................75 Aislamiento de fallas.....................................................................................................................76 Conocimiento del flujo de ejecucin .............................................................................................77 Inmediatez.....................................................................................................................................77 LA SITUACIN DE SETPOINT Y LAS RESTANTES PLATAFORMAS AOP .................................................78 RESUMEN ...........................................................................................................................................80 8. NUESTRO GRANO DE ARENA: DISEO E IMPLEMENTACIN DE LA SOLUCIN 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 ejecucin .............................................................................................95 Sntesis de la primera experiencia ................................................................................................97 SETPOINT V2.0: PROPUESTA FINAL PARA ESTE TRABAJO ...............................................................98 Idempotencia.................................................................................................................................98 Desentendimiento e Intimidad ....................................................................................................102 Conocimiento del flujo de ejecucin ...........................................................................................103 Inmediatez...................................................................................................................................105 Sntesis de la segunda experiencia..............................................................................................109 RESUMEN .........................................................................................................................................110 9. UNIFICANDO CONCEPTOS: UN EJEMPLO DE APLICACIN ...................................111 DESCRIPCIN DE LA APLICACIN AOP.............................................................................................111 Dimensin base y aspectos .........................................................................................................111 Implementacin de los aspectos..................................................................................................112 REALIZANDO EL DEBUGGING DE LA APLICACIN ..............................................................................114 Debugging a nivel cdigo fuente ................................................................................................114 Controlando la dinmica de la aplicacin..................................................................................117 Flujo de ejecucin de aspectos ...................................................................................................119 Determinando el origen de la falla .............................................................................................121 RESUMEN .........................................................................................................................................122 10. CONCLUSIONES................................................................................................................124 ANEXO A EL FRAMEWORK PHOENIX ..................................................................................127 VISIN GENERAL ..............................................................................................................................127 ARQUITECTURA DE PHOENIX............................................................................................................128 MODO DUAL .....................................................................................................................................129 JERARQUA DE UNIDADES .................................................................................................................129 RESUMEN .........................................................................................................................................130 ANEXO B DIAGRAMAS DE SECUENCIA SETPOINT ...........................................................132 El algoritmo del weaver..............................................................................................................132 Obtencin de matchpoint y poltica de weaving .........................................................................134
Adrin Eidelman
5/148
FIUBA
Ejecucin de la RandomWeavingPolicy .....................................................................................136 ANEXO C EJEMPLOS DE REPRESENTACIONES SEMNTICAS .....................................137 REPRESENTACIN SEMNTICA DE LA APLICACIN DOTSTACK.........................................................137 REPRESENTACIN SEMNTICA DEL COMMON TYPE SYSTEM ...........................................................142 REFERENCIAS .................................................................................................................................145
Adrin Eidelman
6/148
FIUBA
1. Introduccin
A partir de la mitad de la dcada de 1980 y hasta la actualidad, la POO o Programacin Orientada a Objetos se ha constituido como uno de los paradigmas de programacin ms importantes. Las caractersticas de la POO han permitido modelar problemas complejos con gran facilidad, y hoy da el paradigma de objetos es probablemente el ms utilizado a la hora de construir soluciones de software. Sin embargo, como todos los paradigmas de programacin existentes, ste posee tambin sus puntos dbiles. Este hecho ha dado lugar a la aparicin de nuevas tcnicas de programacin, dentro de las cuales se destaca principalmente la Programacin Orientada a Aspectos, tambin conocida como AOP por sus siglas en ingls (Aspect Oriented Programming). La Programacin Orientada a Aspectos aparece como una propuesta para solucionar el problema de la separacin de incumbencias transversales o crosscuting concerns, es decir, aquellas funcionalidades o cualidades del sistema que afectan a ms de una clase u objeto [Kiczales et al., 1997]. Ejemplos tpicos 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 cdigo fuente1. En la programacin tradicional, ya sea mediante POO o programacin procedural, la lgica principal de la aplicacin se entremezcla con aspectos suplementarios o no funcionales, como los mencionados anteriormente. La propuesta de AOP se basa en permitir la modularizacin de estos aspectos, permitiendo a los desarrolladores construir la lgica del negocio de forma independiente a las restantes incumbencias, y luego poder relacionarlas con la ayuda automtica de herramientas especialmente diseadas para tal fin. En definitiva, lo que AOP ofrece desde la teora- es una verdadera separacin de incumbencias. Debido a la corta edad que registra la programacin orientada a aspectos, y su inmadurez como tcnica de desarrollo, sta an presenta varios desafos que ser necesario afrontar para pasar de ser una tecnologa promisoria a una tecnologa que se pueda utilizar en la prctica y de manera masiva a nivel industrial. Hoy Algunos trabajos realizados denominan crosscuting concern a cualquier incumbencia transversal independientemente de su carcter 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 discusin sobre este tema.
1
Adrin Eidelman
7/148
FIUBA
da, los mayores esfuerzos en investigacin de este paradigma se centran en las disciplinas de anlisis, diseo e implementacin, y en ese sentido otras reas de investigacin han quedado relegadas. Quizs el ejemplo ms 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, an no se le ha prestado la atencin debida en el mundo AOP y los trabajos relacionados con esta disciplina son realmente escasos. Ciertas caractersticas propias de la programacin orientada a aspectos que sern abordadas a lo largo de este trabajo- hacen que las tcnicas y herramientas de testing existentes en la actualidad no sean las ms adecuadas para este tipo de soluciones. Encontrar tcnicas 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 situacin, con la esperanza de contribuir a la madurez de esta tecnologa y conseguir herramientas prcticas que permitan desarrollar software de alta calidad, la presente tesis abordar el estudio de un tema especfico 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 caractersticas particulares de la programacin orientada a aspectos -relacionadas con la introduccin del aspecto como una nueva entidad de programacin, la relacin e interaccin entre los aspectos y los mdulos tradicionales, entre otras cosas- dan lugar a nuevas fuentes de fallas en los programas, y por lo tanto resultarn en sistemas con nuevos desafos de testing y diferentes necesidades de debugging. La gran mayora 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 ejecucin de los programas. La posibilidad de debuggear aplicaciones AOP es crtica para la adopcin de este paradigma. La intencin de la presente tesis es presentar una propuesta de solucin basada en propiedades de debugging que idealmente debera soportar una herramienta para desarrollos AOP, y realizar una experiencia prctica implementando aquellas
Adrin Eidelman
8/148
FIUBA
funcionalidades que sean posibles de acuerdo a un anlisis previo de factibilidaddentro del framework de AOP SetPoint [Cyment & Altman, 2004]2. Los pasos que se realizarn a lo largo del trabajo sern: 1. Se analizarn las fuentes de fallas que introduce la programacin orientada a aspectos, particulares de este paradigma. 2. A partir del modelo de fallas planteado, y a los trabajos existentes sobre el tema, se presentarn las propiedades de debugging que debera brindar idealmente cualquier herramienta para desarrollos AOP. 3. En base a los dos puntos anteriores, se analizar qu facilidades de debugging ofrece hoy en da el framework para AOP SetPoint, situacin actual. 4. Se disearan y construirn 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 expondrn las conclusiones del trabajo, intentando sentar las bases para nuevas tcnicas de debugging para herramientas AOP. y se establecer una meta previo anlisis de factibilidad- para mejorar la
Organizacin de la tesis
El trabajo se encuentra dividido en una serie de captulos, los cuales se describen brevemente a continuacin: 1. Introduccin: presenta el problema y temas a ser tratados en el trabajo. 2. La Programacin Orientada a Aspectos: realiza una introduccin al paradigma AOP, sus conceptos principales y objetivos. 3. El proyecto SetPoint: introduce el proyecto SetPoint y sus caractersticas salientes, destacando aquellos que estn 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 tcnicas existentes. Presenta
El proyecto SetPoint ser descrito en profundidad ms adelante en este trabajo.
Adrin Eidelman
9/148
FIUBA
aclaraciones acerca de conceptos errneos comnmente utilizados sobre la actividad. 5. Estado del arte: Investigaciones sobre el tema: describe los trabajos de investigacin relacionados con el tema abordado en la presente tesis y presenta los temas pendientes de resolucin relacionados con el aseguramiento de la calidad en desarrollos orientados a aspectos. 6. Definicin 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 captulo 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 debera brindar una solucin ideal de debugging para AOP. En base a las propiedades planteadas se presenta la situacin de SetPoint y otras herramientas de desarrollo, reflejando el estado de situacin actual en relacin al soporte de debugging. 8. Nuestro grano de arena: diseo e implementacin de la solucin en SetPoint: describe la implementacin 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 situacin final de la herramienta en relacin a su versin anterior. 9. Unificando conceptos: un ejemplo de aplicacin: presenta mediante un ejemplo sencillo cmo 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 lneas de investigacin relacionadas. 11. Anexo A El framework Phoenix: introduce las caractersticas ms 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.
Adrin Eidelman
10/148
FIUBA
13. Anexo C Ejemplos de representaciones semnticas: presenta ejemplos de ontologas con el fin de profundizar el concepto de pointcuts semnticos.
Adrin Eidelman
11/148
FIUBA
2. La Programacin Orientada a Aspectos

La Programacin Orientada a Aspectos como nueva tcnica de programacin se encuadra dentro de lo que se conoce de manera genrica como POP o Post-Object Programming [Elrad et al., 2001b]. La Programacin Orientada a Objetos, a pesar de ser el paradigma de programacin dominante en la actualidad, posee limitaciones que han dado origen a esta nueva generacin de tcnicas. Hemos mencionado que AOP propone desde la teora una real separacin de incumbencias. Ahora bien... cul es el problema con POO? Qu es en definitiva AOP? Cmo propone solucionar el problema de las incumbencias transversales? AOP reemplaza POO? El presente captulo intentar aclarar todas estas preguntas.
El problema de las incumbencias transversales

La programacin orientada a objetos nos ha permitido desarrollar aplicaciones complejas: interfaces grficas, sistemas operativos y aplicaciones distribuidas son slo 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 an ms complejos, y es ah donde surgen necesidades de nuevas tcnicas y herramientas que nos permitan hacerlo. POO es una excelente idea, pero tambin tiene sus limitaciones: si uno se detiene a analizar la implementacin en cdigo de una solucin, es posible observar que muchos requerimientos no se descomponen claramente en una unidad que agrupe esos comportamientos. La orientacin 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 cdigo, de forma transversal, generando de esta forma un cdigo de mayor complejidad y ms difcil comprensin.
Adrin Eidelman
12/148
FIUBA
Ejemplificando el problema
Supongamos que nos piden construir un sistema para un estudio jurdico y, como parte de ste, modelamos utilizando los conceptos de la orientacin 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 modelizacin posible es la que muestra la
Figura 2-1.
Empleado
Abogado -enviarMensaje()
Secretaria -enviarMensaje()
Pasante -enviarMensaje()
Figura 2-1: Modelo de la solucin para el estudio jurdico
Dado que los mensajes enviados por abogados y secretarias pueden contener informacin crtica, nos solicitan adems que todo mensaje enviado por alguno de estos actores deber ser encriptado previo a su envo. Por supuesto accedemos al pedido y, dentro de la operacin enviarMensaje de las clases Abogado y Secretaria, agregamos la siguiente lnea de cdigo: 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 cdigo: las operaciones de envo de mensaje de las clases Abogado y Secretaria incluyen la encriptacin de los mismos y, como se ilustra en la Figura 2-2, esta funcionalidad de encriptacin se encuentra ahora dispersa a lo
Adrin Eidelman
13/148
FIUBA
largo de ms de una clase. En conclusin: la encriptacin, en este modelo, constituye una incumbencia transversal o crosscuting concern [Kiczales et al., 1997].
Empleado
Abogado
Encriptacin
-enviarMensaje()
Figura 2-2: La encriptacin de datos constituye una incumbencia transversal
Existe adems otra caracterstica, producida por la aparicin de esta incumbencia transversal, que no hemos mencionado an. Las clases Abogado y Secretaria, que originalmente fueron diseadas para resolver aspectos funcionales del estudio jurdico, se entremezclan ahora con aspectos secundarios al dominio del problema, como es en este caso la funcionalidad de encriptacin. En resumen, son dos los efectos no deseables producto de la existencia de incumbencias transversales: el primero de los efectos mencionados, en donde el cdigo correspondiente a una incumbencia no es encapsulado en un nico mdulo sino que se dispersa en varios puntos del programa, es conocido como Code Scattering. El segundo de los efectos, en donde en un mismo mdulo encontramos cdigo 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 cdigo ms complejo y complicado de entender y mantener. Puede argumentarse que la solucin planteada en este ejemplo puede no ser la mejor. Es cierto que existen soluciones ms elegantes al problema, probablemente mediante la especializacin de las clases o el uso de patrones de diseo. No es intencin del presente trabajo profundizar en esta discusin, sin embargo, como se explica en diversos trabajos relacionados, el problema sigue
Adrin Eidelman
14/148
FIUBA
existiendo ms all del ejemplo que se utilice [Dedecker, 2002; Cyment & Altman, 2004].
Empleado
Code Tangling
Abogado Secretaria -enviarMensaje() Pasante -enviarMensaje()
Code Scattering
-enviarMensaje()
Figura 2-3: Code Scattering y Code Tangling
Una propuesta de solucin: AOP

La programacin 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 modularizacin, denominada aspecto, la cual tiene como objetivo encapsular las incumbencias transversales. Basndose en esta propuesta, existir una dimensin 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 dimensin base se corresponder con la lgica del negocio, mientras que la dimensin 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 teora- estaremos solucionando el problema del code scattering y el code tangling. Ms an, el programador de una dimensin del problema podr ser capaz de desentenderse de las dems dimensiones y concentrarse slo en aquella
Adrin Eidelman
15/148
FIUBA
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, quizs la tendencia en POO hubiese sido la de agrupar las funcionalidades comunes entre las clases en este caso la funcionalidad de encriptacin- y empujarlas hacia arriba en el diagrama de clases, de forma de localizar el cdigo de encriptar exclusivamente en la clase Empleado3. 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 Encriptacin
Aspecto de Encriptacin
Abogado -enviarMensaje()
Figura 2-4: AOP modulariza las incumbencias transversales en unidades llamadas aspectos
Modularizando las incumbencias de esta forma, AOP ofrece -desde la teora- una real separacin de incumbencias.
Elementos distintivos del paradigma AOP4

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 programacin orientada a aspectos lo trata de solucionar. Intentaremos comprender, mediante la presentacin de los elementos
Si se analiza un poco ms en detalle esta solucin, llegar a la conclusin 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 visin comn acerca de que constituye una evolucin lgica en el desarrollo de software, especialmente para desarrollos orientados a objetos. Esta discusin escapa los alcances de este trabajo, a pesar que utilizaremos el trmino a lo largo del mismo.
Adrin Eidelman
16/148
FIUBA
distintivos
del
paradigma,
cmo
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 dimensin base del problema por un lado y otras dimensiones que lo cruzan por otro lado. En dnde se intersecan estos dos mundos? Los puntos en la ejecucin de un programa donde es posible aplicar la lgica de un aspecto se denominan joinpoints. Cada plataforma AOP posee su definicin particular de cules son los puntos de ejecucin que pueden conformar un joinpoint, aunque generalmente stos estn constituidos por llamadas a mtodos, accesos a propiedades de un objeto o creaciones de objetos. La definicin de joinpoint no basta para completar el modelo. Es necesario contar con algn mecanismo que nos permita decir qu aspecto se debe aplicar en determinado joinpoint. Expresndolo de una manera un poco ms 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 cuantificacin [Filman & Friedman, 2000] y su implementacin ser tambin particular de cada plataforma. Mediante la facilidad de cuantificacin 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 cmo funciona AOP empieza a quedar un poco ms clara. Trataremos de aplicar estos nuevos conceptos al ejemplo antes presentado5: De acuerdo a lo expresado anteriormente, tenemos una dimensin base del problema compuesta por la lgica de negocio del estudio jurdico y otra dimensin
El ejemplo utiliza los conceptos de forma general, sin entrar en detalles de implementacin o referenciando a alguna herramienta AOP en particular.
Adrin Eidelman
17/148
FIUBA
transversal compuesta por el aspecto de encriptacin6. Necesitamos, de acuerdo a lo solicitado por nuestro cliente, que los envos de mensaje que realizan tanto un abogado como una secretaria sean encriptados previos a su transmisin. Suponiendo que contamos con una plataforma AOP en la que las llamadas a mtodos 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- podramos decidir aplicar el aspecto de encriptacin a todas las llamadas al mtodo enviarMensaje de instancias de las clases Abogado y Secretaria. Para eso debemos definir el pointcut que incluya a todos esos puntos de ejecucin, por ejemplo de la siguiente manera:
Pointcut mensajesSensibles { todas las llamadas al mtodo enviarMensaje de instancias de las clases Abogado o Secretaria }
Resta definir un advice que indique que se debe aplicar el aspecto de encriptacin en todos los joinpoints del pointcut mensajesSensibles. Esto podra realizarse de la siguiente manera: Advice encriptarMensajesSensibles { aplicar } el aspecto Encriptacin 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 idnticamente a como lo hara si hubisemos optado por mecanismos tradicionales de programacin. En definitiva, esta modularizacin en aspectos tiene por objetivo facilitar la construccin y entendimiento del software, mientras que el resultado que deseamos obtener desde un punto de vista de la ejecucin del mismo no
Lgicamente podrn existir ms aspectos aparte del de encriptacin. Se toma este solo para simplificar el ejemplo.
Adrin Eidelman
18/148
FIUBA
vara con respecto a los restantes paradigmas. El proceso por el cual se combinan la dimensin base con las restantes dimensiones del problema se denomina weaving, trmino que en castellano significa entretejido.
Weaving
El weaving es el proceso que se encarga de que se ejecuten los aspectos que corresponden durante la ejecucin 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. Lgicamente este proceso debe valerse de mecanismos automticos 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 dimensin base en este caso la lgica de negocio del estudio jurdico- con las dimensiones transversales encapsuladas en aspectos.
SISTEMA DE ESTUDIO JURDICO

Encriptacin
Visualizacin
...
weaving
Logging
weaving
Abogados, Secretarias, Legajos, Escritos ...
w
weaving
ea vi ng
we av in g
Caching Tracing
Seguridad
Figura 2-5: El proceso de weaving
Adrin Eidelman
weaving
w vi ea ng
Persistencia
g in av we
19/148
FIUBA
El proceso de weaving es un tema central no slo a la programacin orientada a aspectos, sino tambin 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

Adems de la claridad en el desarrollo que persigue la programacin orientada a aspectos, podemos mencionar otras ventajas que ofrece esta tcnica de programacin: Reutilizacin de aspectos: el tener las incumbencias transversales
modularizadas nos da la posibilidad de reutilizar la lgica de los aspectos en otros desarrollos. Esto se puede tornar sumamente complicado si las funcionalidades se encuentran dispersas a lo largo del cdigo fuente. Utilizacin de aspectos en sistemas legacy: la independencia que poseen los aspectos de la dimensin base facilitan la incorporacin de funcionalidades a sistemas de los cuales no se posee conocimiento y por lo tanto sera sumamente complicado modificar el cdigo para lograrlo. Incluso en plataformas AOP que no se valen del cdigo fuente para lograr el weaving, esto es posible de realizar precisamente sin la existencia del cdigo.
AOP vs. POO

Es importante, para cerrar la idea de la programacin 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 separacin de las incumbencias que POO no logra modularizar. Al programar en AOP, se siguen utilizando objetos, mtodos, atributos y todos los elementos distintivos de la programacin orientada a objetos. Es cierto tambin 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 relacin mucho ms cercana con POO, bsicamente por el uso de clases y objetos o la asociacin de joinpoints con llamadas a mtodos, entre otros.
Adrin Eidelman
20/148
FIUBA
Resumen
Se han presentado en este captulo los conceptos bsicos de la programacin orientada a aspectos, la cual intenta mejorar la modularizacin de las diferentes incumbencias que se presentan en el desarrollo de un sistema. Esta modularizacin se logra mediante el uso de un elemento denominado aspecto, el cual se combina con las restantes dimensiones a travs del proceso de weaving. Se llama joinpoint al punto bien definido en la ejecucin de un programa donde es posible aplicar un aspecto, pointcut a un conjunto bien definido de joinpoints y advice a la relacin entre un pointcut y un aspecto a aplicar. Todos estos conceptos fueron presentados mediante un ejemplo concreto.
Adrin Eidelman
21/148
FIUBA
3. El proyecto SetPoint
Es extenso el listado de herramientas que implementan los conceptos AOP descriptos anteriormente, algunas de ellas utilizadas actualmente en proyectos comerciales y otras que an se encuentran en un estado experimental. Los desarrollos que se realizaron en el marco de la presente tesis utilizaron como plataforma base al framework para desarrollos AOP conocido como SetPoint, el cual al momento de escribir este trabajo- pertenece a la segunda de las categoras mencionadas. Este hecho es el que ha motivado principalmente la eleccin de la plataforma sobre la cual se experimentar, teniendo como objetivo contribuir al desarrollo y maduracin del proyecto. Las siguientes lneas tienen el propsito de explicar los conceptos fundamentales del framework SetPoint y sus particularidades. Como se ha detallado en el captulo anterior, las implementaciones de los diferentes elementos distintivos del paradigma AOP pueden diferir entre las herramientas existentes. De hecho generalmente lo hacen.
SetPoint, lector lector, SetPoint

SetPoint nace como resultado de una tesis de licenciatura realizada en la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires en el ao 2004 [Cyment & Altman, 2004]7. El proyecto ha sentado sus bases terico-prcticas, las cuales sern descriptas en este captulo, pero an se encuentra en etapa de desarrollo. Las interesantes propuestas de SetPoint le han permitido obtener un importante premio otorgado por Microsoft Research8 que tiene el fin de fomentar la evolucin de la herramienta. SetPoint es bsicamente un motor de aspectos para la plataforma Microsoft.NET, es decir, permite aplicar los conceptos AOP antes descriptos en programas desarrollados con cualquiera de los lenguajes de programacin .NET existentes.
Alan Cyment y Rubn Altman son los creadores de la herramienta. Alan Cyment ha participado como co-director en la presente tesis, mientras que Rubn Altman lo ha hecho de manera no oficial. 8 Microsoft Research es la organizacin interna de Microsoft que se encarga de realizar investigaciones en el rea de las ciencias de la computacin. Ms informacin en http://research.microsoft.com/default.aspx.
Adrin Eidelman
22/148
FIUBA
Son varios los conceptos que es necesario presentar para comprender las bases de esta herramienta, los cuales se exponen a continuacin.
Una motivacin para SetPoint: la paradoja de la programacin AOP

Cuando en el captulo anterior se explicaron los conceptos de cuantificacin y pointcut, se ejemplific de forma general cmo se poda predicar sobre un conjunto de joinpoints. Si se analiza en mayor detalle la forma de predicar sobre los joinpoints que nos ofrecen las herramientas AOP en la actualidad, es posible ver que generalmente- el mecanismo provisto se basa en definir expresiones sintcticas sobre el nombre de mtodos, constructores, clases, etc. La siguiente sera la definicin del pointcut mensajesSensibles ejemplo utilizado en el captulo anterior- mediante el mecanismo de definicin sintctica utilizando la sintaxis de AspectJ [Kiczales et al., 2001]9:
pointcut mensajesSensibles(): (target(Abogado) || target(Secretaria)) && call(void enviarMensaje(string));
De acuerdo a este ejemplo, forman parte del pointcut definido todas las llamadas al mtodo enviarMensaje con la signatura especificada- que adems sean llamadas a instancias de la clase Abogado o instancias de la clase Secretaria. Claramente, al especificar el nombre del mtodo o de las clases, se est predicando sobre reglas sintcticas del lenguaje. Algunos lenguajes de definicin de pointcuts flexibilizan el predicado por reglas sintcticas mediante el uso de wildcards. El siguiente ejemplo utiliza el wildcard * para extender el pointcut a todos los mtodos que contengan la palabra Mensaje en su nombre:
pointcut mensajesSensibles(): (target(Abogado) || target(Secretaria)) && call(void *Mensaje(string));
AspectJ es la herramienta ms difundida y utilizada para el desarrollo de sistemas AOP en la actualidad.
Adrin Eidelman
23/148
FIUBA
Este mecanismo de predicacin da origen a una serie de interrogantes acerca de los objetivos que persigue la programacin orientada a aspectos: El hecho que para definir pointcuts sea necesario conocer elementos sintcticos de las diferentes dimensiones del problema no se contrapone con la necesidad que el programador se desentienda de aquellas dimensiones sobre las cuales no est trabajando? El programador de aspectos tiene ahora que conocer qu nombre se le dio a los mtodos en la dimensin base? Esto no atenta contra la propiedad de obliviousness que persigue AOP? Estos interrogantes son los que se plantean en [Tourw et al., 2003] y la respuesta es claramente afirmativa. La definicin de pointcuts basados en expresiones sintcticas es causa de acoplamiento entre el cdigo base y los aspectos y atenta contra la separacin de incumbencias que persigue AOP. En [Tourw et al., 2003] se sealan adems una serie de inconvenientes adicionales: Se puede estar trabajando con otro desarrollador que requiera tambin de sus propias convenciones de notacin, lo que seguramente originar conflictos. El carcter arbitrario de las reglas sintcticas aumenta la
probabilidad de que no todos los joinpoints cumplan con la regla requerida. A su vez se abre tambin la posibilidad de aparicin de falsos negativos. Si corresponde aplicar varios aspectos sobre un mismo joinpoint, se debern seguir una cantidad de convenciones sintcticas sobre un mismo identificador, lo cual podra llevar a nuevos conflictos.
La paradoja de la definicin de pointcuts sintcticos que se presenta en [Tourw et al., 2003] da origen a la propuesta que plantea SetPoint en cuanto a predicado sobre joinpoints. Qu alternativa existe a la definicin sintctica de pointcuts que mejore la situacin anteriormente planteada? La alternativa que se propone en [Cyment & Altman, 2004], idea tambin planteada en [Kellens et al., 2006], es la de proveer un mecanismo de cuantificacin de ms alto nivel, permitiendo que los pointcuts no slo se definan basados en expresiones sintcticas, sino tambin en contenido semntico.
Adrin Eidelman
24/148
FIUBA
Semantic pointcuts y conceptos de la Web semntica

La definicin basada en expresiones sintcticas se encuentra fuertemente ligada a la implementacin en cdigo propiamente dicha ya que se predica indicando nombres de mtodos, de clases, etc.-. Por otro lado, quienes se encargan del anlisis y diseo de los requerimientos de un sistema en general se refieren a estos requisitos en un nivel de abstraccin mayor al del cdigo fuente. Por ejemplo, podemos escuchar a un analista hablar de conceptos del negocio un abogado, una secretaria, un legajo o una factura- o a un diseador de software referirse en trminos de capas, componentes u otros conceptos arquitectnicos. Una manera ms adecuada y natural para predicar sobre los joinpoints podra permitir referirnos a las diferentes dimensiones del problema diciendo por ejemplo, encriptar los mensajes que son enviados por toda aquella persona dentro del estudio jurdico que es propensa de manejar datos sensibles de la empresa o bien persistir en una base de datos todas las operaciones realizadas por clases que implementan transacciones comerciales. Ejemplos como los mencionados son parte de la visin de los creadores de SetPoint en cuanto a cmo debe ser la definicin de pointcuts en una herramienta AOP, y constituyen el core o concepto fundamental del framework. Este mecanismo de cuantificacin se basa en el uso de conceptos semnticos en lugar de expresiones sintcticas, por lo que el nombre que se le ha dado a este tipo de pointcuts es pointcuts semnticos o setpoints (semantic pointcuts). Algunas particularidades que es necesario mencionar acerca de los ejemplos presentados: No se estn haciendo definiciones del tipo ac se debe aplicar el aspecto de encriptacin. No se est predicando sobre cuestiones sintcticas como puede ser el nombre de una clase o la llamada al mtodo X. Se mencionan conceptos netamente funcionales como por ejemplo abogado o secretaria-, referidos a la caracterizacin de la informacin datos sensibleso bien a aspectos arquitectnicos de la implementacin clases-. Es decir, se estn utilizando perspectivas del programa que no necesariamente tienen que ver con el cdigo en s.
Adrin Eidelman
25/148
FIUBA
Para poder plasmar en la prctica la idea de semantic pointcuts es necesario contar con mecanismos de modelado de semntica que permitan describir un universo como puede ser el universo del estudio jurdico, o el universo de una aplicacin con arquitectura de tres capas- y a su vez con mecanismos que permitan relacionar el cdigo con elementos de este universo. La implementacin en SetPoint se basa fuertemente en la utilizacin de conceptos de la Web semntica y en el uso de anotaciones sobre cdigo: los primeros soportan la descripcin de las perspectivas recientemente mencionadas, mientras que las anotaciones permiten asignar una caracterstica particular a una porcin de cdigo y vincular a ste con las perspectivas definidas.
Conceptos de la Web semntica

El objetivo que persigue la Web semntica es simple: crear un medio de intercambio de informacin que permita a una computadora comprender el significado (semntica) de los documentos existentes en la World Wide Web. Hoy en da las pginas web estn diseadas para poder ser ledas por personas obviamente- pero el contenido de las mismas no tiene significado alguno para una mquina. Si realizamos una bsqueda en algn buscador Web, generalmente obtendremos una cantidad de resultados de los cuales no todos sern de nuestro inters. Nosotros, como personas, podemos comprender el significado de los resultados y tenemos la posibilidad de discriminar aqullos que no nos sirven. Esto una computadora no lo puede hacer, ya que para ella no habr diferencias entre el primero, el segundo o el dcimo resultado devuelto. La Web semntica intenta poder darle un significado a las pginas tal que ste pueda ser comprendido y utilizado de forma automtica. En la actualidad, los documentos existentes en la web estn escritos utilizando el lenguaje HTML (HyperText Markup Language), el cual permite confeccionar una estructura de texto en combinacin con otros elementos multimedia como ser imgenes o sonidos. Sin embargo, la capacidad de incorporar metainformacin de manera estndar es muy limitada. Si por ejemplo creamos una pgina que contenga un listado de las pelculas en las que particip Steven Spielberg, el lenguaje HTML no nos permite, de forma no ambigua, decir que Jurassic Park fue estrenada en 1993 o que Spielberg particip en ella como director. La Web semntica intenta brindar esta capacidad mediante la combinacin de una serie
Adrin Eidelman
26/148
FIUBA
de tecnologas que permitan estructurar este conocimiento y poder realizar consultas sobre el mismo. La Figura 3-1 presenta la arquitectura de la Web semntica, la cual consta de una serie de capas representadas por diversas tecnologas, cada una de las cuales se apoya en la anterior para ir agregando expresividad al modelo. La solucin propuesta por SetPoint para la descripcin de universos se basa fuertemente en las capas RDF (Resource Description Framework) y Ontology.
Figura 3-1: Arquitectura de la Web semntica Antes de explicar en qu consisten estas dos tecnologas es necesario mencionar las subyacentes. Las URIs (Universal Resource Identifier) son identificadores nicos de cualquier elemento que desee ser identificado. Guardan una estrecha relacin con las famosas URLs (Uniform Resource Locator) pero permiten identificar cualquier concepto y no slo ubicaciones fsicas en la web. Por ejemplo, continuando con el ejemplo del afamado Steven Spielberg, ste deber tener una URI que lo identifique unvocamente. Lo mismo suceder con la pelcula Jurassic Park e incluso con la palabra pelcula. Por supuesto estos identificadores deben formar parte de un diccionario universal, sin el cual sera imposible estandarizar su uso. La URI para el recurso pelcula podra tener una forma similar a la siguiente: http://purl.org/d/elements/1.1/movie. Por sobre esta capa aparece la tecnologa XML (Extensible Markup Language), ampliamente difundida en la actualidad como herramienta de estructuracin e intercambio de informacin. XML permite estructurar documentos mediante el uso de tags, pero no impone ningn tipo de restriccin semntica al significado de los mismos.
Adrin Eidelman
27/148
FIUBA
RDF utiliza estas dos tecnologas mencionadas para comenzar a darle valor a la informacin, constituyendo la primer plataforma para contar con un modelo semntico ms rico. Mediante RDF es posible especificar tipos y propiedades a cualquier concepto definido, mediante el uso de ternas de la forma <sujeto, predicado, objeto>. Cada uno de los elementos de la terna debe ser un recurso (URI) y la informacin puede ser estructurada utilizando el lenguaje XML. Si volvemos una vez ms al ejemplo anterior, podremos utilizar RDF para decir que Steven Spielberg es el director de Jurassic Park, de una forma similar a la siguiente, obviamente reemplazando cada uno de los elementos por su URI correspondiente: <Steven Spielberg, Director, Jurassic Park> En la misma capa que RDF se ubica RDF-Schema. RDF-Schema extiende RDF permitiendo la especificacin de clases, con una semntica que permite describir jerarquas. Podramos decir, por ejemplo, que Spielberg es un director o que Jurassic Park es una pelcula. Tanto RDF como RDF-Schema se basan en XML para especificar la semntica deseada y como medio de comunicacin entre mquinas. Para ilustrar estos conceptos, el siguiente extracto de RDF-Schema define una taxonoma para una escuela. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <rdfs:Class rdf:ID="Person"> <rdfs:comment>Person Class</rdfs:comment> <rdfs:subClassOf rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Resource"/> </rdfs:Class> <rdfs:Class rdf:ID="Student"> <rdfs:comment>Student Class</rdfs:comment> <rdfs:subClassOf rdf:resource="#Person"/> </rdfs:Class> <rdfs:Class rdf:ID="Teacher"> <rdfs:comment>Teacher Class</rdfs:comment> <rdfs:subClassOf rdf:resource="#Person"/>
Adrin Eidelman
28/148
FIUBA
</rdfs:Class> <rdfs:Class rdf:ID="Course"> <rdfs:comment>Course Class</rdfs:comment> <rdfs:subClassOf rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Resource"/> </rdfs:Class> <rdf:Property rdf:ID="teacher"> <rdfs:comment>Teacher of a course</rdfs:comment> <rdfs:domain rdf:resource="#Course"/> <rdfs:range rdf:resource="#Teacher"/> </rdf:Property> <rdf:Property rdf:ID="students"> <rdfs:comment>List of Students of a course in alphabetical order</rdfs:comment> <rdfs:domain rdf:resource="#Course"/> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq"/> </rdf:Property> <rdf:Property rdf:ID="name"> <rdfs:comment>Name of a Person or Course</rdfs:comment> <rdfs:domain rdf:resource="#Person"/> <rdfs:domain rdf:resource="#Course"/> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Literal"/> </rdf:Property> </rdf:RDF> Finalmente nos interesa conocer la capa de ontologas. Una ontologa es un conjunto de conceptos y relaciones, conjuntamente con sus significados, definiciones y propiedades, expresadas en la forma de axiomas. Una ontologa no es slo una jerarqua de trminos, sino una teora axiomtica completa sobre un dominio... [Uschold, 1998]. La capa de ontologas se basa en los conceptos de RDF a la vez que incorpora una mayor expresividad para describir un universo. Por ejemplo, es posible especificar cardinalidad entre clases, simetra o disyuncin, entre otras cosas. Esta capa est representada actualmente por el lenguaje de representacin conocido con el nombre de OWL (Ontology Web Language), el cual permite definir ontologas. El concepto de ontologa es clave para comprender SetPoint.
Adrin Eidelman
29/148
FIUBA
Los conceptos de la Web semntica ameritan una explicacin mucho ms detallada que la presentada a lo largo de esta seccin. Simplemente se busca dar una aproximacin a las herramientas existentes en la actualidad para poder explicitar conocimiento, de forma que ste pueda ser utilizado por una computadora. Esta pequea introduccin nos permitir entender cmo implementa SetPoint el uso de pointcuts semnticos.
Armando el rompecabezas hacia la implementacin de setpoints

Se han presentado hasta ahora los conceptos principales que hacen a la implementacin de pointcuts semnticos en SetPoint. Trataremos de resumir estas ideas y relacionarlas de forma de entender cmo se materializan en la prctica: Se desea predicar sobre los joinpoints refirindose a perspectivas no directamente relacionadas con el cdigo de la aplicacin. Estas perspectivas no son otra cosa que ontologas o descripciones de universos relacionados de alguna forma con el sistema que se desea implementar. Por ejemplo podremos querer definir la ontologa de un estudio jurdico describiendo la existencia de abogados, secretarias, legajos, juicios, etc.- o de otras perspectivas no necesariamente relacionadas con el negocio, pero que de igual manera nos sirvan para la definicin de pointcuts semnticos. Podramos querer definir la ontologa de una arquitectura MVC (Model-View-Controller) en donde se describa la existencia de una capa de presentacin o el componente del modelo, entre otras cosas-. Se desea a su vez poder relacionar el cdigo de la aplicacin con estas ontologas, de lo contrario no habr forma alguna que el weaver -encargado de decidir si un aspecto debe ser aplicado en un joinpoint- pueda determinar qu joinpoints forman parte del pointcut semntico. El framework debe poder determinar que la clase Abogado est relacionada con el concepto de abogado de la ontologa del estudio jurdico. Es claro que para nosotros este hecho es obvio, no as para una computadora. Esta relacin debe a su vez formar parte del universo semntico.
Adrin Eidelman
30/148
FIUBA
Se desea contar con un motor de inferencia de forma de poder realizar consultas sobre el universo semntico y verificar la inclusin de un joinpoint en un setpoint. Cmo implementa SetPoint estas ideas en la prctica? Vayamos en orden: La forma de describir ontologas ya la hemos mencionado, y es a travs de RDF y OWL. Son varias las herramientas existentes que permiten describir ontologas. En el caso de SetPoint la eleccin ha recado sobre Protg [PROTEGE], la cual tiene la ventaja de ofrecer un entorno visual que facilita enormemente la tarea de modelado. La relacin entre cdigo y las diferentes perspectivas se da a travs de anotaciones en el cdigo, mecanismo soportado por la plataforma .NET. Toda anotacin realizada sobre el cdigo debe estar asociada a un recurso RFD, de manera de poder incluir esta metainformacin en el universo semntico mediante la formacin de ternas. Si por ejemplo assembly incluimos supongamos que la la a un del URI anotacin determinado assembly es semantics://perspectives/architecture:view
semantics://CTS/assemblyExample entonces se incluir la terna <semantics://CTS/assemblyExample,semantics://objectOriented/has Annotation,semantics://perspectives/architecture:view> universo semntico de la aplicacin. El motor de consultas es provisto por la herramienta Sesame [Broekstra et al., 2003] y se utiliza el lenguaje de consultas SeRQL [SeRQL], soportado por la herramienta. Sesame permite realizar consultas sobre modelos RDF y OWL. Los puntos anteriores dan una idea de cmo SetPoint implementa la idea de predicar sobre joinpoints en base a la semntica del problema10. Se le ha dado importancia a este tema dado que sin dudas constituye el elemento distintivo de la plataforma. De todas formas no todo es pointcuts semnticos en la vida de SetPoint y existen otros aspectos de diseo del framework que es importante presentar. Nos basaremos, a partir de lo expresado en [Elrad et al., 2001a], en los cinco elementos distintivos de cualquier herramienta AOP:
10
en
el
Es posible profundizar sobre la idea e implementacin de pointcuts semnticos a travs del ejemplo presentado en el captulo 9, el cual se complementa con los ejemplos de ontologas presentados en el Anexo C.
Adrin Eidelman
31/148
FIUBA
1. Un modelo de joinpoints, es decir, en qu puntos especficos de un programa pueden ejecutarse las restantes incumbencias. 2. Una forma de identificar joinpoints, sobre lo cual nos hemos explayado en lo que va del captulo. 3. La forma de especificar comportamiento en los joinpoints. 4. Las unidades que encapsulan la especificacin de joinpoints y el comportamiento a aplicar. 5. El mecanismo de relacionar estas unidades con el programa base, es decir, el weaving.
Modelo de Joinpoints y Weaving

Hablamos en el captulo anterior acerca de los puntos de ejecucin en un programa que pueden constituir un joinpoint y que esta definicin vara dependiendo de la plataforma AOP que se utilice. SetPoint ha tomado una posicin purista en relacin con el paradigma de orientacin a objetos. Partiendo de la base que un programa est formado por un conjunto de objetos que colaboran entre s envindose mensajes, SetPoint define como posible joinpoint al momento de envo y recepcin de mensajes. Si trasladamos esta definicin terica al mundo .NET, se identifican principalmente dos tipos de joinpoints: 1. Las llamadas a mtodos. 2. La creacin de nuevas instancias de una clase.11 Estas dos operaciones constituyen el modelo de joinpoints para SetPoint y por lo tanto ser posible ejecutar aspectos en alguno de esos dos momentos del flujo de ejecucin del programa base. El weaving en SetPoint presenta dos caractersticas principales: es dinmico e invasivo. Es dinmico ya que el weaving de los aspectos con el cdigo base se realiza en tiempo de ejecucin. Hemos mencionado que un joinpoint puede estar dado por la llamada a un mtodo o la creacin de una nueva instancia de una clase. Durante la ejecucin del programa, cuando se encuentre alguno de estos dos puntos bien definidos en el flujo de ejecucin aparecer en escena el weaver,
11
En plataformas OOP ms puras, como por ejemplo Smalltalk, la creacin de un objeto tambin est dada por la llamada a un mtodo.
Adrin Eidelman
32/148
FIUBA
tomando el control de la ejecucin para decidir si corresponde o no la aplicacin de un determinado aspecto. En contraposicin con los weavers dinmicos existen los weavers estticos. Estos realizan un pre-procesamiento del cdigo base y los aspectos y los combinan para generar un nico ejecutable que luego es utilizado de forma tradicional. Independientemente de si el weaving se realiza de forma esttica o dinmica, llamaremos al programa que resulta del proceso de weaving con el nombre de programa entretejido12. Cmo es que el flujo de ejecucin es derivado al weaver? Aqu aparece la segunda de las caractersticas antes mencionadas: previo a la ejecucin de un programa, ste debe pasar por un pre-proceso propio de SetPoint bautizado como preweaving. El proceso de preweaving es sencillo, simplemente consiste en detectar cada uno de los joinpoints en el programa y reemplazar esos puntos por llamadas al weaver. En la prctica, el weaver no es otra cosa que un objeto -que forma parte del componente principal de SetPoint conocido como SetPoint Engine, encargado bsicamente del proceso de weaving- y el cual decide qu accin tomar en base a las definiciones de pointcuts, aspectos y advices que se hayan realizado. En pocas palabras, se coloca un enlace en cada joinpoint detectado, el cual invoca al objeto weaver durante tiempo de ejecucin, obtenindose un assembly funcionalmente idntico al original salvo por estos enlaces mencionados. En conclusin, el assembly original es reemplazado por un nuevo assembly aspectualizado13, y de ah el carcter invasivo de la plataforma. Volveremos sobre esta caracterstica ms adelante en el trabajo, ya que es relevante al soporte de debugging que provee la herramienta hoy en da.
Completando el universo semntico de la aplicacin

Ya se ha mencionado en ms de una ocasin durante este captulo que adems de las ontologas definidas, es necesario poder relacionar el cdigo con estas otras perspectivas, lo cual se realiza mediante el uso de anotaciones. Tambin se dijo que esta metainformacin debe incluirse como parte del universo semntico sobre el cual se va a predicar, para poder determinar la pertenencia o no de los joinpoints a los pointcuts definidos. Esta tarea es realizada a travs del
12 13
La literatura en ingls utiliza generalmente el trmino woven program. Utilizaremos el trmino assembly aspectualizado para referirnos a un assembly que ha sido sometido al pre-proceso de preweaving de SetPoint.
Adrin Eidelman
33/148
FIUBA
procesamiento del assembly original mediante la ejecucin de un pre-proceso al que se le ha dado el nombre de semanticacin. El proceso de semanticacin del assembly recorre todas las estructuras del mismo clases, mtodos, atributos, etc.- para crear su representacin RDF, que luego ser utilizada por el weaver. El RDF resultante contendr, entre otras cosas, la informacin de qu clases existen en el assembly, qu mtodos forman parte de las clases y qu anotaciones se han realizado sobre cada uno de los elementos. Esta informacin es embebida en el assembly para su posterior uso en el proceso de weaving.
Declaracin de aspectos, advices y pointcuts

Est claro que el weaver debe basar sus decisiones en la definicin de aspectos, advices y pointcuts que se haya realizado. En SetPoint, esta definicin es contenida dentro de un assembly independiente, el cual es utilizado por el SetPoint Engine para tomar las decisiones de weaving. Este assembly es denominado SetPoint Configuration Assembly y contiene no slo los elementos mencionados, sino tambin las ontologas definidas. La particularidad que incluye SetPoint es que provee un lenguaje especfico para realizar esta definicin, el cual intenta simplificar la tarea de escribir estructuras ms complejas a travs del lenguaje .NET utilizado. Este lenguaje ha sido bautizado LENDL por Little aspEct & poiNcut Definition Language14. Una vez declarados los elementos mediante LENDL, ser necesario traducir esta definicin al lenguaje .NET que se desee para la posterior compilacin y generacin del assembly de configuracin15. Tomemos el siguiente ejemplo de definicin LENDL de los elementos AOP mencionados para profundizar sobre estas cuestiones. En este ejemplo se desea realizar un logging de todos los mensajes que son enviados desde la vista al modelo, suponiendo una aplicacin con arquitectura MVC: pointcut ViewToModelMessages{ sender is [architecture#view]; receiver is [architecture#model]; }
14
LENDL, SetPoint... quin haya tenido la desagradable oportunidad de ver a Alan y Rubn jugar al tenis deducir que estos pequeos homenajes al deporte slo pueden realizarlos en el marco de un trabajo relacionado con la informtica. 15 Por supuesto que tambin es posible optar por realizar la declaracin de aspectos, pointcuts y advices directamente con el lenguaje .NET por el cual se haya optado. Sin embargo, SetPoint por el momento solamente provee un traductor de LENDL a C#.
Adrin Eidelman
34/148
FIUBA
aspect LoggingAspect { event startLogging; event endLogging; } advice LogEvents : LoggingAspect{ trigger startLogging before {ViewToModelMessages}; trigger endLogging after {ViewToModelMessages}; }
Pointcuts
La definicin de pointcuts en LENDL se basa principalmente en el uso de tres palabras clave: sender, receiver y message. Estas palabras permiten identificar al objeto que enva el mensaje, al que lo recibe y al mensaje propiamente dicho respectivamente, y de esta forma predicar sobre los posibles joinpoints (Figura
3-2).
class Cliente
class Factura
oFactura.emitir() ...
void emitir() { }
Cliente
emitir
Factura
sender
message
receiver
Figura 3-2: Elementos clave en la definicin de un pointcut semntico en SetPoint La palabra clave is es simplemente un alias del concepto hasAnnotation, representado como todo concepto por una URI. significado del predicado. Lgicamente es posible reemplazar la palabra clave is por la URI de cualquier otro concepto para variar el
Adrin Eidelman
35/148
FIUBA
Por supuesto que los elementos que implementen la vista y el modelo de la aplicacin debern contener la anotacin [architecture#view] o [architecture#model] para que la definicin del pointcut tenga sentido.
Aspectos
Para definir un aspecto simplemente basta con asignarle un nombre y describir qu eventos lo conforman. El concepto de evento es una introduccin realizada por SetPoint que le brinda flexibilidad para asignar comportamientos diferentes de un mismo aspecto a distintos pointcuts el ejemplo anterior de definicin de un aspecto con LENDL es lo suficientemente descriptivo para comprender el concepto-. El comportamiento de estos eventos no forma parte de la definicin LENDL, sino que son programados directamente en el lenguaje nativo de .NET. El siguiente cdigo podra ser la implementacin de los eventos de logging que se incluyen en la definicin LENDL anterior: public class LoggingAspect : IAspect { private DateTime _startTime; public void startLogging(IJoinPoint aJoinPoint) { this._startTime = DateTime.Now; } public void endLogging(IJoinPoint aJoinPoint) { DateTime _endTime = DateTime.Now; string message = Message: + aJoinPoint.message.uri + Sender: + aJoinPoint.sender.uri + Receiver: + aJoinPoint.receiver.uri; message += Inicio: + this._startTime + Fin: + _endTime; System.Diagnostics.EventLog.WriteEntry(SetPoint!, message); } }
Adrin Eidelman
36/148
FIUBA
La definicin de aspectos que se realiza mediante el cdigo LENDL sirve nicamente para la posterior validacin de los advices, ya que son estos ltimos los que especifican el comportamiento a aplicar en los joinpoints16.
Advices
Finalmente son los advices los que definen, mediante lo que en SetPoint se denomina trigger, qu eventos aplicar en relacin a qu pointcut, y adems en qu momento. Los triggers son mensajes que indican al aspecto la ocurrencia de un evento para l relevante. Un advice agrupar los triggers que relacionan cada evento de un aspecto con los correspondientes pointcuts que lo disparan [Cyment & Altman, 2004]. El ejemplo de cdigo LENDL anterior permite comprender la relacin entre las diferentes entidades, la cual tambin se ilustra en la Figura 3-3.
0..*
JoinPoint
0..* Pointcut 0..* 1..* Trigger 1..*
Advice 1..*
Event 1..*
Aspect
Figura 3-3: Relacin entre las entidades AOP en SetPoint En general, cualquier plataforma AOP permite especificar la ejecucin de cierto comportamiento (aspecto) antes, despus o incluso en lugar del joinpoint afectado. SetPoint soporta esta declaracin mediante el uso de las palabras
16
Esto es una decisin de diseo particular de SetPoint, no necesariamente aplica a otras herramientas AOP.
Adrin Eidelman
37/148
FIUBA
claves before y after en relacin al pointcut que se especifique. Otras plataformas incluyen la posibilidad de ejecutar el comportamiento deseado en lugar del joinpoint afectado mediante el uso de la palabra clave around. Para realizar lo mismo en SetPoint, por lo menos al momento de escribir este prrafo, es necesario utilizar la palabra clave before y luego cancelar la ejecucin del joinpoint.
Arquitectura SetPoint
Se han explicado en los prrafos anteriores los principales conceptos que hacen a la herramienta SetPoint, dando una idea tambin de qu elementos constituyen la arquitectura del framework. La Figura 3-4 ilustra y resume esta arquitectura desde un punto de vista de procesos- mostrando cmo se realiza la ejecucin de un desarrollo orientado a aspectos con SetPoint.
Figura 3-4: Vista de procesos de SetPoint
Adrin Eidelman
38/148
FIUBA
Resumen
SetPoint es una herramienta que permite aplicar los conceptos bsicos del paradigma AOP a desarrollos realizados bajo la plataforma .NET. La principal caracterstica del framework radica en la utilizacin de predicados semnticos para la definicin de pointcuts, como alternativa a la definicin mediante expresiones sintcticas. La implementacin de este concepto se basa fuertemente en conceptos de la Web semntica para la representacin de conocimiento. A lo largo del captulo se presentaron adems otros elementos distintivos de SetPoint, como su modelo de joinpoints o el mecanismo de weaving, incluyendo los pre-procesos de semanticacin y preweaving. Se present adems el lenguaje LENDL para definicin de pointcuts, aspectos y advices. En los sucesivos captulos se profundizar sobre los conceptos de SetPoint que estn ligados con los objetivos de la presente tesis.
Adrin Eidelman
39/148
FIUBA
4. Antes de continuar... qu entendemos exactamente por debugging?

Tan pronto como comenzamos a programar nos dimos cuenta, para nuestra sorpresa, que no era tan sencillo hacer que los programas funcionen de la manera que queramos. Puedo recordar el momento exacto en el que me di cuenta que una gran parte de mi vida de ah en ms la iba a dedicar a encontrar errores en mis propios programas.
- Maurice Wilkes descubre el debugging, 1949
Tal vez una de las primeras cosas que hayamos hecho luego de dar los primeros pasos en el mundo de la programacin fue debuggear nuestras aplicaciones. Tal cual lo expresaba Wilkes, desde el momento en que comenzamos a construir soluciones de software, nos damos cuenta que nuestros propios desarrollos no funcionan de la manera esperada y presentan fallas que es necesario corregir. Incluso es probable que a lo largo de toda nuestra vida como programadores hayamos dedicado ms tiempo a la tarea de encontrar estos problemas que a la de construir aplicaciones. En definitiva, para toda aquella persona abocada a la tarea de desarrollar software, el debugging es una tarea de todos los das. Teniendo en cuenta esto, cul es el sentido de explicar qu es el debugging en un trabajo cuya audiencia pertenece ntegramente al mundo de la informtica17? La realidad es que es comn encontrar ciertas confusiones acerca de qu quiere decir exactamente debugging. El presente captulo tiene el objetivo de definir trminos bsicos pero centrales al objetivo de la tesis y dejar en claro qu entendemos por debugging a lo largo de este trabajo.
Bugs, defectos y fallos

Se denomina bug a un error de codificacin o de lgica que existe en el software y que provoca que ste no se comporte como es deseado18. Tal como se describe en [Humphrey, 1999], el trmino bug es poco preciso y puede resultar confuso
17
Dudamos que alguien no relacionado con la informtica tenga inters en leer este trabajo y ms an que haya llegado hasta este punto! 18 Se cree que el trmino bug en software fue utilizado por primera vez cuando se encontr que un malfuncionamiento registrado en la computadora Mark II haba sido producido por una polilla que qued atrapada dentro de la misma (la traduccin de la palabra bug al castellano es bicho).
Adrin Eidelman
40/148
FIUBA
su significado. Segn el autor, el trmino posee una desafortunada connotacin de ser simplemente una molestia, algo que es fcilmente eliminable o que se puede ignorar sin demasiadas consecuencias negativas. En sintona con lo expresado, en [Zeller, 2005] se sugiere la utilizacin de otros trminos tales como errores o fallas ya que mientras los bugs parecen incorporarse al software como si tuviesen vida propia, los errores y fallas son claramente resultados de una accin humana. De acuerdo a lo enunciado, utilizaremos a lo largo del trabajo los siguientes trminos: Fallo: un incorrecto comportamiento del programa que es observado durante la ejecucin del mismo. Falla o defecto: un cdigo incorrecto que puede provocar la aparicin de fallos19.
Debugging
Se conoce como debugging a la actividad de buscar, aislar y corregir defectos en un programa de software. En trminos generales, el debugging se lleva a cabo a travs de la realizacin de los siguientes pasos o sub-actividades [Zeller, 2005]: Reproducir el fallo Encontrar los posibles orgenes que dan lugar a la aparicin del fallo Aislar el origen de la falla Corregir el defecto A medida que el desarrollo de sistemas informatizados fue evolucionando, el debugging se ha hecho cada vez ms importante, y las herramientas para tal fin han evolucionado de la mano de la actividad. Hoy en da el debugging sera realmente complicado de realizar con xito sin herramientas. De todas maneras el concepto de debugging va ms all del uso de una herramienta particular y puede realizarse como una actividad completamente manual. As como la productividad en la programacin est ntimamente relacionada con la pericia del desarrollador, tambin las habilidades de quien realice el debugging son un factor clave para encontrar y corregir las fallas existentes en un programa,
19
Habitualmente el trmino bug se utiliza para referirse a cualquiera de estos dos conceptos.
Adrin Eidelman
41/148
FIUBA
aunque la dificultad de la tarea vara enormemente dependiendo del lenguaje de programacin que se utilice y las herramientas con las que se cuente. Son estas facilidades las que permiten mejorar la experiencia de debugging. Definimos el trmino debuggability como la posibilidad de diagnosticar fallas en una aplicacin de software y mejorar la comprensin del sistema a travs del monitoreo de la ejecucin del mismo [Eaddy et al., 2005]. La presente tesis se propone justamente mejorar la debuggability de sistemas AOP a travs de la implementacin de funcionalidades que as lo permitan. Este tema ser abordado en los sucesivos captulos. Algunos datos tomados de [Zeller, 2005] dan cuenta de lo importante que es contar con un adecuado soporte al debugging: De acuerdo a un estudio realizado en Estados Unidos en 2002, las fallas en software le cuestan aproximadamente U$S 59.5 billones a la economa estadounidense por ao. Del trabajo dedicado a desarrollar software, el 50% se utiliza en actividades de testing y debugging. Las actividades de validacin (debugging, testing y verificacin) pueden fcilmente variar entre el 50% y el 75% del costo total de desarrollo. Tomados de un grupo de desarrolladores experimentados, los tres programadores que se desenvolvan mejor en tareas de debugging pudieron encontrar defectos en aproximadamente el 30% del tiempo y solucionaron un 40% ms de errores que los tres peores. Se estima que mejorando las actividades de testing y debugging se podra reducir tres veces el costo provocado por fallas en el software. Eso se traduce en U$S 22.5 billones.
Debuggers
Dentro del soporte al debugging que ofrecen las diferentes plataformas de desarrollo, existe un elemento distintivo que es el debugger. El debugger es una herramienta que intenta vislumbrar la dinmica de un programa y de esta forma permitir entender su funcionamiento, y encontrar y corregir los defectos que ste
Adrin Eidelman
42/148
FIUBA
posea.
Generalmente el debugger permite al desarrollador seguir el flujo de
ejecucin del programa, detener la ejecucin del mismo en un punto en particular o inspeccionar el estado del programa durante su ejecucin por ejemplo inspeccionar el valor de las variables y la pila de llamadas- entre otras cosas20. Para realizar esto, los debuggers requieren realizar su trabajo a muy bajo nivel, interactuando y cooperando con el sistema operativo [Rosenberg, 1996].
Estado del arte

No todos los debuggers ofrecen las mismas funcionalidades ni trabajan de la misma manera. Los debuggers modernos ofrecen en general las siguientes caractersticas [Rosenberg, 1996]: Interfaz grfica Control del flujo de ejecucin: posibilidad de controlar el flujo de ejecucin mediante el uso de breakpoints y ejecucin paso a paso del programa (single-stepping). Debugging a nivel cdigo fuente (source-level debugging): el cdigo fuente se mapea directamente con la ejecucin de cdigo de mquina, de forma de dar la sensacin al programador que se ejecuta directamente el cdigo fuente. El debugging a nivel cdigo fuente es probablemente la tcnica ms poderosa y utilizada al realizar debugging de aplicaciones. Informacin de contexto: posibilidad de acceder a informacin de contexto del programa. Esta informacin incluye, entre otras cosas, el valor de las variables e informacin de la secuencia de ejecucin Integracin: generalmente los debuggers se encuentran integrados en un entorno ms general de programacin. Esta integracin evita la prdida de tiempo que puede provocar alternar entre el entorno de programacin y el entorno de debugging en el caso de contar con un debugger no integrado (stand-alone). Otras funcionalidades: los debuggers hoy en da proveen funcionalidades extras, como pueden ser capacidades de profiling o la posibilidad de modificar el cdigo fuente del programa sin necesidad de detener su ejecucin.
20
En algunos artculos relacionados con el tema tambin se utiliza el trmino debugger para referirse a la persona que realiza el debugging. En el marco de este trabajo se utilizar exclusivamente para referirse a la herramienta de software.
Adrin Eidelman
43/148
FIUBA
Algunas aclaraciones relacionadas con el debugging

Seguramente las tcnicas de debugging ms poderosas y ms comnmente utilizadas para encontrar fallas en un programa sean el uso de debugging a nivel cdigo fuente en conjunto con la ejecucin paso a paso. Sin embargo no son las nicas. La primera aclaracin que deseamos hacer es la siguiente:
Debugging no es sinnimo de debugging a nivel cdigo fuente y/o ejecucin paso a paso del cdigo de la aplicacin
Existen otras tcnicas tal vez menos potentes pero tcnicas de debugging al fincomo por ejemplo utilizar instrucciones de impresin a pantalla, registrar informacin en archivos de log, utilizar vuelcos de memoria post-mortem, profiling, anlisis del flujo de ejecucin, etc. Existe muchas veces la confusin que debuggear una aplicacin es ejecutar paso a paso las lneas de cdigo fuente para encontrar y solucionar el o los defectos que esta pueda tener. Como se explic, esto no es as. Hablamos tambin de debuggers y su funcin en la actividad de debugging. Muchas veces se cree que el soporte al debugging est dado exclusivamente por esta herramienta. Esto no es cierto, y puede tambin deducirse de las tcnicas antes presentadas. Por ejemplo insertar instrucciones para imprimir en pantalla a lo largo del cdigo fuente, a pesar de ser algo bastante rstico por llamarlo de alguna forma, no es una tarea que necesariamente realiza el debugger. El uso de profilers por dar otro ejemplo tampoco es algo que necesariamente realiza el debugger, pero que sin embargo nos puede resultar vital para detectar anomalas. Incluso algunas caractersticas propias de los entornos de desarrollo nos faciliten la tarea de encontrar y corregir fallas. En definitiva, el soporte al debugging, ya sea ste bueno o malo, no est dado en un ciento por ciento por las funcionalidades que ofrece el debugger con el que contamos, sino tambin por otras caractersticas ms generales del entorno. La segunda aclaracin es entonces la siguiente:
El soporte al debugging no es brindado en su totalidad por un debugger
Finalmente la ltima aclaracin se deduce de la anterior y tiene por objetivo eliminar falsas expectativas que puedan surgir del ttulo de esta tesis:
Adrin Eidelman
44/148
FIUBA
Mejorar la experiencia de debugging no necesariamente implica la construccin o modificacin de un debugger para tal fin
Construir un debugger desde cero es un trabajo sumamente complejo y que puede demandar muchos meses de trabajo a un equipo de varias personas. Por otra parte requiere tener conocimientos muy especficos y de extrema complejidad tcnica. Lgicamente no es un trabajo imposible pero por qu reinventar la rueda? En los prximos captulos se ahondar en la propuesta de la presente tesis para mejorar el soporte al debugging en desarrollos AOP bajo SetPoint, pero como para despejar dudas que puedan surgir a priori, no se construir un debugger particular para AOP.
Resumen
Se definieron en este captulo algunos trminos bsicos que se utilizarn a lo largo de la tesis y se nombraron adems algunas tcnicas comunes de debugging utilizadas en la actualidad. Finalmente se realizaron algunas aclaraciones en relacin al debugging para evitar ciertas confusiones que muy frecuentemente se presentan al tratar tema. En los prximos captulos comenzaremos a referirnos ms precisamente y con mayor profundidad al tema de debugging en aplicaciones orientadas a aspectos, de forma de definir con exactitud el problema en este tipo de desarrollos y proponiendo una solucin para el framework de desarrollo SetPoint.
Adrin Eidelman
45/148
FIUBA
5. Estado del arte: Investigaciones sobre el tema

Teniendo en cuenta lo reciente de la aparicin de AOP como tcnica de programacin, son an pocos los trabajos existentes sobre el tema si se lo compara con otras reas de inters. Como se ha mencionado previamente en este trabajo, el testing an no ha recibido especial atencin en el mundo AOP y por lo tanto las investigaciones relacionadas con la disciplina as tambin como los avances prcticos- son an ms escasas. Recin en el ao 2005 se realiz el primer workshop sobre testing dentro de la comunidad de aspectos, en el cual se presentaron unos pocos papers que tratan diferentes aspectos relacionados con el tema21. Los principales tpicos abordados en estos trabajos se basan principalmente en las dificultades propias de testear desarrollos orientados a aspectos y en el uso de nuevas tcnicas de pruebas unitarias para aspectos. En cuanto a temas particulares de debugging en desarrollos AOP, las
investigaciones existentes son prcticamente nulas, hecho que ha servido como una de las principales motivaciones para abordar el tema en la presente tesis. De todas maneras, y por suerte, ha habido inters de parte de unos pocos investigadores en tratar este tema previamente lo cual ha servido de gran ayuda como base para afrontar este trabajo. El objetivo de este captulo es realizar una breve presentacin de aquellos trabajos que en mayor o menor medida guardan una relacin con el tema central de esta tesis.
Trabajos relacionados
Uno de los principales temas abordados en lo referente al testing de desarrollos orientados a aspectos est relacionado con las fallas caractersticas de este tipo de programas, producto de las particularidades del paradigma. Estas particularidades se dan principalmente por la aparicin del aspecto como unidad de modularizacin y la interaccin entre el programa base y las restantes incumbencias que los aspectos implementan. Los trabajos que han abordado este
21
El Workshop on Testing Aspect-Oriented Programs (WTAOP) fue realizado en conjunto con el Fourth International Conference on Aspect-Oriented Software Development en marzo de 2005. Durante julio de este ao se realizar el segundo, en el marco del International Symposium on Software Testing and Analysis.
Adrin Eidelman
46/148
FIUBA
tema intentan entender qu nuevos tipos de fallas pueden ocurrir y cmo stas se manifiestan a travs de la ejecucin de los programas. A su vez, destacan la importancia de definir nuevos criterios de testing para desarrollos AOP en conjunto con estrategias y tcnicas con las que puedan contar los desarrolladores para evitar y diagnosticar, en la medida de lo posible, estas fallas caractersticas. En [Ceccato et al., 2005] se plantea una discusin en base a las dificultades y facilidades de testing que impone AOP en comparacin con las de OOP. Segn argumentan los autores, la principal complejidad que AOP impone al testing radica en la bifurcacin implcita producida por la designacin de un pointcut, la cual transfiere el control de la ejecucin al advice asociado. Esto produce que la definicin de casos de prueba se torne complicada si se busca lograr cubrir todos los posibles caminos que puede tomar un programa. En contraposicin con esto de acuerdo a lo expresado en el trabajo- la separacin de incumbencias que se logra con AOP permite testear estas incumbencias por separado mediante el uso de stubs y drivers, facilitndose de esta forma la tarea. [Alexander et al., 2004] propone un modelo de fallas candidato para AOP, describiendo una a una las fallas caractersticas del paradigma y las posibles fuentes de error. Este trabajo ha servido como base para otras investigaciones relacionadas en las cuales se ha tomado el modelo de fallas presentado para proponer mejoras a la disciplina. La presente tesis tambin parte del modelo de fallas propuesto para la construccin de nuevas tcnicas de debugging. Teniendo en cuenta la relevancia de este modelo, el mismo ser presentado y explicado en mayor profundidad en el prximo captulo. Existen otros interesantes trabajos de la materia que se han centrado en definir tcnicas especficas de testing para AOP. Las mismas no estn directamente relacionadas con el tema central de esta tesis, pero persiguen un objetivo similar en cuanto a sugerir mejoras a la disciplina. En [Zhou et al., 2004] se propone un algoritmo que selecciona casos de prueba relevantes al sistema que se desea testear. Los autores sugieren un testing incremental del sistema mediante el testing del cdigo base aislado en primera instancia, para luego ir probando en forma independiente cada aspecto individual entremezclado con el cdigo base hasta llegar al testing del sistema completo cdigo base y todos los aspectos existentes- de la misma forma que se testeara un sistema tradicional. Este mismo concepto se extiende en [Zhou, 2004].
Adrin Eidelman
47/148
FIUBA
[Zhao, 2003] introduce el uso de grafos de dependencia para describir relaciones entre clases y aspectos. El trabajo propone un algoritmo que construye grafos que muestran los miembros de las clases y de los aspectos y luego utiliza arcos y vrtices para reflejar el weaving y los pointcuts respectivamente, de forma de conectar los grafos entre s. Estos grafos pueden ser de utilidad para analizar las relaciones entre cdigo base y aspectos y determinar los posibles casos de prueba. En [Zhao & Rinard, 2003; Ishio et al., 2004] se propone similarmente el uso de grafos para comprender las relaciones entre clases y aspectos. Muy pocos trabajos abordan el problema especfico de debugging en desarrollos AOP. [Eaddy et al., 2005] es, hasta donde tenemos conocimiento, el nico trabajo de investigacin que ha tratado la misma problemtica que se plantea en esta tesis. El trabajo propone una serie de propiedades de debugging que, segn los autores, debera incluir cualquier plataforma para desarrollos AOP, de forma de brindar un soporte ideal al debugging en desarrollos de este tipo. En general, las propiedades presentadas intentan otorgar al usuario un mayor control sobre el flujo de ejecucin del programa, el cual se ve alterado en gran medida al entremezclar aspectos con el cdigo base. Por ejemplo, la posibilidad de habilitar o deshabilitar aspectos en tiempo de ejecucin, o la capacidad de introducir nuevos aspectos en forma no anticipada son propiedades que no slo brindan al usuario la posibilidad de manipular la ejecucin, sino que tambin permiten a ste encontrar problemas con mayor facilidad. Al igual que el modelo de fallas presentado en [Alexander et al., 2004], las propiedades planteadas en [Eaddy et al., 2005] han servido como base para la definicin de los requerimientos a implementar en SetPoint, por lo que sern explicadas en mayor detalle ms adelante.
Temas pendientes de investigacin

Son varios los desafos existentes en lo referente a testing y aseguramiento de la calidad en desarrollos orientados a aspectos. El presente trabajo trata principalmente aspectos de debugging del paradigma, pero ste no es el nico tema de la materia que es necesario abordar. Los interrogantes presentados a continuacin, basados principalmente en los tpicos propuestos para el Second Workshop on Testing Aspect-Oriented Programs, resumen los temas que estn
Adrin Eidelman
48/148
FIUBA
siendo discutidos en la comunidad y otorgan una muestra adicional acerca de la inmadurez de esta disciplina: Cmo testeamos unitariamente los aspectos? Muchas veces el comportamiento que se espera obtener al aplicar aspectos en un programa est parcialmente implementado en el cdigo de los mismos, ya que se requiere del contexto post-weaving para obtener el funcionamiento esperado. Por otro lado, el comportamiento obtenido puede potencialmente variar de contexto a contexto, lo cual provoca que el testing aislado de aspectos es decir, como unidades independientes- sea problemtico. Este hecho implica la necesidad de encontrar nuevas estrategias y tcnicas para lograr un adecuado testing unitario de aspectos. Cmo testeamos los programas una vez realizado el proceso de weaving? No siempre el comportamiento que se obtiene una vez realizado el proceso de weaving se corresponde con lo que se tena en mente previo a realizar este proceso. A su vez, el control que se tiene sobre el artefacto resultante, y por lo tanto la capacidad de testing sobre el mismo, se ven reducidos. Es importante por lo tanto contar con tcnicas para entender los efectos que produce el weaving sobre el resultado final. Cmo predecimos el comportamiento que surge de las interacciones entre los aspectos y la dimensin base? Generalmente la interaccin entre aspectos y cdigo base no es directamente deducible al examinar el cdigo fuente correspondiente. Esta situacin produce que las fallas que puedan llegar a surgir sean ms difciles de detectar y diagnosticar. Es necesario como a contar con reducir tcnicas su que permitan tanto de a desarrolladores testers desentendimiento estas
interacciones y tener un mayor control sobre las mismas. Qu tipo de fallas cometen los programadores al utilizar lenguajes AOP? Como se ha mencionado a lo largo de este trabajo y se profundizar ms adelante en el mismo- las caractersticas y particularidades de AOP provocan la aparicin de nuevos tipos de fallas. Estas son difciles de detectar y diagnosticar, hecho que provoca una importante limitacin para el uso efectivo del paradigma de aspectos. Es importante entender qu nuevos tipos de falla pueden ocurrir y
Adrin Eidelman
49/148
FIUBA
cmo estas se manifiestan al ejecutar un programa AOP. A su vez, es necesario poder contar con tcnicas que ayuden a los desarrolladores a evitar estas fallas y a detectarlas con mayor facilidad. Qu diferencias y similitudes existen al testear programas orientados a objetos y programas orientados a aspectos? Las tcnicas y estrategias de testing para desarrollos orientados a objetos no siempre son las adecuadas en desarrollos AOP. Es necesario determinar si las tcnicas que se usan en POO pueden ser utilizadas de igual manera en AOP y de lo contrario discutir cmo estas pueden adaptarse o modificarse para el nuevo paradigma.
Resumen
Se presentaron en este captulo algunos trabajos de investigacin existentes que guardan algn grado de relacin con el tema abordado en la presente tesis. Destacamos dos de ellos que han servido como base y gua para profundizar sobre temas de debugging en aspectos: el modelo de fallas para AOP propuesto en [Alexander et al., 2004] y las propiedades para una solucin ideal de debugging para AOP propuestas en [Eaddy et al., 2005]. La explicacin de ambos trabajos, al ser centrales al desarrollo de este trabajo, ser extendida en los sucesivos captulos. Finalmente se enumeraron los principales temas pendientes de investigacin en lo referente a testing y aseguramiento de la calidad en desarrollos orientados a aspectos.
Adrin Eidelman
50/148
FIUBA
6. Definicin del problema y objetivos

Como se ha explicado en el captulo 2, la programacin orientada a aspectos introduce conceptos tales como joinpoints, advices y aspectos, los cuales son particulares de este paradigma y no se presentan en desarrollos procedurales u orientados a objetos. Se ha mencionado tambin que estas particularidades del paradigma AOP dan nacimiento a nuevos desafos en testing y debugging, debido a que las tcnicas y herramientas existentes no son las ms adecuadas para esta clase de soluciones. El desarrollo de herramientas de este tipo ha quedado relegado con respecto al de weavers y otras herramientas AOP y, por lo tanto, incorporar los nuevos conceptos del paradigma al testing y debugging sigue siendo una cuenta pendiente. Ahora bien, cules son los problemas que se presentan al incorporar estos nuevos conceptos en un desarrollo AOP? En el presente captulo se explicar con mayor detalle de qu manera las caractersticas particulares de la programacin orientada a aspectos introducen nuevas fuentes de fallas a los programas, las cuales dan lugar a la necesidad de encontrar tcnicas y herramientas particulares o extender las actuales- que nos permitan asegurar la calidad de los desarrollos. Por otro lado, se presentarn ciertas particularidades tcnicas de la implementacin de SetPoint las cuales muchas veces se extienden a otras plataformas AOP- que hacen que la experiencia de debuggear una aplicacin que utiliza el framework se torne bastante dificultosa. Estos dos elementos las fallas particulares de AOP y las caractersticas propias de SetPoint- constituyen las principales fuentes de problemas que motivan la bsqueda de un mejor soporte al debugging en desarrollos AOP en el presente trabajo.
Por qu testear desarrollos AOP es diferente?

Es importante entender cules son las cuestiones clave que hacen que el aseguramiento de la calidad en desarrollos AOP presente nuevos desafos. Estas cuestiones estn dadas aunque parezca obvio decirlo- por la introduccin del aspecto como unidad de modularizacin. Ciertas particularidades en la implementacin de los aspectos, as tambin como las interacciones entre estos y
Adrin Eidelman
51/148
FIUBA
el cdigo base producto del proceso de weaving hacen que testear desarrollos AOP sea diferente a hacerlo en desarrollos procedurales u orientados a objetos. En primer lugar, los aspectos no poseen existencia de forma
independiente. Los mismos dependen de un contexto dado por la dimensin base con la cual estos interactan en tiempo de ejecucin y por lo tanto su implementacin puede ser fuertemente dependiente de la implementacin de las clases con las cuales se relacionan. En ese caso, los cambios a estas ltimas son propensos a propagarse hacia los aspectos. Por otro lado, los flujos de control y datos no resultan evidentes al analizar el cdigo fuente de las clases o de los aspectos. Previo al proceso de weaving, no es posible conocer la estructura de los flujos de control y datos que poseer el programa una vez entretejido. Por ltimo, pueden aparecer comportamientos no esperados producto del orden de weaving que se asigne cuando mltiples aspectos deben aplicarse sobre un mismo joinpoint. En resumen, la incorporacin del aspecto introduce una serie de efectos secundarios particulares del paradigma, los cuales pueden resultar en la aparicin de fallas caractersticas del paradigma AOP. Identificar estas fallas es un paso previo ineludible para definir tcnicas y herramientas que nos permitan construir soluciones AOP de calidad. Una propuesta de un modelo de fallas para AOP es presentada en la prxima seccin.
Un modelo de fallas para AOP

En [Alexander et al., 2004] se presenta un modelo de fallas para AOP, el cual describe las particularidades del paradigma que pueden dar lugar a la aparicin de fallas caractersticas en desarrollos orientados a aspectos. La misma, aunque inicial y sujeta a eventuales mejoras, constituye una excelente base sobre la cual comenzar a trabajar. En esta seccin se explican los conceptos desarrollados en ese trabajo.
Adrin Eidelman
52/148
FIUBA
La naturaleza de las fallas en desarrollos AOP

Una falla, cualquiera sea, puede [Alexander & Bieman, 2002; Alexander et al., 2004]: 1. Encontrarse en una porcin del cdigo base que no es afectado por ningn aspecto. 2. Encontrarse en el cdigo de algn aspecto en particular, aislado del contexto del programa entretejido. 3. Surgir por la interaccin entre un aspecto y el cdigo base. 4. Surgir por la ejecucin de ms de un aspecto sobre un mismo punto de ejecucin del cdigo base. En el primero de los casos, la falla es particular de la dimensin base y se presenta incluso sin la existencia del weaving. Es decir, no requiere de un contexto de aspectos para manifestarse como tal. En el segundo de los casos, la falla se produce en cualquier composicin que incluya al aspecto que la contiene, y no est dada por la interaccin propia entre cdigo base y aspectos. En cualquiera de estos dos casos, las fallas son particulares del cdigo que las contiene y su deteccin y diagnstico puede realizarse con las mismas tcnicas y herramientas con las que contamos en la actualidad. Estas fallas no se encuentran inducidas por el proceso de weaving. Las fuentes de fallas que se describen en los puntos 3 y 4 son las que nos interesan, ya que son las que pueden dar origen a defectos caractersticos de desarrollos AOP. En estos casos no slo se presenta la aparicin del aspecto como unidad, sino que adems la posible falla est dada por la interaccin entre aspectos y la abstraccin primaria o dimensin base del problema. Puede suceder, por ejemplo, que el weaving introduzca nuevas dependencias de datos o de control (caso 3), o que una cierta permutacin en el orden de los aspectos que aplican a un mismo joinpoint produzca un comportamiento no deseado durante la ejecucin (caso 4), entre otras cosas. Las potenciales fallas propuestas en [Alexander et al., 2004] provienen de estas dos ltimas fuentes.
Adrin Eidelman
53/148
FIUBA
Modelo de fallas candidato

El modelo de fallas candidato se basa en las particularidades del paradigma, aunque las fallas propuestas pueden estar influenciadas por la implementacin particular de la plataforma AOP con la cual se trabaja. En este caso, el modelo se ha definido a travs del anlisis de las peculiaridades de AspectJ22. Precisin en la definicin de pointcuts (F1) Como hemos visto, la definicin de pointcuts permite predicar sobre los joinpoints de forma de establecer un conjunto de puntos en donde deben ejecutarse ciertos aspectos. Si la definicin no es precisa puede presentarse la situacin en la que existan joinpoints que deberan ser seleccionados y no lo son (definicin fuerte) o joinpoints que deberan ser ignorados y son seleccionados (definicin dbil). Cualquiera sea la situacin, este hecho puede ocasionar un comportamiento incorrecto en el programa final. Incorrecto orden de ejecucin de aspectos (F2) Puede darse el caso que un joinpoint pertenezca a ms de un pointcut y por lo tanto dos o ms aspectos deban aplicarse en un mismo punto de ejecucin. El orden en que estos aspectos son relacionados con el programa base puede alterar el comportamiento del sistema, especialmente si estos aspectos poseen interacciones entre ellos. En el caso de AspectJ, el orden de weaving es determinado mediante la asignacin de prioridades a los aspectos. Si la asignacin de prioridades se realiza incorrectamente, o directamente no se realiza, el programa puede presentar un funcionamiento incorrecto. Incapacidad de establecer las post-condiciones esperadas (F3) Cuando invocamos un mtodo durante la ejecucin de un programa esperamos que el mismo se comporte de acuerdo a su contrato. Esto debe suceder siempre que el cliente que utiliza el mtodo asegure el cumplimiento de las precondiciones, caso en el cual se podr asumir que las post-condiciones del mtodo
22
La evolucin de AOP ha sido fuertemente influenciada por los esfuerzos de la comunidad Java en ese sentido. Consecuentemente, AspectJ se ha transformado en la herramienta principal para el desarrollo de soluciones orientadas a aspectos y de esta manera las particularidades de su implementacin se han tomado muchas veces como base terica para el desarrollo de otras herramientas AOP. Siguiendo esta tendencia, resulta lgico basarse en AspectJ para definir un modelo de fallas candidato.
Adrin Eidelman
54/148
FIUBA
sern satisfechas. En desarrollos orientados a aspectos, esto debe respetarse independientemente de la existencia de aspectos relacionados con el cdigo base. Es decir, los contratos de comportamiento deberan mantenerse incluso luego del proceso de weaving. Incapacidad de preservar invariantes (F4) Adems de establecer sus post-condiciones, los mtodos deben asegurar que los invariantes son preservados. De la misma manera que se describi en el punto anterior, es necesario asegurar que el proceso de weaving no resulte en la violacin de estos. Restriccin de la seleccin de joinpoints al contexto de ejecucin (F5) Algunas plataformas AOP permiten la seleccin de joinpoints de acuerdo a condiciones del contexto de ejecucin23. Para dar un ejemplo, es posible definir la pertenencia de un mtodo X a un pointcut de acuerdo a si aqul ha sido llamado desde el mtodo Y. Si el mtodo X es ejecutado, pero no fue invocado desde el mtodo Y, entonces ste no debe ser seleccionado durante el proceso de weaving24. La incapacidad de restringir la ejecucin al contexto correcto puede resultar en fallas durante la ejecucin del programa. Modificaciones incorrectas en las dependencias de control (F6) El uso de la expresin around permite modificar el flujo de ejecucin de un programa y por consiguiente las dependencias de control del programa base. Cualquier modificacin al flujo de control puede resultar en el malfuncionamiento de la aplicacin. El listado de fallas identificadas permite comprender que la implementacin de tcnicas de programacin orientada a aspectos introduce nuevos tipos de fallas que no existen en desarrollos que no implementan conceptos AOP. La posibilidad de encontrar, evitar o mitigar estas fallas puede ser brindada por un adecuado soporte al debugging.
23
SetPoint no incluye, al momento de escribir este trabajo, la capacidad de predicar sobre condiciones del contexto de ejecucin. 24 En AspectJ esto se logra mediante el uso de la expresin cflowbelow.
Adrin Eidelman
55/148
FIUBA
Debuggeando aplicaciones en SetPoint

Hemos visto hasta ahora las peculiaridades de la programacin orientada a aspectos que motivan la necesidad de extender las actuales tcnicas de testing y debugging. Pueden existir a su vez particularidades tcnicas de las plataformas AOP que influyan en el soporte de debugging que stas pueden ofrecer. Es el caso de SetPoint. La implementacin actual de SetPoint presenta una limitacin fundamental para brindar un adecuado soporte de debugging: no es posible realizar debugging a nivel cdigo fuente de los assemblies aspectualizados. Es difcil imaginar hoy en da el debuggear una aplicacin sin contar con esta tcnica. Qu implica no poder realizar debugging a nivel cdigo fuente la aplicacin? Estas son algunas de las consecuencias: No es posible analizar el flujo de ejecucin del programa a travs del cdigo fuente. No es posible ejecutar paso a paso el programa. No es posible setear breakpoints. No se cuenta con la posibilidad de evaluar los valores de variables en el contexto de ejecucin. Actualmente son numerosas las plataformas para desarrollo AOP que no brindan esta posibilidad. En el caso de SetPoint, esta limitacin est impuesta por el modelo de weaving que utiliza. Como se mencion en el captulo 3, ste puede tener una influencia negativa en el soporte al debugging de la herramienta.
Modelos de weaving
De acuerdo al mecanismo que se utilice para relacionar el cdigo base con los aspectos, el proceso de weaving puede ser clasificado en dos grupos principales: invasivo o no invasivo [Eaddy et al., 2005]. El proceso de weaving de una determinada plataforma pertenecer a uno u otro grupo dependiendo de si se realizan o no transformaciones al cdigo fuente o binario- del programa base para lograr la funcionalidad deseada. Se denomina weaver no invasivo a aquel que no requiere realizar agregados o modificaciones al cdigo previo a que la aplicacin comience su ejecucin
Adrin Eidelman
56/148
FIUBA
[Redmond & Cahill, 2002]. A diferencia de stos, los weavers invasivos se valen de modificaciones para lograr el entretejido; estos ltimos pueden catalogarse a su vez como weavers de cdigo fuente o weavers binarios. Los weavers de cdigo fuente relacionan el cdigo fuente del programa base con el cdigo fuente de aspectos para obtener un cdigo entretejido que luego es compilado para obtener el programa final. En pocas palabras, realizan una transformacin de cdigo a cdigo. En cambio, los weavers binarios realizan el proceso de entretejido a partir del programa base y los aspectos previamente compilados. Este mecanismo de weaving tiene las ventajas de permitir el entretejido entre ambos componentes incluso sin contar con el cdigo fuente y en algunas plataformas- la posibilidad de soportar el uso de diferentes lenguajes de programacin. Una tercera ventaja radica en la posibilidad de realizar el weaving recin en tiempo de ejecucin, cosa que no es posible realizar con un weaver de cdigo fuente. La Figura 6-1, adaptada de [Eaddy et al., 2005] ilustra los modelos de weaving mencionados.
Fuente
Cdigo Fuente Programa Base
Cdigo Fuente Entretejido Compilacin Compilacin
Compilacin
Binario
Binario Programa Base
W ea vi
W ea
vin g
Cdigo Fuente Aspectos
We av in
g
Binario Entretejido
g vin ea
ng
Binario Aspectos
Carga Carga Carga
Carga Source weaving
Runtime
Binary weaving Weaving no invasivo
Entorno de Ejecucin (Runtime)
Figura 6-1: Modelos de weaving
Adrin Eidelman
57/148
FIUBA
El modelo de weaving de SetPoint cae dentro de la categora de invasivo y binario. Como se ha explicado en el captulo 3, SetPoint requiere la compilacin del programa base y el cdigo de aspectos por separado, para luego previa ejecucin de los procesos de preweaving y semanticacin- relacionarlos en tiempo de ejecucin y obtener el programa entretejido (Figura 6-2)25. La eleccin de este modelo tiene un fuerte impacto en el soporte al debugging de la plataforma, y es justamente lo que impide actualmente a un desarrollador que trabaje con SetPoint realizar debugging a nivel cdigo fuente del programa base. Esto sucede porque se pierde la informacin de debugging.
Fuente
Compilacin
Compilacin
Binario
Binario Programa Base
Pr ew ea
vin
Binario Programa Base c/Hooks
Binario Aspectos
Carga
Runtime
Carga
Figura 6-2: Modelo de weaving en SetPoint
25
La figura muestra el caso en el cual no es necesario aplicar aspectos sobre otras dimensiones transversales. De presentarse este caso, el cual es perfectamente vlido, el pre-proceso deber aplicarse de igual manera al archivo binario de aspectos.
Adrin Eidelman
58/148
FIUBA
Informacin de debugging
La informacin de debugging es aquella que permite en cualquier plataformarealizar debugging a nivel cdigo fuente. Bsicamente esta informacin est compuesta por la relacin entre lneas de cdigo fuente y cdigo de mquina, informacin acerca de las variables y cualquier otra informacin que permita utilizar esta tcnica al depurar una aplicacin. En el caso particular de las plataformas de desarrollo de Microsoft, esta informacin es contenida en un archivo independiente cuya extensin es PDB, por program database26. En general, al archivo que contiene la informacin de debugging se lo denomina archivo de smbolos. El archivo PDB almacena entre otras cosas: El mapeo entre los offsets del cdigo IL y las lneas de cdigo fuente. El mtodo que funciona como punto de entrada en el programa (ej, Main en C#). Los nombres de las variables locales
Si no se cuenta con este archivo, no es posible debuggear cdigo fuente en entornos de desarrollo Microsoft. El carcter invasivo y binario del modelo de weaving de SetPoint provoca que la informacin de debugging de una aplicacin aspectualizada quede obsoleta. Cuando se realiza el proceso de preweaving, mediante el cual se reemplazan los joinpoints por enlaces que invocan al weaver en tiempo de ejecucin, el assembly de la aplicacin es modificado y por lo tanto el archivo de smbolos existente ya no se corresponde con el assembly aspectualizado. An ms, si se examinan en mayor detalle las actividades de pre-procesamiento de assemblies en SetPoint, tambin se deduce que no slo es el preweaving el que invalida la informacin de debugging: el proceso de semanticacin encargado de generar la ontologa de cdigo- incorpora la informacin recabada como un recurso embebido del assembly que procesa. Esto tambin constituye
26
El uso de archivos PDB fue adoptado por Microsoft a partir de las versiones 16-bits de Visual C++, luego extendido a la plataforma Visual Studio y vigente en la actualidad.
Adrin Eidelman
59/148
FIUBA
una transformacin al archivo y por lo tanto un factor ms que influye en la prdida de la informacin de debugging. Este problema no existira si la herramienta de instrumentacin de assemblies utilizada -en el caso de SetPoint se utiliz PERWAPI [PERWAPI]- tuviese la capacidad de volver a emitir el archivo PDB reflejando las transformaciones aplicadas al assembly. Esto no slo no es soportado en PERWAPI, sino que ninguna de las herramientas de instrumentacin existentes al momento de desarrollar SetPoint contaba con esa propiedad. En conclusin, luego de los procesos de preweaving y semanticacin se pierde la posibilidad de realizar debugging a nivel cdigo fuente del programa aspectualizado. En el mejor de los casos no ser necesario aplicar aspectos sobre dimensiones transversales y el assembly de aspectos no sufrir transformaciones, conservando as el PDB original y manteniendo la posibilidad de utilizar esta tcnica durante la ejecucin de los aspectos (Figura 6-3). A pesar de esto, no poder hacerlo en el programa base constituye una limitacin muy grande.
PDB
PDB
PDB
Compilacin
Assembly Aspectos
Carga
Figura 6-3: Prdida de la informacin de debugging para el programa base
El caso menos optimista desde un punto de vista del debugging claro estrequerir aplicar aspectos sobre otros aspectos, provocando la situacin que
Adrin Eidelman
60/148
Compilacin
Assembly Programa Base
Preweaving + Semanticacin
Assembly Programa Base Aspectualizado
Carga
FIUBA
muestra la Figura 6-4, en la cual se pierde toda posibilidad de realizar debugging del cdigo.
PDB
PDB
PDB
PDB
Compilacin
Assembly Aspectos
Assembly Aspectos Aspectualizado
Carga
Figura 6-4: Prdida completa de la informacin de debugging
Los archivos de smbolos PDB poseen un formato propietario de Microsoft y por lo tanto resulta muy difcil actualizar la informacin de debugging si se realizan transformaciones al assembly original. En el caso de SetPoint, los procesos de preweaving y semanticacin no slo alteran el mapeo entre IL y cdigo fuente sino que adems, al modificar el assembly original, se pierde la referencia cruzada entre el assembly y su correspondiente archivo PDB. Desconocemos exactamente qu controles se realizan para validar esa relacin no existe documentacin publicada al respectopero evidentemente van ms all de un simple chequeo de coincidencia entre los nombres de archivo. La prdida de informacin de debugging es la razn por la cual prcticamente todas las plataformas .NET que realizan weaving binario no soportan el debugging a nivel cdigo fuente.
Desentendimiento de las actividades propias de AOP

La prdida de la informacin de debugging no es el nico inconveniente que se presenta al utilizar weaving invasivo. Otro aspecto importante a tener en cuenta para lograr un adecuado soporte tiene que ver con el desentendimiento por parte
Adrin Eidelman
61/148
Compilacin
Carga
FIUBA
del desarrollador de las actividades propias de la programacin orientada a aspectos durante el debugging. Cuando se realiza el debugging a nivel cdigo fuente de una aplicacin AOP es deseable mantener una visin del programa como si las tareas de weaving no existieran. En general, el desarrollador que realiza el debugging, querr concentrarse nicamente en el cdigo particular de la aplicacin que desarrolla sea ste cdigo base o cdigo de dimensiones transversales- y no en aquel que tiene que ver con la implementacin de los conceptos AOP, como pueden ser las tareas propias del weaver. Este desentendimiento puede resultar difcil de lograr para plataformas que utilizan un weaving invasivo, ya que el debugger debera poder distinguir entre el cdigo propio de la aplicacin y el cdigo del weaver. Por otro lado, pueden existir situaciones en las cuales el desarrollador desea poder tener control de las actividades AOP con el fin de diagnosticar fallas particulares. De esta forma, es deseable poder contar con la capacidad de desentenderse de estas actividades AOP pero tener a su vez la posibilidad de introducirse en el funcionamiento particulares. Cmo es la situacin de SetPoint en relacin a los conceptos mencionados? Al realizar el debugging a nivel cdigo fuente en SetPoint como se explic, en el mejor de los casos es posible nicamente a nivel cdigo de aspectos- es inevitable tener que lidiar con el cdigo propio del weaver. Esto adems provoca que al realizar un debugging paso a paso, se produzcan saltos inesperados entre el cdigo de aspectos y el cdigo del weaver (Figura 6-5). El debugging de esta forma puede resultar una experiencia confusa para el desarrollador. En resumen, la imposibilidad de realizar debugging a nivel cdigo fuente sumada a la incapacidad de proveer la propiedad de desentendimiento son dos puntos crticos a solucionar para lograr una adecuada experiencia de debugging no slo en SetPoint, sino tambin en muchas otras plataformas que implementan los conceptos AOP de una forma similar. particular de la plataforma para ciertos casos
Adrin Eidelman
62/148
FIUBA
(a)
(b)
Figura 6-5: El cdigo propio del weaver (a) se entremezcla durante el debugging con el cdigo de aspectos (b) haciendo confusa la tarea.
Adrin Eidelman
63/148
FIUBA
Objetivos de la tesis
De acuerdo a los problemas planteados a lo largo del captulo, estamos en condiciones de presentar de forma concreta los objetivos del trabajo, los cuales se enumeran a continuacin: Presentar las propiedades para un soporte ideal de debugging para AOP que facilite y mejore la experiencia de debugging en el desarrollo de soluciones de este tipo. Estas propiedades surgirn principalmente a partir del modelo de fallas propuesto en [Alexander et al., 2004], de la solucin brindada en [Eaddy et al., 2005] y de los problemas particulares de la implementacin tcnica de SetPoint. Analizar SetPoint. Disear y construir, previo anlisis de factibilidad, los requerimientos propuestos dentro del alcance del trabajo. los requerimientos que permitan brindar las principales
propiedades de debugging planteadas en el marco de la plataforma
Resumen
Se presentaron en este captulo las dos principales causas que motivan la necesidad de mejorar el debugging en desarrollos orientados a aspectos. Por un lado se menciona la complejidad inherente del paradigma AOP, que introduce una serie de posibles fallas en los desarrollos que no existan al utilizar otras tcnicas de programacin. Estas fallas se resumen en [Alexander et al., 2004] y estn dadas por la introduccin del aspecto como unidad de modularizacin. En general estn ligadas a las variaciones que pueden introducir los aspectos al flujo de ejecucin, el cual muchas veces no puede ser previsto o se dificulta su comprensin por parte del desarrollador. Por el otro se presentan las dificultades propias que introduce el modelo de weaving de SetPoint, las cuales son comunes a otras plataformas AOP. Estas dificultades estn dadas principalmente por la prdida de la informacin de debugging, restringiendo la posibilidad de realizar debugging a nivel cdigo fuente y por la incapacidad de desentenderse de las actividades propias del
Adrin Eidelman
64/148
FIUBA
weaver, resultando en una experiencia confusa la de buscar y encontrar las fallas en el programa. A partir de estos dos orgenes de complejidad se refinaron los objetivos de la tesis, los cuales se resumen en definir una serie de requerimientos que mejoren la experiencia de debugging e implementarlos en SetPoint, contribuyendo de esta forma en la madurez del proyecto.
Adrin Eidelman
65/148
FIUBA
7. Mejorando la experiencia de debugging en desarrollos AOP

Planteada la problemtica que se desea afrontar, el objetivo de este captulo es presentar una serie de propiedades que debera brindar a nuestro entender una solucin ideal de debugging para desarrollos orientados a aspectos. Estas propiedades constituyen slo una primera propuesta la cual podr refinarse a medida que surjan nuevas necesidades. Es necesario dejar en claro ciertos puntos antes de entrar en el detalle de la solucin propuesta. Como se vio en el captulo anterior, los desafos del debugging estn dados por un lado por las caractersticas propias de la programacin orientada a aspectos reflejadas en el modelo de fallas propuesto en [Alexander et al., 2004]-, y por el otro por las limitaciones existentes en muchas herramientas de desarrollo AOP como consecuencia directa y no deseada de su implementacin tcnica -. El carcter tcnico de estas limitaciones hace que sea factible poder solucionarlas. Si hallamos por ejemplo la forma de actualizar la informacin de debugging contenida en el archivo de smbolos, el problema de no contar con la posibilidad de realizar debugging a nivel cdigo fuente obviamente dejar de estar presente. Por el contrario, las fallas caractersticas de AOP son inherentes al paradigma: podemos buscar herramientas que nos permitan reducir la probabilidad de ocurrencia de las fallas o detectarlas con mayor facilidad, pero seguirn siendo propensas de existir. Por citar un ejemplo, para el caso en que el orden de ejecucin de aspectos sobre un mismo joinpoint produzca un comportamiento no deseado podramos pensar en proveer un mecanismo de priorizacin o contar con la posibilidad de observar en qu orden los aspectos son ejecutados. Sin embargo, la falla se seguir produciendo si los aspectos se priorizan incorrectamente o si el desarrollador no es capaz de detectar el defecto al observar el orden de ejecucin. Esto sucede de forma general para todas las fallas caractersticas de AOP. Un segundo aspecto que es necesario dejar en claro -aunque parezca obvio- es que, dado que el objetivo del trabajo es mejorar el soporte al debugging en desarrollos AOP, las propiedades propuestas estarn directamente relacionadas con
Adrin Eidelman
66/148
FIUBA
esta actividad y las sub-actividades que la conforman27. No se buscar proponer mejoras a los problemas planteados desde otras actividades o disciplinas que no correspondan al debugging de aplicaciones. El debugging a nivel cdigo fuente, por citar un ejemplo, es clave para encontrar el origen de una falla sub-actividad del proceso de debugging- y por lo tanto se encuadra dentro del alcance del trabajo. A partir de lo expresado en el prrafo anterior, es lgico asumir que no todos los problemas presentados en el captulo 6 tendrn una solucin o una forma de afrontarlos desde un punto de vista del debugging. En definitiva, se intentar brindar propuestas que signifiquen una mejora con respecto a la situacin actual, con la esperanza que futuros trabajos presenten nuevas y mejores soluciones, especialmente en relacin a los problemas que queden fuera del alcance de esta tesis.
Propiedades de una solucin ideal de debugging

En lo que resta del captulo se presentarn una serie de propiedades que debera brindar toda plataforma AOP para garantizar un adecuado soporte al debugging. El listado de propiedades surge principalmente del anlisis realizado en [Eaddy et al., 2005] y se ha extendido en el presente trabajo de forma de atacar problemticas no alcanzadas por el listado original28. Se definen a continuacin las propiedades identificadas para profundizar sobre la manera en que stas intentan mejorar la situacin problemtica planteada.
Idempotencia
La capacidad de la plataforma AOP de brindar debugging a nivel cdigo fuente depende exclusivamente de la preservacin de la informacin de debugging de la aplicacin. Denominaremos la propiedad de preservar esta informacin con el nombre
27 28
de
idempotencia29.
La
idempotencia
asegura
que
el
programa
Las sub-actividades del debugging fueron presentadas en el captulo 4. A pesar de que gran parte del esfuerzo de investigacin de la presente tesis fue realizado con anterioridad a la publicacin de [Eaddy et al., 2005], se decidi tomar como base las propiedades propuestas en ese trabajo, teniendo en cuenta los puntos en comn y de forma de enfocar el esfuerzo en la misma direccin. Las principales propiedades propuestas en el trabajo de investigacin mencionado ya haban sido identificadas como puntos de mejora al inicio de nuestro trabajo. 29 En computacin, se denomina idempotencia a la cualidad de un elemento de comportarse de la misma manera al ser utilizado muchas veces o al ser utilizado una sola, de forma similar a la nocin de idempotencia usado en matemticas. Una operacin idempotente es aquella en la cual no existen diferencias, errores o inconsistencias si la operacin es realizada una o muchas veces.
Adrin Eidelman 67/148
FIUBA
entretejido posea la misma capacidad de ser debuggeado que el programa original. Para el caso particular de entornos de desarrollo Microsoft, la propiedad de idempotencia implica mantener un archivo de smbolos vlido para el programa una vez realizado el proceso de weaving. Esto es difcil de lograr debido a que es necesario propagar al PDB el cual posee un formato propietariolas transformaciones que se realizan con el fin de obtener el programa entretejido. No sucede lo mismo para las plataformas Java que utilizan weaving binario, las cuales s satisfacen la propiedad de idempotencia. En Java, la informacin de debugging se almacena dentro mismo del archivo binario o class file30, junto a la definicin de clase y el cdigo binario. Al estar la informacin de debugging localizada en un mismo archivo y estar el formato de la informacin bien definido y documentado, la propagacin de las transformaciones a la informacin de debugging se torna mucho ms sencilla y factible de realizar. Como se vio en el captulo anterior, los weavers no invasivos cumplen por s solos con la propiedad de idempotencia ya que no provocan transformaciones al cdigo del programa. Al solucionar el problema de la prdida de informacin de debugging, la propiedad de idempotencia provee al desarrollador a travs de la capacidad de realizar debugging a nivel cdigo fuente- una herramienta para detectar principalmente fallas producidas por incorrectas dependencias de control (fallas de tipo F6)31. La ejecucin paso a paso del programa entretejido permite comprender y controlar el flujo de ejecucin de la aplicacin a travs del cdigo fuente, y por lo tanto facilita la bsqueda de los orgenes del defecto. De la misma manera, el anlisis de la ejecucin al realizar debugging a nivel cdigo fuente facilita la deteccin de imprecisiones en la definicin de pointcuts (F1) al permitir al desarrollador observar en qu joinpoints se produce la ejecucin de funcionalidades transversales. Existen de todas maneras dos obstculos importantes en relacin a la deteccin de los tipos de falla mencionados. El primero de ellos tiene que ver con lo expresado en el captulo anterior acerca de la necesidad de desentendimiento por parte del desarrollador de las tareas propias del weaver. Comprender el flujo de ejecucin del programa y detectar las fallas relacionadas puede tornarse sumamente complicado si las actividades AOP se entremezclan con el cdigo del programa al realizar la ejecucin controlada. Por otra parte, el debugging de cdigo fuente como tcnica
30
El class file es el formato de archivo al cual los programas Java son compilados. El archivo puede ser luego ejecutado por cualquier implementacin de la Java Virtual Machine. 31 De aqu en ms nos referiremos a las fallas caractersticas a travs de su identificacin: F1, F2,, F6.
FIUBA
de observacin requiere una comprensin detallada del cdigo y por lo tanto no siempre resulta la mejor herramienta para la deteccin de fallas de tipo F1 y F6. Se intentar mejorar esta situacin a travs de propiedades adicionales.
Desentendimiento
El concepto de desentendimiento de las actividades propias de AOP durante el debugging ya fue presentado en el captulo anterior. Entenderemos por desentendimiento a la posibilidad de ocultar las actividades AOP durante el debugging, de forma que el desarrollador pueda concentrarse exclusivamente en su propio cdigo. Al ser desentendido, el desarrollador realiza el debugging de la aplicacin de la misma manera que si el weaving no existiera. Cul es el inconveniente que presenta el no poder ser desentendido de las actividades AOP? Supongamos que se desea debuggear el cdigo fuente del siguiente algoritmo, el cual implementa la funcin de Fibonacci32:
int fib(int n) { int f, f0 = 1, f1 = 1; while (n > 1) { n = n - 1; f = Math.Sumar(f0, f1); f0 = f1; f1 = f; } Console.WriteLine(f); }
Si se ejecuta paso a paso el cdigo del algoritmo en una plataforma AOP tomemos SetPoint como ejemplo para este caso- las sentencias que se presentarn durante la ejecucin son las que se ilustran en el grafo de control de flujo de la Figura 7-133.
32
Un lector atento se dar cuenta que el algoritmo no calcula bien los valores de la funcin para 0 y 1. Para no hacer ms extenso el algoritmo, y por lo tanto el ejemplo, se mantiene la implementacin para valores de n mayores a 1. 33 La ejecucin del cdigo de los aspectos se resume en una nica sentencia para no complicar an ms el grafo. Obviamente en la generalidad de los casos sta estar conformada por ms de una sentencia.
FIUBA
Entry: fib(n)
int f
int f0 = 1 Statement del weaver 1
8 4 int f1 = 1 9 5 while (n > 1) 10 6 n = n- 1 13 7 f = Math.Sumar(f0, f1)
Statement del weaver 2 11 ... 12 Statement del weaver n Aspecto Y Aspecto X
14
f0 = f1
17
Statement del weaver 1
15
f1 = f
18
Statement del weaver 2
16
Console.WriteLine(f)
19
...
20
Aspecto Z
22
Exit
21
Statement del weaver n
Cdigo base Joinpoint Cdigo de weaving Cdigo de aspectos
Figura 7-1: Flujo de control durante una ejecucin no desentendida
Adrin Eidelman
70/148
FIUBA
Cada una de las sentencias ejecutadas que correspondan a un joinpoint en este caso las marcadas en azul oscuro desencadenar a su vez la ejecucin de una serie de acciones pertenecientes a la lgica del weaver sentencias de la columna central del grfico, el cual determinar si corresponde aplicar un aspecto en ese punto de ejecucin. Esto suceder independientemente de si el joinpoint pertenece o no a algn pointcut, ya que es el weaver quien tiene la tarea de decidir si es necesario aplicar aspectos en estos puntos de ejecucin. El ejemplo ilustrado presenta slo dos joinpoints, pero bastan para dar cuenta de lo confuso que puede resultar el debugging si no es posible evitar la convivencia con las actividades AOP, teniendo en cuenta que las mismas por lo general no forman parte del dominio que el programador est intentando debuggear. Para casos de una complejidad un poco mayor, donde la cantidad de joinpoints puede incrementarse considerablemente, la intervencin del weaver es casi constante y por ende el debugging a nivel cdigo fuente se torna una tarea sumamente confusa. Al contar con la propiedad de desentendimiento, las actividades AOP desaparecen desde el punto de vista del debugging de cdigo fuente, y las sentencias que intercepta el debugger para mostrar en pantalla son las que pertenecen exclusivamente al dominio del problema sobre el cual se est trabajando. Esto es anlogo a cuando se depura una aplicacin y las actividades propias del runtime de ejecucin como por ejemplo la ejecucin del garbage collector o la reserva de espacio en memoria al inicializar variables- no son incluidas en el debugging del cdigo. La Figura 7-2 intenta dar una idea de cmo sera el flujo de ejecucin desentendido para el algoritmo del ejemplo anterior, donde es posible observar que el grafo se ha simplificado considerablemente. La propiedad de desentendimiento se combina entonces con la de idempotencia para proveer un adecuado soporte de debugging a nivel cdigo fuente. Como se explic anteriormente, esta tcnica facilita principalmente la deteccin de fallas de tipo F1 y F6, pero resulta tambin fundamental para comprender el comportamiento interno de una aplicacin.
Adrin Eidelman
71/148
FIUBA
Entry: fib(n)
int f
int f0 = 1
int f1 = 1
while (n > 1)
n = n- 1 8 Aspecto X
f = Math.Sumar(f0, f1) 9 Aspecto Y
10
f0 = f1
11
f1 = f Cdigo base 13 Joinpoint
12
Console.WriteLine(f)
Aspecto Z
Cdigo de aspectos 14 Exit
Figura 7-2: Flujo de control durante una ejecucin desentendida
Intimidad
Denominaremos intimidad a la capacidad de debuggear todas las actividades AOP, incluyendo la ejecucin de aspectos o las tareas de weaving. En general, los investigadores de temas AOP exponen las ventajas del desentendimiento, el cual sin embargo puede resultar una desventaja al tratar de diagnosticar fallas introducidas por la propia plataforma AOP o dadas por la interaccin entre
FIUBA
el programa y la plataforma, o bien cuando se busca comprender el comportamiento interno de las actividades de weaving. Siempre en relacin con las actividades propias de la programacin orientada a aspectos, el desentendimiento otorga al usuario la posibilidad de realizar un debugging de caja negra, mientras que el objetivo de la propiedad de intimidad es permitir al usuario realizar un debugging de caja blanca, tal como se mostr previamente en la Figura 7-1.
Las propiedades de intimidad y desentendimiento son excluyentes: cuando el usuario se desentiende de las actividades AOP a su vez deja de lado la propiedad de intimidad, y viceversa. Lgicamente es deseable poder elegir entre debuggear desentendidamente y debuggear ntimamente en cualquier momento durante la actividad34.
Dinamismo
En [Eaddy et al., 2005] se define dinamismo exclusivamente como la posibilidad de habilitar y/o deshabilitar los aspectos en tiempo de ejecucin. Desde nuestro punto de vista, el dinamismo es un concepto ms general, el cual intenta brindar al desarrollador la posibilidad de tener control en la medida de lo posible sobre las actividades de weaving en tiempo de ejecucin. Ejemplos de dinamismo son la habilitacin y deshabilitacin de aspectos tal cual se define en [Eaddy et al., 2005]- y la posibilidad definir el orden de ejecucin de stos cuando aplican a un mismo joinpoint. Tener control sobre la dinmica de las actividades AOP puede facilitar enormemente encontrar los orgenes de una falla. Tomemos como ejemplo el joinpoint dado por la invocacin al mtodo Math.Sumar del ejemplo del algoritmo de Fibonacci (Figura
7-3), suponiendo que sabemos o sospechamos que existe una falla en este punto
de ejecucin del programa, pero desconocemos exactamente qu es lo que la est provocando.
34
En algunas plataformas -como por ejemplo Smalltalk- existe el soporte para ser ntimo a algunas tareas de la mquina virtual, como la mencionada de garbage collecting.
FIUBA
Aspecto X f = Math.Sumar(f0, f1) Aspecto Y
Figura 7-3: Punto de ejecucin donde se produce la falla
La posibilidad de habilitar y deshabilitar los aspectos en tiempo de ejecucin permite al desarrollador simplificar el problema. Por ejemplo, si se deshabilita el Aspecto X y la falla se sigue produciendo, entonces la ejecucin de ese aspecto ser irrelevante al problema que se est queriendo solucionar. Se puede realizar lo mismo para el Aspecto Y o incluso para ambos, de forma de determinar si el origen de la falla se encuentra en el programa base. Para cada circunstancia del problema, este ejemplo de dinamismo permitir determinar si el o los aspectos son relevantes al defecto en cuestin y as encontrar el origen de la falla con mayor facilidad. Lgicamente, contar con esta posibilidad durante la ejecucin del programa adems de poder realizarlo en tiempo de diseo- facilita enormemente la tarea. Como se explic en el captulo anterior, adems de encontrarse dentro del cdigo del programa base o de un aspecto, la falla puede estar dada por el orden de ejecucin de los aspectos sobre un mismo joinpoint (F2). Siguiendo con el ejemplo anterior, la falla en este caso podra estar dada porque la ejecucin de los aspectos se da en el orden X Y cuando lo correcto sera que se d en el orden Y X. Poder definir el orden de ejecucin o la priorizacin de los aspectos en runtime es otro ejemplo de dinamismo que sirve para detectar fallas de tipo F235.
Introduccin de aspectos
La propiedad introduccin de aspectos brinda al desarrollador la posibilidad de incorporar nuevos aspectos a una aplicacin de forma no anticipada. Bsicamente lo que persigue esta propiedad es poder introducir en runtime funcionalidades relacionadas con el testing o el debugging que permitan encontrar la falla con mayor facilidad, sin la necesidad de detener la ejecucin del programa.
35 Est claro que es fundamental para evitar o solucionar fallas de este tipo contar con un mecanismo de priorizacin u ordenamiento de aspectos. Consideramos que este soporte va ms all del alcance de la actividad propia de debugging.
FIUBA
Funcionalidades transversales que tpicamente se utilizan para este fin son el logging y las aserciones. Tanto el logging como las aserciones tienden a dispersarse por todo el cdigo fuente y por lo tanto resulta natural en un desarrollo orientado a aspectos- modularizar estas funcionalidades. El logging se utiliza frecuentemente como tcnica de observacin, de forma de permitir al desarrollador observar hechos valores de variables, porciones de cdigo alcanzadas, etc.- de una ejecucin36. El uso de aserciones permite comparar automticamente los hechos observados con el comportamiento esperado del programa, y se utilizan bsicamente para controlar condiciones de la ejecucin que puedan provocar infecciones, por ejemplo asegurarse que una variable no posea el valor cero cuando va a ser utilizado como divisor. Probablemente los usos ms comunes que se les da a las aserciones son: Controlar invariantes para asegurar la integridad de los datos Controlar precondiciones y poscondiciones para asegurar la correctitud funcional del programa Teniendo en cuenta esto, las aserciones pueden ser utilizadas para detectar fallas relacionadas con la incapacidad de establecer las poscondiciones esperadas o de preservar invariantes (F3, F4).
Modificaciones en tiempo de ejecucin

La propiedad modificaciones en tiempo de ejecucin otorga al desarrollador la posibilidad de modificar el cdigo base o el cdigo de aspectos sin necesidad de detener su ejecucin, mientras se intenta reproducir el fallo o encontrar el defecto que lo provoca. Esta propiedad es popularmente conocida con el nombre de Edit & Continue y cobra especial relevancia cuando la falla que se desea corregir es difcil de reproducir. Permitir realizar modificaciones en runtime no es algo que sea de utilidad exclusiva para desarrollos orientados a aspectos. Sin embargo se incluye dentro de la lista de propiedades principalmente porque la existencia del proceso de weaving dificulta enormemente la posibilidad de contar con esta tcnica.
36
Generalmente esto se implementa mediante el uso de funciones de impresin a un dispositivo de output, tcnica que muchas veces se la denomina con el nombre de printf debugging.
FIUBA
Si se introducen nuevas sentencias de cdigo al programa o bien si se realizan modificaciones a sentencias existentes, habr que asegurarse que tales modificaciones sigan siendo contempladas dentro del proceso de weaving (Figura
7-4). De lo contrario toda modificacin introducida no formar parte de la solucin

aspectualizada. Esto se torna particularmente complicado para las plataformas que cuentan con un modelo de weaving invasivo, en donde el programa entretejido se obtiene previo a la carga de la aplicacin.
Runtime Weaving
Runtime
Programa Aspectualizado
Modificaciones introducidas
Figura 7-4: Las modificaciones introducidas en runtime deben formar parte del programa aspectualizado
Aislamiento de fallas
La propiedad aislamiento de fallas se refiere a la capacidad del debugger de determinar si un fallo se ha producido en el cdigo base o en el cdigo de los aspectos, e informar al desarrollador quin es el actor responsable. Como se vio en el captulo anterior, los orgenes de las fallas en AOP pueden ser diversos. Si el debugger es capaz de informar qu actor programa base o aspectos- es el responsable de la falla, la tarea de encontrar el origen de la misma se simplifica. La complejidad de proveer esta propiedad radica en que es necesario poder discriminar actividades AOP de tareas de la dimensin base, lo cual puede ser complicado una vez ms- cuando el weaving es de carcter invasivo y en especial con weavers de cdigo fuente.
Adrin Eidelman
76/148
FIUBA
Conocimiento del flujo de ejecucin

Denominaremos conocimiento del flujo de ejecucin a la capacidad del
desarrollador de tener conciencia sobre cmo el weaving influye en el flujo de ejecucin del programa. Este conocimiento incluye saber qu aspectos fueron ejecutados, qu situacin provoc su ejecucin, en qu orden fueron ejecutados, etc. Tener visin de cmo se desencadena el flujo de control en una aplicacin orientada a aspectos puede facilitar la deteccin de fallas provocadas por incorrectas dependencias de control (F6), as tambin como por la incorrecta priorizacin de aspectos (F2) o por definicin imprecisa de pointcuts (F1). Es cierto que las tcnicas o herramientas que se usen como medio para comprender el flujo pueden ser muchas y muy variadas. Ya hemos nombrado el debugging a nivel cdigo fuente como una tcnica posible. Sin embargo, para este tipo de fallas, puede ser conveniente contar con herramientas que muestren visualmente las relaciones entre dimensin base y aspectos, en lugar de basarse en elementos puramente textuales como el cdigo. Deducir fallas en las dependencias de control a partir del cdigo fuente de un programa AOP complejo puede ser sumamente complicado. Una tcnica muchas veces utilizada para comprender el flujo de control de un programa sea ste AOP o no- es el uso de grafos de flujo de control. La Figura 7-1 es un ejemplo de este tipo de grafo. Una caracterstica importante al contar con informacin visual es que, a diferencia del debugging a nivel cdigo fuente, sta permite explorar la historia de la ejecucin de forma de determinar, por ejemplo, qu hechos del programa produjeron que se haya ejecutado el aspecto X o el aspecto Y. Mediante la ejecucin paso a paso de un programa, el desarrollador debe aproximarse cuidadosamente al punto en el cual la falla se manifiesta. Llegado a este punto, se debe recomenzar la ejecucin si es que se desea examinar un estado anterior [Zeller, 2005]. La informacin visual de alguna forma otorga un medio para razonar hacia atrs sin necesidad de realizar esto.
Inmediatez
La actividad de debugging se torna mucho ms sencilla si se cuenta con una agradable interfaz de usuario y si adems las herramientas estn integradas al
Adrin Eidelman
77/148
FIUBA
entorno de desarrollo que se utilice. Esto es lo que busca la propiedad de inmediatez. Estas caractersticas permiten una mejor manipulacin del programa que es debuggeado y por lo tanto una mejor experiencia de debugging. En [Ungar et al., 1997] se explica de manera muy clara y prctica qu es lo que se busca con la propiedad de inmediatez en debugging, haciendo una analoga con elementos de la vida cotidiana: Una buena interfaz de usuario te coloca cara a cara con lo que sea que se est manipulando y experimentando. Por ejemplo, el mecanismo de direccin en un auto deportivo te permite sentir la superficie del camino, de forma que uno pueda distinguir si la ruta se encuentra resbaladiza o no. Una buena herramienta, como puede ser un destornillador de alta calidad, pasa a formar parte de tu mano, de forma que se siente que uno mismo est girando el tornillo. El aparato desaparece y uno se siente conectado directamente con el objeto en cuestin. Un entorno de programacin puede transmitir tambin una experiencia similar, ubicando al desarrollador bien cerca del programa. Cuando eso sucede, el debugging se torna ms sencillo. Es cierto que para poder cumplir con esta propiedad es necesario contar con funcionalidades de debugging que puedan incorporarse al entorno. Brindar una experiencia de inmediatez depender entonces del soporte de otras de las propiedades presentadas.
La situacin de SetPoint y las restantes plataformas AOP

Si se analiza la situacin de las herramientas AOP existentes en el mercado en relacin a las propiedades de debugging descriptas, es posible asegurar que la gran mayora soporta slo un nmero reducido de estas. Como se ha explicado a lo largo del trabajo, la bsqueda de un adecuado soporte al debugging no ha sido objeto de atencin en el mundo de aspectos. Y SetPoint no es excepcin. Es posible observar en la Tabla 7-1 cul es la situacin del framework en su versin 1.037: slo dos de las propiedades intimidad y aislamiento de fallas- son provistas.
37
Denominaremos SetPoint 1.0 a la versin original del framework, resultado del trabajo realizado en [Cyment & Altman, 2004].
FIUBA
Propiedades Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez
Soportado / No Soportado
SetPoint 1.0
Tabla 7-1: Situacin actual de SetPoint en relacin a las propiedades de debugging descriptas
El aislamiento de fallas es soportado inherentemente en aplicaciones Windows que utilizan DLLs. Si ocurre una excepcin en alguna DLL, la informacin de la excepcin as tambin como el nombre del archivo que causa el problema son informadas al usuario. La arquitectura propia de SetPoint, basada en DLLs que implementan independientemente la dimensin base, las dimensiones transversales y las actividades propias AOP, permite entonces identificar el actor responsable al producirse una excepcin. Como se vio en el captulo anterior, las DLLs que implementan los crosscuting concerns siempre y cuando no hayan sido tambin aspectualizadas- y la mecnica propia de SetPoint conservan la informacin de debugging, y por lo tanto es posible debuggear estas funcionalidades a nivel cdigo fuente. De esta forma, SetPoint 1.0 soporta tambin la propiedad de intimidad. La situacin no es mucho ms alentadora en la mayora de las restantes plataformas AOP disponibles en el mercado. Es posible observar esto en la Tabla
7-2, donde se muestra la situacin de algunas herramientas para desarrollos

orientados a aspectos38.
38
La informacin presentada ha sido obtenida de [Eaddy et al., 2005]

79/148
Adrin Eidelman
FIUBA
Propiedades AspectJ
SourceWeave .NET
AspectWerkz
Hyper/J
CLAW
Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez
Soportado / No Soportado / Parcialmente Soportado
Tabla 7-2: Situacin de algunas herramientas populares para AOP en relacin a las propiedades de debugging descriptas
Sin querer realizar una lectura detallada acerca de la situacin de cada herramienta en particular, es interesante detenerse un momento en la de AspectJ [Kiczales et al., 2001]. La herramienta ms popular y utilizada para soluciones AOP en la actualidad slo soporta en su totalidad las propiedades de idempotencia e inmediatez, reflejando claramente la poca atencin que se le ha dado al debugging en la comunidad.
Resumen
Se present en este captulo una propuesta de mejora a la situacin problemtica planteada en el captulo anterior. Esta propuesta se basa en una serie de propiedades las cuales a nuestro entender- debera brindar una solucin ideal de debugging para plataformas de desarrollo AOP. Estas propiedades son: Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin
Adrin Eidelman
80/148
FIUBA
Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez Se realiz adems un anlisis acerca de cmo estas propiedades solucionan o facilitan la deteccin de las fallas caractersticas de desarrollos orientados a aspectos. Finalmente se present la situacin de algunas de las principales herramientas de desarrollo AOP en relacin a las propiedades sugeridas, evidenciando la poca madurez del soporte al debugging en este tipo de desarrollos. La situacin de SetPoint tambin fue presentada, la cual se utilizar como punto de partida para el desarrollo de funcionalidades que signifiquen una evolucin de la herramienta en ese sentido.
Adrin Eidelman
81/148
FIUBA
8. Nuestro grano de arena: diseo e implementacin de la solucin en SetPoint

Hemos presentado una propuesta para mejorar la experiencia de debugging en plataformas de desarrollo AOP. El objetivo ser entonces trasladar de la teora a la prctica los conceptos presentados, implementando algunas de estas propiedades en SetPoint. De esta manera buscamos no slo contribuir en la madurez de la actividad de debugging para desarrollos orientados a aspectos, sino adems aportar un grano de arena en la evolucin de este interesante proyecto. A lo largo de este captulo se profundizar sobre la implementacin realizada en SetPoint, las principales decisiones de diseo que se tomaron y las dificultades y limitaciones que se fueron presentando a lo largo del trabajo, para luego en el prximo captulo- describir el resultado final: de qu manera SetPoint soporta el debugging de aplicaciones AOP.
Definiendo el alcance del trabajo

Las propiedades a implementar
Una de las primeras preguntas que nos hicimos al comienzo del proyecto fue sobre qu propiedades deberamos concentrar nuestros mayores esfuerzos. No todas poseen la misma relevancia, y esto era algo que deba ser tenido en cuenta a la hora de definir el alcance del trabajo, as como la factibilidad de construccin y el esfuerzo que ello requerira. En ese sentido estuvimos de acuerdo desde un principio: debamos hacer foco en aquellas propiedades que nos permitiran debuggear aplicaciones AOP de la misma forma que acostumbramos hacerlo en aplicaciones no aspectualizadas. La prioridad recay entonces sobre las propiedades de idempotencia y desentendimiento. Contar con estas propiedades permite que el debugging de aplicaciones sea similar a cuando lo hacemos en aplicaciones no orientadas a aspectos. En un segundo orden de prioridad ubicamos a aquellas propiedades que tienen injerencia sobre el control y el conocimiento del flujo de ejecucin. Esta
Adrin Eidelman
82/148
FIUBA
caracterstica la cumplen las propiedades de dinamismo y conocimiento del flujo de ejecucin. A pesar de ubicarlas un escaln por debajo de las anteriores, era deseable contar con las mismas en la implementacin final. Consideramos que la introduccin de aspectos y las modificaciones en tiempo de ejecucin constituan las propiedades de menor prioridad para este proyecto, basndonos en dos hechos principales: en primer lugar no atacan directamente ninguna de las fallas caractersticas de AOP; en segundo lugar, la complejidad de su implementacin es elevada en relacin a su relevancia. Teniendo en cuenta lo mencionado, estas propiedades quedaron fuera del alcance del trabajo. Finalmente decidimos que las funcionalidades implementadas deberan dentro de lo posible integrarse al entorno de desarrollo, de forma de cumplir con la propiedad de inmediatez. Creemos que esta propiedad posee una menor relevancia que las restantes que decidimos implementar, pero tambin consideramos que es fundamental para lograr una adecuada experiencia de debugging.
Debugger
Una segunda decisin importante que fue necesario tomar estaba relacionada con el debugger en s mismo. Est claro que cuando hablamos de poder realizar debugging a nivel cdigo fuente, tambin deseamos poder inspeccionar el valor de las variables, incluir breakpoints y ejecutar paso a paso una aplicacin. En definitiva, para brindar un adecuado soporte al debugging es evidente que necesitamos contar con un debugger. Deberemos construir un debugger especfico para la plataforma e incorporar nuevas funcionalidades que soporten las propiedades propuestas? Podemos optar por construir las nuevas funcionalidades sobre un debugger existente? A partir de estos interrogantes, planteamos las siguientes alternativas: Construir un debugger desde cero. Tomar como base el debugger de cdigo abierto para SharpDevelop39, y modificarlo para incorporar las nuevas funcionalidades. Utilizar el debugger de Visual para Studio siendo .NET-, sta y la plataforma las generalmente utilizada desarrollos concentrar
modificaciones sobre SetPoint para adaptarnos a las caractersticas de ste.

39
SharpDevelop es una IDE de cdigo abierto para la plataforma .NET completamente desarrollada en C#, la cual soporta varios tipos de proyecto en mltiples lenguajes de programacin.
FIUBA
La opcin de construir un debugger como se adelant en el captulo 4- fue rpidamente desechada. La ventaja de no estar limitado a las decisiones de diseo de otras implementaciones, como por ejemplo el uso de PDBs en entornos Microsoft, no inclinaba la balanza hacia esta opcin teniendo las desventajas de la complejidad de construccin, el esfuerzo que ello requiere y la necesidad de desarrollar funcionalidades que escapan al problema particular de debugging de aplicaciones AOP. La segunda de las opciones pareca a priori interesante: el debugger de SharpDevelop cuenta entre sus funcionalidades ya implementadas las opciones de ejecucin paso a paso, seteo de breakpoints y examinacin de variables, de manera que estas funcionalidades no requeriran ser desarrolladas. Luego tendramos flexibilidad para desarrollar nuestras propias funcionalidades sobre el cdigo abierto del debugger. De todas maneras utilizar una herramienta que al momento de tomar la decisin sigue siendo de carcter experimental y por lo tanto posee una considerable cantidad de errores conocidos y caractersticas deseadas an no implementadas- implicaba un riesgo alto para nuestro proyecto. Nos inclinamos finalmente por la tercera de las propuestas. Utilizar un debugger de uso masivo y funcionalidades conocidas no presentaba el riesgo que implicaba optar por la opcin anterior. Como punto dbil sabamos que lograr implementar ciertas caractersticas especialmente las propiedades de idempotencia y desentendimiento- estara sesgado al funcionamiento y diseo tcnico propio del debugger de Visual Studio.
SetPoint v1.1: Un primer acercamiento

Habiendo definido las prioridades estbamos en condiciones de comenzar a trabajar sobre una primera versin de nuestra implementacin. A travs de lo que denominamos SetPoint v1.1 realizamos un primer acercamiento a la propuesta de solucin, tratando principalmente de: Validar la factibilidad de soportar las propiedades de idempotencia y desentendimiento utilizando el debugger de Visual Studio. Sentar las bases para la implementacin de las restantes propiedades alcanzadas por el proyecto.
Adrin Eidelman
84/148
FIUBA
Describiremos en esta seccin las experiencias realizadas para cada una de las propiedades alcanzadas en esta primera versin y las lecciones aprendidas en esta etapa.
Idempotencia
Las soluciones ms comunes al problema de soportar debugging a nivel cdigo fuente en cdigo entretejido se resumen a continuacin [Eaddy et al., 2005]: Uso de weaving de cdigo fuente: este modelo de weaving realiza el entretejido a nivel cdigo fuente, preservando la informacin de debugging al compilar el cdigo resultante del weaving. Uso de weaving binario debugger-friendly: como se vio en el captulo anterior, existen herramientas AOP que, a pesar de utilizar un modelo de weaving binario, son capaces de preservar la informacin de debugging. Es el caso de los sistemas AOP basados en Java. Uso de anotaciones: en trabajos relacionados con el debugging de cdigo optimizado se menciona la posibilidad de proveer informacin de debugging mediante anotaciones en el cdigo. No tenemos conocimiento sobre la existencia de sistemas AOP que utilicen este medio para proveer esta tcnica de debugging. Ingeniera reversa: cuando el debugger encuentra cdigo binario del cual no se posee informacin a nivel cdigo fuente, generar a demanda la informacin de debugging correspondiente. Como hemos visto a lo largo de este trabajo, SetPoint utiliza un modelo de weaving binario, por lo que optar por cualquiera de las opciones que no incluya este mecanismo de entretejido tiene como contraparte la necesidad de realizar una reingeniera de la arquitectura del framework. Definitivamente esto era algo que no estaba en nuestros planes. Nuestra intencin fue desde un principio intentar soportar esta propiedad manteniendo intacta las principales decisiones de diseo de la primera versin de la plataforma: la eleccin deba recaer entonces en implementar un weaving binario debugger-friendly. Y en el caso de SetPoint esto es posible de lograr nicamente trasladando al archivo de smbolos las transformaciones realizadas sobre los archivos binarios durantes los pre-procesos de preweaving y semanticacin.
Adrin Eidelman
85/148
FIUBA
La situacin ideal para lograr esto es aquella en la cual la herramienta de instrumentacin automticamente refleja en el PDB original los cambios realizados. Lamentablemente ni PERWAPI [PERWAPI], ni ninguna otra herramienta de instrumentacin de las cuales tengamos conocimiento, ofreca esta funcionalidad al momento de encarar el proyecto. Nos propusimos entonces analizar la factibilidad de desarrollar esta funcionalidad nosotros mismos, de forma de actualizar los preprocesos de SetPoint para que los cambios sean reflejados en el archivo de smbolos correspondiente.
APIs para manejo de smbolos

El carcter propietario del formato PDB obliga de alguna forma a que la solucin al problema deba provenir del lado de Microsoft. Tenamos conocimiento de la existencia de una API pblica para la lectura de archivos de smbolos [MSDN-DIA], pero no as de una para la escritura y emisin de los mismos. Contactamos al equipo del CLR en Microsoft para entender la situacin de las APIs existentes para el manejo de smbolos, la cual se resume en la Figura 8-1 [Stall, 2005b].
Bsicamente existe una API de bajo nivel que permite la lectura y escritura de smbolos, la cual es utilizada por el debugger nativo de Visual Studio. Esta API sin embargo no es de carcter pblico y por lo tanto no contbamos con la posibilidad de utilizarla para nuestro fin. Por encima de este componente existen una serie de APIs de mayor nivel, las cuales s son pblicas y son utilizadas para diferentes fines. Inmediatamente por encima de la API de bajo nivel existen una serie de interfaces denominadas DIA [MSDN-DIA] y una API de nombre DbgHelp [MSDNDBGHELP] que permiten nicamente la lectura de archivos PDB (Figura 8-1).
El componente CorSym es el primero de la figura que permite la escritura de archivos de smbolos. CorSym es una API de cdigo no manejado que es utilizada por varias de las herramientas clsicas .NET para la emisin de archivos PDB, como por ejemplo el CLR, los compiladores .NET o ILasm/ILdasm [STALL, 2005c].
Adrin Eidelman
86/148
FIUBA
Mdbg Wrappers(R/W) ISymWrapper (R/W) DbgHelp (R) DIA API (R) Low-level API (no pblica (R/W) ) CorSym (R/W)
Archivo PDB
Figura 8-1: Mapa de APIs para manejo de smbolos Finalmente existen wrappers a CorSym que son utilizados con el mismo fin que ste, pero han sido desarrollados con cdigo manejado. Es el caso de ISymWrapper, interface implementada en Managed C++, y los wrappers de Mdbg, implementados en C# [MSDN-SYMBOL]. En conclusin, dada la existencia de APIs que soportan la escritura de PDBs, la situacin tericamente nos permitira implementar la funcionalidad para reflejar los cambios necesarios en el archivo de smbolos y por lo tanto soportar la propiedad de idempotencia, pero
No todo es lo que parece

Lamentablemente no todo fue tan feliz al pasar de la teora a la prctica. Durante varias semanas intentamos sin xito utilizar los componentes mencionados para la emisin de los smbolos correctos. Nuestro mximo logro fue generar un archivo PDB que no inclua toda la informacin de debugging necesaria y por lo tanto careca de utilidad. A modo de resumen se listan a continuacin las principales limitaciones que encontramos para lograr nuestro objetivo:
Adrin Eidelman
87/148
FIUBA
Los wrappers de Mdbg a las funcionalidades de escritura de PDBs no funcionan correctamente o en algunos casos ni siquiera han sido implementadas.
Sucede lo mismo con ISymWrapper. La documentacin de las APIs que soportan la escritura de archivos de smbolos no existe o bien es escasa y de difcil comprensin. No existen o no tenemos conocimiento de ejemplos pblicos acerca de cmo utilizar CorSym para emitir archivos PDB.
Teniendo en cuenta estos obstculos decidimos continuar con la implementacin de las restantes propiedades y en una segunda iteracin del proyecto intentar resolver el problema del debugging a nivel cdigo fuente en SetPoint.
Desentendimiento
La implementacin del desentendimiento afortunadamente present menos
obstculos que la de idempotencia. Para lograr soportar esta propiedad en SetPoint encontramos dos soluciones posibles, las cuales tienen muchos puntos en comn y difieren ligeramente en cuanto a su funcionalidad. Ambas soluciones hacen uso de anotaciones sobre el cdigo para lograr el funcionamiento deseado. La idea bsicamente consiste en incluir marcas sobre las porciones de cdigo que se desean ocultar al usuario final durante el debugging, y lgicamente que stas sean luego interpretadas por el debugger de forma de lograr el efecto deseado. Teniendo en cuenta la decisin de utilizar el debugger de Visual Studio, se deduce que esta interpretacin de las anotaciones es una funcionalidad existente en este debugger y no deba ser desarrollada especialmente. La implementacin de esta forma slo consisti en marcar el cdigo propio de SetPoint como por ejemplo el cdigo de weaving- para que sea salteado al realizar el debugging. Las dos soluciones posibles las constituyen dos tipos de anotaciones diferentes: la directiva #line hidden y el atributo DebuggerStepThroughAttribute. Se explican brevemente a continuacin cmo funcionan estas marcas para comprender sus diferencias y similitudes [Stall, 2005a; 2006]:
Adrin Eidelman
88/148
FIUBA
Directiva #line hidden

Hemos visto que la informacin de debugging en un archivo PDB mapea cada regin de cdigo IL con las lneas de cdigo fuente de la aplicacin. Los debuggers y compiladores de Microsoft tienen un acuerdo en comn por el cual, si una regin de cdigo IL se mapea con la secuencia 0xFeeFee, entonces el debugger lo saltea durante la ejecucin paso a paso. En C# se puede utilizar la directiva #line hidden para indicarle al compilador que mapee la lneas marcadas a la secuencia 0xFeeFee, en lugar de al nmero de lnea de cdigo fuente que corresponde [MSDN-LINE]. De esta forma es posible ocultar ciertas porciones de cdigo al usuario final y lograr soportar la propiedad de desentendimiento. El siguiente cdigo muestra un ejemplo de uso de la directiva: int x, y, z; string strMensaje = ; // <-- parado en este punto presionar // #line hidden x=2; // esta lnea ser salteada por el debugger y=3; // esta lnea ser salteada por el debugger #line default z = x + y; // <-- la ejecucin paso a paso contina ac strMensaje = La suma de + x.ToString() + y + y.ToString() + es + z.ToString(); Console.WriteLine(strMensaje); F10 (Step Over)
Atributo DebuggerStepThroughAttribute
El uso del atributo DebuggerStepThroughAttribute es similar al de la directiva #line hidden pero presenta tres diferencias principales: 1. Permite ocultar funciones o clases enteras, en lugar de lneas o conjuntos de lneas individuales. 2. No provoca cambios en el PDB, sino que el atributo es almacenado directamente en el assembly y luego interpretado por el debugger durante la ejecucin.
Adrin Eidelman
89/148
FIUBA
3. Permite la inclusin de breakpoints en el cdigo alcanzado por el atributo y de esta forma debuggear el cdigo que en un principio fue marcado como oculto.
Debilidad de la implementacin
La implementacin de esta solucin, como se explic anteriormente, fue
sumamente sencilla, pero present una desventaja que no exista en la versin anterior de SetPoint: la incorporacin de estas anotaciones invalida la propiedad de intimidad, salvo obviamente que en el caso de desear ser ntimos durante el debugging eliminemos cada uno de los atributos o directivas incorporadas. Esto resulta sumamente incmodo. Teniendo en cuenta esta situacin, optamos por el uso del atributo
DebuggerStepThroughAttribute por una sencilla razn: la posibilidad de incorporar breakpoints en el cdigo alcanzado por la marca nos otorga la capacidad de debuggear el cdigo propio del framework, simplemente incorporando los puntos de detencin en las sentencias deseadas. El siguiente fragmento de cdigo muestra la clase Weaver anotada con este atributo. De la misma forma todas las clases propias de SetPoint fueron anotadas para soportar el desentendimiento. namespace setPoint.weaving { [System.Diagnostics.DebuggerStepThroughAttribute] public class Weaver { } } A pesar de verse limitada la propiedad de intimidad, el desentendimiento pudo ser implementado con xito en esta primera versin.
Dinamismo
Decidimos implementar el concepto de dinamismo en SetPoint a travs de los dos ejemplos mencionados en el captulo anterior: la habilitacin y deshabilitacin de aspectos durante la ejecucin y el seteo dinmico del orden de ejecucin de
Adrin Eidelman
90/148
FIUBA
aspectos. Ambas funcionalidades requirieron realizar modificaciones en el weaver del framework. Describimos a continuacin las modificaciones introducidas.
Habilitacin y deshabilitacin de aspectos

Incorporar esta funcionalidad en SetPoint implicaba bsicamente realizar dos tareas: brindarle al usuario un medio para definir el estado de habilitacin de un aspecto en runtime y desarrollar la lgica para controlar este estado en el momento en que se realiza el weaving. Para la primera de las tareas decidimos incluir un archivo con formato XML donde se listen todos los aspectos definidos y en el cual se pueda setear el estado de activacin de cada uno de ellos. Luego en tiempo de ejecucin el weaver monitorear cambios sobre este archivo y en caso de producirse modificaciones stas sern reflejadas en la lista de aspectos propia que maneja SetPoint en memoria. El siguiente es un ejemplo del archivo XML, en el cual existe un nodo por aspecto definido y se utiliza el atributo isEnabled para definir el estado de activacin del mismo. <AspectList> <Aspect isEnabled="True">LoggingAspect</Aspect> <Aspect isEnabled="False">CachingAspect</Aspect> <Aspect isEnabled="True">EncryptionAspect</Aspect> </AspectList> El archivo es generado automticamente en el momento en que el SetPoint Engine procesa la configuracin de aspectos, advices y pointcuts. Ahora bien, si concentramos la habilitacin y deshabilitacin de aspectos en el archivo XML habr un lapso de tiempo, entre que se inicia la aplicacin y modificamos el estado de los aspectos en el archivo, en el cual uno o ms aspectos podrn ser ejecutados. Es deseable tener la posibilidad de desactivar la ejecucin de aspectos desde el minuto cero de ejecucin del programa, funcionalidad no soportada en la primera versin de la plataforma. Como vimos en el captulo 3, SetPoint provee el lenguaje LENDL para la definicin de aspectos y restantes elementos distintivos de AOP. Decidimos entonces incorporar en LENDL la posibilidad de definir un aspecto como habilitado o deshabilitado previo a la ejecucin de la aplicacin, y de esta forma evitar el problema antes descrito. El siguiente cdigo LENDL en el cual se define por
Adrin Eidelman
91/148
FIUBA
completo el aspecto de logging- muestra cmo es posible indicar el estado de activacin del aspecto a partir de las modificaciones realizadas: /************************************/ /* Logging Aspect pointcut ViewToModelMessages{ sender is [architecture#view]; receiver is [architecture#model]; } aspect LoggingAspect disabled{ //<-- estado de activacin event startLogging; event endLogging; event logMovement; } advice LogEvents : LoggingAspect{ trigger startLogging before {ViewToModelMessages}; trigger endLogging after {ViewToModelMessages}; } En lo que respecta a controlar el estado de activacin de los aspectos en tiempo de weaving quizs lo nico a destacar tiene que ver con que la lgica de entretejido en SetPoint no se basa en la ejecucin de aspectos sino que posee una granularidad mayor, basada en la ejecucin de triggers. Consideramos que implementar la activacin/desactivacin a nivel aspecto resultaba ms claro para el usuario que hacerlo a nivel advice o trigger. Mantuvimos por lo tanto esa poltica, trasladando el estado de activacin desde el aspecto al trigger dentro de la lgica del weaver. */ /************************************/
Seteo dinmico del orden de ejecucin de aspectos

A diferencia de otras plataformas AOP como por ejemplo AspectJ- SetPoint no utiliza un mecanismo clsico de priorizacin de aspectos, en el cual cada aspecto es asignado una prioridad y, en el caso en que deban aplicarse dos o ms aspectos en
Adrin Eidelman
92/148
FIUBA
un mismo punto de ejecucin o matchpoint40 (Figura 8-2), estos son ejecutados en un orden de prioridad descendente.
Figura 8-2: El joinpoint en ejecucin provoca la aparicin de un matchpoint SetPoint introduce un objeto titulado policy broker, el cual se encarga de determinar qu poltica u orden de ejecucin- corresponde aplicar al conjunto de aspectos que conforman un matchpoint. Para cada poltica diferente que deseemos que exista deberemos construir un objeto policy broker particular, el cual incluya la lgica para determinar el orden de ejecucin. En la implementacin 1.0 de SetPoint slo existe el policy broker denominado ChainPolicy, el cual ejecuta los aspectos en secuencia de acuerdo al orden en el cual estos fueron definidos. El seteo dinmico del orden de ejecucin en SetPoint consistir entonces en poder definir manualmente, en tiempo de ejecucin, el policy broker que debe utilizar el weaver. Incorporamos para esto un archivo de configuracin que eventualmente se podr utilizar para otras configuraciones- el cual permite fijar una poltica de weaving determinada o bien especificar que la decisin quede a cargo del weaver, tal como lo hace en la primera versin del framework.
40
Trmino introducido por SetPoint para referirse a la situacin en la cual un joinpoint pertenece a ms de un pointcut semntico.
FIUBA
El siguiente es un ejemplo de configuracin, en donde se define como poltica de weaving fija al RandomWeavingPolicy, el cual ejecuta los aspectos en un orden aleatorio y que creamos especialmente para poder testear esta funcionalidad. <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="WeavingPolicy" value="RandomWeavingPolicy" /> <add key="AspectList" value="AspectList.xml" /> <add key="ExecutionFlowFile" value="ExecutionFlow.xml" /> </appSettings> </configuration> En el caso en que el valor de la clave WeavingPolicy se deje vaco, esta decisin ser tomada automticamente por el weaver en tiempo de ejecucin.
Esquema de dinamismo en SetPoint

La Figura 8-3 ilustra la manera en que los conceptos antes explicados se encuadran dentro del funcionamiento general del weaving en SetPoint.
FileWatcher
1 10
SetPoint.dl l.config
App.exe
7 6
SetPoint Engine (SetPoint.dll)
Configuration
AspectList. xml
3 2
LENDLConfiguration (SetPoint.config.dll)
Figura 8-3: Esquema de dinamismo en SetPoint Una aplicacin App.exe inicia su ejecucin, provocando la instanciacin del weaver en la primera ejecucin de un joinpoint (1). Al instanciarse, el weaver incorpora los datos de advices y pointcuts, provenientes de la configuracin realizada con LENDL (SetPoint.config.dll) (2). Este proceso genera a su vez el archivo XML
Adrin Eidelman
94/148
FIUBA
(AspectList.xml) que se utilizar para habilitar y deshabilitar aspectos (3) y traslada al mapa de advices el estado de activacin segn la definicin que se haya realizado (4). Se incorpora adems en la configuracin el policy broker a utilizar, tomado del archivo SetPoint.dll.config (5). Se crea internamente un objeto FileWatcher, el cual monitorea la existencia de cambios en alguno de los archivos XML. Finalizado el proceso de inicializacin del weaver, cada ejecucin de un joinpoint en App.exe derivar el control de ejecucin al weaver (6), el cual determinar si corresponde o no la ejecucin de un aspecto41, tomando en consideracin el estado de activacin de ste y utilizando en este paso el policy broker definido. Una vez realizado esto, el control de ejecucin vuelve a la aplicacin (7). En caso en que el FileWatcher detecte cambios en SetPoint.dll.config (8) o en AspectList.xml (9), la configuracin ser actualizada con los cambios realizados (10), de forma que estos sean tenidos en cuenta durante las tareas de weaving. El proceso se repite de la misma forma salvo la instanciacin del weaverhasta que finalice la ejecucin de la aplicacin.

Cuando en el captulo 5 nombramos algunos de los trabajos relacionados con el aseguramiento de la calidad en desarrollos AOP, destacamos algunos acercamientos al uso de grafos de dependencia para describir relaciones entre clases y aspectos. La Figura 8-4, tomada de [Ishio et al., 2004], muestra un ejemplo de grafo de dependencia para la ejecucin de un programa que utiliza tcnicas orientadas a aspectos.
Figura 8-4: Ejemplo de grafo de dependencia de una aplicacin AOP
41
En rigor de verdad, SetPoint determina la ejecucin de advices.

95/148
Adrin Eidelman
FIUBA
Tambin en el captulo anterior se ilustraron ejemplos mediante el uso de grafos que reflejan el flujo de ejecucin de un programa. Este tipo de grafos son lo que imaginamos como funcionalidad que soporte la propiedad conocimiento del flujo de ejecucin. Teniendo en cuenta que reflejar el flujo completo de ejecucin puede resultar en un grafo de dimensiones considerables y por lo tanto de difcil comprensin, decidimos concentrarnos exclusivamente en las relaciones entre clases y aspectos. Nuestra idea es contar con un registro de qu aspectos fueron ejecutados, cul fue el pointcut que dio lugar a su ejecucin y el punto de ejecucin que inici el weaving como principales datos- para que el usuario pueda realizar un anlisis post-mortem de una ejecucin y comprender en mayor detalle el flujo de control de la misma. Esta informacin debera ser presentada en una forma grfica, similar al de la Figura 8-4, para cada una de las invocaciones a aspectos producida.
Decidimos dejar lo relacionado con la presentacin grfica para la siguiente iteracin y focalizarnos en incluir la lgica necesaria para que el weaver registre esta informacin, dado que este componente es el que maneja la interaccin entre ambos mundos. La implementacin dio como resultado una nueva versin del weaver, capaz de generar un archivo XML con la informacin antes mencionada, el cual es creado a medida que se ejecuta la aplicacin. El siguiente es un extracto de informacin obtenida de un archivo XML de ejecucin, el cual ejemplifica los datos que se obtienen por cada invocacin a un aspecto42: <LogEntries> <AspectCall timeStamp="26/02/2006 05:17:32 p.m."> <PointCut> <name>ViewToModelMessages</name> <Aspect name="LoggingAspect" isEnabled="True"> <Trigger precedence="before">startLogging</Trigger> <Trigger precedence="after">endLogging</Trigger> </Aspect> </PointCut> <EntryPoint> <sender>dotSenku.View.frmPlayRoom</sender> <receiver>dotSenku.Model.Builders.SenkuBuilder</receiver>
42
El ejemplo se realiz a partir de la ejecucin de la aplicacin DotSenku, tomada de [Cyment & Altman, 2004]
FIUBA
<message>dotSenku.Model.Builders.SenkuBuilder..update</messag e> </EntryPoint> <ExecutionOrder> <Event>startLogging</Event> <Event>dotSenku.Model.Builders.SenkuBuilder...update</Event> <Event>endLogging</Event> </ExecutionOrder> </AspectCall> <AspectCall timeStamp="26/02/2006 05:17:32 p.m."> <PointCut> <LogEntries> Con esta informacin estaramos en condiciones de realizar luego una
representacin grfica de la ejecucin de los aspectos. En definitiva, al momento de implementar esta primera versin, el log textual soportaba en forma parcial la propiedad conocimiento del flujo de ejecucin.
Sntesis de la primera experiencia

La implementacin de SetPoint v1.1 nos permiti dar nuestros primeros pasos hacia un adecuado soporte al debugging en la plataforma. Resumimos a continuacin los elementos salientes de este primer acercamiento y reflejamos la situacin final de esta versin en relacin a la versin 1.0: No se logr implementar con xito la propiedad de idempotencia, motivado principalmente por la inexistencia de herramientas adecuadas para la actualizacin de archivos de smbolos. Teniendo en cuenta esta situacin, soportar el debugging a nivel cdigo fuente requerira modificar el modelo de weaving de la plataforma, lo cual quedaba excluido del alcance del trabajo. Logramos implementar la propiedad de desentendimiento del debugging mediante el uso de anotaciones en el cdigo. Esto a su vez impact de forma negativa en el soporte a la propiedad de intimidad. A pesar de esto, consideramos que el cambio fue positivo teniendo en cuenta la mayor importancia a nuestro criterio- de la primera de las propiedades. Soportamos por completo la propiedad de dinamismo y sentamos las bases para el soporte completo de la propiedad de conocimiento del flujo de ejecucin. En ambos casos se obvi la integracin con la IDE de Visual
Adrin Eidelman
97/148
FIUBA
Studio, hecho por el cual la situacin de la propiedad de inmediatez no se vio alterada. La situacin de SetPoint v1.1 se resume en el siguiente cuadro: Propiedades Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez
Soportado /
SetPoint 1.0
SetPoint 1.1
No Soportado /
Parcialmente Soportado
SetPoint v2.0: Propuesta final para este trabajo

Hemos visto que en nuestro primer acercamiento a un adecuado soporte al debugging en SetPoint, la implementacin de las propiedades no siempre fue exitosa o bien nos hemos limitado a sentar las bases para una segunda iteracin de desarrollo. Nos dedicaremos en esta seccin a presentar nuestra propuesta final al menos en el marco de esta tesis- destacando los avances realizados en este segundo acercamiento.
Idempotencia
Destacamos al comienzo del captulo que la propiedad de idempotencia posee desde nuestro punto de vista una relevancia mayor a la de las restantes propiedades. Esto ameritaba realizar un nuevo intento por proveer debugging a nivel cdigo fuente en la plataforma. Mencionamos tambin, al presentar el proyecto SetPoint, que ste ha recibido un premio otorgado por Microsoft Research con el fin de fomentar la evolucin de la herramienta. Este no es un dato menor: el proyecto propuesto relacionado con el uso de una herramienta conocida con el nombre de Phoenix- tiene un impacto directo sobre la capacidad de soportar esta tcnica de depuracin.
Adrin Eidelman
98/148
FIUBA
Phoenix: la resurreccin del debugging de cdigo fuente

Phoenix es el nombre en cdigo para un framework de Microsoft pensado principalmente para la construccin de compiladores, y otras herramientas de anlisis, optimizacin y testing de aplicaciones. Consta bsicamente de un sistema extensible que puede ser adaptado para leer y escribir archivos binarios y assemblies MSIL. Estos archivos son tomados como input para luego ser analizados y/o manipulados a travs de aplicaciones que utilizan la API de Phoenix43. La propuesta que le vali el premio a SetPoint consista en migrar a Phoenix las tareas de instrumentacin de cdigo llevadas a cabo en el pre-proceso de preweaving. Sin lugar a dudas la migracin a Phoenix constitua de un gran inters para nuestro proyecto teniendo en cuenta que, como ya hemos mencionado, el problema de la prdida de informacin de debugging est directamente relacionado con la instrumentacin de assemblies y la incapacidad de las herramientas existentes para regenerar esta informacin. Para nuestra satisfaccin, y de acuerdo a lo expresado por integrantes del equipo de desarrollo del framework en Microsoft, Phoenix posee la capacidad de emitir un archivo de smbolos que refleje las modificaciones realizadas sobre un assembly instrumentado.
PDB
PDB
Instrumentacin con Phoenix

Assembly Original Assembly Instrumentado
(a)
PDB
Instrumentacin con Phoenix

Assembly Original
Assembly Instrumentado
(b)
Figura 8-5: Emisin de PDB actualizado mediante Phoenix
43
Phoenix se explica en mayor detalle en el Anexo A de este trabajo.

99/148
Adrin Eidelman
FIUBA
Como se ilustra en la Figura 8-5, Phoenix se vale de la informacin de debugging del assembly original para poder regenerar un nuevo archivo de smbolos PDB que contenga las modificaciones realizadas al assembly instrumentado (a). En caso de no existir el PDB, el proceso de instrumentacin no es capaz de emitir un nuevo archivo con la informacin de debugging actualizada (b). Tuvimos tambin la inmensa suerte que el proyecto de migracin fue llevado a cabo en forma paralela al desarrollo de esta tesis44, por lo que pudimos contar con la funcionalidad de preweaving implementada bajo Phoenix a tiempo para utilizarla en nuestro trabajo. Efectivamente la nueva versin del pre-proceso genera un PDB vlido que permitira realizar debugging a nivel cdigo fuente en una aplicacin aspectualizada. Sin embargo se nos presentaban an dos importantes inconvenientes por resolver: Phoenix, y por lo tanto la nueva versin del preweaver, corre
exclusivamente bajo Visual Studio 2005, mientras que SetPoint v1.1 lo hace bajo la versin 2003. Para poder incorporar la nueva funcionalidad deberamos por lo tanto migrar obligatoriamente SetPoint a Visual Studio 2005. No slo el preweaving implica cambios en el assembly. Hemos mencionado que el proceso de semanticacin tambin aporta al problema de la prdida de informacin de debugging y por lo tanto habra que alinearlo a la nueva funcionalidad.
Ajustando las piezas restantes

La migracin completa de SetPoint a Visual Studio 2005 requiri nicamente actualizar la versin de PERWAPI [PERWAPI] que utilizaba el pre-proceso de semanticacin a la versin para Visual Studio 2005 recordemos que esta herramienta de instrumentacin de cdigo se utilizaba durante los procesos de semanticacin y preweaving, este ltimo ya migrado a Phoenix- y la actualizacin automtica del cdigo completo de SetPoint que corra bajo Visual Studio 2003. Estas dos modificaciones no presentaron inconvenientes, por lo cual el primero de los problemas fue solucionado con facilidad.
44
Los encargados de realizar esta tarea fueron Marcelo Rodrguez y Juan Vaccari, alumnos de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires. Nuestra participacin en el proyecto consisti del testeo de las funcionalidades y el reporte de incidencias.
FIUBA
Restaba an resolver el problema de la semanticacin. Como se explic en el captulo 3, este proceso se encarga de obtener una representacin RDF del cdigo y almacenarla como recurso embebido en el assembly aspectualizado. Por ms que el preweaving utilizara Phoenix, esta modificacin al assembly invalida el archivo PDB, producindose una situacin similar a la descripta en la Figura 8-5-b. Se nos presentaban para esto dos opciones: migrar tambin el proceso de semanticacin a Phoenix o actualizarlo para evitar modificaciones al assembly que se procesa, manteniendo el uso de la herramienta de instrumentacin actual. Optamos por la segunda de las posibilidades. Resultaba mucho ms sencillo resignar el embebido del recurso y generar el RDF como un archivo independiente antes que realizar la migracin del pre-proceso a Phoenix, la cual implicaba impacto y esfuerzo mucho mayores. Luego lgicamente deberamos modificar el weaver para obtener el RDF desde el archivo y no desde dentro mismo del assembly en cuestin.
PDB
PDB
Semanticacin
RDF Programa Base
Carga
PDB
Figura 8-6: Situacin de la informacin de debugging luego de implementados los cambios Implementadas estas modificaciones habamos logrado finalmente preservar la informacin de debugging y por lo tanto brindar la posibilidad de realizar debugging de cdigo fuente en aplicaciones aspectualizadas con SetPoint (Figura 8-6).
Adrin Eidelman
101/148
Compilacin
Preweaving c/Phoenix
Assembly Programa Base c/ weaving
FIUBA
Salvo el caso de Wicca [Eaddy et al., 2005], no tenemos conocimiento de alguna otra plataforma AOP para Windows que realice weaving invasivo binario y que pueda soportar la propiedad de idempotencia.
Limitaciones y errores conocidos

Al momento de realizar este trabajo, Phoenix se encuentra an en etapas de desarrollo y por lo tanto presenta errores conocidos, no conocidos y limitaciones, los cuales se trasladan a la capacidad de realizar debugging a nivel cdigo fuente en SetPoint. Tenemos conocimiento de dos problemas principales, los cuales han sido reportados al equipo de Phoenix y esperamos se solucionen en prximos releases de la herramienta: Preweaving en aplicaciones con interfaz grfica: el proceso de preweaving no se completa correctamente cuando la aplicacin procesada utiliza forms visuales. Esto limita el uso de SetPoint v2.0 a aplicaciones que no presentan interfaz grfica. Mapeo incorrecto entre cdigo fuente y cdigo IL: el archivo PDB resultante de la instrumentacin con Phoenix no refleja correctamente el mapeo entre los offsets del cdigo IL y las lneas de cdigo fuente cuando se introducen nuevas lneas de cdigo al assembly. Esto provoca que la secuencia de ejecucin al realizar una ejecucin paso a paso de la aplicacin no sea la correcta.
Desentendimiento e Intimidad
La migracin de SetPoint a Visual Studio 2005 nos dio la posibilidad de disponer de las nuevas funcionalidades que ofrece la plataforma. Dentro de ellas nos result sumamente til la denominada Debugging Just-My-Code (JMC). JMC se basa en el uso de atributos para ocultar el cdigo que no desea ser debuggeado, exactamente de la misma forma que las funcionalidades mencionadas en la implementacin del desentendimiento en la versin 1.1. Una de las diferencias la de mayor relevancia para nuestro trabajo- es que JMC puede ser activado o desactivo desde la IDE de Visual Studio, y de esta forma establecer si el debugger
Adrin Eidelman
102/148
FIUBA
debe o no ignorar las anotaciones introducidas en el cdigo [Stall, 2004] (Figura
8-7). Con esta incorporacin el usuario tiene la capacidad de elegir en forma

dinmica si desea ser ntimo o desentendido de las actividades AOP.
Figura 8-7: Activacin/Desactivacin de la funcionalidad Just-My-Code JMC es soportado a travs del uso del atributo DebuggerNonUserCode diferente al utilizado en la versin 1.1- lo cual nos oblig a modificar las marcas introducidas en la primera implementacin del desentendimiento. La incorporacin del JMC nos permiti por lo tanto soportar tanto la propiedad de intimidad como la de desentendimiento de forma completa en SetPoint v2.0.

Nuestro primer acercamiento a la propiedad de conocimiento del flujo de ejecucin se limit a generar en formato de texto la informacin que nos interesaba presentar. Como mencionamos en la seccin anterior, deseamos poder presentar esta informacin de forma grfica y ayudar al desarrollador con la tarea cognitiva de relacionar la descripcin esttica dada por el cdigo fuente con la dinmica del comportamiento del programa. No siempre es posible ni sencillo deducir desde un punto de vista del cdigo fuente si el flujo de ejecucin de un programa ha sido el correcto, especialmente si ste incluye la ejecucin de aspectos. Tengamos en
Adrin Eidelman
103/148
FIUBA
cuenta adems que, a pesar que hoy en da SetPoint no lo soporta, muchas plataformas AOP brindan la posibilidad de aplicar aspectos a partir de condiciones dadas por el contexto de la ejecucin. El uso de informacin grfica puede significar por ende un excelente complemento para comprender el flujo de control. Decidimos brindar la posibilidad de diferente : Aspectos nicamente: muestra los aspectos que corresponde aplicar en el joinpoint perteneciente al o a los pointcuts definidos. Esta informacin facilita la deteccin fallas de tipo F1. Aspectos detallados: muestra la misma informacin que el punto anterior con el agregado de los triggers que conforman los aspectos a aplicar. Orden de ejecucin: muestra el orden en el cual fueron ejecutados los triggers facilitando la deteccin de fallas de los tipos F2 y F6. La Figura 8-8 muestra un posible grfico del primer nivel de detalle para el ejemplo del Estudio Jurdico presentado en el captulo 2 adicionando un aspecto de logging para el caso en que el mensaje sea enviado por un abogado-.
45
visualizar la informacin en tres niveles de detalle
Figura 8-8: Ejemplo de grfico que muestra nicamente la relacin del joinpoint con los aspectos La llamada al mtodo enviarMensaje de la clase Abogado pertenece a los pointcuts MensajesSensibles y MensajesDeAbogados, y por lo tanto provoca la ejecucin de los aspectos de encriptacin y logging46.
45
La funcionalidad de graficacin fue desarrollada utilizando la herramienta de cdigo abierto Netron Project [NETRON]. 46 Siempre y cuando estos aspectos no se hayan deshabilitado tal como se describi en la propiedad de dinamismo.
FIUBA
La Figura 8-9 y la Figura 8-10 presentan, para el mismo ejemplo, los restantes niveles de detalle implementados: en el primer caso es posible visualizar qu triggers conforman los aspectos ejecutados, mientras que en el segundo se observa adems el orden en el cual estos son ejecutados.
Figura 8-9: Ejemplo de grfico que muestra los triggers que conforman los aspectos
Figura 8-10: Ejemplo de grfico que muestra el orden de ejecucin de triggers
Inmediatez
Adrin Eidelman
105/148
FIUBA
Lograr una experiencia de inmediatez en SetPoint implicaba desde nuestro punto de vista- integrar las funcionalidades hasta ahora mencionadas a la IDE de desarrollo. Esto permitira no slo brindar un ms adecuado soporte al debugging sino que tambin otorga al desarrollador la sensacin de contar con una herramienta de desarrollo ms robusta. Visual Studio .NET brinda la posibilidad de extender y automatizar su interfaz de desarrollo construyendo add-ins para tal fin47. A travs de estos incorporamos a la IDE las funcionalidades de dinamismo y conocimiento del flujo de ejecucin, posibilitando al desarrollador hacer uso de las mismas mediante ventanas integradas o tool windows, de la misma forma que acostumbramos a hacerlo con las tpicas ventanas que forman parte de Visual Studio, como por ejemplo las ventanas Watch e Immediate. La Figura 8-11 y la Figura 8-12 muestran las dos solapas del add-in para el manejo de las funcionalidades de dinamismo: habilitacin y deshabilitacin de aspectos y seteo de la poltica de weaving respectivamente.
Figura 8-11: Habilitacin/deshabilitacin de aspectos integrada a la IDE
47
Un add-in es una DLL compilada que corre dentro mismo de Visual Studio y que en general se utiliza para incorporar funcionalidades visuales ej: tool windows, ventanas de propiedades, etc.- como si fuesen parte de la IDE.
FIUBA
Figura 8-12: Seteo de poltica de weaving integrado a la IDE El add-in para la visualizacin de la ejecucin de aspectos presenta una lista mediante la cual es posible acceder a los grficos presentados en la seccin anterior. Esta lista puede ser agrupada por joinpoint (Figura 8-13) o por aspecto ejecutado (Figura 8-14), a partir de la cual el usuario selecciona el tem que se desea visualizar (Figura 8-15).
Figura 8-13: Lista de ejecucin de aspectos agrupada por joinpoint Con la incorporacin de estos add-ins, las funcionalidades de debugging descriptas a lo largo de todo este captulo se encuentran integradas a la IDE de desarrollo de Visual Studio. En el caso de utilizar algn otro entorno de desarrollo o algn otro
Adrin Eidelman
107/148
FIUBA
debugger como puede ser el Microsoft CLR Debugger- estas funcionalidades lgicamente no se encontrarn presentes.
Figura 8-14: Lista de ejecucin de aspectos agrupada por aspecto
Figura 8-15: Visualizacin de la ejecucin de aspectos desde add-in
Adrin Eidelman
108/148
FIUBA
Sntesis de la segunda experiencia

La segunda iteracin de desarrollo nos permiti hacer hincapi en las debilidades de la primera implementacin y principalmente realizar un segundo intento hacia el soporte de la propiedad de idempotencia. Resumimos a continuacin los elementos salientes de este segundo acercamiento y reflejamos la situacin de nuestra propuesta final en relacin a la versin 1.0 de SetPoint:
La migracin del proceso de preweaving a Phoenix nos dio la posibilidad de alcanzar dos hitos importantes en la evolucin de SetPoint: o o Migrar la plataforma completa a Visual Studio 2005. Actualizar los componentes restantes de la plataforma para soportar la propiedad de idempotencia. De esta manera a pesar de las limitaciones an existentes- logramos alcanzar nuestro principal objetivo del trabajo: brindar la posibilidad de realizar debugging de cdigo fuente en aplicaciones que utilizan SetPoint.
Logramos soportar por completo la propiedad de intimidad, la cual se haba visto limitada por la implementacin del desentendimiento en la versin 1.1.
Incorporamos la capacidad de visualizacin grfica sobre la base textual alcanzada en el primer acercamiento. De esta forma soportamos por completo nuestra visin sobre la propiedad de conocimiento del flujo de ejecucin.
Integramos las funcionalidades desarrolladas a la IDE de Visual Studio, mejorando de esta manera la situacin de la propiedad de inmediatez. De todos modos consideramos que SetPoint an carece de ciertas facilidades en ese sentido, especialmente en lo que respecta a la ejecucin de los procesos de preweaving y semanticacin hoy realizados va lnea de comandos y no integrados a la IDE-. De esta forma la propiedad se encuentra an parcialmente soportada.
Adrin Eidelman
109/148
FIUBA
La situacin de SetPoint v2.0 se resume en el siguiente cuadro: Propiedades Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez
Soportado /
SetPoint 1.0
SetPoint 2.0
No Soportado /
Resumen
Los esfuerzos en la implementacin de las propiedades de debugging en SetPoint permitieron mejorar significativamente la situacin de la herramienta en relacin a su versin anterior. Se describieron en este captulo las mejoras introducidas a la herramienta, las cuales permitieron implementar el soporte a la mayora de las propiedades propuestas en el captulo 7. Se explicaron adems las principales decisiones de diseo tomadas durante esta implementacin la cual fue dividida en dos acercamientos que denominamos SetPoint v1.1 y SetPoint v2.0- y los obstculos que se presentaron a lo largo del desarrollo. Finalmente reflejamos mediante una tabla comparativa las diferencias entre la versin original de SetPoint y la versin producto de este trabajo, en donde es posible observar la gran diferencia en lo que respecta al soporte a la actividad de debugging.
Adrin Eidelman
110/148
FIUBA
9. Unificando conceptos: un ejemplo de aplicacin

La intencin de este captulo es presentar, mediante el ejemplo sencillo de una aplicacin AOP, de qu forma es posible realizar la actividad de debugging haciendo uso de los avances alcanzados en este trabajo. El objetivo no es presentar nuevos conceptos sino unificar aquellos que se han desarrollado a lo largo de la tesis, y as clarificar la situacin final de la herramienta.
Descripcin de la aplicacin AOP

Dimensin base y aspectos
La aplicacin utilizada como ejemplo, la cual bautizamos con el nombre DotStack, se basa en la implementacin de una pila esttica y una aplicacin cliente que la utiliza, de acuerdo al siguiente diagrama de casos de uso:
La implementacin de la pila en conjunto con la aplicacin cliente conforman la dimensin base del problema. Definiremos dos funcionalidades transversales, conformadas por un aspecto de logging y uno de encriptacin: se utilizar el primero para generar un registro de toda inclusin de un elemento a la pila, y el segundo para que los valores que se ingresen a la pila sean almacenados en un formato encriptado, los cuales sern desencriptados al recuperarlos.
Adrin Eidelman
111/148
FIUBA
El diagrama de casos de uso de la aplicacin DotStack, contemplados los aspectos mencionados, se muestra a continuacin48:
La aplicacin cliente simplemente realiza la instanciacin de una pila y ejecuta la siguiente secuencia de acciones: 1. Inicializa la pila. 2. Introduce un nmero. 3. Si la pila no est vaca recupera el elemento del tope de la pila y lo imprime en pantalla. 4. Elimina el elemento del tope de la pila.
Implementacin de los aspectos

La implementacin del aspecto de logging consta de dos triggers49: startLogging, el cual registra el comienzo de un evento y endLogging, el cual registra la finalizacin de ese mismo evento. Para el ejemplo presentado, startLogging se deber invocar previo a la ejecucin de la primitiva push y endLogging luego de la
48
La notacin UML utilizada corresponde a la propuesta de [Jacobson, 2004] para la especificacin de aplicaciones AOP. 49 La implementacin del aspecto de logging fue tomada del desarrollo realizado en [Cyment & Altman, 2004], ligeramente modificada para este ejemplo.
Adrin Eidelman
112/148
FIUBA
ejecucin de la misma, de forma de registrar la inclusin de un elemento en la pila. El aspecto de encriptacin tambin se compone de dos triggers: encryptValue, el cual encripta el valor que recibe y decryptValue, el cual realiza la operacin inversa. En nuestro caso encryptValue se deber ejecutar previo a la ejecucin de la primitiva push de forma que los valores incluidos sean guardados de forma encriptada- y decryptValue luego de la ejecucin de la primitiva top tal que los valores sean recuperados en un formato no encriptado-. Para simplificar la implementacin utilizamos un cifrado simple por desplazamiento: al encriptar sumamos 1 al valor recibido, y al desencriptar restamos 1 al valor obtenido de la pila. Es necesario, para obtener el comportamiento deseado, definir los pointcuts, aspects y advices que correspondan y realizar las anotaciones sobre el cdigo. De acuerdo a lo descrito, deben incluirse anotaciones a las primitivas push y top, indicando que corresponden a la inclusin de un elemento a la pila y la obtencin del elemento tope respectivamente: [ProgramAnnotation("semantics://stackprimitives#newitem")] public void push(double dValue) { if (!this.isFull()) { sStack.Add(dValue); } } [ProgramAnnotation("semantics://stackprimitives#showitem")] public int top() { if (isEmpty()) return -1; return (int)sStack[sStack.Count - 1]; }
La definicin de pointcuts, aspects y advices corresponde al siguiente cdigo LENDL: pointcut StackNewItem{ message is [stackprimitives#newitem]; }
Adrin Eidelman
113/148
FIUBA
pointcut StackShowItem{ message is [stackprimitives#showitem]; } aspect LoggingAspect enabled{ event startLogging; event endLogging; } aspect EncryptionAspect enabled{ event encryptValue; event decryptValue; } advice LogEvents : LoggingAspect{ trigger startLogging before {StackNewItem}; trigger endLogging after {StackNewItem}; } advice EncryptValues : EncryptionAspect{ trigger encryptValue before {StackNewItem}; trigger decryptValue after {StackShowItem}; }
Realizando el debugging de la aplicacin

Debugging a nivel cdigo fuente
A partir de haber implementado la propiedad de idempotencia contamos con la posibilidad de realizar debugging a nivel cdigo fuente de cualquiera de las dimensiones de la aplicacin. Como se observa en la Figura 9-1, la cual muestra una sesin de debugging del cdigo de la aplicacin cliente, es posible setear breakpoints, inspeccionar el valor de las variables y realizar una ejecucin paso a paso del cdigo50.
50
Como se explic en el captulo anterior, la ejecucin paso a paso presenta en ocasiones una secuencia de ejecucin errnea producto de la actual incapacidad de Phoenix de generar el correcto mapeo entre cdigo fuente y cdigo IL.
Adrin Eidelman
114/148
FIUBA
Figura 9-1: Debugging del cdigo fuente de la dimensin base de la aplicacin
Esto no era factible de realizar en la versin inicial de SetPoint y significaba una limitacin grande a fin de comprender el comportamiento de la aplicacin y encontrar el origen de las fallas. El debugging de cdigo fuente puede realizarse en forma desentendida o ntima con respecto a las actividades AOP. La Figura 9-2 muestra una sesin de debugging no desentendida, donde el cdigo debuggeado corresponde a tareas propias del weaver. Por el contrario la Figura 9-3 refleja una sesin desentendida, en la cual el debugger no detiene la ejecucin en actividades propias del framework, permitiendo al desarrollador concentrarse en la lgica propia de la aplicacin. Esta capacidad es soportada por las propiedades de intimidad y
desentendimiento, las cuales en conjunto con la de idempotencia permiten un debugging de cdigo fuente similar al que acostumbramos a realizar en herramientas de desarrollo no orientadas a aspectos.
Adrin Eidelman
115/148
FIUBA
Figura 9-2: Debugging no desentendido
Figura 9-3: Debugging desentendido
Adrin Eidelman
116/148
FIUBA
Controlando la dinmica de la aplicacin

Las funcionalidades de dinamismo implementadas en SetPoint v2.0 permiten controlar el estado de activacin de los aspectos y la eleccin de la poltica de weaving, tanto en tiempo de diseo como en tiempo de ejecucin. La Figura 9-4 muestra la inhabilitacin del aspecto de encriptacin durante una sesin de debugging, a travs de la ventana integrada a la IDE de Visual Studio para el manejo de dinamismo en SetPoint.
Figura 9-4: Habilitacin/deshabilitacin de aspectos en tiempo de ejecucin
El estado de activacin de los aspectos puede tambin controlarse en tiempo de diseo, posibilitando as la habilitacin/deshabilitacin de los mismos desde el inicio de la ejecucin. El siguiente ejemplo muestra la inactivacin del aspecto de encriptacin a travs de cdigo LENDL: aspect EncryptionAspect disabled{ event encryptValue; event decryptValue; }
Adrin Eidelman
117/148
FIUBA
Anlogamente, el desarrollador posee la capacidad de establecer la poltica de weaving a utilizar ya sea definiendo una poltica fija o librando esa decisin al weaver en runtime- y de esa forma controlar el orden de ejecucin de aspectos producido un matchpoint (Figura 9-5).
Figura 9-5: Modificacin de la poltica de weaving
Las capacidades de dinamismo soportadas por el framework facilitan la deteccin de ciertos tipos de falla. Ejemplificaremos su uso a travs de un ejemplo concreto: Supongamos que ejecutamos la aplicacin cliente incorporando el valor 3 en la pila y el registro de log indica que el valor agregado fue 4. Este malfuncionamiento es producto del incorrecto orden de ejecucin de los aspectos, como se ilustra en la Figura 9-6, provocando as una falla de tipo F2.
Adrin Eidelman
118/148
FIUBA
push(3)
push(4)
encryptValue(3)
Encriptacin
startLogging(4)
Logging 4 PILA
Valor Ingresado: 4 LOG
Figura 9-6: Incorrecta priorizacin de aspectos
A pesar de lo sencillo del ejemplo, teniendo en cuenta que el problema es fcilmente detectable a travs del debugging del cdigo fuente, controlar la dinmica de weaving puede resultar til en casos de mayor complejidad. Si sospechamos que el origen de la falla se encuentra en alguno de los aspectos, podemos deshabilitarlos alternadamente simplificando as el problema- y analizar si la falla se sigue produciendo en ausencia de alguno de ellos. En este caso particular la ejecucin de los aspectos en forma individual no reproduce el fallo, comportndose la aplicacin de manera correcta. Es natural pensar entonces que la interaccin entre los aspectos puede ser el causante del malfuncionamiento y proceder a modificar la poltica de weaving para variar el orden de ejecucin de estos, el cual debiera ser Logging Encriptacin.
Flujo de ejecucin de aspectos

La implementacin de la propiedad conocimiento del flujo de ejecucin incorpora un medio para controlar que los aspectos ejecutados y su orden de ejecucin sean los correctos. Continuando con el ejemplo anterior, la lista de aspectos ejecutados muestra que, al invocar la primitiva push, el aspecto de encriptacin fue ejecutado previo al de logging, produciendo el malfuncionamiento observado (Figura 9-7).
Adrin Eidelman
119/148
FIUBA
Figura 9-7: Lista de ejecucin de aspectos
Una mejor comprensin del flujo de control se lograr observando la informacin en forma grfica, como muestra la Figura 9-8 para el mismo caso. La presentacin grfica brinda un mayor detalle de la informacin, pudiendo observar el flujo de ejecucin a nivel trigger.
Figura 9-8: Visualizacin del flujo de ejecucin de aspectos
Adrin Eidelman
120/148
FIUBA
La presentacin grfica de la informacin permite detectar otro tipo de fallas relacionadas tambin con un incorrecto flujo de control, pero difciles de detectar a travs de las restantes funcionalidades. Si por ejemplo se define incorrectamente el advice LogEvents, estableciendo como trigger before tanto el trigger startLogging como endLogging, entonces el momento registrado como finalizacin del evento no ser el correcto. Este defecto es prcticamente imperceptible para el caso de la pila teniendo en cuenta que la primitiva push se ejecuta en milsimas de segundo-, pero no as en aplicaciones donde el tiempo que demanda la ejecucin del joinpoint no es despreciable. La informacin grfica presentada en la Figura 9-9 muestra claramente el problema: no slo el orden de ejecucin de triggers es el incorrecto endLogging debera ejecutarse posteriormente a la ejecucin de la primitiva push- sino adems que la falla es observable a travs del color del trigger endLogging, delatando que ste ha sido definido como trigger before.
Figura 9-9: Incorrecta definicin del advice
Determinando el origen de la falla

La propiedad aislamiento de fallas no fue incorporada en el marco de esta tesis, pero bien vale mostrar cmo se presenta en la prctica y completar la visin global del soporte al debugging en SetPoint. Un ejemplo sencillo se muestra en la
Adrin Eidelman
121/148
FIUBA
Figura 9-10, donde se observa el mensaje de error que despliega Visual Studio al
provocarse una excepcin.
Figura 9-10: El error muestra el origen de la falla
La informacin presentada al usuario indica que la excepcin se produjo dentro del aspecto de logging producto de una divisin por cero51. Conocer el actor responsable del fallo puede ser crtico para solucionar el problema rpidamente, caso contrario sera necesario inspeccionar todas las posibles fuentes de error dentro del programa. Esta propiedad es soportada intrnsecamente por Visual Studio, pero la capacidad de identificar el actor responsable surge de la arquitectura de componentes propia de SetPoint.
Resumen
Se present en este captulo un ejemplo de aplicacin que unifica los conceptos vistos a lo largo del trabajo, explicando cmo pueden ser utilizados para facilitar la deteccin de fallas caractersticas en desarrollos AOP. El ejemplo presentado permite al lector comprender de forma rpida las funcionalidades implementadas para obtener un mejor soporte al debugging de aplicaciones AOP. Es cierto que la baja complejidad de la aplicacin y la sencillez de las fallas propuestas posibilitan
51
El error fue sembrado para ejemplificar la funcionalidad. La implementacin original del aspecto de logging no realiza operaciones de divisin.
Adrin Eidelman
122/148
FIUBA
al desarrollador detectar gran parte estos defectos a travs de la mera observacin del cdigo fuente. Creemos sin embargo que exponer los avances a travs de ejemplos ms complejos podra dificultar la comprensin del trabajo realizado.
Adrin Eidelman
123/148
FIUBA
10. Conclusiones
Pudimos alcanzar casi por completo el objetivo principal que dio origen a esta tesis: soportar las propiedades de idempotencia y desentendimiento en desarrollos utilizando SetPoint. Las limitaciones impuestas por Phoenix como herramienta de instrumentacin provocan an la existencia de ciertos obstculos para realizar un debugging a nivel cdigo fuente adecuado. Estas limitaciones se resumen en: o Incapacidad de preservar el correcto mapeo entre cdigo fuente y cdigo IL en el archivo PDB generado, provocando una secuencia de ejecucin incorrecta al realizar una ejecucin paso a paso de la aplicacin. o Problemas al instrumentar aplicaciones que cuenten con forms
visuales, restringiendo el tipo de aplicaciones que pueden utilizarse bajo SetPoint v2.0. Phoenix se encuentra an en etapa de desarrollo con lo cual esperamos que estos problemas sean resueltos en el corto plazo. Haber profundizado nuestros conocimientos sobre los temas abordados nos permiti comprender cuan amplio es el concepto de debugging. A partir de esto pudimos extender el alcance del trabajo que en un principio se limitaba a implementar nicamente las propiedades de idempotencia y desentendimiento- para brindar un mejor soporte a las tareas de debugging y por lo tanto una mejor herramienta para desarrollos AOP. A partir de haber extendido el listado de propiedades de una solucin ideal de debugging para AOP propuesta en [Eaddy et al., 2005], creemos haber realizado una contribucin al avance del aseguramiento de la calidad en desarrollos orientados a aspectos, teniendo en cuenta el poco trabajo existente hasta el momento sobre esta temtica. En relacin a la implementacin de los conceptos presentados: o Realizando una comparacin con la situacin inicial de la herramienta, logramos implementar las propiedades de idempotencia, desentendimiento,
Adrin Eidelman
124/148
FIUBA
dinamismo, conocimiento del flujo de ejecucin y parcialmente la propiedad de inmediatez. Para reflejar el avance logrado, la comparacin entre las versiones 1.0 y 2.0 se resume en el siguiente cuadro: Propiedades Idempotencia Desentendimiento Intimidad Dinamismo Introduccin de aspectos Modificaciones en tiempo de ejecucin Aislamiento de fallas Conocimiento del flujo de ejecucin Inmediatez
Soportado /
SetPoint 1.0
SetPoint 2.0
No Soportado /
Consideramos que el mecanismo de visualizacin elegido resulta efectivo para facilitar la comprensin del flujo de ejecucin de un cdigo AOP y detectar fallas relacionadas. Comprobamos lo difcil que es lograr soportar la propiedad de idempotencia, a pesar de lo cual se hizo un gran avance en ese sentido, consiguiendo que SetPoint sea una de las nicas plataformas de desarrollo AOP que brinda la posibilidad de realizar debugging a nivel cdigo fuente mediante un esquema de weaving invasivo. El trabajo realizado en el marco de esta tesis puede significar un buen punto de partida hacia una IDE de enfoque ms amplio para SetPoint. Quedan an ciertos aspectos por resolver para contar con un entorno adecuado para el desarrollo de aplicaciones utilizando el framework, entre los que podemos destacar: La interfaz para la ejecucin de los procesos de preweaving y semanticacin no se encuentra integrada al entorno que utiliza el programador para escribir el cdigo fuente. Sera deseado proveer al desarrollador la posibilidad de saber en tiempo de diseo a qu joinpoints afectar un pointcut, extendiendo
Adrin Eidelman
125/148
FIUBA
de esta forma las funcionalidades implementadas para comprender el flujo de ejecucin. Las caractersticas del esquema de weaving utilizado en SetPoint hacen complicado implementar las propiedades no alcanzadas en este trabajo: capacidad de realizar modificaciones en tiempo de ejecucin e introduccin de aspectos de forma no anticipada. Esto ha servido para que el proyecto SetPoint est considerando actualmente cambiar su modelo de weaving por otro basado en la modificacin de la mquina virtual de .NET, lo cual puede ser un interesante trabajo a futuro. Creemos que, para comprobar las capacidades reales de la herramienta de brindar un adecuado soporte al debugging, es necesario contar con ejemplos prcticos ms cercanos a la realidad, pero principalmente es necesaria una comunidad de usuarios de SetPoint que provea feedback sobre estas capacidades y sobre otras necesidades que puedan surgir.
Adrin Eidelman
126/148
FIUBA
Anexo A El framework Phoenix52

El objetivo de este captulo es presentar en mayor detalle el framework de Microsoft conocido como Phoenix. Teniendo en cuenta que el mismo an se encuentra en etapas de desarrollo, es realmente escaso el material sobre el mismo de forma que tomamos como fuente la informacin provista directamente por dicha empresa53.
54
No
se
pretende
otorgar
una
visin
crtica
de
la
herramienta , sino ampliar la descripcin brindada en el captulo 8 del presente trabajo.
Visin general
El framework Phoenix provee la infraestructura para la construccin de compiladores y herramientas de programacin, soportando una variedad de lenguajes y arquitecturas. Phoenix consta de un ambiente abierto y extensible diseado para adaptarse a las necesidades de dos audiencias principales: desarrolladores que necesitan compiladores y herramientas para utilizar en un ambiente productivo e investigadores que desarrollan herramientas de programacin. Para los desarrolladores, Phoenix ofrece una serie de bloques de construccin (building blocks) que permiten combinar mtodos y objetos para construir una herramienta que persiga un resultado especfico, los cuales soportan varios lenguajes tales como Java, C#, C o C++. Para el caso de los investigadores, Phoenix ofrece una infraestructura que se adapta a diferentes arquitecturas y lenguajes de forma que nuevas herramientas y compiladores puedan ser desarrollados sin la necesidad habitual de construir esta infraestructura desde cero. La siguiente imagen ofrece una visin general de la plataforma Phoenix:
52 53
Fuente: [PHOENIX] Adems de escasa, la documentacin existente es poco clara. Nos limitamos a incluir slo informacin bsica y de alto nivel de forma de lograr una comprensin mnima del framework. 54 Ms an teniendo en cuenta que, como se describi en captulos previos, Phoenix no fue utilizado directamente en el desarrollo prctico de esta tesis.
Adrin Eidelman
127/148
FIUBA
Arquitectura de Phoenix
Phoenix provee una arquitectura flexible para permitir a sus clientes construir diferentes tipos de compiladores y herramientas. Las primitivas esenciales (core primitives) se encuentran separadas de las primitivas de ms bajo nivel de forma que las herramientas puedan ser redestinadas a diferentes configuraciones. Por sobre esta capa se encuentran los readers, writers y otros componentes que conforman las entradas y salidas de la capa de primitivas esenciales. En el ms alto nivel se ubican una variedad de herramientas de optimizacin y anlisis. Los componentes core en Phoenix utilizan una representacin intermedia (IR), un sistema de tipos y un sistema de smbolos comunes. Para la entrada y salida de los componentes, Phoenix maneja, entre otros, los siguientes formatos de archivos: C Intermediate Language (CIL), Microsoft Portable Executable (PE), Microsoft Common Object File Format (COFF) y Microsoft Intermediate Language (MSIL). El siguiente diagrama muestra la arquitectura en capas de Phoenix:
Adrin Eidelman
128/148
FIUBA
Modo dual
Phoenix puede trabajar tanto en modo manejado como no manejado. En modo manejado, el cdigo fuente es compilado en assemblies .NET, los cuales contienen cdigo MSIL (Microsoft Intermediate Language). En tiempo de ejecucin el cdigo MSIL es convertido a cdigo nativo y ejecutado dentro del entorno de ejecucin .NET. En modo no manejado, el cdigo fuente es compilado directamente a cdigo nativo.
Jerarqua de unidades
Phoenix representa los archivos que procesa mediante unidades de compilacin. Estas unidades de compilacin representan el cdigo a travs de estructuras de datos interrelacionadas. La siguiente es una lista de las unidades existentes en la jerarqua:
Adrin Eidelman
129/148
FIUBA
FuncUnit: encapsula la informacin requerida durante la compilacin de una funcin o mtodo individual. DataUnit: representa una coleccin de datos relacionados, como por ejemplo el resultado de procesar una FuncUnit. ModuleUnit: representa una coleccin de funciones. PEModuleUnit: representa una imagen de un archivo PE, como por ejemplo un EXE o una DLL. AssemblyUnit: representa una unidad de compilacin de un assembly .NET. ProgramUnit: representa una unidad de compilacin de un ejecutable. GlobalUnit: representa la unidad de compilacin de forma global. Contiene al resto de las unidades. El siguiente diagrama muestra la jerarqua de unidades en Phoenix:
Resumen
Phoenix es un framework para el anlisis y optimizacin de software que servir como plataforma base para toda futura tecnologa de compiladores Microsoft. El framework Phoenix es un sistema extensible que puede ser adaptado para la lectura y escritura de archivos binarios y assemblies MSIL y para representar los
Adrin Eidelman
130/148
FIUBA
archivos de entrada en un formato intermedio (IR), de forma que puedan ser analizados y manipulados por aplicaciones que usan la API de Phoenix y reemitidos en algn formato ejecutable.
Adrin Eidelman
131/148
FIUBA
Anexo B Diagramas de secuencia SetPoint

Los diagramas de secuencia de las tareas de weaving realizadas por el framework SetPoint que se exhiben en [Cyment & Altman, 2004] se vieron alterados a partir de la implementacin de las nuevas funcionalidades desarrolladas en este trabajo. Se presentan a continuacin los diagramas actualizados, describiendo las principales modificaciones introducidas:
El algoritmo del weaver

Las modificaciones realizadas al algoritmo del weaver estn dadas principalmente por las funcionalidades de dinamismo reflejadas en la no ejecucin de aspectos deshabilitados y la posibilidad de establecer a discrecin la poltica de weaving- y por la propiedad conocimiento del flujo de ejecucin que requiere el registro de ejecucin de aspectos-. El diagrama a continuacin muestra la secuencia de tareas del weaver mientras que el segundo detalla la seleccin de triggers de acuerdo al estado de activacin del advice al cual pertenecen. El log de ejecucin de aspectos se refleja en los mensajes logAspectCall y logExecutionOrder. El primero indica al objeto executionFlow que registre la informacin correspondiente a los aspectos que deben ejecutarse en el joinpoint en cuestin. El mensaje logExecutionOrder registra el orden en el cual los triggers fueron ejecutados, interviniendo en esta tarea el policy broker seleccionado, ya que solamente ste conoce qu triggers efectivamente se ejecutaron y en qu orden. La seleccin de triggers se lleva a cabo en el mensaje AddRange, el cual es detallado en el segundo de los diagramas de secuencia.
Adrin Eidelman
132/148
FIUBA
Adrin Eidelman
133/148
FIUBA
Obtencin de matchpoint y poltica de weaving

La secuencia de tareas para la obtencin del objeto MatchPoint no difiere en relacin a la implementacin original de SetPoint. Incluimos el diagrama para el caso particular de la ejecucin de la primitiva push del ejemplo del captulo 9 para una mejor comprensin del algoritmo. La seleccin del policy broker difiere con respecto a la original teniendo en cuenta que en esta implementacin es posible establecer la poltica a travs de la configuracin de SetPoint. Los diagramas se muestran en el orden respectivo.
Adrin Eidelman
134/148
FIUBA
Adrin Eidelman
135/148
FIUBA
Ejecucin de la RandomWeavingPolicy
La siguiente secuencia muestra la ejecucin de aspectos a travs de la poltica random de weaving. La secuencia para la chain policy puede encontrarse en [Cyment & Altman, 2004]
Adrin Eidelman
136/148
FIUBA
Anexo C Ejemplos de representaciones semnticas

Con el objetivo de profundizar en el uso de tecnologas de la Web semntica para la implementacin de setpoints, se incluyen en este captulo las descripciones de los universos semnticos del Common Type System55 (CTS) y de la aplicacin DotStack presentada en el captulo 9, a travs de sus representaciones XML. Estas representaciones, las cuales son utilizadas por el weaver de SetPoint para determinar la inclusin de un joinpoint en un pointcut semntico, intentan principalmente facilitar la comprensin de los conceptos presentados en el captulo 3, en particular lo referido a las tecnologas de la web semntica utilizadas por el framework. Es posible observar en estos ejemplos el uso de URIs, XML, RDF-Schema y OWL.
Representacin semntica de la aplicacin DotStack

En el captulo 9 describimos una aplicacin AOP ejemplo la cual bautizamos DotStack- con el fin comprender las funcionalidades implementadas en el marco de la presente tesis. En esta seccin se presenta la representacin XML de la aplicacin en un formato RDF-Schema, la cual describe la estructura de la aplicacin clases, mtodos, anotaciones, etc.- y brinda la posibilidad de determinar la inclusin de un joinpoint en un pointcut semntico. Por ejemplo para el caso de la primitiva push, la cual se ha marcado con la anotacin
semantics://stackprimitives#newitem, existe el siguiente nodo XML que describe la relacin: <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..push" > <hasAnnotation xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://stackprimitives#newitem" /> </rdf:Description>
Ntese que la relacin se expresa en forma similar al de una terna, tal como se describi en el captulo 3.
55
El CTS define tipos y operaciones comunes para el framework .NET. Algunos (integer, floating point, strings) son soportados nativamente por la plataforma, mientras que se dan los lineamientos para las entidades que puede definir el usuario.
Adrin Eidelman
137/148
FIUBA
A continuacin se presenta la representacin XML completa de la aplicacin:

<?xml version="1.0" encoding="UTF-8" ?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Ontology" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Assemb ly" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Module" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack"> <hasModule xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.Program"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Class" /> <isDelegate xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://programElements/objectOriented/CTS#false" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe"> <hasType xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.Program " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.Program..Main "> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.Program"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.Program ..Main" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.Program...ctor ">
Adrin Eidelman
138/148
FIUBA
<rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Constru ctor" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.Program"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.Program ...ctor" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Class" /> <isDelegate xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://programElements/objectOriented/CTS#false" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe"> <hasType xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..sS tack"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Field" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..sStack" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..iC apacity"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Field" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..iCapacity" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..ini tialize">
Adrin Eidelman
139/148
FIUBA
<rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..initialize" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..is Empty"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..isEmpty" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..is Full"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..isFull" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..to p"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..top" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..to p">
Adrin Eidelman
140/148
FIUBA
<hasAnnotation xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://stackprimitives#showitem" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..pu sh"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..push" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..pu sh"> <hasAnnotation xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://stackprimitives#newitem" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack..po p"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Method " /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack..pop" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack...ct or"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Constru ctor" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack...ctor" /> </rdf:Description>
Adrin Eidelman
141/148
FIUBA
<rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack...c ctor"> <rdf:type rdf:resource="semantics://programElements/objectOriented/CTS#Constru ctor" /> </rdf:Description> <rdf:Description rdf:about="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticStack"> <hasMember xmlns="semantics://programElements/objectOriented/CTS#" rdf:resource="semantics://CTS/DotStack/DotStack.exe#DotStack.StaticSt ack...cctor" /> </rdf:Description> </rdf:RDF>
Representacin semntica del Common Type System

Para poder predicar sobre los joinpoints utilizando relaciones del estilo
<Identificador, esUna, clase> debe lgicamente estar definido el concepto de Clase. Para lograr esto, SetPoint incluye dentro de su motor de weaving la descripcin de la ontologa del CTS, la cual se presenta a continuacin en formato XML:
<?xml version="1.0"?> <rdf:RDFxmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns="semantics://programElements/objectOriented/CTS#" xml:base="semantics://programElements/objectOriented/CTS"> <owl:Ontology rdf:about="" /> <owl:Class rdf:ID="ProgramAnnotation" /> <owl:Class rdf:ID="Assembly"> <rdfs:subClassOf> <owl:Class rdf:ID="ProgramElement" /> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Method"> <rdfs:subClassOf> <owl:Class rdf:ID="MethodBase" /> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Instance"> <rdfs:subClassOf rdf:resource="#ProgramElement" /> </owl:Class> <owl:Class rdf:ID="Member"> <rdfs:subClassOf rdf:resource="#ProgramElement" /> </owl:Class> <owl:Class rdf:about="#MethodBase"> <rdfs:subClassOf rdf:resource="#Member" />
Adrin Eidelman
142/148
FIUBA
</owl:Class> <owl:Class rdf:ID="Module"> <rdfs:subClassOf rdf:resource="#ProgramElement" /> </owl:Class> <owl:Class rdf:ID="Type"> <rdfs:subClassOf rdf:resource="#ProgramElement" /> </owl:Class> <owl:Class rdf:ID="Constructor"> <rdfs:subClassOf rdf:resource="#MethodBase" /> </owl:Class> <owl:Class rdf:ID="Field"> <rdfs:subClassOf rdf:resource="#Member" /> </owl:Class> <owl:Class rdf:ID="Interface"> <rdfs:subClassOf rdf:resource="#Type" /> </owl:Class> <owl:Class rdf:ID="Class"> <rdfs:subClassOf rdf:resource="#Type" /> </owl:Class> <owl:ObjectProperty rdf:ID="hasModule"> <rdfs:subPropertyOf> <owl:TransitiveProperty rdf:ID="hasProgramElement" /> </rdfs:subPropertyOf> <rdfs:domain rdf:resource="#Assembly" /> <rdfs:range rdf:resource="#Module" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="inheritsFrom"> <rdfs:range rdf:resource="#Type" /> <rdfs:domain rdf:resource="#Type" /> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="typeOf"> <owl:inverseOf> <owl:FunctionalProperty rdf:ID="instanceOf" /> </owl:inverseOf> <rdfs:domain rdf:resource="#Type" /> <rdfs:range rdf:resource="#Instance" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasAnnotation"> <rdfs:domain rdf:resource="#ProgramElement" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasType"> <rdfs:range rdf:resource="#Type" /> <rdfs:subPropertyOf> <owl:TransitiveProperty rdf:about="#hasProgramElement" /> </rdfs:subPropertyOf> <rdfs:domain rdf:resource="#Module" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="implements"> <rdfs:range rdf:resource="#Interface" /> <rdfs:domain rdf:resource="#Type" /> </owl:ObjectProperty>
Adrin Eidelman
143/148
FIUBA
<owl:ObjectProperty rdf:ID="hasMember"> <rdfs:range rdf:resource="#Member" /> <rdfs:subPropertyOf> <owl:TransitiveProperty rdf:about="#hasProgramElement" /> </rdfs:subPropertyOf> <rdfs:domain rdf:resource="#Type" /> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="isDelegate"> <rdfs:range rdf:resource=http://www.w3.org/2001/XMLSchema#string /> <rdfs:domain rdf:resource="#Class" /> </owl:DatatypeProperty> <owl:TransitiveProperty rdf:about="#hasProgramElement"> <rdfs:domain rdf:resource="#ProgramElement" /> <rdf:type rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty /> <rdfs:range rdf:resource="#ProgramElement" /> </owl:TransitiveProperty> <owl:FunctionalProperty rdf:about="#instanceOf"> <rdfs:range rdf:resource="#Type" /> <rdf:type rdf:resource=http://www.w3.org/2002/07/owl#ObjectProperty /> <rdfs:domain rdf:resource="#Instance" /> <owl:inverseOf rdf:resource="#typeOf" /> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="hasName"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string" /> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty" /> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Member" /> <owl:Class rdf:about="#Type" /> </owl:unionOf> </owl:Class> </rdfs:domain> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="hasNamespace"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string" /> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty" /> <rdfs:domain rdf:resource="#Type" /> </owl:FunctionalProperty> </rdf:RDF>
Adrin Eidelman
144/148
FIUBA
Referencias
[Alexander & Bieman, 2002] R. T. Alexander, J. Bieman. Challenges of AspectOriented Technology, Workshop on Software Quality, 24th Intl Conf. Software Engineering, 2002.
[Alexander et al., 2004] R. T. Alexander, J. Bieman y A. A. Andrews. Towards the Systematic Testing of Aspect-Oriented Programs, Technical Report CS-4-105, Colorado State University, Fort Collins, Colorado, 2004.
[Broekstra et al., 2003] J. Broekstra, A. Kampman y F. van Harmelen. Sesame: An Architecture for Storing and Querying RDF Data and Schema Information, Spinning the Semantic Web, 2003.
[Ceccato et al., 2005] M. Ceccato, P. Tonella y F. Ricca. Is AOP Code Easier or Harder to Test than OOP Code, Fourth International Conference on Aspect-Oriented Software, 2005.
[Cyment & Altman, 2004] A. Cyment y R. Altman. SetPoint: Un enfoque semntico para la resolucin de pointcuts en AOP. Facultad de Ciencias Exactas, Universidad de Buenos Aires, 2004.
[Dedecker, 2002] Jessie Dedecker. Dynamic Aspect Composition using Logic Metaprogramming, Vrieje Universiteit Brussel, Blgica, 2002.
[Eaddy et al., 2005] M. Eaddy, A. Aho, W. Hu, P. McDonald y J. Burguer. Debugging Woven Code. Columbia University, New York; Microsoft Corporation, Redmond, 2005.
[Elrad et al., 2001a] T. Elrad, M. Aksit, G. Kiczales, K. Lieberherr y H. Ossher. Discussing Aspects of AOP, Communications of the ACM, vol. 44, no. 10, pgs. 3338, 2001.
[Elrad et al., 2001b] T. Elrad, R. Filman y A. Bader. Aspect-Oriented Programming, Communications of the ACM, vol. 44, no. 10, pgs. 29-32, 2001.
Adrin Eidelman
145/148
FIUBA
[Filman & Friedman, 2000] R. Filman y D. Friedman. Aspect-Oriented Programming is Quantification and Obliviousness, Proc. Workshop on Advanced Separation of Concerns, OOPSLA 2000.
[Humphrey, 1999] W. S. Humphrey. Bugs or Defects? Technical Report Vol. 2, Issue 1, Carnegie Mellon Software Engineering Institute, Pittsburgh, 1999.
[Ishio et al., 2004] T. Ishio, S. Kusumoto y K. Inoue. Debugging Support for Aspect-Oriented Program Based on Program Slicing and Call Graph, Proc. 20th IEEE International Conference on Software Maintenance, 2004.
[Jacobson, 2004] I. Jacobson. Aspect-Oriented Software Development with Use Cases, Addison-Wesley Professional, 2004. [Kellens et al., 2006] A. Kellens, K. Mens, J. Brichau y K. Gybels. Managing the Evolution of Aspect-Oriented Software with Model-based Pointcuts, Proc. Workshop on Software Engineering Properties of Language for Aspect Technology (SPLAT), 2006.
[Kiczales et al., 1997] G. Kiczales, J. Irwin, J. Lamping, J. Loingtier, C. Videira Lopes, C. Maeda y A. Mendhekar. Aspect-Oriented Programming, ECOOP 1997.
[Kiczales et al., 2001] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm y W. Griswold. An Overview of AspectJ, ECOOP 2001.
[MSDN-DBGHELP] http://msdn.microsoft.com/library/default.asp?url=/library/enus/debug/base/dbghelp_versions.asp. Pgina vigente al 26/08/06. [MSDN-DIA] http://msdn.microsoft.com/library/default.asp?url=/library/enus/diasdk/html/vsoriConceptualOverview.asp. Pgina vigente al 26/08/06. [MSDN-SYMBOL] http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpref/html/frlrfsystemdiagnosticssymbolstore.asp. Pgina vigente al 26/08/06.
[MSDN-LINE]http://msdnwiki.microsoft.com/en-us/mtpswiki/34dk387t(VS.80).aspx. Pgina vigente al 23/08/06.
[NETRON] http://sourceforge.net/projects/netron. Pgina vigente al 23/08/06.
Adrin Eidelman
146/148
FIUBA
[PERWAPI] http://plas.fit.qut.edu.au/perwapi/. Pgina vigente al 23/08/06.
[PHOENIX] http://research.microsoft.com/phoenix. Pgina vigente al 23/08/06.
[PROTEGE] http://protege.stanford.edu/. Pgina vigente al 23/08/06.
[Redmond & Cahill, 2002] B. Redmond y V. Cahill. Supporting Unanticipated Dynamic Adaptation of Application Behaviour, ECOOP 2002.
[Rosenberg, 1996] J. B. Rosenberg. How Debuggers Work: Algorithms, Data Structures, and Architecture, Wiley Computer Publishing, 1996.
[SeRQL] http://www.openrdf.org/doc/sesame/users/ch06.html. Pgina vigente al 23/08/06. [Stall, 2004] M. Stall. How can I debug Just My Code. http://blogs.msdn.com/jmstall/archive/2004/12/31/344832.aspx. Pgina vigente al 24/08/06. [Stall, 2005a] M. Stall. #line hidden and 0xFeeFee sequence points. http://blogs.msdn.com/jmstall/archive/2005/06/19/FeeFee_SequencePoints.aspx. Pgina vigente al 24/08/06. [Stall, 2005b] M. Stall. Big pictures on Symbol APIs. http://blogs.msdn.com/jmstall/archive/2005/10/08/symbol_apis.aspx. Pgina vigente al 23/08/06.
[STALL, 2005c] M. Stall. Symbol API (CorSym.idl) for managed PDBs. http://blogs.msdn.com/jmstall/archive/2005/09/30/corsym_idl.aspx. Pgina vigente al 26/08/06. [Stall, 2006] M. Stall. #line hidden vs. DebuggerNonUserCode attribute. http://blogs.msdn.com/jmstall/archive/2006/07/12/debuggernonusercode_vs_line_ hidden.aspx Pgina vigente al 24/08/06. [Tourw et al., 2003] T. Tourw, J. Brichau y K. Gybels. On the Existence of the AOSD-Evolution Paradox, Workshop on Software-engineering Properties of Languages for Aspect Technologies, AOSD 2003.
Adrin Eidelman
147/148
FIUBA
[Ungar et al., 1997] D. Ungar, H. Lieberman y C. Fry. Debugging and the Experience of Immediacy, Communications of the ACM, vol. 40, no. 4, pgs. 38-43, 1997.
[Uschold, 1998] M. Uschold. Knowledge level modeling: concepts and terminology Knowledge engineering review, vol. 13, no. 1, 1998.
[Zeller, 2005] A. Zeller. Why Programs Fail A Guide to Systematic Debugging, Morgan Kaufmann Publishers, 2005.
[Zhao, 2003] J. Zhao. Data-Flow-Based Unit Testing of Aspect-Oriented Programs, COMPSAC 2003.
[Zhao & Rinard, 2003] J. Zhao y M. Rinard. System Dependence Graph Construction for Aspect-Oriented Programs. Technical Report MIT-LCS-TR-891, Laboratory for Computer Science, MIT, 2003.
[Zhou,
2004]
Y.
Zhou.
Specification-Based
Testing
for
Aspect-Oriented
Programming, International Workshop on Software Engineering and AspectOriented Software Development, 2004.
[Zhou et al., 2004] Y. Zhou, D. Richardson, H. Ziv. Towards a Practical Approach to Test Aspect-Oriented Software, Workshop on Testing Component-based Systems (TECOS2004), 2004.
Adrin Eidelman
148/148

Hacia Una Mejor Experiencia de Debugging en Desarrollos AOP

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Hacia Una Mejor Experiencia de Debugging en Desarrollos AOP

Transféré par

Droits d'auteur :

Formats disponibles

TESIS DE GRADO EN INGENIERA INFORMTICA

Hacia una mejor experiencia de debugging en desarrollos AOP

FACULTAD DE INGENIERA UNIVERSIDAD DE BUENOS AIRES

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

El proyecto SetPoint ser descrito en profundidad ms adelante en este trabajo.

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

2. La Programacin Orientada a Aspectos

El problema de las incumbencias transversales

Hacia una mejor experiencia de debugging en desarrollos AOP

Figura 2-1: Modelo de la solucin para el estudio jurdico

Hacia una mejor experiencia de debugging en desarrollos AOP

Figura 2-2: La encriptacin de datos constituye una incumbencia transversal

Hacia una mejor experiencia de debugging en desarrollos AOP

Figura 2-3: Code Scattering y Code Tangling

Una propuesta de solucin: AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Elementos distintivos del paradigma AOP4

Hacia una mejor experiencia de debugging en desarrollos AOP

JoinPoints, Pointcuts y Advices

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

SISTEMA DE ESTUDIO JURDICO

Abogados, Secretarias, Legajos, Escritos ...

Figura 2-5: El proceso de weaving

Hacia una mejor experiencia de debugging en desarrollos AOP

Otras ventajas que ofrece AOP

AOP vs. POO

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

SetPoint, lector lector, SetPoint

Hacia una mejor experiencia de debugging en desarrollos AOP

Una motivacin para SetPoint: la paradoja de la programacin AOP

pointcut mensajesSensibles(): (target(Abogado) || target(Secretaria)) && call(void enviarMensaje(string));

pointcut mensajesSensibles(): (target(Abogado) || target(Secretaria)) && call(void *Mensaje(string));

AspectJ es la herramienta ms difundida y utilizada para el desarrollo de sistemas AOP en la actualidad.

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Semantic pointcuts y conceptos de la Web semntica

Hacia una mejor experiencia de debugging en desarrollos AOP

Conceptos de la Web semntica

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Armando el rompecabezas hacia la implementacin de setpoints

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP

Modelo de Joinpoints y Weaving

Hacia una mejor experiencia de debugging en desarrollos AOP

Completando el universo semntico de la aplicacin

Hacia una mejor experiencia de debugging en desarrollos AOP

Declaracin de aspectos, advices y pointcuts

Hacia una mejor experiencia de debugging en desarrollos AOP

Hacia una mejor experiencia de debugging en desarrollos AOP