Come possiamo sapere che i metodi formali funzionano?

Un obiettivo importante dei metodi formali è dimostrare la correttezza dei sistemi, sia con mezzi automatizzati che diretti all'uomo. Tuttavia, sembra che anche se è possibile fornire una prova di correttezza, NON si può essere in grado di garantire che il sistema non fallirà. Per esempio:

• Le specifiche potrebbero non modellare correttamente il sistema oppure un sistema di produzione potrebbe essere troppo complicato da modellare oppure il sistema potrebbe essere intrinsecamente difettoso a causa di requisiti contraddittori. Quali tecniche sono note per verificare se una specifica ha un senso del tutto?
• Anche il processo di prova può essere imperfetto! Chi sa che quelle regole di inferenza sono corrette e legittime? Inoltre, le prove possono essere molto grandi e come facciamo a sapere che non contengono errori? Questo è il cuore della critica in "Processi sociali e prove di teoremi e programmi" di Millo, Lipton e Perlis. In che modo i ricercatori sui metodi formali moderni rispondono a questa critica?
• In fase di esecuzione, ci sono molti eventi e fattori non deterministici che possono influenzare seriamente il sistema. Ad esempio, i raggi cosmici possono alterare la RAM in modi imprevedibili e, più in generale, non abbiamo garanzie che l'hardware non subisca guasti bizantini, contro i quali Lamport ha dimostrato di essere molto difficile da sostenere. Quindi la correttezza del sistema statico non garantisce che il sistema non fallisca! Esistono tecniche note per spiegare la fallibilità dell'hardware reale?
• Al momento, i test sono lo strumento più importante che abbiamo per stabilire che il software funziona. Sembra che dovrebbe essere uno strumento complementare con metodi formali. Tuttavia, vedo principalmente ricerche incentrate su metodi formali o test. Cosa si sa sulla combinazione dei due?

Riguardo a 4: c'è molto lavoro che combina metodi formali e test. Googling "testing dei metodi formali" rivela una notevole quantità di lavoro. Sebbene ci siano molti obiettivi diversi di tale lavoro, uno degli obiettivi chiave è generare suite di test più efficaci. Questo discorso offre una buona introduzione, basata sul controllo del modello.

Anche per quanto riguarda il problema della sicurezza del software , che è stato modificato in modo inammissibile: i metodi formali devono lavorare di più per realizzare in quel regno. Tipicamente si scrive una specifica per un software e si verifica che la specifica sia soddisfatta, vale a dire che quando l'input soddisfa la condizione preliminare che l'output soddisfa la postcondizione. Per garantire un software sicuro, è necessario verificare anche che il software si comporti in modo ragionevole per l'input che non soddisfa i requisiti preliminari. (Ovviamente questo equivale a impostare la condizione preliminare su true per tutti gli input.) Lo spazio di tutti gli input è in genere molto più grande di un input ben formato, ma in genere questo è un punto in cui anche il software funzionalmente corretto può essere violato, semplicemente violando i suoi presupposti.

Per quanto riguarda il punto 3: è stato svolto un certo lavoro per verificare i sistemi nelle impostazioni in cui i guasti sono esplicitamente modellati, incluso logica difettosa: ragionamento sui programmi a tolleranza d'errore. Matthew Meola e David Walker. Simposio europeo sulla programmazione, 2010. I lavori sul controllo probabilistico dei modelli e sulla verifica probabilistica certamente affrontano entrambi in qualche modo anche il problema dei guasti.

I tuoi punti in ordine:

• La correttezza di tutte le specifiche è in definitiva soggettiva: sono percepite per risolvere correttamente un problema in base ai loro utenti o no. Non ci si può allontanare da questo è lo sviluppo del software, e nessun metodo ha il proiettile d'argento per questo.
• Molto lavoro è volto a dimostrare che il processo è corretto rispetto alle sue ipotesi. Di solito ci sono informazioni disponibili per gli esperti per convalidare queste regole. Qualsiasi attività umana è soggetta a errori ma i sistemi molto formalizzati che utilizzano approcci ben studiati sono molto meno soggetti a errori rispetto a quasi tutti gli altri processi umani.
• Ad un certo punto, qualsiasi sistema ha una modalità di errore al di fuori dell'ambito di quel sistema. Stai ancora meglio eliminando tutto il prevedibile fonti di errore , anche se ne lasci alcune imprevedibili.
• Test e prove possono facilmente coesistere. Il test è un processo meno specifico e più ad hoc , quindi potresti trovare un lavoro meno formale fatto su di esso. Ma potresti essere interessato a uno strumento come QuickCheck che integra con test le prove offerte dal sistema di tipi Haskell.

I metodi formali hanno già dimostrato di funzionare alla grande. Senza di essi, non saremmo riusciti a far fronte alla complessità della progettazione di moderni sistemi digitali (microprocessori).

Nessuna micro-nave senza la sua logica soggetta alla verifica funzionale di equivalenza; senza che la sua FPU fosse stata soggetta a FV; senza che i protocolli di coerenza della cache fossero soggetti a FV (questo è il caso dal 1995).

