ASPECT-ORIENTED SOFTWARE ENGINEERING: AN EXPERIENCE OF APPLICATION IN A HELP DESK SYSTEM

MARTA S. TABARES
Departamento de Informática, Escuela de Ingeniería de Antioquia, Envigado, pfmstabare@eia.edu.co

RAQUEL ANAYA
Escuela de Ingeniería, Departamento de Sistemas, Universidad EAFIT, Medellín

FERNANDO ARANGO
Escuela de Sistemas e Informática, Universidad Nacional de Colombia, Medellín

RESUMEN: La Ingeniería de Rrequisitos Orientada a Aspectos provee enfoques para la elicitación y especificación de los asuntos y asuntos transversales en etapas tempranas de desarrollo de software. Este artículo presenta un caso de estudio para evaluar un modelo de la separación multidimensional de asuntos orientados a aspectos. Con el caso de estudio, se revisan sus características para la elicitación, análisis y trazabilidad de requisitos, así como algunas limitaciones del modelo y cómo este puede ser adaptado al proceso de desarrollo. Además, planteamos un conjunto de argumentos que podrían promover el desarrollo y evolución de este modelo.

PALABRAS CLAVE: asuntos, separación de asuntos, asuntos transversales, requisitos funcionales, requisitos no funcionales, RF, RNF, ingeniería de requisitos, modelo de requisitos, aspectos tempranos, ingeniería de requisitos orientada a aspectos, DSOA.

ABSTRACT: Aspect-oriented Requirement Engineering provides approaches for eliciting and specifying the concerns and crosscutting concerns in the early stages of software development. In this paper, we present a case study in order to assess a model of the aspect-oriented multidimensional separation of concerns. With the case study, we review their features for elicitation, analysis and traceability of requirements, as well as some limitations of the model and how it can be adapted to the development process. Also, we discuss some issues that might endorse the development and evolution of this model.

KEY WORDS: concerns, separation of concerns, crosscutting concerns, functional requirement, non-functional requirements, FR, NFR, requirement model, requirement engineering, early aspects, aspect-oriented requirement engineering, AORE.

1. INTRODUCCIÓN

La separación de asuntos (separation of concerns) ha sido tratada ampliamente en la ingeniería de software y específicamente por la ingeniería de requisitos. Está orientada hacia la descomposición de los dominios del problema y de la solución, con el fin de reducir la complejidad, eliminar fallas de interpretación, mejorar la relación entre usuarios y

desarrolladores, y estructurar sistemas complejos a través de subsistemas, módulos o elementos simples de una forma más natural [1, 2].Para soportar dicha separación, diferentes enfoques de ingeniería de requisitos han creado modelos que son considerados buenas prácticas para la elicitación y análisis de los requisitos [3, 4, 5, 6, 7]. Los requisitos pueden ser separados de acuerdo a diferentes criterios; generalmente,

Es posible también lograr otro tipo de separación identificando los requisitos que cruzan a otros; estos son llamados asuntos transversales (crosscutting concerns). Comúnmente son difíciles de factorizar y soportar en módulos separados ya que se encuentran dispersos (scattering) o enmarañados (tangling) en diferentes asuntos o requisitos del sistema. Los requisitos más comunes que tienen esta naturaleza transversal son los que representan atributos de calidad del sistema. Por ejemplo, los requisitos asociados al asunto (concern) de “seguridad”, la mayoría de veces no son elicitados en etapas tempranas o son descritos de forma solapada en los requisitos funcionales y consecuentemente este asunto no logra ser separado fácilmente en una clase o método en posteriores fases del ciclo de vida.

La separación de este tipo de asuntos es tratada por el Desarrollo de Software Orientado a Aspectos (AOSD – Aspect Oriented Software Development, www.aosd.net). Esta disciplina nace inicialmente como modelo de programación y rápidamente se percibe su potencialidad como enfoque útil en las fases tempranas del desarrollo [8, 9, 10, 11]. Es asi como surgen diferentes aproximaciones orientadas a aspectos que apoyan la elicitación y análisis de requisitos de software [14] y se constituye la Ingeniería de Requisitos Orientada a Aspectos (AORE - Aspect oriented Requirement Engineering, www.early-aspects.net).

