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).



enter image description here










share|improve this question
























  • 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

















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).



enter image description here










share|improve this question
























  • 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















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).



enter image description here










share|improve this question















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).



enter image description here







uml use-case-diagram






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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




















  • 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














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.






share|improve this answer




























    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






    share|improve this answer





















    • 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











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    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

























    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.






    share|improve this answer

























      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.






      share|improve this answer























        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 11 at 15:05









        Christophe

        38.8k43473




        38.8k43473
























            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






            share|improve this answer





















            • 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















            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






            share|improve this answer





















            • 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













            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






            share|improve this answer












            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







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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


















            • 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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Xamarin.iOS Cant Deploy on Iphone

            Glorious Revolution

            Dulmage-Mendelsohn matrix decomposition in Python