Усі, крім самих тривіальних програм, заповнені помилками, і все, що обіцяє їх видалити, надзвичайно заманливо. На даний момент докази коректності є кодом надзвичайно езотеричні, головним чином через важко засвоєння цього та додаткових зусиль, необхідних для доведення програми правильності. Як ви вважаєте, коли доказ коду коли-небудь зніме?
Відповіді:
Не дуже в цьому сенсі, але чисте функціональне програмування добре в цій галузі. Якщо ви використовуєте Haskell, швидше за все, ваша програма правильна, якщо код збирається. За винятком IO, хороша допомога є типовою системою.
Також може бути корисним програмування контракту. Див. Договори Microsoft Code
Усі, крім самих тривіальних програм
не може бути підтверджено правильність при розумних зусиллях. Для будь-якого формального підтвердження правильності вам потрібна принаймні формальна специфікація, і ця специфікація повинна бути повною та правильною. Це, як правило, нічого, що ви можете легко створити для більшості реальних програм. Наприклад, спробуйте написати таку специфікацію для чогось типу інтерфейсу користувача цього дискусійного сайту, і ви знаєте, що я маю на увазі.
Тут я знайшов приємну статтю на тему:
http://www.encyclopedia.com/doc/1O11-programcorrectnessproof.html
printf("1")правильна чи ні (наприклад, тому, що вимога була "надрукувати однаково розподілене випадкове число від 1 до 6"), такий статичний аналізатор не може вирішити.
Проблема з офіційними доказами полягає в тому, що вона лише відсуває проблему на крок назад.
Сказати, що програма є правильною, рівнозначно тому, що програма робить те, що повинна робити. Як ви визначаєте, що має робити програма? Ви вказуєте це. І як ви визначаєте, що програма повинна робити в крайніх випадках, які специфікація не охоплює? Ну, тоді вам доведеться зробити детальнішу характеристику.
Отже, скажімо, ваша специфікація остаточно деталізується, щоб описати правильну поведінку кожного аспекту всієї програми. Тепер вам потрібен спосіб зробити так, щоб ваші доказові інструменти зрозуміли це. Тож вам доведеться перекласти специфікацію на якусь формальну мову, яку інструмент доказування може зрозуміти ... ей, почекай хвилинку!
Офіційна перевірка пройшла довгий шлях, але зазвичай промисловість / широко використовувані інструменти відстають від останніх досліджень. Ось кілька останніх зусиль у цьому напрямку:
Spec # http://research.microsoft.com/en-us/projects/specsharp/ Це розширення C #, яке підтримує кодові контракти (до / після умов та інваріантів) і може використовувати ці контракти для різних типів статичного аналізу .
Подібні проекти для цього існують і для інших мов, таких як JML для java, і у Ейфеля це вбудовано.
Подальше, такі проекти, як шлам та вибух, можуть використовуватися для перевірки певних поведінкових властивостей з мінімальними анотаціями / втручаннями програмістів, але все ще не можуть мати справу з повною загальністю сучасних мов (такі речі, як ціла арифметика переповнення / покажчика, не моделюються).
Я вважаю, що в майбутньому ми побачимо набагато більше цих прийомів, що застосовуються на практиці. Основним бар'єром є те, що програмних інваріантів важко зробити без анотацій вручну, а програмісти зазвичай не хочуть надавати ці анотації, оскільки це занадто виснажливо / забирає багато часу.
За винятком випадків, коли не з'явиться метод автоматичного доведення коду без великої роботи розробника.
Деякі інструменти формальних методів (наприклад, Frama-C для критичного вбудованого програмного забезпечення C) можна розглядати як (своєрідне) надання або принаймні перевірка підтвердження правильності даного програмного забезпечення. (Frama-C перевіряє, чи програма дотримується її формалізованої специфікації, в якомусь сенсі, і поважає явно анотовані інваріанти в програмі).
У деяких секторах можливі такі формальні методи, наприклад, як DO-178C для критичного програмного забезпечення в цивільних літальних апаратах. Тому в деяких випадках такі підходи можливі і корисні.
Звичайно, розробка менш глючного програмного забезпечення дуже дорога. Але підхід до формального методу має сенс для якогось програмного забезпечення. Якщо ви песимісти, ви можете подумати, що помилка переміщена з коду до її формальної специфікації (яка може мати деякі «помилки», оскільки формалізувати призначене поведінку програмного забезпечення складно і схильність до помилок).
Я натрапив на це питання, і думаю, що це посилання може бути цікавим:
Промислове застосування Astrée
Доведення відсутності RTE у системі, що використовується у Airbus із понад 130 000 рядків коду у 2003 році, здається не поганим, і мені цікаво, чи хтось скаже, що це не реальний світ.
Ні. Загальне прислів’я для цього: "У теорії, теорія та практика однакові. На практиці ні".
Один дуже простий приклад: друкарські помилки.
Насправді запуск коду за допомогою тестування одиниць виявляє такі речі майже одразу, і згуртований набір тестів позбавить потреби будь-яких офіційних доказів. Усі випадки використання - добрі, погані, помилки та кращі випадки - повинні бути перераховані в одиничних тестах, які в кінцевому підсумку є кращим доказом, що код правильний, ніж будь-який такий доказ, який є окремим від коду.
Особливо, якщо вимоги змінюються, або алгоритм оновлюється, щоб виправити помилку - формальне підтвердження, швидше за все, закінчиться застарілим, як і часто отримують коментарі до коду.
Я думаю, що обмеження, встановлені для підтвердження коректності через проблему зупинки, можуть стати найбільшою перешкодою для того, щоб докази коректності стали основними.
Його вже використовують усі. Кожен раз, коли ви використовуєте перевірку типу мови програмування, ви в основному робите математичний доказ правильності вашої програми. Це працює вже дуже добре - це просто вимагає вибрати правильні типи для кожної функції та структури даних, які ви використовуєте. Чим точніший тип, тим кращу перевірку ви збираєтеся отримати. Існуючі типи, доступні в мовах програмування, вже мають достатньо потужні інструменти для опису практично будь-якої можливої поведінки. Це працює всіма доступними мовами. C ++ та статичні мови просто перевіряють у компільований час, тоді як більш динамічні мови, як python, роблять це під час запуску програми. Чек все ще існує на всіх цих мовах. (наприклад, c ++ вже підтримує перевірку побічних ефектів так само, як і haskell,
mutableабо const_cast. Я, звичайно, бачу зв’язок, який ви накреслюєте там, але смак двох підходів мені здається досить різним.