М. Фаулер, К. Скотт - UML Основы (1114905), страница 10

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 10)

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

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

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

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

Разрабатывайте тестовый код таким образом, чтобы вы смогли запускать каждый тест с помощью простой командной строки или нажатия кнопки на графическом интерфейсе пользователя (О(П). Результатом выполнения теста должно быть сообщение «ОК» или список ошибок. Кроме того, все тесты должны проверять свои собственные результаты.

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

Такая команда должна рассматривать всю систему как черный ящик, а нахождение ошибок должно доставлять ее участникам особое удовольствие. (Зловещие усы и нахальные усмешки не обязательны, но желательны.) Для модульного тестирования существует простая, но довольно мощная основа с открытым кодом: семейство хУп($. Более подробную информацию по етой теме можно найти на моей домашней странице в Интернете. В последнем случае очень полезным может оказаться метод реорганизации (см. врезку). Хорошо бы обратить внимание на то, какой объем кода оказывается ненужным после каждой итерации.

Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение. Интеграция должна представлять собой непрерывный процесс. Для участников проекта каждая итерация должна заканчиваться полной интеграцией соответствующих результатов. Однако интеграция может 46 Глава 2. Основы процесса разработки Реорганизация Можете ли вы интерпретировать принцип энтропии применительно к программному обеспечению? Этот принцип предполагает, что программы в самом начале являются хорошо спроектированными, но по мере добавления в них какой-либо новой функциональности постепенно утрачивают свою структуру, превращаясь в конечном счете в бесформенную массу спагетти. Отчасти это происходит по причине масштаба.

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

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

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

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

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

° Выполняйте только небольшие и тщательно продуманные действия. Переместите некоторый атрибут из одного класса в другой. Объедините два подобных метода в один суперкласс. Протестируйте программу после каждого такого действия. Хотя вы не получите сразу впечатляющих результатов, подобные действия позволят избежать дополнительной отладки и, следовательно, сократят общее время разработки.

Реорганизацию следует выполнять всякий раз при добавлении новой функции или обнаружении ошибки. Не следует выделять на реорганизацию специальное временя; лучше делать это понемногу, но каждый день. Дополнительную информацию по реорганизации можно найти в книге Фаулера (Рою)ег),1999 [19). и должна выполняться еще чаще.

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

Разработчику следует выполнять интеграцию всякий раз после завершения каждого значительного объема работы. Кроме того, для гарантии требуемого уровня тестирования на каждой итерации следует запускать полный набор тестов для всех модулей. Глава 2. Основы процесса разработки Когда план заканчивается неудачей Чтобы быть уверенным в выполнении плана, вам необходимо знать только одну вещь, а именно — все что происходит, происходит в соответствии с планом.

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

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

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

Характеристики

Список файлов книги