Низхідне проектування. Open Library - відкрита бібліотека навчальної інформації Висхідне проектування

0

(Лекція 5)

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

Метою проектування БД є адекватне відображення у базі даних суті предметної області, що розглядається з погляду вирішення завдання автоматизації.

Теоретично баз даних існує низка методів розробки моделей БД, що відображають різні рівні її архітектури. Поширені два основні підходи до проектування систем баз даних: "низхідний" і "висхідний".

Відомий також підхід "змішаної стратегії" - спочатку "висхідний" і "низхідний" методи використовуються для різних частин моделі, після чого всі підготовлені фрагменти збираються в єдине ціле.

Розглянемо на малюнку відмінність цих методів

Малюнок - Вибір методу проектування

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

При «висхідному» підході здійснюють структурне проектування знизу вгору. Цей процес називають процесом синтезу, спробою отримання цілого, що адекватно відображає опис предметної області, на основі опису складових його частин.

Етапи проектування БД шляхом «висхідного» проектування представлені малюнку 2.

ДЛМ – даталогічна модель; НФ – нормальна форма; ІЛМ -інформаційно-логічна модель предметної галузі; МБД – модель БД.

Малюнок 2 - Етапи проектування БД методом «висхідного» проектування

p align="justify"> Робота для реляційної БД починається з визначення властивостей об'єктів (атрибутів сутностей) предметної області, які на основі аналізу існуючих між ними зв'язків групуються в реляційні відносини (таблиці), що відображають ці об'єкти (у тому випадку, якщо ми проектуємо структуру реляційної БД).

Як правило, отримують 2 - 3 реляційні відносини, пов'язані між собою.

Надмірність даних у ненормалізованій схемі - повторення даних у БД.

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

Значний обсяг заходів щодо нормалізації схем реляційних відносин навіть дав другу назву методу «висхідного» проектування. Цей метод часто називають методом нормалізації.

Основи теорії нормалізації створив Е. Кодд.

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

Сукупність схем відносин називається схемою реляційної БД.

Нормалізація виключає надмірність та аномалії в БД.

Аномалії у ненормалізованій схемі відношення:

а) оновлення - суперечливість даних, викликана їх надмірністю та частковим оновленням.

Приклад: Схема2

(Код викладача, ПІБ викладача, Код кафедри, Назва кафедри, Коротка назва кафедри, Код посади, Назва посади)

б) аномалія видалення - ненавмисна втрата даних, спричинена видаленням інших даних

в) аномалія введення - неможливість запровадити дані таблицю, викликана відсутністю інших даних.

Схема2 (Код викладача, ПІБ викладача, Код кафедри, Назва кафедри, Коротка назва кафедри, Код посади, Назва посади)

Етапи проектування БД методом нормалізації:

1. Визначення всіх атрибутів, відомості про які будуть включені до БД-збіру сирих даних на підприємстві.

2. Упорядкування списку сирих даних як схем реляційних відносин. Отримана результаті схема відносин перебувають у нульової нормальної формі (0НФ).

3. Приведення схеми ставлення до 1НФ

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

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

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

Видалення груп, що повторюються.

ПГ: ЗАМОВЛЕННЯ (Номер замовника, Ф.,І.,О., тел., дата, Номер замовлення)

Первинний ключ - Номер замовника, Дата, Номер замовлення (якщо одного дня замовник може оформити більш ніж одне замовлення)

Група, що повторюється: Ф,І,О, телефон - повторюються в кожному новому записі при формуванні інформації про нове замовлення, хоча ця інформація відноситься до частини складового ключа - Номер замовника.

Потрібно винести на окрему схему відносин:

ЗАМОВЛЕННЯ (№ замовника, дата, № замовлення)

ФІЗИЧНЕ ОБЛИЧЧЯ (№ замовника, Ф,І,О, телефон)

Зв'язок 1:М між двома новими схемами відносин, «багато» на стороні відносини ЗАМОВЛЕННЯ.

Кожна ФІЗИЧНА ОБЛИЧЧЯ може оформити багато ЗАМОВЛЕНЬ.

Кожен конкретний ЗАМОВЛЕННЯ оформлений одним і тільки одним ФІЗИЧНИМ ОБЛИЧЧЯМ.

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 – робота на тренажерах і т.д. і з кожного виду підбивався результат. З'явився атрибут, що додатково описує вид занять, причому числовий. Його необхідно додати у схему відношення і зробити атрибутом первинного ключа, замінивши таким чином довге символьне поле.

