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.

Answer 2

Taking into account your remarks, here is the modified version of my diagram. I have two complex use cases to develop "Account Management" and "Postulation." But before taking this step, I wanted to know if the attached diagram is correct or there are some improvements to be introduced?

Answer 3

You are completely missing the system's boundaries (the center box with "System" labeled above).

On a conceptual level it is very important to understand what your system's boundaries are, and what is just human driven collateral/corollary labor. Keep those outside the boundary (on paper don't even draw a use case for it, in your mind understand it's part of the system but not something you implement in code, it will be documentation, training or laws) but keep it in the diagram on a sidebar.

That sidebar (the at latere natural language semantic substrate) should be written in simple words and sentences. If you can't do it, you should try to better understand the domain, simplify the diagram and split it in many diagrams.

Split it down into 3 or 4 different diagrams, each of which should be focused on those use cases which are cohesive. Use different diagrams for un-related use cases and different facets of the system. Find the right cut between complexity and simplicity, I suspect you're a bit overdoing it with the extends.

Remember: UML diagrams are surgical tools, use them as focused as possible. More is not better, it is only confusing or dispersing.

Finally, write down actual scenarios for the more complex use cases (those with many extensions). You'll see how difficult it will be to take into account all extension points. This will be a good indication on how complex the system is going to be.

The more you can simplify in this early stage the better for later design and implementation.

Answer 4

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.