М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Підтримуване управління припускає наявність у SDE механізмів і структур, що забезпечують підтримку управління. Наприклад, низхідна розробка програмного забезпечення - управління, яке підтримується в багатьох SDE.

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

Розрізняють типи управління: спрямовані на механізми і структури і спрямовані на управління.

Другий тип управління називається високорівневим або метауправ-лінням. Наприклад, усі проект повинні бути реалізовані мовою ADA.

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

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

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

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

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

Вказані засоби використовуються в рамках трьох таких процесів (рис . 4.2):

- аналіз домена (специфікування вимог) - у результаті виконання процесу визначається «що повніша робити» програмна система;

- аналіз вимог - у результаті виконання процесу визначається «що робить» програмна система;

- проектування - у результаті виконання процесу визначається «як робить» програмна система.

Очевидно, що опис і розробку програмного забезпечення не можна виконати в рамках одного методу. Усі використовувані в інженерії програмного забезпечення метоли поділяють на дві групи: загальнонаукові методи і методи інженерії програмного забезпечення.

Рис. 4.2. Процеси програмного забезпечення

Своєю чергою загальнонаукові методи поділяють на три такі групи:

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

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

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

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

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

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

Методи інженерії програмного забезпечення можна розглядати в контексті двох доменів: прикладного і реалізаційного (рис. 4.3).

Суть розробки програмного забезпечення полягає в реалізації процесу, який починається з ідентифікації вимог у прикладному домені і закінчується створенням програмного продукту, який від­повідає цим вимогам у реалізаційному домені. На практиці процес розробки має ітераційний характер і кожна ітерація використовує два Види аналізу (рис. 4,4).

Рис. 4.4. Зв'язок доменів і моделей

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

Рис. 4.5. Розбіжність поглядів замовника та розробника

На рис. 4.5 ∆ показує початкову розбіжність поглядів замовника ірозробника на продукцію програмного забезпечення.

Моделі можуть бути дескриптивні і прескриптивні. Дескриптивна модель показує, як програмний продукт повинен «поводитися». Ця модель має бути перетворена в прескриптивну модель, що показує, який програмний продукт «поводитиметься» так, як визначає дескриптивна модель. Мета першої моделі - показати, як програмний продукт відповідатиме вимогам, а мета другої - забезпечити однозначне виконання вимог тими, хто конструюватиме програмний продукт.

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