El objetivo a lograr en este artículo es evaluar, por medio de un caso de estudio, el enfoque de la separación multidimensional de asuntos orientados a aspectos [12]. Esta experiencia permitirá divulgar sus características más relevantes de elicitación, análisis y trazabilidad de requisitos, sus limitaciones y las posibilidades de adaptación y uso en el proceso de desarrollo de software.

El artículo está estructurado de la siguiente forma: Sección 2 describe las bases teóricas del modelo. Sección 3 presenta el análisis del caso de estudio desde la perspectiva del modelo. Finalmente en la sección 4 se presentan conclusiones y trabajos futuros.

2. MODELO DE INGENIERÍA DE REQUISITOS ORIENTADO A ASPECTOS AORE

AORE es un modelo para el tratamiento de requisitos que enfatiza el tratamiento de intereses transversales[11, 12]. Este modelo usa la técnica de PREview basada en viewpoints con un mecanismo de composición basado en XML (bajo la herramienta ARCaDe). Un asunto es definido como un conjunto coherente de requisitos; los asuntos transversales son identificables en matrices donde es posible establecer cuándo algunos de sus requisitos influencian de manera positiva (colabora) o afectan de manera negativa (restringe) otros asuntos. La aproximación está orientada principalmente a:

• Identificar, separar y componer asuntos transversales.
• Soportar el establecimiento de compen-saciones (trade-off) tempranas entre asuntos transversales y requisitos que se sobreponen .
]]> Negociar y tomar decisiones entre grupos de participantes (stakeholders).

La aproximación es refinada por Moreira et al. en [13] y adaptada desde una perspectiva multidimensional para tratar los asuntos en un “espacio de asuntos” de forma uniforme sin importar la naturaleza de sus requisitos, funcionales o no funcionales. Posteriormente, el modelo es soportado por PROBE, un framework para verificar con lógica temporal las reglas de composición [18] (ver Figura 1).

Figura 1: Un esquema conceptual de la aproximación AORE
Figure 1: A conceptual schema of the AORE approach

1. Identificar y especificar asuntos. Para esta actividad se utilizan técnicas de separación de requisitos como: viewpoints [3], casos de usos [4], y orientación a objetivos [5], entre otras. Su especificación es realizada en XML.

2. Identificar relaciones de grano grueso entre asuntos. Se buscan las posibles influencias entre los asuntos. Estos asuntos son relacionados entre sí en una matriz.

3. Especificar las proyecciones de los asuntos usando reglas de composición. Se especifican las relaciones entre los asuntos con base en las influencias encontradas entre los requisitos. Esta especificación (XML) se realiza a través de reglas de composición.

4. Manejo de conflictos entre asuntos. Actividad conformada por un conjunto de acciones que llevan a la solución de conflictos ocasionados por las contribuciones entre asuntos.

• Influencia: indica en cuales etapas del ciclo de vida afectarán los asuntos; son particulares a cada proyecto o son determinadas por los desarrolladores.
• Mapeo: indica los artefactos en los cuales serán correlacionados los asuntos especificados:
  • Función: cuando el asunto es posible relacionarlo a nivel de diseño como una clase estándar (o un conjunto de clases) que debe mantener el control de la relación con otras clases.
  • Decisión: cuando el asunto es tenido en cuenta sólo para la toma de decisiones en cualquier etapa del ciclo de vida.
  • Aspecto: cuando las propiedades de un asunto no pueden ser encapsuladas en una clase sencilla y estas propiedades podrían estar dispersas por diferentes clases del núcleo del sistema.

Figura 2: Modelo de ingeniería de requisitos orientado al tratamiento uniforme de asuntos [11-13]
Figure 2: Concern-oriented requirement engineering model [11-13]

Las reglas de composición son especificadas para cada asunto (en XML) como intersecciones composicionales que permiten identificar puntos potenciales de compensación (trade-off) [12]. Las reglas están compuestas por los requisitos de cada asunto (requirement concern), las restricciones con la acción y el operador de tejido correspondiente (constraint action - operator) y la acción de resultado (Outcome action). Esta última acción toma gran importancia en la composición, ya que determinará la acción de salida al realizar el tejido, ya sea por realización satisfactoria de la regla o porque dicha regla satisface otro asunto.

Las restricciones de acción definidas en [12 - (Tabla 1)] especifican el modo en que un requisito puede afectar a otro con el que se relaciona. Así, es posible establecer las condiciones asociadas al comportamiento que será adicionado en el momento del tejido. Algunas de las restricciones de acción definidas son: reforce (reforzar), usada para imponer condición adicional sobre un conjunto de asuntos; ensure (asegurar), usada para determinar que una condición para un conjunto de asuntos existentes; provide (proveer), usada para especificar características adicionales a ser incorporadas en un conjunto de asuntos; affect (afecta), usado para especificar que un conjunto de requisitos de un asunto alterará el estado de otro.

Los operadores definidos en [12 - (Tabla 2)], permiten establecer la condición de evento, es decir “el cuándo” se hará el tejido. La diversidad de operadores lleva a reconocer todos los posibles estados de temporalidad a los cuales un asunto estará asociado en el momento del tejido. Algunos de los operadores definidos son: during (durante), describe el intervalo temporal en el cual un conjunto de requisitos están siendo satisfechos; on (sobre), describe el punto temporal después que un conjunto de requisitos ha sido satisfecho; and, or, xor (y, o, o exclusivo), ayudan a la conjunción y disyunción de requisitos de asuntos.

Los operadores de resultados [12 - (Tabla 3)], permiten representar los resultados del tejido hecho entre asuntos.

3. DESARROLLO DEL CASO DE ESTUDIO

A través del caso de estudio analizamos la aplicabilidad de la aproximación AORE, sus características de elicitación, análisis y trazabilidad de requisitos. De igual forma, en cada actividad hacemos un análisis de sus limitaciones y posibilidades de adaptación y uso en el proceso de desarrollo.

3.1 Descripción General Del Problema
El problema corresponde a un desarrollo orientado a objetos que se localiza en el Departamento de Mantenimiento de una empresa [15]. Su función es dar ayuda en línea a solicitudes de servicios de mantenimiento de edificios. El usuario afectado por el daño debe diligenciar una solicitud en la cual hace una descripción del problema; esta podrá ser ingresada a cualquier hora del día y cualquier día de la semana. Un empleado del área de mantenimiento la recibe y valida; si está correcta, programa los técnicos para la atención del servicio en una agenda de servicios.

Para la elicitación de los asuntos se tuvieron en cuenta artefactos como el discurso general del problema, diagramas de procesos y casos de uso. A continuación se muestra el desarrollo del caso de estudio en cada uno de los pasos indicados por el proceso del modelo.

Los requisitos deben ser agrupados de acuerdo al contexto funcional determinado por cada uno de los asunto. Para lograr esto, realizamos varios refinamientos hasta conseguir las agrupaciones correspondientes.

Los siguientes asuntos fueron identificados:

• Solicitudes: Diligenciar y verificar información relacionada con solicitudes de servicio. Inicia el proceso de atención.
• Servicios: Manejar los servicios pendientes; asignación de técnicos, actualización de la agenda y generación de reporte de servicios.
• Gestión de usuarios: Administrar usuarios, roles y asignar privilegios a éstos.
• Seguridad: Validar el acceso de los usuarios, mostrar información de acuerdo a roles establecidos y garantizar la integridad de los datos.
• Disponibilidad: Habilitar disponibilidad del sistema 24x7.
]]> Compatibilidad: Interactuar con otros sistemas existentes.
• Multiacceso: Soportar múltiples usuarios concurrentes.
• Soporte al sistema: Mantener el sistema operativo, la base de datos, la aplicación y otros dispositivos lógicos y físicos que sean necesarios.
• Sistemas externos: Proveer desde sistemas externos información al sistema de ayuda, para la validación de usuarios, activos y presupuesto.
• Estadísticas de Gestión: Entregar estadísticas de las solicitudes, servicios y funcionalidades del mismo.
• Contratos: Permitir la gestión de la contratación de un servicio con una empresa externa.

La Figura 3(a) muestra la especificación del asunto “Servicios” y en la Figura 3(b) el asunto “Estadísticas de Gestión”, ambos con sus correspondientes requisitos. Cada asunto y requisito es identificado; si un requisito necesita ser subdivido en varios requisitos, el requisito más detallado se identifica conservando el identificador del padre al cual se le adiciona un nuevo número para formar el identificador del requisito hijo.

Figura 3: (a) Requisitos del asunto “Servicios”, (b) Requisitos asunto “Estadísticas de Gestión”
Figure 3: (a) Requirements of the “Services” concern, (b) Requirements of the “Management statistics” concern

