20. Diagramas de componentes: módulos, interfaces y dependencias de software
20.1 Introducción
El diagrama de componentes es un diagrama UML de estructura que muestra partes de software, interfaces y dependencias entre ellas. Es útil para representar una vista de arquitectura o diseño de alto nivel, donde interesa comprender cómo se divide una solución en módulos y cómo esos módulos se comunican.
Mientras un diagrama de clases suele mostrar tipos y relaciones más detalladas, el diagrama de componentes trabaja con bloques mayores: aplicaciones, servicios, bibliotecas, módulos, APIs, subsistemas o partes desplegables.
20.2 Qué representa un componente
Un componente representa una unidad modular de software. Puede ofrecer interfaces, requerir servicios de otros componentes y encapsular una parte de la implementación. El componente se piensa como una pieza que cumple una responsabilidad clara dentro de la solución.
Por ejemplo, en un sistema de ventas pueden existir componentes como Aplicación web, Servicio de pedidos, Servicio de pagos, Servicio de inventario, Base de datos y Cliente de notificaciones.
20.3 Componentes, interfaces y dependencias
Un diagrama de componentes permite observar qué módulos forman el sistema, qué interfaces ofrecen, qué interfaces requieren y qué dependencias existen entre ellos. Esta vista ayuda a discutir arquitectura sin entrar en cada clase interna.
20.4 Interfaces ofrecidas
Una interfaz ofrecida representa un conjunto de servicios que un componente pone a disposición de otros. En UML puede dibujarse con el símbolo de círculo, también llamado lollipop, conectado al componente.
Por ejemplo, un Servicio de pagos puede ofrecer una interfaz ProcesamientoPago, con operaciones para autorizar, confirmar o cancelar pagos. Otros componentes pueden usar esa interfaz sin conocer todos los detalles internos del servicio.
20.5 Interfaces requeridas
Una interfaz requerida representa un servicio que un componente necesita de otro para funcionar. En UML puede representarse con una forma de semicírculo o socket.
Por ejemplo, un Servicio de pedidos puede requerir una interfaz de Pagos para confirmar cobros y una interfaz de Inventario para verificar stock. Esto permite ver dependencias necesarias sin mostrar implementación interna.
20.6 Dependencias entre componentes
Una dependencia indica que un componente necesita a otro. Puede representarse con una flecha discontinua o mediante interfaces ofrecidas y requeridas. La dirección de la dependencia debe mostrar quién necesita a quién.
Las dependencias son importantes porque indican impacto de cambios. Si un componente cambia su interfaz, todos los componentes que dependen de ella pueden verse afectados.
20.7 Puertos
Un puerto representa un punto de interacción de un componente con su entorno. Puede usarse para indicar por dónde entran o salen comunicaciones específicas. Es útil cuando un componente tiene varias formas de comunicación o varias interfaces agrupadas.
Por ejemplo, un componente Aplicación móvil puede tener un puerto para API pública y otro para sincronización. No siempre es necesario mostrar puertos; se usan cuando aclaran la arquitectura.
20.8 Artefactos y componentes
Un componente representa una unidad lógica de software. Un artefacto representa un elemento físico o generado, como un archivo ejecutable, una biblioteca, un paquete, una imagen de contenedor o un archivo de configuración.
En algunos modelos, un componente puede manifestarse en uno o varios artefactos. Por ejemplo, el componente Servicio de pedidos puede desplegarse como un archivo ejecutable, una imagen de contenedor o un paquete de aplicación.
20.9 Componentes y clases
Un componente puede contener muchas clases. El diagrama de componentes no pretende mostrar el detalle interno de cada clase, sino la organización modular de mayor nivel. Para ver clases internas, se puede usar un diagrama de clases separado.
Por ejemplo, el componente Servicio de turnos puede contener clases como Turno, Agenda, ServicioTurnos, RepositorioTurnos y ValidadorDisponibilidad. El diagrama de componentes solo necesita mostrar que existe ese módulo y qué dependencias tiene.
20.10 Componentes y paquetes
Los paquetes organizan elementos del modelo; los componentes representan partes modulares de software. A veces ambos conceptos parecen similares, pero no tienen el mismo propósito. Un paquete agrupa; un componente ofrece o requiere servicios y puede ser una unidad de implementación o despliegue.
En un modelo de arquitectura, puede haber correspondencia entre paquetes y componentes, pero conviene no tratarlos como sinónimos sin analizar la intención.
20.11 Arquitectura por capas
Un diagrama de componentes puede representar una arquitectura por capas. Por ejemplo, Interfaz de usuario, Aplicación, Dominio, Infraestructura y Base de datos. Las dependencias deberían seguir una dirección controlada.
Esta vista ayuda a detectar dependencias incorrectas. Si Dominio depende de Interfaz de usuario, puede existir una violación de separación de responsabilidades.
20.12 Servicios y APIs
En sistemas modernos, los componentes suelen representar servicios o APIs. Un Servicio de usuarios puede ofrecer operaciones de autenticación y consulta de perfiles. Un Servicio de pagos puede ofrecer autorización y confirmación de cobros.
El diagrama de componentes permite mostrar estas integraciones sin entrar en detalles de endpoints, parámetros o protocolos específicos, salvo que sean necesarios para la comprensión.
20.13 Sistemas externos
Los sistemas externos también pueden representarse como componentes cuando participan en la arquitectura. Por ejemplo, una pasarela de pagos, un proveedor de correo, un sistema contable o un servicio de identidad.
Representarlos ayuda a visualizar dependencias fuera del sistema propio y a discutir riesgos, disponibilidad, seguridad e integración.
20.14 Ejemplo: sistema de turnos médicos
Un sistema de turnos médicos puede tener componentes como Aplicación web, Servicio de turnos, Servicio de usuarios, Servicio de notificaciones, Base de datos y API de calendario. El Servicio de turnos puede requerir servicios de usuarios para identificar pacientes y servicios de notificaciones para enviar recordatorios.
Esta vista permite comprender la organización modular sin mostrar todos los detalles internos de clases y métodos.
20.15 Ejemplo: tienda en línea
Una tienda en línea puede incluir componentes como Frontend, API de catálogo, Servicio de pedidos, Servicio de pagos, Servicio de inventario, Servicio de envíos y Base de datos. El Servicio de pedidos puede depender de pagos, inventario y envíos.
El diagrama ayuda a revisar si las dependencias son razonables y si cada componente tiene una responsabilidad clara.
20.16 Cuándo usar diagramas de componentes
Conviene usar diagramas de componentes cuando se necesita explicar arquitectura modular, dependencias entre servicios, interfaces ofrecidas y requeridas, integración con sistemas externos o división de una solución en partes reemplazables.
No son necesarios para describir detalles internos de una clase, el flujo de un proceso o el orden de mensajes de un escenario. Para eso existen otros diagramas UML.
20.17 Nivel de detalle
Un diagrama de componentes puede ser muy general o bastante técnico. En una vista general, puede mostrar aplicaciones y servicios principales. En una vista técnica, puede incluir interfaces, puertos, artefactos y dependencias específicas.
El nivel de detalle debe responder a la pregunta del diagrama. Si se busca comunicar arquitectura a alto nivel, conviene evitar saturar la vista con detalles internos.
20.18 Criterios de revisión
- ¿Cada componente tiene una responsabilidad clara?
- ¿Las interfaces ofrecidas y requeridas están justificadas?
- ¿La dirección de las dependencias es correcta?
- ¿El diagrama evita mostrar detalles internos innecesarios?
- ¿Los sistemas externos están identificados cuando afectan la solución?
- ¿Las dependencias sugieren una arquitectura comprensible y mantenible?
- ¿El nivel de detalle coincide con el propósito de la vista?
20.19 Errores frecuentes
- Confundir componentes con clases individuales.
- Confundir paquetes con componentes sin analizar el propósito.
- Mostrar demasiados detalles internos y perder la vista modular.
- No indicar interfaces importantes.
- Dibujar dependencias en dirección incorrecta.
- Omitir sistemas externos críticos.
- Crear componentes sin responsabilidad clara.
20.20 Qué debes recordar de este tema
- El diagrama de componentes muestra módulos de software y dependencias.
- Un componente puede ofrecer y requerir interfaces.
- Las dependencias indican qué componentes necesitan servicios de otros.
- Los componentes representan una vista modular, no el detalle de cada clase.
- Este diagrama es útil para discutir arquitectura e integración.
- El nivel de detalle debe mantenerse coherente con el objetivo de comunicación.
20.21 Conclusión
El diagrama de componentes permite representar la estructura modular de una solución de software. Ayuda a comprender qué partes existen, qué interfaces ofrecen, qué servicios requieren y cómo se conectan con otros componentes o sistemas externos.
En el próximo tema veremos diagramas de despliegue, orientados a nodos, dispositivos, servidores y artefactos.