Los diagramas UML que los arquitectos todavía usan

Qué es UML y en qué punto está hoy

El Lenguaje Unificado de Modelado (UML) es un lenguaje gráfico de propósito general para describir la estructura y el comportamiento del software. Surgió de la fusión, en Rational Software a mediados de la década de 1990, de los métodos de Grady Booch, James Rumbaugh e Ivar Jacobson, y lo adoptó como estándar el Object Management Group (OMG), un consorcio de estándares del sector, en 1997. UML 2.0 (2005) fue una revisión importante. La versión actual es UML 2.5.1, publicada por el OMG en diciembre de 2017; la anterior, UML 2.4.1, también la publicó ISO como ISO/IEC 19505 (2012). La especificación define catorce tipos de diagrama, divididos en diagramas de estructura (como los de clases, componentes y despliegue) y diagramas de comportamiento (como los de actividades, máquina de estados y secuencia).

La reputación de UML ha cambiado considerablemente. A finales de la década de 1990 y principios de la de 2000 se promovió como la base del desarrollo dirigido por modelos, en el que modelos detallados se transformarían en código. Esa ambición fracasó en gran medida fuera de los dominios especializados, y muchos equipos asocian UML con procesos pesados y diagramas que nadie leía. Cuando Marian Petre entrevistó a 50 desarrolladores de software profesionales para un estudio presentado en ICSE 2013, 35 dijeron que no usaban UML en absoluto y la mayoría de los demás lo usaban de forma selectiva e informal; la mayoría de los equipos dibujan cajas y líneas informales en lugar de UML estricto. Aun así, un puñado de tipos de diagrama UML siguen siendo las mejores herramientas disponibles para ciertas preguntas, sobre todo las relativas al comportamiento a lo largo del tiempo, y su notación se entiende ampliamente. Un arquitecto no necesita los catorce tipos de diagrama; necesita quizá seis, usados de forma deliberada.

Esta sección trata esos seis, cada uno con un pequeño ejemplo de la plataforma de reparto de comida que se usa a lo largo de este capítulo. Da por sabido el vocabulario de C4 de la Sección 4.3; los dos se combinan bien, con C4 para la visión general de la estructura y UML donde la precisión sobre interfaces, interacciones o estados compensa su costo.

Boceto, plano o lenguaje de programación

UML Distilled de Martin Fowler (3.ª edición, Addison-Wesley, 2003) y sus ensayos del mismo año distinguen tres formas de usar UML, una clasificación a la que Steve Mellor llegó de manera independiente. Como boceto, UML se usa de forma informal y selectiva para comunicar ideas: en una pizarra antes de escribir código (boceto hacia delante) o para explicar parte de un sistema existente (boceto inverso). Solo aparecen los elementos importantes, la notación se sigue con flexibilidad y el diagrama a menudo se tira. El propio resumen de Fowler es la exhaustividad es enemiga de la comprensibilidad.

Como plano, UML se usa para producir modelos completos y precisos que otra persona implementa, o que se generan a partir del código existente para documentarlo por completo; lo que importa es la completitud, y normalmente hacen falta herramientas. Como lenguaje de programación, el modelo UML es lo bastante detallado para compilarse en código ejecutable, el objetivo de la arquitectura dirigida por modelos (MDA). Este modo sobrevive en algunos nichos embebidos y críticos para la seguridad (safety), a menudo mediante perfiles y herramientas especializados, pero no se ha generalizado.

Para los arquitectos, el modo boceto es el predeterminado y el modo plano, la excepción. La pregunta útil para cada diagrama es: ¿quién lo leerá y qué decisión o comprensión respalda? Un diagrama de secuencia esbozado para acordar cómo se gestionan los fallos de pago es valioso aunque ignore la mitad de la notación. Un modelo de clases completo de un servicio de 200 clases, mantenido a mano, normalmente no lo es.

Diagramas de componentes: las partes y sus interfaces

Un diagrama de componentes UML muestra las partes modulares de un sistema y, sobre todo, sus interfaces. Su notación característica es la de "bola y enchufe": un pequeño círculo sobre un palo (una interfaz proporcionada, que el componente ofrece) y un semicírculo (una interfaz requerida, que necesita que otro le proporcione). Cuando una bola encaja en un enchufe, los dos componentes quedan conectados a través de esa interfaz. Las dependencias son flechas discontinuas, que pueden llevar opcionalmente un estereotipo como «use».

