Analisi empirica dei meccanismi di log in sistemi open-source

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Analisi empirica dei meccanismi di log in sistemi open-source"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Analisi empirica dei meccanismi di log in sistemi open-source Anno Accademico 21/211 Relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Antonio Pecchia candidato Imperatrice Assunta 534/1657

2 Taluni nascono grandi. Altri alla grandezza giungono per gradi. (W. Shakespeare)

3 Indice Introduzione 5 Capitolo 1. Log Analysis I logs Il meccanismo di logging Il formato dei logs Contributo e problematiche della Log Analysis Obiettivo della tesi 15 Capitolo 2. Progettazione ed implementazione di un tool per il parsing delle chiamate alle funzioni di log Il tool di parsing Scopo del tool Modalità operative Problematiche e soluzioni proposte Considerazioni per la fase di progettazione Validazione dei risultati prodotti 22 Capitolo 3. Descrizione e catalogazione dei sistemi open-source Apache HTTP Web Server Data Distribution Service Cardamom Object Web Corba TAO Minix MySQL RTEMS Criteri di catalogazione dei sistemi 37 Capitolo 4. Analisi sperimentale Confronto del meccanismo di logging tra alcune release di uno stesso software Confronto del logging tra alcune release di Apache Confronto del logging tra alcune release del DDS Confronto del meccanismo di logging tra differenti classi di sistemi 46 III

4 4.2.1 Confronto del logging tra sistemi di vari domini applicativi Confronto del logging tra sistemi con diverse architetture a livello di S.O Confronto del logging tra sistemi scritti in differenti linguaggi di programmazione Confronto del logging tra differenti tipologie di sistema: centralizzato e distribuito 64 Conclusioni e sviluppi futuri 7 Bibliografia 71 IV

5 Introduzione Con l'evoluzione dei sistemi di elaborazione sempre più settori (militari, finanziari, industriali, ecc.) affidano a sistemi automatici il controllo di delicate operazioni. Tale evoluzione ha portato la nascita di calcolatori sempre più funzionali e performanti ma non necessariamente più affidabili o esenti da clamorosi fallimenti. Ogni malfunzionamento può provocare danni più o meno gravi : per esempio, un errore di sviluppo nel campo della telefonia potrebbe comportare problemi di connessione, di ricezione mentre conseguenze più disastrose potrebbero verificarsi in scenari cosiddetti critici per i quali un fallimento nell'assolvere una o più funzioni ad essi richiesti comportano conseguenze di notevole gravità in termini di perdite economiche e/o danni a persone e/o ambiente : si pensi ad un errore in sistemi di controllo di traffico aereo. I fallimenti dei sistema possono essere legati a problemi hardware, generando errori solitamente transitori e facilmente individuabili, e/o a errori nel software, tipicamene più comuni. Questi ultimi sono legati a difetti presenti nella parte software del sistema, noti con il termine Software Faults. La loro usualità è legata alla crescita continua della complessità dei sistemi moderni : oggigiorno i Software Faults sono una delle principali cause di fallimento delle applicazioni. L ipotesi attuale è che non possono essere realizzati software privi di bugs. Ciononostante, soprattutto negli scenari critici, è necessario avere un alto grado di affidabilità del comportamento del sistema. Per questo motivo, sia durante la sua fase di 5

6 sviluppo hardware e software che dopo il suo rilascio, è essenziale che esso venga continuamente osservato ed esaminato. Tuttavia un sistema che funziona correttamente può contenere faults non attivi, detti dormienti. Una delle metodologie più diffuse per la correzione del sistema dai Sosftware Faults è il logging: un insieme di istruzioni per il rilevamento degli errori che si presentano all interfaccia del sistema quando uno o più Software Faults dormienti sono attivati dai fault trigger 1. Attraverso delle semplici chiamate a funzioni di una libreria specifica, inserite in punti specifici del codice sorgente, esse permettono di raccogliere le informazioni relative all evento in appositi file log. La Log Analysis consente di ricostruire la catena di propagazione del guasto (faulterror-failure). Tuttavia, come vedremo in seguito, questo pattern presenta un importante limite : si dimostra che un numero significativo di Software Faults provocano il failure del sistema senza la produzione di alcun event log. Lo scopo di questo elaborato è quello di fornire, mediante un analisi sperimentale di sistemi software, le informazioni necessarie per comprendere l evoluzione del meccanismo di logging tra varie release di uno stesso software e tra diverse tipologie di sistemi : quali costrutti sono stati preferiti ad altri, come è variata la quantità di chiamate ai logs, etc. Tali dati sono interessanti al fine di intuire le eventuali cause della scarsa copertura del meccanismo. Il lavoro è organizzato come segue : Nel capitolo 1 sono introdotti i concetti necessari alla comprensione della log analysis : definizione di log, meccanismi per la detection e collection dei dati, obiettivi e limitazioni della metodologia; Nel capitolo 2 viene illustrato nel dettaglio lo scopo di questa tesi e le tecniche di realizzazione adottate: chiarimenti sulla fase di analisi e progettazione del tool usato per il parsing delle chiamate alle funzioni di logs e sull indagine sperimentale delle 1 I fault trigger sono delle particolari condizioni di attivazione dei fault, quali un particolare stato del sistema, una determinata sequenza di input. Non sono semplici da evidenziare solo con il testing 6

7 strutture usate per la detection. È riportato un esempio a scopo dimostrativo; Nel capitolo 3 è fornita una breve discussione dei sistemi software open-source selezionati per lo studio. Al fine di realizzare dei confronti e delle statistiche significative i software sono stati scelti in modo da coprire differenti caratteristiche reali e classificati secondo particolari criteri di analisi; Nel capitolo 4 sono esposti i risultati sperimentali : attraverso l elaborazione dei risultati ottenuti dall indagine, supportata dal tool, viene analizzata la modalità di detection prima tra le diverse release di uno stesso software e poi tra le differenti categorie di cui prima. 7

8 Capitolo 1 Log Analysis Il fiorire di scenari applicativi sempre più nuovi e complessi, soprattutto in ambienti critici, porta alla necessità di realizzare sistemi software non solo più sofisticati e potenti ma soprattutto più affidabili. Un malfunzionamento in una critical application può provocare danni molto gravi non solo in termini economici ma anche ambientali o addirittura perdite di vite umane. Le cause per cui un sistema può portarsi in uno stato incoerente, e dunque fallire, sono molteplici e possono manifestarsi in ogni fase del suo ciclo di vita: guasto hardware, errori in fase di design, di manutenzione, etc. Nell ambito ingegneristico sono di particolare interesse i Software Faults, classificati come la principale causa dei fallimenti dei sistemi software. I Software Faults sono delle imperfezioni nel codice del sistema, anche noti con il termine bugs : quando si presentano con modalità deterministica si parla di hard faults, mentre si parla di elusive faults quando essi, per limitazioni temporali e tecnologiche, sfuggono ai controlli della fase di testing e si manifestano sotto determinate condizioni computazionali (fault trigger). La natura non deterministica di questo tipo di faults fa sì che ogni applicazione software sia caricata di difetti residui (residual faults). La conseguenza è che un qualsiasi sistema, anche apparentemente corretto, può contenere dei faults inattivi, detti dormienti. L attivazione di un fault, in seguito a particolari trigger, porta il sistema in uno stato di errore : la produzione non corretta del servizio verifica un

9 failure. La rilevazione dell errore e le opportune tecniche di ripristino riportano il sistema ad operare in maniera corretta. In Figura 1 è riportata la catena di propagazione faulterror-failure. La distinzione tra errore e fallimento deriva dalla considerazione che in un sistema complesso l errore può essere confinato ad uno o più componenti senza raggiungere l interfaccia di servizio del sistema, mentre si ha un failure per la propagazione dell errore verso l interfaccia del sistema alterando la correttezza del servizio. È chiaro che l errore deve raggiungere l interfaccia in un tempo ragionavole, altrimenti viene classificato come errore latente. Fault, error e failure sono legati da una precisa relazione definita in letteratura come patologia del guasto. Poichè il fallimento di un componente può rappresentare un guasto esterno per un altro componente, la catena è ricorsiva. Figura 1 Catena di propagazione dell errore I Fallimenti Software rappresentano l incubo dell Information Age. Oltre agli errori ʺ tradizionaliʺ, quali le eccezioni e le computazioni errate, alcuni software faults sviluppati possono essere la causa dell invecchiamento del software : fenomeno in cui progressivamente le condizioni di errore maturate conducono o alla degradazione delle performance o a fallimenti transitori, o ad entrambi. Esempi sono la memoria piena, threads sospesi, corruzione dei dati, frammentazione dello spazio di memorizzazione. 9

10 A causa dell evoluzione di questi sistemi software, soprattutto in molteplici applicazioni critiche, è necessario che essi godino di un elevato grado di affidabilità. Le tecniche per aumentare il grado di dependability di un sistema sono diverse e si differenziano per il modo con cui si relazionano all occorrenza di un fault. La scelta della particolare strategia da adottare è legata alla natura del sistema e al grado di sicurezza che si vuole raggiungere. La log analysis è una delle tecniche a disposizione degli sviluppatori per misurare in maniera diretta la dependability di sistemi software complessi. 1.1 I logs I file di log sono dei file testuali in cui applicazioni, componenti o moduli di sistema memorizzano le informazioni delle operazioni compiute durante la fase operativa del sistema quando si rileva l attivazione di un software fault che ha portato l esecuzione ad uno stato di fallimento (es. se violata un asserzione di una variabile) o di avaria (es. se si riceve un servizio non corretto). Possono essere usati per molteplici scopi ma principalmente intesi per caratterizzare l affidabilità dei sistemi operazionali. Sono realizzati da manodopera umana, organizzati in record contenenti principalmente un timestamp, la descrizione sintetica dell evento, dello stato del sistema, una severity 2, l hostname, il pid del processo che ha generato l errore e possono mostrarsi come avvisi generici, notifiche di stati di errore, etc. Es. July 27 12:46 testlogs[1552] : Attenzione a questo evento! Il formato dell'entry di log è del tutto arbitrario, solitamente rivolto alla comprensione umana: il processo di logging è strettamente legato alla soggettività del singolo sviluppatore, per cui capita spesso che i formati dei logs differiscano sensibilmente anche tra varie sezioni dello stesso software. 1.2 Il meccanismo di logging Il meccanismo di logging è dunque una metodologia che si occupa della detection degli 2 Severity: grado di gravità scelto in un range predefinito 1

