El desarrollo de software orientado a aspectos

1. EL DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS SEGÚN
IVAR JACOBSON
1. Introducción
Son muchos los intereses que un equipo de desarrollo de software debe fijar su
atención: entender el problema, entender su entorno, gestión del proyecto, equipo
de desarrollo, aspectos técnicos, entre otros. Los intereses referidos a aspectos
técnicos como seguridad, persistencia, presentación, 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 codificación en los requisitos, los cuales son un código disperso
(scattered) y diseminado (tangled), que no se resuelven fácilmente usando el
enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la
separación de intereses (separation of concerns) de un sistema para obtener una
mejor modularización, tal como se muestra en la figura 1.
Figura 1. Separación de intereses
Ivar Jaconson, un líder del pensamiento en el mundo del software donde ha hecho
varias contribuciones decisivas, no podía faltar en el revolucionario camino del
enfoque orientado a aspectos. En este sentido, Jacobson y su compañero de
trabajo Pan-Wei Ng (en Ivar Jacobson Consulting - IJC) publicaron, en el año 2005,
el libro titulado “Aspect-Oriented Software Development with Use Cases” donde
describen la extensión del Proceso Unificado para desarrollar software con
aspectos.
En este artículo se proporciona una breve descripción de cada fase del desarrollo
de software orientado a aspectos propuesto por los autores. Esta descripción le
permitirá familiarizarse con términos claves de este enfoque, invitándolo a adquirir
el libro para una completa comprensión ya que ilustra un caso práctico de
aplicación.

2. 2. Desarrollo de software orientado a aspectos
El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una
mejor abstracción modular del sistema. Incluye las siguientes fases:
- Captura de requisitos
- Análisis
- Diseño
- Implementación
- Pruebas
La primera fase trata la separación de intereses tanto los funcionales como los no
funcionales; los requisitos funcionales son modelados con casos de uso que
representan la función básica del sistema y los requisitos no funcionales se
representan con casos de uso de infraestructura. En el análisis y el diseño los
casos de uso se representan en una estructura de composición 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 implementación se genera el código de las clases y aspectos.
Por último en las pruebas se diseñan las pruebas tanto para los casos de uso de la
aplicación como para los casos de uso slice.
2.1. Captura de requisitos
En esta fase se identifican dos categorías de casos de uso: de aplicación y de
infraestructura. Los casos de uso de aplicación describen las funcionalidades
básicas del sistema. Los casos de uso de infraestructura describen cómo el
sistema agrega cualidades como facilidad de uso, confiabilidad, de rendimiento
y de soporte para cada paso de un caso de uso de aplicación.
Figura 2. Casos de uso de aplicación y de infraestructura
La primera actividad consiste en entender los intereses de los stakeholders. El
resultado es obtener una lista de características del sistema la cual incluye
requisitos funcionales y no funcionales.
A continuación, se capturan los casos de uso de la aplicación. Esta actividad
consiste en identificar actores y casos de usos a partir de los requisitos
funcionales de la lista de características, y describir los casos de uso en las
especificaciones de casos de uso contemplando posibles extensiones. La
descripción 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 aplicación. Para ello, se revisa
nuevamente la lista de características del sistema para identificar a los
requisitos no funcionales que afectan a algún paso de los casos de uso de
aplicación, los cuáles serán tratados como casos de uso de transacción (use-
case transaction) si se tratan de requisitos de infraestructura para el sistema.
Esta actividad termina con la descripción de estos tipos de casos de uso en
una especificación contemplando también sus flujos alternativos.
<Use case Transaction>
Use case
Infraestructure use case 1
Infraestructure use case 2
<<extend>>
<<extend>>

3. 2.2. Análisis
Durante el análisis se identifica la estructura de los elementos del análisis en
términos de capas, paquetes y clases (boundary, control y entity). También 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
específicas y no específicas respectivamente que permiten organizar mucho
mejor el sistema.
Un use-case slice contiene elementos necesarios para un caso de uso
específico: una colaboración, que describe la realización de un caso de uso;
una o más clases específicas, que son requeridas para la realización del caso
de uso; y extensiones de clase específicas para un cierto aspecto.
Un non-uc-specific slice contiene clases del dominio del problema que se usan
en muchos casos de uso.
Figura 3. Estructura de elemento
Figura 4. Estructura de caso de uso
2.3. Diseño
Aquí se incluyen actividades relacionadas a refinar las dos estructuras
identificadas en el análisis incluyendo detalles del ambiente de implementación.
Mientras que la estructura del modelo de análisis es independiente de la
plataforma (lenguajes de programación y tecnología), el modelo de diseño es
específico a una plataforma que será utilizado en la implementación.
Application
Layer
Domain
Layer
<<use case slice>>
<<use case slice>><<non-uc-specific
slice>>
<<extend>>
<<extend>>

4. El proceso de refinamiento consiste en refinar las clases con detalles de
implementación y refinar los casos de uso slice incluyendo aspectos y las
extensiones de clases.
Figura 5. Modelando un use-case slice
2.4. Implementación
En esta etapa se genera el código de las clases con un lenguaje de
implementación 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 codificación. Se
diseñan 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 utilización de aspectos en el proceso de desarrollo de software proporciona un
soporte avanzado para la separación de intereses introduciendo una nueva forma
de modularizar el sistema. El resultado de este enfoque es obtener un producto
software más fácil 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 extensión del Unified Modeling
Language (UML), tal como lo hicieron los autores de este enfoque: en casos de
uso, paquetes y clases.
4. Bibliografía
Jacobson I. and Ng P. W. Aspect-oriented Software Development with Use Cases.
Addison Wesley Professional, 2005.