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).
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.
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.
Nos sirven de base para elaborar los aspectos funcionales y nos dan soporte en las etapas de modelado, desarrollo y validación de software.
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
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.
Un actor es una entidad, puede ser entre una persona, organización, dispositivo o componente de software externo que interactúa con el sistema.
Representa las acciones que uno o varios de los actores realizan a fin de conseguir un objetivo determinado.
Es aquello que incluye los casos de usos que se están desarrollando.
Existen 4 tipos diferentes de relaciones que se pueden usar dentro del diagrama de casos de usos.
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
Sirve para representar la parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o en un punto determinado.
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
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.
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
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.
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:
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)
FIN.