Я видел примеры людей, представляющих варианты использования CRUD на диаграммах вариантов использования как «Управление X», но я хотел знать, могу ли я использовать обобщение, подобное показанному на скриншоте, для группировки многих из них.
Мое намерение состоит в том, чтобы «управление элементом» применялось к текущему просматриваемому каталогу. Будет ли это хорошо?





Да, вы можете использовать обобщение, чтобы передать намерение, что субъект управляет элементами, и что элементы могут быть разного типа.
Но ваша диаграмма выглядит очень подробной и больше похожа на модель пользовательского интерфейса, чем на реальный вариант использования, ориентированный на цель. То есть он описывает больше «как», чем «что». Это не запрещено согласно спецификациям UML, но не рекомендуется, так как приводит к сложным диаграммам, отвлекает разработчика модели от целей пользователя и приводит к преждевременному проектированию пользовательского интерфейса, в то время как другие методы моделирования лучше подходят для обеспечения оптимальный пользовательский опыт.
См. также этот вопрос, в котором рассматриваются аналогичные проблемы, но на более низком уровне абстракции.
P.S. Не связанные мысли: диаграмма может создать двусмысленность, поскольку с одной стороны предполагается, что просмотр специализирован по типам элементов (просмотр X и просмотр Y), но в то же время он предполагает, что любой просмотр может быть расширен за счет управления любым типом элементов. элементов (управлять X, управлять Y). Это может быть еще одним признаком того, что вариант использования был создан с учетом дизайна класса и не ориентирован на цели пользователя.
Большое спасибо за ваш ответ! Да, вы правы, это похоже на модель пользовательского интерфейса. Я приму это во внимание в моей фактической диаграмме, а также двусмысленность расширения. Спасибо и за ссылку.
Я думаю, что есть ситуации, в которых рекомендуется подход OP. Обычно каждый вариант использования определяется как последовательность шагов с одним основным потоком и несколькими альтернативными потоками. Предположим, что у Manage X и Manage Y 80 % общих шагов, но 20 % различаются. Тогда подход OP имеет то преимущество, что 80% можно указать в разделе «Управление элементом», а 20% — в специализированных случаях использования. Если бы у вас не было «Управления элементом», вы бы получили дублирование и возможные несоответствия в других случаях использования. Если бы у вас не было Manage X и Manage Y, вы бы загрязнили Manage Item информацией, относящейся к X и Y.
@www.admiraalit.nl Думаю, я полностью согласен с этой точкой зрения. Возможно, здесь есть недоразумение. Я не утверждаю, что обобщение нежелательно; напротив. Моя точка зрения больше касается остальной части диаграммы и двусмысленности, создаваемой двойным обобщением.
Я понимаю. Очень хорошо.
Ну, это основано на мнении. Однако больше похоже, что вы находитесь на лучшем пути к функциональной декомпозиции, а не к синтезу вариантов использования.