Сценарий - это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия.

Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения.

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

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

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

Хорошим примером сценария является описание последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас " how-to videos", в которых такие последовательности отображаются визуально, на конкретных примерах.

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

 

Отображение сценария на диаграммах прецедентов

Сценарии можно, если это помогает пониманию и разработке информационной системы, отображать на диаграмме прецедентов. Это можно сделать различными способами:

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

2.Иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 7.7).

Рис. 6.7.

 

Запись сценария

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

Это может быть:

· структурированный, но неформализованный текст,

· формализованный структурированный текст,

· псевдокод,

· таблица,

· диаграмма активностей, наконец!

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

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

Вот пример простого (неформализованного) текстового описания сценария.

Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку " Далее". Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку " Далее". Система проверяет соответствие кода изображенному на картинке.

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

А вот тот же сценарий в табличном представлении:

Действия пользователя	Реакция системы
Ввод логина, пароля, адреса электронной почты и нажатие кнопки " Далее"	Запрос ввода проверочного кода
Ввод проверочного кода и нажатие кнопки " Далее"	Проверка кода на соответствие изображенному на картинке

 

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

 

7.5 Связь прецедента и сценария (сценариев! )

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

Таким образом, прецедент можно специфицировать ( то есть полностью определить) путем описания потока действий или событий в текстовой форме - в виде, понятном для " постороннего" ( не занятого в непосредственной разработке системы) читателя. А ведь такое описание - это и есть сценарий!

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

В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой " псевдодиаграммой" (рис. 7.8).

Рис. 7.8. Отображение взаимосвязи между требованиями, прецедентами и сценариями в виде специфической диаграммы"

На этой диаграмме для каждой ассоциации проставлена кратность, что не разрешается делать на «канонической» диаграмме прецедентов. Смысл этой кратности вполне понятен: один прецедент определяет несколько сценариев, каждый из которых представляет один из возможных вариантов определяемого прецедентом потока событий.

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

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

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

 

⇐ Предыдущая123Следующая ⇒

Поделиться: