UML 序列图和组件关系
这是在与一位同事的讨论中提出的，作为思考的内容 - 在 UML 序列图中处理组件和子组件之间的关系的技术上合适的方法是什么。
那么问题来了 - 在 UML 最佳实践中，序列图是否应该与图中描述的对象的关系有任何联系？我的直觉是不会——绘制一个序列图，其中每个组件都是单独的，然后用类图或部署图来显示正在发挥作用的其他类型的关系。
如果你说“是！”请向我提供一些很好的例子，说明您会如何以及为何采取不同的做法。
如果“否”，您能否向我指出一些可靠的在线参考资料来证明其合理性？我尝试了 UML 规范，然后……哦！ ...这不是我想要的，除非我试图让自己失去知觉。
具体来说，这是我的示例 - 我想对应用程序服务器如何调用安全插件然后调用已使用 JSP 和 Java 部署的基本应用程序的序列图进行建模。应用程序服务器当然“包含”插件和应用程序，但这对于序列图来说还重要吗？
在这种情况下，您是否会将这三件事作为 3 个泳道，将应用程序服务器作为操作的大脑，或者您会做一些不同的事情来表明插件和应用程序都不会以独立的方式执行大部分操作？
This came up in a discussion with a coworker as food for thought - what's the technically appropriate way to handle the relationship between components and sub components in a UML sequence diagram.
So here's the question - in UML best practices, should a sequence diagram have any connection to the relationship to the objects being described in the diagram? My instinct would be no - draw a sequence diagram with each component separate and follow it up with class diagrams or deployment diagrams to show the other types of relationships in play.
If you say "YES!" please fill me in with some good examples of how and why you would do differently.
If "No", can you point me to some credible online references for justification? I tried the UML spec and ... oy! ... not what I wanted unless i was trying to beat myself unconscious.
In a specific, here was my example - I want to model a sequence diagram of how an application server calls a security plug in and then calls the basic application that has been deployed with JSP and Java. The application server certainly "contains" the plugin and the application, but does that even matter for a sequence diagram?
In that situation would you just throw the three things up as 3 swimlanes with the app server as the brains of the operation, or would you do something different to show that neither the plugin nor the application would be doing much of anything in a standlone way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，
两者都是有效的......
这取决于您使用序列图的目的。
Well,
Both are valid....
It depends on for what purpose you will use your sequence diagrams.
这是我对规范的了解、我读过的内容和经验的总结。
不。序列图是为了显示行为，组件关系是结构的一部分。 UML规范和书籍都是这样细分的，结构图和行为图； Wiki 提供了这样的图像。 两者都使用了一些模型元素，例如类等，但是关系和构图实际上不是这个意义上的。此外，行为图旨在显示执行路径，通常并不“完整”。从这个意义上说，结构图和组件关系更加具体和明确。您始终可以使用颜色代码、使用全名或构造型来丰富视图，但就模型而言，标准图符号没有。
This is distilling down what I know about the spec, what I have read, and experiences.
No. A sequence diagram is to show behavior and the component relationship are part of the structure. The UML spec and books are broken down this way, structure diagrams and behavior diagrams; Wiki provides an image of this. Some model elements like class etc are used in both, but relationships and composition really are not in this sense. Besides, behavior diagrams are meant to show execution paths and are not typically "complete". The structure diagrams and component relationships are more concrete and definitive in that sense. You can always color code, use full names, or stereotypes to enrich view, but as far as the model is concerned and standard diagram notation no.
在序列中包含元素的“内部生命”可能有充分的理由。有时您确实希望提供尽可能完整和详细的信息，例如，如果您要提交设计进行安全审查，那么抽象是不行的；你需要准确地展示实际发生的情况。
换句话说，与其说是 UML 最佳实践的问题，不如说是您需要向哪些特定受众传达哪些确切信息的问题。
Sparx Systems 的 Enterprise Architect 允许您在序列中包含嵌入式元素（例如端口或提供的接口），但说实话，我自己不知道这是否符合 UML。无论如何，这是一个例子。微不足道，但您明白了：
There can be good reasons to include an element's "inner life" in a sequence. Sometimes you do want to provide as complete and detailed information as possible, for instance if you are submitting your design for a security review - then abstractions are no-go; you need to show precisely what's actually going on.
In other words, it isn't so much a question of UML best practice as of what exact information you need to convey to which specific audience.
Enterprise Architect from Sparx Systems allows you to include embedded elements (eg ports or provided interfaces) in a sequence, but in all honesty I don't know myself whether this is UML compliant or not. In any case, here's an example. Trivial, but you get the idea: