Una revisión de un profesional y una guía práctica para visualizar los requisitos del sistema mediante el modelado de casos de uso
🎯 Nueva introducción: Por qué los diagramas de casos de uso cambiaron la forma en que diseño software
Cuando empecé por primera vez en gestión de productos, recopilar requisitos se sentía como intentar atrapar humo con las manos desnudas. Los interesados describían las características en términos abstractos, los desarrolladores las interpretaban de manera diferente, y cuando llegamos a la prueba, nos dimos cuenta de que habíamos construido algo que nadie realmente necesitaba.
Eso cambió cuando descubrí los diagramas de casos de uso UML —y específicamente, cuando comencé a usarVisual Paradigm para darles vida.
Esta guía no es solo una referencia seca de especificaciones. Es la experiencia resumida de alguien que ha usado estos diagramas para alinear equipos multifuncionales, incorporar a nuevos desarrolladores y comunicar límites complejos del sistema a stakeholders no técnicos. Ya sea que seas un analista de negocios, gerente de producto, desarrollador o estudiante, encontrarás conocimientos prácticos junto con las definiciones formales de notación.
Vamos a adentrarnos.
📐 Notaciones de diagramas de casos de uso UML: El vocabulario visual
 |
|---|
| Diagrama de casos de uso UML de ejemplo |
Los diagramas de casos de uso son una piedra angular del lenguaje de modelado unificado (UML), y Visual Paradigm los hace accesibles sin sacrificar precisión. A continuación se muestra la herramienta completa de notación en la que confío diariamente:
| Icono | Nombre |
|---|---|
 |
Casos de uso |
 |
Asociación |
 |
Actor |
 |
Sistema |
 |
Incluir |
 |
Extender |
 |
Dependencia |
 |
Generalización |
 |
Realización |
 |
Colaboración |
| Lista de notaciones UML disponibles en el diagrama de casos de uso UML |
|---|
🔍 Análisis profundo: Notaciones principales explicadas (con contexto del mundo real)
Casos de uso
 |
|---|
| Caso de uso UML |
Un caso de uso representa un objetivo del usuario que puede lograrse al acceder al sistema o a la aplicación de software. En Visual Paradigm, puedes aprovechar la función de subdiagrama para describir la interacción entre el usuario y el sistema dentro de un caso de uso, creando un subdiagrama de secuencia bajo un caso de uso. También puedes describir el escenario del caso de uso utilizando el editor de flujo de eventos.
💡 Consejo profesional de experiencia: Siempre comienzo con nombres de verbo-sustantivo (“Realizar pedido”, “Generar informe”)—esto mantiene el enfoque en los resultados para el usuario, no en los internos del sistema.
Especificación OMG UML
¿Qué es un caso de uso en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 606), un caso de uso es:
Un caso de uso es la especificación de un conjunto de acciones realizadas por un sistema, que produce un resultado observable que normalmente tiene valor para uno o más actores u otros interesados del sistema.
Asociación
 |
|---|
| Asociación UML |
El actor y el caso de uso pueden estar asociados para indicar que el actor participa en ese caso de uso. Por lo tanto, una asociación corresponde a una secuencia de acciones entre el actor y el caso de uso para lograr el caso de uso.
Especificación OMG UML
¿Qué es una asociación en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 36), una asociación es:
Una asociación describe un conjunto de tuplas cuyos valores hacen referencia a instancias tipificadas. Una instancia de una asociación se llama enlace. Un enlace es una tupla con un valor para cada extremo de la asociación, donde cada valor es una instancia del tipo del extremo.
…
Una asociación especifica una relación semántica que puede ocurrir entre instancias tipificadas. Tiene al menos dos extremos representados por propiedades, cada una de las cuales está conectada al tipo del extremo. Más de un extremo de la asociación puede tener el mismo tipo.
Una propiedad de extremo de una asociación que es propiedad de una clase de extremo o que es un extremo navegable propiedad de la asociación indica que la asociación es navegable desde los extremos opuestos; de lo contrario, la asociación no es navegable desde los extremos opuestos.
Actor
 |
