El diagrama UML de despliegue representa una vista estática de la configuración en tiempo de ejecución de los nodos que intervienen en el proceso y de los componentes que se ejecutan en esos nodos. Puede mostrar el hardware del sistema y los paquetes software que hay instalados en él, el middleware que los conecta, etc.
También son útiles para explorar la arquitectura de sistemas embebidos, mostrando los componentes hardware y software, así como sus protocolos o formas de comunicarse.
Diagrama de despliegue del sistema
En el diagrama de despliegue anterior, las cajas tridimensionales representan los nodos del sistema, tanto software como hardware. Podemos clarificar de qué se trata exactamente cada uno mediante estereotipos, siempre que éstos ayuden a entender el diagrama.
Las conexiones entre nodos del sistema pueden etiquetarse con el protocolo de comunicación en que se implementan. Los nodos pueden contener subnodos, o componentes software. Los componentes software usan la misma notación que en los diagramas de componentes,
por lo que podríamos añadir la notación acerca de sus interfaces si fuera necesario, aunque al nivel al que se representan los diagramas de despliegue no suele serlo.
En configuraciones complejas, los diagramas de despliegue pueden extenderse rápidamente si indicamos todos los ficheros de configuración, especificaciones de arquitecturas y versiones de cada componente implicado. Ésta es la información que sería realmente útil para los desarrolladores que deben implantar o mantener el sistema, pero no parece que UML proporcione las herramientas para representarlo de forma compacta.
Veamos el mismo ejemplo más detallado para comprobarlo.
Diagrama de despliegue con alguna información adicional acerca de la configuración del sistema
Vemos que la inclusión de ficheros de configuración, versiones, especificaciones de despliegue, etc. empieza a complicar el diagrama cuando quizá una simple hoja de requisitos y unas instrucciones de despliegue textuales junto con el primer diagrama serían más útiles.
Así pues, cuando trabajemos con diagramas de componentes es recomendable seguir estas prácticas:
- Indicar sólo los componentes software clave para el proyecto.
- Es importante denominar los nodos con nombres descriptivos que sean útiles para los desarrolladores.
- Intentar no abusar de los estereotipos, y mantener una coherencia en su nomenclatura con el resto de diagramas.
- Las comunicaciones también pueden incorporar estereotipos, indicando por ejemplo si la comunicación es síncrona o asíncrona, si se trata de un servicio web, etc.
No es necesario modelar todas las dependencias. Esto da como resultado diagramas completamente saturados de asociaciones que no aportan información. Es más conveniente modelar sólo las que aportarán algo al modelo.• Si existen varias relaciones entre dos clases, puede ser interesan-te indicar el rol que ocupan ellas en cada una. El rol se indica junto a la multiplicidad mediante el sujeto de la oración que contendría el verbo de la asociación (p. ej. “nueva propuesta”, “antiguo cliente”, etc.).