Laura RIVERO, Jorge DOORN= , Mariana del FRESNO, Virginia MAUCO, Marcela RIDAO, Carmen LEONARDI
Universidad Nacional del Centro de la Provincia de Buenos Aires.
Facultad de Ciencias Exactas - Instituto de Sistemas de Tandil - ISISTAN

lrivero@exa.unicen.edu.ar
jdoorn@exa.unicen.edu.ar
mdelfres@exa.unicen.edu.ar
vmauco@exa.unicen.edu.ar
mridao@exa.unicen.edu.ar
cleonard@exa.unicen.edu.ar
 

El desarrollo de productos informáticos seguros y confiables es crucial. La Ingeniería de Requisitos desempeña un rol fundamental en este proceso, ya que enfoca un área substancial: la definición de lo que se desea producir. Un enfoque novedoso [8] presenta una metodología basada en el uso de LEL (Language Extended Lexicon) para registrar el vocabulario de un macrosistema y escenarios para modelar el comportamiento, extendida con la incorporación de heurísticas para la derivación de un modelo conceptual de objetos a través de tarjetas CRC. En este trabajo se exponen las experiencias obtenidas a partir de la aplicación de la metodología a un caso de estudio. Fue seguida etapa por etapa, respetando las heurísticas establecidas en forma estricta, requiriendo en algunos casos de la guía de los autores del método. Durante el desarrollo del caso se detectaron algunas ambigüedades que no resultaban evidentes en un análisis teórico. En el presente artículo se resumen las etapas de la metodología, indicando en cada una de ellas los inconvenientes encontrados al desarrollar el caso de estudio. Se sugieren cambios en algunos casos y en otros se deja el espacio de discusión abierto.
 

Palabras Clave: Análisis Orientado a Objetos, Escenarios, LEL, Rastreabilidad.

Building a secure and reliable software system is crucial. Requirements Engineering plays a main role in this process, because it helps to decide precisely what to build. A singular approach [8] proposes a methodology based in the LEL (Language Extended Lexicon) to record the terminology of the macrosystem and scenarios to model the behavior; a set of heuristics is added in order to obtain an object oriented conceptual model through CRC cards. In this paper the experiences achieved applying the methodology to a real case, are exposed. It was followed stage by stage in a strict way, requiring in some opportunities the assessment of its authors. During the analysis of the real case, some ambiguities were detected which were not evident when the theoretical study was done. The different stages of the methodology are briefly described indicating in each one the drawbacks that had to be coped with. It is suggested some changes in certain cases while in others an open space to discuss is left.

  Key Words: Object Oriented Analysis, Scenarios, LEL, Traceability.

1. Introducción

Es un hecho indudable que los sistemas computacionales están presentes en todos los aspectos de la vida moderna. Baste por ejemplo mencionar sistemas de información en medicina, en la industria aeroespacial, en empresas, etc. Un producto de software y la información que maneja constituyen activos fundamentales en las empresas que los poseen, cualquiera sea su naturaleza. Es importante notar que los productos de software son útiles principalmente para obtener de la información almacenada, nueva información derivada que permita tomar decisiones y obrar. Por consiguiente, es natural suponer que de la confiabilidad del sistema de software se deducirá la confiabilidad de la información resultante. Los errores en el software pueden producir en un plazo no determinado perjuicios no sólo económicos, sino también pérdida de vidas humanas, daños ambientales de diversa gravedad, etc. A pesar de ser un tema crucial, el desarrollo de software en la actualidad todavía está sujeto a procesos de producción informales, parciales y en algunos casos no confiables.

La Ingeniería de Requisitos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema. Esta disciplina establece el proceso de definición de requisitos como una sucesión de actividades mediante la cual lo que debe hacerse se "elicita", se modela y analiza. En este proceso se deben conciliar diferentes puntos de vista y utilizar una combinación de métodos, personas y herramientas. El resultado final constituye la documentación de los requisitos. Éstos deben expresarse de forma clara y estructurada de manera que puedan ser entendidos tanto por expertos como por el usuario, quien deberá participar en la validación [13].

