BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei"

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini ( ) Abstract L obiettivo di questo articolo è descrivere la progettazione e l implementazione di un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web con software di comune distribuzione nelle macchine locali. Il sistema è stato poi esteso per aumentare la QoS introducendo un cluster di server. 1 Introduzione Questo progetto nasce da una esigenza sempre più comune nello sviluppo di sistemi software: la collaborazione tra elementi eterogenei, ovvero scritti in linguaggi diversi ed operanti in diversi sistemi operativi. Lo scopo del progetto è fornire un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web (installata su un server) con software di comune distribuzione nelle macchine locali (es: Microsoft Outlook e Microsoft Pocket Outlook). Poiché i dati possono essere modificati sia sui dispositivi locali che sul server, la sincronizzazione deve essere intelligente, cioè deve poter capire a quale dei due sistemi prestar fede, e prevedere diverse politiche di sincronizzazione e variarla nel tempo, eventualmente prevedendo la possibilità di interpellare l utente stesso in caso di dubbio. Si consideri inoltre che, mentre il server web è sempre on-line, gli altri sistemi possono effettuare modifiche anche off-line e solo in seguito eseguire la sincronizzazione. Nella prossima parte sarà analizzato il problema nei suoi aspetti critici, sondando possibili alternative di soluzione. La terza sezione tratterà delle scelte effettuate nella soluzione, e la quarta mostrerà i dettagli principali dell implementazione. La quinta parte esaminerà un estensione del sistema, introducendo la replicazione del server. 2 Analisi del problema Il problema evidenzia tre importanti aspetti che devono essere affrontati con riguardo: l eterogeneità, il coordinamento tra le entità e le politiche di sincronizzazione. 2.1 Eterogeneità Le entità sono in generale software diversi che girano su piattaforme diverse, e soprattutto che organizzano le informazioni in modo diverso. Perciò è necessario in qualche modo tradurre le informazioni in una struttura logica unica per poterle confrontare. Questa potrebbe essere una struttura astratta creata dal sistema o un vero e proprio file esportato dalle diverse entità in uno standard comune. Questo secondo caso appare più interessante in

2 quanto permette la progettazione di un unico software di sincronizzazione, di cui qualunque programma di terze parti può usufruire previa la realizzazione di un plugin di esportazione ad hoc. 2.2 Coordinamento tra entità La presenza del server web sempre on-line richiama subito l idea di un sistema client/server, che facilita molto la sincronizzazione in quanto è possibile permettere ad una sola entità di monitorare l intera operazione. Questo modello però comporta un alto carico di lavoro sul server, che è prevedibile lavori con diversi utenti contemporaneamente. Non è perciò da escludere una implementazione secondo il modello P2P, considerando che ogni entità ha, a prescindere, la stessa veridicità per quanto riguarda le informazioni che contiene. 2.3 Politiche di sincronizzazione Occorre considerare innanzitutto che in generale le entità, escluso il server web, potrebbero effettuare modifiche sulle informazioni in modalità off-line. Inoltre lo stesso utente potrebbe voler attualizzare le informazioni da due dispositivi diversi contemporaneamente. La sincronizzazione deve essere quindi un operazione atomica, perché sia garantita la consistenza dei dati. Il sistema deve poi prevedere diverse politiche di sincronizzazione, dipendenti dal tempo (ad esempio: è la prima sincronizzazione, e quindi in generale le informazioni locali non sono aggiornate, o il contrario) e dal luogo (ossia dal dispositivo); occorre quindi che queste politiche siano facilmente modificabili e che il sistema ne sia indipendente. 3 Scelte progettuali 3.1 Eterogeneità e politiche di sincronizzazione Il problema dell eterogeneità ha portato alla scelta del Java come linguaggio di implementazione, in quanto è indipendente dalla piattaforma su cui gira, ed è largamente diffuso anche nelle tecnologie mobili. Per permettere il confronto dei dati si è pensato ad un formato standard in cui rappresentarli, ed è stato scelto come linguaggio l Xml, standard sempre più in uso che presenta forti vantaggi in quanto a usabilità e leggerezza, nonché diffusione. Sarà necessario perciò realizzare un exporter (in un linguaggio di programmazione qualunque!) per ogni diverso sistema che vuole interagire attraverso la nostra applicazione. Ma, grazie a questo standard, è anche possibile immaginare che vengano implementati sistemi a partire dal formato Xml da noi utilizzato come standard. Sarà utilizzato l Xml anche per la definizione delle politiche da seguire, rendendone così facile la configurazione. 3.2 Coordinamento Il nostro sistema presenta una forte asimmetria: da una parte abbiamo un server web, sempre on-line ma che deve gestire l accesso di più utenti allo stesso tempo (e anche dello stesso utente da più postazioni); dall altra delle entità che lavorano sia on-line che off-line, e lavorano con un singolo utente. Perciò, nonostante le riflessioni sulla parità di ruolo di tutte le entità, la scelta più efficace appare essere quella di un sistema client/server. È però necessario che il carico di lavoro sul server sia minimo. Ogni operazione di sincronizzazione è quindi effettuata rispetto al server, visto che è l unica entità sempre on-line, il quale ha quindi il solo compito di fornire la sua versione dei dati, nonché di impedire l accesso ai dati dello stesso utente da più postazioni, e garantire l atomicità e la consistenza delle operazioni di sincronizzazione. Compito del client è quindi fare richiesta di sincronizzazione al server ed effettuare il confronto dei dati. In questo modo sarebbe anche facilmente implementabile una politica che preveda l interrogazione diretta del client: l esecuzione avverrebbe sempre in locale, e non comporterebbe un carico di lavoro maggiore da parte del server e della rete. 4 Implementazione Il middleware è stato implementato tralasciando, oltre agli exporter (che come si è già detto sono componenti di fatto esterne al sistema), l interfaccia grafica. È perciò contemplata ma non implementata la possibilità di interrogare direttamente l utente in caso di dubbio. 2

3 Il sistema comprende due sottosistemi in comunicazione tra loro: il client e il server. Entrambi sono stati realizzati secondo una logica di layer, così da facilitare la modifica ed il riutilizzo dei componenti. Local Software WebServer-DB GUI Importer Policy Importer Application Layer Application Layer Network Layer Network Layer Disegno 1: Layers L atomicità dell operazione è realizzata tramite le operazioni di Lock e UnLock che operano sul server a livello Application. In figura 1 e 2 sono riportate le strutture logiche del Client e del Server, ad un livello di astrazione tale da riportare solo i metodi essenziali. Figura 1 Il client ruota attorno alla classe AppLayer, che si serve delle altre classi del sistema. Il dialogo col server è reso trasparente grazie alla classe NetLayer, che implementa il layer di rete, la quale, una volta istanziata, maschera tutto il dialogo di rete con due chiamate di invio e ricezione di file. Figura 2 Il server è stato implementato a partire dal basic remoting pattern Singleton. Questo ci permette di avere una classe istanziata una sola volta, la classe Framework, che, oltre a prendersi carico dell inizializzazione dello Stub e quindi dell infrastruttura di rete, gestisce il delicato accesso alla LockList, nonché la classe LockManager, responsabile di monitorare la lista. Essendo un singleton ha tra l altro il vantaggio di poter essere chiamata da chiunque ne abbia la visibilità (come il NetLayer). Si noti inoltre la classe NetUtility: questa classe composta esclusivamente di metodi statici si può considerare come un semplice middleware per standardizzare la comunicazione tra i componenti del sistema. Fornisce il passaggio di due tipi di dato: messaggio e file. La classe XmlUtility provvede invece tutti i metodi per manipolare i file xml. L interazione tra client e server è riportata in fig. 3. Come si vede il server ha un comportamento passivo, in quanto aspetta le interrogazioni del client e non è preoccupato dell esito dell operazione. Al contrario il client conosce perfettamente l esito delle operazioni e, in caso di errore, può agire di conseguenza. 3

4 Figura 3 L interazione è divisa in due fasi: lock e sync. Questa divisione non è solo logica: la connessione viene chiusa alla fine di ogni fase. Questo per ottimizzare l utilizzo della banda e minimizzare l occupazione delle porte del server. Inoltre, pensando alla possibilità che il processo di sincronizzazione interagisca con l utente, evita di mantenere aperta una connessione inoperosa. In questo modo però il server resterebbe all oscuro di un eventuale fallimento del processo di sincronizzazione, e non potrebbe eliminare la lock effettuata dal client. Per questo è stato pensato un monitor che, dato un tempo massimo di validità della lock, controlla periodicamente il registro di lock per scartare le entry scadute. L eterogeneità è stata risolta, come detto, dall utilizzo di un formato standard basato sull Xml. Il layer Application del client quindi effettuerà una comparazione tra il documento locale, riportato dall Importer, e quello remoto, ricevuto dal Network Layer. Le scelte saranno guidate dalla politica impostata nel file di policy, anch esso in xml. Un esempio di file di policy è il seguente: <?xml version="1.0" encoding="iso "?> <!-- Local: creato in locale. Remote: creato in rem.--> <policy> <new> <!-- possibilità: keep/skip/ask --> <local> keep </local> <remote> skip </remote> </new> <different> <!-- possibilità: keeplocal/keepremote/ask--> <localnewer> keeplocal </localnewer> <remotenewer> keeplocal </remotenewer> <samedate> keepremote </samedate> </different> </policy> Il sistema è stato sviluppato con il framework Eclipse usando Java JRE 1.5. E stato testato in ambiente Windows. 5 Estensione: Server replicati Vogliamo ora incrementare la Qualità del Servizio del nostro sistema. In particolare vogliamo far sì che, in caso di caduta del server, sia ancora possibile fruire del servizio in modo trasparente all utente che lavora da un dispositivo client: vogliamo quindi garantire un servizio sempre attivo 24/7. Visto che abbiamo considerato l exporter server-db come un componente esterno, non ci occuperemo della fault-tolerance del database, in quanto supporremo già fornito da terze parti. Nel nostro sistema fornire un servizio attivo 24/7 vuol dire far si che, in caso di caduta di un server, ce ne sia un altro che possa fornire lo stesso servizio, e questo conservando l atomicità dell azione rispetto all utente. Quindi è necessario avere un sistema replicato in cui tutti i server vedano la tabella dei lock aggiornata. La soluzione proposta prevede di avere un cluster di server secondo il modello del bilanciamento di carico. Ogni copia può realizzare il protocollo di scambio con il client, e il sistema provvede alla sincronizzazione e al bilanciamento. 4

5 Per la gestione dei server si introduce un nuovo componente, chiamato Broker, che dovrà occuparsi della ricezione della richiesta da parte del client, l assegnazione di un server, nonché del monitoraggio e della sincronizzazione del cluster. In questo modo, però, il collo di bottiglia creato dalla possibile caduta del server è solo spostato ad un altra entità. Per questo anche il Broker dovrà essere a sua volta replicato. Figura 4 Il client ora non interrogherà più direttamente il server, ma dovrà contattare il broker. Questi gli dovrà passare il riferimento ad un server. Perciò cambierà leggermente il protocollo di comunicazione, che sarà realizzato come in figura 5. Come si può vedere, dal lato client c è un solo significativo cambiamento: la contrattazione del server come fase iniziale. Contrattazione determinata dalla presenza del messaggio change server. Anche dal lato server i cambiamenti sono minimi: la possibilità di ricevere un ping e il messaggio di lock indiretto lock <username> ##Broker, il cui significato sarà spiegato in seguito. La limitatezza di queste modifiche fa si che sia il client che il server siano ancora compatibili con il precedente protocollo: è ancora possibile la comunicazione diretta client-server senza alcuna mediazione. L introduzione del broker ci permette di delegare a questi il monitoraggio ed il bilanciamento dei server. Il broker sarà in possesso di una lista dei server attivi e di una lista dei server offline, e istanzierà dei processi di monitoraggio per poter aggiornare il contenuto delle liste. In particolare saranno presenti due oggetti attivi, ServerManager e ServerRestore. Il primo monitorerà i server attivi, e, in caso di caduta di uno di questi, li sposterà nella lista dei server offline. Il secondo controllerà i server offline tentando di ripristinare quelli che sono tornati raggiungibili. La struttura logica del broker è riportata in figura 6. Figura 6 Figura 5 La ServerList è stata implementata come un singleton doppio, estendendo la 5

