Desarrollo de software orientado a aspectos

EL DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS SEGÚN IVAR JACOBSON
Ing. Gisella Guzmán Mariluz
pgisguzm@gmail.com

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 comoseguridad, 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 enfocaprincipalmente en la separación de intereses (separation of concerns) de un sistema para obtener una mejor modularización.

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 JacobsonConsulting - 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 conté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. 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ónque se identifica con el estereotipo 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 seidentifican 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.

La primera actividad consiste enentender 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 lasespecificaciones 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...