Esto es exactamente lo que les importa a los arquitectos cuando quieren mostrar la dirección de las dependencias y la sustituibilidad. En el ejemplo, el componente de pedidos no depende directamente del proveedor de pagos; requiere una interfaz PaymentPort, que implementa un adaptador de pagos aparte. Es la inversión de dependencias y el enfoque de puertos y adaptadores del Capítulo 3 hechos visibles: cambiar de proveedor de pagos significa escribir un adaptador nuevo, no modificar el componente de pedidos. Un diagrama de componentes C4 puede mostrar las mismas partes, pero no distingue las interfaces proporcionadas de las requeridas.

Diagramas de despliegue: nodos y artefactos

Un diagrama de despliegue UML muestra la infraestructura física o virtual y lo que se ejecuta en ella. Sus elementos son los nodos, dibujados como cajas tridimensionales, que son recursos de cómputo: un «device», como un teléfono o un servidor, o un «executionEnvironment», como un sistema operativo, un entorno de ejecución de contenedores o un clúster de Kubernetes; los nodos pueden anidarse. Los artefactos, dibujados como rectángulos con un icono de documento y el estereotipo «artifact», son los archivos físicos que se despliegan: un JAR, una imagen de contenedor, un paquete de app móvil, un archivo de configuración. Las líneas entre nodos son vías de comunicación, etiquetadas con protocolos.

Los diagramas de despliegue son vistas de asignación en los términos del SEI (Sección 4.2). Responden a las preguntas del equipo de operaciones: dónde se ejecuta cada parte, cuántas copias hay, en qué región, qué rutas de red existen. El diagrama de despliegue de C4 cubre el mismo terreno con una notación menos formal; cualquiera de los dos sirve, siempre que haya uno por cada entorno importante y muestre las réplicas, los servicios gestionados y los límites de red.

Diagramas de secuencia: quién llama a quién y en qué orden

Si los arquitectos se quedan con un solo diagrama UML, suele ser el diagrama de secuencia. Muestra cómo interactúan los participantes a lo largo del tiempo en un escenario. Los participantes aparecen en la parte superior, cada uno con una línea de vida vertical discontinua; el tiempo avanza hacia abajo. Un rectángulo estrecho sobre una línea de vida, la activación (especificación de ejecución), muestra cuándo ese participante está ocupado atendiendo un mensaje.

Las puntas de flecha tienen significado. Un mensaje síncrono, en el que el emisor espera una respuesta, tiene una línea continua y una punta de flecha rellena. Una respuesta (retorno) tiene una línea discontinua y una punta abierta. Un mensaje asíncrono, en el que el emisor sigue adelante sin esperar, tiene una línea continua y una punta abierta. Acertar con esto importa para la arquitectura: que el servicio de pedidos espere al proveedor de pagos o que publique y siga adelante determina su latencia, sus modos de fallo y su acoplamiento (consulta la Sección 0.6).

Los fragmentos combinados añaden flujo de control: una caja con la etiqueta alt y secciones con guarda separadas por una línea discontinua muestra alternativas (if/else), opt muestra una parte opcional, loop una repetición y par secciones en paralelo. Úsalos con moderación; un diagrama de secuencia con bucles y alternativas anidados es código mal dibujado. Dibuja un diagrama por cada escenario importante, incluidos los escenarios de fallo, que es donde ocurre la mayor parte del razonamiento arquitectónico.

Diagramas de máquina de estados: ciclos de vida y reglas

Muchos objetos de negocio tienen un ciclo de vida: un pedido, un pago, una suscripción, un siniestro de seguros. Un diagrama de máquina de estados lo describe con precisión. Los estados son rectángulos redondeados; un círculo relleno marca el pseudoestado inicial y una diana el estado final. Las transiciones son flechas con la etiqueta event [guard] / action: el evento que desencadena la transición, una condición de guarda opcional que debe cumplirse y una acción opcional que se realiza por el camino. Los estados pueden tener comportamientos internos como entry / notify restaurant.

Las máquinas de estados son arquitectónicas más a menudo de lo que se cree. El ciclo de vida del pedido de abajo lo comparten varios servicios: pedidos es su dueño, despacho y notificaciones reaccionan a sus transiciones y el personal de soporte puede desencadenar algunas de ellas. Acordar los estados y las transiciones válidas, en un solo diagrama, evita toda una clase de bugs en los que un servicio cree que un pedido está cancelado mientras otro envía a un repartidor. El diagrama también saca a la luz preguntas que el texto oculta: ¿se puede cancelar un pedido cuando ya está en reparto? (Aquí, no: no hay ninguna transición desde ese estado a Cancelado.) ¿Un reembolso es una acción de una transición o un ciclo de vida aparte?

Diagramas de actividades: flujos de trabajo y paralelismo

