Содержание к диссертации
Введение
Глава 1. Анализ вопросов проектирования технических объектов с применением средних САПР и постановка задач исследования 11
1.1. Методы автоматизированного проектирования технических объектов. Классификация САПР 11
1.2. Методы и технологии разработки автоматизированных систем, возможности применения и перспективы их развития для решения задач расширения функциональности средних САПР 20
1.3. Постановка задачи исследования 29
1.4. Выводы по главе 1 35
Глава 2. Принципы реализации технологии по разработки интегрируемых модулей расширения функциональности средних САПР 36
2.1. Комплексная методика разработки модулей расширения функциональности средних САПР с помощью интегрированной экспертной системы 36
2.2. Методика построения концептуальной модели разрабатываемых модулей расширения функциональности средних САПР 49
2.3. Структурное описание проблемно-ориентированных системно-образующих функциональных компонентов модулей расширения средних САПР 58
2.4. Методика проектирования модулей расширения функциональности средних САПР 72
2.5. Методика программной реализации проектной модели модулей расширения функциональности средних САПР 80
2.6. Выводы по главе 2 93
Глава 3. Программно-методический комплекс поддержки для процесса разработки модулей расширения функциональности средних САПР 94
3.1. Описание структуры и состава программно-методического комплекса поддержки для процесса разработки модулей расширения функциональности средних САПР 94
3.2 Описание экспертной системы для разработки модулей расширения функциональности средних САПР 102
3.3. Объектно-ориентированная информационно-поисковая подсистема по функциям модулей расширения функциональности средних САПР 109
3.4 Шаблоны проектирования для разработки модулей расширения функциональности средних САПР 117
3.5. Выводы по главе 3 135
Глава 4. Практическое использование программно методического комплекса для поддержки процесса проектирования и разработки модулей расширения функциональности средних САПР 136
4.1. Методические рекомендации по использованию автоматизированных средств комплексной технологии для разработки модулей расширения функциональности средних САПР 136
4.2. Примеры возникновения задач, для решения которых требуется разработка модулей расширения функциональности средних САПР 139
4.3. Примеры получения проектных решений разрабатываемых модулей расширения функциональности средней САПР 148
4.4. Выводыпоглаве4 158
Основные результаты и выводы по работе 159
Литература 161
Приложения 173
- Методы и технологии разработки автоматизированных систем, возможности применения и перспективы их развития для решения задач расширения функциональности средних САПР
- Структурное описание проблемно-ориентированных системно-образующих функциональных компонентов модулей расширения средних САПР
- Объектно-ориентированная информационно-поисковая подсистема по функциям модулей расширения функциональности средних САПР
- Примеры возникновения задач, для решения которых требуется разработка модулей расширения функциональности средних САПР
Методы и технологии разработки автоматизированных систем, возможности применения и перспективы их развития для решения задач расширения функциональности средних САПР
Решение задач расширения функциональности средней САПР достигается путем создания специализированных программных модулей. Данные модули представляют собой законченные автоматизированные системы, функциональность которых расширяет возможности средней САПР. Для того, чтобы выполнить разработку данных модулей необходимо воспользоваться методами и подходами проектирования и разработки программного обеспечения.
Рассмотрим ряд методов и технологий, позволяющих создавать программные системы. Появление первых персональных компьютеров ознаменовало новый этап в развитии информационных технологий. Был разработан метод разработки автоматизированных систем, в основе которых лежал структурный подход. Основой этого метода явилось разделение всего функционального множества на структурно организованные процедуры [15,18].
Для структурного подхода используются два типа представления и формализации данных: функциональная структура и ее описание; структура данных и описание их отношений. Причем, для описания строения процедур, входящих в функциональную структуру, вводится понятие алгоритма, под которым, в общем случае, понимается некоторое предписание выполнить точно определенную последовательность действий, направленных на достижение заданной цели или решение поставленной задачи. Для документирования было разработано средство, которое получило название блок-схема алгоритма.
Соответствующая система графических обозначений была зафиксирована в ГОСТ 19.701-90, которая регламентировала использование обозначений в схемах алгоритма.
Структурный подход к разработке автоматизированных систем получил свое развитие в работах Дугласа Росса в 1973 году. Был разработан метод структурного анализа и проектирования SADT (Structured Analysis and Design Technique). Данный метод представляет собой совокупность правил и процедур, предназначенных для разработки функциональной модели в виде графического представления.
Наряду с методами проектирования разрабатывались средства реализации спроектированных моделей - языки программирования. Одними из первых инструментов, позволяющих создавать автоматизированные системы для персональных компьютеров, были структурные языки программирования процедурного типа[15,18]. Возможности применения структурного подхода для решения задач расширения функциональности САПР появились довольно давно. Ранние версии САПР Autodesk Autocad поддерживали расширение своей функциональности за счет специализированных модулей, разработанных с помощью структурного языка программирования LISP.
Отличительной особенностью программного обеспечения, разработанного на основе структурного подхода, является содержание специальных модулей, которые должны нетривиально отображать сложные структуры данных при переходе от одного функционального блока к другому и реализовывать сложные вычислительные процессы синхронизации данных для обеспечения их целостности. Данный подход проектирования автоматизированной системы не давал возможность разработать единую модель, так как функциональные требования разрабатывались в отрыве друг от друга. Такой принцип привел к потере гибкости и адаптивности создания программных средств, так как при этом не была обеспечена возможность расширять приложения по функциональным возможностям без перепрограммирования и замены системы. Использование разнородных программных средств, построенных на основе различных методологических проработок, и разработанных на различных языках программирования, не обеспечивало необходимого концептуального единства создаваемой системы, что всегда отрицательно влияло на основные характеристики: надежность, производительность и технологичность.
Со временем ситуация стала существенно изменяться, возникла настоятельная потребность в новом подходе проектирования автоматизированных систем, который был способен решить весь комплекс проблем.
Таким подходом стал метод объектно-ориентированного проектирования (ООП), соединяющий в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.
Объектно-ориентированная декомпозиция легла в основу объектно-ориентированного проектирования и является основным отличием от структурного проектирования[14, 15,18, 66, 106, 122]. Появление данного подхода дало начало к разработке комплексов включающих в себя мощные языки объектно-ориентированного программирования, технологии и объектно-ориентированные библиотеки специализированных классов. Одним из представителей современных систем может являться разработка компании Microsoft - программный комплекс Microsoft Visual Studio 6.0, включающий в себя множество языков, таких как: Microsoft Visual Basic 6.0, Microsoft Visual C++ 6.0. Данные языки имеют возможность использовать современные технологии компании Microsoft - OLE Automation (Automation).
Представленный комплекс и технологии дали возможность использовать специализированные механизмы для решения задач расширения функциональности автоматизированных систем, в основе которых лежит принцип взаимодействия через внешние интерфейсы. Одним из явных примеров применения данной технологии является использование внешних интерфейсов при разработке встраиваемых модулей расширения функциональности для САПР Autodesk Inventor. В основе данных работ лежит разработка прикладного программного интерфейса - Application Programming Interface (API).
Создание данных модулей возможно посредством разработки специализированных компонентов по технологии компании Microsoft Component Object Model (COM). Интерфейсом автоматизации можно назвать интерфейс специального типа определенного СОМ. Компонент СОМ содержит код, выполняемый как в внутри процесса САПР Inventor (dll), так и в вне (ехе). Разработанный компонент может содержать в себе функциональные возможности, дополняющие систему, и может динамически обмениваться данными. С помощью специализированного механизма "Add-in", технологии Automation , система позволяет загрузить созданные компоненты и установить связь для добавления дополнительных пунктов меню и исполнения функций при их вызове. Практически все современные языки программирования имеют возможность поддерживать интерфейс автоматизации. Наряду с представленным механизмом, МРФ может быть представлен внешней диалоговой программой, разработанной с учетом объектно-ориентированных принципов, не требующей, чтобы пользователь работал в интерактивном режиме, например с САПР Autodesk Inventor. При этом, данная программа может контролировать работу системы Autodesk Inventor и функционирует независимо от нее.
При использовании представленных информационных технологий основными принципами объектно-ориентированного проектирования и программирования являются: наследование, инкапсуляция и полиморфизм. Принцип, в соответствии с которым знания о более общей категории разрешается принять для более узкой категории, называется наследованием. Термин инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. Третьим принципом ООП является полиморфизм. Под полиморфизмом понимается свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств - это означает, что действия, выполняемые одноименными программными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной программный метод.
Принципы объектно-ориентированного проектирования дали возможность создавать методы проектирования и моделирования программного обеспечения, отличительной особенностью которых стало использование специализированного языка проектирования UML.
В конце 80-х и в начале 90-х годов был разработан унифицированный язык моделирования - UML (Unified Modeling Language). Данный язык проектирования дал возможность унифицировать объектные модели и принципы их создания[36, 48, 51, 52, 94, 109]. Независимо от предметной области, язык UML успешно используется на всех этапах разработки автоматизированной системы. Современная практика программирования показала, что существует разрыв между программистом и конечным пользователем. При этом, важным моментом является применение унифицированных способов описания автоматизированных систем. Данный подход наиболее благоприятен для решения задачи, которая описана в данной работе в связи с тем, что можно отбросить все второстепенные детали для анализа предметной области и описания необходимой дополнительной функциональности средней САПР.
Наиболее известным методом, применяемым в настоящее время для разработки программного обеспечения, является унифицированный процесс, разработанный компанией Rational - Rational Unified Process (RUP). Данный метод является итерационным, и существенно усовершенствовал процесс проектирования и разработки автоматизированных систем и заменил классический подход по разработке программного обеспечения [36, 49, 52, 94, 102, 15,18,37].
Структурное описание проблемно-ориентированных системно-образующих функциональных компонентов модулей расширения средних САПР
Процесс проектирования МРФ средней САПР можно представить как последовательное формирование ряда моделей, с различными уровнями абстрагирования. В разделе 2.2. рассмотрена методика разработки КМ МРФ средней САПР, созданная на базе метода RUP. В этом методе предусмотрен ряд иерархически упорядоченных моделей МРФ, представляющих функциональность: ДФ, ДПФ, ДП, ДС, ДД. В разделе 2.2. речь идет о том, что представление функциональности должно идти в отрыве от разработки архитектуры МРФ в связи с тем, что разработка функций и функциональных пакетов системы производится для проработки потоков данных или объектов. Это делается для того, чтобы специалисты, которые реализуют проект, смогли понять распределение процессов между объектами и построить равномерно распределенную модель КА и соответствующую ПА.
В настоящей работе для разработки проекта используется многоуровневое представление МРФ, включающее пять типов моделей, реализуемых в виде соответствующих диаграмм. Иерархическая обусловленность и выделение определенных уровней иерархии моделей соответствует базовому методу, однако, для ряда диаграмм (ДПФ, ДП, ДС) особое значение имеет процесс функциональной декомпозиции. Чтобы минимизировать трудозатраты на этапе анализа функциональности предлагается подход, в основе которого лежит классификация проблемно-ориентированных системно-образующих функциональных компонентов. Используя данную классификацию, процесс проработки предметной области становится более понятным и наглядным как для конструктора, так и для разработчика. Разработанная классификация позволяет на ранних стадиях определить необходимое множество функциональных компонентов, не затрагивая при этом архитектурные зависимости.
Рассмотрим структуру, назначение и принципы построения модели функциональности, при построении которой разработчик может воспользоваться разработанной классификацией.
Описание функций зачастую производится следующим образом: строится дерево ролей путем выделения типовых ролевых сущностей (множество пользователей МРФ) и для каждой формулируется множество функции, соответствующих описанным требованиям. Затем строится ДФ, при которой на диаграмме каждой роли указываются соответствующие функции. Зачастую, при этом, не возникает вопроса о соответствии уровней декомпозиции функций и функционально образующих ролей (вспомогательные программные системы), поскольку формирование дерева функций заменяется на разделение по пользовательским ролевым сущностям. Используемый подход затрудняет дальнейшее построение других диаграмм (например, ДПФ или взаимодействия) и последующую разработку равномерной архитектуры классов, реализующих необходимую функциональность, и во многом не отвечает на необходимые вопросы разработчиков (в частности каким образом функции внутри модели зависят друг от друга). ДФ должна внести ясность в функционирование МРФ средней САПР, при которой было бы ясно, какая функция перекрывает определенное требование или является декомпозирующей функцией, какая уточняет функциональный принцип.
Корректным подходом является формирование дерева функций и описание возможного выполнения функциональности соответствующим ролям (множество пользователей) предваряющее построение архитектуры, и базируется на понимании, в первую очередь, основных принципов функционирования МРФ средней САПР, без соответствующей реализации. В общем случае при построении ДФ могут встречаться пять типов соответствия между множеством функций и ролей:
- 1 роль задействует 1 функцию;
- 1 роль задействует К функций (К 1);
- 1 функция реализуется совокупностью Ыф функций (Ыф 1);
- 1 функция реализуется 1 ролью (внешняя программная система);
- 1 функция реализуется совокупностью Np ролей (внешними программными система) (Np 1).
Представление на ДФ взаимоотношения функций с внешними системами накладывает определенную архитектурную зависимость, что в последствии может привести к отсутствию гибкости архитектуры, что повлечет трудоемкий процесс сопровождения, связанный с внесением изменений в МРФ. Процесс формирования функциональности МРФ средней САПР надо разделять на две проектные процедуры: описание функций, показывающих специфику поведения МРФ с внешними сущностями (ролями), и описание функций, реализующих функциональные требования МРФ. Для выполнения первого шага необходимо провести предметно-ориентированный анализ ролевых сущностей, при этом, применяемая экспертная система дает рекомендации по анализу и следит за последовательностью в соответствии с МП. Ниже представлен подход, позволяющий выявить из всего множества внешних сущностей необходимые роли, относящиеся к текущему проекту по разработке МРФ средней САПР.
Классификация проблемно-ориентированных ролевых сущностей применяемых для разработки МРФ:
При проектировании МРФ средней САПР необходимо проводить анализ соответствующего конструкторского подразделения с целью выявления и понимания для кого проектируется МРФ, кто является заказчиком и кто будет использовать функциональность разрабатываемого МРФ. Для этого разработана предметная классификация с вариантом заполнения, которая может быть использована как шаблон обследования конструкторского подразделения и применена на последующих разработках МРФ.
Проектно-конструкторское подразделение
Группы конструкторского подразделения Варианты групп могут быть следующие:
Группа механиков
Группа сантехников
Группа электриков
Группа строителей
При данной классификации разработчик четко представляет, для кого конкретно разрабатывается МРФ. При анализе производится описание соответствующих групп. При использовании ЭС генерируются шаблоны примеров описания соответствующих групп. Для группы механиков данное описание представляет следующее:
Структура группы механиков
В состав группы механиков входит 9 человек: руководитель группы, 3 ведущих инженера, 2 инженера I категории, 2 инженер II категории, инженер III категории и ст. техник конструктор. Также функции ведущего инженера группы выполняет и заместитель начальника конструкторского подразделения. Непосредственно работы по конструированию объектов выполняют: руководитель группы, ведущие инженеры, инженер I категории. Инженер II категории, инженер III категории и ст. техник конструктор в основном занимаются доработкой сборочных чертежей, разработкой чертежей сборочных единиц и деталей изделий, спроектированных ведущими инженерами.
Характеристика проектно-конструкторской деятельности
В задачи группы входит конструирование нового оборудования и механизмов и модернизация старого. Выделяются следующие объекты конструирования: плавильные агрегаты, грузоподъемные машины, грузозахватные приспособления, технологическая тара, технологическая оснастка, средства малой механизации (резка текстолита, канатов, выпресовка муфт), транспортные тележки, нестандартные редукторы, пневматические схемы, гидравлические схемы, кинематические схемы. В результате выполнения проекта создается комплект конструкторской документации, включающий сборочные чертежи и чертежи деталей. В процессе проектирования проводятся инженерные расчеты стандартных механических узлов, прочностные расчеты, расчеты динамики механизмов.
Современное положение по автоматизации
В данном разделе описываются применяемые системы автоматизации проектно-конструкторских работ.
Объектно-ориентированная информационно-поисковая подсистема по функциям модулей расширения функциональности средних САПР
ИПС представляет собой совокупность информационных компонентов, реализующих распределенную модель автоматизированной системы. Основная задача разработанных компонентов заключается в предоставлении и обработки информации.
Основными функциями компонентов ИПС являются:
— пополнение и обслуживание БД, которые представляют собой хранилище для описания функций, ролей в разрезе автоматизированных систем и конструкторских подразделений;
— осуществление по заданному запросу перекрестного многоступенчатого поиска в базах данных;
— построение элементов функциональной модели автоматизированным способом.
На рисунке 3.7. представлена архитектура ИПС, определяющая состав программных подсистем и их взаимосвязь.
Подсистема ведения БД представляет собой отдельное специализированное приложение, состоящее из трех подсистем с определенным набором функций для обслуживания БД:
— подсистема ведения описания проблемно-ориентированных функций;
— подсистема ведения описания проблемно-ориентированных программных систем;
— подсистема ведения описания конструкторских подразделений;
На рисунке 3.8. представлена диаграмма компонентов ИПС. Каждый компонент представляет собой реализацию некоторого набора классов и интерфейсов, предназначенных для обеспечения работы ряда подсистем, позволяющих производить ведение БД, реализации поиска по запросу, организованному и запущенному разработчиками МРФ средней САПР. Также в состав ИПС входит подсистема, использующая специализированный компонент генерации вариантов ФМ, который является модулем расширения системы Rational Rose. Последовательно рассмотрим работу каждой подсистемы ИПС в отдельности.
Подсистема ведения описания конструкторских подразделений обеспечивает заполнение исследовательских шаблонов проектирования, позволяющих с их помощью на этапе разработки концептуальной модели построить элементы функциональной модели и их описать с помощью набора специализированной функциональности:
— добавление конструкторских групп;
— удаление конструкторских групп;
— просмотр наименования и вариантов описаний выбранной группы;
— добавление описания варианта группы;
— удаление описания варианта группы;
— печать всех описании вариантов группы;
— печать описания выбранной группы и варианта.
При этом, описание варианта группы состоит из трех разделов:
— описание структуры группы;
— описание проектно - конструкторской деятельности группы;
— описание положений об автоматизации.
Представленная функциональность достигается набором специализированных методов, входящих в состав внешних программных интерфейсов; ICad и IGroupCad.
Использование данной поисковой подсистемы с набором заполненных шаблонов проектирования оптимизирует работу по изучению конструкторского подразделения, для которого разрабатывается МРФ средней САПР, что важно для разработки функциональной модели.
Подсистема ведения БД по автоматизированным системам и специализированным программным библиотекам позволяет заполнить БД информацией по описанию с помощью заложенной функциональности:
— добавление группы систем;
— удаление групп систем;
— просмотр наименования и вариантов систем выбранной группы;
— добавление описания системы;
— удаление описания системы;
— печать описаний всех систем;
— печать описания выбранной системы.
При этом, применяются внешние программные интерфейсы: IRoleApp и IGroupApp.
Подсистема ведения БД по функциям обеспечивает с помощью реализованных программных интерфейсов IgroupF и IFunctions заполнение дерева функций с помощью следующих действий:
— просмотр дерева функциональности;
— поиск вершины;
— добавление вершины (группы функций);
— добавление концевой вершины (функции);
— удаление вершины;
— редактирование наименования вершины;
— печать всех функций;
— печать по группам функций;
— установка зависимостей и их описание.
Отличительной особенностью данной подсистемы является наличие режима установки зависимости между: функциями, автоматизированными системами или программными библиотеками. Данная функциональность достигается при помощи программного интерфейса IUsageF.
Для поддержки этапа проектирования и программной реализации в состав ИПС входит два специализированных компонента, основными функциями которых являются: обеспечение доступа к специфической предметно-ориентированной специализированной информации и осуществление поиска по соответствующим БД.
Для ведения БД специализированного глоссария ИПС снабжена следующей функциональностью:
— добавление термина на русском и английском языке;
— удаление термина;
— просмотр наименования и определения;
— добавление определения термина;
— удаление определения термина;
— печать всех терминов;
— печать определения выбранного термина.
Для ведения БД описания специализированных программных сущностей и механизмов ИПС снабжена следующей функциональностью:
— добавление группы;
— удаление групп;
— просмотр описания;
— добавление описания;
— удаление описания;
— печать описаний;
— печать описания выбранной группы.
Функциональность представленных обеих подсистем достигается за счет использования разработанных программных интерфейсов, входящих в состав двух компонентов: IGroupO, IOpis, ISeekOpis, ISeekGlossary, IGlossary.
Система поиска позволяет сформировать запросы, результаты которых выводятся в виде списков записей БД, при этом, можно просмотреть и вывести на печать описание каждого элемента.
Примеры возникновения задач, для решения которых требуется разработка модулей расширения функциональности средних САПР
Проблема, при которой возникает задача, решение которой требует разработки специализированных средств поддержки процесса проектирования и конструирования в настоящее время довольно часто встречается в работе конструкторских подразделений. Для того, чтобы провести анализ в какой части или при каких работах возникает необходимость дополнительного инструментария для расширения функциональных возможностей средней САПР путем разработки и внедрения специализированных МРФ, необходимо рассмотреть и проанализировать процесс проектирования и конструирования на примере готового проекта или действующего процесса.
Для выявления потребности в предлагаемых программно - методических средствах в настоящей работе проводился анализ на примере предметной области - специализированные модули расширения функциональности средней САПР Autodesk Inventor, применяемые для поддержки процесса проектирования и конструирования ТО в машиностроении.
Выбор данной САПР был произведен на основе анализа и систематизации ряда существенных факторов, таких как: актуальность применения данной системы, ориентированность на проектирование ТО машиностроения, наличие множества исследований и практический опыт работы в данной области, готовые технические решения в виде пакета конструкторской документации.
Для поставленной проработки за основную базу возьмем конструкторский проект разработанной модели специализированной "машины для пробивки корки электролита в торцах электролизеров", конструкция которого выполнена на базе автопогрузчика типа "Балканкар Рекорд". Данная машина применяется в процессе производства алюминия для пробивки корки электролита в торцах работающих электролизеров. В большинстве случаев процесс создания сложных механизмов начинается с моделирования деталей для получения сборочных единиц. Рассмотрим ряд деталей в части модели рабочего механизма - рама с гидроцилиндрами, представленной на рисунке 4.2.
Произведенный анализ процесса проектирования моделей сборочных единиц показал, что затраты времени на разработку в основном связаны с рутинными операциями по созданию геометрии, а именно, контуров деталей и дополнительных конструкторских элементов. Внедрение различных средств автоматизации данных процессов позволит в несколько раз сократить время и значительно повысить качество получаемых конструкторских моделей проектируемых деталей, снизить количество ошибок, допускаемых инженером -конструктором в процессе разработки.
Повторяющиеся операции в процессе проектирования возможны при создании моделей одинаковых или близких по конструкции деталей. В представленной раме с гидроцилиндрами большое количество типовых деталей, одними из которых являются: проушины, шайбы для крепления и втулки. Выбор данной группы деталей произведен на основании их простой конструкции для более полного понимания задачи, решение которой рассматривается в разделах данной диссертационной работы. При этом, в рамках проведенного анализа моделей различных конструкций было выявлено множество деталей, а представленные рассматриваются в качестве примеров.
Построение моделей деталей в средней САПР Autodesk Inventor начинается с создания эскиза, а именно, с простого построения контура будущей детали с помощью прямых линий, окружностей и полуокружностей. Следующий шаг включает в себя работы по наложению геометрических зависимостей (параллельность, горизонтальность, вертикальность, эквивалентность и т.д.) и установки размеров (Рис. 4.3.). Тем самым производится приведение к нужным размерам и более точной форме контура будущей детали. На данном этапе проводимые работы занимают самую большую часть времени разработки детали. Инженеру - конструктору необходимо постоянно следить за правильностью установки зависимостей и размеров геометрических примитивов. При решении задачи параметризации необходимо выполнять специфические для проектируемой детали расчеты и установки расчетных формул в установленные размеры модели детали.
Следующим этапом построения детали является задание формы детали уже не в виде эскиза, а трехмерной модели с определенной толщиной. Для этого необходимо закрыть эскиз и воспользоваться одной из многочисленных команд - выдавливание. Данный шаг является более простым, но без него нельзя получить необходимую модель, при этом, инженер конструктор должен принимать решение каким инструментом ему необходимо воспользоваться.
После выполнения построения 3-х мерной модели выполняются работы по построению дополнительных геометрических элементов. Наряду с созданием дополнительных эскизов в средней САПР Autodesk Inventor имеется возможность снять фаски, проделать отверстия, выполнить закругление и т.д. И, в зависимости от технических условий проектируемой детали, модель может быть доработана до требуемого вида за счет добавления в модель проектируемой детали конструктивных элементов.
В результате выше представленных шагов инженер - конструктор получает трехмерную модель детали: "Проушина", "шайбы" или "втулки" (Рис. 4.4).
Стандартные средства современной средней САПР решают задачи проектирования и конструирования инструментами, которые заложены в них. Процесс получения технических решений необходимых деталей включает в себя множество задач: построение контура детали, установку геометрических зависимостей, установку необходимых размеров, построение 3-х мерной модели, установку дополнительно конструктивных элементов. При этом, могут выполняться различные специфические расчеты. Даже приставленные выше примеры разработки моделей деталей отнимают массу времени в процессе проектирования, хотя многие из них выполняют вспомогательные функции.
Проведенный анализ полученной проектной модели машины для пробивки корки электролита в торцах электролизеров позволяет сделать вывод о необходимости в дополнительных инструментальных средствах поддержки процесса проектирования и конструирования для минимизации времени разработки. В таблице 4.1. представлены результаты анализа, а именно, количество типичных деталей, отличающихся между собой контуром, размерами и дополнительно конструктивными элементами.
Таким образом, потери времени в большей степени связаны с довольно большим количеством постоянно повторяющихся построений и расчетов. Оптимизация данных работ позволит больше времени инженеру-конструктору уделять решению основной задачи, а именно, проектированию важных частей механизмов.
Решение поставленной проблемы может быть найдено в использовании технологий специфичных для средней САПР Autodesk Inventor iFeature и iPart.
Но данные возможности все равно не дают желаемого результата и удобства для инженера - конструктора. При этом, полученные модели все равно требуют проводить работы, связанные, с дополнительной доработкой до требований. Более того, представленные возможности не позволяют реализовать дополнительные расчеты, связанные, в первую очередь, с конструкцией необходимой детали. Из этого можем сделать вывод, что для процесса построения моделей деталей необходимо более радикальное средство, которое могло бы решать весь спектр задач проектирования определенного типа деталей.
Проблема расширения функциональности решается с помощью разработки специализированных интегрируемых МРФ средней САПР, используемых для поддержки процессов проектирования и конструирования. Конструктор с помощью данных модулей в режиме диалога заказывает необходимые параметры и после нажатия клавиши "ОК" получает необходимое решение. При этом, не тратится время на создание эскиза, установку размеров и дополнительно конструктивных элементов. Данная постановка задачи является актуальным направлением и является важной практической задачей в компьютеризации и автоматизации этапов проектирования и конструирования.
Средняя САПР AutoDesk Inventor имеет возможность использовать интегрируемые модули расширения функциональности. Процесс создания интегрируемого модуля, расширяющий функциональность САПР, является разработкой прикладного программного интерфейса (Application Programming Interface, API). Основа концепции API представляет собой приложение, созданное на основе модели компонентных объектов (Component Object Model, COM).
