Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования Ульяновский Государственный технический университет Факультет: Радиотехнический Кафедра: САПР

Диссертация на соискание степени магистра техники и технологии

Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

Направление: 21 020 068 «Проектирование и технология электронных средств»

(магистратура) программа «Информационные технологии в проектировании электронных средств»

Кожевников Михаил Олегович Научный руководитель к.т.н., профессор А. Ф. Похилько Ульяновск 2010 г.

УДК 658.512.22

Рецензент

Аннотация

1. Название: «Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D»

2. Год завершения работы — 2010

3. Объем работы: ___ с.

4. Количество приложений: 4

5. Количество иллюстраций: 44

6. Количество таблиц: 6

7. Количество источников литературы: 41

Характеристика работы:

1. Цель научной работы:

Повысить эффективность математической поддержки проектирования в системе КОМПАС-3D путём интеграции данного продукта с математическим пакетом MathCAD в рамках интегрированной инструментальной среды. Для этого необходимо реализовать Модули интеграции для обоих продуктов, которые позволят организовать обмен данными с внешними приложениями, а так же создать демонстрационный модуль интегрированной САПР, который позволит решить проблему хранения и повторного использования ранее разработанных проектов.

2. Методы проведенных исследований Теория систем, теория множеств, теория баз данных, формальная логика.

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

4. Наличие документа об использовании научных результатов — нет Кожевников М.О.

• Введение
• 1. Обзор методов повышения уровня автоматизации проектирования
• 1.1 Направления развития САПР
• 1.1.1 Интеллектуализация САПР
• 1.1.2 Параметризация.
• 1.1.3 Интеграция САПР
• 1.1.4 Комплексная автоматизация подготовки производства
• 1.2 Технологии интеграции инструментальных приложений
• 1.2.1 От OLE к ActiveX
• 1.2.2 Понятие COM, принципы работы
• 1.2.3 Обзор технологий ActiveX и OLE
• 1.2.4 NET и будущее COM
• 1.2.5 Универсальный формат обмена XML
• 1.3 Возможности КОМПАС-3D
• 1.4 Автоматизация инженерных расчётов
• 1.5 Выводы
• 2. Графический процессор ИИС
• 2.1 Интегрированная Инструментальная Среда
• 2.2 Технологии интеграции инструментальных приложений
• 2.2.1 Компас-3D как Графический процессор ИИС
• 2.2.2 Схема взаимодействия Графического процессора с компонентами интегрированной инструментальной среды
• 2.2.3 Схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции
• 2.3 Модель данных и иерархическая структура функций ИИС
• 2.4 Выводы
• 3. Программная реализация
• 3.1 Выбор средств разработки приложений
• 3.2 Выбор СУБД и разработка структуры базы данных
• 3.3 Разработка Интерфейсных модулей
• 3.3.1 Разработка Интерфейсного модуля для КОМПАС-3D
• 3.3.2 Разработка Интерфейсного модуля для MathCAD
• 3.3.3 Разработка механизма связывания переменных
• 3.4 Разработка графического интерфейса пользователя ИИС
• 3.5 Выводы
• 4. Апробация программного решения
• 4.1 Пример проектирования ребристого радиатора в ИИС
• 4.2 Пример проектирования шпоночной протяжки в ИИС
• 4.3 Выводы
• Заключение
• Литература
• Приложение 1
• Приложение 2
• Приложение 3
• Приложение 4

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

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

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

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

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

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

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

Решение вышеперечисленных проблем состоит в построении такой системы, которая, в рамках интегрированной инструментальной среды, обеспечила бы: обработку данных в специализированных приложениях; простые механизмы обмена данными между различными приложениями; поддержку инструментов хранения и передачи готовых проектных решений, а также инструментов для их модификации. Ключевым элементом интегрированной инструментальной среды, безусловно, стоит признать Графический процессор. Именно от свойств этого компонента, его механизмов интеграции во многом будет зависеть возможность построения такой среды. Но не менее важным элементом ИИС является Математический процессор — без полноценной математической поддержки сложно представить себе современный процесс проектирования.

