Схема вариантов использования UML для плагина, выполняющего различные функции посредством импорта CSV

Question

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

• Создание пользователей
  • Могут быть администраторами или обычными пользователями
• Создание проектов
  • Может быть родительскими проектами или подпроектами родительского проекта
  • Подпроекты копируются из заданного родительского проекта (поэтому плагин также добавляет возможность создавать подпроекты, которые копируются из родительского проекта).
• Назначение пользователей проектам с определенными разрешениями

Я хотел бы нарисовать диаграмму вариантов использования UML для этого плагина, но не могу понять, что go где должно быть, особенно загрузка файла CSV. Я также не понимаю, как нарисовать здесь роль основного приложения. Единственное, что он делает напрямую, в этом случае - это авторизация. Плагин также выполняет эти функции, выполняя операции с базой данных основного приложения, и мне интересно, должны ли быть какие-то ассоциации, исходящие, например, от создания пользователей из-за этого.

Можно найти одну из моих попыток здесь:

Заранее благодарим за любую предложенную помощь!

Answer 1

Предисловие: Мой ответ основан на Bittner / Spence (и других) и не на определении, найденном в спецификациях UML.

---

Пример использования касается дополнительной ценности рассматриваемая система подводит к основному действующему лицу. В вашей системе (как кажется) три варианта использования

• Create user (как насчет их удаления и изменения?)
• Create project (здесь то же самое)
• Assigning user to project (также здесь)

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

Актер Core Application выглядит как представляющий рассматриваемую систему. Если да: выбросьте его, так как это было бы неправильно.

Пузырь Authorize (я полагаю) является ограничением, которое вам нужно прикрепить к вариантам использования, и это означает, что вы должны авторизоваться в базе данных. Это не вариант использования.

Ваша система будет выглядеть как

Теперь ваш плагин просто использует существующие варианты использования и выполняет их на основе скриптов в загруженном CSV. Итак, это новый вариант использования. В зависимости от дизайна это может быть просто новый вариант использования, добавленный к существующей системе. Имя для U C может быть Upload control file для описания того, что на самом деле сделано.

Это была бы другая история, если бы вы разрешить своего рода динамическое c расширение системы. Вы можете спроектировать его так:

Value added system просто имеет "загрузку" U C и использует основную систему в качестве актер.

---

Почему пренебрегая нормой? Ну, по многим и простой причине: это бесполезно. Это чисто техническое описание, и после этого ваш дизайн превратится в паутину. Сосредоточение внимания на добавленной стоимости - это именно то, что должно быть в начале проекта. Если у вас этого нет, вы потерялись с самого начала. Есть пара известных авторов, пропагандирующих этот подход. Я учился у Биттера / Спенса и с тех пор считаю его полезным.