Chapter 2. Il software di CMS

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Chapter 2. Il software di CMS"

Transcript

1 Chapter 2 Il software di CMS Negli ultimi esperimenti HEP (High Energy Physics) linguaggi e strumenti di ingegneria software orientati ad oggetti 1 sono diventati di uso comune per lo sviluppo delle infrastrutture software dedite all analisi fisica finale. Indirizzandosi verso tecniche object-oriented gli esperimenti HEP utilizzeranno database orientati ad oggetti per immagazzinare e gestire i dati sperimentali. Tutti i dati sono visti come oggetti persistenti 2 e possono essere accessibili attraverso un meccanismo di navigazione orientato ad oggetti. La quantità di dati che ogni esperimento produrrà all anno è dell ordine del PByte (10 15 Byte), un ordine di grandezza mai raggiunto prima dai precedenti esperimenti. Le risorse di calcolo [?] richieste sono così grandi che si pensa di soddisfarle da una rete costituita da più calcolatori distribuiti in tutti i laboratori che fanno parte dell esperimento e che useranno database ad oggetti distribuiti. I sistemi software su larga scala come quello di CMS richiedono: una struttura ben definita ed omogenea (architettura); applicazioni ripartite in entità gestibili (componenti/moduli); una comunicazione tra le parti definita in modo univoco (interfacce/protocolli). La Figura 2.1 illustra quelle che sono le relazioni tra le componenti fondamentali del software di CMS. La parte centrale è occupata da un framework 3 che realizza l architettura fornendo un interfaccia uniforme a tutti i moduli software di CMS ed in particolare si preoccupa di gestire i dati persistenti collegandosi direttamente ai vari 1 Nella programmazione orientata ad oggetti una classe rappresenta un tipo di dati che può contenere elementi in stretta relazione tra loro e che condividono gli stessi attributi; un oggetto, di conseguenza, è semplicemente una istanza di una classe. 2 La proprietà di un oggetto di poter essere immagazzinato su disco è detta persistenza. Un oggetto non persistente è detto transiente. 3 Un framework è un sistema che realizza un architettura; è essenzialmente un codice che invoca delle procedure (classi) che lavorano secondo un preciso ordine. 18

2 database (in basso in figura). Le principali applicazioni di CMS (in alto in figura) sono quelle che si interfacciano con l utente finale e usufruiscono di vari servizi software attraverso il framework. Figure 2.1: Le componenti fondamentali del software di CMS e le loro relazioni. Ogni applicazione è costituita da più moduli software; un esempio è illustrato in Figura 2.2 per il software di ricostruzione ed analisi di CMS (ORCA), all interno del quale è presente anche un modulo per la visualizzazione degli elementi sensibili del rivelatore e dell evento simulato e ricostruito. Figure 2.2: Moduli software di ORCA, il programma di ricostruzione ed analisi di CMS. Nel primo paragrafo di questo capitolo si parlerà del Framework e del Modello dei Dati di CMS; nel secondo paragrafo si accennerà ai diversi database attualmente in uso; nell ultimo paragrafo si illustrerà il software che l utente di CMS utilizzerà per le sue applicazioni, in particolare si parlerà del programma di ricostruzione e simulazione. 19

3 2.1 L architettura software di CMS La struttura dell architettura software di CMS è stata scelta per rispondere alle seguenti richieste [?]: ambienti multipli: vari moduli software devono essere in grado di girare in una varietà di ambienti (esempi di ambienti sono il trigger di terzo livello, lo sviluppo di programmi, l analisi dei dati fatta dal singolo ricercatore); migrazione tra gli ambienti: un modulo software può essere sviluppato in un certo ambiente, ma in seguito venire usato in altri ambienti non previsti precedentemente; sviluppo distribuito del codice: il software viene sviluppato da gruppi di persone sparse geograficamente, spesso da programmatori non professionisti; flessibilità: le richieste a cui deve soddisfare il sistema software in sviluppo non si conoscono a priori, pertanto quest ultimo deve essere facilmente adattabile; semplice uso: il sistema software deve essere facile da usare da parte della comunità dei fisici che spesso non è esperta di software. In base alle suddette richieste il software di CMS consiste di: un framework personalizzabile per ogni ambiente di calcolo; moduli software riguardanti la fisica con interfacce ben definite; un toolkit 4 di programmi di utilità e servizio che possono essere usati da ognuno dei moduli di fisica (ad esempio le librerie LHC++, cioè le varie librerie HEP). Il compito del framework è quello di un manager che delega le responsabilità e mantiene il controllo del flusso dei dati. Definisce come le cose devono essere e non cosa si deve fare [?]. Il framework di CMS è quello di simulazione, ricostruzione e analisi denominato COBRA (Coherent Objectoriented Base for simulation Reconstruction and Analysis) di cui si parlerà nel paragrafo Un toolkit è un insieme di generiche procedure (classi) che possono essere invocate per sviluppare nuove applicazioni. 20

4 I moduli di ricostruzione e simulazione, e il toolkit dei programmi di utilità specifici di ciascun rivelatore sono scritti dai fisici che si occupano del rivelatore. I moduli possono essere inseriti nel framework all atto dell esecuzione. Uno può scegliere tra diverse versioni di vari moduli. I moduli citati precedentemente non comunicano tra loro se non attraverso protocolli che sono parte del framework stesso. Il toolkit di programmi di utilità e servizio consiste di due categorie principali: i servizi riguardanti la fisica (istogrammi, algoritmi matematici, routine di calcolo geometrico e fisico..) e servizi di calcolo (accesso ai dati, comunicazione tra i moduli, interfaccia utente,..) e molto probabilmente non sarà specifico di CMS Il Framework di CMS COBRA si preoccupa di gestire trasparentemente i dati persistenti (la loro scrittura e lettura), il flusso dei dati durante la fase di simulazione e ricostruzione, e garantisce un interfaccia uniforme a tutto il codice di CMS. I due principali concetti implementati nel framework di COBRA per pilotare il processo di un evento sono l azione su richiesta e l invocazione implicita [?]. Questo implica che i moduli notificano a COBRA la loro esistenza all inizio del programma e COBRA li richiama quando sono necessari. In questo modo solo i moduli di cui realmente si ha bisogno vengono caricati in memoria ed eseguiti [?]. L invocazione implicita deve avvenire quando accade un particolare evento (cioè una condizione che provoca un cambiamento di stato nei vari oggetti del programma, da non confondere con l evento fisico). Tipici eventi sono la lettura dal rivelatore dei dati relativi ad una nuova interazione, un nuovo run, oppure una nuova configurazione del rivelatore. Per ogni evento esiste un particolare oggetto detto dispatcher che provvede alla sua gestione. Ogni modulo che vuole essere chiamato quando avviene un certo evento deve registrarsi come osservatore ( observer ) dell evento al dispatcher. All arrivo di un nuovo evento il dispatcher informa tutti gli osservatori registrati. Una parte fondamentale del framework è la modalità di gestione dei dati, per questo è importante elaborare un modello di dati Il Modello dei Dati di CMS Il modello dei dati di CMS presenta due aspetti: un modello logico, che descrive le classi, le loro relazioni e il meccanismo di navigazione tra i vari oggetti; 21

5 un modello fisico che descrive come i vari oggetti sono localizzati all interno dei vari file che costituiscono il database. COBRA permette al programma di analisi di vedere i dati secondo il modello logico, e di memorizzare i dati utilizzando un database orientato ad oggetti, secondo il modello fisico. La Figura 2.3 illustra una possibile schematizzazione del modello dei dati nell ambito della fisica delle alte energie in cui è messo in evidenza che, per poter fare analisi (user-tag), è importante avere le informazioni relative all evento, come le tracce, gli oggetti calorimetrici,... (Evento); queste informazioni vengono raccolte in Collezioni di Eventi. Ma è importante anche disporre delle informazioni d ambiente come l allineamento del Tracker, la calibrazione, lo stato del rivelatore quando è avvenuto l evento,... (Dati di Ambiente). Allo scopo di rendere più veloce la fase di analisi è possibile selezionare all interno di uno user-tag gli indici degli eventi che hanno soddisfatto un certo requisito. Figure 2.3: Rappresentazione generale del modello dei dati per la fisica delle alte energie. Ogni rettangolo rapresenta una classe, le frecce invece rappresentano le relazioni tra le classi. La figura mostra come partendo da un oggetto con attributi generali (Evento) si possa accedere (navigare) all informazione degli oggetti con attributi più specifici (tracce, oggetti calorimetrici). In particolare le frecce bidirezionali indicano la possibilità di navigare in entrambe le direzioni. Il modello dei dati di CMS si ispira al modello descritto in precedenza e quindi immagazzinerà informazioni come: 22

6 Evento: dati associati agli eventi, cioè dati associati alle collisioni tra fasci sia a livello di dati allo stato grezzo che a livello di ricostruzione (Figura 2.4), ovvero: RawEvent: i dati di un evento registrati dagli elementi del rivelatore in fase di presa dati o generati dal programma di simulazione; RecEvent: i dati dopo il processo di ricostruzione sia durante la presa dati che durante la simulazione; Figure 2.4: Le classi di un Evento: i RawEvent e i RecEvent. Dati di Ambiente: dati che descrivono le condizioni nel momento in cui è stato prodotto l evento (cioè le informazioni riguardanti l acceleratore LHC, la calibrazione e l allineamento del rivelatore, la geometria del rivelatore,..). Il Modello Logico Il modello logico per i RawEvent è illustrato in dettaglio in Figura 2.5. Figure 2.5: Modello Logico dei RawEvent: le principali classi di ricostruzione e le loro relazioni. Ogni RawEvent è composto da uno o più RawData associati a singole parti del rivelatore. L accesso ai RawData è fornito dai DetectorUnit attraverso i 23

7 ReadOutUnit. I DetectorUnit rappresentano una parte elementare del rivelatore e possono anche inglobare le proprietà geometriche e le calibrazioni. Questi oggetti vengono utilizzati per fornire l accesso agli hit ricostruiti (RecHit) ottenuti dopo la fase di digitizzazione 5. Per esempio all interno del Tracker l implementazione di questo modello è fatta seguendo la seguente corrispondenza (Figura 2.6). Ogni modulo del Tracker è un DetectorUnit; nel caso di un modulo del rivelatore a microstrisce a silicio (SST), come si è visto nel primo capitolo, l elettronica è costituita da 4 o 6 APV25 ognuno corrispondente ad un ReadOutUnit (ROU). Ma ogni APV25 è associato ad un vettore di Digi che contiene la carica rilasciata, RawData, su ogni singola strip dell APV25. Partendo dal modulo del Tracker si può avere accesso agli hit ricostuiti di quel modulo. Figure 2.6: Esempio di implementazione del modello logico dei RawEvent: corrispondenza tra le componenti hardware e software. Il modello logico per i RecEvent è illustrato in Figura 2.7. La figura mostra le relazioni tra le classi che intervengono nel meccanismo di ricostruzione su richiesta. La ricostruzione è gestita da oggetti specializzati per la ricostruzione denominati RecUnit che si registrano come osservatori al framework che notifica loro l arrivo di nuovi eventi. I RecUnit interagiscono con un oggetto denominato Reconstructor per creare il corrispondente RecObj. Diverse combinazioni Reconstructor/RecUnit possono produrre diverse versioni dello stesso RecObj che sono raccolte in collezioni; questo permette un semplice scambio o confronto di diversi algoritmi di ricostruzione. Un RecObj è una classe che identifica vari oggetti come le tracce, gli elettroni, i jet,... Per 5 Il risultato della simulazione sono i SimHit che ancora non sono uguali ai dati reali (Digi, ovvero le informazioni così come sono acquisite dall elettronica). La fase di digitizzazione serve a trasformare i SimHit in Digi. 24

8 Figure 2.7: Modello Logico dei RecEvent: gli oggetti di ricostruzione, le loro classi e le relazioni. esempio quando un utente richiede una collezione di tracce ricostruite con un algoritmo A (RecObj A), COBRA va a controllare se quella traccia esiste già, se così non è se la ricostruisce utilizzando la RecUnit che implementa l algoritmo di ricostruzione di tipo A (RecUnit A). COBRA fornisce il pieno supporto per rendere gli oggetti ricostruiti persistenti e per memorizzare diverse versioni della stessa collezione di RecObj. Una tipica applicazione di questo è la ri-ricostruzione del RecObj con lo stesso Reconstructor ma usando differenti calibrazioni, allineamenti o parametri per gli algoritmi di ricostruzione. Il Modello Fisico CMS attualmente sta utilizzando come database Objectivity/DB [?] (Object DataBase Management Systems) per gestire insiemi di oggetti persistenti. I dati persistenti sono immagazzinati all interno di una federazione (Federate Database) come mostra la Figura 2.8. Una federazione è un insieme di database distribuiti (cioè database che possono risiedere su diverse macchine e su diversi dischi e nastri). I database sono divisi in container, cioè collezioni di oggetti persistenti rappresentati fisicamente da file su disco. La lista di tutti i database e le loro locazioni fisiche sono contenute all interno di un catalogo. Ci sono due tipi di database: i database di Metadata che sono file di metadata ovvero di dati che descrivono altri dati e i database di Evento che contengono i dati relativi all evento. Questi ultimi database sono divisi in più database: quello per gli eventi, per gli hit in generale, per gli hit simulati, per i digi... Il motivo per cui ci sono database così numerosi è dovuto essenzialmente al fatto che si vogliono utilizzare dei file di dimensioni minori di 2 GB (limite 25

9 fisico dei più comuni file-system), ma anche per altri motivi. Ad esempio esiste anche un database per gli hit del Tracker, in quanto le informazioni del Tracker sono molto grandi (grande numero di canali di lettura) e non sempre vengono utilizzate, vengono usate solo quando l evento supera i tagli dovuti al trigger di secondo livello, per cui è opportuno che siano in un file separato. Figure 2.8: Struttura di una federazione. I database relativi all Evento sono identificati da un dataset ed un owner. Per esempio per i dati di MonteCarlo, un dataset viene usato per identificare il processo fisico simulato mentre l owner viene usato per identificare la località dove i dati vengono prodotti e le condizioni di simulazione, cioè in fase di bassa luminosità ( cm 2 s 1 ) o alta luminosità (10 34 cm 2 s 1 ) corrispondente ad un fondo ottenuto sovrapponendo rispettivamente 3.5±1.9 e 17.5±4.2 eventi di minimum bias (pile-up). Allo scopo di illustrare un esempio di dataset ed owner, considero il catalogo della federazione disponibile sulla farm di Bari. La Figura 2.9 illustra solo una parte del catalogo. La collezione di eventi è quella del decadimento dell Higgs in due elettroni e due muoni (dataset), nel caso dell esempio l owner è identificato dalla stringa evidenziata in rosa in cui risulta che gli eventi sono stati generati con pile-up (10 34 cm 2 s 1 ) e che la sede è la farm Bari. 26

10 Figure 2.9: Esempio di catalogo. Sono riportate solo alcune righe della lista dei database contenuti nel catalogo, in cui sono evidenziate con colori diversi le stringhe che rappresentano il dataset e l owner. 2.2 I DataBase di CMS È stato già descritto nel paragrafo precedente il database Objectivity che serve per immagazzinare tutte le informazioni relative agli eventi (l energia, il momento, gli hit, le tracce...). Descriviamo invece di seguito altri database usati da CMS Il Database di Descrizione del Rivelatore Il software offline di CMS, cioè quello per la ricostruzione, simulazione, analisi e visualizzazione, ha bisogno dei dati relativi al rivelatore. Da questo punto di vista ogni programma ha le sue esigenze specifiche: ad esempio il software per la simulazione ha bisogno di una descrizione altamente granulare di tutte le parti sensibili e non del rivelatore, mentre il software di ricostruzione per la ricostruzione delle tracce necessita solo della posizione e delle dimensioni degli elementi sensibili del Tracker. Per raggiungere questo in maniera coerente e consistente ogni applicazione deve consultare una sorgente comune di informazioni ovvero un database contenente la descrizione del rivelatore, questa sorgente è il DDD (Detector Description Database). La descrizione del rivelatore consiste di due parti: una descrizione del rivelatore ideale, che copre informazioni riguardanti la geometria, i materiali usati (aria, silicio, carbone,...), le posizioni e alcune costanti specifiche di ciascun rivelatore di CMS, ed un database delle condizioni di funzionamento dove vanno a finire tutte quelle quantità che variano nel tempo: le correzioni di allineamento e i dati di calibrazione dei vari sottorivelatori. 27

