Diagramas UML de comportamiento: qué son, tipos, ejemplos

Los diagramas UML de comportamiento sirven para representar qué ocurre dentro de un sistema cuando se usa. No se centran tanto en las piezas estáticas del software, sino en las acciones, procesos, interacciones, estados y decisiones que aparecen durante su funcionamiento.

Dicho de forma más sencilla: si un diagrama de clases nos ayuda a entender qué elementos forman un sistema, los diagramas UML de comportamiento nos ayudan a entender cómo se comporta ese sistema cuando alguien interactúa con él.

Y esto, en desarrollo de software, es mucho más importante de lo que parece. En mi experiencia, tanto trabajando en desarrollo como explicando conceptos técnicos en FP Informática, muchas dudas aparecen no porque falte código, sino porque falta una visión clara del comportamiento esperado: qué puede hacer cada usuario, qué pasos sigue un proceso, qué mensajes se envían los objetos o por qué estados pasa una entidad.

Por eso, los diagramas UML de comportamiento no deberían verse como una tarea burocrática ni como “dibujos que hay que entregar”. Bien usados, son una herramienta para pensar mejor antes de programar, detectar problemas de diseño y comunicar decisiones de forma clara.

En esta guía vamos a ver qué son los diagramas UML de comportamiento, qué tipos principales existen, cuándo usar cada uno, qué errores conviene evitar y cómo puedes apoyarte en herramientas como PlantUML para crearlos de forma más sencilla.

Qué son los diagramas UML de comportamiento

Los diagramas UML de comportamiento representan lo que ocurre cuando un sistema está en uso. Es decir, muestran cómo responde el sistema ante acciones externas o internas: una persona que inicia sesión, un cliente que realiza un pedido, una reserva que cambia de estado o un proceso que toma caminos diferentes según una condición.

Cuando hablamos de comportamiento en UML, no estamos hablando de la estructura del sistema, sino de su funcionamiento. Por ejemplo, en una biblioteca digital, el comportamiento incluye acciones como buscar libros, solicitar préstamos, devolver ejemplares o consultar el historial. En una tienda online, el comportamiento puede incluir añadir productos al carrito, calcular el total, pagar, confirmar el pedido y actualizar el stock.

Aquí es donde los diagramas UML de comportamiento tienen sentido. Cada uno responde a una pregunta distinta. Si quiero saber qué puede hacer cada usuario, usaré un diagrama de casos de uso. Si quiero ver los mensajes entre objetos durante una operación, usaré un diagrama de secuencia. Si me interesa el ciclo de vida de una entidad, probablemente usaré un diagrama de estados. Y si necesito representar los pasos de un proceso, el diagrama de actividades será una opción mucho más clara.

Esta distinción es clave. Un error habitual al aprender UML es querer meterlo todo en un único diagrama. Pero un buen modelo no consiste en hacer el diagrama más grande posible, sino en elegir el diagrama adecuado para la pregunta que queremos responder.

En clase suelo explicarlo con una idea sencilla: antes de dibujar, pregúntate qué quieres aclarar. Si no puedes formular esa pregunta, probablemente todavía no sabes qué diagrama necesitas. Los diagramas UML de comportamiento son útiles precisamente porque nos obligan a pensar en términos de uso, interacción y proceso.

La diferencia entre estructura y comportamiento en UML

Los diagramas estructurales muestran cómo está organizado un sistema. Por ejemplo, un diagrama de clases responde a preguntas como: qué clases existen, qué atributos tienen, qué métodos ofrecen y cómo se relacionan entre ellas.

Los diagramas UML de comportamiento, en cambio, responden a preguntas distintas:

Pregunta	Diagrama recomendado
¿Qué puede hacer cada usuario?	Diagrama de casos de uso
¿Qué objetos colaboran en una operación?	Diagrama de secuencia o comunicación
¿En qué orden se envían mensajes?	Diagrama de secuencia
¿Por qué estados pasa un objeto?	Diagrama de estados
¿Qué pasos sigue un proceso?	Diagrama de actividades
¿Qué decisiones o alternativas hay en un flujo?	Diagrama de actividades

Una analogía bastante útil es pensar en una máquina. El diagrama de clases sería el plano de sus piezas. Los diagramas UML de comportamiento serían el manual que explica qué ocurre cuando pulsamos cada botón, cómo se mueve cada parte y qué resultado esperamos en cada situación.

Esa es la razón por la que los diagramas UML de comportamiento son tan útiles en análisis y diseño de software. Ayudan a entender el sistema antes de construirlo, pero también sirven para explicarlo después, mantenerlo y detectar incoherencias.

Una forma sencilla de entenderlos antes de programar

Antes de escribir código, conviene saber qué debe hacer el sistema. Parece obvio, pero en proyectos reales se salta este paso más veces de las que debería.

En consultoría y desarrollo he comprobado que muchos problemas no aparecen porque falte tecnología, sino porque se ha empezado demasiado rápido sin entender bien el proceso. Por ejemplo: ¿qué ocurre si el pago falla?, ¿quién puede cancelar una reserva?, ¿una incidencia cerrada puede volver a abrirse?, ¿el usuario debe estar validado antes de realizar una operación?

Los diagramas UML de comportamiento ayudan a responder a esas preguntas. No sustituyen al código, pero preparan el terreno para que el código tenga más sentido.

Tipos principales de diagramas UML de comportamiento

