Stile client-server

Lo stile client-server

 

Due stili architetturali fondamentali per i sistemi distribuiti sono lo stile client-server e lo stile peer-to-peer.

Contesto: il sistema deve fornire l’accesso a risorse e/o servizi condivisi a un insieme di client distribuiti. Più in particolare il problema è consentire l’accesso a risorse e/o servizi condivisi sostenendo scalabilità, disponibilità da una parte e riuso e modificabilità dall’altra. La soluzione proposta da questo client-server è di organizzare il sistema come un insieme di servizi, server e client, che sono i tre tipici elementi di questo stile. 

Ciascun servizio è caratterizzato da un’interfaccia, basata su un protocollo richiesta-risposta (di tipo sincrono), ed è un elemento centrale in questo stile architetturale.

Un server è un componente software runtime quindi un processo in grado di erogare uno o più servizi, da esso implementati.

Un client è anch’esso un componente runtime (processo) interessato a fruire di uno o più servizi, da parte di uno o più server.

In generale sono i client che richiedono servizi ai server, che svolgono attività solo se richieste ed inoltre questo stile prevede che ci possono essere molti client concorrenti. Quindi i server devono essere implementati in modo da consentire l’accesso concorrente, questo può essere facilitato con le tecnologie di middleware.

In alcuni casi alcuni componenti possono agire sia da server di alcuni servizi. che da client di altri servizi, in particolare quando implementano funzionalità che richiedono il supporto di servizi offerti di altri componenti.

Stile client-server e livelli

Un concetto importante nello stile C/S è quello di livello: in generale il sistema può essere organizzato come una sequenza di livelli; un livello è un nodo o un gruppo di nodi su cui è distribuito il sistema C/S; ogni livello ha responsabilità coese:

Esistono architetture client-server a due, tre e anche quattro livelli.

Nell’architettura a due livelli si distinguono il livello client ed il livello server. Il livello server si fa sempre carico della responsabilità di gestione delle risorse ed il livello server della presentazione, mentre la responsabilità della logica applicativa nel caso di thin client è assegnata al client e nel caso di thick client è assegnata al server. La prima è la prima architettura client-server introdotta intorno agli anni ‘80 in cui i client avevano capacità elaborative abbastanza scarse, ma può sovraccaricare il server ponendo problemi di scalabilità. Il thick consente di ridurre il carico a lato del server, quindi una scalabilità migliore  

Nell’architettura a tre livelli il livello client si occupa solo della presentazione, un server intermedio che si occupa della logica applicativa chiamato talvolta application server, ed un data server per la gestione dei dati e delle risorse. In questo modo il carico viene distribuito meglio ed è possibile ottenere prestazioni migliori ed una migliore scalabilità, anche se l’architettura è più complessa, ma facilitata dall’utilizzo dei middleware moderni. Un’applicazione JavaEE è organizzata su quattro livelli un livello client, due livelli per la logica applicativa (Web Tier e Business Tier quest’ultima costituita da diversi tipi di componenti) e da un Database server. L’introduzione di più livelli consente maggiore flessibilità nella realizzazione di applicazioni, anche se aumenta la complessità e richiede l’uso di middleware più sofisticati.

 

Tipi di servizi

Nello stile client-server i servizi costituiscono una risorsa fondamentale.

Esistono diversi tipi di servizi:

un servizio è stateful se mantiene informazioni sulle conversazioni ovvero sulle sessioni di lavoro con i suoi client; (per esempio un servizio di commercio elettronico, deve mantenere memoria del carrello del cliente, nel momento della vendita)

altrimenti viene detto stateless (per esempio un servizio di previsione del tempo).

In genere questi ultimi sono più facili da implementare e non pongono problemi di scalabilità, mentre i primi possono richiedere dei middleware, essendo più complessi.

 

Altre caratteristiche

Nello stile client-server la comunicazione di solito è asimmetrica e sincrona.

Di tipo asincrono perché la comunicazione è iniziata dal client e proseguita dal server, inoltre è sincrona perché il client rimane in attesa dell’esecuzione da parte del server, ma talvolta sono possibili chiamate asincrone, notifiche e callback che rompono questi vincoli comuni, perché il client dopo la richiesta, continua a lavorare senza attendere la risposta, con le callback il server notifica al client il completamento di un’operazione onerosa e gli restituisce i risultati

GIS 

Cos'è un GIS

Un gis è un sistema informativo ITC di supporto alla acquisizione, analisi, archiviazione e restituzione di informazioni georeferenziate, che hanno cioè una collocazione nello spazio con un riferimento di coordinate.

Per quanto riguarda gli elementi costituenti un GIS, secondo una nota definizione il GIS è composto da elementi SW per acquisire, estrarre, memorizzare,  trasformare e visualizzare dati spaziali.

Funzionalità che un GIS deve offrire
  • Overlay topologico (procedura di analisi spaziale che consente di sovrapporre e intersecare gli strati informativi (layer) unendo così le informazioni associate a ciascuno di essi, per produrre un nuovo strato di sintesi);
  • la possibilità di formulare query spaziali 
  • la possibilità di effettuare buffering per calcolare la distanza tra due elementi in  piani differenti;
  • segmentare una immagine;
  • effettuare operazioni di network analysis e/o di spatial analysis e/o analisi geostatistiche
Quantum GIS (qgis.org)
  • E’ un applicativo Open Source (quindi modificabile, di cui  si possono consultare i sorgenti ed estendibile);
  • il SW di QGIS può essere esteso con funzionalità aggiuntive (implementando dei plug-in);
  • permette la creazione di mappe multilivello (in un sistema informativo georeferenziato, una mappa, chiamata progetto, è composta di più mappe omogenee; ogni mappa rappresenta un certo tipo di entità. Un progetto è una serie di livelli visualizzati uno sopra l’altro);
  • Eèun integrazione di funzionalità con il sistema PostGIS, che è a sua volta un’estensione spaziale del DBMS relazionale PostGRES.

 

Ambiente integrato per la collaborazione (ICE)

Che cos’è un ambiente integrato per la collaborazione (ICE)

E’ una piattaforma per interattività usabile con un PC in una rete esistente. Quindi può sfruttare quanto è attualmente esistente nell’impresa e non richiede nuovi costi per investimenti aggiuntivi. Prevede la creazione di comunità virtuali, ma occorre precisare che le nuove tecnologie non solo la panacea per il loro funzionamento; il gruppo virtuale va controllato, animato e sostenuto da una comunità reale.

Una piattaforma è un ambiente di lavoro general purpose, cioè non è progettato per specifici obiettivi ed applicazioni, ma per un uso che può essere di volta in volta configurato ed adattato. In questa piattaforma gli utenti potranno sviluppare le loro applicazioni, oppure leggere documenti o anche i sorgenti dei programmi in caso di attività di gruppo, o utilizzare applicativi.

Si è passati attraverso diverse fasi: inizialmente era prevista una strutturazione interna del main program in moduli e poi con la programmazione ad oggetti i moduli sono diventati autonomi e quindi anche riutilizzabili. Adesso la tendenza è verso l’utilizzo di sistemi integrati, piattaforme general purpose component-based, quindi ambienti in cui è possibile integrare componenti quali elementi che di volta in volta vengono implementati o scelti e configurati dinamicamente per le funzioni che è necessario svolgere.

L’interattività è un insieme di tecniche e metodi che sono studiati nel settore HCI human-computer interaction, interazione uomo computer e anche dal computer-supported community work (CSCW) che si occupa dell’interazione e della collaborazione attraverso il computer. Nell’iinterattività vengono svolte attività comuni, cioè gli uomini collaborano allo svolgimento di una stessa attività verso obiettivi comuni. Il flusso di informazioni è bi-direzionale, cioè la comunicazione tra gli interlocutori è reciproca; la comunicazione è pluri-direzionale quindi in un gruppo è supportata la comunicazione tutti a tutti, una persona può quindi interloquire o mandare messaggi in maniera sincrona con tutti o con più interlocutori; l’utente deve essere attivo, cioè l’interattività ha senso se una “massa critica”, quindi gran parte degli utenti partecipa attivamente e non come semplice uditore.

Funzionalità disponibili per l’ICE.  Gli ambienti integrati non sono un prodotto definito e sistemi con una configurazione fissata, ma sono insiemi di strumenti che vengono integrati e configurati a seconda delle situazioni, delle necessità e degli obiettivi contingenti.

Prima di tutto ci sono l’audio e la videoconferenza, poi strumenti per la gestione di streaming anche per la gestione e l’uso da remoto di archivi di filmati, la condivisione di desktop per lavorare e condividere un progetto comune, la condivisione di testi per l’editing multiutente dei documenti, che comprende la funzionalità necessaria del versioning; la comunicazione sincrona, cioè i messaggi scambiati con la presenza contemporanea degli interlocutori on line, esempio chat o skype conference fatte con lo scambio di messaggi, gli instant messaging, la comunicazione asincrona quindi forum o scambio di email, gruppi di discussione; interfacce intuitive e semplici.

Esempi specifici di ICE includono Collaborative software per la collaborazione, sistemi per la gestione di flusso di lavoro automatizzati Workflow system, sistemi per la gestione di documenti Document management system, sistemi per la collaborazione peer-to-peer che quindi non fanno uso di server Peer-to-peer collaboration software, sistemi per la gestione della conoscenza Knowledge management system e Social network per la comunicazione.

Lo sviluppo di groupware è una questione ancora aperta e complessa essendo socio-tecnologica, implicando cioè una doppia dimensione sociale, come le inter-relazioni ed i metodi di lavoro e tecnologica come la decisione di quali siano i migliori strumenti e device per sostenere questo tipo di attività. Per questo vengono coinvolti gruppi pluridisciplinari per lo studio e la realizzazione di questi sistemi.

 

ERPS obiettivi e visione d’insieme 

Descrizione generale e obiettivi di un'ERPS

ERPS è un acronimo che significa Enterprise resource planning system, vale a dire sistemi per la gestione delle risorse d’impresa.

Sono degli applicativi generici basati cioè su una piattaforma, su un software applicativo generale, che viene configurato secondo le necessità della singola impresa.

La base di dati su cui si basano questi sistemi deve infatti essere unica, in genere centralizzata, o costituita da archivi distribuiti, ma con un controllo centrale e con una unità di schema di gestione di questi sistemi.

Loro scopo principale è la gestione dell’informazione, che è uno degli aspetti principali della gestione dell’impresa, perché le informazioni devono essere uniche, cioé un’informazione deve essere misurata da un solo dato, in qualunque sua versione e collocazione nell’ambito dei vari archivi di un’impresa. Tutti i reparti di un’impresa devono poter disporre delle stesse informazioni senza ridondanza. Per questo la gestione dell’informazione deve soddisfare determinati principi, che diano la rilevanza che merita a questo aspetto.

La base di dati è condivisa, tutti i moduli, tutti i reparti, devono poter accedere a questa base di dati, attraverso interfacce che costituiscono gli strumenti per l’interattività tra i vari dipendenti dell’impresa,

Tutte le funzioni di gestione dell’impresa potranno accedere a queste informazioni, coordinarsi e usufruire di un’alta interoperabilità: i vari moduli da un lato possono comunicare tra di essi e dall’altro possono scambiarsi informazioni. I vari settori funzionali di questi sistemi sono sostenuti da moduli, componenti software che permettono lo svolgimento adeguato delle funzionalità per gli scopi dell’impresa.

Visione d’insieme

Si tratta di un sistema complesso che fornisce un’ampia copertura funzionale, offrendo sistemi diversi ed eterogenei che permettono di svolgere diverse funzioni e servizi, necessari alla conduzione di un’azienda, in relazione alle diverse attività che vengono svolte dai diversi reparti che compongono una qualsiasi organizzazione aziendale. La diversità di questi moduli, delle necessità e delle funzionalità richieste dai reparti, richiede un’alta interoperabilità tra i vari moduli, interoperabilità sia per lo scambio dei dati, sia per lo svolgimento collaborativo di attività. Infine per una buona gestione delle risorse d’impresa è prevista l’integrazione dei dati.

Questa complessità viene spesso gestita da uno specifico modulo supervisore, vale a dire un modulo per la gestione degli altri moduli specialistici.

Ci sono due tipi di gestione integrata in un sistema complesso:

  • la gestione integrata dei processi per un maggiore risparmio, per poter prendere decisioni veloci e precise e per offrire dati visibili in tutta la realtà aziendale ed eventualmente, anche all’esterno dell’impresa, per la gestione e fidelizzazione dei rapporti con il cliente;
  • la gestione integrata dell’informazione richiede la condivisione e l’aggiornamento delle basi di dati, permette una revisione delle strategie fornendo dati aggiornati, robusti e di prospettiva; una ottimizzazione dei processi che fanno riferimento ad una stessa base informativa, permettendo una economia di gestione e raccogliendo i dati dove e quando servono; le informazioni sono coerenti e omogenee in quanto sono ben gestite, hanno un solo valore e non sono ridondanti. Una buona gestione delle informazioni sostiene quindi anche l’integrità e unicità dell’informazione, ma anche la comunicazione in e out, sia all’interno che verso l’esterno dell’organizzazione e la formazione globale sostenuta dalla possibilità di accesso alle informazioni riservate dell’impresa da parte delle risorse umane;

Le chiavi del successo di un’ERPS di un’azienda sono:

la scelta del sistema che deve essere corretta in riferimento al contesto aziendale. ovvero alle necessità dell’impresa, dal quale dipende anche la configurazione specifica; l’integrazione nei servizi attualmente erogati e l’appropriazione da parte degli utenti sia di quelli interni del back-office, sia degli utenti esterni, come i clienti.

La chiave dell’insuccesso di un’ERPS è invece non comprendere in anticipo le necessità e gli obiettivi dell’impresa. Il successo non è quindi nell’acquisizione di un moderno sistema tecnologico, ma nell’acquisizione del corretto moderno sistema tecnologico.

Per quanto riguarda l’adeguamento alle richieste di cambiamento, che spesso sono necessarie essendo l’ERPS un sistema complesso che viene utilizzato per lunghi periodi in un’impresa, si possono distinguere tre fasi: in una prima fase, durata fino a poco tempo fa, l’adeguamento è stato carente, soprattutto a causa degli applicativi su misura utilizzati nello svolgimento delle attività, implementati basandosi su soluzioni pregresse; c’è stata poi, sempre in questa prima fase, un’evoluzione verso l’inclusione di soluzioni stand-alone sempre però implementate da un solo sviluppatore, che fornissero la massima integrazione ed efficienza, valori positivi ma che fanno perdere molto alla modularità e alla modificabilità di un sistema complesso. Nella seconda fase di sviluppo di questi sistemi si è passati a quella che viene chiamata “strategia il meglio disponibile”, con cui le soluzioni sono realizzate acquisendo nuovi prodotti e con sviluppo di funzionalità, eventualmente implementare ancora da un singolo sviluppatore tenendo conto dell’integrazione all’interno dell’azienda, ma per quanto riguarda l’estensibilità, facendo riferimento al meglio, cioè agli applicativi di punta sul mercato. La terza fase è denominata “integrazione del meglio disponibile” e si riferisce al fatto che non necessariamente i sistemi vengono implementati, infatti l’ERPS è un sistema general purpose che viene esteso acquisendo i componenti migliori sul mercato. Le carenze implementative possono quindi essere risolte con l’interfacciamento ad un sistema esterno eventualmente utilizzando le moderne tecnologie dei web services, con la riscrittura parziale del codice, o con l’implementazione di un modulo specifico.

I principi realizzativi sono l’integrazione di elementi e di moduli software, autonomi ed interoperabili, sia sintatticamente che semanticamente, lo scambio di dati coerente, la base di dati comune ed in genere è utile che ci sia a disposizione un motore di gestione dei workflow, ossia dei flussi lavorativi (WfMS)

Lo sviluppo di un’ERPS porta cambiamenti non solo automatici e tecnologici, ma anche dei processi lavorativi che devono essere aggiornati, nello Staff cioè nelle figure funzionali e loro competenze e nell’operatività cioè nello svolgimento effettivo delle attività svolte.

 

Tattiche architetturali 

In quale momento della definizione di un’architettura software è utile 
applicare le tattiche architetturali

Due importanti approcci per la progettazione degli attributi di qualità, sono gli stili architetturali e le tattiche architetturali. Gli stili architetturali sono utili soprattutto nella fase iniziale di definizione dell’architettura e le tattiche architetturali sono utili soprattutto nel momento di raffinamento dell’architettura.

Le tattiche architetturali sono normalmente delle operazioni di trasformazione, ovvero possono essere applicate quando esiste già un’architettura di riferimento che non soddisfa però in modo adeguato una certa qualità, per esempio le prestazioni. Trasformare un’architettura significa o cambiare la scelta degli elementi che costituiscono una vista dell’architettura oppure il modo in cui gli elementi interagiscono tra di loro, oppure anche cambiare l’assegnazione di responsabilità agli elementi dell’architettura.


Che cos’è una tattica architetturale

Una tattica architetturale è una decisione di progetto che influenza il controllo di un attributo di qualità. In generale le tattiche architetturali presentano queste caratteristiche:

  • codificano le buone esperienze di progettazione;
  • sono opzioni di progettazione, che possono essere alternative tra loro o lavorare in sinergia;
  • si tratta di trasformazioni a grana fine, ovvero riguardano un punto o una manciata di elementi di una delle viste dell’architettura e non hanno influenza sulla struttura complessiva del sistema, è per questo che sono utili soprattutto nel contesto del raffinamento dell’architettura;
  • nell’applicare le tattiche occorre fare attenzione agli effetti collaterali, in certi casi applicando una tattica si migliora il controllo di una qualità e contemporaneamente anche quello di altre qualità, ma in altri casi occorre trovare un compromesso perché migliorando una qualità, si possono avere delle ripercussioni negative sulle altre.


 


 

			

	
	


							


	

		
				

			CRM
		

			


		

		
Definizione di Customer Relationship Management


CRM è un approccio operativo e commerciale al business, alla gestione dell’impresa, che comprende le seguenti attività:


    

  • vendita;e marketing (quindi le attività che riguardano le relazioni con il cliente e la presentazione dei prodotti);
    • 

  • gestione delle transazioni (quindi gli scambi commerciali, la contabilità, le operazioni finanziare);
    • 

  • servizi ai clienti (servizi pre-post vendita ai clienti, ma anche la gestione dei rapporti, come fare per fidelizzare e attrarre i clienti, per conservare e rafforzare il rapporto con loro, ma anche per convincerli ad entrare nella propria clientela);
    • 

  • Gestione problemi e delle esigenze per anticipare, creare, soddisfare, rafforzare relazioni con il cliente;
    • 



Quindi il CRM è un approccio alla gestione imprenditoriale ed aziendale, che è potenziato e supportato dalle tecnologie ICT. Quindi non bisogna confondere l’approccio con un’attività che viene completamente automatizzata.

			

	
	


							


	

		
				

			Cloud computing
		

			


		

		
 


Definizione del Cloud Comnputing e sue caratteristiche.


Il Nist “National Institute of Standards of Technology” ha dato la prima definizione di Cloud computing definendolo come “un modello per la gestione di risorse di calcolo:


    

  • Ubique, che non hanno come caratteristica determinante la loro posizione geografica; il sistema è ubiquo anche lato cliente nel senso che possono essere considerati in questo modello tutti i devices periferici, cellulari e mobili, che permettano un’ interazione, qualunque sia la loro posizione. Le risorse inoltre possono avere qualsiasi formato.
    • 

  • Convenienti, la gestione delle risorse con questo modello è conveniente; è possibile un risparmio economico, perchè non è necessario acquistare e gestire le risorse fisiche che vengono effettivamente utilizzate per le computazioni ed i servizi che vengono richiesti.
    • 

  • A richiesta, questa è una caratterista fondante e prevede che da una parte l’utente di un servizio cloud può richiedere un ammontare di risorse da utilizzare come la potenza di calcolo o la larghezza di banda o la quantità di memoria di archiviazione, ma le risorse sono poi valutate sulla base della necessità, durante l’esecuzione delle computazione e durante l’erogazione dei servizi. Quindi se l’esecuzione di un operazione sta determinando la fine della computazione della memoria, il meccanismo di gestione del modello cloud fornisce risorse aggiuntive.
    • 

  • Fornite e rilasciate rapidamente.
    • 

  • Minima interazione con il fornitore.
    • 



Strumenti di supporto


    

  • Internet;
    • 

  • Middleware avanzato;
    • 

  • Sistemi operativi;
    • 

  • Interfacce utente;
    • 

  • Reti;
    • 

  • Protocolli mobile;
    • 

  • Sensori geo-localizzati.
    • 



Modello dei servizi e caratteristiche essenziali del Cloud Computing


Elementi cardine del servizio sono:


    

  • Virtualizzazione HW & SW;
    • 

  • Controllo;
    • 

  • Gestione erogazione servizi.
    • 



 


    

  • Self-service a richiesta

      

    • Autonomia

        

      • cataloghi servizi;
        • 

      • no interazione con il fornitore;
        • 

      • configurazione servizi.
        • 

      

      • 

    

    • 

  • Accesso alla rete

      

    • Servizi acceduti da rete;
      • 

    • Client HW leggeri e pesanti;
      • 

    • Client SW standard;
      • 

    • Client cloud;
      • 

    

    • 

  • Raggruppamento risorse

      

    • Memoria;
      • 

    • Archiviazione;
      • 

    • Elaborazione;
      • 

    • Larghezza di banda;
      • 

    • Condivisione;
      • 

    • Allocazione dinamica;
      • 

    • Gestione richieste.
      • 

    

    • 

  • Elasticità rapida

      

    • Capacità fornite e rilasciate;
      • 

    • Automaticamente;
      • 

    • Secondo necessità;ta
      • 

    • Disponibilità illimitata.
      • 

    

    • 

  • Misurazione servizi

      

    • Misurazione specifica servizio;
      • 

    • Controllo automatico;
      • 

    • Ottimizzazione uso;
      • 

    • Reporting;
      • 

    

    • 

  • Application Programming Interface -> agevole HCI (es. App che comprendono mobile application, SW applicativo per smartphone, tablet e device mobili);
    • 

  • virtualizzazione -> agevole trasferimento applicazioni.
    • 

  • maggiore affidabilità -> ridondanza, ripetizione.
    • 



Tipologie di fornitura di servizi attraverso il Cloud.


    

  • Sofware as a Service

      

    • Uso applicazioni;
      • 

    • Applicazioni fornite;
      • 

    • Accesso da client;
      • 

    • No controllo infrastruttura;
      • 

    • Configurazione parziale.
      • 

    

    • 



Esempi: Email, Google apps, Desktop virtuali,Customer Relationship Management System. Google apps:  Servizio alle aziende, Risorse di calcolo, Collaborazione online; Via Cloud computing, integra servizi Google, Account personalizzati, Ambiente amministratore.


    

  • Google apps:

      

    • Servizio alle aziende;
      • 

    • Risorse di calcolo;
      • 

    • Collaborazione on line;
      • 

    • Via cloud computing.
      • 

    

    • 



    

  • Platform as a Service;

      

    • Sviluppo dell’utente;
      • 

    • Non c’è il controllo infrastruttura;
      • 

    • Controllo dell’applicazione;
      • 

    • Configurazione ambiente sviluppo.
      • 

    

    • 

  • Esempi

      

    • DBMS;
      • 

    • Server SW;
      • 

    • Strumenti sviluppo.
      • 

    

    • 



    

  • Infrastructure as a Service

      

    • Utente raccoglie risorse;
      • 

    • Non ha il controllo dell’infrastruttura;
      • 

    • Controllo SO;
      • 

    

    • 

  • Esempi

      

    • Macchine virtuali;
      • 

    • Server HW;
      • 

    • Sistema operativo.
      • 

    

    • 



    

  • Storage as a Service

      

    • Ospitalità file system
      • 

    

    • 



