What is the correct way to indicate distribution of classes to binary artifacts in UML?

Question

I am trying to show the overall architecture of a plugin-/component-based system in UML. As a simple example for this question, I will show a main application that loads a plugin interface library (which defines the common interfaces for plugins), as well as two exemplary plugins (one of which comes with some internal details), as shown in the following UML class diagram¹:

In my UML diagram, I would like to highlight how these classes (and the interface) are distributed to separate binaries², in order to clarify what parts of the system can be replaced without recompilation.

Now, while I am aware UML provides quite some leeway and the main point of UML is not sticking to a rigid notation, but expressing information in a way to make it comprehensible, I still expect there to be a common practice for this scenario.

---

One straightforward way of representing the information that I had thought of is using a UML component diagram. Wikipedia cites the definition

a modular part of a system, that encapsulates its content and whose manifestation is replaceable within its environment.

for a component. This seems to fit, given that what I want to show is precisely a replaceable component. Hence, by putting the above types into components, I arrive at this:

While this is comprehensible, I have slight doubts this is the acceptable notation, given that almost all resources (including the aforementioned Wikipedia article) on component diagrams I can find put a great emphasis on defining the required and provided interfaces. Formally, it looks like I should either add small rectangular ports or lollipop-shaped interfaces everywhere in the diagram where relationships connect elements across components. I do not quite like that prospect, as it sounds somewhat cumbersome to achieve, and more importantly, it would clutter the graphic without providing any additional information.

---

Alternatively, a package might be an acceptable notation. My purpose seems to match with what Wikipedia describes in the second list in the respective article as

When organizing component models, use packages to group the components according to ownership and/or reuse possibilities.

A package diagram would look as follows:

On the other hand, I am a bit wary that using the package notation might create confusion with actual in-code packages (namespaces), which are actually orthogonal to assemblies. Indeed, there are resources that interpret a UML package as a 1:1 mapping to Java packages, which is not what I am trying to convey (for the sake of argument, all depicted types might very well reside within the very same namespace, something like MyGreatSystem.Plugins).

---

The only other UML diagram type that could be somewhat suitable might be a deployment diagram, but definitions such as the one from Wikipedia make it rather clear that a node in such a diagram is either a physical machine, or an execution environment, both of which are clearly different from simply being in a separate binary.

---

One last alternative that I could think of is indicating the binary files by connecting the types with UML comments:

However, this seems more like a workaround to me, and I feel that the additional nodes and edges (rather than having the types inside the assemblies, where they actually are) makes the diagram less readable.

---

What is the appropriate UML way to convey which types reside in which binaries in the finished product?

¹: No members for the classes and interfaces are shown here, as they are not relevant for the time being. This may or may not be the same in my final diagram, as the focus mostly does not lie on the complete internal class structure.

²: .NET assemblies in my case, but the question is equally valid for other environments/technologies.

Answer 1

You should make a difference between the components, and the binaries that they are "manifested" in.

The Component is the logical grouping of behavior. The actual physical binary assembly is represented in UML as a manifesting Artifact.

The most dense notation for this can be found in the UML specificaton v 2.5 (beta) on figure 11.40 on page 221

Make sure to use the correct relations between the component and the other elements.

There are a few alternate notations that can be used as well. From the same UML 2.5 specs: