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 comunicacin con el cliente. Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis (qu). De forma que al ser parte del anlisis 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 ms claro es que te presente uno. Este podra ser el caso de uso (use case) de escribir un mensaje en un foro. Nombre: Autor: Fecha: Crear mensaje foro Joaquin Gracia 24/08/2003

Descripcin: Permite crear un mensaje en el foro de discusin. Actores: Usuario de Internet logeado. Precondiciones: El usuario debe haberse logeado en el sistema. Flujo Normal: 1. El actor pulsa sobre el botn para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el ttulo del mensaje y una zona de mayor tamao para introducir el cuerpo del mensaje. 3. El actor introduce el ttulo 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 permitindole que los corrija Poscondiciones: El mensaje ha sido almacenado en el sistema. Los actores son aquellos que interactan 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 ejecucin 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 nmero no resulta nada fcil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visin general del asunto, y ahora s es cuando los diagramas de casos de uso son de utilidad. Elementos bsicos: Actores: Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa que interacta con el sistema. No tiene por qu ser un ser humano, puede ser otro sistema informtico o unidades organizativas o empresas. Siempre hay que intentar independizar los actores de la forma en que se interacta con el sistema. Por ejemplo un teclado no es un actor en la mayor parte de los casos, slo un medio para introducir informacin 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 descripcin textual.

Asociaciones: Hay una asociacin entre un actor y un caso de uso si el actor interacta con el sistema para llevar a cabo el caso de uso. Tipos de asociaciones: Existen tres tipos de asociacin o relaciones en los diagramas de casos de uso: Include: Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar comportamiento comn en dos o ms casos de uso. Las ventajas de esta asociacin son: Las descripciones de los casos de uso son ms cortas y se entienden mejor. La identificacin de funcionalidad comn puede ayudar a descubrir el posible uso de componentes ya existentes en la implementacin. Las desventajas son: La inclusin de estas relaciones hace que los diagramas sean ms difcil de leer, sobre todo para los clientes. Extend: Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relacin implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En principio esas variaciones pueden tambin 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 tambin pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos estn relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos ltimos la semntica es muy similar a las relaciones extend. Lmites del sistema: Resulta til dibujar los lmites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.

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