1

I'm working on a component diagram of a system and due to the system's design quite a few dependency lines end up crossing, which makes the diagram hard to read and hard to follow.

One way to side-step this issue would be to use separate component diagrams to illustrate how a subset of the system's components depend on some component/interface. For example, the dependency on a data store would be represented in a component diagram which covers only the data stores and the components which directly access those datastores, omitting the remaining components. However, I'm not sure this is considered standard practice or even acceptable.

Does anyone know if it's ok to present multiple component diagrams of the same system? If not, what other alternatives are available to avoid cluttering the diagram?

RAM
  • 2,257
  • 2
  • 19
  • 41

2 Answers2

4

Yes, that is the standard practice. Only the most trivial systems are small enough to be represented in a single diagram.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
2

Different views are a common way to simplify complexity in diagrams. However, the desire for multiple diagrams is possibly a bit of a smell that you have too much complexity in the system you are trying to model.

Consider moving up a level up from component diagrams to package diagrams in order to help lay out the bigger picture. This should help you to organize your system in to a set of well organized sub systems. For each sub-system you can then drill down back to the detailed component diagrams.

Murray Foxcroft
  • 12,785
  • 7
  • 58
  • 86
  • The main problem I'm facing is that the system includes a message broker which provides an interface that's required by most of its components, and there's also a data store that provides an interface that's required by a different subset of components. Therefore, if both sets of interfaces are represented in the same diagram then invariably some dependency arrows will cross over each other. – RAM Jan 11 '19 at 13:31
  • At the component level I would model the service bus as a pattern. See https://stackoverflow.com/questions/2480428/how-do-i-draw-an-esb-on-a-soaml-diagram. Then I would use a sequence diagram to model individual interactions. Remember, a service bus is used to decouple systems, so your UML should reflect that too :) – Murray Foxcroft Jan 11 '19 at 13:56
  • The message bus does simplify both the system and the diagram, but once the dependencies between each component and the service bus interface are represented in the graph (ends up with a hub and spoke layout) then it's hard to add a couple of additional dependencies between components without having them cross over each other. – RAM Jan 15 '19 at 09:25