#uml #use-case-diagram
Вопрос:
У меня есть веб-страница с графиком, состоящим из множества узлов внутри. Пользователь, очевидно, может просмотреть график (пример использования: preview the graph ). Он также может фильтровать узлы графика на основе аргумента и сложности, и в этом случае график обновляется, выделяя интересующие узлы (пример использования: filter nodes ).
Моя проблема в следующем: имеет ли смысл вставлять «include» изображение, подобное изображенному на рисунке? Я думаю, что да, так как при обновлении графика пользователь отображает предварительный просмотр графика, который был обновлен снова.
РЕДАКТИРОВАТЬ: Это график; справа есть FILTER панель, позволяющая фильтровать по сложности и теме. 
Комментарии:
1. Как указал Кристоф в своем ответе, вы столкнулись с функциональной декомпозицией. Ищите ответы здесь о включении/расширении (их довольно много) дополнительно. Как всегда, я рекомендую прочитать Биттнера/Спенса о вариантах использования (и их синтезе!).
Ответ №1:
Семантика UML
«include» означает, что один вариант использования ВСЕГДА включается в другой.
Поэтому из вашей диаграммы мы понимаем, что Preview graph это независимый набор моделей поведения, но он также может быть включен в Filter node них . В результате фильтрация всегда подразумевает предварительный просмотр.
Это формально правильно, и смысл, похоже, соответствует вашему повествованию. Более того, это подчеркивает необходимость повторного использования набора моделей поведения.
Логика прецедентов
Однако варианты использования в принципе являются целями пользователя, а не функциями или функциями, которые разбиваются на более подробные. И ваше повествование, похоже, описывает функции и пользовательский интерфейс гораздо больше, чем цели.
Более того, an «include» не представляет собой последовательность. Если Filter node включено Preview graph , это не означает, что фильтрация приводит к предварительному просмотру, и не означает, что фильтрация происходит до предварительного просмотра.
Взгляните с точки зрения пользователя
Хотя мы могли бы утверждать, что предварительный просмотр или фильтрация могут быть целями пользователя, ясно, что предварительный просмотр не является подцелью фильтрации.
Итак, какова реальная цель для пользователя здесь? Может ли это быть для того, чтобы Navigate in the graph ? Как это делается, это детали пользовательского интерфейса: мы просто просматриваем картинку? предлагаем ли мы фильтрацию для облегчения навигации? используем ли мы раскраску для выделения некоторых деталей ? увеличиваем ли мы масштаб, чтобы увидеть больше? Все это (интересные) функции, но не независимые варианты использования.
Редактирование после редактирования
Ваш снимок экрана заново фокусируется на том, что я говорил ранее: фильтрация-это просто средство для облегчения навигации в предварительном просмотре. Я бы рекомендовал не рассматривать это как прецедент.
Если, несмотря на мой совет, вы хотите отобразить фильтрацию на своей диаграмме, вам следует использовать<>, чтобы показать, что поведение фильтрации может улучшить поведение навигации:
<<extend>>
actor --------- Previsualize/Navigate graph <-------------- Filter interests
Комментарии:
1. Правильно, цель пользователя состоит в том, чтобы перемещаться по графику, а затем выбрать узел из графика, щелкнув по нему. Фильтр представлен флажком, поэтому пользователь, установив различные флажки, может выделить (раскрасив их) только интересующие узлы. Второй вариант использования я рассматривал как <<включить><включить>> фильтрации, потому что, если пользователь устанавливает некоторые флажки, график обновляется путем раскрашивания интересующих узлов, но, возможно, это немного растянуто, а также что-то совершенно очевидное. Может быть, было бы более нормально оставить «фильтровать узлы» и «просматривать график» как отдельные простые варианты использования?
2. @MaxyCar Если мы возьмем классический пример банкомата, то в принципе существует вариант использования «Снятие наличных», но не вариант использования «Вставить карту» (потому что это не цель, а просто средство/ограничение для достижения цели) и не вариант использования «выбрать банкноты» (потому что это не цель, это просто подробная информация о том, как достигается цель). В вашем случае вопрос заключается в том, является ли фильтрация отдельной целью для пользователя, ограничением или детализацией реализации. Будет ли пользователь использовать ваше приложение только для фильтрации? Или фильтрация-это просто функция, которая может помочь пользователю в достижении главной цели?
3. @MaxyCar Отлично! Глядя на ваше редактирование, я окончательно подтверждаю свою рекомендацию: с точки зрения прецедента использования существует только один вариант использования. Фильтрация-это не отдельная цель, а функция, которая помогает навигации. Обычно вы документируете это в описании прецедента. Я бы, кстати, рекомендовал стиль «основного варианта использования», в котором перечислены намерения актеров, а не последовательный поток.
4. @MaxyCar Теперь, если, несмотря на мой совет, вы действительно хотите показать фильтр на диаграмме (ваша диаграмма, ваше решение), то у вас должна быть только связь субъекта с вариантом использования предварительного просмотра/навигации и фильтрация с зависимостью <<расширить><расширить>> для основного варианта использования. Расширение означает, что оно может обогатить поведение, но не обязательно.
5. Спасибо, ты самый лучший!