Verifica formale del programma in pratica

Come ingegnere del software, scrivo molto codice per i prodotti industriali. Elementi relativamente complicati con classi, thread, alcuni sforzi di progettazione, ma anche alcuni compromessi per le prestazioni. Faccio molti test e sono stanco dei test, quindi mi sono interessato a strumenti di dimostrazione formale, come Coq, Isabelle ... Potrei usare uno di questi per dimostrare formalmente che il mio codice è privo di bug ed essere fatto con esso? - ma ogni volta che controllo uno di questi strumenti, vado via senza essere convinto che siano utilizzabili per l'ingegneria del software di tutti i giorni. Ora, potrei essere solo io, e sto cercando suggerimenti / opinioni / idee a riguardo :-)

In particolare, ho l'impressione che per far funzionare uno di questi strumenti per me sarebbe necessario un enorme investimento per definire correttamente al prover gli oggetti, i metodi ... del programma in esame. Mi chiedo quindi se il prover non si limiterebbe a rimanere senza vapore, date le dimensioni di tutto ciò che dovrebbe affrontare. O forse dovrei sbarazzarmi degli effetti collaterali (quegli strumenti prover sembrano fare davvero molto bene con i linguaggi dichiarativi), e mi chiedo se ciò comporterebbe un "codice comprovato" che non potrebbe essere usato perché non sarebbe veloce o abbastanza piccolo. Inoltre, non ho il lusso di cambiare la lingua con cui lavoro, deve essere Java o C ++: non posso dire al mio capo che sto per scrivere codice in OXXXml da ora in poi, perché è l'unica lingua in che posso dimostrare la correttezza del codice ...

Qualcuno con più esperienza negli strumenti di correzione formale può commentare? Ancora una volta - ADORO usare uno strumento prover formale, penso che siano fantastici, ma ho l'impressione che si trovino in una torre d'avorio che non riesco a raggiungere dal modesto fossato di Java / C ++ ... (PS: I anche LOVE Haskell, OCaml ... non ho un'idea sbagliata: sono un fan dei linguaggi dichiarativi e delle prove formali, sto solo cercando di vedere come potrei realisticamente renderlo utile all'ingegneria del software)

Aggiornamento: poiché questo è abbastanza ampio, proviamo le seguenti domande più specifiche: 1) ci sono esempi di utilizzo dei tester per dimostrare la correttezza dei programmi Java / C ++ industriali? 2) Coq sarebbe adatto a quel compito? 3) Se Coq è adatto, devo prima scrivere il programma in Coq, quindi generare C ++ / Java da Coq? 4) Questo approccio potrebbe gestire threading e ottimizzazioni delle prestazioni?

Proverò a dare una risposta concisa ad alcune delle tue domande. Tieni presente che questo non è strettamente il mio campo di ricerca, quindi alcune delle mie informazioni potrebbero essere obsolete / errate.

1. Esistono molti strumenti appositamente progettati per dimostrare formalmente le proprietà di Java e C ++.

   Tuttavia, devo fare una piccola digressione qui: cosa significa dimostrare la correttezza di un programma? Il controllo del tipo Java dimostra una proprietà formale di un programma Java, vale a dire che alcuni errori, come l'aggiunta di a floate an int, non possono mai verificarsi! Immagino che tu sia interessato a proprietà molto più forti, vale a dire che il tuo programma non può mai entrare in uno stato indesiderato, o che l'output di una determinata funzione è conforme a una determinata specifica matematica. In breve, esiste un ampio gradiente di ciò che può significare "dimostrare un programma corretto", da semplici proprietà di sicurezza a una prova completa che il programma soddisfa una specifica dettagliata.

   Ora suppongo che tu sia interessato a dimostrare forti proprietà sui tuoi programmi. Se sei interessato alle proprietà di sicurezza (il tuo programma non può raggiungere un determinato stato), in generale sembra che l'approccio migliore sia il controllo del modello . Tuttavia, se si desidera specificare completamente il comportamento di un programma Java, la soluzione migliore è utilizzare un linguaggio di specifica per quella lingua, ad esempio JML . Esistono tali linguaggi per specificare il comportamento dei programmi C, ad esempio ACSL , ma non conosco C ++.

2. Una volta che hai le tue specifiche, devi dimostrare che il programma è conforme a quelle specifiche.

   Per questo è necessario uno strumento che abbia una comprensione formale sia della specifica che della semantica operativa del proprio linguaggio (Java o C ++) al fine di esprimere il teorema di adeguatezza , vale a dire che l'esecuzione del programma rispetta le specifiche.

   Questo strumento dovrebbe anche permetterti di formulare o generare la prova di quel teorema. Ora entrambi questi compiti (specificare e provare) sono piuttosto difficili, quindi sono spesso separati in due:

   • Uno strumento che analizza il codice, le specifiche e genera il teorema di adeguatezza. Come ha detto Frank, Krakatoa è un esempio di tale strumento.

   • Uno strumento che dimostra il teorema (i), automaticamente o interattivamente. Coq interagisce con Krakatoa in questo modo e ci sono alcuni potenti strumenti automatizzati come Z3 che possono anche essere usati.

   Un punto (minore): ci sono alcuni teoremi che sono troppo difficili da dimostrare con metodi automatizzati e che i dimostratori di teoremi automatici hanno occasionalmente dei bug di solidità che li rendono meno affidabili. Questa è un'area in cui Coq brilla in confronto (ma non è automatico!).

3. Se vuoi generare il codice Ocaml, allora scrivi prima in Coq (Gallina), quindi estrai il codice. Tuttavia, Coq è terribile nel generare C ++ o Java, se è persino possibile.

4. Gli strumenti di cui sopra possono gestire problemi di threading e prestazioni? Probabilmente no, i problemi di prestazioni e threading sono gestiti meglio da strumenti appositamente progettati, in quanto sono problemi particolarmente difficili. Non sono sicuro di avere degli strumenti da raccomandare qui, anche se il progetto PolyNI di Martin Hofmann sembra interessante.

In conclusione: la verifica formale dei programmi Java e C ++ del "mondo reale" è un campo ampio e ben sviluppato, e Coq è adatto a parti di tale compito. Puoi trovare una panoramica di alto livello qui per esempio.

Vorrei menzionare tre notevoli applicazioni di metodi formali / strumenti di verifica formale nell'industria o in sistemi reali non banali. Nota che ho poca esperienza su questo argomento e li imparo solo leggendo articoli.

1. Lo strumento open source Java Pathfinder (in breve JPF) rilasciato dalla NASA nel 2005 è un sistema per verificare i programmi eseguibili bytecode Java (vedi Java Pathfinder @ wiki ). È stato utilizzato per rilevare incoerenze nel software esecutivo per K9 Rover presso la NASA Ames.

2. Questo documento: L' uso del controllo del modello per trovare gravi errori del file system @ OSDI'04 mostra come utilizzare il controllo del modello per trovare errori gravi nei file system. Un sistema chiamato FiSC viene applicato a tre file system ampiamente utilizzati e ampiamente testati: ext3, JFS e ReiserFS e vengono rilevati 32 bug gravi. Ha vinto il Best Paper Award.

3. Questo documento: In che modo Amazon Web Services utilizza i metodi formali @ CACM'15 descrive come AWS applica i metodi formali ai suoi prodotti come S3, DynamoDB, EBS e Gestione blocchi distribuiti interni. Si concentra sullo strumento TLA + di Lamport . A proposito, Lamport ha usato intensamente la propria cassetta degli attrezzi TLA. Dà spesso una verifica (abbastanza completa) formale in TLA degli algoritmi / teoremi proposti da lui stesso (così come coautori) in appendici ai documenti.

Una specifica formale di un programma è (più o meno) un programma scritto in un altro linguaggio di programmazione. Di conseguenza, la specifica includerà sicuramente i propri bug.

Il vantaggio della verifica formale è che, poiché il programma e le specifiche sono due implementazioni separate, i loro bug saranno diversi. Ma non sempre: una fonte comune di bug, casi trascurati, spesso corrisponderà. Pertanto, la verifica formale non è una panacea: può ancora mancare un numero non banale di bug.

Uno svantaggio della verifica formale è che può imporre qualcosa come il doppio del costo di implementazione, probabilmente di più (è necessario uno specialista nelle specifiche formali e è necessario utilizzare gli strumenti più o meno sperimentali che ne derivano; ciò non sarà economico ).

Immagino che impostare casi di prova e impalcature per eseguirli automaticamente sarebbe un uso migliore del tuo tempo.

La verifica formale è ora possibile per i programmi scritti in un sottoinsieme di C ++ progettato per sistemi embedded critici per la sicurezza. Vedere http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.ppt per una breve presentazione e http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf per il documento completo.

Fai alcune domande diverse. Concordo che sembra che i metodi di verifica formale per applicazioni industriali / commerciali non siano così comuni. si dovrebbe capire, tuttavia, che molti compilatori di principi di "verifica formale" sono integrati per determinare la correttezza del programma! quindi, in un certo senso, se usi un compilatore moderno, stai usando gran parte dello stato dell'arte nella verifica formale.

Dici "Sono stanco dei test" ma la verifica formale non è in realtà un sostituto per i test. in un certo senso è una variazione sui test.

Tu citi Java. ci sono molti metodi avanzati di verifica formale integrati in un programma di verifica Java chiamato FindBugs che può essere effettivamente eseguito su basi di codice di grandi dimensioni. Nota che verranno visualizzati sia "falsi positivi che falsi negativi" e i risultati devono essere rivisti / analizzati da uno sviluppatore umano. Ma nota anche se non sta rilevando veri e propri difetti funzionali, generalmente genera "antipattern" che dovrebbero essere comunque evitati nel codice.

Non fai più menzione della tua particolare applicazione se non "industriale". La verifica formale nella pratica tende a dipendere dalla particolare applicazione.

Le tecniche di verifica formale sembrano essere ampiamente utilizzate in EE per dimostrare la correttezza del circuito, ad esempio nella progettazione di microprocessori.

Ecco un esempio di un sondaggio sugli strumenti di verifica formale nel campo EE di Lars Philipson .

Forse, un modello di controllo può essere utile.

http://alloytools.org/documentation.html La lega è un modello di controllo.

Una bella presentazione che spiega il concetto di controllo del modello usando Alloy: https://www.youtube.com/watch?v=FvNRlE4E9QQ

Nella stessa famiglia di strumenti arrivano i "test basati sulle proprietà", tutti cercano di trovare un contro-esempio per il modello di specifica del software.