UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II FACOLTÀ DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESI DI LAUREA INTEGRAZIONE DI MECCANISMI ADATTATIVI IN UN ORB CORBA UTILIZZANDO LA PROGRAMMAZIONE ORIENTATA AGLI ASPETTI RELATORE Ch.mo Prof. Domenico Cotroneo CANDIDATO Luciano D Andrea Matr. 41/2143 CORRELATORE Ing. Armando Migliaccio ANNO ACCADEMICO

2 Indice Introduzione... i Capitolo 1 Middleware adattativi Middleware CORBA Architettura Interoperabilità tra ORB Middleware adattativi Autonomic computing QoS-enabled Tecniche di implementazione Esempi di middleware adattativi Capitolo 2 Aspect-Oriented Programming Introduzione AspectJ Join Point Pointcut Advice Inter-type declaration Aspect AspectJ compiler Adattività mediante Aspect-Oriented... 52

3 2.5 Obiettivo Capitolo 3 Caso di studio Introduzione Delay Implementazione Fault tolerance Implementazione Oggetto servente Adaptive Compiler Adaptive Stub Adaptive Skeleton Appendice A JacORB Bibliografia... 94

4 Ringraziamenti

5 Introduzione I middleware tradizionali sono stati sviluppati con riferimento ad applicazioni distribuite su reti e nodi fissi, caratterizzati da ambienti di esecuzione fortemente statici. Con la rivoluzione del mobile computing gli ambienti di esecuzione sono diventati sempre più dinamici e non predicibili, rendendo meccanismi adattativi, tradizionalmente utilizzati nei sistemi real-time, di fondamentale importanza. L obiettivo di questo lavoro di tesi è quello di integrare meccanismi adattativi in un ORB CORBA, in modo da consentire alle applicazioni distribuite CORBA di adattare il proprio comportamento in base alle specifiche definite dall applicazione. In particolare si è fatto riferimento a due casi di studio: nel primo si considera come specifica un vincolo su un parametro di QoS, come il delay; nel secondo si vuole garantire una determinata fault tolerance. A tal fine si è utilizzato l Aspect-Oriented Programming (AOP), che consente di intervenire sulla piattaforma CORBA in maniera trasparente alle applicazioni. Infatti l AOP è il più diffuso tra gli approcci che consentono la Separation of Concerns (SoC), ovvero la separazione del comportamento funzionale di una applicazione dai suoi crosscutting concerns (quali QoS, consumo di energia, fault tolerance e sicurezza). Inoltre l AOP permette di modificare il comportamento di una applicazione utilizzando il meccanismo del join point advice, che consente di intercettare punti ben precisi dell applicazione e definire un nuovo comportamento da adottare. i

6 Il caso di studio sviluppato in questa tesi offre alle applicazioni distribuite CORBA strumenti in grado di adattare il proprio comportamento in relazione alle specifiche definite sul delay e sulla fault tolerance. Per quanto riguarda il delay, esso viene specificato nell applicazione cliente, si intercetta la richiesta di un servizio offerto da un oggetto CORBA, dopodichè si effettua la valutazione del valore di delay (confrontando il valore imposto e il valore letto da un monitor) e quindi, eventualmente, si utilizzano dei meccanismi in grado di far rispettare le condizioni imposte. Per quanto riguarda la fault tolerance, viene specificata nell applicazione servente definendo il tipo di operation mode, ovvero il numero di repliche e il tipo di adjudication strategy da utilizzare. Dunque, in maniera del tutto trasparente all applicazione, si intercetta l esecuzione del servizio offerto da un oggetto CORBA, dopodichè si creano le repliche dell oggetto servente, si inoltra la richiesta del servizio a tali repliche ed infine si crea la risposta in base al tipo di adjudication strategy. Al fine di dotare la piattaforma CORBA di tali meccanismi si è progettato e realizzato un compilatore, denominato ADACompiler, che genera uno stub e uno skeleton che si integrano con quelli esistenti, estendendo in tal modo le loro funzionalità. ii

7 Capitolo 1 Middleware adattativi Capitolo 1 Middleware adattativi 1.1 Middleware Il middleware può essere visto come uno strato software interposto tra il sistema operativo e le applicazioni, in grado di fornire le astrazioni e i servizi utili per lo sviluppo di applicazioni distribuite. Dunque una piattaforma middleware consiste in un insieme di servizi che permettono alle applicazioni di interoperare scambiandosi dati su rete, indipendentemente dai dettagli e dalle differenze tra i linguaggi di programmazione, i sistemi operativi e i protocolli di rete sottostanti. Spesso in letteratura le piattaforme middleware vengono definite come software di connettività tra applicazioni o anche tecnologie collanti (glue technologies), proprio per evidenziare la loro caratteristica di tecnologie di integrazione di applicazioni. Ogni tecnologia middleware si basa su un ben definito modello di elaborazione distribuita, ma caratteristiche comuni sono quelle di: offrire meccanismi di interazione e comunicazione tra applicazioni a un alto livello di astrazione; rendere il più possibile trasparente al programmatore l eterogeneità tra i sistemi dell architettura distribuita. 1

8 Capitolo 1 Middleware adattativi Ci sono diverse tipologie di middleware. Le varie tipologie differiscono tra loro in maniera sostanziale per funzionalità offerte, meccanismi di comunicazione, standard, modelli di programmazione e ambito applicativo. I principali modelli sono: Distribuited Tuples Il modello dello spazio delle tuple si basa su un astrazione di comunicazione costituita da uno spazio virtuale di memoria condiviso (virtual shered memory): le applicazioni possono sincronizzarsi e scambiarsi dati inserendo e prelevando strutture dati (le tuple) dallo spazio di memoria virtuale, mediante operazioni di scrittura (write), lettura (read) e rimozione (take). Remote Procedure Call Il modello di chiamata a procedura remoto (RPC) è un estensione in ambiente distribuito del meccanismo di chiamata a procedura previsto dai tradizionali linguaggi di programmazione. Message-Oriented Middleware Il modello orientato allo scambio di messaggi (MOM) si basa sull astrazione di una coda di messaggi tra processi interoperanti su rete. Nel modello MOM la comunicazione non è di tipo client-server, nel senso che l interazione non avviene per sua natura tra un entità in attesa passiva di richieste e entità che intraprendono la comunicazione, ma è di tipo produttore-consumatore ed è prevalentemente asincrona, sebbene alcuni sistemi consentano anche uno scambio di messaggi di tipo sincrono. 2

9 Capitolo 1 Middleware adattativi Distributed Object Il modello a oggetti distribuito (DOM) nasce dall integrazione di due paradigmi di programmazione: il paradigma dell orientamento agli oggetti e il paradigma client-server. Dal punto di vista concettuale i due paradigmi si fondono in maniera naturale, un oggetto infatti può essere visto come un servente, inteso come entità passiva, che accetta richieste di operazioni per l accesso al proprio stato interno; all invocazione di un operazione su un oggetto-servente può essere attribuita la semantica di tipo client-server. Le piattaforme DOM si presentano sovente sotto forma di Object Request Broker (ORB). Un ORB è una sorta di bus software per l interazione tra oggetti distribuiti su sistemi eterogenei; la comunicazione con un oggetto servente è mediata dal bus, e avviene tramite messaggi di richiesta e risposta scambiati da apposite procedure stub. Esempi di ORB sono Microsoft DCOM e OMG CORBA. 1.2 CORBA CORBA, acronimo di Common Object Request Broker Architecture, è la specifica di un modello di riferimento per middleware a oggetti, che fa parte di un più ampio modello architetturale denominato Object Management Architecture (OMA). 3

10 Capitolo 1 Middleware adattativi CORBA ed OMA sono definiti dal consorzio Object Management Group (OMG). OMG è una organizzazione nata nel 1989 per iniziativa di otto aziende, tra cui Canon, Hewlett-Packard, Philips Telecomminucations, Sun Microsystem e Unisys. Obiettivi del consorzio sono la promozione e standardizzazione di tecnologie e metodologie relative a sistemi software distribuiti orientati agli oggetti, in modo da ridurne la complessità di sviluppo, e supportare l interoperabilità tra ambienti eterogenei Architettura Una applicazione distribuita CORBA consiste di oggetti serventi - entità passive che offrono servizi e che chiameremo oggetti CORBA - e di clienti - entità attive che accedono ai loro servizi. L elemento fondamentale dell architettura è l Object Request Broker (ORB), che fornisce un insieme di servizi per l invocazione di metodi su oggetti remoti. L ORB è l intermediario di ogni interazione e garantisce le proprietà di trasparenza dei sistemi operativi, dei protocolli di rete e dei linguaggi di programmazione. 4

11 Capitolo 1 Middleware adattativi Figura 1.1 Quando il client invoca un operazione su di un oggetto remoto, l ORB è responsabile di trovare l implementazione dell oggetto invocato, attivarlo trasparentemente se necessario, consegnarli la richiesta del client e restituire il risultato al client. Per individuare l oggetto destinatario della richiesta del client, l ORB utilizza Interoperable Object Reference (IOR), cioè un riferimento univoco all oggetto in grado di identificare la macchina su cui è presente il server CORBA che gestisce l'oggetto del quale si vuole richiamare il metodo. 5

12 Capitolo 1 Middleware adattativi Ogni oggetto CORBA consiste di due parti distinte: l interfaccia, pubblica, specificata in un linguaggio ad hoc (IDL); l implementazione, privata, redatta in un linguaggio di programmazione. Il cliente interagisce con il servente sulla base dei servizi pubblicati nell interfaccia, ignorandone i dettagli implementativi. Per la descrizione delle interfacce lo standard CORBA definisce il linguaggio Interface Defination Language (IDL). Il linguaggio IDL consente di specificare le operazioni supportate dall oggetto, il tipo dei suoi parametri e il tipo ritornato. L implementazione invece avverrà in un linguaggio di programmazione (Java, C++, ). Per lo sviluppo dei clienti e dei serventi, lo standard definisce un insieme di interfacce base, che costituiscono il nucleo dell Object Request Broker (ORB). L interfaccia fornita dall ORB per la programmazione dal lato cliente consiste di: un interfaccia statica (static IDL stub, o anche Static Invocation Interface o SII); un interfaccia dinamica (Dynamic Invocation Interface o DII). Per la programmazione lato servente sono disponibili: un interfaccia statica (static IDL skeleton, o anche Static Skeleton Interface o SSI); un interfaccia dinamica (Dynamic Skeleton Interface o DSI); il Portable Object Adapter (POA). 6

13 Capitolo 1 Middleware adattativi Per l invocazione di un servizio remoto sono previste una modalità statica e una dinamica. La modalità statica va utilizzata quando è nota in fase di programmazione l interfaccia IDL del servizio; in tal caso il cliente accede all ORB attraverso lo static IDL stub. Analogamente, nella modalità statica l interazione tra l ORB e il servente ha luogo attraverso lo static IDL skeleton. La modalità dinamica va impiegata quando non è nota a tempo di compilazione l interfaccia IDL del servente; a tale scopo sono previste le interfacce DII e DSI, rispettivamente dal lato cliente e lato servente. A prescindere dalla modalità (statica o dinamica), l invocazione di un servizio avviene sempre con l intermediazione del Broker. L ORB riceve una richiesta dalle procedure stub o DII, quindi individua l Object Adapter relativo all oggetto destinatario. L Object Adapter demanda allo skeleton l estrazione dei parametri della richiesta (unmarshalling) e l invocazione del servizio sull oggetto servente (upcalling) Interoperabilità tra ORB Nell accezione CORBA un oggetto è un entità incapsulata che fornisce servizi ai clienti. Nel modello CORBA una applicazione è costituita da clienti e oggetti che, in generale, possono risiedere su ORB differenti. E possibile che un cliente su un 7

14 Capitolo 1 Middleware adattativi ORB richieda i servizi di un oggetto residente su un ORB differente; si pone dunque il problema di garantire l interoperabilità tra implementazioni commerciali eterogenee dello standard CORBA. Lo standard definisce un modello architetturale per l interoperabilità tra oggetti su ORB diversi, noto come CORBA Interoperability Architecture. A tale scopo l architettura definisce: Un formato universale per la rappresentazione degli object reference, denominato Interoperable Object Reference (IOR); Un formato comune per la rappresentazione dei dati, denominato Common Data Rappresentation (CDR). Il formato CDR è una rappresentazione dei dati neutra rispetto alle piattaforme hardware ed ai protocolli utilizzati nei vari domini ORB. Al più alto livello di astrazione, la Interoperability Architecture consiste di due protocolli per le interazioni tra ORB: General Inter-ORB Protocol (GIOP), obbligatorio per tutti gli ORB conformi allo standard, definisce il formato dei messaggi per le richieste di servizio agli oggetti e le relative risposte, e per la rappresentazione dei dati usa il formato CDR. La realizzazione di GIOP sui protocolli di trasporto della famiglia TCP/IP è denominata Internet Inter-ORB Protocol (IIOP); la sua implementazione è stata resa obbligatoria dalla versione CORBA 2.0; 8

15 Capitolo 1 Middleware adattativi Environment-Specific Inter-ORB Protocol (ESIOP), è di tipo opzionale, riguarda reti basate su protocolli proprietari o comunque usati per l interoperabilità con altri specifici ambienti middleware. Un object reference è l insieme di informazioni necessarie a un cliente per utilizzare un oggetto CORBA all interno di un ORB. Nelle specifiche OMG è definito un formato standard per gli object reference al fine di supportare l interoperabilità tra ORB diversi, denominato Interoperable Object Reference (IOR). La struttura dell IOR è costituita da tre elementi: Repository ID: indica l interfaccia IDL implementata dall oggetto a cui si riferisce l IOR. Endpoint Info: contiene le informazioni necessarie all ORB per stabilire la connessione con l oggetto, ad esempio, utilizzando il protocollo IIOP, in tale elemento sono contenuti la versione del protocollo, l indirizzo IP e il numero di porto TCP; Object Key: la struttura dei dati contenuti in questo elemento non è standardizzata e, pertanto, risulta dipendente dall ORB utilizzato. 1.3 Middleware adattativi Le piattaforme middleware e i servizi relativi costituiscono una componente vitale nella costruzione di sistemi distribuiti robusti. Il middleware facilita lo sviluppo di 9

16 Capitolo 1 Middleware adattativi sistemi software su larga scala, attenuando le difficoltà dello sviluppatore di applicazioni che si occupa di sviluppare un certo numero di servizi necessari al sistema. Le attuali richieste dei sistemi di computing richiedono una maggiore flessibilità dell infrastruttura del sistema, che devono adattarsi ai cambiamenti richiesti dalle applicazioni e dalle condizioni ambientali. I sistemi di prossima generazione richiedono un comportamento predicibile, come troughtput, scalability, dependability e sicurezza. Questa crescente complessità aggiunge, ad un già complesso processo di sviluppo software, un alta probabilità di errori progettuali. Le piattaforme middleware sono state tradizionalmente progettate come un sistema statico monolito. L evoluzione dei vari ambienti di computing, come sistemi distribuiti su larga scala, ubiquitous computing e pervasive computing richiedono una forte scalabilità su piccoli, medi e grandi sistemi. Per venire incontro a tali problematiche sono state sviluppate tecniche che consentono alle piattaforme middleware di ottenere informazioni riguardanti le condizioni dell ambiente circostante e di adattare il loro comportamento per meglio servire il loro obiettivo. In questo senso la ricerca sta fornendo promettenti tecniche in grado di fornire al middleware la capacità di venire incontro a tali esigenze. Tecniche come l adaptive e la reflective sono paradigmi emergenti chiave, per lo sviluppo di piattaforme middleware dinamiche. Tali tecniche permettono al sistema di adattarsi automaticamente venendo incontro alle esigenze 10

17 Capitolo 1 Middleware adattativi dell ambiente circostante e di quelle dell utente. L adattamento può avere luogo in maniera autonoma o semi-autonoma, in base all evoluzione dell ambiente, o alla definizione di varie politiche imposte dall utente o dall amministratore. Negli ultimi anni sono emerse varie piattaforme che supportano la riconfigurabilità, permettendo alla piattaforma di essere personalizzata per uno specifico task; questo lavoro ha condotto allo sviluppo di piattaforme middleware adattative. Un sistema adattativo ha la capacità di cambiare il proprio comportamento e le proprie funzionalità. Un middleware adattativo è un software il cui comportamento funzionale può essere modificato dinamicamente per ottimizzare i cambiamenti dovuti all ambiente o alle richieste dell applicazione. Il reflective middleware è il passo logico successivo una volta che un middleware adattativo è stato realizzato. Un sistema reflective è un sistema che può esaminare e analizzare le proprie capacità e l ambiente operativo, in modo da auto-adattarsi a run-time. Un middleware reflective fornisce i mezzi per consentire di entrate all interno di un sistema, in modo da poterlo manipolare ed adattare a run-time; tale approccio permette l esame automatico delle capacità del sistema e, la correzione e ottimizzazione automatica di tali capacità. Il processo di selfadaptation consente, quindi, a un sistema di fornire servizi migliori rispetto alle proprie esigenze o a quelle dell utente. Le piattaforme reflective supportano un comportamento adattativo avanzato; l adattamento può avere luogo 11

18 Capitolo 1 Middleware adattativi autonomamente in relazione allo stato del sistema, dell ambiente, o di politiche definite dall utente o dall amministratore. Le tecniche di adattatività e reflective sono intimamente correlate, tuttavia hanno chiare differenze e caratteristiche individuali: un sistema adattativo è in grado di cambiare il suo comportamento un sistema reflective può controllare/esaminare il suo stato interno I sistemi posso essere sia adattativi che reflective, o possono essere adattativi ma non reflective, o viceversa. Dunque entrambe queste tecniche possono essere utilizzate, fornendo un potente paradigma di controllo del sistema, consentendo di adattare il proprio comportamento, se necessario. Tipicamente un certo numero di zone all interno delle piattaforme middleware, le sue funzionalità e il suo ambiente sono favorevoli alla analisi, misura e controllo delle performance/funzionalità ottime o desiderate. Componenti software conosciuti come interceptors possono essere inseriti nel percorso di esecuzione di un sistema per monitorare le sue azioni. Usando gli interceptors o tecniche simili, i sistemi reflective possono estrapolare informazioni utili dal corrente contesto esecutivo ed effettuare un analisi su tali informazioni. Solitamente un sistema reflective avrà un certo numero di interceptors e sistemi di monitoraggio che possono essere usati per esaminare lo stato di un sistema, riportando informazioni riguardanti le prestazioni, carico di lavoro, o uso delle risorse correnti. 12

19 Capitolo 1 Middleware adattativi Autonomic computing Con l aumento del carico di lavoro e degli ambienti di esecuzione, i sistemi sono diventati maggiormente non precibili e complessi, richiedendo una maggiore attenzione nel fornire supporto per la loro installazione, configurazione e manutenzione. Per venire incontro a tale problematica IBM ha dato inizio al progetto dell autonomic computing. Il principale obiettivo dell autonomic computing è di semplificare ed automatizzare la gestione dei sistemi, software e hardware, consentendo di gestirsi automaticamente, senza la necessità dell intervento umano. Quattro fondamentali caratteristiche sono necessarie affinché un autonomic system possa gestirsi automaticamente: Self-Configuring Il sistema deve essere in grado di adattarsi al suo ambiente esecutivo. Self-Healing Il sistema deve essere capace di diagnosticare e risolvere interruzioni del servizio. Affinché un sistema sia self-healing, deve essere capace di riconoscere un failure ed isolarlo, proteggendo il resto del sistema dalla sua attività errata. Quindi deve essere in grado di effettuare trasparentemente il recovering dal failure, riparando o sostituendo la sezione del sistema che è responsabile dell errore. Self-Optimizing Il sistema deve valutare le potenziali ottimizzazione che possono essere effettuate. Mediante il monitoring e il tuning delle risorse il 13

20 Capitolo 1 Middleware adattativi sistema dovrebbe ottimizzare efficientemente le risorse per meglio venire incontro alle esigenze del contesto esecutivo e dell utente. Self-Protecting Il sistema deve proteggersi dagli attacchi. Questi sistemi devono prevedere un potenziale attacco, rilevare quando un attacco è in corso, identificare il tipo di attacco ed usare una appropriata contromisura per difendersi o per neutralizzare l attacco. Gli attacchi ad un sistema possono essere classificati come Denial-of-Service (DoS) o infiltrazioni di utenti non autorizzati a informazioni o funzionalità sensibili. Il tema comune condiviso da tutte queste caratteristiche è che ognuna richiede di gestire funzionalità del sistema che sono tradizionalmente di responsabilità dell amministratore del sistema. In questo ambito, le tecniche adattative e reflectives giocano un ruolo chiave nello sviluppo di autonomic computing QoS-enabled Le applicazione distribuited real-time and embedded (DRE) costituiscono una sempre più crescente e importante area di sviluppo. Tuttavia tali applicazioni hanno molte e differenti caratteristiche che con i convenzionali sistemi non possono essere soddisfatte, come le stringenti richieste di Quality of Service (QoS). 14

21 Capitolo 1 Middleware adattativi Middleware che possono soddisfare richieste di QoS, come latency, scalability, dependability e sicurezza, sono sempre più utilizzati per lo sviluppo di applicazioni DRE. La maggior parte delle applicazioni DRE hanno richieste di QoS, che devo essere soddisfatte simultaneamente in real-time. Per garantire che le applicazioni DRE possano soddisfare tali richieste, vari tipi di QoS provisioning possono essere effettuati per allocare e gestire le risorse end-to-end dei sistemi di computing e di comunicazione. La QoS provisoning può essere realizzata nei seguenti modi: Staticamente l allocazione delle risorse, sufficienti per supportare vari gradi di QoS, viene specificata preventivamente nell applicazione. Dinamicamente, l allocazione delle risorse è determinata e gestita in base allo stato del sistema a runtime. La QoS provisioning statica consente di predeterminare le risorse necessarie a soddisfare una determinata richiesta di QoS ed alloca le risorse di un sistema DRE prima o durante lo start-up time. Inoltre è spesso la soluzione più semplice da realizzare. Per consentire una QoS provisioning end-to-end robusta, utilizzando un componente del sistema middleware, la specifica statica della QoS deve essere disaccoppiata dalla implementazione del componente stesso. Tale separazione aiuta a migliorare la riusabilità dei componenti e a disaccoppiare le specifiche di QoS dal loro comportamento per garantirle. 15

