Фаза - построение
Cтраница 2
 |
Пример межмодульного требования. [16] |
Требования уровня модулей проверяются на фазе построения. Все, что остается сделать на фазе тестирования, - выполнить межмодульные тесты, называемые также тестами уровня системы. При этом проверяется, соблюдены ли в окончательном программном тексте требования, для которых используется более одного модуля. Здесь применяется тот же метод, что и на фазе построения: проверка требований, отображенных на модули, при помощи средства Matrix Diagrammer. Но так как требования уровня модулей уже протестированы, группе контроля качества необходимо сосредоточить все свои усилия на межмодульных требованиях. [17]
Системная документация ( один из результатов фазы построения) состоит из собственно репозитория и тех отчетов об описаниях его составляющих, которые, по вашему мнению, необходимы. [18]
Система отслеживания проблем, используемая на фазах построения и тестирования жизненного цикла, вполне подходит и для отслеживания дефектов, возникающих на фазе сопровождения. При выявлении неисправности первой операцией процедуры отслеживания проблем может быть ввод описания проблемы в репозиторий. Эта же операция может быть первой и для процедуры запросов на изменение системы, если требуется внести какие-либо усовершенствования. После устранения дефектов или реализации усовершенствования в производственной среде установите свойства описания проблемы, применимые к этому описанию. Отслеживание такого рода позволяет хранить информацию обо всех дефектах и проблемах в одной области репозитория независимо от того, на какой фазе они возникают: тестирования, построения или сопровождения. [19]
 |
Операции процесса построения и инструментальные средства Oracle Designer. [20] |
В таблице 18.1 приведены результаты и операции фазы построения, а также инструментальные средства Oracle Designer, используемые для их поддержки. Средства с префиксом DE ( Design Editor) входят в состав редактора проектов. [21]
Проект базы данных может изменяться во время фазы построения. При переносе данных из старой системы в новую, скорее всего, появится необходимость в новых изменениях, которые нужно внести в проект базы. [22]
Создание объектов базы данных должно стать первым шагом фазы построения, так как перед генерацией программного текста модуля таблицы и другие объекты поддержки должны присутствовать в базе данных. Generate Database from Server Model - это утилита репозитория, создающая текстовые файлы SQL Plus, которые выполняются для построения объектов базы данных. В генерируемый программный текст включаются SQL-операторы DDL, комментарии SQL Plus и команды, документирующие объекты и выдающие сообщения при выполнении сценариев. [23]
Важная часть процесса разработки, которая выполняется на фазе построения и занимает большую часть времени разработчика - заполнение описаний прикладного программного текста. Хотя генераторы Oracle Designer облегчают труд разработчика, делая все возможное при выполнении стандартных операций и компоновки, тем не менее необходимость в написании программ для реализации бизнес-правил остается. Как правило, подавляющее большинство программных конструкций создается на сервере с использованием хранимых пакетов ( процедур, функций и переменных) PL / SQL и вызывающего их триггерного программного текста. При этом разработчику остается написать небольшой программный текст для выполнения действий, специфичных для данного инструментального средства. Так, в модуле формы Oracle Developer может понадобиться прикладная программная конструкция для перемещения по блоку и для установления свойств записи на основании значения конкретного элемента. Такую конструкцию нежелательно ( а может быть и невозможно) применять в качестве серверной, поэтому нужно создать прикладную логическую схему для выполнения операции в библиотеке или форме. В любом случае создается программный текст ( протестированный или нет), который заносится в репозиторий. [24]
На этапе проектирования базы данных начинается подготовка к фазе построения, когда все располагается по своим местам. [25]
И системная, и пользовательская документация - важные элементы фазы построения. Поскольку система строится во время процесса CADM, на этом этапе она практически готова. В нее должны входить все продукты, созданные на предшествующих фазах, отчеты, генерируемые Oracle Designer, и замечания проектировщиков и разработчиков, в которых описаны решения, принимаемые на протяжении всего процесса. Остается добавить только замечания о проекте, вносимые на фазе построения, и результаты тестирования. [26]
На фазе тестирования и при тестировании программных единиц на фазе построения необходимо отслеживать проблемы для каждого модуля. [27]
Возможно, что вы слышали обратное, но создание пррграммного текста на фазе построения - дело непростое, в отличие от описания модулей и генерирования производственных программ. Конечно же, можно получить 100 % - ный результат ( или даже добиться 0 % послегенерационных изменений), но это серьезная задача, для решения которой требуется максимально. На фазе построения можно применить ряд утилит и методов, которые не относятся к собственно генераторам, но помогают проделать необходимую работу. [28]
На фазе внедрения с помощью Oracle Designer дополняется документация для справочной службы и для пользователей, начатая на фазе построения. Эта документация извлекается непосредственно из информации репозитория. Поэтому единственной задачей здесь является выбор формата или составление отчетов. [29]
Он поддерживает работу на фазах стратегии, анализа и разработки, равно как и заключительную генерацию кода на фазе построения. Не слишком много продуктов CASE обеспечивают решение всех этих задач. Oracle Designer проводит проектировщика через весь жизненный цикл разработки и позволяет генерировать полностью работоспособные и свободные от ошибок формы, Web-приложения, отчеты и меню, а также код SQL, необходимый для создания объектов базы данных. Если применяется метод, отличный от CADM или другого традиционного метода типа водопада, гибкости Oracle Designer хватает и для этого случая. [30]
Страницы: 1 2 3 4