• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Curso Aop01
 

Curso Aop01

on

  • 700 views

 

Statistics

Views

Total Views
700
Views on SlideShare
699
Embed Views
1

Actions

Likes
0
Downloads
15
Comments
0

1 Embed 1

http://amistad-lealtad.blogspot.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Curso Aop01 Curso Aop01 Presentation Transcript

    • Programaci´n Orientada a Aspectos: Metodolog´ y o ıa Evaluaci´n o Fernando Asteasuain, Bernardo E. Contreras, Elsa Est´vez, Pablo R. Fillottrani e Departamento de Ciencias e Ingenier´ de la Computaci´n ia o Universidad Nacional del Sur Av. Alem 1253 – (8000) Bah´ Blanca ıa Argentina {fa,bec,ece,prf}@cs.uns.edu.ar Resumen La Ingenier´ de Software tradicional carece actualmente de mecanismos adecua- ıa dos para abstraer, y encapsular conceptos que no forman parte de la funcionalidad b´sica de los sistemas, tales como debugging, sincronizaci´n, distribuci´n, seguridad, a o o administraci´n de memoria, y otros. El resultado de esta insuficiente abstracci´n o o es una notable disminuci´n de la calidad del software final. Una de las alternati- o vas m´s prometedoras para resolver este problema es la Programaci´n Orientada a a o Aspectos (POA). En este trabajo se analiza la aplicaci´n de la POA. Se realiza la o reingenier´ de una implementaci´n orientada a objetos introduciendo aspectos. Se ıa o definen m´tricas para evaluar las importantes ventajas de incorporar aspectos a la e programaci´n tradicional. Se las aplica a un caso de estudio, y se muestra que los o resultados obtenidos confirman la eficacia, y la utilidad de la POA. Se presenta un caso de estudio que consiste en la adaptaci´n considerando aspectos del protocolo o para transferir archivos Trivial File Transfer Protocol(TFTP). Palabras claves: Ingenier´ de Software, Programaci´n Orientada a Aspectos, ıa o m´tricas orientadas a aspectos, AspectJ, desarrollo orientado a aspectos. e 1 Introducci´n o La Ingenier´ de Software ha evolucionado desde sus comienzos. Con esta evoluci´n se ıa o introdujeron conceptos tales como el agrupamiento de instrucciones a trav´s de procedi- e mientos y funciones, m´dulos, bloques estructurados, tipos de datos abstractos, generici- o dad, y herencia entre otros. Estos conceptos proveen formas de asbtracci´n y constituyen o el medio para lograr una programaci´n de alto nivel. As´ o ımismo, los progresos m´s impor- a tantes se han obtenido aplicando estos conceptos junto con tres principios estrechamente relacionados entre s´ abstracci´n, encapsulamiento, y modularidad. ı: o 1 CACIC 2003 - RedUNCI 1160
    • La Programaci´n Orientada a Objetos (POO) introdujo un avance importante forzando o el encapsulamiento y la abstracci´n, por medio de una unidad que captura tanto funciona- o lidad como comportamiento, y estructura interna. A esta entidad se la conoce como clase, y su principal caracter´ ıstica es que enfatiza datos y algoritmos. A trav´s de POO, o de e otras t´cnicas de abstracci´n de alto nivel, se logra un dise˜ o y una implementaci´n que e o n o satisface la funcionalidad b´sica, y que presenta niveles de calidad aceptable. Sin embargo, a existen conceptos entrecruzados que no pueden encapsularse dentro de una unidad funcio- nal, debido a que atraviesan todo el sistema, o varias partes de ´l. Algunos de ellos son: e sincronizaci´n, manejo de memoria, distribuci´n, chequeo de errores, seguridad, y redes. o o Las t´cnicas de implementaci´n actuales tienden a implementar los requerimientos e o usando metodolog´ de una sola dimensi´n, forzando a que todos los requerimientos sean ıas o expresados en esa unica dimensi´n. Esta dimensi´n resulta adecuada para la funciona- ´ o o lidad b´sica, pero no para los otros requerimientos, los cuales quedan diseminados a lo a largo de la dimensi´n dominante. Es decir, que mientras el espacio de requerimientos es de o n-dimensiones, el espacio de la implementaci´n es de una sola dimensi´n. Dicha diferencia o o produce un mapeo deficiente de los requerimientos a sus respectivas implementaciones. Los dos s´ıntomas m´s significativos de este problema son el C´digo Mezclado (Code Tangling) a o y el C´digo Diseminado (Code Scattering) [1]. El C´digo Mezclado se presenta cuando en o o un mismo m´dulo de un sistema de software conviven simult´neamente m´s de un reque- o a a rimiento. Esto hace que en el modelo existan elementos de implementaci´n de m´s de un o a requerimiento. El C´digo Diseminado se produce cuando un requerimiento est´ esparcido o a sobre varios m´dulos. Por lo tanto, la implementaci´n de dicho requerimiento tambi´n o o e queda diseminada sobre esos m´dulos. o La combinaci´n de estos s´ o ıntomas afecta tanto al dise˜o como a la implementaci´n de n o software [1]. La implementaci´n simult´nea de varios conceptos tiene dos efectos negati- o a vos. El primero es una baja correspondencia entre un concepto y su implementaci´n. El o segundo es una menor productividad de los desarrolladores, ya que se distraen del concepto principal. Por otro lado, la implementaci´n de varios conceptos en un mismo m´dulo lleva o o a un c´digo poco reusable, de baja calidad, y propenso a errores. Esto se debe a que alguno o de los tantos conceptos puede ser subestimado. Por ultimo, la evoluci´n es m´s dificultosa ´ o a debido a la insuficiente modularizaci´n. Los futuros cambios en un requerimiento implican o revisar y modificar cada uno de los m´dulos donde est´ presente ese requerimiento. o e Por las razones expuestas se concluye que las t´cnicas tradicionales no soportan una e completa separaci´n de conceptos. Esto es, no permiten una modularizaci´n adecuada que o o facilite separar la implementaci´n de determinados aspectos, distintos a la funcionalidad o b´sica. Esta situaci´n tiene un impacto negativo en la calidad del software, ya que esta a o caracter´ ıstica es clave para producir un software comprensible y evolucionable. Como respuesta a este problema nace la Programaci´n Orientada a Aspectos (POA). o La POA permite a los desarrolladores escribir, ver, y editar un aspecto diseminado por todo el sistema como una entidad por separado, de una manera inteligente, eficiente e intuitiva. La POA es una nueva metodolog´ de programaci´n que aspira a soportar la ıa o separaci´n de las propiedades para los aspectos antes mencionados. Esto implica separar o la funcionalidad b´sica de los aspectos, y los aspectos entre s´ a trav´s de mecanismos que a ı, e permitan la abstracci´n y la composici´n de los mismos, a fin de poder implementar todos o o los requerimientos del sistema. 2 CACIC 2003 - RedUNCI 1161
    • En este trabajo se estudia la aplicaci´n de la POA. Se compara la implementaci´n de o o un producto de software con y sin aspectos. Se presenta la metodolog´ empleada para ıa convertir una implementaci´n tradicional, en una que considera aspectos. Para realizar o una comparaci´n m´s exhaustiva, se definen m´tricas. Las m´tricas son necesarias en todo o a e e proyecto tecnol´gico, ya que la idea de medici´n hace los conceptos mas visibles, y por lo o o tanto mas comprensibles y controlables [2]. Se introducen m´tricas que permiten medir el e impacto de la aplicaci´n del paradigma. A continuaci´n, se aplican las m´tricas al caso de o o e estudio presentado, y se analizan los valores obtenidos. Finalmente, se mencionan trabajos relacionados, se incluyen las conclusiones, y el trabajo futuro. 2 Fundamentos de la POA Los tres elementos constitutivos principales de la POA son [3]: • Un lenguaje para definir la funcionalidad b´sica, conocido como lenguaje base o a componente. El mismo puede ser un lenguaje imperativo, o no, como por ejemplo C++, Java, Lisp, ML. • Uno o varios lenguajes de aspectos, para especificar el comportamiento de los distintos aspectos. Algunos ejemplos son COOL, para espeficicar sincronizaci´n, y RIDL para o especificar distribuci´n. o • Un tejedor de aspectos, del ingl´s weaver, que se encarga de combinar los lenguajes e en tiempo de ejecuci´n o de compilaci´n. o o Los lenguajes orientados a aspectos definen una nueva unidad de programaci´n de o software para encapsular aquellos conceptos que cruzan todo el c´digo. Al momento de tejer o los componentes y los aspectos para formar el sistema final, es evidente que se requiere una interacci´n entre el c´digo que provee la funcionalidad b´sica, y el c´digo de los aspectos. o o a o Claramente, esta interacci´n no es la misma que ocurre entre los m´dulos del lenguaje base, o o donde la comunicaci´n est´ basada en declaraciones de tipo, y llamadas a procedimientos o a y funciones. Por esta raz´n, la POA define una nueva forma de interacci´n, provista a o o trav´s de puntos de enlace. e Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del c´digo donde es posible agregar el comportamiento adicional que caracteriza a o la POA. Dicho comportamiento adicional es especificado en los aspectos, y puede agregarse antes, despu´s, o en el lugar del punto de enlace. Por ejemplo, dentro de la POO algunos e puntos de enlace pueden ser: llamadas a m´todos, creaci´n de objetos, acceso a atributos, e o etc. Por ultimo, resta mencionar al encargado principal en el proceso de la POA, el tejedor. ´ ´ Este debe realizar la parte final y m´s importante: tejer los diferentes mecanismos de a abstracci´n y composici´n que aparecen tanto en los lenguajes de aspectos, como en los o o lenguajes de componentes, guiado por los puntos de enlace. La estructura general de una implementaci´n basada en aspectos difiere de la estruc- o tura de una implementaci´n tradicional. Una implementaci´n tradicional consiste de un o o lenguaje, un compilador, o int´rprete para ese lenguaje, y finalmente, un programa escrito e 3 CACIC 2003 - RedUNCI 1162
    • en ese lenguaje que implemente la aplicaci´n. En cambio, una implementaci´n basada en o o la POA presenta en primer t´rmino, un lenguaje base que permite implementar la fun- e cionalidad b´sica. Luego, uno o m´s lenguajes de aspectos para la implementaci´n de los a a o mismos, y un tejedor de aspectos encargado de la combinaci´n de los lenguajes. Por ultimo, o ´ se requiere el programa escrito en el lenguaje base, que implementa los componentes fun- cionales, y uno o m´s programas de aspectos que implementan a estos. Gr´ficamente, se a a pueden comparar ambas estructuras, como queda reflejado en la figura 1. Figura 1: Estructura tradicional y Estructura aplicando POA En la secci´n siguiente se presenta el caso de estudio, y su implementaci´n con y sin o o aspectos. En base a ´ste, y con los resultados de las m´tricas definidas, se analizan los e e beneficios de la aplicaci´n del paradigma. o 3 Aplicaci´n de la POA o En este traabjo se plantea un caso de estudio, que considera la implementaci´n del proto- o colo TFTP (Trivial File Transfer Protocol) con y sin aspectos, con el objetivo de aplicar y evaluar la POA. La versi´n sin aspectos es la versi´n TFTP 0.8 de Mark Benvenuto, o o realizada en Java, de distribuci´n libre, y que puede obtenerse de su p´gina [5]. Nuestro o a trabajo consisti´ de una reingenier´ de este producto, logrando una implementaci´n en o ıa o AspectJ [6], una extensi´n de Java para soportar la programaci´n orientada a aspectos. La o o funcionalidad b´sica coincide con la provista por la versi´n original del autor. Sin embargo, a o se debieron introducir algunas modificaciones espec´ ıficas para el tratamiento de los aspec- tos. La comparaci´n de ambas implementaciones permite obtener relevantes conclusiones o y evaluar con resultados concretos la verdadera dimensi´n de las ventajas de la POA, y de o su principal herramienta AspectJ. 4 CACIC 2003 - RedUNCI 1163
    • TFTP es un protocolo para transferir archivos entre procesos. Es una alternativa a FTP (File Transfer Protocol) con menos sobrecarga, m´s simple pero con seguridad a m´ınima. Para mayor informaci´n sobre el protocolo consultar las RFC [10]. o En las pr´ximas dos subsecciones se analizan las dos implementaciones del caso de o estudio. En la primera se describe la implementaci´n en Java, y en la siguiente en AspectJ. o A continuaci´n, se comparan ambas implementaciones, y en la secci´n siguiente se miden o o los resultados mediante la definici´n de m´tricas. o e 3.1 Implementaci´n en Java o En la implementaci´n del protocolo existen dos enfoques principales: el del cliente, y el del o servidor. Por cuestiones de extensi´n, en este trabajo s´lo se analiza el punto de vista del o o servidor. Esto se debe a que el estudio de esta rama de an´lisis es suficiente para mostrar a claramente los resultados obtenidos con la aplicaci´n de las m´tricas. Por razones similares, o e dentro del punto de vista del servidor, s´lo se analizan las acciones correspondientes a la o escritura de archivos. Esto es, un pedido de lectura por parte del cliente. El objetivo principal durante el desarrollo del trabajo fue mantener el modelo lo m´s sencillo posible, a y simult´neamente poder observar mejor el impacto de la utilizaci´n de la POA. a o Figura 2: Rama de an´lisis a La figura 2 muestra el camino de an´lisis elegido. Dicho camino est´ marcado con color a a dentro del arbol que modela la implementaci´n del protocolo TFTP. El c´digo en Java que ´ o o implementa el camino seleccionado se encuentra detallado en [3]. Al analizar el c´digo en Java se observa que si bien la l´gica del protocolo es simple, o o el c´digo resultante es confuso y complejo. Esto se debe a ciertos aspectos, que no tienen o relaci´n directa con el protocolo, sino a cuestiones extras, o agregados. o El aspecto m´s importante y que m´s “ensucia” el c´digo es el aspecto de logging: a a o encargado de llevar las trazas, informar las excepciones, manejar las estad´ ısticas de las 5 CACIC 2003 - RedUNCI 1164
    • conexiones, entre otras tareas. Todo el c´digo necesario para el logging resulta desparra- o mado por todas las clases, esto es, entrecruza las clases, obstruyendo el entendimiento de la l´gica del programa. Este c´digo sucio, que muchas veces resulta c´digo duplicado, incluye o o o sentencias, mensajes, como tambi´n atributos relativos al logging dentro de las clases que e implementan el protocolo. Las graves consecuencias de este tipo de c´digo ya se mencio- o naron en este trabajo, y entre otras podemos mencionar la dificultad de entendimiento y de lectura, menor robustez, dificultades a la hora de enfrentar cambios o modificaciones, y disminuci´n de la calidad. o 3.2 Implementaci´n en AspectJ o AspectJ permite abstraer y encapsular concretamente el aspecto de logging a trav´s del e constructor ling¨´ uıstico aspect [11]. Con esto se logra una funcionalidad b´sica limpia a con c´digo s´lo relativo al protocolo, y en forma separada, todas las acciones de logging, o o claramente especificadas dentro de una unica unidad. ´ A modo de ejemplo, se considera en la figura 3 una porci´n de c´digo escrita en Java, o o y en las siguientes dos figuras la implementaci´n del mismo comportamiento en AspectJ. o if(debug > 0) logWriter.println(quot;Receiving Packetquot;); try{ sock.receive(ACKp); }catch( InterruptedIOException iioe) { logWriter.println(quot;Error Receiving Packet: quot; + iioe); logWriter.println(quot;Continuing to wait for Packetquot;); continue; } ... %C´digo para procesar el paquete o ... Figura 3: Ejemplo de C´digo Mezclado en Java o En la figura 3, se muestra una de las acciones del protocolo correspondiente a la sen- tencia para recibir un paquete. La misma se ve ensuciada por las actividades propias del logging. En AspectJ, el c´digo se divide en dos partes: la funcionalidad b´sica, que consiste o a en recibir el paquete para luego procesarlo; y el aspecto de logging, que encapsula las actividades del logging. En la figura 4 se detalla la funcionalidad b´sica, mientras que en a la figura 5 se detalla la implementaci´n de este aspecto. o En este c´digo resulta una funcionalidad b´sica que se refiere unicamente al protocolo o a ´ TFTP, y las acciones de logging ya no resultan mezcladas, debido a que el aspecto logra abstraerlas por separado. Es importante destacar que estos beneficios resultan de aplicar el paradigma s´lo a una porci´n del sistema. Las ganancias son notablemente mayores al o o aplicar el paradigma sobre el sistema completo. 6 CACIC 2003 - RedUNCI 1165
    • sock.receive(ACKp); %C´digo para procesar el paquete o ... Figura 4: Funcionalidad b´sica a Aspect Logging{ ... pointcut receivePacket(DatagramPacket packet): call(DatagramSocket.receive(DatagramPacket))&& args(packet); before(DatagramPacket packet):receivePacket(packet)&& anyTftp(){ if(debugMode > 0) logStream.println(quot;Receiving Packetquot;); } after(DatagramPacket packet) throwing(InterruptedIOException iioe ): receivePacket(packet){ logStream.println(quot;Error Receiving Packet: quot; + iioe); logWriter.println(quot;Continuing to wait for Packetquot;); } } Figura 5: C´digo del aspecto o Para implementar el resto del sistema en AspectJ se sigue la misma estrategia que se aplic´ a la porci´n de c´digo analizada anteriormente. La estrategia de desarrollo orientada o o o a aspectos que definimos en este trabajo consiste de tres pasos: 1. Identificar un aspecto en el sistema. Por ejemplo, el aspecto de logging en la imple- mentaci´n del protocolo TFTP. o 2. Para el aspecto identificado considerar los siguientes pasos: (a) Identificar un punto o momento en particular donde se necesitan las acciones relacionadas con el aspecto. Por ejemplo, al recibir o enviar un paquete, al leer o escribir un archivo, al crear un socket, al obtener informaci´n de un paquete. o (b) Capturar ese punto como un corte de AspectJ. Por ejemplo, el siguiente corte captura el momento de enviar un paquete. pointcut sendPacket(DatagramPacket packet): call(DatagramSocket.send(DatagramPacket)) && args(packet); (c) Identificar las acciones, relativas al aspecto en cuesti´n, que ocurren antes y o despu´s de ese punto o momento. Por ejemplo, avisar que se est´ enviando un e a paquete antes de comenzar el env´ se˜ alar la finalizaci´n del env´ se˜ alar ıo, n o ıo, n que ha ocurrido una excepci´n. o 7 CACIC 2003 - RedUNCI 1166
    • (d) Codificar esas acciones como avisos “antes” y “despu´s”. Por ejemplo, el si- e guiente aviso “antes” avisa que se est´ por enviar un paquete. a before(DatagramPacket packet):sendPacket(packet){ logStream.println(quot;Sending Packet quot;); } (e) Mientras existan puntos o momentos de inter´s, ejecutar los pasos 2(a), 2(b), e 2(c), y 2(d). 3. Mientras existan aspectos en el sistema, ejecutar el paso 2. El c´digo en AspectJ que implementa el protocolo se encuentra detallado en [3]. o 3.3 Comparaci´n de ambas implementaciones o Al utilizar aspectos la ventaja m´s destacable es que el c´digo que implementa la funcio- a o nalidad b´sica es mucho m´s limpio y entendible. Otra ventaja importante es una mayor a a facilidad para realizar cambios y modificaciones, como tambi´n acciones para remover o e agregar comportamiento. Esto se debe a que todas las acciones de logging resultan encap- suladas en el aspecto, y son claramente identificadas. En cuanto al desarrollo, el mismo se vuelve mucho m´s intuitivo y natural, dada la naturaleza declarativa de los puntos de a enlace, y al comportamiento adicional que permite definir AspectJ. En la pr´xima secci´n se evalua la aplicaci´n del paradigma a trav´s de m´tricas orien- o o o e e tadas a aspectos que cuantifican los resultados de la utilizaci´n de la POA. o 4 M´tricas para POA e A fin de cuantificar los beneficios de la POA, y AspectJ se definen y se aplican m´tricas e orientadas a aspectos en el caso de estudio. Las m´tricas tradicionales no son de significa- e tiva utilidad aplicadas sobre programas basados en este nuevo paradigma. Esto se debe a que no incorporan en sus c´lculos el efecto de una programaci´n orientada a aspectos. Por a o lo tanto, en este trabajo se definen dos m´tricas orientadas a aspectos, las cuales incluyen e los conceptos relacionados al paradigma de aspectos, reflejando de una manera m´s fiel y a precisa el desempe˜ o de la POA. n En primer lugar se define la m´trica Beneficio POA, que mide cu´l es el beneficio e a de introducir aspectos. Para ello, define una relaci´n de esfuerzo de desarrollo entre una o implementaci´n sin considerar aspectos, y otra donde se aplica el paradigma. Est´ definida o a en funci´n de dos factores claves de un proyecto: el tama˜ o del producto, y el esfuerzo o n de desarrollo. Considera el tama˜ o de una implementaci´n sin y con aspectos, y pondera n o estos valores con un factor de desarrollo. Para esto ultimo, se tom´ en cuenta el factor ´ o de desarrollo propuesto por Rich Rice [7]. Este factor establece que para un sistema peque˜ o el tiempo de desarrollo promedio en Java es de 10 horas/programador, mientras n que en AspectJ es de 2 horas/programador. A fin de considerar el tama˜ o de ambas n implementaciones, se evalua el tama˜ o f´ n ısico de los archivos de las clases y del aspecto, medidos en Kb. La m´trica se define como un cociente entre los valores aplicados a ambas e 8 CACIC 2003 - RedUNCI 1167
    • implementaciones. Un valor de resultado mayor que uno significa un impacto positivo de la utilizaci´n de aspectos. La definici´n de la m´trica es o o e T ama˜ o sin Aspectos ∗ F actor de Desarrollo Java n Benef icio P OA = T ama˜ o con Aspectos ∗ F actor de Desarrollo AspectJ n donde T ama˜ o Con Aspectos = T ama˜ o F uncionalidad B´sica + T ama˜ o Aspecto n n a n Para aplicar esta m´trica a nuestro ejemplo, consideramos el tama˜ o f´ e n ısico de las clases especificados en la siguiente tabla. Clases Con aspectos Sin aspectos Tftpd 6,14 Kb 10,1 Kb TftpServerConnection 5,09 Kb 6,35 Kb TftpWriteConnection 8,49 Kb 12,1 Kb Aspect logging 8,30 Kb - Luego, T ama˜ o Sin Aspectos = (10, 1 + 6, 35 + 12, 1)Kb = 28, 55Kb n T ama˜ o Con Aspectos = T ama˜ o F uncionalidad B´sica + T ama˜ o Aspecto n n a n = (6, 14 + 5, 09 + 8, 49)Kb + 8, 30Kb = 19, 72Kb + 8, 30Kb = 28, 02Kb reemplazando estos valores en la f´rmula de la m´trica se obtiene o e 28, 55Kb ∗ 10hp 285, 5 Benef icio P OA = = = 5, 09 28, 02Kb ∗ 2hp 56, 04 Como ya se ha mencionado, la utilizaci´n de aspectos produce un c´digo de funciona- o o lidad b´sica m´s “puro”, debido a que el comportamiento de los conceptos entrecruzados a a queda encapsulado en los aspectos. Para definir el porcentaje de c´digo que se reduce al o introducir aspectos, se define la segunda m´trica, llamada Limpieza. La misma, mide el e porcentaje de c´digo que se depura de la funcionalidad b´sica al introducir aspectos. Uti- o a liza el tama˜ o de las clases, medido en Kb. La definici´n es como se detalla a continuaci´n n o o (T ama˜ o Sin Aspectos − T ama˜ o F uncionalidad B´sica) ∗ 100 n n a Limpieza = T ama˜ o Sin Aspectos n Aplicando esta m´trica en el caso de estudio, resulta el siguiente valor: e (28, 55 − 19, 72)Kb ∗ 100 Limpieza = = 30, 93 28, 55Kb 9 CACIC 2003 - RedUNCI 1168
    • Por ultimo, se compara el tama˜ o de las clases que implementan las funcionalidades b´sicas ´ n a de las dos alternativas, expresado en l´ ıneas de c´digo(LDC). o Clases Con aspectos Sin aspectos Tftpd 199 ldc 318 ldc TftpServerConnection 176 LDC 212 LDC TftpWriteConnection 339 LDC 471 LDC Tama˜ o total n 714 LDC 1001 LDC 5 Trabajos Relacionados R. Laddad [1], enumera algunas de las principales ventajas de la POA. En principio, ayuda eficazmente a superar los problemas causados por el C´digo Mezclado y C´digo o o Diseminado. En cuanto a la modularizaci´n, la POA logra separar cada concepto con o m´ınimo acoplamiento, resultando en implementaciones modularizadas a´ n en la presencia u de conceptos que se entrecruzan. Esto lleva a un c´digo m´s limpio, menos duplicado, o a m´s f´cil de entender y de mantener. A su vez la separaci´n de conceptos permite agregar aa o nuevos aspectos, modificar y / o remover aspectos existentes f´cilmente, lo que permite una a mejor evoluci´n, y mayor reusabilidad. Durante el dise˜ o, el desarrollador se ve beneficiado o n ya que puede retrasar las decisiones sobre requerimientos actuales o futuros, debido a que permite, luego, implementarlos separadamente e incluirlos autom´ticamente en el sistema. a Esto ultimo resuelve el dilema del arquitecto sobre cu´ntos recursos invertir en la etapa de ´ a dise˜ o, cu´ndo la cuesti´n planteada es “demasiado dise˜ o”. n a o n Las desventajas del paradigma surgen del hecho de que la POA est´ en su infancia. En el a an´lisis de Guezzi et.al.[12] sobre la POA se mencionan tres falencias. La primera remarca a posibles choques entre el c´digo funcional, expresado en el lenguaje base, y el c´digo de o o aspectos expresado en los lenguajes de aspectos. Usualmente, estos choques nacen de la necesidad de violar el encapsulamiento para implementar los diferentes aspectos, sabiendo de antemano el riesgo potencial que se corre al utilizar estas pr´cticas. La segunda es a la posibilidad de choques entre los aspectos. El ejemplo cl´sico es tener dos aspectos a que trabajan perfectamente por separado, pero al aplicarlos conjuntamente resultan en un comportamiento anormal. La tercera, trata con posibles choques entre el c´digo de aspectos o y los mecanismos del lenguaje. Uno de los ejemplos m´s conocidos de este problema es la a anomal´ de herencia [9]. Dentro del contexto de la POA, el t´rmino puede ser usado para ıa e indicar la dificultad de heredar el c´digo de un aspecto en la presencia de herencia. o Con respecto a m´tricas para el desarrollo orientado a aspectos, a nuestro entender e existen escasas publicaciones sobre el tema. Zhao [8] propone m´tricas espec´ e ıficas para cuantificar el flujo de control en software orientado a aspectos. Las mismas se pueden utilizar para medir la complejidad de un programa orientado a aspectos. 10 CACIC 2003 - RedUNCI 1169
    • 6 Conclusiones y Trabajo Futuro A partir de los resultados obtenidos en las m´tricas presentadas podemos concluir que la e utilizaci´n de aspectos fue ampliamente exitosa. Primero, la m´trica Beneficio POA arroj´ o e o el valor 5,09 que al ser mayor que 1 se traduce en un impacto positivo. Segundo, el valor 30,93 calculado por la m´trica Limpieza indica que el c´digo original se ha limpiado casi e o en un 31%. Es importante notar que la cantidad de l´ ıneas de c´digo de la funcionalidad o b´sica se redujo en 300 l´ a ıneas de c´digo, que representa el 30% del total, confirmando el o valor obtenido en la m´trica de Limpieza. e Por otra parte, es v´lido preguntarse cu´l es el costo de trabajar con AspectJ. Esta a a cuesti´n es lo que hace tan atractiva a la POA, y en particular a AspectJ, y la respuesta o es que el costo es m´ ınimo. Si el programador ya cuenta con conocimientos s´lidos eno Java, capacitarse en AspectJ es una tarea trivial, debido a que este ultimo lenguaje es una ´ extensi´n del primero. o Aprender a trabajar con aspectos en AspectJ es sumamente sencillo, dada la natura- leza declarativa de los mismos. Una caracter´ ıstica importante de los aspectos es que son f´cilmente “enchufados” y “ desenchufados” (plug-in, plug-out) a la funcionalidad b´sica. a a Esto le permite al programador ir experimentando con aspectos, sin tener que modificar la funcionalidad b´sica, resultando en un aprendizaje gradual y efectivo. Todo lo que hemos a experimentado y analizado, puede resumirse en una sola afirmaci´n, que establece por s´ o ı misma la importancia de este nuevo paradigma “con muy poco esfuerzo, se obtienen ga- nancias importantes en la calidad, no s´lo del producto final, sino tambi´n en el proceso o e que desarrolla el producto”. Los resultados encontrados en la bibliograf´ y los que hemos ıa, obtenido en este trabajo son m´s que prometedores, y nos hacen pensar que la POA es a una de las ramas con mayor futuro dentro de la Ingenier´ de Software. ıa En base a la experiencia lograda con el desarrollo del caso de estudio del presente tra- bajo, es posible agregar otras tres ventajas. En primer t´rmino, al separar la funcionalidad e b´sica de los aspectos, se aplica con mayor intensidad el principio de dividir y conquistar. a Tambi´n hay que destacar que el ambiente de desarrollo es un ambiente de N-dimensiones, e donde es posible implementar el sistema con las dimensiones que sean necesarias, y no en una unica dimensi´n “sobrecargada”. Por ultimo, la POA enfatiza el principio de m´ ´ o ´ ınimo acoplamiento y m´xima cohesi´n. a o Nuestro an´lisis, nos permite observar tambi´n, que los lenguajes orientados a aspectos a e actuales, no cuentan con mecanismos ling¨´ uısticos suficientemente poderosos. Estos meca- nismos son necesarios para respetar por completo todos los principios de dise˜ o, como por n ejemplo, el encapsulamiento. La POA es un nuevo paradigma que a´ n adolesce de madurez y formalidad. Debido a u esto, plantea nuevas l´ıneas de investigaci´n tales como: analizar c´mo aplicar aspectos en o o las otras etapas del ciclo de vida del software, en el an´lisis, en el dise˜ o, en el testing y a n en la documentaci´n; investigar sobre la formalizaci´n de los aspectos; observar c´mo es o o o la integraci´n de los aspectos con las aproximaciones, m´todos, herramientas, y procesos o e de desarrollo existentes; desarrollar herramientas orientadas a aspectos que respeten los principios de dise˜ o, entre otras. n Nuestro pr´ximo paso es investigar c´mo incluir aspectos en el dise˜ o de un sistema de o o n software. El dise˜ o es una parte cr´ n ıtica de cualquier proceso, y es necesario investigar la 11 CACIC 2003 - RedUNCI 1170
    • forma de incluir los aspectos durante esta etapa. La mayor´a de los trabajos de investigaci´n ı o relacionados, buscan maneras convenientes de extender UML, para que este lenguaje de dise˜ o sea capaz tambi´n de expresar aspectos. Debido a que UML es el lenguaje de dise˜ o n e n con mayor respaldo dentro de la Ingenier´ de Software, y es considerado como un est´ndar, ıa a buscaremos los medios para expresar aspectos en UML. Referencias [1] “I want my AOP”. Ramnivas Laddad. Part 1,2,3 from JavaWorld, Enero-Marzo-Abril 2002. [2] “Software Metrics”. Norman Fenton, Lawrence Pfleeger. PWS Publishing Company, 1997. [3] “Programaci´n Orientada a Aspectos: An´lisis del Paradigma”. Asteasuain Fernando, o a Bernardo Ezequiel Contreras. Tesis de Licenciatura en Ciencias de la Computaci´n. o Universidad Nacional del Sur, noviembre de 2002. [4] “Aspect-Oriented Programming”. Gregor Kickzales, John Lamping, Anurag Mendhe- kar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, John Irwin. Procee- dings, European Conference on Object-Oriented Programming (ECOOP), Finland. Springer-Verlag LNCS 1241. Junio 1997. [5] P´gina de Mark Benvenuto: http://www.cs.columbia.edu/˜markb/ a [6] P´gina de AspectJ: http://www.aspectcj.org a [7] “Untangling Code”. Claire Tristram. in the January/February 2001 issue of the Technology Review. [8] “Towards a Metric Suite for Aspect-Oriented Software”. Jianjun Zhao. Technical Report SE-136-25, Information Processing Society of Japan (IPSJ), Marzo 2002. [9] “Analysis of inheritance anomaly in object-oriented concurrent programming langua- ges”. S. Matsuoka, A. Yonezawa. in Research Directions in Concurrent Object- Oriented Programming (G. Agha, P.Wegner, and A. Yonezawa, eds.),pp. 107-150, Cambridge, MA: MIT Press, 1993. [10] Request For Comment 783 y 1350: The TFTP Protocol (Revision 2), junio 1981 - junio de 1982. http://www.ietf.org/ [11] “Getting Started with AspectJ”. Gregor Kickzales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, William G.Grisnold. Communications of the ACM (CACM) Vol. 44 Nro.10, Octubre 2001. [12] “Language Support for Evolvable Software: An Initial Assessment of Aspect-Oriented Programming”. Gianpaolo Cugola, Carlo Ghezzi, Mattia Monga. Proceedings of the International Workshop on the Principles of Software Evolution, IWPSE99, Julio 1999. 12 CACIC 2003 - RedUNCI 1171