Скачать презентацию II МОВИ ТА МЕТОДИ СПЕЦИФІКАЦІЇ ПРОГРАМ Сучасні Скачать презентацию II МОВИ ТА МЕТОДИ СПЕЦИФІКАЦІЇ ПРОГРАМ Сучасні

MOVI_TA_METODI_SPECIFIKACII_PROGRA.pptx

  • Количество слайдов: 19

II МОВИ ТА МЕТОДИ СПЕЦИФІКАЦІЇ ПРОГРАМ II МОВИ ТА МЕТОДИ СПЕЦИФІКАЦІЇ ПРОГРАМ

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

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

Помилки в ПЗ критичному до безпеки У світі постійно відбуваються катастрофи, і все частіше Помилки в ПЗ критичному до безпеки У світі постійно відбуваються катастрофи, і все частіше їх причиною стає неправильне функціонування комп’ютерних систем, зокрема і ПЗ. Оборона, авіація и космос, медицина, технологічні процеси на сучасних ядерних, хімічних та інших виробництвах – це далеко не повний перелік предметних областей, де низька якість ПЗ і, навіть поодинокі дефекти в ньому призводть до загибелі людей та руйнування матеріальних цінностей. Проте, іноді і таке, критичне до безпеки ПЗ помиляється.

Therac-25 (1985 -1987) В 1985– 87 роках 6 людей отримали смертельну дозу опромінення під Therac-25 (1985 -1987) В 1985– 87 роках 6 людей отримали смертельну дозу опромінення під час сеансів радіаційної терапії із застосуванням медичного прискорювача Therac-25 (кількість пацієнтів, також зазнали переопромінення, але вижили, точно не відома). Розслідування показало, що безпосередньою причиною інцидентів була програмна помилка, проте основні помилки були зроблені на стадії проектування устаткування і системи автоматизації.

Ariane 5 (4 червня 1996) Перший запуск ракети-носія Ariane 5 закінчився вибухом через неповні Ariane 5 (4 червня 1996) Перший запуск ракети-носія Ariane 5 закінчився вибухом через неповні 40 секунд польоту. Автопідрив 50 -метрової ракети стався в районі її запуску з космодрому у Французькій Гвіані. За попередні роки ракети серії Ariane сім разів терпіли аварії, але ця побила всі рекорди за викликаними нею збитками. Тільки наукове обладнання, яке знаходилося на борту потягнуло на півмільярда доларів, не кажучи про інші витрати; а астрономічні цифри «втраченої вигоди" від зірваних комерційних запусків і втрата репутації надійного перевізника в дуже конкурентному секторі світової економіки практично не піддаються оцінці. У теж час попередня модель - ракета Ariane 4 - успішно запускалася більше 100 разів.

Ariane 5 (4 червня 1996) Катастрофі, яка відбулася з Ariane 5 мала виключно великий Ariane 5 (4 червня 1996) Катастрофі, яка відбулася з Ariane 5 мала виключно великий резонанс - і з причини безпрецедентних матеріальних втрат, і внаслідок дуже оперативного розслідування, що характеризувалася до того ж відкритістю результатів. В результаті дана подія увійшла в історію не лише космонавтики, але і програмної інженерії. Розслідування показало, що причиною аварії стала допущена (і не виявлена при тестуванні) програмна помилка, пов'язана з некоректним повторним використанням програмного забезпечення і відсутністю точної специфікації повторновикористовуваного модуля.

Mars Climate Orbiter (23. 09. 1999) Апарат для дослідження Марса Mars Climate Orbiter був Mars Climate Orbiter (23. 09. 1999) Апарат для дослідження Марса Mars Climate Orbiter був запущений 11 грудня 1998. Слідом за ним був також запущений Mars Polar Lander - 3 січня 1999. Обидва апарати були втрачені незабаром після того, як вони досягли червоної планети. Ці два космічних корабля коштували NASA близько 327, 6 мільйона доларів, витрачених на їх створення і функціонування. Причина аварії Mars Polar Lander залишилася нез'ясованою. Причина втрати Mars Climate Orbiter полягає в програмнолюдській помилці, яка призвела до того, що один підрозділ, який брав участь в проекті обчислював "в дюймах", а інший - "в метрах", причому з'ясувалося це вже після втрати апарата.