Existen varios enfoques para analizar los requisitos, cuyas especificaciones son en general producidas teniendo en cuenta al usuario. El diseño centrado en el punto de vista del usuario para definir los requisitos es el enfoque al que adhieren recientes metodologías, por ejemplo en [1], OBA [11] y Objectory [2] que propone la especificación de "casos de uso" que complementen satisfactoriamente las características que propone el mencionado enfoque. Durante esta etapa la interacción con el usuario es indispensable, por lo cual estas herramientas deben ser relativas al lenguaje que ellos manejan para facilitar la comunicación.

En [4] se propuso el uso de LEL (Language Extended Lexicon) para modelar el vocabulario de un macrosistema y en [3, 6] escenarios para representar el comportamiento. Estas herramientas forman parte de la "Requirements Baseline" [5]. En [7] y [8] se propuso una extensión a [6] incorporando un modelo conceptual de objetos que representa al macrosistema.

Esta estrategia está basada en la construcción del LEL y escenarios y contiene un conjunto de heurísticas para identificar clases candidatas, sus responsabilidades y colaboraciones a los efectos de construir las tarjetas denominadas CRC. De esta forma, cubre los aspectos mencionados anteriormente a la vez que permite a los analistas visualizar el sistema desde el punto de vista de la tecnología de objetos, modelando al dominio en términos de los objetos que componen la aplicación, sirviendo de base para el desarrollo de software orientado a objetos. Esta metodología es de reciente introducción y no se conocen reportes independientes acerca de su uso, inconvenientes y utilidad. Por esta razón, y con el propósito de contribuir a su evaluación, fue aplicada a un caso concreto. Se desarrollaron el LEL y los escenarios, y se derivaron las tarjetas CRC correspondientes a un sistema de Planes de Ahorro Previo para la adquisición de vehículos. Este trabajo fue desarrollado por cinco de los autores del presente reporte con el asesoramiento de los creadores de la metodología pero sin su participación directa, ni revisión de resultados intermedios. Como consecuencia de esta actividad se logró un ámbito de trabajo razonablemente independiente pero bien predispuesto para aplicarla, lo que de alguna manera se constituyó en una suerte de beta-test de la misma. El equipo de trabajo realizó la totalidad de los pasos requeridos en forma conjunta. La metodología fue seguida etapa por etapa, respetando las heurísticas establecidas en forma estricta. Esta forma de trabajo permitió detectar algunas imprecisiones que no resultan visibles en un estudio teórico del método.

En el presente artículo se reseñan brevemente las etapas de la metodología a partir de la sección 3 y se describen y ejemplifican los inconvenientes encontrados, proponiéndose en algunos casos cambios a la misma y dejando la cuestión abierta en otros.

El caso de estudio corresponde a un Sistema de Planes de Ahorro Previo para la Adquisición de Vehículos 0Km [9]. Existen concesionarias (denominadas Administradoras) que se dedican a gestionar y administrar dichos planes. Los interesados en adquirir unidades 0Km constituyen grupos de una cierta cantidad de personas físicas o legales y participan mensualmente de los sorteos y/o licitaciones que la Administradora organiza. Existen variadas situaciones por las cuales los integrantes de grupos pueden renunciar a su participación, por ejemplo cediendo sus derechos a otro interesado, por incumplimiento en el pago de cuotas, etc.; también es posible que traten de anticipar la entrega del bien que están adquiriendo a través de licitaciones, pago adelantado de cuotas, etc. En todas ellas arbitra la Administradora. Mensualmente se realiza un acto de adjudicación, fiscalizado por un letrado, en el cual además de sortear el número del adherente que resultará favorecido de cada grupo, se abren las ofertas de licitación si las hubiera. Del estudio de estas ofertas surge un beneficiario adicional. La Administradora además entiende en cuestiones legales tales como trámites sucesorios, contratación de seguros de vida y del automotor, intimaciones de pago, contratos con los fabricantes, etc.

El sistema es de una complejidad razonable y presenta una nutrida diversidad de situaciones, razón por la cual resultó adecuado para aplicar la metodología.
 
 

3. Aplicación de la Metodología al Caso de Estudio.

El esquema que resume la secuencia de etapas del método y el producto resultante en cada una de ellas se exhibe en la Figura 1. En las siguientes secciones las etapas son explicadas y a partir de su aplicación, se ilustra cada paso con el correspondiente al caso de estudio, indicándose si corresponde, los cambios sugeridos.

