Online Job Portal System Use Case Diagrams

Question

I want to have a correct use case diagram for an online job portal system. Here is my attemp:

I have some doubts:

1. I can't see where making "Login" use case witch is an important use case for this system.

2. This use case diagram is not showing the difference between a simple visitor and a registered one. The former could view vacancies, view advice without the obligation for having an account. The latter could view vacancies, view advice, upload CV (after be logged), apply for a job (after be logged) ... Is having two actors "Simple visitor" and "Registred Visitor" in my diagram will be correct? Or is there a way to differentiate these two actors without the need to add a second?

Edit1:

Taking into account your remarks, here is my modified version:

Edit2:

I feel unsatisfied with my use case diagram. Here is my new version. use Cases added are:

1. Moderator: Notify JobSeeker/Employer, Disapprove Vacancy/Application, Manage Payment.
2. JobSeeker: View CV, Download CV, View Application Status, View Employer Details, Search Employer.
3. Employer: View CV, Search CV, Download CV, Edit Vacancy, Delete Vacancy, View JobSeeker Details, Search JobSeeker.

And for the development part, I want to partition the work into three modules: one for the moderator, one for the JobSeeker and one for the Employer.

Any remark?

Answer 1

• I think, Login should belong to Account management, as it is here. You can also add there password restoring as "include" of login.

• About new and old users it is not so easy. Because, this difference is applicable on Employer, too. new employer can only see CV without private info (let's call them Shortened CV) and vacancies and can't get applications and publish vacancies. I think, you should have four actors on the right side - registered/unregistered Seeker/Employer. Unregistered actors will be Generalization of the registered ones. This is shown by arrow with empty triangle on the more general entity. So, if you already have shown a connection to some use case for an unregistered guy(parent), you don't need to show it again for the registered one(child) - he inherits all from its "parent".

  • As for changing the state from unregistered to registered, you can draw a diagram for a state machine to explain it - State diagram is the second most common diagram in UML and can be directly cited in Use Case diagram. But if it is for the real work, you needn't - it is too obvious logic.

• You can combine the groups of use cases belonging to same themes into subsystems, the diagram would be more readable. Also you can use different colours groups for different subsystems and their use cases - clients and teachers simply LOVE coloured pictures :-)

• If it is possible, use straight lines or curves for connections - it will be more readable.

• And you haven't any payment system here! Is it out of scope, or you have forgotten?