9.13. Технологія model checking
Розробка паралельних та розподілених багатопоточних програм вимагає особливої ретельності та синхрогвзації роботи окремих частин програми. Це обумовлено великою кількістю помилок, які виникають при розробці таких програм. Особливо це актуально для бортових систем управління літаком або космічним кораблем. Паралельні та розподілені системи можуть працювати коректно довгий час і роками зберігати 'тонкі' помилки, які можуть проявитись у виключних ситуаціях. Такі помилки призводили до крупних аварій і катастроф. Нагадаємо найбільш гучні з них. Так 4 червня 1966 р. на 39 секунді при першому запуску вибухнула ракета «Аріан 5» – аналог російської ракети «Протон». Бортова система ракети «Аріан 5» використовувала ПЗ попередньої версії «Аріан 4», але архітектура апаратної частини була змінена. Після проведеного ретельного розслідування було виявлено помилку в навігаційній програмі бортового комп'ютера. Втрати були величезними. Це ракета, вартість якої перевищувала 7 млрд доларів, встановлене на борту наукове обладнання вартістю більш ніж півмільярда доларів, До цього треба додати втрати від недоотриманої вигоди, а також втрати репутації ракети-носія. Непрямі втрати склали біля 2 млрд. доларів.
25 грудня 2004 р. після семирічного польоту космічний зонд «Гюйгенс» відділився від автоматичної міжнародної станції «Кассіні» і почав спуск на поверхю Титану - супутника Сатурну. 15 січня 2005 р. зонд вперше в історії почав передавати інформацію з поверхні Титану. Помилка в бортовій системі призвела до того, що половина переданої інформації була втрачена. Загальні затрати на розробку складали 2,5 млрд. доларів.
20 грудня 1995 р. зазнав катастрофи літак «Боінг» 757, загинуло 159 людей. Розслідування виявило помилку в одному символі в програмній системі управління польотом. Компанії-виготовники бортового комп'ютера та ПЗ були визнані винними в загибелі людей, родичам жертв було виплачено 300 млн. доларів.
23 березня 2003 р. система «Patriot» помилково ідентифікувала британський бомбардувальник «Tornado» як наближаючу ворожу ракету, та автоматично виконала залп. Загинули 2 пілоти. 2 квітня 2003 р. системою «Patriot» був знищений американський винищувач F-16, пілот загинув. В обох випадках причиною були помилки в бортовій системі автоматичного виявлення цілі та наведення.
Наведені приклади показують, що помилки в складних програмних та апартних системах регулярно виявляються при розробці складних систем.
В наш час, коли все частіше людське життя залежить від роботи автоматичних систем, проблема гарантії коректності програмних та апаратних частин цих систем набуває першочергового значення. Надійність та передбачуваність у поведінці таких систем є більш важливим чинником, ніж усе інше.
Правильність таких програм неможливо довести простим тестуванням, майже на всіх наборах початкових даних вони можуть працювати правильно. Тільки строгий формальний аналіз та верифікація програми можуть виявити помилку.
Формальна верифікація програми являє собою сукупність прийомів та методів формального доведення того, що модель програмної системи задовільняє заданій формальній специфікації. Оскільки будь-що формально довести можна тільки відносно формальної моделі, то аналізуєма система для верифікації та наступної реалізації повинна бути представлена формальною моделлю. Вимоги до кінцевого продукту частіше за все розмиті. Для здійснення верифікації специфікація програми повинна складатись з набору формальних тверджень щодо бажаних властивосткй поведінки системи. Для формальної специфікації застосовується мови логики, кожне твердження якої може бути істиним або хибним для програмної системи, яка перевіряється. Верифікація передбачає перевірку виконання заданих формальних тверджень на данній формальній моделі. В області верифікації програм впродовж десятиліть робились серйозні зусилля по розробці теорії, алгоритмів та техніки верифікації. На даний час ці методи розробляються у трьох основних напрямках:
дедуктивна верифікація;
перевірка еквівалентності;
переваірка моделі (model checking).
Дедуктивна верифікація – це перевірка правильності програми, яка зводиться до доведення теорем у підходящій логічній системі. Цей напрямок розробляється вже більше 40 років, з тих часів, коли Роберт Флойд та Ентоні Хоар вперше поставили проблему доведення правильності програм. Верифікація програм при цьому виконується дедукцією на основі аксиом та правил виводу. Це досить складна процедура не може бути повністю аітоматизована, вона вимагає участі людини, яка діє на основі здогадок та передбачень, та використовує інтуіцію при побудові інваріантів та нетривіальному виборі альтернатив.
Перевірка еквівалентності пов'язана з розробкою формальних моделей взаємодіючих процесів, поданням в рамках таких моделей, як специфікації, так і реалізації та перевіркою еквівалентності поведінок формально визначених моделей поведінки. Цей напрямок був розпочатий працями Робіна Міллера розробкою ним алгебри процесів Обчислення взаємодіючих систем (Calculus of Communicating systems – CCS) біля 30 років тому.
Метод model checking [16] пов'язаний з формальною перевіркою виконання на моделі реалізації властивостей поведінки, які специфіковані на мові формальної логики. Цей метод розроблявся біля 20 років. Метод model checking може бути повністю автоматизований. Model checking – це метод перевірки того, що на даній формальній моделі системи задана логічна формула виконується (приймає істинне значення). Ця техніка була розроблена для моделей систем переходів і так званих «темпоральних» логик. Для реалізації за цим методом реальна система подається простою моделлю у вигляді кінцевого автомату з системою переходів та кінцевою кількістю станів. При цьому кожен стан описується так званими структурами Крипке, які враховують всі стани моделі, початковий стан, правила переходу в інші стани із застосуванням темпоральної логики.
На даний час ця методика розробки складного ПЗ має промислове впровадження та підвищений рівень довіри і широко застосовується при розробці складних систем. Вчені Е. Кларк, А.Емерсон та Дж. Сифакис були були нагороджені у 2007 р. премією імені А. Т'юринга за їх внесок в доведення метода model checking до виробничої технології, яка дозволяє здійснювати верифікацію моделей реальних програмних та апаратних систем. В багатьох роботах наводяться результати використання цієї технології для верифікації програмно-апаратних систем у критичних застосуваннях.
- Міністерство освіти і науки україни
- 9.12. Огляд WinDev 154
- 10. Історія операційних систем 169
- Список літератури 187
- Передмова
- 1. Передвісники комп’ютерної ери
- 1.1. Комп’ютерна програма–що це?
- 1.2. Доелектронна історія обчислювальної техніки
- Логарифмічна лінійка
- 1.3. Можливості двійкового коду
- 1.4. Розвиток двійкової системи
- 1.5. Винахід перших комп’ютерів
- Перша в історії працююча програмнокерована універсальна обчислювальна машина z-3 (1941 р.)
- 1.6. Гарвардська архітектура
- 1.7. Архітектура фон Неймана
- 1.8. Створення зрозумілих людині кодів
- 1.9. Крок на благо програмування
- 1.10. Можливості програмного управління
- 2. Нові мови програмування
- 2.1. Поневіряння пакетної обробки
- 2.2. Універсальна мова програмування
- 2.3. Усунення неоднозначності
- 2.4. Заклик до дотримання математичної строгості
- 2.5. Пошук та усунення помилок
- 2.6. Нелегке мистецтво програмування
- 2.7. Обчислювальна техніка та програмування в срср
- 3. Розквіт та хаос програмного забезпечення
- 3.1. Місце народження хакерів
- 3.2. Два чародії програмування
- 3.3. Перші промислові стандарти
- 3.4. Дружній інтерфейс
- 3.5. Прообраз сучасного «ноутбука»
- 4. Болісний шлях розвитку програмування
- 4.1. Плануюче обчислення
- 4.2. Внесок Великої Британії
- 4.3. Програмування англійською мовою
- 5. Три комерційні гіганти
- 5.1. Перша комерційна мова програмування
- 5.2. Обчислювальна техніка приходить у бізнес
- 5.3. Народження codasyl
- 5.4. Конференція в Цюріху
- 5.5. На шляху до сумісності комп’ютерів
- 5.6. Розбіжності Нового Світу
- 6. Десятиліття динамічного розвитку
- 6.1. Перші кроки непроцедурної мови
- 6.3. Алфавітне хрещення
- 6.4. Успіх та суперечки
- 6.5. Інженерний підхід
- 6.6. Структурний підхід
- 6.7. Поява мови “Ада”
- 7. Програмування приходить у наші домівки
- 7.1. Розквіт Бейсіка
- 7.2. Поява мови Модула-2
- 7.3. Музикальний француз
- 7.4.Довгожитель Lisp – інструмент функціонального програмування
- 7.5. Prolog – нездійснена мрія еом V покоління
- 7.6. Революція на ім’я Java
- 8. Історія і шляхи розвитку супер-еом
- 8.1. Усе починалося з менфреймов
- 8.2. Напрями розвитку обчислювальної техніки
- 8.3. Розвиток елементної бази. Закон Мура
- 8.4. Вдосконалення архітектури
- Звичайна послідовн обробка
- Конвеєрна обробка
- 9. Сучасний стан та перспективи розвитку програмування
- 9.1. Криза у програмуванні
- 9.2. Методологія процедурно-орієнтованогопрограмування
- 9.3. Методологія об’єктно-орієнтованогопрограмування
- 9.4. Методологія об’єктно-орієнтованогоаналізу та проектування
- 9.5. Технології програмування
- 9.6. Case –засоби
- 9.7. Методологія rad
- 9.11.1. Знайомство с LightSwitch
- 9.11.2. Архитектура LightSwitch
- 9.11.3. Створення проекту в Microsoft Visual Studio LightSwitch
- 9.11.4. Дванадцять основних переваг LightSwitch
- 9.12. Огляд WinDev
- 9.12.1. ПризначенняWinDev
- 9.12.2. Деякі характеристики wLanguage
- 9.13. Технологія model checking
- 9.14. NeoBook – программирование для непрограммистов
- 9.14.1. Введення для секретарок
- 9.14.3. Можливості та області застосування
- 9.15. Файлові системи найближчого майбутнього
- 9.15.1. Зетта-повінь настає
- 9.15.2. Файлова система zfs
- 9.15.3. Файлова системаBtrfs
- 9.15.4. Файлова системаHammer
- 10. Історія операційних систем
- 10.1. Послідовна обробка даних
- 10.2. Прості пакетні системи
- 10.3. Багатозадачні пакетні системи
- 10.4. Системи з режимом розподілу часу
- 10.5. Основні досягнення
- 10.6. Сучасні системи unix
- 10.7. Os/2. Битва двох гігантів
- Список літератури