How to model two-step Login in UML via Use Cases and Sequence diagrams properly?

Question

I need to create a login page for a basic accountancy-related application. Login action should be two-step one:

1. User enters their username and password and hits "Authorize" button,
2. After successful authorization user should set the initial parameters for the current session (i.e. the month and year, the unit for which to account etc.). The available params to select from should be taken from the server (they may vary depending on the authorized user's priviliges etc.).

I would like to describe this actions above in UML using both Use Cases and Sequence diagrams. So for now I created such a Use Case diagram:

and a Sequence diagram:

I would like to know if these diagrams are correct (especially whether the relations with Server actor are in proper directions and if I use include relations properly in Use Case diagrams also if the Sequence diagram makes sense). Any improvements and suggestions appreciated.

Answer 1

There are a few things wrong in your diagrams.

First of all, your use of actors. An actor is something/someone outside the system you are modelling that needs to interact with your system. Actors are represented by a stick-man, because they are typically humans. Non-human actors can exist, but it is much harder to tell for non-human actors if they are correctly modeled as actors or if they should have been modeled as a part of the system itself.
The servers, printers, displays, etc., that your software runs on are most definitely not actors. These form an integral part of the system you are designing.

As actors are by definition outside your system, direct interactions between actors are of no interest to you. If you have a sequence diagram with a call/event arrow between two actors, then either it must be possible to remove that interaction without changing the meaning of the sequence diagram, or at least one of the actors should have been part of the system.

---

A proper use-case diagram offers surprisingly little information to the reader. It might be best to consider a use-case diagram as not much more than a graphical index to the use-cases that exist and their primary actors.

A use-case is an interaction between an actor and a system, where the actor uses the system to achieve a goal.

In your example, "login" is a proper use-case, but all the others are not. They are just steps that are taken as part of the "login" use-case. For a correct use-case diagram, you can just erase everything to the right of the "login" use-case.

The normal way to describe a use-case is just plain text, although supporting diagrams like sequence or activity diagrams might be used.