Manual de Usuario RETO-UPVeinsfran/pfc/RETO-Manual.pdf · UNIVERSIDAD POLITÉCNICA DE VALENCIA DEPARTAMENTO DE SISTEMAS INFORMATICOS Y COMPUTACIÓN - DSIC ... el Diagrama de Casos

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

Contenido 1. Introducción.............................................................................................................. 5 2. Modelo de Requisitos y Proceso de Análisis de Requisitos..................................... 6

2.1 Misión del Sistema y Árbol de Refinamiento de Funciones ............................ 8 2.1.1 Misión del Sistema ................................................................................... 8 2.1.2 Árbol de Refinamiento de Funciones ....................................................... 9

2.2 Modelo de Casos de Uso ................................................................................ 10 2.2.1 Extensión ................................................................................................ 11 2.2.2 Inclusión ................................................................................................. 12

2.3 Especificación de Casos de Uso ..................................................................... 13 2.4 Proceso de Análisis de Requisitos .................................................................. 17

2.4.1 Mensajes de Señal .................................................................................. 19 2.4.2 Mensajes de Servicio .............................................................................. 20 2.4.3 Mensajes de consulta .............................................................................. 21 2.4.4 Mensajes de conexión............................................................................. 21

3. Descripción de la Interfaz Gráfica de RETO-UPV ................................................ 23 3.1 Interfaz General de RETO-UPV..................................................................... 23

3.1.1 Menú General ......................................................................................... 24 3.1.2 Interfaz de Árbol de Refinamiento de Funciones................................... 25 3.1.3 Interfaz de Lista de Acceso Rápido a Actores........................................ 28 3.1.4 Interfaz de Lista de Acceso Rápido a Clases.......................................... 29 3.1.5 Interfaz de Acceso Rápido a Descripción............................................... 30 3.1.6 Interfaz de Barra de Herramientas para Elementos de Acceso Rápido.. 31 3.1.7 Interfaz de Barra de Herramientas Vertical............................................ 32

3.2 Interfaz de Propiedades de Nodo.................................................................... 33 3.3 Interfaz de Selección de Objetos .................................................................... 37 3.4 Interfaz de Asignación de Autores y Stakeholders......................................... 38 3.5 Interfaz de Recursos ....................................................................................... 39 3.6 Interfaz de Edición de Diagramas de Casos de Uso....................................... 40

3.6.1 Representaciones de Casos de Uso......................................................... 41 3.6.2 Representaciones de Actores .................................................................. 44 3.6.3 Comunicación......................................................................................... 48 3.6.4 Interacción .............................................................................................. 50 3.6.5 Generalización ........................................................................................ 51 3.6.6 Nota ........................................................................................................ 53 3.6.7 Enlace a nota........................................................................................... 55

3.7 Interfaz de Especificación de Casos de Uso................................................... 56 3.7.1 Interfaz de Especificación de Pasos........................................................ 60 3.7.2 Interfaz de Declaración de Extensiones.................................................. 62

3.8 Interfaz de Edición de Diagramas de Secuencia ............................................ 64 3.8.1 Representaciones de clases..................................................................... 65 3.8.2 Mensajes ................................................................................................. 70 3.8.3 Bloques ................................................................................................... 77 3.8.4 Nota ........................................................................................................ 79 3.8.5 Enlace a nota........................................................................................... 82 3.8.6 Interfaz de Especificación de Mensajes.................................................. 83 3.8.7 Interfaz de Especificación de Objetos .................................................... 86 3.8.8 Interfaz de Especificación de Bloques.................................................... 90

4. Conclusiones........................................................................................................... 92

3

4

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

-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].

Árbol de Refinamiento

Funcional

Misión del Sistema

Modelo de Casos de Uso

MODELO DE REQUISITOS

INGENIERÍA DE REQUISITOS

Diagramas de Secuencia a Nivel

de Análisis

PROCESO DE ANÁLISIS DE REQUISITOS (PAR)

Modelo Funcional

Modelo de Objetos

Modelo Dinámico

MODELO CONCEPTUAL

Tabla de Descomposición

Funcional

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


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


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

2 . 1 . 1 M i s i ó n d e l S i s t e m a

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


2 . 1 . 2 Á r b o l d e R e f i n a m i e n t o d e F u n c i o n e s

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


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


2 . 2 . 1 E x t e n s i ó 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


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).

2 . 2 . 2 I n c l u s i ó 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


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


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


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


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


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


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


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:

2 . 4 . 1 M e n s a j e s d e S e ñ a l

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


Propiedad Valor Descripción

{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. Direction

{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)).

2 . 4 . 2 M e n s a j e s d e S e r v i c i o

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.


