Сценарии событий
Событийные сценарии (event scenarios) используются для документирования поведения системы, представленного определенными событиями. В большинстве случаев сценарий включает в себя:
· Описание начального состояния системы.
· Описание нормального протекания событий.
· Описание исключительных ситуаций и способов их обработки.
· Сведения о других действиях, которые можно выполнять во время реализации сценария.
· Описание конечного состояния системы.
Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].
Пример 3.1.
На рисунке 3.1 приведен сценарий события “Регистрировать программу”, который описывает процесс регистрации новой программы в реестре организации-разработчика.
На первом этапе производится проверка полномочий. Если необходимо, чтобы разработчик, регистрирующий программу, обладал некоторыми полномочиями, например, был участником выполнения данного контракта и занимал определенное положение в команде, то возможны две исключительные ситуации:
· Полномочия недостаточны. Отказ в регистрации программы.
· Незарегистрированный контракт. Отказ в регистрации программы.
Следующий этап – проверка наличия программы – позволяет выявить исключительную ситуацию “Программа зарегистрирована”, при которой разработчику выдается номер, ранее присвоенный программе, и выполняется отказ в регистрации.
Рис. 3.1
Завершается сеанс регистрацией программы, т.е. занесением ее характеристик (наименования, сведений о контракте и других атрибутов) в реестр программ, разработанных организацией, и выдачей ее регистрационного номера разработчику (регистрирующему).
Варианты использования
Варианты использования – это методика формирования требований, основанная на сценариях.
Вариант использования описывает поведение системы при ее ответах на запрос одного из участников (пользователей) системы, называемого основным действующим лицом, в различных условиях [7].
Основное действующее лицо взаимодействует с системой для достижения некоторой цели. Система, отвечая, должна соблюдать интересы всех участников. Различные модели поведения, или сценарии, развертываются в зависимости от определенных запросов и условий, при которых делались эти запросы. Вариант использования собирает вместе эти сценарии. Если вариант использования пишется как требование, то его не следует преобразовывать в другую форму требований к поведению системы, т.к. он точно описывает, что должна делать система. Нужно помнить, что варианты использования – это только часть всех требований, т.к. они не описывают внешние интерфейсы, форматы данных, бизнес-правила и другие нефункциональные требования.
Способ представления вариантов использования зависит от знаний и умений людей (пользователей и разработчиков), средством связи между которыми, они служат. Это может быть текстовая форма, блок-схемы, диаграммы язык программирования и т.д.
При написании варианта использования нужно помнить о трех понятиях, которые служат основой при написании варианта и любого его предложения. Это следующие понятия:
1. Область действия, которая определяет, насколько велика разрабатываемая система.
2. Основное действующее лицо – участник, который обращается к системе, чтобы она обеспечила достижение его цели.
3. Уровень, который определяет, насколько высока эта цель.
Требования должны быть короткими и ясными, поэтому основные рекомендации по написанию варианта использования могут быть следующими [7]:
· Начните со стратегического варианта. От него будут ветвиться варианты использования уровня цели пользователя.
· Именуйте варианты использования с помощью коротких глагольных конструкций, объявляющих цель, которая должна быть достигнута.
· На каждом шаге четко определяйте действующее лицо и его намерения.
· Для описания альтернативного поведения применяйте расширения, а не предложения типа «если … то … иначе» в теле главного варианта использования.
· Для записи шагов варианта использования применяйте только предложения в настоящем времени, с глаголом действия в действительном залоге, и описывающее как действующее лицо успешно достигает цели, продвигающей весь процесс.
Пример 3.2.
Вариант использования “Принять программу в архив”.
Основное действующее лицо: Приемщик.
Область действия: Архив.
Уровень: Цель пользователя.
Основной сценарий:
1. Разработчик сообщает свои характеристики приемщику.
2. Приемщик проверяет полномочия разработчика.
3. Разработчик сообщает регистрационный номер программы.
4. Приемщик проверяет отсутствие программы в архиве.
5. Приемщик получает от разработчика:
ü носитель-оригинал с программой;
ü ведомость носителя, описывающую файлы, находящиеся на носителе-оригинале и их контрольные характеристики.
6. Приемщик контролирует соответствие содержимого носителя и его ведомости.
7. Приемщик копирует содержимое носителя-оригинала на проверенный и зарегистрированный архивный носитель.
8. Приемщик регистрирует копию в качестве подлинника программы.
9. Приемщик передает сведения о приеме программы в архив разработчику.
Расширения:
2а. Полномочия разработчика недостаточны для сдачи программы в архив:
2а1. Приемщик сообщает об этом разработчику, отказывает в приеме программы и переходит в исходное состояние.
4а. Программа уже находится в архиве:
4а1. Приемщик сообщает об этом разработчику, отказывает в приеме программы, выдает ему инвентарный номер, под которым программа принята в архив, и переходит в исходное состояние.
6а. Носитель содержит “лишние” файлы:
6а1. Разработчик уточняет состав файлов программы.
6а2. Приемщик переходит к пункту 7.
6б. Неверные контрольные характеристики файла (файлов):
6б1. Приемщик сообщает об этом разработчику, отказывает в приеме программы и переходит в исходное состояние.