Manual de Usuario RETO-UPV

Transcripción

1 UNIVERSIDAD POLITÉCNICA DE VALENCIA DEPARTAMENTO DE SISTEMAS INFORMATICOS Y COMPUTACIÓN - DSIC Manual de Usuario RETO-UPV (Requirements Engineering TOol) versión 0.91 Octubre 2003

2 2

3 Contenido 1. Introducción Modelo de Requisitos y Proceso de Análisis de Requisitos Misión del Sistema y Árbol de Refinamiento de Funciones Misión del Sistema Árbol de Refinamiento de Funciones Modelo de Casos de Uso Extensión Inclusión Especificación de Casos de Uso Proceso de Análisis de Requisitos Mensajes de Señal Mensajes de Servicio Mensajes de consulta Mensajes de conexión Descripción de la Interfaz Gráfica de RETO-UPV Interfaz General de RETO-UPV Menú General Interfaz de Árbol de Refinamiento de Funciones Interfaz de Lista de Acceso Rápido a Actores Interfaz de Lista de Acceso Rápido a Clases Interfaz de Acceso Rápido a Descripción Interfaz de Barra de Herramientas para Elementos de Acceso Rápido Interfaz de Barra de Herramientas Vertical Interfaz de Propiedades de Nodo Interfaz de Selección de Objetos Interfaz de Asignación de Autores y Stakeholders Interfaz de Recursos Interfaz de Edición de Diagramas de Casos de Uso Representaciones de Casos de Uso Representaciones de Actores Comunicación Interacción Generalización Nota Enlace a nota Interfaz de Especificación de Casos de Uso Interfaz de Especificación de Pasos Interfaz de Declaración de Extensiones Interfaz de Edición de Diagramas de Secuencia Representaciones de clases Mensajes Bloques Nota Enlace a nota Interfaz de Especificación de Mensajes Interfaz de Especificación de Objetos Interfaz de Especificación de Bloques Conclusiones

4 4

5 1. INTRODUCCIÓN Con las técnicas habituales de desarrollo de software, los requisitos de usuario normalmente vienen expresados de forma escasamente estructurada y sin ninguna correspondencia entre éstos y los elementos del modelo conceptual. Como esfuerzo para la superación de esta limitación el modelo de requisitos de OO-Method propone un enfoque sistemático de Ingeniería de Requisitos que define un proceso que posibilita la descomposición sistemática y repetitiva de los requisitos de software hasta obtener una especificación detallada que constituirá el modelo conceptual del sistema deseado. Este enfoque pretende mejorar la calidad del proceso de producción de software proporcionando predictivilidad, ya que el modelo conceptual se construye como una representación precisa, estructurada y bien definida de los requisitos de los usuarios, y por consiguiente aumentando la productividad, facilitando la incorporación en el modelo conceptual de cambios en los requisitos (gracias a la trazabilidad). El enfoque propuesto propone un Modelo de Requisitos que captura los aspectos funcionales del sistema, básicamente, mediante la aplicación de tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Además, se introduce un Proceso de Análisis de Requisitos que permite traducir el Modelo de Requisitos en el Modelo Conceptual manteniendo la trazabilidad entre ambos modelos. Este proceso ayuda a que toda la información capturada en el Modelo de Requisitos tenga una representación en el Modelo Conceptual. 5

6 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- 2. MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS En el presente apartado se presenta un enfoque de Ingeniería de Requisitos para el modelado conceptual de sistemas de información cuyo principal objetivo es proporcionar un conjunto de técnicas y guías para capturar los requisitos del software y analizarlos para que posteriormente puedan ser expresados en un esquema conceptual de OO-Method [OO-Method] garantizando la trazabilidad entre éstos. El enfoque se basa en un marco referencial de herramientas de especificación de requisitos (TRADE [IWPTRADE]) y un método gráfico orientado a objetos para el modelado conceptual con capacidades de generación automática de código (OO-Method). Se define la estructura y técnicas para la construcción de un Modelo de Requisitos Funcionales del sistema y a partir de este modelo, un Proceso de Análisis 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 representación perfectamente identificable en el Modelo Conceptual OO- Method y cada elemento del Modelo Conceptual tiene su origen en el Modelo de Requisitos [IDBMR], [CM-Extreme]. INGENIERÍA DE REQUISITOS MODELO DE REQUISITOS PROCESO DE ANÁLISIS DE REQUISITOS (PAR) MODELO CONCEPTUAL Misión del Sistema Árbol de Refinamiento Funcional Modelo de Casos de Uso Diagramas de Secuencia a Nivel de Análisis Tabla de Descomposición Funcional Modelo de Objetos Modelo Funcional Modelo Dinámico Figura 1. Relaciones entre Modelos El principal objetivo de la presentación de este enfoque de Ingeniería de Requisitos es introducir los conceptos que posteriormente podrán encontrarse en la herramienta RETO-UPV que va a ser desarrollada en el curso del proyecto. 6

