Search code examples
umldiagramuse-caseuse-case-diagram

Use Case Diagram for Login Module


Use Case for Login Module

I made a simple Use Case for Login module I was working on.

In there I have three types of ways to log in and I was wondering if this is the correct way.

Or is it better if I have a single Login process and the Facebook, Email and Google are extended to it.

Thank you for the help.


Solution

  • There is nothing that would be syntactically wrong in your diagram.

    Nevertheless a couple of remarks:

    • Check suspended and Send reset email seem to be actions rather than use cases. To be a use case they should at least imply interactions with the actors.
    • The user specialisation is not really needed, since the diagram shows no specifics at use-case level. It has the benefit to remind that there are different kind of users but you may convey this information in another way.
    • If you chose to keep it because if the big picture, the actors should correspond to roles in the interactions with the system. If the system is about volunteers for assisting blind and visually impaired people, who can ask for support, it’s ok. If not, it could appear ambiguous. Because accessibility requirements should be an implicit requirement for every use-case in every system and should not need explicit actor specialisation in use-case diagrams.

    And some advices:

    • use-cases should in principle have value for the actors and correspond to some of their goals. It’s meant for keeping a view on the big picture and not to decompose in details how the system shall proceed. Therefore keep it simple. A single login use-case and eventually a reset password use-case seem more than sufficient.
    • in order to promote the big picture,make your secondary actor as general as possible: use Identity provider. This will help you to design a future proof system with sound separation of concerns: whenever a new identity provider appears, you could just implement a new specialization of some classes. without changing your use-case nor fundamentally reviewing your design.