11.3. Забезпечення точності програмного засобу.

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

• від погрішності використовуваного методу обчислення (у яку ми включаємо і неточність використовуваної моделі)

• від погрішності представлення використовуваних даних (від т.з. неусувній погрішності)

• від погрішності округлення (неточності виконання використовуваних в методі операцій).

11.4. Забезпечення автономності програмного засобу.

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

11.5. Забезпечення стійкості програмного засобу.

Цей примітив якості ПС забезпечується за допомогою так званого захисного програмування. Взагалі кажучи, захисне програмування застосовується при програмуванні модуля для підвищення надійності ПС в ширшому сенсі. Як затверджує Майерс [11.3], «захисне програмування засноване на важливій передумові: гірше, що може зробити модуль, – це прийняти неправильні вхідні дані і потім повернути невірний, але правдоподібний результат». Для того, щоб цього уникнути, в текст модуля включають перевірки його вхідних і вихідних даних на їх коректність відповідно до специфікації цього модуля, зокрема, повинні бути перевірені виконання обмежень на вхідні і вихідні дані і співвідношень між ними, вказані в специфікації модуля. У разі негативного результату перевірки збуджується відповідна виняткова ситуація. Для обробки таких ситуацій в кінець цього модуля включаються фрагменти другого роду – обробники відповідних виняткових ситуацій. Ці обробники крім видачі необхідній діагностичній інформації, можуть прийняти заходи або по виключенню помилки в даних (наприклад, зажадати їх повторного введення), або по ослабленню впливу помилки (наприклад, щоб уникнути поломки пристроїв, керованих за допомогою даного ПС, при аварійному припиненні виконання програми здійснюють м'яку їх зупинку).

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