Heys guys! Im have been study UML and im trying to to design the use case diagram of a problem.
Lets supose my app consists in this:
Two Requesites: - create teams - create players
This is the deal: A user can create a team, and after create a team he can create players for that team(not required). But in this app there are multiple users, and a user can create a team and other user can create players. The only constraint is that to create players must exist alreay a team. I research and i end up a little confuse. If i get the concepts of relations on use case diagrams right, i think i should have the folowwing two use cases:
[use case - create team] <-------extends---- [use case - create player]
I need opinions,Is this the proper solution? or should i have two not related use cases?
Thanks in advance, and im sorry my english.
Generally you do not need to model dependencies like "A must be done before doing B" in a Use Case Diagram. Use Cases should represent a set of Szenarios to group them as a common case.
The "extends" dependency is used to specify a Use Case which is more special than the extended one. So, if you would like to express that creating a player is a special form of creating a team using "extend" would be fine. Bbut this does not match the situation described above.
If you would like to express that creating a playing always means to create a team as well, you can use an "include" dependency. This could match your case but imo does not entirely.
The final option is to draw an unspecified dependency (no << >> marker) the express that the use cases have something todo with each other.
My recommendation: don't use any dependency in this case.
Some more good explanations can be found here, btw.
There is a common problem with use cases: relations. We tend to use relations to describe the sequence of use cases. But this is a misconception. Here are some words from The UML User Guide about Use Cases and Flow of Events (part 4, chapter 17):
The point is that, if the guide tends to say (implicitly) that relationships should not be used to specify flow of events, it does not say what the use cases relations should be used for. I think this is the reason why use cases are an important point of UML and UP but a tool very difficult to handle.
In your model, you should perhaps change the arrow and the term (simple suggestion, you are the analyst):
This should be represented on your diagram if you want to emphasize the constraint, but not as a representation of the sequence of operations (subtle distinction).
The extends terms is usually associated to generalization / specialization. And in my opinion this is not the kind of relationship you have between a team and a user creation. The example given by the guide is the following (part 4, chapter 18):
That said, modelling the specialization of use case is most of time of limited interest. But sometimes this is needed, it depends on the use cases description: if both are equal you don't, if not you do. An advised programmer knows that specialization does not imply equal assertions.