Сценарий использования

Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.

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

История

В 1986 году Ивар Якобсон, позже соавтор Унифицированного Языка Моделирования (UML) и Рационального Унифицированного Процесса (RUP), впервые сформулировал методику визуального моделирования для описания сценариев использования. Первоначально он использовал несколько иные термины — англ. usage scenarios и usage case, но ни один из них не был естественным для английского языка. И в конечном счете он остановился на термине use case — сценарий использования. После создания Якобсоном методики моделирования сценариев использования многие люди поспособствовали улучшению этой методики, включая Курта Биттнера, Алистера Кокберна, Ганнэра Овергарда, и Джери Шнайдера.

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

Цели сценариев использования

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

Сценарии использования не должны путаться с понятием свойств системы (англ. Feature). Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования.

Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актер (англ. Actor) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Тот же самый человек, использующий систему, может быть представлен как различные актеры, потому что они играют различные роли. Например, «Джек» может играть роль Клиента использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.

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

Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.

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

Сценарий использования должен:

• Описывать что именно система должна сделать, чтобы актер достиг своей цели.
• Не затрагивать деталей реализации.
• Иметь достаточный уровень детализации.
• Не описывать пользовательские интерфейсы и экраны. Это делается во время дизайна пользовательского интерфейса.

Уровень детализации

Алистер Кокберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

• Краткий сценарий использования

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

• Обычный сценарий использования

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

• Полностью детализированный сценарий использования

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

Подходящая детализация

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

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

Рациональный Унифицированный Процесс (RUP) стимулирует разработчиков использовать краткое описание сценариев использования в диаграмме сценариев использования с обычным уровнем детализации в виде комментария и детальным описанием в текстовом анализе. Сценарии могут быть задокументированы с помощью специальных инструментов (например, UML Tool, SysML Tool), или написаны в обычном текстовом редакторе.

Нотация сценариев использования

Основная статья: Прецедент (UML)

В Унифицированном языке моделирования отношениях между всеми или частью сценариев использования и актерами представлены в виде диаграммы сценария использования или диаграммах, первоначально основанных на объектной записи Ивара Якобсона. SysML использует то же самое представление на системном уровне.

На диаграммах сценариев использования в UML сценариев отображается в виде эллипса. Внутри эллипса или под ним указывается имя элемента.

К сценариям использования в UML применимы следующие виды отношений:

• Ассоциация (англ. Association) — может указывать на то, что актер инициирует соответствующий вариант использования.

В том числе между прецедентами:

• Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.
• Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
• Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей.

Сценарии использования и процесс разработки

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

Шаблоны сценариев использования

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

Имя сценария

Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше чем Регистрирующийся Пользователь), и должно объяснять о чем сценарий использования.

Неплохо использовать как имя сценария цель актера, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.

Цель

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

Актеры

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

Заинтересованные лица

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

Предварительное условия

Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария.

Активаторы

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

Есть несколько вариантов как описать ситуацию, когда активация происходит, но предварительные условия не удовлетворены.

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

Порядок Событий

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

Альтернативные пути и дополнения

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

Бизнес правила

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

Ограничения сценариев использования

• Сценарии использования плохо подходят для документирования требований не основанных на взаимодействии с системой (таких как алгоритм или математические требования) или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность).
• Следование шаблонам не гарантирует качество сценариев. Качество зависит только от навыков создателя сценария.
• Есть кривая обучения правильному пониманию сценариев использования, как для конечных пользователей так и для разработчиков. Так как нет никаких полностью стандартных определений сценариев, каждая группа должна постепенно развивать свою собственную интерпретацию.
• Сторонники Экстремального программирования часто считают сценарии использования слишком формальными документами, предпочитая использовать более простой подход пользовательских историй.
• Создателям сценариев часто сложно определить на каком уровне следует описывать пользовательский интерфейс (UI). Хоть теория сценариев использования и предлагает, чтобы пользовательские интерфейсы не описывались в сценариях, часто достаточно трудно описать сценарий не затрагивая описания пользовательского интерфейса.
• Важность сценариев использования может быть переоценена. В книге «Object Oriented Software Construction» (2-ой выпуск), Бертран Мейер обсуждает проблемы, такие как проектирование системы только по сценариям использования исключая другие потенциально ценные методики анализа требований.
• Сценарии использования получили некоторый интерес как отправная точка для тест дизайна. Определенная литература по сценариям использования, однако, утверждает что предварительные и результирующие условия, описанные в сценарии, должны применяться ко всему сценарию (то есть, ко всем возможным путям развития сценария). Это ограничивает пользу сценариев с точки зрения тест дизайна. Если результирующие условия сценария использования являются достаточно общими, чтобы быть правильными для всех вариантов развития событий, они вероятно бесполезны как основа для определения ожидаемого поведения системы в тест дизайне. Например, результирующие условия неудавшейся попытки снять наличные деньги из банкомата отличаются от результирующих условий после успешной операции. Если результирующие условия отразят этот факт, то они также будут отличаться. Если результирующие условия не отражают этого, то они не могут использоваться для определения ожидаемого поведения тестов.

См. также

• Прецедент (UML)
• Анализ требований

Примечания

Ссылки

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