Documentazione progetto software - IoSegnalo

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II
Scuola Politecnica e delle Scienze di Base
Dipartimento di Ingegneria Elettrica
e Tecnologie dell’Informazione
Corso di Laurea Magistrale in Ingegneria Informatica
Tesina Di Progettazione e Sviluppo Sistemi Software
IoSegnalo
Prof.ssa: Candidati:
Anna Rita Fasolino Marco Vaiano
Giovanna Taglialatela
ANNO ACCADEMICO 2019/20

Sommario
Presentazione del progetto............................................................................................................................... 4
Capitolo 1: Descrizione del tipo di processo di sviluppo adottato e tool.......................................................... 4
1.1 Processo di sviluppo software................................................................................................................. 4
1.2 Organizzazione del lavoro........................................................................................................................ 4
1.3 Tool utilizzati............................................................................................................................................ 6
1.4 Stima dei costi ......................................................................................................................................... 6
1.5 Primo workshop dei requisiti e piano della prima iterazione ................................................................. 8
1.6 Secondo workshop dei requisiti e piano della seconda iterazione ......................................................... 9
1.7 Terzo workshop dei requisiti e piano della terza iterazione ................................................................... 9
Capitolo 2: Fase di avvio del progetto............................................................................................................... 9
2.1 Descrizione degli obiettivi ....................................................................................................................... 9
2.2 Prospettive del prodotto ....................................................................................................................... 10
2.3 Vincoli generali ...................................................................................................................................... 10
2.4 Parti interessate .................................................................................................................................... 11
2.5 Requisiti funzionali ................................................................................................................................ 11
2.6 Requisiti non funzionali ......................................................................................................................... 11
Capitolo 3: Specifica dei Requisiti.................................................................................................................... 12
3.1 Documento di specifica dei requisiti ..................................................................................................... 12
3.2 Interfacce richieste................................................................................................................................ 13
3.3 Servizi esterni ........................................................................................................................................ 13
Capitolo 4: Analisi dei Requisiti ....................................................................................................................... 14
4.1 Analisi del Testo..................................................................................................................................... 14
4.2 Attori...................................................................................................................................................... 15
4.3 Descrizione dei Casi D’Uso in formato breve ........................................................................................ 15
4.4 Tabella attori-obiettivi........................................................................................................................... 16
4.5 Diagramma dei casi d’uso...................................................................................................................... 17
4.6 Descrizione dei casi d’uso implementati in formato dettagliato .......................................................... 17
4.7 Diagramma di Contesto......................................................................................................................... 22
4.8 Modello degli Oggetti di Business (Modello di Dominio)...................................................................... 23
4.9 Diagrammi degli stati............................................................................................................................. 24
4.10 Diagrammi di Sequenza di Sistema ..................................................................................................... 24
Capitolo 5: Documentazione di progetto, Architetture e scelte..................................................................... 36
5.1 Diagramma dei componenti.................................................................................................................. 36
5.2 Diagramma di deploy............................................................................................................................. 37
5.3 Stile architetturale: Client-Server.......................................................................................................... 38

5.4 Pattern architetturale Server: BCE ........................................................................................................ 39
5.5 Pattern architetturale Client: MVP........................................................................................................ 41
5.6 Diagrammi architetturali ....................................................................................................................... 45
5.7 Diagrammi di sequenza raffinati ........................................................................................................... 48
5.8 Schema del Database: Diagramma ER................................................................................................... 54
Capitolo 6: Implementazione, deploy ed esecuzione...................................................................................... 55
6.1 Implementazione software ................................................................................................................... 55
6.2 Istruzioni per il deploy del software...................................................................................................... 56
6.3 Istruzioni per la configurazione del database........................................................................................ 56
6.4 Istruzioni per la configurazione del server ............................................................................................ 57
6.5 Istruzioni per l’installazione e configurazione dei client ....................................................................... 59
6.5.1 Esecuzione del client “Cittadino” ................................................................................................... 59
6.5.2 Esecuzione del client “Responsabile Tecnico”................................................................................ 64
Capitolo 7: Testing........................................................................................................................................... 70

Presentazione del progetto
Il progetto prevede la realizzazione di un’applicazione mobile per la gestione delle
segnalazioni dei cittadini, in merito a problemi urbani di vario tipo (segnaletica
stradale, presenza di rifiuti o ostacoli in strada e altro), il cittadino che rileva un
problema può descriverne i dettagli, attendere che sia presa in carico da
responsabili tecnici e visualizzare lo stato di essa, in modo da poter evitare situazioni
di pericolo e permettere interventi tempestivi.
L’applicazione richiede l’interazione con cittadini, amministratore del sistema, che
può eliminare o modificare alcune segnalazioni, e responsabili tecnici.
Capitolo 1: Descrizione del tipo di processo di sviluppo
adottato e tool
1.1 Processo di sviluppo software
Si è utilizzato il processo di sviluppo software iterativo ed evolutivo UP, in modo da
gestire il cambiamento dei requisiti adeguatamente, con la possibilità di ottenere
feedback dai clienti in seguito a rilasci incrementali del software, permettendo il
raffinamento e la crescita di questo dopo ogni iterazione.
1.2 Organizzazione del lavoro
Il team di sviluppo è costituito da due studenti, come primo step si è proceduto ad
una prima analisi e specifica dei requisiti di alto livello, elencando solo i nomi dei casi
d’uso. Successivamente è stata effettuata un’analisi più dettagliata su una parte dei
casi d’uso oggetto della prima iterazione, in cui si è fatta modellazione e
progettazione in coppia con UML. Si è passati poi alla programmazione ed
integrazione del lavoro sviluppato dai componenti del team. Nella prima iterazione
si è considerato il caso d’uso a maggior rischio, ovvero Segnala.

L’obiettivo delle iterazioni è quello di fornire rapidamente una versione funzionante
del sistema, in modo da riceverne eventuali feedback e introdurre cambiamenti
nelle successive iterazioni.
Lo sviluppo del progetto ha avuto una durata di 6 settimane, in cui sono state
eseguite 3 brevi iterazioni. Il team si è riunito 5 giorni a settimana per 6 ore al giorno
circa, per un totale di 30 ore settimanali e 180 per l’esecuzione dell’intero progetto.
Di seguito si mostrano le fasi del processo UP con le relative durate ed elaborati
prodotti:
Fase Durata Numero
Iterazioni
Attività Elaborati
Ideazione 1
settimana
1 Studio di
fattibilità (stima
costi e tempi),
esplorazione dei
requisiti
Modello dei
casi d’uso,
Visione, Piano
di iterazione.
Elaborazione 2
settimane
3 Analisi e
specifica dei
requisiti,
implementazione
iterativa e
verifica del
nucleo
dell’architettura
Modello di
dominio,
Diagrammi di
progettazione,
documento di
architettura,
Prototipo
architetturale
0.1.1,
Prototipo
architetturale
0.1.2
Costruzione 2
settimane
3 Implementazione
iterativa degli
elementi
rimanenti a
minor rischio
Modello di
dominio,
Diagrammi di
progettazione,
documento di
architettura,
Release 0.1.1,
Release 0.1.2
Transizione 1
settimana
1 Test, Rilascio Rilascio della
Release sul
mercato.

1.3 Tool utilizzati
- Microsoft Teams, per organizzare riunioni e discutere delle decisioni da prendere.
- GitHub, per condividere codice.
- Visual Paradigm, per la modellazione in UML.
- Google doc, per la documentazione.
- Database Mysql per la memorizzazione e dei dati.
- Android Studio, per lo sviluppo del lato client dell’applicazione mobile realizzata.
- Eclipse, per lo sviluppo del lato server.
1.4 Stimadei costi
Per la stima dei costi abbiamo usato gli UCP (Use Case Point), che stimano la durata
del progetto, in particolare si è supposto che siano necessarie 20 ore per UCP.
Per effettuare tale stima si devono calcolare gli UUCP (Unadjusted Use Case Points),
dati dalla somma degli UUCW (Unadjusted Use Case Weight) e UAW (Unadjusted
Actor Weight):
UUCP = UUCW+UAW = 120+11 = 131
Use case
complexity
Weight Number of use
cases
Product
Simple 5 1 5
Average 10 7 70
Complex 15 3 45
Total (UUCW) 120
Actor Type Weight Number of
Actor
Product
Simple 1 0 0

Average 2 1 2
Complex 3 3 9
Total (UAW) 11
Abbiamo poi valutato i fattori di complessità tecnica, attribuendo ad ogniuno dei 13
fattori un punteggio indicativo della rilevanza di questi (da 0 a 5).
Fattore Peso Valutazione Impatto
Sistema distribuito 2 4 8
Prestazioni 2 3 6
Efficienza end-user 1 3
Complessità di
elaborazione
1 2 2
Riusabilità del codice 1 3 3
Facilità di
installazione
0.5 4 2
Facilità di uso 0.5 4 2
Portabilità 2 3 4
Facilità di
cambiamento
1 2 2
Uso concorrente 1 2 2
Sicurezza 1 1 1
Accesso per terze
parti
1 1 1
Necessità di
formazione
1 0 0
Totale (Tfactor) 33
Di seguito sono riportati i fattori di aggiustamento della complessità dell’ambiente:
Fattore Peso Valutazione Impatto
Familiarità con
processo di sviluppo
1.5 3 4.5
Esperienza
applicativa
0.5 1 0.5
Esperienza orientata
ad oggetti
1 3 3
Capacità di condurre
analisi
0.5 3 4.5

Motivazione 1 4 4
Requisiti stabili 2 3 6
Staff part-time -1 0 0
Difficoltà linguaggio
di programmazione
-1 2 -2
Totale (Efactor) 20.5
TCF = 0.6+(0.01*Tfactor) = 0.93
EF = 1.4+(-0.03*Efactor) =0.78
Infine, si effettua il calcolo finale degli Use Case Points (UCP).
UCP = UUCP*TCF*EF = 131*0.93*0.78 = 95.02
Si stimano dunque circa 1900 ore per la realizzazione dell’intero progetto.
1.5 Primo workshop dei requisiti e piano della prima
iterazione
Prima della prima iterazione, si è tenuto il primo workshop dei requisiti, il giorno 20
luglio, la cui durata è stata di circa 3 giorni.
-Primo giorno: è stata effettuata un’analisi dei requisiti di alto livello, elencando i
nomi dei casi d’uso. Si è scelto il caso d’uso Segnala, che risulta significativo rispetto
all’architettura, obiettivo principale dell’applicazione che s’intende realizzare,
dunque ad elevato valore di business e rischio elevato.
-Successivi 2 giorni: è stata eseguita un’analisi dettagliata dei requisiti funzionali e
non funzionali del caso d’uso preso in considerazione.
Durante la prima iterazione, si è stabilito quali requisiti sviluppare, dopo una fase di
analisi e progettazione, si è passati alla programmazione e al test.
Alla fine della prima iterazione, è stato scelto un altro 20% di casi d’uso significativi
da analizzare e si è pianificata l’iterazione successiva.

1.6 Secondo workshop dei requisiti e piano della seconda
iterazione
Prima della seconda iterazione, si è tenuto il secondo workshop dei requisiti, il
giorno 31 Agosto, la cui durata è stata di circa 3 giorni.
nomi dei casi d’uso. Sono stati scelti i casi d’uso “Visualizza segnalazioni cittadino”,
“Controlla modifiche segnalazioni” e “Invia notifica”.
-Successivi 2 giorni: è stata eseguita un’analisi dettagliata dei requisiti funzionali e
non funzionali dei casi d’uso presi in considerazione.
Durante la seconda iterazione, si è stabilito quali requisiti sviluppare, dopo una fase
di analisi e progettazione, si è passati alla programmazione e al test.
Alla fine della seconda iterazione, è stato scelto un altro 20% di casi d’uso
significativi da analizzare e si è pianificata l’iterazione successiva.
1.7 Terzo workshop dei requisiti e piano della terza
iterazione
Prima della terza iterazione, si è tenuto il secondo workshop dei requisiti, il giorno
14 Settembre, la cui durata è stata di circa 3 giorni.
nomi dei casi d’uso. Sono stati scelti i casi d’uso “Visualizza segnalazioni aperte”,
“Crea intervento” e “Controlla nuove segnalazioni”. E’ stato inoltre scelto il
requisito non funzionale “Login” per l’autenticazione degli utenti.
-Si è proceduto, successivamente in modo analogo alle precedenti iterazioni,
realizzando la modellazione, progettazione, implementazione e test del software.
Capitolo 2: Fase di avvio del progetto
2.1 Descrizione degli obiettivi
Si desidera realizzare un sistema di gestione, che sia grado di acquisire in
mobilità, le segnalazioni provenienti dai cittadini su problemi relativi ad un