{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.

{destroy}

Aplicable a mensajes en los cuales se desea borrar un elemento de la clase destino. Por ello presenta un cambio de estado fuerte.

Kind of Change

{update}

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


2 . 4 . 3 M e n s a j e s d e c o n s u l t a

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:


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

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.

cardinalidad {0..1} {0..M} {1..1} {1..M}

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>>

2 . 4 . 4 M e n s a j e s d e c o n e x i ó 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


El analista puede dar información sobre las siguientes propiedades:


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

{0} {1} ... {M}

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.

{Inserción}

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.

Actividad

{Borrado}

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

-DESCRIPCIÓN DE LA INTERFAZ GRÁFICA DE RETO-UPV-

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


3 . 1 . 1 M e n ú G e n e r a l

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


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

3 . 1 . 2 I n t e r f a z d e Á r b o l d e R e f i n a m i e n t o d e F u n c i o n e s

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


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


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


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.

3 . 1 . 3 I n t e r f a z d e L i s t a d e A c c e s o R á p i d o a A c t o r e s

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


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

3 . 1 . 4 I n t e r f a z d e L i s t a d e A c c e s o R á p i d o a C l a s e s

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


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

3 . 1 . 5 I n t e r f a z d e A c c e s o R á p i d o a D e s c r i p c i ó 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


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.

3 . 1 . 6 I n t e r f a z d e B a r r a d e H e r r a m i e n t a s p a r a E l e m e n t o s d e A c c e s o R á p i d o

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 , a la Interfaz de Lista de Acceso Rápido a Actores , 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


3 . 1 . 7 I n t e r f a z d e B a r r a d e H e r r a m i e n t a s V e r t i c a l

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 Una nueva representación de un actor

o Una nueva representación de un caso de uso

o Una nueva comunicación

o Una nueva generalización

o Una nueva nota

o Un nuevo enlace a nota (anchor note)

32


La barra de herramientas para diagramas de secuencia presenta las siguientes opciones:

o Un nuevo mensaje general

o Un nuevo mensaje signal

o Un nuevo mensaje query

o Un nuevo mensaje service

o Un nuevo mensaje connect

o Una nueva representación de clase

o Un nuevo bloque

o Una nueva nota

o 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


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


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


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


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


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


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


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


abierta en RETO-UPV para la edición del diagrama. Esta interfaz interactúa con la Interfaz de Barra de Herramientas Vertical (3.1.7), con Interfaz de Árbol de Refinamiento de Funciones (3.1.2) y con la Interfaz de Lista de Acceso Rápido a Actores (3.1.3) para cumplir con los objetivos anteriormente indicados. Debido a que la funcionalidad del editor depende en algunos casos de las otras dos interfaces, la descripción de esta funcionalidad se va a desarrollar a partir de cada uno de los elementos que pueden formar parte de un diagrama de casos de uso en RETO-UPV y de cada una de las operaciones que sobre estos se puede realizar.

3 . 6 . 1 R e p r e s e n t a c i o n e s d e C a s o s d e U s o

C r e a c i ó n

La creación manual o aparición automática de una nueva representación de un caso de uso podrá deberse a la ejecución de alguna de las siguientes acciones:

- Creación de un nuevo nodo hoja dentro de algún grupo funcional en la Interfaz de Árbol de Refinamiento de Funciones (3.1.2). Automáticamente aparecerá la representación de este caso de uso en el diagrama perteneciente al grupo funcional.

- Movimiento de un nodo hoja desde un grupo funcional a otro grupo funcional en la Interfaz de Árbol de Refinamiento de Funciones (3.1.2). Además de aparecer una representación del caso de uso que se ha movido, debido al movimiento de nodos, aparecerán representaciones de todos aquellos casos de uso que se comuniquen ya sea mediante inclusión o extensión con el caso de uso que se mueve (casos de uso a los que incluye o extiende, y no incluidos o extendidos), así como representaciones de las inclusiones o extensiones, de no ser que ya existan representaciones en el diagrama. Aquellos casos de uso que no pertenezcan al grupo funcional de diagrama, mostraran en su interior el nombre el grupo funcional al que pertenecen.

- Interacción con la Interfaz de Barra de Herramientas Vertical (3.1.7). Si se pulsa la opción en la barra de herramientas e inmediatamente se pulsa sobre alguna zona del diagrama de casos de uso, se creará una nuevo caso de uso en el grupo funcional, y aparecerá una representación suya en el punto donde se ha pinchado.

41


Figura 43. Detalle representación de Caso de Uso

S e l e c c i ó n

Para seleccionar una representación de un caso de uso, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada.

Figura 44. Detalle selección deCaso de Uso

R e n o m b r a d o

Para renombrar un caso de uso desde el Editor de Diagramas de Casos de Uso basta con seleccionarlo e inmediatamente pinchar sobre la etiqueta que contiene su nombre. De esta forma podremos editar el nombre del caso de uso sobre la misma etiqueta. Los cambios se harán patentes en cualquier lugar de la herramienta en el que aparezca el caso de uso.

42


Figura 45. Detalle de Edición de Etiquetas de Casos de Uso

M o v i m i e n t o

Un caso de uso puede moverse libremente por el diagrama si se pincha sobre él (seleccionándolo) y sin soltar el botón del ratón se arrastra hacia otra zona del diagrama para acabar soltando el botón y liberando el caso de uso. Las comunicaciones que mantenga con otros casos de uso y las interacciones que mantenga con actores, seguirán a la figura por el diagrama, así como también las posible conexiones que pueda tener con notas.

Figura 46. Detalle de Movimiento de una Representación de Caso de Uso

M e n ú c o n t e x t u a l

Pulsando con el botón derecho sobre una Representación de un Caso de Uso el editor muestra un menú contextual con las siguientes opciones y funcionalidades:

o Open Specification. Seleccionando esta opción se envía al usuario a la Interfaz de Especificación de Casos de Uso (3.7).

43


o Search in FRT. Seleccionando esta opción, el caso de uso aparece seleccionado y visible en la Interfaz de Árbol de Refinamiento de Funciones (3.1.2).

o Delete from Model. Seleccionando esta opción, el caso de uso se elimina del modelo (ver siguiente punto para más información).

o Properties. Seleccionando esta opción se envía al usuario a la Interfaz de Propiedades de Nodo (3.2).

Figura 47. Menú contextual para una Representación de Caso de Uso

E l i m i n a d o

Tres son las formas de eliminar una representación de un caso de uso. - La primera consiste en seleccionar la representación del caso de uso y

seguidamente pulsar la tecla Suprimir. - La segunda consiste en activar el menú contextual que surge al

pinchar encima de la representación con el botón derecho y seleccionando o bien Remove from Model o bien Remove from Diagram.

- La última consiste el eliminar el caso de uso desde el Árbol de Refinamiento de Funciones.

El resultado de estas acciones podrá tener diferente resultado según si el caso de uso al que la figura representa pertenecía o no al grupo funcional al que pertenece el diagrama de casos de uso. De ser así, toda representación del caso de uso, así como las relaciones que mantuviera con actores y otros casos de uso, desaparecerán de todos los diagramas del sistema que se modela. De no ser así, se eliminará solamente la representación del diagrama actual y todas las relaciones que mantenía en el diagrama.

3 . 6 . 2 R e p r e s e n t a c i o n e s d e A c t o r e s

C r e a c i ó n

La creación de una nueva representación de un actor podrá deberse a la ejecución de alguna de las siguientes acciones:

- Interacción con la Interfaz de Barra de Herramientas Vertical (3.1.7). Si

44


se ha pulsado la opción e inmediatamente se pulsa sobre alguna zona del diagrama de casos de uso, se creará un nuevo actor, que se mostrará automáticamente en la lista de actores, y aparecerá una representación suya en el punto donde se ha pinchado. Inmediatamente se mostrará, justo por debajo de la representación, una lista de actores ya existentes en el sistema, posibilitando al analista el cambio de actor de la representación por uno existente (eliminando de la lista de actores al actor recién creado).

- Selección y arrastre desde la Interfaz de Lista de Acceso Rápido a Actores (3.1.3) al Editor de Diagramas de Caso de Uso. Si se selecciona un actor en la lista de actores con el botón izquierdo del ratón y sin soltar el botón se arrastra hacia cualquier posición del editor y se suelta el botón, automáticamente aparecerá una representación del actor donde se ha soltado el botón.

- Movimiento de un nodo hoja desde un grupo funcional a otro grupo funcional en la Interfaz de Árbol de Refinamiento de Funciones (3.1.2). Si el nodo hoja que se ha movido mantenía interacciones con actores en su diagrama origen, se crearán representaciones de los actores en el diagrama destino así como también representaciones de estas interacciones.

Figura 48. Detalle de representación de Actor

S e l e c c i ó n

Para seleccionar una representación de un actor, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada.

45


Figura 49. Detalle selección de representación de actor

R e n o m b r a d o

Para renombrar un actor desde el Editor de Diagramas de Casos de Uso basta con seleccionarlo e inmediatamente pinchar sobre la etiqueta que contiene su nombre. De esta forma podremos editar el nombre del caso de uso sobre la misma etiqueta o bien seleccionar el nombre de otro actor de la lista que aparece justo por debajo del actor. Los cambios se harán patentes en cualquier lugar de la herramienta en el que aparezca el caso de uso. En el caso de haber seleccionado el nombre de otro actor, ya sea mediante la lista o mediante la edición manual del nombre, los cambios no son a nivel de actor, sino a nivel de interacciones que mantenía el actor y a nivel de la representación. La representación cambia de representante, no de nombre. En cuanto a las interacciones, allá donde se encuentre una de las interacciones que mantenía la representación del actor en el diagrama, se cambiará la representación del actor antiguo por otra representante del nuevo actor.

Figura 50. Detalle de edición de etiquetas de representación de actor

46


M o v i m i e n t o

Un actor puede moverse libremente por el diagrama si se pincha sobre él (seleccionándolo) y sin soltar el botón del ratón se arrastra a otro lugar. Las interacciones que mantenga con casos de uso y las generalizaciones que mantenga con actores, seguirán a la figura por el diagrama. Así como también las posible conexiones que pueda tener con notas.

Figura 51. Detalle de movimiento de representación de actor


Pulsando con el botón derecho sobre una Representación de un Actor el editor muestra un menú contextual con las siguientes opciones y funcionalidades:

o Delete from Diagram. Seleccionando esta opción, la representación del actor desaparece sin eliminar el actor del modelo.

o Delete from Model. Seleccionando esta opción, el actor se elimina por completo del modelo (ver siguiente punto para más información), y la representación desaparece.

Figura 52. Menú contextual para una Representación de Actor

E l i m i n a d o

Tres son las formas de eliminar una representación de un actor. - La primera consiste en seleccionar la representación y seguidamente

pulsar la tecla Suprimir.

47


- La segunda consiste en activar el menú contextual que surge al pinchar encima de la representación con el botón derecho y seleccionando o bien Remove from Model o bien Remove from Diagram.

- La última consiste en eliminar desde la lista de actores, al actor en cuestión, en cuyo caso se elimina de todo el sistema.

3 . 6 . 3 C o m u n i c a c i ó n

C r e a c i ó n

La creación de una nueva comunicación de forma manual se produce al interactuar con la Interfaz de Barra de Herramientas Vertical (3.1.7) seleccionando la opción para inmediatamente después, en el editor de diagramas de casos de uso, pulsar el botón izquierdo del ratón sobre una representación de un caso de uso y sin soltar el botón, desplazar el puntero hacia otra representación de otro caso de uso para liberar entonces el botón. Desde que se pulsa hasta que se libera el botón, aparece una línea en movimiento con el puntero como ayuda al usuario.

Figura 53. Detalle de Comunicación

S e l e c c i ó n

Para seleccionar una representación de una comunicación, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada.

Figura 54. Detalle de selección de Comunicación

48



Pulsando con el botón derecho sobre una comunicación el editor muestra un menú contextual con las siguientes opciones y funcionalidades:

o <<extends>>. Seleccionando esta opción, la comunicación pasa a representar una extensión.

o <<include>>. Seleccionando esta opción, la comunicación pasa a representar una inclusión.

o None. Seleccionando esta opción, la comunicación deja de representar a una extensión o una inclusión para quedarse por definir. Es el estado primero de una comunicación.

o Delete from Model. Seleccionando esta opción, la comunicación se elimina por completo del modelo (ver siguiente punto para más información), y la representación desaparece.

Figura 55. Menú contextual para una comunicación

E l i m i n a d o

Dos son las forma de eliminar directamente una comunicación de un diagrama de casos de uso:

- Seleccionando la comunicación y seguidamente pulsando la tecla Suprimir.

- Mediante el menú contextual con la opción Delete from Model.

Mediante estas opciones la comunicación desaparece completamente del sistema que se esta modelando. Cabe la posibilidad de que una comunicación desaparezca de cierto diagrama sin desaparecer del sistema. Esto ocurre cuando se elimina la representación de uno los dos casos de uso (que no el caso de uso) que formaban la comunicación y en otro lugar del sistema estaba presente esta comunicación.

49


3 . 6 . 4 I n t e r a c c i ó n

C r e a c i ó n

La creación de una nueva interacción de forma manual se produce al interactuar con la Interfaz de Barra de Herramientas Vertical (3.1.7) pulsando el botón para inmediatamente después, en el editor de diagramas de casos de uso, pinchar con el botón izquierdo del ratón sobre una representación de un caso de uso y sin soltar el botón, desplazar el puntero hacia una representación de actor para liberar entonces el botón. Esta operación también funciona en orden inverso. Desde que se pulsa hasta que se libera el botón, aparece una línea en movimiento con el puntero como ayuda al usuario.

Figura 56. Detalle de interacción

S e l e c c i ó n

Para seleccionar una representación de una interacción, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada.

Figura 57. Detalle de selección de Interacción


Pulsando con el botón derecho sobre una comunicación el editor muestra un menú contextual con las siguientes opciones y funcionalidades:

o [Actor] ----->[Use Case]. Seleccionando esta opción, la interacción tendrá como origen al actor y como destino al caso de uso.

50


o [Actor] <-----[Use Case]. Seleccionando esta opción, la interacción tendrá como origen al caso de uso y como destino al actor.

o [Actor] <---->[Use Case]. Seleccionando esta opción, la interacción será bidireccional, es decir la comunicación se producirá tanto del actor al caso de uso como del caso de uso al actor..

o Delete from Model. Seleccionando esta opción, la comunicación se elimina por completo del modelo (ver siguiente punto para más información), y la representación desaparece.

Figura 58. Menú contextual para una interacción

E l i m i n a d o

Dos son las formas de eliminar directamente una interacción de un diagrama de casos de uso:

- Seleccionando la interacción y seguidamente pulsando la tecla Suprimir.

- Mediante el menú contextual con la opción Delete from Model. Mediante estas opciones la interacción desaparece completamente del sistema que se esta modelando. Cabe la posibilidad de que una interacción desaparezca de cierto diagrama sin desaparecer del sistema. Esto ocurre cuando se elimina la representación del caso de uso (que no el caso de uso) que formaban la comunicación y en otro lugar del sistema estaba presente esta interacción. O bien al eliminar la representación del actor y en otro lugar del sistema estaba presente esta interacción.

3 . 6 . 5 G e n e r a l i z a c i ó n

C r e a c i ó n

La creación de una nueva generalización de forma manual se produce al interactuar con la Interfaz de Barra de Herramientas Vertical (3.1.7) pulsando el botón para inmediatamente después, en el editor de diagramas de casos de

51


uso, pinchar con el botón izquierdo del ratón sobre una representación de un actor y sin soltar el botón, desplazar el puntero hacia una representación de otro actor para liberar entonces el botón. Desde que se pulsa hasta que se libera el botón, aparece una línea en movimiento con el puntero como ayuda al usuario.

Figura 59. Detalle de Generalización entre actores

S e l e c c i ó n

Para seleccionar una representación de una generalización, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada.

Figura 60. Detalle de selección de Generalización


Pulsando con el botón derecho sobre una comunicación el editor muestra un menú contextual con una sola opción denominada Delete from Model. Seleccionando esta opción, la comunicación se elimina por completo del modelo (ver siguiente punto para más información), y la representación desaparece.

52


Figura 61. Menú contextual para una generalización

E l i m i n a d o

Dos son las formas de eliminar directamente una generalización de un diagrama de casos de uso:

- Seleccionando la generalización y seguidamente pulsando la tecla Suprimir.

- Mediante el menú contextual con la opción Delete from Model. Mediante estas opciones la generalización desaparece completamente del sistema que se esta modelando. Cabe la posibilidad de que una generalización desaparezca de cierto diagrama sin desaparecer del sistema. Esto ocurre cuando se elimina la representación de alguno de los actores que participaban en la generalización y en otro lugar del sistema estaba presente esta generalización.

3 . 6 . 6 N o t a

Una nota (Note en la herramienta) es, gráficamente, como una hoja de papel donde se puede insertar texto como ayuda a la comprensión de alguna parte del diagrama en el que se encuentra.

C r e a c i ó n

La única forma de crear una nueva nota es interactuando con la Interfaz de Barra de Herramientas Vertical (3.1.7) pulsando el botón para inmediatamente después, en el editor de diagramas de casos de uso, pinchar con el botón izquierdo del ratón sobre alguna zona del diagrama para que, sin soltar el botón, desplazarse a otra zona del diagrama estableciendo así las dimensiones de la nota.

Figura 62. Detalle de Nota

53


S e l e c c i ó n

Para seleccionar una nota, basta con pinchar con el botón izquierdo del ratón sobre la nota deseada.

Figura 63. Detalle de selección de Nota

M o v i m i e n t o

Una nota puede moverse libremente por el diagrama si se pincha sobre ella (seleccionándola) y sin soltar el botón del ratón se arrastra a otro lugar. Aparecerá un rectángulo siguiendo el movimiento del ratón. Al posicionar el rectángulo en el área deseada la nota y todos los enlaces que mantuvieran se desplazarán hacia su nueva posición automáticamente.

Figura 64. Detalle movimiento de nota

E d i c i ó n

Para editar una nota, primero hay que seleccionarla y seguidamente hacer clic otra vez sobre ella. Para salir del estado de edición basta con hacer clic con el ratón en otra área del diagrama.

54


Figura 65. Detalle de edición de nota


Pulsando con el botón derecho sobre una nota el editor muestra un menú contextual con una sola opción denominada Delete from Model. Seleccionando esta opción, la nota se elimina por completo del modelo así como todos los enlaces que ésta mantenía.

Figura 66. Menú contextual para una nota

E l i m i n a d o

Dos son las formas de eliminar directamente una nota de un diagrama de casos de uso:

- Seleccionando la nota y seguidamente pulsando la tecla Suprimir. - Mediante el menú contextual con la opción Delete from Model.

3 . 6 . 7 E n l a c e a n o t a

Una enlace a nota (Anchor Note en la herramienta) es, gráficamente, una línea que parte de una nota para asentarse por medio de un círculo de fondo amarillo a un actor, un caso de uso, una generalización, una comunicación o una interacción.

C r e a c i ó n

La creación de un nuevo enlace a nota de forma manual se produce al interactuar con la Interfaz de Barra de Herramientas Vertical (3.1.7) seleccionando la opción para inmediatamente después, en el editor de diagramas de casos de uso, pinchar con el botón izquierdo del ratón sobre algún objeto de los anteriormente mencionados y sin soltar el botón, desplazar el puntero hacia una nota para liberar entonces el botón, o viceversa. Desde que

55


se pulsa hasta que se libera el botón, aparece una línea en movimiento con el puntero como ayuda al usuario.

Figura 67. Detalle de Enlace a Nota


Pulsando con el botón derecho sobre un enlace a nota el editor muestra un menú contextual con una sola opción denominada Delete from Model. Seleccionando esta opción, el enlace a nota se elimina por completo del modelo.

Figura 68. Menú contextual para un enlace a nota

E l i m i n a d o

Para eliminar un enlace a nota del diagrama, o bien, mediante su menú contextual se selecciona la opción Delete from Model, o bien, estando seleccionado el enlace a nota se pulsa la tecla Suprimir.

3.7 Interfaz de Especificación de Casos de Uso

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. Esta secuencia de acciones viene determinada por una lista numerada de pasos que representan la unidad estructural básica de la especificación de un caso de uso.

El pequeño resumen que se hace de la especificación de casos de uso va a servir para ayudar a comprender la solución que RETO-UPV propone para introducir y manipular estos conceptos. RETO-UPV en su Interfaz de Especificación de Casos de Uso además de contemplar la solución para la

56


especificación de casos de uso arriba comentada, contempla también la visualización y manipulación de la descripción del caso de uso y de las extensiones que se proponen para un determinado caso de uso. Con todo esto el usuario tendrá una visión global sobre la acción que se realiza en el caso de uso y sus relaciones con otros casos de uso.

La Interfaz de Especificación de Casos de Uso está compuesta básicamente de tres grandes secciones: Summary, Basic Course y Alternatives.

Figura 69. Interfaz de Especificación de Casos de Uso.

S e c c i ó n S u m m a r y

Encontramos esta sección subdividida en dos partes. A la izquierda de la sección encontramos un cuadro de texto representando la descripción del caso de uso, que podemos encontrar en otras partes de RETO-UPV (ver Interfaz General de RETO-UPV (3.1)), que permite la manipulación y visualización de la descripción del caso de uso. A la derecha encontramos la sección Extends que

57


visualiza la lista de casos de uso que son extendidos por el caso de uso sobre el que se trabaja.

Para manipular la lista de casos de uso extendidos, la sección proporciona una botón llamado Go con el que se accede a otra interfaz más adecuada para la manipulación de las extensiones del caso de uso. Esta nueva interfaz es la Interfaz de Declaración de Extensiones (3.7.2), donde se añaden y eliminan extensiones y se establecen sus condiciones.

La lista de extensiones también permite la visualización rápida de la condición en la que uno de los casos de uso de la lista es extendido. Para ello basta con seleccionarlo y esperar a que aparezca la condición sobre la lista.

Figura 70. Visualización de la condición de una extensión.

S e c c i ó n B a s i c C o u r s e

En esta sección es donde se encuentra detallada la secuencia de pasos que representa realmente la especificación del caso de uso.

Tal y como se ha definido un paso en la Especificación de Casos de Uso (2.3), nos encontramos con que este debe expresar de forma textual cierta acción supeditada a cierta condición. Además los pasos estarán dispuestos de forma secuencial y numerada en orden ascendente. Por último un paso debe encontrarse clasificado como General, Comunicación Actor / Sistema o Respuesta del Sistema.

La declaración de las diferentes partes que componen un paso se realiza mediante la Interfaz de Especificación de Pasos (3.7.1), a la cual se accede o bien inmediatamente al crear un nuevo paso (al pulsar New Step la Interfaz de Definición de Pasos se muestra de inmediato) o bien realizando un doble clic sobre un paso determinado.

Para añadir y eliminar pasos basta con usar los botones New Step y Remove Step. Al eliminar un paso de la lista de pasos todos los pasos inferiores verán decrementado su orden a una posición superior. Además al eliminar un paso, si existía alternativa para el paso, se eliminará de la lista de alternativas.

58


Cada paso, visualmente, se compone de tres partes: su número de orden, su icono de clasificación y su descripción textual.

El número de orden de un paso viene determinado automáticamente al crear el paso. El paso, al crearse, se sitúa justo por encima del paso actualmente seleccionado, es decir, el nuevo paso toma la posición del paso seleccionando desplazando a éste y a los pasos situados por debajo a un orden superior. Ó bien, si no se encuentra seleccionado ningún paso, el nuevo paso se sitúa en la última posición. RETO-UPV proporciona la posibilidad de modificar el orden

de los pasos. Para ello basta con pulsar sobre los iconos o para bajar o subir el paso seleccionado una posición inmediatamente inferior o superior.

Para la diferenciación del tipo de paso según la clasificación expuesta en la sección Especificación de Casos de Uso (2.3), se presenta mediante un icono que diferencia a los tres tipos de pasos:

o Icono General o Icono Comunicación Actor / Sistema o Icono Respuesta del Sistema

El usuario deberá familiarizarse con los iconos para diferenciar rápidamente el tipo de paso con el que trata.

Además de los anteriores iconos, se van a diferenciar los pasos que representan la ejecución de otro caso de uso externo mediante el icono , que indicará al usuario que el paso con el que trata contiene la inclusión bajo cierta condición de otro caso de uso.

La descripción textual del paso, creada de forma automática, se utiliza el siguiente formato

[IF <condicion> THEN,] <acción> [INCLUDE USE CASE <caso de uso incluido>]

que toma su valor final a partir de la información introducida en la Interfaz de Especificación de Pasos (3.7.1). Mediante este formato se puede visualizar la acción que realiza el paso, bajo que condición realiza el paso esta acción y si el paso incluye la ejecución de algún otro caso de uso.

59


RETO-UPV permite así visualizar toda la información que define un paso en la misma lista numerada de pasos, sin ocultar ningún tipo de información referida a éste.

S e c c i ó n A l t e r n a t i v e s

En esta sección se encuentran detalladas las posibles alternativas a los pasos del curso básico.

En cuanto a la visualización de las alternativas, la única variación con respecto a la visualización de los pasos en la sección Basic Course, es que la columna Step, representa, no el orden de la alternativa, sino el orden del paso del que es alternativa. De esta forma es fácil reconocer inmediatamente la alternativa de un paso dado.

Para la creación de las alternativas, basta con seleccionar un paso de la sección Basic Course y pulsar el botón Add Alternative. Esta acción conduce inmediatamente a la declaración de la alternativa, que se produce en la misma Interfaz de Especificación de Pasos (3.7.1). Las alternativas se ordenan de forma ascendente según el orden del paso del que es alternativa, siendo imposible variar su orden.

De igual forma que en la sección Basic Course, mediante un doble clic sobre una alternativa se desplaza al usuario a la Interfaz de Especificación de Pasos (3.7.1). La eliminación de las alternativas se realiza seleccionando un paso y pulsando el botón Remove Alternative. Esto provoca la reordenación automática de las alternativas restantes.

3 . 7 . 1 I n t e r f a z d e E s p e c i f i c a c i ó n d e P a s o s

Como se comenta en la sección anterior (3.7), la unidad estructural básica de la especificación de un caso de uso en OO-Method es el paso.

Tomando como referencia la estructura de paso definida en la sección anterior ([<condicion>,] <actor>|<sistema> <actividad>), podemos encontrar en la Interfaz de Especificación de Pasos tres secciones básicas que corresponde cada una de los elementos de un paso.

o Sección Action: en esta sección se describe en lenguaje natural la acción que realiza el actor o el sistema.

60


o Sección Condition: en esta sección opcional es posible declarar una condición que tendrá que evaluarse previamente a la realización de la acción. También se expresará en lenguaje natural.

o Sección Type Step: en esta sección podemos diferenciar la naturaleza del paso. Mediante esta elección podremos diferenciar si el ejecutor de la acción es un actor, el sistema o simplemente es una acción relativa al contexto donde se desarrolla el caso de uso.

Figura 71. Especificación de Paso

Además de estas tres secciones podemos encontrar una sección Include. La selección de está casilla de selección significará que el la acción del paso corresponderá a la ejecución de otro caso de uso (siendo éste seleccionado de entre los casos de uso de la lista desplegable que se habilita al seleccionar Include). Aunque la acción del paso queda clara al ejecutarse el caso de uso incluido es posible expresar en la acción a modo de resumen la acción que se produce en el caso de uso incluido.

Las secciones Type Step e Include son mutuamente excluyentes. Si se encuentra marcada la casilla de Include, la sección Type Step se encontrará deshabilitada. Si la casilla Include no se encuentra marcada, la sección Use Case se encontrará deshabilitada.

61


Figura 72. Opción Include en Especificación de Paso

3 . 7 . 2 I n t e r f a z d e D e c l a r a c i ó n d e E x t e n s i o n e s

Para expresar el concepto de extensión desarrollado en la sección anterior, la herramienta proporciona una sencilla interfaz donde, para un caso de uso concRETO (el caso de uso en el que se trabaja), se puedan expresar sus extensiones de una manera sencilla.

La interfaz básicamente consta de tres secciones, que interactuando con los botones de Add y Remove, que posibilitan la sencilla creación y manipulación de extensiones.

o Sección Use Cases: Esta sección se compone de un solo listado con todos los casos de uso del sistema excepto el caso que extiende (con el que se trabaja) y los casos de uso que están ya declarados como extendidos por el caso de uso con el que se trabaja.

o Sección Extends: Esta sección se compone de un solo listado con todos los casos de uso que son extendidos por el caso de uso con el que se trabaja.

62


o Sección Condition: Esta sección se compone de un cuadro de edición de texto donde es posible introducir una condición en forma de texto plano para una extensión en particular. La sección únicamente se encontrará habilitada si se encuentra seleccionado algún caso de uso en la sección Extends, en cuyo caso el texto visualizado corresponderá con la condición de la extensión.

Figura 73. Interfaz de creación de extensiones.

La selección de casos de uso en las secciones Use Cases y Extends es mutuamente excluyente. Si se ha seleccionado un caso de uso en la sección Use Cases no se tiene ningún caso de uso seleccionado en la sección Extends y viceversa.

La selección de un caso de uso de la sección Use Cases posibilita la creación de una nueva extensión, simplemente basta con pulsar el botón Add para que este caso de uso aparezca en la sección Extends, formando parte de los casos de uso extendidos, y desaparezca de la sección Use Cases.

De forma similar, la selección de un caso de uso de la sección Extends, posibilita la supresión de una extensión ya establecida. Simplemente basta con pulsar el botón Remove para que el caso de uso pase a encontrarse en la sección Use Cases, dejando este de ser una extensión del caso de uso en el que trabaja.

63


3.8 Interfaz de Edición de Diagramas de Secuencia

La Interfaz de Edición de Diagramas de Secuencia proporciona las herramientas necesarias para capturar las responsabilidades significativas del proyecto para hallar una primera aproximación del esquema conceptual, tal como se comenta en la sección Proceso de Análisis de Requisitos (2.4).

La Interfaz de Edición de Diagramas de Secuencia trabaja conjuntamente con la Interfaz de Barra de Herramientas Vertical (3.1.7) y con la Interfaz de Lista de Acceso Rápido a Clases (3.1.4), siendo imposible su uso sin la interacción con esta interfaz.

Semánticamente un diagrama de secuencia representa las responsabilidades del sistema identificando el objeto cliente y el objeto servidor de cada responsabilidad. Gráficamente, un Diagrama de secuencia se compone básicamente de objetos (o debido al alto nivel en el que se trabaja, clases) que se comunican a través del tiempo mediante mensajes.

Como ocurría con la Interfaz de Edición de Diagramas de Casos de Uso (3.6), es más sencillo describir la funcionalidad del diagrama por medio de cada uno de los elemento que en él pueden aparece

Figura 74. Ejemplo Diagrama de Secuencia

64


3 . 8 . 1 R e p r e s e n t a c i o n e s d e c l a s e s

Popularmente el origen y el destino de un mensajes venia representado por una caja de la que colgaba una línea punteada de donde partían o llegaban mensajes. En RETO-UPV se ha adoptado variar la forma de representar la clase según cierta clasificación informal, variando la representación de estas según el papel que juegue la clase en el diagrama.. Seguidamente queda más detallada esta clasificación.

En todo Diagrama de Secuencia siempre aparecerá por defecto una representación de la clase sistema. Esta representación además no podrá ser eliminada. Tampoco se podrá crear otra representación de la clase sistema en el diagrama. Esta representación incluirá un pequeño icono en la parte inferior izquierda representando al sistema.

Figura 75. Detalle Clase Sistema

A la izquierda de la clase sistema solo podrán aparecer clases que representen a la vez a algún actor o actores que interactúen con el caso de uso al que pertenece el diagrama de secuencia. RETO-UPV con su Interfaz de Especificación de Objetos (3.8.7), permite la posibilidad de agrupar en una línea de tiempo a varios actores. El significado de esta acción se detallará en esta interfaz (3.8.7). Estas clases vienen representadas por un actor si el actor es único o por varios actores si son varios los actores que participan en la misma línea temporal.

Figura 76. Detalle un solo actor

65


Figura 77. Detalle varios actores

Por último, cualquier clase que aparezca a la derecha de la clase sistema, no podrá jugar el papel de actor en el diagrama, al menos en esa instancia de clase. Puede tal vez que una misma clase juegue el papel de actor junto al de no actor, en ese caso la clase aparecerá representada a ambos lados de la clase sistema. La notación gráfica para este tipo de clase es la siguiente:

Figura 78. Detalle de clase

C r e a c i ó n

La creación de una nueva representación de una clase solo podrá deberse a la Interacción con la Interfaz de Barra de Herramientas Vertical (3.1.7). Si se pulsa

la opción en la barra de herramientas e inmediatamente se pulsa sobre alguna zona del diagrama de secuencia, se creará una nuevo representación de una clase aún por determinar. Dependiendo de si se ha pinchado a la izquierda o a la derecha de la clase sistema, aparecerá una representación o otra según lo comentado anteriormente.

S e l e c c i ó n

Para seleccionar una representación de una clase, basta con pinchar con el botón izquierdo del ratón sobre la representación deseada o bien sobre la zona en blanco justo por debajo de la representación.

66


Figura 79. Detalle selección de clase

C a m b i o d e C l a s e

Para cambiar la clase de una representación de clase o asignarle una clase a la representación si se encontraba sin establecer, basta con hacer doble clic sobre la representación para que el programa lleve al usuario a la Interfaz de Especificación de Objetos (3.8.7) donde el usuario podrá cambiar la clase y además podrá asignarle un nombre de objeto cuyo significado será simplemente el de diferenciar una representación de otra de la misma clase.

Figura 80. Detalle de la Interfaz de especificación de objetos

67


M o v i m i e n t o

Para mover una clase, siempre manteniéndose la posición vertical de esta, basta con pulsar el botón izquierdo del ratón y sin soltar desplazar el cuadro y la línea rayada que aparece substituyendo a la clase, a la zona deseada para acabar soltando el botón.

Figura 81. Detalle Movimiento de clases

Una clase puede moverse por el diagrama de secuencia con ciertas restricciones.

o Una clase representando a un actor puede moverse hacia cualquier zona comprendida desde el extremo izquierdo del diagrama hasta el eje vertical de la clase sistema.

o Una clase que no representa a un actor ni es la clase sistema puede moverse hacia cualquier zona comprendida desde el eje vertical de la clase sistema hasta el extremo derecho del diagrama.

o La clase sistema podrá moverse desde el eje vertical de la clase situada inmediatamente a su izquierda (o en su defecto el extremo izquierdo del diagrama) hasta el eje vertical de la clase situada inmediatamente a su derecha (o en su defecto el extremo derecho del diagrama).


Pulsando con el botón derecho sobre una representación de una clase el editor muestra un menú contextual con las siguientes opciones y funcionalidades:

68


o Delete from Diagram. Seleccionando esta opción, la clase se elimina del modelo pero nunca del sistema.

o Properties. Seleccionando esta opción se envía al usuario a la Interfaz de Asignación de Autores y Stakeholders



o (3.4).

Figura 82. Menú contextual para una representación de clase

E l i m i n a d o

Dos son las formas de eliminar una representación de una clase:

o La primera consiste en seleccionar la representación de la clase y seguidamente pulsar la tecla Suprimir. Con lo cual se elimina solamente la representación y nunca la clase.

69


o La segunda consiste en activar el menú contextual que surge al pinchar encima de la representación con el botón derecho y seleccionando Remove from Diagram. Con lo cual se elimina solamente la representación y nunca la clase.

En cualquiera de los dos casos, todos los mensajes, bloques y enlaces a notas que estuvieran establecidos con la representación serian eliminados automáticamente. Si se eliminara la clase desde algún punto del sistema, la representación se mantendría pero pasaría a establecerse sin clase, es decir, la representación dejará de tener una clase asignada.

3 . 8 . 2 M e n s a j e s

Semánticamente un mensaje es una herramienta para capturar responsabilidades de una clase, de la cual otra clase se aprovecha (ver Proceso de Análisis de Requisitos (2.4)). Gráficamente RETO-UPV ha adoptado la representación de un mensaje por medio de una línea dirigida hacia la clase servidora de la responsabilidad.

Además en RETO-UPV podemos ver en la misma representación el nombre de éste mensaje, el estereotipo y otra información dependiente del estereotipo del mensajes.

Para mensajes signal, la única información que se muestra es el nombre del mensaje arriba de la línea dirigida.

Figura 83. Detalle de mensaje con estereotipo signal

Para mensajes service, además del nombre del mensajes, tenemos en la parte inferior el indicativo del estereotipo y el valor de la clase de cambio entre llaves.

70


Figura 84. Detalle de mensaje con estereotipo service

Para mensajes query, tenemos en la parte superior el nombre del atributo derivado (si lo tiene) seguido del símbolo “=”, seguido del nombre del mensaje. Y en la parte inferior tenemos, entre llaves, la cardinalidad del mensaje.

Figura 85. Detalle de mensaje con estereotipo query

Por último, En los mensajes de tipo connect, en la parte superior tenemos el nombre y en la inferior, entre llaves, la cardinalidad del mensaje y la actividad que realiza.

Figura 86. Detalle de mensaje con estereotipo connect

Además de las anteriores formas de expresar gráficamente características propias de cada estereotipo, también se expresa gráficamente la condición de ejecución del mensajes, que es posible establecer en la Interfaz de Especificación de Mensajes (3.8.6), situando delante de todos los elementos de la parte superior del mensaje y entre corchetes, la condición.

Figura 87. Detalle de mensaje con condición

71


C r e a c i ó n

La creación de un nuevo mensaje solo podrá deberse a la interacción con la Interfaz de Barra de Herramientas Vertical (3.1.7). Existen varias posibilidades de creación de mensajes en esta misma barra, dependiendo del estereotipo que se desea asignar al mensaje desde un principio:

o Opción : Si el usuario no tiene claro el estereotipo que tendrá el mensaje, puede seleccionar esta opción y el mensaje aparecerá sin estereotipo.

o Opción : El mensaje que se creará tendrá asignado el estereotipo signal. En el mensaje tendrá que participar una clase en función de actor necesariamente.

o Opción : El mensaje que se creará tendrá asignado el estereotipo service. En el mensaje no podrá participar ninguna clase en función de actor.

o Opción : El mensaje que se creará tendrá asignado el estereotipo query. En el mensaje no podrá participar ninguna clase en función de actor.

o Opción : El mensaje que se creará tendrá asignado el estereotipo connect. En el mensaje no podrá participar ninguna clase en función de actor.

S e l e c c i ó n

Para seleccionar un mensaje, basta con pinchar con el botón izquierdo del ratón sobre el mensaje deseado o bien sobre las etiquetas que a este pertenecen.

Figura 88. Detalle selección de mensaje

C a m b i o d e D a t o s d e l M e n s a j e

Al diseñar RETO-UPV, y más concretamente, al estudiar el tema de los mensajes entre clases, quedo determinada la información que de un mensaje sería relevante conocer. Gran parte de esta información puede manipularse directamente mediante los menús contextuales de los mensajes.

72


Para poder manipular toda esta información en una misma vista se ha creado la Interfaz de Especificación de Mensajes (3.8.6), mediante la cual el usuario tendrá una visión completa de la función del mensaje que se manipula

Figura 89. Detalle de la Interfaz de especificación de mensajes

M o v i m i e n t o

Para mover una mensaje siempre manteniéndose la posición horizontal de este, basta con pulsar el botón izquierdo del ratón y sin soltar desplazar la línea rayada que aparece substituyendo a la clase, a la zona deseada para acabar soltando el botón.

73


Un mensaje puede moverse por el diagrama de secuencia con ciertas restricciones.

o Existe una posición mínima en la parte superior del diagrama. Si se intenta mover hacia esta posición el mensaje se colocará automáticamente en esta posición mínima.

o Un mensaje dentro de un bloque tendrá la movilidad limitada. Si el mensaje es el primero o el último del bloque solo podrán moverse dentro de los límites impuestos por los mensajes que se encuentren justo inmediatamente encima y debajo de estos, y nunca podrán cambiar su orden. Si el mensaje no es ni el primero ni el último solo se podrá mover dentro de los límites impuestos por el primer y el último mensaje del bloque, pudiendo cambiar el orden entre los mensajes de dentro del bloque.

Figura 90. Detalle Movimiento de mensaje


Pulsando con el botón derecho sobre una representación de un mensaje el editor muestra un menú contextual variable según sea el estereotipo actual del mensaje.

Dos son las opciones que aparecen independientemente del estereotipo del mensaje (Change Stereotype no aparece en mensajes signal):

o Delete from Model. Seleccionando esta opción, el mensaje se elimina del diagrama y del modelo.

o Change Stereotype. Dentro de esta opción siempre aparecen presentes el resto de los estereotipos posible para el mensaje. Al seleccionar una de estas opción se produce el cambio de estereotipo.

Para un mensaje sin tipo, el menú contextual que aparece depende de si un actor forma parte del mensaje o no. En ambos casos las opciones que aparecen son las que aparecen por defecto siempre, el único cambio se encuentra en las opciones de cambio de estereotipo que son a <<signal>> para un mensaje del que forma parte un actor y <<service>>, <<query>> y <<connect>> para mensajes en los que no forma parte un actor.

74


Figura 91. Menú contextual para un mensaje sin estereotipo

Figura 92. Menú contextual para un mensaje sin estereotipo

Para un mensaje de estereotipo signal la única opción que aparece es Delete from Model.

Figura 93. Menú contextual para un mensaje con estereotipo signal

Para un mensaje con estereotipo service aparecen las opciones {new}, {destroy} y {update} referidas a la clase de cambio que se provocará en la clase receptora del mensaje. También aparecerá, en el submenú característico de la opcion Change Stereotype la posibilidad de cambiar el mensaje de estereotipo a query o connect.

Figura 94. Menú contextual para un mensaje de estereotipo service

En un mensajes con estereotipo query aparecen las opciones {0..1}, {0..M}, {1..1} y {1..M} referidos a opciones típicas del número de objetos de la clase receptora que participarán en la consulta. Si se desea seleccionar otro tipo de cardinalidad no reflejada en estas opciones el usuario deberá dirigirse a la Interfaz de Especificación de Mensajes (3.8.6). También aparecerá, en el submenú característico de la opcion Change Stereotype la posibilidad de cambiar el mensaje de estereotipo a service o connect.

75


Figura 95. Menú contextual para un mensaje con estereotipo query

Por último, en un mensaje con estereotipo connect nos encontramos con las opciones insert y delete referidas a la actividad del mensaje (ver Mensajes de conexión (2.4.4). Estas dos opciones incluyen un submenú donde se puede elegir entre las opciones min{0}max{1}, min{1}max{1}, min{0}max{M}, min{1}max{M} y min{M}max{M} referidas a los números mínimo y máximo de objetos que pueden seleccionarse en la clase receptora.

Figura 96. Opcion insert en un mensaje con estereotipo connet

Figura 97. Opción delete en un mensaje con estereotipo connect

También aparecerá, en el submenú característico de la opción Change Stereotype la posibilidad de cambiar el mensaje de estereotipo a service o query.

Figura 98. Menú contextual para un mensaje con estereotipo connect

76


E l i m i n a d o

Dos son las formas de eliminar un mensaje:

o La primera consiste en seleccionar el mensaje y seguidamente pulsar la tecla Suprimir.

o La segunda consiste en activar el menú contextual que surge al pinchar encima del mensaje con el botón derecho y seleccionando Remove from Diagram.

En cualquiera de los dos casos, todos los enlaces a notas que estuvieran establecidos con el mensaje serian eliminados automáticamente.

3 . 8 . 3 B l o q u e s

La agrupación de mensajes bajo la estructura de un bloque responde a la necesidad de asignar a estos mensajes una condición de ejecución común o bien a la necesidad de ejecutarlos bajo cierta estructura iterativa expresada también en forma de condición.

Figura 99. Detalle de bloque

C r e a c i ó n

La creación de nuevo bloque solo podrá deberse a la Interacción con la

Interfaz de Barra de Herramientas Vertical (3.1.7). Si se pulsa la opción en la barra de herramientas e inmediatamente se pulsa sobre alguna zona del diagrama de secuencia, y sin soltar se desplaza a otra zona del diagrama, todos los mensajes que se encuentren verticalmente entre la posición inicial y final quedarán englobados dentro del bloque, sea cual sea su posición horizontal.

Por supuesto, un bloque podrá ser super-bloque ó sub-bloque de cualquier otro pero de no ser así, la intersección de dos bloque necesariamente tendrá que

77


ser cero. Además un bloque no podrá contener exactamente el mismo conjunto de mensajes que otro.

Un bloque se representa automáticamente, si se mueven los mensajes puede que el bloque varíe de dimensiones, pero siempre mantendrá el mismo conjunto de mensajes.

S e l e c c i ó n

Para seleccionar un bloque, basta con pinchar con el botón izquierdo del ratón sobre el bloque deseado o bien sobre la zona en blanco justo por debajo de la representación.

Figura 100. Detalle selección de bloque

C a m b i o d e C o n d i c i ó n

Para cambiar la condición de un bloque, el usuario tendrá que hacer doble clic sobre el bloque, y la herramienta lo desplazará a la Interfaz de Especificación de Bloques (3.8.8), donde podrá, además de editar la condición, incluir la descripción textual del bloque.

78


Figura 101. Detalle de la Interfaz de especificación de bloques


La única opción en el menú contextual que aparece sobre un bloque al pulsar con el botón derecho sobre él es la de Delete from Model, cuya funcionalidad es la de eliminar el bloque del modelo.

E l i m i n a d o

Dos son las formas de eliminar un bloque:

o La primera consiste en seleccionar el bloque y seguidamente pulsar la tecla Suprimir. Con lo cual se elimina el bloque pero nunca los mensajes que contiene.

o La segunda consiste en activar el menú contextual que surge al pinchar encima de la representación con el botón derecho y seleccionando Remove from Model. La acción es la misma que en el caso anterior

3 . 8 . 4 N o t a

Una nota (Note en la herramienta) es, gráficamente, como una hoja de papel donde se puede insertar texto como ayuda a la comprensión de alguna parte del diagrama en el que se encuentra.

79


C r e a c i ó n

La única forma de crear una nueva nota es interactuando con la Interfaz de Barra de Herramientas Vertical (3.1.7) pulsando el botón para inmediatamente después, en el editor de diagramas de secuencia, pinchar con el botón izquierdo del ratón sobre alguna zona del diagrama para que, sin soltar el botón, desplazarse a otra zona del diagrama estableciendo así las dimensiones de la nota.

Figura 102. Detalle de Nota

S e l e c c i ó n

Para seleccionar una nota, basta con pinchar con el botón izquierdo del ratón sobre la nota deseada.

Figura 103. Detalle de selección de Nota

M o v i m i e n t o

Una nota puede moverse libremente por el diagrama si se pincha sobre ella (seleccionándola) y sin soltar el botón del ratón se arrastra a otro lugar. Aparecerá un rectángulo siguiendo el movimiento del ratón. Al posicionar el rectángulo en el área deseada la nota y todos los enlaces que mantuvieran se desplazarán hacia su nueva posición automáticamente.

80


Figura 104. Detalle movimiento de nota

E d i c i ó n

Para editar una nota, primero hay que seleccionarla y seguidamente hacer clic otra vez sobre ella. Para salir del estado de edición basta con hacer clic con el ratón en otra área del diagrama.

Figura 105. Detalle de edición de nota


Pulsando con el botón derecho sobre una nota el editor muestra un menú contextual con una sola opción denominada Delete from Model. Seleccionando esta opción, la nota se elimina por completo del modelo así como todos los enlaces que ésta mantenía.

Figura 106. Menú contextual para una nota

E l i m i n a d o

Dos son las formas de eliminar directamente una nota de un diagrama de secuencia:

- Seleccionando la nota y seguidamente pulsando la tecla Suprimir. - Mediante el menú contextual con la opción Delete from Model.

81


3 . 8 . 5 E n l a c e a n o t a

Una enlace a nota (Anchor Note en la herramienta) es, gráficamente, una línea que parte de una nota para asentarse por medio de un círculo de fondo amarillo a una clase, un mensaje o un bloque.

C r e a c i ó n

La creación de un nuevo enlace a nota de forma manual se produce al interactuar con la Interfaz de Barra de Herramientas Vertical (3.1.7) seleccionando la opción para inmediatamente después, en el editor de diagramas de secuencia, pinchar con el botón izquierdo del ratón sobre algún objeto de los anteriormente mencionados y sin soltar el botón, desplazar el puntero hacia una nota para liberar entonces el botón, o viceversa. Desde que se pulsa hasta que se libera el botón, aparece una línea en movimiento con el puntero como ayuda al usuario.

Figura 107. Detalle de Enlace a Nota


Pulsando con el botón derecho sobre un enlace a nota el editor muestra un menú contextual con una sola opción denominada Delete from Model. Seleccionando esta opción, el enlace a nota se elimina por completo del modelo.

Figura 108. Menú contextual para un enlace a nota

82


E l i m i n a d o

Para eliminar un enlace a nota del diagrama, o bien, mediante su menú contextual se selecciona la opción Delete from Model, o bien, estando seleccionado el enlace a nota se pulsa la tecla Suprimir.

3 . 8 . 6 I n t e r f a z d e E s p e c i f i c a c i ó n d e M e n s a j e s

Tomando como referencia el eje básico que forma el estereotipado de mensajes descritos en la sección Proceso de Análisis de Requisitos (2.4), se comenta a continuación la implementación que se ha confeccionado para la introducción de estos datos en RETO-UPV.

También se verá como a otros datos de interés, algunos en entrada y otros de salida (mera información redundante que se encuentra en otras partes del sistema), se les ha dado cabida en esta interfaz para que el analista pueda introducir otra información sobre el mensaje que le resulte interesante y además tenga una visión más global del entorno donde se relaciona el mensaje.

En la siguiente figura podemos observar la interfaz conteniendo como ejemplo el mensaje delete_rate del Diagrama de Secuencia perteneciente al Caso de Uso Delete Rate (ver ¡Error! No se encuentra el origen de la referencia., pág. ¡Error! Marcador no definido.).

83


Figura 109. Interfaz de Especificación de Mensajes.

En la zona superior de la interfaz observamos un conjunto de tres cajas de edición de texto. La primera se trata de la caja de edición de texto Name, donde aparece el nombre del mensaje que se encuentra con la posibilidad de ser modificado. Las dos cajas de edición siguientes muestran información sobre la clase origen y la clase destino del mensaje. Para el analista, esta información funciona en forma de recordatorio sobre en marco donde el mensaje fue creado.

Las cuatro secciones siguientes conforman la información interna del mensaje, fuera ya de su marco existencial. Esta información se encuentra dividida en cuatro secciones:

S e c c i ó n S t e r e o t y p e

Formada por cinco botones de opción, es en esta sección donde se decide el estereotipo del mensaje en cuestión (el estereotipo también puede modificarse en la Interfaz de Edición de Diagramas de Secuencia (3.8)).

84


Dependiendo del marco donde se creó el mensaje, es posible que algunas opciones queden deshabilitadas; concretamente, si alguna de las clases origen o destino tienen la función de actor, las opciones service, connect y query, aparecerán deshabilitadas.

Figura 110. Ejemplo deshabilitación Service, Connect y Query

Si ambas clases origen o destino no tienen la función de actor la opción signal aparecerá deshabilitada.

Figura 111. Ejemplo deshabilitación Signal

S e c c i ó n A s s o c i a t e d D a t a

La aparición de esta sección o no, y la aparición de ciertos controles o no, depende única y exclusivamente de la selección realizada en la sección Stereotype. Si se ha seleccionado como estereotipo alguna de las opciones None o Signal, esta sección simplemente no aparecerá; en su lugar aparecerá una zona vacía.

Si el estereotipo seleccionado es Service, la sección muestra dentro de ella una subsección llamada Kind of Change donde es posible seleccionar el tipo de cambio de la clase de entre New, Update o Destroy cuyo significado podemos encontrar en la sección Proceso de Análisis de Requisitos (2.4).

Figura 112. Ejemplo datos asociados al estereotipo Service

Si el estereotipo seleccionado es Connect, la sección muestra dentro de ella dos subseciones. En la primera, llamada Cardinality, se puede seleccionar unas cardinalidades minimas y máximas para el mensaje, refereridas al número de objetos mínimo y máximo de la clase destino que se puede seleccionar debido a la ejecución del mensaje (como se indica en Proceso de Análisis de Requisitos (2.4)). En la segunda de ellas, llamada Activity,

85


Figura 113. Ejemplo datos asociados al estereotipo Connect

Por último, si el estereotipo seleccionado es Query, la sección muestra dentro de ella dos subsecciones. En la primera, llamada Cardinality, se puede seleccionar el número mínimo y máximo de objetos de la clase destino a los que se pretende involucrar con la consulta. La segunda, llamada Derived Attribute, representa el nombre del la variable donde se debería devolver el resultado de la consulta a realizar.

Figura 114. Ejemplo datos asociados al estereotipo Query

S e c c i ó n C o n d i t i o n

En esta sección se puede expresar una condición en formato texto. El valor que tome esta condición será determinante de la ejecución de la acción que realiza el mensaje. La inclusión de una condición es opcional y aparecerá en el Interfaz de Edición de Diagramas de Secuencia (3.8) entre corchetes e inmediatamente antes del nombre del mensaje.

S e c c i ó n D e s c r i p t i o n

En esta sección, el analista tiene la posibilidad de incluir en lenguaje natural una descripción o un comentario referido a cualquier aspecto que no se pueda explicitar mediante ninguna de las otras opciones comentadas anteriormente.

3 . 8 . 7 I n t e r f a z d e E s p e c i f i c a c i ó n d e O b j e t o s

En esta interfaz es donde el usuario podrá especificar a que clase o clases se está refiriendo en una determinada representación de clase (3.8.1) en cierto Diagrama de Secuencia.

86


Esta interfaz muestra dos caras diferentes dependiendo si la representación de clase se encontraba a la izquierda de la clase sistema o si, al contrario, la representación de clase se encontraba a la derecha de la clase sistema o era precisamente la clase sistema.

Si se está tratando con representaciones a la derecha de la clase sistema la interfaz (ver Figura 115) muestra los siguientes elementos:

o Un cuadro de edición de texto denominado Object Name, en el cual es posible introducir un nombre de objeto, que no tendrá otra utilidad que la de diferenciar dos apariciones de una misma clase en el mismo diagrama.

o Una lista desplegable denominada Class Name, donde es posible seleccionar la clase que se quiere representar. En el caso de que la representación, representara a la clase sistema, esta lista se encontraría deshabilitada.

o Un botón denominado Edit Class, que enlaza con la Interfaz de Asignación de Autores y Stakeholders



o (3.4), donde se podrá editar la clase seleccionada.

87


o Un botón gráfico, , que enlaza con la Interfaz de Recursos (3.5), y permite al usuario crear una nueva clase.

Figura 115. Interfaz de Especificación de Objeto para una clase

Si nos encontramos en el caso de que la representación se encontraba a la izquierda de la clase sistema en la interfaz nos aparece una lista seleccionable de actores y un cuadro de edición de la descripción de la representación (que no de la clase). En cuanto a la edición de la descripción, el cuadro de edición tiene la misma funcionalidad que la la Interfaz de Acceso Rápido a Descripción (3.1.5).

88


Figura 116. Interfaz de Especificación de Objeto para un actor

La lista seleccionable de actores es algo particular, ya que en ella no tienen por que aparecer todos los actores del sistema. En esta lista, solo aparecerán los actores que directamente o indirectamente se comuniquen con el caso de uso al que pertenece el diagrama de secuencia. Es decir, solo aparecerán aquellos actores que interaccionen directamente con el caso de uso, y aquellos actores que interaccionen con otros casos de uso, y que mediante inclusiones a otros casos de uso se llega recursivamente a incluir al caso de uso al que pertenece el diagrama de secuencia. Para aclarar este concepto en la siguiente figura, tomando como caso de uso function1, los actores actor1 y actor2 aparecerían en la lista y el actor3 no aparecería.

89


Figura 117. Ejemplo de actores en Diagrama de Casos de Uso

3 . 8 . 8 I n t e r f a z d e E s p e c i f i c a c i ó n d e B l o q u e s

Esta interfaz se utiliza básicamente para introducir la condición de ejecución del bloque que puede expresarse como el usuario crea oportuno, aunque en un futuro posiblemente debido a ciertas comunicaciones con otras herramientas el usuario deberá adoptar algún criterio en cuanto al formato para que resulte útil esta condición.

90


Figura 118. Interfaz de Especificación de Bloques

Además también se puede editar la descripción del bloque, que como siempre ocurre, tendrá el mismo efecto que si se editara en la Interfaz de Acceso Rápido a Descripción (3.1.5).

91

-CONCLUSIONES-

4. CONCLUSIONES

RETO-UPV proporciona un buen entorno de modelado de requisitos con facilidades gráficas y no gráficas que proporcionan un entorno adecuado para la especificación de requisitos.

Como trabajo futuro se proporcionará la comunicación con la herramienta OLIVANOVA Modeler que es una herramienta de modelado conceptual y generación automática de código.

92

-REFERENCIAS-

Referencias

[REG95] Regnell B., Kimbler K., y Wesselen A. Improving the Use Case Driven Approach to Requirements Engineering. In Second IEEE International Symposium on Requirements Engineering. IEEE, Marzo 1995

[Jac&Al 92] Jacobson i., Christerson M., Jonson P., Overgaard G. Object-Oriented Software Engineering. A Use Case Approach. Addison-Wesley, 1992.

[UML Web Site]

OMG Unified Modeling Language Specification. Versión 1.4. http://www.omg.org/uml

[IPWRE] Insfrán E., Pastor O. and Wieringa R., Requirements Engineering-Based Conceptual Modelling. Journal "Requirements Engineering" (RE), March 2002. 7(2): p. 61-72. Springer-Verlag. ISSN: 0947-3602 (printed version) ISSN: 1433-010X (electronic version).

[IWPTRADE] Insfrán E., Wieringa R. and Pastor O., Using TRADE to improve an Object-Oriented method. University of Twente. Computer Science Department. Enschede, the Netherlands. July 1999.

[IBPGCS] Insfrán E., Burbano M. and Pastor O. Generating Conceptual Schemas from Requirements Models. in Jornadas de Ingeniería de Requisitos Aplicada (JIRA 2001). June 2001. Sevilla, Spain: Universidad de Sevilla. ISBN: 84-96086-06-2

[IDBMR] Insfrán E., Díaz I. and Burbano M. Modelado de Requisitos para la Obtención de Modelos Conceptuales. in V Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes Software (IDEAS'2002). Abril 2002. La Habana, Cuba. ISBN: 959-7160-14-5.

[CM-Extreme] Insfrán E., Pelechano V. and Pastor O., Conceptual Modeling in the eXtreme. Journal "Information and Software Technology" (IST), 2002. 44(11): p. 659-669. Elsevier Science. ISSN: 0950-5849

[OO-Method] Pastor O., Gómez J., Insfrán E. and Pelechano V., The OO-Method approach for Information Systems Modelling: from Object-Oriented Conceptual Modeling to Automated Programming. Information Systems, 2001. 26(7): p. 507-534. ISSN 0306-4379

93

http://www.omg.org/uml

http://link.springer.de/link/service/journals/00766/bibs/2007002/20070061.htm

http://link.springer.de/link/service/journals/00766/bibs/2007002/20070061.htm

http://www.dsic.upv.es/~einsfran/papers/18-Trade-OOMethod.pdf

http://www.dsic.upv.es/~einsfran/papers/18-Trade-OOMethod.pdf

http://www.dsic.upv.es/~einsfran/papers/28-sevillaprn.pdf

http://www.dsic.upv.es/~einsfran/papers/28-sevillaprn.pdf

http://www.dsic.upv.es/~einsfran/papers/39-ideas2002.pdf

http://www.dsic.upv.es/~einsfran/papers/39-ideas2002.pdf

http://www.sciencedirect.com/science?_ob=GatewayURL&_origin=compsciportal&_method=citationSearch&_urlversion=4&_piikey=S0950584902000939&_version=1&md5=1fe44a8d50db18d9f8671cc6adb50d08

http://dx.doi.org/10.1016/S0306-4379(01)00035-7

http://dx.doi.org/10.1016/S0306-4379(01)00035-7

http://dx.doi.org/10.1016/S0306-4379(01)00035-7

-ÍNDICE DE FIGURAS-

Indice de Figuras Figura 1. Relaciones entre Modelos ................................................................................. 6 Figura 2. Ejemplo de Misión del Sistema en ejemplo Rent a Car ................................... 8 Figura 3. Ejemplo de Árbol de Refinamiento de Funciones en ejemplo Rent a Car ..... 10 Figura 4. Relación extends en UML y en RETO-UPV .................................................. 11 Figura 5. Interfaz de Declaración de Extensiones en RETO-UPV................................. 12 Figura 6. Relación include en UML y en RETO-UPV .................................................. 13 Figura 7. Interfaz de Especificación de Casos de Uso en RETO-UPV.......................... 17 Figura 8. Ejemplo de Diagrama de Secuencia................................................................ 19 Figura 9. Propiedades de mensajes <<signal>> ............................................................. 20 Figura 10. Propiedades de mensajes <<service>> ......................................................... 20 Figura 11. Propiedades de mensajes <<query>>............................................................ 21 Figura 12. Ejemplo de mensajes en un Diagrama de Secuencia. ................................... 22 Figura 13. Interfaz General de RETO-UPV ................................................................... 23 Figura 14. Menú File ...................................................................................................... 24 Figura 15. Menú Edit...................................................................................................... 24 Figura 16. Menú View.................................................................................................... 24 Figura 17. Menú Project ................................................................................................. 25 Figura 18. Menú Resources ............................................................................................ 25 Figura 19. Menú Window............................................................................................... 25 Figura 20. Opciones más habituales ............................................................................... 25 Figura 21. Interfaz de Árbol de Refinamiento de Funciones ......................................... 26 Figura 22. Detalle de Diagramas de Secuencia en la interfaz ........................................ 26 Figura 23. Detalle menú contextual de un grupo funcional ........................................... 27 Figura 24. Detalle menú contextual de una función elemental ...................................... 27 Figura 25. Detalle menú contextual de un diagrama de secuencia................................. 28 Figura 26. Detalle Interfaz de Lista de Acceso Rápido a Actoeres................................ 29 Figura 27. Detalle menú contextual Lista de Actores .................................................... 29 Figura 28. Detalle menú contextual actor....................................................................... 29 Figura 29. Detalle Interfaz de Lista de Acceso Rápido a Clases.................................... 30 Figura 30. Detalle menú contextual Lista de Clases ...................................................... 30 Figura 31. Detalle menú contextual Clase...................................................................... 30 Figura 32. Detalle de Interfaz de Acceso Rápido a Descripciones ................................ 31 Figura 33 Interfaz de Barra de Herramientas para Elementos de Acceso Rápido ......... 31 Figura 34. Detalle barra de herramientas para diagramas de casos de uso y para

diagramas de secuencia .......................................................................................... 32 Figura 35. Intefaz de Propiedades de Nodo – General ................................................... 34 Figura 36. Intefaz de Propiedades de Nodo – Priority ................................................... 35 Figura 37. Intefaz de Propiedades de Nodo – Description............................................. 36 Figura 38. Intefaz de Propiedades de Nodo - NFR and Docs......................................... 37 Figura 39. Interfaz de Selección de Objetos................................................................... 38 Figura 40. Interfaz de Asignación de Autores y Stakeholders ....................................... 38 Figura 41. Interfaz de Recursos...................................................................................... 39 Figura 42. Interfaz de Recursos. Requisitos no funcionales........................................... 40 Figura 43. Detalle representación de Caso de Uso......................................................... 42 Figura 44. Detalle selección deCaso de Uso .................................................................. 42 Figura 45. Detalle de Edición de Etiquetas de Casos de Uso......................................... 43 Figura 46. Detalle de Movimiento de una Representación de Caso de Uso .................. 43 Figura 47. Menú contextual para una Representación de Caso de Uso ......................... 44

94


Figura 48. Detalle de representación de Actor ............................................................... 45 Figura 49. Detalle selección de representación de actor ................................................ 46 Figura 50. Detalle de edición de etiquetas de representación de actor.......................... 46 Figura 51. Detalle de movimiento de representación de actor ....................................... 47 Figura 52. Menú contextual para una Representación de Actor..................................... 47 Figura 53. Detalle de Comunicación .............................................................................. 48 Figura 54. Detalle de selección de Comunicación ......................................................... 48 Figura 55. Menú contextual para una comunicación...................................................... 49 Figura 56. Detalle de interacción.................................................................................... 50 Figura 57. Detalle de selección de Interacción............................................................... 50 Figura 58. Menú contextual para una interacción .......................................................... 51 Figura 59. Detalle de Generalización entre actores........................................................ 52 Figura 60. Detalle de selección de Generalización......................................................... 52 Figura 61. Menú contextual para una generalización..................................................... 53 Figura 62. Detalle de Nota.............................................................................................. 53 Figura 63. Detalle de selección de Nota ......................................................................... 54 Figura 64. Detalle movimiento de nota .......................................................................... 54 Figura 65. Detalle de edición de nota ............................................................................. 55 Figura 66. Menú contextual para una nota ..................................................................... 55 Figura 67. Detalle de Enlace a Nota ............................................................................... 56 Figura 68. Menú contextual para un enlace a nota ......................................................... 56 Figura 69. Interfaz de Especificación de Casos de Uso. ................................................ 57 Figura 70. Visualización de la condición de una extensión. .......................................... 58 Figura 71. Especificación de Paso.................................................................................. 61 Figura 72. Opción Include en Especificación de Paso ................................................... 62 Figura 73. Interfaz de creación de extensiones............................................................... 63 Figura 74. Ejemplo Diagrama de Secuencia .................................................................. 64 Figura 75. Detalle Clase Sistema.................................................................................... 65 Figura 76. Detalle un solo actor ..................................................................................... 65 Figura 77. Detalle varios actores .................................................................................... 66 Figura 78. Detalle de clase ............................................................................................. 66 Figura 79. Detalle selección de clase.............................................................................. 67 Figura 80. Detalle de la Interfaz de especificación de objetos ....................................... 67 Figura 81. Detalle Movimiento de clases ....................................................................... 68 Figura 82. Menú contextual para una representación de clase ....................................... 69 Figura 83. Detalle de mensaje con estereotipo signal .................................................... 70 Figura 84. Detalle de mensaje con estereotipo service................................................... 71 Figura 85. Detalle de mensaje con estereotipo query..................................................... 71 Figura 86. Detalle de mensaje con estereotipo connect.................................................. 71 Figura 87. Detalle de mensaje con condición................................................................. 71 Figura 88. Detalle selección de mensaje ........................................................................ 72 Figura 89. Detalle de la Interfaz de especificación de mensajes .................................... 73 Figura 90. Detalle Movimiento de mensaje ................................................................... 74 Figura 91. Menú contextual para un mensaje sin estereotipo......................................... 75 Figura 92. Menú contextual para un mensaje sin estereotipo......................................... 75 Figura 93. Menú contextual para un mensaje con estereotipo signal............................. 75 Figura 94. Menú contextual para un mensaje de estereotipo service ............................. 75 Figura 95. Menú contextual para un mensaje con estereotipo query ............................. 76 Figura 96. Opcion insert en un mensaje con estereotipo connet .................................... 76 Figura 97. Opción delete en un mensaje con estereotipo connect.................................. 76

95


Figura 98. Menú contextual para un mensaje con estereotipo connect .......................... 76 Figura 99. Detalle de bloque .......................................................................................... 77 Figura 100. Detalle selección de bloque......................................................................... 78 Figura 101. Detalle de la Interfaz de especificación de bloques .................................... 79 Figura 102. Detalle de Nota............................................................................................ 80 Figura 103. Detalle de selección de Nota ....................................................................... 80 Figura 104. Detalle movimiento de nota ........................................................................ 81 Figura 105. Detalle de edición de nota ........................................................................... 81 Figura 106. Menú contextual para una nota ................................................................... 81 Figura 107. Detalle de Enlace a Nota ............................................................................. 82 Figura 108. Menú contextual para un enlace a nota ....................................................... 82 Figura 109. Interfaz de Especificación de Mensajes. ..................................................... 84 Figura 110. Ejemplo deshabilitación Service, Connect y Query.................................... 85 Figura 111. Ejemplo deshabilitación Signal................................................................... 85 Figura 112. Ejemplo datos asociados al estereotipo Service.......................................... 85 Figura 113. Ejemplo datos asociados al estereotipo Connect ........................................ 86 Figura 114. Ejemplo datos asociados al estereotipo Query............................................ 86 Figura 115. Interfaz de Especificación de Objeto para una clase................................... 88 Figura 116. Interfaz de Especificación de Objeto para un actor .................................... 89 Figura 117. Ejemplo de actores en Diagrama de Casos de Uso ..................................... 90 Figura 118. Interfaz de Especificación de Bloques ........................................................ 91

96

Documents

Manual de Usuario RETO-UPVeinsfran/pfc/RETO-Manual.pdf · UNIVERSIDAD POLITÉCNICA DE VALENCIA DEPARTAMENTO DE SISTEMAS INFORMATICOS Y COMPUTACIÓN - DSIC ... el Diagrama de Casos