Разработка библиотеки построения детали класса «тела вращения» средствами выбранной графической системы

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

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

 
Рисунок 3.1 - Схема "водопада"

 

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

Известны следующие  модели жизненного цикла:

• Каскадная модель. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• Поэтапная модель с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью; время жизни каждого из этапов растягивается на весь период разработки.
• Спиральная модель. Особое внимание уделяется начальным этапам разработки - выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание некой версии продукта или какого-либо его компонента, при этом уточняются характеристики и цели проекта, определяется его качество и планируются работы следующего витка спирали.

3.2 Определение архитектуры программного средства

 

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

Для определения  структуры необходимо решить две  задачи:

• выделение программных подсистем;
• определение способов взаимодействия между выделенными программными подсистемами.

 

3.3 Разработка структуры программы

 

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

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

 

3.3.1 Обоснование метода разработки структуры программы.

 

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

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

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

3.4 Среда для разработки приложений NX Open API 

 

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

Являясь современным Windows –  приложением, система NX включает в себя API — интерфейс прикладных разработок. NX Open API — это ориентированные на прикладного программиста инструментальные средства разработки различных приложений (библиотек типовых конструктивов, прикладных САПР и т.п.) на базе функций чертежно-графического редактора NX.

NX Open API  представляет собой набор библиотек графических функций, оформленных в виде динамически подключаемых модулей. Эти функции обеспечивают разработчику доступ к графическому ядру системы NX для формирования и обработки чертежей.

При создании приложения может  использоваться любая распространенная среда программирования для операционной системы Windows. Таким образом, у разработчика имеется свобода выбора, поскольку приложение можно создавать нa языкaх С#, С++ и т.д.

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

 

4 Реализация

4.1 Построение  модели детали 40 1141 средствами NX Open API

 

В работе предлагается выполнить построение детали 40 1141, модель которой представлена на рисунке 4.1.

 

Рисунок 4.1 – Модель детали 40 1141

 

Для создания рассматриваемой  модели необходимо осуществить ряд  операций:

1. Произвести построение эскиза детали 40 1141 с параметризацией всех размеров.
2. Реализовать операцию вращение построенного эскиза как показано на рисунке 4.3
3. Выполнить процедуру создания отверстий как показано на рисунке 4.4
4. В конце рекомендуется скрыть линии построения.

Рассматриваемая библиотека начинается со следующей  конструкции:

     Tag UFPart1;

            string name1 = "d:/model_p";

            int units1 = 1;

            theUFSession.Part.New(name1, units1, out UFPart1);

 Первые 3 строки текста применяются для описания переменных. В данном контексте переменная UFPart1 является деталью, ее тип задается как тэг (типовой объект NX). name1 - строковая переменная, которая задает имя файла детали. units1 – переменная целочисленного типа, определяющая тип системы мер (1 – метрическая система, 2 – английская). Четвертая строка отвечает за создание новой детали. Переменные name1 и units1 для нее являются входными, а UFPart1 выходными данными.

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

Рисунок 4.2 –  Результаты построения эскиза

 

Дальше выполняется  операция вращения полученного эскиз  в направлении оси X.

Дальнейший  элемент задает переменные и их значения.

 

double[] ref_pt1 = new double[3];

ref_pt1[0] = 0.00;

ref_pt1[1] = 0.00;

ref_pt1[2] = 0.00;

 

double[] direction1 = { 1.00, 0.00, 0.00 };

string[] limit1 = { "0", "360" };

Tag[] features1;

 

Строки 1 – 4 создают  массив из 3 вещественных чисел и  заполняют его нулями. В дальнейшем он будет использоваться для задания точки с нулевыми координатами, относительно которой будет осуществляться вращение. direction1 – аналогичный массив из трех элементов. В данной программе он отвечает за вектор (точнее его конечную точку), относительно которого осуществляется вращение. Начало вектора находится в начале координат. Переменная limit1 – массив строкового типа, в который заносится начальный и конечный угол для операции вращения, features1 – массив тэгов, выходной информации для операции “Вращение”.

Последующая строка отвечает за операцию “Вращение”

 

theUfSession.Modl.CreateRevolved(objarray1, limit1, ref_pt1, direction1, FeatureSigns.Nullsign, out features1);

 

Аргументами данной операции являются:

1. objarray1 – массив элементов эскиза операции;
2. limit1 – начальный и конечный угол вращения;
3. ref_pt1 – базовая точка;
4. direction1 – вектор, относительно которого осуществляется вращение;
5. FeatureSigns.Nullsign – задает булеву операцию, в данном случае операция отсутствует.

 

Строка

theUfSession.Part.Save();

сохраняет деталь в файл с именем, заданным переменной name1, по умолчанию путь к сохраненному файлу находится по адресу: C:\Program Files\UGS\NX7.5\UGII.

Результаты  операции «вращение» представлены на рисунке 4.3.

 

Рисунок 4.3 –  Результаты операции «вращение»

 

Далее необходимо деталь, представленную на рисунке 4.3, до состояния детали, показанной на рисунке 4.4. Для этого необходимо создать дополнительные плоскости, перпендикулярные оси вращения исходного эскиза и в этих плоскостях нарисовать новые эскизы прямоугольников заданного размера, которые в дальнейшем будет вытягиваться.

 

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

Следующим шагом  построения модели является выполнение операции «выдавливания» построенного эскиза.

Рассмотрим  более подробно построение данной операции на примере. Функция, задающая построение начинается с определения требуемых переменных.

{

         double[] direction4 = { 0.0, 0.0, 1.0 };

//Переменная задающая значения  направления выдавливания ось  CZ

         double[] ref_pt4 = new double[3];

//Требуемая, но не используемая  переменная

 

         string taper_angle4 = "0.0";

//Переменная, определяющая значение  уклона при выдавливании

         string[] limit4 = { "-10", "3" };

//Переменная, определяющая  параметры начала и конца операции  выдавливания

 

         int i4, count4 = 6;

// Переменная счетчик и число объектов в эскизе

 

         Tag[] objarray4 = new Tag[7];

// Массив объектов из 7 элементов.  Заполняется указателями на элементы  эскиза выдавливания при их построении (линии и дуги)

 

         Tag wcs_tag1, matrix_tag1, wcs_tag2, matrix_tag2, wcs_tag3, matrix_tag3, wcs_tag4, matrix_tag4;

//Переменные wcs_tag1 – для записи указателя на текущую систему координат; matrix_tag1 – для записи идентификатора матрицы связанного с объектом и т.д.

 

         Tag[] features4;

//features4 – переменная для записи указателя на объект, получившийся в результате операции выдавливания

 

Далее непосредственно  само выдавливание

//Создание операции  выдавливания

theUFSession.Modl.CreateExtruded(

objarray4/*Массив объектов выдавливания*/,

taper_angle4/*Угол уклона*/,

limit4/*Начало и конец выдавливания*/,

ref_pt4 /*Пустой параметр*/,

direction4/*Направление выдавливания*/, FeatureSigns.Negative/*Буревая операция (ВЫЧИТАНИЕ)*/,

out features4/*Выходной параметр - указатель на результат операции*/);

}

 

Рисунок 4.5 –  Окончательный вид детали

 

Для скрытия  линий построения используем следующую  строку: