Ejemplos de diagramas de componentes

Todos los diagramas de abajo usan las mismas tres marcas, y si sabes leerlas puedes leer los cinco: un componente es una caja con el icono de enchufe, una «interface» es una caja que nombra un contrato, y las flechas dicen de qué lado de ese contrato está cada componente. Una flecha discontinua con triángulo hueco significa esto lo implemento. Una flecha discontinua simple significa esto lo necesito. El juego completo está en los símbolos del diagrama de componentes, y el razonamiento tras la notación en la guía del diagrama de componentes.

Están ordenados por la frecuencia con que aparece la forma y no por complejidad. Cada uno nombra la pregunta que zanja, porque un diagrama de componentes que no zanja nada es el tipo más común y el menos útil: cinco cajas, cinco flechas y ninguna afirmación con la que alguien pueda discrepar.

La figura de la cabecera de este artículo. Una tienda web y una aplicación móvil necesitan datos de producto; un servicio de catálogo los proporciona. La interfaz se dibuja una vez, entre ambos.

Esa única caja es todo el sentido del ejemplo. Antes de que existiera, los dos clientes tenían dos ideas distintas de lo que devuelve «el catálogo», y la diferencia vivía en el que se escribió en segundo lugar. Nombrar ICatalog obliga a plantear qué es realmente el contrato, y una vez nombrado, un cambio en él es visiblemente un cambio para dos consumidores en vez de una edición de un servicio.

Lee las flechas y fíjate en lo que el núcleo de pedidos no toca. No depende de HTTP y no depende de PostgreSQL. Realiza un contrato y requiere otro, y ambos son cajas que podría haberle pasado cualquiera.

Esta es la forma que la gente quiere decir con arquitectura hexagonal, puertos y adaptadores o arquitectura limpia, y un diagrama de componentes es la forma más barata de comprobar si una base de código la tiene de verdad. Si la caja del núcleo tiene una flecha apuntando a un componente de base de datos en vez de a una interfaz, el patrón es una aspiración: algo del medio importa el controlador.

Este es el diagrama que se dibuja antes de una sustitución, no después. La afirmación que hace es precisa y comprobable: todo lo que el servicio de pedidos necesita de la facturación está en IBilling, así que una segunda implementación de esa interfaz puede sustituirse sin que el servicio de pedidos cambie.

Es además la forma más rápida de descubrir que la afirmación es falsa. Si alguien dice «el servicio nuevo no sabe generar los extractos en PDF», entonces los extractos en PDF formaban parte del contrato y faltan en la interfaz, y el diagrama estaba mal antes que la migración. Esa conversación cuesta diez minutos en una pizarra y tres meses en producción.

Cuando la implementación vieja ya no esté, bórrala del diagrama. Un diagrama de componentes que sigue mostrando el mainframe dos años después de apagarlo es la razón de que la gente deje de fiarse de los diagramas.

Topológicamente esto es el ejemplo tres con una tercera implementación añadida, y merece detenerse en ese parecido: reemplazabilidad y extensibilidad son el mismo dibujo. Lo que cambia es la intención. En una migración la realización extra es temporal; en una arquitectura de complementos es el producto.

La técnica de lectura que compensa aquí es tapar la columna derecha con la mano. Lo que queda - el anfitrión e IExporter- es todo lo que necesita saber quien vaya a escribir un cuarto exportador. Si la respuesta a «¿puedo escribir mi propio exportador?» exige leer el código del anfitrión, la interfaz está infraespecificada, y el diagrama acaba de decírtelo.

Dos servicios, cada uno realizando un contrato que el otro requiere. Aquí nada es UML ilegal y nada del diagrama está mal: el dibujo es una imagen exacta de un sistema que va a ser difícil, que es justo lo que quieres que un diagrama sepa decir.

Un ciclo entre componentes significa que ninguno puede entenderse solo: nada de despliegue independiente, nada de probar en aislamiento sin un sustituto del otro, y reemplazar cualquiera de los dos exige cumplir un contrato del que el otro depende a la vez. En un diagrama de clases un ciclo es un olor; entre unidades desplegables es un riesgo de calendario.

Los arreglos habituales se ven en la misma imagen. Mueve lo que Shipping necesita de IOrders a un evento que publique el servicio Orders, para que la flecha pase a ser de un solo sentido. O extrae la parte compartida a un tercer componente del que dependan ambos, lo que convierte el ciclo en una convergencia y te devuelve al ejemplo uno.

Para dibujar uno de estos contra tu propio sistema, la versión paso a paso está en cómo dibujar un diagrama de componentes. Para dónde se ejecutan esos componentes en vez de qué se prometen entre ellos, eso es un diagrama de despliegue.