determinato ambito territoriale (es. Comune), nel quale sono presenti diverse
squadre di tecnici per la soluzione dei problemi presentati.
I cittadini, dopo aver eseguito la procedura di autenticazione, potranno
segnalare fornendo alcune caratteristiche tipiche, i propri dati anagrafici e
un’indicazione geografica relativa al luogo segnalato. Le nuove segnalazioni
dovranno essere notificate ai responsabili di squadra registrati al sistema.
I responsabili di squadra potranno visualizzare le segnalazioni aperte dai
cittadini ma non ancora prese in carico, potranno creare interventi associati
alle stesse e aggiornare lo stato di lavorazione.
Qualora non fosse possibile portare a termine un intervento, in seguito della
presa in carico da parte dei responsabili di squadra, si prevede la possibilità di
"chiudere" anticipatamente la segnalazione e lasciare una nota al cittadino
segnalante.
Si prevede, quindi, una gestione delle segnalazioni e dei relativi interventi per
i quali si susseguiranno diverse fasi di lavorazione (aperto, in lavorazione,
chiuso), informando di volta in volta i cittadini registrati interessati attraverso
l'invio di una notifica.
Le segnalazioni e i relativi interventi dovranno essere archiviati in modo
permanente, distinguendole attraverso un identificativo univoco.
Si prevede, infine, la figura di amministratore di sistema, la quale potrà
visualizzare le segnalazioni presenti in archivio con la possibilità di eliminarle
dal sistema qualora fosse necessario (es. in caso di duplicati).
2.2 Prospettive del prodotto
L’applicazione che s’intende sviluppare, si pone come obiettivo quello di aiutare
l’utente, il cittadino a segnalare qualsiasi problema che gli si presenta in strada, in
modo veloce e semplice, inviando una richiesta di intervento, qualora lo ritenesse
opportuno o addirittura necessario, in caso di situazioni di emergenza o di
potenziale pericolo, si pensi all’osservazione di un albero pericolante, ad una folta
vegetazione che ostacoli il percorso di mezzi di qualsiasi genere, oppure la mancanza
di segnaletica stradale, la presenza di rifiuti o qualsiasi genere di ostacolo su strada e
marciapiedi.
2.3 Vincoli generali
Tutti gli utenti del sistema devono installare l’applicazione sul proprio dispositivo
mobile con sistema operativo Android versione 9, per poter usufruire delle
funzionalità offerte.

2.4 Parti interessate
Si hanno un numero indefinito di cittadini registrati, diversi responsabili di squadre
tecniche dislocati sul territorio, un unico amministratore di sistema.
2.5 Requisiti funzionali
• Il sistema consente agli utenti cittadini registrati di inserire segnalazioni.
• I cittadini registrati potranno visualizzare le segnalazioni da loro inviate.
• Il responsabile tecnico può modificare lo stato della segnalazione per
mostrare l’avanzamento della segnalazione.
• Il responsabile tecnico visualizza le segnalazioni aperte, non ancora prese in
carico.
• Il responsabile tecnico potrà visualizzare gli interventi relativi alle
segnalazioni prese in carico.
• Il sistema prevede una visualizzazione globale di tutte le segnalazioni inserite
con la possibilità di poterle eliminare. Tale operazione è unicamente svolta
dall’amministratore di sistema.
• Invio notifica al responsabile tecnico relativa all’inserimento di nuove
segnalazioni.
• Invio notifica al cittadino, relativa al cambiamento di stato della segnalazione.
2.6 Requisiti non funzionali
Sicurezza
Ogni utente può accedere a determinate funzionalità, dopo aver installato
l’applicazione sul proprio dispositivo mobile ed essersi registrato, è garantito il
rispetto della privacy e la divulgazione dei dati, in base ai consensi che l’utente da in
fase di installazione.
Usabilità
L’applicazione deve essere facilmente utilizzabile, attraverso interfacce semplici ed
intuitive.
Persistenza
I dati relativi alle diverse entità, sono memorizzate in modo persistente su database,
in modo da evitare la perdita degli stessi.

Evolvibilità
In base alle necessità ed ai feedback rilevati, saranno forniti aggiornamenti
dell’applicazione, notificati agli utenti e facilmente installabili.
Robustezza
Durante la fase di test del sistema sono stati gestiti diversi errori, per cui il sistema si
presenta robusto nel caso in cui gli stessi dovessero presentarsi.
Capitolo 3: Specifica dei Requisiti
3.1 Documento di specifica dei requisiti
• Il sistema consente agli utenti cittadini registrati di inserire segnalazioni
fornendo i loro dati personali, informazioni di recapito, tipologia di problema
e un riferimento geografico ottenuta attraverso una mappa oppure tramite
indirizzo. Risulta necessario effettuare controlli sulla validità dei dati inseriti
prima di inserire la segnalazione nel sistema, in caso di inconsistenze si
restituisce un messaggio di errore. Opzionalmente è possibile inserire al più
due foto per mostrare il problema, motivo della segnalazione. All’atto
dell’effettivo inserimento della segnalazione lo stato “aperto” viene
automaticamente assegnato dal sistema e notificate tutte le squadre di
intervento.
• I cittadini registrati potranno visualizzare le segnalazioni da loro inviate.
• La modifica della segnalazione viene effettuata dal responsabile della
squadra di intervento. Nello specifico, la modifica potrà riguardare lo stato di
avanzamento della segnalazione. Si passerà dallo stato “pronto” a quello di
“lavorazione” qualora il responsabile decida di prendere in carico la richiesta
di intervento. Infine, si passa dallo stato di “lavorazione” a “chiuso”, una volta
terminato l’intervento di risoluzione del problema segnalato. In quest’ultima
fase sarà possibile lasciare una nota di chiusura intervento.
Ciascun passaggio tra le varie fasi dovrà essere appositamente segnalato con
una notifica al cittadino interessato.
• Il responsabile di squadra visualizza le segnalazioni aperte, non ancora prese
in carico.

