Базы данных с множественными подсхемами

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

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

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

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

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

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

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

Совокупность пользовательских представлений об изделии, представленных в форме подсхем, определяет модель этого изделия. Для моделирования необходимы:

1) информационные элементы, представленные в ЭВМ в виде алгоритмов и структур данных;

2) система моделирования, представляющая собой совокупность средств для работы с алгоритмами и структурами данных;

3) средства отображения информации, полученной в результате работы системы моделирования.

В САПР особо важную роль играют средства работы с моделью и отображения результатов моделирования. Эти средства составляют основу интерактивного режима работы системы, и по ним можно судить об эффективности системы в целом.

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

Проверка полноты данных может выполняться на одном из двух уровней: изделия и подсхемы. На уровне изделия используются отношения, связывающие различные модели одного объекта. Различные модели изделия определяются на уровне подсхем. Моделью изделия называется хранящееся в базе данных представление о проектируемом объекте. Модели уровней изделия и подсхемы хранятся совместно, но их следует четко различать.

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

Можно перечислить много недостатков схем проектирования и графов версий: с их помощью невозможно сформулировать последовательную методологию проектирования; они не полностью отображают сущность процесса проектирования; в них содержится мало информации, которая могла бы использоваться при моделировании и отображении (в особенности — в части структуры изделий и их геометрических свойств), они неудобны для организации интерактивного взаимодействия конструктора с базой данных и различными подсхемами, используемыми при таком взаимодействии.

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

Более того, если средства расходуются бездумно, проблемы от этого лишь усугубляются.

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

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

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

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

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

Рабочая модель и факты, которым она соответствует, входе работы над проектом довольно быстро меняются;

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

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

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

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

2. Локальная непротиворечивость соответствует уровню представления. Вносимые изменения затрагивают только одно из представлений проектируемого объекта (например, изменение шага установки микросхем на печатной плате).

Версия представления глобально непротиворечива тогда, когда она может быть получена по своим предшественникам в графе версий. Проект изделия глобально непротиворечив, когда все принадлежащие ему версии глобально непротиворечивы.

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

Проектируемый объект частично непротиворечив, если:

1) граф версий соответствует схеме проектирования;

2) все версии обладают свойством непротиворечивости какого-либо типа;

3) все преемники независимо противоречивых версий являются зависимо противоречивыми.

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