Сценарии использования программного обеспечения пользователем согласно формату описания кобейна

1. Провести анализ
предметной области в соответствии с
выбранным задани-

ем.

2.
Составить 5 сценариев использования
программного обеспечения пользователем
согласно формату описания Кобейна.

3. Оформить отчет
о проделанной работе.

4. Защитить
лабораторную работу.

4. Варианты заданий

1.
Интернет-магазин. Должны быть реализованы
сценарии: покупка товара, поиск товара,
добавление нового товара в базу данных
магазина, просмотр и обработка заказов
покупателей, регистрация нового
покупателя.

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

3.
Адресная книга. Должны быть реализованы
сценарии: добавление нового абонента,
добавление категорий абонентов, поиск
абонентов по нескольким полям, добавления
администраторе каталога (пользователей,
которые имеют право редактировать
данные адресной книги), редактирование
данных абонента.

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

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

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

7.
База склада фирмы. Должны быть реализованы
сценарии: добавление нового товара на
склад, списание товара, выдача товара,
поиск товара по различным полям, изменение
месторасположения товара на складе.

8.
Аптечная база. Должны быть реализованы
сценарии: прием заказа от клиента на
изготовление раствора, продажа лекарства,
списание просроченных лекарств,
добавление новые лекарств в базу данных,
поиск заказов по различным полям.

5. Контрольные
вопросы

1. Каким образом
производится моделирование задач?

2. Что такое сценарий
использования?

3. Что такое элемент
use case?

4. Что такое
сущностные элементы use case?

5. Чем отличаются
сценарии использования от модели use
case?

6. Каким образом
можно описать варианты использования?

7. Приведите пример
описания варианта использования по
Коберну?

Лабораторная работа № 2 Принципы проектирования пользовательского интерфейса

1. Цель работы:

Создание
прототипа интерфейса windows-приложения.

2. Методические указания

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

Структурный
принцип

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

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

Принцип простоты

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

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

Принцип видимости

Все
функции и данные, необходимые для
выполнения данной задачи, должны быть
видны, чтобы пользователь не отвлекался
на дополнительную и избыточную информацию.
Принцип видимости связан с проектированием
таких пользовательских интерфейсов, в
которых видны все элементы, нужные для
выполнения данной задачи. Цель – перейти
от философии WYSIWYG
(What
You
See
Is
What
You
Get – что видишь на экране, то и получишь
в результате) к философии WYSIWYN
(What
You
See
Is
What
You
Need
– на экране видишь то, что тебе нужно).
Интерфейсы WYSIWYN оставляют видимыми те,
и только те элементы, которые действительно
нужны пользователю для выполнения
операции. С одной стороны, в задачи
проектирования входит создание такого
интерфейса, на котором были бы явно
видны все нужные и важные функции. С
другой стороны, хороший интерфейс не
должен заваливать пользователя слишком
большим количеством возможных вариантов
или смущать его избыточной информацией.
WYSIWYN-интерфейсы лучше уже тем, что они
принимают во внимание ограниченность
объема «оперативной памяти» человека
и способность узнавать вещи быстрее,
чем вспоминать. Нагрузка на
долговременнуюпамять уменьшается за
счет того, что пользователь постоянно
видит все необходимые опции и варианты.
На кратковременную память нагрузка
снижается за счет того, что пользователю
не приходится запоминать и затем
воспроизводить информацию, содержащуюся
в какой-то другой части интерфейса.

Принцип обратной
связи

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

Хорошие
пользовательские интерфейсы находятся
в диалоге с пользователями, сообщая им
о том, что происходит в системе. Принцип
обратной связи указывает разработчикам
некоторые правила этого диалога.
Практичные системы информируют
пользователя о множестве вещей. К
примеру, они должны позволять ему
узнавать о том, как воспринимаются
вводимые им данные. Всякий раз, когда
меняется внутреннее состояние системы,
и это может оказать какое-либо влияние
на работу пользователя, его следует
уведомлять об этом, особенно если
меняется интерпретация системой его
действий. Разумеется, пользователь
должен знать о действиях, которые
запрещены или игнорируются. При этом
принцип обратной связи не может служить
оправданием созданию бесконечных окошек
сообщений. Информирование пользователя
– не самоцель, а способ организации
диалога в компактной и естественной
форме. Пользователям также требуются
сообщения об ошибках и исключительных
ситуациях. Во многих программах эти
сообщения, к сожалению, неинформативны
и способны ввести в заблуждение. Можно
иногда встретить даже оскорбляющие
сообщения, после прочтения которых
пользователю может стать не по себе.
Вряд ли человек вдохновится, скажем,
такой надписью: «Непра-

вильно!
Введите корректные данные!». Такое
сообщение не только неявно предполагает,
что пользователь – какой-то нехороший
человек, но и, по сути дела, не дает
никакой информации. Здесь не сказано,
что именно неправильно и почему. Грамотно
составленные сообщения об ошибках –
это еще один пример хорошей организации
общения с пользователем. Рекомендации
здесь можно дать такие: краткость; язык,
понятный пользователю; простота
понимания. Прежде всего информативным
должен быть заголовок сообщения. Он
должен в сжатой форме описывать проблему,
а уже само сообщение должно раскрывать
подробности и предлагать способы решения
или последовательность корректирующих
действий.

Принцип
толерантности

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

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

Принцип повторного
использования

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя сценария

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

Цель

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

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

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

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

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

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

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

Активаторы

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

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

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

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

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

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

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

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

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

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

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

См. также

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

Примечания

1. ↑ UML Специальный справочник: «use case (вариант использования, прецедент)». Дата обращения: 21 сентября 2015. Архивировано из оригинала 4 марта 2016 года.

Ссылки

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

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

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

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой. 

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

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

Один сценарий использования должен описывать действия пользователя, которые приведут к одному большому действию- функционалу пользователя. Например, авторизоваться, добавить товар в корзину и тд. 

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

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

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

Сценарии использования включают в себя следующие разделы: 

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

1. Предусловие. Формулировка условий, при которых данный вариант использования может быть инициирован. Условие, помимо прочего, может быть упоминанием о выполнении других вариантов использования. Также в предусловии необходимо указывать, в какой части системы находится пользователь, кратко- какие действия уже выполнил.

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.

2. Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

1. Система выводит информер  с указанием запрещенных символов.

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Когда какая-либо IT-компания начинает разработку программного продукта, ей приходится задумываться о том, как быстрее и проще начать реализацию проекта и создать прототип, с помощью которого можно передать все функциональные возможности ПП. Что такое Use Case, для чего он нужен, чем он может помочь в разработке — расскажет наша статья.

---

Что такое Use Case

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

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

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

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

---

В каких ситуациях может помочь Use Case

Грамотно составленный юзеркейс может помочь в тех случаях, когда:

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

Также Use Case незаменим в тех случаях, когда один и тот же кейс по-своему реализован в разных местах, тем самым затягивая процесс разработки ПП.

---

В чем польза юзеркейса

Качественно составленный Use Case может решать разные задачи. Например:

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

Use Case играет важную роль, когда необходимо подготовить прототип ПП, который покажет особенности и преимущества проекта.

---

Из каких элементов состоит Use Case

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

1. Actor — человек, который пользуется созданной системой. В качестве примера можно привести какой-нибудь интернет-магазин, где в качестве actor выступают продавцы, покупатели, поставщики и все те, кто взаимодействует с этим интернет-магазином.
2. Primary actor — это человек, у которого получается достигнуть поставленных целей с помощью созданного программного продукта. Если вернуться к тому же интернет-магазину, то primary actor в нем может быть производитель вещей, у которого получается реализовывать эти вещи с помощью функционала онлайн-площадки.
3. Stakeholder — человек, который заинтересован в том, чтобы созданы ПП выполнял те или иные действия. В интернет-магазине это может быть какой-нибудь партнер, получающий доход от приведенных покупателей, или подключенная к магазину платежная платформа, через которую совершаются онлайн-платежи.

Также к элементам юзеркейса относятся:

• понятный заголовок, содержащий конечный результат Use Case;
• описание последовательности действий;
• результат, к которому должен привести юзеркейс;
• предусловия — это то, что должно произойти до или после запуска кейса;
• триггеры, влияющие на запуск кейса.

А еще в любом Use Case должны быть прописаны альтернативные пути — события, к которым прибегают в том случае, если кейс не сработал.

---

Какими должен качественный быть Use Case

Высокое качество юзеркейса определяют следующие критерии:

1. Правильная детализация. При составлении Use Case нет смысла описывать каждый шаг пользователей и состояние элементов ПП в этот момент. Главная задача юзеркейса — всего лишь дать общую картину.
2. Простота изложения. Чтобы содержимое юзеркейса было понятным даже новым членам команды, его необходимо писать максимально простым языком. Не стоит использовать для Use Case сложные термины и вставки кода.
3. Единый стиль. Старайтесь использовать для всех юзеркейсов один и тот же шаблон. Это поможет сэкономить время на изучении ПП.

1. Важен контекст. В каждом юзеркейсе должны быть уточнения по поводу тех или иных действий. Так разработчики смогут разобраться в том, какая задача перед ними стоит.
2. Целенаправленность. Не стоит использовать юзеркейса для того, чтобы описать весь путь пользователя. Лучше представить конкретные шаги (регистрация, покупка, отправка заявки и так далее).

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

---

Какую пользу несет Use Case для определенных специалистов в команде

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

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

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

---

