Publicado enUML

Dominar las relaciones de casos de uso de UML: el poder y el peligro de «include» y «extend»

En el mundo de los requisitos de software y la modelización de sistemas, UML (Lenguaje Unificado de Modelado) sigue siendo una piedra angular para visualizar el comportamiento del sistema. Entre sus características más potentes pero frecuentemente malinterpretadas están las«include» y  «extend»  relaciones entre casos de uso. Estos mecanismos están diseñados para reducir la duplicación, gestionar la variabilidad, y mejorar la modularidad en los modelos de casos de uso. Sin embargo, su uso indebido es frecuente—lo que conduce a diagramas excesivamente complejos, confusión entre los interesados y una pérdida de enfoque en el valor para el usuario.

 

 

Este artículo ofrece una guía completa, práctica y respaldada por expertos para comprender, aplicar y evitar los errores comunes de «include» y «extend». Exploraremos sus verdadero significado, compárelos lado a lado, examine por qué caen en la misma trampa que los DFD (descomposición funcional), y ofrezcan mejores prácticas modernas para equipos de 2025–2026—especialmente aquellos que trabajan en entornos ágiles, ágiles o híbridos.

🔹 Semántica central: ¿Qué significan realmente «include» y «extend» Realmente significan

✅ «include»: Reutilización obligatoria – El subproceso «siempre requerido»

Definición:
La relación «include» representa unobligatoria, siempre ejecutada subflujo que se ha factorizado para reutilizarse en múltiples casos de uso.

📌 Características clave:

  • Siempre ejecutada: El caso de uso incluido se ejecuta cada vez que se invoca el caso de uso base.

  • El caso de uso base es incompleto sin él: Sin el comportamiento incluido, el caso de uso base no puede cumplir su propósito.

  • Dirección de dependencia: La flecha apuntadesde base → incluido.

  • Significado independiente: El caso de uso incluido suele serno significativo por sí solo—solo tiene sentido como parte de un proceso más amplio.

  • Analogía: Como unallamada a funciónosubrutina en programación—esencial para la rutina principal.

🧠 Mnemónico clásico:

“Para hacerIniciar sesión, debesAutenticar usuario.”
“Para hacerRetirar efectivo, usted debe Validar PIN.”

Estos son pasos no negociables. No puede iniciar sesión sin autenticación. No puede retirar efectivo sin validar el PIN.

💡 Cuándo usarlo:

  • Cuando un comportamiento común, complejo y reutilizable aparece en dos o más casos de uso.

  • Ejemplos:

    • Autenticar usuario

    • Registrar registro de auditoría

    • Enviar notificación

    • Validar formato de entrada

✅ Regla general: Use «include» solo cuando el comportamiento reutilizado sea significativo, no trivial, y aparece en ≥2–3 casos de uso.

✅ «extend»: Variación opcional – El «complemento condicional»

Definición:
La relación «extend» defineopcional, condicional o variantecomportamiento quese conecta aun punto específico depunto de extensióndel caso de uso base.

📌 Características clave:

  • Ejecutado condicionalmente: Solo se ejecuta bajo ciertas circunstancias.

  • El caso de uso base es completo por sí solo: El flujo normal funciona sin la extensión.

  • Dirección de dependencia: La flecha apuntadesde la extensión → base (hacia atrás).

  • Significado independiente: El caso de uso extendido escasi nunca tiene sentido por sí solo—solo tiene sentidoen contexto.

  • Analogía: Como ungancho, complemento, oconsejo de programación orientada a aspectos (AOP)—añade comportamiento en un punto definido.

🧠 Mnemotécnica clásica:

“Mientras realizas Reservar vuelo, tú podrías querer Seleccionar asiento preferido.”
“Mientras realizas Pagar con tarjeta de crédito, tú podrías tener que Ingresar código 3D Secure.”

Estos son mejoras opcionales—no son necesarios para el flujo principal.

💡 Cuándo usar:

  • Para modelar caminos alternativos, excepciones, o características opcionales.

  • Cuando un caso de uso tiene comportamientos variantes basados en condiciones (por ejemplo, roles de usuario, estados del sistema, preferencias).

  • Ejemplos:

    • Aplicar descuento (extiende Colocar pedido)

    • Solicitar reembolso (extiende Procesar pago)

    • Generar recibo en PDF (extiende Completar transacción)

✅ Regla general: Use «extender» con moderación—solo para variaciones significativas con claridad puntos de extensión.

🔍 Comparación rápida: «incluir» frente a «extender»

