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

Сценарий использования: Актор (зарегистрированный пользователь Wiki) редактирует статью. Схема создана на основ описания на языке UML

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя сценария

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

Цель

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

Акторы (действующие лица)

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

Заинтересованные лица (Стейкхолдеры)

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

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

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

Активаторы

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

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

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

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

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

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

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

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

Бизнес-правила — способ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

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

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

См. также

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

Ссылки

• Use Case 2.0. Неофициальный перевод
• Use Case VS User Story Выбираем подход к специфицированию требований