Які бар'єри перешкоджають широкому застосуванню формальних методів? [зачинено]

Формальні методи можна використовувати для вказівки, доказування та генерації коду для програми. Це менш схильне до помилок - таким чином, здебільшого використовується в програмах безпеки / критичного значення.

Чому ми не використовуємо його частіше для повсякденного програмування, або у веб-додатках тощо ...?

Список літератури:

• Формальні методи
• Б Метод
• Лоріка Хоара

Інженер - це людина, яка може робити з доларом те, що може зробити будь-який ідіот з 10.

Обмеження ресурсами, бюджетні обмеження, часові обмеження, всі вони важливі.

Розробка програмного забезпечення з використанням формальних методів, як правило, значно дорожче і займає набагато більше часу, ніж без. Також для багатьох проектів найважче - розуміння вимог бізнесу. Все, що використання формальних методів купує вас у цьому випадку, є доказом того, що ваш код відповідає 100% вашому неповному та неправильному розумінню бізнес-вимог.

З цієї причини використання формальних методів, доказів, перевірки програм та подібних методів, як правило, обмежується "речами, що мають значення", тобто програмним забезпеченням авіоніки, системами управління медичним обладнанням, електростанціями тощо.

Програмувати чи не програмувати?

Щоб вирішити проблему з програмним продуктом, зрозумівши вимоги, ви можете НАВСЯК написати програму за допомогою мов програмування АБО вказати програму на формальній мові та використовувати засоби генерації коду. Останнє лише додає рівня абстракції.

Правильні речі чи правильні речі?

Офіційний підхід дає вам підтвердження того, що ваше програмне забезпечення працює відповідно до специфікацій. Тож ваш продукт робить все правильно. Але чи правильно це робить?

Вимоги, над якими ви працюєте, можуть бути неповними або неоднозначними. Вони навіть можуть бути баггі. У гіршому випадку реальні потреби навіть не виражені. Але малюнок вартує тисячі слів, просто зображення Google - "Що хоче клієнт", наприклад з цієї статті :

Вартість формальності

У досконалому світі ви мали б повністю деталізовані та досконалі вимоги з самого початку. Потім ви зможете повністю вказати своє програмне забезпечення. Якщо ви підете на офіційний, ваш код буде генеруватися автоматично, щоб ви були більш продуктивними. Підвищення продуктивності компенсувало б вартість формальних інструментів. І всі зараз використовували б формальні методи. То чому ж це не так?

На практиці це рідко є реальністю! Ось чому стільки проектів водоспадів не вдалося, і чому ітеративні методи розробки (спритний, RAD тощо) взяли на себе ініціативу: вони можуть впоратися з неповними та недосконалими вимогами, розробками та реалізаціями та вдосконалити їх до тих пір, поки вони не стануть нормальними.

І ось тут справа. При формальних методах кожна ітерація вимагає мати повністю послідовну формальну специфікацію. Це вимагає ретельного мислення та додаткової роботи, оскільки формальна логіка не прощає і не любить неповні думки. Прості експерименти з викиданням стають дорогими при цьому обмеженні. І так само кожна ітерація, яка б призвела до зворотного відстеження (наприклад, ідея, яка не працювала, або вимога, яку не зрозуміли).

На практиці

Якщо не зобов’язані використовувати формальні методи з юридичних чи договірних причин, ви також можете досягти дуже високої якості без формальних систем, наприклад, використовуючи програмування на основі контрактів та інші належні практики (наприклад, перегляд коду, TDD тощо). Ви не зможете довести, що ваше програмне забезпечення працює, але ваші користувачі швидше насолоджуються робочим програмним забезпеченням.

Оновлення: розмірене зусилля

У жовтневому випуску « Комунікації ОСБ» за жовтень 2018 року є цікава стаття про формально перевірене програмне забезпечення в реальному світі з деякими оцінками зусиль.

Цікаво (на основі розробки ОС для військової техніки) здається, що виготовлення офіційно перевіреного програмного забезпечення вимагає в 3,3 рази більше зусиль, ніж для традиційних інженерних методів. Тож це дійсно дорого.

З іншого боку, для отримання програмного забезпечення підвищеної безпеки таким чином потрібно в 2,3 рази менше, ніж для традиційно розробленого програмного забезпечення, якщо додати зусиль, щоб таке програмне забезпечення було сертифіковано на високому рівні безпеки (EAL 7). Тож якщо у вас високі вимоги щодо надійності чи безпеки, то, безумовно, діловий випадок має бути офіційним.

Дизайн та розробка коду seL4 зайняли два людино-роки. Якщо додати всі сероспецифічні докази за ці роки, загалом вийшло 18 осіб-років за 8700 рядків коду С. Для порівняння, L4Ka :: Фісташка, ще один мікроядр із сімейства L4, порівнянний за розміром з seL4, знадобився шість людино-років, і він не забезпечує значного рівня впевненості. Це означає, що між перевіреним програмним забезпеченням та традиційно розробленим програмним забезпеченням існує лише коефіцієнт 3.3 . Відповідно до методу оцінки Колберта та Бома, 8 традиційна сертифікація загальних критеріїв EAL7 для 8 700 рядків коду С потребує понад 45,9 осіб-років. Це означає, що формальна перевірка впровадження двійкового рівня вже перевищує коефіцієнт 2,3 менш затратні, ніж найвищий рівень сертифікації загальних критеріїв, але вони забезпечують значно більшу впевненість.

Кожна програма будь-якою мовою може розглядатися як формальна специфікація (еквівалентна деякій токарній машині). Будь-яка «формальна специфікація» вищого рівня, яка повинна бути використана для доведення формальної коректності, також - лише інша програма. Але це (як правило) погана, неповна, розпливчаста, недостатньо продумана програма. І не випадково, як правило, це пишуть люди, які не знають, як програмувати (зазвичай це експерти в галузі домену).

І тому доказ того, що одна програма сумісна (дає однакові відповіді або як би ви її характеризували) з її формальними вимогами вищого рівня, незмінно зводиться до того, як ви вирішуєте неясності у формальній специфікації вищого рівня. Не існує хорошого загального призначення для цього.

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

Навіть у перші дні логічного програмування, де ця концепція вперше здавалася такою перспективною (оскільки як специфікація високого рівня, так і фактичні основні програми могли бути написані однією мовою), ця основна проблема виявилася непереборною.