Переводы с мобильного 

Нисходящее проектирование. Нисходящее и восходящее проектирование. Имеет смысл рассматривать полную и частичную ФЗ в том случае, если ПК - составной

0

(Лекция 5)

Методы проектирования БД

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

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни её архитектуры. Распространены два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

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

Рассмотрим на рисунке отличие этих методов


Рисунок - Выбор метода проектирования

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

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

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


ДЛМ - даталогическая модель; НФ - нормальная форма; ИЛМ -информационно-логическая модель предметной области; МБД - модель БД.

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

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

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

Избыточность данных в ненормализованной схеме - повторение данных в БД.

Для того чтобы полученная структура БД (ДЛМ) не обладала различными аномалиями при добавлении, обновлении или удалении данных вследствие их избыточности, необходимо осуществить проверку каждой полученной схемы отношения, как минимум, на соответствие 3НФ. Если схемы отношений не соответствуют этому условию, а они, как правило, не соответствуют, необходимо проводить процесс нормализации.

Значительный объем мероприятий по нормализации схем реляционных отношений даже дал второе название методу «восходящего» проектирования. Этот метод часто называют методом «нормализации».

Основы теории нормализации создал Э. Кодд.

Нормализация - это процесс проектирования в терминах РМД методом последовательных приближений к удовлетворительному набору схем.

Совокупность схем отношений называется схемой реляционной БД.

Нормализация исключает избыточность и аномалии в БД.

Аномалии в ненормализованной схеме отношения:

а) обновления - противоречивость данных, вызванная их избыточностью и частичным обновлением.

Пример: Схема2

(Код преподавателя, ФИО преподавателя, Код кафедры, Название кафедры, Краткое название кафедры, Код должности, Название должности)

б) аномалия удаления - непреднамеренная потеря данных, вызванная удалением других данных

в) аномалия ввода - невозможность ввести данные в таблицу, вызванная отсутствием других данных.

Схема2 (Код преподавателя, ФИО преподавателя, Код кафедры, Название кафедры, Краткое название кафедры, Код должности, Название должности)

Этапы проектирования БД методом нормализации:

1. Определение всех атрибутов, сведения о которых будут включены в БД -сбор сырых данных на предприятии.

2. Составление списка сырых данных в виде схем реляционных отношений. Полученная в итоге схема отношений находятся в нулевой нормальной форме (0НФ).

3. Приведение схемы отношения к 1НФ

Опр. 1НФ: Схема отношения находится в 1НФ тогда и только тогда, если все атрибуты схемы имеют атомарное значение и в схеме отношений отсутствуют повторяющиеся группы.

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

Разбиение схемы отношения на атомарные атрибуты.

Удаление повторяющихся групп.

ПГ: ЗАКАЗ (Номер заказчика, Ф.,И.,О., тел., дата, Номер заказа)

Первичный ключ - Номер заказчика, Дата, Номер заказа (если в один день заказчик может оформить более чем один заказ)

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

Нужно вынести в отдельную схему отношений:

ЗАКАЗ (№ заказчика, дата, № заказа)

ФИЗИЧЕСКОЕ ЛИЦО (№ заказчика, Ф,И,О, телефон)

Связь 1:М между 2-мя новыми схемами отношений, «много» на стороне отношения ЗАКАЗ.

Каждое ФИЗИЧЕСКОЕ ЛИЦО может оформить много ЗАКАЗОВ.

Каждый конкретный ЗАКАЗ оформлен одним и только одним ФИЗИЧЕСКИМ ЛИЦОМ.

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

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

5. Если отношение обладает несколькими потенциальными ключами, то нужно выбрать среди них кандидата в первичный ключ.

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

Опр.: функциональной зависимостью атрибута В (набора атрибутов) отношения R от атрибута (набора атрибутов) А отношения R, обозначаемой R.A -> R.B A->B

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

Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А.

Таким образом, если из семантики предметной области нам известно значение атрибута А, то мы в предметной области однозначно можем определить значение атрибута В.

ФЗ является смысловым свойством атрибутов отношения.

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

Опр.: ключевой атрибут - атрибут, входящий в состав первичного ключа Опр.: не ключевой атрибут - атрибут, не входящий в состав первичного ключа.

Опр.: частичная ФЗ - это зависимость не ключевого атрибута от части составного первичного ключа.

Опр.: полная ФЗ - это зависимость не ключевого атрибута от всего составного первичного ключа.

Имеет смысл рассматривать полную и частичную ФЗ в том случае, если ПК - составной.

Работа(Номер школы (ВК1); Номер инструктора (ПК); Фамилия инструктора; Имя инструктора; Отчество инструктор; Серия паспорта; Номер паспорта; Дата принятия на работу; Госномер автомобиля; Код вида занятий (ВК3))

Функциональные зависимости:

Номер инструктора -> Номер школы Номер инструктора -> Фамилия инструктора Номер инструктора -> Имя инструктора

Номер инструктора -> Отчество инструктора Номер инструктора - >Серия паспорта Номер инструктора -> Номер паспорта Номер инструктора - >Код образования Номер инструктора - >Дата принятия на работу Номер инструктора - >Госномер автомобиля

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

Для приведения к 2НФ необходимо выявит подмножество ФЗ не ключевых атрибутов от составного первичного ключа. Сколько не ключевых атрибутов -столько ФЗ!

Замечание: полное множество ФЗ определяется на основе аксиом и теорем теории множеств.

7. Приведение схемы отношения к 2НФ Технология приведения ко 2НФ:

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

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

Сколько частей первичного ключа образовали частичные ФЗ, столько схем получаем

3) Исходная схема удаляется.

8. Определение транзитивных зависимостей в каждом нормализуемом отношении

Опр.: транзитивная зависимость - атрибут С отношения R транзитивно зависит от атрибута А отношения R, если для атрибутов А, В, С выполняется условие существования следующих ФЗ:

при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.

9. Удаление транзитивных зависимостей путем декомпозиции схем отношений

10 Определение условий необходимости анализа схем отношений на соответствие НФБК (нормальной формы Бойса - Кодда - BCNF)

Эта нормальная форма вводит дополнительное ограничение по сравнению с

Опр.: Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант отношения является потенциальным ключом отношения.

Опр.: Детерминантом ФЗ называется атрибут (набор атрибутов),

расположенный в левой части ФЗ, т.е. от детерминанта функционально полно зависит некоторый другой атрибут (атрибуты)

В отношении м.б. несколько детерминантов

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

Таким образом, НФБК учитывает ФЗ, в которых участвуют все потенциальные ключи отношения, а не только ПК.

На практике такая ситуация встречается достаточно редко, и для всех прочих отношений 3NF и BCNF эквивалентны.

Для отношения с единственным потенциальным ключом его 3НФ эквивалентна и НФБК.

Таким образом, для успешного проведения нормализации (до 3НФ) необходимо на основе анализа предметной области (анализа документов

предметной области) для каждой схемы реляционного отношения:

Выявить потенциальные ключи;

Увидеть повторяющиеся группы и не атомарные атрибуты;

Привести схемы отношения к 1НФ;

Определить функциональные зависимости между не ключевыми атрибутами и первичным ключом;

Определить частичные функциональные зависимости;

Осуществить декомпозицию (деление) соответствующих схем отношений для удалений частичных функциональных зависимостей;

Увидеть транзитивные зависимости между не ключевыми атрибутами и первичным ключом;

Исключить транзитивные зависимости путем декомпозиции

соответствующих схем отношений.

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

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

Рассмотрим на рисунке схему процесса нормализации


Рисунок - Схема процесса нормализации

«Восходящее» проектирование - это достаточно сложная и устаревшая методика, которая подходит для проектирования только небольших баз данных.

Предметная область - автоматизация учета личных данных инструкторов сети школ авто вождения.

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

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

Номер школы;

ФИО инструктора;

Дата рождения;

Номер, серию паспорта;

Дата принятия на работу;

Госномер автомашины, которая закреплена за инструктором (необходимо хранить

последнюю запись - желание заказчика, хотя по-хорошему надо хранить историю);

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

Выявленные ограничения предметной области:

Все данные должны быть обязательными.

За одним автомобилем м.б. закреплено несколько инструкторов.

