EL DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS SEGN IVAR JACOBSON Ing.

Gisella Guzmn Mariluz

gguzman@usmp.edu.pe

1. Introduccin Son muchos los intereses que un equipo de desarrollo de software debe fijar su atencin: entender el problema, entender su entorno, gestin del proyecto, equipo de desarrollo, aspectos tcnicos, entre otros. Los intereses referidos a aspectos tcnicos como seguridad, persistencia, presentacin, manejo de errores, etc. han dado origen al paradigma orientado a aspectos. El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificacin en los requisitos, los cuales son un cdigo disperso (scattered) y diseminado (tangled), que no se resuelven fcilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separacin de intereses (separation of concerns) de un sistema para obtener una mejor modularizacin, tal como se muestra en la figura 1.

Figura 1. Separacin de intereses Ivar Jaconson, un lder del pensamiento en el mundo del software donde ha hecho varias contribuciones decisivas, no poda faltar en el revolucionario camino del enfoque orientado a aspectos. En este sentido, Jacobson y su compaero de trabajo Pan-Wei Ng (en Ivar Jacobson Consulting - IJC) publicaron, en el ao 2005, el libro titulado Aspect-Oriented Software Development with Use Cases donde describen la extensin del Proceso Unificado para desarrollar software con aspectos. En este artculo se proporciona una breve descripcin de cada fase del desarrollo de software orientado a aspectos propuesto por los autores. Esta descripcin le permitir familiarizarse con trminos claves de este enfoque, invitndolo a adquirir el libro para una completa comprensin ya que ilustra un caso prctico de aplicacin.

2. Desarrollo de software orientado a aspectos El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una mejor abstraccin modular del sistema. Incluye las siguientes fases: Captura de requisitos Anlisis Diseo Implementacin Pruebas

La primera fase trata la separacin de intereses tanto los funcionales como los no funcionales; los requisitos funcionales son modelados con casos de uso que representan la funcin bsica del sistema y los requisitos no funcionales se representan con casos de uso de infraestructura. En el anlisis y el diseo los casos de uso se representan en una estructura de composicin que se identifica con el estereotipo <<use case slice>> y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementacin se genera el cdigo de las clases y aspectos. Por ltimo en las pruebas se disean las pruebas tanto para los casos de uso de la aplicacin como para los casos de uso slice. 2.1. Captura de requisitos En esta fase se identifican dos categoras de casos de uso: de aplicacin y de infraestructura. Los casos de uso de aplicacin describen las funcionalidades bsicas del sistema. Los casos de uso de infraestructura describen cmo el sistema agrega cualidades como facilidad de uso, confiabilidad, de rendimiento y de soporte para cada paso de un caso de uso de aplicacin.
<<extend>> Infraestructure use case 1 Use case <Use case Transaction> <<extend>> Infraestructure use case 2

Figura 2. Casos de uso de aplicacin y de infraestructura La primera actividad consiste en entender los intereses de los stakeholders. El resultado es obtener una lista de caractersticas del sistema la cual incluye requisitos funcionales y no funcionales. A continuacin, se capturan los casos de uso de la aplicacin. Esta actividad consiste en identificar actores y casos de usos a partir de los requisitos funcionales de la lista de caractersticas, y describir los casos de uso en las especificaciones de casos de uso contemplando posibles extensiones. La descripcin de los casos de uso ayudar a identificar intereses de corte transversal. En la ltima actividad se capturan los casos de uso de infraestructura como extensiones modulares a los casos de uso de aplicacin. Para ello, se revisa nuevamente la lista de caractersticas del sistema para identificar a los requisitos no funcionales que afectan a algn paso de los casos de uso de aplicacin, los cules sern tratados como casos de uso de transaccin (usecase transaction) si se tratan de requisitos de infraestructura para el sistema. Esta actividad termina con la descripcin de estos tipos de casos de uso en una especificacin contemplando tambin sus flujos alternativos.

2.2. Anlisis Durante el anlisis se identifica la estructura de los elementos del anlisis en trminos de capas, paquetes y clases (boundary, control y entity). Tambin se identifican las estructuras de caso de uso conformados por paquetes estereotipados con <<use-case slice>> y <<non-uc-specific slice>>. Los paquetes use-case slice y non-uc-specific slice son unidades modulares especficas y no especficas respectivamente que permiten organizar mucho mejor el sistema. Un use-case slice contiene elementos necesarios para un caso de uso especfico: una colaboracin, que describe la realizacin de un caso de uso; una o ms clases especficas, que son requeridas para la realizacin del caso de uso; y extensiones de clase especficas para un cierto aspecto. Un non-uc-specific slice contiene clases del dominio del problema que se usan en muchos casos de uso.

Application Layer Domain Layer

Figura 3. Estructura de elemento

<<non-uc-specific slice>>

<<extend>>

<<use case slice>>

<<extend>>
<<use case slice>>

Figura 4. Estructura de caso de uso

2.3. Diseo Aqu se incluyen actividades relacionadas a refinar las dos estructuras identificadas en el anlisis incluyendo detalles del ambiente de implementacin. Mientras que la estructura del modelo de anlisis es independiente de la plataforma (lenguajes de programacin y tecnologa), el modelo de diseo es especfico a una plataforma que ser utilizado en la implementacin.

El proceso de refinamiento consiste en refinar las clases con detalles de implementacin y refinar los casos de uso slice incluyendo aspectos y las extensiones de clases.

Figura 5. Modelando un use-case slice 2.4. Implementacin En esta etapa se genera el cdigo de las clases con un lenguaje de implementacin como JAVA. Asimismo, se codifican los aspectos en un lenguaje orientado a aspectos como AspectJ. 2.5. Pruebas Las pruebas se llevan a cabo desde los requisitos hasta la codificacin. Se disean pruebas para cada caso de uso y caso de uso slice. Por otro lado, se crean casos de prueba slice que se puedan remover al completar las pruebas. 3. Conclusiones La utilizacin de aspectos en el proceso de desarrollo de software proporciona un soporte avanzado para la separacin de intereses introduciendo una nueva forma de modularizar el sistema. El resultado de este enfoque es obtener un producto software ms fcil de mantener, extender y reutilizar. La mejor forma de entender los intereses de corte transversal durante el proceso de modelado es utilizando los mecanismos de extensin del Unified Modeling Language (UML), tal como lo hicieron los autores de este enfoque: en casos de uso, paquetes y clases. 4. Bibliografa Jacobson I. and Ng P. W. Aspect-oriented Software Development with Use Cases. Addison Wesley Professional, 2005.