SESION 08: LAS RELACIONES EN

LOS CASOS DE USO

Ing. Ricardo Nina
Ejemplo de un Diagrama de Caso de Uso

Área de Venta
Nombre del
Sistema Definir crédito

Supervisor

Hacer un pedido
Cliente

Vendedor

Consultar estado
Frontera del de pedido
Sistema
Consultar
embarques Despachador
pendientes
Tipos de Relaciones

 Para identificar la comunicación existente entre los

actores, los casos de uso y actores‐casos de uso se
utilizan varios tipos de relaciones:

 Tipos:

 COMUNICACION
 GENERALIZACIÓN
 EXTENSIÓN
 INCLUSIÓN

3 Ing. Edwin Valencia

 Relaciones entre Casos de Uso
 Comunicación o asociación.
 En este tipo de relaciones participan un Actor y un Caso de Uso.
 Esta es la única relación posible entre ambos.

Notación:
Relaciones entre Casos de Uso
 Aunque la relación de asociación funciona por defecto en
ambos sentidos, es posible indicar si el actor interactúa con
el caso de uso de forma activa (entregando datos e
iniciando un proceso) o pasiva (recibiendo datos o un
estado del sistema) con el caso de uso.
 Esto es posible utilizando una cabeza de flecha en la línea
que une el actor con el caso de uso.
Generar
Pedido
Vendedor

Notificar
Estado Pedido
Adm.
Ventas
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.

6 Ing. Edwin Valencia

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.

7 Ing. Edwin Valencia

Generalización

8 Ing. Edwin Valencia

Generalización
 Generalización

AlmacenarProd

AlmacenarProd AlmacenarProd AlmacenarProd

Regresado Nuevo Cancelado

9 Ing. Edwin Valencia

 Relaciones entre Casos de Uso
 Herencia (Inheritance):
 Permite definir un nuevo Caso de Uso especializado a
partir de otro Caso de Uso general.
 En este tipo de relación, algunos pasos del flujo de
eventos del Caso de Uso general son reemplazados,
eliminados o adicionados en el flujo de eventos del Caso
de Uso específico.
Relaciones entre Casos de Uso
Flujo Eventos Registrar Pedido

1.El Caso de Uso empieza cuando el cajero selecciona

Registrar Pedido.
2. El sistema muestra la interfaz de ingreso de pedidos.
3. El cajero ingresa el nombre y dirección del cliente que
solicita el pedido.
4. El cajero ingresa el código del producto a ordenar.
5. Por cada código ingresado
a) El sistema proporciona la descripción y el precio.
b) El sistema adiciona el precio al total.
…
 Relaciones entre Casos de Uso
Flujo Eventos Registrar Pedido

6. El cajero ingresa los datos de la tarjeta de crédito del cliente.

7. El cajero selecciona Aceptar.
8. El sistema verifica la información, registra la orden como
pendiente y envía la información del pago a la cuenta del
sistema.
9. Cuando el pago es confirmado, la orden es marcada como
confirmada y el número de la Orden es entregado al cajero y el
Caso de Uso termina.
Relaciones entre Casos de Uso
Flujo Eventos Registrar Pedido por Web.
Este Caso de Uso es igual al Caso de Uso “Registrar Pedido” excepto
por:
 En todo el caso de uso, el actor cajero es reemplazado por el actor
cliente.
 El Paso 3. es eliminado y en su lugar el sistema muestra el nombre y
dirección del cliente.
 En el paso 4. el cliente selecciona los productos buscando en el
catálogo en línea en vez de ingresando el código de los mismos.
 En el paso 5a. el sistema muestra la información y el cliente selecciona
agregar el producto al carrito de compras.
 En el paso 5b. el total es asociado con el carrito de compras.
 EXTENSION
 Muchas veces, la funcionalidad de un caso de uso incluye un
conjunto de pasos que ocurren sólo en algunas portunidades.
 Supongamos que estamos especificando un sistema en el cual
los clientes pueden ingresar pedidos interactivamente(registrar
pedidos), y que dentro de la funcionalidad del Registro de
pedidos el usuario puede solicitar al sistema que le haga una
presentación sobre los nuevos productos disponibles, sus
características y sus precios.(consultar catalogo de productos
nuevos)
 En este caso, tengo una excepción dentro del caso de uso
Ingresar Pedido. La excepción consiste en interrumpir el caso
de uso y pasar a ejecutar el caso de uso Revisando
Presentación de Nuevos Productos.
 EXTENSION
 En este caso decimos que el caso de uso Revisar Presentación
de Nuevos Productos extiende el caso de uso Ingresar pedido
y se representa por una línea de trazos desde el caso que
‘extiende a’ al caso que es ‘extendido’.
Caracteristicas de las extensiones

 Representan una parte de la funcionalidad del caso que no

