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

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

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

Действие первое - предыстория

Айвар Якобсон (его фамилия так и произносится: "Я-коб-сон") начал писать о сценариях использования программных продуктов году эдак в 1967, когда работал над системой AXE для компании Eriksson. Те первые сценарии были написаны в свободной форме и весьма неформальным языком. Писал он их для того, чтобы показать, как люди будут использовать эти самые системы AXE. Тогда варианты использования еще не напоминали те сложные формальные структуры, которые зачастую используются сейчас при их описании (к чему и автор, вынужден признаться, приложил руку...).

В середине 80-х Якобсон уже тратил немало времени и сил на описание тех решений, которые он смог найти в этой области в течение прошедших 20 лет. Именно тогда он придумал шведский термин "anvendningfall", что в приблизительном переводе означает "ситуация использования" или, по-английски, "usage case". Работая над английским переводом своей статьи, он решил, что "usage case" звучит как-то не по-английски, и переделал его в "use case". Если вам чем-то не нравится термин use case ("вариант использования"), скажите спасибо, что вам не приходится каждый раз выговаривать anvendningfall.

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

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

В 1992 я натолкнулся на первую, программную статью Якобсона о вариантах использования, которую он написал в 1987 году. В то время я работал над созданием объектно-ориентированной методологии для IBM Consulting Group. Как и многие до меня, я сразу понял, что эти описания поведения системы естественным образом дополняют внутренние описания компонентов системы, которые создаются во время ОО-проектирования. Поэтому я, как и многие другие, начал искать ответ на вопрос: а что же такое эти варианты использования? И, как и многие другие, я попадал то в одну, то в другую ловушку - писал их слишком формально или слишком свободно. Нужно было накопить некоторый опыт, чтобы понять, что лучше всего выбрать средний вариант. Якобсон тем временем продолжал издавать книги и статьи, посвященные вариантам использования, однако почему-то вопросы при этом никуда не исчезали.

Действие второе - последние десять лет

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

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

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

• Что такое вариант использования - строгое изложение требования к системе или просто описание (story)?
• Может быть, "сценарий" - это еще одно название для варианта использования?
• Насколько формальной или неформальной должна быть структура варианта использования?
• Образуют ли варианты использования некую взаимосвязанную структуру, или же просто сваливаются в кучу?

Для некоторых вариант использования был просто еще одним определением понятия "сценарий" (краткого описания некоторого взаимодействия пользователя с системой). Мартин Фаулер (Martin Fowler) часто язвительно замечал, что "вариант использования", скорее всего, и значит "сценарий", только по-шведски. Последователи этой школы считают, что у варианта использования нет никакой внутренней структуры. Если их становится много, то их просто сваливают в кучу, и все. Те, кто пишет варианты использования таким образом, вполне довольны результатами, поэтому до сих пор многие рекомендуют описывать варианты использования именно так.

Прочие же, особенно исследователи и разработчики CASE (Computer Aided Software Engineering) средств, посчитали, что неформальные артефакты будут слишком неполными, и что им нужен математический базис и поддержка в CASE-средствах. Они разработали специальные языки, нотации и программы, с помощью которых варианты использования превратились в строгие и скрупулезные описания. Этот подход снискал куда меньше последователей. Людям был нужен простой способ выражения своих соображений относительно будущей системы. Они не хотели использовать формальные программные средства. Более того, им казалось, что дополнительная работа по формализации вариантов использования не дает ощутимых результатов.

Кроме того, формалисты столкнулись с еще одной проблемой: как учесть все варианты поведения, с которыми может столкнуться система? Как-то меня спросили: "Если я разрабатываю автомат для продажи конфет, как мне специфицировать, какие монетки засунет туда покупатель? Он может положить три монетки по 25 центов, а может и 15 пятицентовиков. Или сначала положит 25 центов, а потом десять пятицентовиков? Или в обратном порядке? Или еще как-нибудь?"

Я ответил: "Нужно написать: человек кладет в автомат деньги".

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

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

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

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

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

Несложно понять, что вариант использования представляет собой текстовое описание шагов, которые выполняет действующее лицо (actor). "Что же объединяет все эти шаги? Что в них общего?" В начале 90-х никто не мог однозначно ответить на этот вопрос.

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

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

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

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

Однако тут перед нами встает еще одна проблема - цели могут иметь различные масштабы.

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

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

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

В описании варианта использования мы совмещаем идею о многоуровневости целей и понятие успешности/неуспешности их достижения. Каждый шаг сценария представляет собой цель меньшего масштаба, которую уже удалось достичь. Мы пишем: "Клиент вставляет карточку в банкомат", имея в виду самую низкоуровневую цель и подразумевая, что клиент ее выполнит. Продолжая описание этого варианта использования в разделе "Альтернативные варианты" или "Дополнения", мы должны будем написать, что случится, если эта низкоуровневая цель все же не будет достигнута: "Карточка застревает в банкомате; банкомат автоматически выключается и ставит в известность ремонтную службу".

Желания заинтересованных сторон

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

И в течение продолжительного времени достаточно было ответить: "А что вы хотите - это же документирование требований к системе! Если не записать все, то требования будут не полными". Приходилось удовлетворяться таким ответом, хотя его было явно недостаточно.

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

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

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

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

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

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

Итак, к этому моменту (1997 год) стало казаться, что в теории создания вариантов использования уже не осталось "белых пятен".

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

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

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

Авторы Экстремального Программирования (ХР) остались верны идее неформальных сценариев, у которых нет никакой заданной структуры. Кент Бек (Kent Beck) создал термин "рассказ пользователя" (user story). Именно им и стали называть такие неформальные требования к системе. Рассказ пользователя состоит из нескольких фраз, записанных на маленькой бумажной карточке. В них пользователь объясняет, что именно он хочет от системы. В ХР рассказ пользователя представляет собой не требование к системе, а некое напоминание о будущем обсуждении этой функциональности с заказчиком. Таким образом, на карточке достаточно записать ровно столько информации, чтобы и заказчики, и программисты поняли, что именно им нужно будет обсудить в дальнейшем.

Ларри Константайн (Larry Constantine) рассматривает описание сценариев с точки зрения проектирования пользовательского интерфейса. Он обнаружил, что для этого ему совершенно не нужно описывать внутреннее поведение системы или ее взаимодействие с второстепенными действующими лицами. Для проектирования интерфейсов вполне достаточно текста, записанного в две колонки. В первой пишут то, что пользователь пытается сделать, во второй - как реагирует на его действия система. Такая простейшая структура позволяет создать интерфейс, отвечающий задачам пользователя. Чтобы избежать путаницы, Константайн переименовал "вариант использования" (use case) в "вариант задачи" (task case), так как варианты использования традиционно представляют собой спецификацию системы.

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

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

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

Будьте готовы использовать различные формы записи вариантов использования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действие четвертое - ближайшее будущее

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

Исходя из этого, в ближайшем будущем с вариантами использования может произойти следующее:

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

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

Что же можно сделать, чтобы варианты использования были действительно полезной техникой? Прежде всего, надо научиться:

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

А потом расслабьтесь и анализируйте доводы за и против.

Рекомендуемые веб-ресурсы

http://www.ForUse.com/
http://midwatch.org/design/ucindex.html

Эта статья на RSDN