如何参数化UML序列图并将其应用于多个对象实例？

我想创建一个序列图来显示一些交互，然后将该序列图用作其他序列图上的交互事件（子序列）。重点是，我希望每次都将子序列应用于子序列中交互所涉及的不同对象实例。在我的例子中，这些实例只是各种文件工件。是否有UML规定的合法方法来实现这一点

编辑：进一步澄清我的背景：

• 我有两个主序列图，我想在其中重用子序列作为交互事件
• 在第一个主序列上，有一个文件必须应用子序列3次
• 在第二个主序列上，有3个不同的文件，子序列必须应用3次
• 这些文件由同一对象实例读取
• 我通过一个原型为
  的调用箭头来模拟从一个文件读取到一个表示该文件的对象实例

---

我需要在子序列中以某种方式引用该文件，但我还没有找到一种简单有效的方法。

基本上有三种不同的方法来指定这种情况

使用闸门。Whith gates可以指定消息序列，这些消息在定义的gate处开始或结束，并且在大多数工具（如果可用）中没有明确显示。相反，它是用在交互边界开始或结束的消息建模的

类似于门的是失物招领信息。这些是将控件传递给另一个序列或从另一个序列返回的特殊消息。例如，在您可以定义一组更详细地指定交互的进一步图表之前

使用抽象，这在大多数情况下是我最喜欢的。这意味着您从类中提取公共接口，并指定与接口的交互，而不是具体的类

复杂但形式上（几乎）正确的协作解决方案

仅仅使用InteractionUses是不够的，因为这不允许您将主交互中的实际角色分配给所用交互的通用角色

协作、协作使用和角色绑定可用于此目的。 请参见我的示例： 这定义了与通用角色发送者、接力者和接受者的协作，并显示了它们之间的交互

现在，您可以在具体情况下使用此协作： 类S使用协作两次，并将不同的角色绑定到其部分（假定A、B和C能够发送和接收Sig1）

使用这些定义，您现在可以创建主序列图： 不幸的是，这不是正确的UML，即使规范中有一个示例（我提交了一个问题）。在工作组找到解决方案之前，你必须伪造这个符号。如何伪造它，取决于您的工具实现规范的严格程度

优势：规范中的一个示例支持正式正确且通用的解决方案

---

缺点：复杂且难以解释，由于规范中存在缺陷，无法完全使用

使用与参数的交互：

现在我们想在InteractionUse的参数中引用主要交互的生命线。不幸的是，在UML中这是不可能的，因为参数是ValueSpecification，它们不能引用另一个modelelement

然而，NoMagic并实现了一个额外的ValueSpecification，称为ElementValue，它正是这样做的。我认为这将是对UML的一个有价值的补充，希望有一天它会被添加。到那时为止，只有MagicDraw用户可以使用此解决方案（据我所知）

使用此非标准元素，我们可以对其进行建模：

生命线之间的连接现在是通过泛型交互参数的参数实现的。从技术上讲，交互使用不需要明确地覆盖生命线，但我认为这样做是有意义的（如我的工具所示，交互使用的边界上有一个非标准的圆圈）

优势： 紧凑、通用的解决方案，几乎符合标准

缺点：

---

使用非标准模型元素，当前仅适用于MagicDraw用户。

实用的非一致性解决方案，带覆盖生命线：

协作和参数解决方案允许（几乎）正式地指定它。然而，在许多情况下，简化模型就足够了。例如，在您的案例中，您只有两个参与者，他们有不同的类型。因此，即使所使用的交互的生命线与主交互的生命线之间没有正式的联系，也不会有歧义。您可以使用InteractionUse的covered属性来指定针对特定InteractionUse的生命线（文件）。这可能是你正在寻找的务实解决方案吗

优势： 紧解

缺点：

---

不符合UML，在更复杂的情况下模棱两可

我不经常使用它，但图门应该是您要寻找的？我不知道，这是如何解决问题的。它要求相同的交互与不同的参与者重复使用多次。盖茨只能部分解决这个问题，因为只有使用过的交互的外部参与者才能改变。其中的消息将始终使用相同的参与者。丢失和找回的邮件不允许指定接收者或发送者，因此不会发生交互。抽象肯定是一件好事，但是它不允许指定交互使用的顺序