CRUD в схеме использования?
Мой вопрос довольно прост. Каков наилучший способ принести CRUD в схему использования? Это должно быть DRY. Я знаю, UML иногда дискреционный, но что вы думаете об этом?
Некоторые идеи:
1 схема использования-случая
![usecase1]()
- Не очень DRY, если есть несколько объектов CRUD.
2 диаграмма использования-случая
![usecase2]()
- Не очень DRY, если есть несколько объектов CRUD.
3 диаграмма использования-случая
![usecase3]()
Update
4 диаграмма использования-случая (@Uffe)
![enter image description here]()
- Заметьте, может быть, не нужно, когда это описано в документации?
5 диаграмма прецедента (@home @Uffe)
![enter image description here]()
Ответы
Ответ 1
Из них я бы сказал, что №3 на самом деле самое худшее, потому что "CRUD" сам по себе не является прецедентом; вы всегда CRUD что-то. Не путайте пример использования <<extend>>
с наследованием класса.
Вариант № 2 тоже не очень хорош, потому что использование использования "управляющего пользователя" не означает, что вы выполняете все четыре действия CRUD.
Если вы действительно хотите быть явным в своих случаях использования, у # 1 есть мои деньги. Но если бы это был я, я бы просто положил один из вариантов использования "Управление пользователями".
Поскольку пользовательское (или что-то еще) управление - это хорошо понятая концепция, случай использования "Управление пользователями" на самом деле довольно понятен и не нуждается в детализации в нескольких случаях использования, если нет особых причин для этого ( например, если система, для которой вы анализируете требования, является механизмом аутентификации). Если это так, используйте # 1.
Ответ 2
В соответствии с книгой "Применение UML и Patterns-Craig Larman" мы можем использовать "Manage User" для использования имени case для отображения операции CRUD в прецеденте. Нет 4 - хороший выбор, и в этом случае мы описываем операции CRUD в сценарии. Создайте пользователя в основном потоке событий, а другие - в альтернативном потоке событий.
Ответ 3
Я проголосую за три, пока в компании подразумевается неявное или явное понимание того, что именно вы имеете в виду CRUD (т.е. каждый должен согласиться с тем, что это просто означает, что базовые формы вводят все данные, если требуется класс более сложный процесс ввода, тогда он должен быть смоделирован как отдельный вариант использования).