artículo completo

LA ORIENTACIÓN A ASPECTOS EN LA INGENIERÍA DE REQUISITOS
Ing. Gisella Guzmán Mariluz
[email protected]
Resumen
La Ingeniería de Requisitos es una rama crítica de la Ingeniería de Software que
desde sus inicios ha sido ampliamente tratada como condición fundamental para crear
productos de calidad. Por otro lado, en el campo de la programación ha evolucionado
el paradigma orientado a aspectos para reducir la complejidad, mejorar la reutilización
y simplificar la evolución en el proceso de software. Esta situación pone en evidencia
la necesidad de tratar estos temas desde las fases tempranas del desarrollo. En este
artículo se da un una visión general de la orientación a aspectos como un enfoque no
convencional en el desarrollo de software. Asimismo, se presentan enfoques más
representativos de la ingeniería de requisitos orientada a aspectos que podrían ayudar
a resolver problemas que enfrentan los equipos de desarrollo durante las primeras
etapas para facilitar el trabajo en la programación orientado a aspectos.
1. Introducción
En el campo de la ingeniería de software han sido muchos los enfoques que se han
propuesto y utilizado para crear software de calidad. Recientemente está
evolucionando un nuevo paradigma y al igual que la orientación a objetos empezó
en el ámbito de la programación: La orientación a aspectos.
La orientación 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, tanto funcionales como no funcionales.
Realizar el proceso de identificación de intereses en la ingeniería de requisitos,
lleva a gestionar la complejidad del desarrollo de software mediante la separación
de las funcionalidades principales de la aplicación (base concerns) de otras partes
con un propósito específico y de corte transversal a la funcionalidad principal
(crosscutting concerns) tales como autenticación, rendimiento, gestión de memoria,
auditoria, la sincronización de procesos concurrentes, el manejo de errores, etc.
En este artículo, se describe brevemente enfoques más representativos de la
ingeniería de requisitos orientada a aspectos que han surgido en estos últimos
años.
Con el fin de entender el contexto de estos enfoques, en la siguiente sección se da
una visión general del desarrollo de software orientado a aspectos.
2. Desarrollo de software orientado a aspectos
2.1. Antecedentes
Los conceptos de orientación a aspectos nacieron en 1996, cuando Gregor
Kiczales propuso una nueva idea: La Programación Orientada a Aspectos
(POA) o Aspect Oriented Programming en su denominación inglesa. A partir de
entonces, la POA y otras técnicas y tecnologías, que se centraban en la
modularización del código que atraviesa varios componentes para realizar una
cierta función (crosscutting code), se agruparon bajo el nombre de Advanced
Separation of Concerns. Después de varios años, en 2002, se adoptó la
denominación actual Desarrollo de Software Orientado a Aspectos (DSOA)
para referirse a las técnicas y tecnologías que pretenden la modularización de
los crosscutting concerns a lo largo del ciclo de vida. Desde entonces, los
investigadores que trabajaban en torno a la orientación a aspectos comenzaron
a estudiar las relaciones entre aspectos así como las propiedades de la
composición aspectual.
Originalmente, la identificación, especificación e implementación de los
aspectos se realizaba en la fase de implementación, viéndose los
programadores en la necesidad de ser ellos los encargados de rediseñar el
sistema para evitar el código entrelazado (crosscutting code). En la actualidad,
la responsabilidad de identificación y especificación de aspectos se ha
desplazado a fases iniciales del ciclo de vida: durante la especificación de
requisitos y la arquitectura del software, dejando a los programadores la
responsabilidad exclusiva de su implementación.
En la siguiente figura se representa la implementación de una funcionalidad
básica basada en los lenguajes de procedimiento generalizado (LPG) versus
una implementación basada en POA.
Figura 1. Implementación LPG versus Implementación POA.
El enfoque OA ha demostrado ser una tecnología potente para manejar la
separación de propiedades. Esta separación permite la construcción de un
software mejor modularizado, facilitando la reutilización, el mantenimiento y la
evolución de los sistemas. El problema principal para la adopción de estas
técnicas en proyectos a gran escala es la falta de un proceso de desarrollo
claro. Por otra parte, una de las principales ventajas de las propuestas de
DSOA es que permiten a los desarrolladores reaccionar fácilmente ante los
cambios no previstos.
2.2. ¿Qué es un aspecto?
Una de las primeras definiciones que aparecieron del concepto de aspecto fue
publicada en 1995, y se describía de la siguiente manera: Un aspecto es una
unidad que se define en términos de información parcial de otras unidades.
La definición de aspecto ha evolucionado a lo largo del tiempo, pero con la que
se trabaja actualmente es la citada por Gregor Kiczales, quien expresa lo
siguiente: “Un aspecto es una unidad modular que se disemina por la
estructura de otras unidades funcionales. Los aspectos existen tanto en la
etapa de diseño como en la de implementación. Un aspecto de diseño es una
unidad modular del diseño que se entremezcla en la estructura de otras partes
del diseño. Un aspecto de programa o de código es una unidad modular del
programa que aparece en otras unidades modulares del programa.”
De manera más informal podemos decir que los aspectos son una clase
particular de intereses que representan la unidad básica de la POA, y pueden
definirse como las partes de una aplicación que describen las cuestiones
claves relacionadas con la semántica esencial o el rendimiento. También
pueden verse como los elementos que se diseminan por todo el código y que
son difíciles de describir localmente con respecto a otros componentes.
Los aspectos no son unidades funcionales en las que se pueda dividir un
sistema, sino propiedades que afectan al rendimiento o la semántica de los
componentes. Algunos ejemplos de aspectos son autenticación, rendimiento,
gestión de memoria, auditoria, la sincronización de procesos concurrentes, el
manejo de errores, etc.
3. Enfoques orientado a aspectos en la Ingeniería de Requisitos
Los enfoques que se describen a continuación tratan sobre el uso de aspectos en la
ingeniería de requisitos.
3.1. Theme/Doc
Theme/Doc es la primera fase del enfoque Theme que describe un proceso de
desarrollo orientado por temas. La aproximación se centra en el concepto de
tema que representa una pieza de funcionalidad, asunto o interés que se quiere
modelar de forma separada del sistema. Theme/Doc parte de una descripción
textual de los requisitos en la cual se realiza un análisis gramatical para
detectar las relaciones entre los requisitos y las acciones minor actions; a partir
de estas acciones se derivan las acciones de mayor granularidad major action
o asuntos que representan la solución de software y que entran al proceso de
diseño siguiendo las características de Theme/UML [1].
3.2. Requisitos y crosscutting concerns
Lars Rosenhainer en [2] se enfoca en la identificación de requisitos y
crosscutting concerns en documentos de requisitos ya existentes. Para
Rosenhainer un requisito es una clase especial de concern. Los requisitos que
atraviesan transversalmente a otros son referidos como requisitos crosscutting.
La expresión crosscutting concern es usada como un sinónimo para las
relaciones entre dos requisitos que está establecida por uno atravesando
transversalmente el otro. Sin embargo, no todas las dependencias de requisitos
son de naturaleza crosscutting.
3.3. Framewok orientado a aspectos
Isabel Brito en [3] propone un enfoque cuyo principal objetivo es desarrollar un
framework orientado a aspectos en el contexto de ingeniería de requerimientos.
Para lograrlo, necesita desarrollar un modelo que soporte la identificación de
concerns, desarrollar un lenguaje para especificar concerns, proponer un
método sistemático para manejar conflictos, identificar y mapear influencias de
aspectos en etapas de desarrollo posteriores para establecer trade-off antes de
que la arquitectura sea derivada, y por último desarrollar una herramienta
simple que soporte la especificación y composición de concerns.
Este modelo de ingeniería de requerimientos se compone de varias tareas, y a
su vez estas, se componen de subtareas. Estas tareas consisten en identificar
concerns del sistema, a partir del uso de documentos y catálogos existentes
(conteniendo terminología de requerimientos no funcionales), luego
especificarlos, es decir, asignar responsabilidades, prioridades, etc., la
siguiente tarea es modelar estos concerns en UML y la última es componer los
concerns, que tiene que ver con identificar match points (abstracciones de join
points en AspectJ), identificar crosscutting concerns y manejar conflictos.
3.4. Desarrollo de software orientado a aspectos con casos de uso
Ivar Jacobson trata la orientación a aspectos en todas las fases de la ingeniería
de software [4]. Este enfoque trata los requisitos funcionales desde los casos
de uso que representan la función básica del sistema (peer use cases). Los
requisitos no funcionales se representan en casos de uso que extienden un
caso de uso de infraestructura, el cual se parametriza al igual que el actor que
lo usa, los parámetros representan el comportamiento que se cruzará en la
funcionalidad de los casos de uso base. 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.
4. Conclusiones
En general, la utilización de aspectos en el proceso de desarrollo proporciona un
soporte avanzado para la separación de concerns introduciendo una nueva unidad
modular: Aspecto.
Lo que se espera es que en las universidades e instituciones académicas en el
contexto de la ingeniería de software aporten con el estudio y desarrollo de
proyectos de investigación para tratar los aspectos desde las fases tempranas.
Estos esfuerzos serán claves para que los egresados puedan adoptar prácticas
reales de la orientación a aspectos con un mejor entendimiento.
5. Bibliografía
1. E. Baniassad and S. Clarke. Theme: An approach for aspect oriented analysis
and design. En International Conference on Software Engineering, 2004.
2. L. Rosenhainer. Identifying Crosscutting concerns in Requirements
Specifications. Monday, October 25, 2004, Vancouver, Canadá.
3. I. Brito, Aspect-Oriented Requirements Engineering. Trabajo de tesis de Isabel
Brito, desarrollado en la Universidad de Nova de Lisboa bajo la supervisión de
la Doctora Ana Moreira.
4. Jacobson I. and Ng P. W. Aspect-oriented Software Development with Use
Cases. Addison Wesley Professional, 2005.