Должны ли разные действующие лица в диаграмме вариантов использования использовать один и тот же вариант использования входа в систему?

Question

У меня в настоящее время есть Use Case Diagram, который похож на вышеупомянутый:

В моем последнем заявлении я, вероятно, поделюсь одной и той же формой Login для Employees и Employers. Должен ли я отразить это в этом Use Case Diagram, когда оба Actors используют один и тот же Login Use Case? Если да, то как я могу представить, что каждый из них может сделать после выполнения Login?

Answer 1

Скорее всего, будут другие общие случаи использования? Так что «абстрактный» пользователь имеет смысл, я думаю, хотя я не думаю, что он должен быть «абстрактным», он может быть актером сам по себе?

Независимо от того, какой стиль вы предпочитаете, целью моделирования является абстрагирование информации. Если сценарий использования входа в систему очень важен в том смысле, в каком он должен быть на диаграмме, эта диаграмма не говорит мне ничего особенного. Эта диаграмма говорит мне, что в этой системе прецедент входа в систему предшествует всем остальным прецедентам? Duh? Любая система будет иметь вариант использования входа в систему, поэтому для большинства систем это не будет (архитектурно / очень) значимым. Если сценарий использования по какой-то причине является особым, я бы поместил его в диаграмму без взаимосвязей, мне кажется, этого достаточно. Диаграмма будет сообщать: у нас есть особый вариант использования входа в систему, мы хотим, чтобы вы приняли его к сведению. Есть ли в системе анонимные варианты использования? Варианты использования, которые могут быть выполнены без варианта использования входа в систему? Это важно, достойно некоторых элементов модели. В противном случае подразумевается ИМХО.

Если ваше моделирование требует большего, чем просто понимание и общение, например необходимо управлять генерацией кода, это, конечно, по-другому. Но тогда вы можете - в зависимости от вашей среды моделирования - сделать ее частью модели, а не диаграммы. Таким образом, он может выполнять как генерацию кода, так и понимание, общение.

Answer 2

@ CesarGon's - хорошее решение.Другая альтернатива - не обязательно лучше, просто другая - это иметь Employee и Employer варианты использования <<include>> login UC.

То, что вы используете, зависит от стиля и предпочтений.Подход абстрактного пользователя может выглядеть чище и более декларативно (вы должны указать логин в качестве предварительного условия на других UC).Подход <<includes>>, возможно, лучше соответствует образу мышления императива / моделирования процессов, поскольку каждый UC будет явно показывать вызов для входа в систему в качестве первого шага.

Answer 3

Почему бы вам не сделать так, чтобы работодатель и сотрудник специализировались на абстрактном Пользователе, и чтобы этот субъект-пользователь использовал сценарий использования входа в систему?

Тогда работодатель и сотрудник будут использовать только свои конкретные варианты использования.*