11 La descrizione ideale è definita in un database XML 6 (extensible Markup Language)[?], invece le informazioni sulle condizioni del rivelatore sono definite in altri database (MySQL, Oracle,...). La Figura 2.10 illustra l architettura del DDD. Le diverse applicazioni hanno un interfaccia comune al cuore del DDD, che consiste di un modello ad oggetti transiente strutturato secondo la descrizione del rivelatore ideale, ma esteso con le informazioni prese dal database delle condizioni. Indipendentemente dal formato delle sorgenti dei dati, le applicazioni accederanno in maniera trasparente ai dati. Figure 2.10: Architettura del Detector Description Database di CMS. Il DDD fornisce una API 7 (Application Programming Interface) in C++ che permette l accesso allo schema XML (contenuto in un file ascii) da parte di un qualsiasi programma. Questa procedura è stata utilizzata dal software di visualizzazione realizzato in questo lavoro di tesi. 6 L XML è un sottinsieme di SGML, cioè di un tipo di linguaggio usato per scrivere documenti HTML. 7 Una API costituisce una serie di funzioni che i programmi possono usare per chiedere dei servizi ad un sistema software. 28

12 2.2.2 Il Database della Costruzione Ogni sottorivelatore ha il proprio database di costruzione, ma qui parleremo solo del database del Tracker. Questo database contiene informazioni relative al processo di produzione dei moduli, come questi vengono assemblati, segue la loro storia dal momento in cui sono costruiti fino all integrazione del rivelatore completo. Ogni modulo del rivelatore è identificato in maniera univoca da un codice a barre in modo tale da poter seguire tutta la sua storia. Tutti i dati sono immagazzinati su un database centralizzato basato su Oracle. La costruzione del rivelatore è fatta da vari centri (test center) che mandano i dati al database centrale (Figura 2.11). Figure 2.11: Il database di costruzione. L interrogazione al database può essere fatta con una interfaccia java che a sua volta può essere usata da un programma di visualizzazione per rappresentare informazioni contenute nel database. Per esempio per visualizzare lo stato di produzione dei moduli con un unica mappa che rappresenta l intero apparato. Di questo esempio e di altri se ne parlerà in dettaglio nei prossimi capitoli. È prevista l esportazione di alcuni dati in altri database che verranno usati durante la presa dati, come quello della calibrazione, o quello dello slow control per controllare le condizioni (temperatura, tensioni,..) in cui lavora il rivelatore. Slow control e calibrazione fanno parte del sistema di 29

13 controllo del rivelatore I database del Sistema di Controllo del Rivelatore Il DCS (Detector Control System) è il sistema di controllo del rivelatore e in quanto tale deve disporre di un database che immagazzina le informazioni necessarie nella fase di presa dati. Nel caso del Tracker esso deve controllare da un lato le condizioni in cui lavora il rivelatore (temperatura, umidità, alte e basse tensioni,... ), dall altro tutti i parametri che caratterizzano la configurazione dell elettronica di front-end nonchè tutti i dati di calibrazione. È già previsto l uso di database Oracle collegati al sistema di controllo con tecnologia SCADA 8 (Supervisory Control And Data Acquisition). Anche in questo caso si può interfacciare un programma di visualizzazione per visualizzare i parametri critici permettendo così di semplificare il controllo dello stato del rivelatore. 2.3 Le applicazioni CMS In questo paragrafo parlerò di alcune delle applicazioni di CMS illustrate in Figura La generazione degli eventi e la simulazione La generazione degli eventi fisici è fatta utilizzando il programma CMKIN, basato attualmente su PYTHIA. CMKIN necessita in ingresso di file di datacard, cioè file ascii che contengono la descrizione dei canali di fisica da simulare, e scrive in uscita un ntupla. Questa ntupla insieme a file di data-card che descrivono i parametri da usare per la simulazione del rivelatore e ad alcuni file che descrivono le condizioni di simulazione (es. la geometria di CMS, il campo magnetico,...), viene letta dal programma di simulazione CMSIM [?] che rilascia in uscita un file in formato ZEBRA [?]. CMSIM è il pacchetto software di simulazione e descrizione del rivelatore basato su GEANT3 [?]. CMSIM legge gli eventi individuali dalle ntuple CMKIN e simula gli effetti di perdita di energia (bremsstrahlung, ionizzazione,...), scattering multiplo, sciami elettromagnetici o adronici nei materiali del rivelatore. L informazione è immagazzinata in forma di hit e contiene tutti i dettagli necessari per simulare la risposta del rivelatore. 8 SCADA è un toolkit per costruire applicazioni di controllo di sistema. Quello del Cern è basato su un prodotto commerciale delle ETM (www.etm.at). 30