22 Capitolo 1 Middleware adattativi La QoS provisioning dinamica permette l allocazione e la gestione delle risorse a run-time per soddisfare varie richieste di QoS da parte delle applicazioni. Determinati eventi, come le fluttuazioni sulla disponibilità delle risorse, dovute ad un sovraccarico temporaneo, producono cambiamenti nelle richieste di QoS o riducono la disponibilità delle risorse, dovute a failures o attacchi esterni; tutto ciò richiede di rivalutare e riallocare le risorse disponibili in modo da garantire il livello di QoS richiesto. A tal fine una politica di QoS provioning dinamica deve consentire di: valutare i cambiamenti sulla disponibilità delle risorse. Quindi un middleware deve essere in grado di monitorare lo stato di un sistema DRE, in modo da determinare la riallocazione delle risorse. Ad esempio, la bandwidth di rete è spesso condivisa da varie applicazioni, dunque un middleware per applicazioni bandwidth-sensitive, come video conferenza o image processing, deve essere in grado di determinare i cambiamenti sulla bandwidth disponibile per una specifica applicazione adattarsi ai cambiamenti del contesto esecutivo per consentire l uso delle risorse disponibili alle applicazioni che ne hanno fatto richiesta. Ad esempio, un middleware che fornisce supporto per video conferenza può scegliere di ridurre temporaneamente la risoluzione video, quando c è un abbassamento della bandwidth di rete; ripristinare la risoluzione video originale, quando la bandwidth disponibile ritorna disponibile. 16

23 Capitolo 1 Middleware adattativi Molte applicazioni implementano QoS provisioning dinamica utilizzando middleware convenzionali, operando sulla struttura del middleware stesso per semplificare lo sviluppo di un sistema DRE. Tuttavia approcci ad hoc portano alla generazione di codice non portabile, che dipende da particolari caratteristiche del SO, alla implementazione fortemente connessa all applicazione software ed altri problemi che rendono difficile adattare l applicazione ai cambiamenti richiesti e alla riusabilità di una implementazione. Nasce dunque l esigenza di separare le funzionalità di QoS provisioning dinamica della struttura di basso livello della piattaforma middleware, dalle funzionalità dell applicazione. La QoS provisioning, dunque, attraversa vari strati di un applicazione ed effettua varie richieste end-to-end, che rendono le applicazioni DRE più difficili da sviluppare, gestire ed adattare Tecniche di implementazione In aggiunta ai paradigmi e linguaggi di programmazione tradizionali, un certo numero di tecniche sono state sviluppate per rendere i sistemi più flessibili. Tali tecniche sono utilizzate nei sistemi adattativi in modo da consentire loro di cambiare il proprio comportamento e le proprie funzionalità. Di seguito si fornisce una descrizione di alcune di queste tecniche, come metalevel programming, component framework e generative programming. 17

24 Capitolo 1 Middleware adattativi Meta-Level Programming Nel 1991 il lavoro condotto di Gregor Kiczale sulla combinazione del concetto di reflection computazionale e di tecniche di programmazione object-oriented, ha portato alla definizione di un protocollo meta-level. Uno dei concetti chiave di questo lavoro di ricerca è la separazione di un sistema in due livelli: il base-level, che fornisce funzionalità al sistema; il meta-level, che contiene le politiche e le strategie riguardo al comportamento del sistema. L analisi e l alterazione di questo meta-level consente di apportare cambiamenti nel comportamento del sistema. Il base-level si occupa dell implementazione del sistema e offre una metainterface a cui il meta-level può accedere. Tale meta-interface fornisce il funzionamento interno dei componenti/oggetti del base-level, consentendo la loro analisi e, alterazione e riconfigurazione del loro comportamento. In tal modo il base-level può essere riconfigurato per ottimizzare le caratteristiche e il comportamento del sistema in modo da migliorare le prestazione in differenti contesti esecutivi. Spesso ci si riferisce a tale tecnica con il termine Meta-Object Protocol (MOP). La progettazione di una meta-interface/mop è uno studio fondamentale per la reflection, tali interfacce dovrebbero essere sufficientemente generali per consentire cambiamenti imprevisti della piattaforma, ma devono 18

25 Capitolo 1 Middleware adattativi essere abbastanza specializzate per preservare l integrità del sistema da possibili modifiche distruttive. Component Framework La crescente complessità dei sistemi di computing e gli stretti vincoli sul budget di sviluppo, hanno reso la programmazione di applicazioni meno flessibile. Lo sviluppo di applicazione utilizzando una collezione di components riusabili e l utilizzo di framework sono emerse come un ottimo approccio per lo sviluppo del software. Un component software può essere visto come un blocco logico funzionale. I components possono essere intere applicazioni o funzionalità incapsulate, che possono essere usate come parte di una applicazione più grande, consentendo la realizzazione di applicazioni utilizzando i components come mattoni di costruzione. L utilizzo dei components fornisce un certo numero di benefici, come la semplificazione dello sviluppo e della manutenzione delle applicazioni, consentendo al sistema di essere maggiormente adattabile e reattivo ai cambiamenti richiesti. Negli ultimi anni c è stato un crescente interesse nell uso dei components come meccanismo di sviluppo di piattaforme middleware; tale approccio ha consentito alle piattaforme middleware di essere più flessibili alle richieste di adattabilità. 19

26 Capitolo 1 Middleware adattativi I component frameworks sono una collezione di interfacce e protocolli di interazione che definiscono come i components interagiscono tra loro e con il framework stesso; essenzialmente il framework permette ai components di essere composti tra loro. Se i components sono l analogo dei mattoni di costruzione, i frameworks possono essere visti come il cemento per tenerli insieme. Esempi di component framworks sono Enterprise Java Beans (EJB) sviluppato da Sun Microsystems, Microsoft.NET e CORBA Component Model (CCM). I component frameworks sono utilizzati anche come un mezzo per i components di accedere ai servizi offerti dal middleware, ad esempio il modello component EJB semplifica lo sviluppo di applicazioni middleware fornendo supporto automatico a servizi come transaction, clustering, sicurezza e così via. Il paradigma di sviluppo component-oriented è visto come una pietra miliare nelle tecniche di programmazione software. Il processo di sviluppo di applicazioni, componendo blocchi di programma precostruiti, può drasticamente ridurre il costo dello programmazione software. Inoltre l uso di components software riusabili può aumentare la reliability, semplificando l implementazione e riducendo la manutenzione di applicazioni complesse. Generative Programming Generative programming è un meccanismo di programmazione che consente ad un programma di creare altri programmi. L obiettivo base di un generative 20

27 Capitolo 1 Middleware adattativi program, anche conosciuto come generator program, è automatizzare quel processo di programmazione noioso, ripetitivo e passibile di errori. Fornendo una definizione delle specifiche, un applicazione personalizzata e ottimizzata può essere prodotta automaticamente. Un generator program, attraverso specifiche espresse in un particolare linguaggio di alto livello, il Domain Specific Language (DSL), produce codice sorgente in uno determinato linguaggio di programmazione utilizzato per l implementazione del sistema. Ad esempio, fornendo le specifiche sul formato di un file di testo, un generator program può essere utilizzato per creare un programma in grado di editare i files in quel formato. Un program generator può usare Java, C, Visual Basic o qualsiasi altro linguaggio come linguaggio di implementazione del sistema. Generative programming permette un alto grado di riuso del codice in quei sistemi che condividono concetti e task comuni, fornendo un effettiva soluzione al supporto di multiple varianti del programma; l insieme di queste varianti sono conosciute come program family. Le tecniche di program generation possono essere utilizzate per creare sistemi capaci di adattare il loro comportamento attraverso la ricompilazione del programma. 21

28 Capitolo 1 Middleware adattativi Esempi di middleware adattativi C è un crescente interesse nello sviluppo di middleware adattativi e reflective, con un largo numero di gruppi di ricerca che si occupano di ricercare in tale direzione. Un certo numero di sistemi middleware sono stati sviluppati o sono in via di sviluppo che utilizzano tecniche adattative e reflective. Di seguito si fornisce una breve descrizione di alcuni sistemi emergenti: QuO (Quality Objects) Framework per fornire qualità del servizio in applicazioni distribuite sviluppato dalla BBN Technologies. Il progetto QuO pone particolare enfasi sulla definizione, misura e controllo della QoS ed adattamento delle applicazioni ai cambiamenti nei suoi livelli. Open ORB 2 Open ORB 2 è un ORB adattativo e dinamicamente riconfigurabile che fornisce supporto alle applicazioni con richieste dinamiche. CIAO (Component Integradet Ace ORB) Implementazione del CORBA Component Model (CCM) sviluppata dallo stesso gruppo DOC al di sopra di TAO. Si propone di fornire un astrazione per la gestione dalla QoS in termini di metadati, in modo da separarla della logica applicativa, in modo tale da rendere più flessibile lo sviluppo di applicazioni con requisiti di QoS. DynamicTAO E stato progettato per introdurre riconfigurabilità dinamica nell ORB TAO aggiungendo capacita adattative e reflectives. 22

29 Capitolo 1 Middleware adattativi QuO QuO estende il middleware tradizionale per aiutare gli sviluppatori a creare e riutilizzare codice adattativo, tenendo separato il codice per l adattatività da quello per l implementazione della logica funzionale di un applicazione. Come descritto in [BBN 02], il framework QuO consente agli sviluppatori di applicazioni DRE di specificare (1) i requisiti di QoS, (2) gli elementi del sistemi che devono essere monitorati e controllati per misurare e fornire QoS e (3) adattare il comportamento del sistema alle variazioni sulla QoS a runtime. L architettura QuO supporta la QoS provisioning dinamica utilizzando i seguenti elementi: Contracts specificano il livello di servizio desiderato dal client, il livello di servizio che un componente prevede di fornire, le regioni di funzionamento di una applicazione che indicano la QoS possibile e le azioni da intraprendere nel caso in cui il livello di QoS cambia. Delegates agiscono come proxies locali di un componente remoto. Ogni delegate fornisce una interfaccia simile a quella del componente remoto, ma aggiunge localmente un comportamento adattativo in relazione allo stato corrente di QoS del sistema, in base alla misura offerta dal contract. SysCond forniscono interfacce alle risorse e ai meccanismi dei sistemi che sono valutati e controllati dai contracts. 23

30 Capitolo 1 Middleware adattativi Figura 1.2 I contracts e delegetes di QuO consentono due modelli distinti per fornire adattatività al livello middleware e a quello applicativo: In-band adaptation fornisce adattatività e controllo della QoS nell accesso dell oggetto remoto, utilizzando l Interceptor Pattern. Il delegate QuO effettua la in-band adaptation ogni qual volta il client effettua una chiamata ad un servizio remoto e ogni volta che si ritorna dall invocazione di un operazione. I delegates client e server verificano lo stato dei relativi contracts e scelgono il comportamento da adottare in base 24

31 Capitolo 1 Middleware adattativi allo stato del sistema. Tali comportamenti includono modellazione o filtering dei dati, scelta di metodi alternativi o di oggetti serventi, e così via. Out-of-band adaptation utilizzato sullo stato di una applicazione, di un sistema o di un sottosistema e non contestualmente all invocazione di un operazione. QuO supporta la out-of-band adaptation monitorando gli oggetti SysCond associati al sistema: ogni qualvolta le condizioni monitorate subiscono un cambiamento o oltrepassano una determinata soglia, un oggetto SysCond innesca una valutazione dei relativi contracts; se il risultato di tale valutazione è nella regione di modifica di un contract, cioè è individuato come un cambiamento, si innesca un comportamento adattativo asincrono per ogni oggetto associato a quei contracts. Uno degli obiettivi di QuO è di separare la fase di programmazione sistematica di QoS, da quella della programmazione di applicazioni. Una conseguenza di tale separazione è che i comportamenti sistematici di QoS possono essere incapsulati in unità riusabili, che non solo possono essere sviluppati separatamente dall applicazione, ma possono essere riusati per selezionare, personalizzare e legarsi a nuove applicazioni. A tal fine QuO fornisce Qosket come un unità di incapsulazione e riuso di sistemi comportamentali nelle applicazioni. 25

32 Capitolo 1 Middleware adattativi Qosket è una collezione di interfacce, contracts, oggetti SysCond, callback, comportamenti adattativi non specializzati e codice implementativo. Tutti questi elementi sono riportati in Figura 1.3. Adapter Interface Qosket Delegate Interface Contracts Callback Objects System Condition Objects Delegate Templates Qosket Implementation Helper Methods Figura 1.3 Inoltre un Qosket offre due interfecce: The adapter interface, interfaccia per le applicazioni. Tale interfaccia consente l accesso alle misure di QoS, alle funzionalità di controllo e adattatività nei Qosket (come gli oggetti SysCond, contract e così via), in modo da poter essere usati dovunque nelle applicazioni 26

33 Capitolo 1 Middleware adattativi The delegate interface, interfaccia per la in-band adaptation. I comportamenti adattativi della in-band adaptation sono specificati utilizzando il linguaggio ASL. In tal modo le strategie adattative del delegate sono incapsulate ed inserite nelle applicazioni usando tecniche di code generation. Open ORB 2 Open ORB 2 è un ORB adattativo e dinamicamente riconfigurabile che fornisce supporto alle applicazioni che hanno richieste dinamiche. Open ORB è stato progettato per essere conforme ai principi della reflection; esso offre un framework che consente ai components di essere manipolati; tali components controllano vari aspetti del comportamento dell ORB, inclusi la gestione di buffer, thread e protocolli. Open ORB è stato implementato come una collezione di components configurabili che possono essere selezionati a build-time e riconfigurati a run-time; questo processo di selezione e configurazione dei components permette all ORB di essere adattativo. Open ORB è stato sviluppato effettuando una chiara separazione tra il base-level e il meta-level. 27

34 Capitolo 1 Middleware adattativi Figura 1.4 Ogni component del base-level può avere un suo insieme privato di components del meta-level, tale insieme definisce il meta-space. Open ORB suddivide il metaspace in distinti models che sono architecture, interface, resource e interceptor, ognuno dei quali si preoccupa di implementare una particolare funzionalità del sistema. Il vantaggio di questo approccio risiede nel facilitare l interfacciamento tra il base-level con il meta-space, scomponendo il problema in varie funzionalità e permettendo ad ogni model del meta-space di implementare una specifica funzionalità. 28

35 Capitolo 1 Middleware adattativi Open ORB 2 utilizza due model per implementare funzionalità strutturali, uno per la definizione della interfaccia estera (interface model) ed un altro per implementazione della sua architettura interna (architecture model). L interface model consente di descrivere l interfaccia di un component.. L architecture model sviluppa l implementazione di un component. Questo approccio consente a tutti gli utenti di accedere all interface model, restringendo l accesso all architecture model, in modo che solo chi è autorizzato può cambiare l architettura del sistema. Esistono altri due modelli che consentono lo sviluppo di funzionalità comportamentali: interceptor e resource model. L interceptor model consente di inserire dinamicamente degli interceptos su una specifica interfaccia, consentendo di aggiungere dei pre- comportamenti e dei post-comportamenti. Questa tecnica può essere utilizzata per introdurre comportamenti non funzionali in un ORB. Il resource model consente di accedere alle risorse del sistema, come memoria e threads. CIAO CIAO è un implementazione del Corba Component Model, standardizzato nel 2002 dall OMG. Tale standard non ha alcun supporto per la Quality of Service (QoS), è questo come evidenziato in [WANG 01] comporta seri limiti per lo sviluppo di sistemi distribuiti con requisiti di QoS. CIAO si pone l obiettivo di 29

36 Capitolo 1 Middleware adattativi estendere il CCM per includere un supporto per il QoS provisioning end-to-end tra i componenti. Figura

