Visualizza il feed RSS

Titolo provvisorio...

I Dieci Comandamenti...

Valutazione: 4 voti, con una media del 5.00.
di pubblicato il 26-02-2009 alle 21:13 (3888 Visite)
No, non si tratta di una informazione sul prossimo passaggio in palinsesto (in effetti la Pasqua è vicina...) dell'arciclassico kolossal di Cecil B. De Mille coi soliti Charlton Heston e Yul Brynner, peraltro un capolavoro irripetibile che fa impallidire le sgangherate produzioni odierne.

Si vuol parlare invece di metodi formali, e in particolare di un famoso decalogo elaborato alcuni lustri or sono da due validi studiosi: Jonathan Bowen della London University e Michael Hinchley della NASA.

Spero che sia ormai chiaro a tutti i miei lettori, anche a quelli più giovani, dove e quando è di fatto obbligatorio progettare il software utilizzando linguaggi formali come Z, OCL, Larch, LOTOS, eccetera: cioè, in soldoni, nei sistemi altamente critici, regolati da severe norme internazionali, dove esistono enormi rischi monetari (o perfino peggio) in caso di errore o disastro colposo. Centrali energetiche, controllori del traffico aereo, ferroviario, navale o satellitare, sistemi d'arma, avionica, aerospaziale... in sostanza, le classiche applicazioni ad elevatissima criticità.

Meno chiaro invece, anche a professionisti più scafati, è il quadro complessivo nei casi meno estremi. Quando conviene davvero utilizzare questi metodi, così dispendiosi e di difficile utilizzo ? Sono davvero così potenti e taumaturgici ? Cosa ci si può aspettare in situazioni "di confine", più ordinarie, mainstream e comunque non esasperate quanto a rischi e costi ?



I due noti specialisti forniscono allora una serie importante di spunti per la riflessione, sotto forma di decalogo.
  1. Scegli la notazione opportuna.
    Esistono dozzine di metodi e linguaggi, ciascuno con caratteristiche peculiari. Solo una conoscenza panoramica delle opportunità esistenti può guidare la scelta razionale.
  2. Sii formale... ma non troppo.
    Sono rarissimi i casi nei quali ogni singolo aspetto del sistema deve essere formalizzato. Normalmente si può (e si deve) operare una selezione sulla base di parametrizzazioni economico-ingegneristiche.
  3. Ricordati di stimare i costi.
    Raccomandazione meno banale di quanto possa apparire. I costi di applicazione dei metodi formali sono molto elevati, e soprattutto sono tendenzialmente raggruppati all'inizio delle attività (elevato costo di startup). Nei casi non criticissimi, il loro impiego deve essere giustificato (anche) finanziariamente.
  4. Abbi sempre a disposizione un esperto in metodi formali.
    Il passaggio di competenze in quest'area ha una curva di apprendimento alquanto ripida, e il rischio di errori nell'uso dei metodi (che ne vanificherebbero lo scopo !) è elevato per i primi mesi. La supervisione e l'affiancamento sono strettamente necessari.
  5. Non abbandonare del tutto i metodi tradizionali.
    Stiamo pur sempre parlando di progetti mainstream, e comunque di criticità non esasperata. Dunque è lecito attendersi che combinazioni di metodi, come ad esempio è per sua stessa natura OCL (UML + Z), siano in realtà la soluzione più adatta a gestire la qualità e l'intero processo di sviluppo.
  6. Non trascurare la documentazione.
    Raccomandazione quasi superflua, in quanto alcuni metodi formali sono per natura autodocumentanti, a partire proprio da Z. Tuttavia, è essenziale ribadire l'importanza della documentazione human-readable e soprattutto, per così dire, customer-readable. Una delle principali difficoltà per l'uso dei metodi formali nel mainstream è proprio l'incomprensibilità delle notazioni formali non solo per il cliente medio, ma perfino per una larga maggioranza di progettisti e tecnici in genere.
  7. Non mettere a rischio la qualità.
    "Non c'è alcunché di magico nei metodi formali". Sintassi e semantica ben definite, assiomi elegantemente scelti e una notazione sintetica non sono sufficienti, da sole, a garantire l'ottimalità del risultato. Occorrono rigore e costanza nell'applicare i criteri generali della quality assurance, come con altri metodi.
  8. Rinuncia al dogmatismo.
    Taluni sostengono che nel real world non sia possibile produrre software del tutto privo di errori (anche sotto forma di omissioni, compromessi, inferenze arbitrarie, errori di terziaria importanza, effetti indesiderati non gravi). Di sicuro, non c'è metodo totalmente automatico che garantisca il passaggio da una specifica al relativo software funzionante: occorre coinvolgere (almeno) un cervello umano in questo passaggio.
  9. Prova, riprova, e riprova ancora.
    Qui chiaramente gli autori non intendono in alcun modo fare improponibili apologie del trial and error, o replicare gli eccessi classici di Yourdon & Coad in fatto di prototipi. Più semplicemente (rasoio di Occam...), ci ricordano che i linguaggi formali sono appunto linguaggi "di specifica e testing". La stessa specifica formale spesso può essere "data in pasto" ad un generatore di test per moduli !
  10. Riutilizza.
    C'è, tra le tante, una obiezione che faccio costantemente presente ai cantori dell'opensource, e specialmente a chi esagerando parla addirittura di "diffusione della conoscenza" tramite meri sorgenti. Una medesima specifica formale logico-matematica per un dato algoritmo era comprensibile, autodocumentante e utilizzabile ai tempi del MarkII e del COBOL; lo è allo stesso modo oggi con i 4GL o con il dotnet, e lo sarà tra vent'anni con i calcolatori quantistici o con quel che verrà. Lo stesso algoritmo cristallizzato in un pezzo di codice in un linguaggio alla moda non ha e mai potrà avere le stesse caratteristiche, oltre ad essere intrinsecamente limitato ad esprimere solo funzioni computabili e idiomi compilabili.
    Non è un dettaglio trascurabile.

aggiornamento da 03-01-2013 a 22:19 di M.A.W. 1968

Categorie
Programmazione , Tecnologia

Commenti

  1. L'avatar di SignIn
    Che dire, post perfetto (titolo superbo). La nota dolente rimane l'osservanza del decalogo da parte del Developer, Project Leader ecc.