• Il responsabile di ciascuna squadra di intervento potrà visualizzare gli
interventi relativi alle segnalazioni prese in carico dalla propria squadra.
• Il sistema prevede una visualizzazione globale di tutte le segnalazioni inserite
con la possibilità di poterle eliminare. Tale operazione è unicamente svolta
dall’amministratore di sistema.
• Un timer associato al tempo controlla nuove segnalazioni inserite dai cittadini
ed invia una notifica ai responsabili di squadra.
3.2 Interfacce richieste
Cittadino:
• Interfaccia per effettuare inserire una nuova segnalazione.
• Interfaccia per visualizzare le segnalazioni inserite.
Responsabile di squadra:
• Interfaccia per visualizzare le segnalazioni inserite dai cittadini e creare interventi.
•Interfaccia per visualizzare gli interventi eseguiti dalla squadra e modificare lo stato
delle segnalazioni ad essi associati.
Amministratore:
•Interfaccia per visualizzare tutte le segnalazioni
•Interfaccia per eliminare una specifica segnalazione
3.3 Servizi esterni
Sono utilizzate le API REST di OpenStreetMap, per ottenere un indirizzo a partire
dalle coordinate prelevate dal marker posizionato sulla mappa google, in tal modo
l’utente può indicare l’indirizzo direttamente sulla mappa geografica senza doverlo
specificare testualmente.

Capitolo 4: Analisi dei Requisiti
4.1 Analisi del Testo
E’ stata effettuata l’analisi testuale tramite Visual Paradigm con l‘obiettivo di
individuare le classi, i casi d’uso e gli attori del sistema software in esame. Nella
tabella di seguito vi sono le parole chiavi e la loro interpretazione in termini di
classe,attore o caso d’uso. Vengono inoltre specificate le occorrenze, ossia quante
volte vengono ripetute nel testo.
No Candidate Class Extracted Text Type Occurence
1 cittadino non registrato cittadini non registrati Actor 1
2 responsabile di squadra responsabili di squadra Actor 1
3 amministratore di sistema amministratore di sistema Actor 1
4 cittadino registrato cittadini registrati Actor 2
5 segnala segnalare Use Case 2
6 controlla errori controlli sugli errori Use Case 1
7 riassegna riassegnarle Use Case 1
8 elimina eliminarle Use Case 1
9 segnalazione segnalazioni Class 4
10 richiesta di intervento richieste di intervento Class 1
11 utente utenti Class 1
12 visualizza visualizzare Use Case 1
13 modifica modificarle Use Case 1
14 aggiorna stato aggiornamento dello stato Use Case 1
15 cittadino cittadini Actor 1
16 accetta accettare Use Case 1
17 inserite inserire Use Case 1
18 sistema di gestione sistema di gestione Class 1

4.2 Attori
• Cittadino,
• Responsabile di squadra
• Amministratore di sistema
• Tempo
Si hanno un numero indefinito di cittadini registrati, diversi responsabili di squadre
tecniche dislocati sul territorio, un unico amministratore di sistema e il tempo.
4.3 Descrizione dei Casi D’Uso in formato breve
In base all’analisi testuale effettuata in precedenza sono stati individuati undici casi
d’uso.
Segnala, inserimento di una nuova segnalazione da parte dei cittadini, lo stato della
segnalazione sarà “aperto”.
Visualizza segnalazioni, il cittadino può visualizzare tutte le segnalazioni che ha
inserito e il relativo stato di avanzamento.
Visualizza segnalazioni aperte, il responsabile tecnico può visualizzare tutte le
segnalazioni con stato “aperto”.
Crea intervento, il responsabile tecnico, dopo aver visualizzato le segnalazioni
aperte, può scegliere da tale lista la segnalazione da prendere in carico e creare un
intervento. In tal caso lo stato della segnalazione viene modificato con “in
lavorazione”.
Modifica stato segnalazione, il responsabile tecnico può modificare lo stato della
segnalazione, può decidere di chiuderla qual’ ora fosse impossibile gestirla o
chiedere ulteriori dettagli descrittivi.
Visualizza interventi tecnico, il responsabile tecnico può visualizzare la lista degli
interventi che ha creato.
Visualizza segnalazioni, l’amministratore può visualizzare tutte le segnalazioni
presenti nel sistema.
Visualizza interventi, l’amministratore può visualizzare la lista di tutti gli interventi.
Elimina segnalazione, associato all’amministratore consente di eliminare una
segnalazione dal sistema.

Controlla nuove segnalazioni, permette all’attore tempo di individuare le nuove
segnalazioni create.
Controlla modifiche segnalazioni, permette all’attore tempo di individuare
modifiche delle segnalazioni presenti nel sistema.
Invia notifica, permette all’attore tempo di inviare una notifica qualora fosse
inserita una nuova segnalazione o modificato lo stato di una segnalazione.
4.4 Tabella attori-obiettivi
Nella seguente tabella, vengono indicati gli attori e i relativi stereotipi, il loro tipo
(Primario o secondario), e i casi d’uso ad essi associati.
Attori Tipo Casi D’uso Stereotipo
Cittadino registrato PRIMARIO • Segnala
• Visualizza segnalazioni
<<Human Actor>>
Responsabile di
squadra
PRIMARIO • Visualizza segnalazioni
aperte
• Crea intervento
• Visualizza interventi
tecnico
<<Human Actor>>
Amministratore PRIMARIO • Visualizza segnalazioni
• Visualizza interventi
• Modifica stato
segnalazione
• Elimina segnalazione
<<Human Actor>>
Tempo PRIMARIO • Controlla nuove
segnalazioni
• Controlla modifiche
segnalazioni
• Invia notifica
<< Device timer
Actor>>