Поэтому цель данной работы можно сформулировать следующим образом:

Повысить эффективность математической поддержки проектирования в системе КОМПАС-3D путём интеграции данного продукта с математическим пакетом MathCAD в рамках интегрированной инструментальной среды.

Достижение поставленной цели потребует решения ряда задач:

· Исследовать структуру ИИС.

· Сформулировать требования, предъявляемые к Графическому процессору в интегрированной инструментальной среде.

· Исследовать возможности и особенности работы систем КОМПАС-3D и MathCAD.

· Исследовать доступные в КОМПАС-3D и MathCAD механизмы интеграции и инструменты для расширения их возможностей.

· Исследовать возможные схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции.

· Разработать структуру базы данных для сохранения результатов проектной деятельности.

· Разработать Интерфейсные модули для КОМПАС-3D и MathCAD.

· Разработать программный модуль, реализуйщий основные возможности Управляющего модуля ИИС.

· Разработать Графический интерфейс пользователя ИИС.

В данной работе, помимо чисто исследовательской части, так же описан процесс разработки CASE-средства, реализующего вышеописанные идеи и задачи. В программной реализации основное внимание уделено интеграции двух важнейших компонентов ИИС — Графического и Математического процессоров, так как основная часть работы пользователя связана именно с ними.

1. Обзор методов повышения уровня автоматизации проектирования

1.1 Направления развития САПР

1.1.1 Интеллектуализация САПР

Стремительное распространение в нашей стране персональных компьютеров сопровождалось не менее стремительным потоком импортных САПР. Все эти системы объединяет одно свойство: крайне низкий уровень их «интеллектуального» развития. Они не способны самостоятельно принять ни одного технического решения и в руках инженера, принимающего все решения, являются не более чем усовершенствованным электронным кульманом. Все богатство инженерных знаний остается в книгах и, по мере способностей и опыта, в человеческих головах.

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

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

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

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

существенно повышается качество разработки в целом и ее фрагментов;

системы получаются более компактными и дешевыми;

обеспечивается большее удобство в планировании разработок;

упрощается процесс внесения изменений;

изменение исходных требований не приводит к полной переработке системы;

уменьшается риск в разработке сложных систем;

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

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

резкое сокращение за счет вышеупомянутого сроков создания высокоавтоматизированных систем, основанных на знаниях;

сокращение трудоемкости программирования за счет автоматической генерации программ на одном из процедурных объектно-ориентированных языков;

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

Интеллектуальная САПР строится для целого класса функционально подобных изделий. Т. е. речь не идет о САПР, как о генераторе параметрических геометрических моделей типового изделия с возможными дополнениями, а как о системе, где такой компонент как параметризованный графический образ изделия в виде чертежа или иной геометрической информации является лишь составной частью всех знаний об изделии. Геометрические знания могут и не использоваться при проектировании. Важным моментом является процесс принятия решений при проектировании. Понятие «интеллектуальная система» ни в коей мере не означает, что в процессе проектирования не может участвовать человек. Понятие интеллектуальной САПР подразумевает разумное сочетание по вопросам принятия решений между человеком и тем интеллектуальным ядром, которое присутствует в системе. Неоспоримым достоинством интеллектуальной САПР является то, что процесс проектирования изделия не связан с уровнем квалификации конечного пользователя системы. Вся нагрузка по грамотному формированию внутреннего интеллектуального ядра системы ложится на плечи эксперта в предметной области (ими, как правило, являются ведущие специалисты предприятий) и только на стадии создания проектного решения.

1.1.2 Параметризация

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

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

Идея параметрического моделирования появилась ещё на ранних этапах развития САПР, но долгое время не могла быть осуществлена по причине недостаточной компьютерной производительности. История параметрического моделирования началась в 1989 году, когда вышли первые системы с возможностью параметризации. Первопроходцами были Pro/ENGINEER (трёхмерное твердотельное параметрическое моделирование) от Parametric Technology Corporation и T-FLEX CAD (двухмерное параметрическое моделирование) от Топ Систем.

