Architetture Applicative

Transcript

1 Alessandro Martinelli 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture con Hardware Dedicato Architetture Multiprocessore Architetture Distribuite in Rete Architetture Multi-Linguaggio Ottimizzazione di Codice ed Ottimizzazione di Processo Fondamenti di Informatica II

2 Una Architettura Software e... Una Architettura Software ad Oggetti è costituita da una serie di Moduli connessi mediante Interfacce di Programmazione, che determinano il modo in cui gli oggetti possono interagire fra di loro. A. Martinelli () Architetture Applicative 6/3/ / 16

3 ... una Architettura Applicativa Una Architettura Applicativa è costituita da una serie di Moduli connessi mediante Interfacce di Comunicazione, che determinano il modo in cui questi moduli possono comunicare ed interagire fra di loro. A. Martinelli () Architetture Applicative 6/3/ / 16

4 Gli Standard di Comunicazione I moduli di una Architettura Applicativa possono essere: Moduli Software appositamente programmati. Moduli Software generici, riutilizzabili. Moduli Hardware e risorse di Sistema. La comunicazione tra moduli eterogenei e/o generici può avvenire attraverso API Standard. Le Interfacce Standard sono Come le Astrazioni nei Linguaggi ad Oggetti L esistenza di un Modulo che Implementa una Interfaccia Standard è concettualmente equivalente all esistenza di un modulo che implementa una interfaccia di programmazione: Le interfacce standard consentono ad un modulo di adattarsi in modo flessibile a sistemi differenti sulla base di un unico meccanismo di comunicazione. Non consentono tuttavia di fare affidamento rigoroso a caratteristiche tecniche o al funzionamento dei moduli sottostanti. A. Martinelli () Architetture Applicative 6/3/ / 16

5 Classificazione dei Moduli Per fornire una classificazione dei moduli, recuperiamo una classificazione tipica dell analisi dei sistemi: Modulo a Scatola Bianca Un modulo di cui si conosce non solo l interfaccia, ma l intero comportamento. Moduli composti da codice scritto da noi Moduli realizzati con Software Open Source Modulo a Scatola Nera Un modulo di cui si conosce solo l interfaccia. Si conoscono cioè i risultati delle chiamate a quel modulo, ma non si conosce l algoritmo che le implementa. Applicazioni scritte da altri di cui non si conosce il codice Modulo a Scatola Grigia Un modulo di cui si possiede un modello di comportamento, anche se non si conoscono certi dettagli implementativi. Moduli che rispondono ad uno standard di comunicazione noto e documentato. A. Martinelli () Architetture Applicative 6/3/ / 16

6 L Importanza dei Sistemi Operativi I Sistemi Operativi rappresentano un importante elemento nella definizione delle Architetture Applicative: Forniscono l accesso all hardware di un sistema attraverso un insieme più o meno completo di Interfacce di Comunicazione Standard Si adattano a differenti tecnologie hardware, in un modo che è totalmente trasparente all Applicazione. Il sistema operativo definisce tipicamente interfacce e strumenti per: L accesso alla memoria di sistema. L accesso alla memoria su Disco. Tipicamente si fa uso del modello del File System. L accesso a dispositivi periferici: stampanti, tastiera, mouse, monitor, audio. L accesso ai dispositivi di comunicazioni in rete. A. Martinelli () Architetture Applicative 6/3/ / 16

7 I parametri critici di una Architettura Applicativa Portabilità Prestazioni Scalabilità A. Martinelli () Architetture Applicative 6/3/ / 16

8 Il problema della portabilità Portabilità Facilità con cui una Architettura Applicativa può essere riprodotta su un sistema differente. Sistema Differente? Stesso sistema operativo, ma differente hardware: Dispositivi hardware con caratteristiche differenti. Certi dispositivi potrebbero essere assenti. Differente sistema operativo Esistono molti fattori in grado di compromettere la portabilità di una architettura applicativa. Tuttavia, un certo livello di non-portabilità potrebbe essere ammesso, a seconda delle circostanze. A. Martinelli () Architetture Applicative 6/3/ / 16

9 La portabilità è tipicamente compromessa da...(1/2) Interfacce di Comunicazione non comuni a tutti i sistemi Operativi Fondamentalmente, vincolano un certo programma ad essere portabile solo su uno o su alcuni sistemi operativi. Interfacce di Comunicazione che dipendono da hardware che potrebbe non essere disponibile Moduli hardware che potrebbero essere assenti costringono: Ad implementare comportamenti differenti in relazione all hardware disponibile A ridurre il numero dei possibili utenti A. Martinelli () Architetture Applicative 6/3/ / 16

10 La portabilità è tipicamente compromessa da... (2/2) Interfacce di Comunicazione di cui esistono differenti versioni, con funzionalità che possono essere messe a disposizione o meno in funzione dell hardware sottostante Le differenti versioni di una API costringono gli sviluppatori ad: Implementare comportamenti diversi a seconda della versione Allinearsi ad una versione meno recente, ammesso che quelle più recenti siano retro-compatibili. Limiti dovuti al linguaggio di programmazione usato Quando non esiste un compilatore o un interprete di un certo linguaggio su un certo sistema operativo Quando un linguaggio implica l uso di librerie con forti dipendenze sulle caratteristiche del sistema operativo. I linguaggi interpretati (java) sono sempre più facili da portare di quelli non interpretati (C) perchè non devono essere ricompilati, e perchè solitamente usano le stesse librerie independentemente dal sistema. A. Martinelli () Architetture Applicative 6/3/ / 16

11 Il problema delle prestazioni Prestazioni Misura di quanto un modulo è veloce a fare il suo lavoro Le Prestazioni di una Architettura Applicativa sono funzione delle Prestazioni di ogni Singolo Modulo. Nell Architettura, è semplice conoscere o anche misurare le prestazioni dei modelli a Scatola Bianca. Se di un modulo non si conosce/possiede l implementazione, ma è unico e noto, si possono comunque fare misure prestazionali. Per moduli a Scatola Grigia forniti da un sistema operativo, la cui implementazione cambia da sistema a sistema, è molto più difficile. In tutti i casi, ma soprattutto nel terzo, è necessario definire un modello prestazionale del sistema. Si deve tenere conto, all interno dell Architettura, di: Processi Paralleli: processi che possono essere eseguiti nello stesso tempo da moduli differenti. Processi in Serie: processi che, per loro natura, devono essere eseguiti necessariamente uno dopo l altro. A. Martinelli () Architetture Applicative 6/3/ / 16

12 Il problema delle prestazioni : l Ottimizzazione Le prestazioni di un Sistema di migliorano con un processo detto di Ottimizzazione. Ottimizzazione L Ottimizzazione è una processo di redefinizione e rivalutazione di una Architettura in cui: Si va alla ricerca del modulo o del componente che incide in modo più negativo sulle Prestazioni del sistema. Questo può dipendere da: Quanto lento è un modulo Quanto spesso quel modulo è utilizzato Si agisce per sostituire o migliorare le prestazioni di quel modulo. A. Martinelli () Architetture Applicative 6/3/ / 16

13 Il problema delle prestazioni : l Ottimizzazione L Ottimizzazione può essere svolta a vari livelli: A livello di singole porzioni di codice sorgente (Esempio : riscrivo un metodo di 10 righe di codice che sono invocate spesso perchè siano più veloci) A livello di singoli moduli di programmazione (Esempio : reimplemento una classe che viene utilizzata spesso perchè utilizzi meno memoria) A livello dei moduli di una Architettura Applicativa (Esempio : sostituisco un modulo con un altro che utilizza uno standard diverso perchè più efficiente) A livello dell intera Architettura Applicativa e dei processi di comunicazione (Esempio: cerco di aumentare le prestazioni diminuendo il numero di chiamate che i moduli si fanno gli uni agli altri). Ma questo implica un design diverso dell intero sistema. Idealmente: Con l Ottimizzazione si cerca di raggiungere il miglior risultato col minimo sforzo. A. Martinelli () Architetture Applicative 6/3/ / 16

14 Il problema delle scalabilità Scalabilità Una Architettura Applicativa è Scalabile quando continua ad essere utilizzabile anche a fronte di un aumento dei parametri o degli utilizzi coinvolti. Scalabile vuol dire che si può moltiplicare i parametri del sistema in modo lineare per un fattore di scalatura. Ogni sistema ha delle dimensioni critiche, oltre le quali è difficile andare. Esempio: Un programma di elaborazione dati opera su un PC. All aumentare dei dati: Aumento la memoria a disposizione Quanta memoria possono mettere su un PC? Compro un processore più veloce. Quanto può essere veloce un processore? A. Martinelli () Architetture Applicative 6/3/ / 16

15 Il Problema delle Licenze (Copyright) (cenni) Un ulteriore aspetto critico delle Architetture Software è la questione delle licenze.... la diffusione in rete del software ha anche contribuito ad alimentare il dibattito sul problema dei Diritti Legali correlati al software I Diritti sul Software Il software viene legalmente considerato come Bene Intellettuale. L Autore è proprietario di qualsiasi diritto ed è suo diritto decidere chi è come L insieme di regole fornite dall Autore è detto licenza (copyright). In Teoria ognuno potrebbe scriversi la propria licenza In Pratica esistono delle Licenze preconfezionate ed è consigliabile fare sempre affidamente ad una di esse. Nota Quando una Architettura Applicativa fa uso di molti moduli, è necessario capire se l Architettura è compatibile alle licenze di tutti i moduli e quali vincoli ci siano nel distribuirla o riprodurla. A. Martinelli () Architetture Applicative 6/3/ / 16

16 Il Problema del Copyright : le licenze Open (cenni) CopyLeft Nel Mondo delle Licenze stanno assumendo una rilevanza sempre più grande le Licenze Open Source, che rilasciano il Codice Sorgente affinchè sia possibile consultarlo e personalizzarlo. Il Software Open si è diffuso soprattutto grazie alla possibilità di rilasciare in rete il codice Sorgente. L idea del Software Open è quella di consentire a chiunque di personalizzare un prodotto software esistente. GNU GPL (General Public License): consente la modifica del codice sorgente, ma versioni modificate che vengano rilasciati devono obbligatoriamente usare la GNU GPL. GNU LGPL (Lesser Public Licence): consente modifica ed utilizzo libero del codice sorgente. CPL (Common Public License): consente modifica ed utilizzo libero del codice sorgente, più adatta ad adattarsi a contesti misti deve presenziano licenze non Open. EPL (Eclipse Public Licence): una CPL modificata, tra le altre cose obbliga al rilascio delle modifiche. A. Martinelli () Architetture Applicative 6/3/ / 16