UML
Diagramas de Casos de Uso
#2
Diagrama de Casos de Uso
Todo sistema tiene como mínimo un diagrama de casos de uso que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).
¿Qué es un caso de uso?
Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa.
Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.
Ejemplo de caso de uso
Un sistema de ventas, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente.
Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso de uso ingresar pedido.
¿Para qué sirven los casos de uso?
Nos sirven de base para elaborar los aspectos funcionales y nos dan soporte en las etapas de modelado, desarrollo y validación de software.
¿Y los diagramas?
Muestra los distintos requisitos funcionales que se esperan de una aplicación o sistema, y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Ayuda a capturar el comportamiento deseado del sistema sin tener que especificar cómo se implementa ese comportamiento
Algunas Características
-
Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de un actor.
-
Se puede considerar que, hasta cierto punto, cada caso de uso es independiente de los demás.
-
Permiten definir los límites del sistema y las relaciones entre el sistema y su entorno.
Elementos del Diagrama de Casos de Uso
Actor
Un actor es una entidad, puede ser entre una persona, organización, dispositivo o componente de software externo que interactúa con el sistema.
Caso de Uso
Representa las acciones que uno o varios de los actores realizan a fin de conseguir un objetivo determinado.
Límite del Sistema
Es aquello que incluye los casos de usos que se están desarrollando.
Relaciones
Existen 4 tipos diferentes de relaciones que se pueden usar dentro del diagrama de casos de usos.
1. Asociación
Una de las relaciones más comunes dentro del diagrama de caso de usos, ésta es normalmente entre un actor y un caso de uso
2. <<extend>>
Sirve para representar la parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o en un punto determinado.
3. <<include>>
Sirve para complementar un caso de uso con otro y compartir una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un caso de uso describiendo sus subfunciones
4. Generalización
Indica que una clase hereda los métodos y atributos especificados por una clase, por lo cual una clase derivada además de tener sus propios métodos y atributos, podrá acceder a las características y atributos visibles de su clase base.
Flujo de eventos
Describe cómo y cuándo empieza y acaba el caso de uso, cuando interactúan con los actores y qué objetos se intercambian. Además conviene separar el flujo principal de uno alternativo.
Caso de Uso: Validar inicio de sesión
Flujo Normal:
1. El Cliente inserta su tarjeta
2. El sistema solicita la clave de acceso
3. El Cliente escribe la clave por teclado
4. El sistema muestra opciones por menús
Flujo Alternativo:
3.A El sistema verifica la clave, y si no es correcta muestra mensaje de clave errónea permitiendo al cliente que vuelva a escribir la clave
Descripción Textual
Lo más importante de los casos de uso es su descripción, mucho más que los diagramas de casos de uso.
La descripción textual de un actor debe describir el rol desempeñado por el actor en su interacción con el sistema.
La descripción textual de un caso de uso debe describir el modo en que un actor interactúa con el sistema.
¿Cómo se desarrolla un modelo de Casos de Uso?
Antes de hacer un diagrama de caso de uso es necesario tratar de entender los requerimientos del sistema, y expresar lo que el sistema debe hacer.
Ejemplo:
“El sistema debe permitir a los usuarios registrarse. El administrador debe poder validar las peticiones de registro antes de que los usuarios puedan publicar nuevos mensajes”.
En base a lo anterior, se trata de responder las preguntas:
- ¿Cuales son las principales funciones o tareas realizadas por el actor?
- ¿Qué información del sistema adquiere, produce o transforma el actor?
- ¿Deberá el sistema informar al actor de los cambios producidos en el entorno?
- ¿Qué información del sistema desea el actor?
- ¿Debe informarse al actor de algún cambio inesperado?
Reglas de Estilo para los Diagramas de Casos de Uso
- Cada actor y caso de uso debe tener un nombre único.
- Los actores deben tener nombres y/o iconos representativos y deben representar roles.
- El nombre de un caso de uso debe indicar acción y debe ser claro y conciso.
- Forma General para el nombre de caso de uso: Verbo (Infinitivo) + Predicado
- Evitar el cruce de líneas (En general, mantener el diagrama ordenado)
- Evitar tener demasiados casos de uso en el mismo diagrama (Máximo 10)
- Narrar el flujo de eventos usando voz activa, en tiempo presente y desde la perspectiva del actor: “El usuario introduce la clave”
-
El caso de uso que se describe debe expresar un solo requisito funcional (No tratar de expresar más de un requisito funcional en el mismo caso de uso)
Ejemplos
#1
#2
#3
#4
#5
Gracias
FIN.
UML: Diagrama de Casos de Uso
By Andres Godinez (Pistö)
UML: Diagrama de Casos de Uso
- 413