Plantilla de diagrama de componentes UML
Cuatro componentes y tres interfaces, cada una proporcionada por exactamente un componente y requerida por otro: la única disposición para la que existe un diagrama de componentes.
Notación: UML 2.5.1Diagrama: Diagrama de componentes
Abre esta plantilla en Archyno
Se abre como un modelo editable, no como una imagen. Cámbialo en el navegador y expórtalo a PNG, SVG, Mermaid, XMI o un fichero Sparx .qea.
Abrir la plantillaQué hay en este diagrama
- Storefront
- Un consumidor. Requiere una interfaz y no proporciona ninguna: el borde del sistema.
- OrderIntake
- El contrato entre la tienda y el servicio. Renómbralo antes que a cualquiera de los componentes.
- Order service
- El componente que proporciona una interfaz y requiere dos. Así son la mayoría de tus componentes.
- OrderRepository
- La persistencia como contrato, para que el almacén detrás sea sustituible sin tocar el servicio.
- Order store
- El componente realizador. El estereotipo «database» dice de qué clase de cosa se trata.
- Payment adapter
- El tercero, encapsulado. La interfaz es tuya aunque el proveedor detrás no lo sea.
Cómo hacerlo tuyo
- Renombra primero las interfaces. Un diagrama de componentes trata de contratos, y los nombres de los componentes son la parte en la que todos ya están de acuerdo.
- Comprueba que cada interfaz la proporciona exactamente un componente. Dos proveedores son el diagrama de una discusión sin resolver.
- Dibuja el extremo requerido como dependencia y el proporcionado como realización. Invertirlos da la vuelta al sentido de todo el diseño.
- Nunca conectes dos componentes directamente. Si no hay interfaz entre ellos, el diagrama es un boceto de cajas y líneas y la notación no hace nada.
- Añade un estereotipo solo donde la clase de componente cambia cómo se despliega: «database», «service», «device». Estereotiparlo todo no dice nada.
- Deja el adaptador del tercero donde está. La interfaz que posees delante de un proveedor que no posees es la razón entera de dibujar este diagrama.
Preguntas frecuentes
¿Cuál es la diferencia entre interfaz proporcionada y requerida?
Una interfaz proporcionada la implementa el componente: cualquiera puede llamarla. Una interfaz requerida debe implementarla otro, o el componente no funciona. En esta plantilla Order service proporciona OrderIntake y requiere OrderRepository y PaymentGateway, así que es proveedor y consumidor a la vez, que es lo que son la mayoría de los componentes reales.
¿Debería usar la notación de bola y zócalo?
Ambas son UML correcto y significan lo mismo. La bola y zócalo es más compacta y se lee bien cuando una interfaz une exactamente dos componentes; la forma de clasificador usada aquí escala mejor, porque un segundo consumidor es una flecha discontinua más en lugar de un conector redibujado. Usa la que tu equipo lea sin preguntar.
¿Es un diagrama de componentes lo mismo que uno de despliegue?
No. Un diagrama de componentes dice qué piezas de software hay y cómo dependen entre sí; uno de despliegue dice en qué máquina se ejecuta cada pieza. Se dibujan juntos a menudo, y fundirlos en una sola imagen es la razón habitual de que ninguno sea legible.
Lee la notación
Cómo leer y dibujar un diagrama de componentes UML: componentes, interfaces provistas y requeridas, notación de bola y casquillo, puertos, y en qué se diferencia de un diagrama de clases.
Una referencia de todos los símbolos del diagrama de componentes UML: la caja de componente, interfaces provistas y requeridas, bola y casquillo, conectores de ensamblado y delegación, puertos y estereotipos.
Dibujar un diagrama de componentes
Paso a paso: elige las piezas, dibuja las cajas, nombra lo que cada una provee, añade lo que requiere y pasa las cuatro comprobaciones que dicen que el diagrama está terminado.
Cinco ejemplos resueltos de diagrama de componentes UML: un catálogo compartido, puertos y adaptadores, la sustitución de un legacy, una arquitectura de plugins y un ciclo de dependencias.