Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
TRPP_gotovoe.doc
Скачиваний:
3
Добавлен:
11.11.2019
Размер:
769.02 Кб
Скачать

Практические примеры диаграмм.

  1. Диаграмма вариантов использования.

Для понимания правил построения диаграмм рассмотрим понятие «сценарий».

Сценарий представляет собой последовательность шагов, описание взаимодействия между пользователем и системой. Рассмотрим реализацию на Web-технологии Internet-магазин. Сценарий покупки товаров в этом магазине следующий:

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

Данный сценарий рассматривает только одну ситуацию, поэтому вариант использования представляет собой множество сценариев объединенных вместе общей целью пользователя.

Для данного случая можно построить вариант использования «Покупка товара», который охватывает несколько сценариев.

Текст примера вариантов использования «Покупка товара».

  1. Покупатель просматривает каталог и выбирает товар для покупки.

  2. Оценка стоимости всех товаров.

  3. Покупатель вводит информацию, необходимую для доставки товара (адрес, время).

  4. Система представляет информацию об общей цене товара и времени доставки.

  5. Покупатель вводит информацию о кредитной карточке.

  6. Система осуществляет авторизацию счета покупателя.

  7. Система выполняет необходимую оплату товара.

  8. Система подтверждает оплату товара по электронной почте.

Альтернатива:

1. Неудача авторизации. На шаге 6 система получила отрицательный ответ на запрос о состоянии счета покупателя. Необходимо предоставить покупателю возможность повторно ввести информацию о состоянии кредитной карточки.

2. Постоянный покупатель (скидки).

Существует множество способов записи содержания вариантов использования. Язык UML в этом случае не определяет ни какого стандарта.

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

Диаграмма вариантов использования является частью языка UML, многие аналитики находят такую диаграмму полезной, однако нет необходимости ее рисовать при описании вариантов использования.

Актеры.

Актер представляет собой некоторую роль, которую играет пользователь по отношению к системе. На рисунке 4 актера:

- менеджер по продажам;

- трейдер;

- продавец;

- система счетов клиентов.

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

Актеры связаны с вариантами исполнения. Один актер может выполнить много вариантов использования. В свою очередь, у варианта использования может быть несколько актеров, которые его выполняют.

Актеры наиболее полезны при попытке сформулировать варианты использования на практике. В случае большой системы, часто трудно определить список вариантов использования. В такой ситуации бывает проще сначала перечислить всех актеров, после чего из них попытаться разработать вариант использования.

Актеры не обязаны быть людьми, хотя на диаграмме вариантов использования изображены в виде людей. Отдельный актер может быть даже внешней системой, которой необходима некоторая информация от разрабатываемой системы.

Существует несколько вариантов изображения актеров. Некоторые разработчики учитывают каждую внешнюю систему или пользователя как актёра, другие – указывают только инициатора варианта использования.

Хотя система счетов клиентов и получает сервис от разрабатываемой системы, на диаграмме вариантов использования не показывается тот факт, что кто-либо из актёров может получать информацию от самой системы счетов клиентов. Эту ситуацию следует представить при разработке модели собственно системы счетов клиентов.

В процессе работы с актерами и вариантами использования нужно уточнять точность установления отношений между ними. Пока не выявились все варианты использования не интересует детальное описание актёров.

Иногда все же встречаются ситуации, когда, возможно, следует больше внимания уделять актерам:

  1. Для разных видов пользователей может потребоваться переконфигурация системы. Тогда каждый вид пользователей представляет собой актера, а варианты использования укажут, что должен делать каждый из этих актеров.

  2. Акцент на получение желаемого сервиса от вариантов использования может помочь установить приоритеты между различными актёрами.

Некоторые варианты использования могут не иметь очевидных связей с отдельными актерами.

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

Отношение включения имеет место, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования.

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

  1. использовать отношения включения, когда приходится повторять одно и тоже в двух или более отдельных вариантах использования;

  2. использовать отношение обобщения, когда описывается изменение некоторой нормализации поведения поверхности;

  3. использовать отношение расширения, когда описывается изменение некоторого формального поведения в более детальной форме.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]