我正在为一个系统建模，该系统(除其他外)具有以下类型的角色:
- 个人玩家 <
- 组球员/gh>
下面是一些额外的事实:
- 对于单个玩家有一组功能需求
- 有几种类型的团队球员(如射手，领航员，工程师等)
- 组玩家的选择(即类型)影响玩家可用的功能
- 团队玩家的功能是:(a)单个玩家可以做的事情的子集(b)(可选)，基于角色的一些额外要求(例如，肉搏战等)。
我可以抽象出参与者，作为一个通用玩家的专门化——但我不太确定如何将其"整合在一起"作为系统的"形式分析"的一部分。
用例和用例模型都使用角色。最初，在用例模型级别上，您将希望通过用例和与这些用例交互的参与者来图形化地描述高级功能。
从你的描述中，听起来个人玩家是一个演员，而团体玩家是一个角色。角色是关于管理的，您可能需要一个处理管理的用例。
所以你的射手，领航员和工程师演员都是玩家类型。你的射手，导航员和工程师角色将成为你的团队角色。定义这些Marksman, Navigator和Engineer角色交互的功能的用例不会处理角色，因为角色是"如何"实现的。
无论如何，当您发现自己将一个给定的参与者分解为子参与者时，您可能想要开始在一个单独的图中对参与者进行实际建模——或者在一个层次结构中描述它们。这可以帮助你摆脱任何不一致和交叉关系。
然后，当您更深入地研究您的用例时，您将实际上开始描述和定义您的参与者。
据说，用例中的参与者表示与系统交互的角色。然而，参与者的作用是识别，而不是描述，因此您不能仅基于参与者模型创建授权系统。对于您的情况，这意味着您必须将玩家识别为参与者，并且根据这些参与者可用的用例可能存在一些一般类别。当然，您可以像在您的案例中那样进入较低的层次，但是这样就丢失了用例的价值。所以我会考虑使用类图来详细描述不同类型的玩家。另一点是，一个用户(在你的例子中是参与者)可以扮演多个参与者的角色(例如，一个组参与者的具体类型)，所以你可以看到，角色(参与者)的组合和生命周期在用例中丢失了。
总结一下，角色泛化的原因不是为了能够建模角色，而是为了重用相关的用例。
用例分析阐明软件做什么，而不是如何做。因此，如果您的任务是描述不同角色的不同功能以及它们如何被聚合，那么请尝试建立一个类图来显示角色和功能之间的一般关系。或者为每个角色建立一个对象图，举例地显示这些关系。