Aspecto «incluir» «extender»
Ejecución Siempre A veces / condicionalmente
¿El UC base se completa solo? ❌ No — depende del incluido ✅ Sí — se completa sin extensiones
Dirección de dependencia Base → Incluido Extender → Base
Dirección de la flecha Apunta al caso de uso incluido Apunta al caso de uso base
Objetivo principal Reutilizar pasos obligatorios y compartidos Gestionar flujos opcionales o variantes
Analogía Llamada a función / subrutina Gancho / complemento / consejo AOP
¿Significado independiente? Rara vez Casi nunca
Mejor para Preocupaciones reutilizables, complejas y transversales Comportamiento condicional, opcional o alternativo

⚠️ El “trampa de descomposición”: ¿Por qué los diagramas de casos de uso se desvían del camino?

Al igual que DFD (Diagramas de flujo de datos) sufren del trampa de descomposición funcional, los diagramas de casos de uso son propensos a la misma enfermedad mortal: sobredescomposición.

📉 La trampa de descomposición funcional del DFD (Resumen):

  • Los equipos siguen dividiendo los procesos en burbujas cada vez más pequeñas.

  • Los diagramas explotan en docenas de funciones pequeñas y de bajo nivel.

  • El el propósito original—entregar valor al usuario—se pierde.

  • Termina pareciéndose a pseudo-código o diseño interno del algoritmo, no el comportamiento del usuario.

🧨 El caso de uso “Enfermedad de la descomposición funcional”:

  • Cada pequeño paso se convierte en su propio caso de uso:

    • Ingresar nombre de usuario

    • Ingresar contraseña

    • Hacer clic en el botón de inicio de sesión

    • Validar formato

    • Mostrar mensaje de error

  • «incluir» se aplica liberalmente para descomponer cada acción.

  • Resultado: Una jerarquía profunda de casos de uso (A → B → C → D…) sin un objetivo claro del actor.

  • Los diagramas se vuelven imposibles de mantener, confusos, y inútiles para los interesados.

❌ Bandera Roja: Si tu diagrama de casos de uso tiene más de 15-20 casos de uso, o si la mayoría de los casos de uso base tienen entre 2 y 4 pasos, es probable que estés atrapado.

🛠️ Por qué ocurre esto: Errores comunes y malentendidos

Error común Explicación Cómo evitarlo
Sobrecargar el uso de «include» Tratar cada subpaso como un caso de uso reutilizable. Solo usa «include» para significativo, reutilizable, transversal comportamientos (por ejemplo, autenticación, registro).
Confundir la dirección de la flecha Dibujar las flechas de «include» hacia atrás (base ← incluido) o las flechas de «extend» hacia adelante. Recuerda: include = base → incluido; extend = extendiendo → base.
Usar «extend» para alternativas Modelar flujos alternativos dentro un caso de uso como «extend» en lugar de usar alternativas textuales. Use flujos alternativos textuales para la mayoría de las variaciones. Reserve «extend» para extensiones verdaderamente opcionales.
Creación de cadenas de inclusión A → B → C → D → E… Evite cadenas profundas. Si necesita múltiples inclusiones, considere refactorizar en un único caso de uso reutilizable.
Puntos de extensión ambiguos Añadir relaciones «extend» sin puntos de inserción claros y nombrados. Defina puntos de extensión explícitos (por ejemplo, “Después de la confirmación del pago”) en el caso de uso base.
Sobrecarga de diagramas Demasiados casos de uso y relaciones → ruido visual. Mantenga los diagramas pequeños, enfocados y centrados en el actor. Use múltiples diagramas por subsistema.
Confusión de los interesados Los interesados no técnicos encuentran difícil comprender «include/extend». Use escenarios textuales o mapas de historias de usuario para claridad.
Modelado a nivel de diseño Modelado de la arquitectura interna (por ejemplo, “llamar a la base de datos”) en lugar de objetivos del usuario. Manténgase enfocado en valor del actor—no implementación.
Debates interminables Equipos discutiendo sobre «¿es incluir o extender?» en lugar de escribir escenarios. Usa heurísticas prácticas y prioriza la claridad sobre la formalidad.

✅ Mejores prácticas para 2025–2026: Un enfoque moderno y ágil

El panorama de la ingeniería de requisitos ha cambiado. Equipos ágiles, ágiles y orientados al producto se están alejando cada vez más de los diagramas UML pesados a favor de técnicas ligeras y centradas en el valor técnicas.

🎯 Principio fundamental: Enfócate en el valor del actor, no en la estructura interna

❗ Haz esta pregunta antes de agregar cualquier «incluir» o «extender»:
«¿Esta relación ayuda al usuario a entender la meta, o solo está desglosando el sistema?»

✅ Prácticas modernas recomendadas:

1. Usa «incluir» con moderación — Solo para comportamientos reutilizables importantes

  • Úsalo solo para asuntos transversales que aparecen en múltiples casos de uso.

  • Ejemplos:

    • Autenticar usuario

    • Enviar notificación por correo electrónico

    • Registrar evento de seguridad

    • Aplicar reglas de negocio

❌ Evitar: Ingresar nombre de usuario, Hacer clic en Enviar, Validar formato de correo electrónico

2. Preferir flujos alternativos textuales sobre «extend»

  • En lugar de:

    «extend»: Seleccionar asiento preferido → Reservar vuelo

  • Usar:

    Casos de uso: Reservar vuelo
...
Flujo alternativo:
  1. El usuario selecciona la opción "Asiento preferido".
  2. El sistema muestra el mapa de asientos.
  3. El usuario selecciona un asiento.
  4. El sistema aplica la preferencia de asiento.

✅ ¿Por qué? Los flujos textuales son más fáciles de leer, más flexibles, y menos propensos al mal uso.

3. Mantener Diagramas de casos de uso Pequeños y enfocados

  • Un diagrama por actor o subsistema.

  • Limitar a 5–10 casos de uso por diagrama.

  • Usar diagramas de paquetes o diagramas de contexto para mostrar la estructura de alto nivel.

4. Pregúntate: “¿Un mapa de historias de usuario comunicaría esto mejor?”

  • Si estás utilizando 10+ relaciones «incluir»/«extender», considera reemplazar el diagrama con:

    • Un mapa de historias de usuario

    • Un tabla basada en escenarios

    • Un diagrama de flujo simple con rutas clave

🔄 Tendencia moderna: Muchos equipos ágiles evitan por completo los diagramas de casos de uso o los usan solo para descubrimiento de alto nivel.

5. Use «extend» solo para variantes significativas

  • Reserva «extend» paraopcional, no esencialcaracterísticas que:

    • Sonraramente utilizadas

    • Sondependientes del contexto

    • Sonindependientesdel objetivo principal

✅ Ejemplo:
Procesar pago (base)
Aplicar autenticación 3D Secure (extend) — solo cuando sea requerido por el banco

❌ Evita:
Ingresar número de tarjeta → Validar tarjeta → Procesar pago (todos deben ser pasos en el mismo caso de uso)

📊 Resumen: Las reglas doradas de «include» y «extend»

Regla Guía
1. «include» = Obligatorio Usa solo paraesenciales, reutilizablespasos que aparecen en ≥2 casos de uso.
2. «extend» = Opcional Úselo solo paracondicional, variante o raracomportamientos.
3. El caso de uso base debe ser completo «extend»: el caso base funciona solo. «include»: el caso base es incompleto sin él.
4. Manténgalo simple Si un caso de uso tiene menos de 4–6 pasos después de «include»/«extend», lo ha descompuesto demasiado.
5. Priorice la legibilidad Escenarios textuales > diagramas complejos.
6. Evite cadenas No A → B → C → D. Refactórelo en un caso de uso reutilizable.
7. Conozca a su audiencia Los interesados no se preocupan por las flechas «include»—les importa el valor.
Pregúntese: «¿Es este un objetivo del usuario o un paso interno?» Si no es un objetivo para el actor, probablemente no deba incluirse en un caso de uso.

🎯 Pensamiento final: Herramientas, no trampas

«include» y «extend» sonherramientas poderosas—no reglas rígidas. Fueron diseñadas para:

  • Reducir la duplicación

  • Gestionar la variabilidad

  • Mejorar la mantenibilidad

Pero comola descomposición funcional en DFDs, se convierten enarmas peligrosascuando se usan en exceso. El verdadero peligro no son las relaciones en sí—esperder de vista el objetivo del usuario.

🔥 Recuerda:
Un caso de uso no es un proceso técnico.
Es una historia sobre lo que el usuario quiere lograr—y cómo el sistema ayuda.

Cuando tengas dudas, pregúntate:

“¿Entendería un usuario esto sin conocer UML?”
Si no, simplifica.
Si sí, estás en el camino correcto.

📚 Lecturas adicionales y referencias

  • Especificación UML (OMG): www.omg.org/spec/UML

  • Martin Fowler – Modelado de casos de uso: Patrones de análisis & UML resumido

  • Ivar Jacobson – La ventaja de los objetos: Trabajo fundamental sobre casos de uso

  • Modelado ágil (AM) por Scott W. Ambler

  • Mapa de historias de usuario por Jeff Patton – Una alternativa moderna a los diagramas complejos

✅ La regla de la oración única

Utilice «include» para reutilización obligatoria, «extend» para variación opcional, pero solo cuando realmente aporte valor. De lo contrario, manténgalo simple.

Porque al final, el objetivo no es dibujar diagramas perfectos diagramas UML—es construir sistemas que aporten valor real a personas reales.

📌 Nota del autor (2025–2026):
A medida que los equipos se orientan hacia enfoque centrado en el producto, orientado al valor, y colaborativo desarrollo, el papel de los diagramas UML tradicionales está evolucionando. «include» y «extend» siguen siendo útiles, pero solo cuando se usan con moderación, claridad y propósito. Deje que sirvan al usuario, no al diagrama.