SISTEMI DISTRIBUITI. Antonio Massari, Massimo Mecella, Enrico Melis, Gaetano Santucci. 1. Introduzione

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "SISTEMI DISTRIBUITI. Antonio Massari, Massimo Mecella, Enrico Melis, Gaetano Santucci. 1. Introduzione"

Transcript

1 SISTEMI DISTRIBUITI Antonio Massari, Massimo Mecella, Enrico Melis, Gaetano Santucci 1. Introduzione Le architetture dei sistemi informativi si sono sviluppate ed evolute nel corso degli anni passando da schemi centralizzati a modelli distribuiti e diffusi, maggiormente rispondenti alle necessità di decentralizzazione e cooperazione delle moderne organizzazioni. In questa tendenza alla distribuzione svolgono un ruolo importante le tecnologie a oggetti distribuiti e il Distributed Object Computing (D.O.C.). Questo contributo vuole fornire un quadro d assieme dello stato dell arte delle tecnologie per la realizzazione di sistemi distribuiti e permettere la comprensione delle loro potenzialità nel breve e medio periodo. In particolare: sono introdotti i concetti di architettura centralizzata ed architettura distribuita e, dall analisi critica dei vantaggi e degli svantaggi offerti dai due tipi di architettura, è presentato e descritto nelle sue caratteristiche principali il concetto di Distributed Object Computing (D.O.C.); sono descritte le metodologie e i modelli adottati per la progettazione di sistemi ad oggetti distribuiti; sono illustrate le tecnologie principali disponibili per realizzare sistemi ad oggetti distribuiti; è fornita una trattazione dei possibili contesti applicativi nei quali il D.O.C. può trovare fertile campo di applicazione; sono svolte alcune considerazioni finali riguardo alle criticità attuali e alle linee evolutive future. 1

2 2. Sistemi centralizzati e sistemi distribuiti Si parla di sistema informatico centralizzato quando i dati e le applicazioni risiedono in un unico nodo elaborativo (Figura 1). Terminali utente Applicazioni Nodo elaborativo Archivi centralizzati Figura 1 - Sistema informatico centralizzato Viceversa, si parla di sistema informatico distribuito quando almeno una delle seguenti due condizioni è verificata [Coulouris et alii, 1994] [Goscinski, 1991] [Mullender, 1993] [Simon, 1996] (Figura 2): le applicazioni, fra loro cooperanti, risiedono su più nodi elaborativi (elaborazione distribuita); il patrimonio informativo, unitario, è ospitato su più nodi elaborativi (base di dati distribuita). Stazioni utente Archivi locali Applicazioni Nodo elaborativo Applicazioni Nodo elaborativo Archivi locali Applicazioni Nodo elaborativo Archivi locali Figura 2 - Sistema informatico distribuito 2

3 In termini generali, quindi, un sistema distribuito è costituito da un insieme di applicazioni logicamente indipendenti che collaborano per il perseguimento di obiettivi comuni attraverso una infrastruttura di comunicazione hardware e software. Le applicazioni che costituiscono un sistema distribuito sono caratterizzate dal ruolo che svolgono nel sistema stesso: Cliente (Client): una applicazione assume il ruolo di Cliente quando è utilizzatore di servizi messi a disposizione da altre applicazioni; Servente (Server). una applicazione assume il ruolo di Servente quando è fornitore di servizi usati da altre applicazioni; Attore (Actor). una applicazione assume il ruolo di Attore quando assume in diverse situazioni nel contesto del sistema sia il ruolo di Cliente che quello di Servente Un caso particolare: i sistemi client-server Un tipo particolare di sistema distribuito è quello client-server, caratterizzato dalla relazione di servizio secondo la quale più processi client avviano un dialogo richiedendo servizi che sono soddisfatti da corrispondenti processi server. Il dialogo fra processi client e processi server è di tipo sincrono, ovvero: il processo server è in generale inattivo, in attesa che gli pervenga una richiesta di servizio; il processo client, quando invia una richiesta di servizio, rimane bloccato, in attesa del ricevimento della corrispondente risposta (Figura 3). Processo client Processo server Richiesta di servizio Restituzione della risposta Esecuzione del servizio tempo Figura 3 - Relazione di servizio fra processo client e processo server La relazione client/server in generale implica l uso di protocolli asimmetrici, in quanto tipicamente un server può servire più client; per questo motivo il server gestisce risorse condivise (dagli n client che a lui si riferiscono) e deve essere progettato con molta cura, in quanto deve operare in condizioni di carico elevato (molte richieste contemporanee), deve preoccuparsi di realizzare meccanismi per salvaguardare la consistenza nell'accesso alle risorse condivise (tipicamente la base informativa a cui si appoggia) e deve essere 3

4 scalabile, cioè deve poter aumentare le proprie dimensioni e capacità di servizio per soddisfare un numero crescente di client L evoluzione delle architetture dei sistemi informatici I sistemi centralizzati sono nati con l informatica moderna negli anni 50 e si sono sviluppati negli anni 60 e 70 grazie all affermarsi delle tecnologie dei mainframe, dei sistemi operativi time-sharing, dei file system e dei DBMS centralizzati (gerarchici e reticolari). La nascita e lo sviluppo, negli anni 70 e 80, di nuove tecnologie più economiche, versatili e facili da usare (mini e micro elaboratori, LAN, DBMS relazionali, architetture client-server, interfacce GUI) ha portato alla crisi del modello centralizzato, evidenziandone la minore economicità e qualità del servizio, e ha promosso la realizzazione di sistemi distribuiti in realtà grandi, medie e piccole, dando luogo al fenomeno dell informatica diffusa. Questo fenomeno di decentralizzazione ha avuto grande impulso per via dei seguenti motivi principali: crollo dei prezzi degli apparati hardware e delle relative licenze software; maggiore scalabilità, continuità e qualità del servizio da parte dei sistemi distribuiti rispetto a quelli centralizzati; maggiore capacità, da parte dei sistemi distribuiti, di venire incontro alle esigenze di flessibilità e di autonomia delle moderne organizzazioni. I sistemi distribuiti implicano scelte gestionali differenti da quelle dei sistemi centralizzati tradizionali. In questi, tipicamente omogenei, il controllo del sistema operativo e della comunicazione terminali/host richiede un staff di analisti/sistemisti dedicato, che sia in grado di assicurare il regolare funzionamento operativo del sistema, e la manutenzione e la gestione di configurazione del sistema sono perfettamente definiti, in quanto vengono svolti in modo centralizzato. Con l'avvento dei sistemi distribuiti nasce la possibilità di scegliere e combinare, ai vari livelli dell architettura, componenti provenienti da fornitori diversi. La definizione del sistema richiede la risoluzione di un insieme di problemi, quali la scelta della piattaforma per il client, di quella per il server (che in generale è differente) e dei protocolli di comunicazione. A fronte della maggior complessità nella definizione e gestione del sistema, causata principalmente dall eterogeneità, si ottenengono in cambio vantaggi dovuti alla possibilità di scegliere per ogni componente quanto di meglio (in termini economici e/o qualitativi) offre il mercato. Nei primi anni 90, sulla base dell esperienza maturata nella gestione dell informatica diffusa, il modello distribuito è stato sottoposto a forte critica [Duchessi, Chengalur- Smith, 1998] proprio per la maggiore complessità progettuale, che determina in generale maggiori costi realizzativi e minore robustezza delle realizzazioni e per la maggiore 4

