Знакомство с прецедентами

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

• Что такое прецеденты.

• Создание прецедента.

• Включение прецедента.

• Расширение прецедента.

• Анализ прецедента.

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

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

Ни статическое, ни динамическое представление не отображают поведения систе­мы с точки зрения пользователя. Понимание его точки зрения — это ключ к построе­нию системы. Система должна удовлетворять требованиям пользователя.

Моделирование системы с точки зрения пользователя — это задача прецедентов.

Что такое прецеденты

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

Делая осознанную покупку, мы все оказываемся в подобном положении. Наши действия называются анализом прецедентов (use case analysis). Мы спрашиваем себя, как будем использовать тот или иной продукт или систему, в которую собираемся вложить деньги, и пытаемся найти то, что удовлетворяет нашим требованиям. Поэто­му очень важно знать эти требования.

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

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

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

Зачем нужны прецеденты

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

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

Пример: автомат по продаже лимонада

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

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

Прецедент Покупка лимонада

Исполнителем в данном прецеденте является покупатель, желающий приобрести ста­кан лимонада. Он инициирует сценарии, опуская монету в автомат. Затем он выбирает сорт лимонада. Если все идет нормально, автомат выдает ему стакан с выбранным напитком.

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

Рис. 1. Прецедент определяет набор сценариев для достиже­ния цели, полезной исполнителю. В рассматриваемом при­мере одним из прецедентов является Покупка лимонада

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

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

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

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

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

Дополнительные прецеденты

Мы рассмотрели пример с автоматом по продаже лимонада с точки зрения потре­бителя — покупателя. Другие пользователи дополняют картину эксплуатации автома­та. Этот автомат обслуживает специалист, пополняющий запасы лимонада, и инкасса­тор. Зачастую такие функции выполняет один и тот же человек. Названные специали­сты реализуют еще два прецедента: Заправка автомата и Сбор денег.

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

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

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

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

Включение прецедента

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

Можно. Это делается с помощью выделения стандартных последовательностей дейст­вий и оформления их в виде дополнительного прецедента. Шаги "разблокирование" и "открытие" можно объединить в рамках прецедента Проникновение внутрь, а "закры­тие" и "блокировку" — в рамках прецедента Выход наружу.

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

Таким образом, прецеденты Заправка автомата и Сбор денег включают новые прецеденты. Такой пример повторного использования прецедента называется включе­нием прецедента.

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

Расширение прецедента

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

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

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

Анализ прецедента

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

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

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

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

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