Regression&Continuous Testing Tecniche,Metodologie e PrototipiAndrea Calabriacorso AAIS2005,prof C.GhezziPolitecnico di MilanoDipartimento Elettronica e InformazioneMilano,Italyandrea cala2@yahoo.itABSTRACTLe modifiche ai software possono inserire errori funzionali o strutturali,e tale problema interessa sia il livello di rilascio di nuove versione del software che quello di singola imple-mentazione delle unit`a.L’obiettivo del Regression Testing`e proprio quello di scoprire la presenza di tali errori,e in que-sto articolo esploreremo le modalit`a di approccio a questa tecnica.Per quanto riguarda il primo livello citato,verranno pre-sentate due metodologie,una che affronta il problema del-la selezione dei test da rieseguire,e dualmente anche quali scartare(con il prototipo DejaVOO),l’altra che si focaliz-za sull’analisi in ambiente di deployment,alfine di rilevare gli scostamenti di comportamento tra il software eseguito in house e quello infield,denominata Selective Capture and Replay Program Execution.Entrambe le tecniche riescono a mantenere le propriet`a di safety,efficienza e precisione. Per quanto interessa il livello di codifica,esiste una parti-colarizzazione del Regression Testing,chiamata Continuous Testing:lafilosofia di fondo`e simile,ma si associa alla fase di implementazione del ciclo di sviluppo software;di questa verr`a mostrato un plugin di Eclipse,e la sua progettazio-ne orientata all’efficienza,allaflessibilit`a e all’estensibilit`a, caratteristiche proprie dell’ambiente in cui si innesta. Categories and Subject DescriptorsD.2.5[Software Engineering]:Testing and Debugging—test regressivi e continuiGeneral TermsMethodologies,Techniques,Algorithms,Prototypes KeywordsTesting,Regression Testing,Continuous Testing,Selecti-ve Capture and Replay Program Execution,test selection, software evolution and manteinance 1.INTRODUZIONEChe il testing sia un momento importante per l’evoluzione di un software ormai`e consolidato,e non solo le software house che progettano e implementano l’applicazione hanno questa mentalit`a,ma anche le stesse aziende committen-ti sono entrate nell’ottica di stipulare contratti in funzione dei test e della loro pianificazione,proprio per la loro capa-cit`a ispettiva e di verifica sull’efficacia dello strumento che stanno acquistando.Il valore quindi del testing si materia-lizza in efficacia,lato acquirente come appena accennato, e efficienza,lato produttore,poich´e grazie ad esso si riesce a dedurre se le funzionalit`a sono state tutte correttamente implementate,o esistono errori.Proprio gli errori sono la preda del testing,sia quelli funzionali,commessi in proget-tazione,che strutturali,inseriti nell’implementazione;ma il testing deve verificare la presenza o l’assenza degli errori? Spesso,giustamente,si lega il termine testing soprattutto alla verifica della presenza degli errori,ma tale definizione non rende merito della prospettiva da cui si vede il testing. Infatti,seguendo il parallelo tra chi produce il software e chi lo commissiona,l’aspetto della presenza degli errori viene stimato e considerato soprattutto da chi progetta e imple-menta l’applicativo,poich´e`e necessario garantire la corret-tezza elaborativa,strutturale,proprio come l’indagine glass box esegue,grazie ad ispezioni di copertura su istruzioni,la-ti,percorsi,flusso dati,e altro ancora[1].Dal punto di vista di chi commissiona il lavoro invece,le esigenze cambiano, e il controllo sulla qualit`a del prodottofinale viene perse-guito sotto il profilo funzionale,ovvero si verifica se riesce a raggiungere gli obiettivi requisiti:ecco da dove nasce la crescente accortezza della dirigenza nello stendere i contrat-ti con gli sviluppatori software in base all’assenza di errori nell’applicazione,mirando alla verifica a scatola chiusa,co-munemente chiamata black box.Data l’attenzione da riporre sul testing,si coglie anche l’im-portanza di una stesura corretta e precisa dei test cases, e test suites,e si capisce perch´e spesso il codice dedicato ad implementare test sia molto voluminoso.Tale volumi-nosit`a,legata alla precisione ispettiva da garantire,richiede spesso molto tempo,tempo monopolizzato da questa fase poich´e sarebbe sciocco eseguirla in parallelo all’implemen-tazione(questo era il pensiero comune,ma come si vedr`a`e cambiato anch’esso!).Proprio sull’ottimizzazione di questo tempo si concentrer`a l’analisi che condurremo,e in parti-colare le problematiche che affronteremo saranno:“Se devo rilasciare una nuova versione di un’applicazione,come pos-so ottimizzare il tempo di testing recliclando le informazioniprecedentemente elaborate?”,e ancora“Come posso miglio-rare il testing nel mi ambiente di sviluppo cercando di capire il comportamento del software nel contesto d’usofinale?”,e infine“E’possibile parallelizzare il testing in qualche modo nella stessa fase di implementazione,evitando di tornare in-dietro sui propri passi troppo tempo dopo?”.Queste domande ci permettono di intuire che le fasi di svi-luppo software che analizzeremo,riprendendo il modello a cascata per esempio,sono due:quella di verifica e valida-zione entro cui si collocano le prime due,e quella di imple-mentazione,ambito della terza.Alle tre domande rispondono tre metodologie differenti,tut-te derivanti dallafilosofia del Regression Testing,tecnica che per definizione verifica la presenza di errori immessi modi-ficando il codice(regressivi appunto):la metodologia Deja-VOO seleziona una parte dei test applicati al software alfine di eseguirli anche sulla nuova release(quindi`e un test strut-turale sulla nuova versione),SCARPE(Selective Capture and Replay of Program Execution)ricerca i comportamenti diversi in ambienti differenti confrontando quello di svilup-po a quello“in campo”alfine di migliorare il testing in house(quindi`e pi`u un testing funzionale,basato sul com-portamento),infine il Continuous Testing`e una tecnica che supporta il singolo sviluppatore durante l’implementazione grazie alla quale riesce ad essere consapevole della presenza di errori introdotti codificando.La struttura dell’articolo ricalca la presentazione delle do-mande:inizialmente verr`a analizzato il Regression Testing in DejaVOO,tecnica ideata da Alessandro Orso,Nanjuan Shi e Mary Jean Harrold1,successivamente si affronter`a l’a-spetto del Selective Capture and Replay of Program Exe-cution,metodologia proposta da Alessandro Orso e Bryan Kennedy,per arrivare nella terza parte al Continuous Te-sting di David Saffe Michael D.Ernst2,e infine le conclusi 2.REGRESSION TESTINGSeguendo l’evoluzione di un software,il regression testing`e sfruttato sulle versioni modificate dell’applicativo per veri-ficare che le parti cambiate si comportino come progettato e non introducano errori inaspettati,comunemente definiti come regression errors.In uno scenario tipico,D`e lo svilup-patore(developer)del programma P per il quale viene stesa la test suite T.Durante la fase di manteinance,D modifica P aggiungendo nuove funzionalit`a ed eliminando i malfunzio-namenti riscontrati;a seguito di tale cambiamento la nuova release P’necessita di essere testata attraverso il regression testing.Una questione importante in tale ambito`e come selezionare un appropriato sott’insieme T’di T da eseguire su P’:tale problematica prende il nome di regression test selection,o abbreviato RTS.Naturalmente la soluzione banale e sem-plicistica`e quella di selezionare l’intera test suite,ma ci`o non ci porta a nessun vantaggio in termini di tempo e costo elaborativo,tanto che addirittura sarebbe uno sforzo inuti-le se i cambiamenti fossero solo marginali;quindi il nostro obiettivo`e cercare un sott’insieme proprio di T.1Docenti e ricercatori presso il dipartimento di Computer Science all’universit`a Georgia Institute of Technology,US. /2Docenti e ricercatori nel dipartimento di Computer Science dell’universit`a MIT,Massachusetts Institute of Technology, US./Una caratteristica particolare che la tecnica RTS deve avere `e la propriet`a di safety:essere safe per un’algoritmo RTS significa selezionare tutti i test case nella test suite che po-trebbero comportarsi in modo differente nelle varie versioni del software.L’importanza di tale propriet`a risiede proprio nella garanzia che la tecnica selezioni tutti i test cases che potrebbero essere rilevanti per P’.In generale le metodologie safe RTS in letteratura differisco-no per efficienza e precisione,caratteristiche che afferiscono al livello di granularit`a a cui si opera:se si lavora ad alti livello di astrazione,analizzando per esempio le informazio-ni di cambiamento e copertura per metodi e classi,si ha un grado di efficienza buono ma si penalizza la precisione sele-zionando pi`u test cases,anche non necessari3;al contrario se si opera a granularit`a pi`ufini,per esempio analizzando le informazioni sui cambiamenti e la copertura a livello di istruzione,si perde in efficienza a vantaggio della precisione selettiva.Si noti che in generale ogni safe RTS deve essere efficace nei costi,ovvero il costo(in termini di tempo e risor-se elaborative impegnate)totale di una RTS,comprensivo di selezione dei test cases e loro elaborazione,deve essere minore del costo di processamento dell’intera test suite,e quindi conveniente eseguire il regression testing.La tecnica che verr`a mostrata riesce ad allineare bene le caratteristiche sopra elencate,sia per efficienza e precisione, che per efficacia in termini di costo,e la dimostrazione di tali vantaggi verr`a descritta nel prototipo progettato,DejaVOO.La presentazione della tecnica proceder`a dall’analisi della metodologia,nei primi paragrafi,attraverso alcuni esem-pi teorici,per arrivare alla valutazione empiricafinale del prototipo.2.1Le fasi della metodologiaLa metodologia si suddivide in due fasi proprio per riusci-re a combinare efficienza e precisione,procedendo prima da un’analisi del sistema ad alto livello,e successivamente ad-dentrandosi in profondit`a:si guida la ricerca quindi inizial-mente in ampiezza,e poi in profondit`a all’interno del nuovo scenario.I due passi si chiamano partizione(partitioning)e selezione (selection):nella prima si analizza il programma cercando di identificare relazioni gerarchiche,di aggregazione e d’uso tra le classi e le interfacce,formando una selezione di que-st’ultime,nella seconda si prende il nuovo panorama appena creato e si aggiungono le informazioni sui cambiamenti tra P e P’,e si estrae il sott’insieme minimo di test cases necessari alla nuova versione.2.1.1La Partizione(partitioning)Nella fase di partizione si conduce un’analisi di alto livello del programma P e P’alfine di identificare le parti dell’ap-plicazione che potrebbero essere toccate dai cambiamenti 3Si considera qui il termine precisione come sinonimo di ef-ficace:per quanto possa sembrare inesatto,l’utilizzo del ter-mine efficace sarebbe improprio poich´e deve essere sempregarantito da tutte le tecniche il raggiungimento della con-dizione di safety,ovvero selezione di tutti i test cases utili, altrimenti non rientrerebbero nelle safe RTS,quindi l’effica-cia`e un prerequisito per ogni metodologia di tale gruppo; il livello di ottimizzazione dell’insieme T’,quindi la sua car-dinalit`a,rientra nella prerogativa di precisione;invece per sottolineare l’aspetto di ottimizzazione computazionale si`e usato l’aggettivo efficiente.effettuati.Per prima cosa`e bene individuare quale sia in generale la differenza tra i tipi di cambiamenti in un software.Le mo-difiche si differenziano in due categorie:le statement level e le declaration level.Un cambiamento statement level afferisce alla modifica,can-cellazione o aggiunta di un’istruzione;questo tipo di varia-zione`e facilmente rilevabile e gestibile dalla RTS poich´e ogni test che attraversa tale istruzione deve essere sicura-mente modifica a declaration level invece`e pi`u complessa da monitorare,poich´e riguarda le variazioni apportate ai tipi di una variabile,all’aggiunta o rimozio-ne di un metodo,alla sua ridefinizione,alle modifiche delle relazioni di ereditariet`a,ecc,tutte peculiariat`a tipiche dei linguaggi ad oggetti.Vediamo un esempio delle definizioni appena espresse nella Figura1;per aumentare la facilit`a di comprensione sar`a tenuto come modello d’esempio per tutta l’esposizione del regression testing tale esempio,in cui per lo stesso motivo sifissa anche la numerazione delle righe. Alla riga9si nota il cambiamento di tipo statement level; facilmente il comportamento differente di tale modifica verr`a individuato tra P e P’proprio perch´e`e locale.Alla riga12 invece,suddivisa per semplicit`a in12a:d,si vede l’aggiunta di un metodo alla classe A in P’:in questo caso il cambia-mento intacca anche l’invocazione dell’istruzione a.foo() alla linea17.Infatti supponendo che LibClass sia una clas-se nella libreria,e che LibClass.geAnyA()sia un metodo statico tale che restituisce un’istanza tra SuperA,A,o SubA, dopo la chiamata alla linea16,il tipo dinamico di a potr`a es-sere SuperA,A,o SubA,e perci`o a causa del binding dinamico la chiamata a.foo()potr`a essere associata a diversi metodi nei due programmi P e P’:in P l’associazione di a.foo() `e sempre verso SuperA.foo,mentre in P’a.foo()varia tra SuperA,A,o SubA a seconda del tipo dinamico di a.Ta-le caratteristica dei cambiamenti declaration level potrebbe essere trascurata da nell’esecuzione di alcuni test,ma non nessuna tecnica RTS deve essere miope tanto da non consi-derare queste situazioni cos`ıtipiche nei linguaggi ad oggetti, altrimenti rischierebbe di rivelarsi unsafe e imprecisa.La fase della partizione si articola nella(1)creazione di un grafo statico delle classi e interfacce(i cui nodi sono quest’ul-time,e gli archi le relazioni tra esse),poi nella(2)selezione dei nodi del grafo in cui si riscontrano cambiamenti,anche in base alle relazioni gerarchiche,di aggregazione e d’uso tra classi e interfacce.Il primo passaggio`e quello di creare un grafo generale del programma chiamato Interclass Relation Graph(IRG),iden-tificando con i nodi le classi e le interfacce,e con gli archi le relazioni gerarchiche,di aggregazione e d’uso.Il grafo IRG di un programma`e una tripletta{N,IE,UE},ove •N`e l’insieme dei nodi,ovvero classi e interfacce;•IE⊂N×N`e l’insieme degli archi di ereditariet`a(inhe-ritance edges,in cui il verso della freccia(per esempio da e1ad e2)indica che e1`e direttamente sottotipo di e2;•UE⊂N×N`e l’insieme degli archi di uso(usage edges),in cui il verso della freccia(per esempio da e3 ad e2)indica che e3contiene un riferimento esplicito ad e2;Lasciando in appendice i dettagli dell’algoritmo di costru-zione del grafo IRG,mostriamo il suo output generato nella Figura2,che si riferisce all’esempio della Figura1.Dopola Figure2:Fase partizione,Grafo IRG del codice diP della Figura1nella pagina seguentecreazione del grafo IRG,si devono selezionare i nodi affetti da cambiamenti:nell’algoritmo,visibile sempre nell’appen-dice,gli ingressi sono proprio il grafo IRG appena creato sia per P che per P’,e i cambiamenti al programma,C;in usci-ta si ottiene la partizione desiderata delle classi e interfacce toccate dai cambiamenti.Un’importante considerazione deve essere fatta sulla com-plessit`a di tali algoritmi,poich´e come accennato in prece-denza deve convenire eseguire tale tecnica di RTS piuttosto che ripetere tutti i test della suite:l’algoritmo buildIRG esegue un singolo passaggio per ogni classe e iterfaccia,per identificare sopra e sotto-tipi e loro riferimenti.Nel caso pessimo la complessit`a`e O(m),dove m`e la dimensione del programma,quindi lineare,valore molto buono.2.1.2La Selezione(selection)La seconda fase della metodologia si occupa della selezione dei test in base alle informazioni acquisite dalla partizione. Come primo passo analizza le classi e le interfacce selezionate e successivamente esegue la selezione.Per quanto riguarda il primo passo,si costruisce un grafo che rappresenta l’insieme partizionato,ma ideato secondo una logica orientata ai linguaggi di programmazione,tanto da chiamarsi Java Interclass Graph,JIG:esso estende il classico IRG poich´e riesce a rappresentare anche gli aspetti propri degli oggetti,come il binding dinamico,la gestione delle eccezioni,ecc.Un esempio di tale grafo viene presentato nelle Figure3e4,che rappresentano una parte del codice d’esempio della Figura1.Nel grafo JIG ogni punto di chiamata,per esempio nelle ri-ghe16e17,`e espansa in un nodo call e uno return(16a, 16b,17a,17b)collegati da archi denominati path-edge,che mostrano il cammino delle chiamate.Per individuare le in-vocazioni ai metodi chiamati si stendono gli archi call-edge, il cui comportamento si differenzia tra le tipologie di chia-mate:non virtuali o statiche,e differenza risiede nel numero di archi che la chiamata genera:per il tipo sta-tico vi sar`a un solo arco uscente dal nodo call,mentre per il tipo dinamico o virtuale dipende dal binding dinamico,e quindi possono essere e si intuisce,`e pro-prio questa la caratteristica primaria del grafico JIG,cheFigure1:Esempio di codice nel Programma P e sua modifica inP’Figure3:Fase Selezione,Grafo JIG per il programma P in Figura1permette di individuare le modifiche anche al binding e al-tri elementi tipici di un linguaggio ad oggetti.Nellefigure presentate si pone l’accento proprio su questo:a seguito del cambiamento infatti,nella Figura3,si osserva che il binding dinamico cambia perch´e`e stato ridefinito il metodo foo() nella classe A.Una volta estratte tutte le classi e le interfacce che sono af-fette dalle modifiche,si procede con il secondo passo della selezione:si esegue una procedura che elabora una matrice di copertura dei test,alfine di selezionare proprio i testche Figure4:Fase Selezione,Grafo JIG per il programma P’in Figura1coinvolgono solo il sott’insieme selezionato.Per far ci`o si co-struisce una tabella in cui le righe sono rappresentate dagli archi edges,proprio perch´e rappresentano ilflusso di esecu-zione del programma,mentre le colonne dai test cases.Una volta travati i test che attraversano le classi e interfacce par-tizionate,termina anche la seconda fase della metodologia, evidenziando i test da rieseguire.2.2Valutazione empirica:DejaVOOLa metodolgia esposta `e stata implementata in un prototipo chiamato DejaVOO ,il cui obiettivo era proprio la sperimen-tazione della fattibilit`a e correttezza di essa.Nella Figura 5viene presentata la struttura del prototipo,che comprende tre moduli principali:InsECT ,DEI ,e Selector.Figure 5:L’archittettura di DejaVOOInsECT (instrumentation,execution and coverage tool)ser-ve per processare e creare la matrice di copertura dei test.DEI (dangerous edge identifier )rappresenta le due fasi,par-tizione e selezione,della metodologia:infatti ha come obiet-tivo quello di costruire i grafiIRG del programma origina-rio e della sua versione modificata,nel modulo Partitioner ,mentre nel Comparator si occupa di creare e analizzare i grafiJIG,permettendo di ricavare i punti pericolosi del pro-gramma.Infine Selector esegue il calcolo finale,unendo le informazio-ni della matrice di copertura dei test cases,con quelle delle istruzioni pericolose,producendo la selezione dei test T .Gli autori hanno sperimentato il prototipo con soddisfacen-ti risultati,i cui dati empirici omettiamo lasciando libero approfondimento nei reference riportati in bibliografia.2.3CommentiLa tecnica mostrata `e interessante perch´e riesce a ridurre il tempo di ri-testaggio di una applicazione,ma naturalmente ha una soglia di convenienza d’uso,rappresentata dai tem-pi:solo se la somma dei tempi di elaborazione dei modu-li visionati in DejaVOO (partizione e selezione)`e inferiore al tempo di riesecuzione dell’intera test suite allora `e con-veniente sfruttare tale tecnica,altrimenti si rischierebbe di contravvenire agli obiettivi proposti di ottimizzazione delle risorse e del tempo.Infine si evidenzia un piccolo difetto intrinseco nella meto-dologia:un’assunzione per la condizione di safety `e quella di avere l’ambiente di esecuzione invariato tra le due versio-ni software,e gli autori seguono tale precondizione ponendo come ipotesi che la JVM usata non cambi tra le release e non ci siano variazioni nelle librerie.Si coglie che tali con-dizioni possono rappresentare dei limiti nel caso in cui si sia ristrutturato anche con nuove caratteristiche di architettura il software,non solo nelle funzionalit`a .Solo in presenza di cambiamenti locali all’ambiente,per esempio a poche libre-rie,ecc,potrebbe essere inconsistente l’uso della metodolo-gia proposta.Si deduce che nelle situazioni in cui si ripla-sma un nuovo applicativo non solo questa tecnica `e difficile da usare,ma in generale il regression testing potrebbe non avere senso,poich´e si dovrebbero anche riscrivere test sui-te dedicate:daltronde cambiare radicalmente l’architetturadell’applicazione esige una riprogettazione,e quindi anche un redesign delle test suite.3.SELECTIVE CAPTURE AND REPLAY OF PROGRAM EXECUTIONIn questa sezione si presenter`a una tecnica di regression te-sting che permette di migliorare il testing in sede di svilup-po attraverso lo studio empirico in campo dei metodologia in realt`a non `e di per s´e una tecnica di te-sting regressivo come l’abbiamo considerata nella sezione 2,ma piuttosto una modalit`a di supporto al regression testing tramite la creazione di stub e drivers per gli oracoli,come andremo a chiarire nel seguito.Tutto nasce dall’osservazione che un programma eseguito in sede di sviluppo (in house )ha un comportamento in qualche misura diverso da quello nell’ambiente d’uso finale (in field );l’obiettivo della metodologia `e quello di catturare queste dif-ferenze per poi saperle identificare al fine di creare una test suite che tenga conto anche di tali problematiche pragmati-che e si evince dal contesto e dagli obiettivi,sia il regression testing che l’analisi d’impatto beneficiano fortemente di tali soluzioni.Dato un programma rilasciato (quindi dopo la fase di de-ployment),la maggior parte delle metodologie suggeriscono di catturare l’intera esecuzione nell’ambiente d’uso,per poi replicarla,e ricavarne le informazioni preziose,per esempio tramite data-mining.Ma dietro a tali ambizioni teoriche ci sono delle difficolt`a oggettive da affrontare,a cui la tecnica in esame tenta di dare valida risposta:•la cattura dell’intera esecuzione `e generalmente un pro-blema infattibile poich´e richiede di memorizzare un vo-lume di dati troppo elevato,per non parlare della com-plessit`a di raccolta in s´e a causa della forte relazione con l’ambiente di collocazione;•i dati prelevati possono contenere informazioni riser-vate,legate alla privacy;•bisogna prevenire o evitare (a seconda della politica in uso)i side effects,per esempio assicurandosi che in fase di replicazione dell’esecuzione non si presentino effetti indesiderati come disturbi che compromettono la stabilit`a del sistema.Per indirizzare tali questioni Orso e Kennedy propongono di selezionare un sott’insieme del programma per cui cattura-re l’esecuzione a runtime,coinvolgendo tutte le interazioni tra tale sott’insieme e il resto dell’applicazione,e replicare le interazioni registrate nel sottosistema isolato;ecco quin-di il significato del nome Selective Capture and Replay of Program metodologia identifica due fasi:(1)la cattura selettiva dell’esecuzione a runtime,e (2)la repli-cazione,al termine delle quali si ottengono le informazioni utili per migliorare le test suite,a beneficio del regression testing.Le problematiche prima estratte vengono cos`ılimate:in-fatti il volume di dati diminuisce sensibilmente,riducendosi alle informazioni necessarie e garantendo efficienza ma sen-za risultare parziale poich´e come vedremo si utilizzano le informazioni di scambio tra i due insiemi complementari del sistema (quello selezionato e il restante).Per quanto ri-guarda la privacy la metodologia semplicemente esclude dalsott’insieme in osservazione tutte le parti che possono con-tenere informazioni riservate,ma se ci`o non fosse possibile si prevede la possibilit`a della replicazione nella stessa mac-china dell’utente.Infine sull’argomento dei side effects la tecnica li evita poich´e la fase della replicazione avviene in maniera isolata,ovvero si simulano le interazione del sotto-sistema con il resto dell’applicazione e dell’ambiente tramite stub e drivers.Proprio questo`e il beneficio indotto al re-gression testing:avendo a disposizione i meccanismi degli oracoli,con stub e drivers,`e possibile non solo creare ma anche eseguire test cases con la simulazione.3.1La metodologiaPrima di dettagliare le fasi della metodologia bisogna pre-sentare alcune osservazioni:data l’importanza che assume in questa tecnica l’ambiente d’esecuzione,non sarebbe corret-to n´e consistente creare una metodologia adatta per tutti i linguaggi di programmazione;per questo motivo viene pre-sentata la tecnica specificatamente per il linguaggio Java, allineandoci con la metodologia DejaVOO,e con il conti-nuous testing che verr`a in seguito proposto.E’bene anche accennare alla terminologia che verr`a usata:il sott’insieme d’interesse dell’applicazione,oggetto della cat-tura selettiva,viene identificato come insieme osservato,le cui classi si chiamano classi osservate;parallelamente si no-minano intuitivamente metodi osservati e campi osservati i metodi e i campi delle classi osservate.Dualmente si agget-tivano come inosservati gli stessi elementi(insieme,classi, metodi,campi)esclusi dall’osservazione.Nella fase di cattura,come la Figura6mostra,prima che l’applicazione inizi,in base ad una lista di classi definite dal-l’utente,si identificano i confini dell’insieme osservato e si applicano delle modifiche al codice per riuscire a catturare le interazioni tra esso e il resto del sistema:tali modifiche vengono chiamate sonde(probes)4.Da questa caratteristi-ca si intuisce che la tecnica`e invasiva,e non si limita ad osservare il comportamento ma attua variazioni per poterlo monitorare:infatti le sonde hanno proprio lo scopo di gene-rare eventi dalle interazioni tra le classi osservate e il codice esterno,che costituiscono con i loro attributi il log di eventi (event log).Nella successiva fase di replicazione si creano scaffolding che ricevono in ingresso l’event log generato in cattura,come visibile in Figura6,e replicano ogni evento registrato ap-poggiandosi ai driver e stub.Nel seguito verranno dati accenni alle due fasi,lasciando li-bero approfondimento sull’argomento tramite la bibliografia consigliata.3.1.1La cattura selettivaNella fase della cattura selettiva si identificano tre passi:(1) identificazione di tutte le interazioni tra codice osservato e inosservato,(2)l’iniezione nel codice delle sonde,(3)la cat-tura efficiente delle interazioni a runtime.Prima di addentrarci nei dettagli,`e bene introdurre il con-cetto di object id:un object id`e un numero positivo che identifica univocamente un’istanza di classe.Per generare 4Per quanto nel corso di tutta la trattazione della metodo-logia venga spesso menzionato l’uso di sonde,non viene de-finito come esse siano,ma solo i loro obiettivi,penalizzando cos`ıla comprensione approfondita dellatecnica.Figure6:La fase della cattura selettiva(parte superiore)e della replicazione(parte inferiore)tale numero,la tecnica sfrutta un global id che viene ini-zializzato a zero nonappena parte la cattura.Nelle classi modificabili l’object id`e creato aggiungendo un campo nu-merico alla classe,e una sonda al suo costruttore:la sonda incrementa il global id e immagazzina il valore nel campo numerico dell’oggetto che sar`a creato.Da ci`o,una volta creata un’istanza di una classe modificabile,la metodologia riesce a recuperare il suo object id semplicemente accedendo al campo numerico creato.Per le classi non modificabili,si associa l’id alle istanze usando la reference map,che man-tiene le informazioni su come mapparare ogni object id all’i-stanza e viene popolata incrementalmente:ogni volta che si deve assegnare un id ad una classe non modificabile si con-trolla nella reference map se esiste gi`a una registrazione per quel valore,e in caso affermativo si incrementa il global id per prelevarne il numero generato,altrimenti si associa quel-lo attuale del global id.Per ottimizzare la fase della cattura selettiva,ovviando al problema del volume di dati da immagazzinare,gli autori propongono di(1)comprendere nell’insieme d’osservazione solo quegli oggetti che intaccano la computazione,e successi-vamente di(2)raccogliere le informazioni a runtime solo on demand,incrementalmente,ovvero quando e se si necessita, senza usare strumenti complessi di analisi statica(si noti la differenza con DejaVOO in cui esiste un’analisi statica pre-liminare costituita della creazione del grafo IRG nella fase di partizione).Il primo punto significa che se avessimo un grafo da controllare di duecento nodi,e il valore da cattu-rare risiedesse nel quinto,non sarebbe necessario registrare le informazioni di tutti i nodi,ma sono sufficienti i primi cinque.Per quanto riguarda il secondo punto,in generale non`e sempre possibile prevedere in anticipo quale sia il sot-t’insieme di informazioni passate ad un metodo rilevante per una chiamata,e quindi la soluzione`e quella di raccogliere tali informazioni in itinere,al momento d’uso.Nel caso di eventi che attraversano i confini dell’insieme osservato(per esempio parametri ed eccezioni),la scelta`e quella di regi-strare i valori attuali dei dati solo per quelli in forma scalare; per gli oggetti si registra il loro object id e il tipo.Sotto tali。
