¿Qué es UML?

UML es un lenguaje visual para describir sistemas de software. Te da un conjunto fijo de formas, líneas y reglas para que un diagrama que dibujes signifique lo mismo para alguien que no estuvo en la sala donde se trazó.

Esa es toda la propuesta de valor, y conviene decirlo sin rodeos. Una caja con un nombre dentro no es UML. Una caja con tres compartimentos, un triángulo hueco apuntando a otra caja y un 1..* en un extremo de una línea sí es UML, y dice algo preciso: este tipo hereda de aquel, y una instancia del primero está asociada al menos con una del segundo. Cualquiera que conozca la notación lo lee de forma idéntica. Eso es lo que estás comprando.

El lenguaje lo mantiene el Object Management Group. La versión actual es UML 2.5.1, publicada en 2017. Desciende del trabajo que Grady Booch, James Rumbaugh e Ivar Jacobson fusionaron en Rational a mediados de los noventa, cuando el campo tenía unas cincuenta notaciones rivales y ninguna forma de leer el diseño ajeno. El OMG adoptó UML 1.1 en 1997. La versión 2.5 fue sobre todo una limpieza: la especificación se había partido en los volúmenes «infrastructure» y «superstructure», por los que pocos sabían moverse, y 2.5 los plegó de nuevo en un solo documento.

Cada diagrama UML responde a una de dos preguntas. Los diagramas de estructuraresponden a «¿de qué está hecho este sistema?»: las partes, los tipos, las máquinas y cómo están dispuestos. Describen cosas que son ciertas al margen del tiempo.

Los diagramas de comportamientoresponden a «¿qué hace este sistema?»: los flujos, los mensajes, los estados y el orden en que ocurren las cosas. Describen cosas que solo son ciertas en un instante.

Un diagrama de clases te dice que un Payment tiene un importe y un estado. Una máquina de estados te dice que un pago pasa de Authorized a Captured pero nunca al revés. Ninguno puede expresar lo del otro, y la mayoría de las preguntas reales necesitan uno de cada. Si te descubres intentando mostrar una secuencia en un diagrama de clases, esa es la señal de dibujar un segundo diagrama en vez de sobrecargar el primero.

El comportamiento tiene un nivel extra de anidamiento. Cuatro de los siete diagramas de comportamiento (secuencia, comunicación, tiempos y global de interacciones) son todos diagramas de interacción, cuatro representaciones distintas de la misma idea de fondo: participantes que intercambian mensajes. En principio son intercambiables. En la práctica dominan los de secuencia, porque un eje temporal vertical es lo más fácil de leer del mundo.

Aquí está el lenguaje entero, al nivel de «¿necesito esto hoy?». Sigue el enlace cuando la respuesta sea sí.

En la práctica, una mayoría holgada del UML real son cuatro de ellos: clases, secuencia, casos de uso y actividades. Los otros diez existen porque alguien los necesitó, y tres o cuatro son realmente excelentes cuando la situación lo pide: una máquina de estados para un ciclo de vida, un diagrama de despliegue para una revisión de infraestructura. El resto puedes leerlos cuando te los encuentres y no dibujarlos nunca.

Parte de la pregunta, no del diagrama. El error es elegir primero un tipo de diagrama y luego decidir qué poner en él: así se acaba con un diagrama de clases de doscientas cajas que nadie ha leído jamás.

• «¿Quién usa esto y para qué?» - diagrama de casos de uso. Alcance y actores, antes de que exista diseño alguno.
• «¿Cuáles son los conceptos y cómo se relacionan?» - diagrama de clases. La vista estructural por defecto.
• «¿Qué pasa cuando alguien pulsa pagar?» - diagrama de secuencia. El orden de los mensajes entre participantes.
• «¿Cuál es el proceso, con sus ramas?» - diagrama de actividades. Flujo con decisiones y paralelismo.
• «¿En qué estados puede estar esto?» - diagrama de máquina de estados. Ciclo de vida y transiciones legales.
• «¿Qué se ejecuta dónde?» - diagrama de despliegue. Nodos, artefactos, entornos.
• «¿Cuáles son los servicios y sus contratos?» - diagrama de componentes. Interfaces ofrecidas y requeridas.
• «¿Cómo está organizado el código?» - diagrama de paquetes. Agrupación y dependencias permitidas.

No es un proceso. UML no dice nada sobre cuándo modelar, cuánto modelar ni quién lo aprueba. Es una notación. Métodos como RUP se construyeron a su alrededor y se confunden a menudo con él; puedes usar UML en cualquier proceso, incluido ninguno.

No es un lenguaje de programación. Los modelos UML pueden ser lo bastante detallados como para generar código, y algunas herramientas hacen exactamente eso. La mayoría de los equipos no lo hacen, y no deberían. La generación de código de ida y vuelta completa es el motivo aislado más común por el que se hunden los esfuerzos de UML: el modelo se convierte en una segunda copia, peor, del fuente, que nadie actualiza.

No es todo o nada. No hay obligación de usar los catorce diagramas ni de modelar cada clase. Dibujar un solo diagrama de secuencia para zanjar una discusión sobre quién llama a quién es un uso completamente legítimo de UML, y probablemente el más valioso.

No es lo mismo que ArchiMate. Ambos son lenguajes de modelado y se solapan lo bastante como para confundir. UML modela software: clases, componentes, mensajes. ArchiMate modela la empresa que lo rodea: procesos de negocio, capacidades, capas de aplicación y tecnología. Una organización grande normalmente necesita los dos, a distintas alturas.

La respuesta honesta es: bastante menos de lo que anima a hacer la herramienta. Un modelo se gana su sitio cuando se lee más a menudo de lo que se edita. Tres cosas lo consiguen de forma fiable.

Modela las partes que cuesta sostener en la cabeza. La máquina de estados del pago, con nueve estados y dos transiciones ilegales, merece un diagrama. El DTO de tres campos no.

Modela a una sola altura por diagrama. El fallo más común en un diagrama de clases real es mezclar conceptos del dominio con fontanería del framework en el mismo lienzo. Dos diagramas, cada uno coherente por dentro, ganan a uno técnicamente completo.

Modela lo que vas a conservar. Un diagrama en una presentación es un dibujo con una caducidad de una reunión, y eso está bien mientras sepas que es eso. Un diagrama en el repositorio, junto al código que describe, es un modelo, y necesita alguien que lo cuide.

Si la notación es nueva para ti, lee primero el artículo del diagrama de clases. Carga con la mayor parte del vocabulario de UML (generalización, asociación, multiplicidad, composición) y todos los demás diagramas de estructura reutilizan esas marcas. Después lee el artículo del diagrama de secuencia, que hace el mismo trabajo para el comportamiento.

Esos dos cubren la mayor parte de lo que te pedirán leer alguna vez. Todo lo demás de esta serie está escrito para cogerlo el día que lo necesites, en cualquier orden, y cada artículo solo da por supuestos esos dos.