- •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. Шляхи досягнення відмінностей між різними версіями програмного забезпечення. Досягти відмінності між різними версіями пз можна також такими способами:
59. Основні підходи до створення стійкого до відмов програмного забезпечення.
Підходи до створення відмовостійкого програмного забезпечення:
N-варіантне програмування. У відповідності із загальною специфікацією різними командами розробників розробляється кілька версій програмного забезпечення. Ці версії виконуються паралельно на окремих комп'ютерах. Результати їх роботи порівнюються за допомогою системи узгодження, результати якої версії, що не збігаються з двома іншими або не отримані вчасно, відкидаються. Це найбільш часто використовуваний підхід до створення відмовостійкого програмного забезпечення. Він використовується в системах сигналізації на залізницях, в авіаційних системах і в системах захисту реакторів.
Блоки відновлення. У цьому методі кожен програмний компонент містить тест, який перевіряє його роботу. Компонент також має підпрограму, яка повторює обчислення, якщо тест виявив неправильне виконання. Але повторні обчислення виконуються іншим модулем компонента, який навмисно побудований на іншій інтерпретації вимог, що пред'являються до компонента. Таким чином, компонент має кілька модулів (блоків відновлення), що виконують однакові функції, але реалізують різні алгоритми. Оскільки модулі виконуються послідовно, в рамках даного підходу немає необхідності дублювати апаратні засоби.
Обидва описаних підходу використовують кілька різних архітектур та програмних реалізацій. Коли для реалізації однієї і тієї ж специфікації використовується декілька різних підходів, природно вважати малоймовірною ситуацію, коли різні версії ПО матимуть одні і ті ж помилки.
60. Шляхи досягнення відмінностей між різними версіями програмного забезпечення. Досягти відмінності між різними версіями пз можна також такими способами:
1 Включення в системну специфікацію вимог використовувати при проектуванні різні підходи. Наприклад, можна зажадати, щоб одна команда розробників використовувала об'єктноорієнтоване проектування, а інша - функціонально-орієнтоване.
Включення в специфікацію вимог, щоб для реалізації були використані різні мови програмування. Наприклад, у системі з трьома версіями ПЗ для написання різних версій можна використовувати мови програмування Ada, C і Java.
Використовувати при розробці системи різні інструментальні засоби та середовища розробки.
Можна зажадати використання конкретних алгоритмів для реалізації певних системних компонентів. Це, звичайно, обмежує свободу розробників і може стати причиною інших проблем. Кожна команда розробників повинна працювати зі своєю специфікацією (так званої Vспецифікацією), яку отримують із загальної специфікації системних вимог. Команди розробників кожної версії ПО повинні працювати ізольовано, щоб зменшити вірогідність появи в версіях однакових помилок.