TESTAREA PE BAZĂ DE

MODEL
(I)

CURS 4
 Model= metodă de reprezentare a
comportamentului software
 Teoria grafurilor în testarea software pe bază
de model
 Probleme cu testarea tradiţională:
 Paradoxul pesticidelor (Beizer, 1990)-Testele
sunt din ce în ce mai puţin eficiente în
descoperirea erorilor, întrucât acestea au fost
deja fixate
 Testele tradiţionale trebuie actualizate la
modificarea softului
 Testarea pe bază de model: generează teste
din descrierea explicită a aplicaţiei- mai uşor
de generat şi menţinut teste utile şi flexibile
 Graful stărilor =maşina finită de stări- model de reprezentare a
comportamentului software

 Ex: aplicaţia începe într-o stare (“se afişează fereastra principală”), utilizatorul
aplică o intrare (“apelează dialogul Help”) şi programul trece într-o stare nouă
(“Dialogul Help afişat”).

 O mare parte din testarea software poate fi privită ca drumul

testerului prin stările diferite ale aplicaţiei, cu verificarea
corectitudinii fiecărui pas
Ce este testarea pe bază de model?
 În încercarea de a face testarea mai simplă şi mai ieftină, s-a dorit ca testarea
să folosească informaţii conţinute în modele explicite (Beizer 1995, Apfelbaum
1997)
 Testarea pe bază de model este o tehnică black-box cu următoarele avantaje
asupra testării tradiţionale:
 Construcţia modelelor de comportament poate începe devreme în ciclul de
dezvoltare.
 Modelarea descoperă ambiguităţile din specificarea şi design-ul software.
 Modelul cuprinde informaţii comportamentale ce pot fi refolosite în testările
viitoare, chiar dacă specificaţia se modifică
 Modelul e mai uşor de actualizat decât o suită de teste individuale
 Modelul furnizează informaţii ce se pot combina cu teoria grafurilor pentru
generarea automată a diverselor scenarii de testare
 Care este lungimea minimală a unui tur prin graf (digraf), cu muchii direcţionate (arce) (se poate circula doar într-un sens)?
 Ciclu eulerian?
 Eulerizarea unui digraf: trebuie să avem un număr de arce ce intră egal cu numărul arcelor ce ies din fiecare nod

 Se numără arcele care intră “+1” şi arcele care ies “-1”, calculându-se polaritatea fiecărui nod în digraf (ex. un nod cu două
arce care ies şi unul care intră are polaritatea “ 1 – 2 = -1”. (în figură e afişată polaritatea nodurilor înainte şi după
eulerizare)

 Pentru crearea unui digraf eulerian, se duplică arcele între nodurile de polaritate pozitivă şi nodurile de polaritate negativă
astfel că toate nodurile vor avea polaritate zero.

 Oricine intră într-un nod printr-un arc de intrare poate ieşi din nod printr-un arc de ieşire .
 În Figură, s-au duplicat arcele “b”, “e” şi “g” pentru echilibrarea digrafului.

 Asfaltatorul poate urma ruta direcţionată minimală a b c b f e g d e g, repetând doar segmentele

“b”, “e” şi “g”
O problemă de testare
 Presupunem că dorim să testăm, şi dispunem de un model
comportamental al software-ului de testat, model ce arată ca digraful
din stânga figurii, unde nodurile reprezintă stările aplicaţiei şi arcele sunt
acţiunile pe care le puteţi executa

 Cum putem executa eficient fiecare acţiune? Soluţia problemei

precedente..
 Pe modelul comportamental se aplică algoritmul de generare automată
a traversării
 Astfel, testerul poate verifica toate acţiunile posibile :
abcbfegdeg
Testarea combinaţiilor de acţiuni
 Executarea fiecărei acţiuni din model seamănă cu acoperirea stărilor când
testăm codul; dar întrucât există deseori multiple variante de urmat din fiecare
nod, ce putem face dacă dorim să testăm combinaţii de acţiuni?
 Spre exemplu, în figură dorim să testăm combinaţii de arce ca “b c”, “b f”, şi “b
g”?
 “b g” nu apare în secvenţa de testare generată anterior,- prin algoritmul
precedent se garantează vizitarea fiecărui nod nu a fiecărei combinaţii de noduri

 Testarea combinaţiilor de acţiuni se numeşte “acoperire de switch” în testarea

folosind maşini finite de stări

 Există un algoritm simplu în teoria grafurilor -de Bruijn (“de-broyn”) care

generează acţiunile corespunzătoare pentru acoperirea switch-urilor (Gross and
Yellen 1998)
 Secvenţele de Bruijn descriu “cea mai scurtă secvenţă suficientă pentru a verifica toate
combinaţiile de lungime n.” (Skiena 1998)
 Secvenţa de Bruijn pentru combinaţii de lungime 2 (toate perechile de acţiuni adiacente) e
generată după cum urmează:
 1. Crează graful dual al grafului original (i.e., un graf în care arcele grafului original sunt
convertite în noduri)
 2. Oriunde în graful original intră un arc 1 într-un nod şi un arc 2 iese din nod, crează un
arc de la nodul 1 la nodul 2.
 Spre exemplu, în figura anterioară, arcul “a” intră în nodul din care iese “b”; astfel că în
graful dual există un arc din nodul “a” către nodul “b”.
 3. Figura anterioară descrie graful dual complet
 4. Eulerizaţi graful dual (prin duplicarea arcelor pentru a echilibra polaritatea nodurilor)
 5. Traversaţi graful eulerizat, notând numele nodurilor prin care treceţi
 Secvenţa generată va fi acoperirea switch-urilor de lungime 2 a grafului (se poate observa
că toate combinaţiile de 2 legături sunt generate incluzând “b c”, “b f” şi “b g”)
 abcbfecbgdefeg
TESTAREA PE BAZĂ DE
MODEL
(II)

CURS 10
Testarea condiţionată de un
termen

limită
Presupunem că suntem în următoarea situaţie de testare:
1. avem la dispoziţie mai multe maşini de test
2. avem timp limitat pentru testare (situaţia reală)
3. fiecare acţiune din modelul comportamental se
execută într-o oră (pentru scopul discuţiei de faţă)
4. aplicaţia intră în starea “reset” când primeşte inputul
“g”.
5. fiecare maşină poate rula un scenariu de test din
starea “reset”
 Să luăm secvenţa de testare pentru figura alăturată :
abcbfegdeg

 Dacă împărţim aceste acţiuni între 2 maşini din starea “reset” (i.e., după
executarea acţiunii “g”), vom avea distribuţia:
 Maşina 1: a b c b f e g (timp de rulare 7 ore)
 Maşina 2: d e g (timp de rulare 3 ore)

 Aceasta este o utilizare ineficientă a maşinilor de test, ar fi bine să

distribuim încărcarea mai echitabil între cele două maşini; în plus,
secvenţe de testare mai scurte uşurează sarcina de reproducere a
defectelor întâlnite

 Nu există o soluţie optimală , simplă a acestei probleme de sub-tur, dar

există câteva euristici foarte bune
Abordarea Dill, Ho, Horowitz
&Yang (1995)
 Stabileşte o limită superioară a numărului de arce ce pot fi
vizitate într-un singur sub-tur
 Algoritmul caută arce nevizitate în graf, vizitând un număr maxim
din acestea, fără să depăşim o limită maximă
 Pe măsură ce numărul de arce dintr-un sub-tur se apropie de
limită, algoritmul termină sub-turul, trece în starea “reset” şi
începe generarea unui alt subtur
 Algoritmul nu garantează optimul, dar tururile sunt în general
eficiente
 Dacă limităm fiecare subtur la 5-6 arce, putem ajunge la
distribuţia (economie de 2 ore a timpului de execuţie):
 Maşina 1: a b c b g (timp de rulare 5 ore)
 Maşina 2: d e f e g (timp de rulare 5 ore)
Drumuri aleatoare
 Drum aleator: din nodul curent, alege aleator
un arc de ieşire, urmează arcul respectiv până
în nodul adiacent şi repetă procesul
 Lipsa unui plan le face interesante pentru
testare, întrucât astfel devin rezistente la
paradoxul pesticidelor (au fost folosite cu
mare succes în testare la Microsoft)
 Dezavantaj: sunt ineficiente în acoperirea
rapidă a unui graf (tind să retraverseze arce
prin care au mai fost)
Testarea căilor celor mai probabile
 Cum putem ghida căile aleatoare în zone de interes pentru tester?- spre
exemplu, cale aleatoare prin activităţile cele mai frecvente ale utilizatorilor...

 Lanţurile Markov pot ajuta ghidarea căilor aleatoare prin asignarea de

probabilităţi arcelor ce ies din noduri astfel încât, statistic, o cale alatoare
este mai probabil să urmeze arcele cu probabilitate mai mare.

 Dezavantaj: există încă o doză mare de incertitudine că vom ajunge pe calea

dorită: dacă avem modelul anterior şi probabilităţile din figură : acţiunea a are
probabilitatea 0.99999 de a fi invocată din nodul A; acţiunea b are
probabilitatea 0.00001 de a fi invocată
 Dacă alegem aleator între ele pe baza acestor probabilităţi, am putea
executa a de mii de ori înainte de a executa b o singură dată- ineficient.
 Lanţuri Markov şi teoria
grafurilor
 Combinăm teoria grafurilor şi probabilităţile lanţurilor Markov pentru a
obţine traversări eficiente ale căilor de interes:
1. Asignăm probabilităţi arcelor din graf (ca în lanţurile Markov).
2. Stabilim o probabilitate minimă a căilor de interes, spre exemplu 0.0000001.
3. Începând cu nodul iniţial, înaintaţi prin graf, păstrând probabilitatea
cumulativă a arcelor traversate.
4. Continuăm traversarea arcelor din graf până ajungem în nodul final al
grafului sau până când probabilitatea cumulativă a drumului urmat scade sub
minimul stabilit
5. Dacă am ajuns în nodul final, memorăm calea prin care am ajuns aici şi
probabilitatea sa.
6. Dacă am ajuns cu probabilitatea cumulativă sub minimul stabilit, ne
întoarcem şi încercăm un alt arc (backtracking).
7. După ce am reţinut toate căile prin graf de probabilitate cumulativă mai mare
decât minimul, le sortăm descrescător în ordinea probabilităţilor cumulative.
 Prin testarea mai întâi a căilor de probabilitate mai mare, ne asigurăm
că am testat aplicaţia cel mai eficient pentru a asigura validitatea
software.
Concluzie
 Modelele sunt un mod excelent de reprezentare şi înţelegere a
comportamentului unui sistem, şi oferă o modalitate facilă de
actualizare a testelor pentru o aplicaţie ce se modifică şi
evoluează constant
 Testarea unei aplicaţii poate fi văzută ca parcurgerea unui drum
prin graful modelului; teoria grafurilor ne permite să folosim
informaţiile de comportament din modele pentru a genera teste
noi şi folositoare

 Întrucât teoria grafurilor abordează direct modelul,

 Noi traversări se pot genera automat când se schimbă modelul

 Testele se pot modifica în mod constant folosind acelaşi model

 Diferite tipuri de traversare servesc diferite necesităţi ale testerilor

 Tehnicile de traversare sunt generale şi pot fi refolosite pe modele

diferite
CURS 10
Testare white-box

Acoperirea cu teste (II)

Acoperirea bazată pe predicate
 predicate(-complete) coverage,
 Criteriile anterioare: NU corelează între ele deciziile.
→ ex. combinaţii a două decizii succesive în program
→ necesar un criteriu mai apropiat de path coverage (care ar
acoperi toate căile de execuţie)
 Se identifică n predicate (condiţii) relevante în
program
 Se încearcă generarea tuturor combinaţiilor posibile
din cele S .2n (S stări = locaţii în program, n
predicate)
→ corelează între ele toate condiţiile şi locaţiile din program
Criterii de acoperire pentru cicluri
 Pentru cicluri simple:
→ zero iteraţii (nu se intră în ciclu)
suplimentar: contor negativ: se comportă corect ?
→ o iteraţie
→ două iteraţii (poate prinde erori de iniţializare)
→ o valoare tipică intermediară
→ N-1 iteraţii
→ N iteraţii
→ se încearcă N+1 iteraţii (mai mult decât nr. maxim
presupus)
 Pentru minim nonzero: se încearcă min-1, min,
min+1 ...
Acoperire pentru cicluri multiple

1. număr minim de iteraţii exterioare

 testaţi complet ciclul interior (ca şi ciclu
independent)
2. continuă mergând în exterior pentru cicluri:
 cu ciclurile interioare la o valoare tipică şi variind
ciclul curent
3. În final, variază simultan toate ciclurile de la
min la max
Acoperirea prin mutaţii
 Se încearcă modificarea deciziilor / instrucţiunilor după anumite
tipare, pentru a se detecta dacă programul funcţionează diferit
 Exemple:
 < modificat în <= , etc.

 +1 modicat în -1 sau ignorat

 limite modificate cu 1

 a || b modificat în a, resp. b

(e relevant testul eliminat?); la fel pentru a && b

 Dacă vreo mutaţie nu e prinsă măcar de un test:
→ fie testele sunt insuficiente
→ fie programul e potenţial greşit (sau are cod irelevant)
Criterii de acoperire pentru date
 Criteriile de până acum: legate de fluxul de control al programului
 O alternativă: criterii legate de fluxul de date (data flow coverage)

 Noţiuni cheie:
 definirea unei variabile (def): un loc unde e atribuită

 utilizarea unei variabile (use): un loc unde e citită

(folosită într-o expresie, testată într-o condiţie)

 diverse criterii de acoperire, ex.: all-defs, all-uses

 def-use coverage: acoperire cu un caz de test pentru fiecare
pereche (fezabilă) de definire-utilizare
Cât de relevantă e acoperirea ?

 complexitatea ciclomatică a CFG-ului.

 Def. Într-un graf, complexitatea ciclomatică e
E - V + 2 (E = nr. de muchii, V = nr. de
noduri)
 măsură bună pt. complexitatea unui program
 dorim acoperire mai mare pt. fragmentele mai
complexe
METODE FORMALE DE TESTARE
Introducere
 Erorile şi sursele lor
 Ce sunt metodele formale?
 Tehnici şi aplicaţii
Obiectivele cursului
• Capacitatea de a verifica corectitudinea comportamentului
sistemelor dezvoltate
 Detectarea surselor şi tipurilor majore de eroare
 Folosirea metodelor formale ca o alternativă la simulare şi
testare
 Descrierea riguroasă a sistemelor
 Construirea de modele adecvate pentru sisteme
 Specificarea neambiguă a proprietăţilor dorite
 Evaluarea aplicabilităţii metodelor formale pentru un anumit
design
 Cunoaşterea şi folosirea unor instrumente de verificare
Cum se pot detecta erorile?
 Testare
+ direct asupra produsului → testele au relevanţă imediată
– erorile detectate târziu sunt costisitoare
– diagnoza necesită observabilitate completă
 Simulare
+ se poate începe din etapa de design
– simulatorul poate fi semnificativ mai lent decât sistemul real
– testarea şi simularea exhaustive sunt adesea imposibile

“Testarea programelor poate fi folosită pentru a demonstra prezenţa

erorilor, nu şi absenţa lor!” (E. W. Dijkstra, 1979)
Ce sunt metodele formale?
 “ ... Limbaje, tehnici şi instrumente bazate pe matematică
pentru specificarea şi verificarea sistemelor” [Clarke & Wing, 1996]
 Mai detaliat: “o mulţime de instrumente şi notaţii

– cu o semantică formală,
– folosite pentru specificarea neambiguă a cerinţelor unui sistem
– ce permit demonstrarea proprietăţilor acestei specificaţii
– şi demonstrarea corectitudinii unei implementări raportat la
specificaţia dată”

[Hinchey & Bowen, Applications of Formal Methods, 1995]

Ce pot garanta metodele formale?
• nu există garanţii absolute
• o metodă formală nu poate fi mai bună decât modelul şi
specificaţiile folosite
– modelul şi specificaţiile trebuie validate
Totuşi, metodele formale oferă:
• o metodă logic consistentă de raţionament
• acoperire exhaustivă, -adesea imposibil de obţinut prin alte
metode
• mecanizare şi automatizare → performanţă şi corectitudine

Pot completa cu succes simularea, testarea, etc.

Metode formale: necesitate şi
dificultăţi
 Utile în special în cazuri de:
– complexitate: tehnici de abstractizare / aproximare
– concurenţă: dificil de reprodus şi analizat altfel
– situaţii critice: avioane, bănci, medicină, securitate
 Dinamica erorilor în dezvoltarea software [John Rushby]
• 20-50 errors/kloc înainte de testare! 2-4 errors/kloc după!
• inspecţia formală a codului poate reduce erorile înainte de testare de 10 ori!
 Studiu de caz asupra unui cod de 10kloc, distribuit, în timp real:
• verificare şi validare: 52% cost (57% timp)
• din care, 27% cost în inspecţie, 73% în testare
• 21% datorită a 4 defecte neacoperite în testarea finală
(unul din faza de design)
• eliminarea erorilor în inspecţia detaliată a codului: de 160 de ori mai eficientă
decât în testare!
Cauzele şi costurile erorilor
 Erori în programe [NASA JPL (Voyager and Galileo
probes)]
• majoritatea: deficienţe în specificarea cerinţelor şi
interfeţelor
• o eroare în 3 pagini de cerinţe şi 21 de pagini de cod
• doar 1 din 3 erau erori de programare
• 2/3 din erorile funcţionale: omisiuni în specificarea
cerinţelor
• majoritatea erorilor de interfaţă: datorate proastei
comunicări
O vedere de ansamblu
• cele mai frecvente cauze ale erorilor:
Erori conceptuale, defecte simultane, interacţiuni
neprevăzute
– dezavantaje principale: aplicarea târzie a metodelor formale
– costul principal: înlăturarea târzie a erorilor
• Potenţialul maxim al metodelor formale:
– în verificarea şi modelarea de nivel înalt
– pentru sisteme complexe, concurente, distribuite, reactive,
în timp real, tolerante la defecte
Metode formale în ciclul de dezvoltare

• Analiza cerinţelor
– poate identifica contradicţii, ambiguităţi,omisiuni
• Design
– descompunerea în componente şi specificarea interfeţelor
– design prin rafinare succesivă
• Verificare
• Testare şi debugging
– generarea de cazuri de test pe bază de model
• Analiză
– model abstract, mai puţin complex decât sistemul real
Aplicaţii
 Verificarea formală pentru:
• Hardware
– Circuite combinaţionale
– Circuite secvenţiale
• Software (în general)
• Protocoale de comunicaţie
• Protocoale de securitate
• Sisteme în timp real
• Sisteme concurente şi distribuite
Abordări în verificare
Două categorii principale:
Verificarea modelului (model checking) (explorarea spaţiului stărilor)
– sistem reprezentat ca o maşină finită de stări
– specificare: accesibilitate (să nu fie atinsă nicio stare de eroare),
Sau mai complex (cu formule din logica temporală)
– foloseşte algoritmi de explorare exhaustivă a spaţiului stărilor
răspuns: “corect”— sau o secvenţă de execuţie drept
contraexemplu

Demonstrarea teoremelor
– model reprezentat logic, cu axiome şi reguli de deducţie
– aplicaţia/analiza domeniului reprezentată corespunzător (o teorie)
– demonstrare mecanică de teoreme: automată sau manuală
Tehnici

• Abstractizare: importantă, reduce

complexitatea verificării
• Construirea şi reducerea din mers a spaţiului
stărilor
• Reprezentarea simbolică a spaţiului stărilor
• Raţionament pe bază de presupuneri
(reducere la absurd)
Aplicaţii: design hardware
 Verificarea echivalenţei combinatoriale
– succes major, devenit standardul în toate instrumentele CAD
• Verificarea design-ului secvenţial
– companiile mari au grupe de cercetare dedicate (IBM, Intel, Motorola, Fujitsu,
Siemens, etc.)
– folosesc verificatori disponibili public sau propriile instrumente
• protocoale de coerenţă a cache-ului: Gigamax, IEEE Futurebus+
• Motorola 68020: modelat în demonstratorul de teoreme Boyer-Moore;
verificarea codului binar produs de compilatoare
• AAMP-5 (procesor folosit de avioane): modelat în demonstratorul de
teoreme PVS; verificarea microcodului pentru executarea instrucţiunilor
• modelarea/verificarea procesoarelor de tip DLX
Aplicaţii: Avioane

Lockheed C130J
– cod ADA cu adnotări, analizat în limbajul SPARK
– rezultat: software “corect prin construcţie”, cost redus
TCAS-II (Traffic Collision Avoidance System)
• obligatoriu pentru cursele comerciale din U.S.
• implementează alerta automatică, şi modifică traiectoria dacă se apropie
periculos de alt obiect
• specificaţie exprimată într-un limbaj formal (RSML)
• completitudinea şi consistenţa verificate
• rezultat: descrierile în lb engleză abandonate în favoarea specificaţiei
formale
Airbus A340
– Cousot (1993) a demonstrat absenţa completă a erorilor la rulare în soft-
ul de control al zborului, folosind un analizor static de programe →
Modelele formale ale sistemelor complexe sunt fezabile → pot fi analizate
de experţi ai domeniului aplicaţiei
Alte aplicaţii
• Telefonie. Specificarea şi analiza interacţiunilor între
diferite caracteristici ale telefonului
• Electronice de consum. Verificarea manuală şi apoi
automată a protocolului de control în componentele
audio Philips.
• Sisteme de control în motoare electronice.
• Protocoale de comunicaţie.
• Protocoale de securitate. Analiza cu logici speciale în
raţionamentul despre intruşi, mesaje criptate etc.
• Software de sistem. Verificarea driverelor
dispozitivelor.
Metode formale: Specificare
• Specificarea este necesară în orice metodă formală
• Necesită un limbaj cu sintaxa şi semantica definite
formal (matematic)
Un limbaj de specificare defineşte:
– un domeniu sintactic (notaţia formală)
– un domeniu semantic (universul obiectelor)
– o definiţie precisă a obiectelor ce satisfac
specificarea
Syntaxa şi semantica
Syntaxa
– un alfabet de simboluri (ex. propoziţii, operatori logici)
– reguli gramaticale de creare a formulelor bine -formate
Semantica
Domeniul semantic variază corespunzător limbajului:
– secvenţe de stări, de evenimente, structuri de sincronizare
(în limbajele de specificare a sistemelor concurente)
– funcţii input/output, relaţii, calcule, transformatori de predicate
(pt limbajele de programare)
Tipuri de specificaţii
• declarative (nu reprezintă neapărat o funcţie calculabilă)
• executabile (ex. limbaje de programare)
• comportamentale (orientate spre proprietăţi) (ex. funcţionalitate,
reactivitate)
– se descrie comportarea sistemului raportat la proprietăţile pe care
trebuie să le satisfacă

• structurale (ex. diagrame, ierarhii)

– se construieşte modelul sistemului folosind noţiuni matematice
precise (mulţimi, funcţii, logica predicatelor)

Uneori, acelaşi limbaj e folosit pentru specificaţie şi model

(implementare).
Proprietăţile specificaţiilor
• neambigue: are un înţeles bine definit (NU: limbaj
fără semantică formală, limbaj natural, scheme
grafice cu mai multe interpretări)
• consistente (non-contradictorii)
– există cel puţin un obiect ce satisface specificaţia
• poate fi incomplet
– poate fi nedeterminist sau să defere comportamentul
către implementare
Dacă limbajul are un sistem pentru inferenţa logică, se
pot demonstra proprietăţi plecând de la specificaţie
(înainte de a construi un model)
 Specificaţia: limbajul Z


– bazat pe logica de ordinul întâi şi teoria mulţimilor
 – funcţional, descriere declarativă

– folosit pentru proiecte industriale în U.K.

 o schemă (PhoneDB) (stări + tranziţii posibile), şi un invariant

 – operaţii ce modifică starea ( ) sau nu ( )
Modelare: automate cu stări finite
• Variante:
– etichete ale stărilor sau tranziţiilor
– tranziţii specificate ca funcţii sau relaţii
– augmentate sau nu cu variabile (date)
• Structuri Kripke:
= automat etichetat cu propoziţii atomice dintr-o mulţime AP:
M = (S, S0,R,L)
– S: mulţime finită de stări
– S0: mulţimea stărilor iniţiale
– R S × S: relaţia totală de tranziţie
– L : S → 2AP: funcţia de etichetare a stărilor
Noţiunea de corectitudine
• În general: sistemul satisface o proprietate (specificaţie)
• Comportamentul este corect funcţional
– sistemul este văzut ca implementând o funcţie de intrare-ieşire
– exemplu de formalism: triplete Hoare
{P} S {Q}
{precondiţie} program(sistem) {postcondiţie}

Exemplu de raţionament:
Noţiunea de corectitudine (cont.)
Comportament corect în timp
• pentru sisteme reactive: execuţie infinită conceptual
• comportament definit ca o reacţie la o secvenţă input
• specificarea: ex. logica temporală
• proprietăţi: absenţa blocajelor, reacţie în timp dat, etc.
Exemple:
– orice cerere să fie urmată de un răspuns în cel mult 5 secunde
– orice proces să obţină resursa de un număr infinit de ori
– pe orice traiectorie, se atinge la un moment dat o stare stabilă
Tehnici de verificare
Două abordări:

Explorarea spaţiului stărilor (model checking)

– specificare în logica temporală
– algoritmi de explorare exhaustivă a spaţiului stărilor verifică valoarea de
adevăr a formulei sau produc un contraexemplu – un exemplu de
execuţie

Demonstrarea de teoreme
– reprezentarea într-un sistem logic cu axiome şi reguli de deducţie
– domeniul analizat e de asemenea reprezentat ca reguli şi axiome (o
teorie)
– demonstrare de teoreme mecanizată: ghidată manual sau automat