La verificació en temps d'execució és un enfocament d'anàlisi i execució del sistema informàtic basat en extreure informació d'un sistema en execució i utilitzar-la per detectar i possiblement reaccionar davant de comportaments observats que satisfan o infringeixen determinades propietats. Algunes propietats molt particulars, com ara la cursa de dades i la llibertat de bloqueig, normalment es volen satisfer tots els sistemes i es poden implementar millor algorítmicament. Altres propietats es poden capturar més convenientment com a especificacions formals. Les especificacions de verificació en temps d'execució s'expressen normalment en formalismes de predicats de traça, com ara màquines d'estats finits, expressions regulars, patrons sense context, lògiques temporals lineals, etc., o extensions d'aquestes. Això permet un enfocament menys ad-hoc que les proves normals. Tanmateix, qualsevol mecanisme per supervisar un sistema en execució es considera verificació en temps d'execució, inclosa la verificació amb oracles de prova i implementacions de referència. Quan es proporcionen especificacions de requisits formals, els monitors se sintetitzen a partir d'ells i s'infonen dins del sistema mitjançant instrumentació. La verificació en temps d'execució es pot utilitzar per a molts propòsits, com ara el seguiment de polítiques de seguretat o seguretat, depuració, proves, verificació, validació, perfils, protecció d'errors, modificació del comportament (per exemple, recuperació), etc. La verificació en temps d'execució evita la complexitat de les tècniques tradicionals de verificació formal, com ara la verificació de models i la demostració de teoremes, analitzant només un o uns quants rastres d'execució reals i, per tant, augmentar la seguretat real del sistema i, per tant, augmentar de manera relativa més la confiança del sistema. en els resultats de l'anàlisi (perquè evita el pas tediós i propens a errors de modelar formalment el sistema), a costa d'una menor cobertura. A més, gràcies a les seves capacitats reflexives, la verificació del temps d'execució es pot convertir en part integral del sistema objectiu, supervisant i guiant la seva execució durant el desplegament.
Història i context Comprovar les propietats especificades formalment o informalment amb sistemes o programes en execució és un tema antic (exemples notables són el sistema de tipus al programari, o els dispositius de seguretat o temporitzadors de control al maquinari), les arrels precises dels quals són difícils d'identificar. La verificació del temps d'execució de terminologia es va introduir formalment com el nom d'un taller de 2001 destinat a abordar problemes a la frontera entre la verificació formal i les proves. Per a bases de codi grans, l'escriptura manual de casos de prova resulta que requereix molt de temps. A més, no es poden detectar tots els errors durant el desenvolupament. Klaus Havelund i Grigore Rosu van fer les primeres contribucions a la verificació automatitzada al Centre de Recerca Ames de la NASA per arxivar estàndards de seguretat elevats en naus espacials, rovers i tecnologia aviònica. Van proposar una eina per verificar les especificacions en lògica temporal i per detectar condicions de carrera i bloquejos en programes Java mitjançant l'anàlisi de camins d'execució únics.
Actualment, les tècniques de verificació del temps d'execució sovint es presenten amb diversos noms alternatius, com ara monitorització del temps d'execució, comprovació del temps d'execució, reflex del temps d'execució, anàlisi del temps d'execució, anàlisi dinàmica, anàlisi simbòlica/dinàmica del temps d'execució, anàlisi de traça, anàlisi de fitxers de registre, etc. La verificació en temps d'execució està íntimament relacionada amb altres àrees ben establertes, com ara les proves (especialment les proves basades en models) quan s'utilitzen abans del desplegament i els sistemes tolerants a errors quan s'utilitzen durant el desplegament.
Dins de l'àmplia àrea de verificació en temps d'execució, es poden distingir diverses categories, com ara:
Monitorització "sense especificacions" que s'orienta a un conjunt fix de propietats relacionades principalment amb la concurrència, com ara l'atomicitat. El treball pioner en aquesta àrea és de Savage et al. amb l'algoritme Eraser monitorització respecte a les especificacions de la lògica temporal; Les primeres contribucions en aquesta direcció han estat fetes per Lee, Kannan i els seus col·laboradors, i Havelund i Rosu.
Enfocaments bàsics miniatura|298x298px|Visió general del procés de verificació basat en el monitor tal com el descriuen Falcone, Havelund i Reger a A Tutorial on Runtime Verification L'ampli camp dels mètodes de verificació en temps d'execució es pot classificar per tres dimensions:
El sistema es pot controlar durant la pròpia execució (en línia) o després de l'execució, per exemple, en forma d'anàlisi de registre (fora de línia). El codi de verificació s'integra al sistema (com es fa a la Programació orientada a aspectes) o es proporciona com a entitat externa. El monitor pot informar d'una violació o validació de l'especificació desitjada.
No obstant això, el procés bàsic de la verificació en temps d'execució segueix sent similar:
Un monitor es crea a partir d'alguna especificació formal. Aquest procés normalment es pot fer automàticament si hi ha autòmats equivalents per a les fórmules del llenguatge formal en què s'especifica la propietat. Per transformar una expressió regular, es pot utilitzar una màquina d'estats finits; una propietat en la lògica temporal lineal es pot transformar en un autòmat Büchi (vegeu també Lògica temporal lineal a l'autòmat Büchi). El sistema està equipat per enviar esdeveniments relacionats amb el seu estat d'execució al monitor. El sistema s'executa i és verificat pel monitor. El monitor verifica el rastre d'esdeveniment rebut i produeix un veredicte si es compleix l'especificació. A més, el monitor envia retroalimentació al sistema per corregir possiblement un comportament fals. Quan s'utilitza la supervisió fora de línia, el sistema de causa no pot rebre cap comentari, ja que la verificació es fa més tard.
Exemples Els exemples següents discuteixen algunes propietats senzilles que han estat considerades, possiblement amb petites variacions, per diversos grups de verificació en temps d'execució en el moment d'escriure aquest article (abril de 2011). Per fer-los més interessants, cada propietat següent utilitza un formalisme d'especificació diferent i totes són paramètriques. Les propietats paramètriques són propietats sobre traces formades amb esdeveniments paramètrics, que són esdeveniments que uneixen dades amb paràmetres. Aquí una propietat paramètrica té la forma , on és una especificació en algun formalisme adequat que fa referència a esdeveniments paramètrics genèrics (no instanciats). La intuïció d'aquestes propietats paramètriques és que la propietat expressada per s'ha de mantenir per a totes les instàncies de paràmetres trobades (mitjançant esdeveniments paramètrics) a la traça observada. Cap dels exemples següents és específic per a cap sistema de verificació en temps d'execució en particular, tot i que òbviament es necessita suport per als paràmetres. En els exemples següents s'assumeix la sintaxi de Java, per tant "==" és la igualtat lògica, mentre que "=" és l'assignació. Alguns mètodes (per exemple, update() a UnsafeEnumExample) són mètodes simulats, que no formen part de l'API de Java, que s'utilitzen per a la claredat.
HasNext miniatura|350x350px|La propietat HasNext La interfície Java Iterator requereix que el mètode hasNext() sigui cridat i retorni true abans de cridar el mètode next(). Si això no passa, és molt possible que un usuari iteri "al final de" una col·lecció. La figura de la dreta mostra una màquina d'estats finits que defineix un possible monitor per comprovar i fer complir aquesta propietat amb la verificació en temps d'execució. Des de l'estat desconegut, sempre és un error cridar el mètode next() perquè aquesta operació podria ser insegura. Si es crida hasNext() i retorna true, és segur cridar next(), de manera que el monitor entra en l'estat més. Tanmateix, si el mètode hasNext() retorna false, no hi ha més elements i el monitor entra a l'estat none. En els estats more i none, cridar al mètode hasNext() no proporciona informació nova. És segur cridar el mètode next() des de l'estat més, però es desconeix si existeixen més elements, de manera que el monitor torna a entrar a l'estat desconegut inicial. Finalment, cridar el mètode next() des de l'estat no té com a resultat l'entrada a l'estat d'error. El que segueix és una representació d'aquesta propietat utilitzant la lògica temporal lineal paramètrica del temps passat.
Aquesta fórmula diu que qualsevol trucada al mètode next() ha d'anar immediatament precedida per una crida al mètode hasNext() que retorni true. La propietat aquí és paramètrica a l'Iterador i. Conceptualment, això significa que hi haurà una còpia del monitor per a cada possible iterador en un programa de prova, encara que els sistemes de verificació en temps d'execució no necessiten implementar els seus monitors paramètrics d'aquesta manera. El monitor d'aquesta propietat es configuraria per activar un controlador quan es viola la fórmula (equivalentment quan la màquina d'estats finits entra a l'estat d'error ), cosa que es produirà quan es crida next() sense cridar primer hasNext(), o quan hasNext() es crida abans de next(), però es retorna false.
UnsafeEnum miniatura|350x350px|Codi que infringeix la propietat UnsafeEnum La classe Vector a Java té dos mitjans per iterar sobre els seus elements. Es pot utilitzar la interfície Iterator, com es veu a l'exemple anterior, o es pot utilitzar la interfície Enumeració. A més de l'addició d'un mètode d'eliminació per a la interfície de l'Iterator, la diferència principal és que l'Iterador "falla ràpidament" mentre que l'enumeració no. Això vol dir que si es modifica el Vector (que no sigui utilitzant el mètode d'eliminació de l'Iterador) quan s'està iterant sobre el Vector mitjançant un Iterador, es llança una ExcepcióModificació Concurrent. Tanmateix, quan s'utilitza una enumeració, aquest no és un cas, com s'ha esmentat. Això pot donar lloc a resultats no deterministes d'un programa perquè el Vector es deixa en un estat inconsistent des de la perspectiva de l'enumeració. Per als programes heretats que encara utilitzen la interfície d'enumeració, és possible que vulgueu fer complir que les enumeracions no s'utilitzen quan es modifica el seu vector subjacent. El següent patró regular paramètric es pot utilitzar per aplicar aquest comportament:
∀ Vector v, Enumeració e : ( e = v.elements()) ( e.nextElement()) * v.update() e.nextElement()
Aquest patró és paramètric tant en l'enumeració com en el vector. Intuïtivament, i com els sistemes de verificació en temps d'execució anteriors no necessiten implementar els seus monitors paramètrics d'aquesta manera, es pot pensar que el monitor paramètric d'aquesta propietat crea i fa un seguiment d'una instància de monitor no paramètric per a cada possible parell de Vector i Enumeració. Alguns esdeveniments poden afectar diversos monitors al mateix temps, com ara v.update(), de manera que el sistema de verificació del temps d'execució els ha d'enviar (de nou conceptualment) a tots els monitors interessats. Aquí s'especifica la propietat perquè indiqui els mals comportaments del programa. Aquesta propietat, doncs, s'ha de controlar per a la coincidència del patró. La figura de la dreta mostra el codi Java que coincideix amb aquest patró, violant així la propietat. El Vector, v, s'actualitza després de crear l'enumeració, e, i després s'utilitza e.
SafeLock