Dentro de UML hay varios diagramas orientados a representar comportamiento. En una primera aproximación, los más importantes son cinco: casos de uso, secuencia, comunicación, estados y actividades.

Cada uno tiene una función concreta. No compiten entre sí; se complementan. De hecho, una misma funcionalidad puede representarse con varios diagramas UML de comportamiento, pero cada uno aportará una vista distinta.

Por ejemplo, imaginemos un sistema de reservas. Con un diagrama de casos de uso puedo representar que un usuario puede consultar salas, crear una reserva, cancelar una reserva o consultar sus reservas. Con un diagrama de secuencia puedo explicar qué objetos colaboran cuando se crea una reserva. Con un diagrama de estados puedo representar que una reserva puede estar solicitada, confirmada, cancelada o finalizada. Y con un diagrama de actividades puedo mostrar los pasos del proceso de creación de reserva.

Eso es lo interesante de los diagramas UML de comportamiento: no muestran “todo”, sino la parte del comportamiento que nos interesa comprender en cada momento.

Diagrama	Qué representa	Cuándo usarlo
Casos de uso	Funcionalidades del sistema desde el punto de vista de actores externos	Al inicio del análisis
Secuencia	Mensajes entre participantes ordenados en el tiempo	Para explicar una operación paso a paso
Comunicación	Colaboración entre objetos mediante mensajes numerados	Para ver qué objetos colaboran
Estados	Estados y transiciones de un objeto	Para entidades con ciclo de vida claro
Actividades	Flujo de trabajo, decisiones y caminos alternativos	Para procesos de negocio o software

Diagrama de casos de uso

El diagrama de casos de uso representa qué funcionalidades ofrece un sistema desde el punto de vista de los actores que interactúan con él. Es uno de los diagramas UML de comportamiento más habituales al inicio del análisis porque ayuda a definir el alcance del sistema.

No muestra código. No muestra clases. No muestra detalles internos. Muestra qué se puede hacer con el sistema.

Por ejemplo, en una plataforma educativa, un alumno puede consultar materiales, entregar tareas y consultar calificaciones. Un profesor puede publicar materiales, crear tareas, revisar entregas y calificar. Un administrador puede gestionar usuarios y configurar el curso.

Diagrama de secuencia

El diagrama de secuencia representa cómo interactúan actores, objetos o componentes a lo largo del tiempo. El tiempo avanza normalmente de arriba hacia abajo, y los mensajes aparecen en el orden en que se producen.

Es uno de los diagramas UML de comportamiento más útiles cuando queremos explicar una operación concreta. Por ejemplo, iniciar sesión, crear una reserva, solicitar un préstamo digital o procesar un pago.

Diagrama de comunicación

El diagrama de comunicación también representa interacción entre objetos, pero pone más atención en qué objetos colaboran y cómo están conectados. A diferencia del diagrama de secuencia, no organiza visualmente el tiempo de arriba abajo, sino que usa mensajes numerados.

Es útil cuando queremos ver la red de colaboración entre objetos sin dar tanto protagonismo a la línea temporal.

Diagrama de estados

El diagrama de estados muestra los estados por los que pasa un objeto durante su ciclo de vida. Es especialmente útil para entidades como pedido, reserva, incidencia, matrícula, préstamo o tarea.

No todos los objetos necesitan un diagrama de estados. Tiene sentido cuando la entidad puede encontrarse en varias situaciones y existen reglas sobre qué cambios están permitidos.

Diagrama de actividades

El diagrama de actividades representa un flujo de trabajo. Se parece a un diagrama de flujo, pero forma parte de UML y permite modelar acciones, decisiones, caminos alternativos, paralelismos y responsabilidades mediante swimlanes.

Es uno de los diagramas UML de comportamiento más fáciles de entender al principio, porque conecta muy bien con la idea de proceso paso a paso.

Diagrama de casos de uso: qué puede hacer cada actor

El diagrama de casos de uso es ideal cuando queremos responder a una pregunta sencilla: ¿qué puede hacer cada actor con el sistema?

Esta pregunta parece simple, pero tiene mucha fuerza. Antes de pensar en pantallas, clases, bases de datos o controladores, necesitamos entender quién interactúa con el sistema y qué espera conseguir.

Por eso el diagrama de casos de uso suele aparecer al principio del análisis. Ayuda a delimitar el alcance, detectar funcionalidades principales y hablar con usuarios o clientes usando un lenguaje comprensible.

En mi caso, cuando explico diagramas UML de comportamiento, suelo insistir mucho en esto: el diagrama de casos de uso no está pensado para enseñar cómo funciona internamente el código. Está pensado para aclarar qué servicios ofrece el sistema desde fuera. Si empezamos a meter detalles técnicos demasiado pronto, el diagrama pierde su utilidad.

Actores, casos de uso y límite del sistema

Un actor es cualquier entidad externa que interactúa con el sistema. Puede ser una persona, otro sistema, una pasarela de pago, un servicio de correo o un administrador.

Un caso de uso representa una funcionalidad con valor para un actor. Por eso conviene nombrarlo con una acción clara, normalmente usando un verbo en infinitivo: iniciar sesión, realizar pedido, consultar calificaciones, registrar incidencia, entregar tarea.

Una regla práctica muy útil es esta: si el nombre del caso de uso no encaja con la frase “el actor puede…”, probablemente está mal nombrado.

Por ejemplo:

