SlideShare une entreprise Scribd logo
1  sur  12
Télécharger pour lire hors ligne
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

Contenu connexe

Tendances

CUADRO COMPARATIVO
CUADRO COMPARATIVOCUADRO COMPARATIVO
CUADRO COMPARATIVOChris023
 
Ingeniería del Software de Gestión. Tema 5
Ingeniería del Software de Gestión. Tema 5Ingeniería del Software de Gestión. Tema 5
Ingeniería del Software de Gestión. Tema 5Enrique Barreiro
 
3 tecnicas modernas programacion
3 tecnicas modernas programacion3 tecnicas modernas programacion
3 tecnicas modernas programacioncortezbfajardo
 
Ingeniería del Software de Gestión. Tema 1
Ingeniería del Software de Gestión. Tema 1Ingeniería del Software de Gestión. Tema 1
Ingeniería del Software de Gestión. Tema 1Enrique Barreiro
 
Fundamentos del diseño de software
Fundamentos del diseño de softwareFundamentos del diseño de software
Fundamentos del diseño de softwarejoelfinol
 
Arquitectura software capitulo i
Arquitectura software capitulo iArquitectura software capitulo i
Arquitectura software capitulo iCathy Guevara
 
Métricas orientadas a objeto
Métricas orientadas a objeto   Métricas orientadas a objeto
Métricas orientadas a objeto David Leon Sicilia
 
Ingeniería del Software de Gestión. Tema 2.
Ingeniería del Software de Gestión. Tema 2.Ingeniería del Software de Gestión. Tema 2.
Ingeniería del Software de Gestión. Tema 2.Enrique Barreiro
 
Técnicas de programación
Técnicas de programaciónTécnicas de programación
Técnicas de programaciónMaría Alvarez
 
Arquitectura software.taxonomias.negocio.001
Arquitectura software.taxonomias.negocio.001Arquitectura software.taxonomias.negocio.001
Arquitectura software.taxonomias.negocio.001Jose Emilio Labra Gayo
 
Libro tecnica de programacion
Libro tecnica de programacionLibro tecnica de programacion
Libro tecnica de programacionMarialix Quintero
 
Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Marta Silvia Tabares
 
Evolucion de la programacion
Evolucion de la programacionEvolucion de la programacion
Evolucion de la programacionRichy Quiñonez
 
Evolucion de la programacion
Evolucion de la programacionEvolucion de la programacion
Evolucion de la programacionOliver Marquez
 
Presentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchPresentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchdanielnp33
 

Tendances (18)

CUADRO COMPARATIVO
CUADRO COMPARATIVOCUADRO COMPARATIVO
CUADRO COMPARATIVO
 
Ingeniería del Software de Gestión. Tema 5
Ingeniería del Software de Gestión. Tema 5Ingeniería del Software de Gestión. Tema 5
Ingeniería del Software de Gestión. Tema 5
 
3 tecnicas modernas programacion
3 tecnicas modernas programacion3 tecnicas modernas programacion
3 tecnicas modernas programacion
 
Ingeniería del Software de Gestión. Tema 1
Ingeniería del Software de Gestión. Tema 1Ingeniería del Software de Gestión. Tema 1
Ingeniería del Software de Gestión. Tema 1
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Fundamentos del diseño de software
Fundamentos del diseño de softwareFundamentos del diseño de software
Fundamentos del diseño de software
 
Arquitectura software capitulo i
Arquitectura software capitulo iArquitectura software capitulo i
Arquitectura software capitulo i
 
Métricas orientadas a objeto
Métricas orientadas a objeto   Métricas orientadas a objeto
Métricas orientadas a objeto
 
Ingeniería del Software de Gestión. Tema 2.
Ingeniería del Software de Gestión. Tema 2.Ingeniería del Software de Gestión. Tema 2.
Ingeniería del Software de Gestión. Tema 2.
 
Técnicas de programación
Técnicas de programaciónTécnicas de programación
Técnicas de programación
 
Arquitectura software.taxonomias.negocio.001
Arquitectura software.taxonomias.negocio.001Arquitectura software.taxonomias.negocio.001
Arquitectura software.taxonomias.negocio.001
 
Libro tecnica de programacion
Libro tecnica de programacionLibro tecnica de programacion
Libro tecnica de programacion
 
Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4
 
Evolucion de la programacion
Evolucion de la programacionEvolucion de la programacion
Evolucion de la programacion
 
Evolucion de la programacion
Evolucion de la programacionEvolucion de la programacion
Evolucion de la programacion
 
La evolcion de la programacion
La evolcion de la programacionLa evolcion de la programacion
La evolcion de la programacion
 
Presentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchPresentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watch
 
Isabel teixeira
Isabel teixeiraIsabel teixeira
Isabel teixeira
 

En vedette

Aso’S Sweets
Aso’S SweetsAso’S Sweets
Aso’S Sweetsmuha
 
Skischansspringen
SkischansspringenSkischansspringen
Skischansspringennewiris
 
Informe de fin de año 2007, II Parte
Informe de fin de año 2007, II ParteInforme de fin de año 2007, II Parte
Informe de fin de año 2007, II ParteAbel Suing
 
