4

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

onlinejobportalsystem

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: onlinejobportalsystemversionmodified

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.

onlinejobportalsystem3

Any remark?

Marie
  • 137
  • 1
  • 3
  • 19
  • I think, it is OK. Drawing more subsystems is a rather cosmetic measure and is not necessary if you do the diagram for yourself. – Gangnus Feb 04 '14 at 09:28
  • 1
    Oh! I have found one little problem - you have select Favorite Vacancies, but not Filtering vacancies. – Gangnus Feb 04 '14 at 09:30
  • And one more detail - You shouldn't try to create the whole application at once. Make it step by step. That means that you need to make some colours for use cases for 1 stage, 2 stage and so on. For ranging the Use cases/functionalities you need to connect them showing, what groups of them MUST be realized together. – Gangnus Feb 04 '14 at 09:35
  • If you won't do the last, your pretty diagram is useless - for it doesn't fit to what you'll be doing really. – Gangnus Feb 04 '14 at 09:36
  • And one more operation/page - choose, who are you, employer, admin, moderator, job seeker... Or you'll have simply different pages addresses for different actors? – Gangnus Feb 04 '14 at 10:05
  • "you have select Favorite Vacancies, but not Filtering vacancies". It seems that I didn't understand the problem. – Marie Feb 04 '14 at 10:09
  • I only noticed that you have invented a nice detail - favorite vacancies, but you have forgotten the more base one - filtering professions, industries, locations, professional tags, and setting ones from the side of employer. – Gangnus Feb 04 '14 at 10:16
  • Any job site has such and their convenience is extremely important. Oh! and filtering on the date of publication/expire, too. – Gangnus Feb 04 '14 at 10:17
  • And the use case "Search for Vancancies" is not sufficiant to tell that we are in the process of "Filtering Vacancies". When a job seeker search for vacancies, he chooses the criteria to filter vancancies. – Marie Feb 04 '14 at 10:33
  • But to make this filtering possible, you have to support it from the employer side. And I'd advice you to make some tags and classification for employers, too, so that seeker can filter employers. (smoking areas, work at low temperatures, waterfall/agile project development and so on) – Gangnus Feb 04 '14 at 10:37
  • Think about hierarchical tag system. If you'll invent and implement such, you can possibly even sell it as a library and surely mention it in CV. – Gangnus Feb 04 '14 at 10:42
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/46738/discussion-between-marie-and-gangnus) – Marie Feb 04 '14 at 10:46

2 Answers2

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?

Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • "You can combine the groups of close use cases into subsystems", I don't understand what do you mean by "close use cases". "And you haven't any payment system here! Is it out of scope, or you have forgotten?"-> I don't think to the payment system. To understant the online job portal system, I looked at some job sites. – Marie Feb 03 '14 at 23:22
  • "close" in English means also "near", "not far from". I mean here "belonging to one theme". As for payment system, where, do you think, the job sites get money to pay for servers, advertisements and work of Moderators/administrators? Employers are paying for participation. – Gangnus Feb 04 '14 at 08:21
  • At this stage, I did not think to the payment system. But I think I can introduce it later. I have a little experience with Search Engine Optimisation. So I think to develop an optimized site. And it is logical that the employers pay for their visibility. Now I want to build the class diagram in order to generate the database and thus be able to start the development part. Is it possible to make design changes (UML diagrams) throughout development. – Marie Feb 04 '14 at 09:06
  • I'll check your class diagrams, too. As for optimization, if you want to put it in diagrams, you need to show ALGORITHM in it. Class diagrams won't help much. Look for Activity/sequence/timeline diagrams. As for automatic UML update, look here:http://modeling-languages.com/uml-tools-textual-notations-define-uml-models/ – Gangnus Feb 04 '14 at 09:20
  • And don't be greedy for upvotes :-). Being generous in upvotes makes the themes you are interested in stronger. People won't go into areas where they aren't getting "good marks". A good answer in C or Java is paying off 10x more than such in UML. It is a pity. – Gangnus Feb 04 '14 at 09:22
1

Although it's likely nobody still cares about my answer I think that the OP's use case diagram show errors as well as the answer does not respond to the flaws the diagram has.

Here it goes: The diagrams are an attempt to perform a functional analysis. This is not what use cases are all about. Their intention is to visualize "use cases" which deliver value to their actors. Not the way certain paths of execution are taken. This is part of what goes inside a use case and take a number of activity diagrams.

<<extend>> and <<include>> are not meant (as the OP tried) for analyzing the path of execution. Their use is to show optionality (either in timely or composite manner) for the system. To be specific: Login is not a use case at all. It is a constraint which applies to use cases and leads to certain implementation restrictions. But it does not deliver a cent of added value to the actor (so what would you reply if your boss asks "What have you done the whole day?", would you reply "Well, I logged on!"?).

PS If your use case diagrams resemble spider webs your design is likely wrong. (I don't know from where I got that but it proves true all time.)

qwerty_so
  • 35,448
  • 8
  • 62
  • 86