Иерархия проектирования нисходящее и восходящее проектирование реферат

Обновлено: 02.07.2024

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

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

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

В таких случаях более предпочтителен нисходящий метод проектирования (рис. 2), заключающийся в том, что разработка изделия начинается с создания его компоновки и определения структуры, на основе которых затем моделируются входящие в изделие детали и узлы. Ниже мы рассмотрим, как осуществляется проектирование по нисходящему методу от идеи к чертежам в системе трехмерного проектирования Pro/ENGINEER WILDFIRE (рис. 3) на примере механизма, модель которого приведена на рис. 4. Рассматриваемый механизм может находиться в двух состояниях: сложенном ( а ) и разложенном ( б ).

Создание компоновки

Компоновка в Pro/ENGINEER WILDFIRE происходит в два этапа: сначала создается так называемая записная книжка инженера (Layout) , а затем каркасная модель сборки (Skeleton) .

Двумерный эскиз обычно определяет общую схему изделия и может быть либо создан с использованием чертежных инструментов Pro/ENGINEER WILDFIRE, либо импортирован из другого графического файла. Он никак не связан с геометрией проектируемой сборки, поэтому достаточно схематично прорисовать разрабатываемое изделие без соблюдения масштаба и детальной прорисовки. На нем указываются основные размеры, которые конструктор может изменять непосредственно на виде.

Каркасная модель сборки это трехмерная модель, геометрия которой определяет пространственные требования к сборке, состыковку компонентов и другие характеристики, необходимые для размещения компонентов сборки и определения их геометрии. Каркасная модель обычно состоит из опорных конструктивных элементов (плоскостей, кривых, координатных систем, точек) и поверхностей. На рис. 6 представлена каркасная модель проектируемого механизма.

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

Проектирование деталей и узлов

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

Организовать параллельное проектирование в Pro/ENGINEER WILDFIRE дает возможность инструмент Copy Geometry , позволяющий копировать любую геометрию поверхности, кривые, кромки, точки, координатные системы и т.д. между компонентами сборки. При нисходящем проектировании основным источником копируемой геометрии для разработчика является каркасная модель сборки, однако в некоторых случаях используется копирование между деталями и узлами сборки.

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

Привязка компонентов к каркасной модели позволяет также моделировать перемещение компонентов в сборке. Например, при изменении высоты конструкции, смоделированной в каркасе, изменится и положение всех связанных с каркасом компонентов (см. рис. 4). Таким образом, применение каркасной модели позволило без создания кинематических связей между компонентами смоделировать два положения конструкции.

Внесение изменений в конструкцию

Основные выводы

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

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

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

Олег Гаршин

Александр Московченко

3.4. Классификация моделей и параметров, используемых при автоматизированном проектировании ………………………………….

3.1. Иерархические уровни проектирования

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

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

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

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

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

• микроуровень, на котором проектируют отдельные детали и элементы машин и приборов.

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

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

Наряду с делением на иерархические уровни применяют разделение представлений о проектируемых объектах на аспекты.

Аспект описания (страта) — описание системы или ёе части с некоторой оговоренной точки зрения, определяемой функциональными, физическими или иного типа отношениями между свойствами и элементами.

Различают аспекты функциональный, информационный, структурный и поведенческий (процессный).

Функциональное описание относят к функциям системы и чаще всего представляют его функциональными схемами.

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

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

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

3.2. Стадии проектирования

Стадии проектирования — наиболее крупные части проектирования как процесса, развивающегося во времени.

В общем случае выделяют:

стадии научно-исследовательских работ (НИР),
эскизного проекта или опытно-конструкторских работ (ОКР),
технического,
рабочего проектов,
испытаний опытных образцов или опытных партий.

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

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

Например, при анализе прочности детали сеточными методами операциями могут быть:

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

Проектирование сводится к выполнению некоторых последовательностей проектных процедур— маршрутов проектирования.

Иногда разработку ТЗ на проектирование называют внешним проектированием, а реализацию ТЗ — внутренним проектированием.

3.3. Содержание технических заданий на проектирование

В ТЗ на проектирование объекта должно содержать, как минимум, следующие данные:

1. Назначение объекта.

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

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

3.4. Классификация моделей и параметров, используемых при автоматизированном проектировании

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

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