11 errori, dovuti all attivazione di Software Faults durante la fase operativa, e della collection delle informazioni relative all evento e allo stato del sistema al momento del rilevamento all interno dei logs. È necessario tener presente che una piattaforma dedicata al logging deve consentire allo sviluppatore di creare messaggi con invocazioni non complesse e permetterne la memorizzazione sul disco in un formato prestabilito, garantendo in tal modo la permanenza dei dati anche in caso di caduta del nodo o comunicazioni 3. Il meccanismo di logging richiede uno studio preliminare del sistema e del suo ambiente sia per identificare le tecniche adeguate al contesto sia per decidere se accompagnarle o meno con un componente ad hoc per il monitoraggio. La registrazione delle informazioni avviene per mezzo di chiamate proprie di una libreria di registrazione nel codice sorgente del programma in punti specifici. Di seguito è riportato un esempio della chiamata a log estrapolata dal file sorgente PublisherImpl.ccp del Middleware DDS 1.. È a cura del programmatore inserire correttamente le chiamate di registrazione all'interno del codice sorgente. I logs risultanti possono essere resi leggibili agli utenti o alle macchine a seconda della loro progettazione e alla loro finalità. if (enabled_ == false) { ACE_ERROR ((LM_ERROR, ACE_TEXT("(%P %t) ERROR: PublisherImpl::lookup_datawriter, ") ACE_TEXT(" Entity is not enabled. \n"))); return ::DDS::DataWriter::_nil (); } Chiamata dʼattivazione estratta dal file sorgente PublisherImpl.cpp di DDS 1. ( ) Sistemi noti basati sul meccanismo di logging sono Unix Syslong 4 e Microsoft. Syslong è un protocollo particolarmente diffuso in ambiente Unix/Linux, prevede che i messaggi di log non siano localmente memorizzati bensì instradati, attraverso la rete, verso applicazioni di monitoraggio. Definisce tre tipologie di entries : 3 I log possono essere memorizzati su database relazionali o su file 4 Con il termine Syslong (System Log) si indica un protocollo appartenente alla suite dei protocolli Internet 11

12 1) Originator che rappresenta il codice del messaggio ; 2) Relay usato per l instradamento ; 3) Collector che si occupa dell analisi e del monitoraggio. A differenza degli altri protocolli, esso non rappresenta uno standard rigidamente definito. Il suo semplice funzionamento può essere così schematizzato : - il client invia un certo messaggio di testo al server, comunemente definito come syslong daemon o syslong server ; - il server può gestire messaggi provenienti da una variegata tipologia di macchine (computer, stampanti, ecc.) e può limitarsi a registrare l'evento per avere un archivio centrale di avvenimenti oppure reagire a particolari livelli di severità chiamando programmi, inviando , etc. La Microsoft, invece, mette a disposizione una sofisticata piattaforma per fare logging distribuito realizzata con tools per l analisi di logs propietari, la Windows Event Log. Gli amministratori di sistemi Windows possono scegliere di inoltrare i logs ai vari sistemi nella rete di lavoro includendo un singolo log server con il compito di collezionare i logs proveninenti da tutte le macchine. Utilizza il Microsoft Event Log protocol : ogni host Windows esegue un Event Log provider, accessibile dal codice usando particolari chiamate di sistema. In presenza di una new entry, quindi quando un error è loggato, il provider automaticamente la scrive sul file log locale oppure la inoltra verso hosts remoti specifici a seconda della configurazione. 1.3 Formato dei logs Come anticipato nel paragrafo 1.1, la mancanza di uno standard per la struttura dei messaggi di log è causa di elevati livelli di eterogenità tra di loro. Ad esempio : I logging frameworks di Apache usano un formato di log personalizzato la cui sintassi è stata stabilita da un pugglable di componenti. È adatto per l adozione di un formato di linguaggio comune ; Syslong impone che i messaggi abbiano una struttura molto semplice : organizzati in record contenti una severity e una facility, seguiti da campi quali timestamp, hostname 12

13 dell originator, il nome dell applicazione. Tuttavia, alla semplicità della struttura si oppone una libertà di sintassi, che contribuisce al problema dell eterogeneità dei dati. Una severity rappresenta un grado d importanza del messaggio ai scopi di analisi, una facility è usata per gruppi di messaggi provenienti da un certo tipo di sorgenti, quali kernel, mail daemon. Se combinati tra loro, secondo la legge P=F*8+S, definiscono il valore di priorità del log. Mycrosoft impone per i Windows Event Log un formato code-oriented : i logs non sono scritti in file testuali ma memorizzati in un database nel loro formato originale e privi di ogni forma di serializzazione. Il formato è definito seguendo frammenti di codice C e prevede il salvataggio di due differenti timestamp : uno che indica il tempo in cui il messaggio è stato registrato e l altro il tempo in cui è stato scritto nel log. 1.4 Contributo e problematiche della Log Analysis La Log Analysis, schematizzata in Figura 2, permette attraverso una registrazione cronologica dei file log di: stabilire le correlazioni tra malfunzionamenti e determinate condizioni di carico di lavoro ; identificare le cause all origine di errori e comportamenti indesiderati ed imprevisti ; fornire analisi ed interpretazioni statistiche sui fallimenti e sulle conseguenti riparazioni dei guasti. Figura 2 Log Analysis Può essere utilizzata dagli sviluppatori per ricostruire la catena fault-error-failure, scoprire i faults (prima dormienti e in seguito attivati) e correggerli, dagli amministratori per 13

14 ottenere delle statistiche sull utilizzo del sistema. Tuttavia, nello scenario descritto non si è tenuto conto dei limiti del meccanismo di logging : la rilevazione di un fallimento è a carico di un operatore umano e dipende fortemente dal fatto che il modulo o l'applicazione tenga traccia o meno del particolare evento che ha generato il failure : il software può contenere dei faults che sfuggono anche al controllo di basso-livello e quindi restare totalmente inclassificati, in tal caso si parlerà di faults non loggati ; non esiste uno standard dedicato alla scrittura dei logs e ciò comporta problemi legati alla loro etereogenità che coinvolge sia il formato sia i contenuti ; i logs possono contenere informazioni fuorvianti, essere incompleti e ridondanti. L eterogeneità del formato è fortemente legata alla complessità del codice del sistema. I problemi legati a questo aspetto possono essere risolti convertendo tutte le entries in un formato comune mentre c'è poco da fare per quelli legati alla varietà dei contenuti. Un aspetto più critico dei limiti del logging riguarda la scarsa copertura dei logs rispetto a quei software faults che, una volta attivati, danno luogo ad errori che generano il bug del sistema rimanendo totalmente inclassificati. Questa difetto spesso è legato alla mancanta consapevolezza della presenza di fenomeni di propagazione degli errori, fonte di un numero elevato di eventi apparentementi non correlati nei logs. Una valutazione dell affidabilità della piattaforma di Windows NT la Log Analysis ha evidenziato che ben il 58% delle cause di failures non sono classificate, mentre uno studio sulla JVM mostra che, pur essendo dotata di un sosfisticato meccanismo di gestione delle eccezioni, non risultano segnalati nei logs il 45% dei casi di fallimento. Questi valori evidenziano una significativa percentuale di difetti strutturali non rilevatati dal meccanismo di logging. Sebbene siano stati realizzati numerosi studi per il perfezionamento delle tecniche per la detection e sulla ricerca di metodologie più innovative per garantire lo sviluppo e la diffusione di sistemi con un più alto livello di dependability, contribuendo alla realizzazione di tools automatici per la generazione e l'analisi (post e/o real time) degli 14

15 eventi di log da fornire poi agli ingegneri del software sia per le nuove applicazioni sia per le applicazioni legacy 5, quale la fault injection oppure la Field Failure Data Analysis (FFDA), risulta ancora poco consistente il contributo nelle ricerche per il superamento di queste limitazioni. 1.5 Obiettivo della tesi Lo scopo del presente elaborato è quello di fornire una valutazione quantativa della metodologia di logging, mediante un analisi sperimentale della modalità con cui è realizzata in un set di software open-source utilizzati in Critical Application. L indagine è compiuta con l ausilio di un tool per il parsing delle chiamate alle funzioni di log (vedi Capitolo 2). Sono sottoposti ad analisi differenti release di uno stesso software, più specificamente si fa riferimento a varie release del Server Apache e del Middleware DDS, e differenti sistemi software scelti in modo da coprire una serie di caratteristiche determinate sulla base di specifici criteri : stile di programmazione (object-oriented e procedure-oriented), dominio applicativo applicativo (mission e business critical), organizzazione a livello di sistema operativo (processo server, middleware, sistema operativo), architettura (centralizzato e distribuito). I sistemi open-source che meglio rispecchiano queste caratteristiche sono : Apache Web Server, MySQL, Corba TAO, Data Distribution Service, RTEMS, Minix e Cardamom Object Web, illustrati nel capitolo 3. Una valutazione empirica delle strutture utilizzate per la detection, suddivisa secondo le tipologie di cui prima, permette di studiare il trend di logging in vari contesti al fine di fornire informazioni utili alla comprensione della scarsa copertura dei logs. 5 Un Sistema legacy è un sistema informativo esistente da anni, di valore per il business da esso supportato, che è stato ereditato dall ambiente elaborativo attuale 15

16 Capitolo 2 Progettazione ed implementazione di un tool per il parsing delle chiamate alle funzioni di log In questo capitolo sarà illustrata la strumentazione adotta per la realizzazione dell analisi sperimentale della modalità di logging nei sistemi open-source: si realizza un tool di supporto, scritto in linguaggio Bash del Sistema Operativo Linux con l ausilio delle espressioni regolari, con lo scopo di filtrare i codici sorgenti dei sistemi da esaminare, di isolare le chiamate alle funzioni di log e di ʺ catturareʺ la struttura di controllo utilizzata per la detection degli errors. Poichè per ogni sistema il logging è realizzato mediante chiamate proprie di una particolare libreria di registrazione nel codice sorgente, per poterle individuare è stato necessario uno studio preliminare dei file sorgenti per ciascuno di essi. I risultati ottenuti dal tool sono stati poi elaborati per la valutazione del trend di logging tra le release di uno stesso software e tra le differenti classi considerate. 2.1 Il tool di parsing Scopo del tool Lo script per il parsing delle chiamate ai log, denominato file_log.sh, è stato scritto in modo da renderlo valido per questo studio e per eventuali studi futuri. In altre parole, è stato realizzato in modo da risultare indipendente dai particolari software esaminati in questo contesto. Ricevuti in ingresso, nel medesimo ordine, la cartella dei file sorgenti del software sottoposto ad esame, il file di testo contenente la lista delle corrispondenti funzioni di log e

