Сценарии use case. Описание (потоки событий) и назначение сценариев

Сценарий, поиск объектов в потоке событий Для перехода от вариантов использования к архитектуре программной системы используются текстовые описания потоков событий, называемые сценариями (scenario). Анализируются имена-существительные в тексте сценария. Некоторые из них будут действующими лицами, другие — объектами, а третьи — атрибутами объекта. Как правило, каждый вариант использования включает несколько потоков:

• типовой ход событий – основной поток, результат которого ожидаем в данном варианте использования;

• альтернативный поток событий – таких потоков может быть несколько, каждый из них приводит к своему результату. Различные потоки событий возникают в точке ветвления при наличии решающего правила «если». В качестве альтернативных сценариев следует предусматривать и «ошибочные» потоки событий, когда актер, являясь физическим лицом, допускает одну из возможных ошибок в действиях. Как и для вариантов использования, существует двухэтапный подход к написанию сценариев. На первом этапе сценарий пишут в произвольной форме с высоким уровнем абстракции. Целью такого сценария будет не выявление объектов, а поверхностное описание потока событий для общего понятия выполняемого функционала и выявления скрытых функций в данном варианте использования. На втором этапе сценарии уточняют и подробно описывают в табличной форме с указанием начальных и конечных условий, точек ветвления с привязкой к разработанному для этого сценария или для группы сценариев проекту графического интерфейса пользователя GUI (graphical user interface). Данные сценарии используются для поиска объектов в потоке событий.

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

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

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

o 25 Диаграммы деятельности. Назначение. Основные элементы (Activity, State, Start State, Stop State, State Transition, State to self, Synchronization, Decision, Swimlane)

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

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

Графическое изображение	Всплывающая подсказка	Назначение кнопки
	State	Добавляет на диаграмму состояние - ситуация в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает какого-то события.
	Activity	Добавляет на диаграмму деятельность
	Start State	Добавляет на диаграмму начальное состояние - начальное состояние, в котором система находится сразу после включения, либо объект сразу после своего создания, либо начальные условия use case.
	End State	Добавляет на диаграмму конечное состояние
	State Transition	Добавляет на диаграмму переход
	Transition to Self	Добавляет на диаграмму рефлексивный переход
	Horizontal Synchronization	Добавляет на диаграмму горизонтально расположенный символ синхронизации - синхронизация позволяет определить независимо выполняемые переходы. При этом переходы могут разделяться на несколько выполняемых независимо (разделение) или, наоборот, несколько входящих переходов будут сливаться в один исходящий.
	Vertical Synchronization	Добавляет на диаграмму вертикально расположенный символ синхронизации
	Decision	Добавляет на диаграмму символ принятия решения для альтернативных переходов -
	Swimlane	Добавляет на диаграмму дорожку - - позволяет моделировать последовательность действий различных объектов и связи между ними. При помощи этого элемента можно моделировать бизнес-процессы организации, отражая на диаграмме различные подразделения и объекты, играющие важные роли в модели бизнеса