37 Capitolo 1 Middleware adattativi Senza entrare nei dettagli del CCM, per i quali si rimanda a [OMG 02], CIAO implementa quasi tutte le funzionalità richieste dalla specifica. I componenti sono arrichiti con delle QoS policies che consentono agli sviluppatori di specificare le configurazioni real-time come descrittori XML senza influenzare l implementazione del componente. CIAO è stato sviluppato su TAO e da esso eredita le caratteristiche del middleware QoS-enabled ed è dotato di funzionalità per fornire ai componenti QoS provisioning statica. TAO è un Real-Time CORBA ORB open-source, altamente performante e configurabile che implementa meccanismi chiave per venire incontro alle richieste di QoS dei sistemi. TAO supporta lo standard reference model OMG CORBA e le specifiche Real-Time CORBA, migliorando l efficienza, la predicibilità e la scalabilità dei comportamenti di QoS. La piattaforma TAO è stata sviluppata al di sopra di ACE (Adaptive Communication Environment), un framework orientato agli oggetti, che implementa diversi patterns per la comunicazione in software concorrente, come descritto in [SCHM 00b]. Lo standard CCM viene esteso da CIAO in modo tale da fornire QoS nel seguente modo: Assembly descriptor delle applicazioni Un CCM assembly descriptor specifica come i componenti sono composti per formare una applicazione. CIAO estende la specifica includendo specifiche per il QoS provisioning. 31

38 Capitolo 1 Middleware adattativi Inoltre viene esteso il formato del assembly descriptor per consentire la specifica dei requisiti di QoS a livello di connessioni tra componenti. Aggregati di configurazione per i client un ORB di un applicazione client può essere configurato per supportare varie policies come priorità level policy e custom priority mapping. Tali aggregati vengono quindi associati ai client e sono utilizzati per interagire con i server e fornire QoS end-to-end. CIAO consente di installare in maniera trasparente questi aggregati nell ORB client. QoS-enabled containers CIAO migliora i containers così come definiti in CCM per supportare funzionalità di gestione della QoS, come politiche RT-CORBA. Specificamente le politiche a livello di componente in CIAO sono le stesse a livello di POA in TAO ovvero: Priority Model, Threadpool, Banded Connection. Invece risorse come Threadpools (con o senza lanes), connection bands, sono comuni all intero component server, all interno del quale sono istanziati i component containers. QoS Adaptation CIAO supporta l installazione di hooks che possono essere utilizzati per iniettare QoS dinamica in maniera trasparente. In altri termini l adattatività non è fornita da CIAO, ma è possibile far interagire i componenti con altri oggetti che forniscono QoS dinamica agli stessi. Gli sviluppatori, utilizzando i modelli di priorità ed i livelli di priorità delle istanze dei componenti possono allocare staticamente risorse di CPU; utilizzando private 32

39 Capitolo 1 Middleware adattativi e banded connections possono riservare risorse di comunicazione per le interconnessioni tra i componenti. Inoltre è possibile installare, attraverso opportune policies di Distributed Middleware Configuration moduli addizionali come protocolli di comunicazione personalizzati o moduli software come quelli per supportare QoS dinamica, uno dei quali verrà mostrato nel successivo paragrafo. DynamicTAO DynamicTAO consente la riconfigurazione on-the-fly e la personalizzazione del motore interno dell ORB TAO continuando a tenerlo in uno stato consistente. 33

40 Capitolo 1 Middleware adattativi Figura 1.6 DynamicTAO consente l analisi e la riconfigurazione del suo motore interno e permette allo sviluppatore dell applicazione di specificare le politiche di riconfigurazione all interno di sotto-classi personalizzabili della classe ComponentConfigurator. Tale classe offre un interfaccia per (1) trasferire i components attraverso il sistema distribuito, (2) effettuare il load e unload a runtime dei moduli nell ORB e (3) analizzare e configurare lo stato dell ORB. 34

41 Capitolo 1 Middleware adattativi L adattabilità della struttura interna di DynamicTAO è realizzata mediante l uso di un insieme di component configurators. Ogni processo eseguito dal DynamicORB contiene una istanza del component configurator chiamata DomainConfigurator, che è responsabile di gestire i riferimenti all ORB e ai servants eseguiti in quel processo. Inoltre ogni istanza dell ORB contiene al suo interno un component configurator personalizzabile, chiamato TAOConfigurator. Figura

42 Capitolo 1 Middleware adattativi TAOConfigurator possiede degli hooks ai quali DynamicORB può associare implementazioni di varie strategie. Gli hooks lavorono come dei mounting point, ai quali una specifica strategia può essere associata e resa disponibile all ORB. Sono supportati hooks per differenti tipi di strategie, come Concurrency, Security e Monitoring. L associazione tra gli hooks e le implementazioni dei components può essere modificata in qualsiasi momento. L architettura del framework di DynamicTAO è mostrata in Figura 1.7. Il Persistent Repository memorizza le implementazioni delle categorie nel file system locale, offrendo metodi per la manipolazione (browsing, creazione, cancellazione) delle categorie e delle implementazioni di ogni categoria. Ogni volta che l implementazione di un component è memorizzata nel repository locale, esso può essere caricato dinamicamente nel processo a run-time. Il Network Broker riceve le richieste di riconfigurazioni attraverso la rete e le inoltra al Dynamic Server Configurator, che fornisce le operazioni comuni per la dinamica configurazione dei components a run-time; inoltre delega alcune delle sue funzioni a specifici components configurator (ad esempio, TAOConfigurator o ServantConfigurator). 36

43 Capitolo 2 Aspect-Oriented Programming Capitolo 2 Aspect-Oriented Programming 2.1 Introduzione L Object Oriented Programming è ormai diventato il paradigma per eccellenza, avendo rimpiazzato quasi completamente quello procedurale. Uno dei grandi vantaggi che ha introdotto è stato quello di permettere di vedere l intero sistema come collezione di classi, ognuna con un ben definito scopo ed una chiara responsabilità, la cui collaborazione permette di raggiungere l obiettivo globale dell applicazione. Strumenti come l incapsulazione, l ereditarietà e il polimorfismo hanno contribuito ad una migliore suddivisione basata sulle funzionalità. Nonostante ciò ci sono parti del sistema che non posso essere viste come di responsabilità di un singolo componente, ma toccano o tagliano l intera struttura o parte di essa. Ci sono cioè alcune funzionalità difficili se non impossibili da esprimere in modo ben localizzato usando i costrutti di modularità tradizionali come le classi, i componenti, o le procedure. Gestione della memoria, meccanismi di sicurezza, condivisione di risorse, logging, gestione degli errori e delle eccezioni sono solo alcune delle caratteristiche che risentono di questo problema. 37

44 Capitolo 2 Aspect-Oriented Programming L Aspect-Oriented Programming (AOP) rappresenta una soluzione a tale problematica. Per capire il contesto in cui è nata, bisogna rifarsi ad un principio fondamentale dell'ingegneria del software: la Separation Of Concern (SOC). La SOC si riferisce all'abilità di identificare, incapsulare e manipolare solamente quelle parti del software che sono rilevanti per un particolare concetto, obiettivo o scopo. Il sistema viene decomposto in funzioni che rappresentano concerns cioè concetti, aree di interesse, requisiti o considerazioni che devono essere realizzati per soddisfare lo scopo del sistema, questi concerns saranno poi realizzati come unità modulari di software durante la fase d implementazione. Un sistema software può essere visto come insieme di concern. Si hanno due tipi di concern: core concern e crosscutting concern. I core concern sono ben modellati dalla OOP utilizzando concetti come l ereditarietà e il polimorfismo, mentre i crosscutting concern (logging, tracing, gestione della sicurezza ed altri) sono ortogonali o indipendenti dagli altri componenti e per loro natura sono distribuiti su più componenti, dunque questi concern sono trasversali alla esecuzione del programma. Un sistema software è composto da più funzionalità, e alla creazione di nuovi use case corrisponde l'introduzione di nuovi componenti e la modifica di quelli già 38

