COMO CONSTRUIR UN

DIAGRAMA DE CASO DE USO

| |
 
 | |   
 ]UE HACER PRIMERO

 Saber los requerimientos de la aplicación a desarrollar.

Para ello tendremos que saber el dominio de la aplicación,
por ejemplo, si la aplicación trata de la gestión de un
videoclub tendremos que indagar en la administración real
de un videoclub.

 Cuando tengamos un conocimiento amplio del dominio de

la aplicación, en una hoja o en el ordenador usaremos un
sistema de listas que nos ayudará a vislumbrar el diagrama
de casos de uso definitivo.
 GENERALIZANDO

 Hacemos una primera lista con todas las acciones

posibles que se puedan llevar a cabo en la aplicación.

 Después hacemos una lista más específica con una

selección de las acciones más relevantes que se
realizarán en la aplicación. Estas acciones serán las
que aparezcan en el diagrama final.

 Realizamos el diagrama de casos de uso UML.

 ELEMENTOS

 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
 DESCRIPCION

 ‡ La descripción se centra en lo que debe hacerse, no

en la manera de hacerlo

 ‡ Deben evitarse expresiones imprecisas. Se busca

sencillez y claridad

 ‡ Puede utilizarse un lenguaje estructurado para

representar secuencia, repeticiones y situaciones
opcionales
 CONSTRUCCION

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

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

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

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

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

 ¿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.
EJEMPLO
 ASOCIACIONES

 
 Existen tres tipos de asociación o relaciones en los
diagramas de casos de uso:

 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.
EJEMPLO
 ASOCIACIONES

 : 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
circurnstancias. En principio esas variaciones
pueden también mostrarse como diferentes
descripciones de escenarios asociadas al mismo caso
de uso.
EJEMPLO

: Resulta útil dibujar los
límites del sistema cuando se pretende hacer un
diagrama de casos de uso para parte del sistema .
EJEMPLO