Affidabilità di Sistemi Software Complessi

appuntiDiIngegneria

Affidabilità di Sistemi

Software Complessi

Sommario

1.0. Affidabilità di Sistemi Software Complessi .........................................................................................2

1.1. Albero della Dependability ................................................................................................................2

1.1.1. Attributi di Fidatezza ....................................................................................................................3

1.1.2. Threats ..........................................................................................................................................6

1.1.3. Mezzi per garantire la Reliability ....................................................................................................9

1.2. Modellazione di sistemi complessi .................................................................................................. 13

1.2.1. SysML .......................................................................................................................................... 13

1.2.1.1. SysML Requirement Diagram ................................................................................................... 14

1.2.1.2. SysML Block Definition Diagram............................................................................................... 15

1.2.1.3. SysML Internal Block Diagram .................................................................................................. 16

1.2.2. Reti di Petri ................................................................................................................................. 17

1.3. Testing ............................................................................................................................................ 19

1.4. Fault Injection ................................................................................................................................. 25

1.5. Tecniche di Misurazione del Grado di Affidabilità ............................................................................ 27

1

1.0. Affidabilità di Sistemi Software Complessi

In questo capitolo si fa riferimento a Sistemi Complessi (cioè costituiti da HW+SW), eterogenei e

distribuiti; essi sono classificati in 3 tipologie:

o Sistemi di lunga durata: applicazioni che devono girare per anni e devono avere poca

probabilità di fallimento (dello 0.95, più si è vicini a 1 e più è improbabile il fallimento).

Esempi sono i satelliti che devono vagare per anni nello spazio.

o Sistemi critici: devono avere probabilità di fallimento prossimo a 1, cioè non devono fallire

mai, ad esempio un SW di gestione di un veicolo senza pilota. Tuttavia questa altissima

affidabilità deve essere garantita per tempi non lunghi. Esempi sono treni ed aerei.

o Sistemi altamente disponibili: l’affidabilità può essere anche bassissima, prossima allo 0

ma quando serve, il servizio deve funzionare, cioè quando lo si interroga esso deve

rispondere. Esempi sono i sistemi transazionali bancari o i sistemi web e-commerce.

1.1. Albero della Dependability

Per questo tipo di Sistemi l’interesse sta nel valutarne l’Affidabilità. Innanzitutto si parte con il

definire di 3 concetti:

o Servizio: è il comportamento di un sistema così com’è percepito dall’utente finale.

o Funzionalità: è ciò che ci si aspetta che il sistema faccia, cioè è tutto ciò che viene

dichiarato nella specifica dei requisiti.

o Interfaccia: è il confine del sistema, che espone i servizi agli utenti finali.

Un sistema è Corretto se rispetta la specifica dei requisiti, cioè se implementa correttamente tutte

le funzionalità previste da essa. Tuttavia anche se un Sistema è corretto non è detto che i servizi

che esso offre all’utente siano anche affidabili, in quanto l’Affidabilità è un requisito non

funzionale. Si definisce allora un concetto di Affidabilità che si rifà al servizio piuttosto che alla

funzionalità, che è la Fidatezza di un Sistema.

La Dependability (Fidatezza) è la capacità di un sistema di fornire un servizio su cui è possibile fare

affidamento in modo giustificato, cioè per cui è possibile tirare fuori una misura di affidabilità che

vada a giustificare il servizio offerto dal sistema. Ad esempio siccome è impossibile che un sistema

SW non fallisca, dire che esso è “fidato” non vuol dire che non fallisca, ma che non ci sono

fallimenti severi e frequenti. La severità di un fallimento è misurata in funzione al danno che esso

può portare: un fallimento è tanto più severo quanto i costi dovuti a riparare le conseguenze

causate sono maggiori dei costi che è necessario affrontare per impedirne le cause che lo hanno

originato. Oltre alla severità è importante valutare anche la frequenza di un fallimento, perché se il

fallimento è frequente può comunque portare disagi. La Dependability si misura in termini di 9

(Nine) dopo lo 0, ed esistono tante metriche per misurare il grado di Dependability del sistema: 2

La Dependability viene descritta da un Albero della Dependability:

Come è possibile vedere da questo albero, la Dependability può essere considerata come un

“Attributo composto”, cioè un attributo caratterizzato da una serie di sotto-attributi, fra cui

l’Affidabilità (Reliability). Inoltre la Dependability è caratterizzata anche da una serie di Minacce

(Threats) che sono le cause di eventuali malfunzionamenti del sistema (e quindi di perdita di

fidatezza), infine è caratterizzata anche da una serie di Mezzi per migliorare il grado di affidabilità.

1.1.1. Attributi di Fidatezza

La Dependability è composta da tutta una serie di sotto-attributi, molti dei quali sono correlati tra

di loro, e questi ultimi sono spesso considerati come delle metriche per misurare la Dependability

di un sistema. 3

Il primo sotto-attributo che si va a studiare è la Reliability (Affidabilità), definita come la misura

