MODELADO DE REQUISITOS PARA LA OBTENCIN DE ESQUEMAS CONCEPTUALES

Emilio Insfrn

Isabel Daz

Universidad Politcnica de Valencia (Espaa) Universidad Central de Venezuela {einsfran|idiaz|mburbano}@dsic.upv.es

Margarita Burbano

Resumen
En este trabajo se presenta un enfoque de Ingeniera de Requisitos para el modelado conceptual de sistemas de informacin. Su principal objetivo es proporcionar un conjunto de tcnicas y guas para capturar los requisitos del software, analizarlos y expresarlos en un esquema conceptual de OO-Method garantizando la trazabilidad entre stos. El enfoque se basa en un marco referencial de herramientas de especificacin de requisitos (TRADE) y un mtodo grfico orientado a objetos para el modelado conceptual con capacidades de generacin automtica de cdigo (OO-Method). Se define la estructura y tcnicas para la construccin de un Modelo de Requisitos funcionales del sistema y a partir de este modelo, un Proceso de Anlisis de Requisitos (PAR) define constructores que permiten representar dichos requisitos en elementos del Modelo Conceptual de OO-Method. Utilizando este proceso cada elemento del Modelo de Requisitos tiene una representacin perfectamente identificable en el Modelo Conceptual OO-Method y cada elemento del Modelo Conceptual tiene su origen en el Modelo de Requisitos.
Palabras claves: ingeniera de requisitos, modelado conceptual, casos de uso, mtodos orientados a objeto

1. Introduccin
Algunas de las debilidades de muchos mtodos estn contextualizadas en etapas tempranas del desarrollo de software. Uno de los problemas derivado de estas debilidades metodolgicas tiene que ver con la dificultad de determinar si el modelo conceptual del sistema de software representa fiel y completamente los requisitos de los usuarios. Casi siempre estos requisitos son expresados de forma escasamente estructurada sin establecer ninguna correspondencia entre stos y los elementos del modelo conceptual. Ms an, generalmente estos mtodos carecen de directrices adecuadas para el desarrollo de modelos conceptuales derivados de las especificaciones y posteriormente de cdigo que sea funcionalmente equivalente a dichos modelos conceptuales. Como un esfuerzo para la superacin de estas limitaciones, en este trabajo se presenta un enfoque sistemtico de Ingeniera de Requisitos que define un proceso que posibilita la descomposicin sistemtica y repetitiva de los requisitos de software hasta obtener una detallada especificacin que constituir el modelo conceptual del sistema deseado. Este enfoque pretende mejorar la calidad del proceso de produccin de software: Proporcionando predecibilidad mediante la construccin de un modelo conceptual como una precisa, estructurada y bien definida representacin de los requisitos de los usuarios. Aumentando la productividad al establecer vnculos precisos entre el modelo conceptual y los requisitos de los usuarios. Esto facilitar la incorporacin en el modelo conceptual de cambios en los requisitos. En consecuencia, tales modificaciones quedarn reflejadas tambin en el sistema de software desarrollado. Para lograr esto, el enfoque propuesto define un Modelo de Requisitos que captura los aspectos funcionales del sistema mediante la aplicacin de tres tcnicas complementarias entre s: la definicin de la Misin del sistema, la construccin del rbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Adicionalmente, se introduce el Proceso de Anlisis de Requisitos que permite traducir el Modelo de Requisitos en el Modelo Conceptual manteniendo la trazabilidad entre ambos modelos. Este proceso garantiza que cada elemento del Modelo de Requisitos (espacio del problema) tenga una representacin en el Modelo Conceptual.

Esta investigacin est soportada por el Programa CYTED (proyecto VII.18), WEST y el Proyecto CICYT (referencia TIC 2001-3530-C02-01).

El enfoque de Ingeniera de Requisitos utiliza algunas de las tcnicas propuestas en TRADE para la especificacin requisitos de usuario conjuntamente con OO-Method [Wie 98] [Wie 99] [Pas&Al 97] en lo relativo a la construccin del Modelo Conceptual y generacin automtica de cdigo. Esta combinacin resulta en un potente ambiente que integra el modelado de requisitos de software, modelado conceptual y generacin automtica de cdigo. Este trabajo ha sido organizado en tres secciones. La primera describe brevemente las principales caractersticas de TRADE y OO-Method y las ventajas de utilizarlas adecuadamente de forma complementaria. La segunda seccin muestra el Modelo Conceptual tal y como es concebido por OO-Method. La tercera presenta una visin general del enfoque de Ingeniera de Requisitos detallando la fase de Modelado de Requisitos y el Proceso de Anlisis de Requisitos como recursos de primordial importancia para la construccin del Modelo Conceptual OO-Method. Esta seccin trata tambin aspectos de trazabilidad entre los elementos generados. Por ltimo, se presentan las conclusiones y trabajos futuros relacionados.

2. Antecedentes: TRADE y OO-Method

