UML 连接器方向
在 UML 组件图中对架构进行建模时，如何同时显示连接器的各种属性？ 就像
- 业务对象信息流（A->B、B->A、A<->B）
- 请求/响应方向
- 同步/异步行为一样，
我知道其他图表类型，例如序列图。 然而，让这些信息在组件图中可见是有价值的。
除了关联（仅显示组件已连接）或“棒棒糖”（请求/响应）之外，还有什么可能？
When modelling an architecture in UML component diagrams, how do you show various attributes of connectors simultaneously? Like
- business object information flow (A->B, B->A, A<->B)
- request/response direction
- synchronous/asynchronous behaviour
I am aware of other diagram types like sequence diagrams. However, having this information visible in component diagrams would have value.
What is possible beyond associations (merely showing that components are connected) or "lollipops" (request/response)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能想使用序列图而不是类（即组件）图。
如果您想坚持使用静态图，您可能还需要考虑添加 << 刻板印象>> 到各种连接器，甚至使用关联类。
如果可能，您可以使用序列图中的连接器来连接组件图中的分类器（例如，同步/异步消息传递箭头）。
You might want to use sequence diagrams instead of class (i.e, component) diagrams.
If you want to stick to a static diagram, you may also want to consider adding << sterotypes>> to various connectors, or even use association classes.
If possible, you can use connectors from sequence diagrams to connect classifiers in component diagrams (e.g., synchronous/asynchronous message-passing arrows).
首先，不要尝试使用类图上的连接器来解释这些动态协作。
类图上箭头连接器的方向只是指定谁知道谁。 这意味着类之间的依赖关系。 通过这些箭头，您可以传达哪些类需要哪些其他类，但您不必解释这些类之间的协作如何。 这就是 UML 动态图的用途。
从类图（系统的静态视图）开始，然后添加一些动态图。
作为动态图，与最常见的序列图一起，您还可以使用：
每个图都有自己的兴趣点，主要策略是重用类图中定义的一些对象以便描述具体的场景。
对于系统上的每一种“有趣”场景，您应该制作这些动态图之一来描述您在类图上指定的对象之间发生的情况。
通常，每个用例将由一个类图和一个或多个动态图来描述。 所有这些设计信息一起称为用例实现，因为它们描述了在构建代码时将使您的用例真实的设计。
查看 Fowler 的 UML Distilled，了解此设计工作流程的简洁但出色的解释，使用统一建模语言。
For a start, don't try to explain these dynamic collaborations using the connectors on your class diagram.
The direction of the arrow connectors on the class diagram just specifies the who knows who. That means, the dependencies between classes. With those arrows you can communicate which classes need what other classes, but you don't have to explain there how are the dynamics of the collaboration between those clases. That's what UML dynamic diagrams are for.
Start with your class diagram, which is the static view of the system, and then add some dynamic diagrams.
As dynamic diagrams, together with sequence diagrams that are the most common, you can also use:
Each has its own point of interest, and the main strategy is that you reuse some of the objects defined in your class diagram in order to describe specific scenarios.
For each one of the 'interesting' scenarios on your system, you should make one of these dynamic diagrams to describe what happens between the objects that you specified on your class diagram.
Typically, each use case will be described by one class diagram and one or more dynamic diagrams. All these design information together is called the use case realization, because they describe the design that will make your use case real when the code is built.
Check out Fowler's UML Distilled for a concise but excellent explanation of this design workflow using UML.
您可以使用信息流关系，如 UML 上层结构 17.2 节中所述：
You can use the InformationFlow relationship, as described in section 17.2 of the UML Superstructure: