Концептуальне моделювання предметної області.

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

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

 

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

 

формалізація, що забезпечує однозначне опис структури предметної області;

зрозумілість для замовників і розробників на основі застосування графічних засобів відображення моделі;

реалізованість, що припускає наявність засобів фізичної реалізації моделі предметної області в ІС;

забезпечення оцінки ефективності реалізації моделі предметної області на основі певних методів і обчислюваних показників.

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

 

 

Логічне і фізичне проектування

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

Другий етап проектування бази даних називається логічним проектуванням бази даних. Його мета полягає в створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена на попередньому етапі, уточнюється і перетвориться в логічну модель даних. Логічна модель даних враховує особливості вибраної моделі організації даних в цільовій СУБД (наприклад, реляційна модель).

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

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

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

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

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

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

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

· визначення конкретних структур зберігання даних і методів доступу до них, забезпечуючих оптимальну продуктивність СУБД;

· розробка засобів захисту створюваної системи.

 

 

Самостійна №7

 

Класифікація CASE – систем.

 

Всі сучасні CASE-засоби можуть бути класифіковані в основному за типами та категоріями. Класифікація за типами відбиває функціональну орієнтацію CASE-засобів на ті чи інші процеси ЖЦ. Класифікація за категоріями визначає ступінь інтегрованості по виконуваних функцій і включає окремі локальні засоби, вирішальні невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані кошти, підтримують весь ЖЦ ІС та пов'язані загальним репозиторием. Крім цього, CASE-засоби можна класифікувати за такими ознаками:

· застосовуваним методологиям і моделях систем і БД;

· ступеня інтегрованості з СУБД;

· доступним платформам.

 

Класифікація за типами переважно збігаються з компонентним складом CASE-засобів і включає наступні основні типи:

 

· засоби аналізу (Upper CASE), призначені для побудови й аналізу моделей предметної області (Design / IDEF (Meta Software), BPwin (Logic Works));

· засоби аналізу і проектування (Middle CASE), що підтримують найбільш поширені методології проектування й які використовуються для створення проектних специфікацій (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналітик (МакроПроджект)). Виходом таких засобів є специфікації компонентів і інтерфейсів системи, архітектури системи, алгоритмів і структур даних;

· засоби проектування баз даних, щоб забезпечити моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених СУБД. До них відносяться ERwin (Logic Works), S-Designor (SDP) і DataBase Designer (ORACLE). Засоби проектування баз даних є також в складі CASE-засобів Vantage Team Builder, Designer/2000, Silverrun і PRO-IV;

· засоби розробки додатків. До них відносяться засоби 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) та ін) і генератори кодів, що входять до складу Vantage Team Builder, PRO-IV і частково - у Silverrun;

· засоби реінжинірингу, що забезпечують аналіз програмних кодів і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin і S-Designor. У сфері аналізу програмних кодів найбільшого поширення отримують об'єктно-орієнтовані CASE-засоби, що забезпечують реінжиніринг програм мовою С + + (Rational Rose (Rational Software), Object Team (Cayenne)).

 

Допоміжні типи включають:

 

v засоби планування і управління проектом (SE Companion, Microsoft Project та ін);

v кошти конфігураційного управління (PVCS (Intersolv));

v засоби тестування (Quality Works (Segue Software));

v засоби документування (SoDA (Rational Software)).