Java 组件图是否仅指物理组件？

在UML组件图中，是否有一个很好的测试某个东西是否符合“组件”的条件，它是物理隔离的，这是真的吗

我找到的大多数定义（Wikipedia、TutorialsPoints等）都将组件称为“文件、库、可执行文件等”

---

然而，一些插图（请参阅）似乎将类建模为组件（例如“学生”、“研讨会”），乍一看可能表明这些只是应用程序中的一些重要类。然而，进一步阅读“创建组件图”标题下的内容，它大量引用了“网络流量”（“减少潜在网络流量”）；这意味着建模的组件是通过网络端口进行通信的不同进程或可执行文件。这似乎意味着其实例位于同一JVM中的各个类（我可能会添加相同的physical.jar）应该位于UML组件图中的同一个组件中。这总是真的吗？如果不是，同一jar和同一JVM中的对象实例何时会被视为此图中的不同组件？

否，UML组件不限于物理文件或类似的内容

物理甚至可能不是谈论系统上的文件的好术语，因为您不能真正接触文件。所有的都是比特和字节

UML2.5将组件定义为

组件表示系统中封装的模块化部分 其内容和表现形式在其内部是可替换的 环境

而且它说

组件是封装状态和状态的自包含单元 许多分类器的行为。组件指定一个正式的 向客户提供的服务合同，以及 它需要从中的系统中的其他组件或服务获取 其提供和要求的接口的条款

组件是可替换的单元，可以在设计时或运行时由 一种基于 其接口的兼容性。只要环境得到充分保护 与组件提供的和要求的接口兼容， 它将能够与这个环境进行交互。同样，一个系统 可以通过添加新的组件类型来扩展 功能。系统功能的较大部分可能是 通过将组件作为包含组件中的零件重新使用进行组装 或组件的组装，并将它们连接在一起

因此，软件应用程序（如Skype或Chrome可以建模为组件，但内部部分（如聊天引擎）或HTML渲染器也可以视为组件

---

通常，组件结构实际上反映在物理实现中；一个软件的每个组件都可以编译成一个单独的dll。除了Geert的优秀答案之外，当您不一定总是需要它时，最好将通常看起来像类的东西封装为一个组件

设想一个能够管理公司车队的应用程序。通常，它会支持汽车。然而，您可能希望能够添加额外的组件，以便能够处理飞机、轮船或自行车。在这种情况下，你可能不需要汽车。这些东西中的每一个都将成为组件，即使您可以简单地将其建模为驻留在系统核心Vehicle中的唯一类的子类。例如，您可能有与这些自行车相关的不同元素，这些元素不包含在类本身中。考虑屏幕、维护模型、与可应用于子类级别的不同方法的所有内容的不同。

此类系统中组件的其他示例可以是驱动程序。这不再是车辆的子类，而是与车辆交互的独立类。同样，根据具体情况，您可能只对公司的汽车感兴趣，或者将汽车与分配给汽车的驾驶员联系起来，甚至允许使用汽车。因此，您会得到一组完全不同的依赖项、屏幕、方法等，它们不仅与驱动程序本身有关，而且与周围环境的交互有关

---

一般来说，虽然这并不限于此，但组件是一种很好的方式，可以考虑如何将系统拆分为更小的部分，这些部分可以分离或连接到系统，并相应地添加或删除其部分功能。

文件、库、可执行文件都是工件的示例，但肯定不是组件的例子。from：组件是执行原型函数所必需的东西。组件中的原型示例包括可执行文件、文档、数据库表、文件和库文件。寻找这类东西的唯一最佳来源是OMG的UML规范：在那里，它说组件代表系统的模块化部分，封装其内容，其表现形式在其环境中是可替换的。“可以编译成单个dll（或jar）”，但不必，对吗？只要在概念上一组类被认为是“接口可互换的”？我之所以问这个问题，是因为我读到一些人将其作为工作分解工具，用于将代码库的不同部分分配给不同的团队/开发人员。是的，通常并不总是这样。感谢具体的示例。我可以把这个建议应用于小项目。我喜欢Geert更一般的答案，它也有参考资料。