Как  составить Use Case

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

Чтобы составить юзерйкейс, необходимо выполнить следующие действия:

1. В первую очередь определяем, какие пользователи будут работать с программным продуктом. Помочь в этом может обычный анализ рынка и ЦА.
2. Выявляем определенную группу пользователей, которые будут работать с ПП.
3. Рисуем портрет группы пользователей и приблизительно определяем, что они будут делать разрабатываемой программе. Каждое действие в рамках ПП — потенциальный Use Case.
4. Определяем последовательность действий для каждого юзеркейса.
5. Приблизительно описываем основной путь пользователя.
6. Прогнозируем ответ системы на действия пользователя.
7. Разрабатываем альтернативные пути для расширения юзеркейса.
8. Повторяем перечисленные шаги для каждой группы пользователей.

Есть пара советов, которые помогут в составлении юзеркейсов. Во-первых, для экономии времени следует разработать шаблон. Такой подход позволит выработать единый стиль и экономить время при разработке других кейсов.

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

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

---

Пример 1: регистрация на сайте

Результат кейса: пользователь создает аккаунт с личным кабинетом.

Номер шага	Действующее лицо	Действие
1	Пользователь	Пользователь нажимает на кнопку регистрации
2	Система	Открывает форма регистрации
3	Пользователь	Пользователь заполняет форма, указывает данные, подтверждает регистрацию
4	Система	Идет проверка корректности заполнения, пользователь вносится в базу данных, на почту отправляется письмо со ссылкой для активации акк
5	Пользователь	Пользователь открывает письмо, переходит по ссылке
6	Система	Система активирует аккаунт, высылает инструкцию по работе с сервисом

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

---

Пример 2: регистрация в интернет-магазине по сложной схеме

• цель: зарегистрироваться в интернет-магазине;
• действующее лицо: незарегистрированный пользователь;
• триггер: пользователь увидел рекламу интернет-магазина и решил зарегистрироваться;
• результат: у пользователя появляется аккаунт с бонусной системой.

Шаги юзеркейса выглядят следующим образом:

1. Пользователь нажимает на кнопку регистрации.
2. Система открывает форму регистрации, запрашивает контактные данные и платежные реквизиты.
3. Пользователь заполняет поля, отправляет на проверку.
4. Система проверяет инфу на корректность, вносит пользователя в базу, отправляет письмо со ссылкой активации.
5. Пользователь открывает письмо, переходит по ссылке.
6. Система активирует аккаунт.

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

---

Пример 3: кейс по взаимодействию с сайтом вуза на примере диаграммы

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

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

---

Эксперты отвечают
 

Вывод

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

Разработка программного обеспечения
Активность ядер
Процессы Требования Дизайн Инженерное дело Строительство Тестирование Отладка Развертывание Обслуживание
Парадигмы и модели
Гибкий Чистая комната Инкрементальный Прототипирование Спираль V модель Водопад
Методологии и рамки
ASD DevOps ПАПА DSDM FDD IID Канбан Lean SD Меньше MDD MSF PSP РАД RUP Безопасный Scrum SEMAT TSP Открыть ВВЕРХ XP
Вспомогательные дисциплины
Управление конфигурацией Документация Обеспечение качества программного обеспечения (SQA) Управление проектом Пользовательский опыт
Практики
ATDD BDD CCO CI CD DDD PP SBE Вставать TDD
Инструменты
Компилятор Отладчик Профайлер Дизайнер графического интерфейса Моделирование IDE Автоматизация сборки Автоматизация выпуска Инфраструктура как код Тестирование
Стандарты и свод знаний
БАБОК CMMI Стандарты IEEE ISO 9001 Стандарты ISO / IEC PMBOK SWEBOK ITIL IREB
Глоссарии
Искусственный интеллект Информатика Электротехника и электроника
Контуры
План разработки программного обеспечения

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

История

В 1987 г. Ивар Якобсон представляет первую статью о вариантах использования на OOPSLA Конференция 87 года.^[1] Он описывает, как этот метод использовался в Эриксон фиксировать и определять требования к системе, используя текстовые, структурные и визуальное моделирование методы объектно-ориентированного анализа и проектирования.^[2] Первоначально он использовал термины сценарии использования и случай использования — последний прямой перевод его шведского термина användningsfall — но обнаружил, что ни один из этих терминов не звучит естественно по-английски, и в конце концов остановился на вариант использования.^[3]

В 1992 году он соавтор книги. Объектно-ориентированная разработка программного обеспечения — подход, основанный на сценариях использования,^[4] которые заложили основу OOSE метод системной инженерии и помог популяризировать варианты использования для сбора функциональные требования, особенно в разработка программного обеспечения. В 1994 году он издает книгу о вариантах использования и объектно-ориентированных методах, применяемых к бизнес-модели и процесс реорганизации бизнеса.^[5]

