Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica
Sviluppo di un’interfaccia per dispositivi
Android al software di monitoraggio Nagios
Tesi di laurea triennale
Relatore: Laureando:
Prof. Silvia Crafa Agostino La Bruna
Anno Accademico 2014-2015Indice
1 Introduzione 1
1.1 Scopo dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Pianificazione dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Ciclo di vita del software . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Studio del dominio 3
2.1 Dominio applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Software esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Dominio tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Analisi dei requisiti 7
3.1 Descrizione generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 UCG: Scenario principale . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 UC1: Inserimento di un nuovo profilo . . . . . . . . . . . . . . 8
3.2.3 UC1: Visualizzazione di un profilo . . . . . . . . . . . . . . . . 9
3.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Progettazione architetturale 13
4.1 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Viste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.3 Oggetti condivisi . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.4 Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.5 Servizi in background . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Package com.arslogicasistemi.apprise . . . . . . . . . . . . . . . 15
4.2.2 Package com.arslogicasistemi.apprise.adapters . . . . . . . . . . 16
4.2.3 Package com.arslogicasistemi.apprise.dao . . . . . . . . . . . . 17
4.2.4 Package com.arslogicasistemi.apprise.services . . . . . . . . . . 17
4.2.5 Package com.arslogicasistemi.apprise.shared . . . . . . . . . . . 17
4.2.6 Package com.arslogicasistemi.apprise.widget . . . . . . . . . . . 18
4.3 Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 MV* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
iiiiv INDICE
4.3.4 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Strumenti e tecnologie utilizzati . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.2 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Java Development Toolkit (JDK) . . . . . . . . . . . . . . . . . 21
4.4.4 Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.6 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.7 Jsoup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.8 AnimatedExpandableListView . . . . . . . . . . . . . . . . . . 22
4.4.9 Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 API utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Progettazione di dettaglio e codifica 25
5.1 Baseline: progetto e lista dei profili . . . . . . . . . . . . . . . . . . . . 25
5.2 Incremento 1: oggetti condivisi . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Incremento 2: database . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Incremento 3: popolamento della lista dei profili . . . . . . . . . . . . 29
5.5 Incremento 4: impostazioni . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Incremento 5: form per i dati di un profilo . . . . . . . . . . . . . . . . 29
5.7 Incremento 6: servizio in background . . . . . . . . . . . . . . . . . . . 29
5.8 Incremento 7: lista dei dettagli di un profilo . . . . . . . . . . . . . . . 30
5.9 Incremento 8: popolamento della lista dei dettagli di un profilo . . . . 30
5.10 Incremento 9: dettagli di un host o di un servizio . . . . . . . . . . . . 31
5.11 Incremento 10: sommario dello stato degli host e dei servizi . . . . . . 31
5.12 Incremento 11: utilizzo di Volley . . . . . . . . . . . . . . . . . . . . . 31
5.13 Incremento 12: suggerimento di aggiunta di un profilo . . . . . . . . . 32
5.14 Incremento 13: riconoscimento automatico del percorso ai CGI . . . . 32
5.15 Incremento 14: possibilità di nascondere i dettagli . . . . . . . . . . . 32
5.16 Incremento 15: possibilità di scegliere l’ordinamento . . . . . . . . . . 32
5.17 Incremento 16: sommario degli errori . . . . . . . . . . . . . . . . . . . 32
5.18 Incremento 17: Apprise Legacy . . . . . . . . . . . . . . . . . . . . . . 32
6 Verifica e validazione 33
6.1 Test di unità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Test di integrazione e di sistema . . . . . . . . . . . . . . . . . . . . . 33
7 Conclusioni 35
7.1 Consuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Raggiungimento degli obbiettivi . . . . . . . . . . . . . . . . . . . . . . 35
7.3 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Glossario 39
Bibliografia 41Elenco delle figure
3.1 UCG: descrive lo scenario principale e le sue funzionalità . . . . . . . . 8
3.2 UC1: descrive le operazioni relative all’inserimento di un nuovo profilo 9
3.3 UC1: descrive le operazioni relative alla visualizzazione di un profilo . 9
4.1 Un esempio di come due fragment possono essere combinati in una
activity unica se lo schermo è abbastanza grande oppure visualizzati
separatamente su schermi più piccoli. . . . . . . . . . . . . . . . . . . . 14
4.2 Diagramma dei package dell’architettura dell’applicazione. . . . . . . . 15
4.3 Rappresentazione del design pattern DAO. . . . . . . . . . . . . . . . . 18
4.4 Rappresentazione del design pattern Observer. . . . . . . . . . . . . . 19
5.1 La lista dei profili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 La schermata delle impostazioni . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Il form che permette di inserire le informazioni per aggiungere o modifi-
care un profilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 La lista con i dettagli di un profilo . . . . . . . . . . . . . . . . . . . . 30
5.5 La schermata con la visualizzazione dei dettagli . . . . . . . . . . . . . 31
Elenco delle tabelle
3.1 Tabella dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vCapitolo 1
Introduzione
Il seguente documento consiste nella relazione delle attività svolte dal laureando La Bruna
Agostino, sotto la supervisione del tutor aziendale Tosato Marco, durante lo stage presso
ArsLogica Sistemi Srl di Padova. Lo stage ha avuto una durata di 320 ore, svolte presso la
sede Padovana dell’azienda.
1.1 Scopo dello stage
L’obbiettivo dello Stage era quello di sviluppare un’applicazione per dispositivi con
sistema operativo Android che consentisse di visualizzare, in una forma adatta per uno
smartphone o un tablet, le informazioni raccolte dal software di monitoraggio Nagios.
Nagios consente di tenere sotto controllo nodi (host) e servizi, specificati nella sua
configurazione, segnalando quando questi sono in uno stato anormale o critico per lo
svolgimento delle loro funzioni.
In precedenza era già stata sviluppata, presso la stessa azienda, un’applicazione
simile, ma per dispositivi con sistema operativo iOS, quindi la realizzazione di questa
nuova applicazione era necessaria per coprire una grossa fetta di dispositivi, prima non
supportati, aumentando il bacino di utenza possibile.
Poiché esistono molte differenze tra i due sistemi operativi, per la progettazione
non si è usata come base l’applicazione già esistente, ma si è scelto piuttosto di cercare
l’architettura migliore per sfruttare tutte le caratteristiche offerte da Android. Sono
inoltre state tenute in considerazione le esigenze degli utenti che poi andranno ad
utilizzare effettivamente l’applicazione in ambito lavorativo. Ciò è stato possibile grazie
ad un confronto continuo con il tutor aziendale sugli aspetti legati all’esperienza utente
che dovesse offrire il software.
Nonostante le differenze tra le due applicazioni, dato che le funzionalità che devono
offrire sono le medesime, è stato deciso di mantenere la stessa nomenclatura per
entrambe, ovvero Apprise.
1.2 L’azienda
ArsLogica Sistemi ha iniziato ad operare nel Luglio 2005 e successivamente si è costituita
società autonoma nell’Aprile 2006 assumendo la denominazione di ArsLogica Sistemi
Srl. La Sede legale della società è a Padova, tuttavia essa opera sull’intero territorio
nazionale tramite risorse dirette e agenzie locali.
12 CAPITOLO 1. INTRODUZIONE
ArsLogica Sistemi fornisce ai Clienti la consulenza e il supporto necessari per
affrontare la progettazione e l’implementazione di una nuova struttura ICT o il consoli-
damento di quella esistente, la sua gestione totale o parziale, l’integrazione di ambienti
eterogenei, applicazioni e database, l’ottimizzazione e la gestione delle prestazioni dei
sistemi aziendali ed il rinnovamento delle soluzioni applicative aziendali.
1.3 Pianificazione dello stage
Durante la pianificazione dello stage sono state identificate le seguenti attività da
svolgere ed il preventivo delle relative ore lavorative:
• Studio, installazione e configurazione di Nagios (20 ore).
• Installazione e studio del funzionamento del plugin Wolfdog per Nagios (20 ore).
• Analisi del problema (40 ore).
• Progettazione architetturale (40 ore).
• Progettazione di dettaglio e implementazione (168 ore).
• Coordinamento e tutoraggio (32 ore).
Per un totale di 320 ore.
1.4 Ciclo di vita del software
Tra i vari cicli di vita esistenti, per lo sviluppo del software, si è deciso di utilizzare il
modello incrementale. Le caratteristiche principali del modello scelto sono:
• Le attività di analisi e progettazione architetturale ad alto livello sono svolte
solo una volta: dopo che sono stati identificati e fissati completamente i requisiti
macroscopici è possibile definire l’architettura di sistema.
• La attività di progettazione di dettaglio e di codifica vengono ripetute più volte,
tante quanti sono gli incrementi.
Il ciclo di vita incrementale stabilisce una baseline sulla quale ammette aggiunte. Le
funzionalità di base vengono sviluppate durante i primi incrementi e ad ogni ulteriore
incremento vengono aggiunte delle caratteristiche.
Tale modello permetterà di:
• Anticipare insiemi di funzionalità:
– Ogni incremento corrisponde al rilascio di una parte delle funzionalità.
– I requisiti obbligatori, quelli a più alta priorità di realizzazione, vengono
rilasciati per primi.
• Testing più esaustivo:
– Il rilascio iniziale viene utilizzato come prototipo.
– I requisiti obbligatori sono quelli che saranno testati maggiormenteCapitolo 2
Studio del dominio
Al fine di comprendere al meglio il funzionamento e l’architettura di Nagios e le esigenze
degli utilizzatori nella prima parte dello stage si è effettuato uno studio del dominio
applicativo. Per quanto riguarda il dominio tecnologico, invece, non è stato necessario uno
studio in quanto le competenze necessarie erano già state acquisite grazie ai corsi seguiti
durante il percorso di studi e ad un corso, seguito privatamente, sulla programmazione per
dispositivi Android.
2.1 Dominio applicativo
2.1.1 Nagios
Nagios è reperibile in due varianti: Nagios Core, che è Open Source e gratuito, e Nagios
XI che è invece una versione Closed Source e a pagamento. Come riferimento si è
utilizzato Nagios Core nelle sue versioni 4.0.8, in quanto essa è l’ultima disponibile, e
3.2.3, poiché la versione 3 di Nagios è ancora la più diffusa.
Poiché Nagios è installabile unicamente su sistemi operativi Linux ed il computer a
disposizione aveva installato Microsoft Windows 7, grazie al software di virtualizzazione
Oracle VirtualBox è stata creata una macchina virtuale con l’installazione di base di
Ubuntu Server 14.04 e si è proceduto con l’installazione e la configurazione di Nagios
Core 4.0.8.
Questa installazione monitorava due nodi: la macchina virtuale Ubuntu (localhost) e
il notebook che faceva da host per la macchina virtuale, con sistema operativo Windows
7 (winserver). Questa configurazione è stata poi utilizzata anche per collaudare
l’applicazione una volta implementata.
2.1.2 Software esistenti
Per comprendere meglio quali funzionalità e caratteristiche privilegiare nella proget-
tazione dell’applicazione si è svolta un’analisi sia dei pregi che dei difetti di alcuni
software già esistenti con funzioni di interfaccia per dispositivi Android a Nagios. I
software che sono stati presi in considerazione sono i seguenti.
• aNag: è senza dubbio l’applicazione più completa che si possa utilizzare al
momento. I suoi lati positivi sono che consente di aggregare istanze multiple di
Nagios, utilizza le CGI stock di Nagios, effettua il recupero delle informazioni in
34 CAPITOLO 2. STUDIO DEL DOMINIO
background automaticamente, è stata programmata nativamente per Android,
permette di filtrare i servizi monitorati e fornisce un sistema di notifiche. I suoi
difetti sono che vengono visualizzate solo le informazioni riguardo ai problemi
presenti, non è ottimizzata per la visualizzazione su dispositivi con schermi ampi
(tablet), la notifica con le informazioni sullo stato rimane permanentemente e per
visualizzare informazioni dettagliate esce dall’applicazione lanciando un browser.
• jNag: lo svantaggio principale di questa applicazione è che per poter funzionare
necessita dell’installazione di un plugin sull’istanza di Nagios. Non è programmato
nativamente per Android, ma sfrutta HTML e Javascript, il che potrebbe causare
problemi prestazionali. Inoltre, per usufruire di tutte le funzionalità, è necessario
acquistare la versione a pagamento. Di positivo ha la possibilità di scegliere dei
servizi monitorati da mettere in evidenza e la possibilità di eseguire comandi
come, per esempio, l’accettazione di un errore e l’inserimento di commenti.
• NagBag: quest’applicazione è risultata non compatibile con la versione 4 di
Nagios ed inoltre presentava pubblicità al suo interno.
• NagMonDroid (NagiosMonitor): quest’applicazione è sviluppata nativamen-
te per Android, fornisce un sistema di notifiche e di recupero delle informazioni in
background. Presenta dei simboli per indicare in modo chiaro lo stato degli host
e dei servizi, ma tutti i servizi di tutti gli host vengono visualizzati nella stessa
schermata, creando confusione, e le informazioni dettagliate vengono visualizzate
all’esterno dell’applicazione lanciando un browser.
• Nagios+Plus: quest’applicazione è sviluppata nativamente per Android, ma
è utilizzabile solo con il dispositivo orientato in verticale ed inoltre presenta
pubblicità al suo interno.
• TiNag: quest’applicazione è a pagamento e l’interfaccia non sembra essere
pensata per schermi di piccole dimensioni, in quanto gli elementi risultano molto
piccoli e difficili da utilizzare.
• Nagios Mobile e Teeny Nagios: queste non sono applicazioni, ma interfacce
web pensate per dispositivi mobili. Vanno installate sullo stesso server su cui è
installato Nagios e necessitano di PHP per generare dinamicamente i contenuti.
2.2 Dominio tecnologico
Per lo sviluppo dell’applicazione è stata riscontrata la necessità di conoscere le seguenti
tecnologie:
• Java: la programmazione di applicazioni per Android sfrutta la sintassi e gran
parte delle API di Java pur utilizzando un compilatore differente da quello Java
standard.
• Android: per programmare una buona applicazione è fondamentale conoscere
l’architettura del sistema operativo Android ed in particolare la gestione del
ciclo di vita delle applicazioni e dei loro componenti. Oltre a questo è necessario
conoscere le API che sono state sviluppate specificamente per la creazione delle
applicazioni Android e dell’interfaccia utente.2.2. DOMINIO TECNOLOGICO 5
• SQL: Android mette a disposizione per ogni applicazione uno o più database
SQLite per salvare informazioni in modo strutturato.
• HTML: Nagios genera, attraverso i suoi CGI, delle pagine HTML che contengono
le informazioni sugli host e sui servizi. Se non sono stati installati plugins
aggiuntivi fare il parsing di quelle pagine HTML è l’unico modo di recuperare le
informazioni da remoto.Capitolo 3
Analisi dei requisiti
In seguito allo studio del dominio sono stati individuati i casi d’uso ed i requisiti relativi
all’applicazione da sviluppare.
3.1 Descrizione generale
L’applicazione dovrà consentire all’utente di creare uno o più profili, ognuno corrispon-
dente ad un’istanza di Nagios. Ogni profilo sarà identificato da un nome e conterrà
l’URL presso cui è raggiungibile l’istanza di Nagios. Inoltre sarà necessario inserire
l’username e la password per accedere a tale istanza. I profili creati potranno essere
modificati ed eliminati.
Ad intervalli regolari saranno recuperate le informazioni riguardanti ogni profilo
presente nell’applicazione e salvate in una base dati locale. Queste informazioni
verranno usate per popolare le viste dell’applicazione.
Se, nei dati recuperati, viene rilevato un peggioramento dello stato di uno o più host
o servizi l’applicazione avvertirà l’utente tramite il sistema di notifiche di Android.
L’utente potrà scegliere l’intervallo con cui l’applicazione recupererà le informazioni.
Avrà anche a disposizione un pulsante per richiedere manualmente l’aggiornamento
delle informazioni.
Nella pagina principale dell’applicazione verrà visualizzato un elenco con il nome dei
profili presenti sul dispositivo ed un corrispondente simbolo indicante lo stato attuale.
Toccando il riquadro relativo ad un profilo si accede ad una schermata con un
sommario sullo stato degli host e dei servizi di quel profilo, in particolare lo stato più
critico degli host e quello più critico dei servizi verranno indicati da un simbolo. Il
sommario può essere espanso visualizzando le informazioni dettagliate per ogni host e
per ogni servizio.
Sarà inoltre possibile vedere maggiori dettagli a proposito di uno specifico host o
servizio, toccando il relativo riquadro. In questo caso le informazioni saranno recuperate
direttamente da internet invece che dalla base dati locale.
3.2 Casi d’uso
In questo paragrafo vengono descritti i principali casi d’uso rilevati durante l’analisi.
Per chiarezza sono stati inseriti dei diagrammi di tipo UML dedicati alla descrizione di
78 CAPITOLO 3. ANALISI DEI REQUISITI
tali casi d’uso, mentre sono state tralasciate le descrizioni estese dei casi d’uso meno
importanti.
3.2.1 UCG: Scenario principale
figura 3.1: UCG: descrive lo scenario principale e le sue funzionalità
Attori Principali: Utente.
Precondizioni: L’applicazione è stata installata ed avviata. Mostra all’utente una
schermata grafica ed è in attesa che quest’ultimo selezioni una funzionalità.
Descrizione: L’applicazione deve permettere all’utente di gestire i profili (inserimento,
modifica, eliminazione), visualizzare le informazioni sugli host e servizi relativi ad un
profilo, richiedere l’aggiornamento delle informazioni presenti nel database ed impostare
con quale frequenza le informazioni vengono aggiornate automaticamente.
Postcondizioni: Il sistema ha ottenuto le informazioni riguardo all’operazione che
l’utente vuole svolgere.
3.2.2 UC1: Inserimento di un nuovo profilo
Attori Principali: Utente.
Precondizioni: L’applicazione visualizza un form per l’inserimento dei dati relativi
al profilo che si vuole aggiungere.
Descrizione: L’applicazione deve consentire all’utente di immettere il nome del nuovo3.2. CASI D’USO 9
Apprise
Condizione: nome già presente
+UC1.1
UC1.1 Inserimento nome
«extend»
UC1.5 Visualizzazione messaggio di errore
+UC1.2 «extend»
UC1.2 Inserimento URL
Utente
+UC1.3 Condizione: URL non valido
UC1.3 Inserimento username
+UC1.4
UC1.4 Inserimento password
figura 3.2: UC1: descrive le operazioni relative all’inserimento di un nuovo profilo
profilo, l’URL a cui sarà possibile reperire l’istanza di Nagios e le credenziali per
accedervi.
Postcondizioni: L’applicazione ha salvato le informazioni inserite.
Scenari Alternativi: Se il nome del profilo è già esistente oppure se l’URL inserito
non è valido l’applicazione mostrerà all’utente un messaggio di errore.
3.2.3 UC1: Visualizzazione di un profilo
Apprise
+UC4.1
UC4.1 Visualizzazione elenco host
+UC4.2
Utente UC4.2 Visualizzazione elenco servizi
figura 3.3: UC1: descrive le operazioni relative alla visualizzazione di un profilo
Attori Principali: Utente.
Precondizioni: L’applicazione visualizza un sommario dello stato degli host e dei
servizi relativi al profilo selezionato.
Descrizione: L’applicazione deve consentire all’utente di visualizzare l’elenco di tutti
gli host e l’elenco di tutti i servizi con i relativi stati.10 CAPITOLO 3. ANALISI DEI REQUISITI
Postcondizioni: L’applicazione sta mostrando le informazioni richieste dall’utente.
3.3 Requisiti
Dall’analisi del dominio e degli use case sono stati individuati diversi tipi di requisiti
ai quali è stato assegnato un codice identificativo ed un numero progressivo.
I requisiti sono stati suddivisi in base all’ambito (generale, utente), in base al
tipo di requisito (funzionale, di qualità, di vincolo) ed in base al grado di priorità di
realizzazione (obbligatorio, desiderabile, opzionale).
Il codice dei requisiti è quindi così strutturato R(G/U)(F/Q/V)(O/D/F) dove:
R = requisito
G = generale
U = utente
F = funzionale
Q = di qualità
V = di vincolo
O = obbligatorio
D = desiderabile
F = opzionale (facoltativo)
Tali requisiti sono stati inseriti, come issues, nel sistema di tracciamento associato
al repository usato per il controllo di versione, in modo da avere un collegamento tra i
progressi fatti con la codifica ed i requisiti.
Requisito Descrizione
RGVO 1 L’applicazione non deve richiedere l’installazione di plugins aggiuntivi
sull’istanza di Nagios
RGQO 2 L’applicazione deve supportare un layout a più pannelli dinamico per
adattarsi a schermi di dimensioni diverse
RGVO 3 L’applicazione dev’essere compatibile con Nagios Core
RGFD 3.1 L’applicazione deve recuperare automaticamente la locazione dei file
CGI dell’istanza di Nagios
RGVD 4 L’applicazione deve supportare lo standard JSON per recuperare le
informazioni
RGFD 5 L’applicazione deve rendere disponibile un widget
RGFD 5.1 Il widget deve mostrare un sommario dello stato di tutti i profili
RGFO 6 L’applicazione segnala all’utente quando viene rilevato un problema
riguardante un host o un servizio
RGVO 6.1 L’applicazione usa il sistema di notifiche di Android per le segnalazioni
di errori o avvertimenti
RUFO 7 L’applicazione deve visualizzare un elenco dei profili salvati
RUFO 7.1 L’applicazione deve visualizzare lo stato dei profili salvati3.3. REQUISITI 11
Requisito Descrizione
RUFF 7.2 L’applicazione deve permettere all’utente di impostare un host come
"preferito"
RUFF 7.3 L’applicazione deve visualizzare anche gli host segnati come "preferiti"
nell’elenco dei profili
RGFO 8 L’applicazione deve recuperare automaticamente le informazioni ad
intervalli regolari
RUFO 8.1 L’applicazione deve permettere all’utente di scegliere la frequenza di
aggiornamento automatico delle informazioni
RUFD 9 L’applicazione deve visualizzare un sommario dei problemi rilevati
negli host e nei servizi di un profilo
RGVF 10 L’applicazione dev’essere compatibile con Icinga1
RUQD 11 Se nessun profilo è presente l’applicazione deve mostrare un messaggio
che suggerisca all’utente di crearne uno nuovo
RGQO 12 Le credenziali di accesso alle istanze di Nagios devono essere salvate
in maniera criptata
RGFO 13 L’applicazione deve usare un database locale per salvare i dati
RGFO 13.1 Le informazioni riguardanti i profili devono essere salvate nel database
locale
RGFO 13.2 Le principali informazioni riguardanti gli host devono essere salvate
nel database locale
RGFO 13.3 Le principali informazioni riguardanti i servizi devono essere salvate
nel database locale
RGVD 14 L’applicazione deve usare la libreria Volley2 per recuperare i dati da
internet
RUFO 15 L’applicazione deve permettere all’utente di inserire un nuovo profilo
RUFO 15.1 Il modulo di aggiunta di un nuovo profilo deve richiedere di inserire
un nome non ancora utilizzato da altri profili
RUFO 15.2 Il modulo di aggiunta di un nuovo profilo deve richiedere di inserire
un URL presso cui sia reperibile un’istanza di Nagios
RUFO 15.3 Il modulo di aggiunta di un nuovo profilo deve richiedere di inserire
l’username che permette di accedere all’istanza di Nagios
RUFO 15.4 Il modulo di aggiunta di un nuovo profilo deve richiedere di inserire
la password che permette di accedere all’istanza di Nagios
RGVD 16 L’applicazione dev’essere in grado di ricevere notifiche push
RUQO 17 L’applicazione deve mostrare un messaggio di avvertimento nel caso
in cui non sia disponibile la connessione di rete
RGFF 18 L’applicazione deve permettere di effettuare una ricerca al proprio
interno
RUFD 19 L’applicazione deve permettere all’utente di scegliere di nascondere i
dettagli sullo stato di host o servizi che non presentano problemi
RUFD 20 L’applicazione deve permettere all’utente di scegliere il tipo di
raggruppamento degli host e dei servizi relativi ad un profilo
RGFF 21 L’applicazione deve rendere disponibile una versione per dispositivi
con sistema operativo Android Wear
RUFO 22 L’applicazione deve permettere all’utente di modificare un profilo
esistente
RUFO 22.1 Il modulo di modifica di un profilo deve permettere di inserire un
nome non ancora utilizzato da altri profili
1 Icinga è un altro software di monitoring che è stato sviluppato a partire da un fork di Nagios.
2 Volley è una libreria che gestisce le connessioni e le richieste di rete in modo ottimizzato per
dispositivi con sistema operativo Android12 CAPITOLO 3. ANALISI DEI REQUISITI
Requisito Descrizione
RUFO 22.2 Il modulo di modifica di un profilo deve permettere di inserire un
URL presso cui sia reperibile un’istanza di Nagios
RUFO 22.3 Il modulo di modifica di un profilo deve permettere di inserire
l’username che permette di accedere all’istanza di Nagios
RUFO 22.4 Il modulo di modifica di un profilo deve permettere di inserire la
password che permette di accedere all’istanza di Nagios
RUFO 23 L’applicazione deve permettere all’utente di eliminare un profilo
esistente
RUQO 24 L’applicazione deve segnalare all’utente se non è riuscita ad aggiornare
le informazioni
RUFO 25 L’applicazione deve permettere all’utente di visualizzare i dettagli
relativi ad un host
RUFO 26 L’applicazione deve permettere all’utente di visualizzare i dettagli
relativi ad un servizio
RUFD 27 L’applicazione deve mostrare una schermata di riepilogo di tutti gli
errori presenti in tutti i profili
tabella 3.1: Tabella dei requisitiCapitolo 4
Progettazione architetturale
In questo capitolo verranno descritte le principali scelte progettuali derivate da quanto
appreso durante lo studio del dominio e l’analisi dei requisiti.
4.1 Componenti
4.1.1 Viste
Per visualizzare le informazioni e le funzionalità disponibili è necessario che l’applicazio-
ne abbia un’interfaccia grafica. Le API di Android mettono a disposizione un sistema
che è composto da una cosiddetta activity, che contiene i metodi relativi alla gestione
dell’interfaccia grafica e un file XML che contiene la descrizione del vero e proprio
layout della vista. Per rendere più flessibile e dinamica la gestione dell’interfaccia
grafica a partire dalle API Level 11 sono stati introdotti i fragment, ovvero dei moduli
di interfaccia grafica che possono essere composti dalle activity in modo da adattarla
al meglio a schermi di dimensioni differenti.
Le viste necessarie saranno quindi:
• Una schermata principale, con la lista dei profili.
• Una schermata con i dettagli di un profilo.
• Una schermata con i dettagli di un host o un servizio.
• Una schermata per inserire o modificare i dati di un profilo.
• Una schermata per impostare la frequenza di aggiornamento automatico.
Siccome la lista dei profili ha una larghezza ridotta, nel caso di visualizzazione su
uno schermo ampio, si può affiancare ai dettagli del profilo selezionato, sfruttando il
meccanismo dei fragment ed ottimizzando l’interfaccia grafica.
4.1.2 Database
Le API di Android offrono varie possibilità di salvare dati sul dispositivo. Dato che
le informazioni riguardanti gli host, i servizi e i profili sono rigidamente strutturate e
che un singolo profilo può contenere anche centinaia di host e di servizi è stato scelto
di sfruttare il database SQLite messo a disposizione dal sistema operativo. Questo
1314 CAPITOLO 4. PROGETTAZIONE ARCHITETTURALE
figura 4.1: Un esempio di come due fragment possono essere combinati in una activity unica
se lo schermo è abbastanza grande oppure visualizzati separatamente su schermi
più piccoli.
comporta una maggiore complessità dell’applicazione, ma garantisce robustezza e buone
prestazioni.
Per disaccoppiare il database dall’applicazione, in modo da renderla maggiormente
manutenibile ed estensibile, è stato deciso di usare il design pattern DAO. Questo
porta benefici anche per l’implementazione, in quanto non sarà necessario usare per
ogni operazione sul database la sintassi SQL, ma si utilizzeranno i metodi del DAO
rendendo il codice più leggibile e meno soggetto ad errori.
4.1.3 Oggetti condivisi
Al fine di aggregare i dati e di agevolare il loro trasferimento tra le classi dell’applicazione
è stato deciso di utilizzare oggetti condivisi. Questi oggetti rappresentano un singolo
profilo, host o servizio e contengono semplicemente i campi dati per contenere le
informazioni della realtà modellata, i metodi per estrarre queste informazioni ed un
costruttore, ma si rivelano molto utili per evitare il proliferare di variabili.
4.1.4 Adapters
Le API di Android consentono di popolare automaticamente l’interfaccia grafica con i
dati presenti nel database grazie al meccanismo degli adapter. Questo garantisce buone
prestazioni e una gestione ottimale della memoria. Tuttavia gli adapter disponibili
nelle API Android non fornivano tutte le caratteristiche per visualizzare le liste nel
modo desiderato, pertanto è stato deciso di sviluppare due adapter personalizzati per
popolare in modo corretto la lista dei profili e le liste degli host e dei servizi.
4.1.5 Servizi in background
Per recuperare le informazioni da internet è stato deciso di sviluppare un servizio che
venga svolto in background ed in un thread separato rispetto all’interfaccia grafica.4.2. ARCHITETTURA 15
In questo modo si evitano rallentamenti durante l’esecuzione e non è necessario che
l’applicazione sia in esecuzione perché i dati vengano recuperati.
4.2 Architettura
com.arslogicasistemi.apprise
services
EditProfileActivity
FetchIntentService
DetailsActivity
SettingsActivity ProfileListActivity ProfileDetailActivity
DetailsFragment
SettingsFragment
ProfileListFragment ProfileDetailFragment
adapters widget HostDetailFragment
ProfileAdapter DetailListAdapter AnimatedExpandableListView
ServiceDetailFragment
dao
shared
HostDaoSQL ProfileDaoSQL
NagiosObject
ProfileDao Profile
ObjectDao ServiceDaoSQL
SQLIteHelper
Service
Enums
SQLContract Host
figura 4.2: Diagramma dei package dell’architettura dell’applicazione.
4.2.1 Package com.arslogicasistemi.apprise
Questo è il package principale, che comprende tutti i package e le classi dell’appli-
cazione. Il suo nome è espressamente richiesto che sia in questa forma dal kit di
sviluppo di Android, ovvero che sia formato da un nome di dominio valido e dal
nome dell’applicazione. Il nome del package identifica anche l’applicazione in caso di
pubblicazione su Google Play Store.
Questo package contiene direttamente le classi relative all’interfaccia grafica, ovvero
• ProfileListActivity: questa è l’activity principale, che viene lanciata all’avvio
dell’applicazione. Contiene il fragment con la lista dei profili e, se lo schermo del
dispositivo è ampio, anche il fragment con i dettagli sul profilo.
• ProfileListFragment: questo è il fragment che contiene la lista dei profili
presenti nel database.16 CAPITOLO 4. PROGETTAZIONE ARCHITETTURALE
• ProfileDetailActivity: questa è l’activity che, se lo schermo del dispositivo è
di dimensioni ridotte, contiene il fragment con i dettagli del profilo.
• ProfileDetailFragment: questo è il fragment che contiene i dettagli del pro-
filo, ovvero una lista con due voci: "Host" e "Servizi". Queste voci possono
essere espanse mostrando l’elenco di tutti gli host e di tutti i servizi del profilo
selezionato.
• DetailsActivity: questa activity contiene il fragment con i dettagli di un host o
di un servizio. Pur non essendo necessario un adattamento dinamico a seconda del
dispositivo è stato deciso di implementare comunque il meccanismo del fragment
per garantire una maggiore modularità.
• DetailsFragment: questa classe astratta è la classe base da cui derivano il
fragment che visualizza i dettagli di un host ed il fragment che visualizza i
dettagli di un servizio.
• HostDetailFragment: questo fragment estende DetailsFragment e visualizza i
dettagli di un host.
• ServiceDetailFragment: questo fragment estende DetailsFragment e visualiz-
za i dettagli di un servizio.
• SettingsActivity: questa activity contiene il fragment che visualizza le impo-
stazioni. Pur non essendo necessario un adattamento dinamico a seconda del
dispositivo è stato deciso di implementare comunque il meccanismo del fragment
per garantire una maggior modularità.
• SettingsFragment: questo fragment visualizza gli elementi grafici per scegliere
la frequenza di aggiornamento delle informazioni.
• EditProfileActivity: questa activity visualizza il form per l’inserimento delle
informazioni di un profilo. A differenza degli altri casi per questa activity non è
stato implementato un fragment collegato perché non si ritiene che sarà oggetto
di espansioni.
Tutte le classi *Activity derivano, direttamente o indirettamente, dalla classe
Activity delle librerie di Android.
Tutte le classi *Fragment derivano, direttamente o indirettamente, dalla classe
Fragment delle librerie di Android.
4.2.2 Package com.arslogicasistemi.apprise.adapters
Questo package comprende i due adapter personalizzati per il popolamento delle viste.
• DetailsListAdapter: questa classe estende AnimatedExpandableListAdapter
che è una classe interna di AnimatedExpandableListView. Si occupa di popolare
la lista espandibile di ProfileDetailFragment con i dati presenti nel database.
In particolare controlla qual è lo stato più critico degli host del profilo selezionato e
assegna un simbolo rappresentativo alla voce "Host", poi procede in modo analogo
per la voce "Servizi" in modo che si abbia un sommario della situazione. Carica
anche l’elenco di tutti gli host ed i servizi, con un sommario delle informazioni
più importanti per ciascuno. Inoltre se l’utente decide di espandere una delle due
voci o entrambe fa visualizzare anche questo elenco.4.2. ARCHITETTURA 17
• ProfileAdapter: questa classe si occupa di popolare la lista di ProfileListFragment
con i dati presenti nel database. In particolare, per ogni profilo, controlla qual è
lo stato peggiore di tutti gli host e servizi ed assegna un simbolo rappresentativo.
4.2.3 Package com.arslogicasistemi.apprise.dao
Questo package comprende tutte le classi che servono a comunicare con il database.
• ObjectDao: questa interfaccia contiene i metodi per eseguire operazioni sul
database che coinvolgono i dati degli host e dei servizi.
• HostDaoSQL: questa classe estende ObjectDao e fornisce l’implementazione dei
metodi per eseguire sul database operazioni riguardanti i dati degli host.
• ServiceDaoSQL: questa classe estende ObjectDao e fornisce l’implementazione
dei metodi per eseguire sul database operazioni riguardanti i dati dei servizi.
• ProfileDao: questa interfaccia contiene i metodi per eseguire operazioni sul
database che coinvolgono i dati dei profili.
• ProfileDaoSQL: questa classe estende ProfileDao e fornisce l’implementazione
dei metodi per eseguire sul database operazioni riguardanti i dati dei profili.
• SQLContract: come consigliato dalle linee guida per lo sviluppo di applicazioni
Android, questa classe specifica in maniera esplicita l’organizzazione del database
SQL in maniera sistematica e documentata.
• SQLiteHelper: questa classe estende la classe SQLiteOpenHelper delle librerie di
Android. Fornisce i metodi per ottenere accesso al database in lettura o scrittura
in modo da garantire che le operazioni più onerose, come quelle di creazione e
aggiornamento del database, non influiscano sulle performance dell’applicazione.
4.2.4 Package com.arslogicasistemi.apprise.services
Questo package contiene la classe che implementa il servizio che recupera i dati in
background.
• FetchingIntentService: questa classe estende la classe IntentService delle
librerie di Android. Contiene i metodi che si collegano ad un’istanza di Nagios,
scaricano le pagine HTML che contengono le informazioni sullo stato degli host
e dei servizi di quell’istanza, fanno il parsing dei contenuti ed aggiornano il
database. Inoltre questa classe si occupa di controllare se ci sono nuovi problemi
sugli host e sui servizi e, in caso ne rilevi, avvisa l’utente attraverso il sistema di
notifiche del sistema operativo.
4.2.5 Package com.arslogicasistemi.apprise.shared
Questo package contiene le classi che servono per condividere le informazioni su profili,
host e servizi fra le varie classi dell’applicazione.
• NagiosObject: questa classe contiene le informazioni in comune tra host e servizi.
• Host: questa classe estende NagiosObject e contiene le informazioni di un host.18 CAPITOLO 4. PROGETTAZIONE ARCHITETTURALE
• Service: questa classe estende NagiosObject e contiene le informazioni di un
servizio.
• Profile: questa classe contiene le informazioni di un profilo.
• Enums: questa classe contiene i tipi enumerazione per gli stati dei profili, degli
host e dei servizi.
4.2.6 Package com.arslogicasistemi.apprise.widget
Questo package contiene la classe che implementa un widget utilizzato nel layout
dell’applicazione.
• AnimatedExpandableListView: questa classe viene utilizzata sotto la licenza
Apache versione 2. Implementa una lista espandibile animata che verrà uti-
lizzata da ProfileDetailFragment. Inoltre contiene una classe interna che
implementa un adapter per il popolamento della lista e che verrà utilizzato da
DetailListAdapter come classe base.
4.3 Design Pattern
In questa sezione verranno brevemente descritti i design pattern che sono stati
individuati durante la progettazione.
4.3.1 DAO
dao
HostDaoSQL ProfileDaoSQL
ProfileDao
ObjectDao ServiceDaoSQL
SQLIteHelper
figura 4.3: Rappresentazione del design pattern DAO.
• Descrizione: tale design pattern si occupa di creare un’interfaccia di accesso alla
base di dati e adatta l’implementazione di tale interfaccia al database utilizzato.4.3. DESIGN PATTERN 19
• Motivazione: questo design pattern verrà utilizzato per accedere al database
ed effettuare operazioni su di esso, disaccoppiando la logica di business da quella
di accesso ai dati.
4.3.2 MV*
• Descrizione: tale design pattern deriva da MVC e MVP con la differenza che
le funzioni di controller/presenter sono integrate nella view.
– Model: rappresenta le informazioni di cui necessita l’applicazione. Consiste
nel database e nelle classi del package dao.
– View: contiene i metodi per visualizzare l’interfaccia grafica, composta dalle
informazioni richieste, e per la creazione ed assegnazione di eventi. Consiste
nelle classi *Activity e *Fragment.
– Layout: sono file XML che rappresentano il layout della view.
• Motivazione: questo pattern verrà utilizzato in quanto è quello utilizzato dalle
librerie di Android.
4.3.3 Observer
figura 4.4: Rappresentazione del design pattern Observer.
• Descrizione: tale design pattern definisce la struttura che consente agli oggetti
di una classe di "osservare" altri oggetti delle classi soggette a controlli. Inoltre,20 CAPITOLO 4. PROGETTAZIONE ARCHITETTURALE
permette l’aggiornamento degli oggetti osservatori quando lo stato di un oggetto
soggetto viene modificato
• Motivazione: questo design pattern riflette in tempo reale sui dati visibili
all’utente qualsiasi modifica avvenga sui dati presenti nel database, indipendente
dal numero di oggetti dipendenti, mantenendo un alto livello di consistenza fra
classi correlate, e contemporaneamente cercando di tenere il più basso possibile
il livello di accoppiamento. Questo design pattern è in parte già implementato
dalle librerie di Android.
4.3.4 Singleton
• Descrizione: tale design pattern assicura la presenza di un’unica istanza della
classe e fornisce un punto d’accesso globale a tale istanza, tramite costruttore
privato e puntatore alla classe stessa.
• Motivazione: questo design pattern verrà utilizzato al fine di garantire la
presenza di un’unica istanza delle classi del package dao.
4.4 Strumenti e tecnologie utilizzati
4.4.1 Android SDK
Fornisce le librerie API e gli strumenti di sviluppo necessari per compilare, testare ed
eseguire il debug di applicazioni per il sistema operativo Android.
In particolare comprende i seguenti strumenti:
• SDK Manager: consente di scaricare e mantenere aggiornate le varie versioni
delle librerie API di Android, dei file immagine per l’emulatore e degli strumenti
collegati.
• Emulator: consente di eseguire dispositivi Android virtuali per eseguire il testing
ed il debug delle applicazioni.
• AVD Manager: consente di creare e gestire i dispositivi virtuali utilizzati
dall’emulatore.
• Android Debug Bridge (ADB): consente di comunicare con un’istanza
dell’emulatore o con un dispositivo Android fisico collegato al computer.
• Device Monitor: fornisce un’interfaccia grafica a svariati strumenti per il debug
e l’analisi di applicazioni Android.
4.4.2 Android Studio
È un’IDE sviluppata da Google in collaborazione con IntelliJ dedicata allo sviluppo
di applicazioni Android. Rispetto ad Eclipse ADT, che storicamente è stato l’unico
software che si integrasse con il kit di sviluppo Android, offre:
• un sistema di configurazione basato su Gradle;
• il completamento automatico del codice focalizzato sullo sviluppo per Android;4.4. STRUMENTI E TECNOLOGIE UTILIZZATI 21
• un editor grafico avanzato per l’interfaccia grafica delle applicazioni;
• la segnalazione nell’editor testuale di istruzioni che possano essere fonte di
problemi di performance, usabilità e compatibilità.
4.4.3 Java Development Toolkit (JDK)
Questo kit di sviluppo è richiesto in quanto Java è stato scelto dagli sviluppatori di
Android come linguaggio per l’implementazione di applicazioni. Esso fornisce, oltre
all’ambiente di esecuzione, tutti gli strumenti per lo sviluppo ed il debug di applicazioni
Java.
4.4.4 Gradle
È uno strumento che consente di gestire e automatizzare la configurazione (build), il
testing, la pubblicazione ed il rilascio di pacchetti software ed altri progetti.
Viene utilizzato da Android Studio per la configurazione delle applicazioni sviluppate
con esso.
4.4.5 Maven
È uno strumento per la gestione di progetti software. Effettua automaticamente il
download di librerie, scaricandoli in locale o in un repository centralizzato. Questo
permette di recuperare in modo uniforme i vari file e di poter spostare il progetto
indipendentemente da un ambiente all’altro avendo la sicurezza di utilizzare sempre le
stesse versioni delle librerie.
Viene utilizzato da Gradle per la gestione automatica delle dipendenze.
4.4.6 SQLite
È una libreria che implementa un DBMS relazionale rispettando lo standard SQL. A
differenza di altri gestori di database che utilizzano l’architettura client-server, SQLite
è incluso nel programma che lo utilizza e non fa uso di un processo a sé stante.
Verrà utilizzato per implementare un database che contenga tutte le informazioni
riguardanti i profili, gli host ed i servizi.
4.4.7 Jsoup
È una libreria Java che fornisce le API per estrarre e manipolare dati da pagine HTML,
sfruttando il loro DOM, il CSS presente ed interrogazioni con una sintassi simile a
Jquery. È stato progettato per trattare correttamente sia le pagine HTML valide che
quelle invalide e disordinate.
Consente di:
• fare il parsing di una pagina HTML da un URL, un file o una stringa;
• trovare ed estrarre dati, scorrendo il DOM o utilizzando i selettori CSS;
• manipolare gli elementi HTML, i loro attributi ed il testo;
• eseguire una pulizia del codice HTML per prevenire attacchi;
• ottenere HTML ordinato e ben formato.22 CAPITOLO 4. PROGETTAZIONE ARCHITETTURALE
Verrà utilizzato per estrarre le informazioni sugli host ed i servizi dalle pagine
HTML generate da Nagios.
4.4.8 AnimatedExpandableListView
Si tratta dell’implementazione di una lista espandibile per applicazioni Android che
supporta le animazioni.
Dato che le liste espandibili predefinite di Android non supportano le animazioni,
per migliorare l’esperienza d’uso dell’applicazione, verrà usata questa implementazione
alternativa.
4.4.9 Bitbucket
È un servizio che comprende un repository online per il controllo di versione, un
sistema di tracciamento issues per la gestione delle modifiche e spazio web per ospitare
documentazione in formato wiki.
Ciò che viene caricato può essere mantenuto privato per gruppi di lavoro fino a 5
persone.
Il repository verrà usato per ospitare il codice prodotto durante l’implementazione
dell’applicazione e per controllarne il versionamento. Verranno tracciati i requisiti
rilevati durante l’analisi con le issues, in modo da tenere sotto controllo i progressi di
implementazione e la copertura dei requisiti. Inoltre in caso vengano rilevati dei bug o
siano necessarie modifiche al codice questo verrà documentato per tenere traccia della
loro risoluzione.
Le issues possono essere di tipi diversi e con priorità diverse:
• Proposal: con questo tipo verranno tracciati i requisiti;
• Bug: con questo tipo verranno tracciati gli errori ed i problemi rilevati;
• Major: con questa priorità verranno tracciati i requisiti obbligatori;
• Minor: con questa priorità verranno tracciati i requisiti desiderabili;
• Trivial: con questa priorità verranno tracciati i requisiti facoltativi.
A tutte le issues riguardanti errori o problemi verrà assegnata la priorità Major.
Verrà utilizzato lo spazio web per le pagine in formato wiki per documentare l’analisi,
la progettazione e la codifica dell’applicazione e per ulteriore documentazione che potrà
essere utile all’azienda in caso debba estendere o modificare l’applicazione.
4.5 API utilizzate
Google stima che circa l’80% dei dispositivi Android attivi sul market utilizzi le
API di livello 15 o superiori. Pertanto si è deciso di utilizzare tale livello come
requisito minimo per l’installazione ed il funzionamento dell’applicazione. Questo rende
possibile utilizzare funzionalità avanzate non presenti nelle API di livello inferiore, che
garantiscono prestazioni ed un’esperienza utente migliori.
Per non escludere il restante bacino di dispositivi è stata realizzata una variante
dell’applicazione compatibile con API di livello inferiore al 15 utilizzando le librerie di
compatibilità incluse nel kit di sviluppo. Questa variante offre le stesse funzionalità
della versione "standard", ma esse sono state rivedute in modo che non utilizzino le4.5. API UTILIZZATE 23 versioni più recenti delle API. Le differenze maggiori comunque si trovano nel codice Java, mentre l’interfaccia grafica resta sostanzialmente invariata. La variante di compatibilità è stata denominata Apprise Legacy.
Capitolo 5
Progettazione di dettaglio e
codifica
In questo capitolo verranno illustrati gli incrementi effettuati per implementare l’applicazione.
Per ogni incremento è stata prima effettuata la progettazione in dettaglio delle funzionalità
prese in esame, poi sono state implementate ed infine il codice è stato testato per controllare
la corretta implementazione.
5.1 Baseline: progetto e lista dei profili
Come base per l’applicazione si è creato il progetto con Android Studio e si so-
no create le due activity principali con i relativi fragment: ProfileListActivity,
ProfileListFragment, ProfileDetailActivity e ProfileDetailFragment. Queste
classi andavano create assieme perché ProfileListActivity in caso di dispositivi con
schermo ampio gestisce entrambi i fragment.
Sono poi state progettate e implementate le funzionalità di ProfileListActivity e
ProfileListFragment per far si che venisse visualizzata una lista con il layout definito
dal file activity_profile_list.xml.
5.2 Incremento 1: oggetti condivisi
In questo incremento sono state progettate e implementate le classi del package shared.
• Enums: questa classe contiene le dichiarazioni dei tipi enumerazione personalizzati
che rappresentano lo stato di host, servizi e profili.
– HostStatus: lo status di un host può essere UP, PENDING, UNREACHABLE o
DOWN.
– ServiceStatus: lo status di un servizio può essere OK, PENDING, UNKNOWN,
WARNING o CRITICAL.
– ProfileStatus: lo status di un profilo può essere UNKNOWN, OK, WARNING o
ERROR.
• NagiosObject: questa classe contiene i campi in comune tra host e servizi. Sono:
2526 CAPITOLO 5. PROGETTAZIONE DI DETTAGLIO E CODIFICA
(a) Visualizzazione su un di- (b) Visualizzazione su un display ampio
splay di larghezza ridot-
ta
figura 5.1: La lista dei profili
– profileId: un numero che identifica il profilo a cui appartiene questo host
o servizio;
– duration: il tempo passato dall’ultima variazione di stato;
– statusInfo: una stringa che contiene informazioni estese sullo stato del-
l’host o servizio;
– lastCheckTime: la data e l’ora in cui Nagios ha effettuato l’ultimo controllo;
– flapping: booleano che indica se questo host o servizio sta fluttuando tra
più stati;
– inScheduledDowntime: booleano che indica se l’host o servizio è in manu-
tenzione programmata.
Inoltre la classe implementa un costruttore che richiede tutti questi campi per la
costruzione dell’oggetto e dei metodi getter per recuperare il valore dei campi.
• Host: questa classe contiene i campi di informazioni legate ad un host, ovvero:
– name: una stringa contenente il nome dell’host;
– status: un campo di tipo enumerazione Enums.HostStatus che indica lo
stato dell’host.
Inoltre la classe implementa un costruttore che richiede tutti questi campi per la
costruzione dell’oggetto e dei metodi getter per recuperare il valore dei campi.
• Service: questa classe contiene i campi di informazioni legate ad un servizio,
ovvero:
– description: una stringa contenente una descrizione identificativa del
servizio;
– hostName: il nome dell’host a cui appartiene questo servizio;5.3. INCREMENTO 2: DATABASE 27
– status: un campo di tipo enumerazione Enums.ServiceStatus che indica
lo stato del servizio;
– currentAttempt: il tentativo corrente di verificare lo stato del servizio;
– maxAttempts: il numero massimo di tentativi dopo i quali lo stato del
servizio diventa stabile.
Inoltre la classe implementa un costruttore che richiede tutti questi campi per la
costruzione dell’oggetto e dei metodi getter per recuperare il valore dei campi.
• Profile: questa classe contiene i campi di informazioni legate ad un profilo,
ovvero:
– id: un numero identificativo del profilo, utile per il suo inserimento e
recupero dal database;
– name: il nome del profilo;
– nagiosUrl: l’URL presso cui è reperibile l’istanza Nagios a cui fa riferimento
questo profilo;
– credentials: le credenziali di accesso all’istanza di Nagios;
– status: un campo di tipo enumerazione Enums.ProfileStatus che indica
lo stato del profilo.
Inoltre la classe implementa un costruttore che richiede tutti questi campi per la
costruzione dell’oggetto e dei metodi getter per recuperare il valore dei campi.
5.3 Incremento 2: database
In questo incremento sono state progettate e implementate le classi del package dao. In
particolare è stata progettata la struttura del database e le funzionalità per accedervi.
• SQLContract: questa classe definisce la struttura del database. È stato deciso
che il database conterrà 3 tabelle, una per i profili, una per gli host ed una per i
servizi.
– profiles: è la tabella che conterrà le informazioni sui profili. Sarà formata
dalle colonne _ID, name, nagiosurl, username, password e status, che
fanno riferimento ai campi del tipo Profile;
– hosts: è la tabella che conterrà le informazioni sugli host. Sarà formata
dalla colonna _ID, che conterrà un numero identificativo dell’host e dalle
colonne name, profileid, status, duration, lastchecktime, statusinfo,
flapping e inscheduleddowntime che fanno riferimento ai campi del tipo
Host;
– services: è la tabella che conterrà le informazioni sui servizi. Sarà for-
mata dalla colonna _ID, che conterrà un numero identificativo del servizio
e dalle colonne description, hostname, currentattempt, maxattempts,
profileid, status, duration, lastchecktime, statusinfo, flapping e
inscheduleddowntime che fanno riferimento ai campi del tipo Service.
Le tabelle degli host e dei servizi contengono tutti gli host ed i servizi di tutti i
profili presenti nel database.Puoi anche leggere
