Как смоделировать простую диаграмму вариантов использования - PullRequest
2 голосов
/ 15 января 2011

Предположим, вам нужно составить диаграмму вариантов использования для этой простой задачи (которая является частью гораздо более крупного упражнения, которое я выполняю):

зарегистрированный пользователь (веб-приложения) может искать туристические достопримечательности.двумя способами: по категориям (например: музеи, парки, театры, места археологических раскопок) или по расположению (город, округ).

Как мне смоделировать этот UCD?

Самый простойпуть будет таким: актер (зарегистрированный пользователь), два варианта использования (поиск туристического аттракциона по категории и поиск по местоположению), вторичный актер (сервер веб-приложения, который будет обрабатывать запрос и отправлять обратно результаты).

Меня беспокоит то, что таким образом четыре категории и два типа местоположений не будут присутствовать в сценарии использования.

Я думал об использовании отношения "удлинить".Например, я бы добавил вариант использования с именем «Поиск парков», который расширяет вариант использования «Поиск по категории».Точка расширения может быть событием, которое пользователь выбирает для поиска парков.

Или я мог бы использовать отношение наследования между «Поиск по категории» и «Поиск парков» ... мммм ... янемного сбит с толку ...

Как бы вы смоделировали эту небольшую проблему, используя USD ??

Спасибо, Лука

Ответы [ 2 ]

2 голосов
/ 20 января 2011

Прежде всего, вы должны понимать, что диаграммы вариантов использования не заменяют фактические (написанные) варианты использования. Описания вариантов использования содержат много важных деталей, которые опущены в диаграммах вариантов использования. Диаграммы вариантов использования хороши для изображения иерархий действующих лиц, связанных вариантов использования и взаимосвязей между вариантами использования, но не более того.

Еще одна важная вещь - понять, что на самом деле представляет собой вариант использования. Хороший способ думать о них - найти цель актера, которого он / она хочет достичь с помощью системы. Достижение этой цели должно дать актеру некоторую деловую ценность. Я хочу сказать, что из того, что вы описали, зарегистрированный пользователь может захотеть найти экскурсию и / или купить входные билеты. Так что это его цель, и это должен быть вариант использования, не путайте варианты использования с функциональностью / функциями, такими как различные способы поиска и т. Д.

В вашем первом предложении у вас есть два варианта использования, которые отличаются только данными (например, это может быть просто другой выбор из поля со списком в форме). Такие различия, если они не влияют на то, как система и действующие лица взаимодействуют, описаны отдельно от вариантов использования в глоссарии данных, на который вы ссылаетесь в своем сценарии использования. Таким образом, вы избежите многих ненужных деталей в описаниях вариантов использования. Если, с другой стороны, шаги в описании изменяются (например, когда зарегистрированный пользователь выбирает систему местоположений, дает ему / ей возможность выбрать другого зарегистрированного пользователя в качестве друга и предварительно выбирает избранные местоположения обоих или что-то подобное ...) Вы можете захватить это, используя альтернативы / расширения.

Вы упоминаете систему, которую разрабатываете, как второстепенный актер. Не забывайте, что разрабатываемая система является неявным действующим лицом и не изображает диаграммы как отдельное действующее лицо. Используйте границу (прямоугольник, охватывающий варианты использования, исключая актеров), чтобы изобразить область действия вашей системы.

Наконец, к твоей заботе. Это всего лишь детали о данных, которые не являются частью варианта использования. Вы можете зафиксировать эти детали в тексте (назвав все категории и т. Д.), Используя глоссарий данных, как упоминалось выше. Если вы считаете, что структура и отношения между данными важны и должны быть записаны с помощью диаграмм, вы можете использовать диаграммы классов для создания моделей данных / предметной области.

Последнее замечание об отношениях использования вариантов - не используйте их, если не нужно. Их часто трудно понять и смутно определить. Никогда не используйте их для декомпозиции функциональности, которая зависит от дизайна, а не анализа с вариантами использования.

0 голосов
/ 26 сентября 2011

Я ненавижу изображать Поиск в случае использования.Просто слишком много переменных.Это все равно что пытаться написать сценарий использования браузера.

Поиск - хороший кандидат на раннее создание прототипа, дополненный бизнес-правилами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...