Основи CASЕ-технологій

Основи CASЕ-технологій

12

1. Методологія RAD

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є що одержала останнім часом широке розповсюдження методологія швидкої розробки застосувань RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

* невелику команду програмістів (від 2 до 10 чоловік);

* короткий, але такий, що ретельно пропрацював виробничий графік (від 2 до 6 міс.);

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

Команда розробників повинна представляти з себе групу професіоналів, що мають досвід в аналізі, проектуванні, генерації коду і тестуванні ПЗ з використанням CASE-засобів. Члени колективу повинні також уміти трансформувати в робочі прототипи пропозиції кінцевих користувачів.

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

* фаза аналізу і планування вимог;

* фаза проектування;

* фаза побудови;

* фаза впровадження.

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи, що розробляється, і ухвалюється рішення про розділення ІС на підсистеми, реалізації однією командою розробників, що піддаються, за прийнятний для RAD-проектів час - близько 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

* загальна інформаційна модель системи;

* функціональні моделі системи в цілому і підсистем, розробників, що реалізовуються окремими командами;

* точно визначені за допомогою CASE-засобу інтерфейси між підсистемами, що автономно розробляються;

* побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

* визначається необхідність розподілу даних;

* проводиться аналіз використання даних;

* проводиться фізичне проектування бази даних;

* визначаються вимоги до апаратних ресурсів;

* визначаються способи збільшення продуктивності;

* завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

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

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

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

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

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

Як підсумок перерахуємо основні принципи методології RAD:

* розробка застосувань ітераціями;

* необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

* обов'язкове залучення користувачів в процес розробки ІС;

* необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

* необхідне використання генераторів коду;

* використання прототипування, що дозволяє повніше з'ясувати і задовольнити потреби кінцевого користувача;

* тестування і розвиток проекту, здійснювані одночасно з розробкою;

* ведення розробки нечисленною добре керованою командою професіоналів;

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

2. Моделювання даних

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

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

Нотація ERD була вперше введена П. Ченом (Chen) і одержала подальший розвиток в роботах Баркера. Метод Баркера висловлюватиметься на прикладі моделювання діяльності компанії по торгівлі автомобілями. Нижче приведені витяги з інтерв'ю, проведеного з персоналом компанії.

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

Продавець: йому потрібно знати, яку ціну запрошувати і яка нижня ціна, за яку можна зробити операцію. Крім того, йому потрібна основна інформація про машини: рік випуску, марка, модель і т. п.

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

Перший крок моделювання - витягання інформації з інтерв'ю і виділення суті.

Суть (Entity) - реальний або уявний об'єкт, що має істотне значення для даної наочної області, інформація про яке підлягає зберіганню

Весь проект розділяється на 4 фази: аналіз, глобальне проектування (проектування архітектури системи), детальне проектування і реалізація (програмування).

На фазі аналізу будується модель середовища (Environmental Model). Побудова моделі середовища включає:

* аналіз поведінки системи (визначення призначення ІС, побудова початкової контекстної діаграми потоків даних (DFD) і формування матриці списку подій (ELM), побудова контекстних діаграм);

* аналіз даних (визначення складу потоків даних і побудова діаграм структур даних (DSD), конструювання глобальної моделі даних у вигляді ER-діаграми).

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

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

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

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

Початкова контекстна діаграма зображена на малюнку 1. На відміну від нотації Gane/Sarson зовнішня суть позначається звичайними прямокутниками, а процеси - колами.

12

Рис. 1. Початкова контекстна діаграма

Список подій будується у вигляді матриці (ELM) і описує різні дії зовнішньої суті і реакцію ІС на них. Ці дії є зовнішніми подіями, що впливають на бібліотеку. Розрізняють наступні типи подій:

Всі дії позначаються як нормальні дані. Ці дані є подіями, які ІС сприймає безпосередньо, наприклад, зміна адреси клієнта, яка повинна бути відразу зареєстрована. Вони з'являються в DFD як вміст потоків даних.

Матриця списку подій має наступний вигляд:

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

На приведеній DFD (рисунок 2) накопичувач даних «бібліотека» є глобальним або абстрактним представленням сховища даних.

Аналіз функціонального аспекту поведінки системи дає уявлення про обмін і перетворення даних в системі. Взаємозв'язок між «абстрактними» потоками даних і «конкретними» потоками даних на діаграмі нульового рівня виражається в діаграмах структур даних.

На фазі аналізу будується глобальна модель даних, «суть-зв'язок», що представляється у вигляді діаграми.

Між різними типами діаграм існують наступні взаємозв'язки:

* ELM-DFD: події - вхідні потоки, реакції - вихідні потоки

* DFD-DSD: потоки даних - структури даних верхнього рівня

* DFD-ERD: накопичувачі даних - ER-діаграми

* DSD-ERD: структури даних нижнього рівня - атрибути суті

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

* детальний опис функціонування системи;

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

* визначення структури призначеного для користувача інтерфейсу, специфікації форм і порядку їх появи;

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

12

Мал. 2.

Список використаної літератури

1. ВендровА.М.Один з підходів до вибору засобів проектування баз даних і застосувань. «СУБД», 1995 №3.

2. КаляновГ.Н. CASE. Структурний системний аналіз (автоматизація і застосування). М., «Лорі», 1996.

3. МаркаД.А., МакГоуен К.Методология структурного аналізу і проектування. М., «МетаТехнология», 1993.

4. Створення інформаційної системи підприємства. «Computer Direct», 1996 N2