Если используется CASE-технология, то техническая спецификация может состоять из ряда отчетов из репозитария.

Обеспечение полноты проекпшрованпя

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

К этапу реализацпп и дальше

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

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

Ниже описано, какую помощь могут оказать проектировщики на этапе реализации.

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

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

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

Почему

проектирование так важно для Oracle

в этой главе:

TIpovhiniipoeamtc в расчете па hoimpenmi/io apxmiieimufpii

Обеспечепие (ibtcohoii iipoiineodirmc.thitocinii

Дщгис 1/ип,1поры, i.oniophic пц.тпо цчтпывать при npoeiiiniipooanuii

роеипт/юванпс Оли Oracle?

Об OracleН

Из этой главы вы узнаете, почему тщательно продуманная структура базы данных жизненно важна для успешной работы приложения, использующего Oracle в качестве технологии базы данных. Главной особенностью, которая отличает Oracle от многих других реляцио1<ных систем управления базами данных, является способность поддерживатъ широкую номенклатуру архитектур и операционных сред. Приложение мс?жет работать как на автономном ПК, так и на мэйнфрейме, обслуживающем свыше тысячи пользователей. И эффективность его работы на обоих концах этого диапазона, зависит от структуры базы данных. Продукты Oracle отличаются богатым набором функциональных возможностей. Это означз-ет, что один и тот же результат можно получить несколькими способами. Задача проектировщиков - выбрать наиболее подходящий для заданных исходных требований метод.

В этой главе представлены базовые архитектуры, которые поддерживает Oracle, в том числе архитектура клиент/сервР, распределенная база данных, хранилища данных и параллельная обработра. (Более подробно мы остановимся на этом в части III книги.) Кроме тоГО, вы ознакомитесь с методами проектирования, позволяющими достичь оптимальной производительности системы. В конце главы приведен перечень существенно важных для проектировщиков особенностей СУБД Oracle? и Ян краткий обзор тех возможностей СУБД OracleS, которые оказывают влиугние на процесс проектирования,

Проектирование в расчете на конкретную архитектуру

Иногда архитектура создаваемой системы должна рассматриваться как заданная. Например, тот факт, что на столах у пользователей конкретного узла уже стоят ПК, которые применяются для выполнения других задач, может вынудить нас использовать архитектуру клиент/сервер. Во многих случаях выбирать тот или иной вариант нас заставляют ограничения, сформулированные при анализе. Например, пропускная способность может быть критическим фактором для рассматриваемой системы, и после тестирования мы можем прийти к выводу о том, что единственный путь достижения необходимой пропускной способности - использовать Parallel Query Option. Как бы многие из нас ни хотели применить ту или иную технологию просто потому, что она привлекательна, приходится быть реалистами и полностью осознавать последствия выбора технологического пути.

Давайте рассмотрим конкретные архитектуры, на которые можно ориентироваться при проектировании.

Клиент /сервер

В том смысле, в котором термин клиент/сервер вошел в употребление, системы клиент/сервер характеризуются тем, что экранная форма, или клиент, и база данных, или сервер, как правило, находятся на разных компьютерах. Клиент и сервер могут быть соединены локальной вычислительной сетью {ЛВС) с высокой скоростью передачи данных и высокой пропускной способностью или глобальной вычислительной сетью {FBQ, которая работает гораздо медленнее и имеет более низкую пропускную способность.

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

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