|---|
| Actor UML |
Los actores son las entidades que interactúan con un sistema. Aunque en la mayoría de los casos, los actores se utilizan para representar a los usuarios del sistema, los actores pueden ser en realidad cualquier cosa que necesite intercambiar información con el sistema. Por lo tanto, un actor puede ser personas, hardware de computadora, otros sistemas, etc.
Tenga en cuenta que el actor representa un rol que un usuario puede desempeñar, pero no un usuario específico. Por lo tanto, en un sistema de información hospitalaria, puede haber médico y paciente como actores, pero no el Dr. John, la Sra. Brown como actores.
💡 Consejo profesional de experiencia: He visto a equipos atascados al modelar a “John el Administrador” como un actor. Recuerde: modele roles, no personas. Esto mantiene su diagrama escalable y reutilizable.
Especificación OMG UML
¿Qué es un actor en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1), un actor es:
Un actor especifica un rol desempeñado por un usuario o cualquier otro sistema que interactúa con el sujeto. (El término “rol” se utiliza aquí de forma informal y no implica necesariamente la definición técnica de ese término que se encuentra en otras partes de esta especificación.)
…
Un actor modela un tipo de rol desempeñado por una entidad que interactúa con el sujeto (por ejemplo, intercambiando señales y datos), pero que es externa al sujeto (es decir, en el sentido de que una instancia de un actor no forma parte de la instancia de su sujeto correspondiente). Los actores pueden representar roles desempeñados por usuarios humanos, hardware externo o otros sujetos. Tenga en cuenta que un actor no necesariamente representa una entidad física específica, sino simplemente un aspecto particular (es decir, “rol”) de alguna entidad que es relevante para la especificación de sus casos de uso asociados. Por lo tanto, una sola instancia física puede desempeñar el rol de varios actores diferentes, y viceversa, un actor dado puede ser desempeñado por múltiples instancias diferentes.
Sistema
 |
|---|
| Sistema UML |
El alcance de un sistema puede representarse mediante un sistema (forma), o a veces conocido como un límite del sistema. Los casos de uso del sistema se colocan dentro de la forma del sistema, mientras que los actores que interactúan con el sistema se colocan fuera del sistema. Los casos de uso dentro del sistema constituyen los requisitos totales del sistema.
Especificación OMG UML
¿Qué es un sistema en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (Especificación de superestructura UML versión 2.4.1, página 608), un sistema es:
Si se muestra un sujeto (o frontera del sistema), la elipse del caso de uso se ubica visualmente dentro del rectángulo de la frontera del sistema. Observe que esto no significa necesariamente que el clasificador del sujeto posea los casos de uso contenidos, sino simplemente que el caso de uso se aplica a ese clasificador.
Incluir
 |
|---|
| Incluir en UML |
Una relación de inclusión especifica cómo se inserta el comportamiento del caso de uso de inclusión en el comportamiento definido para el caso de uso base.
💡 Consejo profesional de experiencia: Utilice
<<incluir>>para pasos obligatorios y reutilizables, como «Autenticar usuario», que aparece en docenas de flujos. Reduce la duplicación y mantiene los diagramas limpios.
Especificación OMG UML
¿Qué es una inclusión en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (Especificación de superestructura UML versión 2.4.1, página 604), la inclusión es:
Una relación de inclusión define que un caso de uso contiene el comportamiento definido en otro caso de uso.
Extender
 |
|---|
| Extender en UML |
Una relación de extensión especifica cómo el comportamiento del caso de uso de extensión puede insertarse en el comportamiento definido para el caso de uso base.
💡 Consejo profesional de experiencia: Reserva
<<extender>>para comportamientos opcionales o condicionales, como «Aplicar código de descuento» durante el proceso de pago. Aclara lo que es fundamental frente a lo que es situacional.
Especificación OMG UML
¿Qué es una extensión en UML? Según la especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG (Especificación de superestructura UML versión 2.4.1, página 601), extender es:
Una relación desde un caso de uso de extensión hacia un caso de uso extendido que especifica cómo y cuándo el comportamiento definido en el caso de uso de extensión puede insertarse en el comportamiento definido en el caso de uso extendido.
…
Esta relación especifica que el comportamiento de un caso de uso puede ser extendido por el comportamiento de otro (usualmente complementario) caso de uso. La extensión tiene lugar en uno o más puntos de extensión específicos definidos en el caso de uso extendido. Observe, sin embargo, que el caso de uso extendido está definido de forma independiente del caso de uso de extensión y tiene significado independientemente del caso de uso de extensión. Por otro lado, el caso de uso de extensión suele definir un comportamiento que no necesariamente tiene sentido por sí solo. En cambio, el caso de uso de extensión define un conjunto de incrementos de comportamiento modulares que aumentan la ejecución del caso de uso extendido bajo condiciones específicas.
Observe que el mismo caso de uso de extensión puede extender más de un caso de uso. Además, un caso de uso de extensión puede ser extendido a su vez.
Dependencia
 |
|---|
| Dependencia en UML |
Una relación de dependencia representa que un elemento de modelo depende de otro elemento de modelo para su especificación y/o implementación.
Especificación OMG UML
¿Qué es una dependencia en UML? Según la especificación del Lenguaje Unificado de Modelado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 61), la dependencia es:
Una dependencia es una relación que indica que un elemento o un conjunto de elementos de modelo requiere otros elementos de modelo para su especificación o implementación. Esto significa que la semántica completa de los elementos dependientes depende, ya sea semánticamente o estructuralmente, de la definición del elemento(s) proveedor(es).
Generalización
 |
|---|
| Generalización UML |
Una relación de generalización se utiliza para representar una relación de herencia entre elementos de modelo del mismo tipo. El elemento de modelo más específico comparte la misma especificación con el elemento de modelo más general, pero lleva más detalles adicionales.
Especificación OMG UML
¿Qué es una generalización en UML? Según la especificación del Lenguaje Unificado de Modelado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 70), la generalización es:
Una generalización es una relación taxonómica entre un clasificador más general y un clasificador más específico. Cada instancia del clasificador específico también es una instancia indirecta del clasificador general. Por lo tanto, el clasificador específico hereda las características del clasificador más general.
Realización
 |
|---|
| Realización UML |
Una realización es una relación entre una especificación y su implementación.
Especificación OMG UML
¿Qué es una realización en UML? Según la especificación del Lenguaje Unificado de Modelado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 131), la realización es:
La realización es una relación de abstracción especializada entre dos conjuntos de elementos de modelo, uno que representa una especificación (el proveedor) y el otro que representa una implementación de este último (el cliente). La realización puede usarse para modelar refinamiento paso a paso, optimizaciones, transformaciones, plantillas, síntesis de modelos, composición de marcos, etc.
Colaboración
 |
|---|
| Colaboración UML |
Especificación OMG UML
¿Qué es una colaboración en UML? Según la especificación del Lenguaje Unificado de Modelado (OMG UML) de OMG (especificación de superestructura UML versión 2.4.1, página 174), la colaboración es:
Una colaboración describe una estructura de elementos colaboradores (roles), cada uno realizando una función especializada, que colectivamente logran alguna funcionalidad deseada. Su propósito principal es explicar cómo funciona un sistema, y por lo tanto, normalmente solo incluye aquellos aspectos de la realidad que se consideran relevantes para la explicación. Así, detalles como la identidad o la clase precisa de las instancias reales que participan se suprimen.
🚀 Tutorial de Diagrama de Casos de Uso: Desde el Concepto hasta la Claridad
Un caso de uso describe cómo un usuario utiliza un sistema para lograr un objetivo particular. Un diagrama de casos de uso consta del sistema, los casos de uso relacionados y los actores, y relaciona estos entre sí para visualizar: ¿qué se está describiendo? (sistema), ¿quién está usando el sistema? (actores) y ¿qué quieren lograr los actores? (casos de uso), por lo tanto, los casos de uso ayudan a asegurar que se desarrolle el sistema correcto al capturar los requisitos desde el punto de vista del usuario.
¿Qué es un diagrama de casos de uso en UML?
Un caso de uso es una lista de acciones o pasos de eventos que normalmente definen las interacciones entre un rol de un actor y un sistema para lograr un objetivo. Un caso de uso es una técnica útil para identificar, aclarar y organizar los requisitos del sistema. Un caso de uso está compuesto por un conjunto de secuencias posibles de interacciones entre sistemas y usuarios que definen las características que se implementarán y la resolución de cualquier error que pueda presentarse.
Mientras que un caso de uso en sí mismo podría profundizar en muchos detalles (como el flujo de eventos y escenarios) sobre cada posibilidad, un diagrama de casos de uso puede ayudar a proporcionar una visión de nivel superior del sistema, ofreciendo una representación simplificada y gráfica de lo que el sistema debe hacer realmente.
Un caso de uso (o conjunto de casos de uso) tiene estas características:
-
Organiza los requisitos funcionales
-
Modela los objetivos de las interacciones entre el sistema/actor (usuario)
-
Describe un flujo principal de eventos (escenarios principales) y posiblemente otros flujos excepcionales (alternativas), también llamados caminos o escenarios de usuario
Notaciones del diagrama de casos de uso
Los casos de uso definen las interacciones entre actores externos y el sistema para alcanzar objetivos específicos. Un diagrama de casos de uso contiene cuatro componentes principales
Actor
Los actores suelen ser individuos involucrados con el sistema, definidos según sus roles. El actor puede ser una persona o un sistema externo.
Caso de uso
Un caso de uso describe cómo los actores utilizan un sistema para alcanzar un objetivo particular. Los casos de uso suelen ser iniciados por un usuario para cumplir objetivos, describiendo las actividades y variantes involucradas en alcanzar el objetivo.
Relación
Las relaciones entre y entre los actores y los casos de uso.
Límite del sistema
El límite del sistema define el sistema de interés en relación con el mundo que lo rodea.
Beneficios del diagrama de casos de uso
-
Los casos de uso son una técnica poderosa para la obtención y documentación de requisitos funcionales de caja negra.
-
Porque los casos de uso son fáciles de entender y ofrecen una excelente manera de comunicarse con clientes y usuarios, ya que están escritos en lenguaje natural.
-
Los casos de uso pueden ayudar a gestionar la complejidad de proyectos grandes al dividir el problema en características principales del usuario (es decir, casos de uso) y al especificar las aplicaciones desde la perspectiva del usuario.
-
Un escenario de caso de uso, a menudo representado por un diagrama de secuencia, implica la colaboración de múltiples objetos y clases; los casos de uso ayudan a identificar los mensajes (operaciones y la información o datos necesarios – parámetros) que unen los objetos y clases entre sí.
-
Los casos de uso proporcionan una buena base para vincular la verificación de los modelos de nivel superior (es decir, la interacción entre actores y un conjunto de objetos colaborativos) y, posteriormente, la validación de los requisitos funcionales (es decir, el plano de prueba de caja blanca).
-
El enfoque centrado en casos de uso proporciona enlaces rastreables para el seguimiento del proyecto, en el que las actividades clave de desarrollo, como los casos de uso implementados, probados y entregados, cumplen los objetivos y metas desde la perspectiva del usuario.
¿Cómo dibujar un diagrama de casos de uso?
Un modelo de caso de uso puede desarrollarse siguiendo los pasos a continuación.
-
Identifique a los actores (rol de los usuarios) del sistema.
-
Para cada categoría de usuarios, identifique todos los roles desempeñados por los usuarios relevantes para el sistema.
-
Identifique qué requieren los usuarios para que el sistema realice estas tareas con el fin de alcanzar estos objetivos.
-
Cree casos de uso para cada objetivo.
-
Estructura los casos de uso.
-
Priorice, revise, estime y valide a los usuarios.
💡 Adaptación Ágil: Para hacer que el enfoque de casos de uso sea más «Ágil», no detalles todos los casos de uso desde el principio. Priorízalos en tu lista de productos y refinéalos a diferentes niveles de detalle según la fase de desarrollo: justo a tiempo y justo lo suficiente.
También puedes:
-
Dibuja paquetes para la categorización lógica de casos de uso en subsistemas relacionados.
Estructuración de Casos de Uso
UML define tres estereotipos de asociación entre casos de uso:
<> Caso de Uso
El momento adecuado para usar la relación <> es después de haber completado la descripción inicial de todos tus casos de uso principales. Ahora puedes revisar los casos de uso e identificar secuencias comunes de interacción usuario-sistema.
<> Caso de Uso
Un caso de uso extendido es, efectivamente, una ruta alternativa del caso de uso base. El caso de uso <> logra esto insertando conceptualmente secuencias de acciones adicionales en la secuencia del caso de uso base.
Caso de Uso Abstracto y Generalizado
El caso de uso general es abstracto. No puede instanciarse, ya que contiene información incompleta. El título de un caso de uso abstracto se muestra en cursiva.
Ejemplo: Este ejemplo muestra un modelo de varios casos de uso empresariales (objetivos) que representan las interacciones entre un restaurante (el sistema empresarial) y sus actores principales.
Después de haber identificado los casos de uso base en la primera versión, quizás podríamos estructurar aún más esos casos de uso con casos de uso <> y <> en una segunda revisión, tal como se muestra en la figura siguiente:
Caso de Uso Empresarial
Un caso de uso empresarial se describe en terminología libre de tecnología que trata el proceso empresarial como una caja negra y describe el proceso empresarial que utilizan sus actores empresariales, mientras que un caso de uso ordinario normalmente se describe a nivel de nivel de funcionalidad del sistema y especifica la función o el servicio que el sistema proporciona al usuario. En otras palabras, el caso de uso empresarial representa cómo se realizará el trabajo manualmente en la situación actual y no necesariamente será realizado por el sistema ni pretende automatizarse en el ámbito del sistema objetivo.
Ejemplos de Diagramas de Casos de Uso
La figura siguiente muestra un ATM ejemplo de diagrama de casos de uso, que es un ejemplo bastante clásico para usar en la enseñanza de diagramas de casos de uso.
El Sistema de Gestión de Documentos (DMS) ejemplo de diagrama de casos de uso a continuación muestra los actores y casos de uso del sistema. En particular, existen relaciones de inclusión y extensión entre los casos de uso.
El Sistema de Pedidos el siguiente ejemplo de diagrama de casos de uso muestra los actores y casos de uso involucrados en el sistema:
🛠️ Mi flujo de trabajo en Visual Paradigm: Consejos que realmente ahorrarán tiempo
Después de años modelando, aquí está mi enfoque simplificado en Visual Paradigm:
Inicio rápido
-
Iniciar el diagrama: Vaya a
Diagrama > Nuevoy seleccione Diagrama de casos de uso. -
Agregar elementos: Use la barra de herramientas izquierda para arrastrar un Actor o Caso de uso al lienzo.
-
Modelado rápido: Pase el cursor sobre un actor y use el Catálogo de Recursos (el ícono pequeño en la esquina superior derecha de la forma) para arrastrar una nueva conexión; esto crea y vincula automáticamente un nuevo Caso de uso.
-
Generación con IA: Puede usar la herramienta de IA para generar un diagrama inicial proporcionando una descripción de texto simple de su dominio, como «sistema de cajero automático».
Características avanzadas en las que confío
-
Flujo de eventos: Haga clic derecho en un caso de uso y seleccione Detalles del caso de uso para escribir una descripción paso a paso del recorrido del usuario.
-
Prototipado: Vincule un Prototipo directamente a un paso del caso de uso para visualizar la interfaz de usuario para esa acción específica.
-
Vinculación de requisitos: Conecte casos de uso a requisitos comerciales específicos para asegurarse de que cada característica técnica tenga un propósito claro.
💡 Consejo profesional: Siempre exporto diagramas como SVG para documentación y PNG para presentaciones. Las opciones de exportación de Visual Paradigm hacen esto sin problemas.
🎯 Nueva conclusión: ¿Por qué esto importa más allá del diagrama
Los diagramas de casos de uso no son solo ejercicios académicos: son herramientas de comunicación que cierran brechas. En mi experiencia:
✅ Partes interesadas finalmente ven qué el sistema hace sin ahogarse en jerga técnica.
✅ Desarrolladores obtienen límites claros para la implementación y las pruebas.
✅ Equipos de QA derivan escenarios de prueba directamente de los flujos de casos de uso.
✅ Propietarios de producto priorizan características según los objetivos de los actores, no solo por complejidad técnica.
El verdadero poder no está en dibujar óvalos perfectos y figuras de palo: está en las conversaciones que el diagrama desencadena. Cuando un analista de negocios, un desarrollador y un usuario final pueden señalar la misma visualización y decir: «Sí, eso es lo que estamos construyendo», has logrado la alineación.
Visual Paradigm reduce la barrera para crear estos diagramas sin sacrificar la rigurosidad de UML. Ya sea que estés documentando una migración de sistema heredado o esbozando un producto de campo verde, invertir tiempo en el modelado de casos de uso genera beneficios en menos rehacer, requisitos más claros y equipos más felices.
Empieza simple. Itera con frecuencia. Deja que el diagrama evolucione con tu comprensión.
📚 Referencia
- ¿Qué es un diagrama de casos de uso? – Una guía introductoria al diagrama de casos de uso: Una visión general fundamental que explica el propósito, los componentes y los beneficios de los diagramas de casos de uso en UML, ideal para principiantes y profesionales por igual.
- Cómo identificar los objetivos de negocio de un sistema de TI: Orientación práctica sobre alinear los requisitos técnicos con los objetivos de negocio mediante técnicas de modelado de casos de uso.
- Guía para principiantes sobre diagramas de casos de uso con Visual Paradigm Online: Tutorial paso a paso para crear diagramas de casos de uso utilizando la herramienta basada en la nube de Visual Paradigm, con capturas de pantalla y consejos de flujo de trabajo.
- Dibujar un diagrama de casos de uso – Guía del usuario: Documentación oficial que detalla la mecánica de crear diagramas de casos de uso en Visual Paradigm, incluyendo el uso de la barra de herramientas y las propiedades de los elementos.
- Tutorial de diagrama de casos de uso de UML (Video): Recorrido visual de los conceptos y creación de diagramas de casos de uso, adecuado para aprendices visuales y sesiones de capacitación en equipo.
- Tutorial de diagrama de casos de uso UML – Lucidchart: Referencia entre herramientas que explica la notación de casos de uso, relaciones y mejores prácticas con ejemplos visuales claros.
- Plantilla y ejemplos de diagrama de casos de uso – Study.com: Recurso educativo con plantillas, ejemplos del mundo real y explicaciones de los componentes del diagrama de casos de uso para uso académico y profesional.
- Redacción de casos de uso efectivos: Guía avanzada sobre la documentación de escenarios de casos de uso, flujo de eventos y vinculación de diagramas con especificaciones detalladas.
- Generación de diagramas impulsada por IA en Visual Paradigm: Demostración del uso de herramientas de IA para acelerar la creación de diagramas de casos de uso a partir de descripciones en lenguaje natural.
- Guía de notaciones de diagramas de casos de uso – Visual Paradigm Circle: Referencia completa para todas las notaciones UML admitidas en diagramas de casos de uso, con extractos de especificaciones de OMG.
- Documentación de casos de uso – Guía del usuario: Instrucciones para enriquecer los casos de uso con descripciones, condiciones previas/posteriores y flujos alternativos dentro de Visual Paradigm.
- Visión general de la herramienta de casos de uso de Visual Paradigm: Página de producto que destaca las características de las capacidades de modelado de casos de uso de Visual Paradigm, incluyendo opciones de colaboración y exportación.
- Mejores prácticas para diagramas de casos de uso (Vídeo): Consejos de expertos para evitar errores comunes y maximizar el valor de los diagramas de casos de uso en proyectos ágiles y tradicionales.
- Diagramas de casos de uso para el diseño de sistemas (Vídeo): Ejemplos prácticos de la aplicación de diagramas de casos de uso a arquitecturas de sistemas del mundo real y recopilación de requisitos.