是否确实可以对某项是否符合UML组件图中的“组件”进行良好的测试，是否将其物理隔离？
我发现的大多数定义（Wikipedia，TutorialsPoints等）将这些组件称为“文件，库，可执行文件等”。
但是，一些插图（请参见http://agilemodeling.com/artifacts/componentDiagram.htm）似乎将类建模为组件（例如“学生”，“研讨会”），乍一看可能表明这些只是应用程序中的一些重要类。但是，在“创建组件图”标题下进一步阅读down，它大量引用了“网络流量”（“减少潜在的网络流量”）；这意味着所建模的组件是通过网络端口进行通信的不同进程或可执行文件。这似乎暗示其实例位于同一JVM（并且我可能添加相同的物理.jar）的各个类应位于UML组件图中的同一组件中。这总是真的吗？如果不是，在这种情况下，在相同的jar和JVM中的对象实例在什么情况下会被视为不同的组件？
答案 0 :(得分：2)
不，UML组件不限于物理文件或类似的文件。
物理甚至可能不是谈论系统上文件的好术语，因为您无法真正触摸文件。都是位和字节。
UML 2.5将组件定义为
组件代表封装的系统的模块化部分 其内容及其表现形式可在其内部替换 环境。
进一步说
Component是一个自包含单元，它封装了状态和 多个分类器的行为。组件指定形式 提供给客户以及那些客户的服务合同 它需要系统中其他组件或服务 提供和要求的接口的条款。
组件是可替换的 单元，可以在设计时或运行时替换为 提供基于以下功能的等效功能的组件 接口的兼容性。只要环境充分 与组件的提供和要求的接口兼容， 它将能够与此环境进行交互。同样，一个系统 可以通过添加新的Component类型扩展来添加新的 功能。系统功能较大的部分可能是 通过将组件重用为包含的组件中的一部分进行组装 或组装组件，并将它们连接在一起。
因此，可以将诸如 Skype 或 Chrome 之类的软件应用程序建模为组件，还可以将其内部组件建模为聊天引擎 ，或者 HTML渲染器可以视为组件。
通常，组件结构实际上是在 physical 实现中反映的；一个软件的每个组件都可以编译为一个dll
答案 1 :(得分：0)
除了Geert的出色回答外，通常不必将通常与类相关的所有东西封装为一个组件，当您不一定总是需要它时，将其封装也是一个好主意。
想象一下一个可以管理公司车队的应用程序。通常，它将附带对汽车的支持。但是，您可能希望能够添加其他组件，以便能够处理飞机，轮船或自行车。在这种情况下，您可能也不需要汽车。即使您可以简单地将其建模为驻留在系统核心（称为Vehicle）中的唯一类的子类，它们也会成为组件。例如，您可能具有与这些自行车相关的不同元素，这些元素未包含在类本身中。考虑一下屏幕，维护模型以及与只能在子类级别上应用的不同方法相关的所有事物的区别。
此类系统中组件的其他示例可以是Drivers。它不再是Vehicle的子类，而是与Vehicle交互的一些单独的类。同样，根据情况，您可能只对公司内的汽车感兴趣，或者将其链接到分配给他们甚至被允许使用的驾驶员。因此，您想到了一套完全不同的依赖项，屏幕，方法等，它们不仅与驱动程序本身有关，而且还与周围环境相互作用。
通常，不限于此，组件是思考如何将系统拆分为较小的部分的好方法，这些较小的部分可以分离或附加到系统上，从而相应地添加或删除其部分功能。