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

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

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

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

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

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

CORSO WEB SERVER, DBMS E SERVER FTP

CORSO WEB SERVER, DBMS E SERVER FTP CORSO WEB SERVER, DBMS E SERVER FTP DISPENSA LEZIONE 1 Autore D. Mondello Transazione di dati in una richiesta di sito web Quando viene effettuata la richiesta di un sito Internet su un browser, tramite

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

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

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

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

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

Prefazione. Contenuti

Prefazione. Contenuti Prefazione Il sistema operativo costituisce uno dei componenti fondamentali di ogni sistema di elaborazione, in particolare è quello con cui l utente entra direttamente in contatto quando accede al sistema,

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

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

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

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

Logbus-ng: a software logging bus for Field Failure Data Analysis in distributed systems Anno Accademico 2009-2010

Logbus-ng: a software logging bus for Field Failure Data Analysis in distributed systems Anno Accademico 2009-2010 tesi di laurea Logbus-ng: a software logging bus for Field Failure Data Analysis in Anno Accademico 2009-2010 relatore Ch.mo prof. Domenico Cotroneo Ch.mo prof. Marcello Cinque correlatore Ch.mo Ing. Antonio

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

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

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

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014

Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014 tesi di laurea specialistica Realizzazione di un framework di monitoring per l'analisi di sistemi critici Anno Accademico 2013/2014 relatore Ch.mo Prof. Domenico Cotroneo correlatore Ch.mo ing. Antonio

Dettagli

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE Pag. 1/1 Sessione ordinaria 2010 Seconda prova scritta Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE CORSO DI ORDINAMENTO Indirizzo: INFORMATICA

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

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

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

Architetture per le applicazioni web-based. Mario Cannataro

Architetture per le applicazioni web-based. Mario Cannataro Architetture per le applicazioni web-based Mario Cannataro 1 Sommario Internet e le applicazioni web-based Caratteristiche delle applicazioni web-based Soluzioni per l architettura three-tier Livello utente

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

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

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

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

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

Esercitazione 8. Basi di dati e web

Esercitazione 8. Basi di dati e web Esercitazione 8 Basi di dati e web Rev. 1 Basi di dati - prof. Silvio Salza - a.a. 2014-2015 E8-1 Basi di dati e web Una modalità tipica di accesso alle basi di dati è tramite interfacce web Esiste una

Dettagli

Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico con Garanzie di Tempo ed Affidabilità

Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico con Garanzie di Tempo ed Affidabilità tesi di laurea Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico Anno Accademico 2008/2009 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Christiancarmine Esposito candidato

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

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

Data Warehouse Architettura e Progettazione

Data Warehouse Architettura e Progettazione Introduzione Data Warehouse Architettura! Nei seguenti lucidi verrà fornita una panoramica del mondo dei Data Warehouse.! Verranno riportate diverse definizioni per identificare i molteplici aspetti che

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

Manuale utente. ver 1.0 del 31/10/2011

Manuale utente. ver 1.0 del 31/10/2011 Manuale utente ver 1.0 del 31/10/2011 Sommario 1. Il Servizio... 2 2. Requisiti minimi... 2 3. L architettura... 2 4. Creazione del profilo... 3 5. Aggiunta di un nuovo dispositivo... 3 5.1. Installazione

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

INTRODUZIONE. Motivazioni e Obbiettivi

INTRODUZIONE. Motivazioni e Obbiettivi INTRODUZIONE Motivazioni dei sistemi distribuiti Caratteristiche generali Alcuni richiami sui database centralizzati Standardizzazione dei dati (ANSI/SPARC) Funzioni dei DBMS relazionali Problematiche

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

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Introduzione: 1. Principi di base dei sistemi operativi 2. Sistemi

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

Progettazione e sviluppo di uno strumento di monitoraggio dei componenti software di un sistema per il controllo del traffico aereo

Progettazione e sviluppo di uno strumento di monitoraggio dei componenti software di un sistema per il controllo del traffico aereo tesi di laurea Progettazione e sviluppo di uno strumento di monitoraggio dei componenti software di un sistema per il controllo del traffico aereo Anno Accademico 2007/2008 relatore Ch.mo prof. Domenico

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows La genealogia di Windows Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

Dettagli

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 La genealogia di Windows DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

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

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

Sistemi operativi e reti A.A. 2015-16. Lezione 2

Sistemi operativi e reti A.A. 2015-16. Lezione 2 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16 Pietro Frasca Lezione 2 Giovedì 8-10-2015 Sistemi batch multiprogrammati La causa principale

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

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

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

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

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

Scriviamo insieme il futuro

