Главная » UML » Определение прецедентов

0

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

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

Прецеденты возникают тогда, когда внимание обращается на значимые результаты, которые система дает актору, и когда объединяются последовательности действий, которые система предпринимает для получения этих значимых результатов. Прецедент можно также рассматривать как средство достижения некоторой "цели", которую система должна дать актору. Крайне полезное обсуждение данного метода можно найти в статье Элистара Кокберна (Alistair Cockburn) .

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

Развитие прецедентов

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

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

- Alistar Cockburn. Structuring Use Cases with Goals. Journal of Object-Oriented Programming, Sept. 1997 и Nov. 1997; см. также http://niembers.aol.com/acocbum/papers/usecases.htm.

 

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

По теме:

  • Комментарии