Buen nombre	Nombre poco recomendable	Motivo
Iniciar sesión	Login	Es más claro para el usuario
Realizar pedido	Pedido	El caso de uso debe ser una acción
Consultar calificaciones	Notas	Describe mejor qué hace el actor
Registrar incidencia	Incidencia	El verbo aclara la funcionalidad

El límite del sistema se representa con un rectángulo que contiene los casos de uso. Los actores quedan fuera porque son externos. Esta separación ayuda a distinguir qué forma parte del sistema y qué elementos interactúan con él desde fuera.

Diferencia entre include y extend

Dentro de los diagramas UML de comportamiento, las relaciones include y extend suelen generar dudas al principio.

La relación include se usa cuando un caso de uso necesita ejecutar siempre otro comportamiento común. Por ejemplo, realizar pedido puede incluir validar usuario. Si cada vez que se realiza un pedido el sistema debe validar al usuario, entonces tiene sentido usar include.

La relación extend se usa cuando un caso de uso añade un comportamiento opcional, excepcional o condicionado. Por ejemplo, aplicar cupón descuento puede extender realizar pedido, porque no todos los pedidos usan cupón.

La diferencia importante es esta:

Relación	Cuándo usarla	Ejemplo
include	Cuando el comportamiento es obligatorio	Realizar pedido incluye validar usuario
extend	Cuando el comportamiento es opcional o condicionado	Aplicar cupón extiende realizar pedido

Un error habitual es usar include y extend como si fueran simples flechas decorativas. No lo son. Representan decisiones de modelado, y por eso deben utilizarse solo cuando aportan claridad.

Ejemplo práctico de casos de uso

Imaginemos una plataforma educativa. Los actores principales podrían ser Alumno, Profesor y Administrador.

El alumno puede consultar materiales, entregar tareas y consultar calificaciones. El profesor puede publicar materiales, crear tareas, revisar entregas y calificar. El administrador puede gestionar usuarios y configurar el curso.

Un esquema textual podría ser:

Sistema: Plataforma educativa

Actor: Alumno
- Consultar materiales
- Entregar tarea
- Consultar calificaciones

Actor: Profesor
- Publicar material
- Crear tarea
- Revisar entrega
- Calificar tarea

Actor: Administrador
- Gestionar usuarios
- Configurar curso

Este ejemplo muestra por qué el diagrama de casos de uso es tan útil al inicio. No necesitamos saber todavía qué clases habrá ni cómo se implementará cada operación. Primero queremos entender qué funcionalidades existen y quién las usa.

Entre todos los diagramas UML de comportamiento, este es probablemente el más cercano al lenguaje del usuario. Por eso también es muy útil para revisar requisitos y evitar malentendidos.

Diagrama de secuencia: mensajes ordenados en el tiempo

El diagrama de secuencia es uno de los diagramas UML de comportamiento más importantes cuando queremos saber qué ocurre paso a paso durante una operación.

Su punto fuerte es el orden temporal. Permite ver qué participante envía un mensaje, quién lo recibe, qué respuesta devuelve y en qué momento ocurre cada cosa.

En una aplicación real, esto puede ser muy útil para explicar procesos como iniciar sesión, registrar una reserva, solicitar un préstamo digital, recuperar una contraseña o confirmar un pedido.

Mientras que el diagrama de casos de uso nos dice “el usuario puede iniciar sesión”, el diagrama de secuencia nos ayuda a responder: ¿qué ocurre exactamente cuando el usuario inicia sesión?

Participantes, líneas de vida y mensajes

Los elementos principales de un diagrama de secuencia son:

Elemento	Significado
Participante	Actor, objeto, servicio o componente que interviene
Línea de vida	Existencia del participante durante la interacción
Activación	Momento en el que un participante ejecuta una operación
Mensaje	Comunicación entre participantes
Retorno	Respuesta devuelta por un participante
Fragmento combinado	Bloque para alternativas, bucles u opciones

Un ejemplo textual sencillo de login sería:

Usuario -> PantallaLogin: introducirCredenciales(email, password)
PantallaLogin -> AuthService: login(email, password)
AuthService -> UsuarioRepository: buscarPorEmail(email)
UsuarioRepository --> AuthService: usuario
AuthService -> AuthService: validarPassword(password, usuario)
AuthService --> PantallaLogin: resultado
PantallaLogin --> Usuario: mostrarMensaje(resultado)

Este tipo de diagrama no pretende enseñar todo el código. Lo que busca es representar la lógica principal de la interacción.

Aquí es donde conviene tener cuidado. En proyectos reales he visto diagramas de secuencia tan cargados de detalles que dejan de ayudar. Si el diagrama necesita más explicación que el propio código, algo falla. La clave está en mostrar los mensajes importantes, no absolutamente todo lo que ocurre por debajo.

Fragmentos alt y loop

Los diagramas de secuencia también permiten representar alternativas y repeticiones.

El fragmento alt se usa cuando hay varios caminos posibles. Por ejemplo, credenciales válidas o credenciales incorrectas:

alt credenciales válidas
    Sistema -> Usuario: mostrarPanelPrincipal()
else credenciales incorrectas
    Sistema -> Usuario: mostrarError()
end

El fragmento loop se usa cuando una parte de la secuencia se repite. Por ejemplo, procesar varias líneas de un pedido:

loop por cada línea del pedido
    Pedido -> LineaPedido: calcularSubtotal()
    LineaPedido --> Pedido: subtotal
end

Estos fragmentos son útiles porque evitan convertir el diagrama de secuencia en una especie de código fuente dibujado. La idea no es programar con flechas, sino representar el comportamiento de forma comprensible.