El LEL (Language Extended Lexicon) [4] es un modelo que permite documentar, en forma de hipertexto, los términos del lenguaje utilizado en el campo de aplicación en el que se desarrolle el sistema, sin necesidad de entender el problema. Consiste en una descripción de los términos significativos del macrosistema, acotando el lenguaje externo y enriqueciendo el interno, de manera tal que asiste en la comprensión de su significado, define claramente estos términos y elimina posibles inconsistencias, ambigüedades y malas interpretaciones de los símbolos que se manejan a lo largo de todo el proceso de desarrollo. Los términos del LEL definen objetos (entidades pasivas), sujetos (entidades activas), frases verbales y estados. Por cada entrada del LEL se especifica:

• Símbolo: nombre o frase que designa al término, con sus sinónimos en el dominio, si existiesen; pueden ser objetos, acciones, sujetos o situaciones.
• Noción: Definición del símbolo. Indica quién, cuándo ocurre, qué procesos involucra, qué significado tienen, etc. los símbolos.
• Impacto: Describe cómo influye el símbolo en el sistema: acciones que se ejecutan sobre otros objetos o que se aplican al que se está definiendo, situaciones derivadas de la que se está definiendo, etc. [7]. En la descripción de las nociones e impactos existen dos reglas básicas que se deben cumplir simultáneamente: "principio de circularidad" y "principio del vocabulario mínimo".

Durante el proceso de construcción del LEL se pudo comprobar que una de las dificultades más frecuentes fue la de precisar el nivel de detalle de algunos impactos. Esto ocurría especialmente en el caso de símbolos representando sujetos y objetos, en los que aparecía como natural una necesidad de expresar comportamiento. Las heurísticas disponibles no fueron de ninguna ayuda en este punto por lo que fue necesario recurrir a la asistencia de expertos y artículos sobre el tema. En todos los casos la recomendación fue optar por la variante más sucinta y evitar la inclusión de comportamientos. Pero, como se verá más adelante, durante la construcción de las tarjetas CRC es necesario recurrir a los impactos del LEL. En este punto se ha percibido una ambigüedad.

El primer pensamiento que tiende a zanjar esta situación es el de establecer que los impactos deben ser completos, y en consecuencia es necesario conocer las acciones que se ejecutan o se aplican al término que se está definiendo. En opinión de los autores, registrar las acciones que se ejecutan o se reciben en forma completa, sin registrar comportamiento, es un problema de enfoque. Por ejemplo, los impactos del ejemplo de la Figura 2. pueden ser escritos en las siguientes formas:

 Los escenarios especifican las posibles formas de usar el sistema para obtener alguna función necesaria para el usuario. Son derivados del léxico del macrosistema teniendo en cuenta las principales acciones desarrolladas por los actores, descriptas en los impactos del término correspondiente del LEL. Son usados para describir el comportamiento externo del sistema centrado en el punto de vista del usuario; son adecuados para validar las especificaciones de requisitos; ayudan a involucrar tempranamente al usuario; facilitan la interacción y proveen criterios de aceptación para la validación basada en requisitos. Asimismo se ha comprobado que el uso de escenarios ha adquirido un interés creciente debido a otras ventajas: facilitan el trabajo interdisciplinario con una continua interacción diseñador-cliente, diseñador-usuario; reducen la complejidad, puesto que obligan a la descomposición del problema del análisis de requisitos en tempranas etapas de diseño; tienen un rol importante en la identificación y manejo de excepciones y permiten alcanzar acuerdos parciales y consistencia sobre el sistema reduciendo el alcance de los procesos de discusión y acuerdo [14]. El modelo de escenarios forma parte de la extensión propuesta a la original de "Requirements Baseline" [4] con el objetivo de modelar aspectos de comportamiento. Esta propuesta [6] es una combinación de ideas presentadas en la literatura [15; 2; 11; 10]. Incorpora los siguientes conceptos respecto de los escenarios: i) evolucionan durante el proceso de desarrollo de software, ii) están naturalmente conectados con el LEL, iii) describen situaciones utilizando lenguaje natural.

La Figura 3a muestra un diagrama de Entidades y Relaciones que exhibe la estructura propuesta en [6] para la definición de escenarios. Cuando un episodio amerita la construcción de un nuevo escenario para describir la situación, se genera un sub-escenario.
 
 

El diagrama de la Figura 3a es muy ilustrativo y contribuye ciertamente a la descripción de las interrelaciones entre los componentes de un escenario. Sin embargo, unas pocas modificaciones al mismo debieran ser realizadas. Los cambios sugeridos se grafican en la Figura 3b.

• Es difícil de interpretar la relación entre ESCENARIO y EPISODIO, indicada "explicado como". Se entiende que ésta pretende registrar el hecho que un episodio puede ser un sub-escenario y que éste es un escenario de por sí. Se observa que en realidad existe una relación débil entre escenarios y episodios y que los mismos contienen una jerarquía de clases disjuntas. Un SUB-ESCENARIO es en realidad un ESCENARIO pero dada la poca expresividad del Modelo E-R para indicar roles, se ha optado por esta representación.
• No se refleja la relación ternaria existente entre EPISODIO-RECURSO-ACTOR, la cual contribuye a clarificar el vínculo que existe entre esas entidades.
• La relación recursiva entre episodios rotulada con "dispara" se ha renombrado "precede a" ya que su única justificación podría ser la necesidad de reflejar orden entre episodios.

Un escenario consta de componentes que se describen a continuación [6]. A algunas de ellas pueden asignárseles las nociones de Restricción y/o Excepción. Una restricción es el alcance o un requisito de calidad y es aplicada a contexto, recurso, episodio. Una excepción marca una situación singular aplicable a un episodio.

Título: Identifica a un escenario. En el caso de un sub_escenario el título es el mismo que la sentencia que contiene al episodio. Se especifica utilizando la siguiente sintaxis: Frase | ([Actor|Recurso}+Verbo+Predicado)

Objetivo: Establece la finalidad del escenario describiendo cómo se alcanza ese objetivo. Sintaxis: [Sujeto] +Verbo + Predicado

Contexto: Describe el estado inicial del escenario, las precondiciones, la ubicación física y temporal. Sintaxis: Ubicación + Estado, siendo el primero un sustantivo, y el segundo [Actor|Recurso] +Verbo+Predicado+{Restricción}

Recursos: Identifica las entidades pasivas con las cuales los actores trabajan. Sintaxis: Sustantivo + {Restricción}

Actores: Detalla las entidades que se involucran activamente en el escenario, generalmente una persona o una organización. Sintaxis: Sustantivo.

Secuencia de Episodios: Los episodios se presentan ordenadamente. Cada uno de ellos representa una acción realizada por un actor, con la participación de otros actores y la utilización de recursos. Un episodio puede ser expresado como un sub-escenario. Una excepción causa una interrupción en la evolución de un escenario, presentando un conjunto de acciones diferentes que se describe como un caso alternativo o como otro escenario. La posibilidad de registrar excepciones en escenarios ha sido cuestionada, en algunos casos argumentando que las discusiones sobre excepciones podrían distraer a los expertos del dominio, alejándolos de tratar los puntos centrales del sistema, en otros aduciendo que podría verse afectada la "vendibilidad" del sistema. Sin embargo, negar o descuidar importantes excepciones en ingeniería de requisitos, podría resultar en la disconformidad del cliente y altísimos costos a largo plazo [14].

La heurística de construcción de escenarios propone que el contexto se obtenga a partir de los impactos de los actores principales identificados en el LEL. Este procedimiento es muy apropiado pero debería agregarse, en el caso de sub-escenarios, la obtención de información de contexto mediante la inspección de los episodios que lo preceden en el escenario padre.

Otro aspecto que los autores entienden puede dar lugar a futuras mejoras de los escenarios deriva de la aparición de dos o más escenarios que contienen los mismos episodios, recursos y actores y cuya única diferencia reside en el contexto. En la Figura 4 se muestra un ejemplo donde se han unificado cuatro escenarios en uno solo vía la creación de un contexto que no responde a la sintaxis indicada, por lo que la sintaxis correspondiente a Contexto, podría ser modificada como: Ubicación + Estado {<conector lógico> (Ubicación + Estado)}, siendo <conector lógico>::= o | y.
 
 

La sintaxis propuesta inicialmente para construir los episodios es la indicada en la Figura 5a. Esta sintaxis contiene algunos errores menores que debieran corregirse:

• Una <sentencia no secuencial> puede estar constituida por una <series> conformada por una sola <sentencia> que a su vez puede ser una <sentencia no secuencial> lo que permite el anidamiento de sentencias no secuenciales, que no es el espíritu de las mismas.
• Una <sentencia no secuencial> puede incluir una <series> formada por una sola <sentencia> de cualquier tipo, cuando se espera que haya al menos dos <sentencia> entre #.

