Энциклопедия по машиностроению XXL

Оборудование, материаловедение, механика и ...

Статьи Чертежи Таблицы О сайте Реклама

Проектирование нисходящее

Существующие методы проектирования программного обеспечения делятся на группы методов восходящего проектирования, нисходящего проектирования и расширения ядра.  [c.386]

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


Что такое нисходящее проектирование  [c.62]

На последующих иерархических уровнях нисходящего проектирования САПР осуществляется разработка оригинальных составных частей КТС и ПМК.  [c.356]

Нисходящее и восходящее проектирование. Если решение задач высоких иерархических уровней предшествует решению задач более низких иерархических уровнен, то проектирование называют нисходящим. Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называют восходящим.  [c.19]

На практике обычно сочетают восходящее и нисходящее проектирование. Например, восходящее проектиро-  [c.19]

Типичная последовательность проектных процедур [2]. На рис. 1.3 представлена типичная последовательность проектных процедур на одном из этапов нисходящего проектирования.  [c.26]

На всех иерархических уровнях нисходящего проектирования, кроме самого верхнего, задача назначения ТТ может быть формализована и представлена как задача оптимального преобразования ТТ к выходным параметрам объекта на к-м уровне в ТТ к выходным параметрам частей объекта на (й-П)-м уровне.  [c.59]

Подпрограмма — часть программы, обладающая именем, которое позволяет этой программе (или всякой другой) вызывать ее, чтобы заставить выполнить некоторое действие. В виде подпрограмм целесообразно программировать действия, общие для ряда программ, и универсальные алгоритмы. Подпрограммы позволяют управлять сложностью программ, допуская сжато именовать сложные последовательности действий. На этом свойстве подпрограмм базируется методология нисходящего проектирования программ (см. 1.3). Подпрограмма, как и любая другая структура управления, должна иметь одни вход и одни выход, причем возврат управления из подпрограммы обязательно должен осуществляться в точку ее вызова.  [c.21]

Процесс проектирования ПО, как и любых других сложных объектов,— блочно-иерархический. Систематическое применение декомпозиции позволяет свести задачу большой размерности к совокупности простых подзадач. Принципиально возможны два подхода к проектированию ПО нисходящий и восходящий.  [c.40]

PDL. Программа, структура которой представлена на рис. 1.14, может быть описана средствами языка PDL па первом шаге нисходящего проектирования следующим образом  [c.40]

Достоинство нисходящего проектирования состоит в том, что оно позволяет разработчикам ПО сосредоточиться на основных для данного момента проблемах и отложить принятие всех тех решений, которые не должны приниматься на данном этапе проектирования.  [c.41]

Использование нисходящего проектирования ставит перед разработчиками ПО две серьезные проблемы.  [c.42]

Вто ,1ая проблема связана с тем, что нисходящее проектирование приводит к древовидной структуре ПО, и вполне вероятно, что в разных поддеревьях этой структуры окажутся модули с похожими, но не одинаковыми спецификациями. Конечно же, целесообразно объединить спецификации и разработать один универсальный модуль, однако это приведет к перепроектированию вызывающих модулей.  [c.42]


Подобно проектированию, кодирование (программирование) модулей ПО может осуществляться в двух направлениях 1) восходящем 2) нисходящем.  [c.44]

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

Создание ПО САПР —сложная научно-техническая задача, решение которой возможно лишь с привлечением современных методов разработки ПО. Процесс создания ПО состоит из шести основных этапов I) анализ требований 2) определение спецификаций 3) проектирование 4) кодирование модулей 5) тестирование 6) сопровождение. Наиболее ответственны ранние этапы разработки, на последний этап приходятся наибольшие затраты. Для повышения производительности труда разработчиков ПО предложен ряд методов и средств анализаторы требований, нисходящее проектирование, модульное и структурное программирование, генераторы прикладных программ и др.  [c.51]

Еще одним приемом, дисциплинирующим создание сложных программ, является составление нескольких уровней описаний алгоритма от наиболее общего до самого детального, и на каждом последующем уровне производится детализация предыдущего. В настоящее время совокупность таких приемов получила название нисходящего проектирования программ или проектирования сверху вниз. Сущность проектирования программ сверху вниз состоит в том, что их разработка производится мелкими шагами, на каждом из которых программист, как правило, принимает одно решение, конкретизирующее ранее полученное описание алгоритма.  [c.71]

При проектировании сверху вниз производится разбиение программы или ее частей на независимые фрагменты, которые программируются отдельно друг от друга. Использование на каждом уровне только стандартных структур позволяет получить структурированную программу. Таким образом, нисходящий способ разработки дает возможность организовывать модульные и структурированные программы.  [c.71]

Память оперативная 26 Планирование эксперимента 137 Подсистемы САПР 22 Показатели электродвигателей 115 Построение гистограмм 257 Принятие проектного решения 14 Программирование модульное 68 нисходящее 71 структурное 70 Проектирование предварительное 13 техническое 14 эскизное 13  [c.295]

Переход от одного уровня к другому может осуществляться как сверху вниз, так и снизу вверх. В первом случае - нисходящее проектирование, а во втором — восходящее проектирование. В книге основное внимание уделено нисходящему проектированию - от ТЗ на весь объект проектирования до проектной документации.  [c.14]

Во-вторых, это разумное сочетание элементов нисходящего и восходящего проектирования, при котором на ранних этапах проектирования ориентировочно распределяются задержки и мощности между блоками, что позволяет далее проектировать эти блоки независимо друг от друга. И если принятые ранее значения параметров блоков оказываются выполнимыми, то дополнительные итерации не требуются.  [c.135]

Структурные описания для сложных объектов являются иерархическими. Только структурных описаний недостаточно для задания объекта, нужно описывать также поведение (функции объекта). Поведенческое описание, как минимум, должно быть задано для сущностей нижнего иерархического уровня. Однако в практике проектирования СБИС превалирует нисходящий стиль, следовательно, проектирование начинается с разработки алгоритмов (поведенческих описаний) верхнего иерархического уровня.  [c.269]

Определение зависимости между напряжением и деформацией в пластической области имеет большое теоретическое и практическое значение при проектировании конструкций, работаюш,их при знакопеременном нагружении. К настоящему времени в литературе известны в основном два подхода к решению этой задачи. Один из них базируется на феноменологических представлениях с использованием классической теории упругости и пластичности, например [1—4], другой — на статистической теории дислокаций [5, 6]. На основании статистической теории дислокаций были получены зависимости между деформацией и напряжением начальной кривой деформации, нисходящей и восходящей ветвей симметричной петли механического гистерезиса. Эти зависимости представлены в виде бесконечных степенных рядов по величине приложенного напряжения, для которого можно считать плотность дислокаций постоянной. При достаточно больших напряжениях (деформациях) экспериментальные данные показывают, что плотность дислокаций изменяется, петли механического гистерезиса несимметричны и разомкнуты.  [c.159]


Блочно-иерархический подход к проектированию использует идеи декомпозиции сложных описаний объектов и соответственно средств их создания на иерархические уровни и аспекты, вводит понятие стиля проектирования (восходящее и нисходящее), устанавливает связь между параметрами соседних иерархических уровней.  [c.14]

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

Чаще всего применяют нисходящий стиль блочно-иерархического проектирования.  [c.32]

Рассмотрим этапы нисходящего проектирования АС.  [c.32]

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

Внешнее и внутреннее проектирование (1]. При нисходящем проектировании формулировка ТЗ на разработку элементов /г-го иерархического уровня относится к проектным процедурам этого же уровня. Иначе обстоит дело с разработкой ТЗ на систему высшего иерархического уровня или на унифицированную систему элементов, предназначенную для многих применении. Здесь разработка ТЗ является самостоятельным этапом проектирования, часто называемым внешним проектированием. В отличие от пего этапы проектирования обчзе <та по сформулированным ТЗ называют внутренним проектированием.  [c.20]

На предыдущем этапе решались задачи /г-го иерархического уровня, одним из результатов рещеиия этих задач при нисходящем проектировании является формулировка ТЗ на проектирование систем (/г+1)-го рассматриваемого уровня.  [c.26]

Ма рис. 1.6 показана схема маршрута технологической под г о т О в к и производства в м а ш и п о с т р о е-н и и [4]. Технологическое планирование для неоригинальных деталей отличается от технологического планирования для оригинальных детален. Для неоригинальных деталей технологический процесс иросктпруегся путем конкретизации и адаптации типового обобщенного технологического процесса, созданного ранее для рассматриваемого класса деталей. Для оригинальных детален выполняется нисходящее проектирование технологического процесса, состоящее из этапов проектирования принципиальной схемы, марщрутнон и операционной технологии, проектирования оснастки, ипструмента и синтеза управляющи.х программ для станков с ЧПУ.  [c.30]

Группа 1 задач параметрического синтеза связана с назначением технических требований к выходным параметрам объекта. На верхнем иерархическом уровне нисходящего проектирования или на каждом иерархическом уровне восходящего проектирования эта задача не может быть полностью формализована. Как правило, исходное ТЗ отражает потребности в новых технических изделиях, их назначение, опыт производства и использования прототипов и т. и. Это ТЗ формулируется на основе мнепи11 экспертов н требует дальнейшей ко]1кретизации и согласования. Существенной частью формируемого ТЗ должны стать перечень выходных параметров объекта и значения технических требований ТТ к ним, т. е. условия работоспособности у ТТ . Определение вектора технических требований ТТ — основная задача параметрического синтеза, решаемая при внешнем проектировании.  [c.59]

Нисходящее проектирование (пошаговая детализация) представляет собой последовательность шагов, уточняюших проект. Первый шаг — определение способа решения задачи в самых общих чертах. За первым шагом следуют мелкие шаги в направлении детализации алгоритмов и структур данных. В ходе этого процесса выделяются отдельные модули решения и данных, и дальнейшая конкретизация каждого модуля может производиться независимо. Специально для реализации стратегии нисходящего проектирования разработай язык проектирования программ PDL [4]. Он состоит из двух частей 1) заданного набора операторов,-построенных по образцу того языка программирования, на котором планируется вести кодирование компонентов ПО 2) предложений естественного языка. Для описания логики проектируемой программы используются управляющие структуры языка программирования (цикл, ветвление, вызов подпрограмм), а для описания данных и процедур их обработки — естественный язык.  [c.40]

Для реализации нисходящего проектирования разработаны технологии, наиболее известной из которых является методология HIPO на основе графических диаграмм (фирма IBM ). В этой методологии предусмотрено два вида диаграмм. С помощью иерархических диаграмм (подобных диаграмме, показанной на рис. 1.14)  [c.41]

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


Восходящее проектирование альтернативно методу пошаговой детализации. В то время как при нисходящем проектировании первоначальная задача разбивается иа подзадачи, которые потом пытаются реализовать, при восходящем проектировании, прежде чем приступить к решению задачи, создаются средства, позволяющие ее решить. Например, если необходимо спроектировать восходящим методом программу, аналогич-Т1ую программе, представленной на рис. 1.14, сначала проектируют модули АН и А12, затем добавляют модуль А1, использующий характеристики АП и А12, и т. д., пока не будет получен законченный проект ПО, отвечающий всем спецификациям.  [c.42]

В действительности при разработке ПО нисходящее и восходящее проектирования не используются по отдельности, а взаимно дополняют друг друга. Например, по восходящему методу первоначально создается инструментарий программистов — общие подпрограммы ввода-вывода, обслуживания структур данных, динамического распределения памяти и т. д. Дальнейшее проектирование ведется нисходящим методом. С использованием нисходящего метода проектируется состав модулей ПО, их функции и связи по управлению. Проектирование связей по информации на этой стадии носит эскизный характер. Детальная разработка межмодульных интерфейсов производится с использованием восходящего метода. Объясняется это следующим чем ниже уровень норархической структуры ПО, занимаемый модулем, тем чан1е этот модуль применяется, н следовательно, обстоятельство, удобен или нет гштерфейс модуля для его разработки, оказывает значительное влияние на эффективность всего ПО.  [c.43]

Рассмотренные выше передовые методы разработки ПО (Н1Р0 — технология, нисходящее проектирование, структурное ирограммирование, нисходящее тестирование, бригада главного црограммиста) были исиользованы фирмой ШМ для создания программной системы объемом свыше 80 тыс. операторов языка программирования, при этом была достигнута производительность труда G5 операторов/деиь па каждого программиста и 35 операторов/день на каждого члена бригады. Если учесть, что бригада возглавлялась программистом чрезвычайно высокой квалификации, а проект поддерживался фирмой с колоссальными возможностями, то можно предположить, что эти показатели близки к предельным. Однако темпы выпуска ЭВМ во всем мире продолжают расти (так, в США в настоящее время количество ежегодно выпускаемых ЭВМ превышает количество студентов, оканчивающих вузы), усиливаются потребности общества в системах ПО. Многие специалисты по электронной обработке данных связывают возможность разрешения этого противоречия с созданием и широким использованием генераторов прикладных программ. Например, такие интерактивные генераторы, как ADF и DMS, позволяют на несколько порядков повысить производительность труда программистов при разработке диалоговых прикладных программ для решения экономических задач. Практически для создания прикладного пакета требуется всего лишь несколько сеансов совместной работы системного аналитика и будущего пользователя за экраном дисплея, во время которых главным об-  [c.49]

Обычно учет физических характеристик, таких, как задержки в элементах и их соединениях, осуществляют на заключительных этапах. Если быстродействие схемы оказывается неудовлетворительным, приходится выполнять дополнительные витки в итерационном цикле проектирования, что заметно удлиняет сроки разработки. Чтобы избежать этого, стараются учитывать физические характеристики (в основном это задержки) на возможно более ранних этапах нисходящего проектирования. В частности, такой учет возможен при планировании кристалла (floorplanning) уже на системном уровне. Он заключается в определении ориентировочного взаимного расположения блоков структурной схемы на кристалле (при многокристальном исполнении блоки предварительно распределяются между кристаллами) и внешних выводов блоков. Это позволяет приблизительно оценить длины связей и, следовательно, задержки в передаче данных уже в самом начале разработки.  [c.129]

При нисходящем проектировании в предществующих процедурах приходится задаваться ориентировочными значениями данных, истинные значения которых становятся известными только после выполнения последующих процедур. Это обстоятельство обусловливает итерационный характер процесса проектирования с возвратами от последующих этапов к предыдущим, что, естественно, существенно увеличивает затраты на проектирование.  [c.135]

Выберем на конусе Штауде образующую q, ориентированную по юдному из своих направлений и имеющую относительно твердого тела направляющие косинусы fg) Tfa и предположим, что она совпадает (также и по стороне) с нисходящей вертикалью, проходящей через точку О. По предположению, направляющие косинусы fa, Ys Удовлетворяют уравнению (39 ), и все сводится к тому, чтобы убедиться, можно ли при соблюдении условия (39 ) определить, по крайней мере, одно действительное значение v, которое удовлетворяло бы уравнению (37). Это векторное соотношение, после проектирования на подвижные оси, дает три линейных уравнения относительно (уравнения Эйлера перманентного вращения тяжелого твердого тела)  [c.109]

Известные методы проектирования предполагают два подхода к проектированию при расчленении исходной системы на части и использовании принципа иерархичности. Если решение задач высоких иерархических уровней предшествует решению задач более низких нерархиче-еких уровней, то проектирование называется нисходящим. Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называется восходящим.  [c.169]

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


Смотреть страницы где упоминается термин Проектирование нисходящее : [c.298]    [c.387]    [c.19]    [c.40]    [c.127]    [c.137]    [c.32]   
Теоретические основы САПР (1987) -- [ c.9 ]

Основы автоматизированного проектирования (2002) -- [ c.18 ]

Основы теории и проектирования САПР (1990) -- [ c.10 , c.301 ]



ПОИСК



Проектирование автоматизированное нисходящее



© 2025 Mash-xxl.info Реклама на сайте