Організаційне забезпечення cапр

Організаційне забезпечення CАI7P включає в себе комплект до­кументів (наказів, положень, штатних розкладів, інструкцій, графі­ків робіт та ін.), що встановлюють правила виконання автоматизо­ваного проектування. Прикладами таких документів є інструкція користувача САПР, інструкція з експлуатації технічних засобів, по­садова інструкція системного адміністратора і т.д.

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

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

Документи, що входять до складу методичного забезпечення САПР, регламентують порядок (технологію) її експлуатації. У них викладені теорія, методи, способи, математичні моделі, алгоритми, алгоритмічні і спеціальні мови для опису об’єктів, термінологія, но­рмативи та інші дані, що розкривають методологію (ідеологію) фу нкціонування системи.

Методичне забезпечення сапр

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

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

HIPO технологія проектування програмного забезпечення

Фірма IBM створила методологію діаграм вхід-обробка-вихід (низхідне проектування), тобто, HIPO (Hierarchical Input-Processing-Output., або специфікація інтерфейсів. Згідно з даним підходом структура програми представляється у такому вигляді(рис.7.2)

Специфікації 1…………………………………………… 2…………………………………………… 3…………………………………………….

Рис.15.1 Ієрархична блок-схема програми

Головне полягає в тому, що використовується деякий формалізований і регламентований підхід до документування. Діаграми IPO є основними в технології. У діаграмах виділено 3 колонки. У лівій записується вхідна інформація (та, що подається на вхід алгоритму), в середній описаний процес (алгоритм), в правій - вихідна інформація.

Рис.15.2 IPO- діаграма

Мова заповнення IPO діаграм не обмовляється і може бути будь-яким. Кожна діаграма відповідає одному рівню (кроку) проектування. На одній діаграмі має бути не більше 6-7 програмних блоків, що уточнюють назву (характер) роботи. Це заставляє проектувальника системи розбивати її по рівнях на невелике число підсистем і побудувати для всієї системи деяке дерево розглядів проектування. Назва, що привласнюється одному блоку має бути коротким, загальноприйнятим і обов'язково зберігатися без змін у всіх діаграмах системи. При необхідності кожна назва може бути довизначена і розширена в спеціальної області, званою областю специфікацій. Всі IPO діаграми мають строго формалізовану систему заслань, які задаються наочно на HIPO діаграмах. Якщо якийсь блок уточнюється іншими IPO діаграмами, то йому привласнюється відповідний номер. Якщо блок не має уточнюючого номера зв'язку, то його деталізація закінчена, і він може бути безпосередньо закодований на на мові програмування. Формалізована система заслань дозволяє проектувальникові і адміністраторові легко стежити і впливати на процес розробки системи.

Лекція 16 Управління даними в САПР

1. Особливості управління проектними даними в САПР

2. Варіанти управління даними в мережах САПР

3. Розподілені бази даних

Особливості управління проектними даними в САПР

Розглянемо детальніше таку функцію системних середовищ САПР як управління даними.

Як вже наголошувалося, БД в САПР є важливою обслуговуючою підсистемою, він виконує функції інформаційного забезпечення і має ряд особливостей. У нім зберігаються як рідко змінні дані (архіви, довідкові дані, типові проектні рішення), так і відомості про поточний стан різних версій виконуваних проектів. Як правило, БД працює в розрахованому на багато користувачів режимі, з його допомогою здійснюється інформаційний інтерфейс (взаємодія) різних підсистем САПР. Побудова БД САПР - складне завдання, що обумовлене наступними особливостями САПР [1].

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

2. Нерідко обміни повинні проводитися з високою частотою, що пред'являє жорсткі вимоги до швидкодії засобів обміну (вважають, що СУБД повинна працювати із швидкістю обробки тисяч суті в секунду).

3. У САПР проблема цілісності даних виявляється важчою для вирішення, чим в більшості інших систем, оскільки проектування є процесом взаємодії багатьох проектувальників, які не тільки прочитують дані, але і змінюють їх, причому значною мірою працюють паралельно. З цього факту витікають слідства:

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

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

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

5. Ієрархічна структура проектних даних і, отже, віддзеркалення спадкоємства в цілях скорочення об'єму БД.

До певної міри названі особливості враховуються в СУБД третього покоління, в яких стали застосовуватися риси об'єктно-орієнтованих (об'єктних) СУБД. У них набори даних, що характеризують стан предметної області (стан проекту у разі САПР), поміщаються в окремі файли. Інтерпретація семантики даних здійснюється за допомогою спеціальних процедур (методів), супроводжуючих набори. Спадкоємство властивостей об'єктів предметної області виражається за допомогою введення категорій класу, надкласу, підкласу. Інформаційні моделі додатків для таких СУБД розробляються на основі методик типа IDEF1X.

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

