KonspectL_OAPSOS_wrk_ukr1

3.4 Автоматизовані засоби проектування і розробки інформаційних систем

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

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

Стійке положення вони займають в наступних областях:

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

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

Достоїнства:

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

Більшість CASE-средств заснована на парадигмі методология/метод/нотация/средство. Методологія визначає керівні вказівки для оцінки і вибору проекту того, що розробляється ПО, кроки роботи і їх послідовність, а також правила розподілу і призначення методів. Метод – систематична процедура або техніка генерації описів компонентів ПО (наприклад, проектування потоків і структур даних). Нотації призначені для опису структури системи, елементів даних, етапів обробки і включають графи, діаграми, таблиці, блок схеми, формальні і природні мови. Засоби – інструментарій для підтримки і посилення методів. Ці інструменти підтримують роботу користувачів при створенні і редагуванні графічного проекту в інтерактивному режимі, вони сприяють організації проекту у вигляді ієрархії рівнів абстракції, виконують перевірки відповідності компонентів.

Склад, структура і функціональні особливості CASE-средств

CASE-средства служать інструментарієм для підтримки і посилення методів структурного аналізу і проектування. Ці інструменти підтримують роботу користувачів при створенні і редагуванні графічного проекту в інтерактивному режимі, вони сприяють організації проекту у вигляді ієрархії рівнів абстракції, виконують перевірки відповідності компонентів. Фактично CASE-средства є новим типом графічно-орієнтованих інструментів, висхідних до системи підтримки ЖЦ ПО. Зазвичай до них відносять будь-який програмний засіб, що забезпечує автоматичну допомогу при розробці ПО, його супроводі або діяльності після управління проектом, і що проявляє наступні додаткові риси:

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

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

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

Інтегрований CASE-пакет містить чотири основні компоненти:

1. Засоби централізованого зберігання всієї інформації про проектований ПО в перебігу всього ЖЦ (репозитарий) є основою CASE-пакета. Відповідна БД повинна мати можливість підтримувати велику систему описів і характеристик і передбачати надійні заходи по захисту від помилок і втрат інформації. Репозітарій повинен забезпечити:

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

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

3. Засоби аналізу, проектування і розробки призначені для того, щоб забезпечити планування і аналіз різних описів. А також їх перетворення в процесі розробки.

4. Засоби виводу служать для документування, управління проектом і кодової генерації.

Всі перераховані компоненти в сукупності винні:

підтримувати графічні моделі;
контролювати помилки;
організовувати і підтримувати репозитарий;
підтримувати процес проектування і розробки.

Підтримка графічних моделей

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

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

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

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

Контроль помилок

Важливість контролю помилок на етапах аналізу вимог і проектування специфікацій обуславливается можливістю їх автоматичного виявлення на ранніх етапах ЖЦ. CASE забезпечує автоматичну верифікацію і контроль проекту на повноту і спроможність на ранніх етапах ЖЦ, що впливає на успіх розробки в цілому. На підтвердження цього можна привести наступні статистичні дані, засновані на звітах фірми TRW по аналізу 5 крупних проектів:

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

У CASE диаграммеры і верификаторы здатні здійснювати наступні типи контролю:

1. Контроль синтаксису діаграм і типів їх елементів. Зазвичай такий контроль здійснюється при введенні і редагуванні елементів діаграм. Приклади контрольованих ситуацій:

по синтаксису: будь-який функціональний елемент діаграми повинен мати принаймні один вхідний і один вихідний потік; два елементи даних не можуть бути безпосередньо зв'язані;
по типах: функціональний елемент повинен завжди використовуватися для представлення процедурного компоненту; потік даних завжди повинен бути представлений компонентом даних.

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

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

4. Крізний контроль діаграм одного або різних типів на предмет їх спроможності по рівнях – вертикальне і горизонтальне балансування діаграм. При вертикальному балансуванні (діаграми одного типу) виявляються незбалансовані потоки даних між діаграмами, що деталізуються і деталізуючою. Горизонтальне балансування визначає некоректності між DFD, ERD, STD, словниками даних і мініспецифікаціями процесів. Так при балансуванні DFD-ERD контролюється відповідність кожного сховища даних на DFD суті або відношенні на ERD. Контроль DFD-STD здійснюється по наступних правилах: кожен процес, що управляє, на DFD деталізує специфікацією управління STD, і навпаки, кожній STD повинен відповідати процес, що управляє; кожна умова (дія) в STD повинна відповідати вхідному (вихідному) потоку, що управляє, на DFD, і навпаки, кожному потоку, що управляє, залежно від його спрямованості повинна відповідати умова/дія на STD. При балансуванні DFD-словарь даних мініспецифікація повинні перевірятися наступні правила:

кожен потік і сховище даних повинні бути визначені в словнику даних (контроль невизначених значень), і навпаки, кожне визначення в словнику повинне бути відбите на діаграмі, в мініспецифікації або іншому визначенні (контроль невживаних значень);
кожен процес на DFD повинен деталізувати за допомогою DFD або мініспецифікацій (але не тим і іншим одночасно), і навпаки, кожна мініспецифікація повинна відповідати єдиному процесу;
посилання до даним в миниспецификаци повинні відповідати об'єктам на діаграмах і в словнику даних;
по можливості повинна контролюватися семантика мініспецифікації: наприклад, якщо вхідні і/або вихідні потоки пов'язані з сховищем даних, то це повинно бути відбито в мініспецифікації (операторами READ, GET, WRITE, PUT і тому подібне)

Організація і підтримка репозитария

Основні функції засобів організації і підтримки репозитария – зберігання. Доступ, оновлення, аналіз і візуалізація всієї інформації за проектом ПО. Вміст репозитария включає не тільки інформаційні об'єкти різних типів. Але і відносини між їх компонентами, а також правила використання або обробки цих компонентів (рис 11.3). Репозітарій може зберігати понад 100 типів об'єктів, прикладами яких є структурні діаграми, визначення екранів і меню, проекти звітів, описи даних, логіка обробки, моделі даних, моделі організації, моделі обробки, початкові коди, елементи даних і тому подібне

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

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

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

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

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

Підтримка процесу проектування і розробки.

За підтримки проектування і розробки основну роль грають наступні можливості CASE-пакетов: покриття ЖЦ, підтримка прототипирования, підтримка структурних методологій, автоматична крдогенерация.

При покритті ЖЦ найбільша увага приділяється його критичним етапам – аналізу вимог і проектуванню специфікацій. Останні є основою всього проекту, тому їх повнота і коректність впливають на успіх розробки в цілому. Важливу роль при автоматизації ранніх етапів ЖЦ грають можливості підтримки прототипирования. Відповідні засоби використовуються для визначення системних вимог і відповіді на питання ою очікуваній поведінці системи. такі засоби як генератори меню. Екранів і звітів, дозволяють швидко побудувати прототипи призначених для користувача інтерфейсів і забезпечити моделлю функціонування системи з позицій кінцевого користувача. Використання мов четвертого покоління (4GL) дозволяє будувати складніші моделі, при цьому прототип дозволяє промоделировать основні функції системи, але не здатний контролювати її очікувану поведінку. Виконувані мови специфікацій перетворять процес процес розробки в наступний ітеративний процес: специфікації визначаються і виконуються, потім проводиться перевизначення або коректування. Створені таким чином прототипи дозволяють визначати, чи є проектована система повною і коректною.

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

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

Кодогенерація здійснюється на основі репозитария і дозволяє автоматично побудувати до 80-90% об'єктних код або текстів програм на мовах високого рівня. При цьому різними CASE-пакетами підтримуються практично всі відомі мови програмування, проте найчастіше як цільові мови виступають COBOL, C, ADA. Засоби кодогенерації по відношенню до облиште цільового продукту розділяються на засоби генерації каркаса ПО і засоби генерації повного продукту. У першому випадку автоматично будується откомментированная логіка (потоки управління) ПО, а також коди для БД, файлів, екранів, звітів і тому подібне. решта фрагментів ПО кодуються уручну. У другому випадку з проектних специфікацій генерується повна документована програма, включаючи виконуваний код, призначену для користувача і програмну документацію, набори тестів і так далі Всі ці компоненти повної програми зв'язуються в єдиний об'єкт, що зберігається в репозитарии для полегшення доступу і супроводу.

КЛАСИФІКАЦІЯ CASE-СРЕДСТВ.

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

Аналіз і проектування. Засоби даної групи використовуються для створення специфікацій системи і її проектування; вони підтримують широко відомі методології проектування. До таких засобів відносяться CASE-аналитик (Ейтекс), The Developer (ASYST Technologies), POSE (Computer Systems Advisers), ProKit Workbench (McDonnell Douglas), Excelerator (Index Tecnology), Design-Aid (Nastec), Design Machine (Optima), MicroStep (Meta Systems), vsDesigner (Visual Software), Analist/Designer (Yourdan), Design/IDEF (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architest (Popkin Softwre & Systems), Westmount I-CASE Yourdon (Westmount Technology B.V. & CADRE Tecnologies), CASE/4/0 (micro TOOL GMBH). Їх метою є визначення системних вимог і властивостей, якими система повинна володіти, а також створення проекту системи, що задовольняє цим вимогам і що володіє відповідними властивостями. На виході продукуються специфікації компонентів системи і інтерфейсів, що зв'язують ці компоненти, а також «калька» архітектури системи і детальна «калька» проекту, що включає алгоритми і визначення структур даних.

Проектування баз даних і файлів. засоби даної групи забезпечують логічне моделювання даних, автоматичне перетворення моделей даних в Третю Нормальну Форму, автоматичну генерацію схем БД і описів форматів файлів на рівні програмної коди: ERWin (Logic Works), Chen Toolkit (Chen & Associates), S-Desgnor (SDP), Designer/200 (Oracle), Silverrun (Computer Systems Advisers).

Програмування. Засоби цієї групи підтримують етапи програмування і тестування, а також автоматичну кодогенерацію із специфікацій, отримуючи повністю документовану виконувану програму COBOL 2/Workbench (Micro Focus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software)/ Крім диаграммеров різного призначення і засобів підтримки роботи з репозитарием, в цю групу засобів включені і традиційні генератори код, аналізатори код (як статиці, так і динаміці), генератори наборів тестів. Аналізатори покриття тестами, відладчики.

Супровід і реинжиниринг. До таких засобів відноситься документатор. Аналізатори програм. Засоби реструктурування і реинжиниринга: Adpac CASE Tools (Adpac), Scan/COBOL, SuperStructure (Computer Data Systems), Inspector/Recorder (Languge Tecnology). Їх метою є коректування, зміна, аналіз, преоброзование і реинжиниринг існуючої системи. Засоби дозволяють здійснювати підтримку всієї системної документації, включаючи коди, специфікації, набори тестів; контролювати покриття тестами для оцінки повноти тестируемости; управляти функционированем системи і тому подібне особливий інтерес представляють засоби забезпечення мобільності (у CASE вони отримали назву засобів міграції) і реинжиниринга. До засобів міграції відносяться транслятори, конвертори, макрогенератори і ін., що дозволяють забезпечити перенесення існуючої системи в нове операційне або апаратурне оточення. Засоби реинжиниринга включають:

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

Оточення. Засоби підтримки платформ для інтеграції, створення і надання товарному вигляду CASE-средствам: Multi/Cam (AGS Management Systems), Sylva Foundry (Cadware).

Управління проектом. Засоби, що підтримують планування, контроль, керівництво, взаємодію, тобто функції, необхідні в процесі розробки і супроводу проектів: Project Workbench (Applied Business Tecnology).

Класифікація по категоріях визначає рівень інтегрованості по виконуваних функціях і включає допоміжні програми (tools), пакети розробника (toolkit) і інструментальні засоби (workbench). Категорія tools позначає допоміжний пакет, вирішальний невелике автономне завдання, що належить проблемі ширшого масштабу. Категорія toolkit представляє сукупність інтегрованих програмних засобів, що забезпечують допомогу для одного з класів програмних завдань; використовує репозитарий для всієї технічної інформації, що управляє, про проект, однієї фази або одного етапу розробки ПО. Категорія workbench є інтеграцією програмних засобів, які підтримують системний аналіз. Проектування і розробку ПО; використовують репозитарий, що містить всю технічну інформацію , що управляє, про проект; забезпечує автоматичну передачу системній інформації між розробниками і етапами розробки; організовує підтримку практично повного ЖЦ (від аналізу вимог і проектуванні ПО до отримання документованої виконуваної програми). Workbench в порівнянні з toolkit володіє вищим ступенем інтеграції виконуваних функцій, більшою самостійністю і автономністю використання. А також наявністю тісного зв'язку з системними і технічними засобами апаратно-обчислювального середовища, на якій workbench функціонує. По суті workbench може розглядатися як автоматизована робоча станція, використовувана як інструментарій для автоматизації всіх або окремих совокупностей робіт із створення ПО.

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

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

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

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

Нижні (Lower) CASE є засобами розробки ПО (при цьому може використовуватися до 30% специфікацій, створених засобами середнього CASE). Вони містять системні словники і графічні засоби, що виключають необхідність розробки фізичних специфікацій. Є системні специфікації, які безпосередньо переводяться в програмні коди системи, що розробляється (при цьому автоматично генерується до 80-90% код). На ці засоби покладені також функції тестування, управління конфігурацією, формування документації. Головними перевагами нижніх CASE є: значне зменшення часу на розробку, полегшення модифікацій, підтримка можливостей прототипирования (спільно з середніми CASE).

Содержание