4.5 Diagramma dei casi d’uso
4.6 Descrizione dei casi d’uso implementati in formato
dettagliato
Caso d’uso: Segnala
Portata: Applicazione mobile
Livello: Obiettivo Cittadino
Attore primario: Cittadino
Parti interessate e interessi: Cittadino

Pre-condizioni: Il cittadino registrato deve autenticarsi.
Post-condizioni: Il sistema memorizza la segnalazione.
Scenario principale:
1. Il sistema acquisisce i dati personali del cittadino.
2. Il cittadino inserisce la posizione geografica (rilevata dal modulo GPS) o
indirizzo del luogo da segnalare, il tipo di problema e una descrizione
facoltativa.
3. Il cittadino conferma la segnalazione.
4. Il sistema controlla il corretto inserimento dei dati.
5. Il sistema conferma l’inserimento della segnalazione.
Scenari alternativi:
2.a I dati inseriti dall’utente non sono corretti
1.Il sistema restituisce a video un messaggio di errore
Caso d’uso: Visualizza segnalazioni
Livello: Obiettivo Cittadino
Attore primario: Cittadino
Parti interessate e interessi: Cittadino
Pre-condizioni: Il cittadino registrato deve autenticarsi.
Post-condizioni: nessuna.
1. Il cliente clicca sul bottone di visualizzazione delle segnalazioni.
2. Il sistema preleva le segnalazioni del cittadino specifico e le inserisce
all’interno di una tabella.
3. Il sistema mostra la tabella.
2.a Non sono presenti segnalazioni relative al cittadino che ha effettuato la
richiesta di visualizzazione.
1. Viene mostrata la tabella vuota.

Caso d’uso: Crea intervento
Livello: Obiettivo Responsabile tecnico
Attore primario: Responsabile tecnico
Parti interessate e interessi: Responsabile tecnico
Pre-condizioni: il Responsabile tecnico registrato deve autenticarsi.
Post-Condizione: Segnalazione presa in carico dal responsabile di squadra.
1. Il responsabile tecnico sceglie la segnalazione su cui avviare un intervento e
conferma la presa in carico.
2. Il sistema modifica lo stato della segnalazione.
1.a Il responsabile tecnico richiede ulteriori dettagli per poter intervenire.
1. Il cittadino segnalante viene notificato della richiesta di ulteriori
dettagli.
1.b La segnalazione non può essere presa in carico per diversi motivi.
1. Il responsabile tecnico invia una risposta di impossibilità di
intervento al cittadino che ha segnalato il problema.
Caso d’uso: Visualizza segnalazioni aperte
Post-Condizione: Nessuna.
1. Il responsabile tecnico clicca sul bottone visualizza segnalazioni.
2. Il sistema preleva le segnalazioni con stato aperto e le inserisce in una tabella.
3. Il sistema mostra la tabella con le segnalazioni aperte.

2.a Non sono presenti segnalazioni aperte.
1. Viene mostrata la tabella vuota.
Caso d’uso: Visualizza interventi tecnico
1. Il responsabile tecnico clicca sul bottone visualizza interventi.
2. Il sistema preleva gli interventi relativi allo specifico responsabile tecnico.
3. Il sistema mostra la tabella con gli interventi gestiti dal responsabile tecnico.
2.a Non sono presenti interventi.
1. Viene mostrata una tabella vuota.
Caso d’uso: Controlla nuove segnalazioni
Livello: Obiettivo Responsabile tecnico e amministratore
Attore primario: Tempo
Parti interessate e interessi: Responsabile tecnico e amministratore.
Pre-condizioni: Timer scattato dopo un intervallo di 5 minuti.
1. Il sistema preleva le segnalazioni con stato aperto, dal database.
2. Confronto le nuove segnalazioni con quelle prelevate in precedenza.
3. Invia una notifica al responsabile tecnico.

1.a La nuova lista delle segnalazioni è uguale a quella precedentemente ottenuta.
Caso d’uso: Controlla modifiche segnalazioni
Portata: Applicazione mobile.
Livello: Obiettivo Responsabile tecnico e cittadino.
Attore primario: Tempo.
Parti interessate e interessi: Responsabile tecnico e amministratore.
Pre-condizioni: Timer scattato dopo un intervallo di 5 minuti.
1. Il sistema preleva le segnalazioni del cittadino, dal database.
2. Il sistema confronta la data dell’ultima modifica tra la versione locale di
ciascuna segnalazione e quella appena prelevata.
3. Il sistema invia una notifica al cittadino.
2.a Le date di ultima modifica delle diverse versioni di segnalazioni sono uguali.

4.7 Diagramma di Contesto
Il seguente diagramma mostra il contesto del sistema, ovvero le interazioni che esso
ha con attori e sistemi esterni.

4.8 Modello degli Oggetti di Business (Modello di Dominio)
Il seguente modello illustra il dominio informativo del problema, mostrando i
concetti fondamentali del dominio, tralasciando le funzionalità offerte dal sistema.
Viene modellato il dominio di interesse senza specificare il modo in cui viene
realizzato.

4.9 Diagrammi degli stati
Il cuore del sistema consiste nella creazione e gestione delle segnalazioni descritte
dall’utente cittadino.
In particolare, una segnalazione, tra i vari attributi che la identificano, ha l’attributo
stato che ne indica lo stato di avanzamento dalla creazione, in cui lo stato risulta
“Nuovo”, alla presa in carico da parte di un Responsabile tecnico, che ne crea
l’intervento per gestirla, a tal punto lo stato sarà “In lavorazione”, fino al termine
della gestione della segnalazione, con stato pari a “Chiuso”.
Il seguente diagramma mostra gli stati in cui si trova una segnalazione:
4.10 Diagrammi di Sequenza di Sistema
I diagrammi di Sequenza di Sistema mostrano le operazioni offerte dal sistema.
Tali diagrammi possono essere usati per definire gli input ed output dei sistemi e
rappresentano un particolare scenario di un caso d’uso.
Si mostrano, di seguito, i diagrammi di sequenza non raffinati relativi ai casi d’uso.

Caso d’uso: Login (Cittadino)

Caso d’uso: Login (Amministratore)