6 peculiarità del singleton alle due liste di cui necessitiamo. Si noti che, nonostante l analogia col server, la classe Broker non è un singleton come la classe server.application.framework. Questo perché nel broker tutta la parte a livello di applicazione riguarda la ServerList, e perciò è a questa classe che è stato applicato il pattern. Le informazioni dei server sono incapsulati nella classe serializable ServerInfo. E perciò possibile inviarli ad oggetti remoti (quali i client) grazie ai nuovi metodi getobj e sendobj aggiunti alla classe NetUtility, a cui è stata anche aggiunta la funzione connect(serverinfo). La ServerList incapsula i server nella classe ServerListInfo, che estende la ServerInfo aggiungendo l attributo use che permette di utilizzare un algoritmo di bilanciamento di carico: ad ogni chiamata getworkingserver viene scelto il server con il parametro use maggiore, e allo stesso tempo viene incrementato di uno il valore di tutti i server. I parametro del server scelto viene poi decrementato del numero dei server presenti. Viene qui assunta nuovamente una politica positivista: il server ritornato è sicuramente on-line. Questa scelta, basata sull esistenza di un doppio monitoraggio (si veda il prossimo capoverso), permette di risparmiare il tempo altrimenti perso da una verifica dello stato del server. La sincronizzazione viene effettuata con una strategia positivista al momento stesso delle chiamata da parte dell utente: mentre il server scelto viene messo in comunicazione con l utente, agli altri server viene inviata la stessa richiesta con il suffisso ##Broker. Questo viene codificato dal server come una richiesta differente, in quanto eseguirà solo le operazioni che riguardano la lock. In questo modo si suppone che l esecuzione sul server scelto vada a buon fine. Questa scelta è stata dettata dalla volontà di minimizzare i cambiamenti, e supportata dalla relativa semplicità dell operazione. Si è deciso quindi di seguire una politica simile all aggiornamento eager di tutte le copie, ma le copie secondarie eseguono l operazione solo parzialmente, e non c è una fase di accordo finale. La chiamata agli altri server viene eseguita attraverso il ServerManager: questo permette di aggiornare la lista dei server attivi. Il ServerManager può essere eseguito anche come processo indipendente che si ripete ad intervalli regolari, in modo da migliorare il throughput al momento della richiesta da parte del cliente nel caso di un lungo intervallo di inattività del sistema. Il ServerRestore viene istanziato come un processo indipendente che, ad intervalli regolari, effettua una ping su tutti i server offline. Nel caso di risposta affermativa avvia la procedura di restore schematizzata in figura 7. Figura 7 Viene richiesto alla ServerList un WorkingServer, e a questi viene richiesto di comunicare al server in fase di restoring la lista delle lock. In seguito viene reinserito tra i server attivi. L operazione usa nuovamente i metodi sendobj e receiveobj di NetUtility, perciò anche la classe Lock ora implementa l interfaccia Serializable. La replicazione del broker è realizzata attraverso un cluster statico (nel nostro caso 2 istanze) a copie attive, una primaria ed una secondaria: entrambi i broker possono operare in maniera indipendente, e non è necessaria nessuna fase di aggiornamento tra i due, in quanto ognuno monitora comunque i server attivi. Il client avrà l indirizzo di entrambi, e potrà 6

7 accedere alla copia secondaria in caso non sia disponibile quella primaria. Sarebbe interessante, come attività futura, sviluppare in modo più completo questa replicazione, ad esempio condividendo tra i broker le informazioni di bilanciamento del carico dei server, o sfruttando il broker secondario per il controllo dello stato dei server. Le modifiche al client per adattarlo a questa estensione sono minime: è stato modificato unicamente il layer di rete, introducendo la possibilità della contrattazione del server con il broker, ad eccezione dell aggiunta di un ulteriore parametro nella configurazione per conoscere anche l indirizzo del broker secondario. Si è approfittato del cambiamento per eseguire anche una refactory del codice sfruttando la nuova classe ServerInfo dove possibile. E possibile eliminare il broker e creare un sistema di coordinamento per cui un server si prende dinamicamente l incarico di coordinatore. E possibile implementare un layer di rete alternativo che utilizzi un altra tecnologia (es: bluetooth) per la comunicazione tra un dispositivo comunque connesso alla rete (che può comportarsi quindi come un server, essendo sincronizzato con il server principale) ed uno che non può connettersi. Il server ha subito anch esso i cambiamenti principalmente nel Network Layer, per adattarlo alle nuove funzionalità come la comunicazione con il broker ed il restoring, ed ha subito qualche modifica anche nel layer applicativo: oltre alla modifica già citata della classe Lock, si sono aggiunti nuovi metodi nel Framework e nella LockList per l invio e la ricezione dell intera lista. 6 Conclusioni È stato realizzato un middleware di sincronizzazione per sistemi eterogenei, che prevede l utilizzo di un formato standard basato sull xml per il confronto dei dati, la possibilità di definire politiche di sincronizzazione anch esse in xml, che si basa su di un modello client/server. Il middleware è stato progettato ed implementato, rispondendo a tutti i requisiti. Lo si è poi esteso aumentandone la Qualità di Servizio, introducendo un cluster di server gestito da un broker a sua volta replicato. Grazie ad una politica positivista, il servizio non ha perso significativamente velocità, guadagnando in disponibilità. 6.1 Sviluppi futuri E possibile modificare il cluster di server utilizzando una politica non positivista, e quindi con un protocollo di coordinazione tra broker e server più complesso ma più affidabile. 7

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

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

