Cтраница 4
На фазе предварительного проектирования эти требования связываются с модулями путем создания пользовательского ассоциативного типа ( см. главу 12) и назначения каждому модулю отдельных требований. На фазе построения создается собственно программный текст модуля, и группа контроля качества проводит тестирование программных единиц на уровне модуля, подтверждая, что данный модуль действительно реализует соответствующие требования. Группа выполняет аудит требований в книге проекта и проверяет, все ли требования, сформулированные на фазе анализа, связаны с модулями. Кроме того, группа контроля качества должна еще раз проверить отображение требований на модули и ответить на вопрос: удовлетворяют ли на самом деле существующие на данный момент модули выдвинутым требованиям. [46]
В Module Network Viewer устанавливаются связи между модулями и определяются основные свойства этого уровня. На диаграмме модуля можно указать, какие элементы данных используются для каждой таблицы или представления, а также как они будут отображаться в сгенерированной компоновке. При переходе к фазе построения типичный сеанс генерирования модуля начинается с анализа на диаграмме модуля его визуальных аспектов и характеристик, связанных с данными. После этого генерируется модуль, делаются замечания по поводу нужных изменений, которые затем вносятся в свойства модуля на диаграмме или в навигаторе. Этот цикл повторяется до тех пор, пока модуль не будет работать должным образом. Главное, что нужно сделать на этапе прикладного проектирования, - ввести как можно более полные описания, основываясь на знании системы. Эта фаза заканчивается перед генерацией модулей, на следующей фазе выполняется повторяющийся цикл генерирования и уточнения. [47]
На фазе построения нужно категорически избегать каких-либо изменений. Затраты на изменение очень высоки и обычно непредсказуемы. Если изменения производятся на фазе построения, их следует документировать и отражать в виде модификаций или исправлений, вносимых в продукты тех фаз, которые предшествуют анализу и проектированию. [48]
Разработка базы данных предполагает проектирование таблиц и столбцов наряду с детальной спецификацией доменов и проверкой ограничений на столбцы. Разработка базы данных включает также денормализацию базы данных для улучшения ее производительности, что в равной степени относится и к триггерам поддержки денормализации. Эти заключительные части разработки проводятся на фазе построения. [49]
На фазе построения после настройки формы ее нужно сразу же передать на тестирование программных единиц. Это позволит разработчикам немедленно получить результаты независимо от того, соответствуют ли формы проектным спецификациям или нет. Подобный подход помогает выявлять недостатки на фазе построения, до того как они распространятся на все приложения. [50]
План разработки приложения создать не сложно. Разработка приложения предполагает подробную идентификацию использования столбцов для каждого модуля и полное определение модулей. Многие работы по заключительной разработке приложения выполняются на фазе построения. [51]
На фазе тестирования выполняется проверка новой системы на соответствие установленным правилам. Разрабатывается план тестирования, в котором должны быть описаны не только предполагаемые тесты, но и то, как нужно реагировать на их возможные сбои и несоответствия. Нереально, особенно в случае больших систем, начинать разработку плана тестирования только после завершения фазы построения. Эти этапы должны в определенной степени перекрываться. После настройки каждого модуля и проведения его тестирования на уровне программных единиц он уже вполне готов для того, чтобы приступить к планированию тестов. [52]
![]() |
Операции процесса прикладного проектирования и инструментальные средства Oracle Designer. [53] |
На этапе прикладного проектирования полностью описываются модули ( экраны, отчеты, меню), составляющие окончательное приложение. Oracle Designer помогает ввести эти описания организованно и согласно методике, благодаря чему можно указать все детали. Описания Oracle Designer выступают в роли программных спецификаций, из которых приложение генерируется в окончательном виде на фазе построения. Другой важной операцией этого этапа является перекрестная проверка проекта базы данных, которая позволяет убедиться в том, что элементы данных, описанные во время проектирования базы данных, используются в полном объеме и входят в состав группы создаваемых модулей. [54]
Помимо этого, следует проанализировать описания каждой таблицы и каждого столбца и Детализировать их как можно подробнее. Чем полнее вы выполните задачи этой фазы, тем реже придется прерываться на этапе прикладного проектирования или на фазе построения для внесения пропущенных деталей. Кроме того, если описания таблиц и столбцов правильно построены на этапе проектирования, при работе с таблицами в модулях всякий раз будут наследоваться некоторые характеристики описаний таблиц. Аналогично, свойства столбцов будут наследоваться в модуле в виде свойств связанных элементов. Таким образом, в этот момент можно решить, каким именно образом будут просматриваться или использоваться таблицы. Предположим, что существует описание некоторой таблицы, используемое в четырех модулях. Свойства отображения таблицы, указанные в ее описании, будут применяться во всех четырех модулях. Естественно, разрешается переустанавливать значения параметров таблицы и указывать дополнительные детали на уровне модулей. Однако свойства уровня таблиц предоставляют достаточно удобный набор установок по умолчанию и снижают объем операций настройки модулей. [55]
Эти сотрудники выполняют схожие тесты на фазах построения и тестирования. Тем самым они подтверждают корректное и соответствующее запланированному функционирование приложения. На фазе построения выполняются тесты уровня программных единиц или уровня модулей, в которых центром внимания является каждый из модулей. А на фазе тестирования выполняются тесты уровня системы, в которых проверяются группы модулей и то, как модули взаимодействуют между собой. [56]