Прикладні динамічні бібліотеки для системи Компас-3D

Міністерство освіти і науки, молоді та спорту України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій та управління Кафедра технічної кібернетики Дипломна робота зі спеціальності: Комп’ютеризовані та робото технічні системи Прикладні динамічні бібліотеки для системи Компас-3D

Кривий Ріг, 2012

Завдання на дипломну роботу

1. Тема роботи: Прикладні динамічні бібліотеки для системи Компас-3D затверджена наказом по інституту від «01 «листопада 2011 р. № 55С-01_____________

2. Термін здачі студентом закінченої роботи 03.05.12. _

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, вихідні масиви даних, програмна документація, наукові матеріали.

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка завдання; Прикладні конструкторські бібліотеки та інструменти для їх створення в системі Компас-3D; Дослідження методів створення динамічних бібліотек системи Компас-3D в середовищі Delphi; Опис функціональних можливостей та програмної реалізації прикладної бібліотеки; Економічне обґрунтування доцільності розробки програмного продукту; Охорона праці.

5. Перелік графічного матеріалу (з точними вказівками обов’язкових креслень)

1. Структура спеціалізованої САПР;

2. Схема створення прикладних динамічних бібліотек за допомогою API;

3. Приклад вікна стандартної бібліотеки системи Компас-3D;

4. Логіко-функціональна схема роботи користувача з бібліотекою;

5. Схема взаємодії бібліотеки з системою;

6. Діалогове вікно бібліотеки;

7. Вікно редагування значень модулів;

8. Загальний вигляд створеної моделі.

Календарний план

Анотація

Метою дипломної роботи є дослідження можливостей створення прикладних динамічних бібліотек для системи Компас-3D в середовищі Delphi з використанням функцій API-інтерфейсу. Результатом виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса.

Аннотация

Целью дипломной работы является исследование возможностей создания прикладных динамических библиотек для системы Компас-3D в среде Delphi с использованием функций API-интерфейса. Результатом выполнения дипломной работы является разработка элемента САПР, создающего по минимальному количеству начальных данных 3D-модель зубчатого колеса.

The summary

The purpose of the diploma work is research of the possibilities applied dynamic libraries creation for the system Компас-3D in the environment of Delphi with the use of API-interface functions.

The result of diploma work implementation is development of CAD-element, which creating the 3D-models of gear-wheels on the least of initial data.

Вступ

В умовах ринку САПР, що динамічно розвивається, знання основ тривимірного моделювання, параметризації, створення креслень в CAD-системі є необхідним для інженера-конструктора. У будь-якій проектно-конструкторській організації, на будь-якому підприємстві і вищому учбовому закладі в останні декілька років велика увага приділяється підготовці розрахунків, креслень і документації саме з використанням персональних комп’ютерів.

Технічний фахівець, окрім знань в своїй області, повинен відмінно володіти навиками автоматизованого проектування, легко, точно, а головне — швидко вирішувати поставлені задачі в графічному редакторі або розрахунковій системі. Без цього його підприємство, а значить, і він сам, приречено виявитися роздавленим жорсткою ринковою конкуренцією.

Серед безлічі інженерних систем для тривимірного моделювання, доступних сьогодні, насправді небагато таких, які при зручності інтерфейсу, легкості і простоті в освоєнні, володіли б широким функціоналом і при цьому мали б доступну ціну. Однією з таких систем є програма Компас-3D.

Найважливішою характеристикою будь-якої сучасної CAD-системи, разом з інструментальними засобами моделювання, є можливість автоматизації за допомогою різних допоміжних засобів процесів створення типових елементів і їх подальшого застосування. Це, по-перше, припускає наявність підсистем, що розширюють стандартні можливості програми, які дозволяють прискорити проектування власне об'єкту (агрегату, механізму, будівлі), а не окремо взятої деталі або складової. Найчастіше такі підсистеми є модулями (бібліотеками), що підключаються, функціонують тільки в середовищі «батьківського» графічного редактора і що дозволяють на основі його базових функцій швидко створювати і використовувати різні стандартні елементи.

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

Для розширення можливостей САПР Компас без зміни початкового коду в ній реалізований механізм бібліотек, що динамічно підключаються. Кожна бібліотека — це файл з розширенням rtw. Насправді це найзвичайніша dllбібліотека, у якої розширення dll замінене на rtw. Таку бібліотеку легко написати, наприклад в середовищі програмування Delphi. Вона підключатиметься до Компас так само, як і всі інші бібліотеки, і матиме повний доступ до API Компас для виконання різних побудов і маніпуляцій з графічними об'єктами і документами.

Бібліотека може мати свою екранну форму, що різко спрощує введення даних — можна використати будь-які компоненти Delphi, підключити бази даних і т.д.

В більшості випадків результатом роботи бібліотеки повинна бути побудова якого-небудь фрагмента креслення або 3D-моделі. Оскільки побудова виконується повністю програмним шляхом, на одержувані моделі не накладається ніяких обмежень.

Метою виконання дипломної роботи є розробка елементу САПР, що створює по мінімальній кількості початкових даних 3D-модель зубчатого колеса (як прямозубого, так і косозубого). Розроблена прикладна динамічна бібліотека реалізована у вигляді файлу формату RTW.

1. Постановка завдання

1.1 Найменування та галузь використання

Найменування розробки: прикладні динамічні бібліотеки для системи Компас-3D. Розроблена система динамічних бібліотек може бути використана для автоматизації конструкторської діяльності та пройшла практичну апробацію в умовах підприємства «КВМШ плюс».

1.2 Підстава для створення

Підставою для розробки є наказ № 55С-01 від 1 листопада 2011 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 03.11.11. Закінчення робіт: 03.05.12.

1.3 Характеристика розробленого програмного забезпечення

Система динамічних бібліотек, що призначена для автоматизації конструкторської діяльності, була створена за допомогою середовища прискореної розробки програмного забезпечення Delphi з використанням функцій API-інтерфейсу системи Компас-3D.

Завданням виконання дипломної роботи є розробка елементу САПР, що створює при мінімальній кількості початкових даних 3D-модель зубчатого колеса (як прямозубого, так і косозубого).

Розроблена прикладна динамічна бібліотека реалізована у вигляді файлу Gears3D.rtw. Дані про ряд модулів зубчастих коліс, що відповідають ГОСТ зберігаються у зовнішньому файлі бази даних — gears.mdb.

1.4 Мета й призначення

Метою дипломної роботи є дослідження можливостей створення прикладних динамічних бібліотек для системи Компас-3D в середовищі Delphi.

В результаті експериментальних досліджень була розроблена система, яка виконує наступні функції. Після виклику бібліотеки користувачем з’являється діалогове вікно, в якому він задає модуль (обирає із стандартного ряду), кількість зубів, ширину зубчатого вінця, а також кут нахилу зубів колеса (якщо колесо є косозубим). По введених параметрах бібліотека повинна згенерувати тривимірну модель колеса.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· робота в середовищі операційних систем Windows 2000/XP/Vista/7;

· простота та зрозумілість інтерфейсу користувача.

Мінімальні вимоги до апаратного забезпечення:

· IBM-сумісний комп’ютер, не нижче Pentium IІІ, RAM-512Mb, SVGA-800*600*16bit;

· вільний простір на жорсткому диску не менш 500 Мб;

· монітор, клавіатура, маніпулятор типу «миша».

Додаткове програмне забезпечення — встановлення системи Компас-3D версії від 10 та вище.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· технічне завдання на реалізацію проекту;

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. Прикладні конструкторські бібліотеки та інструменти для їх створення в системі компас-3D

2.1 Призначення і основні характеристики систем автоматизації конструкторської документації

Сучасний рівень програмних і технічних засобів електронної обчислювальної техніки дозволяє перейти до нових інформаційних комп’ютерних технологій, створювати системи автоматизації розробки і виконання конструкторської документації (АКД), що задовольняють стандартам ЄСКД як за якістю виконання документів, так і по дотриманню вимог стандартів. На комп’ютері можуть бути створені конструкторські документи (креслення і схеми) як з використанням, наприклад графічних примітивів типу відрізка, кола, полілінії та ін., так і фрагментів раніше створених конструктивних елементів: графічних зображень (ГЗ) стандартних виробів, типових і уніфікованих конструкцій, їх частин і т.д. При цьому моделі вищезгаданих фрагментів можуть бути параметрично заданими. За допомогою завдання різних значень параметрів конструктор може змінити їх розміри і геометричну форму, забезпечуючи багатоваріантність ГЗ і відповідно креслень і схем. При такому підході до конструювання використання комп’ютерної графіки не усуває креслення як основу конструювання, комп’ютер використовується як «електронний кульман», що полегшує працю конструктора. Такий підхід базується на двовимірному геометричному моделюванні.

При розробці КД в цьому випадку ефективність застосування комп’ютерної графіки забезпечується наступними її можливостями:

· наявністю у всіх графічних редакторах засобів перетворень: повороту, перенесення, масштабування, побудови дзеркального зображення і др.;

· використання готових фрагментів креслень з бібліотеки: конструктивних і геометричних елементів, уніфікованих і типових конструкцій, стандартних виробів;

· формуванням креслень з використанням об'єктно-орієнтованих інтерфейсів користувача, ведення діалогу з комп’ютером в звичних для конструктора (у вигляді піктограм) термінах і із звичними для нього об'єктами ГЗ;

· наявністю пакетів програм опису типових моделей-представників креслень об'єктів, коли процес створення конкретного креслення виробу полягає в маніпулюванні розмірами, представленими у вигляді параметрів;

· отриманням креслень високої якості, оформлених за стандартами ЄСКД (формується на етапі конструювання) шляхом виводу на графічні пристрої, принтери і інші пристрої.

Рис. 2.1 Структура системи АКД, заснованої на двовимірному геометричному моделюванні

Для використання цих можливостей застосовуються системи-надбудови над базовою графічною системою (наприклад, над AutoCAD), що містять спеціалізовані для конкретного виробу моделі необхідних фрагментів ГЗ, інтерфейсів користувача, що є об'єктно-орієнтованими «падаючими» і піктографічними меню і відповідними бібліотеками слайду.

Існують і інші підходи до автоматизації конструкторської діяльності, наприклад на основі просторового геометричного моделювання, коли формується просторова модель геометричного об'єкту (ГО), що є наочнішим способом представлення оригіналу і могутнішим і зручнішим інструментом для вирішення геометричних завдань (рис 2.2). Креслення тут грає допоміжну роль, а методи його створення засновані на методах комп’ютерної графіки, методах відображення просторової моделі (у Компас-3D — тривимірне моделювання). При першому підході - традиційному процесі конструювання — обмін інформацією здійснюється на основі конструкторської, нормативно-довідкової і технологічної документації; при другому — на основі внутрішньо-машинного представлення ГО, загальної бази даних, що сприяє ефективному функціонуванню програмного забезпечення систем автоматизованого проектування (САПР) конкретного виробу.

Рис. 2.2 Структура системи АКД, заснованої на використанні просторової моделі геометричного об'єкту

2.2 Методи створення графічних зображень і геометричних об'єктів

Формування моделі параметрично заданого ГО забезпечується з використанням програм створення моделі або об'єктно-орієнтованих систем-надбудов над САПР. Методи створення моделей, параметрично керованих ГО, характеризуються більшими витратами на формування моделі. Щоб скоротити ці витрати, при описі деяких груп технічних об'єктів можна користуватися одним із двох принципово різних методів: варіантним або генерируючим.

Варіантний метод заснований на тому, що для певного класу виробів виявляється модель-представник, за допомогою якої отримують всі геометричні форми цього класу виробів. Представника класу виробів називають типізованою, або комплексною моделлю, а отримані з неї форми — варіантами виконань. Виконання виробу визначається заданими параметрами, обнулення яких приводить до виключення складових елементів ГО. У простому випадку змінюються тільки розміри, а конструкція окремих варіантів сімейства виробів залишається незмінною. Опис ГО, заданого параметрами, лежить в основі багатоваріантного конструювання. Витрати на опис типової моделі великі в порівнянні з витратами на отримання варіантів, тому багато систем використовують принцип вкладеності моделей: один раз описані типові моделі використовуються для опису інших типових моделей як макрокоманди.

Генеруючий метод заснований на розділенні ГО на конструктивні і геометричні елементи і створенні нових ГО з наявних елементів за допомогою вибору різних їх поєднань. На рис. 2.3 приведений приклад розділення деталі на елементи. Системи АКД, що працюють по генеруючому методу, володіють високою гнучкістю і ефективні, оскільки досвід показує, що більшість конструкторських розробок створюються шляхом поєднання елементів, що не використалося, раніше відомих, як за принципом функціонування, так і по виконанню.

2.3 Структура й основні принципи побудови систем автоматизації конструкторської документації

Система АКД виконує введення, зберігання, обробку і виведення графічної інформації у вигляді конструкторських документів. Для реалізації системи необхідні: документи, що регламентують роботу системи АКД; початкова інформація для формування інформаційної бази; інформаційна база, що містить моделі ГО, ГЗ, елементи оформлення креслення по ЄСКД; технічні і програмні засоби створення ГО і ГЗ і їх виводу; інтерфейс користувача у вигляді діалогу з комп’ютером.

Рис. 2.3 Структурна схема елементів геометричного об'єкту Всі перераховані складові утворюють методичне, інформаційне, технічне, програмне і організаційне забезпечення системи АКД (рис. 2.4). Основними принципами побудови системи АКД є:

· мобільність — адаптуються системи АКД до різних САПР. Шлях до цього — використання поширених базових графічних систем (наприклад, AutoCAD) і мов програмування;

· інформаційна єдність всіх частин АКД і САПР, яке передбачає єдність бази даних для різних призначень (скажімо, користування моделі ГО і ГЗ як для формування креслень, так і для розрахунків і виготовлення виробу);

· інваріантність — максимальна незалежність складових частин і системи АКД в цілому по відношенню до об'єктно-орієнтованих систем АКД і САПР. Наприклад, система електронних пристроїв може бути використана як графічна підсистема в системі управління робототехнічним комплексом і як графічна підсистема в системі управління контрольно-вимірювальним пристроєм;

· можливість розширення системи АКД шляхом доповнення нових складових частин й розвиток старих.

2.4 Основи розробки спеціалізованих САПР

Більшість вживаних в промисловості тривимірних САПР можуть бути використані як основа для побудови спеціалізованої САПР, що вирішує завдання розрахунку і проектування конкретного класу виробів. При цьому необхідно об'єднати розрахунковий модуль, що визначає розмірні і інші параметри проектованого об'єкту з тривимірним геометричним ядром, що вже є в САПР.

Рис. 2.4 Методичне, інформаційне, технічне, програмне та організаційне забезпечення системи АКД Рис. 2.5 Структура спеціалізованої САПР Для цього спочатку створюється параметрична збірка проектованого механізму, в якій ряд розмірів винесений в змінні моделі. Розрахунковий модуль (це зовнішній exe-файл або що підключається до САПР dll-бібліотека, написані, наприклад, на Delphi) може розрахувати необхідні значення змінних моделі і автоматично змінити їх, внаслідок чого буде одержаний новий варіант 3D збірки.

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

Очевидно, головну складність представляє не стільки виконання розрахунків, скільки організація взаємодії розрахункового модуля і САПР. Історично склалося, що більшість сучасних САПР не підтримують СОМ-технологію, що додатково ускладнює управління ними із зовнішньої програми. Як правило, таке управління здійснюється за допомогою технології API (Application Programming Interface). API-технологія надає програмістові набір процедур і функцій для управління САПР, але не дає прямого доступу до властивостей і методів об'єктів всередині САПР, що робить код програми декілька громіздкішим і менш зрозумілішим.

Для розширення можливостей САПР Компас без зміни початкового коду в ній реалізований механізм бібліотек, що динамічно підключаються. Кожна бібліотека — це файл з розширенням .rtw. Насправді це найзвичайніша dll-бібліотека, у якої розширення dll замінене на rtw. Таку бібліотеку легко написати, наприклад, на Delphi. Вона підключатиметься до Компас так само, як і всі інші бібліотеки, і матиме повний доступ до API Компас для виконання різних побудов і маніпуляцій з графічними об'єктами і документами. Бібліотека може мати свою екранну форму, що різко зпрощує введення даних — можна використати будь-які компоненти Delphi, підключити бази даних і т.д.

В більшості випадків результатом роботи бібліотеки повинна бути побудова якого-небудь фрагмента креслення або 3D моделі. Оскільки побудова виконується повністю програмним шляхом, на одержувані моделі не накладається ніяких обмежень — наприклад, можна створити бібліотеку, що будує зубчате колесо з довільним числом зубів і т.д.

Бібліотеки розділяються по типу документа, в якому вони проводять побудови. Для запуску 3D бібліотеки необхідно, щоб поточним документом була 3D модель або збірка, а для 2D бібліотеки — креслення або фрагмент.

Як вже наголошувалося, жоден набір бібліотек до графічної системи не може охопити всю безліч різних напрямів і галузей промисловості і повною мірою задовольнити вимоги всіх категорій користувачів. Спектр завдань конструкторсько-технологічної підготовки виробництва став настільки широким, що рішення деяких з них як стандартними, так і прикладними засобами, наданими компанією — розробником ПО, може віднімати дуже багато часу і бути нераціональним, а в окремих випадках навіть неможливим.

