UML use case diagram - depicting relationships correctly?
up vote
1
down vote
favorite
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
uml use-case-diagram
add a comment |
up vote
1
down vote
favorite
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
uml use-case-diagram
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
uml use-case-diagram
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
uml use-case-diagram
uml use-case-diagram
edited Nov 17 at 8:18
Thomas Kilian
23.1k63359
23.1k63359
asked Nov 9 at 18:29
Jenny
62
62
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25
add a comment |
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
It's difficult to comment a diagram which is not here. But to address your specific positioning question, the use case diagram makes a difference between primary and secondary actors.
In principle Vet and Nurses would be users of the system. They would therefore be considered as primary actors.
You can place the actors anywhere according to the UML specs. However, there is a convention to place primary actors on the left, and secondary on the right. So, even if it's not mandatory, do it when you can.
add a comment |
up vote
0
down vote
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
It's difficult to comment a diagram which is not here. But to address your specific positioning question, the use case diagram makes a difference between primary and secondary actors.
In principle Vet and Nurses would be users of the system. They would therefore be considered as primary actors.
You can place the actors anywhere according to the UML specs. However, there is a convention to place primary actors on the left, and secondary on the right. So, even if it's not mandatory, do it when you can.
add a comment |
up vote
0
down vote
It's difficult to comment a diagram which is not here. But to address your specific positioning question, the use case diagram makes a difference between primary and secondary actors.
In principle Vet and Nurses would be users of the system. They would therefore be considered as primary actors.
You can place the actors anywhere according to the UML specs. However, there is a convention to place primary actors on the left, and secondary on the right. So, even if it's not mandatory, do it when you can.
add a comment |
up vote
0
down vote
up vote
0
down vote
It's difficult to comment a diagram which is not here. But to address your specific positioning question, the use case diagram makes a difference between primary and secondary actors.
In principle Vet and Nurses would be users of the system. They would therefore be considered as primary actors.
You can place the actors anywhere according to the UML specs. However, there is a convention to place primary actors on the left, and secondary on the right. So, even if it's not mandatory, do it when you can.
It's difficult to comment a diagram which is not here. But to address your specific positioning question, the use case diagram makes a difference between primary and secondary actors.
In principle Vet and Nurses would be users of the system. They would therefore be considered as primary actors.
You can place the actors anywhere according to the UML specs. However, there is a convention to place primary actors on the left, and secondary on the right. So, even if it's not mandatory, do it when you can.
answered Nov 11 at 15:05
Christophe
38.8k43473
38.8k43473
add a comment |
add a comment |
up vote
0
down vote
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
add a comment |
up vote
0
down vote
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
add a comment |
up vote
0
down vote
up vote
0
down vote
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
answered Nov 11 at 18:04
Sakuna Madushanka
307
307
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
add a comment |
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
Please do not advocate using «extends» as a way to describe alternate scenarios. I have found that in more than 90% of the cases an extend use case is not needed and can be replaced by an include, or by an alternate scenario in the main use case (or both). Extends appear to only be useful in a very limited set of conditions.
– Geert Bellekens
Nov 12 at 14:42
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
I agree that «extend» should not be treated as the standard way of modeling alternate scenarios. Even «include» should be used only for a compelling reason, such as reuse, and not for functional decomposition. But looking at this use case diagram, every «extend»-association might have a good business case. For example, it is now possible to specify, develop and test use case 'Cancel an appointment' completely in release 1 and add the optional payment of the cancellation fee in release 2.
– www.admiraalit.nl
Nov 14 at 20:41
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53231461%2fuml-use-case-diagram-depicting-relationships-correctly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Hmm. Which diagram?
– Thomas Kilian
Nov 9 at 19:12
Hi Jenny, you could have made a bit of an effort to include a nice readable diagram without the extra parts of the application or computer. If you can't be bothered to invest time in your question, how can you expect people to invest time to answer it.
– Geert Bellekens
Nov 12 at 14:45
I'm not sure how to do that. I'll google it and get back to you.
– Jenny
Nov 12 at 14:50
Done! Hopefully that will be easier to view.
– Jenny
Nov 13 at 19:13
It doesn't matter where you draw the actors. You may move an actor from the left-hand side to the right-hand side and vice versa without changing the meaning of the model. It doesn't matter how you divide use cases over multiple diagrams either. You can depict them all in one diagram, draw some in one diagram and others in another diagram, or you could even draw the same use case in multiple diagrams. It doesn't influence the semantics of the model.
– www.admiraalit.nl
Nov 14 at 20:25