En la Figura 5b se propone una sintaxis ligeramente modificada que corrige estos aspectos, pero que tiene, en opinión de los autores, un aspecto opinable. Como resultado del caso de estudio, no se puede concluir ninguna recomendación, pero sí se puede plantear la posibilidad de eventuales mejoras luego de un estudio más profundo.
 
 

Sean los episodios registrados en el escenario de la Figura 6a.
 
 

La redacción y la lectura de este episodio están dificultadas por la repetición de condiciones que a su vez constituyen frases largas. Los especialistas de la informática naturalmente tienden a pensar que es mejor anidar el segundo SI dentro del primero, lo que generaría al menos dos cambios en la sintaxis:

• Admitir que el lugar ocupado por <sentencia episodio> en <sentencia condicional> pueda ser ocupado por más de una <sentencia>.
• Permitir que cualquiera de las sentencias que reemplazaron la <sentencia episodio> pueda a su vez ser condicional.

En este punto la discusión es: ¿qué clarifica más la lectura de los episodios de los escenarios: la presencia de condiciones exageradamente largas o la existencia de una sintaxis más elaborada?. No debe pasarse por alto que estas dos no son las únicas opciones para describir esta situación. Los episodios de la Figura 6a podrían haberse redactado tal como se indica en la Figura 6b. Está claro que la factorización realizada en la Figura 6b, generando un sub-escenario, mejora la lectura del episodio en cuestión, pero contribuye al incremento, tal vez nocivo, de los sub-escenarios contenidos en el conjunto de episodios. Evidentemente, una investigación estadística de más de un caso de estudio aplicando sistemáticamente cada posible solución, contribuiría a esclarecer este punto.

En este punto vale la pena remarcar la interacción entre el LEL y los escenarios para la definición del modelo de objetos. El LEL define, a través de sus impactos, el comportamiento global que tiene una entidad dentro del macrosistema, permitiendo definir las responsabilidades con un grado de abstracción mayor que el descripto en los episodios de los escenarios, evitando inspeccionarlos en una primera etapa. Por otro lado, actúa como filtro para concentrarse sólo en los términos significativos del sistema. Esta relación bidireccional permite establecer un substrato común de los términos utilizados por los diseñadores, expertos en el dominio y administradores. En el desarrollo de nuevos escenarios el diseñador emplea términos del LEL y establece un vínculo entre el escenario y el símbolo. Para términos que aparecen durante la construcción de un escenario, y no están previamente en el LEL, debe definirse una nueva entrada y luego establecer el vínculo. Estos vínculos asimismo sirven como caminos de acceso a los diferentes escenarios donde el término cumple un rol relevante [14].

Los escenarios pueden ser utilizados para encontrar los objetos, delinear sus responsabilidades y colaboraciones con otras clases y sus asociaciones [12], permitiendo construir un modelo estático del sistema. El objetivo de esta etapa es transformar la descripción en lenguaje natural de los escenarios en una estructura preliminar, por ejemplo a través de tarjetas CRC. El punto de partida es el modelo de escenarios y el LEL y las principales actividades son: i) identificar clases primarias; ii) identificar clases secundarias; iii) refinar colaboraciones y responsabilidades; iv) documentar las clases; v) definir un modelo de objetos.

Las heurísticas disponibles para la definición de las tarjetas CRC no mencionan la inspección de las nociones de los términos del LEL, habiéndose indicado que resulta suficiente el estudio de los impactos. Durante el proceso concreto de confección de las tarjetas CRC para el caso de estudio, fue necesario consultar también las nociones del LEL en un número significativo de casos. Esta consulta adicional fue necesaria para refinar la especificación del 20% de las clases primarias detectadas y aproximadamente del 60% de las clases secundarias. Las secundarias son las clases que reciben acciones y ello justifica un porcentaje más elevado de casos. Además, la indicación en las heurísticas de inspeccionar los impactos es demasiado lacónica ya que una cantidad importante de responsabilidades puede obtenerse siguiendo los hipervínculos consignados en estos impactos. Este hecho está profundamente relacionado con la contradicción descripta en la sección 3.1. y podría enunciarse que la redacción de los impactos del LEL orientada a los "qué" más la información obtenida vía los hipervínculos a los otros símbolos involucrados es equivalente a la incorporación de conducta en el LEL. Por lo tanto, si bien la mayor parte del trabajo se puede realizar inspeccionando sólo los impactos, se sugiere que se incluya la inspección de las nociones y de los términos vinculados en los impactos del LEL en forma sistemática en el método propuesto.

