Casos de USO

Diagramas de Casos de uso

DOCUMENTOS ALTERNOS.

EjemploCasodeUso_Pantallas,

ResumenDiapositivasUML_CasosDeUso

Plantilla

DEFINICION

Quien más o quien menos ha visto algún diagrama UML, lo más probable es que te hayas topado con algún diagrama de clases. También es muy probable que hayas visto algún caso de uso (use case), pero… ¿sabes lo que son?

En los libros que tratan de UML, normalmente, los primeros diagramas que presentan, de entre todos los tipos de diagramas UML, son los Casos de Uso. Y como están en los primeros capítulos siempre son leídos y pocas veces bien entendidos.

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. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean también una forma visual de representar la información. Sin embargo estás muy equivocado, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para que quede claro, “Los diagramas no son lo importante“.

Se que alguno estará impaciente con los diagramas, así que luego los trataré. Pero primero vayamos con lo realmente interesante.

Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿que 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:

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

Saltándome los campos evidentes como nombre, autor, fecha y descripción; 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.

De forma que un caso de uso (use case) es un documento como el anteriormente presentado. Los casos de uso se pueden detallar más o menos dependiendo de la necesidad del problema. El que te he presentado no es completo, si te interesa puedes echar un vistazo a una plantilla completa de un caso de uso (use case), se les suele llamar casos de uso “full-dressed”.

Pero no voy a terminar sin explicar, como he prometido antes, los diagramas de casos de uso, que a mi me gusta llamar diagramas de “muñecos y pelotas”.

Muñecos y Pelotas

Cuando empiezas a tener un número considerable de casos de uso como el anterior, no resulta nada fácil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visión general del asunto, y ahora si, es cuando los diagramas de casos de uso son de utilidad.

En los diagramas de casos de uso los muñecos son los actores y las pelotas son los documentos de casos de uso. Así que dibujas un muñeco por actor y una pelota por cada caso de uso (use case) y los enlazas con líneas cuando haya una relación entre ellos.

Con esto consigues una visión general de cómo los diferentes actores interactúan con los distintos casos de uno.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Definiciones básicas

Actores

Artículo principal:

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

/*/*/*/*/*/*/*/

Los actores pueden representar roles jugados por usuarios humanos, hardware externo, u otros sujetos. Un actor no necesariamente representa una entidad física específica, sino simplemente una faceta particular (es decir, un “rol”) de alguna actividad que es relevante a la especificación de sus casos de uso asociados. Así, una única instancia física puede jugar el rol de muchos actores diferentes y, asimismo, un actor dado puede ser interpretado por múltiples instancias diferentes

*/*/*/*/*/*/*

Tipos de relaciones

  • comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
  • usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.
  • extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura

Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.

En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.

Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.

Video relacionado.

REFERENCIAS

De los modelos a los casos de uso

 

Documentacion complementaria para realizar un ejercicio completo con Diagramas_de_ejemplocompleto

Anuncios

Acerca de JARB

Profesor investigador

Comentarios

Aún no hay comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: