На чем основано нисходящее проектирование

Совершенный код: нисходящее и восходящее проектирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Преимущества нисходящего проектирования на примере использования Pro/ENGINEER WILDFIRE

Восходящий и нисходящий способы проектирования

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

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

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

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

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

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

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

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

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

Возможности Pro/ENGINEER WILDFIRE позволяют применять в одном проекте несколько «записных книжек» одновременно, что удобно при работе над большими проектами. Например, при разработке автомобиля можно создать отдельные «записные книжки» для двигателя, каркаса, подвески и т.д. и установить взаимосвязи между ними.

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

При построении геометрии каркасной модели ведущий конструктор устанавливает взаимосвязи между ее размерами и параметрами «записной книжки», что позволяет в дальнейшем при изменении параметров обеспечить автоматическое изменение всех связанных параметров в каркасной модели, а через нее — во всех компонентах сборки. Ведущему конструктору достаточно поменять размер или другой параметр в компоновке, и соответствующие изменения автоматически выполнятся во всех связанных деталях, узлах и чертежах. На рис. 7 отмечены зависимости, созданные в каркасной модели.

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

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

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

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

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

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

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

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

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

Продемонстрируем процесс внесения изменений при нисходящем проектировании на примере — увеличим высоту конструкции (см. рис. 4 а ) в разложенном состоянии, для чего в «записной книжке» изменим соответствующий параметр. После этого Pro/ENGINEER WILDFIRE автоматически просчитает все параметры, значения которых вычисляются с использованием уравнений, и выполнит проверку на корректность введенных значений в соответствии с заданными критериями. В нашем случае такая проверка показала, что высота увеличена слишком сильно и конструкция стала неустойчивой, а значит, необходимо увеличить и ее длину. На схеме (рис. 12) красным цветом показаны изменения, которые конструктор вносит вручную. После изменения параметров «записной книжки» каркасная модель обновляется автоматически (на рисунке показан новый каркас), а для обновления сборки достаточно выполнить команду «Перестроить» (Regenerate). Таким образом, изменение, внесенное конструктором на самом верхнем уровне — в «записной книжке инженера», повлекло за собой автоматические изменения на всех остальных уровнях — в сборке, в деталях, в чертежах.

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

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

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

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

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

Олег Гаршин

Руководитель подразделения «Системы автоматизированного проектирования и подготовки производства» инженерно-консалтинговой компании SOLVER.

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

Ведущий консультант отдела «Проектирование машин и конструкций» подразделения «САПР и ПП» компании SOLVER.

Источник

Привет студент

Проектирование (АС) Лекция 6.

Нисходящее проектирование БД

При «нисходящем» проектировании осуществляется структурное проектирование сверху—вниз («нисходящее» проектирование).

Этапы проектирования БД методом «нисходящего» проектирования представлены на рисунке.

Рисунок — Этапы проектирования БД методом «нисходящего» проектирования

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

На основе описания внешнего уровня строится концептуальная

Такой подход к проектированию БД называют также концептуальным или концептуальным проектированием.

В концептуальном подходе к проектированию БД выделяют следующие три

— реальный мир или объектную систему;

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

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

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

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

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

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

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

— преобразование ДЛМ в физическую модель БД, полученную на ЯОД выбранной СУБД (формирование внутреннего уровня БД).

Метод «нисходящего» проектирования достаточно формализован и используется в CASE (Computer Aided System/Software Engineering — компьютерное проектирование программного обеспечения и систем) средствах.

— особенно эффективно их использование при создании крупных корпоративных АИС большим коллективом разработчиков;

CASE—средства классифицируются по:

— поддерживаемым методологиям проектирования (структурно— ориентированные, объектно—ориентированные, комплексно—ориентированные);

— поддерживаемым графическим нотациям построения диаграмм$

— степени интегрированности (отдельные локальные средства, набор интегрированных средств, охватывающих большинство этапов разработки АИС)$

— по режиму коллективной разработки проекта (режим реального времени, режим объединения проектов) и ряду других.

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

Наиболее популярные приведены в таблице.

Источник

Вопрос 4. Восходящее и нисходящее проектирование

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

Кроме процедур детализации на иерархические уровни при блочно-иерархическом подходе к проектированию ЭС применяют расчленение представлений об изделии на ряд аспектов по характеру отображаемых свойств.

К числу основных аспектов относятся функциональный, конструкторский и топологический.

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

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

На системном уровне в качестве систем фигурируют комплексы, а в качестве элементов – блоки аппаратуры.

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

На схемотехническом уровне эти блоки рассматриваются как системы, состоящие из схематических компонентов.

На компонентном уровне сами компоненты рассматривают как системы и рассматривают процессы, протекающие в схематических компонентах.

Конструкторскому аспекту соответствует иерархия конструктивов, включающая уровни описания компонентов изделия, дискретных элементов и микросхем и топологических фрагментов.

В технологическом аспекте рассматриваются иерархические уровни описания технологических процессов в виде маршрутов проектирования, совокупности операций и переходов.

В зависимости от того в какой последовательности выполняются проектные процедуры различают два способа проектирования:

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

Нисходящее проектирование – это проектирование сверху вниз, и характеризуется противоположной последовательностью выполнения процедур.

Типичная последовательность процедур нисходящего проектирования ЭС, включает в себя:

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

— схемотехническое проектирование – это разработка функциональных и принципиальных схем.

— конструкторское проектирование – это выбор формы, компоновки и размещения конструктивов, трассировка межсоединений и разработка конструкторской документации.

— технологическое проектирование – это разработка маршрутов и технологической базы, выбор оснастки.

Нисходящее проектирование (рис. 3).

Рис. 3 Последовательность этапов нисходящего проектирования ЭС

Типичная последовательность процедур восходящего проектирования включает в себя (рис. 4).:

Приборно-технологическое проектирование – это выбор базовой технологии, расчёт диффузии профиля, выбор топологии компонентов.

Схемотехническое проектирование – это синтез принципиальной электрической схемы, оптимизация параметров элементов.

Функционально-логическое проектирование – это синтез логических схем, реализация памяти, синтез контролирующих и проверяющих тестов.

Конструкторско-технологическое проектирование – это размещение элементов, трассировка межсоединений, проверка соответствия топологических и электрических схем, вычерчивание послойной топологии.

Рис. 4 Последовательность этапов восходящего проектирования, характерная для проектирования интегральных схем (ИС)

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

Алгоритм получения проектного решения представлен на рисунке 5

Рис. 5 Алгоритм выполнения проектной процедуры

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

Источник