Un diagrama de actividades es un diagrama de flujo con una semántica precisa. Los rectángulos redondeados son acciones; los rombos son decisiones (con guardas en los flujos de salida) y fusiones; las barras gruesas son bifurcaciones, que dividen un flujo en flujos paralelos, y uniones, que esperan a todos los flujos de entrada antes de continuar. Las particiones, a menudo llamadas calles (swimlanes), muestran quién o qué realiza cada acción. Un bucle debe volver a través de un rombo de fusión: dos flujos que entraran directamente en una misma acción significarían que la acción espera a ambos, como una unión.

Los arquitectos usan los diagramas de actividades para procesos de negocio y flujos de trabajo que abarcan varias partes de un sistema, sobre todo cuando importan el paralelismo y las responsabilidades. El ejemplo muestra que la preparación de la comida y la asignación del repartidor se ejecutan en paralelo, que la asignación se repite en bucle hasta que un repartidor acepta y que la entrega espera a ambas. Eso plantea de inmediato una pregunta arquitectónica: ¿y si ningún repartidor acepta en veinte minutos mientras la comida ya está lista? El diagrama hace visible el hueco; la respuesta podría ser una transición por timeout, un paso de compensación o un cambio en el ciclo de vida del pedido. Los flujos de trabajo de larga duración de este tipo suelen implementarse como sagas o flujos orquestados, que se tratan en el Capítulo 6.

Diagramas de clases, con moderación: el modelo de dominio

El diagrama de clases es el diagrama UML más conocido y el que los arquitectos deberían usar con más moderación. Dibujar a mano todas las clases de un servicio es el modo plano en su versión menos útil: queda desactualizado en semanas y el código dice lo mismo con más precisión. Donde los diagramas de clases se ganan su sitio es en el modelo de dominio: un diagrama pequeño de los conceptos de negocio clave, sus atributos y sus relaciones, que desarrolladores, responsables de producto y expertos del dominio pueden discutir juntos. En términos de diseño guiado por el dominio (Capítulo 5), recoge el lenguaje ubicuo de un contexto delimitado.

Lo esencial es poco. Una caja de clase tiene un nombre, atributos y, opcionalmente, operaciones. Una línea simple es una asociación, con nombre opcional y con multiplicidades en cada extremo (1, 0..1, 0..*, 1..*). Un rombo relleno marca la composición: las partes pertenecen exactamente a un todo y no le sobreviven, como las líneas de pedido pertenecen a un pedido. Un triángulo hueco marca la generalización (herencia) y una línea discontinua con punta abierta, una dependencia. Las multiplicidades encierran decisiones de diseño reales: Order 1 to 0..1 Delivery dice que un pedido tiene como mucho una entrega, lo que descarta repartir un pedido grande entre dos repartidores. Si el negocio pudiera querer eso, el diagrama es donde aflora la pregunta.

Cuándo UML es excesivo y cuándo importa la precisión

UML es excesivo cuando el público no lo conoce y la pregunta no lo necesita: un diagrama de contexto C4 comunica mejor con los directivos que un diagrama de casos de uso UML, y un boceto en la pizarra es la herramienta adecuada para una discusión de diseño que habrá terminado en una hora. Es excesivo cuando se mantienen a mano diagramas que podrían generarse y cuando se impone una notación estricta en un boceto cuyo propósito es explorar. La observación de Fowler de que la precisión añadida en UML 2 sirve sobre todo a quienes lo usan como plano y como lenguaje de programación, y supone una carga para quienes hacen bocetos, sigue siendo válida.

La precisión compensa cuando un malentendido sale caro. Las interfaces entre empresas son el caso más claro: cuando la empresa de reparto de comida se integra con un proveedor de pagos o con el sistema de pedidos de una gran cadena de restaurantes, cada parte construye a partir de la descripción de la otra y solo descubre los desajustes en las pruebas o en producción. Un diagrama de secuencia preciso del flujo de pago, con timeouts, reintentos, claves de idempotencia y webhooks, adjunto a la especificación de la interfaz, es un seguro barato. Las industrias reguladas y críticas para la seguridad (safety) (dispositivos médicos, ferrocarril, aviación, automoción, algunos sistemas financieros) a menudo exigen documentación de diseño que los auditores puedan rastrear desde los requisitos hasta la implementación; allí es habitual el UML formal o su pariente de la ingeniería de sistemas, SysML. Las reglas de concurrencia y de ciclo de vida que comparten varios equipos, como los estados del pedido de antes, se benefician de una notación que obliga a declarar cada transición. Y el desarrollo externalizado o distribuido, en el que quienes implementan un diseño no pueden preguntar fácilmente a su autor, necesita descripciones que dejen menos margen a la interpretación.