5 complessità gestionale, che genera costi spesso nascosti per gli utenti e le organizzazioni. L analisi critica dei punti di forza e dei punti di debolezza del modello centralizzato e del modello distribuito ha portato la comunità scientifica ed i fornitori di tecnologie ad elaborare un nuovo modello di elaborazione, il Distributed Object Computing (D.O.C.), che tende a fornire un contesto virtualmente unitario di elaborazione, in cui più processi elaborativi (oggetti) cooperano come se risiedessero su un unica macchina [Krieger, Adler, 1998] (Figura 4). Sistema a oggetti distribuiti Hardware Software di base Reti Infrastruttura a oggetti distribuiti Figura 4 - Infrastruttura per sistemi a oggetti distribuiti Tale contesto unitario di elaborazione è realizzato mediante un infrastruttura tecnologica ad oggetti distribuiti che ne permette la distribuzione fisica su più macchine connesse tra loro in rete, in modo che: la progettazione, la realizzazione e la gestione delle applicazioni basate sull infrastruttura può avvenire a livello operativo con tecniche e complessità simili a quelle dell ambito dei sistemi centralizzati; si demanda ai fornitori e agli specialisti di infrastrutture ad oggetti distribuiti la risoluzione di tutte le problematiche architetturali, tecnologiche e gestionali proprie delle infrastrutture stesse Il concetto di middleware Con il termine middleware si indica un insieme di componenti software che realizzano una macchina virtuale (ovvero un insieme di servizi fra loro coerenti e simulanti il comportamento di un unico elaboratore che fosse progettato per erogarli). La macchina virtuale è messa a disposizione delle applicazioni, che la usano mediante chiamate ai servizi da questa offerti. Il middleware realizza la macchina virtuale usando servizi offerti da apparati hardware e software di livello più basso (Figura 5). 5

6 Generalmente si distingue fra due tipi di middleware: generalizzato e orientato a specifici tipi di servizio. Il middleware generalizzato è il substrato della maggior parte delle interazioni tra componenti di un sistema distribuito; include gli strumenti di comunicazione, i servizi di sicurezza, i servizi di indirizzamento, i meccanismi di sincronizzazione, i servizi di accodamento. Interfaccia utente Interfaccia utente Interfaccia utente Interfaccia utente Applicazione Applicazione Applicazione Applicazione Middleware dei servizi distribuiti Software di base Software di base Software di base Hardware Hardware Hardware Hardware Rete Figura 5 - Il Middleware Fra i middleware orientati a specifiche classi di servizio ricordiamo, a titolo di esempio: il middleware per accesso a basi di dati, come Open Data Base Connectivity - ODBC 1 ; 1 ODBC: è un'interfaccia di programmazione (Application Programming Interface - API) proposta da Microsoft nel 1991 per permettere l accesso a basi di dati relazionali da parte delle applicazioni software in modo indipendente dalle caratteristiche fisiche dei singoli DBMS. Tramite un'interfaccia ODBC, un'applicazione scritta in SQL può accedere ai dati remoti. Il linguaggio supportato è un'insieme particolarmente ristretto del linguaggio SQL standard, definito nel

7 il middleware per la gestione di transazioni, come quello previsto dal modello Distributed Transaction Processing DTP del consorzio X/Open; Nell ambito del D.O.C., i middleware che permettono a un insieme complesso di oggetti distribuiti di cooperare su una rete di calcolatori sono riconducibili a tre tecnologie principali (Figura 6): middleware generalizzati a oggetti, per governare le complessità dei sistemi a oggetti distribuiti facendoli apparire come se fossero centralizzati; tecnologie basate su, per la diffusione dei servizi informatici a vaste popolazioni di utenti, accentrando presso un singolo nodo logico ( site) la logica elaborativa; tecnologie di incapsulamento dei sistemi legacy, che permettono di usufruire dei sistemi informativi e transazionali offerti dalle vecchie architetture di elaborazione nel nuovo contesto tecnologico, valorizzando così gli investimenti pregressi. browser Xnet server Servizi forniti BROKER Servizi offerti Servizi legacy Tecnologia web Middleware basato su oggetti Incapsulamento sistemi legacy Figura 6 - Le tecnologie a oggetti distribuiti Il ruolo che le tre classi tecnologiche hanno è quindi il seguente: i middleware generalizzati a oggetti realizzano la macchina virtuale che permette la progettazione e la realizzazione di un sistema distribuito come costituito da più oggetti applicativi fra loro cooperanti; nello sviluppo applicativo il sistema è da SQL Access Group - SAG - un gruppo di 50 grandi utenti di DBMS. Nell'architettura ODBC la comunicazione tra un'applicazione ed il DBMS server è effettuato da un driver, una libreria che viene collegata dinamicamente all'applicazione e da essa usata; esso maschera le differenze d'interazione legate non solo al DBMS, ma anche al sistema operativo ed al protocollo di rete usati. Per garantire la compatibilità rispetto allo standard ODBC, ciascun produttore di DBMS deve garantire driver che prevedono l'uso del DBMS server nell'ambito di una specifica rete e con uno specifico sistema operativo (nel nodo dove il DBMS è installato). 7

