【问题标题】:Multiple component diagrams of the same system?同一系统的多个组件图?
【发布时间】:2019-06-06 08:09:34
【问题描述】:

我正在制作一个系统的组件图,由于系统的设计,很多依赖线最终会交叉,这使得该图难以阅读和理解。

回避此问题的一种方法是使用单独的组件图来说明系统组件的子集如何依赖于某些组件/接口。例如,对数据存储的依赖关系将在组件图中表示,该图仅涵盖数据存储和直接访问这些数据存储的组件,省略其余组件。但是,我不确定这是否被视为标准做法,甚至是否可以接受。

有谁知道是否可以呈现同一系统的多个组件图?如果不是,还有哪些其他替代方法可以避免图表混乱?

【问题讨论】:

    标签: uml component-diagram


    【解决方案1】:

    是的,这是标准做法。 只有最微不足道的系统才能小到可以在单个图表中表示。

    【讨论】:

      【解决方案2】:

      不同的视图是简化图表复杂性的常用方法。但是,对多个图表的渴望可能有点让人觉得您尝试建模的系统过于复杂。

      考虑从组件图升级到包图,以帮助布局更大的图景。这应该可以帮助您将系统组织成一组组织良好的子系统。对于每个子系统,您可以向下钻取到详细的组件图。

      【讨论】:

      • 我面临的主要问题是系统包含一个消息代理,它提供了大多数组件所需的接口,还有一个数据存储提供了不同的接口所需的接口组件的子集。因此,如果两组接口都在同一张图中表示,那么总是有一些依赖关系箭头会相互交叉。
      • 在组件级别,我将服务总线建模为一种模式。见stackoverflow.com/questions/2480428/…。然后我会使用序列图来模拟个人交互。请记住,服务总线用于解耦系统,因此您的 UML 也应该反映这一点:)
      • 消息总线确实简化了系统和图表,但是一旦每个组件和服务总线接口之间的依赖关系在图表中表示(最终以中心辐射型布局结束),那就很难了在组件之间添加一些额外的依赖项,而不会让它们相互交叉。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2022-07-22
      • 1970-01-01
      • 2010-12-19
      • 1970-01-01
      • 2014-07-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多