Двухмерное параметрическое черчение и моделирование.

Параметризация двухмерных чертежей обычно доступна в CAD-системах среднего и тяжёлого классов. Однако, упор в этих системах сделан на трёхмерную технологию проектирования и возможности параметризации двухмерных чертежей практически не используются. Параметрические CAD-системы, ориентированные на двухмерное черчение (лёгкий класс) зачастую являются «урезанными» версиями более продвинутых САПР.

Трёхмерное твердотельное параметрическое моделирование.

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

Типы параметризации:

Ш Табличная параметризация

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

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

Ш Иерархическая параметризация

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

Помимо «дерева построения» модели, система запоминает не только порядок её формирования, но и иерархию её элементов (отношения между элементами). (Например: сборки -> подсборки -> детали).

Параметризация на основе истории построений присутствует во всех САПР использующих трёхмерное твердотельное параметрическое моделирование. Обычно такой тип параметрического моделирования сочетается с вариационной и/или геометрической параметризацией.

Ш Вариационная (размерная) параметризация

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

Процесс создания параметрической модели с использованием вариационной параметризации выглядит следующим образом:

На первом этапе создаётся эскиз (профиль) для трёхмерной операции. На эскиз накладываются необходимые параметрические связи.

Затем эскиз «образмеривается». Уточняются отдельные размеры профиля. На этом этапе отдельные размеры можно обозначить как переменные (например, присвоить имя «Length») и задать зависимости других размеров от этих переменных в виде формул (например, «Length/2»)

Затем производится трёхмерная операция (например, выталкивание), значение атрибутов операции тоже служит параметром (например, величина выталкивания).

В случае необходимости создания сборки, взаимное положение компонентов сборки задаётся путём указания сопряжений между ними (совпадение, параллельность или перпендикулярность граней и рёбер, расположение объектов на расстоянии или под углом друг к другу и т. п.).

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

Ш Геометрическая параметризация

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

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

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

Процесс создания параметрической модели методом геометрической параметризации выглядит следующим образом:

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

Затем проставляет размеры между конструкторскими линиями. На этом этапе можно задать зависимость размеров друг от друга.

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

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

Геометрическая параметризация даёт возможность более гибкого редактирования модели. В случае необходимости внесения незапланированного изменения в геометрию модели не обязательно удалять исходные линии построения (это может привести к потере ассоциативных взаимосвязей между элементами модели), можно провести новую линию построения и перенести на неё линию изображения. 39]

1.1.3 Интеграция САПР

Интеграция ПО базируется на идеях объектно-ориентированного программирования. Следует различать синтаксический и семантический аспекты интеграции. Синтаксическая интеграция реализуется с помощью унифицированных языков и форматов данных, технологий типа ODBC для доступа к общему банку данных или компонентно-ориентированных (CBD — Component-Based Development) технологий. Семантическая интеграция подразумевает автоматическое распознавание разными системами смысла передаваемых между ними данных и достигается значительно труднее. Для создания ПО САПР, так же как и других сложных автоматизированных информационных систем, определяющее значение имеют вопросы интеграции ПО. Теоретической базой для создания технологий интеграции ПО в САПР являются:

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

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

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

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

Другими словами, в каждом приложении совокупность используемых при обменах понятий, предметных переменных и числовых параметров существенно ограничена и достаточно определена для того, чтобы можно было ставить вопрос о типизации моделей и языка взаимодействия. Такие вопросы решаются в рамках технологий STEP/CALS. Число приложений, нашедших свое описание в прикладных протоколах STEP, ограничено, но совокупность таких протоколов может расширяться.

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

Современные ОС позволяют работать одновременно с несколькими задачами с выделением каждой задаче своего окна на экране дисплея. Межпрограммные взаимодействия осуществляются путем посылки сообщений, как это принято в объектно-ориентированном программировании. Используются специальные средства организации взаимодействий.

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

В операционных системах Microsoft для организации межпрограммных взаимодействий были предложены средства Clipboard, DDE, OLE и в дальнейшем технология ActiveX.

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

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

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

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

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

Какое же место занимает геометрическая модель в представлении изделия для комплексной автоматизации подготовки производства? Это только одно из свойств изделия.

Таким образом, для комплексного решения задачи автоматизации необходима некоторая интегрирующая среда, управляющая процессом подготовки производства на основе:

информации о составе и структуре изделия;

состава исходных данных для каждого этапа подготовки производства;

состава выходных данных для каждого этапа подготовки производства;

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

привязки к информационным ресурсам предприятия;

привязки к структуре системы подготовки производства предприятия.

На первый взгляд разработка подобной системы не представляет особой проблемы. Однако даже поверхностный анализ реального положения дел показывает что:

Известны единичные случаи успешного решения этой задачи.

Стоимость таких систем достигает астрономических значений.

На сегодня не известно примеров универсального решения этой задачи.

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

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

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

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

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

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

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

Такие цепочки импорта-экспорта свойств и являются связями, обеспечивающими совместимость элементов конструкции.

Что дает такая организация модели? На первый взгляд одни и те же свойства многократно дублируются в дереве объектов (каждое свойство однажды экспортируется и многократно импортируется). Однако такой механизм делает каждый объект независимым и самодостаточным. Если некоторые свойства характеризуют объект, но не определяются им (импортируемые свойства), то они являются исходными данными для определения других свойств объекта (внутренних или экспортируемых). Каждый объект связан с внешним миром (моделью) импортируемыми — экспортируемыми свойствами и только.

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

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

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

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

1.2 Технологии интеграции инструментальных приложений

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

Можно сказать, что история программирования — это история попыток написать совершенный код. Разработка как прикладного, так и системного программного обеспечения страдала от бесконечных проволочек, а сами программы отличались умопомрачительной сложностью и непредсказуемым количеством «жучков». И все же без программ не обойтись, но как написать хорошую программу? Для этого нужно обладать способностью соединить общие принципы программного проекта с желанием (и даже горячим стремлением) вникнуть в миллиарды мелочей. Это требует не только колоссальных интеллектуальных усилий, но и соответствующего инструментария, который, увы, все еще далек от совершенства.

OLE, ActiveX, COM, .NET фирмы Microsoft — еще на один шаг приближают нас к более совершенным, т. е. более надежным и эффективным, программам. Но не только: «более совершенные» программы должны делать то, что раньше было невозможно, т. е. решать новые проблемы. В основе этих технологий лежит очень простая идея, но, как оказалось, она позволяет существенно повысить эффективность программирования.

1.2.1 От OLE к ActiveX

Первоначально OLE была задумана как технология интеграции программных продуктов, входящих в комплект Microsoft Office. Предшественницей OLE является реализованная в Windows технология динамического обмена данными DDE (Dynamic Data Exchange), до сих пор широко применяемая в данной среде. Однако многие разработчики не без оснований считают, что DDE трудно использовать, поскольку это технология низкого уровня. По существу, DDE представляет собой модель взаимодействия процессов — протокол, с помощью которого приложение может организовать канал обмена данными с DDE-сервером, находящимся на той же машине. DDE — это асинхронный протокол. Иными словами, после установления связи вызывающая сторона передает запрос и ожидает возврата результатов. Такой механизм более сложен, чем синхронный вызов функции, так как нужно учитывать вероятность нарушения связи, таймауты и другие ошибки, которые приложение должно распознавать и исправлять. Низкая популярность DDE вынуждала Microsoft искать различные способы его усовершенствования. Для упрощения наиболее сложных аспектов протокола была предложена спецификация DDEML, но этого оказалось недостаточно.

