Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 53
Текст из файла (страница 53)
Уточнение прецедентов 247 ° Система выиолнлеаь Это о»качает, что системз обеспечивает описапиыс в прсцедеите фуикциоиальиыс возможности. Это то, что делает система в зависимости от полученного ввода. ° Лолезиь»й еглэаеимй (»сзульггют. Важно отметить, что результат прецедента должен быть полезен пользователю, т.е. "жилец нажимает кнопку выкл»очатсля" пс является правильным прецедентом; (система иичего ис делает для пользователя). Но "жилец пажимает кнопку выключателя, и система включает свет" является осмысленным прецедентом. ° Оя(мдслеииь»й акяю)».
Это человек или прибор (жилец по имени Липла или спгиал от кнопки иевпатиой ситуации), ииициирующий даппос действие (переключение света или активацию систему безаиасиости). Эволюция прецедентов На ранних итерациях в части 3, "Определение системы", было выявлено большииство наиболее важных прецедентов. Однако описывались только иемиогие из иих — те, которые считались архитектурно эиачимыми или особеиио хорошо описывали поведеиис системы. Как правило, описания этих прецедентов выполиеиы в виде дополнения к докумеиту-коицепции, в котором описывается, как предполагается использовать содержащиеся в документе фуикции. В процессе уточисиия завершается разработка всех прецедентов, необходимых для определения системы. Показателем того, что прецедентов "достаточно", является то, что полный набор прецедентов описывает все возможныс способы иснользоваиия системы иа уровне конкретизации, пригодном для проектирования, реаошзацпи и тестирования.
Следует отметить, что детализация прецедента яе лкляеяия декомпозицией системы. Другими словами, мы ие иачипаем с прецедента высокого уровня, чтобы лазим разбивать его иа все большее число прецедеитов. Вместо этого мы стараемся (х»лес точно описать взаимодействия акторов с системой. Таким образом, разработка прецедентов более похожа иа уточпеиие последовательностей действий, а ие иа иерархическое разбиение их иа более мелкие дейст. вия. В модели часто есть прсцедеиты, которые настолько просты, что ие нуждаются в детальном описании потока событий; достаточно краткого описания.
Критерием для принятия такоп» решения является то, что пользователи поииыают, что означает прсцедепт, а для разработчиков и тсстологов дигиь»й уровень детализации удобен. Какие действия включить в прецедент Часто трудно решить, является ли миожсство взаимодействий пользователя с системой (или диалог) одиил~ прецедентом или иссколькимш Рассмотрим использование лвшииы, при»пгмщощсй банки и бутылки. Клиент загружает в пее консервные банки и бутылки, иажимаст кнопку и получает квитанцию, по которой люжет затем получить дсиьги.
Является ли загрузка сдаваемых предметов одним прецедситом, а получеиис квитаицпи — др)тим» Или это все одни прсцедсит» Имеют место два действия, ио в отдельности оии не приносят пользы клиенту. Именно полный диалог, со всеми загрузками и получсиием квитанции, имеет смысл для клисыта. Следовательно, именно полный диалог — от загрузки первого сдаваемого предмета до нажатия кнопки и получения квитанции — является полным вариантом использоваиия, т.е. прецедентом. 248 Часть 5. Уточнение определения системы Кроме того, хотелось бы хранить эти два действия вместе, чтобы иметь возможность одновременно их просматривать, модифицировать, вместе проверять, изменять, когда зто необходимо, писать характеризующую их пользовательскую документацию и обращаться с ними, как с единым целым.
Это становится особенно важным в более крупных системах. Рабочий пример. Строение простого прецедента Рассглотрил~ шаг за шагом процедуру определения прецедента. Будем использовать про стой пример из системы НО(.Б; жилец включает освещение в комнате, используя автоматическую систему управления освещением НО(лз. Определение акторов Первым делом необходимо точно установить, кто взаимодействует с прецедентом. Во многих системах, спроектированных для пользователей, следует сначала выявить людей, которые будут использовать систему. В нашем случае жилец взаимодействует с системой, чтобы управлять освещением в комнате.
Таким образом, выявлен единственный актор, пользователь (Жилец), нажимающий кнопку пульта. Предостережение. При определении акторов полезно вести "именной список", чт~ Г>ы видеть, какие из них уже определены, и случайно не создать некий актор повторно под другим именем. Дать название прецеденту Каждый прецедент должен иметь имя, показывающее, что достигается при его взаимодействии с актором(ами). Имя может состоять из нескольких слов, проясняющих его смысл. Различные прецеденты не должны иметь одно и то же имя. К заданию имени следует подходить ответственно.
Оно должно быть уникальным и в то же время таким, чтобы его можно бьио лег ко отличить от имен других прецедентов данного проекта. В английском языке имена прецедентов часто начинаются с глагола, обозиа- Упраеленае чающего действие, которое отражает предназначение данного пре- осюцаяаеи цедента. Назовем наш прецедент "Управление освещением".
Моаою создавать структуру имен формальным методом, чтобы сгруппировать аналогичные прецеденты в аналогично именованные группы. Можно также ввести порядковый номер или другой уникальный идентификатор в имя прецедента, чтобы было удобнее работать со списком прецедентов. Например, разработчик может указать имя данного прецедента как "03! Управление освещением".
Однако опыт свидетельствует, что простого именования прецедентов и, возможно, применения неких вспомогательных програьпг, позволшощих нам их находить, сортировать и анализировать, обычно вполне достаточно. Глава 24. Уточнеыые прецедеытон 249 Составление краткого описания Краткое описание прецедента должно отражать его роль и цель. При его написании следует рассмотреть, кзкие акторы участвуют в нем, а также обратиться к глоссарию.
Если необходимо, можно определить новые понятия. Это описание должно служить своего рода неформальным обзором функциональных возможностей. Их полное описание содержится в следующем разделе прецедента "Поток событии". Описание прецедента предназначено для получения "общего впечатления" и ничего более. В нашем случае люжио описать прецедент следующим образом. Описание прецедента "Упривленые освещением" Данный прецедент определяет способ вюпочеиия и выключения света, а также изменения его яркости, в зависимости от того, как долго пользователь удерживает кнопку пульта в нажатом состоянии.
Определение потока событий Сердцевиной прецедента является поток событий. Как правило, это текстовое описа- 3 ыие операций автора и различных ответов системы. Поток событий описывает, что, как предполагается, будет делать система в зависимости от поведения актора.
Между прт чим, пе обязательно описывать поток в текстовой форме. Для этого можно использовать диаграммы взаимодействия УМЕ, а также другие формальные методы, обсуждаемые в главе 28. Все оии вполне пригодны для документации прецедентов. Главное — обеспечить понимание, и не существует единственного подхода на все случаи жизни.
Однако, как правило, вполне подходит описание на естественном языке. Поток событий описывает достижение цели прецедеыта и предназначен для рассмотрения следующими заинтересованными лицами. ° Клиентами, которые одобряют результат и "благословляют" функции ° Пользователями, которые будут работать с системой ° Разработчиками прецедентов, которые заинтересованы в точ- ном описании желаемого поведения системы ° Рецеызеитами, которые составляют непредвзвтое мнение о системе ° Проектировщиками, которые анализируют прецеденты в поис- ках классов, объектов и т.п.
° Тестологами, которым нужно создатьтестовые примеры ° Менеджером проекта, которому необходимо понимать весь проект в целом ° Составителем технической документации, которому нужно документировать функции системы так, чтобы было понятно пользователю ° Людьлги, из отдела маркетинга и продаж, которым необходимо понимать функции продукта и объяснять его достоинства остальнылл Вы, возможно, думаете, что глРактически не бывает ситуаций, когда можно описать гфоспюй поянпс собыитй, когпормй рабоптеог во всех случаях; всегда нулсен способ длл описания некоторых алагпернативних потоков.
Ничего страпшого. Определение потока сооытий 250 Часть б. Уточнение определения системы прецедента допускает альтернативные потоки. Но сначала создадим основной поток для нашего примера. Основной поток для прецедента "Управление освещением". Отметим, что данный поток собь<тпй нигде нс указывает, хак система выполняет то или иное действие. Он указывает только, чмо происходит. Основной поток начинается, когда Жилец нажимает любую кнопку пульта. Если >Килсц отпускает кнопку в тсчспие периода времени, отсчитываемого тай<э<сром, си< тел<а "переключает" состояние освещения, ° Если освещение было включено, оно полностью выключается.
° Если сост был выкл<очсп, освсн!ение включается с тем жс уровнем яркости, которыя был перед последним выкл<очснием. Конец основного потока. Альтернативный поток событий. Во многих случаях прецедент <южст иметь различпыс потоки, в зависимости от возникающих условий. Иногда зти потоки связаны с выявленными в процессе обработки ошибочными условнямн, в других сл> <аях опи могут описывать дополннтсльныс спосооы обработки конкретных условий. Наприк<ер, прецедент, печатающий квитанцию для операции с кредитной карточкой, может обнаружить, что у принтера закончилась бумага. Этот специальный случай будет описан в прецеденте как альтернативный ноток событий. При записи альтернативных потоков не забывайте документировать условия, приводящие к ннм! На количество альтернативных потоков не накладыва<отса ограничения, поэтому б>дьте внимательны и документируйтс вес альтернативные потоки, в том числе все возможные условия возникновения ошибок.
В пашем прим< рс альтернативный поток событий возникает, когда Жилец удержива. ет кнопку пульта в нажатом состоянии долыяс одной селупды. Итак, нам нужно добавить в прецедент альтернативный поток. Альтернативный поток событий: постепенное изменение яркости Если Жилец удерживает к<<оп>у пульта в нажатом состоянии дольше одной сск>э<ды, система инициирует действия по изменению яркости для данной кнопки пульта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
