Should different actors in a Use Case Diagram share the same Login Use Case?

I currently have a Use Case Diagram that is similar to the above one:

In my final application I will probably share the same Login form for both Employees and Employers. Should I reflect that in this Use Case Diagram, having both Actors using the same Login Use Case? If so, how can I then represent what each one of them can do开发者_开发问答 after doing the Login?

Most likely there will be other shared use cases? So the 'abstract' user makes sense I think, although I don't think it needs to be ‘abstract’, it can be an actor in its own right?

No matter what style you prefer the purpose of modeling is to abstract information away. If the login use case is very significant in a way that it needs to be in the diagram, this diagram is not telling me anything special about it. This diagram tells me that in this system the login use case precedes all other use cases? Duh? Any system will have a login use case so for most systems it won’t be (architecturally/very) significant. If the use case is special for some reason I would put in the diagram without relationships, that suffices I think. The diagram will communicate: we have a special login use case, we want you to take note of it. Does the system have anonymous use cases? Use cases that can be executed without the login use case? That is significant, worthy of some model elements. Otherwise it is implied IMHO.

If your modeling needs to do more than enable understanding and communication e.g. needs to drive code generation, this is different of course. But then you can – depending on your modeling environment – make it part of the model but not the diagram. That way it can do both: drive code generation and enable understanding, communication.

Why don't you make both Employer and Employee specialise from an abstract User, and make that User actor use the Login use case?

Then Employer and Employee would use their specific use cases only.

@CesarGon's is a good solution. Another alternative - not necessarily better, just different - is to have both Employee & Employer Use Cases <<include>> the login UC.

Which you use depends on style & preference. The Abstract User approach can look cleaner and is more declarative (you should specify login as a pre-condition on other UCs). The <<includes>> approach perhaps fits an imperative/process modelling mindset better since each UC will explicitly show the call to login as the first step.