7 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- El Modelo de Requisitos tiene como objetivo ofrecer una serie de técnicas y métodos para capturar los requisitos de los usuarios de una manera estructurada, así como facilitar la transición al Esquema Conceptual manteniendo la trazabilidad [IBPGCS], [IDBMR]. Para conseguirlo, el modelo emplea una aproximación basada en los casos de uso, la cual se usa ampliamente en entornos de ingeniería de requisitos, con la diferencia de que la información recolectada se orienta de cara a generar el esquema conceptual. Esta será la gran diferencia entre la herramienta que se pretende implementar y los diferentes entornos que incluyen posibilidades de captura de requisitos de usuario. La herramienta que se va a desarrollar estará pensada exclusivamente a la captura de estos requisitos dando la posibilidad a la posterior generación automática de esquemas conceptuales. De acuerdo a alcanzar la trazabilidad entre las fases de modelado de requisitos y de modelado conceptual, se define un proceso de análisis de requisitos, el cual provee un método sistemático en el proceso de la generación del esquema conceptual a partir del modelo de requisitos. Y serán precisamente el modelado de requisitos y el proceso de análisis de requisitos las dos técnicas a las que se va a dar soporte en la herramienta RETO-UPV para poder posteriormente pasar al modelo conceptual de forma automática. La finalidad del modelo de requisitos es capturar de una manera precisa lo que el cliente quiere que se construya. Además, el propósito es modelar los requisitos de tal manera que personas que no estén familiarizadas con la notación empleada puedan entenderlos y revisarlos. La notación es lo suficientemente precisa para que pueda servir de base para la fase de modelado conceptual. Los conceptos básicos de los que se hace uso son los actores y los casos de uso. Debido a que los casos de uso son simples y a que las descripciones de los casos de uso se fundamentan en conceptos naturales que pueden encontrarse en el espacio del problema, los clientes y los usuarios finales pueden participar activamente en el modelado de requisitos. A pesar de estas ventajas, existen dos inconvenientes principales: o Es difícil encontrar el nivel de abstracción correcto para especificar los casos de uso (lo que en realidad es un caso de uso) o También es complicado encontrar un proceso para analizar y traducir las especificaciones de los casos de uso en un modelo conceptual. A este proceso se le denomina síntesis [REG95]. Las técnicas que se utilizan en el modelo de requisitos presentado para solucionar estos problemas son las siguientes: 7

8 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- o Misión del Sistema (2.1.1): describe la finalidad del sistema en una o dos frases. También describe las responsabilidades más significativas así como una lista de características que el sistema no va a hacer. o Árbol de Refinamiento de Funciones (2.1.2): asociado al particionamiento de las interacciones externas de acuerdo a diferentes áreas del negocio u objetivos del negocio. o Modelo de Casos de Uso (2.2): incluye las especificaciones de Casos de Uso para especificar la composición de las interacciones externas y el Diagrama de Casos de Uso para mostrar la comunicación entre el entorno (actores) y el sistema. Utilizar la misión del sistema y el árbol de refinamiento de funciones conjuntamente con el modelo de casos de uso es la clave para encontrar un buen nivel de abstracción para los casos de uso, respondiendo a la pregunta de qué es realmente un caso de uso y paliando de esta manera la primera desventaja presentada anteriormente. 2.1 Misión del Sistema y Árbol de Refinamiento de Funciones Misión del Sistema Describe el propósito del sistema, sus responsabilidades y alcance. A través de la definición de su misión es posible determinar con precisión qué hará y qué no hará el sistema (ver Menú General (3.1.1) e Interfaz de Árbol de Refinamiento de Funciones (3.1.2)). 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. Figura 2. Ejemplo de Misión del Sistema en ejemplo Rent a Car 8

9 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS Árbol de Refinamiento de Funciones Descompone el sistema en interacciones externas, de acuerdo a algún criterio preestablecido como puede ser, las áreas u objetivos organizacionales, los actores y sus responsabilidades, etc. Las interacciones externas son organizadas en funciones que forman una jerarquía a manera de árbol, en cuya raíz se ubica la misión del sistema. Esta Misión del Sistema (2.1.1) es refinada hasta obtener otras funciones elementales representadas en la jerarquía a través de los nodos hoja. Este proceso descendente de refinamiento funcional puede generar distintos niveles de nodos, siendo aquellos que están entre la raíz y los nodos hoja denominados nodos intermedios. Un nodo intermedio es un sumario de funciones elementales. En general, una rama completa de nodos con origen en la raíz del árbol, representa toda la funcionalidad relativa a un área o actividad de la organización, según el criterio de descomposición utilizado. Una función 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. El Árbol de Refinamiento de Funciones (ver Menú General (3.1.1) e Interfaz de Árbol de Refinamiento de Funciones (3.1.2)) representa la descomposición jerárquica de las funciones de un sistema, independientemente de la estructura del mismo. El árbol resultante es una organización de interacciones externas que no dice nada acerca de la composición interna del sistema. Sin embargo, es un insumo muy útil para la construcción del Modelo de Casos de Uso pues permite iniciar su construcción con una clara delimitación de las funcionalidades y con un mismo nivel de abstracción: todo nodo hoja será un Caso de Uso. De esta forma se evitan confusiones sobre qué es un Caso de Uso y además hay un claro criterio de completitud: las hojas del ARF como refinamiento de la Misión del Sistema. 9

10 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Figura 3. Ejemplo de Árbol de Refinamiento de Funciones en ejemplo Rent a Car 2.2 Modelo de Casos de Uso El objetivo fundamental del Modelo de Casos de Uso es la especificación de actores y casos de uso y el establecimiento de las relaciones que entre ellos se producen. 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][UML Web Site]. El principal insumo requerido para el desarrollo de este modelo son las funciones elementales identificadas como nodos hoja en el Árbol de Refinamiento de Funciones del sistema (ver Misión del Sistema y Árbol de Refinamiento de Funciones (2.1)). Cada una de estas funciones elementales es considerada como un caso de uso en el modelo. Es decir, el conjunto de todos los casos de uso define la arquitectura funcional del sistema, estableciendo una sencilla división del mismo facilitando así la construcción del Modelo Conceptual. La combinación de Casos de Uso (o de escenarios, ver Proceso de Análisis de Requisitos (2.4)) se modela estableciendo relaciones entre ellos. Con esta finalidad, en la fase de Ingeniería de Requisitos se utilizan las relaciones de extensión e inclusión. La forma de representar estas relaciones de extensión e inclusión habrán de adecuarse a la forma en la que se especifican los Casos de Uso (2.3) y en la que se modelan los Diagramas de Secuencia (2.4) ya que estas dos herramientas son esenciales para conseguir la trazabilidad deseada entre el Modelo de Requisito y del Modelo Conceptual. 10

11 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS Extensión Se caracteriza por estar establecida entre dos casos de uso y se define como una relación dirigida que indica que una instancia de un caso de uso (el caso de uso base) puede ser incrementada con la estructura y comportamiento definido en otro caso de uso (el caso de uso que se extiende o caso de uso extensión). Un caso de uso puede extender muchos casos de uso y, un caso de uso puede ser extendido por más de un caso de uso. Figura 4. Relación extends en UML y en RETO-UPV La relación de extensión no implica que cada uno de los dos casos de uso que participan de la relación pierdan toda o parte de su funcionalidad ni que ninguno de los dos casos de uso dependa del otro. Cada uno de los dos casos de uso tienen vida propia y podrían ser ejecutados por separado, sin necesidad de que la relación se concrete. La relación de extensión establecida entre dos casos de uso puede incluir una condición que deberá cumplirse para que la extensión del caso de uso base pueda efectuarse. La solución propuesta por UML es semejante a la adoptada en RETO-UPV y consiste en una línea dirigida cuyo origen es el caso de uso extensión y su destino el caso de uso extendido. Además, RETO-UPV en su Interfaz de Especificación de Casos de Uso (3.7) proporciona las herramientas necesarias para establecer la condición de la extensión. 11

12 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Figura 5. Interfaz de Declaración de Extensiones en RETO-UPV La representación gráfica de la extensión en RETO-UPV se realiza bajo el entorno de la Interfaz de Edición de Diagramas de Casos de Uso (3.6) Inclusión La relación de inclusión es otra forma de relación entre dos casos de uso. La inclusión es una relación dirigida que indica que la funcionalidad definida en un caso de uso es incorporada o insertada por completo en otro (denominado caso de uso base). La inserción se efectúa en el lugar definido para tal fin en el caso de uso base. De esta forma, al realizarse la secuencia del caso de uso base e identificar el punto donde se debe concretar la inserción, se ejecuta el caso de uso incluido, finalizada su ejecución, continua desarrollándose la secuencia de acciones del caso de uso base. Un caso de uso incluido representa una funcionalidad encapsulada que puede ser reutilizada en muchos otros casos de uso. Un caso de uso puede ser incluido en más de un caso de uso y también es posible incluir en un caso de uso la funcionalidad de muchos otros casos de uso. La solución propuesta en UML es semejante a la adoptada en RETO-UPV y consiste en una línea dirigida cuyo origen es el caso de uso base y su destino el caso de uso incluido. 12

13 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Figura 6. Relación include en UML y en RETO-UPV La representación gráfica de la inclusión en RETO-UPV se realiza bajo el entorno de la Interfaz de Edición de Diagramas de Casos de Uso (3.6). Además, el Modelo de Requisitos contempla la posibilidad de identificar el momento en que se produce esta inclusión en el transcurso de la actividad del caso de uso, es decir, el momento en el que se detiene momentáneamente la ejecución del caso de uso base para pasar a la ejecución del caso de uso extendido y al finalizar éste, seguir la ejecución del caso de uso base donde se quedó. Este momento vendrá definido en forma de paso (ver más adelante) y RETO- UPV contempla esta posibilidad en su Interfaz de Especificación de Casos de Uso (3.7). 2.3 Especificación de Casos de Uso Básicamente, la especificación 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 satisfacción de los requisitos. La especificación de casos de uso es un proceso incremental e iterativo que toma la forma de un corto y genérico texto inicialmente, pero que sin embargo, a medida que se alcanza un mayor conocimiento del dominio, el texto crece en 13

14 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- tamaño y complejidad limitándose así la comprensión en etapas posteriores de construcción del sistema. Para minimizar el impacto de estos problemas, la descripción de los casos de uso se estructurará precisándose su nivel de detalle en términos de las necesidades del modelado y del momento de desarrollo del sistema. OO-Method [OO-Method] propone el paso como unidad estructural básica de la especificación de un caso de uso, y lo define como la descripción de una actividad realizada por el actor o el sistema durante la interacción desencadenada entre éstos para el logro de una funcionalidad. RETO-UPV adopta también el paso como unidad estructural básica como se verá en las secciones Interfaz de Especificación de Casos de Uso (3.7) e Interfaz de Especificación de Pasos (3.7.1). Un paso hace referencia únicamente a una de las siguientes situaciones: el actor envía información al sistema sobre una actividad, o bien el sistema envía información al actor sobre una actividad, o bien el sistema ejecuta una acción sobre sí mismo. Además un paso no puede descomponerse en otros pasos. Se puede decir que un paso es unidireccional y atómico. Un paso consta básicamente de acción, condición y ejecutor de la acción (un actor o el sistema), de forma que se podría describir mediante una oración simple (sujeto y predicado), garantizando su atomicidad y su unidireccionalidad. Así podríamos definir un paso mediante la siguiente estructura: [<condición>,] <actor> <sistema> <actividad> o Condición: Expresión que puede tomar un único valor de verdad. Restringe la ejecución de la actividad del paso al cumplimiento de un requisito previo. Esto es, la realización de la actividad depende del valor de verdad de la condición. Es opcional, como parte de la estructura del paso. o Actor o Sistema: Responsable de ejecutar la acción verbal de la actividad. Gramaticalmente, cumple la función de sujeto de la oración. 14