Ejemplo de login con diagrama de secuencia

El login es un buen ejemplo porque casi todo el mundo entiende el proceso.

Un usuario introduce email y contraseña. La pantalla de login envía esos datos a un servicio de autenticación. El servicio consulta el repositorio de usuarios, valida la contraseña y devuelve un resultado. Después, la pantalla muestra acceso concedido o denegado.

En PlantUML podría representarse así:

@startuml
actor Usuario
participant PantallaLogin
participant AuthService
participant UsuarioRepository

Usuario -> PantallaLogin: introducirCredenciales(email, password)
PantallaLogin -> AuthService: login(email, password)
AuthService -> UsuarioRepository: buscarPorEmail(email)
UsuarioRepository --> AuthService: usuario
AuthService -> AuthService: validarPassword(password, usuario)
AuthService --> PantallaLogin: resultado
PantallaLogin --> Usuario: mostrarMensaje(resultado)
@enduml

Este ejemplo enseña una de las grandes ventajas de los diagramas UML de comportamiento: ayudan a convertir una operación cotidiana en una secuencia clara de responsabilidades.

Diagrama de comunicación: objetos que colaboran

El diagrama de comunicación, también conocido en versiones anteriores como diagrama de colaboración, muestra qué objetos participan en una interacción y qué mensajes se envían entre ellos.

A primera vista puede parecer muy parecido al diagrama de secuencia, y en parte lo es. Ambos son diagramas UML de comportamiento centrados en la interacción. La diferencia está en el enfoque.

El diagrama de secuencia destaca el orden temporal. El diagrama de comunicación destaca la colaboración entre objetos.

Es decir, si lo que más me importa es ver qué ocurre primero, después y al final, normalmente elegiré un diagrama de secuencia. Pero si lo que quiero es ver qué objetos colaboran y cómo están conectados, el diagrama de comunicación puede ser más cómodo.

Diferencia entre diagrama de comunicación y secuencia

La diferencia se entiende mejor con una tabla:

Aspecto	Diagrama de secuencia	Diagrama de comunicación
Foco principal	Orden temporal	Colaboración entre objetos
Representación del tiempo	De arriba hacia abajo	Mensajes numerados
Lectura	Muy clara para procesos paso a paso	Útil para ver relaciones
Riesgo visual	Puede crecer mucho en altura	Puede crecer mucho en conexiones

El mismo proceso de login que antes vimos como secuencia podría representarse así en formato comunicativo:

Usuario -- PantallaLogin
PantallaLogin -- AuthService
AuthService -- UsuarioRepository

1: Usuario -> PantallaLogin: introducirCredenciales()
2: PantallaLogin -> AuthService: login()
3: AuthService -> UsuarioRepository: buscarPorEmail()
4: UsuarioRepository -> AuthService: usuario
5: AuthService -> PantallaLogin: resultado
6: PantallaLogin -> Usuario: mostrarMensaje()

Aquí el orden sigue existiendo, pero no depende de la posición vertical de los mensajes, sino de su numeración.

Cuándo merece la pena usarlo

El diagrama de comunicación merece la pena cuando queremos explicar responsabilidades entre objetos y no necesitamos una lectura temporal tan detallada.

Por ejemplo, puede ser útil cuando ya tenemos un diagrama de clases y queremos ver cómo colaboran algunas de esas clases durante una operación. También puede ayudar cuando una interacción tiene pocos objetos y mensajes claros.

Eso sí, como ocurre con otros diagramas UML de comportamiento, no hay que forzarlo. Si el proceso tiene muchas alternativas, muchas llamadas y un orden temporal importante, probablemente el diagrama de secuencia será más legible.

La idea importante es no elegir el diagrama por costumbre. Elegir bien los diagramas UML de comportamiento consiste en decidir qué vista del sistema necesitamos: funcionalidades, mensajes, colaboración, estados o flujo de trabajo.

Diagrama de estados: el ciclo de vida de un objeto

El diagrama de estados representa los estados por los que puede pasar un objeto durante su ciclo de vida y los eventos que provocan cambios entre esos estados.

Es uno de los diagramas UML de comportamiento más útiles cuando una entidad tiene una vida propia dentro del sistema. Por ejemplo, un pedido, una reserva, una incidencia, una matrícula, una tarea o un préstamo digital.

No todos los objetos necesitan un diagrama de estados. Una clase sencilla con datos estáticos quizá no lo necesita. Pero si una entidad puede estar en distintas situaciones y las reglas de transición son importantes, este diagrama puede evitar muchos errores.

Por ejemplo, un pedido puede estar creado, pagado, preparando, enviado, entregado o cancelado. Pero no cualquier cambio debería ser posible. Un pedido entregado no debería volver al estado creado. Un pedido cancelado no debería pasar a enviado. Y un pedido pagado quizá solo pueda cancelarse si todavía no está preparado.

Ahí es donde el diagrama de estados aporta valor.

Estados, eventos, transiciones y condiciones de guarda

Los elementos principales de un diagrama de estados son:

Elemento	Significado
Estado inicial	Punto donde empieza el ciclo de vida
Estado final	Punto donde termina el ciclo
Estado	Situación estable de un objeto
Evento	Hecho que provoca una transición
Transición	Cambio de un estado a otro
Condición de guarda	Condición que debe cumplirse
Acción	Operación ejecutada durante la transición

Un ejemplo básico de tarea podría ser:

