3

我正在建模一个具有（除其他外）这些类型的角色的系统：

  1. 个人球员
  2. 团体选手

以下是一些额外的事实：

  • 单个播放器有一组功能要求
  • 有几种类型的团体玩家（例如射手，导航员，工程师等）
  • 组播放器的选择（即类型）会影响播放器可用的功能
  • 团体玩家的功能是以下各项的结合： (a) 单个玩家可以做的事情的子集 (b)（可选），基于角色的一些附加要求（例如，肉搏战等）。

我可以将演员抽象为通用 Player 的专业化 - 但我不太确定如何将它们“组合在一起”作为系统“形式分析”的一部分。

任何人都可以帮忙吗？

4

3 回答 3

1

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

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

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

无论如何，大约在您发现自己将给定的参与者分解为子参与者的时候，您可能想要开始在单独的图表中对参与者进行实际建模 - 或在层次结构中描绘它们。这可以帮助您摆脱任何不一致和交叉关系。

然后，随着您对用例的深入研究，您实际上将开始描述和定义您的参与者。

于 2011-09-20T15:51:55.627 回答
0

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

总结actor泛化的原因不是为了能够对角色建模，而是为了重用相关的用例。

于 2011-08-03T12:25:43.120 回答
0

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

于 2011-08-03T12:32:35.867 回答