Проектирования на макроуровне

Большой класс задач АП со­ставляют анализ во временной области и параметриче­ская оптимизация объектов при функциональном проек­тировании на макроуровне. Большинство таких объек­тов описывается системами обыкновенных дифференци­альных уравнений (ОДУ). Для анализа этих объектов широко используются методы:

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

2) неявные численного интегрирования ОДУ;

3) Ньютона для итерационного решения системы не­линейных алгебраических уравнений;

4) Гаусса (или его модификации) для решения си­стем линейных алгебраических уравнений.

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

Примечание, Далее изложение материала будет ориентиро­вано в основном на такие пакеты. Однако это ни в коей мере не сказывается на его общности.

К основным требованиям, предъявляемым к пакетам функционального проектирования, наряду с рассмотрен­ными выше (см. Введение) также относятся:

приемлемые затраты ресурсов ЭВМ для анализа объектов большой размерности (описываемых жесткими системами ОДУ, содержащих тысячи переменных);

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

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

В составе пакета функционального проектирования выделяют три основные части (подсистемы): 1) языко­вую; 2) обрабатывающую; 3) монитор.

Примечание. Функции монитора пакета функционального проектирования схожи с функциями монитора САПР и описаны в § 1.2.

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

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

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

Рис. 5.1. Схема трансляции на промежуточный язык:

0_Bxi — описание объекта проектирования на i-м входном языке; T_i — i-й транслятор; О_пр — описание на промежу­точном языке

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

Для перевода описаний на входных языках в описа­ние на промежуточном языке используются соответству­ющие трансляторы, как это показано на рис. 5.1.

Входные трансляторы САПР согласно суще­ствующей теории машинного перевода формальных язы­ков принято рассматривать состоящими из трех основ­ных блоков: 1) лексического; 2) синтаксического; 3) ге­нератора кода. Все блоки имеют доступ к общему набору массивов и таблиц.

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

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

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

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

Взаимодействие блоков в трансляторе зависит от осо­бенностей входного и промежуточного языков. Так, если эти языки синтаксически близки, то можно построить транслятор по схеме с одним проходом. В таких трансля­торах вызов блоков осуществляется циклически: лекси­ческий блок вырабатывает лексему; она передается син­таксическому блоку, который порождает один или не­сколько атомов; генератор кода «развертывает» эти атомы в слова промежуточного языка; затем управление вновь передается лексическому блоку и т. д., пока не бу­дет исчерпано описание на входном языке. Если языки синтаксически различны, то возникает необходимость в организации иной схемы взаимодействия блоков транс­лятора, при которой они включаются в работу однократ­но: сначала лексический блок выдает полную цепочку лексем, затем синтаксический блок переводит ее в после­довательность атомов, преобразуемую генератором кода на последнем этапе в предложения промежуточного язы­ка. Такой транслятор называется трехпроходным. Мно­гопроходные трансляторы характеризуются большими затратами памяти, необходимой для хранения всей це­почки лексем и (или) атомов.

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

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

с терми­нологией, сокращениями, ГОСТами, соглашениями, принятыми в данной предметной области.

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

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

Промежуточный язык пакета проекти­рования, как и его входные языки, состоит из двухподмножеств: языка описания объекта (ЯОО) и языка описания задания на проектирование (ЯОЗ). Первый является непроцедурным и служит для предоставления пакету сведений о структуре и элементах проектируемой технической системы. Второй необходим для указания пакету задания на расчет и должен быть процедурным. При исследовании физического объекта во времен­ной области ЯОЗ должен содержать, по крайней мере, че­тыре основных оператора: 1) расчета статического состояния; 2) расчета переходных процессов; 3) много­вариантного анализа; 4) оптимизации. Для реализации режима интерактивного взаимодействия пользователя с пакетом не только на этапе подготовки исходного описа­ния, но и на этапе расчета по одному из этих операторов

Рис. 5.2. Схема маршрута взаимодействия подпрограмм пакета функционального проектирования

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

■ Примечание. В § 5.3 дано краткое описание промежуточ­ного языка программного комплекса ПЛ-6.

Обрабатывающая подсистема. Она осуществляет не­посредственное решение проектных задач. Именно эта подсистема реализует заложенное в пакет математичес­кое обеспечение. На рис. 5.2 схематично представлена структура обрабатывающей подсистемы, отражающая маршрут взаимодействия подпрограмм при решении за­дачи параметрической оптимизации непрерывного объек­та по временной области. Она характеризуется ярко вы­раженной вложенностью модулей и, следовательно, раз­ной частотой их использования: чем ниже уровень, за­нимаемый модулем, тем чаще он используется. Так, типовые значения

частот использования модулей уровня 6 относительно уровня 4 имеют порядок 10³.

