Se hai imparato metodi formali per il software, quanto ti è stato utile?

Se sei stato addestrato all'uso di metodi formali (FM) per la programmazione:

• Quanto ti è stato utile?
• Cosa ha comportato la tua formazione FM (ad es. Un corso, un libro)?
• Quali strumenti FM usi?
• Quali sono i vantaggi in termini di velocità / qualità rispetto al non utilizzo della FM?
• Che tipo di software crei con FM?
• E se non usi direttamente FM adesso, vale la pena imparare almeno ??

Sono curioso di ascoltare quante esperienze / opinioni su FM si possono trovare in questa comunità; Sto iniziando a leggerlo e voglio saperne di più.

sfondo

La programmazione e lo sviluppo / ingegneria del software sono alcune delle più recenti abilità / professioni umane sulla Terra, quindi non sorprende che il campo sia immaturo, il che mostra nell'output principale del nostro campo, come codice tipicamente in ritardo e soggetto a errori. L'immaturità del settore è anche dimostrata dall'ampio margine (almeno 10: 1) nella produttività tra i programmatori medi e migliori. Tali fatti tristi sono ben trattati in letteratura e introdotti da libri come Code Complete di Steve McConnell .

L'uso di metodi formali (FM) è stato proposto da figure di spicco del software / CS (ad esempio il defunto E. Dijkstra ) per affrontare (una delle) cause alla radice degli errori: la mancanza di rigore matematico nella programmazione. Dijkstra, ad esempio, ha sostenuto gli studenti che sviluppano un programma e le sue prove insieme .

La FM sembra essere molto più diffusa nei curricula CS in Europa rispetto agli Stati Uniti. Ma negli ultimi anni, nuovi approcci FM "leggeri" e strumenti come la lega hanno attirato una certa attenzione. Tuttavia, FM è ben lungi dall'essere un uso comune nell'industria e spero in questo caso di ricevere un feedback sul perché.

Aggiornare

A partire da ora (14/10/2010), delle 6 risposte sottostanti, nessuno ha chiaramente discusso dell'uso della FM nel lavoro nel "mondo reale". Sono davvero curioso se qualcuno può e vuole; o forse FM illustra davvero la divisione tra mondo accademico (FM è il futuro!) e industria (FM è per lo più inutile).

Assolutamente inutile per qualsiasi cosa non banale.

Avevo un corso chiamato, giustamente, "Metodi formali" che si concentrava su Alloy: non posso assolutamente vederlo da nessuna parte. Aveva un'altra classe incentrata sulla modellazione di concorrenza con LTSA, altrettanto inutile.

Il problema è che la maggior parte dei bug e dei problemi nel software (almeno nella mia esperienza) derivano dalla complessità che si verifica al di sotto del livello di astrazione di tali strumenti.

Ho un background in CSP (Comunicazione di processi sequenziali). Non per suonare il mio corno, ma ho scritto la tesi del mio Master su CSP a tempo, in particolare "compilando" le specifiche scritte in metodi formali in C ++ eseguibile. Posso dire di avere una certa esperienza con i metodi formali. Una volta che ho completato la mia laurea e ho ottenuto un lavoro nel settore, non ho usato metodi formali. I metodi formali sono ancora troppo teorici per essere applicati nel settore. I metodi formali hanno trovato alcune applicazioni pratiche nell'area dei sistemi integrati. Ad esempio, la NASA utilizza metodi formali nei loro progetti. Vorrei ipotizzare che i metodi formali sono ben lungi dall'essere ampiamente adottati nel settore. Semplicemente non ha senso scrivere le specifiche del software in metodi formali e poi "interpretarle dall'uomo" nel proprio quadro di scelta. L'inglese semplice e i diagrammi funzionano meglio per questo, mentre i test unitari e di integrazione hanno svolto un ottimo lavoro di "verifica" della correttezza del codice. pensoi metodi formali rimarranno nel mondo accademico per qualche tempo .

Diagrammi di stato e reti di Petri sono utili per modellare e analizzare protocolli e sistemi in tempo reale. Per prima cosa aiutano a progettare una soluzione. In secondo luogo aiutano a trovare casi di test per software entusiasmanti in situazioni molto specifiche.

Ho letto alcuni libri sui metodi formali e ne ho applicati alcuni. La mia reazione immediata fu: "Accidenti, questi libri mi dicono come essere un buon programmatore, purché io sia un matematico perfetto". Un altro punto debole è che puoi provare l'equivalenza solo con un'altra descrizione formale. Scrivere una specifica formale per un programma equivale a scrivere un programma in un linguaggio di livello superiore, e non c'è modo di evitare di introdurre bug in una specifica abbastanza grande.