15 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- o Actividad: Descripción de la acción que realiza el actor o el sistema. Gramaticalmente, es el predicado de la oración. Se caracteriza por tener un único verbo. 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 especificación a través de una secuencia numerada de pasos (en RETO-UPV ver Interfaz de Especificación de Casos de Uso (3.7)). Esta secuencia discrimina los pasos según su naturaleza clasificando las acciones del actor de las ejecutadas por el sistema y distinguiéndolas de aquellas acciones relativas al contexto donde se desarrolla el caso de uso. La nomenclatura que propone OO-Method para esta clasificación es la siguiente: o 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 más próximo del caso de uso, promoviendo su activación o constituyéndose en receptores de ciertos resultados parciales o finales obtenidos a través de la ejecución del mismo. Los pasos generales no serán implementados como parte del sistema pero su conocimiento es importante para comprender mejor la funcionalidad descrita por el caso de uso. o Comunicación Actor / Sistema: describe una actividad realizada por el actor o el sistema a través de la que uno de éstos aporta información al otro. En términos de la unidireccionalidad de este tipo de pasos, si el actor es el emisor del mensaje, el sistema es el receptor o viceversa. Los pasos de Comunicación Actor / Sistema son de gran ayuda para capturar ciertos aspectos de la interfaz usuario del software en desarrollo. o Respuesta del Sistema: son actividades realizadas por el sistema que ocasionan un cambio en su estado. En este tipo de paso el sistema es el emisor y receptor del mensaje. En la especificación de casos de uso OO-Method se introduce el concepto de paso alternativo. Que se caracteriza porque describe una actividad 15

16 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- complementaria de alguno de los pasos de la trayectoria básica o de cualquiera de las trayectorias alternas. Por lo tanto un paso alternativo siempre está vinculado a algún paso de una de las trayectorias del caso de uso (ver Interfaz de Especificación de Casos de Uso (3.7)). La ejecución de un paso alternativo depende de la ejecución previa de un determinado paso (al que está vinculado) y del cumplimiento de su condición de activación. Un paso alternativo se utiliza para el manejo de excepciones funcionales relativas a la actividad descrita en el paso al que está vinculado. Entre casos de uso es posible establecer relaciones de inclusión o de extensión. Además de estas relaciones entre casos de uso, se introduce la relación de activación mediante la que se modela la incorporación condicionada o no de un caso de uso en otro, sin que exista entre éstos dependencia estructural ni funcional sólo de uso. Cuando el caso de uso base activa la funcionalidad descrita en otro caso de uso, se ejecuta la funcionalidad de esta último. Finalizada su ejecución, el caso de uso base continúa la realización de su trayectoria de eventos, independientemente de haber sido exitosa o no la realización de caso de uso activado. La incorporación de esta nueva relación establece un vínculo entre dos casos de uso, pero sólo a nivel de uso ya que estructuralmente no están relacionas entre sí. En general, el flujo de eventos de un caso de uso puede ser presentado como una lista numerada de pasos (ver Interfaz de Especificación de Casos de Uso (3.7)). Pero no siempre este flujo de eventos sigue una trayectoria secuencial, desarrollándose 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 carácter iterativo o repetitivo en atención al cumplimiento de una condición. 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 lógicas de control de la programación estructurada. 16

17 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Figura 7. Interfaz de Especificación de Casos de Uso en RETO-UPV 2.4 Proceso de Análisis de Requisitos Última fase y fase esencial del Modelado de Requisitos antes de poder aplicar la trazabilidad para hallar una primera aproximación del esquema conceptual del sistema que se modela. El propósito principal de este proceso es identificar las responsabilidades más significativas del sistema en desarrollo. Se define responsabilidad como una obligación que tiene un objeto con respecto a su propio comportamiento, lo que conlleva a la definición de operaciones, o mejor dicho, a la especificación de los servicios de una clase. Estas responsabilidades resultan en especificaciones de eventos o de transacciones. Con el propósito de describir las responsabilidades detectadas en el contexto de un caso de uso y sin pretender entrar en detalles propios de los esquemas 17

18 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- conceptuales, se utilizan los Diagramas de Secuencia. En estos diagramas se representan las responsabilidades identificando el objeto cliente y el objeto servidor, al que la responsabilidad pertenece (ver Interfaz de Edición de Diagramas de Secuencia (3.8)). Como ya se ha dicho, no se pretende crear un Esquema Conceptual, por lo que la especificación de los Diagramas de Secuencia para representar las responsabilidades de las clases se efectúa a muy alto nivel. En OO-Method la determinación de responsabilidades se realiza en el contexto de un escenario, que se define como un secuencia específica 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 compilación de múltiples 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 interacción entre instancias de clases. Esto puede realizarse a nivel de objetos o a nivel de clases. Estos diagramas muestran la secuencia ordenada en el tiempo de los mensajes que envían y reciben genéricamente los objetos durante la ejecución de un escenario. Se define mensaje como una comunicación entre dos objetos que se transmiten información con la finalidad de que se ejecute una actividad. Un mensaje especifica los roles que deben cumplir tanto el objeto cliente como el objeto servidor, así como la acción que será ejecutada. Resumiendo, el Proceso de Análisis de Requisitos consiste, básicamente, en la construcción de los Diagramas de Secuencia OO-Method a partir del Modelo de Requisitos del sistema [IPWRE]. 18

19 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Figura 8. Ejemplo de Diagrama de Secuencia. Los diagramas de secuencia, además de expresar en detalle los resultados del Proceso de Análisis de Requisitos, constituyen un recurso de mucha importancia para la construcción del Modelo de Objetos de OO-Method. Con esta finalidad, se ha incorporado en estos diagramas cierta información que resulta de interés para identificar elementos de este modelo. Esta información se expresa estereotipando los mensajes del diagrama de secuencia con el propósito de distinguirlos. En RETO-UPV se adopta esta misma forma de estereotipar los mensajes (ver Interfaz de Especificación de Pasos (3.7)). La clasificación para estereotipar mensajes, es la siguiente: Mensajes de Señal Son aquellos que representan una interacción entre el actor y el sistema. Su estereotipo es <<signal>>. El sistema se comunica con el exterior (representado por el actor) utilizando estos mensajes. La información recogida en estos mensajes permite realizar una interacción entre objetos de la clase sistema. Estos mensajes son muy importantes para la construcción de la interfaz de usuario. La única propiedad que discrimina este tipo de mensajes es la dirección del mensaje: 19

20 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- Propiedad Valor Descripción Direction {input} Aplicable a mensajes de tipo señal cuyo origen es una clase que representa a un actor del Diagrama de Casos de Uso y cuyo destino es la clase que representa al sistema. {output} Aplicable a mensajes en los que el origen es el sistema y el destino es una clase actor del Diagrama de Casos de Uso. Figura 9. Propiedades de mensajes <<signal>> Debido a que gráficamente es posible deducir el estereotipo y la propiedad de estos mensajes, no es necesario que el analista los represente explícitamente en el diagrama de secuencia. Es decir, no veremos el estereotipo <<signal>> representado en los diagramas de secuencia (como se ha implementado en la herramienta RETO-UPV, ver Interfaz de Edición de Diagramas de Secuencia (3.8)) Mensajes de Servicio Los mensajes estereotipados con la etiqueta <<service>>, representan la modificación del estado instancia de la clase receptora del mensaje. Los mensajes de tipo servicio, pueden realizarse como consecuencia de la ejecución secuencial de mensajes en el Diagrama de Secuencia en cuestión. En este caso puede tomar el valor new, destroy o update. Propiedad Valor Descripción {new} Presenta un cambio de estado fuerte porque se aplica a mensajes cuyo destino es una clase del sistema en la cual se desea crear un nuevo elemento que cumpla todas las características de dicha clase. Kind of Change {destroy} {update} Aplicable a mensajes en los cuales se desea borrar un elemento de la clase destino. Por ello presenta un cambio de estado fuerte. Aplicable a mensajes cuyo destino es una de las clases del sistema y modifica su estado. Este tipo de mensaje permite que se produzca un cambio de estado débil en el elemento de la clase receptora del mensaje. Figura 10. Propiedades de mensajes <<service>> 20

21 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS Mensajes de consulta Los mensajes de consulta, son estereotipados con la etiqueta <<query>> y representan consultas sobre el estado de un objeto. Para que un objeto pueda conocer parte del estado de otro objeto establece una interacción entre ellos. El conjunto de propiedades que el analista puede asignar a estos mensajes, es el siguiente: Propiedad Valor Descripción atributo derivado Aunque es una propiedad, notacionalmente no se representará de la forma tradicional sino como se muestra a continuación: Atributo Derivado = nombre del mensaje descripción cardinalidad {0..1} {0..M} {1..1} {1..M} Descripción de la consulta que es escrita en lenguaje natural. En esta propiedad es recomendable que el analista especifique las características de la consulta. Número de objetos involucrados en la consulta (cardinalidad). La constante M puede ser un número mayor a 1. Es una propiedad opcional. Figura 11. Propiedades de mensajes <<query>> Mensajes de conexión Los mensajes con el estereotipo <<connect>> se utilizan para establecer una relación estructural entre los objetos participantes en la interacción. La aparición de un mensaje de este tipo en un escenario está supeditada a la ejecución de un mensaje estereotipado como service, es decir, un mensaje de tipo selección se activa cuando en un mensaje de tipo servicio aparece la necesidad de establecer o eliminar vínculos entre los objetos de las clases que participan en esta interacción. 21

22 -MODELO DE REQUISITOS Y PROCESO DE ANÁLISIS DE REQUISITOS- El analista puede dar información sobre las siguientes propiedades: Propiedad Valor Descripción Cardinalidad Mínima {0} {1}... {M} Número mínimo de objetos que puede ser seleccionado de la clase destino. El rango de valores a seleccionar se encuentra entre 0 y M elementos. Cardinalidad Máxima Actividad {0} {1}... {M} {Inserción} {Borrado} Máximo número de objetos que puede ser seleccionado de la clase destino de la interacción. El rango de valores a seleccionar, al igual que en la cardinalidad mínima, se encuentra entre 0 y M elementos. La actividad de un mensaje es de inserción cuando es necesario relacionar elementos que ya han sido creados, con algún objeto de la clase que envía el mensaje. La actividad de un mensaje es de borrado cuando desea quitarse una selección que se ha establecido entre los elementos de una interacción. En el ejemplo presentado a continuación se observa la utilización de los estereotipos en los mensajes: Figura 12. Ejemplo de mensajes en un Diagrama de Secuencia. 22

23 3. DESCRIPCIÓN DE LA INTERFAZ GRÁFICA DE RETO-UPV 3.1 Interfaz General de RETO-UPV El elemento de nivel superior de la herramienta es el proyecto, que engloba todos los otros conceptos del Modelo de Requisitos. Al iniciar la herramienta, se carga la ventana principal de la herramienta y que representa la Interfaz General de RETO-UPV, que se encuentra dividida en los siguientes grupos. Figura 13. Interfaz General de RETO-UPV 23

