Job website use case diagrams

Question

Here is my Job website use cases diagram. I do not know if what I did is correct or not. Any help?

Edit 1

Here is the modified version of the online job portal system:

this system contains two complex use cases: "Account Management" and "Job Application". Here is the diagram for Account Management:

and the diagram for Job Application:

I need your opinions.

Answer 1

Not bad, but there are some problems.

• Job Application is a process and is a Use Case. But Account (of anybody) is NOT an action or a process. It is an inner term in your application. It should appear at first in your component diagram, or even later.
• "extend" means that the pointed subject is a variation of the pointing one. You obviously misuse it.
• Account management is a subsystem - rectangle that is a part of the large one and contains the appropriate use cases. If drawing that is inconvenient, use for (sub)systems small rectangles and containment dependencies (with cross in circle on the side of container) and connect them to Use Cases by simple connectors. Of course, you needn't put dialogues with all subsystems on the same diagram.
• Maintaining of website is not connected to any practical use case really. It is separate admin task. Or you mean by it something else? Then change the name.
• You have use cases not connected to any actor. It is an error.
• Login is not part of job application. View vacancies are not variation of it, too. Favorite vacancies ARE extension of view vacancies.
• Please, try to minimize the use of "include" and "extend" in Use Case Diag. In 90% cases people use them, when they incorrectly are describing structure information on the Use Case diag. Here you write only Who will do What to Whom, and maybe a bit structure these Whos and Whoms into organizations and subsystems. Notice, you can describe structure ABOVE use case, not BELOW it!

Small details:

• you could consider divide moderator from administrator.
• edit your connections lines - they are strangled more than necessary.

(And thank you very much for translation - my French is too miserable to manage the modelling)

A bit more on @pid answer.

I am afraid, I can't agree with ignoring the pure human operations. On the contrary. Put them here, only their use cases will connect not actor-(sub)system, but actor-actor. And seeing them is very good for better planning the system as a whole. And ignoring them it is impossible to create a system good for user. The IT system is an integral component of the larger system, and we are creating the larger one really, with planning the support, processes, exchange of info, divisions and dependencies.