[*] -> Pendiente
Pendiente -> EnProgreso : iniciar()
EnProgreso -> Finalizada : completar()
Pendiente -> Cancelada : cancelar()
EnProgreso -> Cancelada : cancelar()
Finalizada -> Archivada : archivar()
Cancelada -> [*]
Archivada -> [*]

Este ejemplo permite ver de forma clara qué estados existen y qué cambios están permitidos.

En mi experiencia, este tipo de diagrama ayuda mucho cuando el alumnado o el equipo empieza a mezclar acciones con estados. “Crear tarea” no es un estado; es una acción. “Pendiente” sí es un estado. Esta diferencia parece pequeña, pero cambia completamente la calidad del modelo.

Ejemplo de pedido, reserva o tarea

Un pedido de tienda online es un ejemplo clásico para entender los diagramas UML de comportamiento orientados a estados.

Podría tener estos estados:

Estado	Descripción
Creado	El cliente ha creado el pedido, pero aún no ha pagado
Pagado	El pago se ha confirmado correctamente
Preparando	El almacén está preparando el pedido
Enviado	El pedido ha salido del almacén
Entregado	El cliente ha recibido el pedido
Cancelado	El pedido se ha cancelado antes de completarse

Y sus transiciones podrían representarse así:

@startuml
[*] --> Creado
Creado --> Pagado : confirmarPago()
Creado --> Cancelado : cancelar()
Pagado --> Preparando : preparar()
Preparando --> Enviado : enviar()
Enviado --> Entregado : confirmarEntrega()
Pagado --> Cancelado : cancelar() [noPreparado]
Cancelado --> [*]
Entregado --> [*]
@enduml

La condición [noPreparado] es una condición de guarda. Indica que esa transición solo puede ocurrir si se cumple una condición concreta. Esto permite representar reglas de negocio sin escribir código detallado.

Este es uno de los motivos por los que los diagramas UML de comportamiento son tan útiles antes de programar. Te obligan a pensar en situaciones límite: qué se puede hacer, qué no se puede hacer y en qué momento.

Errores frecuentes en diagramas de estados

Al trabajar con diagramas de estados, hay algunos errores bastante comunes:

Error	Por qué es un problema	Cómo corregirlo
Confundir estado con acción	Un estado debe ser una situación, no un verbo	Usar “Pendiente” en vez de “Crear tarea”
No incluir estado inicial	No se sabe dónde empieza el ciclo	Añadir [*] al inicio
Permitir transiciones imposibles	El modelo contradice la lógica del negocio	Revisar reglas de transición
Crear demasiados estados	El diagrama se vuelve confuso	Modelar solo estados relevantes
No nombrar eventos	No se sabe qué provoca el cambio	Añadir eventos como pagar(), cancelar(), enviar()

Un buen diagrama de estados no intenta complicar el sistema. Al contrario: intenta hacerlo más claro.

Diagrama de actividades: pasos, decisiones y caminos alternativos

El diagrama de actividades representa un flujo de trabajo. Es parecido a un diagrama de flujo, pero integrado dentro de UML y pensado para modelar procesos de software o de negocio.

Dentro de los diagramas UML de comportamiento, el diagrama de actividades es uno de los más intuitivos. Sirve para responder a preguntas como: qué pasos sigue un proceso, qué decisiones aparecen, qué caminos alternativos existen y dónde empieza o termina el flujo.

Por ejemplo, podemos usarlo para representar un proceso de login, una compra online, una devolución, una solicitud de préstamo digital o la entrega de una tarea en un aula virtual.

Su fuerza está en que no se centra tanto en objetos concretos, sino en acciones y decisiones. Por eso es muy útil cuando queremos explicar el proceso de forma global.

Actividades, decisiones, fork, join y swimlanes

Los elementos más habituales de un diagrama de actividades son:

Elemento	Significado
Nodo inicial	Inicio del flujo
Acción o actividad	Paso que se realiza
Transición	Flecha entre acciones
Decisión	Punto donde el flujo se divide
Unión	Punto donde se reúnen caminos alternativos
Fork	Divide el flujo en acciones paralelas
Join	Une acciones paralelas
Nodo final	Final del proceso
Swimlane	Carril que separa responsabilidades

Las actividades deben escribirse con verbos claros. Por ejemplo: validar formulario, comprobar stock, enviar confirmación, registrar entrega, calcular total.

Evitaría nombres como “formulario”, “stock” o “email”, porque no representan acciones. En los diagramas UML de comportamiento, los nombres deben ayudar a entender qué está ocurriendo.

Un ejemplo simple de login podría ser:

Inicio
  -> Introducir credenciales
  -> Validar campos
  -> ¿Campos completos?
       [no] -> Mostrar error de campos obligatorios -> Fin
       [sí] -> Comprobar usuario y contraseña
  -> ¿Credenciales correctas?
       [sí] -> Crear sesión -> Mostrar panel principal -> Fin
       [no] -> Mostrar error de acceso -> Fin

Este diagrama permite ver el proceso completo, incluyendo decisiones y caminos alternativos.

Diferencia entre diagrama de actividades y diagrama de secuencia

Esta diferencia suele generar dudas, así que merece la pena dejarla clara.

Aspecto	Diagrama de actividades	Diagrama de secuencia
Qué muestra	Pasos de un proceso	Mensajes entre participantes
Foco	Flujo de trabajo	Interacción temporal
Muy útil para	Procesos de negocio y decisiones	Diseño técnico de una operación
Ejemplo	Proceso de compra	Mensajes entre Cliente, PedidoService y PagoService

Si quiero representar los pasos generales de una compra online, usaré un diagrama de actividades. Si quiero representar los mensajes concretos entre objetos durante el pago, usaré un diagrama de secuencia.

Ambos son diagramas UML de comportamiento, pero responden a preguntas distintas.

Ejemplo de proceso de compra online

Un proceso de compra online puede representarse así:

Inicio
  -> Seleccionar productos
  -> Revisar carrito
  -> Confirmar pedido
  -> Calcular total
  -> Solicitar pago
  -> ¿Pago aceptado?
       [sí] -> Registrar pedido
            -> Actualizar stock
            -> Enviar confirmación
            -> Fin
       [no] -> Mostrar error de pago
            -> ¿Reintentar?
                 [sí] -> Solicitar pago
                 [no] -> Cancelar operación -> Fin

Este ejemplo muestra por qué el diagrama de actividades es tan útil. No solo vemos los pasos ideales, sino también qué ocurre cuando algo falla.

En desarrollo real, eso marca la diferencia. Muchas veces diseñamos pensando solo en el camino feliz: el usuario hace todo bien, el pago funciona y el sistema responde perfecto. Pero los sistemas reales tienen errores, excepciones y decisiones. Los diagramas UML de comportamiento nos ayudan a hacer visibles esos caminos antes de que se conviertan en problemas.

Cómo elegir el diagrama UML de comportamiento adecuado

Una misma funcionalidad puede representarse con varios diagramas UML de comportamiento, pero no todos aportan lo mismo.

Por eso, antes de dibujar, conviene hacerse una pregunta muy concreta: ¿qué quiero entender o explicar?

Esta pregunta evita perder tiempo y mejora la comunicación del diseño. No se trata de hacer diagramas por hacer. Un buen diagrama responde a una pregunta concreta y ayuda a tomar decisiones.

Quiero representar…	Diagrama más adecuado	Motivo
Qué funcionalidades tendrá el sistema	Casos de uso	Muestra servicios desde la perspectiva del actor
Cómo se comunican los objetos durante una operación	Secuencia	Muestra mensajes ordenados en el tiempo
Qué objetos colaboran en una operación	Comunicación	Destaca relaciones y mensajes numerados
Los cambios de estado de una entidad	Estados	Representa ciclo de vida y transiciones
Los pasos de un proceso	Actividades	Muestra flujo, decisiones y alternativas

Si quieres saber qué funcionalidades hay

Usa un diagrama de casos de uso.

Es la mejor opción cuando estás en una fase temprana y necesitas entender qué podrá hacer cada actor. Por ejemplo: usuario, administrador, profesor, alumno, bibliotecario, pasarela de pago o sistema de correo.

Este diagrama ayuda a delimitar el alcance. También permite hablar con personas no técnicas sin entrar todavía en clases, métodos o repositorios.

Si quieres ver mensajes entre objetos

Usa un diagrama de secuencia.

Es ideal cuando quieres explicar una operación concreta con cierto detalle técnico. Por ejemplo: login, crear reserva, solicitar préstamo o recuperar contraseña.

Aquí interesa ver quién llama a quién, en qué orden y qué respuestas se producen.

Si quieres representar estados

Usa un diagrama de estados.

Es perfecto para entidades con ciclo de vida claro. Por ejemplo: pedido, reserva, incidencia, matrícula, tarea o préstamo digital.

Este diagrama ayuda a controlar reglas. Qué cambios están permitidos, qué eventos provocan transiciones y qué estados finales existen.

Si quieres explicar un proceso paso a paso

Usa un diagrama de actividades.

Es una gran opción para procesos donde hay decisiones, caminos alternativos o responsabilidades repartidas. Por ejemplo: compra online, devolución, validación, entrega de tarea o creación de incidencia.

Como profesor, me parece uno de los diagramas UML de comportamiento más agradecidos para empezar, porque se entiende rápido y permite detectar pasos mal ordenados o decisiones incompletas.

Herramientas para crear diagramas UML de comportamiento

Los diagramas UML de comportamiento pueden crearse con herramientas gráficas, plugins de un IDE o lenguajes textuales. La elección depende del objetivo: aprender, documentar, trabajar en equipo, generar imágenes o versionar los modelos.

No hay una única herramienta perfecta para todo. Lo importante es que la herramienta no se convierta en el centro del aprendizaje. Primero hay que entender el diagrama; después ya elegiremos con qué dibujarlo.

Algunas opciones habituales son:

Herramienta	Tipo	Ventajas	Limitaciones
Papyrus	Plugin/entorno Eclipse	Enfoque UML completo	Puede ser complejo al principio
PlantUML	Textual	Rápido, versionable y ligero	Requiere aprender sintaxis
StarUML	Gráfica	Interfaz clara orientada a UML	Algunas funciones pueden depender de licencia
Visual Paradigm	CASE completa	Muy potente para modelado profesional	Puede ser excesiva para empezar
diagrams.net	Gráfica general	Sencilla y accesible	No valida UML de forma avanzada

Por qué PlantUML es útil para aprender y documentar

PlantUML permite escribir diagramas como texto. Esto puede parecer menos visual al principio, pero tiene ventajas muy interesantes.

Por ejemplo:

• Se puede guardar junto al código.
• Se puede versionar con Git.
• Permite revisar cambios fácilmente.
• Evita perder demasiado tiempo moviendo cajas y flechas.
• Obliga a entender la estructura del diagrama.
• Genera imágenes a partir de texto.

