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