Resoconto dello stage
3.3. ANALISI DEI REQUISITI 19
Casi d’uso principali
I casi d’uso descrivono le funzionalità di Cloud Backup. Nella lista dei principali use case, riportata di seguito, ognuno di essi è caratterizzato dalle seguenti informazioni:
un codice univoco, nome, lista degli attori, descrizione, precondizione e postcondizione, ovvero le condizioni prima e dopo l’esecuzione della funzionalità rappresentata del caso d’uso.
Caso d’uso UC1: Visualizza lista backup
• Attori: utente autenticato.
• Descrizione: un utente autenticato ha la possibilità di vedere i backup delle sue istanze, sia di Amazon che di Google.
• Precondizione: l’utente ha scelto la funzionalità del sistema per visualizzare i suoi backup.
• Postcondizione: l’utente ha visualizzato una lista dei suoi backup.
Caso d’uso UC2: Gestione scheduler
• Attori: utente autenticato.
• Descrizione: l’utente ha la possibilità di inserire un nuovo scheduler. Uno scheduler, che ha il compito di gestire i backup di un’istanza, è composto da un nome, una descrizione e cicli di ritenzione giornaliero, settimanale e mensile. Per i cicli di ritenzione settimanale e mensile è possibile specificare, rispettivamente, il giorno della settimana e il giorno del mese in cui fare il backup. Inoltre, l’utente può visualizzare, modificare o eliminare gli scheduler precedentemente creati.
• Precondizione: l’utente ha deciso di sfruttare la funzionalità del sistema per gestire gli scheduler.
• Postcondizione: l’utente ha gestito i suoi scheduler.
Caso d’uso UC3: Associa scheduler a istanza
• Attori: utente autenticato.
• Descrizione: l’utente ha la possibilità di associare uno scheduler a un’istanza.
A questo punto, lo scheduler gestisce i backup delle istanze in trasparenza, senza che l’utente si preoccupi della gestione tramite console.
• Precondizione: l’utente ha scelto la funzionalità del sistema per poter associare uno scheduler ad un’istanza.
• Postcondizione: l’utente ha associato un’istanza allo scheduler.
20 CAPITOLO 3. RESOCONTO DELLO STAGE Caso d’uso UC4: Gestisci i backup delle istanze
• Attori: time
• Descrizione: time causa l’avvio della gestione dei backup delle istanze secondo le caratteristiche dello scheduler a cui è associata. Se il numero di backup è maggiore della lunghezza del ciclo di ritenzione, viene eliminato il backup più datato per lasciare spazio a quello più recente (secondo la politica FIFO).
• Precondizione: l’utente ha creato degli scheduler e gli ha associato delle istanze da manutenere.
• Postcondizione: il sistema ha gestito i backup delle istanze.
Caso d’uso UC5: Errore gestione backup
• Attori: time
• Descrizione: time causa l’avvio della gestione dei backup delle istanze secondo le caratteristiche dello scheduler a cui è associata. Si potrebbero presentare delle situazioni che possono generare degli errori. Il sistema è in grado di gestire le seguenti situazioni anomale: mancano le credenziali del provider perchè l’utente non le ha ancora inserite, le credenziali non sono valide oppure esse non hanno sufficienti permessi per permettere al sistema di gestire le istanze.
• Precondizione: l’utente ha creato degli scheduler e gli ha associato delle istanze da manutenere.
• Postcondizione: si sono verificati dei problemi durante la gestione dei backup.
Il sistema notifica l’errore all’utente.
• Estensioni: UC4 - Gestisci i backup delle istanze.
Caso d’uso UC6: Gestisci i backup delle istanze AWS
• Attori: time
• Descrizione: time causa l’avvio della gestione dei backup delle istanze secondo le caratteristiche dello scheduler a cui è associata. Se il numero di backup è maggiore della lunghezza del ciclo di ritenzione, viene eliminato il backup più datato per lasciare spazio a quello più recente. In questo use case il sistema si interfaccia con AWS, sfruttando le credenziali (access key e secret key) inserite dall’utente.
• Precondizione: l’utente ha creato degli scheduler e gli ha associato delle istanze da manutenere. Inoltre, l’utente ha inserito access key e secret key valide e con sufficienti permessi per gestire istanze e backup.
• Postcondizione: il sistema ha gestito i backup delle istanze.
3.4. PROGETTAZIONE 21 Caso d’uso UC7: Gestisci i backup delle istanze Google Cloud Platform
• Attori: time
• Descrizione: time causa l’avvio della gestione dei backup delle istanze secondo le caratteristiche dello scheduler a cui è associata. Se il numero di backup è maggiore della lunghezza del ciclo di ritenzione, viene eliminato il backup più datato per lasciare spazio a quello più recente. In questo use case il sistema si interfaccia con Google Cloud Platform, sfruttando le credenziali (client id, client secret e refresh token) inserite dall’utente.
• Precondizione: l’utente ha creato degli scheduler e gli ha associato delle istanze da manutenere. Inoltre, l’utente ha inserito client id, client secret e refresh token validi e con sufficienti permessi per gestire istanze e backup.
• Postcondizione: il sistema ha gestito i backup delle istanze.
3.4 Progettazione
3.4.1 Architettura
Ho progettato un’architettura multi-tier con lo scopo di separare le funzionalità del software in più strati (o livelli) in comunicazione tra loro. Questo tipo di architettura può essere visto come una pila in cui la comunicazione è possibile solamente tra livelli adiacenti. I vantaggi ottenuti nell’adottare questo tipo di architettura sono la facilità di estensione, manutenzione e testabilità dell’applicazione realizzata. Ho individuato i seguenti livelli (elencati dalla cima della pila verso il fondo), ciascuno rappresentante un package a livello logico: front-end, controller, business logic e persistenza dei dati.
I livelli adicenti comunciano tra di loro scambiandosi degli oggetti; poichè Java è un linguaggio fortemente tipizzato, tali devono essere rappresentati da una classe. A questo scopo ho definito dei package ciascuno dei quali si occupa di rappresentare una classe di oggetti scambiati tra gli strati della pila. Ho definito un package DTO per rappresentare gli oggetti ricevuti o inviati dal controller al client, all’interno del body della richiesta e della risposta HTTP, e passati al livello business logic per poter essere elaborati. Per la comunicazione tra business logic e persistenza dei da-ti ho definito un package enda-tity le cui classi reppresentano gli oggetda-ti salvada-ti del database.
L’architettura progettata, oltre ad essere multi-tier, aderisce ai principi REST: la comunicazione tra front-end e back-end avviene tramite protocollo HTTP e il formato del body delle richieste e delle risposte è JavaScript Object Notation (JSON). Inoltre, l’applicazione realizzata è stateless: nessuna informazione sulla sessione del client viene salvata nel back-end. Questo significa che ogni richiesta HTTP è indipendente dalle altre e ognuna di esse deve fornire tutte le informazioni necessarie al back-end affinchè quest’ultimo possa elaborarla. Queste informazioni, che comprendono il token di autenticazione, vengono salvate a livello di front-end.
22 CAPITOLO 3. RESOCONTO DELLO STAGE
Figura 3.5: Architettura
Ho definito un package, a livello di back-end, che gestisce le istanze in cloud con dei thread che vengono programmati ed eseguiti ogni giorno, secondo le politiche degli scheduler definiti dall’utente. Lo scopo di un thread è quello di creare il backup di un’istanza e, eventualmente, eliminare quello più datato.
3.4.2 Dependency Injection
Ho utilizzato la Dependency Injection per garantire una più semplice manutenibilità e testabilità del codice. Quello che bisogna fare per applicare questo design pattern è dichiarare le dipendenze di cui una componente ha bisogno. Quando questa componente verrà istanziata, un injector si prenderà carico di risolvere le sue dipendenze, iniettando un’istanza della classe che è stata specificata come dipendenza.
Questo modo di operare effettua un’inversione di controllo rispetto al tipico pattern visto per la programmazione procedurale. Consideriamo una classe A che è composta da un attributo di una classe B. Con un approccio procedurale, una classe A dovrebbe istanziare, durante la sua creazione, un oggetto di tipo B. Adoperarando la Dependency Injection, specificando la classe B tra le dipendenze della classe A, viene iniettato in quest’ultima un’istanza di B: si verifica un’inversione di controllo in quanto la classe B viene istanziata prima della classe A. Nel mio progetto di stage, l’inversione di controllo si traduce nell’iniettare le componenti dei livelli più bassi della pila progettata nelle componenti dei livelli più alti.
Questo modo di operare rende il codice anche facilmente testabile, in particolare, a livello di unità. Infatti, è possibile simulare il comportamento di una dipendenza tramite l’utilizzo di uno stub il quale sarà iniettato al suo posto. Ho deciso di adoperare questo design pattern anche per facilitare l’aggiunta di test a Miriade, che ha l’abitudine di definire delle suite di test automatici per i suoi progetti.
3.4. PROGETTAZIONE 23
Figura 3.6: Test di unità
3.4.3 Back-end
Controller
Lo scopo dei controller è quello di offrire degli end-point a cui il front-end farà delle richieste HTTP. Ogni end-point soddisfa le funzionalità che l’azienda mi ha chiesto di sviluppare durante le riunioni fatte con il tutor aziendale e un sistemista dell’azienda.
Ho definito i seguenti end-point REST:
• POST /login: permette di effettuare il login in Cloud Backup inserendo nel body delle richiesta la email e la password. Se le credenziali sono corrette allora il back-end risponde con un token di autenticazione che dovrà essere specificato come header nelle successive richiste;
• POST /keys: permette ad un utente di inserire le proprie credenziali. All’interno del body della richiesta deve essere specificato il provider a cui fanno riferimento le credenziali;
• PUT /keys/{provider}: permette ad un utente di aggiornare le credenziali del provider specificato;
• DELETE /keys/{provider}: permette ad un utente di eliminare le credenziali del provider specificato;
• GET /backups: permette ad un utente di ricevere una lista (eventualmente vuota) di tutti i suoi backup;
• GET /backups/{provider}: permette ad un utente di ricevere una lista di tutti i backup appartenenti al provider specificato;
• GET /backups/{provider}/{backup_id}: permette ad un utente di ricevere le informazioni del backup con l’id specificato e appartanente al provider indicato nel path della richiesta;
• GET /schedulers: permette ad un utente di ricevere una lista (eventualmente vuota) di tutti i suoi scheduler ;
• POST /schedulers: permette ad un utente di inserire un nuovo scheduler ;
24 CAPITOLO 3. RESOCONTO DELLO STAGE
• GET /schedulers/{scheduler_id}: permette ad un utente di ricevere tutte le informazioni di uno scheduler (nome, descrizione, cicli di ritenzione);
• PUT /schedulers/{scheduler_id}: permette di aggiornare le caratteristiche di uno scheduler ;
• DELETE /schedulers/{scheduler_id}: permette ad un utente di eliminare uno scheduler ;
• GET /schedulers/{scheduler_id}/instances: permette ad un utente di avere una lista (eventualmente vuota) delle istanze manutenute dallo scheduler con l’id specificato nel path della richiesta. Viene anche ritornata una lista, per ogni istanza, degli id dei backup creati dallo scheduler ;
• POST /schedulers/{scheduler_id}/instances: permette ad un utente di associare un’istanza ad uno scheduler affinchè quest’ultimo possa gestirne i backup;
• GET /schedulers/{scheduler_id}/instances/{provider}/{instance_id}: permette ad un utente di ricevere le informazioni dell’istanza associata allo scheduler e una lista (eventualmente vuota) degli id dei backup che lo scheduler ha fatto dell’istanza stessa;
• DELETE /schedulers/{scheduler_id}/instances/{provider}/{instance_id}: un utente può eliminare l’associazione tra scheduler e istanza.
Figura 3.7: Richiesta HTTP per effettuare il login
Figura 3.8: Richiesta HTTP per visualizzare la lista dei backup
3.4. PROGETTAZIONE 25