16.4. Поняття комп'ютерної технології розробки програмних засобів і її робочі місця.
Є деякі труднощі у виробленні строгого визначення CASE-технологии (комп'ютерній технології розробки ПС). CASE це абревиатура від англійського Computer-Aided Software Engineering (Компьютерно-помогаємая Інженерія Програмування). Але без допомоги (підтримка) комп'ютера ПС вже давно не розробляються (використовується хоч би компілятор). Насправді, в це поняття вкладається вужчий (спеціальний) сенс, який поступово розмивається (як це завжди буває, коли яке-небудь поняття не має строгого визначення). Спочатку під CASE розумілася [16.4] інженерія ранніх етапів розробки ПС (визначення вимог, розробка зовнішнього опису і архітектури ПС) з використанням програмної підтримки (програмних інструментів). Тепер під CASE може розумітися [16.4] і інженерія всього життєвого циклу ПС (включаючи і його супровід), але тільки у тому випадку, коли програми частково або повністю генеруються по документах, отриманих на вказаних ранніх етапах розробки. В цьому випадку CASE-технология почала принципово відрізнятися від ручної (традиційною) технології розробки ПС: змінився не тільки зміст технологічних процесів, але і сама їх сукупність.
В даний час комп'ютерну технологію розробки ПС можна характеризувати [16.1] використанням
програмної підтримки для розробки графічних вимог і графічних специфікацій ПС
автоматичній генерації програм на якій-небудь мові програмування або в машинному коді (частково або повністю)
програмної підтримки прототипирования.
Говорять також, що комп'ютерна технологія розробки ПС є "безпаперовою", тобто розрахованою на комп'ютерне представлення програмних документів. Проте, упевнено відрізнити ручну технологію розробки ПС від комп'ютерної по цих ознаках досить важко. Значить, найістотніше в комп'ютерній технології не виділено.
На наш погляд, головна відмінність ручної технології розробки ПС від комп'ютерної полягає в наступній. Ручна технологія орієнтована на розробку документів, що однаково розуміються різними розробниками ПС, тоді як комп'ютерна технологія орієнтована на забезпечення семантичного розуміння (інтерпретації) документів програмною підтримкою комп'ютерної технології. Семантичне розуміння документів дає програмній підтримці можливість автоматично генерувати програми. У зв'язку з цим істотною частиною комп'ютерної технології стає використання формальних мов вже на ранніх етапах розробки ПС: як для специфікації програм, так і для специфікації інших документів. Зокрема, широко використовуються формальні графічні мови специфікацій. Саме це дозволяє раціонально змінити і саму сукупність технологічних процесів розробки і супроводу ПС.
З проведеного обговорення можна визначити комп'ютерну технологію розробки ПС як технологію програмування, в якій використовуються програмні інструменти для розробки формалізованих специфікацій програм і інших документів (включаючи і графічні специфікації) з подальшою автоматичною генерацією програм і документів (або хоч би значній їх частині) по цих специфікаціях.
Тепер стають зрозумілими і основні зміни в життєвому циклі ПС для комп'ютерної технології. Якщо при використанні ручної технології основні зусилля по розробці ПС робилися на етапах власне програмування (кодування) і відладки (тестування), то при використанні комп'ютерної технології на ранніх етапах розробки ПС (визначення вимог і функціональної специфікації, розробки архітектури). При цьому істотно змінився характер документації. Замість цілого ланцюжка неформальних документів, орієнтованій на передачу інформації від замовника (користувача) до різних категорій розробникам, формуються прототип ПС, що підтримує вибраний призначений для користувача інтерфейс, і формальні функціональні специфікації (іноді і формальні специфікації архітектури ПС), достатні для автоматичного синтезу (генерації) програм ПС (або хоч би значній їх частині). При цьому з'явилася можливість автоматичної генерації частини документації, необхідної розробникам і користувачам. Замість ручного програмування (кодування) автоматична генерація програм, що робить не потрібною автономну відладку і тестування програм: замість неї додається достатньо глибокий автоматичний семантичний контроль документації. З'являється можливість автоматичної генерації тестів по формальних специфікаціях для комплексної (системною) відладки ПС. Істотно змінюється і характер супроводу ПС: всі зміни розробником-супровідником вносяться тільки до специфікацій (включаючи і прототип), решта змін в ПС здійснюється автоматично.
З урахуванням сказаного життєвий цикл ПС для комп'ютерної технології можна представити [16.4] наступною схемою (мал. 16.3).
-
Мал. 16.3. Життєвий цикл програмного засобу для комп'ютерної технології.
Прототіпірованіє ПС є необов'язковим етапом життєвого циклу ПС при комп'ютерній технології, що на мал. 16.3 показано пунктирною стрілкою. Проте використання цього етапу у багатьох випадках і відповідна комп'ютерна підтримка цього етапу є характерною для комп'ютерної технології. В деяких випадках прототипирование робиться після (або в процесі) розробки специфікацій ПС, наприклад, у разі прототипирования призначеного для користувача інтерфейсу. Це показано на мал. 16.3 пунктирної поворотної стрілки. Хоча повернення до попередніх етапів ми допускаємо на будь-якому етапі, але тут це показано явно, оскільки прототипирование є особливим підходом до розробки ПС (див. лекцію 3). Прототіпірованіє призначеного для користувача інтерфейсу дозволяє замінити непрямий опис взаємодії між користувачем і ПС при ручній технології (при розробці зовнішнього опису ПС) прямим вибором користувачем способу і стилю цієї взаємодії з фіксацією всіх необхідних деталей. По суті, на цьому етапі проводиться точний опис призначеного для користувача інтерфейсу, зрозумілий програмній підтримці комп'ютерної технології, причому з відповідальною участю користувача. Все це базується на наявність в програмній підтримці комп'ютерної технології оболонки, що настроюється, з обширною бібліотекою заготовок різних фрагментів і деталей екрану. Таке прототипирование, мабуть, є кращим способом подолання бар'єру між користувачем і розробником.
Розробка специфікацій ПС розпадається на декілька різних процесів. Якщо виключити початковий етап розробки специфікацій (визначення вимог), то в цих процесах використовуються методи, що приводять до створення формалізованих документів, тобто використовуються формалізовані мови специфікацій. При цьому широко використовуються графічні методи специфікацій, що приводять до створення різних схем і діаграм, які визначають структуру інформаційного середовища і структуру управління ПС. До таких структур прив'язуються фрагменти описи даних і програм, представлені на мовах алгебри специфікацій (наприклад, що використовують операційну або аксіоматичну семантику), або логічних мовах специфікацій (що базуються на логічному підході до специфікації програм). Такі специфікації дозволяють в значній мірі або повністю автоматично генерувати програми. Істотною частиною розробки специфікацій є створення словника іменованої суті, використовуваної в специфікаціях.
Автоматизований контроль специфікацій ПС використовує та обставина, що значна частина специфікацій представляється на формальних мовах. Це дозволяє автоматично здійснювати різні види контролю: синтаксичний і частковий семантичний контроль специфікацій, контроль повноти і спроможності схем і діаграм (зокрема, всі їх елементи повинні бути ідентифіковані і відбиті в словнику іменованої суті), крізний контроль збалансованості рівнів специфікацій і інші види контролю залежно від можливостей мов специфікацій.
Генерація програм ПС. На цьому етапі автоматично генерує скелети код програм ПС або повністю коди цих програм по формальних специфікаціях ПС.
Автоматизоване документування ПС. Припускає можливість генерації різних форм документів з частковим заповненням їх за інформацією, що зберігається в репозиторії. При цьому кількість видів документів скорочується в порівнянні з традиційною технологією.
Комплексне тестування і відладка ПС. На цьому етапі тестуються всі специфікації ПС і виправляються виявлені при цьому помилки. Тести можуть створюватися як уручну, так і автоматично (якщо це дозволяють використовувані мови специфікацій) і пропускаються через програми ПС, що згенерували.
Атестація ПС має колишній зміст.
Супровід ПС істотно спрощується, оскільки основні зміни робляться тільки в специфікаціях.
Робоче місце комп'ютерної технології розробки ПС є інструментальним середовищем, що підтримує всі етапи життєвого циклу цієї технології. У цьому середовищі істотно використовується репозиторій. У репозиторії зберігається вся інформація, що створюється в процесі розробки ПС (зокрема, словник іменованої суті і всі специфікації). По суті, робоче місце комп'ютерної технології є інтегрованим хоч би по призначеному для користувача інтерфейсу і по даним. Основними інструментами такого робочого місця є:
конструктори призначених для користувача інтерфейсів;
інструмент роботи із словником іменованої суті;
графічні і тестові редактори специфікацій;
аналізатори специфікацій;
генератор програм;
документатор.