Power Sexualidad Calliky[2]
Power Sexualidad Calliky[2]Power Sexualidad Calliky[2]
Power Sexualidad Calliky[2]laspsicope
 
有智慧的一段話
有智慧的一段話有智慧的一段話
有智慧的一段話honan4108
 
Prohibido Pablo Neruda
Prohibido Pablo NerudaProhibido Pablo Neruda
Prohibido Pablo NerudaJulio Mendoza
 

En vedette (9)

Introduction
IntroductionIntroduction
Introduction
 
Treshombres
TreshombresTreshombres
Treshombres
 
Aso’S Sweets
Aso’S SweetsAso’S Sweets
Aso’S Sweets
 
Skischansspringen
SkischansspringenSkischansspringen
Skischansspringen
 
Informe de fin de año 2007, II Parte
Informe de fin de año 2007, II ParteInforme de fin de año 2007, II Parte
Informe de fin de año 2007, II Parte
 
Power Sexualidad Calliky[2]
Power Sexualidad Calliky[2]Power Sexualidad Calliky[2]
Power Sexualidad Calliky[2]
 
有智慧的一段話
有智慧的一段話有智慧的一段話
有智慧的一段話
 
Prohibido Pablo Neruda
Prohibido Pablo NerudaProhibido Pablo Neruda
Prohibido Pablo Neruda
 
Capstone Pp
Capstone PpCapstone Pp
Capstone Pp
 

Similaire à Curso Aop01

Manual de Ingeniería de Software
Manual de Ingeniería de SoftwareManual de Ingeniería de Software
Manual de Ingeniería de SoftwareDavidHerrera295
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentesTensor
 
Fundamentos para el diseño de un software
Fundamentos para el diseño de un softwareFundamentos para el diseño de un software
Fundamentos para el diseño de un softwaressalzar
 
Presentacion diego
Presentacion diegoPresentacion diego
Presentacion diegodiegoching2
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructuradowaralivt
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructuradowaralivt
 
Tema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesTema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesGary Araujo Viscarra
 
¿Qué es la arquitectura de software?
¿Qué es la arquitectura de software?¿Qué es la arquitectura de software?
¿Qué es la arquitectura de software?Israel Rey
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de softwareandres Mora
 
Metodologia De Desarrollo De Software
Metodologia De Desarrollo De SoftwareMetodologia De Desarrollo De Software
Metodologia De Desarrollo De SoftwareMartin Penaloza
 
Metodologia rad
Metodologia radMetodologia rad
Metodologia radjuan198
 
Diseno Software
Diseno SoftwareDiseno Software
Diseno Softwarealfmuny
 
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116AlejandroCoronado26
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortellforwer1223
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software41b3r
 

Similaire à Curso Aop01 (20)

Manual de Ingeniería de Software
Manual de Ingeniería de SoftwareManual de Ingeniería de Software
Manual de Ingeniería de Software
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentes
 
Fundamentos para el diseño de un software
Fundamentos para el diseño de un softwareFundamentos para el diseño de un software
Fundamentos para el diseño de un software
 
Logo2
Logo2Logo2
Logo2
 
Presentacion diego
Presentacion diegoPresentacion diego
Presentacion diego
 
Presentacion MSF
Presentacion MSFPresentacion MSF
Presentacion MSF
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Desarrollo estructurado
Desarrollo estructuradoDesarrollo estructurado
Desarrollo estructurado
 
Tema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentesTema1 desarrollo de software basado en componentes
Tema1 desarrollo de software basado en componentes
 
¿Qué es la arquitectura de software?
¿Qué es la arquitectura de software?¿Qué es la arquitectura de software?
¿Qué es la arquitectura de software?
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Metodologia De Desarrollo De Software
Metodologia De Desarrollo De SoftwareMetodologia De Desarrollo De Software
Metodologia De Desarrollo De Software
 
Proyecto
ProyectoProyecto
Proyecto
 
Proyecto
ProyectoProyecto
Proyecto
 
Metodologia rad
Metodologia radMetodologia rad
Metodologia rad
 
Diseno Software
Diseno SoftwareDiseno Software
Diseno Software
 
Poa
PoaPoa
Poa
 
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116
Fundamentos básicos para el Diseño de Software - Alejandro Coronado 26776116
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortell
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software
 

Plus de AmistadLealtad

Plus de AmistadLealtad (7)

Proyecto De Tecnica De Programacioin I I
Proyecto De Tecnica De Programacioin  I IProyecto De Tecnica De Programacioin  I I
Proyecto De Tecnica De Programacioin I I
 
Programacionorientadaaaspectos
ProgramacionorientadaaaspectosProgramacionorientadaaaspectos
Programacionorientadaaaspectos
 
Poa Borrador
Poa BorradorPoa Borrador
Poa Borrador
 
Wp Aspect J
Wp Aspect JWp Aspect J
Wp Aspect J
 
P3 Componentes
P3 ComponentesP3 Componentes
P3 Componentes
 
Curso Aop
Curso AopCurso Aop
Curso Aop
 
Charla 2005 09 16
Charla 2005 09 16Charla 2005 09 16
Charla 2005 09 16
 

Curso Aop01

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. (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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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