Jakarta ee UML序列图和组件关系

这是在与一位同事的讨论中提出的，作为思考的食粮——在UML序列图中处理组件和子组件之间关系的技术上合适的方法是什么

所以这里有一个问题——在UML最佳实践中，序列图应该与图中描述的对象的关系有任何联系吗？我的直觉是否定的——画一个序列图，每个组件都是独立的，然后用类图或部署图来显示其他类型的关系

如果你说“是的”，请给我举一些好例子，说明你将如何以及为什么做得不同

如果是“否”，你能给我指一些可信的在线参考资料来说明理由吗？我尝试了UML规范并且。。。哎呀。。。不是我想要的，除非我试图把自己打晕

在一个特定的示例中，这里是我的示例—我想建模一个序列图，说明应用程序服务器如何调用安全插件，然后调用使用JSP和Java部署的基本应用程序。应用服务器当然“包含”了插件和应用程序，但这对序列图有影响吗

---

在这种情况下，你会将这三个东西作为3个泳道，以应用服务器作为操作的大脑，还是会做一些不同的事情来表明插件和应用程序都不会以独立的方式做很多事情？

这是我对规范的了解，我读过的内容，和经验

不可以。序列图是用来显示行为的，组件关系是结构的一部分。UML规范和书籍是这样分解的，结构图和行为图；一些模型元素，如class等，在这两种语言中都有使用，但关系和组合实际上并不是在这个意义上。此外，行为图旨在显示执行路径，通常不“完整”。从这个意义上讲，结构图和组件关系更加具体和明确。您始终可以使用颜色代码、全名或原型来丰富视图，但就模型和标准图表符号编号而言

两者都是有效的

这取决于使用序列图的目的

> 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。无论如何，这里有一个例子。琐碎，但你明白了：