UML –
Diagrama de Casos
de Uso
Profesores:
Facultad de Ingeniería y Tecnología
Mg. Adrián H. Tozzi
Informática Lic. Domingo Donadello
Mg. Paula Angeleri
Ingeniería de Software II Lic. Diego Albamonte
Lic. Miguel A. Secatore
Especificaciones de
Requerimientos
Captura de Requisitos
Definición
Actores, Relaciones y Prioridades
Contenido Clasificación
Casos de Uso de Alto Nivel
Casos de Uso Expandido
Ejemplos
Casos de Usos Esenciales y Reales
La RS describe ...
Especificacio
nes de Inputs El Outputs
Requerimient Sistema
os
Ambientes
Funciones
Performance
Requisitos funcionales.
Modelo de Casos de
Uso.
Captura de
Requisitos Requisitos No funcionales.
Especificación
Suplementaria.
Fueron formalizados por Ivar Jacobson
(use cases).
Describen bajo la forma de acciones y
Definición reacciones el comportamiento de un
sistema desde el punto de vista de un
usuario.
Permiten definir los límites del sistema
y las relaciones entre el sistema y el
entorno.
Ingresar un nuevo producto Ingresar nuevas categorías
Ejemplos
Modificar productos Modificar categorías
Coordinador de
Ventas Interno
Borrar productos Borrar categorías
Ingresar un nuevo cliente
<<uses>> Modificar Un cliente
Vendedor
<<extends>>
<<extends>>
Ejemplos Cargar un pedido Pedidos recomendados
Borrar un cliente
Borrar un pedido
Gerente de
Ventas
Modificar un pedido
Actores principales: personas que utilizan
las funciones principales del sistema.
Actores secundarios: personas que efectúan
tareas administrativas o de mantenimiento.
Actores Material externo: dispositivos materiales
imprescindibles que forman parte de la
aplicación y que deben ser utilizados.
Otros sistemas: sistemas con los que el
sistema debe interactuar.
Relación de comunicación: Se señala por
una flecha entre el actor y el caso de uso.
Relación de uso: Entre casos de uso
significa que una instancia del caso de uso
fuente comprende también el
Relaciones comportamiento descrito por el caso de
uso destino.
Relación de extensión: Entre casos de
uso significa que el caso de uso fuente
extiende el comportamiento del caso de
uso destino.
Los casos de uso más importantes
deben ser abordados por los
primeros ciclos de desarrollo.
Prioridades Primero se deben tomar los casos
de uso que:
Influencian significativamente la
arquitectura del sistema.
Suponen un alto riesgo para el
cumplimiento de los requerimientos.
Clasificación de casos de uso:
Alto nivel: muy breves, describen el
proceso en dos o tres oraciones.
Expandidos: pueden contener cientos de
oraciones describiendo en detalle un
Casos de proceso.
Uso
Clasificación Creación:
Crear los casos de uso de alto nivel
durante la fase de Plan y Elaboración.
Rescribir los más importantes y críticos de
esos casos de uso, en formato expandido.
Describe un proceso brevemente,
usualmente en 2 o 3 oraciones.
Ayudan a comprender rápidamente:
La complejidad del sistema.
Casos de La funcionalidad del sistema.
Uso de Alto
Nivel Use case:
Actores:
Comprar un ítem.
Cliente, Cajero.
Tipo: primario.
Descripción: Un cliente llega a la caja con ítems a comprar.
El cajero registra los ítems comprados por el cliente
y recibe el pago. Al finalizar el cliente se retira con
los ítems comprados.
Muestran más detalle que los de alto
nivel. Se lo usa para conseguir una
mejor un comprensión de los procesos y
de los requerimientos.[Wirfs-Brock93].
Casos de
Uso Use case:
Actores:
Comprar un ítem al contado.
Cliente (iniciador), Cajero.
Expandido Propósito: Capturar una venta y su pago al contado.
Overview: Un cliente llega a la caja con ítems a comprar.
El cajero registra los ítems comprados por el cliente
y recibe el pago. Al finalizar el cliente se retira con
los ítems comprados.
Tipo: primario y esencial.
Acción del actor: Respuesta del sistema:
1. Este caso de uso comienza
cuando el usuario llega a la
registradora con los ítem que
quiere comprar.
2. El cajero registra el identificador 3. Determinar el precio del ítem y
Ejemplo de cada ítem. agrega la información del ít em a
la transacción de venta corriente.
Curso Típico de Se presenta la descripción y
precio del ítem corriente.
los Eventos 4. Cuando se terminan de entrar los
ítems, el cajero le indica a la
5. Calcula y presenta el total de la
venta.
registradora que la entrada de
ítems está completa.
6. El cajero le dice al cliente el total.
Visión General
El propósito principal de este caso de uso es crear un nuevo pedido de
productos para un cliente.
Actor Principal: Vendedor
Actor Secundario: Ninguno
Punto de comienzo: El actor solicita un nuevo pedido
Punto de finalización: El pedido es creado o cancelado
Resultado esperado: El pedido es generado.
Flujo de eventos
El actor recibe un llamado telefónico del cliente. El cliente le solicita al actor que
Ejemplo le tome el pedido. El actor abre el formulario de entrada del pedido. Solicita el
nombre y la dirección del cliente. El actor ingresa el nombre del cliente en el
sistema. El actor confirma que los datos personales del cliente sean correctos. Si
Generar Pedido la información es correcta, el actor solicita los datos del pedido. Si la información
del cliente es incorrecta, la actualiza. El actor selecciona una categoría de
producto. Luego selecciona los artículos. Ingresa la cantidad para cada artículo.
El actor selecciona el flete. El actor confirma con el cliente que toda la
información esté correcta. El actor completa los detalles del pedido. El actor
graba en la base de datos.
Flujos de eventos alternativos
Ninguno
Casos de uso extendidos
Ninguno
Puntos sobresalientes
Ninguno
Representar pasos individuales,
operaciones o transacciones como
casos de uso.
Ejemplo: imprimir el recibo.
Errores
• Un caso de uso es una descripción de un
proceso que incluye varios pasos o
transacciones.
• No es un paso individual o una actividad
en el proceso.
Casos de uso expandidos expresados
en formato ideal, sin detalles de
implementación, dónde las decisiones
de diseño se abstraen y se posponen
(especialmente las referidas a las GUI).
Casos de
Usos Se los crea durante el relevamiento
Esenciales de los requerimientos.
Muestran la esencia del proyecto sin
que nos abrumen los detalles de
diseño.
Describen concretamente los
procesos en términos de su
diseño actual real y según las
tecnologías específicas. Cuando
incluyen GUIs suelen contener
Casos de “screen shots” y discuten la
Uso Reales interacción con los widgets.
Selos crea durante la fase de
diseño del ciclo de desarrollo.
Riesgos relacionados con nuevas
tecnologías.
Riesgos relativos a la arquitectura.
Priorizar
Riesgos relativos a construir el sistema
adecuado.
Riesgos relativos al rendimiento.
UML en 24 Horas
Joseph Schmuller, Editorial Pearson Prentice Hall
UML y Patrones
Craig Larman, Editorial Pearson Prentice Hall
El Proceso Unificado de Desarrollo de
Software
Bibliografí Rumbarg, Jacobson y Booch, Editorial Addison
a Wesley
El Proceso Unificado de Modelado
Jacobson y Booch, Editorial Addison Wesley
Páginas Web
http://www.rational.com
http://www.omg.org
http://www.softeam.fr/produits
