Este documento presenta una introducción a los diagramas de casos de uso, describiendo que son casos de uso y como se usan los diagramas de casos de uso para capturar los requisitos funcionales de un sistema y mostrar las interacciones entre actores y el sistema. Explica los elementos clave de los diagramas de casos de uso como actores, casos de uso y relaciones, así como buenas prácticas y ventajas y desventajas de usar diagramas de casos de uso.

1. DIAGRAMAS DE
CASOS DE USO
Integrantes:
Eliana Farinango
Tamia Maldonado

2. CASO DE USO
• DEFINICIÓN
 Es una técnica para capturar información de cómo un sistema o negocio
trabaja actualmente o de cómo se desea que trabaje.
 Un caso de uso describe que hace un sistema pero no especifica como lo
hace.
 Debe ser simple, claro y conciso.

3. DIAGRAMA DE CASOS DE USO
• Muestra los distintos requisitos funcionales que se esperan de una aplicación
o sistema y como se relaciona con su entorno.
• Sirve para facilitar la comunicación con los futuros usuarios del sistema y con
el cliente, resultan especialmente útiles para determinar las características
necesarias que tendrá el sistema.

4. ELEMENTOS
• ACTOR es una entidad externa que interactúa con
el sistema participando en un caso de uso.
• Pueden ser personas, ordenadores o eventos externos.
• No necesariamente representa a un individuo en
particular, sino más bien la labor que el individuo
realiza frente al sistema.

5. ELEMENTOS
• CASOS DE USO
• Describen un grupo de actividades de un sistema que
produce un resultado concreto y tangible.
• Representan el interfaz externo del sistema y
especifican qué requisitos de funcionamiento debe
tener este (únicamente el qué, nunca el cómo).
CASO DE USO

6. ELEMENTOS
• RELACIONES marcan una interactuación entre dos elementos.
• TIPOS
 Asociación
 Relación más básica que indica la invocación
desde un actor o caso de uso a otra operación

7. ELEMENTOS
• RELACIONES marcan una interactuación entre dos elementos.
• TIPOS
 Inclusión (include o use)
 Indica que un caso de uso engloba la acción de
otro. Se usa para evitar repetir el mismo flujo de
eventos repetidas veces poniendo
comportamiento común en un caso de uso aparte.
‹‹include››

8. ELEMENTOS
• RELACIONES marcan una interactuación entre dos elementos.
• TIPOS
 Extensión (extends)
 Indica que un caso de uso incorpora el
comportamiento de otro caso de uso. Se usa
cuando dos casos de uso tienen características
similares.
‹‹extends››

9. ELEMENTOS
• RELACIONES marcan una interactuación entre dos elementos.
• TIPOS
 Generalización
 Indica que el caso de uso fuente hereda la
especificación del caso de uso destino. Un caso de
uso es un caso particular de uno más general.

10. ELEMENTOS
• LÍMITES DEL SISTEMA
• Resulta útil cuando se pretende hacer un diagrama de
casos de uso para una parte del sistema

11. ESTRUCTURA

12. BUENAS PRÁCTICAS Y
RECOMENDACIONES DE USO
• El caso de uso debe describir qué debe hacer el sistema a desarrollar en su
interacción con los actores y no cómo debe hacerlo.
• El nombre del caso de uso debe ilustrar el objetivo que pretende alcanzar el
actor al realizarlo.
• El caso de uso debe describir interacciones con los actores sin hacer
referencias explícitas a elementos concretos de la interfaz de usuario del
sistema a desarrollar.

13. BUENAS PRÁCTICAS Y
RECOMENDACIONES DE USO
• En los diagramas de casos de uso, debe evitarse que se crucen las líneas que
unen los actores a los casos de uso.
• La invocación de unos casos de uso desde otros casos de uso, sólo debe
usarse como un mecanismo para evitar repetir una determinada secuencia de
pasos que se repite en varios casos de uso. Nunca debe usarse para expresar
posibles menús de la interfaz de usuario.

14. VENTAJAS
• Fácil diagramación
• Facilita el entendimiento de los procedimientos realizados por el sistema para
el desarrollador
• Plantea las interacciones básicas entre usuario y sistema
• Facilita la priorización de requerimientos

15. DESVENTAJAS
• Cuando el diagrama es muy extenso o muy amplio dificulta su
entendimiento.
• No establecen completamente los requisitos funcionales ni permiten
determinar los requisitos no funcionales.