Citation preview

DIAGRAMAS DE CASOS DE USO Los casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente. Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. En los UML se presentan los distintos diagramas de clases, pero sin embargo los diagramas no son lo importante. Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿Qué es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario. Pero lo más claro es que te presente uno. Este podría ser el caso de uso (use case) de escribir un mensaje en un foro. Nombre:

Crear mensaje foro

Autor:

Joaquin Gracia

Fecha:

24/08/2003

Descripción: Permite crear un mensaje en el foro de discusión. Actores: Usuario de Internet logeado. Precondiciones: El usuario debe haberse logeado en el sistema. Flujo Normal: 1. El actor pulsa sobre el botón para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje. 3. El actor introduce el título del mensaje y el cuerpo del mismo.

4. El sistema comprueba la validez de los datos y los almacena. Flujo Alternativo: 4. El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole que los corrija Poscondiciones: El mensaje ha sido almacenado en el sistema. Los actores son aquellos que interactúan con el sistema. Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo. Luego tenemos el flujo de eventos, que corresponde a la ejecución normal y exitosa del caso de uso (use case). Los flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados. Por último, las poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente. Ahora, entrando en la parte de los diagramas, Cuando empiezas a tener un número no resulta nada fácil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visión general del asunto, y ahora sí es cuando los diagramas de casos de uso son de utilidad. Elementos básicos: Actores: Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa que interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema informático o unidades organizativas o empresas. Siempre hay que intentar independizar los actores de la forma en que se interactúa con el sistema. Por ejemplo un teclado no es un actor en la mayor parte de los casos, sólo un medio para introducir información al sistema. Suele ser útil mantener una lista de los usuarios reales para cada actor. Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones. Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando. Se representan mediante un óvulo. Cada caso de uso debe detallarse, habitualmente mediante una descripción textual.

Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema para llevar a cabo el caso de uso. Tipos de asociaciones: Existen tres tipos de asociación o relaciones en los diagramas de casos de uso: Include: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar comportamiento común en dos o más casos de uso. Las ventajas de esta asociación son: § Las descripciones de los casos de uso son más cortas y se entienden mejor. § La identificación de funcionalidad común puede ayudar a descubrir el posible uso de componentes ya existentes en la implementación. Las desventajas son: § La inclusión de estas relaciones hace que los diagramas sean más difícil de leer, sobre todo para los clientes. Extend: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relación implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En principio esas variaciones pueden también mostrarse como diferentes descripciones de escenarios asociadas al mismo caso de uso. La flecha en el caso de las relaciones “extend” va hacia el caso de uso “original”. Generalizaciones: En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos últimos la semántica es muy similar a las relaciones “extend”. Límites del sistema: Resulta útil dibujar los límites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.

Bibliografía http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php http://www.slideshare.net/ktyk/uml-casos-de-uso http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf