Якщо ви засвоїли формальні методи програмного забезпечення, наскільки корисними ви їх знайшли?

Якщо ви були навчені використовувати формальні методи (FM) для програмування:

• Наскільки корисним ви його знайшли?
• Що було пов'язано з вашим тренуванням у галузі FM (наприклад, курс, книга)?
• Які інструменти FM ви використовуєте?
• Які переваги у швидкості / якості надав вам порівняно з тим, що не використовуєте FM?
• Яке програмне забезпечення ви створюєте за допомогою FM?
• І якщо ви зараз безпосередньо не використовуєте FM, чи варто було принаймні навчитися ??

Мені цікаво почути стільки досвіду / думок про FM, скільки можна знайти в цій спільноті; Я починаю читати про це і хочу знати більше.

Фон

Програмування та розробка / інженерія програмного забезпечення - одні з найновіших навичок / професій людини на Землі, тому не дивно, що це поле незріле - що показує головний вихід нашого поля як код, який зазвичай запізнюється та схильний до помилок. Незрілість галузі також показує широкий запас продуктивності між середніми та найвищими кодерами. Такі похмурі факти добре висвітлені в літературі та представлені такими книгами, як Кодекс Стіва Макконнелла .

Застосування формальних методів (FM) було запропоновано основними фігурами в програмному забезпеченні / CS (наприклад, пізній Е. Дійкстра ) для вирішення (однієї з) першопричин помилок: відсутність математичної суворості в програмуванні. Наприклад, Dijkstra виступав за те, щоб студенти разом розробляли програму та її доказ .

Здається, FM є набагато більш поширеним у європейських навчальних програмах порівняно зі США. Але в останні кілька років нові "легкі" підходи до FM та інструменти на зразок Alloy привернули певну увагу. Тим не менш, FM далеко не звичайне використання у промисловості, і я сподіваюся на деякі відгуки про те, чому.

Оновлення

На сьогодні (14.10.2010) із шести відповідей нижче, ніхто не чітко сперечався щодо використання ФМ у роботі "реального світу". Мені дуже цікаво, якщо хтось може і захоче; або, можливо, FM справді ілюструє розрив між науковими колами (FM - майбутнє!) та галуззю (FM - це здебільшого марно).

Абсолютно марно ні для чого нетривіального.

У мене був курс, який, влучно, називався "Формальні методи", який був зосереджений на "Сплаві". Був ще один клас, який зосередився на моделюванні одночасності з LTSA - однаково марним.

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

У мене є досвід роботи в CSP (Комунікація послідовних процесів). Я не зубнув власний ріг, але я написав магістерську дисертацію про Timed CSP, особливо "компілюючи" специфікації, написані формальними методами, у виконуваний C ++. Я можу сказати, що я маю певний досвід формальних методів. Після того, як я закінчив ступінь і влаштувався на роботу в галузі, я взагалі не використовував формальних методів. Формальні методи все ще занадто теоретичні, щоб застосовуватись у галузі. Формальні методи знайшли деяке практичне застосування в області вбудованих систем. Наприклад, NASA використовує формальні методи у своїх проектах. Я б припускав, що формальні методи дуже далеко не широко застосовуються у галузі. Просто не має сенсу писати специфікації програм у формальних методах, а потім "по-людськи інтерпретувати" їх на ваш вибір. Звичайна англійська мова та діаграми працюють краще для цього, в той час як тестові модулі та інтеграції роблять досить непогану роботу з "перевірки" правильності коду. Я думаюформальні методи залишатимуться у світі академіків ще деякий час .

Діаграми стану та сітки Петрі корисні для моделювання та аналізу протоколів та систем реального часу. Спочатку вони допомагають розробити рішення. По-друге, вони допомагають знайти тестові випадки захоплюючого програмного забезпечення у дуже конкретних ситуаціях.

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

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

Одне, що я підбирав, що є загалом кориснішим, - це концепція інваріанта, заява про програму та її стан, що завжди відповідає дійсності. Все, що ви можете викликати, це добре.

Як було сказано вище, я не є ідеальним математиком, і тому мої докази іноді містять помилки. Однак, на мій досвід, це, як правило, великі тупі помилки, які легко вловити та виправити.

Я взяв аспірантуру з офіційного програмного аналізу, де ми зосередилися на оперативній семантиці. Я зробив свій остаточний документ про зусилля seL4, переглядаючи формальні методи, які вони використовували. Моє основне вилучення з точки зору практичності було те, що воно має граничну цінність. Ви не тільки повинні написати програму, ви повинні написати підтвердження. Ого. Два джерела помилок. Не лише один. Крім того, було встановлено величезну кількість обмежень щодо фактичного коду. Офіційно описати фізичний комп'ютер, включаючи введення-виведення , дуже важко .

Минулого року самоучка себе TLA + використовую з тих пір. Це один із перших інструментів, до якого я звертаюсь кожного разу, коли починаю проект. Помилка більшості людей полягає в тому, що вони припускають, що формальні методи - це все або нічого: або ти не використовуєш формальні методи, або ти маєш повну перевірку. Однак між ними є щось: формальна специфікація , де ви перевіряєте, чи абстрактна специфікація вашого проекту не порушує ваших інваріантів. На відміну від перевірки, специфікація досить практична для використання у промисловості.

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

process node \in 1..5 \* Nodes
variables online = TRUE,
          stored \in SUBSET data; \* Some set
begin 
  Transfer:
    either
      with node \in Nodes, datum \in stored do
        node.stored := node.stored \union {datum};
      end
    or \* crash
      online := FALSE;
    end either;
end process;

Цей фрагмент визначає п'ять вузлів, які працюють одночасно, виконуючи передачі у довільному порядку, де кожна передача є довільною частиною даних до довільного вузла. Крім того, ми вказали, що будь-яка передана передача може вийти з ладу і спричинити збій вузла. І ми можемо змоделювати всі ці способи поведінки в контрольній моделі TLA +! Таким чином ми можемо перевірити, що незалежно від порядку, рівня відмов тощо, наші вимоги все ще зберігаються. Якщо говорити про це, додамо пару вимог. По-перше, що ми ніколи не передаємо дані в офлайн-вузол:

[][\A node \in Nodes: ~online => UNCHANGED node.stored]_vars

У нашій спрощеній версії перевірка моделі знайде стан відмови. Ми також можемо вказати "будь-який фрагмент даних є щонайменше в одному онлайн-вузлі":

\A d \in data: \E n \in Nodes: n.online /\ d \in n.stored

Що теж не вдасться. Удачі, перевіривши їх за допомогою одиничного тесту!

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

Раніше я працював у відділі ICL, перш ніж їх придбав Fujitsu. У них були великі урядові контракти, які вимагали підтвердження того, що програмне забезпечення працює як рекламоване, тому вони побудували машину, яка буде приймати офіційну специфікацію, написану на Z та підтверджувати код під час її запуску, з великим зеленим або червоним світлом для пропуску / невдача.

Це було дивовижною справою, але, як зазначає поважаний @FishToaster , було марним для нічого нетривіального.

1. " Наскільки корисно ви знайшли це? "

Застосування мереж Петрі в комп'ютерному програмуванні дуже корисно. Я створив метод «Чисті елементи та анотації», заснований на мережах Петрі (Chionglo, 2014). Я застосовую метод з 2014 року для написання програм JavaScript, які використовують API Acrobat / JavaScript для програм PDF-форм.

2. « Що стосувалося вашого навчання у галузі FM (наприклад, курс, книга)? "

Я «тренувався» на Петрі Мережі шляхом самостійного навчання. Я читав глави про сітки Петрі з підручника «Сітки Петрі та Графчет: засоби для моделювання дискретних систем подій» (Давид та Алла, 1992). Я також читав наукові статті про Петрі Мережі. Після створення та документування «Чистих елементів та анотацій» я кілька тижнів практикував застосування методу.

3. " Які інструменти для використання FM ви використовуєте? "

Я малюю схеми Петрі Net за допомогою PowerPoint. Я створюю перегляд форм анотацій за допомогою Word. Я створюю токенові ігри як програми формату PDF, використовуючи Acrobat та Notepad. Після додавання записів до форми переклад цих записів у код JavaScript є систематичним. Таким чином, повинна бути можливість автоматизувати переклад. Якщо «записи» були додані до графічних об’єктів у PowerPoint, тоді також слід мати можливість систематично переводити їх у код JavaScript та автоматизувати цей переклад. Я також використовую набір інструментів незавершеного виробництва, які виконують ці переклади, та для створення додаткових ресурсів для створення програм PDF-форм (Chionglo, 2018; 2017).

4. « Які переваги у швидкості / якості ви отримали у порівнянні з тим, що не використовуєте FM? "

Я можу писати програми JavaScript, використовуючи "Чисті елементи та анотації" швидше, ніж можу написати програму JavaScript, не використовуючи "Чисті елементи та анотації". А для великих програм я можу припинити кодування і повернутися до кодування пізніше (або набагато пізніше), не задаючись питанням, де продовжувати (Chionglo, 2019). У деяких випадках я можу писати програми JavaScript, використовуючи "Чисті елементи та анотації", але не можу писати програми JavaScript, не використовуючи "Чисті елементи та анотації". Наприклад, я не міг би створити нерекурсивні реалізації рекурсивних функцій без використання "Чистих елементів та анотацій" (Chionglo, 2019b; 2018b; 2016). Це вірно з інструментами незавершеного виробництва чи без них.

5. " Яке програмне забезпечення ви створюєте за допомогою FM? "

Я використовую "Чисті елементи та анотації" для створення програм JavaScript, які використовують API Acrobat / JavaScript для додатків PDF-форм. Я також можу застосувати метод створення програм JavaScript для документів HTML і створення ескізів Arduino (Chionglo, 2019c; 2019d).

6. " І якщо ви зараз безпосередньо не використовуєте FM, чи варто було принаймні вчитися? " Не застосовується.

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

Chionglo, JF (2019b). Обчислення N-го терміну рекурсивного відношення: Використання нерекурсивної функції - відповідь на запитання на обміні стека математики. < https://www.academia.edu/38496025/Computing_the_N-th_Term_of_a_Recursive_Relation_Using_a_Non-Recursive_Function_A_Reply_to_a_Question_at_Mathematics_Stack_Exchange >.

Chionglo, JF (2019c). Логіка, моделювання та ескіз контролю ефектів полум'я: відповідь на запит на Форумі спільноти Arduino. https://www.academia.edu/40342956/Flame_Effect_Control_Logic_Simulation_and_Sketch_A_Reply_to_a_Request_at_the_Arduino_Community_Forum .

Chionglo, JF (2019). Як продовжувати кодування програми після тривалої перерви? Відповідь на “Як ви знаєте, де ви зупинилися у своїх кодах після 2-тижневої перерви?” - Обмін стеками програмного забезпечення. https://www.academia.edu/39705042/How_I_Continue_Coding_an_Application_after_a_Long_Break_Reply_to_How_do_you_know_where_you_stopped_in_your_codes_after_a_2-week_break_Software_Engineering_Stack_Exchange .

Chionglo, JF (2019d). Показувати та приховувати логіку управління: надихає запитання під час переповнення стека. < https://www.academia.edu/40283015/Show-and-Hide_Control_Logic_Inspired_by_a_Question_at_Stack_Overflow >.

Chionglo, JF (2018b). Модель сітки Петрі для фактору числа: і нерекурсивна функція JavaScript для її обчислення. <>.

Chionglo, JF (2018). Створіть Hyper Form ™ - Робочий процес у процесі виконання: оновлення досліджень у галузі мережевого програмування. https://www.academia.edu/37697498/Create_Hyper_Form_-A_Workflow_in_Progress_Update_on_the_Net_Programming_Research .

Chionglo, JF (2017). Чисте програмування: Дослідницька пропозиція: для розробки програм PDF-форм за допомогою PowerPoint та Acrobat. https://www.academia.edu/33374809/Net_Programming_A_Research_Proposed_For_Developing_PDF_Form_Applications_with_PowerPoint_and_Acrobat. .

Chionglo, JF (2016). Чиста модель Петрі для обчислення числа Фібоначчі. https://www.academia.edu/31748108/A_Petri_Net_Model_for_Computing_the_Fibach_Number.

Chionglo, JF (2014). Чисті елементи та примітки для комп'ютерного програмування: обчислення та взаємодії в PDF. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Девід, Р. та Х. Алла. (1992). Сітки Петрі та Графсет: Інструменти для моделювання систем дискретних подій. Верхнє сідло, штат Нью-Джерсі: Зал Prentice.