содержание .. 4 5 6 7 ..

Управление сложными проектами в интегрированных САПР - часть 6

высокая информационная сложность объекта проектирования, не позво-

ляющая обрабатывать объект целиком (возникает необходимость декомпозиции
объекта с последующим “сшиванием” его частей);

наличие локальных и глобальных критериев оценки качества проектных

решений, используемых проектными процедурами;

специализация технических и программных средств, направленная на вы-

полнение проектных процедур разных видов;

выполнение ряда работ в условиях частичной неопределенности в отно-

шении корректности и достаточности исходной информации для отдельно взя-
той проектной процедуры;

частое отсутствие однозначных формализованных стратегий проектиро-

вания, гарантирующих получение заданного результата;

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

решений;

наличие большого числа интерактивных процедур (имеется в виду вме-

шательство человека в автоматизированный процесс проектирования) в силу
невозможности получения приемлемого проектного решения иным способом;

наличие большого количества ошибок в проектных решениях, связанных

с использованием интерактивных процедур.

Перечисленные выше факторы предъявляют особые требования к органи-

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

По оценкам специалистов на устранение ошибок проектирования прихо-

дится в среднем 20% стоимости проекта и расходуется более 30% времени, за-
траченного на разработку проекта [27]. Поэтому любая технология, позволяю-
щая существенно уменьшить количество ошибок, имеет исключительно важное
значение. Одним из способов решения данной проблемы является организация
сквозного проектирования в интегрированной САПР, другим

−

создание инфра-

структур САПР, обеспечивающих интеграцию инструментальных средств про-
ектирования и данных с управлением при помощи унифицированного интер-
фейса пользователя [28, 29].

1.1.7.

Концепция сквозного проектирования в

интегрированной САПР

В основу построения концепции сквозного проектирования в интегриро-

ванной САПР положена следующая интерпретация понятия “сквозное проек-
тирование” с системной точки зрения:

обеспечение модульной структуры системы с четкой регламентацией

внешних спецификаций модулей;

обеспечение унифицированного системного интерфейса, не зависящего от

вида информации, вырабатываемой модулями системы;

организация контроля и управления проектами на уровне проектных ре-

шений, вырабатываемых модулями системы;

отчуждение проектных решений от их авторов;
иерархическая структура объекта проектирования, представленная в виде

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

идентификация проектных процедур и проектных решений;
наличие в системе только двух типов модулей: управляющих (УМ) и об-

рабатывающих (ОМ);

организация межмодульных обменов только по схеме: УМ

↔

ОМ;

высокая степень автономности модулей;
слабое взаимодействие между модулями системы (ненагруженный

трафик передачи больших информационных массивов).

На основе выбранных системных критериев можно представить понятий-

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

Согласно этой модели, в качестве конвейера рассматривается мониторная

система, а в качестве рабочих мест конвейера

−

обрабатывающие подсистемы.

К понятию обрабатывающих подсистем отнесены все проектирующие и обслу-
живающие подсистемы.

Предложенная понятийная модель позволяет построить интегрированную

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

1.1.8.

Системные среды (инфраструктуры) САПР

В течение последних 10

−

15 лет за рубежом наблюдается повышенная

маркетинговая  активность  в  области  так  называемых  системных  сред,  или  ин-
фраструктур  САПР  (CAD  Framework).  Десятки  компаний,  среди  которых  как
малоизвестные,  так  и  всемирно  признанные  фирмы  (например,  Digital  Equip-

ment Corp., Mentor Graphics Corp.,  Cadence Design Systems Inc. и другие), пред-
лагают  инфраструктуры  собственной  разработки  в  качестве    единого  решения
проблемы интеграции различных инструментальных программных средств про-
ектирования. В США в 1988 году была создана некоммерческая организация

−

консорциум CAD Framework Initiative (CFI), работающий над созданием и вне-
дрением стандартов на инфраструктуры САПР и объединяющий около 40
фирм-поставщиков средств САПР [30]. В Западной Европе действует родствен-
ная организация

−

консорциум EuroCFI [31].

Основными направлениями исследований, проводимых в настоящее вре-

мя под эгидой CFI , являются [31]:

разработка архитектуры системной среды

−

анализ взаимозависимостей и

взаимосвязей функциональных частей инфраструктуры;

создание подходов и средств представления проекта

−

разработка инфор-

мационной модели для описания проекта и определение спецификаций про-
граммного интерфейса для доступа к элементам проекта;

исследование механизмов управления проектными данными

−

обеспече-

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

выработка подходов к управлению методологией проектирования

−

раз-

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

Ключевыми элементами любой инфраструктуры САПР являются интер-

фейс пользователя, методы доступа к базам данных и средства организации
взаимодействия между прикладными программами. В настоящее время сущест-
вуют два основных типа инфраструктур: инфраструктуры, ориентированные на
управление процессом проектирования, и инфраструктуры, ориентированные на
управление проектом [27].

Инфраструктуры первого типа, как правило, являются специализирован-

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

Инфраструктуры второго типа ориентированы на управление данными

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

содержание .. 4 5 6 7 ..