ЧАСТЬ ие реляционнь!х систем баз данных

вы поставите ему систему, которую нельзя :10вать, даже если вы уложитесь в сроки и бюджет.

Тем не менее отдельные стадии, из которых состоит модель водо-нада, совершенно необходимы. Если вы пропустите хоть одну, то непременно провалите проект. Недостаток модели водопада в том, что она линейна: ни одна из стадий не может быть проведена повторно, и ее результаты нельзя пересмотреть.

Есть несколько альтернативных моделей. Спиральная модель предлагает осуществлять итерации, то есть каждая последующая стадия позволяет уточнить результат дущей (рис. 6-2).

Рис. 6-2. Спиральная модель

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

ГЛАВА б Процесс проектирования

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

Модель, которую я рекомендую для проектирования больших систем, называется методом приращений или эволюционной разработкой (рис. 6-3).

Построение архитектуры

Спиральная разработка компонентов

(Детальное проектирование

Тестирований

Выпуск

версии . ,.-1

системы / IСоставление бюджета!

Интеграция

Проектирование

Рис. 6-3. Эволюционная разработка

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

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

ЧАСТЬ 2 Проектирование реляционньи систем баз данных

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

Метод приращений предполагает, что любая большая система разделяется на ряд компонентов, но это не обязательно справедливо для всех без исключения систем. Может потребоваться написать много вспомогательного кода. Например, такая ситуация: экран ввода данных должен вызывать компонент Microsoft ActiveX, который будет осуществлять поиск кода заказчика и выполнять некоторые действия, если код не найден. Но компонент ActiveX еще не создан. Разработчики вынуждены написать дополнительный код, позволяющий осу-вызов методов без ошибок. Сложные системы могут включать значительный объем такого вспомогательного кода.

А ведь кроме того, есть вероятность, что компонент ActiveX так никогда и не будет реализован: не выделят денег на его создание, или вы обнаружите, что он не нужен. Тогда придется создать компонент, чьей единственной функцией будет поддержка работы других компонентов. Не очень элегантное решение, и вам определенно не захочется рассказывать об этом специалисту но технической поддержке.

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

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

равлять. Например, вы сможете поставить пользователю ядро системы

на ранней стадии проекта. Система начнет окупать себя, и это будет

способствовать дальнейшему финансированию проекта заказчиком.