En mi caso, me gusta especialmente para contextos educativos porque reduce el ruido visual. El alumnado no se queda atascado alineando elementos, sino pensando en actores, mensajes, estados, transiciones o decisiones.

Para los diagramas UML de comportamiento, PlantUML resulta muy práctico porque permite crear rápidamente casos de uso, secuencias, estados y actividades.

Cuándo usar herramientas gráficas

Las herramientas gráficas también tienen mucho sentido, sobre todo cuando queremos trabajar de forma visual, presentar diagramas a otras personas o crear documentación más cuidada.

Por ejemplo, diagrams.net puede ser suficiente para un esquema sencillo. StarUML o Visual Paradigm pueden encajar mejor en un contexto más profesional. Papyrus puede ser interesante si se trabaja dentro del ecosistema Eclipse.

La clave es no perder de vista el objetivo. Una herramienta no arregla un mal modelo. Si el diagrama está mal planteado, da igual que esté hecho con la herramienta más potente del mercado.

Buenas prácticas para crear diagramas UML claros

Los diagramas UML de comportamiento deben ser claros, coherentes y útiles. Si un diagrama complica más de lo que aclara, algo no va bien.

Estas son algunas buenas prácticas que conviene aplicar.

No mezclar niveles de detalle

Uno de los errores más frecuentes es mezclar abstracciones.

Por ejemplo, en un mismo diagrama de actividades no conviene combinar pasos muy generales como “Gestionar pedido” con detalles demasiado concretos como “Comprobar si el campo email contiene @”. El resultado suele ser un diagrama irregular y difícil de leer.

Antes de empezar, decide el nivel de detalle. ¿Quieres explicar el proceso general o una operación concreta? ¿Estás modelando para usuarios, para alumnado o para programadores?

Usar nombres claros

Los nombres deben ayudar a entender.

En casos de uso, actividades y mensajes, conviene usar verbos: iniciar sesión, validar campos, registrar pedido, enviar confirmación, calcular total.

En estados y participantes, suelen funcionar mejor los sustantivos o nombres de situación: Pendiente, En progreso, Finalizada, Cancelada, UsuarioRepository, AuthService.

Esta diferencia ayuda a no confundir acciones con estados.

Evitar diagramas enormes

Un diagrama enorme rara vez es mejor. Puede parecer completo, pero muchas veces es ilegible.

Si un diagrama empieza a tener demasiadas flechas, demasiados actores o demasiadas decisiones, puede ser mejor dividirlo en varios diagramas más pequeños.

Los diagramas UML de comportamiento funcionan mejor cuando responden a una pregunta concreta. Por ejemplo: “¿cómo se crea una reserva?” es mejor que “¿cómo funciona toda la aplicación?”.

Documentar lo que el dibujo no explica

Un diagrama puede ser muy útil, pero no siempre basta por sí solo. En proyectos reales, algunos casos de uso importantes deberían acompañarse de una especificación textual.

Por ejemplo, para el caso de uso “Entregar tarea” podríamos documentar:

Campo	Ejemplo
Nombre	Entregar tarea
Actor principal	Alumno
Objetivo	Permitir que el alumno suba una entrega
Precondiciones	El alumno ha iniciado sesión y la tarea está abierta
Flujo principal	Seleccionar tarea, adjuntar archivo, confirmar entrega
Flujos alternativos	Archivo no válido, plazo cerrado, error de conexión
Postcondiciones	La entrega queda registrada

Esto convierte el diagrama en una herramienta mucho más completa. El dibujo ofrece una visión rápida, y el texto aclara los detalles que no caben bien en el diagrama.

Mantener los diagramas actualizados

Otro error común es crear diagramas al inicio del proyecto y olvidarse de ellos.

Si el sistema cambia, los diagramas también deberían cambiar. De lo contrario, dejan de ser documentación y se convierten en una fuente de confusión.

Aquí PlantUML puede ayudar bastante, porque permite versionar los diagramas junto al código. Si el diagrama está en texto, es más fácil revisarlo, modificarlo y mantenerlo actualizado.

Ejemplo integral: sistema de reservas

Para ver cómo se complementan los diagramas UML de comportamiento, imaginemos un sistema de reservas de salas de estudio.

El sistema permite que los usuarios consulten salas disponibles, creen reservas, cancelen reservas y consulten sus propias reservas. Además, un administrador puede gestionar salas. Una reserva puede estar solicitada, confirmada, cancelada o finalizada. Para crear una reserva, el sistema comprueba disponibilidad, registra la reserva y envía una confirmación.

Este mismo sistema puede representarse desde distintas perspectivas.

Casos de uso del sistema de reservas

El diagrama de casos de uso mostraría qué puede hacer cada actor.

Actor: Usuario
- Consultar salas
- Crear reserva
- Cancelar reserva
- Consultar mis reservas

Actor: Administrador
- Gestionar salas

Relaciones:
- Crear reserva incluye comprobar disponibilidad
- Crear reserva incluye enviar confirmación

Aquí vemos el alcance funcional del sistema.

Secuencia para crear una reserva

El diagrama de secuencia mostraría qué componentes colaboran cuando el usuario crea una reserva.

@startuml
actor Usuario
participant ReservaController
participant ReservaService
participant SalaRepository
participant ReservaRepository
participant EmailService

