М. Сидоров - Вступ до інженерії програмного забезпечення

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

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

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

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

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

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

Таблиця 4.2

Розглянемо ці методи докладніше.

Рівні абстракції (Е. Дейкстра, 1968). Ґрунтуючись на досвіді системи мультипрограмування Т.Н.Е., Дейкстра запропонував розробляти програмне забезпечення за рівнями. Перший низький рівень забезпечує балові сервіси для реалізації наступних, рівнів і ґрунтується на можливостях тієї машини, що реально існує. Кожен наступний рівень використовує сервіси поперед нього. Процес Створення рівнів продовжується до тих пір, доки по буде реалізований найвищий рівень абстракції. Наводиться приклад з управлінням пам'яті. На базовому рівні (машинна мова) відомі канальні команди для обміну даними між різними типами пам'яті. На першому рівні проектується механізм управління перериваннями - вплив на сигнали переривання, але без деталей маскування, відкриття, закривання, блокування, черговості. На наступному рівні проектується канальний супервізор - зберігається можливість управління каналами без зайвих деталей і, нарешті, на ще вищому рівні адміністратор пам'яті організовує обмін. Метод можна віднести як до методів розробки, так і управління.

Покрокове уточнення (Н. Вірт, 1971). Цей метод ґрунтується на таких принципах:

- розкладання простору рішень на підпростори;

- ітеративне вирішення завдання (повторення дій);

- аналіз ефективності розкладання (наступне поліпшення виконується лише у вигідному напрямі).

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