TRADE define un marco de tcnicas y heursticas de anlisis y diseo basadas en tcnicas de especificacin estructuradas y orientadas a objeto [Wie 98]. En el esquema conceptual de TRADE se distinguen las interacciones externas de la descomposicin interna para clasificar las propiedades del sistema a desarrollar. Las interacciones externas, de especial inters para este trabajo, son funciones que describen el comportamiento del sistema y su comunicacin con el ambiente en el que est inmerso. Algunas tcnicas propuestas por TRADE para especificar las interacciones externas y sus propiedades son: Misin del Sistema, rbol de Refinamiento de Funciones, Diagramas de Contexto, Diagramas de Casos de Uso y Diagramas de Escenarios. Estas tcnicas son utilizadas convenientemente por el enfoque de Ingeniera de Requisitos que se propone. La descomposicin interna trata de cmo las interacciones externas son representadas internamente en el sistema, es decir, cul ser la estructura interna del sistema en trminos de los elementos utilizados para describirlo. El enfoque de Ingeniera de Requisitos que se propone utiliza el paradigma orientado a objetos y, en particular, OO-Method como aproximacin metodolgica. Este mtodo se caracteriza por proporcionar tcnicas grficas de modelado conceptual basadas en UML que son soportadas por un lenguaje formal de especificacin (OASIS) [Pas&Al 97] [Pas&Al 01] [PR 95]. De esta forma, la especificacin formal acta como un repositorio del alto nivel para todas las propiedades del sistema (estructura, comportamiento y funcionalidad). Adicionalmente, OO-Method define un Modelo de Ejecucin que define mecanismos de traduccin automtica de elementos del modelo conceptual en cdigo fuente siguiendo unos patrones de traduccin perfectamente definidos y que son explicados en detalle en [Pas&Al 01]. Esto permite generar automticamente una aplicacin funcionalmente equivalente a su especificacin formal. La conveniente combinacin de TRADE y OO-Method permiti establecer los fundamentos del mtodo de Ingeniera de Requisitos para el modelado conceptual presentado en este trabajo. TRADE proporciona un conjunto de tcnicas para el tratamiento de requisitos. Su principal debilidad es que carece de un mtodo bien definido para guiar el proceso de especificacin de los mismos de tal forma que pueda ser utilizada posteriormente en el diseo e implementacin del sistema. Por el contrario, OO-Method es un mtodo riguroso que permite obtener un producto final de software a partir del Modelo Conceptual. Sin embargo, no ofrece mecanismos que apoyen el proceso de construccin de este modelo. La combinacin TRADE/OO-Method logra la completitud requerida para solucionar estos problemas de la siguiente manera: Definiendo un Modelo de Requisitos que utiliza un subconjunto de tcnicas de TRADE e indicando cmo aplicarlas correctamente. Conectando el Modelo de Requisitos con el Modelo Conceptual OO-Method mediante un proceso sistemtico que permita obtener el segundo a partir del primero.

3. Modelo Conceptual OO-Method

La fase de Modelado de Requisitos tiene una finalidad doble que no podemos perder de vista en ningn momento. Por un lado debe permitir entender las necesidades del usuario en el dominio del problema y representarlo de una forma sencilla, completa y sin ambigedades. Por otro lado, toda la informacin de requisitos capturada debe tener su representacin en el Modelo Conceptual. A continuacin se describe brevemente el modelo conceptual lo que ayudar a comprender mejor el espritu del mtodo de requisitos

propuesto. El Modelo Conceptual OO-Method representa los requisitos de los usuarios, especificando el qu har el sistema sin indicar cmo y suponiendo un ambiente de implementacin ideal [MP 84]. El cambio de granularidad de requisitos al modelo conceptual viene dado porque en el Modelo Conceptual realizamos explcitamente la descomposicin interna del sistema en trminos de las clases que lo componen. Para esto, se utilizan tres modelos complementarios entre s que utilizan notacin UML: Modelo de Objetos: se representan las clases en el espacio del problema necesarias para soportar la funcionalidad requerida, y se especifican con detalle sus propiedades estticas (atributos, servicios, restricciones de integridad y relaciones de agregacin, de herencia y de agente)1. Modelo Dinmico: especifica el ciclo de vida de los objetos y sus interacciones mediante: Los Diagramas de Transicin de Estados: que describen el comportamiento de cada clase a travs del establecimiento de los ciclos de vida vlidos para sus instancias. Una vida vlida es una secuencia de estados que caracteriza correctamente el comportamiento de los objetos. Los Diagramas de Colaboracin: que muestran las interacciones entre los objetos que pueden ser: triggers, que son servicios que se activan automticamente cuando se cumple una condicin o, interacciones globales, que son la especificacin de la interaccin entre distintos objetos mediante el envo de mensajes. Modelo Funcional: es un modelo textual usado para capturar la semntica de los cambios de estado de un objeto como consecuencia de la ocurrencia de un servicio. Especifica de forma declarativa cmo cada servicio cambia el estado del objeto dependiendo de sus argumentos.

4. Un Enfoque de Ingeniera de Requisitos para el Modelado Conceptual

La Figura 1 muestra la integracin de la fase de Ingeniera de Requisitos a la arquitectura de OO-Method. Esta representacin general permite observar todo el mtodo de desarrollo de software, desde la captura de los requisitos hasta la obtencin del producto final. En particular, se enuncian las tcnicas utilizadas para la construccin del Modelo de Requisitos que, conjuntamente con el Proceso de Anlisis de los mismos, hacen posible el desarrollo del Modelo Conceptual OO-Method. Esta seccin est dedicada, precisamente, a describir estas tcnicas as como tambin los mecanismos de traduccin del modelo de entrada (Modelo de Requisitos) al modelo de salida (Modelo Conceptual OO-Method).

4.1 Fase de Modelado de Requisitos

El propsito del Modelo de Requisitos es capturar precisa y fielmente las principales caractersticas del sistema software que se desea construir. Este modelo permite representar los requisitos del sistema de manera que cualquiera de sus potenciales usuarios pueda revisarlo y comprenderlo, sin que para esto necesite un entrenamiento especial. No obstante, la notacin utilizada en tal representacin es lo suficientemente precisa para que pueda servir de base a la fase de modelado conceptual. En este modelo los conceptos de actor y caso de uso desempean roles de mucha importancia. Ambos conceptos fundamentan el Modelo de Casos de Uso propuesto por Jacobson en su Mtodo OOSE [Jac&Al 92]. Es reconocida la efectividad de este modelo para manejar la complejidad de los requisitos. Su simplicidad, derivada del uso del lenguaje natural para describir la funcionalidad observada en el espacio del problema, posibilita la participacin activa de usuarios finales y clientes en el modelado de los requisitos. Sin embargo, el Modelo de Casos de Uso tiene dos desventajas importantes que dificultan frecuentemente la puesta en prctica de las tcnicas de Ingeniera de Requisitos: la dificultad de determinar el nivel de abstraccin correcto para especificar los casos de uso y la inexistencia de un proceso para analizar esta especificacin y traducirla a un modelo conceptual1. Las tcnicas propuestas para el desarrollo del Modelo de Requisitos intentan superar estos problemas (Fig. 1). La determinacin del propsito del sistema (Misin) y la descomposicin de sus interacciones externas en funciones (rbol de Refinamiento de Funciones) conjuntamente con una estructurada especificacin de las funcionalidades (Modelo de Casos de Uso), constituyen la clave para el establecimiento del nivel de abstraccin adecuado de los casos de uso. El Proceso de Anlisis de Requisitos, por su parte, considera los
1
1

