UML: как уменьшить количество вариантов использования системы учетных записей пользователей, чтобы избежать избыточности и ненужных вариантов использования?

Question

Мне нужна помощь, чтобы уменьшить количество вариантов использования в моей подсистеме.

Эта подсистема предназначена для управления несколькими учетными записями для пользователей, администраторов и суперпользователя со следующими требованиями:

система должна управлять учетными записями пользователей, в которых есть:

• Пользователи: могут создавать, читать, обновлять, удалять и блокировать свои собственные учетные записи, а также входить в систему.

  Создать требуется электронная почта аутентификация. Вход должен запрашивать двухэтапную аутентификацию (необязательно)

• Администраторы: могут управлять всеми учетными записями пользователей (CRUD, блокировка и вход) в качестве пользователя. Также только чтение и вход в свою учетную запись.

  Для входа требуется двухэтапная аутентификация.

• Суперпользователь: может управлять как учетными записями пользователей, так и администраторами (CRUD, блокировка, логины) и их собственная учетная запись суперпользователя.

  Создание администратора требует авторизации по электронной почте и телефону.
  Логин такой же, как у администратора, требуется двухэтапная авторизация.
  Может делегировать доступ суперпользователя другому администратору.

Системный поток должен быть понятен только с диаграммой вариантов использования и описаниями вариантов использования (без других типов диаграмм)

Как правильно их спроектировать варианты использования, чтобы избежать дублирования описаний вариантов использования и сделать ненужные варианты использования на диаграмме?

Например, в этой системе пользователь, администратор и суперпользователь имеют вариант использования входа в систему каждый. Вход пользователя запрашивает двухэтапную аутентификацию (необязательно), в то время как для администратора и суперпользователя всегда требуется двухэтапная аутентификация.

Суперпользователь наследуется от администратора, который наследуется от пользователя.

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

Answer 1

Кажется, вы ищете параметризованные варианты использования, которые представляют собой концепцию, продвигаемую Алистером Кокберном для текстовых вариантов использования.

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

Насколько мне известно, такой концепции не существует в нотации UML. Таким образом, у вас обычно будет либо вариант использования Manage XYZ и описание деталей в описаниях, либо четыре варианта использования Create XYZ, Update XYZ, Delete XYZ, Read XYZ. Лично я предпочитаю первый, чтобы вариант использования передавал большую картину.

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

Наконец, я хотел бы добавить, что варианты использования не предназначены для моделирования потоков и последовательность событий. Сценарии использования предназначены для определения различных целей, которые могут привести к разным видам взаимодействия. В этой связи мне интересно, имеет ли смысл различать guish Manage own account и Manage other user account, поскольку это соответствует очень разным целям.