UML: Casos de Uso. Use case
Desarrollo de Software Orientado a Objetos
Por Joaquin Gracia27 de Septiembre de 2003
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:
| |
Flujo Alternativo:
| |
| 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.
)Leer más...
.jpg)