Una relacin de agente en OO-Method especifica cules son los objetos que pueden activar los servicios de otros objetos. En UORE (Usage Oriented Requirements Engineering) este proceso es conocido como sntesis [RKW 95].

aspectos relativos al anlisis de estas funcionalidades y a su traduccin al Modelo Conceptual OO-Method. En las prximas secciones se describen las tres tcnicas que permiten generar el Modelo de Requisitos.
Misin del Sistema

Modelo de Requisitos (MR)

rbol de Refinamiento de Funciones

Dominio del problema

Modelo de Casos de Uso

Proceso de Anlisis de Requisitos (PAR)

Diagramas de Secuencia
Traduccin guiada

Modelo Conceptual (MC) Modelo de Ejecucin (ME)

Modelo Objeto

Modelo Dinmico

Modelo Funcional

OASIS
Traduccin automtica

Visual Basic BDR

Java BDR

Visual C++ BDR

FIG. 1. INGENIERA DE REQUISITOS Y OO-METHOD

4.1.1. Misin del Sistema Describe el propsito del sistema, sus responsabilidades y alcance. A travs de la definicin de su misin es posible determinar con precisin, aunque sea en trminos generales, qu har y qu no har el sistema. Aunque sea una tcnica relativamente sencilla, es de vital importancia consensuar desde el principio con los usuarios el objetivo del sistema y tenerlo presente durante todas las fases del proceso de desarrollo del sistema. 4.1.2. rbol de Refinamiento de Funciones Descompone el sistema en interacciones externas, de acuerdo a algn criterio preestablecido por ejemplo, las reas u objetivos organizacionales, los actores y sus responsabilidades, etc. Las interacciones externas son organizadas en funciones que forman una jerarqua a manera de rbol, en cuyo nivel ms alto (raz) se ubica la misin del sistema. Esta Misin del Sistema es refinada hasta obtener otras funciones elementales representadas en la jerarqua a travs de los nodos hoja. Este proceso descendente de refinamiento funcional puede generar distintos niveles de nodos. Aquellos que estn entre la raz y los nodos hoja son denominados nodos intermedios. Un nodo intermedio es un sumario de funciones elementales. En general, una rama completa de nodos con origen en la raz del rbol, representa toda la funcionalidad relativa a un rea o actividad de la organizacin, segn el criterio de descomposicin utilizado. Distinguir entre nodos hoja y nodos intermedios no es una tarea trivial. Una funcin es considerada como elemental si es activada por un evento enviado por un usuario del sistema (actor) o por la ocurrencia de un evento temporal [Wie 98]. El rbol de Refinamiento de Funciones2 representa la descomposicin jerrquica de las funciones de un sistema, independientemente de la estructura del mismo. El rbol resultante3 es una organizacin de interacciones externas que no dice nada acerca de la composicin interna del sistema. Sin embargo, es un insumo muy til para la construccin del Modelo de Casos de Uso pues permite iniciar su construccin con una clara delimitacin de las funcionalidades y con un mismo nivel de abstraccin: todo nodo hoja ser un Caso de Uso. De esta forma se evitan confusiones sobre qu es un Caso de Uso y adems hay un claro criterio de completitud: las hojas del ARF como refinamiento de la Misin del Sistema. En la Figura 2 se muestra, a manera de ejemplo, el rbol de Refinamiento de Funciones de un tpico Sistema de Terminales de Venta (STV) para una tienda. Este sistema ser utilizado para ilustrar algunos de los conceptos y planteamientos que se introducen en este trabajo.

2 3

La tcnica del rbol de Refinamiento de Funciones fue definida por Martin en [Mar 89]. Algunos autores utilizan un Grafo de Refinamiento de Funciones, estableciendo los correspondientes vnculos entre nodos con igual funcionalidad en distintas ramas. En el mtodo que se propone dicha funcionalidad aparece una sola vez ya que el objetivo es slo detectar interacciones externas para especificarlas posteriormente en el Modelo de Casos de Uso.

4.1.3. Modelo de Casos de Uso El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso propuesto por Jacobson, bajo el esquema conceptual y notacional definido en UML [Jac&Al 92] [OMG 01]. De esta forma, la especificacin de actores y casos de uso as como el establecimiento de las relaciones entre stos, constituye el objetivo fundamental del Modelo de Casos de Uso. El principal insumo requerido para el desarrollo de este modelo son las funciones elementales identificadas como nodos hoja en el rbol de Refinamiento Funcional del sistema. Cada una de estas funciones elementales es considerada en el modelo como un caso de uso (Fig. 2 y Fig. 3). Luego de identificar sus actores, la especificacin de los casos de uso describe en lenguaje natural la secuencia completa y ordenada de las acciones que el sistema debe ejecutar, incluyendo todas sus posibles variantes, al interactuar con los actores para la satisfaccin de los requisitos.
STV

Nodo Raz

Gestin de Ventas

Gestin de Artculos

Gestin de Usuarios

Nodos Intermedios

Vender Artculos F1.A

Devolver Artculos F1.B

Registrar Artculos F2.A

Actualizar Precio F2.B

Actualizar Inventario F2.C

Registrar Registrar Cajero Supervisor F4.A F4.B

Mantener Mantener Informacin Informacin Cajero Supervisor F4.C F4.D

Nodos Hoja (Funciones Elementales)

FIG. 2. RBOL DE REFINAMIENTO DE FUNCIONES DEL SISTEMA DE TERMINALES DE VENTA (STV)

La especificacin de casos de uso es un proceso incremental e iterativo que, inicialmente, toma la forma de un corto y genrico texto escrito en prosa. Sin embargo, a medida que se alcanza un mayor conocimiento del dominio, este texto crece en tamao y detalle adquiriendo formas complejas que limitan su comprensin y posterior uso en las distintas etapas de la construccin del sistema. Con el propsito de minimizar el impacto de estos problemas, la descripcin de los casos de uso es estructurada precisndose su nivel de detalle en trminos de las necesidades del modelado y del momento de desarrollo del sistema. La estructura propuesta para los casos de uso y la determinacin del nivel de abstraccin de los mismos responden tambin a ajustes necesarios para su posterior utilizacin en la construccin de otros modelos OO-Method.