Tabla 1. Especificacion del asunto Servicios
Table 1. Specification of the “Services” concern

Tabla 2. Especificacion del asunto “Soporte al sistema”
Table 2. Specification of “System Support” concern

Análisis de la actividad
La elicitación de requisitos es una actividad compleja que depende de las interacciones entre los participantes. Para el desarrollo de este caso de estudio, sólo contamos con los documentos de requisitos que habían sido obtenidos con anterioridad. En la tarea de agrupar los requisitos en asuntos se encontraron las siguientes dificultades: (a) algunos requisitos estaban descritos de forma inexacta o confusa, lo que ocacionó que fueran desechados o agrupados en asuntos diferentes de su función real; (b) algunos requisitos, si bien estaban descritos correctamente, estos eran agrupables en varios asuntos a la vez (superposición temprana); (c) otros requisitos eran no agrupables en ningún asunto, lo que significaba que faltaban asuntos por definir o se presentaban errores en la descripción del problema o en la elicitación del requisito. También es posible encontrar asuntos sin requisitos asociados; generalmente son requisitos del sistema que ellos mismos constituyen un asunto.

En general, esta actividad es de alto riesgo y requiere de mucho tiempo ya que es necesario llegar a un buen nivel de descripción de los requisitos. Es importante resaltar que los analistas deben procurar documentación complementaria que les permita disminuir factores de riesgo como la ambigüedad y la incompletitud de los requisitos. Algunas de estas podrían ser, catálogos de requisitos no funcionales, repositorio de requisitos funcionales, catálogos de reglas de negocio y de asuntos transversales, entre otros [6, 16].

Por ejemplo, en la Tabla 1 el asunto “Servicios” es influenciado positivamente por el asunto “Solicitudes”. Esto quiere decir que los requisitos del asunto “Servicios” se satisfacen si se cumplen los requisitos del asunto “Solicitudes”. De forma similar, podemos hacer la siguiente interpretación en la Tabla 2, el asunto “Soporte al Sistema” es influenciado positivamente por el asunto “Seguridad” porque si se satisfacen algunos de los requisitos del asunto “Seguridad” se garantiza que se cumplen algunos de los requisitos del asunto “Soporte al Sistema”. Por ejemplo, si se cumple el requisito 1 del asunto “Seguridad” (permitir el acceso al sistema de ayuda solamente a usuarios autorizados de acuerdo a roles establecidos), incluyendo su hijo (mostrar la información a los usuarios de acuerdo a los roles establecidos), se satisface el requisito 1 del asuntno “Soporte al Sistema” (dar soporte al hardware y al sistema operativo donde corre la aplicación del sistema de ayuda).

En la Tabla 3, se proyecta cada uno de los asuntos en una relación muchos a muchos. La Tabla se lee de fila a columna, por ejemplo: el asunto Solicitudes (So) influencia sobre los asuntos Servicios (Se),Estadísticas de Gestión (Est) y Contratos(Con).

Desde una vista de grano grueso, la influencia de un asunto en otro permite que los analistas tengan en cuenta situaciones importantes tales como: qué asuntos deberán ser tratados bajo reglas de composición, el nivel de complejidad del sistema, el nivel de trazado de los asuntos transversales candidatos y posibles conflictos entre los participantes.

Tabla 3. Matriz de asuntos relacionados
Table 3. Matrix relating concerns

Análisis de la actividad
Aunque identificar las relaciones entre asuntos de grano grueso requiere de un trabajo exhaustivo, en este proceso encontramos las siguientes utilidades para la elicitación de requisitos:

• Tratar los requisitos funcionales y no funcionales bajo criterios similares de funcionalidad del sistema. Es común dejar las tareas de elicitación de requisitos no funcionales a los arquitectos, pero realmente quien tiene las necesidades exactas sobre el sistema es el usuario. Por ejemplo, el requisito de seguridad para el caso de estudio, “permitir el acceso al sistema de ayuda solamente a usuarios autorizadas de acuerdo a roles establecidos”, no es una necesidad del desarrollador sino del usuario. Posteriormente, el arquitecto identificará que atributo de calidad cruzará dicho requisito para transformalo en un componente del sistema que podrán satisfacer dicha necesidad o en un lineamiento de arquitectura. Igualmente este tipo de requisitos proveerán a los desarrolladore criterios de pruebas muy importantes.
• Verificar la calidad semántica de los requisitos cuando se está en la tarea de agruparlos. Es una tarea extensa y dispendiosa, pero trae beneficios para la transformación de los requisitos en arte-factos o componentes de software en etapas posteriores.
• Establecer la influencia entre asuntos permite realizar control del trazado vertical (dependencia entre requisitos). Esta tarea proporciona características de fiabilidad, exactitud y permite disminuir la complejidad en los modelos de requisitos y casos de uso que determinen la arquitectura del sistema.
]]> Identificar los asuntos transversales conduce al aseguramiento de una buena arquitectura del sistema. El hallar solapamiento temprano tanto de requisitos funcionales como no funcionales, orienta la identificación de los asuntos transversales. Dos criterios para su identificación pueden ser: (a) asuntos con funcionalidad independiente que pueden contribuir con información adicional a otros asuntos; en este caso podríamos hablar de asuntos como “Seguridad” o “Estadísticas de Gestión”. (b) asuntos con funcionalidad solapada pero que no es posible identificarlos de forma independiente de los asuntos sobre los cuales contribuye (posible dependencia entre requisitos funcionales).

Para crear las reglas de composición nos basamos en el solapamiento temprano inicialmente detectado al nivel de requisitos y registrado al nivel de grano grueso en la Tabla 3. Esta parte del proceso corresponde a lo que se denomina intersección composicional. De acuerdo a la experiencia obtenida, la composición puede ser lograda de forma organizada y ágil a través de los siguientes pasos:

1. Identificar de la matriz de asuntos relacionados, los asuntos fuentes (filas) y asuntos destino (columnas).
2. Para cada uno de los requisitos del asunto fuente verificar la multiplicidad de la relación con los requisitos del asunto destino (ver Figura 4). Los requisitos del asunto fuente que tengan una multiplicidad de 1:n (uno a muchos) con requisitos del asunto destino se les asignará la restricción de acción y el operador correspondiente. Este es un caso de requisito diseminado (scattering) en otros requisitos, e.g. R_A1.
3. Para cada uno de los requisitos del asunto destino verificar la multiplicidad de la relación con los requisitos del asunto fuente. Los requisitos del asunto destino que tengan una multiplicidad de 1:n con requisitos del asunto fuente se le asigna la restricción de acción y el operador correspondiente a cada relación o conjunto de relaciones. Este es un caso de requisito mezclado (tangling) en otros requisitos s, e.g. R_B4.
4. Cuando algún requisito de un asunto destino participa de una multiplicidad n:m (muchos a muchos) se puede considerar que el asunto/requisito es tranversal (candidato) al asunto/requisitos fuente, e.g. R_B4.

Figura 4: Relación de asuntos y requisitos
Figure 4: Relationship of the concerns and requirements

Por cada composición hallada, se debe determinar qué comportamiento preestablecido o adicional será involucrado. El uso de las restricciones de acción no está asociado a algunos asuntos específicos y son definidas genéricamente; estas ayudarán a que el analista entienda todas las posibles variables en el tejido de los asuntos en etapas posteriores. Para el uso de las restricciones de acción y los operadores hemos creado los siguientes criterios de uso:

• Si al realizar la composición es necesario que un asunto destino “adicione” com-portamiento en otro conjunto de asuntos origen, se utilizan restricciones de acción tales como enforce, provide y affect. El asunto que provee la información adicional en la composición bajo este tipo de restricciones de acción es un asunto transversal candidato.
• La acción excluir actúa como una excepción (exception) que puede ocurrir en un asunto fuente cuando un requisito agrupado en dicho asunto no será ejecutado en el momento de la composición. Ésta y las restricciones de applied y ensure, pueden orientar a la declaración de una acción más genérica llamada exception que permita manejar otro tipo de excepciones de tiempo, satisfacción de cumplimiento de la regla y de una composición, entre otras.
]]> Los operadores son usados según la temporalidad y las secuencias de ejecución de los asuntos en el momento del tejido. Estos pueden ser asociados a las restricciones de acción según sea la forma como pueden ser controladas las actividades de los procesos de negocio del problema tratado.

Para ilustrar el caso de estudio, en la Tabla 4 se muestran dos de las reglas de composición elaboradas para los asuntos “Servicios” y “Disponibilidad”. El buen entendimiento del uso de operadores en estas reglas es fundamental para dar significado a la composición ya que estos son la restricción o condición de la regla.

Análisis de la actividad

El análisis de la composición de requisitos no es un tema muy tratado por los modelos actuales de ingeniería de requisitos. No obstante, el uso de reglas de composición en etapas tempranas provee algunos de los siguientes beneficios:

• Diferenciar entre dependencia de requisitos y composición de requisitos.
• Identificar, con mayor certeza, en la especificación de los casos de uso, elementos tales como: precondiciones, postcondiciones, puntos de extensión y flujos alternos; además de relaciones tipo <<extend>> e <<include>>.
• Detectar y evitar futuros acoplamientos entre clases a partir de la correcta definición de las reglas de composición.
• Establecer relaciones de trazado que puedan conservar el sentido de la composición desde etapas tempranas.

3.5 Manejo De Conflictos
El manejo de conflictos que propone la aproximación se basa en el análisis de compensaciones. Los pasos a seguir para la identificación y posterior administración de conflictos son:

1. Refinar la matriz de asuntos relacionados (Tabla 3), indicando en cada interrelación el tipo de contribución definitiva que un asunto ejerce sobre otro (ver Tabla 5). Por ejemplo, el asunto “Servicios” contribuye positivamente con el asunto “Estadísticas de Gestión” y el asunto “Soporte al Sistema” restringe (contribuye negativamente) el asunto “Disponibilidad”.
2. Doblar la matriz de contribución sobre su diagonal; ésta actividad permite observar el efecto acumulativo para las situaciones donde dos asuntos influyen entre sí de manera recíproca (ver Tabla 6). Después de un análisis detallado, si al doblar la matriz se presenta más de un signo en la misma casilla (denotado en oscuro en la matriz) los signos de la contribución deben ser iguales. Si la correspondencia es de signos contrarios se debe revisar la especificación de los requisitos de los asuntos en conflicto, y se debe tomar alguna de las siguientes decisiones:
   • Redactar de nuevo el (los) requisito(s) de uno o ambos asuntos.
   • Subdividir el requisito existente, para restringir su generalidad.
   • Verificar que el requisito sí pertenezca al asunto en cuestión.
   • Eliminar o invalidar el requisito.
   ]]>

Tabla 5. Matriz de contribución
Table 5. Contribution matrix

Tabla 6. Matriz de contribución de asuntos doblada sobre su diagonal
Table 6. The concern contribution matrix folded along its diagonal

Como se observa en la matriz de contribución doblada, los asuntos “Disponibilidad” y “Soporte al Sistema” se influencian de forma recíproca y de manera negativa. Esto puede significar que, cuando se satisfacen los requisitos de “Soporte al Sistema” se penaliza el cumplimiento de algunos de los requisitos de “Disponibilidad”, y al aumentar la “Disponibilidad” del sistema el tiempo dedicado al soporte se ve afectado, disminuyendo la posibilidad del cumplimiento de los requisitos del asunto “Soporte al Sistema”. Lo contrario ocurre entre “Seguridad” y “Soporte al Sistema”, para éste caso se garantiza que los requisitos de “Soporte al Sistema” se cumplan; es decir, si se puede brindar “Seguridad” al sistema de la solución y al resto de sistemas que interactúan con éste, el soporte a dicho sistema es menos traumático y difícil.

El último paso para la negociación consiste en darle un peso a las contribuciones que tienen signo negativo en la matriz. La persistencia del conflicto debe ser solucionado según el nivel de importancias que tiene para los participantes. El peso es un número real entre 0 y 1, y representa la prioridad del asunto fuente en relación con el asunto destino. Muy importante toma valores entre (0.8 - 1], importante (0.5 – 0.8], promedio (0.3 – 0.5], no tan importante (0.1 – 0.3], sin importancia [0, - 0.1] (ver Tabla 7).

En la matriz se observa que no se presenta ningún conflicto entre los asuntos, pues no hay más de una contribución negativa en diferentes filas en una misma columna. A la influencia bidireccional negativa entre los asuntos de “Disponibilidad” y “Soporte al Sistema” se le asignó un peso de 0.7 producto de la negociación entre los participantes del proyecto. Se consideró que ambos asuntos para el presente sistema se encuentran en la categoría de importante.