della durata dell’intervallo di tempo per cui il sistema fornisce, in maniera continuativa, un servizio

corretto. In altre parole essa definisce la probabilità che il sistema fallisca in un arco di tempo,

cioè R(t)=Pr{!Failure in (0, T)}. Ad esempio come richiesta, un committente potrebbe chiedere di

essere garantito che un aereo voli per la durata di 2 ore con un grado di affidabilità di 4 nine, cioè

0.999; vorrebbe dire che su 9999 voli il sistema non dovrebbe fallire neppure una volta, cosa che

richiederebbe una simulazione di almeno 10000 voli prima di consegnare il progetto finito. Per

descrivere la frequenza di un fallimento in un prodotto HW, si usa una curva di affidabilità

standardizzata detta la Bathtube curve:

Tale curva viene generata mappando:

 il tasso di guasti iniziali della "mortalità infantile”: un tasso di fallimento decrescente che

denota fallimenti precoci individuati quando il prodotto viene introdotto per la prima volta,

che sono per lo più errori di montaggio o progettazione per colpa dei quali si rischia di dover

buttare l’intero sistema già all’inizio.

 il tasso di guasti casuali: è un tasso di fallimento costante che denota i guasti casuali

individuati durante la "vita utile - normale"; (è la zona più ampia rispetto a tutte le altre).

 il tasso di guasti "logori": è un tasso di fallimento crescente che denota i guasti dovuti all’usura

individuati quando il prodotto supera la sua vita di progettazione.

Grazie a questa curva è possibile per i sistemi HW fornire una stima del grado di affidabilità prima

ancora di rilasciare il prodotto; non valgono le stesse considerazioni per il SW perché prima di

tutto il SW non si usura, più aumenta il tempo di vita e più è buono in quanto con il passare del

tempo vengono eliminati i faults e quindi al contrario dell’HW più passa il tempo e più migliora

l’affidabilità. Per il SW si usa la seguente curva: 4

C’è una fase iniziale di Testing/Debugging che va a migliorare l’affidabilità prima di mettere il

prodotto SW prima di metterlo in commercio; apportare modifiche al sistema per risolvere i faults

individuati richiede l’introduzione di nuovo SW (upgrade), che probabilmente introdurrà nuovi

faults. Quindi non è vero che effettuando degli upgrade si migliora nell’affidabilità, tuttavia dopo

diversi upgrade il grado di affidabilità resta invariato se e solo se il contesto applicativo in cui gira il

SW resta invariato (fase di obsolescenza). La prima differenza tra queste due curve è che nell’HW

la sostituzione di un componente rotto o usurato poteva soltanto migliorare l’affidabilità a

differenza del SW; altra differenza è che mentre per l’HW la curva aiuta a fare una stima apriori del

grado di affidabilità utile a tutti coloro che producono lo stesso HW, per il SW non è possibile

riciclare le stesse informazioni dalla curva perché ogni SW sarà sempre diverso anche se fornisce lo

stesso servizio quindi, ogni volta che si produce un SW bisogna calcolare la curva di affidabilità ex

novo.

La correttezza è una condizione necessaria ma non sufficiente per la

Reliability, perché un sistema affidabile deve per lo meno garantire la

correttezza, al contrario non è detto che un sistema che garantisca la

correttezza sia anche affidabile. In altre parole la correttezza è contenuta

nella Reliability

Altro attributo è l’Availability (Disponibilità) che definisce

la capacità del sistema in un certo istante di fornire un

servizio corretto. La Disponibilità è legata alla velocità con

cui il sistema si ripristina quando fallisce

Altri attributi importanti sono:

o Safety: è la probabilità che il sistema fallisca in modo catastrofico portando danni seri a

cose o persone. A differenza della Security, tale attributo si focalizza solo sugli aspetti di

sicurezza relativi a cose o persone. A differenza della Dependability la non si concentra su

tutti i failures ma solo i failure catastrophic.

o Security: inteso come sicurezza informatica, indica l’assenza di manipolazioni improprie e

accessi non autorizzati al sistema

o Performability: è una metrica introdotta per valutare le prestazioni del sistema anche in

caso di guasto, per capire fino a che punto un sistema è in grado di tollerare la presenza di

un fallimento. Rappresenta una misura indiretta del grado di affidabilità. È un requisito non

funzionale.

o Mantainability: è la capacità di un sistema di essere facilmente sottoposto a modifiche o

riparazioni. 5

1.1.2. Threats

I Threats (minacce) sono le cause di un eventuale malfunzionamento del sistema e quindi di una

perdita di fidatezza di esso. Si classificano in 3 categorie: Faults, Errors e Failures.

I Faults (guasti) si definiscono come una causa accertata/origine di un errore, derivata dal

malfunzionamento di un componente, di un’interfaccia, dall’utilizzo sbagliato da parte dell’utente

o da un errore in fase di progettazione o implementazione del sistema. Il termine fault e bug sono

sinonimi, la differenza è che con bug si intende qualcosa di relativo al SW mentre con il termine

fault si intende qualcosa di più generico che può essere dovuto sia all’HW che al SW. Si

distinguono due grandi classi di faults:

o Solid fault: anche detto Hard Fault o Bohrbug, in riferimento al modello atomico di Bohr. Si

tratta di faults ben localizzati nel sistema e ripetibili in quanto si ripresentano ogni volta

che si verificano le stesse condizioni che li hanno originati, solitamente si rilevano nelle fasi

iniziali dello sviluppo di SW. In linea generale sono legati a guasti di tipo fisico piuttosto che

a errori di progettazione. Si tratta di faults deterministici, per cui facendo girare

l’applicazione nelle stesse condizioni l’errore si ripresenta, motivo per il quale è possibile

correggere essi con un debugging, partendo dal fallimento e facendo un backtracking per

ricercare le condizioni di errore che hanno originato tale fallimento.

o Elusive fault: anche detto Soft Fault, o Heisenbugs in riferimento al principio di

indeterminazione di Heisenberg. Si tratta di faults che si verificano in particolari condizioni

che non sono determinate, ovvero che possono presentarsi una volta e non ripresentarsi

più, per questo motivo non essendo riproducibili le condizioni che causano il faults, non è

possibile fare il debug all’indietro e correggere l’errore, per questo motivo gli elusive faults

sono più gravi dei solid faults, gli elusive faults nei sistemi HW sono eccezioni, in quelli SW

sono la norma perché un sistema SW girerà in condizioni sempre diverse. La maggior parte

di questi faults si solleverà nelle fasi finali dello sviluppo SW.

In genere, durante il ciclo di vita del SW, prima del deploy del sistema SW, vengono trovati e

corretti la maggior parte degli Hard Faults; invece non sarà semplice individuare gli Elusive Faults

durante lo sviluppo, motivo per il quale questi ultimi saranno scoperti nella fase operativa del ciclo

di vita del SW. Per cui verrà rilasciato un SW sapendo che ci sono ancora alcuni Hard Faults e

tantissimi Elusive Faults. 6

I faults si classificano in base a vari fattori:

Fattore di Tipi di faults

Classificazione Human faults: guasti derivanti da errori umani commessi sia in fase di progettazione (design

faults) che in fase di utilizzo (interaction faults) del sistema.

In base alle

cause: Physical faults: guasti del sistema dovuti alla rottura di una parte fisica/meccanica del sistema,

oppure derivanti da problemi HW interni o da cambiamenti esterni come variazioni delle

condizioni ambientali.

Malicious faults: guasti introdotti deliberatamente nel sistema con la volontà di alterarne lo

In base alle stato provocando una sospensione del servizio o anche di accedere alle informazioni riservate.

intenzionalità: Non malicious faults: guasti introdotti inconsapevolmente all’interno del sistema.

Fault permanenti (hard): guasti stabili e continui nel tempo. Essi sono causati da difetti in fase

di progettazione o da malfunzionamenti fisici, la riparazione consiste quindi nel migliorare il

In base alla progetto, correggendo gli errori o nel riparare/sostituire la parte fisica non funzionante.

persistenza: Fault transienti: guasti che si verificano in concomitanza di particolari e temporanee condizioni

ambientali, quando queste spariscono sparisce anche l’effetto del guasto e il sistema continua a

funzionare. Sono più difficili da risolvere rispetto ai permanent e agli intermittent fault. Possono

essere originati da ambienti instabili. Qui L'hardware è quindi integro, ma ha funzionato in

modo anomalo per qualche tempo, causando il fault. Essi non possono essere riparati.

Fault intermittenti: guasti che si verificano in maniera instabile in diversi intervalli temporali e

scompaiono senza alcuna azione di ripristino per poi comparire più avanti. Sono generati da

difetti di progetto, o anche dall'utilizzo di HW di cattiva qualità. Sono più difficili da risolvere

rispetto ai solid fault, ma più semplici rispetto ai transienti perché essi hanno il vantaggio che si

ripresentano periodicamente (hanno una certa frequenza di verifica) e si ha maggiore possibilità

di capire quali sono le condizioni ambientali che l’hanno causato, in modo tale da riprodurle per

fare operazioni di debugging.

La seconda tipologia di Threats è composta dagli Errors (errori), che sono lo stato scorretto in cui si

porta il sistema quando si attiva un guasto. Un errore è la parte dello stato di un sistema che può

indurre al fallimento, ovvero a fornire un servizio non conforme alle specifiche. Un fault può

portare o meno a uno o più errori (multiple related errors), in un sistema SW possono esserci più

fault ma non è detto che si attivino tutti causando errori. La causa di un errore è un fault. Un

errore, a seconda del sollevamento o meno di un messaggio di errore quando si verifica può

distinguersi in:

o Detected: errori rilevati a livello utente e opportunamente segnalati da un messaggio di

errore;

o Latente: sono errori non rilevati a livello utente e di conseguenza non segnalati da

o