Este documento introduce los casos de uso y diagramas UML. Explica qué son los casos de uso, cómo identificarlos y describirlos. También cubre los actores, escenarios, relaciones entre casos de uso como generalización e inclusión, y cómo modelar el comportamiento de un sistema usando diagramas de casos de uso. El documento concluye resumiendo la actividad complementaria de modelar casos de uso para un proceso industrial.
2. Inicio
◦ Objetivos de la clase
Desarrollo
◦ ¿Qué es un caso de uso?
◦ Diagramas de casos de uso
Cierre
◦ Síntesis
◦ Lo que viene
3. Definir y describir Artefactos UML para BPMN.
Diagramas de casos de uso (Modelo
conceptual).
Discutir la importancia que tienen los casos
de uso para analizar sistemas
4. Recordemos que UML, ayuda a:
◦ Visualizar
Ayuda a que analistas de SW e interesados en el
proceso hablen mismo lenguaje
◦ Especificar
Ayuda a definir modelos precisos
◦ Construir
Sirve para conectarse con distintos tipos de
programación
◦ Documentar
requisitos, arquitectura del sistema, pruebas, etc.
5. UML Business Modelling Profile:
◦ Extensión de UML
◦ Ayudar a la comunicación entre usuarios y analistas
6. Como identificar un caso de uso?:
◦ Cuáles son las tareas y responsabilidades de cada actor?
◦ ¿Algún actor creará, almacenará, cambiará, borrará o
leerá información del sistema?
◦ ¿Qué Casos de Uso
crearán, almacenarán, cambiarán, borrarán o leerán esta
información?
◦ ¿Es necesario que un Actor informe al sistema sobre
cambios externos?
◦ ¿Es necesario que un Actor sea informado sobre ciertas
incidencias del sistema?
◦ ¿Qué Casos de Uso darán soporte y mantendrán el
sistema?
◦ ¿Pueden ser realizados por los Casos de Uso todos los
requerimientos funcionales
7. Descripción de un conjunto de secuencias de
acciones que ejecuta un sistema para
producir un resultado observable para el
actor:
Actor
Caso de
uso
Retirar dinero
Cliente
Nombre simple
8. Actor
◦ Representa un conjunto de roles que tienen los
usuarios al interactuar con éstos
◦ Puede representar una persona, hardware o sistema
◦ Se puede definir categoría generales de actores y
posteriormente generalizarlos, a través de una
relacion de generalización
actor actor
Usuario
Usuario autenticado
9. Proporcionar un medio para que
desarrolladores, usuarios finales y expertos
lleguen a una comprensión común del
sistema
Mostrar comportamientos esenciales de un
sistema o subsistema y no debe ser mi muy
específico ni muy genérico
Describe que hace un sistema pero no como
lo hace
10. El comportamiento de un caso de uso se
puede especificar como un flujo de eventos
en forma textual:
◦ Ejemplo: Validar usuario en Tbanc
Evento principal: El sistema (pagina web) le pide al
cliente ingresar su Rut y password. El cliente acepta
presionando el botón entrar. A continuación se solicita
ingresar el pin pass, presiona enter y el cliente entra a
su sucursal virtual
Evento alternativo: El sistema le pide al cliente ingresar
su Rut y password. El Cliente ingresa la password
erróneamente tres veces. El sistema lo bloquea
11. Escenarios:
◦ Es una interacción entre sistemas y actores que
puede ser descrito como una secuencia de
mensajes. El caso de uso será una generalización
de un escenario
Socio biblioteca
Llevar prestado libro
13. Especificando relaciones los casos de uso
para extraer su comportamiento y
extenderlos en otros casos de uso
◦ Generalización
◦ Inclusión
◦ extensión
14. Generalización
◦ Hereda el significado y comportamiento del padre
Caso de uso padre Caso de uso hijo
15. Inclusión
◦ Incluye explícitamente el comportamiento de un
caso de uso en el caso base
Gerente
Comercial
Buscar datos
de producto
cliente
<<include>>
<<include>>
Ingresar pedido Obtener reporte de
De Ventas por producto
16. Extensión
◦ Incluye implícitamente el comportamiento de un
caso de uso en el caso base Se usa para modelar un
comportamiento opcional del sistema
cliente
<<extend>>
Realizar llamada Realizar llamada
telefónica Con conferencia
17. Para modelar el comportamiento de un
elemento
◦ Identificar los actores relacionados con ese caso de
uso
◦ Organizar los actores desde los roles más
generales a los más específicos
◦ Considerar las formas más importantes que tiene el
actor para interactuar con el elemento
◦ Utilizar relaciones de inclusión y extensión en los
casos de uso
◦ Modelar los casos de uso más importante del
sistema
18. ¿Qué debiera incluir una descripción de un caso:
◦ Comentarios generales y anotaciones que describan el caso.
◦ Requerimientos: cosas que el caso de uso debe permitir hacer al
usuario, tales como <habilidad para actualizar un pedido>, <habilidad
para modificar el pedido>, etc.
◦ Restricciones: reglas acerca de qué se puede hacer y qué no se puede
hacer. Incluyen:
◦ Pre-condiciones que deben ser verdaderas antes que el caso de uso “esté
corriendo”, por ejemplo, <crear pedido> debe preceder a <modificar
pedido>
◦ Post-condiciones que deben ser verdaderas una vez que el caso de uso
“esté corriendo”, por ejemplo, <pedido es modificado y es consistente>
◦ Invariantes: estas deben ser siempre verdaderas, por ejemplo, un pedido
siempre debe tener un número de cliente.
◦ Escenarios: descripción secuencial de los pasos necesarios para llevar
adelante el caso de uso. Puede incluir multiples escenarios.
◦ Diagramas de escenario: diagramas de secuencia similares a los
workflow, pero representados gráficamente.
◦ Atributos adicionales: tales como fases de implementación, número de
versión, grado de complejidad,etc
19. Diagrama que muestra un conjunto de casos
de uso, actores y sus relaciones.
Se utilizan para modelar el comportamiento
de un sistema.
22. Sintésis
Actividad complementaria virtual
◦ Grupos tres alumnos
◦ Seleccionar algún proceso de una industria
◦ Hacer la descripción de casos de usos básicos
◦ Plazo una semana
Lo que viene
◦ Diagramas de actividad