Разработка прикладной библиотеки автоматизированного проектирования сборочной модели переходника

Ниже мы рассмотрим некоторые схемы разработки проекта.

"Водопад" - схема разработки  проекта 

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

Ниже мы рассмотрим каждый из этапов, подробнее остановившись на этапе проектирования.

Стратегия

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

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

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

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

В документе обязательно должны быть описаны:

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

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

Следует отметить, что и на этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MoSCoW - предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

Двумя классическими результатами анализа являются:

• иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);
• модель "сущность-связь" (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

 

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

 

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

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

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

 

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

Различают следующие основные классы архитектур программных средств:

• цельная программа;
• комплекс автономно выполняемых программ;
• слоистая программная система;
• коллектив параллельно выполняемых программ.

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

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

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

 

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

 

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

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

 

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

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

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

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

 

3.3.2 Модульная структура программного  средства

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

 

Form1.cs – главный модуль программы

Form2.cs – модуль визуализации эскизов

 

4 Реализация

4.1 Построение модели переходника

 

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

 

 

Рисунок 4.1 – Эскиз переходника

 

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

4. Произвести построение фланца (рисунки 4.2-4.6).
5. Провести построение заглушки (рисунки 4.7,4.8)
6. Построить основание (рисунки 4.9, 4.10)
7. Построить крепежные элементы
8. Выполнить сборку (рисунок 4.11)
9. В конце рекомендуется скрыть линии построения.

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

//прямоугольник1

double[] point_A = { 0.0, 0.0, 0.0 };

double[] point_B = { 0, 164, 0.0 };

double[] point_C = { 164, 164, 0.0 };

double[] point_D = { 164, 0, 0.0 };

string taper_angle = "0.0";

double startheight_rect = 0;

double height_rect = 30;

double[] ref_pt_extrude0 = { 0.0, 0.0, 0.0 };

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

FeatureSigns Operaciy_rect = FeatureSigns.Nullsign;

body1 = rectangl(point_A, point_B, point_C, point_D, startheight_rect, height_rect, taper_angle,

ref_pt_extrude0, direction_extrude0, Operaciy_rect);

//круг1

string taper_angle1 = "0.0";

double[] arc1_centerpt1 = { 82, 82, 0 };

double arc1_start_ang1 = 0.0;

double arc1_end_ang1 = 3.14159265358979324 * 2;

double arc1_rad1 = 30;

double startheight1 = 0;

double height1 = 18;

double[] matrix1 = { 1, 0, 0, 0, 1, 0, 0, 0, -1 };

double[] ref_pt_extrude1 = { 0.0, 0.0, 0.0 };

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