Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
IPZ_1modul.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
611.93 Кб
Скачать

47 Основні підходи до проектування надійного програмного забезпечення.

Існують два доповнюючих один одного підходи, які використовуються при розробці надійного програмного забезпечення.

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

Запобігання збоїв означає поставку замовнику програмних систем, вільних від помилок і збоїв. Це можна зробити двома способами: за допомогою методів програмування, які мінімізують число помилок, можливих в системі (мінімізація помилок і збоїв); за допомогою статичних і динамічних методів тестування, які виявляють ці помилки і дозволяють їх виправити до початку експлуатації системи (виявлення помилок і збоїв).

48 Основні вимоги до розробки безвідмовного програмного забезпечення.

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

  1. Перевірка вимог, мета якої полягає у виявленні помилок і інших проблем у системній специфікації (див. розділ 6). Велика частка відмов і збоїв у роботі готового програмного продукту обумовлена помилками в специфікації вимог.

  2. Управління вимогами. У завдання управління вимогами, як вказувалося в главі 6, входить контроль за змінами у вимогах і відстеження внесення відповідних змін (викликаних зміною вимог) на всіх етапах створення системи. Багато помилок у готових системах з'являються в результаті того, що зміни вимог не були враховані при проектуванні або реалізації системи. 3. Перевірка моделей. Це автоматичний аналіз системних моделей за допомогою інструментальних CASE-засобів, які контролюють внутрішню і зовнішню несуперечливість цих моделей. Внутрішня несуперечність означає несуперечність окремої моделі системи; зовнішня - несуперечність всіх моделей системи (наприклад, моделі станів і моделі об'єктів). 4. Перевірка системної архітектури та інспекція коду програм. Як буде показано в главі 19, перевірка архітектури і коду програм базується на технологічних картах перевірки програм і призначена для виявлення і усунення цих помилок перед тестуванням системи. 5. Статичний аналіз. Це автоматизований метод аналізу програм, призначений для знаходження потенційно помилкових умов. Цей метод описується в главі 19.

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

49. Конструкції мов програмування, що потенційно можуть призвести помилок.

  1. Числа с плавучею комою. Ці числа неточні за своєю природою. Це породжує певні проблеми, особливо при порівнянні чисел. Наприклад, число 3.00000000 може іноді представлятися як

2.99999999, а іноді як 3.00000001. Порівняння останніх чисел показало б, що вони не рівні. Числа з фіксованою комою, де встановлено кількість десяткових знаків, більш "надійні" при точному порівнянні.

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

  2. Динамічний розподіл пам'яті. У цьому випадку виділення пам'яті для програми здійснюється під час її виконання, а не під час компіляції. Небезпека криється в можливості такого розподілу пам'яті, при якому програма буде виконуватися поза доступною області пам'яті. Цей тип помилки дуже важко виявити, оскільки система може успішно працювати протягом тривалого часу, перш ніж виникнуть які-небудь проблеми.

  3. Введення даних без перевірки. Деякі системи організують процес введення даних незалежно від їх змісту. Це прорахунок в захищеності системи, оскільки можуть бути введені дані, які не відкидаються системою, але можуть призвести до її збою.

  4. Паралельність процесів. Паралельне виконання процесів небезпечно тим, що важко передбачити взаємовплив від обміну даними між процесами, яке може бути різним в залежності від часових параметрів обміну. Цю проблему неможливо виявити переглядом тексту програм; крім того, під час випробувань системи не завжди можна виявити комбінації часових параметрів, які призводять до непередбаченого взаємовпливу процесів. Якщо без паралельності процесів неможливо обійтися, необхідно мінімізувати взаємозалежності між процесами. У деяких мовах програмування (наприклад, Ada і Java) є засоби для управління паралельним виконанням процесів.

  5. Введення даних без перевірки. Деякі системи організують процес введення даних незалежно від їх змісту. Це прорахунок в захищеності системи, оскільки можуть бути введені дані, які не відкидаються системою, але можуть призвести до її збою.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]