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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Architettura del sistema

Architettura del sistema 18/06/15 I N D I C E 1 INTRODUZIONE... 2 2 DEFINIZIONE DEGLI OBIETTIVI... 2 3 PROGETTO DI MASSIMA... 3 3.1 REQUISITI DELLA SOLUZIONE... 4 4 LA SOLUZIONE... 4 4.1 IL NUCLEO CENTRALE... 5 4.1.1 La gestione

Dettagli

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Servizi di connessione Prodotti a supporto del business Per sfruttare al meglio una rete di ricarica per veicoli

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

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi PRIVACY E SICUREZZA LA PRIVACY DI QUESTO SITO In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano. Tale politica

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

Sistemi centralizzati e distribuiti

Sistemi centralizzati e distribuiti Sistemi centralizzati e distribuiti In relazione al luogo dove è posta fisicamente la base di dati I sistemi informativi, sulla base del luogo dove il DB è realmente dislocato, si possono suddividere in:

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

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

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

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

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

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

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 all elaborazione di database nel Web

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

Dettagli

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

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

Progettaz. e sviluppo Data Base

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

Dettagli

Object Oriented Programming

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

Dettagli

Introduzione ai Sistemi Operativi

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

Dettagli

IL SISTEMA INFORMATIVO AZIENDALE

IL SISTEMA INFORMATIVO AZIENDALE IL SISTEMA INFORMATIVO AZIENDALE CL. 5ATP - A.S. 2006/2007 L azienda e i suoi elementi PERSONE AZIENDA BENI ECONOMICI ORGANIZZAZIONE L azienda è un insieme di beni organizzati e coordinati dall imprenditore

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

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

Check list per la valutazione di adeguatezza e Indice di adeguatezza

Check list per la valutazione di adeguatezza e Indice di adeguatezza Check list per la valutazione di adeguatezza e Indice di adeguatezza DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 16 Indice 1. PREMESSA... 3 2. ELEMENTI DI VALUTAZIONE DELL ADEGUATEZZA DELLA SOLUZIONE...

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

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

@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

L Informatica al Vostro Servizio

L Informatica al Vostro Servizio L Informatica al Vostro Servizio Faticoni S.p.A. è Certificata UNI ENI ISO 9001:2008 N. CERT-02228-97-AQ-MILSINCERT per Progettazione, Realizzazione, Manutenzione di soluzioni Hardware e Software Soluzioni

Dettagli

SERVER E VIRTUALIZZAZIONE. Windows Server 2012. Guida alle edizioni

SERVER E VIRTUALIZZAZIONE. Windows Server 2012. Guida alle edizioni SERVER E VIRTUALIZZAZIONE Windows Server 2012 Guida alle edizioni 1 1 Informazioni sul copyright 2012 Microsoft Corporation. Tutti i diritti sono riservati. Il presente documento viene fornito così come

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

e.toscana Compliance visione d insieme

e.toscana Compliance visione d insieme Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione

Dettagli

Outsourcing: un nuovo servizio

Outsourcing: un nuovo servizio Outsourcing: un nuovo servizio Ottobre 2001 I diritti di riproduzione, di memorizzazione elettronica e di adattamento totale o parziale con qualsiasi mezzo, compresi i microfilm e le copie fotostatiche

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

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

Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi.

Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi. Via Emanuela Loi 1, 09010 Villaspeciosa (CA) P.IVA 03071740926 - Tel.+39 380 45 42 015 CF: CSCLSN78R17B354H *** @Mail: info@afnetsistemi.it @Pec: info.afnet@pec.it Web: http://www.afnetsistemi.it E-Commerce:

Dettagli

w w w. n e w s o f t s r l. i t Soluzione Proposta

w w w. n e w s o f t s r l. i t Soluzione Proposta w w w. n e w s o f t s r l. i t Soluzione Proposta Sommario 1. PREMESSA...3 2. NSPAY...4 2.1 FUNZIONI NSPAY... 5 2.1.1 Gestione degli addebiti... 5 2.1.2 Inibizione di un uso fraudolento... 5 2.1.3 Gestione

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

7. Architetture Software

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

Dettagli

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

Relazione introduttiva Febbraio 2006

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

Dettagli

Alessandra Raffaetà. Basi di Dati

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

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

BOZZA DEL 06/09/2011

BOZZA DEL 06/09/2011 ARTICOLAZIONE: INFORMATICA Disciplina: COMPLEMENTI DI MATEMATICA (C4) Il docente di Complementi di matematica concorre a far conseguire allo studente, al termine del percorso quinquennale, i seguenti risultati

Dettagli

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO 1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO Quello che generalmente viene chiamato sistema di automazione d edificio si compone di diverse parti molto eterogenee tra loro che concorrono, su diversi livelli

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

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

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

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1)

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1) La gestione di un calcolatore Sistemi Operativi primo modulo Introduzione Augusto Celentano Università Ca Foscari Venezia Corso di Laurea in Informatica Un calcolatore (sistema di elaborazione) è un sistema

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

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

Tecnologia di un Database Server (centralizzato) Introduzione generale

Tecnologia di un Database Server (centralizzato) Introduzione generale Introduzione Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Introduzione generale Angelo Montanari Dipartimento di Matematica e Informatica Università di

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

All INTERNO DELLA RETE DEL VALORE DI INTERNET E POSSIBILE INDIVIDUARE 2 GRUPPI PRINCIPALI UTILIZZATORI FINALI ABILITATORI

All INTERNO DELLA RETE DEL VALORE DI INTERNET E POSSIBILE INDIVIDUARE 2 GRUPPI PRINCIPALI UTILIZZATORI FINALI ABILITATORI 1 Lo scenario: i soggetti che operano su Internet All INTERNO DELLA RETE DEL VALORE DI INTERNET E POSSIBILE INDIVIDUARE 2 GRUPPI PRINCIPALI UTILIZZATORI FINALI E-market player Digitalizzatori di processi

Dettagli

IL CSI PIEMONTE PER LA CONTINUITÀ DEI VOSTRI SERVIZI

IL CSI PIEMONTE PER LA CONTINUITÀ DEI VOSTRI SERVIZI IL CSI PIEMONTE PER LA CONTINUITÀ DEI VOSTRI SERVIZI LA CONTINUITÀ OPERATIVA È UN DOVERE La Pubblica Amministrazione è tenuta ad assicurare la continuità dei propri servizi per garantire il corretto svolgimento

Dettagli

Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server

Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server Caso di successo Microsoft Virtualizzazione Gruppo Arvedi Il Gruppo Arvedi sceglie tecnologie Microsoft per la virtualizzazione dei sistemi server Informazioni generali Settore Education Il Cliente Le

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

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

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

Dettagli

Informatica per la comunicazione" - lezione 9 -

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

Dettagli

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

Automazione Industriale 4- Ingegneria del Software

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

Dettagli

Basi di dati (3) Ing. Integrazione di Impresa A.A. 2007/08

Basi di dati (3) Ing. Integrazione di Impresa A.A. 2007/08 Università di Modena e Reggio Emilia Panoramica Basi di dati (3) Ing. Integrazione di Impresa A.A. 2007/08 Docente: andrea.bulgarelli@gmail.com Argomento: struttura SQL Server (1.0)! Componenti! Edizioni!

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Corso Web programming

Corso Web programming Corso Web programming Modulo T3 A1 Modelli di programmazione 1 Prerequisiti Concetto di rete Processi e thread Concetti generali sui database 2 1 Introduzione Un particolare ambito della programmazione

Dettagli

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

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

Dettagli

L archivio di impresa

L archivio di impresa L archivio di impresa Mariella Guercio Università degli studi di Urbino m.guercio@mclink.it Politecnico di Torino, 25 novembre 2011 premessa L archivistica è una disciplina della complessità, aperta, basata

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

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario

Data Base Management System. Strumenti: Formato: Pro: Contro: Software specifico. Proprietario Data Base Management System Strumenti: Software specifico Formato: Pro: Proprietario Massima semplicità di inserimento e gestione Tipizzazione Validazione dei dati Contro: Creazione del database Programmazione

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

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

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

Dettagli

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

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE EGIDIO PICERNO POTENZA 9 LUGLIO 2010 Interoperabiltà è la capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto

Dettagli

I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno

I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno I benefici di una infrastruttura IT sicura e ben gestita: come fare di più con meno In questi ultimi anni gli investimenti

Dettagli

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

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

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Strumento evoluto di Comunicazione con i Venditori

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

Dettagli

Creare una Rete Locale Lezione n. 1

Creare una Rete Locale Lezione n. 1 Le Reti Locali Introduzione Le Reti Locali indicate anche come LAN (Local Area Network), sono il punto d appoggio su cui si fonda la collaborazione nel lavoro in qualunque realtà, sia essa un azienda,

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

10. Stratificazione dei protocolli

10. Stratificazione dei protocolli 10. Stratificazione dei protocolli 10.1. Introduzione Abbiamo visto la struttura dell'internet. Ora dobbiamo esaminare la struttura del restante software di comunicazione, che è organizzato secondo il

Dettagli