Diagramas de componentes UML

Un diagrama de componentes describe un sistema como piezas reemplazables. Un componente en UML no es una clase cualquiera: es una unidad con frontera definida que, en principio, podría cambiarse por otra implementación de los mismos contratos sin que nada a su alrededor se entere.

Todo el valor está en esa definición. El diagrama te obliga a anotar, por cada pieza, exactamente dos cosas: qué proporciona y qué requiere. Esas dos listas son el contrato de la pieza con el resto del sistema, y son justo lo que necesitas al planificar una migración, dimensionar una reescritura o decidir si una frontera de servicio está en el sitio correcto.

La forma de bola y zócalo (ball and socket) es la compacta y la que la mayoría de herramientas dibuja por defecto: una piruleta que sale de un componente es una interfaz que proporciona, media copa es una que requiere, y una bola descansando en un zócalo son las dos conectadas. Es la misma información que las flechas de arriba, en menos espacio. Usa la que a tus lectores les resulte más fácil; sé coherente dentro de un diagrama.

Cada marca que este tipo de diagrama puede llevar -ambas notaciones de interfaz, los conectores de ensamblaje y delegación, los puertos y los cuatro estereotipos que merecen escribirse- está recogida en los símbolos del diagrama de componentes.

Es la pregunta en la que se atasca todo primer diagrama de componentes, y la especificación no ayuda: UML dice que un componente es una unidad reemplazable con un contrato definido y deja el tamaño enteramente en tus manos. Para una norma es la respuesta correcta y ante una pizarra es inútil, así que aquí está la regla de trabajo.

Un componente es aquello que podrías sacar a concurso. Si puedes imaginarte entregando a otro equipo las listas de interfaces proporcionadas y requeridas y diciendo «construid esto, no miraremos dentro», es un componente. Si esa entrega exigiera una conversación sobre las tripas, la frontera está dibujada en el sitio equivocado, y ese es el hallazgo, no un problema de dibujo que haya que sortear.

En la práctica suele caer en uno de estos niveles, y en cuál caiga te dice para qué sirve el diagrama.

• Un servicio desplegable. Un repositorio, un pipeline, una guardia. La respuesta más común en cualquier cosa construida en la última década y el nivel al que merece la pena mantener el diagrama en el repositorio.
• Una biblioteca o módulo. Dentro de un desplegable, cuando la discusión va de estructura interna: qué paquete puede depender de cuál. Aquí un diagrama de paquetes suele decir lo mismo más barato.
• Un sistema entero. El mainframe, el CRM, el proveedor de pagos. El nivel del diagrama de contexto, donde lo que importa es de qué dependes y no cómo está construido.

Mezclar dos de esos niveles en un diagrama es el error que produce esos diagramas de componentes desbordados que la gente recuerda. Una imagen con tres microservicios, una biblioteca de utilidades y «SAP» son tres diagramas superpuestos, y ningún lector puede saber qué cajas son pares.

La técnica de lectura más útil es tapar un componente con la mano. Lo que queda es su contrato: las interfaces que estaban conectadas a él. Si puedes entregar esa lista a otro equipo y decir «construid algo que satisfaga esto», el diagrama está haciendo su trabajo. Si no puedes -si reemplazar el componente exigiera conocer cosas que no están dibujadas- la frontera está en el sitio equivocado, y conviene saberlo antes de que alguien lo intente.

La segunda técnica es seguir las interfaces requeridas. Cada una es una dependencia que alguien tiene que satisfacer, y un ciclo en ese grafo es un problema arquitectónico real que un diagrama de componentes hace visible de inmediato.

Ambas técnicas se ven mejor aplicadas que descritas. Cinco diagramas de sistemas en los que probablemente hayas trabajado -un catálogo compartido, puertos y adaptadores, la sustitución de un sistema heredado, un anfitrión de plugins y un ciclo- se recorren en los ejemplos de diagramas de componentes, cada uno con la discusión que zanja.

Cinco tipos de diagrama son rectángulos unidos por líneas, y toda la diferencia está en qué es un rectángulo. Elegir el equivocado es el error más caro disponible aquí, porque el diagrama parecerá correcto y responderá a una pregunta que nadie hizo.

La duda que más aparece es componentes frente a despliegue, y la separación es limpia una vez dicha: un componente es una unidad lógica y un nodo una física. Un componente puede correr en cuarenta nodos; un nodo puede alojar una docena de componentes. En cuanto una caja de tu diagrama de componentes adquiere una región, un número de instancias o un nombre de host, ha dejado de ser un componente y el diagrama se ha convertido calladamente en dos.

Si conoces C4, su diagrama de contenedores cae casi exactamente donde un diagrama de componentes al nivel de servicio desplegable, y su propio nivel de «componentes» está un paso más adentro de lo que UML suele entender. Los vocabularios no encajan, así que escribe en el diagrama cuál usas: esa línea de leyenda evita la mayoría de las discusiones.

Los diagramas de componentes envejecen bien, lo cual es inusual. Las interfaces cambian mucho más despacio que el código que hay detrás, así que un diagrama de componentes versionado sigue siendo cierto mucho más tiempo que un diagrama de clases del mismo sistema, y en consecuencia merece más la pena mantenerlo.

1. Componentes que en realidad son clases. Si no puede reemplazarse de forma independiente de manera plausible, no es un componente. Usa un diagrama de clases.
2. Dibujar solo las interfaces proporcionadas. Las requeridas llevan la información de dependencia, que es la mitad más útil.
3. Flechas entre componentes sin interfaz. Una flecha desnuda dice «depende de algún modo», que es justo lo que este diagrama existe para precisar.
4. Mezclar despliegue. Servidores, regiones y contenedores pertenecen a un diagrama de despliegue.
5. Interfaces nombradas según el proveedor. ILedger está bien mientras haya un solo libro mayor; cuando puede haber dos implementaciones, nombra el contrato por la capacidad, no por el proveedor actual.