Несмотря на различия между низкоуровневой технологией системных объектов и средствами интеграции компонентов высокого уровня, Microsoft попыталась предоставить разработчикам объединенное решение. В качестве технологии более высокого уровня была реализована OLE 1.0 OLE 1 (Object Linking and Embedding — связывание и внедрение объектов). Она расширила возможности протокола DDE и, используя его как базовый механизм коммуникаций, позволила активизировать встроенный объект в документе, т. е. получить составной документ. Таким образом, OLE 1.0 унаследовала многие проблемы асинхронного протокола. Эта технология имела множество недостатков, а ее компоновка была слишком сложна для пользователей среднего уровня. Кроме того, установленные связи легко нарушались, например, в результате изменения маршрута доступа к файлу связанного объекта.

Первое воплощение OLE — OLE 1 — представляло собой механизм создания и работы с составными документами (compound documents). С точки зрения пользователя, составной документ выглядит единым набором информации, но фактически содержит элементы, созданные двумя или несколькими разными приложениями. С помощью OLE 1 пользователь мог, например, объединить электронную таблицу, созданную Microsoft Excel, с текстовым документом «производства» Microsoft Word. Идея состояла в том, чтобы документо-ориентированная (document-centric) модель работы с компьютером позволила бы пользователю больше думать об информации и меньше — о приложениях, ее обрабатывающих. Как следует из слов «связывание и внедрение», составные документы можно создать, либо связав два разных документа, либо полностью внедрив один документ в другой.

OLE 1, как и большинство первых версий программных продуктов, была несовершенна. Архитекторам следующей версии предстояло улучшить первоначальный проект. Вскоре они поняли, что составные документы — лишь частный случай более общей проблемы: как разные программные компоненты должны предоставлять друг другу сервисы? Для решения этой проблемы архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий — Модель многокомпонентных объектов (Component Object Model — СОМ). Новая версия OLE не только обеспечивает поддержку составных документов лучше, чем первая, но и несомненно идет куда дальше простого объединения документов, созданных в разных приложениях. OLE 2 позволяет по-новому взглянуть на взаимодействие любых типов программ.

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

Благодаря этим преимуществам, СОМ скоро стал частью технологий, не имеющих никакого отношения к составным документам. Однако в Microsoft хотели сохранить общее имя для всей группы технологий, в основе которых лежит СОМ. Компания решила сократить название Object Linking and Embedding до OLE — эта комбинация более не рассматривалась как аббревиатура — и опустить номер версии.

В начале 1996 года Microsoft ввела в оборот новый термин — ActiveX. Сначала он относился к технологиям, связанным с Интернетом, и приложениям, выросшим из него, вроде WWW (World Wide Web). Поскольку большинство разработок Microsoft в данной области было основано на СОМ, то и ActiveX была непосредственно связана с OLE. Однако очень скоро новый термин стал захватывать территории, традиционно принадлежавшие OLE, и вот теперь все вернулось на круги своя: OLE, как встарь, обозначает только технологию создания составных документов связыванием и внедрением, а разнообразные технологии на основе СОМ, ранее объединенные под именем OLE, собраны под знаменем ActiveX. А некоторые технологии, название которых содержало слово «OLE» даже перекрестили: теперь это технологии ActiveX. Новые технологии на основе СОМ, которым раньше полагался ярлык «OLE», теперь частенько получают пометку «ActiveX» .

1.2.2 Понятие COM, принципы работы

Все технологии OLE и ActiveX, построены на основании, обеспеченном СОМ. Чем занимаеться СОМ? Данная модель определяет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои сервисы другой, вне зависимости от их природы.

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

Большинство объектов СОМ поддерживают более одного интерфейса. Сам объект всегда реализуется внутри некоторого сервеpa. Сервер может быть либо динамически подключаемой библиотекой (DLL), подгружаемой во время работы приложения, либо отдельным самостоятельным процессом.

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