В то же время, Грейди Буч и Джеймс Рамбо работать над объединением своих объектно-ориентированный анализ и дизайн методы, Метод Буча и Метод объектного моделирования (OMT) соответственно. В 1995 году к ним присоединился Ивар Якобсон, и вместе они создали Единый язык моделирования (UML), который включает моделирование вариантов использования. UML стандартизирован Группа управления объектами (OMG) в 1997 г.^[6] Джейкобсон, Буч и Рамбо также работают над усовершенствованием Цель процесс разработки программного обеспечения. Результирующий Единый процесс опубликовано в 1999 году и продвигает подход, основанный на вариантах использования.^[7]

С тех пор многие авторы внесли свой вклад в развитие этой техники, в частности: Ларри Константин развивается в 1995 г. в контексте ориентированный на использование дизайн, так называемые «основные варианты использования», которые нацелены на описание намерений пользователя, а не на последовательность действий или сценариев, которые могут ограничивать или искажать дизайн пользовательского интерфейса;^[8] Алистер Кокберн публикует в 2000 г. целевые примеры использования, основанные на текстовых описаниях и табличных спецификациях;^[9] Курт Биттнер и Ян Спенс в 2002 году разработали передовые методы анализа функциональных требований с помощью вариантов использования;^[10] Дин Леффингуэлл и Дон Видриг предлагают применять варианты использования для управления изменениями и взаимодействия с заинтересованными сторонами;^[11] В 2004 году Гуннар Овергаард предложил распространить принципы шаблонов проектирования на сценарии использования.^[12]

В 2011 году Джейкобсон вместе с Яном Спенсом и Куртом Биттнером издает электронную книгу Пример использования 2.0 адаптировать методику к гибкому контексту, обогатить ее дополнительными «фрагментами» вариантов использования и продвигать ее использование на протяжении всего жизненного цикла разработки.^[13] представив обновленный подход на ежегодном IIBA конференция.^[14][15]

Основной принцип

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

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

Согласно Свод знаний программной инженерии (SWEBOK),^[16] варианты использования относятся к основанным на сценариях требование техники, а также модельный анализ техники. Но варианты использования также поддерживают сбор требований на основе повествования, сбор дополнительных требований, системную документацию и приемочное тестирование.^[1]

Вариации

Существуют разные варианты использования и вариации техники:

• Сценарии использования системы определяют требования к разрабатываемой системе.^[2] В своем подробном описании они идентифицируют не только взаимодействия с акторами, но и сущности, участвующие в обработке. Они являются отправной точкой для дальнейшего анализа моделей и проектной деятельности.
• Сценарии бизнес-использования сосредоточены на бизнес-организации, а не на программной системе. Они используются для определения бизнес-моделей и требований бизнес-процессов в контексте инициатив по реинжинирингу бизнес-процессов.^[5]
• Существенные варианты использования, также называемые абстрактными вариантами использования, описывают потенциальные намерения участников и то, как система их решает, без определения какой-либо последовательности или описания сценария.^[8] Эта практика была разработана с целью поддержки дизайна, ориентированного на пользователя, и предотвращения предвзятого отношения к пользовательскому интерфейсу на ранней стадии спецификации системы.^[7]
• Вариант использования 2.0 адаптирует методику к контексту методов гибкой разработки.^[1] Этот метод обогащает практику сбора требований поддержкой повествований пользовательских историй. Он также предоставляет «срезы» вариантов использования для облегчения инкрементального выявления требований и обеспечения инкрементной реализации.

Объем

Объем варианта использования может определяться предметом и целями:

• Субъект определяет систему, подсистему или компонент, который будет обеспечивать взаимодействие.^[17]
• Цели могут быть структурированы иерархически с учетом уровня организации, заинтересованного в цели (например, компания, отдел, пользователь), и декомпозиции цели пользователя на подцели.^[9] Декомпозиция цели выполняется с точки зрения пользователей и независимо от системы, что отличается от традиционной функциональной декомпозиции.^[10]  

использование

Известно, что варианты использования применяются в следующих контекстах:

• Объектно-ориентированная разработка программного обеспечения (OOSE), как движущий элемент;^[4]
• Единый язык моделирования (UML) как инструмент поведенческого моделирования;^[17]
• Единый процесс разработки программного обеспечения (UP) и его предшественник, IBM Рациональный унифицированный процесс (RUP);^[7]

• предварительная документация спецификация требований к программному обеспечению (SRS), как альтернативная структура для функциональных требований;^[18]
• получение дизайна из требований с использованием объект-контроль-граница подход;^[7]
• и гибкое развитие.^[1][19]

Шаблоны

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

Кокберн стиль