En el caso particular de las clases secundarias las guías provistas resultan claramente insuficientes para definir las responsabilidades de las mismas. La confección de las tarjetas CRC para el caso de estudio sólo permitió detectar el problema pero no se hizo evidente la forma de resolverlo. Sólo se puede aconsejar lo mismo que ha sido puntualizado en el párrafo anterior.

Como resultado de la aplicación del método al caso real mencionado, se puntualizan las siguientes consideraciones:

• Los impactos del LEL deben ser lo más completos que sea posible pero debe esmerarse su redacción tratando de registrar en los mismos el punto de vista de los "qué" evitando reflejar los "cómo".
• Se debiera especificar en las heurísticas el uso de episodios previos de un sub-escenario para la obtención del contexto del mismo. Parece razonable permitir que la sintaxis del contexto admita la combinación de contextos simples mediante el uso de conectores lógicos.
• La expresividad de los episodios condicionales y su eventual extensión es una cuestión abierta ya que es factible encontrar buenos contraejemplos a cualquier sugerencia.
• Se debiera especificar en la heurística de construcción de las tarjetas CRC la inspección de las nociones y los términos del LEL vinculados, además de los impactos.
• Finalmente se ha encontrado que la determinación de las responsabilidades de las clases secundarias no es siempre definible con las guías suministradas.

Al Profesor Dr. Julio Leite por habernos contagiado su entusiasmo por la Ingeniería de Requisitos en general y el estudio de los escenarios en particular.

[1] Hsia, Pei et. al. Formal Approach to Scenario Analysis. IEEE Software, march 1994. (33-40)

[2] Jacobson I. et al. Object Oriented Software Engineering: A Use-Case Driven Approach. Addison Wesley, 1992
[3] Kaplan,V.,Hadad, G., Oliveros, A., Uso de Lexico Extendido del Lenguaje (LEL) y de Escenarios para la Elicitacion de Requerimientos. Aplicación a un Caso Real, Informe de Investigación Dpto. de Investigación de la Universidad de Belgrano, Argentina
[4] Leite J.C.S.P., Franco A.P., O so de Hipertexto na Elicitaçao de Linguagens da Aplicaçao". IV Simpósio Brasileiro de engenharia de software Sau Pedro, 1990
[5] Leite J.C.S.P, Albuquerque Oliveira, A P. A Client Oriented Requirements Baseline. Proceedings of RE 95’: Second IEEE International Symposium on Requeriments Engineering. Inglaterra, Marzo 1995.
[6] Leite J.C.S.P., Rossi G.,et al. Enhancing a Requirements Baseline with Scenarios. Proceedings of RE 97’: International Symposium on Requeriments Engineering, IEEE. Enero 1997
[7] Leite, JCSP. Ingeniería de Requisitos. Notas de cátedra. 1997.
[8] Leonardi, M., Maiorana, V., Balaguer, F. Una Estrategia de Análisis Orientada a Objetos basada en Escenarios. Actas II Jornadas de Ingeniería de Software JIS97. Donostia, San Sebastián. España. Set.1997.
[9] Mauco, V.; Ridao, M.; del Fresno , M.; Rivero, L.; Doorn, J.Ingeniería De Requisitos, Proyecto: Sistema de Planes de Ahorro Reporte Final. ISISTAN. UNCPBA. diciembre1997.
[10] Potts, C. Using Schematic Scenarios to Understand user Needs. DIS’95
[11] Rubin, K. and Goldberg, A. Object Behavior Analysis. CACM, Vol.35, No. 9, September 1992.
[12] Rumbaugh, J., M. Blaha et al. Object-oriented Modeling and Design, Prentice Hall, 1991
[13] Rumbaugh, J. Getting Started: Using the Use Cases to Capture Requirements. JOOP, sept. 1994
[14] Weidenhaupt, K. et. al. Scenarios in System Developments: Current Practice. IEEE Software. Mar/Apr 98.
[15] Zorman L., REBUS: Requeriments Envisaging By Utilizing Scenarios, PhD Thesis, Univ. South California

---

---