Диаграммы прецедентов системы онлайн-портала вакансий

Question

Я хочу иметь правильную диаграмму прецедентов для системы портала онлайн-вакансий. Вот моя попытка:

У меня есть некоторые сомнения:

1. Я не могу понять, где создание сценария использования "Логин" является важным вариантом использования для этой системы.

2. Эта диаграмма использования не показывает разницы между простым посетителем и зарегистрированным. Первые могли просматривать вакансии, просматривать советы без обязательства иметь учетную запись. Последний может просматривать вакансии, просматривать советы, загружать резюме (после того, как будет зарегистрирован), подать заявку на работу (после того, как будет зарегистрирован) ... Будет ли правильно иметь двух актеров "Простой посетитель" и "Зарегистрированный посетитель" на моей диаграмме? Или есть способ разграничить этих двух актеров без необходимости добавлять секунду?

Edit1:

С учетом ваших замечаний, вот моя модифицированная версия:

Edit2:

Я чувствую себя неудовлетворенным моей диаграммой вариантов использования. Вот моя новая версия. Добавлены следующие случаи использования:

1. Модератор: Уведомить JobSeeker/ Работодателя, Отклонить вакансию / Заявление, Управление оплатой.
2. JobSeeker: просмотр резюме, загрузка резюме, просмотр статуса приложения, просмотр сведений о работодателе, поиск работодателя.
3. Работодатель: просмотр резюме, поиск резюме, загрузка резюме, редактирование вакансии, удаление вакансии, просмотр сведений о вакансии, поиск работы.

А что касается разработки, я хочу разделить работу на три модуля: один для модератора, один для JobSeeker и один для работодателя.

Любое замечание?

Answer 1

• Я думаю, логин должен принадлежать управлению аккаунтом, как здесь. Вы также можете добавить туда восстановление пароля как "включенный" логин.

• С новыми и старыми пользователями это не так просто. Потому что эта разница применима и к работодателю. Новый работодатель может видеть только резюме без личной информации (назовем их "Сокращенное резюме") и вакансий и не может получать заявки и публиковать вакансии. Я думаю, у вас должно быть четыре актера справа - зарегистрированный / незарегистрированный Искатель / Работодатель. Незарегистрированные актеры будут обобщать зарегистрированных. Это показано стрелкой с пустым треугольником на более общем объекте. Таким образом, если вы уже показали соединение с каким-либо вариантом использования для незарегистрированного парня (родителя), вам не нужно показывать его снова для зарегистрированного парня (ребенка) - он наследует все от своего "родителя".

  • Что касается изменения состояния с незарегистрированного на зарегистрированное, вы можете нарисовать диаграмму для конечного автомата, чтобы объяснить это - Диаграмма состояний является второй наиболее распространенной диаграммой в UML и может быть прямо упомянута в диаграмме вариантов использования. Но если это для реальной работы, вам не нужно - это слишком очевидная логика.

• Вы можете объединить группы вариантов использования, относящихся к одной и той же теме, в подсистемы, чтобы схема была более удобочитаемой. Также вы можете использовать разные цветовые группы для разных подсистем и их вариантов использования - клиенты и преподаватели просто ЛЮБЯТ цветные картинки:-)

• Если это возможно, используйте прямые линии или кривые для соединений - это будет более читабельным.

• И у вас здесь нет платежной системы! Это выходит за рамки или вы забыли?

Answer 2

Хотя, вероятно, никто не заботится о моем ответе, я думаю, что диаграмма варианта использования OP показывает ошибки, а также ответ не отвечает на недостатки, которые есть на диаграмме.

Здесь это идет: диаграммы - попытка выполнить функциональный анализ. Это не то, что варианты использования все. Их намерение состоит в том, чтобы визуализировать "варианты использования", которые приносят пользу их участникам. Не так, как определенные пути исполнения взяты. Это часть того, что входит в сценарий использования и содержит ряд диаграмм действий.

<<extend>> а также <<include>> не предназначены (как попытался OP) для анализа пути выполнения. Их использование - показать возможность (своевременно или составно) системы. Чтобы быть конкретным: Login это не случай использования вообще. Это ограничение, которое применяется к случаям использования и приводит к определенным ограничениям реализации. Но это не приносит центу дополнительной ценности для актера (так что бы вы ответили, если бы ваш босс спросил: "Что вы делали целый день?", Вы бы ответили: "Ну, я вошел в систему!"?).

PS Если ваши диаграммы вариантов использования напоминают паутину, ваш дизайн, скорее всего, неверен. (Я не знаю, откуда я это взял, но это подтверждается все время.)