Величезний перелік областей застосування САПР — перша причина, по якій будь-яка з сучасних CAD-систем повинна бути максимально відкритою і обов’язково містити інструменти для створення пакету призначених для користувача бібліотек. Другою причиною є орієнтація на замовника. Якщо, наприклад, переважна більшість підприємств, що використовують ту або іншу систему, працюють в машинобудуванні, а одиниці — у області виробництва медичного устаткування, то розробники прикладних бібліотек вимушені підстроюватися під першу категорію. Але для замовників Компас жодних проблем не виникне — вони можуть створити бібліотеки самостійно.

Перерахуємо основні способи створення бібліотек:

· створення бібліотеки фрагментів (ескізів) або моделей на основі базових можливостей системи КОМПАС-3D;

· створення бібліотеки шаблонів за допомогою Менеджера шаблонів;

· використання спеціального макросередовища Компас-Макро для підготовки призначеного для користувача додатку;

· застосування інструментальних засобів Компас-Майстер, тобто власне написання (програмування) бібліотек.

Який з цих варіантів вибрати? Все залежить від поставлених цілей і від нашого уявлення про майбутню бібліотеку: який вона повинна бути, що робитиме (створювати, редагувати, виконувати які-небудь інші дії), наскільки могутніми і гнучкими повинні бути її функції. Велике значення має і рівень підготовки розробника. Прості бібліотеки не вимагають майже ніяких спеціальних знань, але і можливостей надають небагато. Створення складніших модулів неможливе без деяких навиків і досвіду (іноді із зовсім іншої наочної області, зокрема з програмування), при цьому чим складніше проектована бібліотека, тим більше глибокі знання необхідні. Під складністю бібліотеки тут слід розуміти рівень автоматизації тих конструкторських рішень, які будуть реалізовані в створюваному додатку. Але не варто думати, що найбільш автоматизована бібліотека завжди є кращим рішенням. Занадто автоматизовані додатки не залишають місця ініціативі і не дають можливості варіювати рішення.

2.5 Бібліотеки фрагментів і моделей

Для створення бібліотек цього типа нам не буде потрібно ніяких спеціальних навиків, окрім уміння працювати в Компас-Графік або в Компас-3D. За допомогою таких бібліотек кожен проектувальник може систематизувати свій набір найбільш часто використовуваних елементів, щоб полегшити доступ до них при розробці нових креслень або моделей.

Створити свою бібліотеку фрагментів зовсім нескладно. Для цього у вікні Менеджера бібліотек потрібно скористатися командою контекстного меню Додати опис > Бібліотеки документів. У діалоговому вікні відкриття бібліотеки, що з’явилося, слід вибрати тип файлу: Компас-бібліотеки фрагментів (*.lfr), якщо ми створюємо сховище для креслень або ескізів, або Компас-бібліотеки моделей (*.l3d) — для наповнення майбутньої бібліотеки 3D-моделями. У результаті у вікні Менеджера бібліотек повинна з’явитися наша бібліотека, поки що порожня. Після запуску до неї можна додавати фрагменти і моделі за допомогою команд контекстного меню.

Головна перевага бібліотек фрагментів — простота їх створення і застосування. Великим плюсом таких додатків є також те, що при появі нових версій Компас не потрібно підганяти або змінювати їх структуру під тільки що випущений реліз. Досить завантажити старий файл бібліотеки в Менеджер бібліотек, і можемо не сумніватися — все працюватиме.

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

Ширшими можливостями, в порівнянні з бібліотеками фрагментів, володіють бібліотеки шаблонів Компас-3D.

2.6 Створення бібліотек шаблонів

Бібліотека шаблонів це прикладна бібліотека, що складається з базового креслення, що параметризується, або тривимірної моделі, таблиці змінних, набраної відповідно до деяких правил в табличному редакторі MS Excel, і схеми документа Компас-3D або рисунка, що містить імена змінних. Бібліотека є файлом з розширенням *.tlm, за допомогою якого змінним фрагмента, що параметризується, або деталі ставляться у відповідність значення, набрані в Excel-таблиці. Для створення бібліотек шаблонів призначений спеціальний додаток під назвою Менеджер шаблонів.

Розробку шаблону слід починати із створення його прототипу (фрагмента або деталі), користуючись стандартними засобами Компас-Графік або Компас-3D. Потім необхідно параметризувати викреслений фрагмент або ескізи моделі і призначити зовнішніми всі змінні, які ми плануємо вводити (набирати) в таблиці Excel. Наступним кроком є створення таблиці значень. Така таблиця формується в редакторі Excel і включає назви зовнішніх змінних, що параметризуються, прапорці видимості колонок значень в Менеджері шаблонів, конкретні значення або їх інтервал для кожної змінної та інше. Формування ще однієї складової частини шаблону схеми параметрів не викличе особливих утруднень. Схемою може бути будь-який графічний файл системи Компас-3D або файл-рисунок у форматі *.bmp, *.gif або *.jpg.

Коли всі три розглянутих вище компоненти підготовлені, їх потрібно зібрати в єдиний додаток. Для цього, користуючись командою «Новая библиотека», слід вказати назву майбутньої бібліотеки і директорію, де вона буде розміщена. Далі необхідно оформити внутрішню деревовидну структуру бібліотеки, тобто розділи і підрозділи, в яких знаходитимуться підготовлені нами шаблони.

Рис. 2.6 Приклад вікна стандартної бібліотеки системи Компас-3D

Завершує етап підготовки бібліотеки наповнення розділів відповідними шаблонами, для чого слід скористатися командою «Создать шаблон». Після її виклику з’явиться невелике віконце, в якому для кожного шаблону потрібно ввести ім'я, вказати файл з фрагментом, що параметризується, або моделлю, файл таблиці параметрів Excel і заставку (необов'язково). Після закінчення всіх цих дій бібліотека шаблонів повністю готова до роботи. Можна завантажувати певний шаблон, вводити значення змінних і вставляти готову деталь або фрагмент в документ.