Разом з чисто об'єктними СУБД (ODBMS), застосовують СУБД об'єктно-реляційні. У останніх відбувається об'єднання властивостей реляційних і об'єктно-орієнтованих СУБД: об'єктно-орієнтована СУБД забезпечується не процедурною мовою запитів або в реляційну СУБД вводяться спадкоємство властивостей і класи. Непроцедурность вхідної мови забезпечується використанням мови SQL. Його оператори безпосередньо включаються в програми на мові С. Можливо написання додаткових програм, що інтерпретують SQL-запити.

Відмітні особливості СУБД третього покоління:

­ розширений набір можливих типів даних (це абстрактні типи, масиви, множини, записи, композиції різних типів, відображення величин із значеннями різних типів);

­ відвертість (доступність з різних мов програмування, можливість звернення до прикладних систем з СУБД);

­ непроцедурность мови (загальноприйнятою стає мова запитів SQL)

­ управління асинхронними паралельними процесами, стан яких відображає БД.

Остання властивість дозволяє говорити про тісний взаємозв'язок СУБД і підсистеми управління проектами DESPM (Design Process Manager).

Названі особливості управління даними в САПР знайшли свій вираз в сучасних підсистемах управління проектними даними PDM.

У PDM різноманітність типів проектних даних підтримується їх класифікацією і відповідним виділенням груп з характерною безліччю атрибутів. Такими групами даних є описи виробів з різних точок зору (аспекти). Для більшості САПР машинобудування характерними аспектами є:

­ властивості компонентів і складок (ці відомості називають Bill of materials - BOM)

­ моделі і їх документальний вираз (основними прикладами можуть служити креслення, 3D-модели візуалізації, сіткові уявлення для звичайно-елементного аналізу, текстові описи)

­ структура виробів, що відображає взаємозв'язки між компонентами і складками і їх описами в різних групах.

Унаслідок великого об'єму проектних даних і наявності ряду версій проектів PDM повинна володіти розвиненою системою пошуку потрібних даних по різних критеріях.

Розглянуті особливості БнД в САПР дозволяють кваліфікувати їх як системи Data Warehouse (DW), тобто сховища даних. Для сховищ даних характерний ряд особливостей, співпадаючих з названими вище особливостями БнД САПР, а саме:

1) тривале зберігання інформації, що відображає історію розробок;

2) частота операцій читання даних вища за частоту операцій оновлення даних;

3) використання єдиних форматів для однотипних даних, отриманих з різних джерел (наприклад, від різних програмно-методичних комплексів).

Ці особливості дозволяють управляти конфігурацією проектів, що, зокрема, означає зберігання в САПР всіх версій проекту і, можливо, даних за проектами попередніх розробок, задоволення складних запитів, для відповіді на які потрібне витягання і обробка даних з різних частин сховища (так звана багатовимірна обробка). Моделі даних в DW відрізняються від реляційних моделей (RM), тому що у RM використанням нормальних форм прагнуть максимально зменшити надмірність даних, що приводить до збільшення числа таблиць, але зменшених розмірів, проте багатовимірний пошук, потрібний в DW, в безлічі таблиць утруднений. Тому в DW частіше використовується модель даних «зірка», в якій є загальна таблиця фактів (Fact Table) і кожному факту ставиться у відповідність декілька таблиць з необхідними атрибутами. Цілісність даних в DW забезпечується перевіркою і трансформацією даних (data cleaning), що вводяться із зовнішніх джерел, наявністю дисципліни оновлення даних, централізованим зберіганням основної бази, при цьому достатня швидкодія підтримується передачею копій певних частин бази в локальні бази, звані кіосками даних (Data Mart) і орієнтовані на окремі групи користувачів.

Прикладом СУБД, що враховує вимоги, що пред'являються з боку САПР, є система IMAN фірми EDS Unigraphics. Це система управління об'єктно-орієнтованими базами даних, її можна також назвати системою інтеграції даних. Вона виконує функції підсистеми PDM, які є функціями зберігання даних, управління доступом до них, контролю змін, що вносяться, створення специфікацій виробів, інтеграції прикладних підсистем. Всередині IMAN використовується реляційна модель даних, а на інтерфейсному рівні - об'єктно-орієнтована інформаційна модель. Для синхронізації змін передбачається блокування доступу користувачів, якщо з БД вже почав роботу деякий користувач.

Іншими відомими прикладами підсистем управління проектними даними можуть служити системи Optegra (фірма Comptitervision), Euclid Design Manager (Matra Datavision), ProPDM у складі САПР Pro/Engineer (РТС), TEchnoDOCS (Російська фірма «Весть»).

