I have made this use case diagram of a game called Tictactoe.
Please correct it if it is wrong.
Here is an image of the use case diagram:
the difference between players is too small to differ players 1 and 2. There is only one actor - player
Player does not check who won. This is NOT outer behaviour of the system and that means, it is not a use case.
So, the start use case diagram could be shown as:
But as we have only one actor, we don't need to show actors at all. And we can group the use cases into subsystems/packages. Maybe you haven't seen such UC diagrams, but in the UML standard 2.5 documentation there such ones, too.
The next step could be joining the state machine diagrams right here or as standalone diagrams.
Related
Im new in UML,
I am recently in charge of a web application, this application manages projects through a flow of states. There are multiple users within the application and each of them can intervene in the flow in a certain state.
Therefore I want to represent this information through a state diagram for me and for future developers do not have to ask the same question again.
My question is: How do I represent the different actors in the state diagram and their intervention in each of them?
Do I need to create a different state diagram for each actor?
Is there a diagram to do this that you do not know?
Thanks.
This is my example diagram and how an actor can pass from stateX to stateY
You try to oversimplify your model.
Each actor has certain system functionality that they can run. These single functionalities are called Use Cases (UC) and you present them on a Use Case diagram. This diagram shows which Actor can perform what Use Case but it does not show a relation to a state. While each Use Case can have pre-conditions defining what has to be true before the UC can be performed and post-conditions declaring what will be true if the UC ends successfully (which in your case would both probably be something like "System is in State A"), UC diagram does not support showing pre- and post-conditions. You can always add them in the notes attached to a UC.
To have a clear view of the system State Machine you can use two diagrams. One will be UC diagram, the other one will be State Machine Diagram or to be more specific Protocol State Machine. Then on State Machine you depict which UC causes what system State change while UC diagram provides information which Actor is eligible for running specific UC.
Finally you can use Sequence Diagram if you want to model how specific flow of interactions in the system impact changes of the system state. You can present states and actors on a single diagram here, but it is not designed, cannot and should not be used to depict all possibilities on a single diagram.
Disclaimer
Next part of my answer is opinion based
/Disclaimer
Most probably I would use UC diagram and SM diagram together according to information you've provided.
On the notation
A side note to your diagram - ovals are used only on UC diagram and represent Use Cases. They are not associated with each other, only with Actors.
States are presented as rectangles with rounded corners (both in State Machine Diagram and Sequence Diagram).
I have build a usecase diagram for hotel reservation
Should i build a sequence diagram for each usecase in the usecase diagram, or can i summarize multiple usecase in a single sequence diagram?
A use case diagram shows how use cases and actors relate to each other and gives a usefulness system overview. Use cases boil the system down to their added values and do not show how these are achieved.
Any scenario of a use case is graphically represented in an activity diagram where the single steps occur as actions.
A sequence diagram is used to show how objects communicate.
Usually you derive classes and relate them to actions of the use case activities. So when you create a sequence diagram it highlights a certain aspect of the whole system. This highlight is usually spot on and not a floodlight. Putting multiple use case scenarios in a single SD would for sure simply blind any reader instantly.
Usecase diagram
Use case diagrams show business use cases, actors, and the relationships between them. The relationships between actors and business use cases state that an actor can use a certain functionality of the business system. You will not find any information about how or in what chronological sequence these services are rendered
sequence diagram
A sequence diagram can map a scenarios described by a use case in step by step detail to define how objects collaborate to achieve your application's goals.
Here is the diagram , which will clear things better to you
I'm creating a use case diagram for a checkers game that I programmed. How in-depth are you really supposed to go when making these? I read that they are supposed to be simple, but that is kind of vague. Do I need to create more arrows, for example between "move regular" (which means move a regular piece, as oppose to a king) and "jump"? Or is it fine not having a connection there? I just don't want to make too many arrows because it will begin to look pretty messy. Any input will be appreciated.
1) ..UML..diagram..how in-depth are you..supposed to..do I need..more arrows..don't want..it..look..messy..?
How in-depth and how simple depends on many factors, basically on an answer to "why you need it" and "who will read it".
Actually the set of questions and guides and other practices that can help you decide can be quite long. Especially useful one is listed in the chapter Agine Modeling: Agile/Lean Documentation: Strategies for Agile Software Development in Scott W. Ambler's online book.
One thing that you should get absolutely clear is what kinds of UML diagrams you need/want
2) UML..use case diagram..more arrows..or..no..connection..too many arrows..?
The arrows in use case diagrams are not an arbitrary connection lines but instead they have precise meaning, especially the <<include>> and <<extend>> relationship, see http://www.uml-diagrams.org/use-case-reference.html for their definition and examples
Besides being graphical bubbles the use case represent how an actor interacts with the System Under Design. Content of the bubbles is then described in more/less formalized text form, see Wikipedia: Use case and especially Alistair Cockburn's use case pages as he basically defined meaning of the term (later adopted by UML) his opinion matters.
3) I'm creating a..UML..diagram for a checkers game that I programmed..
In your case the King Piece bubble does not seem to be included-in or extending the Start Game bubble initiated by the Player and I don't see what sequence of steps might be hidden inside its textual representation (or in your code).
The things you began to draw look much more like UML Activity Diagram, an example
and some explaining links:
overview Debenedetti Emanuele, Activity diagrams in UML 2.0
background by Conrad Bock (one of UML authors), UML 2 Activity and Action Models, The Journal of Object Technology
UML 2 Activity and Action Models
UML 2 Activity and Action Models, Part 2: Actions
UML 2 Activity and Action Models, Part 3: Control Nodes
UML 2 Activity and Action Models, Part 4: Object Nodes
UML 2 Activity and Action Models, Part 5: Partitions
UML 2 Activity and Action Models, Part 6: Structured Activities
tool manuals
PaceStar UML Diagrammer, UML Diagramming Guide - http://www.pacestar.com/uml/udg60.pdf
Sparx Enterprise Architect, Using UML Part Two – Behavioral Modeling Diagram - http://www.sparxsystems.com.au/downloads/whitepapers/UML_Tutorial_Part_2_Introduction.pdf
Microsoft Visual Studio, UML Activity Diagrams - http://msdn.microsoft.com/en-us/library/vstudio/dd409360.aspx
There are much less use cases here. Pls refer to the following diagram drawn by myself:
The other requirements can be written in use case specification, specially the business rules.
Use case name: Move piece
Actors: Player (Primary)
Pre-conditions: ******
Post-conditions: ******
Stakeholders and Interests: ******
Basic Path:
Player selects one piece and the destination square, and submit a move request.
System validates destination square.
System moves the piece and calculates the moving.
System displays the moving result.
Exception Path:
2a. destination square is not valid:
2a1. System ****
Business Rule:
valid destination square : ……
calculating rule, such as king piece, win 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.
I'm learning UML by trying to simulate how a car service garage works with diagrams and documentation. One problem I have is with postcondition (or rather, GOTO) statements.
Is the dashed line << include >> relationship only for preconditions? Can Use-case bubbles connect to eachother and follow a logic path?
So this is what I have so far..
1) Is the 'Settle Payment' bubble in the wrong place? Should it have been << include >>ed to the other bubbles?
2) Should I associate the 'request service' bubbles to the technician too as he will be the one fixing the car?
Image
Use Cases are like classes. They have inheritance (extends) and relationships like includes and uses.
Preconditions are common relationship constraints. Some of us write the preconditions and postconditions in the text of the use case. You can draw it, but it isn't required.
Do not try to sequence the use case bubbles. That's what activity diagrams and sequence diagrams are for. That's what narrative text is for. That's something the users already know.
Also, don't waste a lot of time treating the use cases as a super-high-level programming language. Remember, the actors already know what they're doing; they don't need help sequencing things.
You need to focus on capturing the actors, the use cases, and basic "extends", "uses", "includes" among the use cases. Use Case models are not programming. The use case diagram is knowledge capture of "who" and "what".
Think of it as more like a security model that defines what the actors can do. Order, sequence, and other details don't matter as much as what the actors do.
When you have Actor associated with actor (like Technician and Front Desk), you're saying that the actors interact outside the system. You're saying that the tech never logs in to the system to do get their work or log their time.
If the technician actually will log in to get work and record time, then the technician participates in some use cases.
Use cases aren't programming. They're things actors do. Use cases are connected by virtue of being built in a big, common piece of software. You don't need to draw data flow or logic arrows among the use cases. They can all be largely independent.
When you design the system, you'll implement UI features and database features that connect the use cases in some sequence.