Dettagli

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

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE INTRODUZIONE L ingegneria del software è la disciplina tecnologica e gestionalerelativa alla realizzazione sistematica e alla manutenzione di un software rispettando

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

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

Dettagli

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli

Progetto Virtualizzazione

Progetto Virtualizzazione Progetto Virtualizzazione Dipartimento e Facoltà di Scienze Statistiche Orazio Battaglia 25/11/2011 Dipartimento di Scienze Statiche «Paolo Fortunati», Università di Bologna, via Belle Arti 41 1 La nascita

Dettagli

Architettura SW Definizione e Notazioni

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

Dettagli

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

Concetti base. Impianti Informatici. Web application

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

Dettagli

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 1. ABSTRACT Al giorno d oggi, l enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che

Dettagli

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

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

Dettagli

Ingegneria del Software Progettazione

Ingegneria del Software Progettazione Ingegneria del Software Progettazione Obiettivi. Approfondire la fase di progettazione dettagliata che precede la fase di realizzazione e codifica. Definire il concetto di qualità del software. Presentare

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

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

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

Applicazione: SAI - Sistema di Audit Interno

Applicazione: SAI - Sistema di Audit Interno Riusabilità del software Catalogo delle applicazioni: Amministrativo/Contabile Applicazione: SAI Sistema di Audit Interno Amministrazione: Agenzia delle Entrate Responsabile dei sistemi informativi Nome

Dettagli

Motore di riempimento DB (generatore dati per simulazione)

Motore di riempimento DB (generatore dati per simulazione) SISTEMI DISTRIBUITI prof. S.Pizzutilo Motore di riempimento DB (generatore dati per simulazione) Studente: Alessandro Balestrucci 617937 Corso di Laurea: Informatica Magistrale Dipartimento di Informatica

Dettagli

Descrizione generale. Architettura del sistema

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

Dettagli

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna Progetto RE.VE.N.GE. DDS con Fault-tolerance del Sistema di Consegna Progetto di: Marco Livini, Luca Nardelli, Christian Pinto Reti di Calcolatori LS 08-09 Prof. Antonio Corradi, Ing. Luca Foschini Relazione

Dettagli

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

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

Dettagli

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

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

Architetture Software

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

Dettagli

Database e reti. Piero Gallo Pasquale Sirsi

Database e reti. Piero Gallo Pasquale Sirsi Database e reti Piero Gallo Pasquale Sirsi Approcci per l interfacciamento Il nostro obiettivo è, ora, quello di individuare i possibili approcci per integrare una base di dati gestita da un in un ambiente

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

Auditing di Eventi. Daniele Di Lucente

Auditing di Eventi. Daniele Di Lucente Auditing di Eventi Daniele Di Lucente Un caso che potrebbe essere reale Un intruso è riuscito a penetrare nella rete informatica della società XYZ. Chi è l intruso? Come ha fatto ad entrare? Quali informazioni

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

1. SISTEMA INFORMATICO GESTIONALE

1. SISTEMA INFORMATICO GESTIONALE 1. SISTEMA INFORMATICO GESTIONALE 1.1 Introduzione Il sistema informatico gestionale, che dovrà essere fornito insieme ai magazzini automatizzati (d ora in avanti Sistema Informatico o semplicemente Sistema),

Dettagli

Il Provvedimento del Garante

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

Dettagli

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

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Architetture dei Sistemi Distribuiti

Architetture dei Sistemi Distribuiti Università degli tudi di Roma Tor Vergata Facoltà di Ingegneria Architetture dei istemi Distribuiti Corso di istemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Architettura sw di sistemi distribuito

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

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

Dettagli

IBM i5/os: un sistema progettato per essere sicuro e flessibile

