Is there an agreed UML diagram style for documenti

Question

I'm planning to draw some UML structure diagrams that illustrate the place of Docker images (or containers, in deployment diagrams) in the overall structure of the software I am architecting. I'm interested in illustrating the contents of containers, the mapping of network ports and other interfaces and the way multiple containers inter-operate.

My problem space is that of distributed, event-based systems (DEBS), so I expect that most of my containers will have message queues coming in and going out. Another part of my architecture involves the use of an in-memory data grid, which will span across many containers across multiple nodes in a cluster.

How can this be modeled with UML ? If it can't, is there anything planned in UML to address such distribution issues ?

Answer 1

You want to represent docker containers and how they deploy your data grids. But you also want to show how this is related to your software architecture.

I think you should first have a look a deployment diagrams. These are best suited for representing the execution of your system across hardware and software environments:

• here an example showing how to represent docker hosts, and images with "nodes" and communication paths
• here an example showing how to further represent the inside of a node with "artifacts" such as for example components, which could represent your data-grid components linked across several nodes, and message queue if it's an independent component.
• here a nice overview of the notation. Interesting in your case: you could also show the deployment of a artifact accross several nodes with a dependency arrow to the nodes. This would make the diagram focusing on how your components are distributed, keeping artifacts on one side and execution environment on the other, avoid over-inflated 3D node boxes.

The component architecture could then be described in a component diagram, as pointed out by Thomas Kilian in his comment. For the sake of completeness: see here or here.

Finally, you could explain the relationship between your high-level independent components and your detailed classes by using the composite structure diagram.