ANALISIS DE SISTEMAS
UML
Casos de Uso y sus Diagramas
UML
Unified Modeling Language
Lenguaje Estándar para:
Visualizar
Especificar y construir
Documentar los planos del software
Indican como crear y leer modelos bien formados pero no nos dicen
qué modelos se deben crear ni cuándo se los deberían crear
Ir a Casos de uso
UML es un lenguaje para visualizar
• La distancia entre pensar en una implementación y transformarla en código es casi
cero.
• En algunos casos: Lo que piensas lo codificas.
• Algunas cosas se modelan mejor textualmente; otras se modelas mejor de forma
gráfica
• UML es algo más que un simple montón de símbolos gráficos.
UML es un lenguaje para especificar
• Significa construir modelos precisos, no ambiguos y completos
• UML cubre todas las decisiones de análisis, diseño e implementación
UML es un lenguaje para construir
• No es un lenguaje de programación
• Pero sus modelos pueden conectarse a una gran variedad de lenguajes de
programación
UML es un lenguaje para documentar
• UML cubre la documentación de la arquitectura de un sistema y todos sus detalles
• Proporciona un lenguaje:
Expresar requisitos y pruebas
Modelar actividades de planificación de proyectos y gestión
de versiones
CASOS DE USO
Qué es un caso de uso?
Para que sirven los casos de uso?
Cómo se representan?
Como identificar los casos de uso?
Cómo se debe crear un caso de uso?
Flujo de eventos Model
Relaciones
Diagramas de caso de uso Use case 1
Actor 2
Use case 2
Use case 3
Use Case 2
Specification
QUÉ ES UN CASO DE USO?
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
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
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
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
actor
Cliente
generalización
Cliente actor
Comercial
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.
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
Ejemplo:
VALIDACIÓN DE USUARIO
FLUJO DE EVENTO PRINCIPAL:
El caso de uso comienza cuando se pide el cliente ingresa la tarjeta en el cajero y este
la solicita una identificación personal (clave), el cliente introduce este dato, luego
presiona “Continuar”, el sistema lo comprueba para su validación, si la clave 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 clave o corregirla durante su digitación antes de
introducirla totalmente y reintentar.
- El cliente introduce un clave inválida, el caso de uso vuelve a empezar, si se lo
realiza tres veces se cancela la transacción.
CÓMO IDENTIFICAR LOS CASOS DE USO?
CÓMO SE DEBE DE 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?
La descripción del Caso de Uso comprende:
el inicio: cuándo y qué actor lo produce?
el fin: cuándo se produce y qué valor devuelve?
la interacción actor-caso de uso: qué mensajes
intercambian ambos?
objetivo del caso de uso: ¿qué intenta el caso de uso?
cronología y origen de las informaciones
repeticiones de comportamiento: ¿qué operaciones son
iteradas?
situaciones opcionales: ¿qué ejecuciones alternativas se
presentan en el caso de uso?
Puntos claves del ejemplo:
Las precondiciones son los hechos que se han de cumplir para que el flujo
de evento se pueda llevar a cabo.
Flujo de eventos Normal, que corresponde a la ejecución normal y exitosa
del caso de uso
Los flujos alternativos son los que nos permiten indicar qué es lo que hace
el sistema en los casos menos frecuentes e inesperados.
las poscondiciones son los hechos que se ha de cumplir si el flujo de
eventos normal se ha ejecutado correctamente.
Ejemplo: escribir un mensaje en un foro
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:
- GENERALIZACIÓN
- EXTENSIÓN
- INCLUSIÓN
Veamos un Ejemplo simple completo, y veamos lo que son Técnicas Comunes del
Modelado antes de pasar a una conclusión final.
Bibliografía..
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 destino
Caso de uso origen
INCLUSIÓN
Un caso base de uso base incorpora explisitamente 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>>
REPRESENTACIÓN:
<<include>>
Caso de uso destino
Caso de uso origen
EJEMPLO:
Buscando datos de
producto
<<include>>
<<include>>
Ingresando pedido Obtener reporte
De Ventas por
producto
Empleado de Gerente
ventas
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.
<<extends>>
Caso de uso
destino
Caso de uso
origen
Ejemplo:
Realizar <<extend>> Realizar llamada
Llamada telefónica Con conferencia
Red relación de extensión
telefónica
<<extend>>
Recibir llamada Recibir llamada
Actores
telefónica adicional
Casos de uso
Usar agenda
frontera del sistema
Usuario
Teléfono móvil
Ejemplo de todas las relaciones :
<<extends>>
Giro por Internet
Cliente
<<includes>>
Giro
Identificación
DIAGRAMAS DE CASO DE USO
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.
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.
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 .
Antes Después
Realizar
Transacción
Con tarjeta
Comercio
Procesar factura
Del cliente
Cliente
Ajustar
transacciones
Gestionar cuenta
Del cliente
Cliente Cliente Entidad
individual corporativo Financiera
•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.