IBM i5/os: un sistema progettato per essere sicuro e flessibile IBM i5/os garantisce la continua operatività della vostra azienda IBM i5/os: un sistema progettato per essere sicuro e flessibile Caratteristiche principali Introduzione del software HASM (High Availability

Dettagli

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA A.S. 2011-2012 Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECICO USTRIALE CORSO SPERIMETALE PROGETTO «ABACUS» Indirizzo: IFORMATICA Tema di: SISTEMI DI ELABORAZIOE E TRASMISSIOE DELLE

Dettagli

27/03/2013. Contenuti

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

Dettagli

CAPITOLO 8.1 UNA REALIZZAZIONE WEB GIS PER L AGGIORNAMENTO IN RETE DI DATABASE TOPOGRAFICI

CAPITOLO 8.1 UNA REALIZZAZIONE WEB GIS PER L AGGIORNAMENTO IN RETE DI DATABASE TOPOGRAFICI PRIN 2004: I Servizi di posizionamento satellitare per l e-government CAPITOLO 8.1 UNA REALIZZAZIONE WEB GIS PER L AGGIORNAMENTO IN RETE DI DATABASE TOPOGRAFICI Matteo Crozi, Anna Spalla DIET - Dipartimento

Dettagli

Prot: Del: Allegato Capitolato Tecnico. Sistema GAIA. Sistema informativo di governo dell Ambiente e flussi informativi ambientali verso gli utenti

Prot: Del: Allegato Capitolato Tecnico. Sistema GAIA. Sistema informativo di governo dell Ambiente e flussi informativi ambientali verso gli utenti REPUBBLICA ITALIANA Regione Siciliana ASSESSORATO TERRITORIO ED AMBIENTE Via Ugo La Malfa, 169 Palermo Prot: Del: Allegato Capitolato Tecnico Sistema GAIA Sistema informativo di governo dell Ambiente e

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

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

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

Dettagli

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E.

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Class Discovery E. TINELLI Contenuti Classi di analisi: definizione ed esempi Tecniche per la definizione

Dettagli

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand!

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand! Introduzione Qui di seguito vengono esposte le risposte alle domande più frequenti relative a Oracle Siebel CRM On Demand. Inoltre, il Solutions Launchpad che contiene il link a questo documento offre

Dettagli

Approfondimenti tecnici su framework v6.3

Approfondimenti tecnici su framework v6.3 Sito http://www.icu.fitb.eu/ pagina 1 I.C.U. "I See You" Sito...1 Cosa è...3 Cosa fa...3 Alcune funzionalità Base:...3 Alcune funzionalità Avanzate:...3 Personalizzazioni...3 Elenco Moduli base...4 Elenco

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa!

C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa! C è aria di cambiamento nel mondo dell assistenza sanitaria integrativa! EC CONSULTING Via A. Grandi, 21 20090 Vimodrone (MI) TEL.: 02.27408094 FAX: 02.27409150 e-mail info@ecconsulting.it web www.ecconsulting.it

Dettagli

BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari. Advanced Advanced Technology Solutions

BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari. Advanced Advanced Technology Solutions BrokerINFO La soluzione integrata per la distribuzione dei dati dei mercati finanziari Advanced Advanced Technology Solutions La soluzione integrata per la distribuzione dell informativa dei mercati finanziari

Dettagli

L E I N F O R M A Z I O N I P E R F A R E

L E I N F O R M A Z I O N I P E R F A R E L E I N F O R M A Z I O N I P E R F A R E C E N T R O Con InfoBusiness avrai Vuoi DATI CERTI per prendere giuste DECISIONI? Cerchi CONFERME per le tue INTUIZIONI? Vuoi RISPOSTE IMMEDIATE? SPRECHI TEMPO

Dettagli

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI PROCEDURA DI SELEZIONE PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, ANALISI, SVILUPPO, MANUTENZIONE ADEGUATIVA, CORRETTIVA ED EVOLUTIVA DI SISTEMI INFORMATIVI SU PIATTAFORMA IBM WEBSPHERE BPM (EX LOMBARDI)

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Introduzione OS=Astrazione Dare l illusione all applicazione di memoria infinita, CPU infinita,unico

Dettagli

Università degli studi Roma Tre Dipartimento di informatica ed automazione. Tesi di laurea

Università degli studi Roma Tre Dipartimento di informatica ed automazione. Tesi di laurea Università degli studi Roma Tre Dipartimento di informatica ed automazione Tesi di laurea Reingegnerizzazione ed estensione di uno strumento per la generazione di siti Web Relatore Prof. P.Atzeni Università

Dettagli

Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu)

Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu) Sistemi Mobili M Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu) 08 Cenni di Sincronizzazione Dati e SyncML Docente: Paolo

Dettagli

COM & DCOM (Distributed) Component Object Mode. Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000

COM & DCOM (Distributed) Component Object Mode. Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000 COM & DCOM (Distributed) Component Object Mode Valentina Del Frate Corso Di Controllo Digitale A.A. 1999/2000 COM : Prima Definizione (Glossario Informatico) Una Architettura software messa a punto da

Dettagli

Antonio Brunetti, Mathias Galizia, Fabio Campanella

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

Dettagli

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

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 La gestione degli Istituti di Vigilanza e Sorveglianza L efficienza

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Per organizzazioni di medie dimensioni. Oracle Product Brief Real Application Clusters (RAC)

Per organizzazioni di medie dimensioni. Oracle Product Brief Real Application Clusters (RAC) Per organizzazioni di medie dimensioni Oracle Product Brief Real Application Clusters (RAC) PERCHÉ UN ORGANIZZAZIONE NECESSITA DI UNA FUNZIONALITÀ DI CLUSTERING? La continuità operativa è fondamentale

Dettagli

Relazione finale di Didattica e laboratorio di Programmazione

Relazione finale di Didattica e laboratorio di Programmazione Relazione finale di Didattica e laboratorio di Programmazione Prof.ssa Vallì Carando Tirocinante Maria Grazia Maffucci Classe di concorso A042 aprile 2013 Progettazione Web Applicazioni client-server La

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

U-GOV Spazi e Calendari

U-GOV Spazi e Calendari U-GOV Spazi e Calendari Organizzazione e monitoraggio delle risorse di Ateneo White Paper Aprile 2008 Titolo White Paper: Aprile 2008 S1-0 Autori: Audience: KION, Relazioni Esterne Direttori amministrativi,

Dettagli

SMS @Server. Caratteristiche e applicazioni

SMS @Server. Caratteristiche e applicazioni SMS @Server Caratteristiche e applicazioni Sommario: - Presentazione - Ambiti di applicazione - Case studies - Perché SMS @Server - Dettagli tecnici - Periferiche supportate Presentazione di SMS @Server

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Parte II: Reti di calcolatori Lezione 10

Parte II: Reti di calcolatori Lezione 10 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 10 Giovedì 9-04-2015 1 Database distribuiti e gerarchici

Dettagli

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete Sistemi Operativi di Rete Estensione dei Sistemi Operativi standard con servizi per la gestione di risorse in rete locale Risorse gestite: uno o più server di rete più stampanti di rete una o più reti

Dettagli

Il Contesto. Riassunto

Il Contesto. Riassunto Temento Systems mostra come la tecnologia Jtag Boundary-Scan integrata in un sistema automatico di collaudo possa aumentare la copertura del test di schede complesse altrimenti non collaudabili. Il Contesto

Dettagli

Introduzione al linguaggio Java: Servlet e JSP

Introduzione al linguaggio Java: Servlet e JSP Introduzione al linguaggio Java: Servlet e JSP Corso di Gestione della Conoscenza d Impresa A. A. 2006/2007 Dipartimento di Informatica Università degli Studi di Bari 1 Servlet e JSP: il contesto Un applicazione

Dettagli

ERP Commercio e Servizi

ERP Commercio e Servizi ERP Commercio e Servizi Sistema informativo: una scelta strategica In questi ultimi anni hanno avuto grande affermazione nel mercato mondiale i cosiddetti sistemi software ERP. Tali sistemi sono in grado

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

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

Wireless Grids e Pervasive Grids. Pervasive Grids

Wireless Grids e Pervasive Grids. Pervasive Grids Griglie e Sistemi di Elaborazione Ubiqui Wireless Grids e Pervasive Grids Griglie e Sistemi Ubiqui - D. Talia - UNICAL 1 Wireless Grids e Pervasive Grids Wireless Grids Caratteristiche Sistemi Applicazioni

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

Soluzione dell esercizio del 12 Febbraio 2004

Soluzione dell esercizio del 12 Febbraio 2004 Soluzione dell esercizio del 12/2/2004 1 Soluzione dell esercizio del 12 Febbraio 2004 1. Casi d uso I casi d uso sono riportati in Figura 1. Figura 1: Diagramma dei casi d uso. 2. Modello concettuale

Dettagli

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012 Sapienza Università di Roma Facoltà di Ingegneria dell Informazione, Informatica e Statistica Corso di Laurea in Ingegneria Informatica ed Automatica Corso di Laurea in Ingegneria dei Sistemi Informatici

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

@CCEDO: Accessibilità, Sicurezza, Architettura

@CCEDO: Accessibilità, Sicurezza, Architettura Rev. 8, agg. Settembre 2014 @CCEDO: Accessibilità, Sicurezza, Architettura 1.1 Il Sistema di Gestione della Sicurezza Per quanto riguarda la gestione della Sicurezza, @ccedo è dotato di un sistema di autenticazione

Dettagli

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36 10. Design Patterns Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 10. Design Patterns 1 / 36 Problemi Ci focalizziamo nelle problematiche riguardanti la

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

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

Dettagli

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015 ASSE DISCIPLINA DOCENTE MATEMATICO INFORMATICA Cattani Barbara monoennio CLASSE: quinta CORSO D SEZIONE LICEO SCIENZE APPLICATE

Dettagli

MetaMAG METAMAG 1 IL PRODOTTO

MetaMAG METAMAG 1 IL PRODOTTO METAMAG 1 IL PRODOTTO Metamag è un prodotto che permette l acquisizione, l importazione, l analisi e la catalogazione di oggetti digitali per materiale documentale (quali immagini oppure file di testo

Dettagli

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

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

Dettagli

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A.

NoSQL http://nosql. nosql-database.org/ Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Linguaggi e Tecnologie Web A. A. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Linguaggi e Tecnologie Web A. A. 2011-2012 NoSQL http://nosql nosql-database.org/ Eufemia TINELLI Cosa è NoSQL? 1998 il termine NoSQL è

Dettagli

UN APP FLESSIBILE E INTUITIVA PER GESTIRE I TUOI AFFARI IN TUTTA COMODITÀ

UN APP FLESSIBILE E INTUITIVA PER GESTIRE I TUOI AFFARI IN TUTTA COMODITÀ UN APP FLESSIBILE E INTUITIVA PER GESTIRE I TUOI AFFARI IN TUTTA COMODITÀ APP Mobile MIGLIORA LA QUALITÀ DEL RAPPORTO CON I CLIENTI, SCEGLI LA TECNOLOGIA DEL MOBILE CRM INTEGRABILE AL TUO GESTIONALE AZIENDALE

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Sistemi Distribuiti Introduzione al corso

Sistemi Distribuiti Introduzione al corso Altri testi di consultazione Sistemi Distribuiti Introduzione al corso Testo di riferimento G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005

Dettagli

Laboratorio di Informatica I

Laboratorio di Informatica I Struttura della lezione Lezione 1: Le Architetture Distribuite Vittorio Scarano Algoritmi e Strutture Dati: Algoritmi Distribuiti Corso di Laurea in Informatica Università di Salerno Le architetture distribuite

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

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

Dettagli

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

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

Dettagli

Distributed Object Computing

Distributed Object Computing Evoluzione Architetturale Distributed omputing entralizzata Monolitica anni 60-70 Reti locali di P anni 80 Reti lient Server anni 80-90 Internet The network is the computer Paolo Falcarin Sistemi Informativi

Dettagli

Architetture di Cloud Computing

Architetture di Cloud Computing Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architetture di Cloud Computing 1 Cloud computing Sommario Principali requisiti richiesti dal cloud clomputing

Dettagli

Sistemi operativi e reti A.A. 2013-14. Lezione 2

Sistemi operativi e reti A.A. 2013-14. Lezione 2 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 2 Giovedì 10-10-2013 1 Sistemi a partizione di tempo (time-sharing) I

Dettagli

Approfondimenti. Contenuti

Approfondimenti. Contenuti Approfondimenti dott. Stefano D. Fratepietro steve@stevelab.net C I R S F I D Università degli studi di Bologna stevelab.net Creative Commons license Stefano Fratepietro - www.stevelab.net 1 Contenuti

Dettagli

DEFINIZIONI FONDAMENTALI

DEFINIZIONI FONDAMENTALI Consorzio per la formazione e la ricerca in Ingegneria dell'informazione DEFINIZIONI FONDAMENTALI Per vincere ci vuole una buona partenza... Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it

Dettagli