Аннотация
Бондаренко Е.С., Григорьев А.В. Исследование возможностей применения технологии программных шаблонов для синтеза геометрических объектов языковыми средствами САПР CATIA. В статье проанализированы существующие надстройки для создания шаблонов в САПР CATIA. Проведен анализ свойств и вариантов создания базовых геометрических объектов. Разработана методика создания программных шаблонов для синтеза объектов в CATIA, описаны использованные алгоритмы и представлена работа основных модулей приложения. Исследованы возможности применения технологии программных шаблонов для синтеза геометрических объектов языковыми средствами САПР CATIA.
Введение
При создании моделей в САПР часто используется стандартный набор тел, в которых изменяются лишь параметры, такие как длина, ширина, высота, диаметр и т.д. Для упрощения и сокращения времени проектирования сложных деталей целесообразно создавать шаблоны, применяемые для всех или для части создаваемых моделей./p>
В связи с этим расширение функциональных возможностей подсистемы геометрического проектирования в САПР CATIA должно улучшать работу проектировщика за счет уменьшения затраченного времени на создание геометрических объектов при проектировании сложных объектов и иметь удобный пользовательский интерфейс.
Для решения этой задачи в программировании широко применяются программные шаблоны.
Шаблон проектирования или паттерн в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста [1].
На текущий момент существуют различные надстройки в САПР CATIA, которые автоматизируют создание геометрических объектов в САПР, однако еще не существует программы для автоматизации геометрии, использующей технологию программных шаблонов в CATIA.
Поэтому целью данной работы является исследование возможности применения технологии программных шаблонов для синтеза геометрических объектов языковыми средствами САПР CATIA, проанализировать существующие надстройки для создания шаблонов в САПР CATIA, спроектировать и разработать приложение, моделирующее построение простых геометрических объектов с использованием программных шаблонов.
Сравнение инструментов автоматизации геометрии в CATIA
Для автоматизации проектирования в САПР CATIA используют как языковые средства, которые взаимодействуют с системой и могут дополнять ее, так и встроенные инструменты системы.
Подробный анализ существующих инструментов для создания шаблонов проектирования рассмотрен в [2]. Исходя из изложенного там материала, среди всех рассмотренных средств можно выделить наиболее мощные – скрипты и шаблоны знаний. Проведем их сравнительный анализ.
Количество строк кода, которые необходимо написать в подходе с шаблоном знаний, меньше чем с подходом сценариев VB. Кроме того, поскольку шаблон знаний имеет возможность управлять геометрией, и последовательное удаление происходит автоматически, строки кода удаления не нужны. Однако с подходом сценария VB, должна быть записана вся последовательность удаления, и таким образом, количество кода становится больше.
Нет возможности для проверки ошибок и отладки кода в шаблонах знаний, начиная с версии R18 CATIA V5 [3]. Дело значительно отличается от подхода к написанию сценариев VB, где в стандартной IDE доступно множество способов проверки синтаксических ошибок и отладка кода. Весь процесс поиска ошибок и отладки кода можно сделать логическим и постепенным. Это также позволяет сделать код более надежным для обработки широкого спектра сценариев с помощью отладки и проверки ошибок.
Следует отметить, что не все функции и инструменты, доступные в CATIA V5, могут быть доступны в шаблонах знаний. Это означает, что шаблон знаний в некоторой степени ограничен количеством функций CATIA, к которым он может получить доступ, и, следовательно, код, который написан в шаблоне знаний, содержит лишь встроенные функции. С другой стороны, с подходом сценариев VBA, очень большое количество функций и инструментов становится доступно. Это дает возможность использовать ряд инструментов и функций при программировании моделей, к которым не может получить доступ шаблон знаний.
Постановка задачи и описание разрабатываемой подсистемы
Так как во всех рассмотренных методах создания шаблонов в САПР CATIA есть такие недостатки как: 1) сложный синтаксис создания шаблонов и недостаток документации для изучения способов их создания; 2) отсутствие возможности задания алгоритма проектирования как методики проектирования определённого класса объектов с последующим повторным использованием этого алгоритма; 3) высокие требования к уровню знания проектировщиком предметной области; то возникает соответствующая задача: создать подсистему проектирования геометрических объектов в САПР CATIA V5 для возможности создания алгоритма проектирования для его многократного использования.
Структурное проектирование
Поставленная задача позволяет составлять и анализировать технические решения, множество которых можно представить в форме дерева из вершин типа И и ИЛИ. На рисунке 1 приведена схема алгоритма проектирования структуры объектов.
Рисунок 1 – Блок-схема алгоритма проектирования объектов
Вершины типа И определяют необходимый состав объекта, а вершины ИЛИ – неопределенные компоненты, подлежащие конкретизации путем анализа согласованности свойств компонента и объекта или анализа работы системы. Результатом структурного проектирования являются состав компонентов и отношения между ними. На этапе технического проектирования состав компонентов и соединения должны быть полностью конкретизированы [3].
Предикаты и отношения над ними
Предикаты – это И-ИЛИ-деревья, привязанные к семантике структуры физического блока.
Имеются три типа предикатов:
- внешняя граница, включающая собственные данные, т.е. выходы, «собственный потенциал блока», а также – «чужие данные», как факт наличия на внешней границе блока «чужих потенциалов», как источников их влияния на «собственный потенциал»;
- внутренняя граница блока, как набор собственных потенциалов для внутренних, инкапсулированных блоков – методов; включает также дополнительно специальный блок - «обратную границу», т.е. – внешнюю границу, вывернутую наизнанку; фактически задает список потенциалов, он же – список подблоков.
- набор структурных связей между всеми внутренними подблоками и «обратной границей»; порождает состав входов-выходов внутренних подблоков, т.е. внешних границ для внутренних, инкапсулированных подблоков; т.о., порождаются предикаты внешних границ внутренних поблоков.
Имеются:
- внутренние зависимости между ИЛИ-узлами, входящими в тот же предикат;
- внешние зависимости между ИЛИ-узлами, входящими в другой, смежный предикат;
Смежные предикаты:
- «внешняя граница – внутренняя граница»;
- «внутренняя граница – набор структурных связей»;
Т.о., внешне предикат представляет собой совокупность И-ИЛИ-узлов, доступных для ввода отношений совместности или – не совместности.
Как предикат внешней границы, так и предикат внутренней границы имеют одну и ту же природу и представляют собой перечисление потенциалов.
Предикат структурных связей отличается тем, что задает пары структурных связей между потенциалами.
Предикат как перечисление потенциалов включает [4]:
- состав типов потенциалов, входящих в «границу»;
- состав массивов потенциалов, как часть любого типа;
- состав элементов конкретного массива потенциалов любого типа (размер массива).
Предикат структурных связей включает:
- структурные связи между типами потенциалов, входящими в предикат «внутренней границы»;
- структурные связи между отдельными массивами потенциалов, входящими в отдельные типы потенциалов;
- структурные связи между единичными потенциалами (единичные структурные связи), входящими в те или иные массивы тех или иных типов потенциалов.
Совокупность «собственного» потенциала и «чужих» потенциалов, влияющих извне, составляют «внешнюю границу» блока.
Семантика и назначение данного блока – это описание механизма совокупного влияния «чужих» потенциалов на «собственный».
Внутренняя структура блока – результат декомпозиции блока на подблоки, которые делятся на две группы:
- подблоки, имеющие связь вовне;
- подблоки, не имеющие связь вовне.
Четырехточечники – небазовый модуль знаний, имеющий структуру из подблоков.
Вызов модулей происходит сверху-вниз:
- четырехугольник;
- линии;
- точки.
Структурные паттерны
Для синтеза геометрических объектов будем использовать структурные паттерны на базе онтологий. Их особенность заключается в том, что их работа происходит с порождающими грамматиками. Они представлены в форме Бэкуса-Наура. Шаблоны могут быть контекстно свободными, тогда любые комбинации ИЛИ-узлов разрешены [5].
Вводим контекстную зависимость отношениями совместности-несовместности, т.е. запрещаем невозможные комбинации.
Отношения совместности-несовместности являются инструментом вызова встроенных предполагаемых по умолчанию продукций. Если в данном ИЛИ-узле выбрана k-я альтернатива, то во всех ИЛИ-узлах, связанных с данным узлом отношениями совместности-несовместности, удаляются те альтернативы, которые несовместны с данной (выбранной) альтернативой.
Структурные паттерны предполагают некоторые структурные отличия, которые свойственны тем целевым классам, которые мы строим. В нашем случае структурными отличиями являются ИЛИ-узлы, порождающие грамматики.
Технология онтологий
Н. M. Боргест полагает, что онтология проектирования - это формализованное описание знаний субъектов проектирования о процессе проектирования новых или модернизаций уже известных артефактов, включая знания о самом объекте проектирования и близких к нему по свойствам артефактов, а также тезаурус предметной области [6].
Существовали разные подходы к обогащению моделей САПР с семантикой. OntoCAD [7] - это онтологический подход к аннотации, основанный на маркировке геометрических элементов моделей САПР с использованием концепций онтологии САПР. Некоторые исследователи представили онтологический подход к семантическому описанию данных и особенностей САПР. Они используют систему правил для автоматической классификации функций САПР, чтобы обеспечить совместимость отображения между различными системами САПР.
Онтология используется для представления и обоснования знаний о шаблонах, продуктах и их отношениях.
Онтология может служить тем слоем, который представляет собой знание о шаблонах и их взаимосвязи. Использование дает следующие преимущества:
- онтологии могут представлять несколько типов отношений между объектами;
- онтологии могут быть интегрированы с CATIA;
- онтологиями можно управлять вне CATIA;
- онтологии могут быть автоматически обработаны, чтобы найти зависимости и обнаружить конфликт между объектами;
- возможность автоматического переноса шаблонов CATIA в онтологию;
- умение наглядно представлять отношения среди шаблонов;
- возможность визуально представить цепочку причинно-следственных изменений в шаблоне на других шаблонах;
- возможность представлять правила и формулы на отношениях между шаблонами и параметрами.
Классы и подклассы
Каждое И-ИЛИ дерево – это класс, который имеет свой набор входных данных и методов. Подкласс – это класс, наследующий некоторые свойства от своего суперкласса.
В общем виде диаграмма классов разработанной системы представлена на рисунке 2.
Рисунок 2 – Диаграмма классов подсистемы
Стоит отметить, что в разработанной системе имеется сразу три И-ИЛИ дерева:
- И-ИЛИ дерево точек;
- И-ИЛИ дерево линий;
- И-ИЛИ дерево четырехугольников.
Структура классов
Класс – это основной элемент, в рамках которого осуществляется конструирование программ.
Метод класса – это базовая процедура, оперирующая как набором параметров частью внешних данных вышележащего класса, так и частью инкапсулированных данных вышележащего класса.
Подкласс – это класс, оперирующий как внешними данными частью внешних данных вышележащего класса и частью инкапсулированных данных вышележащего класса; играет роль «декомпозированного» метода вышележащего класса.
Совокупность методов класса задает внутренний алгоритм класса, как процедуры, используя для этого все внешние данные класса и все инкапсулированные данные класса.
Инкапсулированные данные класса – набор данных, посредством которого достигается связь методов или подклассов между собой для создания алгоритма класса.
Связь двух методов посредством некоторого инкапсулированного данного считается структурной связью двух методов.
Так же считается структурной связью передача некоторого данного класса на вход метода, или, наоборот, формирование некоторого выходного данного класса некоторым методом.
Любой метод должен быть привязан либо к некоторому инкапсулированному данному, которое он формирует на выходе, либо – к некоторому данному внешней границы класса, который он формирует. Такие данные называются «собственными» данными метода.
Можно сказать, что список инкапсулированных данных «плюс» список внешних данных, формируемых внутри методами (выходы класса), фактически задает список методов внутри класса.
Структурная связь между методами может быть:
- инкапсулированным данным, связывающим выход и вход двух методов;
- входным внешним данным, подаваемым на вход некоторого метода;
- выходным внешним данным класса, формируемое некоторым методом [7].
Создание классов
Создание простого класса предполагает создание базового класса и подкласса. Создание класса предполагает:
- ввод внешних данных класса;
- ввод инкапсулированных данных класса;
- ввод набора методов класса, оперирующих внешними и внутренними данными класса.
Подкласс создается внутри некоторого класса и представляет собой метод в рамках вышележащего класса. Он оперирует как внешними данными вышележащего класса, так и частью инкапсулированных данных вышележащего класса. Имеет свои инкапсулированные данные и методы.
Модуль классов
Модуль классов – это специальный шаблон классов, позволяющий выбрать (синтезировать) класс, имеющий требуемые отличия. Такими отличиями могут быть:
- наличие или отсутствие некоторого «внешнего» данного класса, т.е. – имени и типа;
- наличие или отсутствие некоторого «инкапсулированного» данного класса, т.е. – имени и типа;
- наличие или отсутствие некоторого метода.
Такой модуль класса имеет смысл, если он является компонентом вышележащего модуля классов, т.е. является его подклассом.
Модуль класса может быть сложным, т.е. – включать в себя внутренние модули. Модулем может быть, как модуль метода, так и модуль подкласса.
Создание модуля классов предполагает варианты:
1) создание модуля знаний для стандартных методов;
2) создание модуля знаний для классов, не имеющих внутренних подклассов, но имеющих базовые методы, т.е. – шаблоны методов;
3) создание модуля знаний для классов, имеющих «обобщенные» подклассы, т.е. – шаблоны подклассов;
4) создание модуля знаний для классов, имеющих внутри как подклассы, т.е. – шаблоны подклассов, так и шаблоны методов;
Класс, входящий в модуль классов, может идентифицироваться сложным именем:
"имя модуля"."имя класса в модуле"
Модуль знаний классов
Модуль знаний классов (шаблон) создается как набор трех И-ИЛИ-деревьев:
- внешней границы модуля (И-ИЛИ-дерева внешних данных класса);
- внутренней границы (И-ИЛИ-дерево «инкапсулированных» данных и, фактически, списка методов);
- списка внутренних структурных связей, связывающих методы посредством инкапсулированных данных и имеющих формат «Метод_1. Имя параметра-Выхода».
Полный состав структурных связей должен покрывать все входы выходы всех методов, имеющихся в классе, т. о., если взять список связей, то можно «породить» все входы-выходы всех внутренних методов класса, извлекая их из списка связей.
Над ИЛИ-узлами любого И-ИЛИ-дерева внутри дерева определены отношения «совместности-несовместности». Их задача – запретить невозможные варианты структуры.
Т. о., если некоторый ИЛИ-узел сократит состав своих альтернатив, то это должно привести к сокращению числа альтернатив в ИЛИ-узле, связанным с текущим ИЛИ-узлом отношениями «совместности-несовместности».
Над смежными ИЛИ-узлами И-ИЛИ-деревьев также определены отношения «совместности-несовместности». Т. о., есть связанные деревья:
- внешняя граница класса – инкапсулированные данные;
- инкапсулированные данные – список связей между методами класса.
Все варианты, которые можно породить любым И-ИЛИ-деревом, имеют свое имя (номер). Та или иная комбинация номеров должна соответствовать возможным классам.
Т. о., пронумерованы все варианты:
- внешней границы класса;
- инкапсулированных данных класса (списка используемых методов);
- вариантов взаимодействия методов посредством инкапсулированных данных и данных, входящих во внешнюю границу класса.
Подкласс как модуль знаний строится в предположении, что при синтезе определяется вариант его внешней границы, с последующим переходом на внутреннюю границу и – список структурных связей.
Модуль знаний методов
Для модуля знаний методов создается только одно И-ИЛИ-дерево – внешней границы модуля (И-ИЛИ-дерева внешних данных метода как класса). Над ИЛИ-узлами этого дерева определены отношения совместности-несовместности.
Модуль знаний методов строится как механизм выбора имени конкретного метода из ряда возможных по конкретному составу его входов-выходов, сложившегося по результату сужения числа альтернатив всех ИЛИ-узлов до одной альтернативы.
Вариант набора параметров (входов-выходов) метода – имя метода.
Кроме этого, имеется набор собственно методов как библиотека подпрограмм. Например, API графики (точки, линии).
Порядок задания вложенных модулей знаний
В этом случае если имя конкретного класса (метода) нам пока не известно, то в структурных связях вместо соответствующего имени используется имя модуля с соответствующим идентификатором (например, с «#»).
После синтеза по списку связей строится его внешняя граница, что позволяет в некоторой степени (частично) определится с именем класса.
После полного синтеза класса все параметры определяются до конца.
Порядок обхода И-ИЛИ дерева при выводе
При выводе возможны две стратегии обхода ИЛИ-узлов в предикате для выбора требуемого решения:
- сначала вглубь, затем – в ширину;
- сначала в ширину, затем вглубь.
В первом случае разбираемся с одной тонкостью структуры до конца, во втором – с общей компоновкой, а только потом разбираемся с тонкостями структуры объекта.
Логический вывод объекта на модулях знаний
Логический вывод предполагает работу с модулями знаний, т.е.:
- вывод выполняется на совокупности модулей знаний (в нашем случае три модуля - «точка», «линия», «четырехточечник»);
- модули знаний вложены в друг друга по сложности («точка» - в «линии», «линия» - в «четырехточечнике»);
- вывод начинается с модуля высшего порядка (в нашем случае – это «четырехточеник»), затем по мере необходимости подключаются нижележащие модули.
Модуль знаний представляет собой ряд подмодулей знаний (И-ИЛИ-деревьев):
1) внешней границы, как наборов внешних данных класса (входных и выходных);
2) списка подблоков, как совокупности внутренних методов класса, обладающих набором выходных (собственных) данных, среди которых есть все «инкапсулированные», внутренние данные, а также – все «выходные» данные внешней границы класса;
3) внутренней среды блока-класса как списка структурных связей, заданных:
- как набор «инкапсулированных» данных класса, связывающих по имени входы и выходы смежных методов;
- как набор внешних «входных» данных класса, связывающих по имени некоторый вход внешней границы класса и вход некоторого метода;
- как набор внешних «выходных» данных класса, связывающих по имени некоторый выход внешней границы класса и выход некоторого внутреннего метода.
Вывод в рамках одного модуля знаний
В рамках одного модуля знаний вывод предполагает следующие этапы вывода:
- вывод на подмодуле внешней границы (И-ИЛИ-дерево с отношениями совместности - несовместности);
- вывод на подмодуле списка подблоков.
Вывод в рамках одного предиката (И-ИЛИ дерева)
Логический вывод в рамках одного предиката (И-ИЛИ-дерева с определенными над ним отношениями совместности-несовместности) предполагает одновременное выполнение двух действий:
- выбор (логический вывод) нужного класса в рамках интеллектуального шаблона (И-ИЛИ-дерева классов);
- построение нужного объекта (как экземпляра выбранного класса).
Построение нужного объекта осуществляется путем задания ряда значений «прямо вводимых параметров». При этом:
- приоритет при выводе имеет процесс ввода значений «прямо вводимых параметров»;
- выбор (логический вывод) нужного класса в рамках интеллектуального шаблона выполняется из специфики (требований), налагаемых конкретными значениями «прямо вводимых параметров»;
- набор значений «прямо вводимых параметров» составляет техническое задание на вывод нужного класса и – объекта как экземпляра класса;
- все прочие значения параметров объекта класса, не вводимые прямо, рассчитываются по формульным зависимостям, имеющимся в классе (т.е. - по методам), путем программной интерпретации класса.
Механизм логического вывода
В различной части, которую этот модуль извлекает из модуля знаний, каждый элемент представляет собой листья И-ИЛИ дерева решений, по которым система производит теоретико-множественные операции в процессе диалога с пользователем и даёт ему возможность неявно выбрать ту или иную схему по её структурным особенностям. Система позволяет пользователю, как указать какой-либо элемент как удовлетворяющий его требованиям, так и исключить элемент из выбора, т.е. выбранного признака в схеме не должно быть.
Разработанная подсистема обладает механизмом, который при каждом выборе или действии пользователя сужает набор данных, доступных для следующего выбора. Алгоритм работы логического вывода представлен на рисунке 3.
Рисунок 3 – Алгоритм логического вывода
Разработанный программный комплекс для автоматизации проектирования геометрических объектов содержит в себе правила, благодаря которым осуществляется поиск методов по заданным входным параметрам. Эти правила выглядят следующим образом:
ЕСЛИ [требуемого признака у схемы нет], ТО [удалить схему из дальнейшего рассмотрения];
ЕСЛИ [признак есть только у удалённых схем], ИЛИ [признак есть у всех доступных схем] ТО [удалить этот признак из дальнейшего рассмотрения].
Именно благодаря этим правилам создаётся И-ИЛИ дерево и осуществляется поиск и вызов метода для создания геометрических объектов по заданным пользователем параметрам.
Выводы
В ходе выполнения работы исследованы возможности применения технологии программных шаблонов для синтеза геометрических объектов языковыми средствами САПР CATIA, проанализированы существующие надстройки для создания шаблонов в САПР CATIA. Была спроектирована и разработана подсистема, синтезирующая простые геометрические объекты с использованием программных шаблонов.
Разработана методика создания программных шаблонов для синтеза объектов в CATIA и реализован программный продукт с описанием использованных алгоритмов и реализацией основных модулей приложения.
По заданным входным параметрам система способна определить метод для создания геометрических объектов. Система может проектировать объекты, вызывая вложенные модули знаний с набором их методов. Разработанное ПО предоставляет возможность вести диалог с пользователем не только посредством диалоговых окон, но и косвенно.
Данная программа не сильно производительная, за счет чего работает очень быстро и не нагружает систему.
В дальнейшем планируется усовершенствование и расширение созданной подсистемы путем добавления новых модулей знаний и методов API CATIA для синтеза геометрических объектов.
Список использованной литературы
1. Бондаренко Е.С. Исследование API САПР CATIA V5 и перспективы развития создания приложений в ней [Электронный ресурс] / Е.С. Бондаренко, А.В. Григорьев // Материалы студенческой секции X Международной научно-технической конференции «Информатика, управляющие системы, математическое и компьютерное моделирование» (ИУСМКМ - 2019). – Донецк: ДОННТУ, 2019. –с. 105-109.
2. Бондаренко Е.С. Исследование возможности применения шаблонов в САПР CATIA для синтеза геометрических объектов [Электронный ресурс] / Е.С. Бондаренко, А.В. Григорьев // Материалы студенческой секции XI Международной научно-технической конференции «Информатика, управляющие системы, математическое и компьютерное моделирование» (ИУСМКМ - 2021). – Донецк: ДОННТУ, 2021.
3. Katzenbach A., Bergholz W., Rolinger A.: Knowledge-based design – an integrated approach, in: S. B. Heidelberg (Ed.), The Future of Product Development, 2007, pp. 13-22.
4. Григорьев А.В. Специфика выполнения теоретико-множественных операций над контекстно-свободными грамматиками в условиях различных форм дополнительных семантических правил в семиотической модели интеллектуальных САПР / А.В. Григорьев / Научные труды Донецкого национального технического университета. Серия «Проблемы моделирования и автоматизации проектирования динамических систем» (МАП – 2006). Выпуск 5 (116). – Донецк: ДонНТУ, 2006. – С. 91-104.
5. Mizoguchi R.: Tutorial on ontological engineering - part 1: Introduction to ontological engineering, in: New Generation Computing, Vol. 21, Ohmsha, 2003, pp. 365-384.
6. Ledermann C., Hanske C., Wenzel J., Ermanni P., Kelm R., ”Associative parametric CAE methods in the aircraft pre-design”, Journal of Aerospace Science and Technology, Vol. 9, Issue 7, October 2005, pp. 641-651, Elsevier.
7. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. — Приемы объектно-ориентированного проектирования. Паттерны проектирования, 2011.