Esempi: Dropbox, Google Drive, SkyDrive, Ubuntu One.


    

  • Data as a Service

      

    • Accesso dati da applicazione;
      • 

    • Uso via mashup

        

      • Mashup è una Applicazione web con le seguenti caratteristiche:

          

        • Integrazione semplice;
          • 

        • Contenuti da fonti differenti;
          • 

        • Risultati arricchiti;
          • 

        • Non previsti;
          • 

        • Servizio singolo;
          • 

        • Unica interfaccia utente.
          • 

        • Componenti, connettori standard -> semplice integrazione contenuti;
          • 

        • Abilitatori -> conversione contenuti;
          • 

        

        • 

      

      • 

    

    • 



    

  • Business Process as a Service

      

    • Accesso a funzionalità gestione Wf;
      • 

    • Non è necessaria esperienza informatica;
      • 

    

    • 

  • Network as a Service

      

    • Accesso a rete;
      • 

    • Accesso a cloud diversi;
      • 

    • Software Defined Networking:

        

      • Paradigma di architettura di rete che prevede una separazione netta tra livello di controllo e livello dati;
        • 

      • Protocollo OpenFlow;
        • 

      • Standardizzato;
        • 

      • Potenza;
        • 

      

      • 

    

    • 



Application Programming Interface


    

  • Servizi valore aggiunto;
    • 

  • Indipendenza da HW;
    • 

  • Gestione dinamica;
    • 

  • Qualità del Servizio.
    • 



Classi di consumatori dei servizi Cloud.


    

  • Cloud privato

      

    • Uso:

        

      • Singola organizzazione;
        • 

      • Molti utenti.
        • 

      

      • 

    • Proprietà, gestione e attivazione

        

      • Organizzazione;
        • 

      • Fornitore esterno;
        • 

      • Entrambi;
        • 

      • Ambiente lavorativo virtuale;
        • 

      • Diversa pianificazione risorse;
        • 

      • Miglioramento lavoro;
        • 

      • Richiesta di sicurezza.
        • 

      

      • 

    

    • 

  • Cloud di comunità

      

    • Uso:

        

      • Organizzazioni con interessi comuni.
        • 

      

      • 

    • Proprietà, gestione, attivazione

        

      • Organizzazioni della comunità;
        • 

      • Fornitore esterno;
        • 

      • Entrambi.
        • 

      

      • 

    

    • 

  • Cloud pubblico

      

    • Uso:

        

      • Pubblico;
        • 

      

      • 

    • Proprietà, gestione e attivazione

        

      • Imprenditori;
        • 

      • Università;
        • 

      • Pubblica Amministrazione;
        • 

      • Combinazione;
        • 

      

      • 

    

    • 

  • Cloud ibrido.

      

    • Uso:

        

      • Infrastrutture eterogenee.
        • 

      

      • 

    • Proprietà, gestione, attivazione:

        

      • Privati;
        • 

      • Comunità;
        • 

      • Pubblici.
        • 

      

      • 

    • Questo tipo di cloud comporta la risoluzione di problemi di:

        

      • Interoperabilità;
        • 

      • Standard;
        • 

      • Trasporto dati;
        • 

      • Trasporto applicazioni;
        • 

      • Bilanciamento cloud.
        • 

      

      • 

    

    • 



Spunti di riflessione suggeriti


    

  • In che classe di consumatori inserireste la vostra realtà lavorativa? E quella formativa? Argomentate
    • 


			

	
	


							


	

		
				

			Design pattern
		

			


		

		
Un pattern software è una soluzione provata e ampiamente applicabile ad un particolare problema di progettazione, scritta in una forma standard.  Ci sono diversi tipi di pattern software:


    

  • i pattern GRASP – codificano dei principi per l’assegnazione di responsabilità e sono dei pattern molto generali;
    • 

  • design pattern – sono dei pattern di progettazione molto più diffusi; sono costituiti da alcuni oggetti e classi che interagiscono tra di loro, sono quindi a grana relativamente piccola;
    • 

  • pattern architetturali – per esempio l’architettura a strati e poiché uno strato potrebbe racchiudere decine o centinaia di classi, sono a grana grossa;
    • 

  • idiomi di programmazione – sono di granularità più piccola e la soluzione è costituita da una manciata di istruzioni;
    • 



 

			

	
	


							


	

		
				

			Modellazione di dominio
		

			


		

		
Analisi di un sistema software


