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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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