Содержание к диссертации
Введение
ГЛАВА 1. Базы данных в САПР СБИС 13
1.1. Основные виды моделей данных 17
1.2. Существующие требования к базам данных САПР СБИС 31
1.3. Объектные представления 33
1.4. Подход с интеграцией представлений в схему базы данных 3 7
1.5. Подход с интеграции представлений во внешней схеме данных 43
1.6. Сравнение подходов к организации объектных представлений 44
1.7. Цели и задачи работы 46
1.8. Выводы 46
ГЛАВА 2. Разработка модели объектных представлений на основе функционального интерфейса в ООБД САПР 48
2.1. Базовые концепции абстракции доступа к данным 48
2.2. Модель вычислимых объектных представлений на основе функционального интерфейса 51
2.3. Методы построения представлений 53
2.4. Способы изменения хранимых данных через объектное представление 57
2.5. Основные подходы к реализации объектных представлений 60
2.6. Анализ методов решения проблемы когерентности при использовании временных объектов 65
2.7. Метод выбора способа реализации представления 68
2.8. Выводы 71
ГЛАВА 3. Программная реализация объектно-ориентированной БД САПР СБИС с поддержкой объектных представлений 72
3.1. ООБД на основе языков описания схемы 73
3.2. ООБД без явного описания схемы 7 3
3.3. Требования к системе поддержки объектных представлений в САПР СБИС 75
3.4. Аспектно-ориентированный подход к программированию 7 6
3.5. Выбор БД в качестве основы для реализации 77
3.6. Архитектура системы поддержки объектных представлений в САПР СБИС 80
3.7. Программная реализация системы поддержки объектных представлений 82
3.8. Реализация поддержки временных объектов 89
3.9. Реализация поддержки ограничения доступа к хранимым данным через объектные представления 97
3.10. Выводы 102
ГЛАВА 4. Примеры практического использования системы поддержки объектных представлений 104
4.1. Структура базы данных смешанного моделирования 105
4.2. Объектные представления для доступа к логическому и схемотехническому описаниям субблоков 108
4.3. Сравнение системы поддержки объектных представлений с системой OpenAccess 110
4.4. Анализ и сравнение методов разработки, основанных на различных подходах к интеграции компонентов САПР 114
4.5. Выводы 118
Заключение 119
Библиография
- Основные виды моделей данных
- Модель вычислимых объектных представлений на основе функционального интерфейса
- ООБД на основе языков описания схемы
- Структура базы данных смешанного моделирования
Введение к работе
Работа посвящена созданию методов и инструментальных средств разработки программного обеспечения (ПО) баз данных в системах автоматизации проектирования (САПР) сверхбольших интегральных схем (СБИС). Предметом исследования в работе являются способы автоматизации разработки ПО баз данных (БД) этапов логического и схемотехнического проектирования СБИС. В работе проведен анализ задач по хранению проектных данных САПР СБИС, а также существующих способов создания ПО, решающего эти задачи. Проведенный анализ позволил сформулировать требования к БД САПР СБИС. Была предложена модель преобразований объектов на основе функциональных интерфейсов, позволяющая разделить этап преобразования данных для конкретных программных компонентов САПР и этап непосредственной работы с этими данными, что позволяет существенно упростить процесс разработки компонентов САПР.
На основе результатов проведенного исследования создана программная среда, реализующая систему поддержки объектных преобразований на основе объектно-ориентированной БД (ООБД) GOODS. На основе данного каркаса разработана ООБД, интегрирующая проектную информацию логического и схемотехнического этапов проектирования СБИС. Ввиду схожести ряда задач проектирования, разработанный подход и инструментальные средства можно использовать для интеграции и других этапов.
В работе проведено сравнение сложности разработки ПО БД традиционными способами и с использованием предложенного метода. Сделаны выводы о перспективности данного подхода.
Актуальность темы
Современные системы автоматизации проектирования являются сложными многокомпонентными системами, в рамках которых разработчику доступно большое количество разнообразных маршрутов проектирования. В рамках каждого из этих маршрутов между собой взаимодействуют несколько отдельных средств проектирования. При росте числа взаимодействующих компонентов САПР сложность их интеграции значительно возрастает. Так, при использовании промежуточных языков представления данных количество связей между компонентами возрастает экспоненциально [1]. Организация взаимодействия компонентов на основе баз данных способна снизить сложность взаимодействия. Но и при таком подходе, по некоторым оценкам, на разработку средств интеграции может тратиться до сорока процентов общего времени разработки системы.
Наиболее трудными этапами разработки многокомпонентной системы являются этап интеграции и тестовые испытания [2 ] . При этом выявляются ошибки и просчеты, связанные с взаимодействием составляющих частей системы, обнаружение которых на предыдущих этапах затруднено. Проблема осложняется еще и тем, что подчас бывает довольно сложно определить, какой именно из компонентов является причиной некорректной работы системы в целом. Создание системы поддержки преобразований данных способно локализовать задачи преобразования проектных данных, отделить их от процесса использования этих данных и, тем самым, существенно снизить сложность
- б -
разрабатываемой системы и повысить возможности её тестирования, а, как следствие, и надёжность разработанной системы.
Информация об объекте проектирования, хранимая в БД, содержит большое количество аспектов {логическое, схемотехническое и другие представления схемы) [3 ] . Использование современных технологий программирования {таких, как объектно-ориентированные БД) позволяет снизить сложность разработки механизмов передачи информации между компонентами САПР и центральной БД. Но при этом сохраняется высокая сложность и взаимосвязанность хранимых в БД данных. Для работы конкретному приложению желательно иметь такой интерфейс к БД, который предоставлял бы доступ к хранимым данным в виде, удобном этому приложению. Кроме этого, изменение структуры хранимых в БД данных сказывается на всех работающих с ней приложениях. По этой причине актуальность средств, позволяющих упростить задачу интеграции компонентов САПР и защитить компоненты от изменений в структуре хранимых данных, является высокой.
Несмотря на большое количество ведущихся в данной области исследований, ряд проблем ещё остаются нерешёнными: существующие подходы являются недостаточно гибкими и накладывают существенные ограничения на интерфейсы доступа к базам данных при разработке компонентов САПР.
Цель работы
Целью диссертационной работы является разработка математического, алгоритмического и программного обеспечения для интеграции компонент САПР.
Для достижения поставленной цели необходимо решение следующих научно-технических задач:
Исследовать существующие подходы к интеграции компонентов САПР на основе объектных представлений.
Разработать методы преобразования данных на основе функционального интерфейса.
Предложить способы обновления данных через объектные представления.
Разработать методы ограничения доступа к данным на основе объектных представлений.
Создать архитектуру системы поддержки объектных представлений.
Разработать на основе этой архитектуры систему поддержки объектных представлений, интегрированную в объектно-ориентированную базу данных.
Провести практическую апробацию разработанной системы.
Научная новизна работы
Впервые разработана модель преобразований объектов на основе функционального интерфейса;
Разработана архитектура системы поддержки объектных представлений в объектно-ориентированных БД;
Определены критерии выбора способов настройки функциональных интерфейсов в зависимости от сложности реализуемых преобразований;
Разработан метод создания объектных представлений для модели преобразований объектов на основе функционального интерфейса;
Предложена структура объектно-ориентированной базы данных для интеграции средств цифрового и аналогового моделирования, отличающаяся от
известных систем возможностью реализации произвольных преобразований данных.
Практическая значимость работы
На основе полученных теоретических результатов разработана система поддержки объектных преобразований, являющаяся удобным инструментальным средством для разработчиков компонентов САПР. Данная система позволяет упростить процесс разработки программных интерфейсов к базам проектных данных САПР, а также уменьшить количество ошибок при разработке и, следовательно, увеличить надёжность разрабатываемых компонентов. В результате уменьшаются сроки выхода САПР на рынок и уменьшается число обращений в службу технической поддержки.
Методы исследования
В работе был использован математический аппарат теории множеств и теории алгоритмов. Экспериментальные результаты были получены при помощи разработанной программной среды.
Достоверность полученных результатов подтверждается используемым в работе математическим аппаратом, экспериментальным тестированием и промышленной эксплуатацией разработанного программного обеспечения в САПР «AVOCAD».
Реализация результатов работы
Результаты работы в виде объектно-ориентированной системы управления базами данных в составе САПР «AVOCAD» внедрены в процесс проектирования ИС 000 «Юник Ай Сиз», НИИФП и в учебный процесс МГИЭТ(ТУ), что подтверждается актами о внедрении. Использование разработанного программного обеспечения на предприятиях показывает высокую эффективность его применения в цикле
проектирования аналоговых, цифровых и аналого-цифровых ИС.
Личный вклад автора
Основными из полученных автором результатов, являются:
Систематизация требований к разработке ПО БД САПР логического и схемотехнического этапов проектирования СБИС.
Разработка модели объектных преобразований на основе функционального интерфейса.
Разработка методов обновления данных через функциональный интерфейс и способа выбора используемых методов в зависимости от сложности преобразований.
Разработка архитектуры поддержки объектных представлений с преобразованиями на основе функционального интерфейса.
Создание программного и алгоритмического обеспечения для реализации разработанной архитектуры.
Создание при помощи реализованной программной среды интегрированной БД логического и схемотехнического этапов проектирования в рамках разработки системы «AVOCAD».
Представляется к защите
Модель преобразования объектов на основе функционального интерфейса.
Архитектура системы поддержки объектных представлений в ООБД САПР.
Критерии выбора способов настройки функциональных интерфейсов в зависимости от сложности реализуемых преобразований.
Метод создания объектных представлений для модели преобразований объектов на основе функционального интерфейса.
Структура объектно-ориентированной базы данных САПР для интеграции средств цифрового и аналогового моделирования.
Апробация результатов работы
Результаты диссертационной работы докладывались и обсуждались на научно-технических совещаниях 000 «Юник Ай Сиз» и на следующих конференциях:
X Всероссийская межвузовская научно-техническая
конференция студентов и аспирантов, Москва, Зеленоград,
23,24 апреля 2003г.
XI Всероссийская межвузовская научно-техническая
конференция студентов и аспирантов, Москва, Зеленоград,
23,24 апреля 2004г.
XLVII научная конференция МФТИ, Москва, 26-27 ноября 2004.
XII Всероссийская межвузовская научно-техническая
конференция студентов и аспирантов, Москва, Зеленоград,
23,24 апреля 2005г.
XLVIII научная конференция МФТИ, Москва, 26-27 ноября 2005.
V Международная научно-техническая конференция "Электроника и информатика - 2005", 23 - 25 ноября 2005.
Публикации.
Материалы, отражающие основное содержание работы, опубликованы в двух научных статьях и шести докладах в трудах российских и международных научно-технических конференций. Библиографические данные публикаций приведены в разделе "Библиография".
Структура работы.
Диссертация состоит из введения, четырех глав, заключения, списка исполь зованных источников, приложения, содержащего акты внедрения результатов работы.
В первой главе описаны основные виды моделей данных, применяемых в БД САПР, рассмотрены основные требования, предъявляемые к БД САПР. Проанализированы способы построения объектных баз данных. Проведено сравнение реляционных и объектных баз данных в задачах САПР СБИС. Выявлены ограничения и недостатки объектной модели при использовании в САПР СБИС. Описаны методы преодоления этих ограничений путем введения дополнительного уровня абстракции на основе т.н. «объектных представлений». Проведён обзор и сравнение методов создания объектных представлений в БД САПР. Выявлены недостатки предложенных подходов. Сформулирована задача разработки объектных представлений на основе функционального интерфейса.
Вторая глава посвящена разработке модели объектных представлений на основе функционального интерфейса для объектно-ориентированных баз данных САПР. Кратко описаны основные концепции, используемые в настоящее время для доступа к данным, и описана разработанная на их основе модель. Для представленной модели описаны варианты реализации, выявлены их достоинства и недостатки, описаны критерии выбора методов реализации и представлен алгоритм выбора оптимального варианта.
В третьей главе кратко описываются подходы к реализации ООБД САПР, разрабатываются критерии выбора ООБД в качестве основы для реализации, проводится выбор такой ООБД. Описывается архитектура системы поддержки объектных представлений. Рассматриваются методы реализации внутренних и внешних по отношению к объекту представления функций преобразования. Также предлагаются
- 12 -способы создания систем поддержки временных объектов и контроля доступа к проектным данным.
В четвёртой главе описывается разработка базы данных смешанного моделирования на основе разработанной системы поддержки объектных преобразований и производится сравнение методов разработки.
Основные виды моделей данных
В современных СУБД в основном применяются следующие модели данных: иерархическая, сетевая, реляционная, семантическая.
Иерархическая модель представляет собой набор типов записей и набор типов связей, которые описывают взаимосвязи между типами записей. Существует ограничение, которое устанавливает, что каждый тип записи в заданном дереве (за исключением корневого типа) должен иметь в качестве родителя только один тип записи. Следовательно, иерархическая БД представляет собой лес деревьев, удовлетворяющий структуре, описанной в схеме Сетевая модель данных похожа на иерархическую, за исключением двух отдельных моментов. Во-первых, она разрешает множественные типы связей между типами записей. Во-вторых, запись может иметь множество родителей. Вследствие этого сетевая модель более гибкая, нежели иерархическая.
Различные СУБД, использующие иерархическую или сетевую модели данных, предлагают межзаписные типы связей вместе с записями в качестве базовой конструкции модели. Такие типы связей точно выражают межзаписные отношения. Традиционно такие системы страдают от недостатка независимости физической организации данных. Например, связи между типами записей служат как для описания концептуальных взаимосвязей, так и для указания пути -доступа на физическом уровне. В связи с этим добавление новых записей и связей в физическую схему, предназначенное для повышения эффективности доступа, ведет к необходимости изменения прикладных программ, хотя концептуально информация не менялась [8].
Реляционная модель данных
Для большинства существующих систем управления базами данных характерна жесткая связь СУБД с поддерживаемой ее моделью данных. В частности реляционные СУБД реализует реляционную модель данных [ 9 ] . Реляционная модель определяет: единую концепцию структуризации данных, называемую отношением (или таблицей) для представления всех данных в базе, набор операций над отношениями, называемый реляционной алгеброй (эти операции включают выборку, проекцию, объединение, пересечение...), ряд ограничений, например, значение колонки таблицы должно быть атомарным. Реляционные СУБД, кроме того, предоставляют: набор стандартных типов данных, которые могут быть использованы в колонках таблицы (CHAR, DATETIME, FLOAT...), непроцедурный язык манипулирования данными, который может быть определен в терминах реляционной алгебры (SQL), реализацию этого языка.
Реляционная модель базируется на понятии п-арного отношения, которое может рассматриваться как таблица с фиксированным количеством поименованных столбцов и -переменным числом строк. Строки в таблице называются кортежами, а столбцы атрибутами. Взаимоотношения между записями называются наборами. Реляционные операции над ВД, такие, как формирование подмножества строк или столбцов, формирование объединения, разности или пересечения наборов, комбинирование отношений за счет присоединения наборов, могут быть реализованы с использованием языка манипулирования данными. Такие языки в реляционной модели данных обычно получаются из реляционного исчисления или реляционной алгебры. Реляционная модель преодолевает записно-ориентированные ограничения иерархической и сетевой моделей за счет разрешения отношений типа «многие ко многим» без использования указателей.
Межзаписные отношения поддерживаются в едином ключе посредством одинаковых значений. Простота и универсальность реляционной модели является ее фундаментальным достижением. Другие аспекты реляционного подхода также имеют важное значение. Они включают в себя независимость физической организации данных, высокоуровневые операционные примитивы общего назначения, обработку наборов записей (в противоположность позаписной обработке), а также мощный математический базис.
Типичный сценарий работы с РСУБД выглядит следующим образом: приложение посылает SQL запрос РСУБД, который определяет критерии выборки данных из различных таблиц базы. В результате выполнения запроса формируется таблица результатов (таблицы реализованы в SQL как мультимножества строк), которая пересылается обратно программе-клиенту.
Модель вычислимых объектных представлений на основе функционального интерфейса
Набором атрибутов А класса назовём множество атрибутов, принадлежащее этому классу: А к {А0}. Пусть задан хранимый класс SC = {Aso, Iso}, где Asc - набор атрибутов класса SA, Isc - набор открытых методов класса (интерфейс). Виртуальным атрибутом VA назовём атрибут класса, не хранимый в памяти, а получаемый путём вызова функции преобразования VA = F (SA). Опишем класс представления VC = {AvC, Ivc} t имеющего набор виртуальных атрибутов VA и набор открытых методов Ivc. Тогда процесс преобразования можно описать следующим образом: VC - SC: l"SC/ ВС } - {F (Asc), Ivc}. Рассмотрим возможные варианты преобразования: 1. Атрибут виртуального класса получается на основе только одного атрибута хранимого класса: Fi(Ase) - А (рис. 2.2). 2. Атрибут виртуального класса получается на основе нескольких атрибутов хранимого класса. Fn (SA) - Ave (рис. 2.3). 3. Набор атрибутов виртуального класса получается на основе набора атрибутов хранимого класса: Fj;(SA) - VA (рис. 2.4).
Операцией обновления набора атрибутов хранимых классов SA через объектное представление назовём изменение хранимых данных, соответствующее изменению атрибутов виртуальных классов VA. Пусть дана функция прямого преобразования F. Назовём функцией обратного преобразования F такую функцию, для которой
Требования, накладываемые на функцию обратного преобразования, описаны в разделе «Проблема обновления данных через представления».
Модели объектных представлений, описанные ранее, обладают ограниченными возможностями по преобразованию данных. Докажем, что предложенная модель является более общей. Для этого рассмотрим реализацию с помощью данной модели возможностей по преобразованию, описанной в модели MultiView, которая имеет наибольшие возможности из используемых в настоящее время моделей. Модель MultiView позволяет производить реструктуризацию данных внутри класса, а также позволяет проводить ограниченный набор преобразований над данными одного экземпляра класса. В этот набор входят «выборка и сокрытие данных» и «вычисление по заданным правилам».
Выборка и сокрытие данных
Для построения представления, организующего преобразования методом выборки и сокрытия данных, необходимо описать набор преобразований вида Fi(Asc) - А а для каждого атрибута виртуального класса. При этом -функция отображения Fj. является элементарной и осуществляет копирование атрибута хранимого класса в атрибут виртуального класса. Функция обратного преобразования в таком случае будет копировать атрибут виртуального класса в атрибут хранимого класса.
Вычисление по заданным правилам
При использовании данного способа могут быть реализованы преобразования F!(ASC) - А , Fn(SA) - А с, при этом набор SA ограничен только атрибутами хранимого объекта, без использования атрибутов, доступных по объектным ссылкам. Для реализации обратного преобразования Fx" (Ау0) - Аас, Fn4 (AvC) - SA необходимо, чтобы функция обратного преобразования F существовала и была однозначной. В случае неоднозначности функции обратного преобразования пользователь может задать её вручную.
Набор правил преобразования, доступных в модели MultiView, ограничен арифметическими операциями для числовых типов и операциями выборки для типов, являющихся встроенными контейнерами. При применении операций выборки в класс представления попадают только те объекты хранимых классов, которые удовлетворяют заданным условиям. В качестве условий задаётся набор операций сравнения для встроенных языковых типов (т.н. POD-типов).
Все операции производятся на стороне сервера, при этом в модели MultiView не поддерживается хранение и исполнение методов класса на стороне сервера. Поэтому правила преобразования должны быть выражены исключительно в терминах действий над POD-типами. Таким образом, для преобразований по заданным правилам доступны только атрибуты, имеющие POD-тип. При этом для использования в -преобразовании доступны атрибуты объектов по хранящимся объектным ссылкам. Правила преобразования описываются на языке описания схемы MultiView.
В качестве примера рассмотрим класс представления, реализующий преобразование атрибута «сопротивление» R хранимого класса Resistor, в атрибут «проводимость» G виртуального класса VResistor (рис. 2.5) .
ООБД на основе языков описания схемы
К первой группе относятся БД, в которых схема хранимых данных задаётся с помощью отдельного языка описания объектов (ODL - object description language). Подход, основанный на языке описания объектов, входит в стандарт ODMG-93 [40]. Данный язык должен обладать достаточно богатой семантикой, чтобы на нём можно было описать существующие в различных языках программирования концепции объектного проектирования, такие как множественное наследование, экстенты, метаклассы и т.д.
Основным преимуществом данного подхода является независимость формата входного файла от языка программирования. Отсюда же следует и основной недостаток - поскольку в таком случае не существует средств сопоставления описания классов в программе и в базе данных, возможно появление ошибок при их несовпадении.
Ко второй группе относятся БД, в которых схема хранимых данных задаётся путём модификации исходного кода программы. Существуют несколь ко подходов к реализации таких систем.
В первом из них в некотором файле описывается набор классов, который образует схему хранимых данных. Этот файл подаётся на вход некоторому транслятору, который извлекает схему хранимых данных и создаёт на её основе БД.
Плюсы данной системы - автоматизация создания схемы на основе модифицированного языка программирования позволяет избавиться от возможных несоответствий между классами, исполь зуемыми программой, и хранимыми классами, описанными на отдельном языке, как в предыдущем подходе.
Минусом такого подхода является привязка к языку, на котором осуществляется работа с БД. Так, если был разработан транслятор, преобразующий заголовочный файл на языке C++ в описание, используемое БД для создания схемы, то для разработки на языке Smalltalk придётся создавать отдельный транслятор, выполняющий ту же функцию. Кроме этого, файлы, подаваемые на вход транслятора, в большинстве реализаций не являются корректными входными файлами языков программирования, в результате чего транслятор вынужден создавать не только управляющую информацию для создания схемы данных, но и корректный выходной файл на языке программирования. Примером системы, основанной на таком подходе, является ООБД Objectivity [41].
Второй подход основан на реализации набора классов и методов, которые описывают структуру хранимого класса. В данном подходе каждый класс, описываемый как сохраняемый, должен быть унаследован от специального класса-предка, реализующего большую часть функциональности по сохранению-восстановлению данных. После этого в классе должен быть переопределён метод, некоторым образом описывающий структуру данных этого класса.
Основным преимуществом этого подхода является полное отсутствие необходимости дополнительных преобразований информации. Описанная в тексте программы структура данных напрямую компилируется в объектный код. При этом не возникает ошибок вследствие несовпадения описаний схемы (как в первом подходе) или неправильной трансляции из модифицированного кода (как в первом варианте второго подхода). К тому же данный подход является более гибким при модификации исходных текстов программы. Примером такой системы является БД GOODS [42] . В данной БД для -описания структуры хранимых данных используется набор макроопределений, реализующих код обработки структуры хранимого в БД класса.
Основной задачей, для решения которой разрабатывается система поддержки объектных представлений, является задача интеграции программных компонентов САПР, разрабатываемых в пределах одной компании, в единую систему. При этом для данной системы характерны следующие особенности:
1. Наличие исходных кодов различных компонентов даёт возможность более глубоко интегрировать систему в САПР для обеспечения оптимальной производительности.
2. При этом желательно ослабить связанность различных модулей друг с другом, чтобы избежать необходимости их повторной перекомпиляции и тестирования, что позволит увеличить скорость разработки уменьшить её стоимость.
3. Интеграцию необходимо провести в рамках единой БД, что позволит упростить доступ к проектным данным для компонентов САПР и уменьшить избыточность этих данных.
Структура базы данных смешанного моделирования
Для интеграции программных компонентов САПР СБИС в единую систему используются несколько различных подходов:
1. Преобразование информации в один из стандартных форматов передачи проектных данных (таких как EDIF) и обмен данными через файл в файловой системе.
2. Использование открытого интерфейса программирования приложений (АРІ) для обмена проектной информацией (например, OpenAccess).
3. Использование БД, содержащих проектную информацию и доступных для компонентов САПР. В качестве таких БД в настоящее время наиболее широко используются реляционные и объектно-ориентированные БД.
Передача проектной информации с помощью файлов стандартных форматов используется в основном для передачи данных между компонентами САПР разных производителей [50, 51] . Определённый и фиксированный формат таких файлов гарантирует, что при переходе к новой версии программного обеспечения между компонентами САПР не будет потеряна совместимость. Использование этого метода для интеграции компонентов САПР одного производителя нецелесообразно ввиду большой сложности и трудоёмкости написания трансляторов, а также низкой скорости их функционирования и отсутствием возможности контроля за проектными данными.
Использование для интеграции API представляет альтернативу подходу на основе файлов. Использование стандартных интерфейсов позволяет интегрировать средства проектирования различных производителей. Но, как показано выше, реализации данного подхода в настоящее время проигрывают по соотношению гибкость/эффективность доступа подходам, основанным на базах данных.
Применение для интеграции различных видов БД в наибольшей степени оправдано при разработке САПР, состоящей из средств проектирования одного производителя [52 ] . При использовании БД программист имеет возможность реализовывать совместный доступ к проектным данным, а также назначать пользователям права доступа. Также использование БД гарантирует защиту проектных данных и их восстановление при сбоях в работе аппаратного обеспечения.
Использование реляционных СУБД в САПР СБИС малоэффективно из-за особенностей проектной информации. Компоненты САПР обычно используют навигационный доступ к данным вместо поиска всех объектов, удовлетворяющих определённому критерию. В результате в РБД должна часто выполняться медленная операция объединения таблиц, что приводит к значительному снижению быстродействия. Вследствие невозможности прямого отображения реляционной модели БД в объектную модель современных приложения программистам приходится вручную реализовывать системы отображения реляционных данных в объекты либо использовать так называемые объектно-реляционные БД, в результате падает скорость разработки программного обеспечения САПР. Также затруднена реализация дополнительных требований к БД САПР, как например поддержка длинных транзакций, контроль доступа на уровне объектов и использование механизма контроля версий.
Наиболее удобным методом интеграции является использование ООБД, что позволяет снизить затраты на загрузку данных. Такие БД с высокой скоростью осуществляют навигационный доступ к данным и не требуют реализации дополнительных преобразований из хранимого формата данных в объектный формат данных приложения. При этом организация на базе данного подхода БД САПР СБИС остаётся сложной. При интеграции в глобальную модель данных всех приложений эта модель становится очень сложной и написание вручную средств навигации по ней становится неэффективным.
Использование дополнительного слоя преобразований, реализуемого с помощью системы поддержки объектных представлений, помогает решить эту проблему. Наличие механизмов автоматической поддержки преобразований из глобальной модели данных в локальную модель приложения позволяет существенно ускорить процесс разработки и снизить её сложность.
Сравнивая предлагаемый метод с другими методами разработки, можно сделать вывод, что он значительно упрощает разработку компонентов САПР, обеспечивая сопоставимую или несколько более низкую скорость доступа к данным. Данный недостаток является в большинстве приложений несущественным, поскольку время доступа к хранимым данным обычно значительно меньше времени их обработки. При этом в типичном случае в процессе работы загружается только часть хранимой информации, что также снижает влияние скорости загрузки данных через объектные представления на общую скорость работы системы. В особо критичных к скорости доступа местах следует использовать методы преобразований, поддерживающие создание временных объектов. Результаты сравнительного анализа методов разработки представлены в таблице 4.2.
