Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 [ 10 ] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Построение

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

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

Итерации на стадии построения являются как инкрементными (наращиваемыми), так и повторяющимися.

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

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

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

Таким образом, как можно видеть из предыдущего обсуждения, варианты использования служат основой для планирования проекта, и именно поэтому в языке UML им уделяется такое серьезное внимание.

Самотестируемое программное обеспечение

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

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

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

Функциональные или системные тесты должны разрабатываться отдельной небольшой командой, работа которой состоит только в тестировании. Такая команда должна рассматривать всю систему как черный ящик, а нахождение ошибок должно доставлять ее участникам особое удовольствие. (Зловещие усы и нахальные усмешки не обязательны, но желательны.)

Для модульного тестирования существует простая, но довольно мощная основа с открытым кодом: семейство xUnit. Более подробную информацию по этой теме можно найти на моей домашней странице в Интернете.

В последнем случае очень полезным может оказаться метод реорганизации (см. врезку). Хорошо бы обратить внимание на то, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение.

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

Реорганизация

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

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

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

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

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

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

1 2 3 4 5 6 7 8 9 [ 10 ] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.