Caso d’uso: Login (Responsabile tecnico)

Caso d’uso: Visualizza segnalazioni cittadino
Caso d’uso: Visualizza interventi (amministatore)

Caso d’uso: Visualizza segnalazioni (amministatore)
Caso d’uso: Elimina segnalazione (amministratore)

Caso d’uso: Crea intervento (Responsabile tecnico)

Caso d’uso: Visualizza segnalazioni aperte (Responsabile
tecnico)

Caso d’uso: Visualizza interventi (Responsabile tecnico)

Caso d’uso: Controlla modifiche segnalazioni (Tempo)

Caso d’uso: Controlla nuove segnalazioni (Tempo)

Capitolo 5: Documentazione di progetto, Architetture e
scelte
5.1 Diagramma dei componenti
Tale diagramma mostra la struttura interna del sistema software, dei componenti
che lo costituiscono e della relazione tra di essi.
Il Diagramma è costituito dai seguenti componenti:
• Un componente per ogni utente del sistema, che interagisce con il sistema
attraverso delle interfacce specifiche.
• Un componente che rappresenta il Server, che gestisce le richieste degli utenti
interagendo con il componente Database.
• Un componente che permette di gestire la persistenza dei dati, database
MySQL.
• Due componenti, di cui usufruisce il componente Cittadino, per aggiornare
l’indirizzo, ovvero il componente OpenStreetMap e per visualizzare la mappa,
ovvero GoogleMaps.

5.2 Diagramma di deploy
Il sistema “IoSegnalo” è costituito da tre Client ed un Server, i client sono distribuiti
su dispositivi mobile con sistema operativo Android versione 9 mentre il Server su
un calcolatore con sistema operativo Windows 10, su tale nodo deve essere
installato un Database MySQL Server, la comunicazione con esso è gestita con
l’utilizzo delle Hibernate API.
La comunicazione tra Client e Server avviene tramite rete, utilizzando il protocollo
TCP/IP.

5.3 Stile architetturale: Client-Server
Per il sistema progettato “IoSegnalo”, è stato utilizzato lo stile architetturale Client-
Server, si hanno tre Client relativi agli utenti Cittadino, Responsabile Tecnico e
Amministratore ed un solo Server.
I tre Client offrono l’interfacciamento utente, essi inviano richieste al Server tramite
il connettore, basato sul protocollo di rete TCP/IP.
Utilizzando tale stile, si ha la possibilità di avere ruoli separati, tramite diverse
interfacce client indipendenti, eseguite su dispositivi diversi.
Dal punto di vista logico, il sistema può essere visto come 2-tiered, ovvero diviso in
due livelli, i client gestiscono le interfacce utente con i relativi input, eventi grafici e
output e la logica applicativa, dunque includono il livello di presentazione e di
applicazione in un unico livello, mentre il server contiene il livello della gestione dei
dati.

5.4 Pattern architetturale Server: BCE
Per progettare il Server è stato utilizzato il pattern architetturale Boundary Cotroller
Entity, si tratta di un’architettura a livelli, tale pattern è molto utilizzato nella
progettazione del software orientata agli oggetti, struttura le classi componendo il
software in base alle loro responsabilità nella realizzazione dei casi d’uso.
• Il package Entity contiene gli oggetti del dominio applicativo, corrispondono
alle strutture dati nel database, tale package include le classi Segnalazione,
Intervento, Utente e Archivio.
• Il package Boundary contiene oggetti responsabili dell’interfaccia del Server e
della logica di presentazione, è prevista infatti un’interfaccia lato Server da cui
è possibile avviare il Server stesso o Stopparlo.
• Il package Controller contiene oggetti che percepiscono gli eventi generati
dall’utente e controllano l’esecuzione di un processo di business,
rappresentano azioni e attività dei casi d’uso.
Il Controller fa da intermediario tra Entity e Boundary, esso sviluppa la logica
di business del sistema.
Abbiamo utilizzato il pattern strutturale Facade, attraverso la classe Archivio
si fornisce un’interfaccia più semplice all’esterno, unificando le interfacce più
complesse relative alle classi Utente, Segnalazione ed Intervento.
Tale pattern ci permette di nascondere la complessità del sistema, riducendo
la comunicazione e dipendenza tra classi. Si mostra la riduzione di complessità
ottenuta riducendo il numero di associazioni con la seguente figura:

Si mostra l’architettura del Server:

5.5 Pattern architetturale Client: MVP
Il pattern architetturale utilizzato per realizzare i Client è il Model View Presentation,
tale modello deriva dal Model View Controller, utilizzato principalmente per creare
interfacce utente. Abbiamo effettuato tale scelta in quanto tale modello si adatta
bene all’ecosistema di Android.
Differenze tra MVC e MVP
MVC
• Model, contiene dati, notifica le View.
• View, gestisce interazione con l’utente, non contiene alcuna logica di
business.
• Controller, aggiorna il Model quando si presenta un’evento sulla View,
aggiorna la vista quando il Model cambia.

Usare tale modello in Android risulta complesso, tutta la logica di business ricade nel
controller, un problema che talvolta si ha, è quello di avere tutta la logica in
un’activity del controller, inoltre tutte le attività di Android sono molto collegate sia
all’interfaccia utente, che ai meccanismi di accesso ai dati, ciò porta ad avere
componenti fortemente accoppiati che comportano difficoltà di modifica e di
refactoring.
MVP
• Model contiene gli oggetti del dominio di interesse, i dati del sistema.
• Le view gestiscono le interfacce utente.
• A differenza del pattern MCV, in cui il model può comunicare direttamente
con la view, in tale pattern vi è Il Presenter che fa da intermediario tra View e
Model.
• Tale modello tenta di separare la logica di business dalle view, fornendo
attività più semplici.
• Il Presenter recupera i dati dal model e li restituisce alla view, ascolta l’azione
dell’utente, aggiorna il modello di dati e visualizza.
• Il MVP disaccoppiando alcune parti, fornisce modularità e testabilità.
Pattern utilizzati: Facade e Proxy
Analogamente al package entity nell’architettura BCE del Server, si utilizzato il
pattern strutturale facade per poter ottenere minore complessità, riducendo il
numero di associazioni che connettono le classi del Model all’esterno.
Per quanto concerne la comunicazione col server, è stato fatto uso del pattern
Proxy.
Tale pattern viene utilizzato per creare un oggetto che controlla un altro oggetto che
sia:
• Remoto
• Costoso da creare
• Sottoposto a specifici diritti di protezione.

Struttura del pattern Proxy:
Si compone principalmente di 3 elementi:
• Proxy: mantiene un riferimento che consente di accedere a RealSubject, nel
nostro caso “ProxyComunicazione”.
• Subject: Definisce una interfaccia comune per RealSubject e Proxy, nel nostro
caso “Comunicazione”.
• RealSubJect: definisce l’oggetto reale che il proxy rappresenta, nel nostro caso
“RealComunicazione”.

In “IoSegnalo” è stato utilizzato questo pattern al fine di evitare un uso eccessivo del
canale di comunicazione, realizzando il concetto di “Lazy Loading”, ovvero si è
previsto di inviare effettivamente una richiesta del client solo se necessario.
La classe “Archivio” la quale si occupa di preparare ed inviare le richieste da
inoltrare al Server, farà uso di un oggetto Proxy che controllerà se tale richiesta
corrisponde alla stessa già effettuata nell’invio precedente in rete. In caso di esito
negativo tale richiesta verrà inoltrata alla classe “RealComunicazione” per l’effettivo
invio al Server attraverso una socket.
Con questo pattern, si avrà la sicurezza di inviare soltanto richieste diverse tra loro
evitando di sovraccaricare il server con richieste alla quale ha già fornito una
risposta precedentemente.
Durante lo sviluppo, in particolare dei casi d’uso di controllo di nuove segnalazioni e
di modifiche alle segnalazioni, effettuate rispettivamente dai client “Responsabile
Tecnico” e “Cittadino”, vista la presenza di richieste identiche inviate ogni 5 minuti,

si è creata una sorta di “backdoor” all’interno del Proxy al fine di garantire che
soltanto questo tipo di richieste che sono uguali tra loro possano essere inviate al
Server.
5.6 Diagrammi architetturali
Vista Cittadino (MVP):

Architettura Client- Server
Vista Responsabile tecnico (MVP):

5.7 Diagrammi di sequenza raffinati
Caso d’uso: Segnala

Caso d’uso: Visualizza segnalazioni cittadino

Caso d’uso: Visualizza segnalazioni aperte
(Responsabile tecnico)

Caso d’uso: Controlla nuove segnalazioni aperte
(Tempo)

5.8 Schema del Database: Diagramma ER
Il Database utilizzato per la persistenza dei dati, precisamente delle Segnalazioni,
Utenti e Interventi segue il seguente schema ER.
Si noti che la tabella Utenti raccoglie Cittadini, Responsabili Tecnici e Amministratore
differenziandoli in base al valore contenuto nel campo "Tipo".

Capitolo 6: Implementazione, deploy ed esecuzione
6.1 Implementazione software
L’applicazione software realizzata è Object-Oriented, il linguaggio di
programmazione scelto è Java.
Le applicazioni client sono state sviluppate utilizzando l’IDE Android Studio, mentre
per il server è stato utilizzato l’IDE Eclipse.
Trattandosi di una architettura client-server, è stato utilizzato il meccanismo delle
Socket per la comunicazione su rete tra le due parti.
Il client istanzia una socket ad ogni messaggio di richiesta che si intende inviare al
Server. La gestione della comunicazione e quindi dell’invio della richiesta e della
ricezione della risposta da parte del Server è effettuata dalla classe
“RealComunicazione”.
Sia i messaggi di richiesta che di risposta sono implementati mediante un ArrayList
data la sua possibilità di essere serializzato/deserializzato, nel quale il primo campo
contiene il tipo di richiesta (o di risposta) e i successivi conterranno l’informazione
da trasmettere.
Per quanto concerne il Server, la comunicazione avviene mediante la classe
“ControllerComunicazione” la quale istanzia un thread che si metterà in ascolto sulla
porta 7777. I messaggi ricevuti dal client vengono distinti, come già anticipato, in
base al primo campo dell’ArrayList attraverso un costrutto “Switch”, e in base
adesso si effettueranno le opportune operazioni.
Si noti che in questa implementazione non è prevista la possibilità di accogliere più
richieste contemporaneamente dai diversi client, ma una volta instaurata la
comunicazione tra un client e il server, quest’ultimo resterà occupato per tutta la
durata della comunicazione.
Il thread relativo alla creazione della socket in ascolto sul server è stato incluso in un
costrutto “while” che consente la possibilità di fermare l’esecuzione del server
mediante il “click” del relativo bottone presente nell’interfaccia grafica.
La gestione delle notifiche relative alle nuove segnalazioni (responsabili tecnici), e
delle notifiche relative alle modifiche dello stato di una segnalazione (cittadini) è
stata realizzata definendo un Timer impostato a 5 minuti (300000ms) al quale è
stato fatto uno “schedule” delle classi “ControllerModificheSegnalazioni” e
“ControllerSegnalazioniAperte” che si occuperanno rispettivamente di effettuare le
opportune operazioni per la verifica e notifica di modifiche alle segnalazioni
attraverso la data di ultima modifica, e di nuove segnalazioni aperte.

Il componente Server, unica parte dell’architettura la quale si interfaccia col
Database, sfrutta il framework Hibernate per effettuare le operazioni di
inserimento, modifica, eliminazione e recupero dei record dalla base di dati.
Il DBMS utilizzato è MySQL, installato sul computer dove è in esecuzione
l’applicazione Server.
Infine sono state utilizzate le API REST consentendo al client Cittadino di accedere ai
servizi web offerti da OpenStreetMap per la geolocalizzazione inversa, ovvero per
ottenere l’indirizzo a partire dalle coordinate GPS.
6.2 Istruzioni per il deploy del software
Per effettuare il deploy del software, occorre disporre una macchina da adibire a
Server, con sistema operativo Windows 10 e dispositivi con sistema operativo
Android (preferibilmente smartphone in modalità portrait) dotati di modulo GPS per
la geolocalizzazione delle segnalazioni e Google Services per l’accesso a Google
Maps.
6.3 Istruzioni per la configurazione del database
Prima di avviare il Server sull’apposita macchina, occorre innanzitutto installare il
software MySQL Server, assicurarsi che siano eseguiti i servizi sul sistema operativo
e infine configurare Hibernate in modo che l’applicazione riesca a connettersi al
database.
A tal fine si è configurato il file “hibernate.cfg.xml” come di seguito:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<property
name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.password">esame2020</property>
<property
name="hibernate.connection.url">jdbc:mysql://localhost:3306/database?characterEncoding=
latin1</property>
<property name="hibernate.connection.username">root</property>
<property
name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
<mapping class="entity.Utente" />
<mapping class="entity.Segnalazione" />
<mapping class="entity.Intervento" />
</session-factory>
</hibernate-configuration>
E’ possibile notare la stringa di connessione contenente la parola chiave “localhost”
in quanto il modulo Server di MySQL è in esecuzione in locale.

Inoltre, sono presenti diversi mapping tra le classi presenti nel codice e le entità del
database.
6.4 Istruzioni per la configurazione del server
L’applicazione server è stata sviluppata e testata per essere eseguita su macchine
dotate di sistema operativo Windows 10 e Java JDK versione 8.
Al fine di rendere accessibile i servizi offerti dal server anche all’esterno della rete
locale, e quindi per effettuare test remoti su vari dispositivi, si è configurato il
gateway di rete in modo da effettuare un port-forwarding associando una porta
esterna di comunicazione ad una interna della macchina server. Nel nostro caso
abbiamo utilizzato la porta 7777.
Data la presenza di un firewall presente sul gateway, al fine di garantire la
comunicazione della macchina server all’esterno della rete, si è configurato un DMZ
associato all’indirizzo locale 192.168.1.5 .
Con queste configurazioni di rete è stato possibile effettuare sia test nel quale tutti i
client e il server, erano presenti nella rete locale, e sia in remoto nel quale tutti i
dispositivi erano connessi a reti diverse tra loro.
Effettuate queste configurazioni, avviare il server risulta alquanto semplice.
Per facilitare l’esecuzione del Server si è scritto un file “batch” per l’esecuzione del
comando: “java -jar Server.jar” il quale avvierà l’applicazione Server nella JVM.
Lanciata l’applicazione, cliccando su “Avvia Server”, verrà avviato il modulo Server.

Un feedback fornito dall’applicazione ci dirà che il server è “Online”, ovvero in
esecuzione ed è in ascolto sulla porta 7777.
Una ulteriore conferma ci verrà data dai messaggi presenti nel prompt dei comandi.
In fase di implementazione è stata prevista anche la possibilità di “fermare” il server,
terminando il thread di ascolto.
In tal caso, per effettuare tale operazione, occorre semplicemente cliccare sul tasto
“Ferma Server”
Anche in questo caso, l’applicazione ci darà un “feedback” indicando che il server
risulta “Offline”.

6.5 Istruzioni per l’installazione e configurazione dei client
L’applicazione client è stata sviluppata e testata su dispositivi Android dotati di
livello API compatibili con la versione 28, quindi Android 9.0 .
Per l’installazione dell’applicazione è necessario trasferire il pacchetto di
installazione, file con estensione “.apk”, sul dispositivo, disabilitare la protezione di
“origini sconosciute” per i pacchetti di installazione e lanciare l’eseguibile.
Sono state sviluppate 2 applicazioni client, una per i Cittadini e l’altra per i
Responsabili Tecnici. Da progetto è previsto anche un altro client per
l’Amministratore. Quest’ultimo al momento non risulta ancora implementato.
I due client sono differenziati in base al colore “foreground” dell’icona dell’app come
mostrato in figura:
Al fine di consentire l’accesso dell’applicazione al modulo GPS del dispositivo, e
quindi prelevare la posizione del cittadino che intende inserire una segnalazione,
risulta necessario abilitare l’accesso alla posizione tramite le impostazioni del
dispositivo e fornire le eventuali autorizzazioni richieste in fase di installazione.
6.5.1 Esecuzione del client “Cittadino”
Terminata l’installazione, l’icona sulla “Home” di sistema consente di eseguire
l’applicazione.
Sono state implementate diverse viste per il client versione “Cittadino”.
Si fa presente che al termine dello sviluppo della suddetta versione Client, è stata
prodotta una registrazione dimostrando quanto prodotto
(demo_ClientCittadini.mp4).

Vista delle Funzioni Cittadino

Vista Visualizza Segnalazioni Cittadino

Vista Notifica Segnalazioni Aggiornate
6.5.2 Esecuzione del client “Responsabile Tecnico”
Terminata l’installazione, l’icona sulla “Home” di sistema consente di eseguire
l’applicazione.
Sono state implementate diverse viste per il client versione “Responsabile Tecnico”.
Si fa presente che al termine dello sviluppo della suddetta versione Client, è stata
prodotta una registrazione dimostrando quanto prodotto
(demo_ClientRespTecnici.mp4).

Vista delle funzioni Responsabile Tecnico

Vista delle segnalazioni con stato “Aperto”

Vista di Notifica nuove Segnalazioni

Capitolo 7: Testing
Attraverso la fase di testing è stata verificata la correttezza, completezza e
affidabilità del software sviluppato.
Durante lo sviluppo di IoSegnalo, il testing è stato svolto al termine di ciascuna
iterazione.
Al fine di tenere traccia del processo e dei casi di test analizzati si è fatto ricorso ad
una tabella su “Smartsheet”, dove sono stati individuati come “passati” i casi di test
in cui i risultati attesi ed effettivi coincidevano.
Dai casi testati si evidenziano alcuni problemi relativi al login, alla configurazione del
timer per la rilevazione di modifiche delle segnalazioni di un cittadino e infine di
autorizzazione all’uso del modulo GPS.

Documentazione progetto software - IoSegnalo

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Similar to Documentazione progetto software - IoSegnalo

Similar to Documentazione progetto software - IoSegnalo (20)

Recently uploaded

Recently uploaded (11)

Documentazione progetto software - IoSegnalo