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

Мы обнаружили, что самый лучщий метод (конечно, в среде разработки Oracle) - дать каждому разработчику свою собственную схему (в Oracle? это то же самое, что и пользовательское имя) и настоять на том, чтобы разработчики применяли синонимы для обращения к объектам в совместно используемой схеме, которую сопровождает администратор БД группы разработчиков. Это - относительно простой способ проверки того, на какие приватные объекты ссылается та или иная схема.

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

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

Управление исходным кодом

Перед началом генерации необходимо определить, инсталлировать и протестировать систему управления исходным кодом. Понадобятся также таке-файлы, проектные файлы или какие-либо иные методы, позволяющие полностью управлять частичной или полной регенерацией приложения. Управление исходным кодом - относительно изученная область, если речь идет о коде, написанном на С или С++, однако редко какие средства УРП хорощо стыкуются (если вообще стыкуются) с системами управления исходным кодом и с make.

Если используются генераторы исходного кода, то в действительности исходный код может представлять собой репозитарии или словарь проектирования, а не исходный код, хранящийся в чисто текстовых файлах. Примеры - Oracle Developer/2000 и Microsoft Visual Basic. Даже там, где используются чисто текстовые файлы (например, INP-файлы SOL*Forms версий 2.x и 3.0), система управления исходным кодом может не знать, как вставить свою управляющую информацию в файл, не сделав этот файл недействительным для программы, которая предназначена для его чтения.

Управление исходным кодом может оказаться еще более сложной задачей в средах клиент/сервер, где одна часть кода должна компилироваться на клиенте, а остальные части - на сервере. Чтобы обеспечить синхронность этих двух сред, необходимо планирование и новаторские технические приемы.

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

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

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

Администратор и (или) администратор БД должны будут предоставить разработчикам и тестировщикам регистрационцые имена и учетные записи. Группа проектировщиков, поддерживая постоянную связь с администратором БД, должна обеспечить, чтобы каждый класс пользователей был представлен в целевой системе и мог использоваться в системном тесте.

См. Database Fingerprinting by Chris Johnson, Database Programming and Design, September 1995.

Шаблоны кода

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

Рассмотрим пример, в котором экранные формы разрабатываются с помощью Oracle Forms, а для упрощения этого процесса применяется схема, изображенная на рис. 15.4 У нас есть два шаблона, по которым можно построить новую экранную форму Один предназначен для простых форм, а другой - для более сложных Кроме того, мы имеем каталог библиотек PL/SQL, которые могут использоваться и другими приложениями (не Oracle Forms).

Строится на

Ссыпки

*- Библиотечная

форма

Вызовы

Рис 15 4 Типичная конфигурация шаблонов для разработки в Oracle Forms

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