24 3.1.1 Menú General Desde la barra de menús se puede acceder a gran parte de la funcionalidad de la herramienta. Las funcionalidades de sus menús desplegables son: o Menú File. Este menú contiene opciones típicas para la gestión de ficheros del proyecto (Opciones New Project, Open Project, Save Project y Save Project As y Salida (Opción Exit Project). Figura 14. Menú File o Menú Edit. Este menú contiene opciones típicas de edición (Opciones Copy, Paste, Cut, Select All, etc...). Figura 15. Menú Edit o Menú View. Este menú contiene opciones para mostrar u ocultar los diversos paneles que forman la sección de visualización rápida (Function Refinement Tree, Actors, Classes, Description), así como opciones de Zoom (Opciones Zoom In y Zoom Out). Figura 16. Menú View o Menú Project. Este menú contiene solamente una opción que lleva al usuario a la Interfaz de Asignación de Autores y Stakeholders (3.4). 24

25 Figura 17. Menú Project o Menú Resources: Mediante las opciones de este menú se accede de forma inmediata a la Interfaz de Recursos (3.5) (Opciones Actors, Classes, Authors, Stakeholders, Non Funcional Requirements). Figura 18. Menú Resources o Menú Window: Este menú ofrece opciones básicas de manejo de las ventanas abiertas en cierto instante (Opciones Cascade, Tile) Figura 19. Menú Window Además de estas opciones existe un a pequeña barra de herramienta que implementa cinco de estas opciones, tomadas como más usuales. Figura 20. Opciones más habituales Interfaz de Árbol de Refinamiento de Funciones Esta interfaz presenta de forma jerárquica los diferentes elementos que conforman el Árbol de Refinamiento de Funciones. En el árbol podemos encontrar la misión del sistema en la raíz, los grupos funcionales como nodos internos y las funciones elementales como nodos hoja. 25

26 Figura 21. Interfaz de Árbol de Refinamiento de Funciones Además de presentar el árbol de refinamiento de funciones, esta interfaz incluye toda la funcionalidad necesaria para la gestión de este árbol que conjuntamente con la ayuda de la botonera de la Interfaz de Barra de Herramientas para Elementos de Acceso Rápido (3.1.6) proporcionan un entorno ideal para la gestión del árbol. El árbol se muestra sus elementos mediante un nombre que identifica el nodo y un icono que identifica el tipo de nodo del que se trata. El icono para la misión y para los grupos funcionales será, mientras que el icono para las funciones elementales será. Además el árbol incluye una funcionalidad adicional a la proporcionada por la definición de Árbol de Refinamiento de Funciones (2.1.2). El árbol muestra también los Diagramas de Secuencia asociados a cada función elemental (caso de uso). Para ello se vale de un tercer icono que identifica este tipo de nodo,. Esta funcionalidad añadida no modifica el Modelo de Requisitos (2), sino que es una solución propuesta para la herramienta RETO-UPV, como facilidad para el usuario. Figura 22. Detalle de Diagramas de Secuencia en la interfaz 26

27 Es en los menús contextuales donde se encuentra la funcionalidad particular de la interfaz. Estos menús varían dependiendo del tipo del elemento sobre el que se ha mostrado: o Misión del sistema y grupos funcionales. En este menú aparecen las opciones New Functional Group y New Function, que crean respectivamente un nuevo grupo funcional y una nueva función descendientes directos del nodo seleccionado. La opción Remove Functional Group aparecerá solamente en los nodos intermedios y no en la misión y eliminará automáticamente el grupo funcional y todos los nodos descendientes sean del tipo que sean. Por último, la opción Open Diagram transporta al usuario a una ventana del tipo Interfaz de Edición de Diagramas de Casos de Uso (3.6), donde se podrá editar el diagrama de casos de uso perteneciente al grupo funcional el cuestión (o a la misión) y la opción Properties, que transporta al usuario a la Interfaz de Propiedades de Nodo (3.2), donde se podrán introducir información relevante de este tipo de nodos. Figura 23. Detalle menú contextual de un grupo funcional o Funciones elementales. Este menú pertenece a los nodos hoja del árbol de refinamiento de funciones, es decir a las funciones elementales o casos de uso. Podemos encontrar las opciones Add Sequence Diagram que añaden un nuevo nodo hijo del tipo Diagrama de Secuencia, y la opción Remove Function, que provocará la eliminación de la función elemental y de todos sus Diagramas de Secuencia. También encontramos la opción Specification que transporta al usuario a la Interfaz de Especificación de Casos de Uso (3.7) donde el usuario puede concretar la acción que conlleva la ejecución de la función en el sistema. Por ultimo nos encontramos con la opción Properties cuyo significado es equivalente al anteriormente comentado para grupos funcionales. Figura 24. Detalle menú contextual de una función elemental 27

28 o Diagramas de secuencia. Este menú solamente consta de dos opciones. La primera, Open Diagram, transporta al usuario a una ventana del tipo Interfaz de Edición de Diagramas de Secuencia (3.8) donde podrá editar el Diagrama de Secuencia correspondiente al nodo seleccionado. Y la segunda, Remove Secuence Diagram, que permite eliminar el diagrama de secuencia del modelo. Figura 25. Detalle menú contextual de un diagrama de secuencia Otra característica de esta interfaz es la posibilidad de cambiar un nodo determinado de padre, bajo ciertas restricciones. Podemos seleccionar un nodo y sin soltar el botón del ratón, moverlo encima de otro nodo para soltar entonces el botón, dependiendo del tipo de nodo que se mueva y del tipo de nodo sobre el que se libera, el resultado de la operación será diferente. Las restricciones de movimiento son: o Solamente es posible mover grupos funcionales y funciones, nunca la misión del sistema o diagramas de secuencia. o No es posible mover un grupo funcional a otro grupo funcional descendiente del primero. Los resultados del movimiento son: o Nodo (función o grupo funcional) sobre Grupo Funcional. Si el nodo no pertenecía al grupo funcional, este pasará a formar parte del grupo funcional y se situará en la última posición de los hijos de éste. Si el nodo pertenecía al grupo funcional entonces se situará en la última posición del mismo grupo funcional. o Nodo (función o grupo funcional) sobre Función. El nodo se situará justo bajo la función sobre la que se libera. Esta operación además puede suponer un cambio de grupo funcional Interfaz de Lista de Acceso Rápido a Actores Con el objetivo de poder acceder rápidamente a los recursos de tipo actor del sistema, la Interfaz de Lista de Acceso Rápido a Actores muestra la lista de actores del sistema sobre la que se puede realizar una serie de funciones básicas 28

29 como son la creación de nuevos actores, la eliminación de actores ya existentes o el cambio de nombre de los actores existentes. Figura 26. Detalle Interfaz de Lista de Acceso Rápido a Actoeres Para renombrar un actor basta con seleccionarlo y pinchar sobre él otra vez esperando que la interfaz ofrezca la posibilidad de renombrar el actor. La interfaz propone dos menús contextuales, uno sobre la zona sin utilizar el control, y otro sobre un actor ya creado. El primero de ellos solamente contiene una opción Insert New Actor que proporciona una forma rápida de crear nuevos actores. Figura 27. Detalle menú contextual Lista de Actores El segundo, sobre un actor, proporciona dos opciones, Delete from Model que elimina el actor del modelo, y Properties que traslada al usuario a la Interfaz de Recursos (3.5). Figura 28. Detalle menú contextual actor Interfaz de Lista de Acceso Rápido a Clases Esta interfaz tiene exactamente la misma funcionalidad que la Interfaz de Lista de Acceso Rápido a Actores pero referida a clases del sistema y no a actores. 29

30 Figura 29. Detalle Interfaz de Lista de Acceso Rápido a Clases En cuanto a los menús contextuales, el primero de ellos, aquel que aparece en la zona en blanco de la lista de clases, Insert New Class, nos propociona la posibilidad de crear una nueva clase de forma rápida. Figura 30. Detalle menú contextual Lista de Clases En cuanto al menú que aparece sobre una clase determinada, las opciones que aparecen son las mismas y con la misma funcionalidad que en la Interfaz de Lista de Acceso Rápido a Actores. Figura 31. Detalle menú contextual Clase Interfaz de Acceso Rápido a Descripción Esta interfaz proporciona una manera rápida de acceder a las descripciones de la mayoría de los elementos que pueden aparecer en el modelo. La interfaz muestra en todo momento la descripción del elemento seleccionado del sistema que puede ser: o Un nodo de la Interfaz de Árbol de Refinamiento de Funciones (3.1.2). o Un actor de la Interfaz de Lista de Acceso Rápido a Actores (3.1.3). o Una clase de la Interfaz de Lista de Acceso Rápido a Clases (3.1.4). o Cualquier elemento de la Interfaz de Edición de Diagramas de Casos de Uso (3.6). o Cualquier elemento de la Interfaz de Edición de Diagramas de Secuencia (3.8). 30

31 Figura 32. Detalle de Interfaz de Acceso Rápido a Descripciones Además permite la edición de estas descripciones y muestra bajo el cuadro de texto el nombre y tipo del elemento seleccionado en cada momento Interfaz de Barra de Herramientas para Elementos de Acceso Rápido Esta barra de herramientas se compone de cuatro secciones. La primera de ellas corresponde a utilidades de muestra / ocultación de las interfaces que tiene por debajo. Concretamente se compone de cuatro botones correspondientes a la Interfaz de Árbol de Refinamiento de Funciones Acceso Rápido a Actores, a la Interfaz de Lista de, a la Interfaz de Lista de Acceso Rápido a Clases, y a la Interfaz de Acceso Rápido a Descripción. Si cualquiera de estos botones se encuentra pulsado, entonces la interfaz correspondiente estará visible, si se encuentra desactivado, la interfaz no estará visible. Figura 33 Interfaz de Barra de Herramientas para Elementos de Acceso Rápido La segunda sección corresponde con tres funcionalidades pertenecientes a la Interfaz de Árbol de Refinamiento de Funciones. Son las tres funcionalidades más usuales de esta interfaz y crean (si es posible) sobre el nodo seleccionado, un nuevo grupo funcional, una nueva función, o un nuevo diagrama de secuencia. La tercera sección contiene una sola opción y corresponde con la creación de un nuevo actor en la Interfaz de Lista de Acceso Rápido a Actores. Por último, la cuarta sección, también contiene una sola opción correspondiente con la creación de una nueva clase en la Interfaz de Lista de Acceso Rápido a Clases. 31

32 3.1.7 Interfaz de Barra de Herramientas Vertical Esta interfaz es resulta esencial para trabajar con la Interfaz de Edición de Diagramas de Casos de Uso (3.6) y con la Interfaz de Edición de Diagramas de Secuencia (3.8). La interacción con esta barra de herramientas es la que hace posible la creación de los diferentes elementos de los diagramas de casos de uso y de los diagramas de secuencia. Las opciones que contiene la barra dependen de la ventana activa en la herramienta, si la ventana activa corresponde a la Interfaz de Edición de Diagramas de Casos de Uso, entonces aparecen utilidades de creación para diagramas de casos de uso, en cambio, si la ventana activa corresponde a la Interfaz de Edición de Diagramas de Secuencia, las utilidades de creación serán para diagramas de secuencia. Figura 34. Detalle barra de herramientas para diagramas de casos de uso y para diagramas de secuencia La barra de herramientas para diagramas de casos de uso contiene las siguientes opciones de creación: o o o o o o Una nueva representación de un actor Una nueva representación de un caso de uso Una nueva comunicación Una nueva generalización Una nueva nota Un nuevo enlace a nota (anchor note) 32

33 La barra de herramientas para diagramas de secuencia presenta las siguientes opciones: o o o o o o o o o Un nuevo mensaje general Un nuevo mensaje signal Un nuevo mensaje query Un nuevo mensaje service Un nuevo mensaje connect Una nueva representación de clase Un nuevo bloque Una nueva nota Un nuevo enlace a nota Tras la elección de una de estas opciones, el usuario tendrá que interactuar con una de las dos interfaces: Interfaz de Edición de Diagramas de Casos de Uso (3.6) y con la Interfaz de Edición de Diagramas de Secuencia (3.8). 3.2 Interfaz de Propiedades de Nodo En RETO-UPV a cualquier nodo del árbol de refinamiento de funciones se le podrá introducir cierta información adicional con respecto a temas del marco en el que se pretende crear la aplicación que se está modelando, como puede ser el tema de prioridades, documentación asociada, requisitos no funcionales... La Interfaz de Propiedades de Nodo engloba todas estas funcionalidades en un mismo formulario con varias pestañas de selección que separan informaciones de un mismo tipo o ámbito. En la primera de estas pestañas, llamada General, tenemos una visión del espacio de tiempo en el que se está desarrollando el nodo y de los responsables del éxito o fracaso de éste. Además nos aparece el nombre del nodo, que en este caso no es modificable. Podremos pues ver la fecha de creación del nodo y la fecha de última modificación. Además podremos asignar o desasignar autores y stakeholders al nodo. Un autor será un analista o usuario de la herramienta y un stakeholder será 33

34 cierta persona o entidad que tiene interés por el éxito del desarrollo del nodo. La designación de estos dos tipos de recursos se produce al pulsar alguno de los botones Add Autor y Add Stakeholders y la herramienta trasladar al usuario a la Interfaz de Selección de Objetos (3.3). Figura 35. Intefaz de Propiedades de Nodo General En la segunda pestaña encontramos toda la información sobre la prioridad del nodo. Esta se divide a su vez en cuatro subgrupos que contienen una serie de estado seleccionables: o Importance. Se refiere a la importancia en general que tiene el nodo dentro del global de nodos. La importancia se gradúa en High, Medium y Low. o Urgency. Se refiere a la necesidad temporal de completar la especificación del nodo. La urgencia se gradúa en High, Medium y Low. o Stability. Se refiere al grado de aceptación del nodo dentro del modelo. Es decir, una estabilidad alta supone que el nodo permanecerá seguro en el modelo y una estabilidad baja supone que tal vez el nodo desaparezca por falta de convicción en el analista de su 34

35 utilidad en el modelo. La estabilidad se gradúa en High, Medium y Low. o State. Se refiere al estado de completitud en la concepción y especificación del nodo. Se gradúa de menor a mayor completitud en Identified, Needs Analysis, Needs Verification, Verified, Needs Validation y Validated. Figura 36. Intefaz de Propiedades de Nodo Priority 35

36 La tercera pestaña corresponde a la descripción del nodo y la funcionalidad es la misma que en otras partes de la herramienta como en la Interfaz de Acceso Rápido a Descripción (3.1.5). Figura 37. Intefaz de Propiedades de Nodo Description La última pestaña, de nombre NFR and Docs, corresponde a la asignación de Requisitos No Funcionales y de Documentos asociados al nodo. Esta asignación, al igual que en el caso de autores y stakeholders, se produce por medio de la Interfaz de Selección de Objetos (3.3). 36

37 Figura 38. Intefaz de Propiedades de Nodo - NFR and Docs 3.3 Interfaz de Selección de Objetos Esta interfaz es llamada desde otras interfaces de la herramienta para permitir la selección de algún recurso. En ella aparece una lista de un mismo tipo de recurso, donde se puede seleccionar uno de ellos que será el que se devuelva a la interfaz llamante. Los tipos de recursos que podemos encontrar en esta interfaz son: actores, clases, autores, stakeholders y requisitos no funcionales. 37

38 Figura 39. Interfaz de Selección de Objetos 3.4 Interfaz de Asignación de Autores y Stakeholders Si se desea asignar en una misma sesión, los mismos autores y stakeholders a todos los elementos del modelo que los acepten, esta interfaz proporciona la manera de hacerlo. Basta con seleccionar un subgrupo de los autores del sistema y un subgrupo de los stakeholders del sistema para que en cada modificación que se realice a un nodo o a un requisito no funcional, queden añadidos a sus propiedades. Figura 40. Interfaz de Asignación de Autores y Stakeholders 38

39 3.5 Interfaz de Recursos En esta interfaz el usuario puede acceder a los recursos más significativos del modelo de una forma rápida y general. Se podrán acceder a los actores, las clases, los autores, los stakeholders (personas o entidades interesadas) y los requisitos no funcionales. Todos estos recursos comparten interfaz, excepto los requisitos no funcionales que contienen una funcionalidad añadida. Figura 41. Interfaz de Recursos Las funcionalidades que contempla esta interfaz son la creación, renombrado y borrado de recursos, y la introducción de la descripción de estos. Para ello se hace valer de dos botones: New y Delete from Model. La edición del nombre se produce de la misma forma que en las interfaces de acceso rápido de actores y clases. 39

40 Los requisitos no funcionales incluyen la selección de un tipo de una lista que ofrece la interfaz. Este tipo solo podrá seleccionarse una vez por requisito no funcional. Es esencial que el requisito contenga descripción y el único modo de introducirla en la herramienta es mediante esta interfaz. Figura 42. Interfaz de Recursos. Requisitos no funcionales 3.6 Interfaz de Edición de Diagramas de Casos de Uso El objetivo de esta interfaz es proporcionar los mecanismos necesarios para poder representar, entre otras cosas, las relaciones que mantienen los casos de uso y los actores entre ellos. Como se ha indicado anteriormente (ver Misión del Sistema y Árbol de Refinamiento de Funciones (2.1)), cada grupo funcional representa un Diagrama de Casos de Uso, y, por lo tanto, también representa una posible ventana 40