Шаблон, определенный Алистер Кокберн в его книге Написание эффективных сценариев использования был одним из наиболее широко используемых стилей написания сценариев использования.^{[нужна цитата ]}

Объемы проектирования

Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «Объем проектирования», который может быть черным ящиком (внутренние детали скрыты) или белым ящиком (показаны внутренние детали). Доступны пять символов:^[20]

Объем	Значок
Организация (черный ящик)	Заполненный дом
Организация (белый ящик)	Незаполненный дом
Система (черный ящик)	Заполненная коробка
Система (белый ящик)	Незаполненная коробка
Компонент	Винт или болт

Другие авторы иногда называют варианты использования на уровне организации «бизнес-вариантами использования».^[21]

Уровни целей

Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «Уровень цели»;^[22] предпочтительный уровень — «Пользователь-цель» (или в просторечии «уровень моря»^[23]:101).

Уровень цели	Значок	Символ
Очень высокая сводка	Облако	++
Резюме	Летающих змей	+
Пользовательская цель	Волны в море	!
Подфункция	Рыбы	—
Слишком низко	Морской моллюск	—

Иногда при написании текста имя варианта использования, за которым следует альтернативный текстовый символ (!, +, — и т. Д.), Является более кратким и удобным способом обозначения уровней, например оформить заказ!, авторизоваться-.

Полностью одет

Кокберн описывает более подробную структуру варианта использования, но позволяет упростить ее, когда требуется меньше деталей. В его полностью одетом шаблоне варианта использования перечислены следующие поля:^[24]

• Заголовок: «Целевая фраза с активным глаголом, обозначающая цель основного действующего лица»^[25]
• Основной актер
• Цель в контексте
• Объем
• Уровень
• Заинтересованные стороны и интересы
• Предварительное условие
• Минимальные гарантии
• Гарантии успеха
• Спусковой крючок
• Основной сценарий успеха
• Расширения
• Список вариантов технологий и данных

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

Подход Кокберна повлиял на других авторов; например, Александер и Беус-Дукич обобщают шаблон Кокберна «Полностью одетый вариант использования» с программного обеспечения на системы всех видов, со следующими полями, отличными от Кокберна:^[26]

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

Повседневная

Кокберн признает, что проекты не всегда могут нуждаться в подробных «полностью подготовленных» сценариях использования. Он описывает случайный вариант использования с полями:^[24]

• Название (цель)
• Основной актер
• Объем
• Уровень
• (История): тело варианта использования — это просто параграф или два текста, неформально описывающие происходящее.

Стиль Фаулера

Мартин Фаулер утверждает: «Не существует стандартного способа написания содержимого варианта использования, и разные форматы хорошо работают в разных случаях».^[23]:100 Он описывает «общий стиль использования» следующим образом:^[23]:101

• Заголовок: «цель, которую пытается достичь вариант использования»^[23]:101
• Основной сценарий успеха: пронумерованный список шагов^[23]:101
  • Шаг: «простое изложение взаимодействия между действующим лицом и системой»^[23]:101
• Расширения: отдельно нумерованные списки, по одному на каждое расширение.^[23]:101
  • Расширение: «условие, которое приводит к взаимодействиям, отличным от .. основного сценария успеха». Добавочный номер основного шага 3 имеет номер 3a и т. Д.^[23]:101

Стиль Фаулера также можно рассматривать как упрощенный вариант шаблона Кокберна.

Актеры

Вариант использования определяет взаимодействие между внешними участниками и рассматриваемой системой для достижения цели. Актеры должны уметь принимать решения, но не обязательно должны быть людьми: «Действующим лицом может быть человек, компания или организация, компьютерная программа или компьютерная система — оборудование, программное обеспечение или и то, и другое».^[27] Актеры всегда заинтересованные стороны, но не все заинтересованные стороны являются участниками, поскольку они «никогда не взаимодействуют напрямую с системой, даже если они имеют право заботиться о том, как система ведет себя».^[27] Например, «владельцы системы, совет директоров компании и регулирующие органы, такие как Налоговая служба и Департамент страхования» могут быть заинтересованными сторонами, но вряд ли будут действующими лицами.^[27]

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

Актеры часто работают от имени кого-то другого. Кокберн пишет: «В наши дни я пишу« торговый представитель для клиента »или« клерк для отдела маркетинга », чтобы зафиксировать, что пользователь системы действует для кого-то другого». Это говорит проекту, что «пользовательский интерфейс и допуски безопасности» должны быть разработаны для торгового представителя и клерка, но что роль клиента и отдела маркетинга несут ответственность за результаты.^[28]

