Составные части варианта использования Вариант использования как соглашение о поведении

Составные части варианта использования Вариант использования как соглашение о поведении

Разрабатываемая система — это механизм для выполнения соглашения между участниками. Варианты использования обеспечивают поведенческую часть этого соглашения. Каждое предложение в варианте использования описывает действие, защищающее некоторый интерес какого-либо участника. Предложение может описывать взаимодействие двух действующих лиц или внутренние действия системы, которые она должна выполнять для защиты интересов участников. Сначала рассмотрим вариант использования как способ фиксации взаимодействия участников, имеющих определенные цели. Отталкиваясь от этого положения, мы можем расширить обсуждение, изучая вариант использования как соглашение между участниками. Я называю первую часть концептуальной моделью Действующие лица и цели, а вторую — концептуальной моделью Участники и интересы.
2.1. Взаимодействия действующих лиц, имеющих цели.
Действующие лица имеют цели.
Представьте себе служащего, ответственного за прием запросов на обслуживание по телефону (на рис. 2.1 служащий представлен основным действующим лицом). Когда поступает звонок, цель служащего —открыть компьютерный журнал и инициировать запрос.
Обязанность системы — зарегистрировать и инициировать запрос на обслуживание в нашем примере. (В действительности она отвечает за защиту интересов всех участников, причем служащий, основное действующее лицо, только один из них. Сосредоточимся на обязанности системы обеспечить обслуживание для основного действующего лица.).
Чтобы выполнить свою обязанность, система формулирует подцели. Некоторые подцели она способна реализовывать внутри себя, но для других ей необходима помощь вспомогательного действующего лица. Этим вспомогательным действующим лицом может быть подсистема печати или другая организация, например партнерская компания или правительственная организация.
Рис. 2.1. Действующее лицо, имеющее цель, инициирует выполнение обязанностей другого действующего лица.
Вспомогательное действующее лицо обычно выполняет свое обещание и добивается подцели для разрабатываемой системы (SuD). SuD взаимодействует с внешними действующими лицами. Она достигает своих подцелей через некоторую последовательность действий, пока не выполнит своей обязанности, т.е. не окажет обещанную услугу.
Предоставление обещанной услуги — высшая цель, достигаемая через подцели. Подцели можно, в свою очередь, разбить на подподцели и т.д. до бесконечности. Подпод(...под)целей может быть бесконечное множество, если мы разбиваем действия действующих лиц на мелкие составляющие. В стихотворении “Похвала поэзии” Джонатан Свифт говорит о блохе, на которой натуралисты нашли блох еще меньшего размера, которые, в свою очередь, имеют еще более мелких блох и т.д. Предела этому нет.
Вероятно, наиболее трудная часть создания хороших вариантов использования — это управление блохами на блохах, т.е. подподцелями. Подробнее об этом см. в главе 5, в главе 7 (правило 6) и в главе 20 (памятка 6).
Концептуальная модель Действующие лица и цели удобна, поскольку применима и к бизнесу, и к компьютерным системам. Действующими лицами может быть человек, организация или компьютер. Мы можем описать смешанные системы, включающие людей, компании и компьютеры. Мы можем описать программную систему, управляемую другой компьютерной системой, которая обращается к одушевленному вспомогательному действующему лицу, или организацию, которая обращается к компьютерной системе либо индивидууму. Это полезная обобщенная модель.
Целей можно и не достигнуть.
Что, по-вашему, будет делать служащий, разговаривающий с клиентом по телефону, если компьютер отказывает во время записи запроса? Если система не может предоставить обещанную услугу, служащий должен придумать резервную цель, в этом случае, вероятно, с помощью карандаша и бумаги. Сохраняя за собой основную обязанность по работе, служащий должен иметь план на случай отказа системы.
Точно также система может столкнуться с отказом на пути к одной из своей подцелей. Возможно, основное действующее лицо дало неверные данные, может быть, это внутренняя неисправность или вспомогательное действующее лицо не предоставило обещанную услугу. Как же должна вести себя система? Это действительно интересная часть требований к поведению SuD.
Иногда система может устранить неисправность и вернуться к нормальному поведению. В других случаях она должна просто отказаться от этой цели. Если вы идете к своему банкомату и пытаетесь извлечь больше денег, чем есть у вас на счету, ваша цель выудить наличные просто не будет достигнута. Ничего у вас не выйдет и при отключении банкомата от сети. Но если вы всего лишь ошиблись, набирая код, система предоставит вам вторую попытку ввести код правильно.
Такая фокусировка на неудачах в достижении целей и реакциях на неудачи объясняет, почему варианты использования являются хорошим описанием поведения системы и отличными функциональными требованиями в целом. Специалисты по функциональной декомпозиции и декомпозиции потоков данных отметили это как наиболее значительное преимущество, которое дали им варианты использования.
Взаимодействие имеет составную структуру.
Простейшее взаимодействие — это отправление сообщения: “Привет, Джин, — говорю я, проходя по холлу. Это и есть простое взаимодействие. В процедурном программировании простому взаимодействию соответствует вызов функции, например print (значение). В объектно-ориентированном программировании один объект посылает сообщение другому, скажем, objectA->print(3Ha4eHne).
Последовательность сообщений, или сценарий — это составное взаимодействие. Предположим, я иду к автомату с газированной водой, опускаю в него долларовую банкноту за 80-центовый напиток и получаю сообщение, что нужно опустить точную сумму. Вот мое взаимодействие с автоматом:.
1.
Я опускаю долларовую банкноту.
2.
Нажимаю кнопку "cola".
3.
Автомат требует точную сумму мелочью.
4.
Я нажимаю на "Возврат монет".
5.
Автомат возвращает доллар монетами.
6.
Забираю монеты и ухожу.
Можно сжать последовательность, как если бы это был единственный шаг (“Я попытался купить колу в автомате, но он потребовал точную сумму”), и развернуть этот сжатый шаг в более длинную последовательность:.
1.
Я пошел в банк компании и взял некоторую сумму.
2.
Попытался купить колу в автомате, но тот потребовал точную сумму.
3.
Прошел до кафетерия и купил воду там.
Таким образом, при необходимости взаимодействие можно свернуть или, напротив, разбить на шаги, как позволяют цели. Каждый шаг сценария фиксирует цель, и поэтому каждый шаг можно развернуть как отдельный вариант использования. Так что взаимодействия напоминают блох, у которых есть блохи, да и цели тоже.
Удобно то, что поведение системы можно представить на весьма высоком уровне обобщения, когда цели и взаимодействия находятся в свернутом виде. Постепенно развертывая их, можно описать поведение системы сколь угодно точно. Я часто называю набор вариантов использования постоянно разворачивающейся историей. Наша задача — писать эту историю так, чтобы читатель легко в ней ориентировался.
Я использую слово последовательность в широком смысле. Во многих случаях взаимодействия не обязательно должны происходить в каком-то определенном порядке. Чтобы купить воду за 80 центов, я мог бы опустить восемь монет по 10 центов, три монеты по 25 центов и монету в 5 центов либо... (можете продолжить список). Не имеет значения, какую монету опускать первой.
Строго говоря, последовательность — не совсем подходящее слово. Правильный математический термин — "частичное упорядочение". Однако слово последовательность точнее по смыслу и гораздо легче воспринимается теми, кто пишет варианты использования. Если кто-нибудь спросит вас о сообщениях, которые могут поступать одновременно, попросите кратко написать об этом. Посмотрите, с чем они к вам придут. Мой опыт показывает, что люди создают удивительно ясные описания после весьма непродолжительного обучения. Поэтому я продолжаю употреблять слово последовательность. Пример сложных последовательностей вы найдете в варианте использования 22.
С формальным языком для вариантов использования дело обстоит не так просто. Большинство разработчиков языков либо заставляют пишущего варианты использования перечислять все возможные порядки, либо изобретают сложные нотации для произвольного порядка событий. Мы создаем варианты использования для людей, а не для компьютеров, поэтому просто пишем: “Покупатель опускает 80 центов пятицентовыми, десятицентовыми или двадцатипятицентовыми монетами в любом порядке”.
Последовательности хороши для описания взаимодействий в прошлом, поскольку прошлое полностью определено. Чтобы описать взаимодействия в будущем, необходимы наборы возможных последовательностей, по одной для каждого условия, которое может когда-либо возникнуть. Если я вам рассказываю о том, как вчера просил повышения, я говорю:.
“Вчера я имел серьезный разговор с боссом. Я сказал... Она сказала...
Я сказал...”, и т.д.
Но о будущем я расскажу так:.
“Меня действительно беспокоит предстоящий разговор с боссом”.
“Почему?”.
“Я собираюсь просить повышения”.
“Как?”.
“Ну, сначала я скажу... Затем, если она скажет..., я отвечу...”.
“Но если она скажет..., я попробую...”, и т.д.
Точно так же, объясняя кому-либо, как купить содовой воды, мы скажем:.
“Прежде всего, запаситесь монетами”.
“Если у вас есть точная сумма, опустите монеты в автомат и нажмите.
кнопку ’’cola".
“Если нет, опустите деньги и посмотрите, сможет ли автомат дать сдачи.
Если да...”.
Чтобы описать взаимодействие в будущем, придется иметь дело с различными условиями, создавая наборы последовательностей. Для каяедой последовательности мы указываем условие, саму последовательность и результат.
Можно спрятать набор последовательностей в одном предложении: “Сначала пойдите купить воды в автомате”. Или: “Затем попросите у босса повышение”. Как и с последовательностями, эти предложения можно вместить в краткое описание высокого уровня обобщения или развернуть их в подробное описание в соответствии с нашими потребностями.
Теперь вы знаете, что вариант использования содержит набор возможных сценариев для достижения цели. Для завершенности добавим:.
* Все взаимодействия имеют отношение к одной и той же цели одного и того же основного действующего лица.
■ Вариант использования начинается с инициирующего события и продолжается, пока цель не достигнута или ее достижение не прервано и система не освобождается от своих обязательств по отношению к данному взаимодействию.
Вариант использования как сборник сценариев.
У основного действующего лица есть цель; система должна помогать действующему лицу достичь этой цели. Некоторые сценарии приводят к достижению заданной цели; другие заканчиваются, если цель оказывается недостижимой. Каждый сценарий содержит последовательность шагов, показывающих, как раскрываются действия и взаимодействия. Вариант использования собирает все эти сценарии вместе, показывая все пути, которые могут привести или не привести к цели.
Рассмотрим “полосатые брюки” (рис. 2.2). Ремень на брюках указывает цель, которая объединяет все сценарии. Из двух половинок брюк одна предназначена для
Рис. 2.2. "Полосатые брюки" — сценарии приводят или не приводят к цели.
Каждая полоса соответствует одному сценарию и находится в части успехов или в части неудач. Назовем первую полосу на половинке успехов основным сценарием. Остальные полосы — это другие сценарии, в конце концов приводящие к успеху, некоторые альтернативными путями, другие — справившись с промежуточным отказом. Каждая полоса на половинке неудач — это сценарий, в котором возникает сбой, после которого он, возможно, восстановится, но завершится все-таки неудачей.
сценариев, которые приводят к успеху, а другая — для сценариев, которые кончаются неудачей.
На самом деле мы не будем отдельно писать каждый сценарий от начала до конца. Это нерациональная стратегия, поскольку это утомительно и сложно поддерживать. “Полосатые брюки” помогают понять, что каждый вариант использования имеет два исхода, что цель основного действующего лица связывает все сценарии и что каждый сценарий — это простое описание цели, достигаемой или нет.
На рис. 2.3 я дополнил “полосатые брюки” подчиненными вариантами использования, входящими в основные, которые их вызывают. Заказчик хочет разместить заказ. Одна из подцелей заказчика — открыть кредит. Это подцель сложная и может быть достигнута или нет: вариант использования, который мы свернули в единственный шаг. Шаг “заказчик открывает кредит” — это ремень на других брюках. В полосе, или сценарии, этого шага подцель либо достигается, либо нет. В сценариях 1 и 2 на рисунке подцель достигается. В сценариях 3 и 7 — нет. В сценарии 3, однако, следующая подцель для определения запасов достигается, и вариант использования в целом завершается успешно. В сценарии 7 вторая попытка тоже не удается, и полный вариант использования для размещения заказа завершается неудачей.
Полоски на подчиненных вариантах использования (см. рис. 2.3) показывают, что внешнему варианту использования как бы все равно, какой подчиненный вариант использования выполняется в его рамках. Подчиненный вариант приводит к успеху либо к неудаче. Внешний, или вызывающий, вариант использования просто основан на успехе либо на неудаче шага, определяемого подчиненным вариантом использования.
Рис. 2.3. "Полосатые брюки" с подцелями.
Основные идеи, которые следуют из аналогии с “полосатыми брюками”, таковы:.
■ Некоторые сценарии приводят к успеху, другие к неудаче.
■ Вариант использования собирает вместе все сценарии, успешные и заканчивающиеся неудачей.
■ Каждый сценарий — это непосредственное описание одного набора обстоятельств с одним исходом.
■ Варианты использования содержат сценарии (полосы на брюках),.
а сценарий содержит подчиненные варианты использования в качестве своих шагов.
■ На шаг сценария не влияет, какая полоса в подчиненном варианте использования была задействована. Влияет лишь результат —закончился вариант успехом либо неудачей.
Эти основные идеи прослеживаются на протяжении всей книги.
2.2. Соглашение между участниками, имеющими интересы.
Модель Действующие лица и цели объясняет, как писать предложения в варианте использования, но не касается необходимости описывать внутреннее поведение разрабатываемой системы. По этой причине модель Действующие лица и цели следует расширить. Здесь важно, что варианты использования можно рассматривать как соглашение между участниками, имеющими свои интересы. Расширенную модель я буду называть концептуальной моделью Участники и интересы. Блок участников и интересов определяет, что включить в вариант использования и что нет.
SuD реализует соглашение между участниками, причем варианты использования детализируют поведенческую часть этого соглашения. Во время работы системы.
присутствуют не все участники. Обычно присутствует основное действующее лицо, но не всегда. Другие участники отсутствуют, поэтому их можно назвать действующими лицами вне сцены. Система работает, чтобы удовлетворить интересы этих действующих лиц, включая сбор информации, проведение проверок достоверности и обновление журналов (рис. 2.4).
Банкомат должен вести журнал всех взаимодействий, чтобы защитить участников в случае разногласий. Он записывает и другую информацию, поэтому можно определить, как далеко зашла транзакция перед сбоем. Банкомат и банковская система проверяют, имеет ли держатель счета соответствующий капитал, прежде чем выдать ему наличные. Это гарантирует, что банкомат не выдаст больше денег, чем есть на счету этого клиента.
Вариант использования как соглашение о поведении охватывает в полном объеме поведение, связанное с удовлетворением интересов участников, и только его.
Чтобы тщательно выстроить вариант использования, перечислим всех участников, назовем их интересы в связи с функционированием варианта использования и установим, что значит для каждого участника успешное завершение варианта использования и какие гарантии они хотят получить от системы. Разобравшись с этим, напишем шаги варианта использования с гарантией, что все интересы удовлетворяются от момента инициирования варианта использования до его окончания. Так определяется, когда начинать и когда заканчивать описание, а также что включать или не включать в вариант использования.
Большинство людей не пишут варианты использования так кропотливо, и часто им это сходит с рук. Опытные писатели проделывают это упражнение в голове, когда пишут бессистемные варианты использования. Они, возможно, опускают некоторые вещи, но учитывают их при разработке программного обеспечения. Однако иногда это дорого обходится, как в истории, описанной в разделе 4.1.
Чтобы удовлетворить интересы участников, должны быть описаны три вида действий:
РИС. 2.4. SuD обслуживает основное действующее лицо, защищая интересы действующих лиц вне сцены.
■ Взаимодействие между двумя действующими лицами (чтобы содействовать достижению цели).
■ Проверка достоверности (чтобы защитить участника).
■ Изменение внутреннего состояния (от имени участника).
Модель Участники и интересы вносит лишь небольшое изменение в общую процедуру создания варианта использования: перечень участников и их интересов и использование этого перечня в качестве двойной проверки для гарантии, что ничто не пропущено в тексте варианта использования. Это изменение существенно влияет на качество варианта использования.
2.3. Графическая модель.
Этот раздел предназначен только для тех, кому нравится строить абстрактные модели; его можно пропустить.
Вариант использования описывает соглашение о поведении между участниками, имеющими интересы. Мы организуем поведение с помощью функциональных целей избранного множества участников (тех, кто попросит систему что-нибудь сделать для них). Этих участников мы называем основными действующими лицами. Название варианта использования — это цель основного действующего лица. В варианте использования содержатся все аспекты поведения, необходимые для описания этой части соглашения.
У системы есть обязанность удовлетворять оговоренные соглашением интересы обусловленных соглашением участников с их действиями. Действия бывают трех типов:.
■ Взаимодействие между двумя действующимилицами, при котором информация может передаваться назад или вперед.
■ Проверка достоверности, чтобы защитить интересы одного из участников.
■ Изменение внутреннего состояния для защиты интереса участника.
Сценарий состоит из шагов действия. В сценарии успеха все (обусловленные соглашением) интересы участников удовлетворяются вследствие обслуживания, которое сценарий обязан выполнять. В сценарии неудачи все интересы защищаются в соответствии с гарантиями системы. Сценарий завершается, когда все интересы участников удовлетворены или защищены.
Три триггера, которые запрашивают достижение цели, являются основным действующим лицом, инициирующим взаимодействие с системой, основным действующим лицом, использующим посредника для инициирования взаимодействия, или временным триггером либо триггером состояния.
Модель вариантов использования, описанная в этой главе, показана на рис. 2.5 —.
2.8. Здесь используется унифицированный язык моделирования UML.
РИС. 2.5. Действующие лица и участники. Участник имеет интересы. Действующее лицо характеризуется поведением. Основное действующее лицо одновременно является участником
РИС. 2.6. Поведение. Ориентированное на цель поведение включает обязанности, цели и действия. Частные действия, о которых мы пишем, содействуют или защищают интересы участников. Взаимодействия соединяют действия одного действующего лица с действиями другого
РИС. 2.7. Вариант использования как инициирование обязанности. Вариант использования фиксирует цель основного действующего лица и обращается к SuD для выполнения ее соответствующей обязанности
РИС. 2,8. Взаимодействия как композиция. N действующих лиц взаимодействуют.
Взаимодействия можно разложить на варианты использования, сценарии и простые сообщения. Термин "последовательность" употребляется для удобства.
Это абстрактная модель. Я не знаю, как ее отлаживать. Могу лишь предложить несколько лет тестировать ее на проектах, используя основанный на модели инструмент. Другими словами, она, вероятно, содержит несколько неуловимых ошибок. Я включил ее для тех, кто хочет поэкспериментировать и, возможно, создать такой основанный на модели инструмент.