UML tiene fama de pesado, pero la mayoría de los ingenieros sigue recurriendo a él cuando necesita ser preciso: un diagrama de clases para fijar un modelo, un diagrama de secuencia para clavar una interacción, una máquina de estados para hacer explícitas las transiciones. El problema nunca fue UML. Era el dibujo. Colocar a mano una docena de clases con sus campos y relaciones es exactamente el tipo de trabajo minucioso y mecánico que nadie quiere hacer dos veces.
Eso lo convierte en un encaje casi perfecto para la IA. La estructura está bien definida, la notación es estándar y el diseño se basa en reglas. Tú aportas la intención; la herramienta se encarga de colocar.
Dos formas de empezar: descríbelo o apunta al código
Hay dos puntos de partida honestos para un diagrama UML generado con IA, y cada uno encaja en un momento distinto.
- Desde una descripción, cuando el diseño aún está en tu cabeza. "Un User tiene muchos Orders; cada Order tiene Line Items; un Line Item hace referencia a un Product." Estás esbozando el modelo en voz alta y quieres verlo.
- Desde código o un esquema existentes, cuando el diseño ya existe y quieres la imagen. Tus clases, tus tablas SQL y tus tipos ya codifican las relaciones. Generar a partir de ellos significa que el diagrama coincide con la realidad y no con tu recuerdo de ella.
La segunda es el superpoder discreto. Un diagrama de clases derivado de los tipos reales no puede mentir sobre los campos, y un modelo de estilo ER generado a partir de DDL real no puede inventarse una relación que no existe.
Un diagrama de clases a partir de una frase
Supón que describes un pequeño modelo de pedidos. El diagrama generado te da cajas reales: cada clase con sus atributos, y las asociaciones dibujadas con la multiplicidad adecuada, no simples líneas.
Diagramas de secuencia: la interacción, no los objetos
Los diagramas de clases muestran estructura; los de secuencia muestran comportamiento a lo largo del tiempo. Son aún más tediosos de dibujar a mano, porque cada mensaje es una flecha colocada con precisión entre líneas de vida. Describe el flujo en su lugar: "El cliente llama a la API, que consulta la caché, no encuentra el dato, consulta la base de datos, escribe en la caché y responde." Obtienes líneas de vida y mensajes ordenados que luego puedes recortar y anotar.
La notación es estándar y el diseño se basa en reglas. Precisamente por eso una máquina puede hacer el borrador y tú puedes confiar en que sabrás corregirlo.
Mantenlo fiel: genera a partir de lo real
El UML más duradero no se dibuja desde la imaginación; se deriva de lo que ya existe. Si tus modelos cambian, un diagrama dibujado a mano se queda atrás. Generar el diagrama de clases a partir de tus tipos reales, o un modelo de datos a partir de tu esquema real, significa que la imagen se actualiza cuando lo hace el código. Regenera en lugar de redibujar, y el diagrama deja de ser una pieza de museo.
Después hazlo legible, porque UML puede volverse denso
Un UML completo puede convertirse rápidamente en un muro de cajas. La ventaja de un resultado editable es que puedes podarlo hasta lo que realmente quieres transmitir. Oculta los atributos que no importan para este diagrama. Agrupa las clases de un mismo agregado. Resalta la relación en la que el lector tiene que fijarse. Un diagrama que dice una cosa con claridad es mejor que uno completo que nadie lee.
Genera la estructura, corrige los detalles, recórtalo hasta el mensaje y exporta una versión que dure. UML deja de ser una tarea pesada y vuelve a ser aquello para lo que existía: una imagen precisa y compartida de cómo está montado el sistema.