Заинтересованная сторона может играть как активную, так и неактивную роль: например, Потребитель является одновременно «покупателем массового рынка» (не взаимодействующим с системой) и пользователем (действующим лицом, активно взаимодействующим с приобретенным продуктом).^[29] В свою очередь, Пользователь является как «обычным оператором» (субъектом, использующим систему по прямому назначению), так и «функциональным бенефициаром» (заинтересованной стороной, получающей выгоду от использования системы).^[29] Например, когда пользователь «Джо» снимает наличные со своего счета, он управляет банкоматом и получает результат от своего имени.

Кокберн советует искать участников среди заинтересованных сторон системы, основных и вспомогательных (вторичных) участников варианта использования, самой разрабатываемой системы (SuD) и, наконец, среди «внутренних участников», а именно компонентов системы. в стадии проектирования.^[27]

Пример использования для бизнеса

Точно так же, как вариант использования описывает серию событий и взаимодействий между пользователем (или другим типом действующего лица) и системой, для получения результата (цели), бизнес-вариант использования описывает более общее взаимодействие. между бизнес-системой и пользователями / участниками этой системы для получения ценных бизнес-результатов. Основное отличие состоит в том, что система, рассматриваемая в модели бизнес-варианта использования, может содержать людей в дополнение к технологическим системам. Этих «людей в системе» называют работниками бизнеса. В примере с рестораном необходимо принять решение, относиться ли к каждому человеку как к действующему лицу (т.е. вне системы) или как к бизнес-работнику (внутри системы). Если официант считается актером, как показано в примере ниже, тогда система ресторана не включает официанта, и модель раскрывает взаимодействие между официантом и рестораном. В качестве альтернативы можно было бы рассматривать официанта как часть ресторанной системы (бизнес-работника), а клиента рассматривать как вне системы (актера).^[30]

Визуальное моделирование

Типы диаграмм UML
Структурные диаграммы UML
Диаграмма классов Схема компонентов Схема составной структуры Схема развертывания Схема объекта Схема упаковки Схема профиля
Диаграммы поведенческого UML
Диаграмма деятельности Схема связи Обзорная диаграмма взаимодействия Схема последовательности Диаграмма состояний Временная диаграмма Диаграмма вариантов использования

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

Кроме того, другие поведенческие диаграммы UML, такие как диаграммы деятельности, диаграммы последовательности, схемы связи и диаграммы состояний также можно использовать для соответствующей визуализации вариантов использования. В частности, Схема системной последовательности (SSD) — это диаграмма последовательности, которая часто используется для отображения взаимодействий между внешними участниками и разрабатываемой системой (SuD), обычно для визуализации конкретного сценария варианта использования.

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

Примеры

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

Пример использования: Редактировать статью

Основной актер: Член (Зарегистрированный пользователь)

Объем: а Вики система

Уровень: ! (Пользовательская цель или уровень моря)

Краткий: (эквивалентно история пользователя или эпос)

Участник редактирует любую часть (всю статью или только раздел) статьи, которую он читает. При редактировании допускается предварительный просмотр и сравнение изменений.

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

…

Постусловия

Минимальные гарантии:

Гарантии успеха:

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

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

Статья с включенным редактированием предоставляется участнику.

Триггеры:

Участник вызывает запрос на редактирование (для всей статьи или только одного раздела) статьи.

Основной поток:

1. Система предоставляет новую область / поле редактора, заполненное всем релевантным содержанием статьи с информативным сводным обзором редактирования, которое может редактировать участник. Если участник просто хочет отредактировать раздел статьи, отображается только исходное содержание раздела, а заголовок раздела автоматически заполняется в сводке редактирования.
2. Участник изменяет содержание статьи до тех пор, пока не будет удовлетворен.
3. Участник заполняет сводку редактирования, сообщает системе, хотят ли они посмотреть эту статью, и отправляет правку.
4. Система сохраняет статью, регистрирует событие редактирования и завершает необходимую постобработку.
5. Система представляет участнику обновленный вид статьи.

Расширения:

2–3.

а. Предварительный просмотр:

1. Участник выбирает Показать предварительный просмотр который отправляет измененный контент.
2. Система повторно запускает шаг 1 с добавлением обработанного обновленного содержимого для предварительного просмотра и сообщает участнику, что его / ее правки еще не были сохранены, а затем продолжает.

б. Показать изменения:

1. Участник выбирает Показать изменения который отправляет измененный контент.
2. Система повторно запускает шаг 1 с добавлением результатов сравнения различий между текущими изменениями, внесенными участником, и самой последней сохраненной версией статьи, а затем продолжает.

c. Отменить редактирование:

1. Участник выбирает Отмена.
2. Система отменяет все изменения, внесенные участником, и переходит к шагу 5.

4а. Тайм-аут:

…

Преимущества

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

