Is there an agreed UML diagram style for documenting or illustrating the role of (Docker) containers in a system architecture specification? [closed]

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.