
- •1. Основні ознаки розподілених програмних систем.
- •2. Характеристики розподілених систем, що впливають на продуктивність обчислень.
- •3. Характеристики розподілених систем, що впливають на надійність обчислень.
- •4. Характеристики розподілених систем, що впливають на економію ресурсів.
- •6. Недоліки розподілених систем, що пов’язані з їх використанням.
- •7. У чому полягає складність розробки розподілених систем?
- •8. Основні види архітектур розподілених систем.
- •9. Особливості архітектури клієнт/сервер.
- •10. Види архітектур клієнт/сервер та галузі їх застосування.
- •11. Особливості застосування архітектури Клієнт / сервер на Основі тонкого клієнта.
- •12. Особливості застосування архітектури Клієнт / сервер на Основі Товстого клієнта.
- •13. Особлівості багаторівневої архітектури Клієнт / сервер.
- •14. Характеристики архітектури розподіленіх об'єктів.
- •15. Основні Переваги архітектури розподіленіх об'єктів.
- •16. Основні недолікі архітектури розподіленіх об'єктів.
- •17. Характеристика систем реального часу.
- •18. Класифікація систем реального часу за типами вхідніх сігналів.
- •19. Особливості проектування систем реального часу.
- •20. Засоба підвіщення продуктівності систем реального часу.
- •21. Моделі систем реального часу.
- •22. Вимоги до засобів програмування систем реального часу.
- •23. Керуючі компоненти систем реального часу.
- •24. Компоненти, що підвищують надійність систем реального часу.
- •25. Особливості керування процесами в системах реального часу.
- •26. Види інтерфейсів користувача та їх особливості.
- •27. Переваги та недоліки графічного інтерфейсу користувача.
- •28. Особливості проектування інтерфейсу користувача.
- •29. Основні засади проектування інтерфейсу користувача.
- •31 Основні види взаємодії користувача і програми та сфери їх застосування.
- •32 Недоліки та переваги основних видів взаємодії користувача з програмою.
- •33 Способи подання інформації користувачу.
- •34 Основні правила використання кольору в інтерфейсах користувача.
- •35 Засоби інтерфейсу спрямовані на підтримку користувача.
- •36 Основні види документації для користувачів програмних систем.
- •37 Основні складові надійності програмних систем.
- •38 Обґрунтування потреби у високонадійних програмних системах.
- •39 Поняття критичної системи.
- •40 Основні типи критичних систем.
- •41. Основні джерела відмов та підходи до проектування критичних систем.
- •42. Основні підходи для підвищення безвідмовності систем.
- •43. Рівні безпечності програмних систем.
- •44. Способи підвищення безпечності програмних систем.
- •45. Типи пошкоджень систем, що викликаються зовнішніми чинниками.
- •46. Засоби підвищення захищеності програмних систем.
- •47 Основні підходи до проектування надійного програмного забезпечення.
- •48 Основні вимоги до розробки безвідмовного програмного забезпечення.
- •49. Конструкції мов програмування, що потенційно можуть призвести помилок.
- •50. Методи програмування, що потенційно можуть призвести до помилок.
- •51. Укривання даних, як спосіб підвищення надійності програмування.
- •52. Технологічні заходи мінімізації числа відмов у програмних системах.
- •53. У проблемі безвідмовності виділяють чотири аспекти.
- •54. Існує два підходи, що використовуються для розробки пз, стійкого до збоїв.
- •55. Обробка виключень в мовах програмування як засіб підвищення надійності.
- •56.Основні типи виявлення збоїв у програмних системах.
- •57. Способи локалізації помилок та пошкоджень даних в програмах.
- •58. Види стійких до відмов архітектур.
- •59. Основні підходи до створення стійкого до відмов програмного забезпечення.
- •60. Шляхи досягнення відмінностей між різними версіями програмного забезпечення. Досягти відмінності між різними версіями пз можна також такими способами:
47 Основні підходи до проектування надійного програмного забезпечення.
Існують два доповнюючих один одного підходи, які використовуються при розробці надійного програмного забезпечення.
1. Запобігання збоїв. В процесі проектування і реалізації використовуються такі технології розробки ПЗ, які зводять до мінімуму помилки оператора і допомагають знаходити системні помилки (перш ніж система буде запущена в експлуатацію). 2. Стійкість до збоїв. Система проектується таким чином, щоб можна було виявити і виправити збої і непередбачене поводження системи до того, як це приведе до відмови в її роботі.
Запобігання збоїв означає поставку замовнику програмних систем, вільних від помилок і збоїв. Це можна зробити двома способами: за допомогою методів програмування, які мінімізують число помилок, можливих в системі (мінімізація помилок і збоїв); за допомогою статичних і динамічних методів тестування, які виявляють ці помилки і дозволяють їх виправити до початку експлуатації системи (виявлення помилок і збоїв).
48 Основні вимоги до розробки безвідмовного програмного забезпечення.
Процес розробки ПЗ повинен включати в себе добре спланований комплексний процес тестування, що має на меті виявлення системних помилок. Процес тестування, що мінімізує кількість системних помилок, має кілька складових.
Перевірка вимог, мета якої полягає у виявленні помилок і інших проблем у системній специфікації (див. розділ 6). Велика частка відмов і збоїв у роботі готового програмного продукту обумовлена помилками в специфікації вимог.
Управління вимогами. У завдання управління вимогами, як вказувалося в главі 6, входить контроль за змінами у вимогах і відстеження внесення відповідних змін (викликаних зміною вимог) на всіх етапах створення системи. Багато помилок у готових системах з'являються в результаті того, що зміни вимог не були враховані при проектуванні або реалізації системи. 3. Перевірка моделей. Це автоматичний аналіз системних моделей за допомогою інструментальних CASE-засобів, які контролюють внутрішню і зовнішню несуперечливість цих моделей. Внутрішня несуперечність означає несуперечність окремої моделі системи; зовнішня - несуперечність всіх моделей системи (наприклад, моделі станів і моделі об'єктів). 4. Перевірка системної архітектури та інспекція коду програм. Як буде показано в главі 19, перевірка архітектури і коду програм базується на технологічних картах перевірки програм і призначена для виявлення і усунення цих помилок перед тестуванням системи. 5. Статичний аналіз. Це автоматизований метод аналізу програм, призначений для знаходження потенційно помилкових умов. Цей метод описується в главі 19.
6. Планування і керування тестуванням системи. Необхідно розробити набір всебічних тестів і сам процес тестування, який гарантує повну перевірку системи. Питання тестування систем розглядаються в главі 20.
49. Конструкції мов програмування, що потенційно можуть призвести помилок.
Числа с плавучею комою. Ці числа неточні за своєю природою. Це породжує певні проблеми, особливо при порівнянні чисел. Наприклад, число 3.00000000 може іноді представлятися як
2.99999999, а іноді як 3.00000001. Порівняння останніх чисел показало б, що вони не рівні. Числа з фіксованою комою, де встановлено кількість десяткових знаків, більш "надійні" при точному порівнянні.
Вказівники. Це низькорівневі конструкції, що містять адреси, які є посиланнями безпосередньо на осередки оперативної пам'яті машини. Вони небезпечні, оскільки допускають суміщення імен, а також ускладнюють перевірку масивів та інших структур.
Динамічний розподіл пам'яті. У цьому випадку виділення пам'яті для програми здійснюється під час її виконання, а не під час компіляції. Небезпека криється в можливості такого розподілу пам'яті, при якому програма буде виконуватися поза доступною області пам'яті. Цей тип помилки дуже важко виявити, оскільки система може успішно працювати протягом тривалого часу, перш ніж виникнуть які-небудь проблеми.
Введення даних без перевірки. Деякі системи організують процес введення даних незалежно від їх змісту. Це прорахунок в захищеності системи, оскільки можуть бути введені дані, які не відкидаються системою, але можуть призвести до її збою.
Паралельність процесів. Паралельне виконання процесів небезпечно тим, що важко передбачити взаємовплив від обміну даними між процесами, яке може бути різним в залежності від часових параметрів обміну. Цю проблему неможливо виявити переглядом тексту програм; крім того, під час випробувань системи не завжди можна виявити комбінації часових параметрів, які призводять до непередбаченого взаємовпливу процесів. Якщо без паралельності процесів неможливо обійтися, необхідно мінімізувати взаємозалежності між процесами. У деяких мовах програмування (наприклад, Ada і Java) є засоби для управління паралельним виконанням процесів.
Введення даних без перевірки. Деякі системи організують процес введення даних незалежно від їх змісту. Це прорахунок в захищеності системи, оскільки можуть бути введені дані, які не відкидаються системою, але можуть призвести до її збою.