Validazione sistema cloud

Partendo dalla validazione del sistema sul cloud, dunque, veriĄcheremo se quanto deĄnito nel capitolo relativo alle speciĄche di sistema ‘e stato rispettato.

I requisiti funzionali che rientrano nel dominio del sistema su cloud sono indicati con i codici RF1, RF4, RF5, RF6, RF7, RF8. Di seguito, per ciascun requisito funzionale, verr‘a analizzata ogni componente del sistema e verr‘a mostrato come esso risponde a tale requisito e attraverso quale funzionalit‘a riesce a soddisfarlo. I requisiti funzionali in questione sono:

• RF1 : il primo requisito funzionale aveva lo scopo di speciĄcare che il sistema dovr‘a consentire lŠelaborazione di dati satellitari. Tale speciĄca, ovviamente, ‘e automaticamente rispettata nel momento in cui abbiamo scelto Open Data Cube come piattaforma IT; infatti, ‘e proprio questo che ci ha guidati verso la scelta della piattaforma.

• RF4 : questo requisito si occupava di deĄnire le funzionalit‘a del sistema Ąnale ed, in particolare, il fatto che esso dovr‘a offrire la possibilit‘a di effettuare ana-lisi speciĄcando unŠarea geograĄca, un intervallo temporale ed un satellite. Per rispettare tale requisito abbiamo sfruttato la piattaforma ODC ed il sistema di sviluppo Jupyter; in particolare, questo requisito ci ha indirizzati verso la scelta della componente Jupyter per ODC grazie alla quale abbiamo consegnato agli analisti un sistema pronto per eseguire analisi e una pipeline di ETL che mette a disposizione i dati satellitari da analizzare.

• RF5 : tale requisito riguardava lŠimplementazione di unŠinterfaccia Web grazie alla quale gli utenti business si possano interfacciare con il sistema. Questa spe-ciĄca ‘e stata pienamente rispettata, come approfonditamente spiegato durante il presente elaborato di tesi, dal momento che abbiamo scelto di inglobare nel si-stema ODC la componente Web UI che ci ha messo a disposizione unŠinterfaccia graĄca da offrire allŠutente Ąnale per interagire con il sistema.

• RF6 : questa speciĄca imponeva che il sistema da realizzare predisponesse unŠap-posita area dove lŠutilizzatore Ąnale potesse condividere feedback, segnalare bug e/o comunicare qualsiasi problema riscontrato. La convalida di questa speciĄ-ca pu‘o essere visualizzata in Figura 5.7, dove viene mostrata proprio la pagina

ŞFeedbackŤ della Web UI di ODC che permette allŠutente di inviare feedback allŠadmin del sistema.

Figura 5.7.Area Feedback della Web UI di Open Data Cube

• RF7 : il presente requisito richiedeva la predisposizione di un notebook Jupyter che si interfacciasse con la piattaforma IT. Uno dei vari motivi che ci hanno por-tato alla scelta della piattaforma ODC, infatti, ‘e spor-tato proprio quello di poter integrare un servizio Jupyter al sistema. Come mostrato al termine del capitolo precedente ed, in particolare, nella sezione riguardante lŠimplementazione del si-stema in cloud, la pagina iniziale del servizio JupyterLab ‘e raggiungibile tramite lŠIP 18.198.132.132 alla porta 8000.

• RF8 : questa speciĄca riguardava la possibilit‘a di accedere al sistema attraverso il Web e, oltre questo, di offrire risorse cloud per permettere agli utenti di utilizzare il sistema a prescindere dalle risorse computazionali possedute da questi ultimi.

Come mostrato al termine dellŠimplementazione del sistema, questo requisito ‘e totalmente soddisfatto dal momento che il sistema ‘e raggiungibile allŠindirizzo 18.159.98.100 (speciĄcando la porta 8000) ed ‘e stato totalmente implementato in cloud utilizzando il servizio AWS di Amazon.

Parlando dei requisiti non funzionali, invece, quelli che rientrano nel suddetto do-minio sono indicati con i codici RNF4, RNF5, RNF6, RNF7, RNF8, RNF9, RNF10, RNF11, RNF12, RNF13, RNF14, RNF15. In maniera duale a quanto appena fatto per i requisiti funzionali, presenteremo nel seguito lŠanalisi di ogni requisito con la relativa validazione:

• RNF4 : questo requisito imponeva al sistema una continua disponibilit‘a. Per il rispetto di questa speciĄca, come gi‘a motivato nel capitolo della progettazione,

‘e stato adottato il sistema cloud di AWS, che assicura livelli di availability molto elevati e maggiori di qualunque altro cloud provider.

• RNF5 : questo requisito prevede che il sistema rispetti la reliability; questa policy

‘e stata veriĄcata durante la fase di testing (sia del sistema in cloud che della pipeline di ETL) e, come affermato precedentemente, verr‘a continuata a testare durante tutto il proseguimento del progetto Forestry Analyzer.

• RNF6 : questa speciĄca riguarda il rispetto dei principi di conĄdenzialit‘a ed integrit‘a dei dati. Per farlo abbiamo impostato metodi di autenticazione per ogni servizio ed, in particolare, per i dati sensibili degli utenti Ąnali (che verranno memorizzati del database di Django gestito da PostgreSQL).

• RNF7 : questo requisito richiede che il sistema assicuri che i dati satellitari ven-gano elaborati in maniera sufficientemente veloce. Come sappiamo, la velocit‘a di un sistema pu‘o essere misurata valutando i tempi di risposta a relativi a de-terminate richieste. Ovviamente, le operazioni pi‘u onerose che il sistema dovr‘a effettuare sono quelle di gestione ed analisi di dati satellitari molto pesanti. Pro-prio per questo motivo, la scelta della piattaforma IT ‘e stata fondamentale ed

‘e ricaduta su ODC che permette di elaborare i dati in tempi ragionevolmente brevi.

• RNF8 : il presente requisito impone che il sistema adotti appropriati livelli di sicurezza per ciascun componente del sistema. Innanzitutto, ‘e stato utilizzato un metodo di autenticazione per accedere ad ognuno dei 3 servizi del sistema (interfaccia Web, Jupyter e PostgreSQL). Inoltre, ‘e stato conĄgurato un sistema di autenticazione per le interfacce della Web UI (come possiamo vedere nelle Figure 5.8 e 5.9) e di JupyterLab.

Figura 5.8.Sistema di autenticazione della Web UI di Open Data Cube

Per quanto riguarda PostgreSQL, invece, questo servizio ‘e stato conĄgurato in una sotto-rete privata che lo rende raggiungibile solo dalle VM della UI e di Jupyter, assicurando lŠisolamento.

• RNF9 : questo requisito, che imponeva la scelta di una piattaforma open source,

‘e stato rispettato dal momento che la piattaforma IT adottata ‘e Open Data Cube, che fa della ĄlosoĄa open uno dei suoi punti di forza.

• RNF10 : questa speciĄca impone al sistema di garantire lŠastrazione dei dati;

come in alcuni requisiti gi‘a analizzati, in questo caso, il soddisfacimento del

re-Figura 5.9.Sistema di autenticazione di JupyterLab

quisito derivava totalmente dalla scelta della piattaforma IT. ODC, infatti, offre allŠutente un alto livello di astrazione nascondendo i dettagli dei dati satellitari grezzi ed agevolando la gestione degli stessi.

• RNF11 : il presente requisito riguarda lŠinterfaccia graĄca; in particolare, impone che essa dovr‘a essere chiara, intuitiva e di facile utilizzo per permettere una UX ottimale, ed, inoltre, richiede che la UI dovr‘a permettere di visualizzare i dataset disponibili su determinate aree del globo e di selezionare facilmente sotto-aree di interesse per visualizzare i risultati delle analisi.

Come possiamo vedere nelle Figure 5.10 e 5.11, la Web UI permette di soddisfare il requisito ed offre al cliente business, che utilizzer‘a il sistema, vari strumenti a supporto.

Figura 5.10.Mappa della Web UI

• RNF12 : il presente requisito impone che il sistema Ąnale dovr‘a essere agevolmen-te utilizzabile anche da uagevolmen-tenti che non hanno particolari conoscenze in ambito

Figura 5.11.Visualizzazione dei dati caricati in ODC

IT. Come abbiamo visto nelle immagini precedenti, la Web UI offre unŠagevole esperienza di navigazione attraverso un header che presenta vari men‘u a tendina per selezionare la funzionalit‘a con la quale interfacciarsi col sistema.

• RNF13 : questo requisito non funzionale richiedeva che il sistema deve essere accessibile agli utenti tramite un browser. Come si vede da tutti gli screenshot delle interfacce di ODC e di JupyterLab, questi ultimi sono servizi liberamente accessibili da un normalissimo browser (quello delle immagini, ad esempio, ‘e Google Chrome) cercando sul Web lŠindirizzo IP della macchina e la porta che viene esposta.

• RNF14 : il presente requisito richiede che la piattaforma IT scelta deve offrire la possibilit‘a di replicare lŠinfrastruttura su un sistema di cloud computing. Questo requisito ‘e stato uno dei pi‘u decisivi nella scelta della piattaforma ODC. Come abbiamo potuto vedere, ‘e stato possibile effettuare il deploy del sistema ODC su cloud utilizzando la tecnologia AWS offerta da Amazon.

• RNF15 : questŠultimo requisito non funzionale imponeva che il servizio di cloud computing a supporto del sistema sarebbe dovuto essere Amazon AWS e, come abbiamo visto, ‘e stato proprio questo il cloud provider utilizzato.