UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA

MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE

FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI
AMPOSDRU

Investeşte în oameni !
Proiect cofinanţat din FONDUL SOCIAL EUROPEAN
prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007 – 2013
Axa prioritară 1: „EDUCAŢIA ŞI FORMAREA PROFESIONALĂ ÎN SPRIJINUL CREŞTERII ECONOMICE ŞI DEZVOLTĂRII SOCIETĂŢII
BAZATE PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
Cerere de propuneri de proiecte: nrnr. 86 „Universitate
Universitate pentru viitor”
Titlul proiectului: Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de
licenţă şi masterat, din domeniul Ingineria Sistemelor
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806

Gabriela Varvara
Ingineria Programarii I

Curs 9
Dezvoltarea sistemelor critice
Partener P4

MINISTERUL EDUCAŢIEI, UNIVERSITATEA UNIVERSITATEA TEHNICĂ UNIVERSITATEA TEHNICĂ UNIVERSITATEA SC ASTI AUTOMATION SRL
CERCETĂRII, TINERETULUI ”POLITEHNICA” DIN ”GHEORGHE ASACHI” ”POLITEHNICA”
ŞI SPORTULUI DIN CLUJ-NAPOCA DIN DIN
BUCUREŞTI IAŞI TIMIŞOARA

<Ingineria programarii I>

Curs 9: Dezvoltarea sistemelor critice - Agenda <Gabriela Varvara>

Obiective curs:

Obiectivul
Obi ti l 1:1 explicarea
li modului
d l i in
i care toleranta
t l t la
l defect
d f t sii evitarea
it
defectelor contribuie la dezvoltarea de sisteme sigure.
Obiectivul 2:descrierea caracteristicilor proceselor software sigure.
Obiectivul 3: introducerea tehnicilor de programare destinate evitarii
defectelor.
Obiectivul 4: descrierea mecanismelor de toleranta la defect si folosirea
acestora in procese de diversificare si redundanta.

Subiecte tratate: procese si programare pentru sisteme sigure, toleranta la

defecte, arhitecturi cu toleranta la defecte.

2
 <Ingineria programarii I>
Dependabilitatea software si atingerea acestui deziderat <Gabriela Varvara>

In general clientii produselor software se asteapta ca orice produs IT sa fie

dependabil. Totusi, pentru aplicatiile necritice, ei vor fi fortati sa accepte si
unele caderi ale sistemului.
Pentru aplicatiile cu cerinte de dependabilitate ridicate vor trebui adoptate
strategii de inginerie software speciale.
Atingerea dependabilitatii inseamna:
Evitarea erorilor
Evitarea erorilor umane
Procesul de dezvoltare este organizat astfel incat erorile sistem sunt
detectate si reparate inaintea livrarii produsului la client
Detectia erorilor - sunt utilizate tehnici de verificare si validare pentru a
descoperi si inlatura erorile din sistem inaintea livrarii
Toleranta la erori – sistemul este dezvoltat astfel incat erorile din softul
livrat nu determina caderi ale acestuia

<Ingineria programarii I>

Diversitate si redundanta <Gabriela Varvara>

Redundanta - pastrarea a mai mult decat o versiune pentru componentele critice,

astfel incat la caderea uneia o alta sa fie disponibila
Pentru situatiile in care disponibilitatea este critica vor trebui inserate servere
de backup cu comutare automata la aparitia unei erori

Diversitate - furnizarea aceleasi functionalitati in modalitati diferite, astfel incat

sa se evite caderea in acelasi mod
Pentru a furniza rezilienta fata de atacurile externe unele servere vor fi
implementate in mai multe sisteme de operare (Linux, Windows, etc.)

Adaugarea de redundanta si diversitate va duce, insa, la cresterea complexitatii

produsului cu cresterea simultana a probabilitatii de producere de erori
Unii ingineri sustin ca simplitatea la care se adauga o verificare si validare
extensiva reprezinta o metoda mai eficace de creare de software dependabil

4
 <Ingineria programarii I>
Software fara erori <Gabriela Varvara>

Pentru sistemele mici exista actualmente metode de inginerie software care sa creeze
produse IT fara erori
Software-ul fara erori este acela ce se conformeaza propriilor specificatii. Aceasta nu
inseamna ca este un produs lipsit de erori, caci ar putea exista erori in specificatii.
Costul producerii de soft fara erori este foarte ridicat (vezi fig.) si se recomanda doar in
cazuri exceptionale. Uneori este mai ieftin sa se accepte costurile eliminarii
consecintelor producerii erorilor decat sa se dezvolte un soft lipsit de eroare.
Dezvoltare de soft lipsit de erori inseamna:
Folosirea de procese de
dezvoltare dependabile
Managementul calitatii
Existenta de specificatii formale
Verificare statica
Tipizare extinsa
Programare sigura multe putine foarte putine

Informatii protejate numar erori reziduale

<Ingineria programarii I>

Procese dependabile <Gabriela Varvara>

Pentru a garanta ca numarul de erori este minim va trebui folosit un proces de

dezvoltare bine definit si repetabil.
Aceste caracteristici ale procesului nu depind integral de abilitati personale ale
membrilor echipei de dezvoltare
Pentru detectia erorilor, activitatile procesului de dezvoltare trebuie sa includa un
efort semnificativ in directia verificarii si validarii
Caracteristicile unui proces de dezvoltare software dependabil:
Documentabil - procesul trebuie sa se deruleze dupa un model definit cu specificarea
tuturor activitatilor si a documentelor ce trebuie produse in cadrul acestora
Standardizat – trebuie sa existe un set comprehensiv de standarde de dezvoltare care
sa specifice cum va fi produs softul si cum va fi disponibila documentatia
Auditabil – procesul trebuie sa fie inteles de catre persoane dinafara echipei de
dezvoltare care sa poata verifica modul cum au fost urmate standardele de proces si sa
g
faca sugestii de imbunatatire a p
procesului.
Divers – procesul trebuie sa includa activitati de verificare si validare diverse si
redundante
Robust – procesul trebuie sa fie capabil sa se refaca in urma caderilor unor activitati
individuale

6
 <Ingineria programarii I>
Programare dependabila <Gabriela Varvara>

Folosirea de constructii si tehnici de programare care sa contribuie la

evitarea/toleranta in raport cu defectele, cum ar fi:
Proiectare simpla
j
Protejarea p
informatiei in raport cu accesul neautorizat. Informatia
trebuie expusa doar acelor parti de program ce trebuie sa o
foloseasca (implica crearea de tipuri abstracte de obiecte/date ce
contin starea si furnizeaza doar operatii pe stare. In acest fel se evita
erorile prin 3 modalitati:
probabilitatea de corupere accidentala a informatiei este redusa
informatia este inconjurata de “firewall”, ce atrage scaderea
probabilitatii de extindere a erorilor la alte parti din program
deoarece toata informatia este localizata, scade probabilitatea de
a produce erori si creste probabilitatea ca un reviewer sa le
depisteze
Minimizarea folosirii constructiilor de programare nesigure

<Ingineria programarii I>

Exemple de acces prin metode si lucru cu variabile statice <Gabriela Varvara>

interface Queue {

public void put (Object o) ;

public void remove (Object o) ;
public int size () ;

} //Queue class Signal {

static public final int red = 1 ;

static public final int amber = 2 ;
static public final int green = 3 ;

public int sigState ;

}

8
 <Ingineria programarii I>
Programarea sigura <Gabriela Varvara>

Erorile de programare sunt, cel mai adesea, o consecinta a greselilor facute de

catre programatori. Acestea apar deoarece se pierde evidenta relatiilor dintre
variabilele programului.
p g
Programarea structurata – propusa inca din 1968, ea reprezinta o metoda de
dezvoltare ce creste gradul de intelegere al codului si permite evitarea erorilor de
programare prin:
Eliminarea instructiunilor go to;
Controlul executiei prin cicluri while sau instructiuni if;
Proiectare top
top-down;
down;

<Ingineria programarii I>

Constructii de programare ce pot produce erori <Gabriela Varvara>

Unele constructii de programare atrag dupa sine o probabilitate crescuta de

producere de erori si vor trebui folosite cu prudenta:
Folosirea numerelor in virgula mobila – este inerent imprecisa si poate conduce la
comparatii invalide.
Pointeri – pot referi zone gresite de memorie, determinand coruperea datelor.
Alocarea dinamica a memoriei – poate cauza overflow pe memorie.
Paralelismul – poate produce erori subtile de temporizare datorate interactiunii
netransparente intre procesele ce se deruleaza in paralel.
Recursivitatea – poate genera depasirea memoriei (memory overflow)
Intreruperile – pot determina oprirea unei operatii critice si astfel programul devine dificil de
inteles ca actiune
Mostenirea – determina nelocalizarea codului si poate produce comportament neprevazut
atunci cand se opereaza schimbari si dificultati in intelegerea modului de executie.
Aliasing – folosirea a mai mult de un nume pentru a referi o singura variabila de stare
Masive nemarginite – pot produce erori de depasire ale bufferelor in cazul in care marginirea
nu este verificata.
Preprocesari implicite ale intrarilor – reprezinta actiuni ce se executa pentru indiferent ce
informatie de intrare.

10
 <Ingineria programarii I>
Tratarea exceptiilor <Gabriela Varvara>

O exceptie program este o eroare sau un eveniment neasteptat cum ar fi o

cadere de tensiune
Constructiile ce manipuleaza exceptiile permit, pentru aceste evenimente,
tratare fara a fi necesara o verificare continua a starii pentru identificarea
exceptiilor.
Tratarea exceptiilor prin constructii de control normale implica introducerea
unui volum mare de cod suplimentar ce reprezinta o sursa potentiala de erori.
Ex. Tratare exceptii in Java: class Sensor {
class SensorFailureException extends Exception { int readVal () throws SensorFailureException {

SensorFailureException (String msg) { try {

super (msg) ; int theValue = DeviceIO.readInteger () ;
Alarm.activate (msg) ; if (theValue < 0)
} throw new SensorFailureException ("Sensor failure") ;
} // SensorFailureException
p return theValue ;
}
catch (deviceIOException e)
{
throw new SensorFailureException (“ Sensor read error ”) ;
}
} // readVal
} // Sensor

11

<Ingineria programarii I>

Folosirea exceptiilor – Controller de temperatura <Gabriela Varvara>

Exceptiile pot fi folosite drept o tehnica obisnuita de programare si nu doar exclusiv