14 Per i rivelatori traccianti (la parte interna del Tracker e il sistema muonico) l informazione immagazzinata si riferisce ai punti di ingresso e di uscita della traccia, al vettore momento nel punto d ingresso, al tipo di particella, all energia persa nel volume sensibile. Per i calorimetri gli hit simulati contengono l informazione relativa all energia depositata da uno sciame in un cristallo o nello scintillatore e il tempo in cui ciò è avvenuto. Oltre agli hit simulati, CMSIM immagazzina anche tracce e vertici simulati. Queste informazioni vengono usate per verificare le prestazioni della ricostruzione. I risultati della simulazione vengono immagazzinati in file ZEBRA e successivamente vengono importati nel software di ricostruzione (ORCA) e poi immagazinati nel database di Objectivity. La dimensione di un singolo evento è in media di 2 MB. Sia CMSIM che CMKIN sono programmi scritti in FORTRAN. Ben presto CMSIM sarà sostituito da un nuovo pacchetto software, attualmente in sviluppo, denominato OSCAR [?] (Object Oriented Simulation for CMS Analysis and Reconstruction), un programma scritto in C++ basato sul toolkit di GEANT4 [?]. OSCAR produrrà lo stesso tipo di informazioni di CMSIM con la differenza fondamentale che la simulazione dei processi elementari è fatta con GEANT4 invece che con GEANT3. Per simulare la risposta del rivelatore è necessario combinare il segnale relativo all evento di interesse con il segnale prodotto dagli eventi di fondo (eventi di pile-up) che risultano essere in media una ventina per ogni bunch crossing. Oltre ai 20 eventi contemporanei a quello di interesse vengono sovrapposte le risposte del rivelatore ad eventi che sono avvenuti a 5 bunch crossing precedenti e 3 successivi a quello che contiene l evento di interesse. Naturalmente ad ogni hit viene assegnato il tempo del bunch crossing a cui appartiene. Il numero di eventi di pile-up sarà quindi pari a 160, 20 per ciascuno degli 8 pacchetti vicini a quello contenente il segnale di interesse. Gli eventi di pile-up sono presi a caso da una collezione di eventi di miminum bias il cui numero è scelto abbastanza grande per assicurare che nello stesso evento di interesse non venga utilizzato per due volte lo stesso evento di minimum bias che invece può essere usato in eventi di interessse diversi. Questo metodo di riusare gli stessi eventi di pile-up è stato scelto per limitare le necessità di tempo di CPU. Questa fase, in cui si fa una accurata simulazione del comportamento del rivelatore, è detta fase di digitizzazione. In particolare si tiene conto del modo in cui viene acquisita l informazione da parte dell elettronica, ad esempio vengono aggiunti gli effetti dovuti al rumore. In generale si cerca di dare una simulazione la più possibile realistica del comportamento dell elettronica di ReadOut. 31

15 2.3.2 Il software di ricostruzione La ricostruzione è il processo di riduzione dei dati al fine di farne l analisi. Il processo di ricostruzione è visto come una collezione di unità di ricostruzione indipendenti (RecUnit), ognuna delle quali da in uscita un corrispondente insieme di oggetti ricostruiti (RecObj). Le unità di ricostruzione trattano: dati reali forniti dal sistema di acquisizione dati o dati di simulazione, oggetti prodotti da altre unità di ricostruzione, dati di ambiente come la descrizione del rivelatore, lo stato del rivelatore, la calibrazione, l allineamento, i parametri che gestiscono gli algoritmi di ricostruzione. Il processo di ricostruzione segue due fasi. La prima fase prevede una ricostruzione locale per ogni sottorivelatore. La seconda fase è la ricostruzione globale che fornisce gli oggetti ricostruiti (RecObj) per l analisi fisica. L attuale software di ricostruzione di CMS è ORCA (Object Oriented Reconstruction for CMS Analysis), usato per la ricostruzione degli oggetti del rivelatore (tracce, cluster, vertici,..) e per la ricostruzione degli oggetti fisici (jet, elettroni, muoni,..). Essendo il Tracker oggetto di questa tesi, mi soffermerò solo sulla sua ricostruzione focalizzando l attenzione sul processo di ricostruzione delle tracce. Nella fase della ricostruzione della traccia la maggiore difficoltà viene dal grande numero di RecHit per evento con cui si ha a che fare (circa in fase di alta luminosità e di un fattore 25 volte più basso in fase di bassa luminosità). Il design degli algoritmi dipende da molti aspetti del rivelatore: dalla forma delle traiettorie delle particelle all interno del campo magnetico, dalla geometria e performance del rivelatore. Pertanto non esiste un solo algoritmo di ricostruzione delle tracce, ma la collaborazione CMS ne ha sviluppato diversi. La ricostruzione delle tracce è divisa in 4 fasi. Nella prima fase vengono creati dei candidati di tracce in cui i parametri sono stimati a partire da un insieme limitato di informazioni. I candidati possono essere interni o esterni al Tracker; quelli esterni sono costruiti usando le informazioni del sistema di muoni e del sistema dei calorimetri, mentre quelli interni usando le informazioni del Tracker stesso. In questo caso l operazione di calcolo dei candidati parte dai RecHit di due strati del rivelatore, in particolare si parte dal rivelatore a pixel. Ogni coppia di RecHit costituisce un possibile candidato traccia. Per limitare il numero dei candidati si fanno delle ipotesi aggiuntive: che la traccia passi per il punto di interazione e che il momento abbia un certo valore minimo. Nella seconda fase si ha la costruzione della traccia. Questo è un processo iterativo: i candidati di traccia vengono usati per predire la posizione del 32

16 RecHit in uno strato successivo, se il RecHit è trovato è aggiunto alla traccia e i parametri della stessa sono modificati. L iterazione finisce quando tutti gli strati sono stati inclusi nella traccia e il numero di strati con RecHit è superiore ad un certo valore minimo. Nella terza fase vengono eliminate alcune delle tracce usando il seguente metodo: se due tracce condividono metá dei RecHit, solo la traccia migliore in termini di χ 2 viene conservata. L ultima fase permette di ottenere i parametri della traccia all origine estrapolando all indietro la traccia. 33

Nuovi oggetti grafici per la Visualizzazione del Tracker

Nuovi oggetti grafici per la Visualizzazione del Tracker Chapter 4 Nuovi oggetti grafici per la Visualizzazione del Tracker In questo capitolo illustrerò i nuovi oggetti grafici che ho sviluppato ed implementato nel software di visualizzazione di CMS. Prima

Dettagli

Lezione 22 Trigger. Trigger: seleziona gli eventi interessanti fra tutte le collisioni. Decide se l evento deve essere letto ed immagazzinato.