Escludendo evidenti differenze tra software e sistemi fisici ingegnerizzati (ad esempio ponti, dove si possono aggiungere fattori di sicurezza), svolgono il ruolo di ingegneria matematica in CS. Tuttavia, l'uso di FM dipende sempre dal rapporto costi / benefici. Il test Fuzz ripaga alla grande in aziende come Microsoft (Google SAGE in una diapositiva).

Anche all'interno di un micro, ci sono sottosistemi (ad esempio pipeline di microprocessori), in cui FV non ha avuto lo stesso impatto di altrove (ad esempio FPU, in cui i test convenzionali non sono stati eseguiti affatto in molti casi in cui la valutazione formale della traiettoria simbolica ha dimostrato l'assenza di bug : Kaivola et al CAV'09).

Metodi formali vengono anche utilizzati nella sintesi di artefatti (codice, test di alta qualità, programmi per scaricare in modo ottimale i banchi di batterie, ...). Naturalmente, tutti i problemi sollevati nella domanda sono abbastanza validi e, come in qualsiasi altro uso della tecnologia, le pubblicità false devono essere riconosciute ed evitate.

Riguardo a 2: se il sistema è formalizzato in un assistente di prova (ad esempio, Twelf o Agda o Coq) e le proprietà di solidità e completezza sono verificate e le prove sono fatte in questa codifica, questo non è un problema. Potresti aver formalizzato un sistema che non sta descrivendo ciò che intendevi, ma almeno non avrai prove errate o un sistema rotto in cui stai ragionando.

Tuttavia, sembra che anche se è possibile fornire una prova di correttezza, NON si può essere in grado di garantire che il sistema non fallirà.

Sì, forse non ci sono garanzie . I metodi formali hanno lo scopo di trovare ed eliminare gli errori e convincere gli umani.

Quali tecniche sono note per verificare se una specifica ha un senso del tutto?

Potresti essere interessato agli strumenti di controllo del modello per le specifiche dei sistemi formali .

Anche il processo di prova può essere imperfetto! Chi sa che quelle regole di inferenza sono corrette e legittime?

Penso che (a causa del teorema di incompletezza di Goedel) mostrare che un sistema di regole di inferenza è coerente fa necessariamente appello a un insieme ancora più potente di regole di inferenza.

Inoltre, le prove possono essere molto grandi e come facciamo a sapere che non contengono errori?

Si spera che enormi prove siano controllate da un piccolo correttore di prove che può essere letto e compreso dagli umani in un ragionevole lasso di tempo. Questo è talvolta chiamato il "criterio di Bruijn". Se ritieni che il correttore di prove non certifichi una prova errata, devi solo controllare il controllore.

Esistono tecniche note per spiegare la fallibilità dell'hardware reale?

Che ne dite di linguaggio assembly digitato tollerante ai guasti ?

Tuttavia, vedo principalmente ricerche incentrate su metodi formali o test. Cosa si sa sulla combinazione dei due?

"La conferenza TAP è dedicata alla convergenza di prove e prove" .

Cercare su Google "prove e prove" ha parecchi buoni risultati above the fold.

Quali tecniche sono note per verificare se una specifica ha un senso del tutto?

È sicuramente una chiamata di giudizio. Nell'ingegneria del software, le persone hanno progettato una metodologia molto rigorosa per trovare / scrivere / confermare le specifiche. Questo viene fatto da veri umani e usando un processo non formale (nel senso non matematico), quindi è ancora soggetto a incongruenze, ma alla fine, corrisponde a ciò che le persone vogliono verificare, né più né meno.

Esistono tecniche note per spiegare la fallibilità dell'hardware reale?

Certo, esiste un campo di verifica noto come verifica del runtime , è inoltre possibile utilizzare il controllo del modello basato sull'esecuzione sul sistema reale in esecuzione in un ambiente totalmente virtuale soggetto a uno scenario specifico (ho contribuito a questo con V-DS + APMC ). Tuttavia, questo è chiaramente un grave problema per aggiungere l'interazione tra il sistema e l'ambiente nel processo di verifica.

Tuttavia, vedo principalmente ricerche incentrate su metodi formali o test. Cosa si sa sulla combinazione dei due?

Caspita, oggi sarò totalmente senza vergogna e mi citerò di nuovo. Con i coautori lavoriamo sulla combinazione di verifica e verifica dei modelli, puoi consultare l'elenco delle pubblicazioni di un ex dottorando del nostro gruppo o cercare "verifica approssimativa del modello probabilistico" o "verifica statistica dei modelli" in qualsiasi buon motore di ricerca (lavoro svolto da Younes et al., Sen et al. O me stesso et al. E molti altri).

Potresti essere molto interessato alle opere di John Rushby , uno dei progettisti del proveratore di teoremi PVS, che è genericamente interessato esattamente ai punti che menzioni. Potresti divertirti a leggere questo classico rapporto alla FAA sull'uso dei metodi formali e la certificazione dei sistemi critici (1993) e i suoi nuovi scritti sull'assemblaggio di un caso probabilistico e formale di sicurezza su vari mezzi di prova forniti (test, prove, analisi, ecc.).