这是在与同事的讨论中提出的，作为思考的食物 - 在 UML序列图中处理组件和子组件之间关系的技术上合适的方法是什么。
所以这里有一个问题——在 UML 最佳实践中，序列图是否应该与图中描述的对象的关系有任何联系？我的直觉是不会——画一个序列图，每个组件都是分开的，然后用类图或部署图来展示其他类型的关系。
如果你说“是！” 请用一些很好的例子来说明你如何以及为什么会做不同的事情。
如果“否”，您能否为我指出一些可靠的在线参考资料以证明其合理性？我尝试了 UML 规范，然后......哦！......不是我想要的，除非我试图让自己失去知觉。
具体来说，这里是我的示例——我想对应用程序服务器如何调用安全插件然后调用已使用 JSP 和 Java 部署的基本应用程序的顺序图建模。应用程序服务器当然“包含”插件和应用程序，但这对于序列图是否重要？
在这种情况下，您是否只是将这三件事作为 3 条泳道将应用服务器作为操作的大脑，或者您是否会做一些不同的事情来表明插件和应用程序都不会以独立的方式做很多事情?
出色地，
两者都是有效的......
这取决于您将使用序列图的目的。
> We draw a diagram since we have a purpose.... So Ask yourself which
> one help me more about solving my problem at hand? Which one is
> helpfull for my purpose?
在序列中包含元素的“内在生命”可能有充分的理由。有时您确实希望提供尽可能完整和详细的信息，例如，如果您要提交设计以供安全审查 - 那么抽象是不行的；您需要准确显示实际发生的情况。
换句话说，与其说是 UML 最佳实践的问题，不如说是您需要向哪些特定受众传达什么确切信息。
Sparx Systems 的 Enterprise Architect 允许您在序列中包含嵌入式元素（例如端口或提供的接口），但老实说，我不知道这是否符合 UML。无论如何，这里有一个例子。微不足道，但你明白了：
这是在提炼我对规范的了解、阅读的内容和经验。
不，序列图是显示行为，组件关系是结构的一部分。UML规范和书籍都是这样分解的，结构图和行为图；Wiki 提供了这方面的图像。 两者都使用了类等一些模型元素，但关系和组合实际上不是这个意义上的。此外，行为图旨在显示执行路径，通常不是“完整的”。从这个意义上说，结构图和组件关系更加具体和明确。您始终可以使用颜色代码、使用全名或构造型来丰富视图，但就模型而言，标准图表符号没有。