Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema.
Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.
Un caso de uso describe desde el punto de vista de los actores un grupo de actividades de un sistema que produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas:
- Cada caso de uso está relacionado como mínimo con un actor
- Cada caso de uso es un iniciador (es decir, un actor)
- Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
- <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso
- <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.
- Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
No hay comentarios:
Publicar un comentario