17 il numero di righe che le precedono, lo scopo del tool è quello di fornire in output : o la stima della quantità di codice dei sorgenti : Loc ; o la porzione di codice esaminato : Loc ANALIZZATE ; o l aliquota di codice dedicato al logging, ovvero il numero di chiamate a log : LOG ; o la catalogazione e il conteggio di tutte le strutture di controllo individuate, utilizzate per la detection degli errors : IF, ELSE, SWITCH, IFDEFINE, CATCH e OTHER ; gli IF sono a loro volta classificati in IF con 1 condizione, IF con 2 e IF con un numero di condizioni maggiori di 2, suddivise in base alle condizioni logiche ; o la classificazione e l enumerazione di tutte le possibili operazioni coinvolte nelle clausole dei costrutti IF : =,, <, >, e ; o la schedatura e il calcolo di ciascuno dei possibili valori coinvolti nelle condizioni degli IF : notevoli «NULL,, 1, -1, TRUE, FALSE» e di default «VALUE». I risultati ottenuti in questo step sono oggetto di studio nelle fasi successive dell analisi, esposte nel Capitolo 4. In Figura 3 è riportato un esempio di analisi del sosftware Apache v

18 SORGENTI: http_main.c, http_config.c, http_log.c FUNZIONI: ap_log_error n=3 TOOL ===================== ====Report =========================== LS SORGENTI LS ANALIZZATE 632 LOG 132 ELSE(std) 1 SWITCH 4 IFD 17 CATCH OTHER 19 TOT IF 71 -> IF 1-Cond: 66 ** IF 2-Cond: 4 ** IF >= 3-Cond: 1 IF 2-Cond-> IF 1-Op/AND: 4 ** IF 1-Op/OR: IF 3-Cond-> IF 2-Op/AND: ** IF 2-Op/OR: 1 ** IF 2-Op/AND-OR: == -!= - < - > - <= - >= NULL 4 - (4) (8) () () VALUE (44) TRUE 13 - (13) FALSE 1 - (1) Figura 3 Esempio: Analisi del software Apache Modalità operative Il funzionamento dello strumento di parsing può essere schematizzato in tre fasi: 1) Isolamento delle chiamate alle funzioni di log ; 2) Stima della percentuale della quota di codice dedicata al logging rispetto a quella dei sorgenti ; 3) Identificazione delle strutture di controllo per la detection. La fase di isolamento è adempita mediante : a) Copia di tutti i sorgenti, ricevuti come primo parametro di input, in un unico file di 18

19 testo 6. È importante tener presente che essi non sono altro che dei file scritti in un certo linguaggio di programmazione e quindi contenenti commenti che possono inquinare l analisi. Per questo motivo, tale operazione è anticipata da una di decommentazione. Il file testuale così ottenuto è denominato file_error.txt ; b) Trascrizione : fissato un n, si copia per ciascuna funzione di log (memorizzata nella lista e fornita al tool come secondo parametro d ingresso) una quantità di codice che precede la chiamata di log di un numero n di righe nel file di testo file_log_error.txt. Tale file è utilizzato per individuare le strutture utilizzate per il rilevamento di errori. La fase di stima è realizzata attraverso il conteggio delle : righe filtrate dei sorgenti, memorizzate nel file file_error.txt ; righe estrapolate per l individuazione delle strutture di controllo e salvate nel file_log_errog.txt ; chiamate a funzioni di log presenti nel file_error.txt. 2.2 Problematiche e soluzioni proposte Le difficoltà incontrate nella progettazione dello script sono state: farsì che esso fosse indipendente dalla tipologia del sistema; la scelta del numero di righe da prelevare per la cattura delle strutture di detection. La soluzione proposta per il primo punto è stata quella di fornire i sorgenti da analizzare come parametri d ingresso. In particolare, per ogni sistema è necessario raccogliere tutti i sorgenti da esaminare in una directory e fornirla al tool come primo input. A questo punto nasce il problema legato all eterogeneità delle funzioni di log tra i vari sistemi. Un idea consiste nel memorizzare in una lista tutte le chiamate individuate e fornirla come secondo input. Per quanto riguarda la scelta del numero di righe da prelevare per l individuazione delle strutture di controllo si è pensato di rendere tale valore arbitrario e modificabile per altre esigenze di analisi e per questo sarà fornito in input, rappresentando quindi il terzo 6 Esempio alcuni dei sorgenti del software Apache sono : http_config.c, http_request.c, http_main.c 19

20 paramentro d ingresso. Tuttavia, nella nostra indagine la scelta di tale valore è il risultato di una serie di test : per ciascun sistema di elaborazione sono stati provati diversi valori fino a trovare quello che è risultato più idoneo. Sono state prelevate n righe antecedenti alle funzioni e memorizzate in un file testuale. Attraverso un ispezione di quest ultimo si è verificato qual era il valore che permettesse di catturare una quantità di strutture tale da ritenere l analisi attendibile. Le prove sono state realizzate con n=1, n=5, n=4, n=3 e n=2. Per n=1 è stata registrata un abbondanza di informazioni superflue che avrebbe reso lo studio inattendibile. Già scegliendo n=4, tale entità è risultata alquanto accettabile. Con n=3 si è verificato che in alcuni casi i costrutti venivano persi (ad esempio perchè le chiamate di logs sono anticipate da una serie di operazioni, quali il refresh di una variabile). La porzione di informazioni perse rispetto alla quota di chiamate analizzate è risultata tale da essere trascurabile. Analogamente per la razione di dati superflui. Con n=2, invece, il numero di costrutti persi è stato tale da rendere la nostra analisi incerta. In questo caso di studio i sistemi saranno analizzati con n=3. Sono riportati alcuni esempi dei pezzi di codici estrapolati con n=3: if (!reported && (active_threads == ap_threads_per_child)) { reported = 1; ap_log_error(aplog_mark, APLOG_NOERRNO APLOG_ERR, server_conf, "Server ran out of threads to serve requests. Consider " "raising the ThreadsPerChild setting"); Chiamata dʼattivazione estratta dai sorgenti di Apache (http main.c, ) if (hostname.c_str()[] == ) { ctx.reporterror("hostname required on nodeid %d since it will " "act as server.", id1); Chiamata dʼattivazione estratta dai sorgenti di MySQL ( ) if(path == strlen(path) == ){ ERROR_SET(fatal, NDBD_EXIT_INVALID_CONFIG, "Invalid configuration fetched. Configuration does not contain valid ", param_string); } Chiamata dʼattivazione estratta dai sorgenti di MySQL (Configuration.cpp ) 2

21 A questo punto ci si aspetta che il file_log_error.txt abbia un numero di righe pari a n log* n (nel nostro caso n log*3), mentre invece non risulta così : sebbene in un quantità molto ridotta alcuni costrutti attivano in maniera sequenziale due o più logs. Quest'osservazione può essere utile nel caso in cui si voglia studiare la complessità del corpo dei costrutti di controllo. 2.3 Considerazioni per la fase di progettazione Come già anticipato nel Cap , parte del compito del tool consiste nella catalogazione e nel conteggio di tutte le strutture utilizzate per il logging : IF, ELSE, CASE, IFDEFINE, CATCH e OTHER nel quale sono raccolti per default tutte quelle non elencate. La scelta di conteggiare anche i CATCH deriva dal fatto che i file sorgenti dei sistemi possono essere scritti in linguaggi che prevedono la gestione delle eccezioni per mezzo di blocchi try-catch (es. C++, Java). Per i costrutti IF, poichè essi sono i principali costrutti di controllo utilizzati nel meccanismo di logging, da come sarà anche illustrato nel capitolo successivo, viene effettuata un ulteriore catalogazione : IF composti da una condizione, IF composti da due condizioni e IF con un numero di condizioni maggiore di 2. Si è scelto di enumerare le condizioni limitatamente a n>2 (con n=n di condizioni) in quanto il numero di clausole così composte è molto ridotto, e quindi un ulteriore scomposizione non avrebbe fornito alcun contributo utile ai fini dell analisi. Per gli IF composti da 2 o più clausole sono stimate le possibili condizioni: IF con 1 AND, IF con 1 OR per quelli composti da 2 condizioni, IF con 2 AND, con 2 OR oppure con 1AND/ 1OR per gli IF con n>2. Un secondo passo della scomposizione degli IF consiste nell esaminare la struttura delle clausole : è eseguita la schedatura e il calcolo di ciascuna delle operazioni fattibili e dei i possibili valori coinvolti. Le operazioni possibili sono quelle di confronto : uguaglianza, disuguaglianza e monotonia lasca e stretta. Per quanto riguarda invece i possibili valori coinvolti, essendo questi una quantità infinita, è stato scelto di raggrupparli in tre categorie : quelli notevoli NULL,, 1 e -1 perchè usati normalmente non solo in operazioni di confronto ma anche in operazioni quali il set/reset di variabili, 21

Analisi empirica dei meccanismi di log in sistemi open-source!

Analisi empirica dei meccanismi di log in sistemi open-source! tesi di laurea! Analisi empirica dei meccanismi di log in sistemi open-source! Anno Accademico 2010/2011! relatore! Ch.mo prof. Domenico Cotroneo! Correlatore! Ing. Antonio Pecchia! Candidato! Assunta

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Sistemi e schedulazione in tempo reale

Sistemi e schedulazione in tempo reale Sistemi e schedulazione in tempo reale 1 Sistemi in tempo reale Sistemi di calcolo in cui la correttezza del funzionamento dipende criticamente dal tempo in cui i risultati sono prodotti. Possibili campi

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

Dettagli

Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis

Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis tesi di laurea Realizzazione di un tool di instrumentazione automatica a supporto della failure analysis Anno Accademico 2011/2012 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Antonio Pecchia

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario L hardware di I/O Struttura Interazione tra computer e controllori

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

Dettagli

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Sistema operativo Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Architettura a strati di un calcolatore

Dettagli

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari Gubiani & Montanari Il DBMS Oracle 1 Il DBMS Oracle Express Edition Donatella Gubiani e Angelo Montanari Il DBMS Oracle Il DBMS Oracle Oracle 10g Express Edition Il DBMS Oracle (nelle sue versioni più

Dettagli

Virtualizzazione e Macchine Virtuali

Virtualizzazione e Macchine Virtuali Virtualizzazione e Macchine Virtuali Gabriele D Angelo, Ludovico Gardenghi {gda, garden}@cs.unibo.it http://www.cs.unibo.it/~gdangelo/ http://www.cs.unibo.it/~gardengl/ Università di Bologna Corso di Laurea

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell

Dettagli

Capitolo 5: I thread

Capitolo 5: I thread Capitolo 5: I thread Generalità. Modelli multithread. Problematiche relative ai thread. Pthread. 5.1 I thread Il thread è un flusso di controllo relativo ad un dato processo. Molti sistemi operativi moderni

Dettagli

Un approccio innovativo alla tecnica di robustness testing del sistema operativo Linux

Un approccio innovativo alla tecnica di robustness testing del sistema operativo Linux tesi di laurea Un approccio innovativo alla tecnica di robustness testing del sistema Anno Accademico 2009/2010 relatore Ch.mo prof. Domenico Cotroneo correlatori Ing. Domenico Di Leo Ing. Roberto Natella

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli

Analisi della dependability di un middleware per la

Analisi della dependability di un middleware per la tesi di laurea Analisi della dependability di un middleware per la distribuzione ib i dei dati conforme allo standard d OMG Anno Accademico 2005-2006 relatori Ch.mo prof. Stefano Russo Ch.mo prof. Domenico

Dettagli

Funzioni del Sistema Operativo

Funzioni del Sistema Operativo Il Software I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono il cosiddetto Hardware (ferramenta). La struttura del calcolatore può essere schematizzata come una serie di

Dettagli

Introduzione ai sistemi operativi

Introduzione ai sistemi operativi Introduzione ai sistemi operativi Che cos è un S.O.? Shell Utente Utente 1 2 Utente N Window Compilatori Assembler Editor.. DB SOFTWARE APPLICATIVO System calls SISTEMA OPERATIVO HARDWARE Funzioni di un

Dettagli

Corso Web programming

Corso Web programming Corso Web programming Modulo T3 A1 Modelli di programmazione 1 Prerequisiti Concetto di rete Processi e thread Concetti generali sui database 2 1 Introduzione Un particolare ambito della programmazione

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Pietro Frasca Lezione 5 Martedì 21-10-2014 Thread Come abbiamo detto, un processo è composto

Dettagli

Implementazione di un servizio VoIP in ambienti SOA per mobile computing

Implementazione di un servizio VoIP in ambienti SOA per mobile computing tesi di laurea Implementazione di un servizio VoIP in ambienti SOA per mobile computing Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo correlatore ing. Marcello Cinque candidato Vittorio

Dettagli

Realizzazione di un sistema di logging prototipale per la piattaforma

Realizzazione di un sistema di logging prototipale per la piattaforma tesi di laurea Realizzazione di un sistema di logging prototipale per la piattaforma Android Anno Accademico 2011 / 2012 relatore Ch.mo prof. Marcello Cinque candidato Dario De Meis Matr. 528 / 741 Smartphone

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi:

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: 1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: compile time, load time, execution time. Quale delle modalità precedenti necessita di un supporto hardware per poter essere

Dettagli

Si S curezza a sw w net il c orr r e r tto design del t uo s istema i nform r atico una soluzione

Si S curezza a sw w net il c orr r e r tto design del t uo s istema i nform r atico una soluzione Sicurezza asw net il corretto design del tuo sistema informatico una soluzione Sicurezza asw net un programma completo di intervento come si giunge alla definizione di un programma di intervento? l evoluzione

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Maxpho Commerce 11 Gestione CSV Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Indice generale 1 - Introduzione... 3 1.1 - Il file CSV...3 1.2 - Modulo CSV su Maxpho... 3 1.3 - Modulo CSV Pro

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Strumento per l iniezione di guasti software nel sistema operativo GNU/Linux

Strumento per l iniezione di guasti software nel sistema operativo GNU/Linux Tesi di laurea Strumento per l iniezione di guasti software nel sistema operativo GNU/Linux Anno Accademico 2009/2010 Relatore Ch.mo prof. Marcello Cinque Correlatore Ch.mo ing. Roberto Natella Candidato

Dettagli

Messaggi volatili. Matteo Zignani. 10 gennaio 2015

Messaggi volatili. Matteo Zignani. 10 gennaio 2015 UNIVESITÁ DEGLI STUDI DI MILANO LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE PROGETTO LABORATORIO DI RETI DI CALCOLATORI Messaggi volatili Matteo Zignani 10 gennaio 2015 1 PRESENTAZIONE DEL PROBLEMA Lo studente

Dettagli

INFORMATICA. Il Sistema Operativo. di Roberta Molinari

INFORMATICA. Il Sistema Operativo. di Roberta Molinari INFORMATICA Il Sistema Operativo di Roberta Molinari Il Sistema Operativo un po di definizioni Elaborazione: trattamento di di informazioni acquisite dall esterno per per restituire un un risultato Processore:

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

I processi. Un processo è una attività, controllata da un programma, che si svolge su un processore.

I processi. Un processo è una attività, controllata da un programma, che si svolge su un processore. I processi Cos è un processo? Un processo è una attività, controllata da un programma, che si svolge su un processore. Il programma è una entità statica che descrive la sequenza di istruzioni che devono

Dettagli

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript

Realizzazione di un Tool per l iniezione automatica di difetti all interno di codice Javascript tesi di laurea di difetti all interno di codice Javascript Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Domenico Amalfitano candidato Vincenzo Riccio Matr.

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

ORACOLO Gestione questionari.

ORACOLO Gestione questionari. ORACOLO Gestione questionari. Oracolo è un software di gestione questionari e test nato per raccolta dati ad uso scientifico. Oracolo è adatto a raccogliere dati su questionari personalizzabili di qualunque

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Sme.UP Web Application

Sme.UP Web Application Sme.UP Web Application Web Application Web.UP Una interfaccia web per i vostri dati gestionali Il modulo applicativo Web.UP fornisce al progettista di siti Internet una serie di potenti strumenti per l'integrazione

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario Data Base Management System Strumenti: Software specifico Formato: Pro: Proprietario Massima semplicità di inserimento e gestione Tipizzazione Validazione dei dati Contro: Creazione del database Programmazione

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Dispensa di Informatica I.1

Dispensa di Informatica I.1 IL COMPUTER: CONCETTI GENERALI Il Computer (o elaboratore) è un insieme di dispositivi di diversa natura in grado di acquisire dall'esterno dati e algoritmi e produrre in uscita i risultati dell'elaborazione.

Dettagli

Corso basi di dati Introduzione alle ASP

Corso basi di dati Introduzione alle ASP Corso basi di dati Introduzione alle ASP Gianluca Di Tomassi Email: ditomass@dia.uniroma3.it Università di Roma Tre Web statico e Web interattivo In principio il Web era una semplice collezione di pagine

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

Strumento evoluto di Comunicazione con i Venditori

Strumento evoluto di Comunicazione con i Venditori Strumento evoluto di Comunicazione con i Venditori GAS 2 net è una soluzione web-based compliant con le definizioni di strumento evoluto come richiesto dalla normativa vigente (Del. AEEG n 157/07, Del.

Dettagli

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo.

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo. Pro COMMERCIALE (La farmacia può decidere di accettare o meno l allineamento commerciale di un prodotto) ACCETTARE IL PRODOTTO SOSTI- TUTIVO (La farmacia può decidere di accettare o meno il prodotto sostitutivo)

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Soft Control facile con RTX e Windows Embedded Standard 7 RTX 2009: funzionalità ed uso pratico Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Definizione di Sistema Tempo Reale: Definizione

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

1. BASI DI DATI: GENERALITÀ

1. BASI DI DATI: GENERALITÀ 1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente

Dettagli

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo F.O.A.M. Free Object Access Method Un introduzione Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo Il protocollo FOAM. FOAM (Free Object Access Method) è un protocollo

Dettagli

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

Programmazione Server Side e Database in rete

Programmazione Server Side e Database in rete Programmazione Server Side e Database in rete Prof. Massimo PALOMBO -IIS A. MEUCCI Casarano La programmazione Stand-Alone consente di costruire applicazioni, più o meno complesse, ma utilizzabili esclusivamente

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

Dettagli

LUCA VACCARO. Politecnico di Milano. S2MS Guida di Riferimento

LUCA VACCARO. Politecnico di Milano. S2MS Guida di Riferimento LUCA VACCARO Politecnico di Milano S2MS Guida di Riferimento L U C A V A C C A R O S2MS Guida di Riferimento Software sviluppato da Luca Vaccaro luck87@gmail.com Progetto del corso Internetworking TCP/IP

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Antonio Brunetti, Mathias Galizia, Fabio Campanella

Antonio Brunetti, Mathias Galizia, Fabio Campanella Atti Progetto AQUATER, Bari, 31 ottobre 2007, 9-14 LA BANCA DATI DEI PROGETTI DI RICERCA E L ARCHIVIO DOCUMENTALE DEL CRA Antonio Brunetti, Mathias Galizia, Fabio Campanella Consiglio per la Ricerca e

Dettagli

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli

InfoTecna ITCube Web

InfoTecna ITCube Web InfoTecna ITCubeWeb ITCubeWeb è un software avanzato per la consultazione tramite interfaccia Web di dati analitici organizzati in forma multidimensionale. L analisi multidimensionale è il sistema più

Dettagli

Strategie per il miglioramento dei log applicativi basate su Software Fault Injection

Strategie per il miglioramento dei log applicativi basate su Software Fault Injection tesi di laurea Anno Accademico 2010/2011 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Roberto Natella candidato Daniele Esposito Matr. 534/003280 Introduzione Software Fault: difetti presenti

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati

Uno strumento per il deployment automatico di performance test su piattaforme per la distribuzione di dati tesi di laurea Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Controneo correlatore Ing. Christiancarmine Esposito candidato Antonella Niola Matr. 534/158 .:: Contesto ::. www.cosmiclab.it Il

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

catalogo corsi di formazione 2015/2016

catalogo corsi di formazione 2015/2016 L offerta formativa inserita in questo catalogo è stata suddivisa in quattro sezioni tematiche che raggruppano i corsi di formazione sulla base degli argomenti trattati. Organizzazione, progettazione e

Dettagli

Informatica e Bioinformatica: Sistemi Operativi

Informatica e Bioinformatica: Sistemi Operativi Informatica e Bioinformatica: Sistemi Operativi 11 marzo 2013 Macchina Hardware/Software Sistema Operativo Macchina Hardware La macchina hardware corrisponde alle componenti fisiche del calcolatore (quelle

Dettagli

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante CONOSCENZE DI INFORMATICA 1) Una periferica di input è: A) il mouse B) il monitor C) la stampante 2) Una memoria in sola lettura con la particolarità di essere cancellata in particolari condizioni è detta:

Dettagli

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Mattia Gentilini Relatore: Renzo Davoli Laurea Specialistica in Informatica I Sessione A.A. 2005/2006

Dettagli