L’analisi del software è interessata a comprendere il problema che il software è chiamato a risolvere, indipendentemente dalle possibili soluzioni. L’analisi del software può essere svolta in modi diversi, una di queste è l’analisi orientata agli oggetti. In particolare l’analisi per un sistema software è interessata a comprendere:


    

  • le informazioni che il sistema deve gestire;
    • 

  • le funzioni che il sistema deve svolgere;
    • 

  • il comportamento del sistema;
    • 



Per esempio un sistema di anagrafe di un comune, deve rappresentare le informazioni sugli abitanti di un comune e sui rispettivi nuclei familiari. Questa rappresentazione fa riferimento solo ad alcuni dati del dominio di interesse, non a tutte le informazioni del mondo reale. Il sistema deve essere dinamico nel senso che deve acquisire conoscenza anche dei cambiamenti relativi alle informazioni.


Differenza tra funzioni e comportamento.


Le funzioni o operazioni del sistema definiscono le interazioni con il sistema, in particolare gestiscono le notifiche dei cambiamenti di stato delle informazioni avvenuti nel mondo reale e di cui il sistema deve tenere in conto. Per esempio la nascita di una nuova persona comporta la notifica della nascita stessa nel sistema di anagrafe.


Un comportamento definisce il modo in cui il sistema deve reagire alle funzioni che comportano un cambiamento di stato, aggiornando il suo stato e la propria conoscenza delle informazioni del dominio di interesse. Per esempio, ritornando all’esempio precedente, dopo la notifica della funzione, si deve procedere alla registrazione del nascituro, nel sistema di anagrafe.


Classe concettuale, associazione e attributo presenti in un modello di dominio


Una classe concettuale rappresenta un concetto del mondo reale del sistema che si sta modellando, in particolare rappresenta un insieme di oggetti che sono considerati simili, per esempio la classe studente o la classe corso di una università. Il modello di dominio mostra una “astrazione” di cose del mondo reale, quindi identifica in una stessa classe degli oggetti che hanno delle caratteristiche simili, dove la similitudine va misurata nell’ambito del dominio di interesse. Ed inoltre è un’astrazione perché non vengono rappresentati tutti gli aspetti del mondo reale, ma solo gli aspetti rilevanti nel dominio del nostro sistema. Per esempio degli studenti interesserà sapere il nome, cognome e la matricola, ma non l’altezza o il peso non di interesse nel dominio dell’università. E’ possibile pensare ad una classe in termine di tre aspetti che sono:


    

  • simbolo – utilizzato nel diagramma per rappresentare la classe, nel caso di UML la notazione è un rettangolo con all’interno il nome della classe, che normalmente viene scelto al singolare per rappresentare il singolo elemento della classe;
    • 

  • intenzione – ossia la definizione, normalmente fatta in linguaggio naturale, degli elementi della classe, che viene tipicamente riportata nel glossario: va specificato quale dominio si vuole rappresentare con il simbolo, ad esempio uno studente già laureato o ancora immatricolato e gli studenti di quale/i università. Il simbolo da solo non aiuta a capire cosa si vuole rappresentare con esso, per cui questa, per evitare ambiguità, l’interpretazione va definita con precisione.
    • 

  • estensione – l’estensione di una classe è l’insieme degli oggetti del mondo reale e del dominio di interesse rappresentati da questa classe. Le istanze di una classe in UML sono chiamate oggetti. La notazione in UML per gli oggetti è ancora il rettangolo, con un nome simbolico per l’oggetto seguito dal simbolo “:” ed il nome della classe, cioè il nome dell’insieme cui appartiene quell’oggetto. In questo caso l’oggetto rappresenta un oggetto del mondo reale, non è un oggetto del mondo software memorizzato in un computer. In un modello di dominio le classi sono probabilmente il costrutto più significativo ed i concetti più importanti del dominio vanno sicuramente rappresentati come classi.
    • 



Una classe descrizione contiene informazioni che descrivono qualcos’altro. Il principio è che una informazione, per quanto possibile, va rappresentata in un posto solo.


    

  • Un’associazione è una relazione tra classi che indica una connessione significativa fra le classi stesse. In UML l’associazione viene rappresentata da una linea che collega le due classi con l’indicazione del nome dell’associazione, più ulteriori informazioni, frequente è la molteplicità. Le istanze delle associazioni sono chiamate collegamenti e vengono rappresentate con una linea che collega i due oggetti, con accanto il nome dell’associazione, di cui quel collegamento è istanza.

      

    • Un aggregazione è un associazione che suggerisce una relazione intero-parte.
      • 

    • Una composizione è una forma forte di aggregazione intero-parte, più utile da mostrare.

        

      • ciascuna parte appartiene ad un solo composto;
        • 

      • ciascuna parte deve sempre appartenere ad un composto;
        • 

      • la vita delle parti è limitata da quella del composto.
        • 

      

      • 

    

    • 

  • Un attributo è un valore, ovvero un dato, degli oggetti di una classe. La notazione è ancora il rettangolo, questa volta diviso in sezioni. Nella sezione più alta c’è il nome della classe, nella seconda sezione sono elencati gli attributi della classe. Ad esempio gli attributi matricola, nome e cognome di una classe studente. A livello di istanza un attributo di una classe associa a ciascun oggetto della classe un valore. Nelle istanze di classe quindi gli attributi assumono valori diversi di quelli presenti negli altri oggetti ad esempio matricola=12345, nome=”Mario”.

      

    • Gli attributi che è utile ricordare sono quelli per cui i requisiti indicano la necessità di ricordare informazioni (dati). 
      • 

    • Gli attributi devono avere un tipo semplice, elementare. 
      • 

    

    • 