Supervisor

Vender Artculos Registrar Artculos Actualizar Inventario Actualizar Precio

Devolver Artculos Cajero

FIG. 3. MODELO (PARCIAL) DE CASOS DE USO DEL SISTEMA DE TERMINALES DE VENTA (STV)

El nivel de abstraccin de un caso de uso est vinculado al contenido informativo relevante o significativo que se desea expresar en el caso de uso. La caracterizacin de la abstraccin utilizada en el mtodo est basada en las propuestas introducidas por Constantine/Lockwood y Cockburn en [Coc 97a], [Coc 97b], [CL 99] y [CL 00]. De los primeros autores se utiliza el concepto de caso de uso esencial mientras que, del ltimo, la definicin de niveles de refinamiento. Fundamentada en estos planteamientos, el nivel de abstraccin de la especificacin de un caso de uso se caracteriza por: Expresar de forma esencial la funcionalidad, utilizando el lenguaje del dominio del problema. Suponer un ambiente ideal de implementacin por lo que se excluyen aspectos relativos a los recursos tecnolgicos requeridos para la ejecucin del caso de uso. Describir la funcionalidad en trminos de la intencin del usuario al interactuar con el sistema y de las responsabilidades de este ltimo.

Mostrar un refinamiento parcial de detalle de interaccin a nivel de interfaz semntica. Esto significa que la especificacin del caso de uso no describe la interfaz que utiliza el actor para comunicarse con el sistema ni tampoco el formato de la informacin intercambiada por el actor y el sistema durante el desarrollo de la interaccin pero s detalla el contenido de la misma siempre que se considere relevante en el contexto de dicha interaccin. La descripcin de la interfaz del sistema es el objetivo del Modelo de Presentacin OO-Method. La unidad estructural bsica de la especificacin de un caso de uso OO-Method es el paso. Un paso es la descripcin de una actividad realizada por el actor o el sistema durante la interaccin desencadenada entre stos para el logro de una funcionalidad. Un paso se caracteriza porque es: Unidireccional: un paso muestra una sola direccin de la comunicacin establecida entre el actor y el sistema o el sistema consigo mismo. Esto implica que un paso hace referencia nicamente a una de las siguientes situaciones: un actor enva informacin al sistema sobre una actividad o el sistema enva informacin al actor sobre una actividad o el sistema ejecuta una accin sobre s mismo. Atmico: la comunicacin unidireccional que describe un paso no admite descomposicin en otras comunicaciones unidireccionales. Un paso no puede componerse de otros pasos. Esto es, un paso slo debe describir una nica actividad realizada por el actor o el sistema con significado en el contexto de una de las direcciones de la interaccin establecida entre stos. En trminos gramaticales, la unidireccionalidad y la atomicidad de un paso pueden garantizarse redactndolo como una oracin simple, es decir, utilizando un nico sujeto y un nico predicado (un slo verbo) [DM 01]. Aplicando este formato gramatical, un paso quedara estructurado como se muestra en la Figura 4. En el ejemplo de la Figura 5 se utiliza este formato para escribir un paso.
[<condicin>,] <actor><sistema> <actividad>
donde: Condicin Expresin que puede tomar un nico valor de verdad. Restringe la ejecucin de la actividad del paso al cumplimiento de un requisito previo. Esto es, la realizacin de la actividad depende del valor de verdad de la condicin. Es opcional, como parte de la estructura del paso. Responsable de ejecutar la accin verbal de la actividad. Gramaticalmente, cumple la funcin de sujeto de la oracin. Descripcin de la accin que realiza el actor o el sistema. Gramaticalmente, es el predicado de la oracin. Se caracteriza por tener un nico verbo. FIG. 4. FORMATO DE UN PASO

Actor o Sistema Actividad

Si la cantidad pagada es mayor o igual al monto total de la venta, el STV actualiza el inventario
Condicin Sistema Actividad

FIG. 5. EJEMPLO DE PASO ESCRITO SEGN EL FORMATO PROPUESTO

El flujo de eventos que se desarrolla entre el actor y el sistema para el logro del objetivo del caso de uso es narrado en la especificacin, a manera de conversacin, a travs de una secuencia numerada de pasos. Esta secuencia discrimina los pasos segn su naturaleza de forma similar a como se propone en [Con 95], [Lar 98] y [Wir 93]. Esta clasificacin separa las acciones del actor de las ejecutadas por el sistema y las distingue de aquellas relativas al contexto donde se desarrolla el caso de uso. La Figura 6 muestra la secuencia correspondiente al caso de uso Venta de Artculos de un Sistema de Terminales de Venta (STV)1. En su especificacin se ha utilizado un formato de tres columnas que diferencia cada paso segn sea: General: describe un suceso del espacio del problema que est fuera del alcance del sistema de software que se est modelando. Tales sucesos ocurren en el entorno funcional ms prximo del caso de uso, promoviendo su activacin o constituyndose en receptores de ciertos resultados parciales o finales obtenidos a travs de la ejecucin del mismo. Los pasos generales no sern implementados
1

Es un sistema computarizado que permite registrar las ventas realizadas en una tienda y facilitar el procesamiento de los pagos.

como parte del sistema pero su conocimiento es importante porque ayudan a comprender mejor la funcionalidad descrita por el caso de uso. La entidad perifrica del caso de uso que estimula directa o indirectamente su ejecucin es denominada actor externo a diferencia del actor principal responsable de iniciar la trayectoria de eventos propia de la funcionalidad que se est especificando. Comunicacin Actor/Sistema: describe una actividad realizada por el actor o el sistema a travs de la que uno de stos aporta informacin al otro. En trminos de la unidireccionalidad de este tipo de pasos, si el actor es el emisor del mensaje, el sistema es el receptor o viceversa. Gramaticalmente, se caracterizan porque el sujeto de la oracin es el actor o es el sistema de software que se est modelando (Fig. 4). Los pasos de Comunicacin Actor/Sistema permiten capturar ciertos aspectos de la interfaz usuario del software en desarrollo. Respuesta del Sistema: son actividades realizadas por el sistema que ocasionan un cambio en su estado. En trminos de la unidireccionalidad de la interaccin que el caso de uso describe, en este tipo de pasos el sistema es emisor y receptor del mensaje. Gramaticalmente, se caracterizan porque el sujeto de la oracin es el sistema de software que se est modelando (Fig. 4). La especificacin de los casos de uso distingue la trayectoria bsica de las alternas, de acuerdo con el planteamiento presentado en OOSE por Jacobson [Jac&Al 92]. Ambas trayectorias se describen utilizando pasos, discriminndolos segn sus tipos para lo cual se mantiene el formato de tres columnas. Cada una de las trayectorias (tanto la bsica como las alternas) se corresponde con un escenario del caso de uso y el conjunto de todos los escenarios posibles definen completamente el contexto de comportamiento que se desea especificar. La trayectoria bsica describe el escenario primario del caso de uso mientras que, cada una de las trayectorias alternas, describe un escenario secundario. La trayectoria alterna se activa con el cumplimiento de una condicin y, cuando esto sucede, la trayectoria bsica deja de ejecutarse, realizndose los pasos de la trayectoria alterna. Por otra parte, entre los casos de uso es posible establecer relaciones de inclusin o de extensin, manteniendo la semntica establecida por el UML en la versin 1.4 [OMG 01]. En general, el flujo de eventos de un caso de uso puede ser presentado como una lista numerada de pasos. Pero no siempre este flujo de eventos sigue una trayectoria secuencial, desarrollndose desde el principio hasta el final en el mismo orden en el que suceden los pasos. En ocasiones, la secuencia de eventos puede bifurcarse o tener un carcter iterativo o repetitivo en atencin al cumplimiento de una condicin. Para representar estos casos especiales en los que el flujo de eventos no sigue un recorrido lineal, se permite el uso de las tradicionales estructuras lgicas de control de la programacin estructurada.

4.2 Proceso de Anlisis de Requisitos (PAR)

El propsito principal de este proceso es identificar las responsabilidades ms significativas del sistema en desarrollo. Una responsabilidad es una obligacin que tiene un objeto con respecto a su propio comportamiento [Lar 98] [Gra 98] [OMG 01]. Las responsabilidades conllevan a la definicin de operaciones, esto es, a la especificacin de los servicios de una clase. Utilizando terminologa OO-Method, las responsabilidades resultan en especificaciones de eventos (unidades atmicas de ejecucin) o de transacciones (unidades moleculares de ejecucin). Con el propsito de describir las responsabilidades detectadas en el contexto de un Caso de Uso se utilizan Diagramas de Secuencia con notacin UML (versin 1.4). En estos diagramas se representan las responsabilidades, identificando el objeto que la invoca (objeto cliente) y el objeto al que sta pertenece (objeto servidor). Para mostrar las decisiones sobre asignacin de responsabilidades entre los objetos, el Proceso de Anlisis de Requisitos prev la especificacin de Diagramas de Secuencia pero a muy alto nivel y como herramienta para representar estas responsabilidades. Tales decisiones pueden ser tomadas aplicando alguna de las tcnicas o heursticas planteadas para facilitar la identificacin de responsabilidades como, por ejemplo, las que se describen en GRASP (General Responsibility Assignment Software Patterns) [Lar 98] o en el mtodo RDD (Responsibility Driven Design) [WWW 90]. En OO-Method la determinacin de responsabilidades se realiza en el contexto de un escenario. Un escenario es una secuencia especfica de las acciones que describe un caso de uso. Es una instancia de ste que muestra una de las trayectorias de su flujo de eventos. As, un caso de uso puede ser considerado como la compilacin de mltiples escenarios algunos de los cuales, los primarios, describen su trayectoria normal mientras que otros, los secundarios, se refieren a sus trayectorias alternas.

Los diagramas de secuencia permiten describir patrones de interaccin entre objetos o clases. A travs de estos diagramas se muestra la secuencia ordenada en el tiempo de los mensajes que envan y reciben genricamente los objetos durante la ejecucin de un escenario. UML define un mensaje como la especificacin de un estmulo [OMG 01]. Un estmulo es una comunicacin entre dos objetos que se transmiten informacin con la finalidad de que se ejecute una actividad. Un mensaje especifica los roles que deben cumplir tanto el objeto emisor (el cliente) como el objeto receptor del estmulo (el servidor) as como la accin que ser ejecutada. De esta forma, a travs de los mensajes se expresan las responsabilidades que cumplirn los objetos en el sistema.
CASO DE USO ACTORES REFERENCIA CRUZADA RESUMEN CONDICIN PREVIA Venta de Artculo Cajero F1.a Permite registrar la informacin relativa a la venta de uno o ms artculos. Los artculos deben estar prerregistrados en el sistema. TRAYECTORIA BSICA GENERAL (1) El Cliente llega a la caja para registrar su compra. (2) El Cajero inicia una nueva sesin de venta. (3) El STV presenta el inicio de la sesin. PARA CADA artculo a vender (4) El Cajero introduce la identificacin de un artculo. (5) El Cajero introduce cantidad del artculo vendido. (6) El STV determina informacin y precio por unidad del artculo. (7) El STV registra la venta del artculo. (8) El STV calcula el subtotal de la venta de un artculo. (9) El STV actualiza la cantidad en existencia correspondiente al tipo de artculo vendido. (10) El STV muestra informacin sobre el subtotal de la venta. (11) El STV pregunta si la venta ha concluido. FIN PARA (12) El Cajero avisa sobre la finalizacin de la venta. (13) El STV calcula el monto total de la venta. (14) El STV muestra informacin sobre el monto total de la venta. (15) El Cajero informa al Cliente sobre el monto total de la venta. COMUNICACIN ACTOR/SISTEMA RESPUESTA DEL SISTEMA

FIG. 6. ESPECIFICACIN DEL CASO DE USO: VENTA DE ARTCULO

