用例图中的关联方向

Question

在UML用例图中，演员和用例之间的关联方向是什么意思？它是数据流方向还是控制流方向？标准是否对此有任何规定？

- mkaul

Answer 1

啊不，这是一个关联。在规范中，演员和用例之间的关联没有方向性。请参见从规范中提取的图像。

使用方法是：如果演员在左边，则表示这是一个“主要演员”，即激活用例的演员。如果演员在右边，则表示该演员是次要演员：他参与用例但不激活它。

请注意多重性：“示例显示客户或管理员可以或可以不参与其关联的任何UseCases（因此是0..1多重性）。从UseCase的角度看，每个示例中的UseCase都必须有一个Actor来启动它（因此是1多重性）。存款和注册ATM UseCases需要银行的参与，而银行可以同时参与许多存款和注册ATM UseCases。”（摘自p641）

关键是，如果您有很多演员，则将它们保留在左侧或右侧并不容易。因此，“我”（但这是我的方式，而不是规范）使用有向关联，如果这是从演员到用例的关联，则表示该演员是主要演员；如果这是从用例到演员的关联，则表示这是次要演员。

- granier

---

你忘记了图片。与其说规范，不如说UML规范。左右应该加上“在考虑系统的边界内”。最后：这只是一个广泛使用的惯例。 - qwerty_so

OMG不是一个规范组织，而只是由许多公司支持的松散组织。相比之下，ISO是一个政府组织，制定标准。“考虑中的系统”（SUC）是一个常见术语。您不需要在用例图中对边界进行刻板印象的刻画，因为它会隐含地表示SUC。In/out和left/right也是（被接受的）惯例，在UML中没有具体说明。（嘿嘿，现在我的回答在你的评论前面了） - qwerty_so

图片马上就要来了 :) 对于你而言，规范与规范机构不同，因为UML并非由一个规范机构编写的？为什么不呢。至于系统，这很奇怪，但没有元类System，有一个模型可以应用Stereotype SystemModel，但我认为没有元类System或SystemBoundary。因此，当我建模用例时，我尽量避免谈论系统。根据定义，用例在系统内部，而演员在外部。 - granier

啊，顺便提一下：在图表中使用正确的谓语-主语（-宾语）UC名称。而且这些多重性没有任何意义。哦不。它们来自UML规范。他们应该为此付出代价 >:-( - qwerty_so

关于“SUC”，元类SystemBoundary会很有用，因为大多数UML用户在建模用例时会绘制一个矩形来显示系统边界。关于规范或规范，即使我不确定这在这里是否有意义，你也是正确的。 - granier

Answer 2

在UC图中，箭头的方向没有统一的含义。我曾使用有向和无向箭头来区分主要和次要参与者（并将其写入域建模指令中）。我不是唯一这样做的人。后来我才知道（正如@granier所指出的那样），将主要参与者放在系统边界的左侧，将次要参与者放在右侧也很常见。

注：正如@granier所评论的那样，UML规范中的UC内容太过技术化。其中一些内容像include/extend被错误地视为功能分解。@granier从规范中摘出的图片甚至缺乏UC名称的良好措辞。我宁愿去读Bittner/Spence的书，他们真正了解业务术语。

- qwerty_so