1. В списке названий целей указаны самый короткий краткое изложение того, что предлагает система (даже чем пользовательские истории ). Он также предоставляет структуру планирования проекта, которую можно использовать для определения начальных приоритетов, оценок, распределения команд и сроков.
2. Основной успешный сценарий каждого варианта использования дает всем участникам согласие относительно того, что система в основном будет делать, а что нет. Он предоставляет контекст для каждого конкретного требования к позиции (например, подробные пользовательские истории), контекст, который очень трудно найти где-либо еще.
3. Условия расширения для каждого варианта использования обеспечивают основу для исследования всех мелочей, которые так или иначе занимают 80% времени и бюджета разработки. Он обеспечивает механизм прогнозирования, поэтому заинтересованные стороны могут выявить проблемы, ответы на которые могут потребовать много времени. Эти проблемы могут и должны быть решены раньше срока, чтобы ответы были готовы, когда команда разработчиков приступит к работе над ними.
4. Фрагменты сценария расширения варианта использования дают ответы на многие подробные, часто сложные и игнорируемые бизнес-вопросы: «Что мы должны делать в этом случае?» Это структура мышления / документации, которая соответствует выражению if … then … else, которое помогает программистам обдумывать проблемы. За исключением того, что это делается во время расследования, а не во время программирования.
5. Полный набор сценариев использования показывает, что исследователи продумали потребности каждого пользователя, каждую цель, которую они преследуют в отношении системы, и каждый задействованный бизнес-вариант.

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

Ориентирован на пользователя

Сценарии использования представляют собой мощный ориентированный на пользователя инструмент для процесса разработки требований к программному обеспечению.^[32] Моделирование вариантов использования обычно начинается с определения ролей ключевых заинтересованных сторон (актеры) взаимодействия с системой, и их целей или задач, которые система должна выполнять (внешняя перспектива). Эти пользовательские цели затем становятся идеальными кандидатами для названий или заголовков вариантов использования, которые представляют желаемые функциональные возможности или услуги, предоставляемые системой. Этот ориентированный на пользователя подход гарантирует, что разрабатывается то, что имеет реальную ценность для бизнеса и действительно нужно пользователю, а не те тривиальные функции, которые предполагаются с точки зрения разработчика или системы (изнутри).

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

Лучшее общение

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

Требования к качеству при структурированной разведке

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

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

Упрощение тестирования и пользовательской документации

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

Ограничения

Ограничения вариантов использования включают:

• Сценарии использования плохо подходят для регистрации требований системы, не связанных с взаимодействием (таких как алгоритм или математические требования) или нефункциональные требования (например, платформа, производительность, время или аспекты безопасности). Их лучше декларативно указать в другом месте.
• Поскольку полностью стандартных определений вариантов использования не существует, каждый проект должен формировать свою собственную интерпретацию.
• Некоторые отношения вариантов использования, например расширяет, неоднозначны в интерпретации и могут быть трудными для понимания заинтересованными сторонами, как указывает Кокберн (Проблема № 6)^{[34][нужна цитата ]}
• Разработчикам сценариев использования часто бывает сложно определить уровень пользовательский интерфейс (UI) зависимость для включения в вариант использования. Хотя теория вариантов использования предполагает, что пользовательский интерфейс не может быть отражен в вариантах использования, может быть неудобно абстрагироваться от этого аспекта дизайна, поскольку это затрудняет визуализацию вариантов использования. В программной инженерии эта трудность решается применением прослеживаемость требований, например, с матрица прослеживаемости. Другой подход к связыванию элементов пользовательского интерфейса с вариантами использования — это прикрепление дизайна пользовательского интерфейса к каждому этапу варианта использования. Это называется раскадровкой варианта использования.
• Сценарии использования можно переоценить. Бертран Мейер обсуждает такие вопросы, как слишком прямое управление проектированием системы, исходя из вариантов использования, и использование вариантов использования, исключая другие потенциально ценные методы анализа требований.^[35]
• Сценарии использования являются отправной точкой для разработки тестов,^[36] но поскольку для каждого теста нужны собственные критерии успеха, может потребоваться изменить варианты использования, чтобы обеспечить отдельные постусловия для каждого пути.^[37]
• Хотя варианты использования включают цели и контексты, независимо от того, конфликтуют ли эти цели и мотивы, стоящие за целями (проблемы заинтересованных сторон и их оценки, включая отсутствие взаимодействия), или отрицательно / положительно влияют на другие цели системы, они являются предметом целенаправленных методов моделирования требований (таких как BMM, Я*, КАОС и ArchiMate БРОНЯ).

Заблуждения

Эта секция нуждается в расширении. Вы можете помочь добавляя к этому. (Июль 2015 г.)

Распространенные заблуждения о вариантах использования:

Истории пользователей подвижны; варианты использования — нет.

Agile и Scrum нейтральны по требованиям техники. Как Scrum Primer^[38] состояния,

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

Методы использования прецедентов эволюционировали, чтобы учесть подходы Agile за счет использования фрагментов прецедентов для постепенного обогащения прецедентов.^[13]

Варианты использования — это в основном диаграммы.

Крейг Ларман подчеркивает, что «варианты использования — это не диаграммы, это текст».^[39]

В вариантах использования слишком много контента, связанного с пользовательским интерфейсом.

Как говорят некоторые,

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

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

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

Написание сценариев использования для больших систем утомительно и пустая трата времени.

Как говорят некоторые,

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

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

Фактически, форматы вариантов использования, сформулированные эти популярные стили шаблонов, например RUP и Cockburn (также принятые метод ОУМ ) и т. д., зарекомендовали себя на практике как ценные и полезные инструменты для сбора, анализа и документирования сложных требований больших систем. Качество хорошей документации по прецедентам (модель) не следует судить в основном или только по его размеру. Также возможно, что качественная и всеобъемлющая модель варианта использования большой системы может, наконец, превратиться в сотни страниц, главным образом из-за присущей ей сложности проблема в руки, а не из-за плохих навыков письма его авторов.

Инструменты

Текстовые редакторы и / или текстовые процессоры с поддержкой шаблонов часто используются для написания сценариев использования. Для больших и сложных системных требований полезны специальные инструменты для сценариев использования.

Некоторые из хорошо известных инструментов сценариев использования включают:

• CaseComplete
• Архитектор предприятия
• MagicDraw
• Рациональное программное обеспечение RequisitePro — один из первых широко известных инструментов управления сценариями и требованиями в 1990-х годах.
• Разработчик программных идей
• Программное обеспечение вики — хорошие инструменты для команд для совместной разработки и управления сценариями использования.

Наиболее Инструменты UML поддерживают как написание текста, так и визуальное моделирование вариантов использования.

Смотрите также

• Дело о злоупотреблении
• Бизнес-кейс
• Сущность-контроль-граница
• Разделение событий
• Особенность
• Список инструментов UML
• Случай неправильного использования
• Требование
• Выявление требований
• Сценарий
• Раскадровка
• Прецедент
• Точки использования

Рекомендации

дальнейшее чтение

• Александр, Ян и Беус-Дукич, Лерка. Обнаружение требований: как указать продукты и услуги. Wiley, 2009.
• Александр, Ян, и Дева, Нил. Сценарии, истории, сценарии использования. Wiley 2004.
• Армор, Фрэнк и Грэнвилл Миллер. Расширенное моделирование вариантов использования: программные системы. Аддисон-Уэсли, 2000.
• Курт Биттнер, Ян Спенс, Моделирование вариантов использования, Addison-Wesley Professional, 20 августа 2002 г.
• Кокберн, Алистер. Написание эффективных сценариев использования. Аддисон-Уэсли, 2001.
• Ларри Константин, Люси Локвуд, Программное обеспечение для использования: практическое руководство по основным моделям и методам проектирования, ориентированного на использование, Аддисон-Уэсли, 1999.
• Денни, Ричард. Успешное использование сценариев использования: разумная работа для обеспечения качества. Аддисон-Уэсли, 2005.
• Фаулер, Мартин. UML Distilled (третье издание). Аддисон-Уэсли, 2004.
• Якобсон Ивар, Кристерсон М., Йонссон П., Овергаард Г., Объектно-ориентированная разработка программного обеспечения — подход, основанный на сценариях использования, Аддисон-Уэсли, 1992.
• Якобсон Ивар, Спенс И., Биттнер К. Сценарий использования 2.0: Руководство по достижению успеха с вариантами использования, IJI SA, 2011.
• Дин Леффингуэлл, Дон Видриг, Управление требованиями к программному обеспечению: подход к использованию, Аддисон-Уэсли Профессионал. 7 декабря 2012 г.
• Кулак, Дэрил и Имонн Гини. Примеры использования: требования в контексте. Аддисон-Уэсли, 2012.
• Мейер, Бертран. Построение объектно-ориентированного программного обеспечения. (2-е издание). Прентис Холл, 2000.
• Шнайдер, Джери и Винтерс, Джейсон П. Применение вариантов использования 2-е издание: Практическое руководство. Аддисон-Уэсли, 2001.
• Вазлавик, Рауль С. Объектно-ориентированный анализ и дизайн информационных систем: моделирование с помощью UML, OCL и IFML. Морган Кауфманн, 2014.

внешняя ссылка

• Колонка вариантов использования Алистера Кокберна
• Примеры использования (Usability.gov)
• Базовый шаблон сценария использования Алистер Кокберн
• Применение сценариев использования для анализа заинтересованных сторон «Проект Икар: сценарии заинтересованных сторон для программы межзвездных исследований», JBIS, 64, 224-233
• «Академический обзор роли вариантов использования в UML»
• Поиск варианта использования в IBM developerWorks