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

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

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it FIRESHOP.NET Gestione Utility & Configurazioni Rev. 2014.3.1 www.firesoft.it Sommario SOMMARIO Introduzione... 4 Impostare i dati della propria azienda... 5 Aggiornare il programma... 6 Controllare l integrità

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Descrizioni VHDL Behavioral

Descrizioni VHDL Behavioral 1 Descrizioni VHDL Behavioral In questo capitolo vedremo come la struttura di un sistema digitale è descritto in VHDL utilizzando descrizioni di tipo comportamentale. Outline: process wait statements,

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

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

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

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

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

PROFILI ALLEGATO A. Profili professionali

PROFILI ALLEGATO A. Profili professionali ALLEGATO A Profili professionali Nei profili di seguito descritti vengono sintetizzate le caratteristiche di delle figure professionali che verranno coinvolte nell erogazione dei servizi oggetto della

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

Sizing di un infrastruttura server con VMware

Sizing di un infrastruttura server con VMware Sizing di un infrastruttura server con VMware v1.1 Matteo Cappelli Vediamo una serie di best practices per progettare e dimensionare un infrastruttura di server virtuali con VMware vsphere 5.0. Innanzitutto

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

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

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti Dai sistemi concorrenti ai sistemi distribuiti Problemi nei sistemi concorrenti e distribuiti I sistemi concorrenti e distribuiti hanno in comune l ovvio problema di coordinare le varie attività dei differenti

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis 2 Intervento immediato con Bosch Intelligent Video Analysis Indipendentemente da quante telecamere il sistema utilizza, la sorveglianza

Dettagli

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone SQL: il DDL Parti del linguaggio SQL Definizione di basi di dati (Data Definition Language DDL) Linguaggio per modificare

Dettagli

GESTIONE DELLA E-MAIL

GESTIONE DELLA E-MAIL GESTIONE DELLA E-MAIL Esistono due metodologie, completamente diverse tra loro, in grado di consentire la gestione di più caselle di Posta Elettronica: 1. tramite un'interfaccia Web Mail; 2. tramite alcuni

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

F O R M A T O E U R O P E O

F O R M A T O E U R O P E O F O R M A T O E U R O P E O P E R I L C U R R I C U L U M V I T A E INFORMAZIONI PERSONALI Nome Indirizzo Laura Bacci, PMP Via Tezze, 36 46100 MANTOVA Telefono (+39) 348 6947997 Fax (+39) 0376 1810801

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate.

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate. Comandi filtro: sed Il nome del comando sed sta per Stream EDitor e la sua funzione è quella di permettere di editare il testo passato da un comando ad un altro in una pipeline. Ciò è molto utile perché

Dettagli

Guida Dell di base all'acquisto dei server

Guida Dell di base all'acquisto dei server Guida Dell di base all'acquisto dei server Per le piccole aziende che dispongono di più computer è opportuno investire in un server che aiuti a garantire la sicurezza e l'organizzazione dei dati, consentendo

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Energy risk management

Energy risk management Il sistema di supporto alle tue decisioni Energy risk management Un approccio orientato agli attori M.B.I. Srl, Via Francesco Squartini 7-56121 Pisa, Italia - tel. 050 3870888 - fax. 050 3870808 www.powerschedo.it

Dettagli

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1 Tutorial Configuration Managment Configurare il servizio EC2 su AWS Pagina 1 Sommario 1. INTRODUZIONE... 3 2. PROGRAMMI NECESSARI... 4 3. PANNELLO DI CONTROLLO... 5 4. CONFIGURARE E LANCIARE UN ISTANZA...

Dettagli

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata Giampiero Carboni Davide Travaglia David Board Rev 5058-CO900C Interfaccia operatore a livello di sito FactoryTalk

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

Installazione di GFI Network Server Monitor

Installazione di GFI Network Server Monitor Installazione di GFI Network Server Monitor Requisiti di sistema I computer che eseguono GFI Network Server Monitor richiedono: i sistemi operativi Windows 2000 (SP4 o superiore), 2003 o XP Pro Windows

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Progetto VirtualCED Clustered

Progetto VirtualCED Clustered Progetto VirtualCED Clustered Un passo indietro Il progetto VirtualCED, descritto in un precedente articolo 1, è ormai stato implementato con successo. Riassumendo brevemente, si tratta di un progetto

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

GUIDA RAPIDA emagister-agora Edizione BASIC

GUIDA RAPIDA emagister-agora Edizione BASIC GUIDA RAPIDA emagister-agora Edizione BASIC Introduzione a emagister-agora Interfaccia di emagister-agora Configurazione dell offerta didattica Richieste d informazioni Gestione delle richieste d informazioni

Dettagli

CONFIGURAZIONE DEI SERVIZI (seconda parte)

CONFIGURAZIONE DEI SERVIZI (seconda parte) Corso ForTIC C2 LEZIONE n. 10 CONFIGURAZIONE DEI SERVIZI (seconda parte) WEB SERVER PROXY FIREWALL Strumenti di controllo della rete I contenuti di questo documento, salvo diversa indicazione, sono rilasciati

Dettagli

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Problem Management Obiettivi Obiettivo del Problem Management e di minimizzare l effetto negativo sull organizzazione degli Incidenti e dei Problemi causati da errori nell infrastruttura e prevenire gli

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

Processi ITIL. In collaborazione con il nostro partner: Processi ITIL In collaborazione con il nostro partner: NetEye e OTRS: la piattaforma WÜRTHPHOENIX NetEye è un pacchetto di applicazioni Open Source volto al monitoraggio delle infrastrutture informatiche.

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

INTRODUZIONE, LINGUAGGIO, HANDS ON. Giuseppe Cirillo g.cirillo@unina.it

INTRODUZIONE, LINGUAGGIO, HANDS ON. Giuseppe Cirillo g.cirillo@unina.it INTRODUZIONE, LINGUAGGIO, HANDS ON Giuseppe Cirillo g.cirillo@unina.it Il linguaggio C 1972-Dennis Ritchie 1978-Definizione 1990-ANSI C 1966 Martin Richars (MIT) Semplificando CPL usato per sviluppare

Dettagli

Agilent OpenLAB Chromatography Data System (CDS)

Agilent OpenLAB Chromatography Data System (CDS) Agilent OpenLAB Chromatography Data System (CDS) EZChrom Edition e ChemStation Edition Requisiti hardware e software Agilent Technologies Informazioni legali Agilent Technologies, Inc. 2013 Nessuna parte

Dettagli

GESTIONE ATTREZZATURE

GESTIONE ATTREZZATURE SOLUZIONE COMPLETA PER LA GESTIONE DELLE ATTREZZATURE AZIENDALI SWSQ - Solution Web Safety Quality srl Via Mons. Giulio Ratti, 2-26100 Cremona (CR) P. Iva/C.F. 06777700961 - Cap. Soc. 10.000,00 I.V. -

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Posta Elettronica. Claudio Cardinali claudio@csolution.it

Posta Elettronica. Claudio Cardinali claudio@csolution.it Posta Elettronica Claudio Cardinali claudio@csolution.it Posta Elettronica: WebMail Una Webmail è un'applicazione web che permette di gestire uno o più account di posta elettronica attraverso un Browser.

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it

Zabbix 4 Dummies. Dimitri Bellini, Zabbix Trainer Quadrata.it Zabbix 4 Dummies Dimitri Bellini, Zabbix Trainer Quadrata.it Relatore Nome: Biografia: Dimitri Bellini Decennale esperienza su sistemi operativi UX based, Storage Area Network, Array Management e tutto

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

Milano, Settembre 2009 BIOSS Consulting

Milano, Settembre 2009 BIOSS Consulting Milano, Settembre 2009 BIOSS Consulting Presentazione della società Agenda Chi siamo 3 Cosa facciamo 4-13 San Donato Milanese, 26 maggio 2008 Come lo facciamo 14-20 Case Studies 21-28 Prodotti utilizzati

Dettagli

Architettura di un sistema informatico 1 CONCETTI GENERALI