Scriviamo insieme il futuro Res User Meeting 2014 con la partecipazione di Scriviamo insieme il futuro Research for Enterprise Systems 1 Generale - 1 Obbiettivo Fornire al Cliente uno strumento a supporto della problematica Legata

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

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10 Soluzioni software di EDM "Electronic Document Management" Gestione dell archiviazione, indicizzazione, consultazione e modifica dei documenti elettronici. Un approccio innovativo basato su tecnologie

Dettagli

Processi. Laboratorio Software 2008-2009 C. Brandolese

Processi. Laboratorio Software 2008-2009 C. Brandolese Processi Laboratorio Software 2008-2009 Introduzione I calcolatori svolgono operazioni simultaneamente Esempio Compilazione di un programma Invio di un file ad una stampante Visualizzazione di una pagina

Dettagli

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28

Corso di Elettronica dei Sistemi Programmabili. Sistemi Operativi Real Time. Introduzione. Aprile 2014 Stefano Salvatori 1/28 Corso di Elettronica dei Sistemi Programmabili Sistemi Operativi Real Time Introduzione Aprile 2014 Stefano Salvatori 1/28 Sommario Definizioni livelli di astrazione processi di tipo batch e processi interattivi

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

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

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

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

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo tesi di laurea Analisi e sperimentazione della piattaforma Web Service Notification Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo Correlatore Ing. Christiancarmine Esposito candidato

Dettagli

CATALOGO CORSI DI FORMAZIONE INFORMATICA

CATALOGO CORSI DI FORMAZIONE INFORMATICA CATALOGO CORSI DI FORMAZIONE INFORMATICA La Dialuma propone a catalogo 22 corsi di Informatica che spaziano tra vari argomenti e livelli. TITOLI E ARGOMENTI I001 - Informatica generale Concetti generali

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

NetCrunch 6. Server per il controllo della rete aziendale. Controlla

NetCrunch 6. Server per il controllo della rete aziendale. Controlla AdRem NetCrunch 6 Server per il controllo della rete aziendale Con NetCrunch puoi tenere sotto controllo ogni applicazione, servizio, server e apparato critico della tua azienda. Documenta Esplora la topologia

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

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

Corso di Sistemi di elaborazione delle informazioni

Corso di Sistemi di elaborazione delle informazioni Corso di Sistemi di elaborazione delle informazioni Biacco Sabrina ENTERPRISE RESOURCE PLANNING Gli ERP sono delle soluzioni applicative in grado di coordinare l'insieme delle attività aziendali automatizzando

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

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico Impossibile visualizzare l'immagine. Struttura di un sistema operativo Struttura dei Sistemi Operativi Servizi di un sistema operativo Interfaccia Utente Capitolo 2 -- Silberschatz Chiamate di sistema

Dettagli

Tesi di laurea triennale. Anno Accademico 2010/2011. Relatore Ch.mo prof. Porfirio TRAMONTANA. Correlatore Ch.mo Sig.

Tesi di laurea triennale. Anno Accademico 2010/2011. Relatore Ch.mo prof. Porfirio TRAMONTANA. Correlatore Ch.mo Sig. Tesi di laurea triennale Creazione, gestione e risoluzione delle problematiche relative ai flussi di stampa e postalizzazione massivi di fatture e comunicazioni alla clientela: Porting SpeedPost. Anno

Dettagli

Parte VI SISTEMI OPERATIVI

Parte VI SISTEMI OPERATIVI Parte VI SISTEMI OPERATIVI Sistema Operativo Ogni computer ha un sistema operativo necessario per eseguire gli altri programmi Il sistema operativo, fra l altro, è responsabile di riconoscere i comandi

Dettagli

Prototipazione di un componente di elaborazione dei piani di volo in un sistema di Traffic Management

Prototipazione di un componente di elaborazione dei piani di volo in un sistema di Traffic Management tesi di laurea in un sistema di Traffic Management Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Antonio Strano candidato Giuseppe Diodato Mottola Matr. 534/2115 Obiettivo

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

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

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

PHP ), con l'introduzione di un middleware quale Zend Framework a

PHP ), con l'introduzione di un middleware quale Zend Framework a Quella che segue è la rappresentazione ad alto livello dell'architettura proposta per il sistema in corso di realizzazione. In questa fase non vengono ancora affrontate le tematiche di sicurezza, load

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

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

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

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base)

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base) Sistema Operativo (Software di base) Il Sistema Operativo Il sistema operativo è un insieme di programmi che opera sul livello macchina e offre funzionalità di alto livello Es.organizzazione dei dati attraverso

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Caratterizzazionedei SistemiDistribuiti

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

MIXER: gestione trasmissioni DJ: governance di MIXER

MIXER: gestione trasmissioni DJ: governance di MIXER MIXER-DJ MIXER: gestione trasmissioni DJ: governance di MIXER MIXER Mixer è un ambiente applicativo di tipo Enterprise Service Bus (ESB) per la gestione delle trasmissioni di file su Linux. All'interno

Dettagli