Can I add 2 Login features in One Use Case Diagram

Question

I drew an Use Case Model for Academic Calendar Application, and what am struggling with is the fact I put 2 login features in the same model. One for the academic advisor and one for the students.

So my question is: is it okay with this?
Or should I draw a line from actor academic advisor to the same feature as login for the students.

Last and important one: What does Extends means in dashed lines?

Here is my Model

Answer 1

In short

Login should in principle not be a use case. But if you keep it, don’t duplicate it for different actors: prefer the addition association with the same use case, or better refactor your diagram to use generalization.

The extension means that Change Profile Status may in some situations enrich the behaviors and interactions of Login.

More explanations

1. Is the login a use-case at all?

There is no order among use cases, and a use case should be a reason for the actor to use the system. According to your diagram, an actor could use the system just for the sole purpose of Login (really?). Or do a Managing schedule without a login (oops).

This suggests that the login is not a use-case but a constraint, or an action in the activity diagrams that would describe each use case. (By the way, login is often obsolete in an era of Single Sign On that makes it happen behind the scene without user involvement; autheticate user) would be the corresponding action)

2. Ambiguity of a use cases with several actors

The UML specification do not define the semantic of a use case with several actors. It can mean that one among several can perform the use-case (but multiplicity should be set accordingly), or that several or all are involved in the use case, but without telling if it’s at the sale time or one after the other.

In any case, it’s ambiguous, even if most of us get the intended meaning right when reading the diagram.

On the other side, use-cases should not be duplicated to represent the same set of behaviors for different actors.

Is there an alternative?

Two popular techniques help to disambiguate having several actors aiming for the sale use-case:

• generalization of actors: if a use-case is common to several actors, you could perhaps identify a base actor for all the common use-cases. In your diagram this would mean introducting an actor User and let Student and Admin inherit from User.
• disambiguate in the textual narrative that should be provided to describe each use case