Tutorial para Documentacion de UML

1. INTEGRANTES:
 Harold Kevin Quispe Canaza
 Aldrey Suclla Fortes

2. CASOS DE USO
Qué es un caso de uso?
Para que sirven los casos de uso?
Cómo se representan?
Cómo se debe crear un caso de uso?
Flujo de eventos
Relaciones
Diagramas de caso de uso
Use Case 2
Specification
Actor 2
Use case 1
Model
Use case 2
Use case 3

3.  Describen una interacción típica entre un usuario (actores) y un sistema de
cómputo.
 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
 Produce algo de valor para algún actor como el cálculo de algún resultado
 Describe qué hace un sistema pero no especifica cómo lo hace
 El caso de uso capta alguna función visible para el usuario.
 El caso de uso puede ser pequeño o grande.
 El caso de uso logra un objetivo discreto para el usuario.
 Un caso de uso debe ser simple, claro y conciso
QUÉ ES UN CASO DE USO?

4. PARA QUE SIRVEN LOS CASOS DE USO?
 Para capturar el comportamiento deseado del sistema sin tener que
especificar como se implementa ese comportamiento
 Como medio de comprensión del sistema para desarrolladores, usuarios
finales y expertos del dominio
 Ayudan a validar la arquitectura y a verificar el sistema en el transcurso
del desarrollo de este

5. CÓMO SE REPRESENTAN?
Un caso de uso se representa en UML como un óvalo:
Nombre del Caso de Uso
En UML, un actor se representa como monigote
Actor

6. ACTORES
 Representa un conjunto de roles que los usuarios de los casos de uso
juegan al interactuar con éstos
 Representa un rol que es jugado por una persona, un dispositivo hardware u
otro sistema que interactúe con nuestro sistema
 Se puede definir categorías generales de actores (como cliente) y
especializarlos (como Cliente Comercial) a través de relaciones de
generalización
Cliente
Cliente
Comercial
actor
actor
generalización
 Un actor y un caso de uso se pueden comunicar a través de una
asociación en donde cada uno de ellos pueden enviar y recibir mensaje.

7. FLUJO DE EVENTOS
 Cómo y cuándo empieza y acaba el caso de uso
 Cuándo interactúan con los actores y que objetos se intercambian
 Conviene separa el flujo principal de uno alternativo

8. Ejemplo:
VALIDACIÓN DE USUARIO

9. FLUJO DE EVENTO PRINCIPAL:
el caso de uso comienza cuando se pide al cliente un número de identificación
personal (cédula), el cliente introduce la cédula, luego acepta con enter, el
sistema lo comprueba para su validación, si la cédula es válida el sistema
acepta la entrada y acaba el caso de uso.
FLUJO DE EVENTO EXCEPCIONAL:
- El cliente puede cancelar su transacción en cualquier momento con el botón
cancelar, reiniciando el caso de uso, no se efectúa ningún cambio a la cuenta
del cliente .
- El cliente puede borrar la cédula en cualquier momento antes de introducirlo
y volver a teclear una nueva cédula
- El cliente introduce un cédula inválida el caso de uso vuelve a empezar, si se
lo realiza tres veces se cancela la transacción.

10. Cómo identificar los casos de uso?

11. Cómo se debe crear un caso de uso?
 Tras localizar los actores, procede el describirlos
 especificar describiendo un flujo de eventos
 Los actores sólo pueden conectar a los casos de uso a través
de asociaciones
 Generalmente hay pocos actores asociados a cada Caso de
Uso
 Preguntas clave:
– ¿cuáles son las tareas del actor?
– ¿qué información crea, guarda, modifica, destruye o lee el actor?
– ¿debe el actor notificar al sistema los cambios externos?
– ¿debe el sistema informar al actor de los cambios internos?

12. RELACIONES
Para extraer el comportamiento de los casos de uso en los que se incluye y
poniendo ese comportamiento en otros casos de uso que lo extiende
Tipos:
 Asociación
 Dependencia o instanciación
 Generalización
1. Extensión
2. inclusión

13. GENERALIZACIÓN
 El caso hijo hereda el comportamiento y significado de caso de uso
padre
 El hijo puede añadir o redefinir el comportamiento del padre
 El Caso de Uso fuente hereda la especificación del Caso de Uso
destino
Caso de uso origen
Caso de uso destino

14. Ejemplo de Generalización

15. Ejemplo mas claro

16. INCLUSIÓN
 Un caso base de uso base incorpora
expolisitamente el comportamiento de otro caso de
uso en el lugar especificado en el caso base.
 Se usa para evitar describir el mismo flujo de
eventos repetidas veces, poniendo
comportamiento común en un caso de uso aparte
 Se representa como una dependencia
estereotipada con <<include>>

17. Caso de uso origen
Caso de uso destino
<<include>>
Ingresando pedido
Buscando datos de
producto
Obtener reporte
De Ventas por
producto
<<include>>
<<include>>
Empleado de
ventas
Gerente
REPRESENTACIÓ
N:
EJEMPLO:

19. EXTENSIÓN
 Significa que un caso de uso base incorpora implícitamente el
comportamiento de otro caso de uso en el lugar especificado
indirectamente por el caso de uso que extiende al base
 Se usa esta relación cuando se tiene un caso de uso que es similar
a otro, pero que hace un poco más.
Caso de uso
origen
Caso de uso
destino
<<extends>>

20. Realizar
Llamada telefónica
Realizar llamada
Con conferencia
Recibir llamada
telefónica
Recibir llamada
adicional
Usar agenda
<<extend>>
<<extend>>
relación de extensión
frontera del sistema
Casos de uso
Red
telefónica
Usuario
Actores
Teléfono móvil

22.  Ejemplo de todas las relaciones :
Identificación
Giro por Internet
Cliente
Giro
<<extends>>
<<includes>>

24. En UML, cada caso de uso debe tener al menos un actor. Esta forma de
ver el sistema nos ayuda a concebirlo como un todo.
 Un diagrama de casos de uso es un diagrama que muestra
un conjunto de casos de uso, actores y sus relaciones.
 Son importantes para modelar el comportamiento de un
sistema.
 Normalmente los casos de uso contienen:
 Casos de Uso
 Actores
 Relaciones de dependencia, generalización y asociación.

25.  Cubren principalmente el comportamiento del sistema.
 Es un tipo especial de diagrama, por su contenido particular.
 Se emplean para modelar la vista de casos de uso
estática.(comportamiento, servicios externos).
 Para modelar el contenido de un sistema
 Dibujar una línea alrededor de todo el sistema, los actores quedarán
fuera del sistema e interactúan con el, se especificara los actores y
el significado de los roles.
 Para modelar los requisitos de un sistema
 Especificar que debería hacer el sistema, independientemente de
cómo se haga, se especificará el comportamiento deseado del
sistema.
 Permite ver el sistema entero como una caja negra.

26. Técnicas comunes del modelado
 Elementos dentro y fuera, son responsables del comportamiento que
esperan los elementos externos..
 Los elementos externos que interactúan con el sistema constituyen su
contexto, es decir el entorno en que reside el sistema.
 Modelar el contexto de un sistema
 Identificar actores en torno del sistema.
 Grupos que necesitan ayuda del sistema,
 Grupos necesarios para ejecutar las funciones del sistema.
 Grupos que interactúan con el hardware o software.
 Grupos que realizan funciones secundarias de administración y
mantenimiento.
 Organizar los actores similares en jerarquía de
generalización/especificación
 Proporcionar un estereotipo para cada actor.
 Introducir los actores en un diagrama de CU y especificar las vías de
comunicación .

27. Asociación
 Es el tipo de relación más básica que indica la invocación desde un
actor o caso de uso a otra operación (caso de uso). Dicha relación se
denota con una flecha simple.


29. Dependencia o Instanciación
 Es una forma muy particular de relación entre clases, en la
cual una clase depende de otra, es decir, se instancia (se
crea). Dicha relación se denota con una flecha punteada.

30. Antes Después

31. Comercio
Cliente
Entidad
Financiera
Cliente
individual
Cliente
corporativo
Realizar
Transacción
Con tarjeta
Procesar factura
Del cliente
Ajustar
transacciones
Gestionar cuenta
Del cliente

32. CONCLUSIONES:
•Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué).
•Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario.
Es decir, describen un uso del sistema y cómo este interactúa con el usuario.
• Los diagramas de casos de uso muestran las relaciones entre los casos de
uso de un sistema y sus actores.
•En una relación << extends>>, un actor que lleve a cabo el caso de uso base
puede realizar o no sus extensiones. Mientras, en una relación <<include>> el
actor que realiza el caso de uso base también realiza el caso de uso incluido.