Busca "tipos de diagramas UML" y vas a encontrar tres respuestas distintas: unos dicen que hay 13, otros que 14, y bastantes artículos (incluida la versión anterior de esta misma guía) afirman que existen tres grandes tipos. Solo una de esas respuestas coincide con el estándar.
La cifra correcta es 14 diagramas repartidos en 2 categorías, y está fijada en la especificación UML 2.5.1 que publica el Object Management Group (OMG). Pero la pregunta que importa no es cuántos hay. Es cuáles vas a dibujar en un trabajo real, cuáles no vas a tocar nunca y por qué un lenguaje de 1996 sigue apareciendo en ofertas de empleo de 2026.
Vamos por partes.
Qué es UML y por qué sigue vivo treinta años después
UML (Unified Modeling Language) es un lenguaje de modelado visual estandarizado que permite especificar, diseñar y documentar la estructura y el comportamiento de un sistema de software mediante diagramas, sin escribir código. Lo mantiene el Object Management Group (OMG), y la versión vigente es la 2.5.1, publicada en diciembre de 2017. El lenguaje está además reconocido como norma internacional en ISO/IEC 19505, que recoge una revisión anterior de UML 2 (la 2.4.1) y que ISO confirmó de nuevo en 2025.
Antes de UML, cada equipo documentaba con su propia notación. Booch tenía la suya, Rumbaugh la suya, Jacobson la suya. Dos empresas que colaboraban en un proyecto no podían leer los diagramas de la otra sin traducirlos primero. Grady Booch, James Rumbaugh e Ivar Jacobson publicaron la versión 0.9 del lenguaje unificado en 1996 y presentaron UML 1.0 a la OMG en enero de 1997, que adoptó UML 1.1 ese mismo noviembre. A partir de ahí, un diagrama de clases significa lo mismo en Madrid que en Bangalore.
Esa es la razón por la que UML aguanta. No es el lenguaje más ágil ni el más cómodo, pero es el único con una semántica formal que todo el mundo interpreta igual. Cuando un contrato, una auditoría o una certificación exige documentación de arquitectura, nadie discute qué significa una flecha con rombo relleno.
La realidad de 2026 es más matizada, y la vemos en detalle más abajo: UML se usa mucho menos de forma completa y bastante más de forma selectiva. Casi nadie modela un sistema entero. Casi todo el mundo dibuja un diagrama de secuencia cuando tiene que explicar un flujo complicado.
Tipos de diagramas UML: 2 categorías y 14 diagramas
Aquí está el error que arrastran cientos de artículos en español sobre tipos de diagramas UML, incluida la versión anterior de esta guía: presentar "estructurales, de comportamiento y de interacción" como tres categorías al mismo nivel.
No lo son. Los diagramas de interacción son un subgrupo dentro de los de comportamiento. El Anexo A de la especificación UML 2.5.1 lo deja explícito: hay dos ramas, y la de comportamiento contiene cuatro diagramas de interacción entre sus siete miembros.
Categoría | Diagramas | Qué responde |
|---|---|---|
Estructurales (7) | Clases, Objetos, Componentes, Estructura compuesta, Despliegue, Paquetes, Perfil | Qué piezas tiene el sistema y cómo se relacionan |
Comportamiento (3) | Casos de uso, Actividades, Máquina de estados | Qué hace el sistema a lo largo del tiempo |
Comportamiento → Interacción (4) | Secuencia, Comunicación, Tiempos, Global de interacciones | Cómo se intercambian mensajes las piezas |
Distribución según el Anexo A de la especificación UML 2.5.1 (OMG, 2017). Los diagramas de interacción se cuentan dentro de los 7 de comportamiento, no aparte.
El matiz que casi nadie explica: si encuentras fuentes que hablan de 13 diagramas, no están mintiendo, están citando una versión anterior. UML 2.0 definía 13 tipos y el diagrama de perfil se incorporó a la taxonomía en UML 2.2. Desde entonces son 14 y no ha vuelto a cambiar.
Hay un segundo matiz que conviene conocer: el diagrama de objetos aparece en la taxonomía oficial, pero la especificación no le dedica una sección normativa propia. Los objetos se representan mediante instance specifications, que es el mismo mecanismo que usa el diagrama de clases. Por eso algunos autores lo tratan como una variante del de clases en lugar de como un tipo independiente.
Los 7 diagramas UML estructurales
Los diagramas UML estructurales congelan el sistema en un instante. No cuentan qué pasa, cuentan qué hay.
Diagrama de clases
El más usado con diferencia. Representa las clases del sistema, sus atributos, sus métodos y las relaciones entre ellas: herencia, composición, agregación, asociación.
Es la base de cualquier diseño orientado a objetos y el punto de partida natural para aplicar los principios SOLID antes de escribir la primera línea. Un diagrama de clases bien hecho te enseña los problemas de acoplamiento cuando todavía cuesta cero arreglarlos.
En un checkout de e-commerce tendrías clases como Carrito, LineaPedido, Producto, Pago y Usuario, con la relación de composición entre Carrito y LineaPedido marcada con rombo relleno: si el carrito desaparece, sus líneas también.
Diagrama de objetos
Una instantánea del diagrama de clases con datos reales dentro. En vez de la clase Producto, ves producto_4471: Producto con precio = 49,90.
Sirve para validar que un modelo abstracto aguanta un caso concreto. Es especialmente útil cuando el equipo discute si una relación debería ser 1:N o N:M y nadie se pone de acuerdo: pintas tres objetos reales y la discusión se acaba sola.
Diagrama de componentes
Descompone el sistema en módulos reemplazables con interfaces definidas. Cada componente expone lo que ofrece (interfaz proporcionada) y declara lo que necesita (interfaz requerida).
Es el diagrama natural para documentar un sistema de microservicios o para justificar por qué una capa no debería depender de otra, que es exactamente el terreno de la arquitectura hexagonal.
Diagrama de estructura compuesta
Mira dentro de una clase o componente y muestra sus partes internas y los puertos por los que se comunican. Es el más especializado de los siete y aparece sobre todo en sistemas embebidos y en ingeniería de sistemas con SysML.
Si estás empezando, este lo puedes dejar para después. No es una prioridad.
Diagrama de despliegue
Sitúa el software sobre el hardware. Nodos, artefactos, protocolos de conexión: qué se ejecuta en qué máquina y cómo hablan entre ellas.
Con arquitecturas cloud ha recuperado utilidad. Un diagrama de despliegue que muestre balanceador, tres instancias de aplicación, réplica de lectura de base de datos y CDN explica un coste de infraestructura mejor que una hoja de cálculo, y ayuda a detectar puntos únicos de fallo antes de que se conviertan en una incidencia a las tres de la mañana.
Diagrama de paquetes
Agrupa elementos en paquetes y dibuja las dependencias entre ellos. Su valor está en hacer visibles las dependencias circulares, que son el síntoma más fiable de una arquitectura que se está deteriorando.
Diagrama de perfil
El más raro de todos. Sirve para extender UML con estereotipos y etiquetas propias, adaptando el lenguaje a un dominio específico. Es el mecanismo que usan perfiles como SysML o MARTE para existir.
No vas a crear uno salvo que trabajes en metamodelado.
Antes de seguir con la segunda mitad, un apunte práctico: los diagramas se aprenden dibujando, no leyendo definiciones. Si quieres empezar hoy mismo, en la guía de salidas y roles tech de thePower incluimos plantillas editables de los cuatro diagramas más usados en entrevistas técnicas, con el mismo caso de checkout que estamos siguiendo aquí resuelto paso a paso.
Los 7 diagramas UML de comportamiento
Aquí el sistema se mueve. Estos diagramas cuentan qué ocurre y en qué orden.
Diagrama de casos de uso
Modela el sistema desde fuera: qué actores hay y qué pueden hacer. Actores como monigotes, casos de uso como elipses, y las relaciones include y extend entre ellos.
Es el diagrama que se enseña primero en todas partes y, paradójicamente, el que menos aporta en proyectos modernos, donde las historias de usuario cubren el mismo terreno con menos ceremonia. Sigue siendo útil para delimitar el alcance de un proyecto en la primera reunión con cliente, sobre todo cuando hay que dejar por escrito qué queda fuera.
Diagrama de actividades
Un flujo de control con nodos de decisión, bifurcaciones y barras de sincronización para el paralelismo. Es prácticamente un diagrama de flujo con semántica formal.
Es el mejor de los catorce para documentar procesos de negocio y flujos donde varias cosas ocurren en paralelo. También es el que mejor entiende una persona sin perfil técnico, cosa que importa más de lo que parece cuando tienes que validar un flujo con el departamento de operaciones.
Diagrama de máquina de estados
Modela los estados por los que pasa un objeto y qué eventos provocan cada transición. Estado inicial, estados intermedios, transiciones con guardas, estado final.
Este es el diagrama infravalorado del conjunto. Cualquier entidad de negocio con ciclo de vida —un pedido que va de creado a pagado, preparando, enviado y entregado, con ramas hacia cancelado y devuelto— gana más de un diagrama de estados que de tres reuniones. Y detecta transiciones imposibles que nadie había considerado, como pasar de devuelto a enviado.
Diagrama de secuencia
El campeón absoluto de uso real. Ordena los mensajes entre participantes a lo largo de una línea de tiempo vertical, con líneas de vida y barras de activación.
Es el que dibujas cuando tienes que explicar cómo funciona una autenticación OAuth, por qué una petición tarda 800 milisegundos o dónde exactamente se rompe una integración. Cualquier persona que trabaje en desarrollo backend acaba dibujando diagramas de secuencia aunque nunca haya estudiado UML formalmente.
Diagrama de comunicación
La misma información que el de secuencia, pero organizada alrededor de las relaciones entre objetos en vez de sobre un eje temporal. Los mensajes van numerados.
Sirve cuando lo que te interesa ver es la topología de conexiones y no el orden. En la práctica, la mayoría de equipos elige secuencia y no vuelve a mirar atrás.
Diagrama de tiempos
Representa cambios de estado sobre un eje temporal explícito, con duraciones y restricciones de tiempo. Su terreno son los sistemas de tiempo real, el software embebido y los protocolos de comunicación.
Fuera de esos ámbitos casi no se ve.
Diagrama global de interacciones
Combina varios diagramas de interacción en un flujo de nivel superior, usando la notación de actividades para encadenarlos. Es útil en sistemas grandes donde hace falta una vista de conjunto de escenarios.
Los 5 diagramas UML que vas a usar de verdad
Después de repasar los catorce tipos de diagramas UML, la conclusión honesta es que en un proyecto normal usarás cinco. Probablemente menos.
Diagrama | Frecuencia real | Cuándo lo dibujas |
|---|---|---|
Secuencia | Muy alta | Explicar un flujo, depurar una integración, documentar una API |
Clases | Alta | Diseñar el modelo de dominio, revisar acoplamiento |
Actividades | Media-alta | Documentar un proceso de negocio o un flujo con paralelismo |
Máquina de estados | Media | Cualquier entidad con ciclo de vida (pedido, ticket, suscripción) |
Despliegue | Media | Arquitectura cloud, auditorías, estimación de costes |
Los otros 9 | Baja o nula | Contextos muy específicos: embebidos, metamodelado, certificaciones |
Frecuencias basadas en el uso habitual en equipos de producto y consultoría. No son datos de encuesta, son criterio profesional.
Si vas a invertir tiempo, inviértelo en secuencia y clases. Con esos dos cubres la mayoría de situaciones en las que alguien te pide "haz un diagrama de esto".
Y el consejo menos popular: no dibujes lo que no vas a mantener. Un diagrama desactualizado hace más daño que la ausencia de diagrama, porque la gente lo lee y toma decisiones con información falsa. Si no vas a actualizarlo, no lo hagas.
Herramientas para hacer diagramas UML en 2026
La versión anterior de esta guía recomendaba ArgoUML e IBM Rational Rose. ArgoUML no publica una release desde 2014. Rational Rose está descatalogado. Esta es la foto actual.
Herramienta | Tipo | Coste | Para qué encaja |
|---|---|---|---|
Mermaid | Diagrams-as-code | Gratis, open source | Diagramas dentro de Markdown; renderiza nativo en GitHub, GitLab y Notion |
PlantUML | Diagrams-as-code | Gratis, open source | Cobertura UML más completa; el estándar para modelado C4 serio |
draw.io / diagrams.net | GUI | Gratis | Diagramas rápidos, colaborativos, sin instalar nada |
Visual Paradigm | GUI profesional | Freemium | Modelado formal, ingeniería directa e inversa de código |
StarUML | GUI de escritorio | Licencia de pago | Modelado completo con generación de código |
Enterprise Architect | GUI empresarial | Licencia de pago | Entornos regulados, trazabilidad de requisitos |
Lucidchart | GUI colaborativa | Freemium | Equipos mixtos con perfiles no técnicos |
Precios y estado de mantenimiento verificados en agosto de 2026. Consulta la web oficial de cada herramienta antes de decidir.
¿UML está muerto? UML vs C4 vs diagrams-as-code
La pregunta aparece cada año y la respuesta corta es que UML no está muerto, está acotado.
Lo que murió fue el UML completo de principios de los 2000: modelar el sistema entero con los catorce diagramas antes de escribir código, con la promesa de generar la aplicación desde el modelo. Eso no funcionó. Los modelos se desincronizaban del código en semanas y mantenerlos costaba más que el propio desarrollo.
Lo que quedó es el UML selectivo: cuatro o cinco diagramas, dibujados cuando resuelven un problema concreto de comunicación.
En paralelo apareció el modelo C4 de Simon Brown, que no compite con UML sino que se apoya en él. C4 no es una notación, es una forma de organizar la arquitectura en cuatro niveles de zoom: contexto, contenedores, componentes y código. Puedes representar esos niveles con PlantUML, con Mermaid o dibujándolos a mano. Su ventaja es que se explica en diez minutos, y ese es exactamente el motivo por el que ha ganado terreno.
Enfoque | Qué es | Curva de aprendizaje | Dónde encaja mejor |
|---|---|---|---|
UML completo | Notación estándar, 14 diagramas | Alta | Sectores regulados, certificaciones, docencia |
UML selectivo | 4-5 diagramas del estándar | Media | La mayoría de equipos de producto |
Modelo C4 | Método de 4 niveles de zoom | Baja | Documentar arquitectura para públicos mixtos |
Diagrams-as-code | Formato, no notación | Baja | Cualquier equipo con el diagrama en el repositorio |
Las tres últimas filas no son excluyentes. Lo habitual en 2026 es un equipo que organiza su documentación con C4, la escribe en Mermaid y usa notación UML de secuencia cuando toca detallar un flujo.
Donde UML sigue siendo innegociable es en entornos con exigencia normativa: dispositivos médicos, automoción, aeronáutica, banca. Ahí la trazabilidad entre requisito y diseño es auditable y el estándar ISO tiene peso legal.
Cómo aprender UML desde cero
No necesitas saber programar para empezar, aunque ayuda mucho tener nociones. Este es el orden que funciona.
Primero, la notación básica. Clases, relaciones y multiplicidad. Distinguir herencia de composición y composición de agregación. Son dos tardes.
Segundo, dibuja un sistema que conozcas. No un ejemplo de libro. Coge una aplicación que uses a diario y modela su modelo de dominio en un diagrama de clases. Ahí es donde descubres que no entendías el dominio tan bien como creías.
Tercero, secuencia y estados. Con el mismo sistema del punto anterior, dibuja un flujo completo en diagrama de secuencia y el ciclo de vida de su entidad principal en máquina de estados.
Cuarto, pásalo a código. Reescribe esos diagramas en Mermaid o PlantUML y súbelos a un repositorio. Es la diferencia entre saber UML y usar UML.
Si estás aprendiendo a programar desde cero, el mejor momento para meter UML es justo cuando empiezas con orientación a objetos: los diagramas de clases hacen visible lo que los conceptos abstractos no consiguen explicar.
Y una advertencia sobre el mercado laboral: UML solo no te contrata. Es una habilidad de apoyo, no un perfil. Lo que se contrata es desarrollo, arquitectura y análisis, y ahí UML aparece como una línea más del stack junto a lenguajes, frameworks y testing. Si tu objetivo es trabajar en tech, el modelado va dentro de una formación más amplia como la de desarrollador full stack, no como especialidad aislada.
En los programas tech de thePower el modelado se trabaja aplicado sobre proyectos reales, que es la única forma en la que estos diagramas se te quedan.
Preguntas frecuentes sobre diagramas UML
¿Tengo que dibujar los 14 diagramas en un proyecto real?
No, y hacerlo sería contraproducente. En un proyecto normal se usan entre dos y cinco diagramas, elegidos según el problema de comunicación que haya que resolver. Dibujar los catorce genera documentación que nadie mantiene y que en tres meses estará desactualizada.
¿Cuál es la diferencia entre un diagrama de secuencia y uno de comunicación?
Contienen la misma información con distinta prioridad visual. El de secuencia ordena los mensajes sobre un eje temporal vertical y hace evidente el orden. El de comunicación los organiza alrededor de las conexiones entre objetos y numera los mensajes, lo que pone la topología en primer plano. En la práctica, la mayoría de equipos usa solo el de secuencia.
¿Me van a pedir UML en una entrevista técnica?
Es poco frecuente que te pidan notación UML formal, pero muy habitual que te pidan diseñar un sistema en una pizarra. En ese ejercicio se espera que sepas representar entidades, relaciones y flujos de forma comprensible. Dominar clases y secuencia te da un lenguaje limpio para hacerlo sin improvisar la notación sobre la marcha.
¿Mermaid o PlantUML?
Mermaid si tus diagramas van dentro de documentación Markdown y quieres que GitHub, GitLab o Notion los rendericen sin configurar nada. PlantUML si necesitas cobertura completa del estándar UML, estereotipos personalizados o modelado C4 riguroso. Ambos son gratuitos y open source, y nada impide usar los dos.
¿UML sirve para bases de datos?
Parcialmente. El diagrama de clases se parece a un modelo entidad-relación y muchos equipos lo usan para diseñar el modelo de datos, pero UML modela objetos con comportamiento, no tablas. Para diseño relacional puro, el modelo entidad-relación es más preciso porque representa claves foráneas, índices y restricciones que UML no contempla.
¿Hay una versión de UML posterior a la 2.5.1?
No. La 2.5.1 es de diciembre de 2017 y sigue siendo la especificación vigente de la OMG en 2026. UML 2 está además publicado como norma ISO/IEC 19505, que recoge la revisión 2.4.1 y que ISO confirmó de nuevo en 2025. La estabilidad del estándar es intencionada: cambiarlo rompería la interoperabilidad que justifica su existencia.
De nuevo, lo primero, principal y primordial es aprender a diagramar. Luego, familiarizarte con cualquiera de estas herramientas será sencillo.
Desde luego, si buscas especializarte, el saber cómo diagramar con UML no es suficiente. También es necesario que perfecciones tus habilidades como programador y desarrollador, ampliando tus conocimientos en lenguajes de programación, frameworks y herramientas de desarrollo.
Para ello, lo mejor es optar por una formación especializada, donde tus habilidades con UML puedan ayudarte a complementar un enorme repertorio de herramientas de desarrollo.
¿Qué tal todo?, ¿digerible hasta ahora? Déjanos saber en comentarios qué opinas del tema:
