Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 11 12 13 [ 14 ] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

цию о кредитной карточке и совершает платеж. Система проверяет авторизацию кредитной карточки и подтверждает оплату товара тотчас же и по электронной почте.

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

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

Ниже представлен простой формат для записи варианта использования, в котором исходный сценарий описан в виде последовательности нумерованных шагов, а альтернативы могут изменять эту последовательность (рис. 3.1).

Покупка товара

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

2. Покупатель оценивает стоимость всех товаров.

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

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

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

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

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

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

Альтернатива: Неудача авторизации

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

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

Альтернатива: Постоянный покупатель

За. Система предоставляет информацию о текущей покупке и ее цене, а также последние 4 цифры информации о кредитной карточке.

36. Покупатель может согласиться или отказаться от предложенной системой информации.

После этого перейти на шаг 6 исходного сценария.

Рис. 3.1. Текст примера варианта использования

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

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

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

Количество деталей в сценарии зависит от риска в соответствующем варианте использования: чем больше риск, тем больше деталей необходимо указать. Часто случается так, что на фазе исследования я детально описываю только небольшое количество вариантов использования, в то время как остальные из них содержат не больше информации, чем вариант использования на рис. 3.1. В процессе итерации вы можете добавить в вариант использования больше деталей, если они необходимы для его реализации. При этом можно не записывать все детали явным образом; часто очень эффективно их вербальное понимание.

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

Когда А. Джекобсон в 1994 г. [24] предложил варианты использования в качестве основных элементов процесса разработки программного обеспечения, он ввел также диаграмму для их наглядного представления. Диаграмма вариантов использования в настоящее время также является частью языка UML.

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

На рис. 3.2 показаны некоторые варианты использования для финансовой торговой системы (трейдинг).

Менеджер по продажам

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

Вариант использования

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

Актеры

Актер представляет собой некоторую роль, которую играет пользователь по отношению к системе. На рис. 3.2 представлены 4 актера: менеджер по продажам, трейдер (оптовый торговец), продавец и система счетов клиентов. (Да, я знаю, что было бы лучше использовать слово роль , но, по всей видимости, имел место неточный перевод со шведского языка.)

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

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

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

1 2 3 4 5 6 7 8 9 10 11 12 13 [ 14 ] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.