Які ж істотні відмінності бібліотек шаблонів від бібліотек фрагментів? Перш за все це можливість вставки в документ не всього фрагмента, а окремих його шарів, а також наявність ряду дискретних значень для змінної, що виключає введення або вибір користувачем помилкових значень. Крім того, змінні шаблонів можуть бути різних типів, зокрема логічних і строкових, а в розмірних написах фрагмента-заготівки нескладно резервувати змінні для текстових підстановок (вони повинні виділятися з обох боків знаком #). Головною ж перевагою бібліотек шаблонів є те, що при використанні шаблону не доводиться змінювати змінні, що уручну параметризуються, як це робилося б при вставці фрагмента або моделі з бібліотеки фрагментів. При вставці об'єкту в активний документ Менеджер шаблонів сам поклопочеться про те, щоб підставити потрібні значення з вибраного користувачем ряду.

Безумовно, на розробку шаблонів йде більше часу і при цьому одних тільки навиків роботи з Компас вже буде недостатньо доведеться вивчити принципи роботи Менеджера бібліотек. Зате застосування шаблонів дає можливість достатньо гнучко автоматизувати створення типових елементів і разом з тим не забороняє динамічно управляти процесом формування бібліотечного елементу.

2.7 Створення прикладних бібліотек за допомогою Компас-Макро

Компас-Макро — це інтегрована в систему Компас-3D середовище розробки конструкторських додатків на основі мови програмування Python. Чому за основу вибраний саме Python? По-перше, Python розповсюджується безкоштовно і, як наслідок, не накладає ніяких обмежень на використання і розповсюдження написаних на ньому програм. По-друге, сьогодні Python — одна з найпростіших і зрозуміліших мов програмування, проте при всій своїй простоті він мало в чому поступається таким «китам» об'єктно-орієнтованого програмування, як C++ і Object Pascal (Delphi).

За своєю суттю Компас-Макро є звичайною бібліотекою, що підключається до Компас, тільки з великими можливостями. При створенні додатків в Компас-Макро можна користуватися як функціями Компас-Майстер, так і спеціальними функціями макросередовища, що полегшують розробку прикладних бібліотек. Серед спеціальних функцій Компас-Макро слід зазначити функції постановки кутових, лінійних і радіальних розмірів, функцію вставки в документ фрагмента, малювання лінії-винесення та ін. Синтаксис перерахованих методів значно простіший за їх аналоги, реалізовані Компас-Майстер (наприклад, замість виклику олнієї функції створення лінійного розміру в Компас-Макро при роботі з API-функціями середовища Компас-Майстер доводиться оголошувати і ініціалізувати цілих три інтерфейси).

2.8 Інструментальні засоби розробки бібліотек

Компас-Майстер — це дуже могутні інструментальні засоби розробки додатків (бібліотек) необмеженої складності, що функціонують в середовищі Компас-3D. З допомогою Компас-Майстер прикладний програміст дістає доступ до всіх без виключення функцій системи.

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

Доступ до внутрішніх функцій Компас-Графік і Компас-3D забезпечується двома шляхами:

· через експортні функції, оформлені у вигляді dll-модулів, які розробник підключає до своєї програми, при створенні плоских креслень; через використання об'єктів СОМ при програмному формуванні твердотільних моделей;

· за допомогою технології Automation (Автоматизації), реалізованої через API (Application Programming Interface — програмний інтерфейс додатку) системи Компас. Управління і взаємодія з системою при цьому оформлене через інтерфейси IDispatch.

Використання інтерфейсів IDispatch можливо в будь-якому з найбільш поширених сьогодні середовищ програмування (Visual C++, Delphi, C++Builder, Visual Basic).

Інтеграція з такими могутніми програмними пакетами дозволяє, крім застосування графічного інструментарію Компас, використовувати в створюваних модулях всі переваги сучасного об'єктно-орієнтованого програмування.

Рис. 2.7 Схема створення прикладних динамічних бібліотек за допомогою API

3. Дослідження методів створення динамічних бібліотек системи компас-3d в середовищі Delphi

3.1 Технологія COM, автоматизація і інтерфейси IDispatch

З початку 1990 років корпорація Microsoft розробляє технологію, що дозволяє створювати гнучкі модульні програми так, щоб окремі модулі можна було писати на різних мовах програмування, але щоб при цьому забезпечувалася їх повна взаємозамінюваність при використанні в різних програмних пакетах. На сьогодні ця технологія повністю сформована і називається COM (Component Object Model, модель компонентних об'єктів).

Технологія COM описує методологію реалізації компонентів програмного забезпечення: об'єктів, які можуть повторно використовуватися, можуть бути неодноразово підключені до різних додатків. Повторне використання компонентів стало логічним слідством еволюції об'єктно-орієнтованого програмування і одержало назву компонентно-орієнтованого підходу. Концепція компонентно-орієнтованого програмування передбачає повне відділення внутрішніх функцій компоненту від функцій доступу до нього ззовні. Тепер, звертаючись до компоненту, необов’язково знати його внутрішній устрій, для цього досить лише мати інформацію про те, як викликати його функції. Іншими словами, необхідно знати, як взаємодіяти з компонентом і який у нього інтерфейс. Така функціональність в COM досягається за рахунок підтримки одного або декількох інтерфейсів, які використовуються іншими програмами для доступу до внутрішніх членів і методів компоненту.

Таким чином, інтерфейс — це те, що розміщене між двома об'єктами і забезпечує зв’язок між ними. Інтерфейс-орієнтоване програмування є технологією розробки програмного забезпечення, жорстко націленою на використання інтерфейсів. Інтерфейс є свого роду сполучною ланкою, наданою програмі, що управляє, для доступу до COM-об'єкту.

Об'єкт COM — конкретний екземпляр COM-класу, завершений об'єкт з власними членами даних і методами, який може легко вбудовуватися в програми або розповсюджуватися як окремий програмний продукт. COM-об'єкт є або DLL-бібліотекою або ЕХЕ-програмою для Wіndows, які можна створювати в будь-якому середовищі програмування, здатному підтримувати потрібний формат уявлення. COM-об'єкт може мати багато функцій, доступ до яких відбувається через його інтерфейси. Будь-який COM-об'єкт повинен мати принаймні один інтерфейс ІUnknown, хоча насправді має їх значно більше.

Свого часу розробники технології COM дійшли висновку, що повинен існувати деякий механізм запиту інтерфейсу для визначення його можливостей. Цей запит також повинен існувати для того, щоб забезпечити оновлення клієнтськими програмами значення лічильника посилань на даний інтерфейс. Даний лічильник визначає, як довго інтерфейс залишатиметься доступним, перш ніж він буде видалений з пам’яті.

Саме для цієї мети існує спеціальний інтерфейс, який називається ІUnknown. Він має настільки важливе значення, що основний принцип специфікації СОМ вимагає, щоб всі об'єкти СОМ окрім своїх спеціалізованих інтерфейсів підтримували інтерфейс ІUnknown. Причому кожен визначений для об'єкту інтерфейс повинен походити від ІUnknown або від інтерфейсу, який в свою чергу сам походить від ІUnknown. Даний принцип називається спадкоємством інтерфейсів.

У інтерфейсі ІUnknown реалізовано лише три методи: Queryіnterface (), AddRef () і Release (). Метод Queryіnterface () визначає, чи є одержаний інтерфейс потрібним. Методи AddRef () і Release () використовуються для підрахунку посилань на даний інтерфейс при його застосуванні багатьма програмами. Перед початком використання COM-об'єкту клієнт викликає метод СОМ, тим самим збільшуючи кількість посилань на інтерфейс на одиницю. Після закінчення роботи з інтерфейсом клієнт повинен викликати функцію Release (), щоб зменшити кількість посилань на одиницю. Коли лічильник посилань для всіх інтерфейсів стане рівним нулю, означає, об'єкт більше ніким не використовується і його можна вивантажувати з пам’яті.

На сьогодні технологія СОМ використовується практично у всіх серйозних програмах. Припустимо, що користувачу в якому-небудь звіті потрібно помістити електронну таблицю з розрахунками, які посилаються на певні параметри в тексті. Щоб виконати будь-які обчислення без використання технології СОМ, довелося б постійно перемикатися між двома програмами (Word і Excel), а інформацію копіювати (вирізувати і вставляти). За допомогою технології COM можна застосовувати функції електронної таблиці прямо в текстовому редакторі і автоматично форматувати отриманий результат. Можливість реалізувати операції такого роду називається автоматизацією.

Мета автоматизації полягає в тому, щоб дати можливість програмі надавати у використання сервіси, які в ній присутні. Основною особливістю автоматизації є можливість комбінувати функції різних спеціалізованих додатків в одному модулі. СОМ дає можливість програмам передавати свою інформацію в інші додатки і модулі.

Якби кожна програма або додаток-сценарій могли б підтримувати покажчики і процедуру обходу покажчиків, то проблема була б вирішена. Проте в деяких мовах програмування є певна трудність з процедурою обходу таблиці покажчиків. Деякі з них, наприклад Vіsual Basіc, не підтримують покажчики безпосередньо. Для вирішення цієї проблеми був розроблений спеціальний інтерфейс, який дозволяє будь-яким мовам програмування, зокрема таким, як Vіsual Basіc, звертатися до методів COM-компонентів. Цей інтерфейс одержав назву ІDіspatch.

Отже, будь-яка програма, яка надає свої можливості іншим додаткам (підтримує автоматизацію), може робити це через інтерфейс ІDіspatch. Інтерфейс ІDіspatch походить від базового інтерфейсу моделі СОМ ІUnknown, проте, на відміну від інших COM-інтерфейсів ІDіspatch містить метод Іnvoke (). Його можна використовувати для дійсного виконання методів, які підтримує COM-об'єкт. Клієнт може виконати будь-який метод COM-об'єкту, викликавши метод Іnvoke () інтерфейсу ІDіspatch. Цей механізм працює за допомогою інтерфейсу диспетчеризації. Він визначає методи, які будуть доступні завдяки використанню методу Іnvoke () інтерфейсу ІDіspatch.

Інтерфейси IDispatch можна застосовувати в будь-якому з найбільш поширених сьогодні середовищ програмування (Visual C++ Studio, Borland Delphi, Borland C++Builder, Visual Basic). Саме цим Компас-Майстер вигідно відрізняється від Компас-Макро: нам не доведеться вивчати малознайому мову програмування, ми можемо створювати свої додатки в тому середовищі, до якого звикли.

3.2 Склад СОМ-додатку

При створенні СОМ-додатку необхідно забезпечити наступне:

· СОМ-інтерфейс;

· СОМ-сервер;

· СОМ-клієнт.

Розглянемо ці три складові СОМ-додатку.

3.2.1 СОМ — інтерфейс

Клієнти СОМ зв’язуються з об'єктами за допомогою СОМ-інтерфейсів. Інтерфейси — це групи логічно або семантично зв’язаних процедур, які забезпечують зв’язок між постачальником послуги (сервером) і його клієнтом. На рис. 3.1 схематично зображено стандартний СОМ-інтерфейс.

Рис. 3.1 СОМ-інтерфейс

Ключовими аспектами СОМ-інтерфейсів є:

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

· За взаємною домовленістю, всі імена інтерфейсів починаються з букви I, наприклад IРersist, IМalloc.

· Кожен інтерфейс гарантовано має свій унікальний ідентифікатор, який називається глобальним унікальним ідентифікатором (Globally Unique Identifier, GUID). Унікальні ідентифікатори інтерфейсів називають ідентифікаторами інтерфейсів (Interface Identifiers, IIDs). Ці ідентифікатори забезпечують усунення конфліктів імен різних версій додатку або різних додатків.

· Інтерфеси не залежать від мови програмування. Для реалізації СОМ-інтерфейсу можна скористатися будь-якою мовою програмування. Мова програмування повинна підтримувати структуру покажчиків, а також мати можливість виклику функції за допомогою покажчика явно або неявно.

· Інтерфейси не є самостійними об'єктами, вони лише забезпечують доступ до об'єктів. Таким чином, клієнти не можуть безпосередньо звертатися до даних, доступ здійснюється за допомогою покажчиків інтерфейсів.

· Всі інтерфейси завжди є потомками базового інтерфейсу IUnknown.

Базовий СОМ-інтерфейс IUnknown

Базовий інтерфейс IUnknown забезпечує механізм обліку посилань (лічильник посилань на СОМ-об'єкт). При передачі покажчика на інтерфейс виконується метод інтерфейсу ІUnknown AddRef. Після закінчення роботи з інтерфейсом додаток-клієнт викликає метод Release, який зменшує лічильник посилань.

Під час виклику методу Querylnterface інтерфейсу ІUnknown в метод передається параметр IID, який має тип TGUID, тобто ідентифікатор інтерфейсу. Параметр методу out повертає або посилання на інтерфейс, що запрошувався, або значення NH.

Покажчики СОМ-інтерфейсу Покажчик інтерфейсу — це 32-бітовий покажчик на екземпляр об'єкту, який є, у свою чергу, покажчиком на реалізацію кожного методу інтерфейсу. Реалізація методів доступна через масив покажчиків на ці методи, який називається vtable. Використання масиву vtable схоже на механізм підтримки віртуальних функцій в Object Pascal.

Рис. 3.2 Схема роботи покажчика СОМ-інтерфейсу

3.2.2 СОМ-сервери

СОМ-сервер є додатком або бібліотекою, яка надає послуги додатку-клієнту або бібліотеці. СОМ-сервер містить один або більше СОМ-об'єктів, де СОМ-об'єкти виступають як набори властивостей, методів і інтерфейсів.

Клієнти не знають як СОМ-об'єкт виконує свої дії. СОМ-об'єкт надає свої послуги за допомогою інтерфейсів. Крім того, додатку-клієнту не потрібно знати, де знаходиться СОМ-об'єкт. Технологія СОМ забезпечує прозорий доступ незалежно від місцезнаходження СОМ-об'єкту.

Коли клієнт запрошує послугу від СОМ-об'єкту, він передає СОМ-об'єкту ідентифікатор класу (CLSID). CLSID — всього лише GUID, який застосовується при зверненні до СОМ-об'єкту. Після передачі CLSID, СОМ-сервер повинен забезпечити так звану фабрику класу, яка створює екземпляри СОМ-об'єктів.

СОМ-сервер повинен виконувати наступне:

· реєструвати дані в системному реєстрі Windows для зв’язування модуля серверу з ідентифікатором класу (CLSID);

· надавати фабрику СОМ-класу, що створює екземпляри СОМ-об'єктів;

· забезпечувати механізм, який вивантажує з пам’яті сервери СОМ, які у даний момент часу не надають послуг клієнтам.

Фабрика класу СОМ-об'єкти є екземплярами СoСlass. CoСlass — це клас, що підтримує один або більш інтерфейсів. СОМ-об'єкти можуть надавати тільки ті послуги, які визначені в інтерфейсах СoСlass. Екземпляри CoСlass створюються за допомогою спеціального типу об'єкта, який називається фабрика класу.

Фабрика класу — це спеціальний СОМ-об'єкт, який підтримує інтерфейс IСlassFactory і відповідає за створення екземплярів того класу, з яким асоційована дана фабрика класу.

Інтерфейс IСlassFactory має два методи:

· Createlnstance, який створює екземпляр СОМ-об'єкта, асоційованої фабрики класу

· LockServe, який застосовується для зберігання СОМ-сервера в пам’яті. Якщо параметр метода fLock має значення true, то лічильник посилань сервера збільшується, в іншому випадку — зменшується. Коли лічильник досягає значення 0, сервер вивантажується з пам’яті.

Кожного разу, коли послуги СОМ-об'єкта запрошуються клієнтом, фабрика класу створює і реєструє екземпляр об'єкту для конкретного користувача. Якщо послуга того ж СОМ-об'єкту запрошує інший клієнт, фабрика класу створює другий екземпляр об'єкту для обслуговування другого клієнта. СoСlass повинен мати фабрику класу і ідентифікатор класу CLSID. Використання CLSID для СoClass має на увазі, що вони можуть бути відкоректовані кожного разу, коли в клас вводяться нові інтерфейси. Таким чином, на відміну від DLL, нові інтерфейси можуть змінювати або додавати методи, не впливаючи на старі версії.

Локальні і віддалені сервери З використанням СОМ клієнт не повинен турбуватися про те, де розташовується об'єкт, він просто робить виклик інтерфейсу даного об'єкту. Технологія СОМ забезпечує всі необхідні кроки для того, щоб зробити цей виклик. Кроки можуть відрізнятися, залежно від місцезнаходження об'єкту. Об'єкт може знаходитися в тому ж процесі, де і клієнт, в іншому процесі на тому ж комп’ютері, де розташований клієнт, або на іншому комп’ютері в мережі. Залежно від цього застосовуються різні типи серверів:

· внутрішній сервер (In-process server);

· локальний сервер (Local server);

· видалений сервер (Remote server).

Внутрішній сервер — це бібліотека DLL, яка запущена в одному процесі разом з клієнтом. Додаток-клієнт зв’язується з сервером усередині процесу за допомогою прямих викликів СОМ-інтерфейсу. На рис. 3.3. представлена схема взаємодії клієнта з внутрішнім сервером.

Рис. 3.3 Схема взаємодії клієнта с внутрішнім сервером Локальний сервер — це додаток ЕХЕ, який запущено в іншому процесі, але на одному комп’ютері разом з клієнтом. Наприклад, лист електронної таблиці Microsoft Excel пов’язаний з документом Microsoft Word. При цьому два різні додатки працюють на одному комп’ютері. Локальні сервери використовують СОМ для з'єднання з клієнтом.

Коли клієнт і сервер знаходяться в різних додатках, а також, коли вони знаходяться на різних комп’ютерах в мережі, СОМ використовує внутрішній проксі для реалізації процедури видаленого виклику. Проксі розташовується в одному процесі разом з клієнтом, тому, з погляду клієнта, виклик інтерфейсів здійснюється так само, як і у разі, коли клієнт і сервер знаходяться усередині одного процесу. Задача проксі полягає в тому, щоб перехоплювати виклики клієнта і перенаправляти їх туди, де запущено сервер. Механізм, який дозволяє клієнту діставати доступ до об'єктів, розташованих в іншому адресному просторі або на іншому комп’ютері, називається маршалінгом (marshaling).

Функції маршалінга:

· приймати покажчик інтерфейсу з процесу серверу і робити покажчик проксі в процесі клієнта доступним;

· передавати аргументи викликів інтерфейсу таким чином, ніби вони відбулися від клієнта і розміщувати аргументи в процесс видаленого об'єкту.

Для будь-якого виклику інтерфейсу клієнт поміщає аргументи в стек, викликає необхідну функцію СОМ-об'єкту через покажчик інтерфейсу. Якщо виклик об'єкту відбувся не усередині процесу, виклик проходить через проксі. Проксі пакує аргументи в пакет маршалінга і передає структуру, що вийшла, видаленому об'єкту. Заглушка об'єкту розпаковує пакет маршалінга, вибирає аргументи із стека і викликає необхідну функцію СОМ-об'єкту.

Таким чином, маршалінг — це процес пакування інформації, а демаршалінг — процес розпакування інформації.

Тип маршалінга залежить від об'єктної приналежності СОМ. Об'єкти можуть використовувати стандартний механізм маршалінга, що надається інтерфейсом IDispatch. Стандартний маршалінг дозволяє встановлювати зв’язок за допомогою стандартного системного видаленого виклику процедури (Remote Procedure Call, RPC).

На рис. 3.4 зображена схема, що показує методику взаємодії клієнта і серверу у разі, коли додатки працюють на одному комп’ютері, але в різних процесах.

Рис. 3.4 Схема взаємодії клієнта з сервером в різних процесах на одному комп’ютері

Видалений сервер — це бібліотека DLL або інший додаток, запущений на іншому комп’ютері. Тобто клієнт і сервер працюють на різних комп’ютерах в мережі. Видалений сервер використовує розподілені СОМ-інтерфейси (Distributed COM, DCOM) для зв’язку з клієнтом.

Видалений сервер працює також з допомогою проксі. Відмінність в роботі між локальним і видаленим сервером полягає в типі межпроцесного зв’язку, що використовується. У разі локального серверу — це СОМ, а у разі видаленого серверу — DCOM. Схема взаємодії клієнта і видаленого сервера показана на рис. 3.5.

Рис. 3.5 Схема взаємодії клієнта з сервером на різних комп’ютерах

3.2.3 СОМ-клієнти

Дуже важливим при розробці СОМ-додатків є створення додатків, так званих СОМ-клієнтів, що можуть запрошувати інтерфейси об'єктів, щоб визначити ті послуги, які може надати СОМ-об'єкт.

Типовим СОМ-клієнтом є диспетчер автоматизації (Automation Controller). Диспетчер автоматизації - це частина додатка, яка «знає» який тип інформації необхідний йому від різних об'єктів сервера, і вона запрошує дану інформацію у міру потреби.

3.3 Базові інтерфейси API системи Компас

Взаємодія зовнішнього додатку або модуля, що підключається, з системою Компас (з функціями моделювання, математичними функціями ядра системи та ін.) здійснюється за допомогою програмних інтерфейсів, званих API. У КОМПАС на даний момент існують API двох версій: API 5 і API 7. Насправді обидві версії реалізують різні функції системи і взаємно доповнюють один одного. Звідси, очевидно, що обидві версії програмних інтерфейсів в рівній мірі підтримуються і розвиваються з урахуванням самих змін в системі.

В основному, для створення повноцінних модулів, що підключаються, досить методів і властивостей інтерфейсів API 5.

3.3.1 Інтерфейс KompasObject

Головним інтерфейсом API системи Компас є KompasObject. Одержати покажчик на цей інтерфейс (якщо бути точним, на інтерфейс додатку API 5) можна за допомогою експортної функції CreateKompasObject (). Методи цього інтерфейсу, головні з яких представлені таблиці 3.1, реалізують найбільш загальні функції роботи з документами системи, системними настройками, файлами, а також дають можливість одержати покажчики на інші інтерфейси (інтерфейси динамічного масиву, роботи з математичними функціями, бібліотек моделей або фрагментів і різних структур параметрів певного типа).

Таблиця 3.1 Деякі методи інтерфейсу KompasObject

3.3.2 Інтерфейс документа моделі ksDocument3D

Інший важливий інтерфейс API 5 — інтерфейс документа моделі ksDocument3D.

Одержати його можна за допомогою методів інтерфейсу KompasObject:

· ActiveDocument3D — для того, що вже існує і активного в даний момент документа;

· Document3D — якщо ми плануємо створювати новий тривимірний документ.

Графічні документи мають власний інтерфейс — ksDocument2D, зі своїми специфічними властивостями і методами. Зображення в ескізах тривимірних операцій створюються саме за допомогою функцій, присутніх ksDocument2D.

Властивості (члени даних) інтерфейсу ksDocument3D дозволяють динамічно управляти настройками будь-якого тривимірного документа системи з нашого модуля. Найбільш використовувані з них приведені таблиці 3.2.

Таблиця 3.2 Властивості інтерфейсу ksDocument3D