Любой СОМ-объект — это экземпляр определенного класса. Обычно знать класс объекта необходимо для запуска экземпляра этого объекта, выполняемого с помощью библиотеки СОМ. Эта библиотека присутствует на любой системе, поддерживающей СОМ, и имеет доступ к справочнику всех доступных на данной машине классов СОМ-объектов. Клиент может, например, вызвать функцию библиотеки СОМ, передав ей класс нужного ему СОМ-объекта и задав один из поддерживаемых объектом интерфейсов, указатель которого нужен клиенту в первую очередь. (Эти сервисы реализованы библиотекой СОМ в виде обычных вызовов функций, а не через методы интерфейса СОМ.) Затем библиотека СОМ запускает сервер, реализующий объекты данного класса. Кроме того, библиотека возвращает клиенту указатель требуемого интерфейса вновь созданного экземпляра объекта. Далее клиент может запросить указатели на другие необходимые ему интерфейсы непосредственно у самого объекта.

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

Благодаря СОМ, клиентам нет нужды учитывать данные отличия — доступ ко всему осуществляется единообразно. Для доступа к сервисам, предоставляемым любыми типами программного обеспечения, используется одна общая модель.

1.2.3 Обзор технологий ActiveX и OLE

Как OLE, которая теперь снова обозначает только технологии создания составных документов, так и широкий набор технологий под маркой ActiveX, разработаны с использованием СОМ. Многие из этих технологий своими корнями уходят в поддержку составных документов, тогда как другие предназначены совершенно для других целей.

Автоматизация

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

Приложение можно сделать программируемым, обеспечив доступ к его сервисам через обычный СОМ-интерфейс. Однако так поступают редко. Вместо этого доступ к сервисам приложений осуществляется через диспинтерфейсы (dispinterface). Они очень похожи на интерфейсы, (у него есть методы, клиенты осуществляют к нему доступ через указатель интерфейса и т. д.), но имеют и существенные отличия. В частности, методы диспинтерфейса гораздо проще вызывать клиентам, написанным на простых языках типа Visual Basic. Это очень важно: ведь большинство людей, желающих писать программы, осуществляющие доступ к внутренним сервисам приложений, чаще всего выбирают Visual Basic и аналогичные среды.

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

Составные документы

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

Для решения этой проблемы предназначена технология OLE (ранее называвшаяся Документы OLE — OLE Documents). Поддерживая нужные СОМ-объекты, каждый с собственным набором интерфейсов, независимые приложения могут совместно работать, чтобы пользователь получил один составной документ. Все эти интерфейсы носят абсолютно общий характер — ни одно приложение не знает, что представляют собой другие. Зачем встраивать в текстовый процессор функции электронной таблицы? OLE поможет просто задействовать в случае необходимости существующее приложение электронной таблицы.

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

При создании составного документа с помощью OLE одно из приложений всегда является контейнером. Как следует из названия, контейнер определяет самый общий документ, в котором содержится все остальное. Другие приложения — серверы — могут размещать свои документы внутри документа-контейнера. При использовании OLE документ сервера может быть либо связан, либо внедрен в документ контейнера.

Управляющие элементы ActiveX

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

Первоначально управляющие элементы ActiveX были известны под названием управляющие элементы OLE или ОСХ. Microsoft изменила название, чтобы отразить некоторые новые возможности, сделавшие эти элементы более подходящими для Интернета и WWW. Например, управляющий элемент ActiveX может хранить свои данные на странице где-то в WWW либо может быть выкачан с сервера WWW и затем запущен на машине клиента. И контейнер, в котором работает управляющий элемент, не обязан быть средой программирования — вместо этого он может быть средством просмотра WWW.

Управляющие элементы ActiveX — не отдельные приложения. Напротив, они являются серверами, которые подключаются к контейнеру элементов. Как обычно, взаимодействие между управляющим элементом и его контейнером определяется различными интерфейсами, поддерживаемыми СОМ-объектами. Фактически управляющие элементы ActiveX используют многие другие технологии OLE и ActiveX. Например, управляющие элементы обычно поддерживают интерфейсы для внедрения и зачастую предоставляют доступ к своим методам через диспинтерфейсы Автоматизации. 41]