Ряд фірм розробляє системи PDM, які можна використовувати як самостійні продукти і як підсистеми в автоматизованих системах проектувань і управління.

Прикладом може служити система PartY (фірма «Лоция Софт»), в якій передбачені функції управління конфігурацією виробів, управління проектними даними і документообігом, графічний призначений для користувача інтерфейс, реалізація архітектури клієнт-сервер.

В даний час фахівці розділяють системи DW або DW-платформи на два сегменти: засоби генерації сховищ даних (data warehouse generation - DWG) і засобу управління сховищами даних (data warehouse management - DWM) [2]:

­ DWG - програмні засоби, що використовуються в проектуванні, очищенні, перетворенні, завантаженні і адмініструванні сховищ даних;

­ DWM - СУБД, вживані для управління даними в сховищі даних.

Дослідження ринку DW-платформ показує, що лідерство вже не перший рік зберігає декілька найбільших компаній. Їх ефективність оцінювалася, виходячи з прибутку, отриманого від продажів DW, а також думки галузевих експертів. Лідерами є компанії «Oracle», «Microsoft» і «IBM».

Пропозиції «Microsoft» в цій області включають SQL Server для управління сховищем даних і SQL Server Integration Services (сервіси інтеграції) для генерування DW. Розроблені продукти на базі Microsoft’s SQL Server для серверів HP і Dell. У цих продуктах привертає саме те, що Microsoft SQL Server - це не тільки СУБД, але і інтеграційна функціональність, представлена у вигляді програмних продуктів Integration Services, Analysis Services і Reporting Services. У обох варіантах партнерства передбачені опції конфігурації, що базуються на об'ємі даних, а також цінова політика, зручніша, ніж при покупці компонентів окремо.

Компанія Informatica також є постачальником програмного забезпечення для платформ DW. Основні її інструменти відносяться до сегменту генерування DW. Це засоб ETL, управління якістю і інтеграції даних. Платформа інтеграції Informatica використовується як в сховищах даних, так і в інших додатках, наприклад для управління нормативно-довідкової інформації і реплікації. Особливу роль грають можливості інтеграції в реальному часі, а також програмне забезпечення, що надається у вигляді послуги Informatica On Demand, що пропонує набір сервісів інтеграції, призначених для роботі в SaaS-середовищі. Вона забезпечує засоби інтеграції даних, що конфігуруються, настроюються і керовані з браузера.

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

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

Якість даних, метадані і управління нормативно-довідковою інформацією (MDM - master data management) отримують все більш широке визнання. Адміністрування, якість даних і інтеграція, підтримка неструктурованих або напівструктурованих даних, доступу, аналізу і управління мультимедійним контентом як і раніше залишаються найбільш важливими завданнями для удосконалення DW.

Щодо СУБД (DBMS, Data Base Management System) для сховищ даних сьогодні можна вже з упевненістю говорити, що з традиційних засобів зберігання даних окремих користувачів вони еволюціонували в аналітичні інфраструктурні репозиторії підприємств [3]. Крім того, можна відмітити, що розвиток СУБД направлений на перехід від виконання звичайних функцій (у тому числі і підтримка аналітичних додатків в реальному часі) до рішення критично важливих завдань шляхом автоматизації ключових процесів. Прикладом може бути перенесення обчислювальних потужностей на рівень ближче до рівня зберігання. Наприклад, вертикальні СУБД фірм Sand technology, Sybase IQ і Vertica підтримують ефективні підбір (sub-selection) даних, що зберігаються, і скорочення введення/виведення.

Стає менш важливим розмір БД. Сьогодні середні сховища даних (5-20Тбайт) вирішують основні аналітичні завдання організації.

Все більше значення для подальшого розвитку СУБД для сховища даних набуває «змішане навантаження, що змінюється» (changing mixed workload), яке впливає на ефективність сховищ даних, оскільки користувачі застосовують структуровані складні запити, а також швидко виконувані тактичні запити, що вимагає великих ресурсів процесорів, пам'яті і дискового простору.

Виділяють шість причин (навантажень) «змішаного навантаження, що змінюється»:

• безперервне (майже в реальному часі) завантаження даних, яке схоже на завантаження при оперативній обробці транзакцій (OLTP), вимагає постійного оновлення індексів і інших оптимізаційних структур і ставить додаткові завдання управління сумарними і агрегованими даними, зокрема в плані підтримки інструментальних панелей і готових звітів;

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

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

­ об'єм аналітики в OLTP-додатках, що росте, вимагає тактичного використання сховищ даних як джерело інформації для транзакційних додатків, де важливим завданням є швидке виконання запитів;

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

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

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