在用例分析中使用actor对这些角色进行建模

Question

我正在建模一个系统，其中包含（以及其他）这些类型的角色：

1. 个人球员
2. 小组玩家

以下是一些其他事实：

• 单个玩家有一系列功能要求
• 有几种类型的团体玩家（例如，标记员，导航员，工程师等）
• 群组播放器的选择（即类型）会影响播放器可用的功能
• 群组玩家的功能是： （a）个人玩家可以做的事情的一部分 （b）（可选），基于角色的一些额外要求（例如，手拉手等）。

我可以抽象演员，作为通用播放器的特殊化 - 但我不太确定如何“将它们整合在一起”作为系统“正式分析”的一部分。

有人可以帮忙吗？。

Answer 1

用例和用例模型都使用actor。最初，在用例模型级别，您将希望以图形方式描述通过用例的高级功能和与这些用例交互的actor。

根据您的描述，听起来像个人玩家是演员而团队玩家是角色。角色是关于管理的，您可能需要一个处理管理的用例。

所以你的射手，导航员和工程师演员都是一种玩家。您的Marksmen，Navigators和Engineers角色将成为您的团队角色。定义这些Marksman，Navigator和Engineer actor与之交互的功能的用例不会处理角色，因为角色是它实现的“方式”。

无论如何，在您发现自己将某个演员分解为子演员的时候，您可能想要在单独的图表中开始实际建模演员 - 或者在层次结构中描绘演员。这可以帮助您摆脱任何不一致和交叉关系。

然后，当您深入研究用例时，您将真正开始描述和定义您的演员。

Answer 2

据说，用例中的参与者代表与系统交互的角色。然而，演员的观点是识别，而不是描述，因此你不能创造例如仅基于演员模型的授权系统。对于您的情况，这意味着您必须将玩家识别为演员，并且根据可用于这些演员的用例，可能存在一些常规类别。当然，您可以像在您的情况下那样进入低级别，但随后用例的值会丢失。所以我会考虑使用类图来详细说明不同类别的玩家。另一点是，一个用户（在你的情况下是玩家）可以扮演多个角色的角色（例如，具体类型的群组玩家），因此你可以看到角色（演员）的构成和生命周期在用例中丢失了。

总结一下，参与者概括的原因不是能够对角色建模，而是重用相关的用例。

Answer 3

用例分析阐明了软件的功能，而不是软件的功能。因此，如果您的任务是描述不同角色的不同功能以及如何聚合它们，请尝试设置一个类图，显示角色和功能之间的一般关系。或者为每个显示这些关系的角色设置一个对象图。