8 modellato secondo un paradigma a oggetti, che promuove la modularità, la riusabilità e la manutenibilità e le problematiche proprie della distribuzione del sistema sulla rete di calcolatori sono affrontate dal middleware generalizzato a oggetti e da chi, a livello sistemistico, è chiamato a configurarlo e ottimizzarlo; le tecnologie based permettono la diffusione dei servizi informativi e transazionali offerti dagli oggetti di cui il sistema distribuito si compone su reti Internet, Intranet o Extranet; queste tecnologie costituiscono il mezzo più moderno di diffusione dei servizi all utenza, sia per la praticità e la gradevolezza dell interfaccia utente offerta, sia per l economicità del supporto all esercizio; le tecnologie di incapsulamento di sistemi legacy permettono di ottenere oggetti applicativi corrispondenti ai servizi transazionali (incapsulamento di transazioni host esistenti) o ai servizi informativi (incapsulamento di accesso a archivi di dati esistenti) offerti dai sistemi legacy; in questo modo i servizi offerti dai sistemi esistenti possono essere sfruttati nel nuovo contesto tecnologico, valorizzando gli investimenti pregressi e permettendo l adozione di percorsi di migrazione graduali dalle vecchie alle nuove architetture Caratteristiche specifiche del D.O.C. Le principali caratteristiche del D.O.C. sono le seguenti: il sistema è modellato come un insieme di oggetti, ciascuno dei quali rappresenta in modo naturale un oggetto di business dell organizzazione, cioè una risorsa che svolge un ruolo nei processi aziendali; gli oggetti comunicano tra loro attraverso lo scambio di messaggi; non esiste una netta distinzione tra oggetto client e oggetto server, in quanto uno stesso oggetto può essere contemporaneamente cliente ed offrire servizi ad altri; la granularità degli oggetti sulla rete può essere molto più fine rispetto a quella implicitamente considerata nei sistemi client/server tradizionali; non sono imposti vincoli sulle piattaforme hardware, sui sistemi operativi, sui protocolli di comunicazione e sui linguaggi di programmazione da usare, in quanto l incapsulamento in un oggetto dei suoi dettagli realizzativi e la separazione tra interfaccia verso l esterno e caratteristiche realizzative interne sono principi fondamentali dell orientamento agli oggetti. Un ambiente di D.O.C si caratterizza, in generale, per la disponibilità di (figura 7): Interface Definition Language (IDL). E un linguaggio per descrivere le operazioni di un oggetto software accessibili esternamente; consente di definire le operazioni disponibili per un oggetto e i parametri per l invocazione dell operazione. IDL è importante perché fornisce un modo normalizzato per definire i servizi resi disponibili da un oggetto. Definita l interfaccia l oggetto può essere richiamato ed usato da un qualsiasi altro oggetto cliente, anche se 8

9 quest ultimo è realizzato in un differente linguaggio di programmazione. Con IDL si stabilisce una sorta di contratto tra il client ed il server: il server fornisce servizi coerenti con l interfaccia, il client richiede i servizi in modo conforme a quanto stabilito dall interfaccia. Protocolli d interoperabilità. Un IDL definisce interfacce comuni per gli oggetti, ma non specifica il modo in cui le richieste e le relative risposte sono trasmesse sulla rete. La trasmissione delle richieste di servizio e delle risposte è la seconda funzione base di un middleware di DOC ed è ottenuta con un protocollo d interoperabilità che specifica il tipo di messaggi da scambiare e la loro interpretazione. La complessità del protocollo è direttamente collegata al potere espressivo dell IDL; il processo di trasformazione delle strutture dati in messaggi è detto marshaling, e la relativa decodifica dei dati dal messaggio è detto unmarshaling. Message Broker. Una tematica importante in un ambiente di DOC riguarda il meccanismo con il quale i clienti dei servizi riescono a individuare i serventi di interesse e ad instaurare con essi il colloquio. Il più semplice approccio è la strategia direct mail, nella quale ogni oggetto conosce l indirizzo esatto (indirizzo IP nel caso in cui il protocollo di rete sia TCP/IP) di ogni altro oggetto al quale voglia inviare messaggi. Una tale strategia è efficiente ma poco flessibile, in quanto ogni oggetto è conosciuto in rete in quanto collegato all indirizzo di un server. Un cambiamento di configurazione imp lica che tutti i client debbano essere informati delle nuove allocazioni di servizi. La soluzione a tali difficoltà è costituita dall introduzione di un message broker (ORB - Object Request Broker), che funge da registro per l instradamento dei messaggi. In questo modo possono essere utilizzati nomi descrittivi che il broker traduce in indirizzi fisici. Un broker fornisce alcuni benefici fondamentali: nella progettazione fornisce un buon modo per separare la complessità della rete dalle funzionalità dell applicazione distribuita; nell operatività del sistema rende più semplice riconfigurare un applicazione in caso di aumento del carico o di malfunzionamenti. Servizi di Supporto. Le piattaforme per il DOC più moderne offrono servizi di supporto che rendono più semplice sviluppare applicazioni distribuite. Un esempio classico è il Naming Service, che permette ai componenti distribuiti di localizzarsi l uno con l altro sulla rete. La ricchezza dell insieme dei servizi di supporto offerti è elemento critico per permettere il rapido sviluppo di applicazioni distribuite flessibili e estendibili. Strumenti di sviluppo e componentware. Gli ambienti di D.O.C. più moderni sono completati da strumenti di supporto alle attività dei progettisti e dei programmatori che ne facilitano il compito, sia automatizzando l esecuzione di alcuni passi realizzativi, sia inglobando in oggetti riusabili la soluzione di problematiche tecniche e applicative specifiche. Gli strumenti più potenti sono quelli che rendono trasparente il processo di distribuzione degli oggetti sulla rete: essi nascondono molte delle complessità del middleware stesso, permettendo di concentrarsi maggiormente sulle problematiche proprie del dominio applicativo. 9

10 Client marshaling Protocollo d interoperabilità Middleware unmarshaling Server definizione IDL dei servizi offerti Figura 7 - Concetti fondamentali di un infrastruttura di DOC L adozione di infrastrutture ad oggetti distribuiti permette di cogliere i seguenti benefici: disponibilità e qualità del servizio elevate; scalabilità delle soluzioni, adattabilità, flessibilità ed apertura; economicità; semplicità di realizzazione e gestione a livello operativo. 3. Metodologie per sistemi a oggetti distribuiti Le prime metodologie di analisi e progettazione Object Oriented sono apparse da più di un decennio e si sono sviluppate in numerose differenti proposte (tra le quali Object Modeling Technique - OMT di Rumbaugh [Rumbaugh et alii, 1991], Booch Methodology [Booch, 1994], Shlaer - Mellor method [Shlaer, Mellor, 1988], la metodologia di Coad Yourdon [Coad, Yourdon1, 1991] [Coad, Yourdon2, 1991], Use Case/Object Oriented Software Engineering-OOSE di Jacobson [Jacobson, 1995], la metodologia Fusion di Coleman [Coleman et alii, 1993]). In [Hutt1, 1994] [Hutt2, 1994] sono analizzate e comparate 21 metodologie orientate agli oggetti diverse. Tale situazione è indice non solo di giovinezza del settore e di grande interesse per l argomento, ma anche di frammentazione e di assenza di una metodologia affermata. La Figura 8 mostra la distribuzione dell uso delle diverse metodologie nella pratica industriale. 10

11 altri 37% Fusion 3% OMT 20% Jacobson 5% Coad &Yourdon 5% Shlaer & Mellor 15% Booch 15% Figura 8 - L uso industriale delle metodologie OO. Nel 1995 tre tra i principali studiosi di metodologie di analisi e progettazione orientate agli oggetti (G.Booch, J.Rumbaugh e I.Jacobson) si sono associati con l obiettivo di definire una metodologia unificata e di realizzare uno strumento CASE che la supportasse pienamente. Questo sforzo ha prodotto nel 1997 UML (Unified Modeling Language), un linguaggio standardizzato dall Object Management Group e adottato anche da Microsoft, per la rappresentazione orientata agli oggetti dei sistemi software. Al di là dell importanza di questo strumento, manca però ancora un indicazione metodologica generale e soprattutto le proposte attuali non tengono in debito conto le problematiche architetturali che un sistema distribuito e complesso presenta. Si rimanda alla vasta letteratura specialistica per una completa trattazione delle diverse problematiche (si veda, per esempio, [Umar1, 1997] per un primo orientamento bibliografico). In questo contesto, al fine di fornire un orientamento generale, si introduce il modello basato su oggetti e si evidenziano i passi e le tecniche metodologiche che arricchiscono i classici approcci progettuali orientati ai sistemi centralizzati per renderli idonei a trattare il progetto e la realizzazione di sistemi a oggetti distribuiti Il modello basato su oggetti Il modello basato su oggetti nasce agli inizi degli anni 90 grazie all opera di diversi ricercatori operanti nell area dei sistemi operativi distribuiti [Mullender, 1993] come semplificazione del modello orientato agli oggetti in modo da consentire una rappresentazione a oggetti di applicazioni complesse che siano facilmente realizzabili e distribuibili su reti di grandi dimensioni. Il modello mette a disposizione i seguenti costrutti di rappresentazione principali: l oggetto, insieme integrato di dati (che costituiscono il suo stato) e di funzioni (che costituiscono il suo comportamento) su di essi operanti; ogni oggetto è 11

12 dotato di una propria identità che lo differenzia dagli altri a prescindere dallo stato in cui si trova ed è creato come istanziazione di un modello, detto classe; l interfaccia, che raggruppa i servizi messi a disposizione da un oggetto e invocabili da altri oggetti; ogni oggetto può possedere una o più interfacce; la connessione tra due oggetti, che costituisce il meccanismo con il quale i servizi forniti dalle interfacce dell uno (servente) sono usati dall altro (cliente); una connessione può essere sincrona (bloccante per il cliente) o asincrona (non bloccante), di tipo pull (il cliente chiede l esecuzione del servizio) o di tipo push (il servente propone attivamente il servizio). La figura seguente mostra la simbologia comunemente usata per rappresentare i diversi costrutti. Interfaccia Oggetto servente Oggetto cliente Gestione ordini Gestione acquisti Connessione Figura 9 - Il modello basato su oggetti Il modello basato su oggetti è più povero del modello orientato agli oggetti almeno per i seguenti due motivi: non è presente il concetto di ereditarietà fra classi; non è affermata esplicitamente la corrispondenza fra oggetti del modello e oggetti del mondo reale da rappresentare. Il primo aspetto è giustificato dalla difficoltà, da parte di molte tecnologie a oggetti distribuiti, di definire e mantenere correttamente e efficientemente le gerarchie di classi di oggetti in un contesto distribuito. Il secondo aspetto permette al modellista di individuare oggetti corrispondenti a componenti architetturali (processi) che possano essere trattati direttamente da un middleware a oggetti distribuiti, piuttosto che a concetti del mondo reale. Ad esempio, nella precedente Figura 9, l oggetto Gestore ordini, componente del sistema, sostituisce il più generale oggetto Ordine, rappresentativo di un concetto della realtà rappresentata. Il modello basato su oggetti salvaguarda la proprietà di incapsulamento, da parte di ogni oggetto, del proprio patrimonio privato di dati e di funzioni. Tale proprietà, presente nei modelli orientati agli oggetti, è assicurata dal costrutto di interfaccia, che è l unico 12

13 meccanismo mediante il quale oggetti clienti possono usufruire dei servizi messi a disposizione degli oggetti serventi. La proprietà di incapsulamento del modello permette di affermare che ogni oggetto è: unità di esecuzione: ogni oggetto è dotato delle risorse necessarie (dati e funzioni) necessarie per l esecuzione dei servizi forniti all esterno; unità di fallimento: i malfunzionamenti che si verificano nell esecuzione di un oggetto sono circoscritti all oggetto stesso e non degradano il funzionamento degli altri oggetti del sistema; unità di attivazione: ogni oggetto costituisce un insieme autoconsistente di dati e funzioni da allocare su un elaboratore; unità di distribuzione: ogni oggetto, nell ambito di un sistema distribuito, può essere collocato su un nodo diverso della rete, senza che ciò impedisca il funzionamento del sistema; unità di replicazione: ogni oggetto è candidato ad essere replicato, per aumentare la robustezza e l efficienza del sistema; unità di parallelismo: ogni oggetto può costituire un processo elaborativo autonomo, permettendo così l elaborazione parallela su una o più macchine; unità di realizzazione: ogni oggetto può essere realizzato in modo indipendente dagli altri, costituendo quindi il pacchetto di lavoro elementare da affidare ad un gruppo di sviluppatori. La Figura 10 mostra, a titolo esemplificativo, lo schema ad oggetti di un sistema per il commercio elettronico. UTENTE DEL SERVIZIO Utente finale POS evoluto Interfaccia -oriented del C.E. Configurazione negozio/servizi Gestore negozio Gestione Amministrativa C.E. Informazioni di shopping Acquisto Vendite Gestore Transazioni MALL Gestione Pagamenti Statistiche Gestore profili negozi Figura 10 - schema a oggetti di un sistema di commercio elettronico 13

14 3.2. Le modalità di comunicazione fra oggetti Nel modello a oggetti, la comunicazione tra due oggetti può avvenire secondo due differenti modalità: sincrona e asincrona. La modalità sincrona (Request/Replay) è analoga ad una chiamata a procedura/funzione dei linguaggi di programmazione, con il relativo passaggio dei parametri. E' il middleware che si occupa di raccogliere i valori di questi parametri, di impacchettarli insieme al nome dell'operazione per formare un messaggio e di inviarli all oggetto server; quando questi avrà eseguito il compito richiesto, sempre il middleware impacchetterà il valore di ritorno dei parametri di uscita per restituirli al client. I middleware che si basano su questo meccanismo vengono tipicamente classificati come basati su RPC (Remote Procedure Call). Il client ed il server devono essere contemporaneamente attivi nel momento in cui il servizio viene richiesto e il client rimane in attesa finché il server non comp leta il compito richiesto e restituisce la risposta. Tale modalità implica un forte accoppiamento tra il client ed il server, in quanto il client rimane bloccato, consumando risorse, dal momento in cui ha inviato la richiesta a quello in cui ottiene la ris posta. Nella modalità asincrona i componenti possono essere attivi in momenti differenti, in quanto la comunicazione avviene attraverso lo scambio di messaggi unidirezionali: il client invia un messaggio ad una coda d'attesa, il server preleva i messaggi dalla coda. In questo modo c'è totale indipendenza tra i due oggetti e la coda d'attesa costituisce l'elemento di disaccoppiamento. In tal caso il middleware si occupa della gestione della coda e dello smistamento dei messaggi; tali middleware vengono classificati come MOM (Messagge Oriented Middleware) e/o MQM (Message Queueing Middleware). La modalità di comunicazione asincrona può essere realizzata secondo quattro schemi di interazione tra client e server: Publish & Subscribe - I client ed i server non comunicano in modo diretto, ma partecipano a una relazione ternaria in cui gli oggetti server (publisher) forniscono informazioni, gli oggetti client (subscriber) le ricevono e un terzo soggetto (il distributor) si occupa della distribuzione ai subscriber delle informazioni prodotte dai publisher. La Figura 11 mostra lo schema a oggetti di riferimento per tale modalità di comunicazione asincrona. Multicasting - In questo schema c'è una conoscenza diretta dei riceventi da parte della sorgente dell'informazione. Tipicamente il multicasting è fatto direttamente dal soggetto sorgente, che si connette ai riceventi e fornisce i messaggi. La Figura 12 mostra lo schema a oggetti di riferimento per tale modalità di comunicazione. Instance Based Routing - E' una variante del Publish&Subscribe, in cui i subscriber non solo dichiarano l'interesse in qualche tipo di messaggi, ma hanno la possibilità di fornire dei criteri di selezione ulteriori, con cui il distributor determina se effettivamente consegnare certi messaggi ai subscriber. In sostanza mentre nel Publish&Subscribe si possono distinguere i messaggi solamente in 14

15 base al loro tipo, in questo schema si ha la possibilità di raffinare ulteriormente le tipologie anche in base a sottocaratteristiche degli stessi. Store & Forward - Nello schema Publish&Subscribe il messaggio viene consegnato ai subscriber solo se questi hanno una connessione attiva con il distributor; il messaggio infatti è consegnato immediatamente a tutti i subscriber connessi al momento e quindi cancellato. In pratica il meccanismo è asincrono tra gli oggetti terminali (publisher e subscriber) ma richiede sincronicità tra distributor e subscriber. Nello schema Store&Forward invece, il messaggio viene memorizzato dal distributor non appena ricevuto dal publisher e viene mantenuto fino alla consegna a tutti i subscriber. La consegna avviene al momento della connessione dei subscriber al distributor o su iniziativa del distributor allo scadere di un timeout. Get info Publication Subscriber Distributor Publisher Subscription Registration Figura 11 - Schema a oggetti della comunicazione Publish&Subscribe Publication Subscriber Publisher Subscription Figura 12 - Schema a oggetti della comunicazione Multicasting Al fine di mettere maggiormente in luce le caratteristiche di tali quattro modalità di comunicazione, si propone un esempio attinente la realtà della Pubblica Amministrazione, in particolare, la problematica della diffusione di leggi e normative presso tutti i soggetti interessati, pubblici e privati. Lo schema Publish & Subscribe è adatto per soddisfare le esigenze informative generali di una pluralità di soggetti (subscriber), a fronte di una pluralità di enti normatori (publisher). Un ente terzo o uno degli enti normatori è in tale caso chiamato a svolgere il ruolo di distributor. Ogni ente normatore inizialmente dichiara, mediante il servizio di registrazione, la propria volontà a pubblicare le normative prodotte che poi, mediante il servizio di pubblicazione, mette a disposizione. Ogni subscriber inizialmente sottoscrive l abbonamento al servizio, specificando alla produzione normativa di quale o quali enti è 15

16 interessato. In seguito, il distributor provvede a fornire a ogni subscriber le norme nel frattempo prodotte, inviandogliele (servizio push) o fornendogliele su richiesta (servizio pull). Lo schema Multicasting è adatto quanto l ente normatore interessato alla pubblicazione sia uno solo. In tale caso, i subscriber si rivolgono direttamente a lui, sia per l abbonamento al servizio, sia per la fornitura delle normative prodotte. Il meccanismo Multicasting richiede, in generale, la conoscenza reciproca da parte degli utenti e del fornitore del servizio. Nel caso in cui il servizio informativo sia aperto al pubblico, si parla più propriamente di Broadcasting. Lo schema Instance Based Routing consentirebbe, nel nostro esempio, di fornire un servizio informativo più diversificato, che permette all utente di selezionare le norme da ricevere non solo in base alla tipologia (per esempio, leggi regionali ) e all ente normatore (per esempio una specifica Regione) ma anche in base al contenuto (per esempio, norme riguardanti le tematiche ambientali, ovvero norme nel cui testo ricorre il termine documento elettronico ). Lo schema Store & Forward, infine, si distingue per la flessibilità del collegamento richiesto fra il distributor e i subscriber che, a differenza dello schema Publish & Subscribe, non è necessario sia attivo al momento della diffusione delle informazioni richieste. Nel nostro esempio, è probabilmente consigliabile lo schema Store & Forward per la fornitura delle norme di interesse a utenti non istituzionali (per esempio, imprese private), per le quali non è realistico ipotizzare un collegamento perennemente attivo con il distributor, mentre per gli utenti istituzionali (gli enti pubblici) lo schema Publish & Subscribe sarebbe di naturale applicazione, anche alla luce della disponibilità della Rete Unitaria Quadro metodologico Le metodologie adottate in questo settore derivano dall evoluzione delle metodologie classiche di progettazione di sistemi informativi con i contributi derivanti dalle problematiche proprie dei sistemi distribuiti e dei sistemi orientati agli oggetti [Umar1, 1997]. La Figura 13 mostra, su un impianto metodologico classico a cascata, le fasi principali che si innestano per trattare le tematiche della distribuzione di un sistema basato sui oggetti. 16

17 Progetto concettuale del sistema complessivo Progetto dello schema a oggetti del sistema complessivo Progetto della distribuzione dello schema a oggetti Progetto logico e fisico, realizzazione e test di ogni oggetto Integrazione e test di sistema Figura 13 - Quadro metodologico per la progettazione di sistemi distribuiti a oggetti In particolare: a valle della produzione di una rappresentazione concettuale del sistema, ottenuta con tecniche tradizionali o object oriented, si produce lo schema basato su oggetti del sistema; questo processo è supportato dall uso di euristiche di trasformazione per il passaggio dalla rappresentazione concettuale iniziale a quella basata su oggetti; lo schema ad oggetti così ottenuto è la base del progetto della distribuzione del sistema sulla rete di calcolatori disponibili; si individuano i nodi chiamati ad ospitare ogni oggetto del sistema e si risolvono le problematiche di frammentazione, replicazione, parallelismo ed allocazione che conducono alla configurazione ottimale del sistema sulla rete; ogni oggetto componente lo schema ad oggetti risultante è realizzato autonomamente, usando le metodologie e gli ambienti di sviluppo che meglio si adattano al compito da svolgere, all ambiente elaborativo ospitante ed alla cultura del gruppo di sviluppo; i diversi oggetti realizzati sono integrati in modo da comporre il sistema complessivo, verificando il corretto funzionamento delle mutue connessioni e delle modalità di esecuzione dei servizi offerti dalle interfacce Progettazione dello schema a oggetti In questa fase il prodotto del progetto concettuale del sistema complessivo effettuato durante la fase precedente (in generale costituito da schemi concettuali dei dati e delle 17

18 funzioni, seguendo approcci tradizionali, o da schemi orientati agli oggetti, seguendo un approccio object-oriented) deve essere trasformato in uno schema basato su oggetti del sistema complessivo. Tenendo presente la definizione di oggetto, i criteri che si seguono nell individuazione degli oggetti dello schema sono quelli della massima coesione interna fra dati e funzioni formanti i singoli oggetti e del minimo accoppiamento fra oggetti diversi. In tale modo, infatti, si minimizzano le necessità di comunicazione fra oggetti diversi in esercizio, allocabili su nodi elaborativi diversi e quelle di accordo fra gruppi di lavoro diversi che realizzino oggetti diversi Progettazione della distribuzione In questa fase lo schema a oggetti deve essere distribuito in modo ottimale sulla rete di elaboratori [Coulouris et alii, 1994] [Goscinski, 1991] [Mullender, 1993] [Simon, 1996]. La Figura 14 individua i passi principali da compiere. Requisiti organizzativi e tecnici 1 - Identificazione delle alternative di configurazione Descrizione delle possibili alternative Progetto complessivo del sistema Grafo di allocazione degli oggetti 3 - Allocazione degli oggetti nui nodi della rete 2 - Progetto della frammentazione e della replicazione Figura 14 - Progetto della distribuzione 18

19 Passo 1 Identificazione delle alternative di configurazione della rete In base alla realtà esistente e ai requisiti del nuovo sistema, si individuano le topologie di rete possibili e le caratteristiche dei nodi elaborativi. In questa fase è particolarmente importante individuare eventuali applicazioni legacy con cui interfacciarsi, che possono vincolare in modo significativo le scelte di allocazione Passo 2 Progetto della frammentazione e della replicazione In questo passo, ogni oggetto dello schema a oggetti originario può essere: frammentato, ovvero suddiviso in un insieme di oggetti cooperanti; la frammentazione è effettuata quando si desideri aumentare la località con la quale i servizi forniti da serventi sono erogati ai clienti; si pensi, a tale proposito, ai meccanismi dei proxy client e dei proxy server, che permettono di aumentare l efficienza e la continuità di servizio diminuendo le comunicazioni in rete; replicato, ai fini di una maggiore continuità di servizio, di una maggiore tolleranza ai guasti e di maggiori livelli prestazionali; la replicazione è uno strumento ottimale qualora le repliche non condividano uno stato interno modificabile nel tempo e non abbiano quindi necessità di frequente sincronizzazione reciproca. Quando si frammenta un oggetto, i sottocomponenti possono avere un grado di mutua coesione nullo (nessuna necessità di cooperazione) o non nullo. In questo ultimo caso la frammentazione avviene: senza replicazione: si osserva in tal caso comunicazione fra i componenti; con replicazione: ottimale quando le diverse repliche non abbiano uno stato interno da condividere. Durante questo passo, inoltre, si identifica per ogni oggetto la necessità di essere: mono-processo: in questo caso l oggetto è chiamato a risolvere le richieste di un solo cliente; oggetti di questa natura sono tipicamente gli oggetti di interfaccia utente; multi-processo: in questo caso l oggetto è chiamato a risolvere richieste provenienti in parallelo da più clienti; oggetti di questa natura sono quelli che incapsulano risorse condivise e che richiedono, in sede di realizzazione, la risoluzione di problematiche di gestione della concorrenza. 19

20 Passo 3 Allocazione degli oggetti sui nodi della rete Durante questo passo i diversi oggetti costituenti lo schema, eventualmente frammentati e replicati, debbono essere allocati sui diversi nodi fisici della rete di calcolatori disponibili. Il passo di allocazione tiene conto dei seguenti fattori: località degli oggetti rispetto a utilizzatori e risorse: gli oggetti usati direttamente dagli utenti (interfaccia utente) saranno allocati sulle macchine usate dagli utenti stessi; gli oggetti che gestiscono risorse legacy (basi di dati, transazioni) saranno collocati possibilmente sui sistemi legacy stessi; disponibilità sul nodo delle funzionalità necessarie per il funzionamento dell oggetto: ogni oggetto, per funzionare, richiede risorse elaborative e di memorizzazione specifiche che debbono essere presenti sul nodo elaborativo che lo ospita, o comunque convenientemente raggiungibili da questo; per esempio, un oggetto che debba funzionare in modalità multi-processo deve essere allocato su un nodo dotato di un sistema operativo che permetta la presenza contemporanea di più processi in esecuzione; un oggetto che debba eseguire operazioni matematiche complesse si avvantaggerà della presenza di coprocessori matematici sulla macchina che lo ospita; un oggetto che debba gestire dati multimediali richiede un nodo elaborativo dotato di capacità e periferiche specifiche; ottimalità della collocazione di ogni oggetto in rapporto alle capacità elaborative e di memorizzazione dei singoli nodi e alle capacità di trasmissione dei canali di comunicazione fra nodi; uno schema di allocazione di oggetti su una rete di calcolatori è ritenuto accettabile se la potenza elaborativa richiesta a ogni nodo è inferiore di quella disponibile e se il traffico di dati su ogni tratta è inferiore alla sua capacità. La verifica del progetto di allocazione si effettua conoscendo il grado di replicazione degli oggetti, la frequenza di invocazione dei diversi servizi offerti dagli oggetti serventi, il carico elaborativo richiesto nell esecuzione dei singoli servizi, e confrontando il carico complessivo sugli elaboratori e sui canali trasmissivi con la capacità elaborativa, di memorizzazione e di trasmissione degli stessi. Il progetto della distribuzione è un processo iterativo, in quanto non è detto che un primo schema a oggetti sia allocabile sulla rete di calcolatori data in modo da soddisfare tutti i requisiti e i vincoli che si evidenziano durante il passo di allocazione. Le indicazioni che emergono durante questo passo portano il progettista a rivedere lo schema a oggetti, usando in particolare gli strumenti della frammentazione e della replicazione spingendolo, in casi estremi, a proporre variazioni sulle dotazioni hardware e software della rete di calcolatori da adottare. 20

2. Sistemi centralizzati, sistemi distribuiti e sistemi cooperativi

2. Sistemi centralizzati, sistemi distribuiti e sistemi cooperativi CAPITOLO 1 ARCHITETTURE DEI SISTEMI DISTRIBUITI Antonio Massari, Massimo Mecella, Enrico Melis, Gaetano Santucci 1. Introduzione Le architetture dei sistemi informativi si sono sviluppate e evolute nel

Dettagli

8. Sistemi Distribuiti e Middleware

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

Dettagli

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

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

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

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

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

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

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

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

Sistemi Informativi Distribuiti

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

Dettagli

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

Struttura della lezione. Lezione 9 Architetture dei sistemi distribuiti (2) Il valore aggiunto di una rete di N utenti

Struttura della lezione. Lezione 9 Architetture dei sistemi distribuiti (2) Il valore aggiunto di una rete di N utenti Struttura della lezione Lezione 9 Architetture dei sistemi distribuiti (2) Vittorio Scarano Corso di Programmazione Distribuita (2003-2004) Laurea di I livello in Informatica Università degli Studi di

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

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

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

Dettagli

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE ARCHITETTURE DEI SISTEMI DI ELABORAZIONE 1 SISTEMI ACCENTRATI CARATTERISTICHE Sistemi proprietari Monocultura Scarsa diffusione informatica Backlog 2 Soluzione centralizzata TERMINALE TERMINALE ELABORATORE

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

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

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

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

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

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

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

Dettagli

Linguaggio SQL: costrutti avanzati

Linguaggio SQL: costrutti avanzati Linguaggio SQL: costrutti avanzati Gestione delle transazioni Introduzione Transazioni in SQL Proprietà delle transazioni 2 Pag. 1 1 Gestione delle transazioni Esempio applicativo Operazioni bancarie operazione

Dettagli

Tecnologia dei Sistemi Informativi. architettura s.i. 1

Tecnologia dei Sistemi Informativi. architettura s.i. 1 Tecnologia dei Sistemi Informativi architettura s.i. 1 Sistema Informativo comprende risorse umane è fortemente integrato con il sistema organizzativo è essenziale per il funzionamento dell'azienda architettura

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

Pag. 1. Gestione delle transazioni. Linguaggio SQL: costrutti avanzati. Esempio applicativo. Gestione delle transazioni. Prelievo. Esempio applicativo

Pag. 1. Gestione delle transazioni. Linguaggio SQL: costrutti avanzati. Esempio applicativo. Gestione delle transazioni. Prelievo. Esempio applicativo Gestione delle transazioni Introduzione Transazioni in SQL Linguaggio SQL: costrutti avanzati 2 applicativo Operazioni bancarie operazione di prelievo dal proprio conto corrente mediante bancomat Gestione

Dettagli

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011

Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 Corso di Laurea in Ingegneria Informatica Algoritmi e basi di dati Modulo Basi di dati a.a. 2010-2011 2011 Docente: Gigliola Vaglini Docente laboratorio: Alessandro Lori 1 Obiettivi del corso Imparare

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE Internet e la Banca Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Gruppo AIVE 1 Scenario Le BANCHE in Italia, al contrario delle concorrenti europee, hanno proposto, sul mercato dei nuovi

Dettagli

Introduzione ai Sistemi Distribuiti

Introduzione ai Sistemi Distribuiti Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ai Sistemi Distribuiti Corso di Sistemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Definizioni di SD Molteplici

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

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

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

Dettagli

Capitolo 3: Strutture dei sistemi operativi

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

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

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

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

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Organizzazione del testo

Organizzazione del testo Questo testo è un introduzione allo standard CORBA (Common Object Request Broker Architecture) e all architettura di riferimento OMA (Object Management Architecture), per lo sviluppo di sistemi software

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

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

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Estratto dell'agenda dell'innovazione e del Trade Bologna 2011 Speciale: I casi Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Innovare e competere con le ICT: casi di successo - PARTE I Cap.8

Dettagli

B.P.S. Business Process Server ALLEGATO C10

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

Dettagli

Architetture per le applicazioni web-based. Mario Cannataro

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

Dettagli

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

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

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

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

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

Dettagli

@2011 Politecnico di Torino. Pag. 1. Architettura distribuita. Architetture Client/Server. Architettura centralizzata. Architettura distribuita

@2011 Politecnico di Torino. Pag. 1. Architettura distribuita. Architetture Client/Server. Architettura centralizzata. Architettura distribuita Architettura client/ stazioni utente Basi di ati Architetture /Server B locali M BG Architettura centralizzata Un architettura è centralizzata quando i dati e le (programmi) risiedono in un unico Tutta

Dettagli

Basi di Dati Distribuite

Basi di Dati Distribuite Basi di Dati Distribuite P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone (McGraw-Hill Italia) Basi di dati: architetture linee di evoluzione - seconda edizione Capitolo 3 Appunti dalle lezioni SQL come DDL

Dettagli

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

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

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

INTRODUZIONE. Motivazioni e Obbiettivi

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

Dettagli

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Versione Preliminare Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2008-2009 Questi

Dettagli

CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE.

CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE. CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE. Articolo 1 Oggetto dell appalto 1. L appalto ha per oggetto la progettazione,

Dettagli

Ministero del Lavoro e delle Politiche Sociali

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

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

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

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

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

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

Identificazione dei bisogni Introduzione

Identificazione dei bisogni Introduzione Pagina 1 di 5 Identificazione dei bisogni Introduzione Le Tecnologie dell'informazione e della Comunicazione (TIC, o anche, in inglese, Information and Communication Technologies, ICT) hanno profondamente

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE SISTEMI ACCENTRATI CARATTERISTICHE ARCHITETTURE DEI SISTEMI DI ELABORAZIONE Sistemi proprietari Monocultura Scarsa diffusione informatica Backlog 1 2 Soluzione centralizzata SISTEMI DISTRIBUITI TERMINALE

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

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata COD. PROD. D.6.3 1 Indice Considerazioni sulla virtualizzazione... 3 Vantaggi della virtualizzazione:... 3 Piattaforma di virtualizzazione...

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

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D Introduzione Versioni al tratto Versione 3D Sistemi La versione negativa Distribuiti 3D prevede l utilizzo dell ombra esclusivamente sul fondo colore Rosso Sapienza. Laurea magistrale in ingegneria informatica

Dettagli

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

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

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 SECONDO BIENNIO Disciplina: INFORMATICA La disciplina Informatica concorre a far conseguire allo

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

Reti di Calcolatori. Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer

Reti di Calcolatori. Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer Reti di Calcolatori 1. Introduzione Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer Reti di calcolatori : Un certo numero di elaboratori

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

Sistema Operativo Compilatore

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

Dettagli

Infrastrutture INFormatiche Ospedaliere 2 Corso di laurea di Ingegneria Medica. Indice 5. SISTEMI INFORMATIVI BASATI SU WEB...2

Infrastrutture INFormatiche Ospedaliere 2 Corso di laurea di Ingegneria Medica. Indice 5. SISTEMI INFORMATIVI BASATI SU WEB...2 Indice 5. SISTEMI INFORMATIVI BASATI SU WEB...2 5.1 INTRODUZIONE...2 5.2 EVOLUZIONE DELLE ARCHITETTURE INFORMATICHE...3 5.3 CLASSIFICAZIONE DEI SISTEMI INFORMATIVI BASATI SU WEB...5 5.3.1 Tipologia del

Dettagli

L evoluzione delle Applicazioni Distribuite

L evoluzione delle Applicazioni Distribuite L evoluzione delle Applicazioni Distribuite Dai terminali a fosfori verdi al Client-Server a Internet Architettura basata su Mainframe thin client su 3270 a fosfori verde server TP-Monitor su Mainframe

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO CARRARO GROUP

Estratto dell'agenda dell'innovazione e del Trade Padova 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO CARRARO GROUP Estratto dell'agenda dell'innovazione e del Trade Padova 2011 Speciale: I casi Introduzione dell'area tematica IL CASO CARRARO GROUP Innovare e competere con le ICT: casi di successo - PARTE II Cap.9 Far

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

IN CHIAVE E-GOVERNMENT

IN CHIAVE E-GOVERNMENT UNA NUOVA SUITE IN CHIAVE E-GOVERNMENT La Pubblica Amministrazione cambia. Si fa strada concretamente l idea di uno stile di governo innovativo che, grazie alla potenzialità di interconnessione, renda

Dettagli

componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali

componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali 1 Premessa I sistemi informativi basati su Web sono usati per gestire grandi quantità di informazioni su Internet e per gestire la collaborazione tra siti distribuiti che cooperano agli stessi scopi aziendali.

Dettagli

TECNICO SUPERIORE PER LE TELECOMUNICAZIONI

TECNICO SUPERIORE PER LE TELECOMUNICAZIONI ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE TELECOMUNICAZIONI STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

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

Corso di Sistemi di elaborazione delle informazioni

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

Dettagli

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

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

Sistemi Operativi (modulo di Informatica II)

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

Dettagli

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

Sme.UP Web Application

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

Dettagli

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 linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration COSA FACCIAMO SEMPLIFICHIAMO I PROCESSI DEL TUO BUSINESS CON SOLUZIONI SU MISURA EXTRA supporta lo sviluppo

Dettagli

La carta di identità elettronica per il sistema dei servizi

La carta di identità elettronica per il sistema dei servizi La carta di identità elettronica per il sistema dei servizi L AMMINISTRAZIONE LOCALE: IL FRONT OFFICE DELL INTERO MONDO DELLA PUBBLICA AMMINISTRAZIONE Con il Piano di E-Government, con il ruolo centrale

Dettagli