я рисунок случая схемы использования для моего клуба, но я не уверен, что это правильный способ сказать, администратор может сделать что-нибудь и член может только просмотреть профиль, обновлять данные только сам данныеUse Case Diagram для клуба членства
Я строю диаграмму с gliffy, это my diagram и json data (это просто еще одно изображение на рисунке ниже).
В принципе ваш рисунок в порядке. Что определенно неверно, CRUD. Это не вариант использования. То же самое касается Search. Вариант использования должен иметь по существу и глагол как минимум. У него может быть и объект.
Другое дело <<include>> отношение. Избегай это! То, что вы пытаетесь здесь, - это функциональное разложение. Синтезированы случаи использования. Когда дело доходит до функциональной декомпозиции в дизайне класса, вы можете ввести общий пакет для поиска или CRUD.
'общий пакет для поиска или CRUD' должен был быть« общим пакетом для поиск или CRUD'? –
Рекомендуя избегать включения ассоциации, вы имеете в виду, что включение ассоциаций должно быть составлено отдельно в более подробной диаграмме UC без Актеров? –
@ VojtěchDohnal (исправит опечатку) Я имею в виду, что вы просто не должны использовать '<
Существуют различные подходы к созданию UC. Я предпочитаю привязывать их к бизнес-процессам, а не к актерам, поскольку актер - это в основном просто любой пользователь системы с некоторыми правами доступа.
В этом случае я согласен с @Thomas Kilian, что использовать случаи использования, такие как CRUD или Update member data не очень полезно. В диаграмме вариантов использования вы моделируете интерфейс вашей системы - кнопки, доступные для внешнего мира (актеров) для печати. Update member data не видно снаружи, так зачем моделировать его в диаграмме использования случая?
Какой формат является gliffy (ваш json)? –
Это данные json с форматом .gliffy, который вы можете попробовать импортировать на [gliffy.com] (https://www.gliffy.com/) –
Нет. Требуется регистрация. Укажите общий формат. –