代码之家  ›  专栏  ›  技术社区  ›  Christophe

UML通信图中涉及的对象之间的关系

  •  0
  • Christophe  · 技术社区  · 3 年前

    简言之

    在UML通信图中,相互交互的对象在视觉上用线连接,有序的消息可以沿着线在两个方向上循环。对象之间的线通常表示链接,即关联的实例。但对象可以交换消息,即使它们没有关联(例如,如果一个对象作为参数传递或返回给另一个)。

    我希望在不相关联的对象之间表示这样的消息交换。但我想澄清一下,所涉及的对象之间没有直接的关联。UML规范是否允许在不创建用户定义的构造型的情况下表达这一点?

    此外,当前的UML规范是否在某个地方定义了交互通信图中对象之间关系的术语?是否可以在图中进一步指定通信对象是如何相互了解的?

    提问前做了更多的研究

    我目前正在重读“ UML用户指南,第2版 “由Grady Booch、James Rumbaugh和Ivar Jacobson撰写,这是一本以读者友好的明文解释UML规范的伟大书籍。这是该书的更新版UML2,我可以将其大部分主张映射回UML 2.5.1规范。

    然而,在关于交互的第16章中,他们解释了对象通过链接进行通信:

    链接指定一条路径,一个对象可以沿着该路径将消息发送到另一个(或同一个)对象。(…)如果您需要更精确地了解该路径的存在方式,可以使用以下约束之一来装饰链接的适当一端:

    • 关联:(…)对象通过关联可见
    • self:(…)对象可见,因为它是操作的调度程序
    • global:(…)对象可见,因为它位于封闭范围内
    • local:(…)对象可见,因为它在本地作用域中
    • parameter:(…)对象可见,因为它是一个参数

    在第19章中,他们为通信图解释了交互中涉及的对象是相互关联的:

    将连接这些对象的链接渲染为此图的圆弧。链接可能有用于识别它们的角色名。最后,用对象发送和接收的消息来装饰这些链接。

    这似乎很简单。因此,我查找了相应的UML 2.5.1规范:

    • 链接仅定义为关联的实例。
    • 对于通信图,在第17.9节中根本没有提及链路或通信信道。图17.26显示了相互连接的对象(即生命线),但连接对象的线和表示沿线消息的箭头似乎都被图形定义为“消息”。这在我看来很含糊。
    • 此外,我还没有发现任何关于约束、关键字或预定义刻板印象的参考,这些约束、关键字和刻板印象可以描述对象如何在特定的图表中相互了解,并可以证明它们之间的沟通渠道是合理的。
    • 我可以找到 «association» , «local» , «global» , «parameter» (与上面的含义相同)在过时的UML1.4规范中被定义为原型,但在当前规范中不再存在。

    因此,我提出了这个问题。

    0 回复  |  直到 3 年前
        1
  •  1
  •   Christophe    3 年前

    规范没有明确说明这一点,但我认为这是所使用链接的定义:

    当两个对象可以相互作用时,就称它们是链接的。

    规范中有几个地方谈到了链接。我在11.2.3.3中发现的最普遍的一个

    每个链接都可以通过指针这样简单的东西来实现,或者通过 像网络连接这样复杂的东西,并且可能代表 实例能够通信的可能性,因为它们 身份是通过作为参数传入而已知的 在变量或槽中,甚至因为通信实例 是相同的实例。

    由此,我得出了我的简单定义。

    所以,我不同意,链接不是 “仅定义为关联实例” 。这种误解可能源于这样一个事实,即使用InstanceSpecification指定链接仅适用于关联:每个想要为链接的InstanceSpecification提供插槽的InstanceSpecifications都必须有一个Association作为分类器。但是-链接可以存在,即使没有指定它们。它们可以由其他模型元素指定。

    指定模型元素的其他链接包括 连接器 在复合结构图中或 信息 在交互图中或 属性 参数 在类图中。

    沟通图只是展示互动的一种方式。它们具有与序列图相同的底层元模型实例。因此,即使生命线之间有线,也没有相应的模型元素。它们只是为了有一个连接消息符号的位置(见表17.4通信图中包含的图形路径)。

    消息可以引用连接器。因此,您可以将通信图中的线视为该连接器的可视化表示。但是,没有必要对连接器进行明确的建模。有些工具需要连接器,但在规范中,连接器是可选的。

    正如你所说,没有刻板印象来描述物体是如何相互了解的。你需要定义自己的。然而,还有其他可能性:生命线表示一个可连接的元素,它可以是参数或属性(或变量,但没有人使用它们)。通过查看所表示的属性,可以发现它是全局属性还是局部属性,以及它是关联端。

    话虽如此,但有一个陷阱。正式表示的所有元素必须直接或间接属于交互的上下文类(17.12.17.5中的same_classifier约束)。在我遇到的大多数情况下,这种上下文只是系统。这意味着,所有属性都必须是全局的。我与本节的作者进行了长时间的交谈,发现其想法是,交互应该属于协作,与系统的连接是通过CollaborationUses和roleBindings实现的。这就是为什么MagicDraw会自动为每个交互创建协作的原因。

    这增加了另一个间接级别,正如我们所知,它解决了;-)计算机科学中的所有问题。幸运的是,大多数工具都没有强制执行这一规则,所以我们可以自由地让生命线表示系统真实组件的属性和参数。