Los diagramas de casos de uso visualizan las interacciones entre usuarios y sistemas, mostrando cómo funcionan los programas desde la perspectiva del usuario. Incluyen actores, casos de uso y relaciones, y son herramientas para definir requisitos funcionales y guiar la documentación y pruebas. Aunque efectivos para sistemas interactivos, deben complementarse con información adicional para detallar requisitos no funcionales.

1. Diagramas de casos de uso
Diagramas de casos de uso
Autor: Sinuhé Navarro Martín

2. Diagramas de casos de uso
Descripción
Un diagrama de casos de uso debe mostrar a simple vista, qué se puede hacer con
un programa desde el punto de vista de un usuario. Cada cosa que el usuario
hace, es un caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas.

3. Diagramas de casos de uso
Objetivos
❖ Indicar los requisitos funcionales: cómo
funciona un programa/sistema.
❖ Proporcionar una descripción clara de su suso:
cómo el usuario interactúa con el sistema.
❖ Orientar en la realización de pruebas: nos dice
cómo debe funcionar (requisitos).
❖ Sirve de guía para crear la documentación de
uso del programa.
❖ Buen punto de partida para los diagramas de
clases

4. Diagramas de casos de uso
Elementos de un diagrama de casos de uso
❖ Actores: Es cualquier cosa que interactúa con el sistema, y es
externo a él. No es necesariamente una persona, puede ser un
dispositivo u otro sistema. Se representan mediante un
monigote.
❖ Casos de uso: Representan el funcionamiento que se produce
tras la orden de un actor. Se representan con una elipse, y
dentro se escribe la descripción textual.
❖ Relaciones: Relacionan a los actores con los casos de uso,
aunque en algunos casos también permiten relacionar unos
casos de uso con otros.
❖ Un rectángulo se usa para representar los límites del sistema,
si es necesario.

5. Diagramas de casos de uso
Relaciones entre casos de uso
Inclusión
❖ Un caso de uso incluye a otro, cuando para
realizar el caso de uso inicial se debe
obligatoriamente realizar el caso de uso
secundario.
❖ El actor que realiza el caso de uso base también
realiza el caso de uso incluido.
Extensión
❖ Un caso de uso extiende de otro, cuando hace
algo similar pero amplía la funcionalidad.
❖ Es una variación del comportamiento
normal.
❖ Un actor que lleve a cabo el caso de uso base
puede realizar o no sus extensiones

6. Diagramas de casos de uso
How-to
Para diseñar un diagrama de casos de uso se comienza por
reconocer los actores y los casos de uso, para posteriormente
relacionarlos.
Los casos del uso son a menudo elaborados en colaboración por los
analistas de requisitos y los clientes.
Típicamente se desarrollan 3 niveles de abstracción de diagramas
de casos de uso:
Diagrama de contexto
interacción del sistema con el exterior
Diagramas iniciales
principales funcionalidades
Casos de uso
Despliegue de los diagramas iniciales

7. Diagramas de casos de uso
Normas de aplicación
❖ Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea. Desde una
perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica del
sistema.
❖ El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto
influenciará el nivel del detalle requerido en cada caso de uso.
❖ Un caso de uso contiene opcionalmente una descripción textual.
❖ Los casos de uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni
explican cómo se implementará.
Un caso de uso debe:
❖ Describir una tarea del negocio que sirva a una meta de negocio.
❖ Tener un nivel apropiado del detalle.
❖ Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento.

8. Diagramas de casos de uso
Ventajas
❖ Tiene éxito en sistemas interactivos, ya que
expresa la intención que tiene el usuario al
hacer uso del sistema.
❖ Como técnica de extracción de requisitos
permite centrarse en las necesidades del
usuario, evitando que la gente
especializada en informática dirija la
funcionalidad del sistema basándose
solamente en criterios tecnológicos.
❖ Facilita luego la priorización del requisito.
❖ No establecen completamente los
requisitos funcionales ni permiten
determinar los requisitos no funcionales.
❖ Los casos de uso deben complementarse
con información adicional como reglas de
negocio, requisitos no funcionales,
diccionario de datos que complementen los
requisitos del sistema.
Limitaciones

9. Diagramas de casos de uso
Referencias
❖ https://es.wikipedia.org/wiki/Caso_de_uso
❖ http://entornos.codeandcoke.com/doku.php?id=apuntes:diagramas