24-02-2012, 18:08
Nei precedenti articoli abbiamo utilizzato il termine affidabilità in modo intuitivo ed informale, come faremo nel prosieguo della trattazione: questo implica che intendiamo definire affidabile un software la cui funzionalità corrisponde ai requisiti proposti. I risultati prefissati, le elaborazioni compiute ed eventuali azioni eseguite producono quanto ci si attende oppure differiscono da quanto richiesto. Ad esempio un software preposto ad un microprocessore che sovrintende i servizi a bordo di un’auto è da considerarsi inaffidabile se genera spontaneamente i comandi di apertura delle portiere quando il veicolo è in movimento. Può invece considerarsi affidabile quando, essendo ferma l’auto, il livello di carburante indicato risulta inferiore a quello effettivo.
Si badi con attenzione che il concetto espresso in merito all’affidabilità è da valutare come soggettivo in larga misura, poiché esprime la valutazione soggettiva di quale possa essere uno scostamento intollerabile rispetto a quanto si è previsto. La definizione formulata ha comunque il pregio di non porre sullo stesso piano ogni tipo di malfunzionamento, ma di definirne e graduarne l’importanza.
A differenza dell’affidabilità, un concetto definibile in modo estremamente preciso è indubbiamente quello della correttezza: data infatti una definizione dei requisiti che il software deve soddisfare, questi sarà definito corretto nel momento in cui i requisiti medesimi vengono totalmente soddisfatti. Ciò significa che, ogni malfunzionamento, indipendentemente dalla sua gravità, costituisce ragione affinché il software in esame venga definito scorretto!
Un modo fattibile per definire la specifica dei requisiti di un modulo software che definiremo P, consiste nel fissare due predicati I ed O, rispettivamente definiti predicati di ingresso ed uscita. In pratica P dovrà ricevere in ingresso dei dati che soddisfino il predicato I e, al termine dell’esecuzione, si ponga in uno stato che abbia a soddisfare O. In seguito avremo modo di osservare come, tramite il ricorso a dei principi matematici, è possibile tentare di dimostrare che per ogni ingresso che soddisfa I, al termine dell’esecuzione di P vale O. Si veda l’esempio a seguire in cui P calcola l’indice m al quale è memorizzato il minimo valore contenuto in un vettore V di n interi tra essi distinti. La sua specifica è data dai due predicati:
I i, j, i j, j n, V[i] V[i]
O i, i m, l i, m n, V[m] < V[i]
Si osservi quindi in pratica che non necessariamente un software corretto si comporta in modo da essere intuitivamente ritenuto affidabile, questo poiché l’attributo di correttezza viene definito in riferimento a quanto specificato come requisito, ma purtroppo non sempre i requisiti specificano, a loro volta, con esattezza, tutto ciò che viene ritenuto importante. Addirittura accade che i requisiti specificati risultino essi stessi quasi sempre incompleti rispetto a quelli reali, o perché ci si dimentica di specificare determinati requisiti o perché se ne omettono degli altri poiché ritenuti ovvii. Il software che ha la capacità a comportarsi in modo accettabile in corrispondenza di situazioni non specificate nei requisiti viene definito robusto.
Vengono sovente utilizzati altri termini per indicare categorie particolari di software robusto, come ad esempio sicurezza in concomitanza di sistemi con accesso ad informazioni private e protette, per denotare sistemi che vigilano sull’accesso a tali informazioni impedendo intrusioni involontarie o di natura dolosa. Si utilizza invece il termine innocuità (safety) in contemporaneità a sistemi che risultano critici e pericolosi anche per la vita dell’uomo, per denotare il fatto che questi sistemi non entrano mai in uno stato in cui il livello di pericolo in merito ai possibili malfunzionamenti può essere intollerabile. Peculiarità comune delle proprietà legate da innocuità e sicurezza è quella di essere formulabili come proprietà negative: in entrambi questi casi è infatti indispensabile garantire che il sistema non entri mai in certi stati. Ad esempio un requisito inerente la sicurezza potrebbe essere dato dal fatto che, in determinati archivi, non possano accedere in scrittura solamente certe categorie di utenti ed in lettura delle altre. Un requisito di innocuità può stabilire che il controllore dell’assetto di volo di un aereo assicuri che l’altezza del volo sia sempre maggiore o uguale a zero, oppure che un robot non abbia ad entrare in rotta di collisione con gli operatori umani.
Nel seguito dei nostri articoli utilizzeremo in prevalenza il termine affidabilità per denotare collettivamente le peculiarità inerenti la qualità di abbiamo sopra discusso, tenendo comunque conto del fatto che il termine in oggetto è utilizzato da alcuni nei termini di un rigoroso approccio matematicamente definito che da luogo ad una proprietà assolutamente misurabile
Si badi con attenzione che il concetto espresso in merito all’affidabilità è da valutare come soggettivo in larga misura, poiché esprime la valutazione soggettiva di quale possa essere uno scostamento intollerabile rispetto a quanto si è previsto. La definizione formulata ha comunque il pregio di non porre sullo stesso piano ogni tipo di malfunzionamento, ma di definirne e graduarne l’importanza.
A differenza dell’affidabilità, un concetto definibile in modo estremamente preciso è indubbiamente quello della correttezza: data infatti una definizione dei requisiti che il software deve soddisfare, questi sarà definito corretto nel momento in cui i requisiti medesimi vengono totalmente soddisfatti. Ciò significa che, ogni malfunzionamento, indipendentemente dalla sua gravità, costituisce ragione affinché il software in esame venga definito scorretto!
Un modo fattibile per definire la specifica dei requisiti di un modulo software che definiremo P, consiste nel fissare due predicati I ed O, rispettivamente definiti predicati di ingresso ed uscita. In pratica P dovrà ricevere in ingresso dei dati che soddisfino il predicato I e, al termine dell’esecuzione, si ponga in uno stato che abbia a soddisfare O. In seguito avremo modo di osservare come, tramite il ricorso a dei principi matematici, è possibile tentare di dimostrare che per ogni ingresso che soddisfa I, al termine dell’esecuzione di P vale O. Si veda l’esempio a seguire in cui P calcola l’indice m al quale è memorizzato il minimo valore contenuto in un vettore V di n interi tra essi distinti. La sua specifica è data dai due predicati:
I i, j, i j, j n, V[i] V[i]
O i, i m, l i, m n, V[m] < V[i]
Si osservi quindi in pratica che non necessariamente un software corretto si comporta in modo da essere intuitivamente ritenuto affidabile, questo poiché l’attributo di correttezza viene definito in riferimento a quanto specificato come requisito, ma purtroppo non sempre i requisiti specificano, a loro volta, con esattezza, tutto ciò che viene ritenuto importante. Addirittura accade che i requisiti specificati risultino essi stessi quasi sempre incompleti rispetto a quelli reali, o perché ci si dimentica di specificare determinati requisiti o perché se ne omettono degli altri poiché ritenuti ovvii. Il software che ha la capacità a comportarsi in modo accettabile in corrispondenza di situazioni non specificate nei requisiti viene definito robusto.
Vengono sovente utilizzati altri termini per indicare categorie particolari di software robusto, come ad esempio sicurezza in concomitanza di sistemi con accesso ad informazioni private e protette, per denotare sistemi che vigilano sull’accesso a tali informazioni impedendo intrusioni involontarie o di natura dolosa. Si utilizza invece il termine innocuità (safety) in contemporaneità a sistemi che risultano critici e pericolosi anche per la vita dell’uomo, per denotare il fatto che questi sistemi non entrano mai in uno stato in cui il livello di pericolo in merito ai possibili malfunzionamenti può essere intollerabile. Peculiarità comune delle proprietà legate da innocuità e sicurezza è quella di essere formulabili come proprietà negative: in entrambi questi casi è infatti indispensabile garantire che il sistema non entri mai in certi stati. Ad esempio un requisito inerente la sicurezza potrebbe essere dato dal fatto che, in determinati archivi, non possano accedere in scrittura solamente certe categorie di utenti ed in lettura delle altre. Un requisito di innocuità può stabilire che il controllore dell’assetto di volo di un aereo assicuri che l’altezza del volo sia sempre maggiore o uguale a zero, oppure che un robot non abbia ad entrare in rotta di collisione con gli operatori umani.
Nel seguito dei nostri articoli utilizzeremo in prevalenza il termine affidabilità per denotare collettivamente le peculiarità inerenti la qualità di abbiamo sopra discusso, tenendo comunque conto del fatto che il termine in oggetto è utilizzato da alcuni nei termini di un rigoroso approccio matematicamente definito che da luogo ad una proprietà assolutamente misurabile