Lenguaje Unificado de Modelado (UML) los diagramas de casos de uso son herramientas poderosas para modelar los requisitos funcionales de un sistema. Ilustran cómo los actores (usuarios o sistemas externos) interactúan con el sistema a través de casos de uso, que representan funcionalidades específicas. Dos relaciones clave en los diagramas de casos de uso—Incluir y Extender—ayudan a gestionar la complejidad al estructurar y modularizar el comportamiento. Este tutorial ofrece una explicación detallada de estas relaciones, sus propósitos, características y aplicaciones prácticas, completo con ejemplos para garantizar claridad.
En diagramas de casos de uso UML, Incluir y Extenderlas relaciones de inclusión y extensión te permiten descomponer casos de uso complejos en componentes más pequeños, reutilizables o opcionales. Estas relaciones mejoran la modularidad, reducen la redundancia y aumentan la claridad de los diagramas.

Relación de inclusión (<<incluir>>): Representa un comportamiento obligatorio que siempre se ejecuta como parte de un caso de uso base. Extrae la funcionalidad común compartida entre múltiples casos de uso en un componente reutilizable.
Relación de extensión (<<extender>>): Representa un comportamiento opcional o condicional que extiende un caso de uso base bajo condiciones específicas, manteniendo al caso de uso base enfocado en su funcionalidad principal.
Ambas relaciones utilizan flechas punteadas para conectar casos de uso, con etiquetas que indican<<incluir>> o <<extender>>. La dirección de la flecha es crítica, ya que refleja la dependencia entre los casos de uso.
El IncluirLa relación de inclusión se utiliza para extraer el comportamiento común y obligatorio de múltiples casos de uso en un único caso de uso reutilizable. Esto promueve la reutilización y simplifica los casos de uso base al evitar la funcionalidad duplicada.
Obligatorio: El caso de uso incluido se ejecuta siempre cuando se realiza el caso de uso base.
Reutilizable: El caso de uso incluido es una función independiente y coherente que puede ser utilizada por múltiples casos de uso base.
Simplifica los diagramas: Al extraer los pasos comunes, el caso de uso base permanece conciso y enfocado.
Dirección: La flecha apunta desde el caso de uso base hacia el caso de uso incluido, indicando que el caso de uso base depende del incluido.
Una flecha punteada etiquetada como<<incluir>> conecta el caso de uso base con el caso de uso incluido.
Considere un sistema de compras en línea donde un cliente puedeColocar pedido o Cancelar pedido. Ambos casos de uso requieren que el clienteIniciar sesión en el sistema.
Casos de uso base: Colocar pedido, Cancelar pedido
Casos de uso incluidos: Iniciar sesión
Explicación: Iniciar sesión es un paso obligatorio tanto para realizar como para cancelar un pedido. En lugar de duplicar la funcionalidad de inicio de sesión en ambos casos de uso, se extrae en un caso de uso separadoIniciar sesión caso de uso, que es incluido por ambos.
Representación del diagrama:
[Realizar pedido] ----<<incluir>>----> [Iniciar sesión]
[Cancelar pedido] ----<<incluir>>----> [Iniciar sesión]
En un sistema de biblioteca, un usuario puedePedir libro oDevolver libro. Ambos procesos requierenVerificar usuario.
Casos de uso básicos: Pedir libro, Devolver libro
Casos de uso incluidos: Verificar usuario
Explicación: Verificar la identidad del usuario (por ejemplo, comprobando su tarjeta de biblioteca) es un paso obligatorio tanto al pedir como al devolver un libro. ElVerificar usuario el caso de uso se incluye para evitar la redundancia.
Representación del diagrama:
[Pedir libro] ----<<incluir>>----> [Verificar usuario]
[Devolver libro] ----<<incluir>>----> [Verificar usuario]
Cuando múltiples casos de uso comparten un paso común y obligatorio.
Cuando deseas simplificar las descripciones de casos de uso al extraer funcionalidades reutilizables.
Cuando el caso de uso incluido tiene sentido de forma independiente (por ejemplo, Iniciar sesión o Verificar usuario puede entenderse como funciones independientes).
La ExtenderLa relación de extensión se utiliza para modelar un comportamiento opcional o condicional que solo se ejecuta bajo circunstancias específicas. Permite que el caso de uso base se mantenga enfocado en su funcionalidad principal mientras se añade comportamiento opcional de forma modular.
Opcional/Condicional: El caso de uso que extiende se ejecuta solo si se cumplen ciertas condiciones.
Dependiente: El caso de uso que extiende no tiene sentido por sí solo y depende del caso de uso base.
Puntos de extensión: El caso de uso base puede definir puntos específicos donde se puede insertar el comportamiento de extensión.
Dirección: La flecha apunta desde el caso de uso que extiende hacia el caso de uso base, indicando que el caso de uso que extiende añade comportamiento al base.
Una flecha punteada etiquetada como<<extend>> conecta el caso de uso extendido con el caso de uso base, a menudo con una nota que especifica la condición o el punto de extensión.
En un sistema de cajero automático, el caso de uso base esRetirar efectivo. Un comportamiento opcional,Imprimir comprobante, puede ocurrir si el usuario solicita un comprobante.
Caso de uso base: Retirar efectivo
Caso de uso extendido: Imprimir comprobante
Condición: El usuario elige imprimir un comprobante después de retirar efectivo.
Explicación: Imprimir un comprobante no es obligatorio y solo ocurre si el usuario lo solicita explícitamente. El Imprimir comprobante caso de uso extiende Retirar efectivo en el punto de extensión “El usuario solicita comprobante.”
Representación del diagrama:
[Imprimir comprobante] ----<<extend>>----> [Retirar efectivo]rn(Nota: Condición = El usuario solicita comprobante)
En una plataforma de cursos en línea, un usuario puedeRealizar cuestionario. Un comportamiento opcional,Solicitar pista, ocurre si el usuario tiene dificultades con una pregunta.
Casos de uso base: Realizar cuestionario
Caso de uso extendido: Solicitar pista
Condición: El usuario solicita una pista durante el cuestionario.
Explicación: Solicitar una pista es opcional y depende de la necesidad del usuario. El Solicitar pista caso de uso se extiende Realizar cuestionario en el punto de extensión “El usuario necesita ayuda.”
Representación del diagrama:
[Solicitar pista] ----<<extender>>----> [Realizar cuestionario]
(Nota: Condición = El usuario necesita ayuda)
Cuando el comportamiento es opcional o depende de condiciones específicas.
Cuando deseas mantener el caso de uso base enfocado en su funcionalidad principal.
Cuando el caso de uso extendido no tiene sentido sin el caso de uso base (por ejemplo, Imprimir comprobante no tiene relevancia sin Retirar efectivo).
La tabla a continuación resume las diferencias entre Incluir y Extender relaciones para guiar su uso:
|
Criterios |
Incluir (<<incluir>>) |
Extender (<<extender>>) |
|---|---|---|
|
¿Es el comportamiento obligatorio? |
Sí, siempre se ejecuta como parte del caso de uso base |
No, se ejecuta solo bajo condiciones específicas |
|
¿Puede el comportamiento funcionar por sí solo? |
Sí, es una función coherente y reutilizable |
No, depende del caso de uso base |
|
¿Ocurre en múltiples casos de uso? |
Sí, compartido entre múltiples casos de uso |
Normalmente específico para un solo caso de uso |
|
Propósito |
Fomentar la reutilización y simplificar el caso de uso base |
Añadir comportamientos opcionales o excepcionales de forma modular |
|
Dirección de la flecha |
Base → Caso de uso incluido |
Extender → Caso de uso base |
Vamos a aplicar ambas relaciones en un sistema de gestión de restaurantes para ilustrar su uso en un escenario del mundo real.
Un sistema de restaurante permite a los clientesPedir comida y Reservar mesa. El sistema también maneja comportamientos adicionales como Pagar la cuenta y Solicitar para llevar.
Ordenar comida: El cliente ordena comida desde el menú.
Reservar mesa: El cliente reserva una mesa para comer.
Autenticar cliente: Verifica la identidad del cliente (por ejemplo, mediante una cuenta de lealtad).
Pagar la cuenta: El cliente paga su pedido (obligatorio para Ordenar comida).
Solicitar para llevar: Una solicitud opcional para empacar el pedido para llevar.
Incluir: Ambos Ordenar comida y Reservar mesa requieren Autenticar cliente para verificar la identidad del cliente. Ordenar comida también incluye Pagar la cuenta porque el pago es obligatorio después de realizar el pedido.
Extender: Pedir comida puede ser extendido porSolicitar para llevar si el cliente elige llevarse la comida.
[Pedir comida] ----<<incluir>>----> [Autenticar cliente]
[Pedir comida] ----<<incluir>>----> [Pagar la cuenta]
[Reservar mesa] ----<<incluir>>----> [Autenticar cliente]
[Solicitar para llevar] ----<<extender>>----> [Pedir comida]
(Nota: Condición = El cliente solicita para llevar)
Autenticar cliente está incluido en ambosPedir comida yReservar mesa porque es un paso obligatorio para acceder al sistema.
Pagar la cuenta está incluido enPedir comida porque el pago es necesario para completar el pedido.
Solicitar para llevar extiendePedir comida porque es un comportamiento opcional que solo ocurre si el cliente solicita para llevar.
Use con moderación la función incluir: Solo extraiga el comportamiento en un caso de uso incluido si es compartido por múltiples casos de uso o simplifica significativamente el caso de uso base. El uso excesivo de incluir puede hacer que los diagramas se vean desordenados.
Defina puntos de extensión claros para extender: Especifique las condiciones o puntos en el caso de uso base donde se aplica el comportamiento de extensión para evitar ambigüedades.
Mantenga los casos de uso enfocados: Asegúrese de que el caso de uso base permanezca simple y enfocado en su objetivo principal, utilizandoIncluir para los pasos obligatorios yExtender para los opcionales.
Valide la reutilización para Incluir: El caso de uso incluido debe ser significativo y reutilizable en diferentes contextos.
Evite complicar excesivamente los diagramas: UseIncluir yExtender solo cuando aporten claridad. Las relaciones complejas pueden confundir a los interesados.
Confundir Incluir con Extender:
Error: UsarIncluir para un comportamiento opcional oExtender para un comportamiento obligatorio.
Solución: Compruebe siempre si el comportamiento es obligatorio (useIncluir) o condicional (useExtender).
Sobrecargar las relaciones:
Trampa: Crear demasiados Incluir o Extender relaciones, lo que dificulta la lectura del diagrama.
Solución: Solo utilice estas relaciones cuando reduzcan la redundancia o mejoren la claridad.
Condiciones de extensión ambiguas:
Trampa: No especificar la condición para una Extender relación, lo que genera confusión.
Solución: Siempre incluya una nota o descripción de la condición o punto de extensión.
Incluir comportamientos no reutilizables:
Trampa: Crear un caso de uso incluido que solo se use por un caso de uso base.
Solución: Asegúrese de que el caso de uso incluido sea reutilizable o simplifique significativamente el caso de uso base.
Los Incluir y Extender relaciones en los diagramas de casos de uso de UML son esenciales para gestionar la complejidad y garantizar la modularidad. El Incluir relación promueve la reutilización al extraer el comportamiento obligatorio y compartido, mientras que la Extender relación mantiene los casos de uso base enfocados al modelar comportamientos opcionales o condicionales. Al comprender sus propósitos, características y mejores prácticas, puedes crear diagramas de casos de uso claros, mantenibles y efectivos que comuniquen la funcionalidad del sistema a los interesados.