Варианты использования, десять лет спустя
Страница 5. Действие третье - наши дни
Страница 5 из 6

Действие третье - наши дни

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

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

В своей книге "Writing Effective Use Cases"4, я выделяю три уровня детализации в описании вариантов использования: краткий, обычный и полный.

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

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

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

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

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

Используйте их только в тех ситуациях, когда это оправдано

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

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

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

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

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

Не забывайте об ограничениях, которые есть у вариантов использования

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

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

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

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

Избегайте типичных ошибок

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

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

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

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

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

 
 
« Предыдущая статья   Следующая статья »