Non ho mai fatto funzionare i metodi formali su larga scala. Possono essere utili per ottenere qualcosa di piccolo e complicato, e per convincermi che sono corretti. In questo modo, posso lavorare con blocchi leggermente più grandi e a volte fare un po 'di più.

Una cosa che ho raccolto che è più generalmente utile è il concetto di un invariante, un'affermazione su un programma e il suo stato che è sempre vero. Qualunque cosa tu possa ragionare è buona.

Come accennato in precedenza, non sono un matematico perfetto, quindi le mie prove a volte contengono errori. Tuttavia, nella mia esperienza questi tendono ad essere grandi errori stupidi che sono facili da catturare e correggere.

Ho seguito un corso di laurea in analisi formale dei programmi, dove ci siamo concentrati sulla semantica operativa. Ho fatto il mio ultimo lavoro sullo sforzo seL4, rivedendo i metodi formali che hanno usato. Il mio take-away principale in termini di praticità era che aveva un valore marginale. Non solo devi scrivere il programma, devi anche scrivere la prova. Wow. Due fonti di bug. Non solo uno. Inoltre, c'era un'enorme quantità di restrizioni poste sul codice reale. È molto difficile descrivere formalmente un computer fisico, incluso l' I / O.

L'autodidatta TLA + dell'anno scorso lo uso da allora. È uno dei primi strumenti a cui cerco ogni volta che inizio un progetto. L'errore che la maggior parte delle persone fa è presumere che i metodi formali siano una cosa del tutto o niente: o non stai usando metodi formali o hai una verifica completa. Tuttavia, c'è qualcosa tra loro: specifiche formali , in cui controlli che una specifica astratta del tuo progetto non rompa i tuoi invarianti. A differenza della verifica, le specifiche sono abbastanza pratiche da utilizzare nell'industria.

I linguaggi di specifica sono più espressivi dei linguaggi di programmazione. Ad esempio, ecco una (molto) semplice specifica PlusCal per un archivio dati distribuito:

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;

Questo frammento specifica cinque nodi in esecuzione contemporaneamente, eseguendo trasferimenti in un ordine arbitrario, in cui ogni trasferimento è un pezzo arbitrario di dati a un nodo arbitrario. Inoltre, abbiamo specificato che qualsiasi dato trasferimento potrebbe non riuscire e causare l'arresto anomalo del nodo. E possiamo simulare tutti questi comportamenti nel controllo modello TLA +! In questo modo possiamo verificarlo indipendentemente dall'ordine, dai tassi di fallimento, ecc., I nostri requisiti sono ancora validi. A proposito, aggiungiamo un paio di requisiti. Innanzitutto, non trasferiamo mai i dati su un nodo offline:

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

Nella nostra versione semplificata, il modello di controllo troverà uno stato di errore. Possiamo anche specificare "ogni dato dato si trova in almeno un nodo online":

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

Che fallirà anche. Buona fortuna controllandoli con un test unitario!

Il principale limite delle specifiche è che esiste indipendentemente dal tuo codice attuale. Può solo dirti che il tuo design è corretto, non che lo hai implementato nel modo giusto. Ma è più veloce da specificare che da verificare e rileva bug troppo sottili per il test, quindi trovo che valga la pena. Praticamente qualsiasi codice che coinvolga la concorrenza o più sistemi è un buon posto per una specifica formale.

Lavoravo in un dipartimento dell'ICL, prima che fossero acquistati da Fujitsu. Avevano alcuni grandi contratti di tipo governativo che richiedevano la prova che il software funzionava come pubblicizzato, quindi hanno costruito una macchina che avrebbe preso le specifiche formali scritte in Z e convalidato il codice mentre correva, con una grande luce verde o rossa per il passaggio / fallire.

È stata una cosa straordinaria, ma, come sottolinea lo stimato @FishToaster , è stato inutile per qualsiasi cosa non banale.

1. " Quanto ti è stato utile? "

L'applicazione di reti di Petri alla programmazione per computer è molto utile. Ho creato "Net Elements and Annotations", un metodo basato su reti di Petri (Chionglo, 2014). Ho applicato il metodo dal 2014 per scrivere programmi JavaScript che utilizzano l'API Acrobat / JavaScript per le applicazioni di moduli PDF.

2. " Che cosa ha comportato la tua formazione FM (ad esempio un corso, un libro)?”

