0

Hi,

Please, this isn't about opinions on uml, it's usefulness (or lack thereof), it's standing, etc - please (I'm so tired)!

I have a text usage case which main success scenario is thus:

A) Two Players.
B) Each player is prompted to enter their name
C) Program randomly selects which is to be player 1 and the other is player 2
D) Player 1 selects a coin option (either "heads" or "tails")
E) Player 2 gets the other option
F) Program randomly produces a coin toss result ("heads" or "tails")
G) Result of toss is compared with each player's coin option and result is printed to screen
H) One of the players "wins" and the other "looses"

The problem I don't understand is how to represent something like this in a use case diagram. How many actors and their names? Why? What to have the use cases cover, and how may? Why?

Here's the problem/my confusion:

Regarding actors

On the one hand, player 1 and player 2 share a very fundamental commonality (ie: they are both 'players'). So, in that sense, a person should be able to just use one primary actor named player with a multiplicity of 2. Unfortunately though, theres a problem with this. While there is one thing that both players 'do' the same (enter their name) there's another thing that is not the same for both players (one of them gets to choose a coin option while the other has no choice - he get's whatever is left/ the 'other' option). That being so, how could you use only one primary actor "player"?

Alternatively, if you make two primary actors "player 1" and "player 2", it seems to me they would have completely distinct use cases and the diagram would make it look like each actor had it's own system (player 1 having a use case about choosing a coin option and player 2 having a use case where he gets the other option - ie: two separate use cases to go with those two separate actors and no connections between them).

Bottom line, how do I integrate all this into a use case that makes sense?

Thanks in advance for any help with this.

Jake

Edited by ClientAlive: stupid code block and its line numbers (grrr)

2
Contributors
2
Replies
8
Views
4 Years
Discussion Span
Last Post by ClientAlive
0

Interesting. I never thought of using extensions like that.

With what you show, there's one thing I don't get. Does that way commuincate how the stystem is dependent on the players entering certain data (name, coin option) at certain stages of the execution? Is a use case even the place for that type of information anyway or am I off base with that question? I'm new to all this so not real familiar with what all is communicated there.

Here's what I played around with last night a little bit. Still, I'm not terribly confident it's all that clear or descriptive. Seems cluttery too.

thx.

CoinTossProgram

Edited by ClientAlive: Added question/request for clarification.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.