Ракето-носій “Зеніт” (12. 03. 2000) Запуск ракети-носія Ракето-носій “Зеніт” (12. 03. 2000) Запуск ракети-носія "Зеніт" 12 березня 2000 за програмою "Морський старт" (Sea Launch) закінчився аварією. Через кілька хвилин після старту ракета "Зеніт" відхилилася від курсу і не змогла вивести на задану орбіту перший супутник для системи стільникового телефонного зв'язку ICO Global Communications. Після аварії учасники консорціуму Sea Launch утворили декілька комісій для розслідування її причини. В опублікованих висновках експертів компанії Боїнг причиною збою називається програмна помилка. Через цю помилку не був закритий клапан в пневматичній системі другого ступеня ракети. Ця система відповідальна за виконання декількох операцій, у тому числі за роботу рульового двигуна. Через те, що клапан не був закритий, тиск в пневматичній системі впав більше, ніж на 60% від заданого. Тому двигун не зміг розвинути необхідну тягу, а ракета, відповідно, не змогла вийти на задану орбіту.

Викид радіактивної речовини в Зах. Австралії (грудень 2001) На заводі з переробки урану в Викид радіактивної речовини в Зах. Австралії (грудень 2001) На заводі з переробки урану в Західній Австралії в кінці грудня 2001 року відбувся викид радіоактивної речовини. Розслідування інциденту показало, що стався він через "логічну помилку" в ПЗ комп'ютерів, встановлених на заводі. Розробником цього ПЗ є компанія Amec Engineering. Як повідомляється, через цю помилку під час проведення регламентних робіт сталося відключення живлення системи рідинного охолодження. У цій ситуації повинні були автоматично відключитися насоси, які качають охолоджуючу рідину, але цього не сталося. Перш ніж персонал встиг зробити це вручну, тиск у трубопроводах зріс, і один з них не витримав. За заявою компанії Heathgate Resources, яка обслуговує завод, софтверна фірма Amec виправила помилку в ПО і знову перевірила роботу всієї комп'ютерної системи заводу.

Airobus А 310 Як мінімум 5 авіакатастроф літаків Airobus A 310 можна пов'язати з Airobus А 310 Як мінімум 5 авіакатастроф літаків Airobus A 310 можна пов'язати з помилками в програмному забезпеченні.

Катастрофи Описані катастрофи, самі по собі безпрецедентні, але вони, звичайно ж не є унікальними. Катастрофи Описані катастрофи, самі по собі безпрецедентні, але вони, звичайно ж не є унікальними. Можна приводити довгий список великих і малих інцидентів в критичних до безпеки системах (mission-critical), що сталися з причини дефектів у програмному забезпеченні та проявилися тільки в режимі експлуатації. Звичайно, більшість інцидентів так чи інакше розслідувалася і осмислювалося.

Один з видатних фахівців в галузі безпеки систем та керуваннями ризиками, професор Вашингтонського Університету Один з видатних фахівців в галузі безпеки систем та керуваннями ризиками, професор Вашингтонського Університету Ненсі Левесон (Nancy Leveson) ввела спеціальний термін Safeware, який винесла в назву своєї книги [N. Leveson, "Safeware: System Safety and Computers", - Addison-Wesley, 1995], де систематично розглядаються питання безпеки і ризиків в комп'ютерних системах. Зокрема, в цій книзі розбираються деякі поширені міфологічні уявлення про ПЗ та пов'язаних з ним безпеки та ризики, що існують на тлі все більш широкого використання складних систем у потенційно небезпечних додатках. Зупинимося на деяких з них.

МІФИ ПРО БЕЗПЕЧНЕ ПЗ «ДЕШЕВЕ І ТЕХНОЛОГІЧНЕ» ПЗ Вартість написання та сертифікації дійсно надійного МІФИ ПРО БЕЗПЕЧНЕ ПЗ «ДЕШЕВЕ І ТЕХНОЛОГІЧНЕ» ПЗ Вартість написання та сертифікації дійсно надійного ПЗ дуже висока; до того ж необхідно брати до уваги витрати на супровід - знову ж такий, який не підриває надійності і безпеки. Показовий приклад: тільки супровід відносно простого і не дуже великого за обсягом (близько 400 тис. слів) програмного забезпечення для бортового комп'ютера, встановленого на американському космічному кораблі типу Shuttle, варто NASA 100 млн. дол рік.

МІФИ ПРО БЕЗПЕЧНЕ ПЗ ПРОСТОТА ВНЕСЕННЯ ЗМІН Зміни в програмних модулях легко виконати технічно, МІФИ ПРО БЕЗПЕЧНЕ ПЗ ПРОСТОТА ВНЕСЕННЯ ЗМІН Зміни в програмних модулях легко виконати технічно, проте важко зробити це без внесення нових помилок. Необхідні для гарантій безпеки верифікація і сертифікація означають нові великі витрати. До того ж, чим довше час життя програми, тим більше зростає небезпека разом зі змінами внести помилки.

МІФИ ПРО БЕЗПЕЧНЕ ПЗ Принцип повторного використання Думка про те, що використання модулів, які МІФИ ПРО БЕЗПЕЧНЕ ПЗ Принцип повторного використання Думка про те, що використання модулів, які вже себе зарекомендували з гарної сторони, так само як і "коробкового» продукту, дає гарантії відсутності в ньому помилок, дуже природня. Проте, насправді повторне використання програмних модулів може і знизити безпеку з тієї простої причини, що дані модулі спочатку розроблялися і налагоджували для використання в іншому контексті, а специфікація зазвичай не дає вичерпного звіту про всі види можливої поведінки модуля (аварія, яка сталася з Ariane 5 має в основі причину саме повторне використання модуля з некоректною для зміненого контексту специфікацією). У випадку з Therac-25 використали модулі, спочатку розроблені для попередньої версії системи (Therac-20) - у всякому разі, було точно встановлено, що саме помилки в цих повторновикористовуваних модулях викликали принаймні два смертельні випадки. Причому, ці помилки (як вже було встановлено заднім числом) виявлялися і при роботі Therac-20, але та система була влаштована так, що масивного переопромінення не відбувалося, а тому і процес корекції помилок не запускався.

МІФИ ПРО БЕЗПЕЧНЕ ПЗ Коректність ПЗ В твердження, що тестування ПЗ та / або МІФИ ПРО БЕЗПЕЧНЕ ПЗ Коректність ПЗ В твердження, що тестування ПЗ та / або "доказ" його коректності дозволяють виявити і виправити всі помилки мало хто вітить. Причина очевидна. Перш за все, вичерпне тестування складних програмних систем неможливо в принципі: реально перевірити тільки невелику частину з усього простору можливих станів програми. В результаті, тестування може продемонструвати наявність помилок, але не може дати гарантію, що їх немає. Що ж стосується використання математичних методів для верифікації ПЗ в плані його відповідності специфікації, то воно (попри оптимізм, особливо явний в 70 -х р. ) поки не увійшло в практику в скільки-небудь значному масштабі. Питання, реалістично очікувати, що для систем масштабу Ariane 5 можливо виконати повний цикл докази правильності всього ПЗ, залишається відкритим. Немає сумнівів, однак, що для окремих підсистем така задача може і повинна ставитися.

На очах підвищується складність програмно-апаратних систем, які традиційно не відносяться до розряду критичних до На очах підвищується складність програмно-апаратних систем, які традиційно не відносяться до розряду критичних до безпеки (mission-critical). Не за горами час, коли на масовий споживчий ринок почнуть надходити програмні комплекси, дефекти в яких можуть виявитися вкрай неприємними для неготових до прийняття ризику "простих" громадян. Зрештою, навіть звичайна праска здатна викликати пожежу і напевно, якийсь програмно-керований суперкухонний-комбайн недалекого майбутнього може (при ПО належної "якості") повестися несподівано (а то і небезпечно) для користувача.

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