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