Plugins 在UML中，指示类到二进制工件的分布的正确方法是什么？

我试图用UML展示一个基于插件/组件的系统的总体架构。作为这个问题的一个简单示例，我将展示一个加载插件接口库（定义插件的公共接口）的主应用程序，以及两个示例性插件（其中一个带有一些内部细节），如以下UML类图1所示：

在我的UML图中，我想强调这些类（和接口）是如何分布到单独的二进制文件2的，以便澄清系统的哪些部分可以在不重新编译的情况下被替换

现在，虽然我知道UML提供了相当大的回旋余地，UML的要点不是坚持严格的表示法，而是以一种可以理解的方式来表达信息，但我仍然希望这个场景有一个通用的实践

---

表示我所想到的信息的一种简单方法是使用。定义

系统的模块化部分，封装其内容，其显示在其环境中是可替换的

对于一个组件。这似乎是合适的，因为我想展示的正是一个可替换的组件。因此，通过将上述类型放入组件，我得出以下结论：

虽然这是可以理解的，但我有点怀疑这是一个可接受的符号，因为我能找到的组件图上的几乎所有资源（包括）都非常强调定义所需和提供的接口。从形式上看，我应该在图中的任意位置添加小矩形端口或棒棒糖形状的接口，在图中，关系将元素跨组件连接起来。我不太喜欢这种前景，因为它听起来有点麻烦，更重要的是，它会在没有提供任何额外信息的情况下使图形变得混乱

---

或者，a可能是一个可接受的符号。我的目的似乎与相关文章第二个列表中描述的内容相匹配：

组织组件模型时，使用包根据所有权和/或重用可能性对组件进行分组

包图如下所示：

另一方面，我有点担心使用包表示法可能会与实际的代码内包（名称空间）产生混淆，这些包实际上与程序集正交。事实上，这将UML包解释为Java包的1:1映射，这不是我想要传达的（为了论证，所有描述的类型可能都位于同一名称空间中，类似于

MyGreatSystem.Plugins

）

---

唯一另一种稍微合适的UML图类型可能是a，但定义（如中的定义）相当清楚地表明，在这样的图中，a要么是物理机器，要么是执行环境，两者显然不同于简单地位于单独的二进制文件中

---

我能想到的最后一种选择是通过将类型与UML注释连接起来来指示二进制文件：

但是，对我来说，这更像是一种变通方法，我觉得额外的节点和边（而不是在程序集中的实际位置包含类型）会降低图表的可读性

---

什么是合适的UML方式来传达成品中哪些类型驻留在哪些二进制文件中？

1：这里没有显示类和接口的成员，因为它们暂时不相关。这在我的最终图表中可能是相同的，也可能不是相同的，因为重点主要不在完整的内部类结构上

---

2:.NET程序集，但这个问题对于其他环境/技术同样有效。

我对您的第一个图表与使用包的图表相当满意。组件可以很好地包含元素（根据UML规范，它由

PackageableElements

组成）。为了可读性，我会放大

核心应用程序

，这样钻石就完全在里面了。第三种选择就是：一种选择。我更喜欢第一个。

您应该区分组件和它们“显示”在其中的二进制文件

组件是行为的逻辑分组。实际的物理二进制程序集在UML中表示为一个显化的工件

最密集的符号可以在第221页图11.40中的UML规范V2.5（beta）中找到

确保在组件和其他元素之间使用正确的关系

也可以使用一些替代符号。来自相同的UML 2.5规范：

---

有人能解释一下否决票吗？人们永远不会习惯那些否决票的巨魔……嗯，但我想展示的是物理二进制程序集。对于最终用户，物理二进制程序集构成组件，因为最终用户可以替换和添加程序集，只要它们包含兼容类型。公共类型集是组件的接口。这些类型，主要是类，正是我想显示的每个程序集的内容，以及它们的成员的相关子集。您所展示的Beta 1规范中的图11.40看起来似乎只是一个类型名称列表（？）物理二进制程序集是工件，而不是组件。符号中有一些选项，但其背后的模型保持不变。好的，因此符合特定插件接口的可替换编译文件是工件，而不是组件，最终用户可以替换它们。在这种情况下，我仍然不确定使用什么符号-我正在寻找某种包含相关类的框（表示程序集），以指示