Mi sono "allenato" sulle reti di Petri attraverso l'autoapprendimento. Ho letto i capitoli sulle reti di Petri dal libro di testo "Petri Nets and Grafcet: Tools for Modeling Discrete Event Systems" (David and Alla, 1992). Ho anche letto articoli di ricerca sulle reti di Petri. Dopo aver creato e documentato "Elementi e annotazioni netti", ho praticato l'applicazione del metodo per diverse settimane.

3. “ Quali strumenti FM usi?”

Traccio diagrammi di Petri Net usando PowerPoint. Creo la vista modulo delle annotazioni usando Word. Creo giochi di token come applicazioni per moduli PDF usando anche Acrobat e Blocco note. Dopo aver aggiunto le voci nel modulo, la traduzione di queste voci nel codice JavaScript è sistematica. Pertanto, dovrebbe essere possibile automatizzare la traduzione. Se le "voci" sono state aggiunte agli oggetti grafici in PowerPoint, dovrebbe anche essere possibile tradurle sistematicamente in codice JavaScript e automatizzare anche questa traduzione. Uso anche una serie di strumenti di work-in-progress che eseguono queste traduzioni e per creare risorse aggiuntive per la creazione di applicazioni per moduli PDF (Chionglo, 2018; 2017).

4. “ Quali vantaggi ti ha dato in termini di velocità / qualità rispetto al non utilizzo di FM? ”

Posso scrivere programmi JavaScript usando "Net Elements and Annotations" più velocemente di quanto possa scrivere un programma JavaScript senza usare "Net Elements and Annotations". E per i programmi di grandi dimensioni posso smettere di programmare e tornare alla codifica in seguito (o molto più tardi) senza chiedermi dove continuare (Chionglo, 2019). In alcuni casi posso scrivere programmi JavaScript usando "Net Elements and Annotations" ma non posso scrivere i programmi JavaScript senza usare "Net Elements and Annotations". Ad esempio, non avrei potuto creare implementazioni non ricorsive di funzioni ricorsive senza l'uso di "Net Elements and Annotations" (Chionglo, 2019b; 2018b; 2016). Questi sono veri con o senza gli strumenti di work-in-progress.

5. " Che tipo di software crei con FM? "

Uso "Net Elements and Annotations" per creare programmi JavaScript che utilizzano l'API Acrobat / JavaScript per le applicazioni di moduli PDF. Posso anche applicare il metodo per creare programmi JavaScript per documenti HTML e creare Arduino Sketches (Chionglo, 2019c; 2019d).

6. " E se non usi direttamente FM adesso, vale la pena imparare almeno? " Non applicabile.

Riferimenti

Chionglo, JF (2019b). Calcolo dell'ennesimo termine di una relazione ricorsiva: utilizzo di una funzione non ricorsiva: una risposta a una domanda allo scambio di stack matematici. < 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). Logica, simulazione e schizzo del controllo dell'effetto fiamma: una risposta a una richiesta nel forum della community di 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). Come continuo a codificare un'applicazione dopo una lunga pausa? Rispondi a "Come fai a sapere dove ti sei fermato nei codici dopo una pausa di 2 settimane?" - Software Engineering Stack Exchange. 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). Logica di controllo Show-and-Hide: ispirata a una domanda in overflow dello stack. < https://www.academia.edu/40283015/Show-and-Hide_Control_Logic_Inspired_by_a_Question_at_Stack_Overflow >.

Chionglo, JF (2018b). Un modello di Petri Net per il fattoriale di un numero: e una funzione JavaScript non ricorsiva per calcolarlo. <>.

Chionglo, JF (2018). Crea Hyper Form ™ - Un flusso di lavoro in corso: aggiornamento sulla ricerca sulla programmazione in rete. https://www.academia.edu/37697498/Create_Hyper_Form_-A_Workflow_in_Progress_Update_on_the_Net_Programming_Research .

Chionglo, JF (2017). Programmazione netta: una proposta di ricerca: per lo sviluppo di applicazioni per moduli PDF con PowerPoint e Acrobat. https://www.academia.edu/33374809/Net_Programming_A_Research_Proposal_For_Developing_PDF_Form_Applications_with_PowerPoint_and_Acrobat. .

Chionglo, JF (2016). Un modello di Petri Net per il calcolo del numero di Fibonacci. https://www.academia.edu/31748108/A_Petri_Net_Model_for_Computing_the_Fibonacci_Number.

Chionglo, JF (2014). Elementi e annotazioni netti per la programmazione di computer: calcoli e interazioni in PDF. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

David, R. e H. Alla. (1992). Reti di Petri e Grafcet: strumenti per la modellazione di sistemi di eventi discreti. Upper Saddle, NJ: Prentice Hall.