Отримали схему відношення:

ПК – первинний ключ – номер інструктора; Код виду занять

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

Зміна держномера автомобіля (автомобіль списали) поведе за собою необхідність зміни цього поля у всіх рядках, де він згадується (фіксуємо лише фотографію моменту - за ким був останнім закріплений автомобіль, але таких людей м.б. декілька і для їх виявлення необхідно зробити певну роботу , причому роботу адміністратора БД).

Явна надмірність – повторення назви виду занять.

Неявна надмірність – зміна держномера автомобіля.

Подальшим, необхідним нормалізації, етапом роботи є визначення залежностей між атрибутами з урахуванням семантики предметної області.

Завантажити лекцію: У вас немає доступу до завантаження файлів з нашого сервера.

Проектуючи нові вироби з використанням тривимірних САПР, на підприємствах зазвичай застосовують висхідний метод(Рис. 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

Метод низхідного проектування пропонує послідовне розкладання загальної функції розробки даних на прості функціональні елементи («зверху-вниз»).

В результаті будується ієрархічна схема, що відображає склад і взаємопідпорядкованість окремих функцій, що зветься функціональна структура алгоритму (ФСА) додатка.

Послідовність дій щодо розробки функціональної структури алгоритму застосування:

· Певна мета автоматизації предметної області та їх ієрархія (ціль-підціль);

· Встановлює склад додатків (завдань обробки), що забезпечують реалізацію поставлених цілей;

· Уточнюється характер взаємозв'язку додатків та їх основні характеристики (інформація для вирішення завдань, час та періодичні рішення, умови виконання та ін.);

· Визначається необхідність для вирішення завдань функції обробки даних;

· Виконується декомпозиція функцій обробки до необхідної структурної складності, що реалізується пропонованим інструментарієм;

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

Розкладання має суворо функціональний характер, тобто. окремий елемент ФСА визначає закінчену змістовну функцію обробки інформації, яка передбачає певний спосіб реалізації на програмному рівні. Функції введення-виведення інформації рекомендується відокремлювати від функцій обчислювальної чи логічної обробки даних.

За частотою використовувані функції поділяються на:

· Одноразово виконувані;

· Повторювані;

Ступінь деталізації функцій може бути різною, але ієрархічна схема повинна давати уявлення про склад та структуру взаємопов'язаних функцій та загальний алгоритм обробки даних. Широко використовувані функції набувають рангу стандартних функцій при проектуванні внутрішньої структури програмного продукту.

Модульне проектування

Модульне проектування (програмування) – засноване на поняття модуля – логічних взаємопов'язаних сукупністю функціональних елементів, оформлених у вигляді окремих програмних модулів.

Модуль характеризується:

· один вхід та один вихід –на вході програмний модуль отримує окремий набір вихідних даних, виконані містять обробку та повертається один набір результатних даних, тобто. реалізує стандартний принцип IPO(Input->Process->Output) - вхід - процес - вихід;

· функціональна завершеність –модуль виконує перелік регламентуючих операцій для реалізації кожної окремої функції у повному складі, достатніх для завершення розпочатої обробки;

· логічна незалежність –результат роботи програмного модуля залежить від вихідних даних, але з залежить від роботи інших модулів;

· слабкі інформаційні зв'язки з іншими програмними модулями– обмін інформацією між модулями має бути по можливості мінімізованим;

· оглядовий за розміром та складністю програмний елемент;

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

Функції верхнього рівня забезпечені головним модулем, він керує виконанням функцій нижче, яким відповідає підлеглі модулі.

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

· Кожен модуль викликається на виконання вищестоящим модулем і закінчує роботу, що повертає управління модуля, що його викликав;

· Прийняття основних рішень в алгоритмі виноситься на максимально «високий» за ієрархією рівень;

· Для використання однієї і тієї ж функції у різних місцях алгоритму створюється один модуль, який викликається на виконання в міру необхідності;

Об'єктно-орієнтоване проектування

Об'єктно-орієнтований підхід до проектування програмного продукту ґрунтується на:

· Виділенні класів об'єктів;

· Встановленні характерних властивостей об'єктів та методів їх обробки;

· Створення ієрархії класів, успадкування властивостей об'єктів та методів їх обробки;

Кожен об'єкт поєднує як дані, і програму обробки цих даних і належить до певного класу. За допомогою класу один і той же програмний код можна використовувати для різних об'єктів, що до нього належать.

Об'єднаний підхід розробки алгоритмів і програм передбачає:

· Об'єктно-орієнтований аналіз предметної області;

· Об'єктно-орієнтоване проектування;

· Об'єктно-орієнтований аналіз – аналіз предметної області та виділення об'єктів, певних властивостей та методів обробки об'єктів, встановлених їх взаємозв'язків;

Об'єктно-орієнтоване проектування поєднує процес об'єктної декомпозиції та подання з використанням модулів даних проектованої системи на логічних та фізичних рівнях у статистиці та динаміці.

Для проектування програмного продукту розроблено об'єктно-орієнтовані та інструментальні засоби розробки інтерфейсу користувача.

Висновок: об'єктно-орієнтована технологія розробки програмного продукту поєднує дані та процеси в логічні сутності – об'єкти, які мають здатність успадковувати характеристики (методи та дані) одного або більше об'єктів, що забезпечують тим самим повторним використанням програмного коду. Це призводить до значного зменшення витрат на створення програмного продукту, що підвищує ефективність життєвого циклупрограмного продукту (зменшується тривалість фази розробки). Під час виконання програми об'єкту надсилається повідомлення, яке ініціює обробку даних об'єкта.

5. Індивідуальне завдання

5.1 Постановка задачі

Автоматизована інформаційна довідкова система ЗМК

Організаційно-економічна сутність завдання

Розроблена програма є прикладом програм для ЗМК та називається «Форма заповнення реалізації замовлення». За допомогою цієї програми можна значно швидше оформити замовлення продукції. Періодичність розв'язання задач: щодня. Дані в програму надходять із бази даних, яку користувач заповнює, здійснюючи замовлення.

5.1.2 Опис вхідної інформації

Вхідна інформація міститься у базі даних з такою назвою: Замовлення.mdb. база даних містить такі поля з типами даних:

Таблиця 1.

Код	Лічильник
Дата	дата та час
Код дверей	Короткий текст
Організація	Короткий текст
Підрозділ	Короткий текст
Дата запуску	дата та час
дата виконання	дата та час
Відповідальний	Короткий текст

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

Такий підхід зручний тим, що дозволяє людині постійно мислити на предметному рівні, не опускаючись до конкретних операторів та змінних. Крім того, з'являється можливість деякі підпрограми не реалізовувати одразу, а тимчасово відкладати, доки не будуть закінчені інші частини. Наприклад, якщо є необхідність обчислення складної математичної функції, виділяється окрема підпрограма такого обчислення, але реалізується вона тимчасово одним оператором, який просто надає заздалегідь обране значення (наприклад, 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, тому що дві оцінки, найбільшу та найменшу, враховувати не треба.

Якби це завдання вирішувалося послідовно, то вже на етапі видалення оцінок могли б виникнути певні проблеми.

Реалізацію підпрограм Номер_самого_великого_елемента_в_масиві та Номер_ самого_маленького_елемента_в_масиві виконайте самостійно.

Якщо розв'язання задач високих ієрархічних рівнів передує розв'язанню задач нижчих ієрархічних рівнів, то проектування називають низхідним(покрокова деталізація). Якщо раніше виконуються етапи, пов'язані з нижчими ієрархічними рівнями, проектування називають висхідним.

У кожного з цих двох видів проектування є переваги та недоліки. При низхідному проектуванні система розробляється в умовах, коли її елементи ще не визначені і, отже, відомості про їх можливості та властивості мають ймовірний характер. При висхідному проектуванні, навпаки, елементи проектуються раніше за систему, і, отже, ймовірний характер мають вимоги до елементів. В обох випадках через відсутність вичерпної вихідної інформації мають місце відхилення від потенційно можливих оптимальних технічних результатів. Однак слід пам'ятати, що подібні відхилення неминучі при блочно-ієрархічному підході до проектування і будь-якої прийнятної альтернативи блочно-ієрархічному підходу при проектуванні складних об'єктів не існує. Тому оптимальність результатів блочно-ієрархічного проектування слід розглядати з позицій техніко-економічних показників, що включають, зокрема матеріальні та тимчасові витрати на проектування.

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

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

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