If a player could be assigned to a team then the use case would be Assign Player but if a player could also be reassigned then would another use case, Reassign Player, be created, which could include Assign Player?
Or would the single use case of Assign Player be enough and just state the assumption that Assign Player would handle the event of that player being currently assigned?
This depends, as always.
However, this might well be worth a use of an <<includes>> relation. Re-assigning a player might eventually be more complex and in the end you'll just Assign player as usual. Eventually. But as well the re-assignment might be a completely different thing in which case you have two different and independent use cases. Or it's a "don't care of the previous assignment" in which case you have just one single UC Assign player.
Edit As per Patrick87's comment I add the following: A UC represents a single added value a system under consideration delivers to one of its actors. Now, an added value is something unique. Finding that is hard, which is why it need business analysts that know their job. I for myself try seeing a UC as something like a unique selling proposition. It's not obvious in most cases. But once you placed the right bubble it feels right. Don't start decomposing it into single "functions". That's a different story and it can only start after all UCs are settled. Only then you start construction scenarios inside each UC to describe the how-to.
And my general recommendation: read Bittner/Spence who really get to the point.
I do not know what your teams are playing. It could be a game like chess, or a kind of sports like soccer.
So your use case would be something that tells us about the overall goal of your system under construction:
Is it "play soccer game" or "play chess"?
You can decompose that into more fine grained scenarios, as long as you still describe actual goals of your system.
For actual functional decomposition, you should use other diagramtypes, namely activity diagrams, state diagrams and possibly sequence diagrams.
Related
I have a task to make a simple information system for the functioning of a guest house. I need to make a USE CASE diagram, but I don't know if what I've done is correct, or if I need to add something, I don't know where to include the maid.
As users of the system I have put - client, receptionist, manager
As objects of the system I have put client, room, occupied rooms, employees (maids, receptionist, manager), tour agency, payment
Can you give me a hand?
Well, you are at the verge of functional decomposition. And that's not what UCs are about. They are about added value. So the bubbles contain headers describing those added values. For a hotel the basic UC would be Reserve room. (A real hotel would of course offer more added values, but for your example that's it.)
Now, the reservation is usually going along with payment. But would you consider that added value? I would not. So rather than making these UCs they are constraints (from requirements defined elsewhere). There's a lot one could talk about representing requirements and business rules, but that is far too much for a discussion here. I recommend reading Bittner/Spence about UC sythesis. It takes that book and a lot of experience to get familiar with this area.
Note that UCs are described with subject/predicate(/object) to be meaningful. Room is no UC. If you intend to show an object, use a rectangle (with object notation). That however, is in most times more confusing than helpful. Stay with actors and (real!) use cases.
Another note: the downward association from Hotel manager should rather be a generalization (open triangle instead of an arrow). And the actors usually are also shown with arms ;-)
I'm practicing drawing a use case diagram for a very simple case, a color-guessing game.
I don't have a picture but it is really simple, with two bubbles for the Player actor to interact with, Play Game and Reset Game.
I would like to add a condition "initialize game" for both use cases, in Play Game it is a precondition and in Reset Game it is a post condition.
It cannot be another use case because the actor would be then System or Game and that's not feasible. Only Player benefits from performing the two current use cases.
How should I include that condition in the use case diagram? Or should I?
No.
Use cases are about added value. A single use case shows a single added value brought to its primary actor by the system under consideration. Nothing else! Use cases are a very high business view on the system under consideration.
The conditions you are talking about are part of scenarios you design to implement reaching that added value. And it's hidden in activities inside the use cases.
Other conditions like "user must be logged in" are constraints and attached to use cases somehow. No need to show these on a diagram (though you may if needed).
For my homework, I have to write functional requirement of a game called downfall (see Wikipedia).
We have to make this game, but with not two sides but n (any number of) sides.
In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.
I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:
What I dont understand are the following:
Is the number of players functional requirement?
Is the table having two sides a functional requirement?
Is the goal of the game (getting coins from top to bottom) a functional requirement?
Is a rule like coins must reach bottom in order a functional requirement?
If they are, what use case could they belong to? Is my use case diagram wrong?
I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.
About requirements
First, let's handle the requirement question:
A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
is EndTurn an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
you say that RotateDials extends ChooseDials. This means that a player could ChooseDials but not rorate it. Is this a valid scenario ?
if on the other hand you'd say that ChooseDials includes RotateDials, the latter would always happen. But then, wouldn't ChooseDial not be more than just choosing a dial ? Shouldn't it then be called PlayTurn ?
I could understand that for learning purpose, you'd want to decompose the Play game in more detailed use-cases. Typically, once the players try to reach their goal Play game, this might include sub-goals of Play turn. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *).
Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.
There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...
I am creating a small Multiplayer game. It can only be played when there are two players present (not more than that).
In a typical single player game, there should be an Actor called "Player". But in this case there are two players. So is it possible to declare "Player1" and "Player2" as actors?
note: In some of the tasks, either one of them will participate. How can I represent that? (just like entering the high-score [only one of them can be the winner. Both of them cannot be the winner at the same time] ).
Is this correct ?? -
I'd just use a single actor called Player and add a constraint that there need to be exactly 2 player instances. The use cases where the number of players is irrelevant you don't have that constraint.
Play again is no use case. It's probably a simple action in the Play game UC where the question pops up.
P.S. You should read Bittner/Spence to get the idea about UC synthesis.
P.P.S.: As already mentioned in the comments, an actor is not a person, but the way some (usually) person acts. If you have a two player game and both players are equal, you have just one actor (the way they act is the same). If you have a game with two different players like one challenger and one opponent, you would use two different actors. Namely Challenger and Opponent. They both might act similarly when it comes to watching statistics or the like. Now you have a third role Player from which the actors above can inherit:
An UseCase diagram must list the possible kind of usage of your system (the Multiplyer game), the possible kind of actor and their relationship (which usecase is accessible by which kind of actor). So in the case of your game does two players are two different kind of actor (which means that they will not have the same kind of interaction with the game) or are they the same kind of actor (with the same kind of intarction with the game)?
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.