Смекни!
smekni.com

Разработка библиотеки для КОМПАС График Расчет и построение теплообменников (стр. 2 из 17)

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

Распространен еще один способ наращивания функциональности пакета - разработка дополнительных модулей (plug-in) на компилируемых языках программирования общего назначения, таких, как Паскаль, Си или Си++. Известные примеры реализации этого подхода - разработка модулей обработки изображений для графических программ AdobePhotoshop, AdobeIllustrator, AdobePremiere, расчетных модулей для 3D StudioMAX и др. Каждый дополнительный модуль можно считать библиотекой с одной или несколькими функциями, которые пользователь может вызывать из среды конкретного пакета (базового пакета). Изнутри модуля можно обращаться к базовому пакету, обмениваться с ним данными, согласованно показывать какие-либо диалоговые окна, т.е. "встраиваться" в интерфейс пользователя базового пакета.

КОМПАС-МАСТЕР 5, предназначен для разработки дополнительных модулей для пакета КОМПАС 3D - прикладных библиотек. Некоторые дополнительные модули могут обладать собственной сложной и в какой-то мере самодостаточной функциональностью, что позволяет называть их приложениями в среде КОМПАС.

Первые версии КОМПАС разрабатывались для MS-DOS и в версиях до 5.0 содержали собственный Си-подобный язык программирования. При переходе в среду Windows оказалось удобным оформлять прикладные библиотеки в виде динамических библиотек (DLL) Windows. Инструментальные средства для разработки прикладных библиотек были сделаны в виде библиотек функций, доступных для вызова из распространенных сред разработки - Borland C++, BorlandDelphi, Borland C++ Builder, Visual C++ и др. Круг пользователей КОМПАС-МАСТЕР существенно увеличился, поскольку они смогли разрабатывать прикладные библиотеки КОМПАС с помощью привычных сред разработки.

В последнее время в КОМПАС были добавлены средства поддержки технологии СОМ, обеспечивающей модульность программ на уровне исполняемых файлов. Технология СОМ описывает, каким образом программные продукты в среде ОС Windows могут предоставлять доступ к своим функциям из внешних программ, написанных на различных языках программирования. Эти функции группируются в "объекты СОМ", доступные для использования из любых языков, поддерживающих технологию СОМ.

1.3 Особенности использования КОМПАС-МАСТЕР

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

В программах на Паскале и Си++ часто приходится пользоваться готовыми функциями и процедурами, хранящимися в библиотеках функций. Вместе с компиляторами распространяются как стандартные библиотеки функций (математические функции, функции ввода/вывода, контейнерные библиотеки и др.), так и библиотеки, разработанные для конкретной среды программирования (например, VCL для BorlandDelphi и C++ Builder). Большое количество библиотек разрабатываются различными фирмами и предлагаются как самостоятельные продукты.

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

При статической компоновке для использования библиотечных функций в Объектном Паскале требуется библиотечный модуль * .dcu. Этот модуль подключается к модулям разрабатываемой программы с помощью служебного слова uses. В результате подключения модуля можно пользоваться процедурами, функциями, классами и переменными, описанными в интерфейсной части подключенного модуля. Реализация этих процедур и функций содержится в файле * . dcu в двоичном виде. В Delphi при большом количестве связанных по смыслу модулей они могут объединяться в пакеты - файлы с расширением * . dcp, например, vcl50 . dcp.

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

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

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

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

В ОС Windows и во многих других современных операционных системах поддерживается модульность приложений на уровне операционной системы. Для этого есть несколько подходов. Один из них - применение динамически загружаемых библиотек (они называются также просто динамическими библиотеками, DLL) Приложе-ние может состоять не из единственного исполняемого файла, а из некоторого мно-жества таких файлов. Конечно, есть головной ЕХЕ-файл, запускаемый пользователем, а также может быть несколько файлов динамических библиотек (обычно с расширениями *.DLL). Эти библиотеки содержат функции, доступные для вызова из различных приложений. Загрузка и выгрузка DLL из оперативной памяти выполняется операционной системой без вмешательства приложения. Несколько приложений могут одновременно пользоваться одной и той же динамической библиотекой. Такое использование функций называется динамической компоновкой.

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

Для разработки программы в Delphi на Объектном Паскале с использованием функций DLL требуются 2 файла: (1) заголовочный модуль * .dcu с описанием библиотечных функций в интерфейсном разделе и с "заглушками" функций в разделе реализации и (2) файл * . dll с реализацией библиотечных функций. При сборке проекта компилятор оформляет вызов в соответствии с описанием функции, а компоновщик добавляет в исполняемый файл код функции-заглушки из раздела реализации заголовочного модуля. Функция-заглушка сама по себе сложных действий не выполняет, она организована таким образом, что либо загружает DLL и вызывает из нее соответствующую функцию, либо, если DLL загружена, вызывает из нее функцию сразу. Длительность вызова функции из DLL выполняется ненамного дольше вызова статически компонуемой функции. Библиотека DLL (файл * . dll) может присутствовать на ПК в единственном экземпляре - либо в каталоге WINDOWS\SYSTEM, если пользователей у этой DLL очень много, либо в каталоге основного пакета, если она используется только этим пакетом и его дополнительными модулями.

КОМПАС 9 включает в себя набор библиотек DLL, в которых реализована функциональная часть системы для работы с моделью чертежа (т.е. для создания и обработки структур данных, представляющих чертежи и другие графические документы), математические функции с реализацией различных алгоритмов вычислительной геометрии, различные функции для формирования и обработки чертежей. В исполняемом файле KOMPASW.EXE реализован пользовательский интерфейс системы, а по мере необходимости для выполнения команд пользователя вызываются необходимые функции из различных DLL. В состав КОМПАС-МАСТЕР входят заголовочные модули для основных DLL, входящих в состав КОМПАС 5. Общее количество импортируемых функций - около 300, их можно вызывать из программ на Си++ и Delphi. Описание этих функций содержится в файле помощи APPTOOLS . HLP.

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