Tabla 7. Matriz doblada con ponderación en las contribuciones negativas ]]> Table 7. Weighted (folded) negative contribution matrix

Análisis de la actividad

• En esta parte, el nivel de refinamiento y entendimiento de los requisitos es mayor lo que permite detectar y corregir errores de la elicitación de requisitos de los pasos anteriores. Inclusive, es posible llegar a un conjunto de requisitos que puedan ser agrupados en un nuevo asunto de grano grueso.
• Esta buena práctica puede compensar conflictos proporcionados por situaciones tales como: carencia de definición o desconocimiento de los procesos de negocio que acompañan los requisitos elicitados, definición errada del alcance del proyecto, especificación de requisitos no controlada y ausencia del dimensionamiento de los riesgos, entre otras.
• Valorar la importancia del conflicto ayuda a los participantes a reevaluar la verdadera necesidad y prioridad de los requisitos solicitados.

Esta es una de las tareas más difíciles del modelo ya que la aproximación no provee criterios explícitos para determinar el tipo de mapeo y su influencia. Para lograr esto nosotros usamos los criterios creados en la actividad 3.4.

Tabla 8. Dimensiones de los asuntos
Table 8. Concern dimensions

También, la influencia y el mapeo podrán ser usados como vínculos de trazado con restricción identificada que permitirá controlar los asuntos y sus requisitos tanto hacia delante como hacia atrás en el ciclo de vida de desarrollo.

4. CONCLUSIONES Y TRABAJOS FUTURO

Una vez hemos realizado el aporte crítico en cada una de las actividades del modelo AORE, presentamos algunas conclusiones generales y trabajos futuros que pueden orientar el uso de esta aproximación en otras técnicas de ingeniería de requisitos.

La capacidad de AORE resalta la identificación y análsis de asuntos/requisitos transversales. Esta práctica no es usual o al menos no evidente cuando se trabaja bajo procesos de desarrollo de software conocidos, como el proceso unificado (RUP – Rational Unified Process). Aunque al principio parece difícil y costosa su manipulación, el modelo provee características para: (a) disminuir la complejidad de desarrollo; (b) disminuir el riesgo en el diseño e implementación a partir de la solución de conflictos; (c) controlar y soportar de la trazabilidad de requisitos al poder inferir vínculos de trazado identificando su influencia y mapeo en posteriores artefactos o fases del ciclo de vida. Estas características abren la posibilidad de orientar el manejo de requisitos en nuevos dominios de la ingeniería de software, como MDA (Model-Driven Architecture) [21], ya que sería posible controlar la multiplicidad de interelación de los asuntos/requisitos fuente y destino en modelos CIM (Computation independent model) y su posterior transformación en modelos PIM (platform independent model) y PSM (platform specific model).

El modelo hace un aporte muy importante en relación a la separación y composición de asuntos. RUP dirige la descomposición del problema hacia la funcionalidad (casos de uso) que debe ser entregada como producto de software. Por la orientación de los casos de uso, los analistas limitan su especificación a la descripción de requisitos funcionales. Comúnmente, atributos de calidad, (conocidos también como requisitos no funcionales), y reglas de negocio que han sido elicitados, y que podrían ser transversales a muchas funcionalidades, son tratados por los arquitectos en fases avanzadas del ciclo de vida.

Realizando una separación orientada por AORE, todo asunto del sistema podría tratarse de manera homogéna en un espacio multidimensional de concerns. Por ejemplo, Jacobson y Ng en [19], identifican asuntos transversales procedentes de los requisitos no funcionales o reglas de negocio representados en casos de uso extendidos. Sousa et al. [20], presentan casos de uso y relaciones estereotipadas para representarlos y pueda darse una separación plena de los asuntos que conciernen a muchos otros sin afectar las funcionalidades básicas.

La composición en RUP está dirigida a la agrupación de elementos de modelo (casos de uso y otros) en paquetes que determinen la arquitectura del sistema y guíen las iteraciones que permitirán la planificación y estimación del costo de sus productos. La elaboración de reglas de composición orientada por AORE puede ser obtenida desde la especificación de cada caso de uso. Es decir, elementos tales como precondiciones, postcondiciones y puntos de extensión podrían proveer las restricciones de acción, los operadores y las acciones que deberán ejecutarse una vez se efectue la composición con los flujos básicos, alternos y subflujos. Así, desde etapas tempranas, los arquitectos tendrán elementos para proyectar la construcción o uso de componentes y servicios en una arquitectura de diseño y su posterior implementación.

REFERENCIAS

[1] DIJKSTRA, E.W. A Discipline of programming, Prentica Hall, Englewood Cliffs, NJ, 1976.         [ Links ]
[2] PARNAS, D. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 1053-1058,1972.         [ Links ]
[3] SOMMERVILLE, I. Software Engineering, 7 ed: Addision-Wesley, 2004.         [ Links ]
[4] JACOBSON, I., CHIRSTERSON, M., JONSSON P. and Overgaard G., Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.         [ Links ]
[5] LAMSWEERDE, A. Goal-Oriented Requirements Engineering: A Guided Tour, presented at 5th IEEE International Symposium on Requirements Engineering, 2001.         [ Links ]
[6] CHUNG, L., NIXON, B., YU E. and MYLOPOULOS J. Non-Functional Requirements in Software Engineering: Kluwer Academic Publishers, 2000.         [ Links ]
[7] LAMSWEERDE, A.V. Goal-Oriented Requirements Engineering: A Roundtrip from Research to Practice, presented at Requirements Engineering (RE 2004), Kyoto, Japan , 2004.         [ Links ]
[8] KICZALES, G. HILSDALE, E., HUGUNIN, J., KERSTEN, M., PALM, J. and GRISWOLD W. G. Getting Started with AspectJ. Comm. Of the ACM, v. 44, n. 10, 59-65, 2001.         [ Links ]
[9] TARR, P., OSSHER, H., SUTTON, S.M. Jr., N Degrees of Separation: Multidimensional Separation of Concerns 21st Int. Conf. On Software Eng. ACM, 107-119, 1999.         [ Links ]
[10] CLARKE, S., BANIASSAD, E., Aspect-Oriented Analysis and Design. The Theme Approach. Addison-Wesley, Object Technology Series, 2005.         [ Links ]
[11] RASHID, A., MOREIRA, A. and ARAÚJO, J. Modularisation and Composition of Aspectual Requirements. AOSD, ACM, 11-20, 2003.         [ Links ]
[12] MOREIRA A., ARAUJO J., and RASHID A., “Multi-Dimensional Separation of Concerns in Requirements Engineering,” presented at RE’05 Conference (RE 05), France , 2005.         [ Links ]
[13] MOREIRA, A., ARAÚJO, J. and RASHID A. A Concern-Oriented Requirements Engineering Model. CAISE, LNCS Vol.3520, 293-308, 2005.         [ Links ]
[14] CHITCHYAN, R., RASHID, A., SAWYER, P., BAKKER, J., PINTO, M., GARCIA, A., TEKINERDOGAN, B., CLARKE, S., JACKSON, A., “Survey of Aspect-Oriented Analysis and Design Approaches”, AOSD-Europe-ULANC-9, AOSD-EUROPE network of excellence. May 2005.         [ Links ]
[15] PINEDA, O. Definition, Analysis, and Design for General Services Software at UNAL Medellín branch. Thesis Degree National University of Colombia . 2004.         [ Links ]
[16] Open Process Framework Repository Organization (OPFRO). http://www.opfro.org.
[17] BRITO, I.S., MOREIRA, A. Integrating the NFR framework in a RE model”. EA 2004: AORE and Architecture Design, workshop 3rd Inter. Conf. on Aspect-Oriented Software Development, Lancaster, UK, 22-26 2004.         [ Links ]
[18] SHMUEL, K., AWAIS, R., From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems. RE 2004: 48-57.         [ Links ]
[19] JACOBSON I. , and NG, P.W., “Aspect-Oriented Software Development with Use Cases”, Addison Wesley Professional, 2005.         [ Links ]
[20] SOUSA, G., SOARES, S., BORBA P., and Castro J., “Separation of Crosscutting Concerns from Requirements to Design: Adapting the Use Case Driven Approach”, EA’04: Aspect-Oriented Requirements Engineering and Architecture Design. Workshop at AOSD 2004, pages 93-102. 2004, Lancaster UK .         [ Links ]
[21] MDA Guide Version 1.0.1. Copyright © 2003 OMG. http://www.omg.org.