Математическая функциональная модель в общем случае представляет собой алгоритм вычисления вектора выходных параметров Y при заданных векторах параметров элементов X и внешних параметров Q.

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

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

Кроме того, введены понятия полных моделей и макромоделей, моделей статических и динамических, детерминированных и стохастических, аналоговых и дискретных.

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

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

Стохастические и детерминированные модели различают в зависимости от учета или не учета случайных факторов.

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

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

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

при t = 0 V = V₀ (1)

где V — вектор фазовых переменных, t — время; V₀ — вектор начальных условий. К примерам фазовых переменных можно отнести: токи и напряжения в электрических системах, силы и скорости — в механических, давления и расходы — в гидравлических.

Разработка (или выбор) структуры объекта — проектная процедура, называемая структурным синтезом, а расчет (или выбор) значений параметров элементов X — процедура параметрического синтеза.

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

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

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

Задачу параметрического синтеза называют параметрической оптимизацией (или оптимизацией), если ее решают как задачу минимизации функции

extr F(X), X D_х

где F(Х) - целевая функция; X — вектор управляемых (называемых также проектными или варьируемыми) параметров; D_x = Х| j(Х) Пропустить Оглавление

Рассмотрим общесистемные принципы проектирования сложных объектов. В учебной литературе обычно анализируют четыре таких принципа.
1. ^ Принцип декомпозиции. Описание сложного объекта должно бытьсогласовано с физиологическими возможностями восприятия человека. Это требование можно выполнить в рамках некоторого единого описания, не расчленяя его на простые составные части, только для простыхобъектов. Например, разработать единую принципиальную электрическую схему ЭВМ практически не возможно, или составить блок-схему сложного программного комплекса. Эти схемы будут просто необозримы. Даннымпринципом пользуются подсознательно, называя его принципом модульности (структурное программирование, модульность и магистральность в микропроцессорной технике).
Разбить проектируемый объект на простыесоставляющие различными разными способами. Например, случайным образом, или так, чтобы части содержали одинаковое число элементов, или – имели бы одинаковый вес и т.п.
В проектировании при декомпозиции чаще другихприменяют два следующих критерия. ^ Степень детализации отображаемых свойств; на основе этого критерия объект разбивают на несколько иерархических уровней, чем ниже уровень, тем более детально описаны егочасти. В учебной литературе можно найти многочисленные примеры декомпозиции по данному критерию программных комплексов, механических или электронных объектов.
Критерий характер отображаемых свойствпозволяет различить три стороны в описании объекта: функциональную, конструкторскую и технологическую. Соответственно, различают три аспекта в процессе проектирования. При функциональном проектировании основноевнимание уделяют принципам функционирования, характеру физических и информационных процессов. В результате имеют принципиальные, функциональные, кинематические и т.п. схемы и сопровождающие их документы.Конструкторский проект реализует функциональный проект в виде конкретных геометрических форм элементов и их взаимного расположения в пространстве.

Чтобы читать весь документ, зарегистрируйся.

Связанные рефераты

Принципы проектирования

. 2. 1. Принципы проектирования 2.1.1. Основные нормативные документы Из анализа.

Среда как объект проектирования

. Тема: Среда как объект проектирования. Композиция и цвет в.

Автоматизированное проектирование объектов из ко

. ….2 1 СТРУКТУРА ПРОЦЕССА АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ……………………………………………………..….5.

15 Стр. 35 Просмотры

Экологические требования при проектировании объе

Эстетические принципы проектирования

. Эстетические принципы проектирования Художественное конструирование —.

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

В книгах эти подходы часто противопоставляются. Считается, что если выбран один подход, то второй — исключен. Но это не так — в статье я объясню, почему следование только в одном направлении приводит к проблемам.

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

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

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

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

В качестве примера возьмем второй проект Хекслета, где разрабатывается библиотека для построения различий между двумя файлами. Если коротко, то весь интерфейс библиотеки — это одна функция, которая принимает на вход два пути до файлов определенных форматов (yml, json, ini) и возвращает описание различий между структурами этих файлов. Вот её использование:

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

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

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

Перед тем, как читать дальше, попробуйте ответить сами себе, что не так с этим кодом?

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

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

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

Попробуем переписать этот код правильно, с выделением хороших абстракций:

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

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

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

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

Читайте также: