Casos de uso

Diseñando un Diagrama de Casos de Uso con UML (Unified Modeling Language)
UML especifica una notación para el diseño de diagramas de casos de uso. Hay que decir que un diagramas de casos de uso no son una especificación detallada de cada caso de uso sino de aquellos que poseen una mayor relevancia en el desarrollo del sistema. Para ello existen otras vistas como la vista de interacción,específicamente los diagramas de secuencia o de colaboración que expresan detalladamente el flujo de interacción entre el actor y el sistema de manera detallada conocidos como casos de uso extendidos. Los diagramas de casos de uso son un nivel de abstracción más alto que el detalle de los mismos y presenta todos los casos de uso del sistema a construir (en algunos casos se crean diagramas de casos de usode varios niveles o separados por módulos esto depende del tamaño del sistema o del propio gusto del modelador)
Para poder crear diagramas de casos de uso hay que entender la semántica para su construcción. UML 2.0  definió una notación para cada elemento del diagrama:
1. Actor
2. Caso de Uso
3. Relaciones
A. Asociación
B. Inclusión (INCLUDE)
C. Extensión (EXTEND)D. Generalización
1. Actor: El caso de uso es una descripción funcional de la interacción entre uno o varios actores y el sistema que se está modelando específicamente sobre la funcionalidad desarrollada en el caso de uso. El actor está asociado a un rol específico que cumple en la interacción con el sistema (Ej. Usuario administrador, empleado, etc.). Un actor del sistema generalmentecorresponde con un ser humano que tiene un rol de interacción con el caso de uso pero no siempre es así; un actor puede ser un hardware, otro sistema, un servicio que consume las funcionalidades modeladas en el caso de uso, etc. En UML 2.0 un actor se expresa simplemente con una figura en forma de ser humano. Esta figura va acompañada del nombre del actor que representa.

Notación UML 2.0 para unActor
2. Caso de Uso: Un casos de uso define un comportamiento del sistema para cumplir un objetivo particular para un actor particular. Previa a la especificación de casos de uso existe todo un proceso que se expondrá en otros artículos de casosdeuso.com relacionada con la Ingeniería de Requerimientos, pero básicamente se podría decir que un requerimiento funcional del sistema puede dar origen auno o muchos casos de uso. Es por eso que definir correctamente todos los requerimientos funcionales (y no funcionales) previos al diseño de diagramas de casos de uso es tan importante.  Por ejemplo, podríamos decir que existe un requerimiento funcional que es el CRUD (Create-Read-Update-Delete) para Administrar Clientes en un sistema de pedidos, es decir, que este requerimiento está asociado conel comportamiento de que el sistema adicione, consulte, actualice un elimine un cliente del sistema, estas operaciones solo podrán ser realizadas por un usuario Administrador de Pedidos. Desde la orientación a objetos también se observa claramente que existe una entidad de negocio (clase) que es el Cliente compuesto de un conjunto de atributos y operaciones (las del requerimiento). El diagrama decasos de uso no muestra el detalle de estas operaciones (se puede presentar en un diagrama de secuencias o en artefacto de software que es un documento de caso de uso del que hablaremos en otros artículos) pero sí presenta la relacion entre el actor (en este caso el cliente) y los casos de uso. La forma de diseñar los diagramas de casos de uso depende mucho de la complejidad de los procesos denegocios a modelar. Para efectos de nuestro ejemplo podriamos decir que este requerimiento Administrar Clientes da origen a cuatro casos de uso: Crear  Cliente, Buscar Cliente, Actualizar Cliente y Eliminar Cliente. La notación UML para un caso de uso se denota por una elipse y el nombre del caso de uso.

Notacion UML 2.0 para un Caso de Uso
3. Tipos de Relaciones: Para la construcción de los...