siempre ocurre.
 Son un caso de uso en sí mismas.
 No necesariamente provienen de un error o excepción. En su
libro, Jacobson ejemplifica los casos de uso con ir a cenar a un
restaurant. Para él, tomar café después de cenar es un ejemplo
de una extensión.

La pregunta que surge claramente es ¿cuál es la diferencia

entre una alternativa y una extensión? La respuesta puede
derivarse de las características de cada uno:
Características de las extensiones
 Una extensión es un caso de uso en sí mismo, mientras que una
alternativa no.
 Una alternativa es un error o excepción, mientras que una extensión
puede no serlo.

 De todas formas, en la práctica aparecen dudas con respecto

a la conveniencia de considerar algo optativo en un caso
como una alternativa o una extensión, sobre todo porque no
queda claro si algo puede ser visto como un caso de uso en sí
mismo o no. Como regla aproximada en este caso podemos
pensar que si algo opcional debe ser expresado con más de
un paso, seguramente es una extensión y no una alternativa.
Ejemplos de Extensiones
Notación:
 Relación de extensión

 Ejemplo:
Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
Establecer prioridad: punto de
extensión
Enviar pedido para ser procesado
según la prioridad.

19
Relación de extensión

20
Relaciones entre Casos de Uso
Ejemplo del escenario primario de un <<Extend>>
Caso de Uso: Comprar Bienes
Descripción: Realiza la compra de un bien indicado
Flujo de Eventos:
1. El cajero selecciona la opción comprar bienes.
2. El cajero ingresa el código del bien a comprar
2. El sistema calcula el precio e impuesto del bien
Punto de
<Extend Point 1>
Extensión
3. El cajero selecciona aceptar y el caso de uso termina.
Caso de Uso: Validar Tarjeta
Descripción: Verifica la tarjeta de crédito de un cliente.
Insertar Segmento en <Extend Point 1>
1. El cajero ingresa el número de la tarjeta de crédito del cliente.
2. El sistema verifica que el número de la tarjeta sean validos
3. El sistema aprueba la tarjeta
4. Se carga el monto a la tarjeta del cliente.
 INCLUSION
 Es común que la misma funcionalidad del sistema sea accedida a partir
de varios casos de uso. Por ejemplo, la funcionalidad de buscar un
producto puede ser accedida desde el ingreso de pedidos, desde las
consultas de productos, o desde los reportes de ventas por producto.
¿Cómo hago para no repetir el texto de esta funcionalidad en todos los
casos de uso que la acceden? La respuesta es simple: sacando esta
funcionalidad a un nuevo caso de uso, que es usado por los casos de los
cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se
representa por una línea punteada desde el caso que ‘usa a’ al caso que
es ‘usado’.
Relación de inclusión
 Permite factorizar un comportamiento en un
caso de uso aparte y evitar repetir un mismo
flujo en diferentes casos de uso.
 Ejemplo:
Hacer Pedido:
Obtener y verificar el número de
pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
…
23
 INCLUSION
 Decimos, por ejemplo, que el caso de uso Obtener reporte de ventas por
producto usa al caso de uso Buscar producto

 Este concepto no es novedoso, es simplemente el concepto de la subrutina o

subprograma usado en un nivel más alto de abstracción.
 Características de Inclusión
Las características de las relaciones de uso son:
 Aparecen como funcionalidad común, luego de haber especificado varios casos
de uso.
 Los casos usados son casos de uso en sí mismos.
 El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la
diferencia con las extensiones, que son opcionales.

<<include>> Actualizar
Retirar
efectivo cuenta

Retirar <<extend>> Proteger por

efectivo con falta fondos
protección
 Características de Inclusión
 ¿Qué pasa con la funcionalidad que es común a varios casos de uso, pero al
mismo tiempo es opcional? Por ejemplo, pensemos en la impresión de un
comprobante, algo que el usuario de un sistema puede o no hacer en distintos
casos de uso. Si uno se guía por la funcionalidad común a varios casos, piensa que
el caso de uso imprimir comprobante es usado por otros casos, pero si se guía por
la opcionalidad, piensa que extiende a otros casos. Como esto no queda claro a
partir de la bibliografía, creemos conveniente que este tipo de situaciones se
especifiquen como extensiones, ya que de esta forma podemos remarcar
gráficamente la opcionalidad de la relación.

EmbarcarOrden <<include>>

<<include>> ActualizarInventario
LlenarOrden
<<include>>
AlmacenarProducto
Ejemplos de inclusión
Ejemplos de inclusion
 Ejemplo
Extensión
«extend»
Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización
«include»
Seguir Pedido Examinar retina

29
Ejemplo

30