Создание базы данных. Практические рекомендации

Практические рекомендации

Ниже изложены некоторые наши соображения, связанные с выполнением расссматриваемого этапа методики реконструкции.

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

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

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

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

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

♦ Учитывая потенциально большие объемы исходных моделей, следует максимально повысить эффективность подачи запросов.

♦ Необходима возможность удаленного доступа к базе данных посредством одного или нескольких географически распределенных пользовательских интерфейсов.

♦ Путем комбинирования информации из различных таблиц следует реализовать объединение представлений.

♦ Необходима поддержка языков запросов, способных выражать архитектурные образцы.

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

К примеру в инструментарии Dali применяется реляционная модель базы данных. Она предполагает преобразование извлеченных представлений (которые в зависимости от инструментов извлечения, могут существовать в самых разных форматах) в стандартную форму Rigi. Затем данные считываются сценарием peri и выводятся в формате, предусматривающем наличие кода SQL, который позволяет конструировать реляционные таблицы и наполнять их извлеченной информацией. Схема этого процесса изображена на рис. 10.2.

Пример кода SQL, предназначенного для построения и наполнения реляционных таблиц, показан в листинге 10.1.

При вводе данных в базу генерируются две добавочные таблицы: elements и relationships. В них содержатся списки извлеченных элементов и отношений соответственно.

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

В текущей версии инструментария Dali функциональность реляционной базы данных POSTGRES формируется средствами SQL и peri, которые отвечают за генерирование и обработку архитектурных представлений (соответствующие примеры приводятся в разделе 10.5). Редактировать сценарии SQL в целях обеспечения их совместимости с другими реализациями SQL не представляет труда.

Листинг 10.1. Пример кода SQL, сгенерированного средствами инструментария Dali

create table calls< caller text, callee text); create table access(func text, variable text): create table defines_var(file text, variable text):

insert into calls values('main', 'control'); insert into calls values('main', 'clock');

insert into accesses values('main', ' stat 1');

Практические рекомендации

На этапе создания базы данных имеет смысл учитывать следующие соображения.

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

♦ Перед конструированием любой базы данных необходимо тщательно про думать се структуру Каким будет первичный (а возможно, и вторичный* ключ? Какие соединения, охватывающие сразу несколько таблиц, будут сопряжены с наибольшими издержками? Применяемые в ходе реконструкции таблицы, как правило, не отличаются особой сложностью — порядка dir_contains_dir или function_calls_function, а в качестве первичного ключа выступает функция всей строки.

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

Дата добавления: 2015-04-25