45 Capitolo 2 Aspect-Oriented Programming esistenti. In tal caso, possono sorgere i seguenti problemi di decomposizione: tangling e scattering. Tangling (aggrovigliamento): un componente contiene sia il codice che implementa l'use case dominante che il codice di altri use case. Scattering (sparpagliamento): codice di un case che è presente in più componenti. I concern che evidenziano le proprietà di tangling e scattering sono proprio i crosscutting concerns La AOP è stato definito come paradigma di programmazione indirizzato alla modellazione dei crosscutting concern. Un aspect può essere visto come un crosscutting concern, cioè come una competenza che taglia e attraversa la struttura del core concern. Durante l analisi i concerns trasversali possono essere separati dalle funzionalità di base, invece al livello di implementazione componenti ed aspetti devono essere combinati insieme. È necessario disporre di meccanismi che coordinano e compongono insieme componenti ed aspetti al livello di implementazione, operazione che è indicata con il termine di weaving. Figura

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Progettazione ed implementazione di un tool per lo sviluppo di applicazioni in Esperanto

Progettazione ed implementazione di un tool per lo sviluppo di applicazioni in Esperanto Università degli studi di Napoli Federico II Facoltà di Ingegneria Corso di laurea in Ingegneria Informatica Capri Feb. 2004 Progettazione ed implementazione di un tool per lo sviluppo di applicazioni

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

Distributed Object Computing

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

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

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

Le fattispecie di riuso

Le fattispecie di riuso Le fattispecie di riuso Indice 1. PREMESSA...3 2. RIUSO IN CESSIONE SEMPLICE...4 3. RIUSO CON GESTIONE A CARICO DEL CEDENTE...5 4. RIUSO IN FACILITY MANAGEMENT...6 5. RIUSO IN ASP...7 1. Premessa Poiché

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

Implementazione di un servizio VoIP in ambienti SOA per mobile computing

Implementazione di un servizio VoIP in ambienti SOA per mobile computing tesi di laurea Implementazione di un servizio VoIP in ambienti SOA per mobile computing Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo correlatore ing. Marcello Cinque candidato Vittorio

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

Lezione 1. Introduzione e Modellazione Concettuale

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

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo

Dettagli

Sistemi informativi secondo prospettive combinate

Sistemi informativi secondo prospettive combinate Sistemi informativi secondo prospettive combinate direz acquisti direz produz. direz vendite processo acquisti produzione vendite INTEGRAZIONE TRA PROSPETTIVE Informazioni e attività sono condivise da

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Sistemi Informativi e Sistemi ERP

Sistemi Informativi e Sistemi ERP Sistemi Informativi e Sistemi Trasformare i dati in conoscenza per supportare le decisioni CAPODAGLIO E ASSOCIATI 1 I SISTEMI INFORMATIVI LI - E IMPRESA SISTEMA DI OPERAZIONI ECONOMICHE SVOLTE DA UN DATO

Dettagli

Strumenti per la gestione della configurazione del software

Strumenti per la gestione della configurazione del software tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Luigi Suarato candidato Pasquale Palumbo Matr. 534/000021 MANUTENZIONE DEL SOFTWARE Il Configuration

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

Dettagli

Architetture software

Architetture software Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architettura software 1 Architetture software Sommario Definizioni 2 Architettura Definizione. L architettura

Dettagli

Sistema Operativo. Fondamenti di Informatica 1. Il Sistema Operativo

Sistema Operativo. Fondamenti di Informatica 1. Il Sistema Operativo Sistema Operativo Fondamenti di Informatica 1 Il Sistema Operativo Il Sistema Operativo (S.O.) è un insieme di programmi interagenti che consente agli utenti e ai programmi applicativi di utilizzare al

Dettagli

Firewall applicativo per la protezione di portali intranet/extranet

Firewall applicativo per la protezione di portali intranet/extranet Firewall applicativo per la protezione di portali intranet/extranet Descrizione Soluzione Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO (MI)

Dettagli

Il sistema operativo TinyOS

Il sistema operativo TinyOS tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo candidato Giovanni Chierchia Matr. 534 / 804 ::. Obiettivi del lavoro di tesi Studio del sistema operativo TinyOS Studio

Dettagli

Database. Si ringrazia Marco Bertini per le slides

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

Dettagli

Il Sistema Operativo

Il Sistema Operativo Il Sistema Operativo Il Sistema Operativo Il Sistema Operativo (S.O.) è un insieme di programmi interagenti che consente agli utenti e ai programmi applicativi di utilizzare al meglio le risorse del Sistema

Dettagli

SOFTWARE PER LA RILEVAZIONE DEI TEMPI PER CENTRI DI COSTO

SOFTWARE PER LA RILEVAZIONE DEI TEMPI PER CENTRI DI COSTO SOFTWARE PER LA RILEVAZIONE DEI TEMPI PER CENTRI DI COSTO Descrizione Nell ambito della rilevazione dei costi, Solari con l ambiente Start propone Time&Cost, una applicazione che contribuisce a fornire

Dettagli

Software per Helpdesk

Software per Helpdesk Software per Helpdesk Padova - maggio 2010 Antonio Dalvit - www.antoniodalvit.com Cosa è un helpdesk? Un help desk è un servizio che fornisce informazioni e assistenza ad utenti che hanno problemi nella

Dettagli

Università Politecnica delle Marche. Progetto Didattico

Università Politecnica delle Marche. Progetto Didattico Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Sede di Ancona Anno Accademico 2011-2012 Corso di Tecnologie WEB Docente prof. Alessandro

Dettagli

La Metodologia adottata nel Corso

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

Dettagli

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

Infrastruttura di produzione INFN-GRID

Infrastruttura di produzione INFN-GRID Infrastruttura di produzione INFN-GRID Introduzione Infrastruttura condivisa Multi-VO Modello Organizzativo Conclusioni 1 Introduzione Dopo circa tre anni dall inizio dei progetti GRID, lo stato del middleware

Dettagli

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi Project Management Modulo: Introduzione prof. ing. Guido Guizzi Definizione di Project Management Processo unico consistente in un insieme di attività coordinate con scadenze iniziali e finali, intraprese

Dettagli

Dispensa di Informatica I.1

Dispensa di Informatica I.1 IL COMPUTER: CONCETTI GENERALI Il Computer (o elaboratore) è un insieme di dispositivi di diversa natura in grado di acquisire dall'esterno dati e algoritmi e produrre in uscita i risultati dell'elaborazione.

Dettagli

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Basi di dati Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Anno Accademico 2008/2009 Introduzione alle basi di dati Docente Pierangelo

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

Architetture Applicative

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

Dettagli

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

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

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

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

Per capire meglio l ambito di applicazione di un DWhouse consideriamo la piramide di Anthony, L. Direzionale. L. Manageriale. L.

Per capire meglio l ambito di applicazione di un DWhouse consideriamo la piramide di Anthony, L. Direzionale. L. Manageriale. L. DATA WAREHOUSE Un Dataware House può essere definito come una base di dati di database. In molte aziende ad esempio ci potrebbero essere molti DB, per effettuare ricerche di diverso tipo, in funzione del

Dettagli

1. BASI DI DATI: GENERALITÀ

1. BASI DI DATI: GENERALITÀ 1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente

Dettagli

Introduzione alle applicazioni di rete

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

Dettagli

Il modello di ottimizzazione SAM

Il modello di ottimizzazione SAM Il modello di ottimizzazione control, optimize, grow Il modello di ottimizzazione Il modello di ottimizzazione è allineato con il modello di ottimizzazione dell infrastruttura e fornisce un framework per

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

Dettagli

03. Il Modello Gestionale per Processi

03. Il Modello Gestionale per Processi 03. Il Modello Gestionale per Processi Gli aspetti strutturali (vale a dire l organigramma e la descrizione delle funzioni, ruoli e responsabilità) da soli non bastano per gestire la performance; l organigramma

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

Manuale Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise

Manuale Amministratore Legalmail Enterprise. Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise Manuale Amministratore Legalmail Enterprise Manuale ad uso degli Amministratori del Servizio Legalmail Enterprise Pagina 2 di 16 Manuale Amministratore Legalmail Enterprise Introduzione a Legalmail Enterprise...3

Dettagli

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

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

Dettagli

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8 Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare

Dettagli

Vulnerability Assessment relativo al sistema Telecom Italia di autenticazione e autorizzazione basato sul protocollo Radius

Vulnerability Assessment relativo al sistema Telecom Italia di autenticazione e autorizzazione basato sul protocollo Radius Vulnerability Assessment relativo al sistema Telecom Italia di autenticazione e autorizzazione basato sul protocollo Radius L obiettivo del presente progetto consiste nel sostituire il sistema di autenticazione

Dettagli

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi Il Software Il software impiegato su un computer si distingue in: Software di sistema Sistema Operativo Compilatori per produrre programmi Software applicativo Elaborazione testi Fogli elettronici Basi

Dettagli

Sistemi Operativi. Conclusioni e nuove frontiere

Sistemi Operativi. Conclusioni e nuove frontiere Sistemi Operativi (modulo di Informatica II) Conclusioni e nuove frontiere Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Definizione di sistema operativo Evoluzione futura

Dettagli

Il servizio di registrazione contabile. che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili

Il servizio di registrazione contabile. che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili Il servizio di registrazione contabile che consente di azzerare i tempi di registrazione delle fatture e dei relativi movimenti contabili Chi siamo Imprese giovani e dinamiche ITCluster nasce a Torino

Dettagli

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

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

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

Siti web centrati sui dati (Data-centric web applications)

Siti web centrati sui dati (Data-centric web applications) Siti web centrati sui dati (Data-centric web applications) 1 A L B E R T O B E L U S S I A N N O A C C A D E M I C O 2 0 1 2 / 2 0 1 3 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

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

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

GESTIONE DEI PROCESSI

GESTIONE DEI PROCESSI Sistemi Operativi GESTIONE DEI PROCESSI Processi Concetto di Processo Scheduling di Processi Operazioni su Processi Processi Cooperanti Concetto di Thread Modelli Multithread I thread in Java Concetto

Dettagli

Progettare un Firewall

Progettare un Firewall Progettare un Firewall Danilo Demarchi danilo@cuneo.linux.it GLUG Cuneo Corso Sicurezza 2006 Concetti introduttivi Come pensare un Firewall Argomenti trattati I Gli strumenti del Firewall Gli strumenti

Dettagli

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 StruxureWare Data Center ExpertDispositivo virtuale Il server StruxureWare Data Center Expert 7.2 è disponibile come dispositivo virtuale, supportato

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

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015 Prodotto Release Gennaio 2015 Il presente documento e' stato redatto in coerenza con il Codice Etico e i Principi Generali del Controllo Interno Sommario Sommario... 2 Introduzione...

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

Scheduling della CPU. Sistemi multiprocessori e real time Metodi di valutazione Esempi: Solaris 2 Windows 2000 Linux

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

Dettagli

Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it

Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it Cenni di programmazione distribuita in C++ Mauro Piccolo piccolo@di.unito.it Socket Nei sistemi operativi moderni i servizi disponibili in rete si basano principalmente sul modello client/server. Tale

Dettagli

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

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

Dettagli

COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING

COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING Febbraio Inserto di Missione Impresa dedicato allo sviluppo pratico di progetti finalizzati ad aumentare la competitività delle imprese. COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING COS E UN

Dettagli

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell

Dettagli

Base di dati e sistemi informativi

Base di dati e sistemi informativi Base di dati e sistemi informativi Una base di dati è un insieme organizzato di dati opportunamente strutturato per lo svolgimento di determinate attività La base di dati è un elemento fondamentale per

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

OmniAccessSuite. Plug-Ins. Ver. 1.3

OmniAccessSuite. Plug-Ins. Ver. 1.3 OmniAccessSuite Plug-Ins Ver. 1.3 Descrizione Prodotto e Plug-Ins OmniAccessSuite OmniAccessSuite rappresenta la soluzione innovativa e modulare per il controllo degli accessi. Il prodotto, sviluppato

Dettagli

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

Progettazione di Basi di Dati

Progettazione di Basi di Dati Progettazione di Basi di Dati Prof. Nicoletta D Alpaos & Prof. Andrea Borghesan Entità-Relazione Progettazione Logica 2 E il modo attraverso il quale i dati sono rappresentati : fa riferimento al modello

Dettagli

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software di sistema e software applicativo I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software soft ware soffice componente è la parte logica

Dettagli

2 Gli elementi del sistema di Gestione dei Flussi di Utenza

2 Gli elementi del sistema di Gestione dei Flussi di Utenza SISTEMA INFORMATIVO page 4 2 Gli elementi del sistema di Gestione dei Flussi di Utenza Il sistema è composto da vari elementi, software e hardware, quali la Gestione delle Code di attesa, la Gestione di

Dettagli

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale La soluzione modulare di gestione del Sistema Qualità Aziendale I MODULI Q.A.T. - Gestione clienti / fornitori - Gestione strumenti di misura - Gestione verifiche ispettive - Gestione documentazione del

Dettagli

Introduzione alla Progettazione per Componenti

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

Dettagli

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell

Dettagli

PROTOS GESTIONE DELLA CORRISPONDENZA AZIENDALE IN AMBIENTE INTRANET. Open System s.r.l.

PROTOS GESTIONE DELLA CORRISPONDENZA AZIENDALE IN AMBIENTE INTRANET. Open System s.r.l. Open System s.r.l. P.IVA: 00905040895 C.C.I.A.A.: SR-7255 Sede Legale: 96016 Lentini Via Licata, 16 Sede Operativa: 96013 Carlentini Via Duca degli Abruzzi,51 Tel. 095-7846252 Fax. 095-7846521 e-mail:

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

Inizializzazione degli Host. BOOTP e DHCP

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

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Database e reti. Piero Gallo Pasquale Sirsi

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

Dettagli

Si applica a: Windows Server 2008

Si applica a: Windows Server 2008 Questo argomento non è stato ancora valutato Si applica a: Windows Server 2008 Protezione accesso alla rete è una tecnologia per la creazione, l'imposizione, il monitoraggio e l'aggiornamento dei criteri

Dettagli

Reti di Telecomunicazione Lezione 6

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

Dettagli

Applicazioni web centrati sui dati (Data-centric web applications)

Applicazioni web centrati sui dati (Data-centric web applications) Applicazioni web centrati sui dati (Data-centric web applications) 1 ALBERTO BELUSSI ANNO ACCADEMICO 2009/2010 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente lo strumento di riferimento

Dettagli

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE Relatore: prof. Michele Moro Laureando: Marco Beggio Corso di laurea in Ingegneria Informatica Anno Accademico 2006-2007

Dettagli

Laboratorio di Informatica I

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

Dettagli

Corso Analista Programmatore Web PHP Corso Online Analista Programmatore Web PHP

Corso Analista Programmatore Web PHP Corso Online Analista Programmatore Web PHP Corso Analista Programmatore Web PHP Corso Online Analista Programmatore Web PHP Accademia Futuro info@accademiafuturo.it Programma Generale del Corso Analista Programmatore Web PHP Tematiche Trattate

Dettagli

Presentazione di Cedac Software

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

Dettagli

9. Architetture di Dominio

9. Architetture di Dominio 9. Architetture di Dominio imparare dall esperienza comune Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 9. Architetture di Dominio 1 / 20 Sommario 1 Architetture

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

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

Dettagli

Gestione della memoria centrale

Gestione della memoria centrale Gestione della memoria centrale Un programma per essere eseguito deve risiedere in memoria principale e lo stesso vale per i dati su cui esso opera In un sistema multitasking molti processi vengono eseguiti

Dettagli

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

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

Dettagli