Modelling these roles using actors in a use case analysis

Question

I am modelling a system that has (amongst others), these types of roles:

1. Individual player
2. 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 ?.

Answer 1

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.

Answer 2

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.

Answer 3

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.