Lezione 22 Trigger. Trigger: seleziona gli eventi interessanti fra tutte le collisioni. Decide se l evento deve essere letto ed immagazzinato. : seleziona gli eventi interessanti fra tutte le collisioni. Decide se l evento deve essere letto ed immagazzinato. Sistema di acquisizione dati (DAQ): raccoglie i dati prodotti dall apparato e li immagazzina

Dettagli

3.1 La visualizzazione del rivelatore e degli eventi

3.1 La visualizzazione del rivelatore e degli eventi Chapter 3 La Visualizzazione 3.1 La visualizzazione del rivelatore e degli eventi 3.1.1 L Event Display Gli esperimenti di fisica delle alte energie investigano le reazioni tra le particelle elementari

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

Sistemi Operativi GESTIONE DELLA MEMORIA CENTRALE. D. Talia - UNICAL. Sistemi Operativi 6.1

Sistemi Operativi GESTIONE DELLA MEMORIA CENTRALE. D. Talia - UNICAL. Sistemi Operativi 6.1 GESTIONE DELLA MEMORIA CENTRALE 6.1 Gestione della Memoria Background Spazio di indirizzi Swapping Allocazione Contigua Paginazione 6.2 Background Per essere eseguito un programma deve trovarsi (almeno

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

Lezione 8. Motori di Ricerca

Lezione 8. Motori di Ricerca Lezione 8 Motori di Ricerca Basi di dati Un campo prevalente dell applicazione informatica è quello costituito dall archiviazione e dalla gestione dei dati (basi di dati). Sistema Informativo. Un 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

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

SOFTWARE. È l insieme delle istruzioni che è necessario fornire alla macchina per il suo funzionamento. Vi sono due categorie di software:

SOFTWARE. È l insieme delle istruzioni che è necessario fornire alla macchina per il suo funzionamento. Vi sono due categorie di software: 1 SOFTWARE È l insieme delle istruzioni che è necessario fornire alla macchina per il suo funzionamento. Vi sono due categorie di software: SOFTWARE DI SISTEMA (o di base), che deve gestire le funzioni

Dettagli

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

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

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

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

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

Dettagli

WEBsfa: l automazione della forza vendita via Web

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

Dettagli

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

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere:

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere: Modello OAIS Prof.ssa E. Gentile a.a. 2011-2012 Prof.ssa E. Gentile Progettazione e Produzione di Contenuti Digitali 1 Modello di riferimento Un modello di riferimento dovrebbe descrivere: le componenti

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

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

TEORIA sulle BASI DI DATI

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

Dettagli

Cataloghi per i dati aperti

Cataloghi per i dati aperti Progetto PerformancePA Ambito A - Linea 1 - Una rete per la riforma della PA Cataloghi per i dati aperti Autore: Vincenzo Patruno Creatore: Formez PA, Progetto Performance PA Diritti: Dipartimento della

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Progettaz. e sviluppo Data Base

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

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

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

Richiami di informatica e programmazione

Richiami di informatica e programmazione Richiami di informatica e programmazione Il calcolatore E una macchina usata per Analizzare Elaborare Collezionare precisamente e velocemente una grande quantità di informazioni. Non è creativo Occorre

Dettagli

Introduzione ai Sistemi Operativi

Introduzione ai Sistemi Operativi Introduzione ai Sistemi Operativi Sistema Operativo Software! Applicazioni! Sistema Operativo! È il livello di SW con cui! interagisce l utente! e comprende! programmi quali :! Compilatori! Editori di

Dettagli

Appunti di Sistemi Distribuiti

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

Dettagli

Reti di Telecomunicazione Lezione 6

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

Dettagli

Il CMS Moka. Giovanni Ciardi Regione Emilia Romagna

Il CMS Moka. Giovanni Ciardi Regione Emilia Romagna Il CMS Moka Giovanni Ciardi Regione Emilia Romagna Moka è uno strumento per creare applicazioni GIS utilizzando oggetti (cartografie, temi, legende, database, funzioni) organizzati in un catalogo condiviso.

Dettagli

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

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

Dettagli

Architetture Applicative

Architetture Applicative Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture

Dettagli

Stato del software per l analisi del test beam. 21/6/2002 Tommaso Boccali 1

Stato del software per l analisi del test beam. 21/6/2002 Tommaso Boccali 1 Stato del software per l analisi del test beam 21/6/2002 Tommaso Boccali 1 Analisi del test beam Review di quello che esiste 2 pacchetti software (TT6 e ROB) committati e usabili da tutti Set di macro

Dettagli

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa.

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa. La trasmissione dell informazione N.R2 La comunicazione tra due calcolatori si realizza tramite lo scambio di dati su un canale di comunicazione, esiste quindi un TRASMETTITORE che invia dei dati e un

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Protezione. Sistemi Operativi mod. B 16.1

Protezione. Sistemi Operativi mod. B 16.1 Protezione Scopi della Protezione Dominio di Protezione Matrice d Accesso Implementazione della Matrice d Accesso Revoca dei Diritti d Accesso Sistemi Basati su Abilitazioni Protezione basata sul linguaggio

Dettagli

Relazione introduttiva Febbraio 2006

Relazione introduttiva Febbraio 2006 Amministrazione Provincia di Rieti Febbraio 2006 1 Progetto Sistema Informativo Territoriale Amministrazione Provincia di Rieti Premessa L aumento della qualità e quantità dei servizi che ha caratterizzato

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA 1 Sistema Informativo Un sistema informativo (SI) è un componente di una organizzazione il cui obiettivo è gestire le informazioni utili per gli scopi dell

Dettagli

I Sistemi Informativi

I Sistemi Informativi I Sistemi Informativi Definizione Un Sistema Informativo è un mezzo per acquisire, organizzare, correlare, elaborare e distribuire le informazioni che riguardano una realtà che si desidera descrivere e

Dettagli

Laboratorio Matematico Informatico 2

Laboratorio Matematico Informatico 2 Laboratorio Matematico Informatico 2 (Matematica specialistica) A.A. 2006/07 Pierluigi Amodio Dipartimento di Matematica Università di Bari Laboratorio Matematico Informatico 2 p. 1/1 Informazioni Orario

Dettagli

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

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

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

Dettagli

Cataloghi per i dati aperti

Cataloghi per i dati aperti Cataloghi per i dati aperti Questo materiale didattico è stato realizzato da Formez PA nel Progetto PerformancePA, Ambito A Linea 1, in convenzione con il Dipartimento della Funzione Pubblica, organismo

Dettagli

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

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

Dettagli

Archivi e database. Lezione n. 7

Archivi e database. Lezione n. 7 Archivi e database Lezione n. 7 Dagli archivi ai database (1) I dati non sempre sono stati considerati dall informatica oggetto separato di studio e di analisi Nei primi tempi i dati erano parte integrante

Dettagli

Altri metodi di indicizzazione

Altri metodi di indicizzazione Organizzazione a indici su più livelli Altri metodi di indicizzazione Al crescere della dimensione del file l organizzazione sequenziale a indice diventa inefficiente: in lettura a causa del crescere del

Dettagli

Introduzione all elaborazione di database nel Web

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

Dettagli

Sistema di Trigger e di Acquisizione dati di CMS c 2008 by Antonio Pierro November 3, 2008

Sistema di Trigger e di Acquisizione dati di CMS c 2008 by Antonio Pierro November 3, 2008 Sistema di Trigger e di Acquisizione dati di CMS c 2008 by Antonio Pierro November 3, 2008 1 Introduzione Dal punto di vista del computing, il DAQ di CMS consiste in un grande ambiente di calcolo distribuito,

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Sistemi di gestione delle basi di dati 1 Cos è un DBMS? Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni (ad esempio, Madonna

Dettagli

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Funzioni di Esportazione Importazione 1 Indice AIRONE GESTIONE RIFIUTI... 1 FUNZIONI DI ESPORTAZIONE E IMPORTAZIONE... 1 INDICE...

Dettagli

Le Basi di Dati. Le Basi di Dati

Le Basi di Dati. Le Basi di Dati Le Basi di Dati 20/05/02 Prof. Carlo Blundo 1 Le Basi di Dati Le Base di Dati (database) sono un insieme di tabelle di dati strutturate in maniera da favorire la ricerca di informazioni specializzate per

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

Architettura di un computer

Architettura di un computer Architettura di un computer Modulo di Informatica Dott.sa Sara Zuppiroli A.A. 2012-2013 Modulo di Informatica () Architettura A.A. 2012-2013 1 / 36 La tecnologia Cerchiamo di capire alcuni concetti su

Dettagli

VisualTailor. Il software di configurazione tecnico commerciale ad hoc

VisualTailor. Il software di configurazione tecnico commerciale ad hoc VisualTailor Il software di configurazione tecnico commerciale ad hoc devo creare le specifiche per realizzare un prodotto personalizzato su richiesta dei miei clienti!!! Come devo fare????? Visual Tailor

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

Dettagli

Aspetti applicativi e tecnologia

Aspetti applicativi e tecnologia Aspetti applicativi e tecnologia Premessa Architetture usate per i database Le prime applicazioni erano definite monolitiche, cioè un unico computer (mainframe) gestiva sia le applicazioni che i dati,

Dettagli

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale della Logistica e della Produzione Una piattaforma per la negoziazione di servizi business to

Dettagli

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

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

Dettagli

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

Requisiti della Business Intelligence

Requisiti della Business Intelligence Realizzazione di un sistema informatico on-line bilingue di gestione, monitoraggio, rendicontazione e controllo del Programma di Cooperazione Transfrontaliera Italia - Francia Marittimo finanziato dal

Dettagli

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

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

Dettagli

Strumento evoluto di Comunicazione con i Venditori

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

Dettagli

Struttura logica di un programma

Struttura logica di un programma Struttura logica di un programma Tutti i programmi per computer prevedono tre operazioni principali: l input di dati (cioè l inserimento delle informazioni da elaborare) il calcolo dei risultati cercati

Dettagli

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it

Basi di dati. Gabriella Trucco gabriella.trucco@unimi.it Basi di dati Gabriella Trucco gabriella.trucco@unimi.it Esempio Quando si pensa ad un database, generalmente si immagina una tabella contenente grandi quantità di informazioni, sulla quale è possibile

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Organizzazione della memoria

Organizzazione della memoria Memorizzazione dati La fase di codifica permette di esprimere qualsiasi informazione (numeri, testo, immagini, ecc) come stringhe di bit: Es: di immagine 00001001100110010010001100110010011001010010100010

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

MECCANISMI E POLITICHE DI PROTEZIONE 13.1

MECCANISMI E POLITICHE DI PROTEZIONE 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

SH.Invoice è un software pratico e completo per la gestione della fatturazione di professionisti e imprese.

SH.Invoice è un software pratico e completo per la gestione della fatturazione di professionisti e imprese. Presentazione: SH.Invoice è un software pratico e completo per la gestione della fatturazione di professionisti e imprese. Il programma si distingue per la rapidità e l elasticità del processo di gestione

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

Plone all Università di Ferrara - Case Study

Plone all Università di Ferrara - Case Study Plone all Università di Ferrara - Case Study Francesco Margutti, Cesare Stefanelli, Luca Tebaldi Università di Ferrara, Italia {francesco.margutti, cesare.stefanelli, luca.tebaldi}@unife.it 1. L Università

Dettagli

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o Navigare verso il cambiamento La St r a d a p i ù semplice verso il ca m b i a m e n t o Le caratteristiche tecniche del software La Tecnologia utilizzata EASY è una applicazione Open Source basata sul

Dettagli

DATABASE. Progettare una base di dati. Database fisico e database logico

DATABASE. Progettare una base di dati. Database fisico e database logico DATABASE Progettare una base di dati Database fisico e database logico Un DB è una collezione di tabelle, le cui proprietà sono specificate dai metadati Attraverso le operazioni sulle tabelle è possibile

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

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Implementazione di MVC. Gabriele Pellegrinetti

Implementazione di MVC. Gabriele Pellegrinetti Implementazione di MVC Gabriele Pellegrinetti 2 Come implementare il pattern Model View Controller con le tecnologie JSP, ASP e XML Implementazione del pattern MVC in Java (JSP Model 2) SUN è stato il

Dettagli

Sistemi Operativi. Organizzazione logica ed implementazione di un File System

Sistemi Operativi. Organizzazione logica ed implementazione di un File System Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Organizzazione logica ed implementazione di un File

Dettagli

Database. Si ringrazia Marco Bertini per le slides

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

Dettagli

ASPETTI GENERALI DI LINUX. Parte 2 Struttura interna del sistema LINUX

ASPETTI GENERALI DI LINUX. Parte 2 Struttura interna del sistema LINUX Parte 2 Struttura interna del sistema LINUX 76 4. ASPETTI GENERALI DEL SISTEMA OPERATIVO LINUX La funzione generale svolta da un Sistema Operativo può essere definita come la gestione dell Hardware orientata

Dettagli

TYPO3 in azione con l infrastruttura ZEND: affidabilità e sicurezza. Mauro Lorenzutti CTO di Webformat srl mauro.lorenzutti@webformat.

TYPO3 in azione con l infrastruttura ZEND: affidabilità e sicurezza. Mauro Lorenzutti CTO di Webformat srl mauro.lorenzutti@webformat. TYPO3 in azione con l infrastruttura ZEND: affidabilità e sicurezza Mauro Lorenzutti CTO di Webformat srl mauro.lorenzutti@webformat.com Scaletta Test di performance Monitoring e reportistica errori Integrazione

Dettagli

Scheduling della CPU

Scheduling della CPU Scheduling della CPU Sistemi multiprocessori e real time Metodi di valutazione Esempi: Solaris 2 Windows 2000 Linux 6.1 Sistemi multiprocessori simmetrici Fin qui si sono trattati i problemi di scheduling

Dettagli

Corso di Sistemi Operativi Ingegneria Elettronica e Informatica prof. Rocco Aversa. Raccolta prove scritte. Prova scritta

Corso di Sistemi Operativi Ingegneria Elettronica e Informatica prof. Rocco Aversa. Raccolta prove scritte. Prova scritta Corso di Sistemi Operativi Ingegneria Elettronica e Informatica prof. Rocco Aversa Raccolta prove scritte Realizzare una classe thread Processo che deve effettuare un numero fissato di letture da una memoria

Dettagli

Modulo informatica di base 1 Linea 2

Modulo informatica di base 1 Linea 2 Modulo informatica di 1 Linea 2 Mattia Dip. di Informatica e Comunicazione Università degli Studi di Milano, Italia mattia.monga@unimi.it a.a. 2010/11 1 c 2010 M.. Creative Commons Attribuzione-Condividi

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

JSIS JSIS L architettura JSIS

JSIS JSIS L architettura JSIS JSIS JSIS L architettura JSIS La piattaforma JSIS Java Solution Integrated Suites, interamente realizzata dai nostri laboratori di sviluppo software, è una soluzione che integra la gestione di diverse

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 3-Compilatori e interpreti 1 Prerequisiti Principi di programmazione Utilizzo di un compilatore 2 1 Introduzione Una volta progettato un algoritmo codificato in un linguaggio

Dettagli

Introduzione alle basi di dati (prima parte)

Introduzione alle basi di dati (prima parte) Introduzione alle basi di dati (prima parte) Università degli Studi di Salerno Corso di Laurea in Scienze della Comunicazione Informatica generale (matr. Dispari) Docente: Angela Peduto A.A. 2007/2008

Dettagli

Università degli Studi di Bologna Bologna, 12/12/2002 Corso di Laurea In Informatica. Alessandro Valenti. Sessione II

Università degli Studi di Bologna Bologna, 12/12/2002 Corso di Laurea In Informatica. Alessandro Valenti. Sessione II Università degli Studi di Bologna Bologna, 12/12/2002 Corso di Laurea In Informatica Alessandro Valenti Sessione II Anno Accademico 2001-2002 SOMMARIO: Scenario Data Integration Il Servizio AnaWeb Web

Dettagli

Automazione Industriale 4- Ingegneria del Software

Automazione Industriale 4- Ingegneria del Software Automation Robotics and System CONTROL Università degli Studi di Modena e Reggio Emilia Automazione Industriale 4- Ingegneria del Software Cesare Fantuzzi (cesare.fantuzzi@unimore.it) Ingegneria Meccatronica

Dettagli

disponibili nel pacchetto software.

disponibili nel pacchetto software. Modulo syllabus 4 00 000 00 0 000 000 0 Modulo syllabus 4 DATABASE 00 000 00 0 000 000 0 Richiede che il candidato dimostri di possedere la conoscenza relativa ad alcuni concetti fondamentali sui database

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

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

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

Dettagli