Usuario -> ReservaController: solicitarReserva(sala, fecha, hora)
ReservaController -> ReservaService: crearReserva(datos)
ReservaService -> SalaRepository: comprobarDisponibilidad(sala, fecha, hora)
SalaRepository --> ReservaService: disponible

alt sala disponible
  ReservaService -> ReservaRepository: guardar(reserva)
  ReservaService -> EmailService: enviarConfirmacion(reserva)
  ReservaService --> ReservaController: reservaConfirmada
  ReservaController --> Usuario: mostrarConfirmacion()
else sala no disponible
  ReservaService --> ReservaController: errorDisponibilidad
  ReservaController --> Usuario: mostrarError()
end
@enduml

Aquí vemos la colaboración técnica.

Estados de una reserva

El diagrama de estados mostraría el ciclo de vida de la reserva.

@startuml
[*] --> Solicitada
Solicitada --> Confirmada : confirmar()
Solicitada --> Cancelada : cancelar()
Confirmada --> Cancelada : cancelar()
Confirmada --> Finalizada : cumplirFecha()
Cancelada --> [*]
Finalizada --> [*]
@enduml

Aquí vemos qué estados existen y qué transiciones están permitidas.

Actividades para crear una reserva

El diagrama de actividades mostraría el flujo del proceso.

@startuml
start
:Seleccionar sala;
:Seleccionar fecha y hora;
:Comprobar disponibilidad;
if (¿Disponible?) then (sí)
  :Registrar reserva;
  :Enviar confirmación;
  :Mostrar reserva confirmada;
else (no)
  :Mostrar mensaje de no disponibilidad;
endif
stop
@enduml

Aquí vemos los pasos, la decisión principal y los caminos posibles.

Este ejemplo resume muy bien el valor de los diagramas UML de comportamiento: cada uno cuenta una parte distinta del mismo sistema. Ninguno lo explica todo, pero juntos ofrecen una visión mucho más completa.

Conclusión: UML no va de dibujar, va de entender mejor el sistema

Los diagramas UML de comportamiento permiten representar lo que ocurre dentro de un sistema cuando se usa. Nos ayudan a explicar funcionalidades, interacciones, estados, decisiones y procesos.

El diagrama de casos de uso define qué puede hacer cada actor. El diagrama de secuencia muestra mensajes ordenados en el tiempo. El diagrama de comunicación destaca la colaboración entre objetos. El diagrama de estados describe el ciclo de vida de una entidad. Y el diagrama de actividades representa pasos, decisiones y caminos alternativos.

Pero lo más importante no es memorizar símbolos. Lo realmente útil es saber elegir el diagrama adecuado.

En mi experiencia, tanto en desarrollo como en docencia, UML empieza a tener sentido cuando dejamos de verlo como una obligación y empezamos a usarlo como una herramienta para pensar. Un buen diagrama aclara. Un mal diagrama decora. Y en software, aclarar antes de construir ahorra mucho trabajo después.

Por eso, si estás aprendiendo análisis y diseño de software, no intentes hacer todos los diagramas UML de comportamiento a la vez. Empieza por la pregunta: qué quiero entender. Después elige el diagrama que mejor responda.

Preguntas frecuentes sobre diagramas UML de comportamiento

¿Qué son los diagramas UML de comportamiento?

Los diagramas UML de comportamiento son diagramas que representan lo que ocurre cuando un sistema se usa. Muestran funcionalidades, interacciones, estados, procesos, decisiones y flujos de trabajo.

¿Qué diferencia hay entre un diagrama de clases y un diagrama de comportamiento?

Un diagrama de clases muestra la estructura del sistema: clases, atributos, métodos y relaciones. Los diagramas UML de comportamiento muestran cómo funciona el sistema durante su uso.

¿Cuáles son los principales diagramas UML de comportamiento?

Los principales diagramas UML de comportamiento son el diagrama de casos de uso, el diagrama de secuencia, el diagrama de comunicación, el diagrama de estados y el diagrama de actividades.

¿Cuándo usar un diagrama de casos de uso?

Conviene usar un diagrama de casos de uso cuando queremos representar qué funcionalidades ofrece el sistema a cada actor externo. Es muy útil al inicio del análisis.

¿Cuándo usar un diagrama de secuencia?

Conviene usar un diagrama de secuencia cuando queremos mostrar los mensajes entre participantes en una operación concreta y en orden temporal.

¿Qué diferencia hay entre diagrama de secuencia y diagrama de comunicación?

El diagrama de secuencia se centra en el orden temporal de los mensajes. El diagrama de comunicación se centra en qué objetos colaboran y cómo se conectan mediante mensajes numerados.

¿Cuándo usar un diagrama de estados?

Conviene usar un diagrama de estados cuando una entidad tiene un ciclo de vida claro, con estados y transiciones. Por ejemplo: pedido, reserva, incidencia, matrícula o préstamo.

¿Cuándo usar un diagrama de actividades?

Conviene usar un diagrama de actividades cuando queremos representar los pasos de un proceso, incluyendo decisiones, caminos alternativos o responsabilidades.

¿PlantUML sirve para crear diagramas UML de comportamiento?

Sí. PlantUML permite crear diagramas UML de comportamiento mediante texto. Es útil para casos de uso, secuencia, estados y actividades, y facilita versionar los diagramas junto al código.

¿Cuál es el error más común al crear diagramas UML de comportamiento?

Uno de los errores más comunes es hacer diagramas demasiado grandes o mezclar niveles de detalle. Un buen diagrama debe responder a una pregunta concreta y ser fácil de entender.