Номер сотрудника уникальный в пределах всей ИС, охватывающей сеть школ.


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

Поле "вид занятий" символьное, что нежелательно для атрибута, входящего в состав первичного ключа. В ходе дальнейшего анализа предметной области был выявлен документ, который перечислял существующие виды занятий автошколы, причем, записи были пронумерованы в шапке отчетного документа- 1 - руководство школой; 2- чтение теоретического курса; 3 - работа на тренажерах и т.д. и по каждому виду подводился итог. Появился атрибут, дополнительно описывающий вид занятий, причем числовой. Его необходимо добавить в схему отношения и сделать атрибутом первичного ключа, заменив, таким образом, длинное символьное поле.

Получили схему отношения:


ПК - первичный ключ - Номер инструктора; Код вида занятий

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

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

Явная избыточность - повторение названия вида занятий.

Неявная избыточность - изменение госномера автомобиля.

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

Скачать лекцию: У вас нет доступа к скачиванию файлов с нашего сервера.

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

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

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

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

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

1. Процесс решения наиболее просто описывается подпрограммами:

Ввести_оценки_в_массив;

Удалить_самую_большую_оценку;

Удалить_самую_маленькую_оценку;

Вывести_результаты;

Теперь можно приступить к детализации каждой их этих подпрограмм.

2. Удалить_самую_большую_оценку;

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

I = Номер_самого_большого_элеменша_в_массиве;

3. Удалить_самую_маленькую_оценку;

I = Номер_самого_маленького_элемента_в_массиве;

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

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

FOR I = 1 ТО N

SUM = SUM + Ocenki(I)

SUM = SUM / (N - 2)

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

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

Реализацию подпрограмм Номер_самого_большого_элемента_в_массиве и Номер_ самого_маленького_элемента_в_массиве выполните самостоятельно.

1. Суть нисходящего проектирования. Материал: файл tema_3vopr1.doc

2. Пример нисходящей разработки.

Материал: файлы tema_3vopr2.doc, plan_nish_otl. doc, primer2.doc

3. Условия успешного применения и оценка нисходящего подхода.

Материал: файл tema_3vopr3&4.doc

4. Восходящий подход как «традиционная» альтернатива нисходящему. Соотношение подходов

Материал, общий для тем 3 и 4: схемы нисходящей и восходящей отладки – файлы
nishotl. doc, voshotl. doc; принципы тестирования - файл test_bas. doc (выдавались на лабора-
торных работах).

1. Суть нисходящего проектирования

В сокращенном виде материал по нисходящей разработке был представлен в лабораторной работе 1.

· Нисходящая разработка как двухкомпонентный процесс поуровневого проектирования и отладки

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

· Общая характеристика нисходящего проектирования

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

Предлагаемый подход может рассматриваться как синтез классического нисходящего подхода и более поздней методики потоков работ (Workflow methodology).

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

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

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

· Общая схема

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

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

Процесс нисходящей разработки является иерархическим. Схема его приведена на рис. 3.1.

Рис. 3.1. Общая схема нисходящего проектирования

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

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

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

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

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

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

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

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

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

· Механизм процедур как адекватное средство реализации нисходящего подхода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«САПР и графика» 11"2004

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

Наименование параметра Значение
Тема статьи: Вопрос 4. Восходящее и нисходящее проектирование.
Рубрика (тематическая категория) Производство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- системно-техническое проектирование - ϶ᴛᴏ анализ тактико-технических требований на проектировании комплекс определœенных основ принципов функционирования, выработка структурных схем.

- схемотехническое проектирование - ϶ᴛᴏ выработка функциональных и принципиальных схем.

- конструкторское проектирование - ϶ᴛᴏ выбор формы, компоновки и размещения конструктивов, трассировка межсоединœений и выработка конструкторской документации.

- технологическое проектирование - ϶ᴛᴏ выработка маршрутов и технологической базы, выбор оснастки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка - установление соответствия качества предмета (продукта разработки) предъявляемым требованиям.

Вопрос 4. Восходящее и нисходящее проектирование. - понятие и виды. Классификация и особенности категории "Вопрос 4. Восходящее и нисходящее проектирование." 2017, 2018.