Modello di dominio


Il modello di dominio descrive le informazioni di interesse attraverso classi, associazioni e attributi; in genere contiene una decina o qualche decina di classi, associazioni o attributi. Ci sono diverse motivazione per cui creare un modello di dominio, sia nel contesto dell’analisi che in quello della progettazione. Nel contesto dell’analisi è utilizzato:


    

  • per analizzare le informazioni che il sistema deve gestire;
    • 

  • per comprendere il dominio ed il suo vocabolario. I nomi del modello di dominio devono quindi essere significativi e descrivere solo cose che ci sono nel dominio stesso e inseriti al singolare;
    • 

  • come fonte di ispirazione per le classi software dello strato del dominio; cioè i nomi scelti per le classi software in genere si ispirano a quelli delle classi di dominio.
    • 



Quindi il modello di dominio rappresenta le informazioni che il sistema deve gestire ed è utile perché nella progettazione, si sceglieranno molte classi software e associazioni ispirandosi alle classi del modello di dominio. ispirandosi al principio del salto rappresentazionale basso.


Creare un modello di dominio sembra semplice, ma è un’attività complessa. E’ teoricamente semplice perché per crearlo è sufficiente identificare le classi, le associazioni, gli attributi e mostrarli in un diagramma utilizzato come modello di dominio. Queste attività non vanno svolte in cascata, una dopo l’altra, ma sono intrecciate tra di loro. Lo sviluppo di un modello di dominio in ambito iterativo, va fatto solo con riferimento ai requisiti correnti dell’iterazione in cui ci troviamo, per esempio per una certa iterazione POS possiamo essere interessati solo al pagamento in contanti e non ad altri tipi di addebiti. Il termine modello di dominio, non è un termine di UML, ma piuttosto un termine del processo unificato; UML definisce il diagramma delle classi non un modello di dominio. Quest’ultimo sta ad indicare un diagramma delle classi di UML utilizzato, dal punto di vista concettuale, per descrivere le informazioni di interesse, nel dominio del sistema in discussione.


 

			

	
	


							


	

		
				

			Architetture sofware: introduzione
		

			


		

		
Esistono numerose definizioni di architettura sofware una delle quali è la seguente: l’architettura software di un sistema software è l’insieme delle strutture del sistema, necessarie per ragionare su di esso, che comprendono elementi sofware, le relazioni tra di essi, e le loro proprietà.


I sistemi sofware sono caratterizzati da:


    

  • una grande complessità;
    • 

  • i requisiti di qualità, che derivano da molte parti interessate, rivestono un ruolo sempre più significativo per il successo di questi sistemi;
    • 



Nello sviluppo del sofware non è quindi sufficiente considerare solo elementi a “grana piccola” come classi e oggetti, ma anche elementi a “grana grossa”, cioè elementi che contengono più classi ed oggetti; occorre considerare anche i requisiti di qualità e non solo quelli funzionali.


L’architettura sofware è il vettore principale delle qualità di un sistema software (come prestazioni, sicurezza e modificabilità), nessuna delle quali può essere raggiunta senza una visione architetturale unificante.


La disciplina dellearchitettura software è interessata alla:


    

  • progettazione di sistemi complessi;
    • 

  • progettazione di elementi sofware a “grana grossa”;
    • 

  • progettazione per i requisiti di qualità.
    • 



Un’architettura comprende/definisce una serie di elementi. 


    

  • Sono importanti sia elementi software, che elementi non software (come l’hardware su cui il sofware è mandato in esecuzione, ma anche il team di sviluppo che si occupa dell’implementazione).
    • 

  • Ogni elemento sofware è caratterizzato da:

      

    • un insieme di responsabilità (che cosa l’elemento deve fare);
      • 

    • un confine (che cosa l’elemento non deve fare);
      • 

    • un insieme di interfacce;
      • 

    

    • 

  • Esistono due tipi principali di elementi sofware:

      

    • componenti, responsabili di funzionalità e della gestione dei dati;
      • 

    • connettori, responsabili della interazione fra componenti.
      • 

    

    •