Quali sono gli ostacoli che impediscono l'adozione diffusa di metodi formali? [chiuso]

È possibile utilizzare metodi formali per specificare, provare e generare codice per un'applicazione. Questo è meno soggetto a errori - quindi utilizzato principalmente nei programmi di sicurezza / critici.

Perché non lo usiamo più spesso per la programmazione di tutti i giorni, o nelle applicazioni web, ecc ...?

Riferimenti :

• Metodi formali
• Metodo B.
• Hoare Logic

Un ingegnere è una persona che può fare con un dollaro ciò che qualsiasi idiota può fare con 10.

Vincoli di risorse, vincoli di bilancio, vincoli di tempo, sono tutti importanti.

Lo sviluppo di software con metodi formali è generalmente molto più costoso e richiede molto più tempo che senza. Inoltre, per molti progetti, la parte più difficile è comprendere i requisiti aziendali. Tutto ciò che l'utilizzo di metodi formali ti acquista in quel caso è la prova che il tuo codice corrisponde al 100% alla tua comprensione incompleta e errata dei requisiti aziendali.

Per questo motivo, l'uso di metodi formali, prove, verifica del programma e tecniche simili è in genere limitato a "cose ​​che contano", ovvero software avionici, sistemi di controllo per apparecchiature mediche, centrali elettriche, ecc.

Programmare o non programmare?

Per risolvere un problema con un prodotto software, dopo aver compreso i requisiti, è POSSIBILE scrivere un programma utilizzando i linguaggi di programmazione o specificare il programma utilizzando un linguaggio formale e utilizzare gli strumenti di generazione del codice. Quest'ultimo aggiunge solo un livello di astrazione.

Fare le cose giuste o fare le cose giuste?

L'approccio formale fornisce una prova del funzionamento del software in base alle specifiche. Quindi il tuo prodotto fa le cose bene. Ma fa le cose giuste?

I requisiti su cui stai lavorando potrebbero essere incompleti o ambigui. Potrebbero anche essere buggy. Nel peggiore dei casi, i bisogni reali non sono nemmeno espressi. Ma un'immagine vale più di mille parole, solo immagini di Google per "Ciò che il cliente desidera", ad esempio da questo articolo :

Il costo della formalità

In un mondo perfetto, avresti requisiti dettagliati e perfetti fin dall'inizio. È quindi possibile specificare completamente il software. Se dovessi scegliere formale, il tuo codice verrebbe generato automaticamente in modo da essere più produttivo. L'aumento della produttività compenserebbe il costo degli strumenti formali. E ora tutti avrebbero usato metodi formali. Allora perché no?

In pratica, questa è raramente la realtà! Questo è il motivo per cui così tanti progetti a cascata fallirono e perché iterativi metodi di sviluppo (agile, RAD, ecc.) Presero il comando: possono gestire requisiti, progetti e implementazioni incompleti e imperfetti e perfezionarli fino a quando non vanno bene.

E qui arriva il punto. Con i metodi formali, ogni iterazione richiede una specifica formale completamente coerente. Ciò richiede un pensiero attento e un lavoro aggiuntivo, perché la logica formale non è perdonante e non ama i pensieri incompleti. Semplici esperimenti usa e getta diventano costosi sotto questo vincolo. E così fa ogni iterazione che porterebbe a backtracking (ad esempio un'idea che non ha funzionato o un requisito che è stato frainteso).

In pratica

Quando non sei obbligato a utilizzare metodi formali per motivi legali o contrattuali, puoi anche ottenere una qualità molto elevata senza sistemi formali, ad esempio utilizzando la programmazione basata su contratto e altre buone pratiche (ad esempio revisione del codice, TDD , ecc ...). Non sarai in grado di dimostrare che il tuo software funziona, ma i tuoi utenti apprezzeranno prima di tutto il funzionamento del software.

Aggiornamento: sforzo misurato

Nel numero di ottobre 2018 di Communications of the ACM c'è un articolo interessante sul software ufficialmente verificato nel mondo reale con alcune stime dello sforzo.

È interessante notare che (basato sullo sviluppo del sistema operativo per apparecchiature militari), sembra che produrre software provato formalmente richieda uno sforzo 3,3 volte maggiore rispetto alle tecniche di ingegneria tradizionali. Quindi è davvero costoso.

D'altra parte, per ottenere software ad alta sicurezza in questo modo è necessario un impegno 2,3 volte inferiore rispetto a un software progettato in modo tradizionale se si aggiunge lo sforzo per rendere tale software certificato ad alto livello di sicurezza (EAL 7). Quindi, se hai requisiti di alta affidabilità o sicurezza, c'è sicuramente un business case per andare formale.

la progettazione e lo sviluppo del codice seL4 sono durati due anni-persona. Sommare tutte le prove sierospecifiche nel corso degli anni arriva a un totale di 18 anni-persona per 8.700 righe di codice C. In confronto, L4Ka :: Pistachio, un altro microkernel della famiglia L4, di dimensioni paragonabili a seL4, ha richiesto sei anni-persona per svilupparsi e non fornisce un livello significativo di affidabilità. Ciò significa che esiste solo un fattore 3,3 in tra software verificato e software di ingegneria tradizionale. Secondo il metodo di stima di Colbert e Boehm, 8 una tradizionale certificazione EAL7 Common Criteria per 8.700 righe di codice C richiederebbe più di 45,9 anni-persona. Ciò significa che la verifica formale dell'implementazione a livello binario è già più di un fattore 2.3 meno costoso del più alto livello di certificazione dei criteri comuni, ma fornisce una garanzia significativamente più forte.

Ogni programma in qualsiasi lingua può essere pensato come una specifica formale (equivalente ad un tornio). Qualsiasi "specifica formale" di livello superiore da utilizzare per dimostrare la correttezza formale è anche solo un altro programma. Ma è (tipicamente) un programma cattivo, incompleto, vago, scarsamente pensato. E non a caso, in genere scritto da persone che non sanno programmare (di solito sono esperti di dominio).

E così dimostrando che un programma è compatibile (produce le stesse risposte o comunque tu lo caratterizzi) con i suoi requisiti formali di livello superiore, invariabile si riduce al modo in cui risolvi le ambiguità nella specifica formale di livello superiore. Non esiste un buon modo generale per farlo.

La mappatura dei requisiti di alto livello con dettagli di livello inferiore è l'essenza di ciò che riguarda la vera programmazione. Non dovrebbe sorprendere il fatto che il lavoro di base svolto da un programmatore che legge e interpreta le specifiche non può essere sostituito da agitando la mano e dicendo: "Ora basta vedere se questa specifica formalità di alto livello è rispettata da questo programma di esempio".

Anche ai primi tempi della programmazione logica, in cui questo concetto sembrava inizialmente così promettente (poiché sia ​​la specifica di alto livello che i programmi reali sottostanti potevano essere scritti nella stessa lingua), questo problema fondamentale si rivelò irrisolvibile.