Я разрабатываю мобильное приложение для поиска изображений
Это моя диаграмма вариантов использования
Актер = пользователь смартфона
Система = клиентское приложение
Запрос предварительно обрабатывается на стороне клиента перед отправкой на сервер (например, голосовой запрос преобразуется в текстовый запрос).
я должен добавить этот вариант использования к моей диаграмме?
Я думаю, что это может быть расширенное использование cqse, подобное этому
Во-первых "Общий совет":
«Не тратьте свое время, спрашивая: «Должен ли я добавить это?». Потому что вы единственный парень, который может это сказать? Просто спросите себя: показывая или добавляя это на свою диаграмму, какую пользу вы получите?
Моделирование означает, что показ важных концепций скрывает детали. Вы тот, кто определит, что важно, а что — в деталях. Потому что вы внедрите систему и запачкаете руки.
Во-вторых "Технически"
Расширяет означает, что "выполнение варианта использования/сценария" является необязательным или условным.
Итак, если «предварительно обработать запрос» [ я не знаю, что это значит. Что бы это ни было] выполняется необязательно на основе условия [предположим, что когда условие x истинно в случае использования «сделать запрос», тогда будет выполнен вариант использования/сценарий «предварительный запрос»), это технически верно< /strong> использование отношений расширения. Таким образом, вы можете сделать собственное суждение.
Наконец: технически правильно не означает, что это правильно.
По возможности старайтесь не использовать отношения «включить» или «расширить». Они делают ваши варианты использования и диаграммы более сложными.
Сначала напишите варианты использования в виде текста. Затем, если вы обнаружите «одинаковые сценарии» [повторяя] в своих вариантах использования, извлеките их как отдельные варианты использования. Используйте "include", чтобы присоединить эти распространенные варианты/сценарии использования к основным вариантам/сценариям использования. Используйте расширение «отношения» всякий раз, когда вы находите/обнаружите новые важные сценарии, которые могут выполняться основными вариантами использования.
Мои личные идеи:
Для меня вы даже не должны показывать «Создать запрос» на своей диаграмме. [Конечно, при написании вариантов использования, если все эти 3 варианта использования делают запрос одинаково, напишите это как отдельный вариант использования, а затем включите основные сценарии использования. напишите это, используя отношения включения, это экономит время. И в этом нет ничего плохого. Будьте осторожны, я говорю «при написании вариантов использования в виде текста»].
Главный вопрос: «Должен ли я показать это на моей диаграмме вариантов использования». Итак, вы должны спросить, кто будет читать мои диаграммы вариантов использования? или почему я создаю такие диаграммы? Судите сами, исходя из контекста. Будьте прагматичны.
Дополнительная информация:
Прецеденты — это «текстовые истории» о том, как какой-либо участник использует систему для достижения целей. В вашей ситуации вашим актером является пользователь смартфона.
Итак, спросите себя, что пользователь хотел сделать с вашей системой?
Сделать снимок. [ звучит разумно ]
Печать с клавиатуры [плохой звук] : Почему он/она печатает с клавиатуры? Какова его/ее основная цель? Возможно, вы имеете в виду поиск по картинке... В этом случае «клавиатура для набора текста» не является хорошим кандидатом для использования. Чтобы найти картинку, он, вероятно, напишет название картинки на клавиатуре. Но набор текста с клавиатуры не является его/ее основной целью: это часть этапа использования «Поиск изображения по тексту».
Обработать запрос: [преобразовать голосовой запрос в текстовый] Таким образом, это не вариант использования. Это может быть частью этапа «Поиск по голосу»: Когда вы пишете «Поиск по голосу», используйте текст прецедента:
Основной сценарий:
...
Альтернативные сценарии
2 а) Приложение для поиска изображений не может распознать голос: .....
Для меня даже это добавляет ненужные технологические детали: Мы можем не упоминать шаг 2. Просто скажем: «Приложение поиска изображений ищет картинку, имя которой дается голосом». Генерация текстового запроса из голоса — деталь реализации. Как вы будете это делать. Но примеры использования сосредоточены на том, "что пользователь сможет делать с вашим приложением".
Не забывайте, что варианты использования — это не диаграммы. Диаграммы вариантов использования хороши только для визуального представления основных функций вашей системы. Случаи использования — это «текстовые истории».
Таким образом, есть много способов показать их на диаграммах вариантов использования:
Как правило, используйте отношения минимального расширения, включения, обобщения в диаграммах вариантов использования. Не тратьте много времени на выявление отношений в вариантах использования.
Бесплатный ресурс Use Case. Проверьте бесплатную главу Крейга Лармана из его популярной книги:
Прежде всего, я бы использовал <<include>> вместо <<extend>. `<<extend>> определяет дополнительное и необязательное поведение для расширенного варианта использования, а расширенный вариант использования не требует этого поведения для своей работы. С другой стороны, <<include>> отображает поведение, которое добавлено к включенному варианту использования. Кроме того, поскольку это поведение является частью того, что вы делаете в варианте использования make query; Просто опишите это в описании варианта использования make query.
