Важной особенностью модулей Logic, Layout, Router программы PADS, созданной фирмой Mentor Graphics для проектирования печатных плат (ПП), является наличие в них автоматизации как элемента Object Linking and Embedding (OLE) [1]. Автоматизация включает в себя сервер и клиент. Выступая в качестве cервера, PADS предоставляет свои данные и функциональные возможности другим программам, а как клиент может использовать данные и функциональные возможности других программ. Это означает, в частности, что автоматизация как элемент OLE создает предпосылки для гармоничного интегрирования модулей PADS в программную среду предприятия.

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

Специфические требования к дизайну обычно формулируются разными лицами - разработчиком принципиальной схемы, специалистом по электромагнитной совместимости, изготовителем ПП ... - и сохраняются в разных документах. Задача-максимум состоит в том, чтобы посредством предоставленных OLE средств определенным образом внедрить указанные документы в проект и по возможности автоматически содействовать реализации в дизайне содержащихся в них требований. Аналогом этому может служить воздействие Design Rules и Preferences на работу инструментов PADS.

Зафиксированные в Design Rules и Preferences параметры учитываются двумя типами инструментов PADS: конструкторскими и контрольными. Специфические требования к дизайну могут аналогичным образом отражаться в функциях новых инструментов двух названных типов (подробнее о контрольных инструментах см. [2]).

Наиболее простой способ разработки новых инструментов для PADS состоит в использовании Basic Editor, включенного в каждый из модулей PADS. В том случае, когда число дополнительных требований к дизайну невелико, а количество создаваемых инструментов ограничено единицами и необходимость одновременного использования нескольких из них отсутствует, Basic Editor можно признать приемлемым средством решения задачи. В противном случае возникают осложнения, связанные в основном со следующими двумя недостатками Basic Editor и создаваемых в нем Basic Scripts как инструментов PADS:

- После старта любого Basic Script исключается возможность старта следующего скрипта до момента окончания пользования первым.

- При пользовании Basic Scripts теряют свои прежние функции F-клавиши. Они могут приобрести новые функции, если это предусмотрено скриптом. Но прежние функции вызываться F-клавишами не будут до тех пор, пока скрипт в работе.

Гораздо удобнее, однако, при проектировании ПП применять инструменты, выполненные не в виде Basic Scripts, a в форме Windows-программ, связывающихся с PADS посредством компонентов OLE. Кроме устранения указанных выше недостатков, этим достигаются еще и такие преимущества, как исключение доступа пользователя к кодам программы (защита их от изменения, сохранение авторских прав разработчика), выбор привычной программной среды и языка программирования (Basic Editor с его несколько своеобразным диалектом Visual Basic требует все-таки некоторого переучивания и приобретения определенных навыков).

Это не значит, что от Basic Editor рекомендуется отказаться. Оптимальным вариантом яляется использование его для проверки идей иструментов и только потом перепрограммирование последних в Windows-программы, если идеи хорошо реализуются и работа себя оправдывает.

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

Указанная проблема может возникнуть также и в силу того, что упоминаемые в специфических требованиях объекты проекта или их характеристики не включены в число предоставляемых для опроса или изменения через компоненты OLE. Здесь следует заметить, что количество таких недоступных, а тем более неизменяемых объектов и их свойств довольно велико и желание решить абсолютно все поставленные задачи вряд-ли осуществимо. Но с помощью некоторых неописываемых Mentor Graphics приемов можно все-таки дополнительно минимировать число задач, остающихся нерешенными.

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

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

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

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

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