En el Proceso de Anlisis de Requisitos, es posible utilizar dos tipos de diagramas de secuencia, dependiendo del momento y estrategia de desarrollo seguida as como tambin del nivel de detalle deseado. Un primer tipo de diagrama de secuencia OO-Method hace nfasis en la interaccin, en trminos de los actores y el sistema, mostrando el flujo de eventos que ocurren en el dominio del problema (Fig. 7). Este tipo de diagrama de secuencia muestra las responsabilidades pero no los objetos clientes ni los objetos servidores (dada una especificacin de Casos de Uso con sus pasos de obtiene automticamente donde cada paso se convierte en un auto-mensaje). El segundo tipo de diagrama de secuencia es la evolucin del primero y representa de manera precisa y detallada las interacciones entre los actores y el sistema pero, esta vez, indicando el intercambio de mensajes entre las clases de objetos participantes. Esto es, se muestran las responsabilidades y tambin las clases de objetos clientes y servidores (Fig. 8). El Proceso de Anlisis de Requisitos consiste, bsicamente, en la construccin de los diagramas de secuencia OO-Method a partir del Modelo de Requisitos del sistema. Los diagramas de secuencia se presentan como esquemas genricos de especificacin de interacciones entre los objetos que participan en un escenario. Por lo tanto, no son desarrollados para determinados objetos sino,

ms bien, para las clases que describen la estructura y comportamiento del caso de uso respectivo. No obstante, se admite la incorporacin de objetos slo cuando sea necesario hacer referencia a ms de un objeto de la misma clase en un mismo diagrama de secuencia.
:Sistema :Objeto1 :Objeto2

:Actor
mensaje

:Sistema
lnea de vida

:Actor

mensaje mensaje [condicin]* mensaje

mensaje automensaje

automensaje [condicin] mensaje INCLUDE escenario mensaje

mensaje
mensaje

mensaje
activacin (foco de control)

mensaje

FIG. 7. DIAGRAMA DE SECUENCIA (FORMATO 1)

FIG. 8. DIAGRAMA DE SECUENCIA (FORMATO 2)

Los diagramas de secuencia, adems de expresar en detalle los resultados del Proceso de Anlisis de Requisitos, constituyen un recurso de mucha importancia para la construccin del Modelo de Objetos de OO-Method. Con esta finalidad, se ha incorporado en estos diagramas cierta informacin que resulta de inters para identificar elementos de este modelo. Esta informacin se expresa estereotipando los mensajes del diagrama de secuencia con el propsito de distinguirlos segn la clasificacin que se muestra en la Figura 9 [IPW 02].
ESTEREOTIPO <<Signal>> PROPIEDAD Direction VALOR {input} {output} {new} <<Service>> Kind of Change derived attribute description <<Query>> multiplicity {0..1} {0..M} {1..1} {1..M} {0} {1} ... {M} {insert} activity {delete} {destroy} {update} DESCRIPCIN Aplicable a mensajes de tipo seal cuyo origen es una clase que representa un actor en el Modelo de Casos de Uso y cuyo destino es la clase que representa al Sistema en desarrollo. Aplicable a mensajes en los que el origen es el Sistema y el destino es un actor en el Modelo de Casos de Uso. Mensaje que indica la creacin de una nueva instancia de la clase receptora del mensaje. Aplicable a mensajes utilizados para borrar una instancia de la clase receptora del mismo. Aplicable a mensajes que modifican el estado de la clase receptora del mismo. Atributo Derivado = nombre del mensaje Descripcin en lenguaje natural de la consulta. Propiedad opcional que indica el nmero de objetos involucrados en la consulta (cardinalidad). La constante M debe ser mayor a 1.

mn/max. multiplicity <<Select>>

Nmero mnimo (o mximo) de objetos que puede ser seleccionado de la clase destino en una interaccin. El rango de valores a seleccionar se encuentra entre 0 y M elementos. La actividad de un mensaje es de insercin cuando es necesario relacionar elementos que ya han sido creados, con algn objeto de la clase que enva el mensaje. La actividad de un mensaje es de borrado cuando desea quitarse una seleccin que se ha establecido entre los elementos de una interaccin.

FIG. 9. ESTEREOTIPOS DE LOS MENSAJES DE LOS DIAGRAMAS DE SECUENCIA OO-METHOD

4.3 Trazabilidad
De acuerdo con el trabajo de Gotel, el modelo de trazabilidad utilizado para relacionar los distintos elementos del Enfoque de Ingeniera de Requisitos con los elementos del Modelo Conceptual OO-Method, se caracteriza por ser estructural y estar basado en referencias cruzadas [Got 95]. Esto significa, en primer lugar, que la relacin establecida entre estos elementos es estructural (por ejemplo, las clases identificadas en el PAR son tambin clases en el Modelo Conceptual). En segundo lugar, se establecen explcitamente referencias entre los elementos a diferentes niveles de abstraccin (por ejemplo, la especificacin de cada caso de uso indica cul es el nodo hoja del rbol de Refinamiento de Funciones que le da origen). Por otra parte, la trazabilidad en el enfoque de Ingeniera de Requisitos puede ser estudiada desde dos perspectivas. Internamente, la trazabilidad es establecida entre los elementos de las distintas tcnicas del Modelo de Requisitos y entre stos y los que pertenecen al Proceso de Anlisis de Requisitos. Desde una perspectiva externa, la trazabilidad queda determinada por los vnculos establecidos entre los elementos de dicho proceso y los constructores del Modelo Conceptual OO-Method.

La trazabilidad interna se consolida de la siguiente manera: La misin del sistema se expresa a travs de las funciones elementales identificadas en el rbol de Refinamiento de Funciones (Fig. 2). Cada funcin elemental (nodo hoja) es considerada como un caso de uso en el Modelo de Casos de Uso (Fig. 2 y Fig. 3). Cada escenario de un caso de uso tiene asociado un diagrama de secuencia. La Figura 10 muestra el diagrama de secuencia de un escenario del caso de uso Venta de Artculos del STV. Cada paso de un caso de uso se corresponde con, al menos, una interaccin (mensaje) en el diagrama de secuencia (excepto los pasos de tipo General que no son representados en estos diagramas). Cada paso de un caso de uso del tipo Comunicacin Actor/Sistema se transforma en, al menos, una interaccin entre las clases Actor y Sistema en los diagramas de secuencia. Obsrvese cmo los pasos de tipo Comunicacin Actor/Sistema de la especificacin del caso de uso Venta de Artculos (Fig. 6) se corresponden con interacciones entre el actor Cajero y el STV en el diagrama de secuencia de la Figura 10. Cada paso de un caso de uso del tipo Respuesta del Sistema se convierte en, al menos, una autointeraccin de la clase Sistema en el formato bsico de los diagramas de secuencia (donde no aparecen an todas las clases que participan en el escenario). Cada paso de un caso de uso de tipo Respuesta del Sistema se transforma en, al menos, una interaccin entre el Sistema y una clase-servidora o bien entre una clase cliente y una clase servidora en el formato extendido de los diagramas de secuencia (con todas las clases participantes en el caso de uso correspondiente). En la Figura 10 es posible observar la correspondencia entre los pasos de tipo Respuesta del Sistema del caso de uso Venta de Artculos y los correspondientes mensajes en el diagrama de secuencia. Ntese, por ejemplo, que el Paso 7 de la especificacin de este caso de uso (Fig. 6) deriva en tres interacciones en el diagrama (Fig. 10). Una de estas interacciones se realiza entre el STV y la clase Venta mientras que los otros mensajes son intercambiados entre clases del dominio. Las condiciones (bifurcaciones e iteraciones) en un caso de uso son tambin condiciones (bifurcaciones e iteraciones) en los diagramas de secuencia (Fig. 6 y Fig. 10). Para los casos de uso incluidos o que extienden as como para las trayectorias alternas, se construyen diagramas de secuencia por separado, mantenindose las mismas reglas de trazabilidad expuestas. La trazabilidad externa garantiza que la informacin generada a travs del Proceso de Anlisis de Requisitos pueda utilizarse en la construccin del Modelo Conceptual OO-Method. A continuacin se describen algunos de estos vnculos: Cada una de las clases identificadas en los diagramas de secuencia es tambin una clase en el Modelo de Objetos. La Figura 11 muestra las clases que participan en el escenario del caso de uso Venta de Artculos de la Figura 10. Tal representacin es una vista parcial del Modelo de Objetos del STV. Cada mensaje de tipo servicio de los diagramas de secuencia se corresponde con una operacin de la clase servidora de dicho mensaje (Fig. 9). Por ejemplo, el mensaje CrearVenta que se observa en el diagrama de secuencia con el estereotipo <<new>> es, en el Modelo (Parcial) de Objetos, un servicio de la clase Venta (Fig. 11). La existencia de mensajes estereotipados <<query>> denotan la necesidad de conocer el estado de un objeto desde otro. Esto tambin se considera para establecer una relacin de agregacin entre estas clases. Cada mensaje estereotipado como <<select>> en los diagramas de secuencia representa una relacin de agregacin establecida entre las clases cliente y servidora de dicho mensaje. Por ejemplo, la relacin de agregacin establecida entre las clases LneaVenta y Artculo de la Figura 11 resulta del mensaje de tipo seleccin para el que estas clases son respectivamente, las clases cliente y servidora en el diagrama de secuencia de la Figura 10. Por otra parte, la cardinalidad tambin puede derivarse haciendo un estudio de todas las relaciones de agregacin identificadas en cada uno de los escenarios de los casos de uso. Las transacciones globales son grupos de servicios que incluyen diferentes objetos. Cada escenario es un candidato a transaccin global.

:STV :Cajero

:Venta

:LneaVenta

:Artculo

Paso 2

Inicia sesin de venta Presenta nueva venta Paso 7 CrearVenta <<new>>

Paso 3

Paso 4 Paso 5

[Artculo a vender]* Introduce ID de artculo Introduce cantidad vendida de artculo

Paso 6 ConsultarInformacin <<query>> Paso 7 CrearLneaVenta <<new>> Paso 7 ArtculoVendido <<select>> Paso 8 CalcularSubtotal <<query>> Paso 9 ActualizarCantidad <<update>>

Paso 10 Paso 11 Paso 12

Muestra informacin del subtotal Pregunta si la venta ha concluido Finaliza venta Muestra informacin del total Paso 13 CalcularTotal <<query>>

Paso 14

FIG. 10. UN ESCENARIO DEL CASO DE USO VENTA DE ARTCULOS DEL STV

5. Conclusiones y trabajos futuros

* IdLineaVenta IdVenta En este trabajo se present el enfoque de Ingeniera de Fecha Cantidad Total Requisitos para el modelado conceptual en OO-Method. Para esto se describi, en primer lugar, el Modelo de Requisitos que CrearVenta CrearLineaVenta EliminarVenta EliminarLineaVenta RegistrarVenta RegistrarLineaVenta permite capturar y especificar los requisitos de los usuarios CalcularTotal VerificarPago aplicando convenientemente tres tcnicas: la Misin del sistema, la construccin del rbol de Refinamiento de Funciones y la especificacin del Modelo de Casos de Uso. En segundo lugar, se defini un Proceso de Anlisis de Requisitos Pedido Artculo que permite, a travs de la identificacin de responsabilidades IdPedido IdArtculo Fecha Nombre en el mbito de cada escenario de un caso de uso, representarlas PrecioUnidad CantidadEnExistencia como mensajes estereotipados con Diagramas de Secuencia. De Mnimo CrearPedido CrearArtculo esta forma se aade informacin sobre la descomposicin ActualizarCantidad AvisoCompra interna del sistema deseada y se facilita la construccin del ConsultaArtculo Modelo Conceptual OO-Method analizando los diagramas de secuencia resultantes. FIG. 11. MODELO (PARCIAL) DE OBJETOS DEL STV De esta forma, se tiene un fundamento para cada uno de los conceptos que aparecen en el Modelo Conceptual y se asegura la trazabilidad entre estas fases del desarrollo. Como aportes concretos del mtodo propuesto cabe mencionar: El uso de tcnicas sencillas y complementarias para la completa especificacin de requisitos funcionales La definicin de una estructura de casos de uso y aplicacin de niveles de abstraccin coherentes gracias al uso del rbol de Refinamiento de Funciones. El uso de dos formatos de diagramas de secuencia. El primero obtenido automticamente a partir de la especificacin de pasos del caso de uso y el segundo como evolucin del primero incorporando la descomposicin interna del sistema.
1..1 1.. 0..M 1..1 0..M 1..1

Venta

LneaVenta

La aplicacin de cuatro estereotipos definidos en trminos de la informacin que pueden aportar los mensajes para la construccin del Modelo Conceptual OO-Method. El detalle de trazabilidad entre requisitos y modelo conceptual. Este trabajo es el resultado de un proyecto desarrollado por la Universidad Politcnica de Valencia conjuntamente con CARE Technologies S.A. y Consoft S.A. Durante su desarrollo, ha sido de mucho inters transferir los resultados de la investigacin acadmica al mbito industrial para su posterior evaluacin. La adopcin de esta aproximacin de la Ingeniera de Requisitos por parte de estas empresas se debe, en gran medida, al conjunto compacto y estable de las tcnicas y mtodos propuestos as como a la trazabilidad existente entre los elementos de modelacin utilizados. El enfoque ha sido aplicado exitosamente en dos proyectos de tamao medio en los que se observaron, entre otras, las siguientes ventajas: Superacin de la ambigedad existente en torno al proceso de construccin del Modelo Conceptual OO-Method mediante la utilizacin del Modelo de Requisitos y el Proceso de Anlisis de los mismos. El impacto de los cambios en los requisitos de los usuarios fue fcilmente auditado y transformado en soluciones especficas a travs de los mecanismos de trazabilidad. Como consecuencia de estos resultados se esta desarrollando en CARE Technologies S.A. una herramienta CASE que soporte este mtodo de requisitos y se integre con la herramienta CASE de OO-Method (SOSY Modeler). Dicha integracin permitir automatizar la trazabilidad entre los requisitos, el modelo conceptual y el sistema de software generado. Varios son los trabajos futuros a realizar en este contexto. Es de particular inters la extensin del mtodo de forma a introducir informacin necesaria para la generacin automtica de casos de prueba basados en los diagramas de secuencia construidos. Tambin la identificacin y especificacin de requisitos no funcionales, la gestin de cambios y la generacin de informes personalizados son otras de las actividades a llevar a cabo.

Referencias
[Coc 97a] [Coc 97b] [Con 95] [CL 99] [CL 00] [DM 01] [Gra 98] [Got 95] [IPW 02] [Lar 98] [Jac&Al 92] [Mar 89] [MP 84] [OMG 01] COCKBURN A. Goals and Use Cases. Journal of Object-Oriented Programming 10(5): 35-40. Sep/Oct, 1997. COCKBURN A. Using Goal-Based Use Cases. Journal of Object-Oriented Programming 10(7): 5662. Nov/Dec, 1997. CONSTANTINE L. Essential Modeling: Use Cases for User Interfaces. ACM Interactions, 2(2): 34-36. April, 1995. CONSTANTINE L., LOCKWOOD L. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley. Boston,1999. CONSTANTINE L., LOCKWOOD L. Structure and Style in Use Cases for User Interface Design. http://www.forUse.com DAZ I., MATTEO A. Alternativas Gramaticales del Espaol y la Especificacin de Casos de Uso. XXVII Conferencia Latinoamericana de Informtica CLEI`2001. Mrida (Venezuela). GRAHAM I. Requirements Engineering and Rapid Development. An Object-Oriented Approach. XXVII Addison-Wesley, 1998. GOTEL O. Contribution Structures for Requirements Traceability. PhD Thesis, Imperial College. Department of Computing. London-England, 1995. INSFRAN E., PASTOR O., WIERINGA R. Requirements Engineering-Based Conceptual Modeling. Accepted for the Requirements Engineering Journal. LARMAN C. Applying UML and Patterns. Prentice Hall. Upper Saddle River NJ, 1998. JACOBSON I., CHRISTERSON M., JONSSON P., OVERGAARD G. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley,1992. MARTIN J. Information Engineering. Book I: Introduction. Prentice-Hall, 1989. McMENAMIN S.M., PALMER J.F. Essential Systems Analysis. Prentice-Hall, 1984. OMG Unified Modeling Language Specification. Version 1.4. Sept, 2001. http://www.omg.org/uml

[PR 95]

PASTOR O., RAMOS I. OASIS Version 2 (2.2): A Class-Definition Language to Model Information Systems. Servicio de Publicaciones Universidad Politcnica de Valencia, Espaa. 1995. SPUPV-95.788. PASTOR O., INSFRAN E., PELECHANO V., ROMERO J., MERSEGUER J. OO-Method: An OO Software Production Environment Combining Conventional and Formal Methods. In 9th Conference on Advanced Information Systems Engineering (CAiSE97), p. 145-159. Barcelona (Espaa), June 1997. Springer-Verlag. LNCS (1250). ISBN: 3-540-63107-0. PASTOR O., GMEZ J., INSFRAN E., PELECHANO V. The OO-Method Approach for Information Systems Modelling: from Object-Oriented Conceptual Modeling to Automated Programming. Information Systems 26(7): 507-534, 2001. REGNELL B., KIMBLER K., WESSLEN A. Improving the Use Case Driven Approach to Requirements Engineering. Second IEEE International Symposium on Requirements Engineering. IEEE, March 1995. WIERINGA R. J. Postmodern Software Design with NYAM: not yet another Method. Requirements Targeting Software and Systems Engineering, p. 69-94. 1998. WIERINGA R. J. TRADE: Techniques for Requirements and Design Engineering of Software Systems. Technical Report, Computer Science Department. University of Twente, Enschede, the Netherlands. June 1999. WIRFS-BROCK R. Designing Scenarios: Making the Case for a Use Case Framework. Smalltalk Report, p. 9-20. Nov/Dec, 1993. WIRFS-BROCK R., WILKERSON B., WIENER L. Designing Object-Oriented Software. Prentice Hall. Englewood Cliffd NJ, 1990.

[Pas&Al 97]

[Pas&Al 01]

[RKW 95]

[Wie 98] [Wie 99]

[Wir 93] [WWW 90]