在用例分析中使用参与者对这些角色进行建模
我正在建模一个具有(除其他外)以下类型角色的系统:
- 个人玩家
- 团体玩家
以下是一些额外的事实:
- 个人玩家有一组功能要求
- 团体玩家有多种类型(例如标记员、导航员) 、工程师等)
- 群组播放器的选择(即类型)会影响播放器可用的功能
- 群组播放器的功能是以下各项的并集: (a) 单个玩家可以做的事情的子集 (b)(可选),一些基于角色的附加要求(例如肉搏战等)。
我可以将参与者抽象为通用玩家的专业化 - 但我不太确定如何将其“组合在一起”作为系统“形式分析”的一部分。
有人可以帮忙吗?
I am modelling a system that has (amongst others), these types of roles:
- Individual player
- Group player
Here are some additional facts:
- There is a set of functional requirements for an individual player
- There are several types of group players (for e.g.marksman, navigator, engineer etc)
- The choice (i.e. type) of group player, influences what functionality is available to the player
- The functionality of a group player is the union of:
(a) a subset of the things that an individual player can do
(b) (optionally), some additional requirements based on the role (e.g. hand to hand combat etc).
I can abstract the actors, as specializations of a generic Player - but I'm not quite sure how to "fit it all together" as part of the "formal analysis" of the system.
Can anyone help ?.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
用例和用例模型都利用参与者。最初,在用例模型级别,您将希望通过用例以图形方式描述高级功能以及与这些用例交互的参与者。
从你的描述来看,个人玩家是演员,团体玩家是角色。角色与管理有关,您可能需要一个处理管理的用例。
所以你的射手、导航员和工程师演员都将是一种玩家类型。您的射手、导航员和工程师角色将是您的团队角色。定义这些射手、导航员和工程师参与者交互的功能的用例不会处理角色,因为角色是它实现的“方式”。
无论如何,大约在您发现自己将给定演员分解为子演员时,您可能想要开始在单独的图表中实际对演员进行建模 - 或在层次结构中描绘它们。这可以帮助您消除任何不一致和交叉关系。
然后,当您更深入地研究用例时,您实际上将开始描述和定义参与者。
Both use cases and use case models utilize actors. Initially, at the use case model level you will want to graphically depict both the high-level functionality via use cases and the actors that interact with those use cases.
From your description, it sounds like an Individual Player is an actor and a Group Player is a role. Roles are about administration and you might want a use case(s) that deals with administration.
So your Marksman, Navigator and Engineer actors would all be a type of Player. Your Marksmen, Navigators and Engineers roles would be your group roles. The use cases defining the functionality these Marksman, Navigator and Engineer actors interact with wouldn't deal with roles because roles are the "how" it gets implemented.
Anyway, at about the time you find yourself breaking a given actor into sub-actors, you may want to start actually modeling the actors - or depicting them in a hierarchy - in a separate diagram. This helps you shake out any inconsistancies and cross-relationships.
Then, as you delve more deeply into your use cases, you will actually start describing and defining your actors.
据说,用例中的参与者代表与系统交互的角色。然而,参与者的目的是识别,而不是描述,因此你不能创建例如仅基于参与者模型的授权系统。对于您的情况,这意味着您必须将玩家识别为演员,并且根据这些演员可用的用例,可能有一些常规类别。当然,您可以按照您的情况进入低级别,但这样用例的价值就会丢失。所以我会考虑使用类图来详细说明不同类别的玩家。另一点是,一个用户(您的情况下的玩家)可以扮演多个参与者的角色(例如,团体玩家的具体类型),因此您可以看到,角色(参与者)的组成和生命周期在用例中丢失了。
总结一下参与者泛化的原因不是能够对角色进行建模,而是能够重用相关的用例。
It is said, that actors in use cases represent roles interacting with the system. However, the point of actors is to identify, not describe, therefore you cannot create e.g. an authorization system based solely on the actor model. For your case, this means you have to identify a player as an actor and there might be some general categories according to use cases available for those actors. Of course, you can go to the low level as in your case, but then the value of use cases gets lost. So I would consider using class diagram to detail various categories of players. Another point is, that one user (player in your case) can take role of multiple actors (e.g. concrete type of a group player), so you can see, that the role (actor) composition and lifecycle is lost in a use case.
To summarize the reason for actor generalization is not to be able to model roles, but to reuse associated use cases.
用例分析阐明了软件做什么,而不是如何做。因此,如果您的任务是描述不同角色的不同功能以及如何聚合它们,请尝试建立一个类图来显示角色和功能之间的一般关系。或者为每个角色设置一个对象图来示例性地显示这些关系。
The use case analysis clarifies what a software does and not how. So if your task is to describe the different capabilities of the different roles and how they can be aggregated, try to set up a class diagram showing the general relation between role and functionality. Or set up an object diagram for each of your roles showing these relations exemplarily.