Diagramas de Casos de Uso: Representación de la Interacción entre Sistemas y Actores, Monografías, Ensayos de Diseño

¡Descarga Diagramas de Casos de Uso: Representación de la Interacción entre Sistemas y Actores y más Monografías, Ensayos en PDF de Diseño solo en Docsity! Diagramas de Casos de uso • Un caso de uso representa una interacción típica entre un usuario y un sistema informático • Utilizaremos los casos de uso para: – Capturar los requisitos funcionales del sistema • Un caso de uso es un grafo con dos tipos de nodos: – Actor - que representa cualquier elemento que intercambia información con el sistema, por lo que está fuera de él – Caso de uso - Es una secuencia de intercambios en diálogo con el sistema que se encuentran relacionadas por su comportamiento – Los arcos entre los actores y los casos de uso se denominan arcos de comunicación • El actor es un agente externo. Un actor representa un cierto papel que un usuario puede jugar. • Una máquina también puede ser un actor. • Cada caso de uso tiene una descripción informal en lenguaje natural o en un lenguaje estructurado Diagramas de Casos de uso Un diagrama de casos de uso es un grafo que incluye: • los actores • un conjunto de casos de uso encerrados en un recinto, • la comunicación entre los actores y los casos de uso • las generalizaciones sobre los casos de uso. Notación de los casos de uso en UML •Los casos de uso se representan por una elipse conteniendo el nombre, que opcionalmente podría ir debajo de la elipse. •Los actores se representan con un monigote y el nombre del actor al pie de la figura. Los nombres de los actores suelen empezar por mayúscula. Caso de Uso Actor Arco de comunicación Construcción de Casos de uso • Es un proceso iterativo. Se van descubriendo los escenarios desde el punto de vista del usuario, es decir los ACTORES. • Para detectar los casos de uso es conveniente hacer las siguientes preguntas: – ¿Cuáles son las principales tareas de cada actor? – ¿Escribe/lee/modifica el actor alguna información del sistema? – ¿Informa el actor al sistema de los cambios externos? – ¿Desea el actor ser informado de cambios no esperados? • Es un proceso iterativo, en el que pueden utilizarse distintas técnicas de observación o de entrevista estructurada (para describir los escenarios potenciales desde el punto de vista del usuario). • Los casos de uso no pueden ser demasiado pequeños, ya que deben aportar algún valor al actor. • En el momento de identificar los actores es conveniente distinguir entre – actores principales (que son los que emplean directamente el sistema llevando a cabo las tareas más importantes) – actores secundarios (existen para que los principales puedan utilizar el sistema). • La estructura del sistema debe decidirse teniendo en cuenta a los actores principales. Construcción de Casos de uso • Proceso de elaboración de los casos de uso • Identificar a grandes trazos los casos de uso – Las principales etapas de cada caso de uso se describen en un par de frases – Se distingue un caso principal y se identifican los casos alternativos y excepciones • Se establece un proceso iterativo en el cual los casos de uso se amplían, profundizándose en su descripción, buscándose etapas comunes y alternativas que representar en otros caso de uso relacionados por las relaciones incluye, generaliza y extiende. • Se debe cuidar que: – Exista una descripción breve que represente una verdadera imagen del caso de uso – Las condiciones de arranque y parada del caso de uso estén bien definidas – Los usuarios estén satisfechos de la secuencia de interacciones entre el actor y el caso de uso Construcción de Casos de uso •El problema fundamental es encontrar el nivel de abstracción adecuado. En general si un caso de uso se hace demasiado grande, a medida que se va detallando es conveniente dividirlo en varios. •Se pueden hacer preguntas como: •¿es posible ejecutar un paso de forma independiente a los otros o siempre va encadenado con ellos? Dos pasos que siempre se encadenan forman parte habitualmente del mismo caso de uso •¿es lógico agrupar varios pasos para documentarlos, probarlos o modificarlos en conjunto? Si es así, deben formar parte del mismo caso de uso. • Escenarios •Un caso de uso tiene como instancias los escenarios: situaciones concretas que deben recorrer total o parcialmente el caso de uso. •Se deben consideran en lo posible todos los escenarios de modo que se pueda validar el caso de uso. •La última comprobación consiste por tanto en asegurar que el caso de uso represente todos los escenarios. •A veces se confunde el caso de uso con alguno de sus escenarios: Si aparecen muchos caso de uso puede que sea un síntoma de una mala descripción del sistema Casos de uso: Peligros No saber cuando parar. - Existe una gran confusión entre la adquisición de los requisitos y los casos de uso y entre el diseño y los casos de uso. Por ejemplo, •¿Es un juego completo de casos de uso lo mismo que los requisitos de un producto? •¿Existen otros requisitos (del producto o del proyecto) que no estén capturados en los casos de uso? •¿Hay algún aspecto del diseño/arquitectura del sistema que no se ha capturado con los casos de uso? •Hay que tener claras las guías para establecer las relaciones entre los casos de uso, el análisis y el diseño. La cobertura es el mayor problema de quien usa los casos de uso: Una cosa es decir que “el conjunto de todos los casos de uso especifican la totalidad de la funcionalidad del sistema” … y otra cosa es demostrar que se ha capturado por completo la funcionalidad del sistema en un conjunto de casos de uso. Casos de uso - Ejemplos sacar dinero depositar dinero administración cliente sistema del banco transferencias operador Ejemplo de un Cajero automático CU-003 Sacar dinero Descripción El sistema deberá permitir al cliente del banco, en cualquier momento, sacar dinero según se describe en el siguiente caso de uso: Secuencia Normal 1+ El usuario inserta la tarjeta en el cajero 2 + El cajero lee el código de la banda magnética de la tarjeta y verifica si es aceptable y pide el código del usuario 3+ El usuario introduce el código 4 + Si el código es correcto, el cajero pide al usuario que seleccione el tipo de transacción deseada 5+ El usuario selecciona la función sacar dinero, 6 + El cajero le pide al usuario que teclee la cantidad deseada 7 + El usuario teclea la cantidad que quiere sacar, 8 + El cajero envía la petición al sistema del banco 9 a Si conecta el sistema deberá comprobar si hay dinero en la cuenta 9 b Si no conecta el sistema deberá comprobar si el dinero es menos que el límite 10 En cualquiera de los dos casos el sistema: + expulsa la tarjeta + imprime el recibo + entrega el dinero Excepciones 2' La tarjeta no es aceptada + Se expulsa emitiendo un sonido 4' Código incorrecto (1,2) + Se emite un mensaje dando al usuario la oportunidad de volver a introducir el código (paso 3) 4'' Código incorrecto (3) + Se emite un mensaje y se retiene la tarjeta 9' No autorizado para sacar dinero + El sistema de banco no autoriza a sacar dinero. Se emite un mensaje de información y se expulsa la tarjeta 9 a ', 9 b' No hay dinero suficiente + El cajero no dispone de la cantidad pedida. Emite un mensaje y vuelve al paso 7 1..10' Cancelar + En cualquier momento el usuario puede cancelar la transacción, con lo que se expulsa la tarjeta Casos de uso - Ejemplos Completar pedido Empleado Venta por catalogo telefónico Comprobación del estado Vendedor Realización de un pedido Cliente Establecer credito Supervisor Ejercicio • Realizar el diagrama de Casos de Usos para los siguientes enunciados • 1. Sistema de una biblioteca el usuario prestado un libro a la bibliotecaria lo lleva luego lo devuelve y la bibliotecario cada día actualiza el catálogo de la biblioteca • 2. Maquina expendedora de Cafe Ingeniería del Software I - 3º I.T.Informática de Gestión Peticiones al catálogo con pedidos Realización de un pedido Información suministrada por el Cliente Pedido de productos Orden de pago