pentru procesele de fault recovery.
De exemplu, un controller al temperaturii de refrigerare cu facilitati de tipul: comutare
pompa on/off, setare alarma pe depasire temperatura maxima – ce foloseste ca tehnica
de programare exceptiile are codul:
class FreezerController { if (freezerTemp > d angerTemp )
Sensor temp Sensor = n ew Se nsor () ; throw new F reezerTooHotException () ;
Dial tem pDial = n ew D ial () ; freezerTemp = tempSensor.readVal () ;
float freezerTemp = tem pSensor.readVal () ; } while (true) ;
final float dangerTemp = (float) -18.0 ;
} // try block
final long coolingTime = (long) 200000.0 ; catch (FreezerTooHo tException f)
public void run ( ) throw s InterruptedException { { Alarm.activate ( ) ; }
try { Pump .switchIt (Pump .on) ; catch (InterruptedException e)
do { {
if ((freezerTemp p > tem p
pDial.setting
g ()) System.out.println (“Thread exception”) ;
throw new InterruptedException ( ) ;
if (Pump .status == Pum p.off)
}
{ Pump .switchIt (Pump .on) ; } //run
Thread.sleep (coolingTime) ; } // FreezerController
}

12
 <Ingineria programarii I>
Toleranta la defecte <Gabriela Varvara>

Toleranta la defecte inseamna ca sistemul trebuie sa isi continue operarea in pofida

caderii software ce a aparut.
Sistemele critice trebuie sa fie tolerante la defecte.
Aceasta cerinta apare ca o consecinta a cerintelor de disponibilitate inalta sau atunci
cand costurile implicate de caderea sistemului sunt foarte mari.
Chiar daca un sistem critic s-a dovedit a fi conform cu propriile specificatii, el va trebui
suplimentar sa fie si tolerant la defecte, deoarece specificatiile pot contine erori sau
validarea s-ar putea sa fi fost incorecta.
Se intreprind actiuni astfel incat sistemul sa poata realiza:
Detectia defectelor – sistemul trebuie sa poata depista aparitia unei stari
incorecte.
Evaluarea efectelor unui defect – sistemul trebuie sa poata detecta ce parti ale
starii sale sunt afectate de defect.
Restabilire dupa defect – sistemul trebuie sa isi refaca starea prin comutare
intr-o stare sigura cunoscuta.
Actiuni externe sistemului - repararea erorii : odata detectata producerea unei erori,
sistemul trebuie modificat pentru a preveni reaparitia defectului. Cum majoritatea
defectelor soft sunt tranzitorii, repararea nu este necesara de cele mai multe ori.

13

<Ingineria programarii I>

Detectarea defectelor si evaluarea consecintelor <Gabriela Varvara>

Este primul stadiu din implementarea mecanismelor de toleranta la defecte

Implica definirea constrangerilor pentru existenta tuturor starilor legale si verificarea starilor
curente in raport cu aceste constrangeri:

// The
Th dose
d off insulin
i li to
t be
b delivered
d li d mustt always
l be
b greater
t
// than zero and less that some defined maximum single dose
insulin_dose >= 0 & insulin_dose <= insulin_reservoir_contents
// The total amount of insulin delivered in a day must be less
// than or equal to a defined daily maximum dose
cumulative_dose <= maximum_daily_dose

Procesul de detectie a defectelor poate fi:

Preventiv – initiat inainte schimbarii de stare. Daca se detecteaza un defect tranzitia starilor
nu se mai produce
Retrospectiv – initiat dupa ce tranzitia de stare s-a produs. Acest proces este folosit cand:
o secventa incorecta de actiuni corecte conduce la o stare eronata sau
detectia preventiva este prea implicanta

14
 <Ingineria programarii I>
Detectia preventiva a erorilor si extensia definitiilor de tip <Gabriela Varvara>

Detectia preventiva, prin introducerea de noi constrangeri va determina o

extensie a tipurilor de date manipulate de catre sistem:
public void assign (int n) throws NumericException
{
if (n < 0 | n%2 == 1)
class PositiveEvenInteger {
throw new NumericException ();
int val = 0 ; else
l
val = n ;
PositiveEvenInteger (int n) throw s Num ericException } // assign
{
if (n < 0 | n%2 = = 1)
throw new N ume ricException () ; int toInteger ()
else {
val = n ; return val ;
} //to Integer
}// PositiveEvenInteger

boolean equals (PositiveEvenInteger n)

{
return (val == n.val) ;
} // equals

} //PositiveEven

15

<Ingineria programarii I>

Evaluarea consecintelor defectelor <Gabriela Varvara>
Se va evalua starea sistemului in vederea stabilirii gradului de extensie a coruptiei provocata de caderea
acestuia.
Se va stabili ce parti din spatiul starii sistemului au fost afectate de cadere. Acest lucru se realizeaza prin functii
de validare ce vor fi aplicate elementelor starii. Se va testa incadrarea in limite admisibile a valorilor de retur.
class RobustArray {
// Checks that all the objects in an array of objects
// conform to some defined constraint

boolean [] checkState ;
CheckableObject [] theRobustArray ;

RobustArray (CheckableObject [] theArray)

{
checkState = new boolean [theArray.length] ;
theRobustArray = theArray ;
} //RobustArray
public void assessDamage () throws ArrayDamagedException
{
boolean hasBeenDamaged = false ;

for (int i= 0; i <this.theRobustArray.length ; i ++)

{
if (! theRobustArray [i].check ())
{
checkState [i] = true ;
hasBeenDamaged = true ;
}
else
checkState [i] = false ;
}
if (hasBeenDamaged)
throw new ArrayDamagedException () ;
} //assessDamage
} // RobustArray

16
 <Ingineria programarii I>
Tehnici de evaluare a consecintelor defectelor <Gabriela Varvara>

Pentru evaluarea consecintelor defectelor de transmisie de date se utilizeaza

sumele de verificare.
Pentru evaluarea integritatii structurilor de date se folosesc pointeri
redundanti.
Pentru procese nefinalizate se recurge la folosirea timerelor de urmarire (watch
dog timers). Daca dupa un anumit timp nu s-a primit nici un raspuns se
presupune ca un defect s-a produs.

17

Restabilire (redresare) sistem dupa producerea erorii <Ingineria programarii I>

<Gabriela Varvara>

Redresarere inainte– aplicarea unui proces de restabilire a sistemului atunci

cand acesta se afla intr-o stare defectuoasa. Implica cunostinte din domeniul
aplicatiei pentru efectuarea corectiilor posibile de stari.
stari
Redresare inapoi – revenirea sistemului intr-o stare cunoscuta, sigura.
Presupune un proces simplu de memorare a starilor sigure ce vor inlocui
starile corupte.

18
 <Ingineria programarii I>
Restabilire inainte (in avans) – forward recovery <Gabriela Varvara>

Se aplica pentru:
Coruperea datelor pe perioada unui proces de transmisie – datele codificate vor fi
reprezentate
t t redundant,
d d t in i vederea
d recuperarii
ii acestora
t in
i caz de
d corupere.

Coruperea informatiei pentru date structurate – se recurge la utilizarea unor pointeri

redundanti ce permit reconstituirea unei liste sau a unui fisier, daca un numar
suficient de pointeri raman necorupti.

19

<Ingineria programarii I>

Restabilire inapoi (backward recovery) <Gabriela Varvara>

Cea mai des folosita metoda de restabilire inapoi este cea a tranzactiilor –
modificarile nu vor fi aplicate decat la finalizarea calculelor. Daca apare o
eroare sistemul va fi lasat in starea precedenta tranzactiei.
tranzactiei
Verificarile periodice sunt o alta metoda de revenire a sistemului intr-o stare
precedenta, corecta.

20
 <Ingineria programarii I>
Procedura de sortare sigura <Gabriela Varvara>

Procedura:
Va monitoriza propria executie si va evalua corectitudinea acesteia
Va mentine o copie a intrarilor
Va identifica si gestiona exceptiile
Va
V valida
lid sortarea
t deoarece iin acestt caz conditia
d diti pentru
t o sortare
t valida
lid este
t
cunoscuta. In multe alte cazuri, insa, verificarile de validare sunt extrem de dificile.
class SafeSort { if (order == Sort.ascending)
for (int i = 0; i <= intarray.length-2 ; i++)
static void sort ( int [] intarray, int order ) throws SortError if (intarray [i] > intarray [i+1])
throw new SortError () ;
{
else
int [] copy = new int [intarray.length]; for (int i = 0; i <= intarray.length-2 ; i++)
if (intarray [i+1] > intarray [i])
// copy the input array throw new SortError () ;
} // try block
for (int i = 0; i < intarray.length
intarray length ; i++) catch (SortError e )
copy [i] = intarray [i] ; {
try { for (int i = 0; i < intarray.length ; i++)
Sort.bubblesort (intarray, intarray.length, order) ; intarray [i] = copy [i] ;
throw new SortError ("Array not sorted") ;
} //catch
} // sort
} // SafeSort

21

<Ingineria programarii I>

Arhitecturi tolerante la defecte <Gabriela Varvara>

Probleme de dependabilitate:

Programarea clasica de tip defensiv (tratarea defectelor post factum) nu poate

trata erori ce provin din proasta interactiune hardware-software.

Adesea, o intelegere gresita a cerintelor poate duce la concluzia ca verificarile si

codul corespunzator acestora este gresit.

Sistemele cu cerinte de disponibilitate ridicata impun proiectarea unei arhitecturi

tolerante la erori.

In aceste conditii, arhitectura aleasa va trebui sa suporte atat erorile software cat si pe
cele hardware.

22
 <Ingineria programarii I>
Toleranta la erori hardware <Gabriela Varvara>

Modelul de arhitectura tolerant la erori cel mai folosit implica crearea unei redundante modulare
triple (triple-modular redundancy TMR).
Pentru fiecare intrare exista trei componente replicate identic ce o trateaza. Iesirile acestor
componente vor fi comparate si, daca macar una este gasita diferita, blocul modular respectiv este
neglijat si se considera evenimentul – producere eroare componenta hardware.
Acest tip de tratare se bazeaza pe erorile rezultate din caderea componentelor si pe un proces de
proiectare ce sa ia in considerare o probabilitate scazuta de cadere simultana a componentelor.

A1

A2 comparator
pe iesire

A3

Comparatorul de iesire este simplu; ele compara semnalele de intrare si, daca unul este diferit il
rejecteaza (selectia iesirii curente se bazeaza pe votul majoritar).
Comparatorul de iesire este conectat la o unitate de management a erorilor ce va incerca fie sa
repare modulul fie il va scoate din uz.

23

<Ingineria programarii I>

Arhitecturi tolerante la erori software <Gabriela Varvara>

Succesul TMR in ceea ce priveste toleranta la defecte hardware se bazeaza pe 2 ipoteze:

Componentele hardware nu au erori de proiectare comune
Componentele cad in mod aleator si exista o mica probabilitate de cadere simultana a
acestora

Nici una din aceste ipoteze nu este valabila pentru erorile software
Nu este posibil sa replicam pur si simplu componentele software caci ele pot avea erori de
proiectare comune. Astfel, caderea simultana a componentelor este virtual inevitabila.

Drept consecinta, pentru proiectarea sistemele software se aplica principiul diversitatii:

Versiuni diferite ale sistemului sunt proiectate si implementate in moduri diferite. Astfel, se
presupune ca ele vor avea moduri de cadere diferite.
Se adopta pentru proiectare metode diferite ( ex. orientat-obiect si orientat functional):
Implementare in limbaje diferite;
Folosirea de utilitare diferite;
Adoptarea unor algoritmi diferiti de implementare.

24
 <Ingineria programarii I>
Analogii software pentru TMR <Gabriela Varvara>

Programare in N versiuni – aceleasi specificatii sunt implementate de catre echipe diferite, in

versiuni diferite. Se presupune ca exista o mica probabilitate ca echipele sa comita aceleasi erori.
Toate versiunile vor lucra simultan, selectandu-se iesirea pe principiul sistemului majoritar de
votare (folosita frecvent de catre compania Airbus pentru modelele sale comerciale).

Versiune 1

Intrare
Comparator
Versiune 2
iesire
rezultat agreat

Versiune 3
Manager erori

N-versiuni
In mod empiric, exista o evidenta clara a faptului ca toate echipele gresesc la fel in interpretarea
specificatiilor si aleg acelasi tip de algoritmi pentru sistemele lor.
Comparatorul este o unitate simpla ce recurge la mecanismul de votare pentru selectia iesirii.
Pentru un sistem de timp real, poate sa existe cerinta ca rezultatele diferitelor versiuni sa se
produca intr-un anumit interval de timp.

25

<Ingineria programarii I>

Blocuri de restabilire <Gabriela Varvara>

Folosirea blocurilor de restabilire – un numar de versiuni ale aceleasi specificatii sunt scrise si
executate secvential. Apoi se aplica un test de acceptare pentru a selecta iesirea ce va fi transmisa
mai departe.
Acest mecanism forteaza spre folosirea de algoritmi diferiti pentru fiecare versiune in scopul
reducerii probabilitatii de producere de erori comune.
Proiectarea testului de acceptanta
p este dificila deoarece acesta trebuie sa fie independent
p de
modul de calcul folosit.
Pentru sistemele de timp real acest mecanism este dificil de aplicat deoarece presupune operarea
secventiala a unor versiuni redundante.
testare algoritm 1 Test acceptare
Testare
Algoritm 1 Test acceptare Continuare executie
daca test acceptare
reuseste si semnal
exceptie daca testul
reluare reluare
esueaza
retestare retestare

Algoritm 2 Algoritm 3

Blocuri recuperare

26
 <Ingineria programarii I>
Probleme in folosirea diversitatii de proiectare software <Gabriela Varvara>

Echipele nu sunt diverse cultural – ele tind sa gestioneze in maniera

asemanatoare problemele.
Apar erori tipice pentru aceasta metoda:
Echipe diferite comit aceleasi erori - unele parti ale implementarii sunt mai
dificile decat altele, astfel ca se comit aceleasi greseli in aceleasi locuri.
Daca exista o eroare in specificatii ea se reflecta in toate implementarile;
acest fapt poate fi gestionat pana la un anume punct recurgand la
reprezentari multiple ale specificatiilor.

27

<Ingineria programarii I>

Puncte cheie ale prezentarii <Gabriela Varvara>

Dependabilitatea sistemelor poate fi atinsa prin evitarea defectelor, depistarea acestora

si toleranta la defecte.
Folosirea redundantei si diversitatii sunt esentiale pentru obtinerea de sisteme
dependabile.
In vederea minimizarii erorilor este esentiala folosirea unui proces de dezvoltare bine
definit si repetabil
repetabil.
Unele constructii de programare pot genera erori – ori de cate ori este posibil ele vor
trebui evitate.
Pentru sistemele dependabile managementul erorilor se realizeaza prin intermediul
exceptiilor.
Toleranta le defecte implica detectia erorilor, evaluarea efectelor erorilor, restabilirea si
repararea sistemului.
Programarea in N versiuni si folosirea blocurilor de restabilire sunt metode alternative
pentru arhitecturile tolerante la defecte.
p

28