Пакеты функционального проектирования как про­граммы, обрабатывающие предложения и директивы входного языка, являются языковыми процессорами. Су­ществует два типа языковых процессоров: интерпретато­ры и трансляторы. Структура пакета проектирования, построенного по принципу интерпретации, укрупненно показана на рис. 5.3. Его языковая подсистема ЯП вос­принимает описание проектируемого объекта и задания на его расчет на входном (или промежуточном) языке и порождает (обычно в ОП) структуры данных, содержа­щих описание объекта и решаемой задачи в удобной для машинной обработки форме ВПД. Эта информация в дальнейшем интерпретируется обрабатывающей подсис­темой (ОБрП).

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

Пакет функционального проектирования, построен­ный с использованием принципа трансляции, до начала расчета не имеет полной и скомпонованной обрабатыва­ющей подсистемы. Языковая подсистема такого пакета воспринимает описание на промежуточном (входном) языке и в качестве выхода выдает на объектном языке программу(ы) вычислений в соответствии с входным описанием. Объектным языком может быть любой алго­ритмический язык высокого уровня (ПАСКАЛЬ, ФОРТ­РАН, ПЛ/1 и др.) или язык машинных команд. Если в качестве объектного используется машинный язык, то полученные программы будут сразу готовы к выполне­нию. Если же объектный язык — язык высокого уровня, то дополнительно необходим перевод объектной програм­мы в машинные команды. Транслятор, выходом которого являются объектные программы в машинных командах, называют компилятором.

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

Рис. 5.3.

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

Выбор типа языкового процессора. Внастоящее вре­мя при создании пакетов проектирования находят применение оба принципа, хотя чаще используется принцип интерпретации, а пакеты-трансляторы сочетают в себе оба этих принципа, причем в разных пакетах в различ­ной степени. Так, в программе многоуровневого модели­рования MACRO генерируется на языке ФОРТРАН только подпрограмма, реализующая алгоритм Гаусса для решения системы линейных алгебраических уравне­ний, в пакете КРОСС в виде объектной программы на языке ПЛ/1 оформляются уравнения математической модели всей проектируемой системы, в программном комплексе ПА-6 компиляции подлежит большинство мо­дулей нижних уровней структуры обрабатывающей под­системы. Пакеты-трансляторы, а тем более компилято­ры, обычно более сложны в разработке, чем интерпре­таторы.

Применение для создания ПО того или иного подхода оказывает ключевое влияние на вычислительную эффек­тивность пакета. Объектные программы, полученные в результате работы языковой подсистемы пакета-транс­лятора, в большинстве случаев являются значительно более быстродействующими по сравнению с пакетами-интерпретаторами (при условии, конечно, одинаковости используемого математического обеспечения). Объясня­ется это тем, что объектная программа представляет со­бой линейную программу, содержащую минимально необходимое количество команд, адресная часть которых настроена непосредственно на используемые элементы данных. Все операции, нужные для определения опти­мальной последовательности команд и их операндов, вы­полняются однократно на этапе трансляции. Разность в быстродействии иллюстрируется рис. 5.4, а, где пред­ставлены графики затрат машинного времени Т на одно­кратное выполнение процедуры прямого хода Гаусса интерпретирующей и скомпилированной подпрограммами при учете разреженности матрицы коэффициентов сис­темы линейных алгебраических уравнений (в экспери­менте использовался прямой способ кодирования разре­женных матриц, среднее количество ненулевых элемен­тов справа от диагонали составляло 2,2), N — порядок решаемой системы ЛАУ. Большие затраты для интерпре­тирующей подпрограммы обусловливаются накладными расходами, связанными с определением координат эле­ментов разреженной матрицы и преобразованием индек­сов массивов в действительные адреса. Выбор тех или иных способов кодирования разреженных матриц позволяет

500 1000 N 500 1000 N

а) б)

Рис. 5.4.

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

■ Примечание. Процедура решения системы линейных алге­браических уравнений — одна из наиболее «длительных» и ча­сто используемых при анализе, как во временной, так и в час­тотной областях.

В общем случае скомпилированный вариант любой процедуры расчета требует большего объема ОП, чем ее интерпретирующий вариант. На рис. 5.4, б даны графи­ки зависимости затрат памяти от порядка решаемой сис­темы уравнений N для скомпилированной и интерпрети­рующей процедур прямого хода Гаусса. Наклон прямой, характеризующей зависимость затрат памяти от порядка N для скомпилированного варианта, больше наклона пря­мой, характеризующей ту же зависимость для интерпре­тирующего варианта. Однако разница в затратах памяти для систем с порядком не более 1000 несущественна для современных ЭВМ.

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

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

Использование динамической загрузки подпрограмм в ОП не всегда удобно, так как в этом случае исключа­ется возможность использования общих областей и гло­бальных структур данных. Другой аспект вопроса о затратах ОП — распределение ОП под структуры дан­ных. В пакетах-трансляторах память под структуры дан­ных рабочей программы выделяется статически и строго необходимого размера. В обрабатывающей подсистеме интерпретатора необходимо динамическое распределение памяти, однако его использование связано с увеличением затрат машинного времени.

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

Важным преимуществом пакетов-трансляторов явля­ется следующее. Фаза собственно трансляции описания на промежуточном языке в объектную программу вклю­чается однократно и занимает малую долю от всех за­трат времени ЭВМ на анализ и параметрическую опти­мизацию физического объекта. На этом этапе языковая подсистема пакета, построенного по принципу трансля­ции, выполняет многие из тех функций и процедур, кото­рые в обрабатывающей подсистеме пакета-интерпретато­ра выполняются многократно уже на этапе расчета и поэтому являются источником больших «накладных» расходов. Вследствие этого на эффективность пакетов-трансляторов оказывают слабое влияние способы представления

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

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

Пакеты-компиляторы, выходом языковой подсистемы которых являются программы на машинном языке, могут различаться типом загрузки объектной программы в ОП. Например, в пакете ПАРМ используется схема «компи­ляция— выполнение», в нем генерируемые машинные команды помещаются в специально отведенную область ОП. По окончании генерации всей объектной программы ей передается управление. Такой подход характеризует­ся большими затратами ОП, так как языковая подсистема пакета и вырабатываемая им объектная программа располагаются в памяти одновременно.

Другой недоста­ток этого подхода — необходимость разрешения ссылок между сгенерированными модулями и «постоянными» подпрограммами каким-либо образом в самом пакете проектирования. От перечисленных недостатков свободны пакеты-компиляторы, выходом языковых подсистем ко­торых являются объектные программы в виде, пригод­ном для обработки редактором связей из состава ОС.

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

На выбор способа построения программы любой про­цедуры оказывают влияние следующие критерии: 1) час­тота исполнения процедуры при расчете; 2) способ доступа к данным, используемый в процедуре; 3) степень инвариантности процедуры к структуре и размерности проектируемого объекта.

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

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

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

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

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

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

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

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

Закрытый пакет проектирования — пакет, реализация в ко­тором нового элемента математического обес­печения требует пере­программирования большого числа входя­щих в его состав моду­лей. Такая модифика­ция пакета под силу только его разработчи­ку, а затраты на нее могут быть соизмеримы с затратами на создание нового пакета.

В ограниченно открытом пакете проектирования реализация нового метода или алгоритма состоит во включении в его состав нового модуля. Все изменения, связанные с подключением новой подпро­граммы, локализованы в одном из «старых» модулей и проводятся по формальным правилам, задаваемым соот­ветствующей инструкцией. Такие изменения могут быть выполнены квалифицированным пользователем-програм­мистом самостоятельно. Включение новых модулей в ограниченно открытый пакет проектирования и их отлад­ка связаны с большими накладными расходами, требуют от пользователя глубокого знания структуры ПО и осо­бенностей используемой ОС. Такие пакеты проектирова­ния не защищены от внесения ошибок пользователя.

Открытый пакет проектирования харак­теризуется тем, что его расширение не требует каких-ли­бо изменений в уже существующих модулях. Связь но­вых и старых модулей происходит с помощью паспортов, описывающих интерфейсы модулей. Такие паспорта за­полняются для каждого вновь включаемого модуля и располагаются в локальной БД пакета проектирования. Создание открытых пакетов проектирования требует предварительной структуризации математического обес­печения, основанной на анализе процедурного состава известных алгоритмов анализа и оптимизации (см. рис. 5.2). Полученная обобщенная структура вычислительного процесса позволяет

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

Так как связь модулей по управлению и информации в открытых пакетах должна осуществляться с помощью системы паспортов, то в паспорте модуля содержатся сведения об информационных массивах и переменных, используемых в нем, о его объеме, значениях парамет­ров, используемых «по умолчанию» и т.п. В открытых пакетах-интерпретаторах вызов в ОП модулей происходит но командам динамической загрузки, обращению к модулю предшествует интерпретация его паспорта, счи­танного из локальной БД. Но из загруженных таким об­разом модулей исключается вызов каких-либо подпро­грамм, а к ним самим невозможно обращение по коман­де на языках высокого уровня. В этом основная труд­ность создания открытых пакетов-интерпретаторов.

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

Пакетный и диалоговый режимы работы пакетов функционального проектирования.На макроуровне па­кеты проектирования должны допускать пакетный и диа­логовый режимы работы.

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

отношении пакет-транслятор предоставляет пользовате­лю больше возможностей.

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

■ Примечание. При необходимости несложно организовать передачу сгенерированных языковой подсистемой пакета-транс­лятора объектных программ (на языке высокого уровня) для дальнейшей обработки и расчета на мощном вычислительном комплексе. Построение входных трансляторов и языковой под­системы реентерабельными обеспечивает множественный доступ пользователей в данном режиме работы пакета.

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

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