UML context diagram involving platforms

Question

I modeled a lot using UML over the course of the past years, but this is somehow giving me headache.

Let's have a look at the following example. The yellow components are those that I actually consider as "part of my application", namely the "Webserver" and "Service A". So a user might take an action on a website and the webserver contacts a platform, which is used for hosting (low-code platforms such as Outsystems or CAMUNDA are closest to what I mean here), in order to run a particular "Service A". This communication is managed by "Event Management" so that the Webserver never gets directly in contact with the service.

Now, I want to represent my application as a single white-boxed component and create a context view. Simply omitting the hosting platform results in a clear conflict as both, "Service A" and the "Webserver" only provide an interface and therefore cannot communicate with each other.

First I thought that it can be handeled using deployment diagrams, but the service is really a part of the platform and part of the application at the same time. And to be honest: I don't want to have the platform in all of my diagrams - we don't do this for services running on a particular OS neither...

So where is my mistake? How would you model it?

Answer 1

What are context diagrams?

UML does not have context diagrams. This terminology is borrowed from the DFD notation, where a level 0 diagram showed data flows between the system under consideration and the external entities, be it humans, organisations, or other systems.

The closest diagram in UML would be:

• from a purpose point of view: a use case diagram to show the system and the actors in its environment. The independent systems around could be actors, but the association would not show any flow, but just involved as primary or auxiliary actors in the the goals satisfied by your system.

• from a technical point of view: a communication diagram where each instance represents a whole system. But you're no longer modeling the system then, but a system of systems.

What do you want to show with your diagram?

Your first component diagram shows how the components of your systems are "wired", including the external components that you have to use as pieces of your system. The only doubt I have here, is whether you should really show service A as a subcomponent of the platform. I'd rather see it as an independent component that is connected to the platform using the platform interface.

Your second component diagram focuses on your application, promoting it as component. This view can somehow be defended at a higher level of abstraction, but it looks weird because of the missing parts, and the tile "application" (whereas the webserver has other purposes than your application). An improvement could be:

• to add the event queue between the unconnected interfaces, or hide the interfaces, as it is internal details not relevant to the outside context.
• alternatively to consider the interfaces at a more abstract level, i.e. viewing the connection between your components as being implemented using the event queue, i.e. the mechanism to connect the components would be part of the interface.
• personally, I'd keep in My Application only the components of the application, and would show the interfaces to the platforms as external interfaces, because these are required to be "wired" to make it a useful component.

This being said, it seems in the first diagram that you try to show the overall architecture. The platform, webserver and browser are in reality execution environments on different devices/nodes, and it would much clearer what is really an interchangeable component, and what is the infrastructure on which these components run, using a deployment diagram.