Architettura di un sistema informatico 1 CONCETTI GENERALI Architettura di un sistema informatico Realizzata dal Dott. Dino Feragalli 1 CONCETTI GENERALI 1.1 Obiettivi Il seguente progetto vuole descrivere l amministrazione dell ITC (Information Tecnology end

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Indicizzazione terza parte e modello booleano

Indicizzazione terza parte e modello booleano Reperimento dell informazione (IR) - aa 2014-2015 Indicizzazione terza parte e modello booleano Gruppo di ricerca su Sistemi di Gestione delle Informazioni (IMS) Dipartimento di Ingegneria dell Informazione

Dettagli

FileMaker Server 13. Guida introduttiva

FileMaker Server 13. Guida introduttiva FileMaker Server 13 Guida introduttiva 2007-2013 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 Stati Uniti FileMaker e Bento sono marchi

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

RedDot Content Management Server Content Management Server Non sottovalutate il potenziale della comunicazione online: usatela! RedDot CMS vi permette di... Implementare, gestire ed estendere progetti

Dettagli

DigitPA egovernment e Cloud computing

DigitPA egovernment e Cloud computing DigitPA egovernment e Cloud computing Esigenze ed esperienze dal punto di vista della domanda RELATORE: Francesco GERBINO 5 ottobre 2010 Agenda Presentazione della Società Le infrastrutture elaborative

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi IL GESTIONALE DEL FUTURO L evoluzione del software per l azienda moderna Gestirsi / Capirsi / Migliorarsi IL MERCATO ITALIANO L Italia è rappresentata da un numero elevato di piccole e medie aziende che

Dettagli

Come difendersi dai VIRUS

Come difendersi dai VIRUS Come difendersi dai VIRUS DEFINIZIONE Un virus è un programma, cioè una serie di istruzioni, scritte in un linguaggio di programmazione, in passato era di solito di basso livello*, mentre con l'avvento

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

PLM Software. Answers for industry. Siemens PLM Software

PLM Software. Answers for industry. Siemens PLM Software Siemens PLM Software Monitoraggio e reporting delle prestazioni di prodotti e programmi Sfruttare le funzionalità di reporting e analisi delle soluzioni PLM per gestire in modo più efficace i complessi

Dettagli

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.

explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting. explora consulting s.r.l. Via Case Rosse, 35-84131 SALERNO - tel 089 848073 fax 089 384582 www.exploraconsulting.it info@exploraconsulting.it Procedura di gestione per Laboratori di Analisi Cliniche Pag.

Dettagli

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless La configurazione degli indirizzi IP Configurazione statica, con DHCP, e stateless 1 Parametri essenziali per una stazione IP Parametri obbligatori Indirizzo IP Netmask Parametri formalmente non obbligatori,

Dettagli

Boot Camp Guida all installazione e alla configurazione

Boot Camp Guida all installazione e alla configurazione Boot Camp Guida all installazione e alla configurazione Indice 4 Introduzione 5 Cosa ti occorre 6 Panoramica dell installazione 6 Passo 1: verifica la presenza di aggiornamenti. 6 Passo 2: apri Assistente

Dettagli

progettiamo e realizziamo architetture informatiche Company Profile

progettiamo e realizziamo architetture informatiche Company Profile Company Profile Chi siamo Kammatech Consulting S.r.l. nasce nel 2000 con l'obiettivo di operare nel settore I.C.T., fornendo servizi di progettazione, realizzazione e manutenzione di reti aziendali. Nel

Dettagli

CARATTERISTICHE DELLE CRYPTO BOX

CARATTERISTICHE DELLE CRYPTO BOX Secure Stream PANORAMICA Il sistema Secure Stream è costituito da due appliance (Crypto BOX) in grado di stabilire tra loro un collegamento sicuro. Le Crypto BOX sono dei veri e propri router in grado

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Integrated Development Environment (IDE) DevC++ 4.9.9.2

Integrated Development Environment (IDE) DevC++ 4.9.9.2 Integrated Development Environment (IDE) DevC++ 4.9.9.2 Manuale utente Data ultima revisione: 22/10/2008 Fondamenti di informatica Università Facoltà Corso di laurea Politecnico di Bari 1 a Facoltà di

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

SISSI IN RETE. Quick Reference guide guida di riferimento rapido

SISSI IN RETE. Quick Reference guide guida di riferimento rapido SISSI IN RETE Quick Reference guide guida di riferimento rapido Indice generale Sissi in rete...3 Introduzione...3 Architettura Software...3 Installazione di SISSI in rete...3 Utilizzo di SISSI in Rete...4

Dettagli

Guida alla scansione su FTP

Guida alla scansione su FTP Guida alla scansione su FTP Per ottenere informazioni di base sulla rete e sulle funzionalità di rete avanzate della macchina Brother, consultare la uu Guida dell'utente in rete. Per ottenere informazioni

Dettagli