Document

Università degli Studi di Padova
Facoltà di Scienze MM.FF.NN
Laurea in Informatica
iWWAlarms
monitoraggio di un impianto industriale con
iPhone
Candidato:
Alberto Baggio Mat 560164
Anno Accademico 2010-2011
Relatore:
Paolo Baldan
Alberto Baggio
Tesi – iWWAlarms
1
Indice generale
Introduzione..........................................................................................................................................4
L'azienda..........................................................................................................................................5
Scopo dello stage.............................................................................................................................5
Prodotto ottenuto..............................................................................................................................7
Organizzazione del documento........................................................................................................7
Strumenti utilizzati...............................................................................................................................8
Strumenti utilizzati...........................................................................................................................9
Ambiente di sviluppo..................................................................................................................9
Strumenti forniti con Xcode........................................................................................................9
Cocoa........................................................................................................................................10
Analisi.................................................................................................................................................11
Scopo del documento.....................................................................................................................12
Scopo del prodotto....................................................................................................................12
Descrizione generale – configurazione .........................................................................................12
Funzioni del prodotto................................................................................................................13
Vincoli generali.........................................................................................................................13
Dipendenze................................................................................................................................13
Casi d'uso.......................................................................................................................................13
Use Case UC0 – Connessione/autenticazione...........................................................................13
Use Case UC1 – Post autenticazione........................................................................................14
Use Case UC3 – Impostazione parametri connessione.............................................................15
Use Case UC4 – Visione allarmi attivi.....................................................................................15
Use Case UC 4.1 – Dettaglio allarme.......................................................................................16
Use Case UC6 – Statistiche allarmi attivi.................................................................................17
Use Case UC7 – Filtraggio allarmi...........................................................................................17
Lista dei requisiti...........................................................................................................................18
Requisiti funzionali...................................................................................................................18
Requisiti di qualità....................................................................................................................20
Specifica.............................................................................................................................................21
Apple Notification Service, APNs.................................................................................................22
Connessione e comunicazione..................................................................................................22
JSON.........................................................................................................................................22
Formato del messaggio di notifica............................................................................................23
Sicurezza...................................................................................................................................24
Scelte progettuali...........................................................................................................................24
Alberto Baggio
Tesi – iWWAlarms
2
Modulo connessione.................................................................................................................25
Modulo Data Store....................................................................................................................25
Modulo Controllo-Visualizzazione...........................................................................................26
Definizione di prodotto.......................................................................................................................27
Pattern............................................................................................................................................29
Model.............................................................................................................................................31
DownloadAllarmiAttivi............................................................................................................31
StoreAllarmiAttivi....................................................................................................................32
DataBase...................................................................................................................................34
RandomColor............................................................................................................................35
Filters........................................................................................................................................35
View...............................................................................................................................................36
Classi che disegno i grafici:......................................................................................................36
Gestori touch utente..................................................................................................................37
Controller.......................................................................................................................................38
iAlarmsAppDelegate.................................................................................................................38
RootController..........................................................................................................................39
Page...........................................................................................................................................39
ContPage...................................................................................................................................40
ControllerQuartaVista...............................................................................................................40
DettaglioAllarme.......................................................................................................................41
ViewFilterResult.......................................................................................................................41
SaveFilters.................................................................................................................................41
MyFilterDisplay:.......................................................................................................................42
Elenco file:.....................................................................................................................................42
SLOC.............................................................................................................................................44
ToDo..............................................................................................................................................44
Conclusioni.........................................................................................................................................45
Risultato....................................................................................................................................47
Scostamento rispetto a quanto pianificato.................................................................................47
Riassuntivo ore..........................................................................................................................48
Esperienza maturata..................................................................................................................48
Miglioramenti............................................................................................................................48
Appendice...........................................................................................................................................49
Elenco Requisiti.............................................................................................................................50
Tracciamento dei requisiti..............................................................................................................51
Tracciamento: requisiti funzionali - Use Case..........................................................................51
Tracciamento: Use Case – requisiti funzionali.........................................................................52
Tracciamento Classi – requisiti soddisfatti...............................................................................52
Requisito – classi che partecipano al soddisfacimento.............................................................54
Glossario.............................................................................................................................................57
Bibliografia.........................................................................................................................................59
Alberto Baggio
Tesi – iWWAlarms
3
Indice delle illustrazioni
Illustrazione 1: Autoware - Logo aziendale..........................................................................................5
Illustrazione 2: Configurazione lato Server..........................................................................................6
Illustrazione 3: iPhone SDK.................................................................................................................9
Illustrazione 4: Configurazione..........................................................................................................12
Illustrazione 5: UC0 - Connessione/autenticazione............................................................................13
Illustrazione 6: UC1 - post autenticazione.........................................................................................14
Illustrazione 7: UC3 - Impostazione parametri connessione..............................................................15
Illustrazione 8: UC4 - Visione allarmi attivi......................................................................................15
Illustrazione 9: UC4.1 – Dettaglio allarme.........................................................................................16
Illustrazione 10: UC6 Statistiche allarmi attivi..................................................................................17
Illustrazione 11: UC7 - Filtro allarmi.................................................................................................18
Illustrazione 12: Schema comunicazione APNs.................................................................................22
Illustrazione 13: Oggetto JSON..........................................................................................................23
Illustrazione 14: Array JSON.............................................................................................................23
Illustrazione 15: Formato messaggio di notifica................................................................................23
Illustrazione 16: Token Trust..............................................................................................................24
Illustrazione 17: Visione ad alto livello - moduli...............................................................................25
Illustrazione 18: Diagramma Classi - prima parte..............................................................................28
Illustrazione 19: Diagramma Classi - seconda parte..........................................................................29
Illustrazione 20: NSNotificationCenter..............................................................................................29
Illustrazione 21: Diagramma di sequenza - scaricamento allarmi......................................................30
Illustrazione 22: Database filtri.db.....................................................................................................34
Illustrazione 23: Area selezionata.......................................................................................................36
Illustrazione 24: Grafici......................................................................................................................37
Illustrazione 25: Gerarchia viste.........................................................................................................38
Illustrazione 26: Pianificato................................................................................................................46
Illustrazione 27: Effettivo...................................................................................................................46
Illustrazione 28: Computazione statistiche.........................................................................................47
Alberto Baggio
Tesi – iWWAlarms
4
Introduzione
Alberto Baggio
Tesi – iWWAlarms
5
Il mercato degli smartphone è in continua crescita, basta analizzare alcuni dati per aver riprova
di questo:
•
15,037,000 è il numero di italiani che posseggono uno smartphone (fonte Ansa, 6 luglio
2010)
•
+38% è il tasso di crescita del mercato in Europa del 2009 rispetto al 2008 (fonte:
Comscore)
Questo stage nasce dall'esigenza di un'azienda vicentina, l'Autoware, di ampliare il suo
mercato verso nuovo prospettive come questa.
L'azienda
“La nostra società è nata nel 1996 con la convinzione che il software nel mondo della
produzione dovesse essere sviluppato in maniera altamente professionale e con un'elevata
qualità del servizio consulenziale. Autoware è stata, per oltre dieci anni, ed è un attore
importante nel mondo dell'integrazione dei sistemi di controllo dei processi e della gestione
della produzione. La ragione della nostra reputazione sta nel fatto di essere sempre stati, più di
ogni altra cosa, concentrati sul successo dei nostri clienti. Il nostro obbiettivo è fornire
soluzione e servizi per la gestione e l'automazione della produzione”.
Illustrazione 1: Autoware - Logo aziendale
Autoware è specializzata nella fornitura di soluzioni per la raccolta e la distribuzione dei dati di
produzione, sfruttando le più moderne tecnologie così da riempire il vuoto di comunicazione
che esiste tra shop floor e ERP.
Autoware è collaboratore di Wonderware, azienda americana leader mondiale nella produzione
di software atti alla gestione automatizzata delle attività industriali in tempo reale. I software
sviluppati in collaborazione dalle due aziende permettono la sincronizzazione della produzione
e delle attività industriali così da ottenere la velocità e la flessibilità necessarie per conseguire
un profitto costante.
Ad oggi Autoware è organizzata in tre business units che si occupano di aspetti diversi:
•
Industrial Automation
•
Manufacturing Execution Systems
•
Machine Vision Solutions
Scopo dello stage
Il presente stage ha avuto come obbiettivo lo sviluppo di un'applicazione iPhone che permette
la visualizzazione di allarmi provenienti da macchinari industriali, come: pressione elevata,
temperatura fuori norma, voltaggio inadatto, blocco del macchinario, etc. L'applicazione
presenta le seguenti funzioni: visualizza gli allarmi attivi e ne permette il filtraggio secondo
parametri configurabili; consente la visualizzazione di svariate statistiche; permette
l'impostazione dei parametri di connessione.
La configurazione presente lato server verrà descritta in dettaglio successivamente,
brevemente è così strutturata. Il monitoraggio degli impianti industriali è effettuato da oggetti
Alberto Baggio
Tesi – iWWAlarms
6
sviluppati con l'ambiente di sviluppo integrato, Archestra IDE. Questi sono eseguiti dal runtime
environment fornito con Archestra. I dati monitorati da questi vengono archiviati su di un
database centralizzato SQL Server.
Illustrazione 2: Configurazione lato Server
Le problematiche più rilevanti affrontate nel corso dello stage sono state:
•
la creazione del canale di comunicazione fra azienda e dispositivo;
•
la necessità di visualizzare allarmi in tempo reale, prima che questi vengano trasferiti al
database aziendale che ne tiene traccia;
•
il rilascio dei certificati SSL per usufruire dell'Apple Notification Service, indispensabili
per utilizzare il servizio di push;
•
l'allineamento fra la versione del software lato server e la versione dell'applicazione sul
client
Per quando riguarda il canale, fra server aziendale e dispositivo viene stabilita una connessione
socket persistente, e lo scambio d'informazione è effettuato utilizzando il protocollo Json-RPC.
Il problema di dover ricevere gli allarmi senza subire la latenza dovuta al tempo di
memorizzazione nel database, è stata risolta sviluppando un nuovo oggetto lato server che
effettua il monitoraggio dei macchinari e lavora simultaneamente all'oggetto che invia i dati al
database SQL Server. È stata adottata questa soluzione per avere una notifica degli allarmi
immediata, senza dovere attendere la loro comunicazione e memorizzazione nel server. Questa
scelta permette inoltre di alleggerire il carico di lavoro del server. Nel secondo capitolo verrà
descritta con più precisione la configurazione lato server presente, in particolare i diversi
strumenti che permettono la rilevazione e memorizzazione dei dati.
Il rilascio dei certificati, necessari per usufruire del servizio di push messo a disposizione da
Apple, al momento è ancora manuale. Il certificato permette al server di registrarsi/comunicare
con il servizio di push (APNs) messo a disposizione da Apple. Ogni server nel quale verrà
installato il pacchetto, necessiterà di un certificato differente. Al momento ogni cliente deve
registrarsi presso Apple e scaricare manualmente il certificato SSL per il proprio server. È
previsto lo sviluppo futuro di una procedura automatizzata
Vi è ancora da risolvere il problema dell'allineamento fra le versioni dell'applicazione lato
server e lato client; in particolare per poter usufruire a pieno delle funzionalità presenti, sarà
Alberto Baggio
Tesi – iWWAlarms
7
necessario che la versione del client sia sempre aggiornata all'ultima rilasciata. Se questa
risulta datata rispetto l'oggetto server con cui comunica, viene informato l'utente, utilizzatore
del dispositivo, della necessità di aggiornamento.
Prodotto ottenuto
L'applicazione ottenuta è in grado di visualizzare gli allarmi attivi, calcolare statistiche su questi
e permette la configurazione dei parametri di connessione. Non è completa ma è comunque già
fruibile; al momento non è stata ancora provata in un vero impianto industriale ma solamente
con il database e ambiente di prova presente in sede di sviluppo.
Non è ancora stata sviluppata completamente la sezione che visualizza dati statistici calcolati
sullo storico degli allarmi memorizzato nel server aziendale, differente da quella che visualizza
dati statistici sugli allarmi attivi. Anche se preventivata, questa sezione è ancora da sviluppare
per due motivi: la mancanza di tempo e la necessità di aggiungere funzionalità lato server atte
ad alleggerire la quantità di calcolo da effettuare nel client (in particolare il calcolo di dati
statistici su grosse quantità di dati).
Durante lo sviluppo dell'applicazione sono stati effettuati svariati test tesi a verificare il corretto
funzionamento dell'applicazione in casi limiti come: il sovraccarico del server, l'invio di
pacchetti vuoti o errati, la mancanza di connessione. Il testing finale e completo
dell'applicazione, anche se preventivato, deve ancora essere effettuato, per la mancanza di
tempo e perché l'applicazione non è completa.
L'applicazione è stata presentata nel mese di ottobre a Los Angeles in una fiera di settore dei
prodotti MES.
Organizzazione del documento
I capitoli successivi sono così strutturati: il capitolo seguente descrive gli strumenti utilizzati per
lo sviluppo. Capitolo 3 e 4 presentano l'analisi dei requisiti e definizione di prodotto. Infine
nell'ultimo capitolo sono presenti le conclusioni.
Alberto Baggio
Tesi – iWWAlarms
8
Strumenti utilizzati
Alberto Baggio
Tesi – iWWAlarms
9
Strumenti utilizzati
Per lo sviluppo dell'applicazione e stato utilizzato l'SDK (Software Development Kit) iPhone SDK.
È stato rilasciato il 6 marzo 2008 e permette lo sviluppo di applicazioni per iPhone e iPod touch,
a partire dalla 3.1 anche per iPad.
L'ambiente di sviluppo integrato (Integrated Development Envoiroment, IDE) fornito dall'SDK è
Xcode. Oltre questo sono stati utlizzati gli strumenti iPhone Simulator, Interface Builder e
Instrument tutti forniti nel kit. iPhone SDK richiede un Mac Intel con Mac OS X Leopard. Altri
sistemi operativi, inclusi Microsoft Windows (qualsiasi versione), Linux e vecchie versioni di Mac
OSX, non sono supportati.
Illustrazione 3: iPhone SDK
Ambiente di sviluppo
È stato utilizzato l'IDE (Integrated Development Envoiroment) Xcode , sviluppato da Apple Inc,
e disponibile solo per amibente Mac OS X. Questo è fornito gratuitamente con il sistema
operativo a partire da Mac OS X 10.3 Panther e scaricabile gratuitamente, previa registrazione,
dal sito: http://developer.apple.com/technologies/tools/xcode.html.
Dalla versione 3.1, Xcode e lo strumento per sviluppare le applicazioni native per iPhone, iPod
touch. Dalla versione 3.2 consente lo sviluppo anche per iPad.
Strumenti forniti con Xcode
•
Instrument: tool integrato in Xcode che permette il monitoraggio e l'analisi delle
prestazioni di un'applicazione eseguita su iPhone. In particolare è in grado di
visualizzare aspetti fondamentali quali: allocazione e rilascio della memoria, sequenza
degli eventi, attività della CPU, threads in esecuzione e risorse impiegate da questi,
traffico network e altro ancora.
•
Interface Builder: software che permette di disegnare interfacce grafiche per i
framework Cocoa e Carbon. Le interfacce vengono salvate in directory contenenti gli
oggetti grafici e le loro relazioni; il tutto è raggruppato in file XML o NeXT con estensione
.nib. Al lancio dell'applicazione i corrispondenti oggetti NIB vengono scompattati e
collegati al codice binario.
•
Iphone Simulator: tool che permette di emulare l'iPhone su pc Mac.
Alberto Baggio
Tesi – iWWAlarms
10
Cocoa
L'applicazione è stata sviluppata in Objective-C, linguaggio orientato agli oggetti con a base il
C. Per lo sviluppo in Objective-C si è utilizzato Cocoa, insieme di framework orientati agli
oggetti che permettono lo sviluppo di applicazioni eseguibili in MAC OS X e iPhone OS. Cocoa e
Objective-C risultano essere unico framework ed unico linguaggio utilizzabili nello sviluppo per
iPhone OS.
Molti potrebbero non concordare con questa visione chiusa e vincolante da parte di Apple. La
giustificazione data da Steve Jobs (CEO Apple) in risposta alla domanda di un utente, riguardo il
blocco dello sviluppo di applicazioni realizzate in Flash CS5 e poi esportate in Objective-c, è
stata la seguente:
“Apple ha creato una piattaforma di sviluppo senza precedenti, in grado di offrire agli
sviluppatori una certa immediatezza ed una semplicità assoluta nella costruzione del codice e
dell'interfaccia grafica dell'applicazione. Creare piattaforme alternative in grado di appoggiarsi
alla nostra non fa altro che confondere gli sviluppatori e sicuramente non fa bene a noi dato
che blocca i progressi e i possibili miglioramenti di tutto ciò che abbiamo creato”.
Vi è da precisare che sono presenti altri tool che permettono di programmare in linguaggi
diversi, come JavaScript, e poi tradurre il tutto in un progetto Xcode.
Chiara la politica di difendere il proprio mercato, difficile trovarsi pienamente d'accordo
considerando che l'unico mercato di applicazioni per iPhone risulta essere l'AppStore di cui
Apple ha il pieno controllo. In particolare un'applicazione per essere commercializzata
nell'AppStore deve essere approvata da Apple. Inoltre i ricavati ottenuti dalla vendita finiscono
per il 70% al creatore e per il 30% ad Apple che si occupa completamente della
commercializzazione.
Alberto Baggio
Tesi – iWWAlarms
11
Analisi
Alberto Baggio
Tesi – iWWAlarms
12
Scopo del documento
Il seguente capitolo illustra in modo chiaro e dettagliato i bisogni evidenziati dal proponente, la
ditta Autoware. Prima di esporre i requisiti emersi, verrà esposta brevemente la configurazione
nella quale si integrerà il prodotto.
Nella stesura ed elaborazione dell'analisi si è fatto riferimento alla specifica v 1.0 fornita
dall'Ing. Andrea Piccolo.
Scopo del prodotto
iAlarms è un'applicazione iPhone in grado di visualizzare in tempo reale allarmi provenienti da
macchinari industriali nei quali sia installato e configurato l'ambiente Archestra di WonderWare.
Tipologie di allarmi visualizzati potrebbero essere: bloccaggio del macchinario, temperatura
eccessiva, sbalzi di tensione, pressione troppo elevata, etc.
Descrizione generale – configurazione
Il monitoraggio degli impianti industriali è effettuato da oggetti sviluppati con l'ambiente di
sviluppo integrato: Archestra IDE. Questi vengono eseguiti dal runtime environment fornito con
Archestra. I dati monitorati sono archiviati su di un database centralizzato SQL Server. Nei
dispositivi industriali oltre l'oggetto sviluppato con Archestra, è presente il software inTouch che
permette la visualizzazione dei dati in tempo reale. InTouch è in grado di interfacciarsi sia con
il database che all'oggetto in esecuzione.
Illustrazione 4: Configurazione
Alberto Baggio
Tesi – iWWAlarms
13
Quando in un macchinario vengono superati dei valori limite l'oggetto rivela lo stato di allarme
e registra questo nel server ed in InTouch.
Per il funzionamento dell'applicazione iPhone è stato sviluppato un ulteriore oggetto Archestra
che lavora in parallelo a quello già presente. Questo ogni qual volta viene registrato un allarme,
notifica l'evento all'applicazione iPhone. Il nuovo oggetto ha un piccolo database proprio nel
quale salva gli allarmi attivi; mentre lo storico degli allarmi è nel database centralizzato.
Funzioni del prodotto
L'applicazione presenta le seguenti principali caratteristiche funzionali:
•
visualizza gli allarmi attivi attraverso un sistema di paginazione
•
permette la visione di statistiche calcolate sullo storico degli allarmi
•
è in grado di fornire informazioni dettagliate sugli allarmi attivi
•
consente il filtraggio degli allarmi secondo svariati parametri
•
visualizza statistiche e grafici riguardanti gli allarmi attivi
•
permette l'impostazione dei parametri di connessione all'oggetto server (indirizzo IP,
porta, user, password).
Vincoli generali
Il prodotto è soggetto ai seguenti vincoli di ordine generale
•
funzionamento su iPhone OS a partire dal 3.1
Dipendenze
Per il corretto funzionamento è necessario che la versione dell'applicazione e del software lato
server siano compatibili fra loro.
Si assume che l'iPhone nel quale l'applicazione verrà eseguita abbia la funzione di push attivata
e disponga di una connessione a internet per effettuare lo scaricamento dei dati
Casi d'uso
Vengono riportati in questa sezione i casi d'uso, in modo grafico e in modo narrativo. L'intento
è evidenziare le funzionalità principali a base della fase di analisi.
Use Case UC0 – Connessione/autenticazione
Illustrazione 5: UC0 - Connessione/autenticazione
Caso d'uso: connessione al server remoto previa autenticazione
Sommario: effettua la connessione al server remoto, utilizzando i parametri di connessione
salvati nel file options.plist e configurabili dalla sezione apposita dell'applicazione.
Alberto Baggio
Tesi – iWWAlarms
14
Attore: l'utente
Precondizioni: per poter effettuare l'autenticazione l'utente deve:
•
Aver impostata indirizzo IP e porta corretti di una macchina dove sia funzionante
l'oggetto server.
•
Avere inserito le credenziali corrette per l'autenticazione.
Post-condizione:
dall'applicazione.
è
possibile
usufruire
delle
funzionalità
messe
a
disposizione
Use Case UC1 – Post autenticazione
Illustrazione 6: UC1 - post autenticazione
Caso d'uso: funzionalità disponibili dopo aver effettuato la connessione ed autenticazione al
server.
Sommario: sarà possibile:
•
Impostare i parametri di connessione (disponibile anche prima di essersi autenticati)
•
Visionare gli allarmi attivi
•
Visionare statistiche riguardanti gli allarmi attivi
•
Visionare statistiche riguardanti lo storico degli allarmi
•
Filtrare gli allarmi secondo parametri decidibili
•
Gestire il push degli allarmi
Attore: l'utente
Precondizioni: per poter usufruire di queste funzionalità l'utente deve essere connesso e
autenticato al server remoto. L'impostazione dei parametri di connessione non necessità la
connessione.
Alberto Baggio
Tesi – iWWAlarms
15
Post-condizioni: è possibile utilizzare ulteriormente l'applicazione.
Use Case UC3 – Impostazione parametri connessione
Illustrazione 7: UC3 - Impostazione parametri connessione
Caso d'uso: impostazione dei parametri di connessione
Sommario: possibilità di impostare i seguenti parametri di connessione:
•
indirizzo IP server
•
porta
•
user e password di autenticazione
Attore: l'utente
Precondizione: nessuna
Post-condizione: è possibile utilizzare ulteriormente l'applicazione
Use Case UC4 – Visione allarmi attivi
Illustrazione 8: UC4 - Visione allarmi attivi
Caso d'uso: visione allarmi attivi
Sommario: sistema di paginazione che visualizzi gli allarmi attivi evidenziando descrizione,
area e data per ogni allarme. Deve essere inoltre possibile visualizzare in dettaglio ogni singolo
allarme.
Attore: l'utente
Alberto Baggio
Tesi – iWWAlarms
16
Precondizione: per poter usufruire di queste funzionalità l'utente deve essere connesso e
autenticato al server remoto.
Post-condizione: è possibile utilizzare ulteriormente l'applicazione
Use Case UC 4.1 – Dettaglio allarme
Illustrazione 9: UC4.1 – Dettaglio allarme
Caso d'uso: visione dettaglio allarmi
Sommario: visione dettagliata informazioni riguardanti:
•
Descrizione allarme
•
Area provenienza allarme
•
Data lancio allarme
•
Provider provenienza allarme
•
Nome completo allarme
•
Priorità allarme
•
Valore allarme
Attore: l'utente
Precondizione: per poter usufruire di queste funzionalità l'utente deve essere connesso e
autenticato al server remoto.
Post-condizione: è possibile utilizzare ulteriormente l'applicazione
Alberto Baggio
Tesi – iWWAlarms
17
Use Case UC6 – Statistiche allarmi attivi
Illustrazione 10: UC6 Statistiche allarmi attivi
Caso d'uso: visione statistiche allarmi attivi
Sommario: statistiche riguardanti:
•
Occorrenze allarmi per area, visualizzate con tre differenti grafici (Radar-plot, bar-graph,
pie-plot)
•
Occorrenze allarmi per descrizione, visualizzate con tre differenti grafici (Radar-plot, bargraph, pie-plot)
•
Distribuzione allarmi ultima settimana
•
Distribuzione allarmi ultime sette ore
Attore: l'utente
Precondizione: per poter usufruire di queste funzionalità l'utente deve essere connesso e
autenticato al server remoto.
Post-condizione: è possibile utilizzare ulteriormente l'applicazione
Use Case UC7 – Filtraggio allarmi
Caso d'uso: filtraggio allarmi attivi
Sommario: possibilità di filtrare gli allarmi attivi secondo i seguenti parametri:
•
Area provenienza
•
Descrizione allarme
Alberto Baggio
Tesi – iWWAlarms
18
•
Priorità allarme
•
Ora lancio allarme
Attore: l'utente
Precondizione: per poter usufruire di queste funzionalità l'utente deve essere connesso e
autenticato al server remoto.
Post-condizione: è possibile utilizzare ulteriormente l'applicazione
Illustrazione 11: UC7 - Filtro allarmi
Lista dei requisiti
Di seguito verranno elencati i requisiti emersi suddivisi per categoria (funzionali, di qualità,
d'ambiente). All'interno di ogni categoria verranno classificati per importanza (obbligatori,
desiderabili).
Requisiti funzionali
Requisiti funzionali obbligatori (RFO):
•
RFO1: gestione del push degli allarmi dall'oggetto server al dispositivo
•
RF02: visione degli allarmi attivi attraverso un sistema di paginazione che evidenzi:
•
RFO2.1: data e ora attivazione allarme
•
RFO2.2: nome (Description) allarme
•
RFO2.3: area sorgente allarme
•
RFO3: possibilità di visualizzare informazioni statistiche calcolare sullo storico degli
allarmi
•
RFO4: possibilità di effettuare il filtraggio degli allarmi secondo i seguenti parametri:
•
RFO4.1: descrizione allarme
Alberto Baggio
Tesi – iWWAlarms
19
•
•
•
RFO4.2: area provenienza allarme
•
RFO4.3: priorità allarme
•
RFO4.4: data e ora attivazione allarme
RFO5: visualizzazione dettagliata del singolo allarme con informazioni riguardo:
•
RFO5.1: data e ora attivazione allarme
•
RFO5.2: provider di provenienza dell'allarme
•
RFO5.3: area di provenienza dell'allarme
•
RFO5.4: tipologia allarme
•
RFO5.5: descrizione allarme
•
RFO5.6: indicazione numerica priorità
•
RFO5.7: valore allarme
•
RFO5.8: eventuale commento dell'utente che ha effettuato il riconoscimento
dell'allarme
•
RFO5.9: nome completo allarme
RFO6: visualizzazione statistiche riguardanti gli allarmi attivi:
•
•
•
•
RF06.1: distribuzione occorrenze allarmi per area visualizzata con tre differenti
grafici:
•
RFO6.1.1: pie-chart
•
RFO6.1.2: bar graph
•
RFO6.1.3: radar-plot
RF06.2: distribuzione occorrenze allarmi per descrizione visualizzata con tre
differenti grafici:
•
RFO6.2.1: pie-chart
•
RFO6.2.2: bar graph
•
RFO6.2.3: radar-plot
•
RFO6.3: distribuzione occorrenze allarmi ultima settimana
•
RFO6.4: distribuzione occorrenze allarmi ultime sette ore
RFO7: Impostazione parametri connessione:
•
RFO7.1: indirizzo IP oggetto server
•
RFO7.2: porta a cui connettersi
•
RFO7.3: nome utente per la login al server
•
RFO7.4: password per la login al server
RFO8: possibilità di salvare i filtri personalizzati
Requisiti funzionali desiderabili (RFD):
•
RFD1: gaussiana tempi riconoscimento degli allarmi salvati nello storico
Alberto Baggio
Tesi – iWWAlarms
20
Requisiti di qualità
Requisiti di qualità obbligatori:
•
RQO1: è garantito il funzionamento su iPhone iOS 3.1 o superiore
•
RQO2: il codice sorgente è corredato di documentazione
•
RQO3: saranno effettuate fasi di test corredate di documentazione
Le tabelle descriventi il tracciamento dei requisiti sono presenti in appendice.
Alberto Baggio
Tesi – iWWAlarms
21
Specifica
Alberto Baggio
Tesi – iWWAlarms
22
In questa sezione vera data una visione ad altro livello delle scelte progettuali che sono state
fatte nello sviluppo del prodotto. Prima di fare questo viene descritto il funzionamento del
servizio di push nel dispositivo iPhone (APNs, Apple Push Notification Service).
Apple Notification Service, APNs
APNs è un servizio messo a disposizione da Apple in grado di propagare informazione ad
iPhone, iPod, iPod Touch ed iPad. Questi dispositivi si registrano al servizio, stabilendo una
connessione IP protetta e ricevono le notifiche. Se una notifica arriva mentre l'applicazione non
è in esecuzione, il dispositivo avverte l'utente dei dati in attesa.
L'oggetto server aziendale, con cui l'applicazione scambia dati, invia le notifiche all'APNs,
questo effettua il push ai dispositivi interessati. Fra oggetto server ed APNs viene stabilita una
connessione socket persistente.
Connessione e comunicazione
Una notifica è un breve messaggio costituito da due parti: il token del dispositivo e
l'informazione (payload).
Il token è un codice che permette all'APNs di localizzare il dispositivo nel quale è installata
l'applicazione. Viene utilizzato anche per autenticare l'invio della notifica (solamente i provider
in sua conoscenza sono in grado inviare notifiche al dispositivo proprietario).
Illustrazione 12: Schema comunicazione APNs
La comunicazione avviene nel modo seguente:
•
Server e dispositivo stabiliscono una connessione con il servizio di notifica
•
Il dispositivo comunica al server il proprio token associato all'applicazione
•
L'oggetto server crea un pacchetto di notifica che include il token del dispositivo e
l'informazione
•
Questo pacchetto viene inviato al servizio APNs, che effettua il push al dispositivo con il
token comunicato. Da notare che l'iPhone OS del dispositivo mantiene una connessione
persistente con l'Apple Notification Service.
•
L'iPhone OS del dispositivo decodifica la notifica e determina se è presente
un'applicazione destinataria della notifica (potrebbe essere stata disinstallata nel
frattempo).
È presente un servizio di feedback che notifica al server quando l'invio di una notifica non va a
buon fine, in particolare è in grado di informare dell'eventualità che nel dispositivo sia stata
disinstalla l'applicazione.
JSON
JSON è un semplice protocollo per lo scambio dei dati basato su due strutture differenti: oggetti
ed array.
Un oggetto è una serie ordinata di coppie nome-valore (un dizionario). Inizia con '{' e finisce
Alberto Baggio
Tesi – iWWAlarms
23
con '}'. Ogni nome è seguito da ':' ed il valore associato. Le coppie nome-valore sono separate
da virgole.
Un array è una raccolta ordinata di valori, separati da virgole. Comincia con '[' e finisce con ']'.
Un valore può essere una stringa, un numero, un booleano o un oggetto o array annidato. Il
formalismo ed i caratteri di escape per le stringhe sono i medesimi del C.
Illustrazione 13: Oggetto JSON
Illustrazione 14: Array JSON
Formato del messaggio di notifica
Il pacchetto che costituisce la notifica push è un oggetto dizionario JSON. Le coppie del
dizionario descrivono: il messaggio di allerta, il numero da visualizzare nel badge
dell'applicazione (il pallino rosse che compare sopra l'icona) ed il suono di allerta da associarvi.
Il messaggio di allerta può essere una stringa o un dizionario contenente più elementi. Nel caso
in cui sia semplicemente una stringa, il testo inviato viene visualizzato in una finestra di allerta
contenente due pulsanti: 'annulla' o 'vedi'. Alla pressione del tasto vedi viene avviata
l'applicazione e passata la notifica.
Illustrazione 15: Formato messaggio di notifica
Se il messaggio è un dizionario, contiene diversi elementi: body, action-loc-key e loc-args. Il
campo body specifica il messaggio di allarme da visualizzare. Action-loc-key specifica il testo
da visualizzare nel pulsante 'vedi' della finestra di allarme; se impostato a null, apparirà un
unico tasto con impresso 'OK', la cui pressione comporta la chiusura della finestra senza il
Alberto Baggio
Tesi – iWWAlarms
24
lancio dell'applicazione. Loc-Key permette di impostare una stringa da visualizzare di default
all'occorrenza di un certo allarme. Loc-args permette di specificare una lista di argomenti da
associare a Loc-Key prima descritto.
La stringa binaria inviata è formata come in figura. Il primo byte identifica il comando; due byte
indicano la lunghezza del token; n byte rappresentano il token; altri due byte indicano la
lunghezza del carico utile; in coda è presente il carico utile. La lunghezza massima del carico
utile deve essere di 256 byte.
Illustrazione 16: Token Trust
Sicurezza
Per garantire la sicurezza vi sono due meccanismi che devono essere implementati: Connection
Trust e Token Trust.
Connection Trust consiste nell'utilizzo di un protocollo TSL di comunicazione
Token Trust serve per avere la sicurezza che il messaggio inviato sia ricevuto solamente dalla
propria applicazione e non sia intercettato. Per questo è il dispositivo che richiede un token, da
associare all'applicazione, all'APNs e dopo averlo ricevuto lo comunica all'oggetto server
aziendale, che lo utilizzerà nel push.
Scelte progettuali
La seguente sezione descrive le scelte progettuali che sono state adottate nella realizzazione
dell'applicazione.
Ad altissimo livello sono individuabili tre moduli separati e cooperanti fra loro:
•
un modulo che si occupa della connessione con il server remoto e dello scambio di dati
con questo;
•
un modulo che si occupa del salvataggio dei dati;
•
un modulo che si occupa del controllo e della visualizzazione.
Alberto Baggio
Tesi – iWWAlarms
25
Illustrazione 17: Visione ad alto livello - moduli
Modulo connessione
Questo modulo è stato importato dal progetto iCem ,applicazione sviluppata da Autoware.
Il modulo implementa le seguenti funzionalità:
•
stabilisce una connessione socket con il server, prelevando le informazioni riguardo
indirizzo IP, porta, utente e password dal file di configurazione option.plist, modificabile
dall'applicazione;
•
permette la disconnessione dal server;
•
permette il trasferimento di dati dal server, utilizzando il protocollo JSON-RPC (codificadecodifica i pacchetti);
•
registra il dispositivo all'APNs di Apple;
•
implementa la coda nella quale si registrano gli oggetti in attesa di Informazione dal
server;
•
definisce le varie tipologie di errore di connessione e le gestisce;
•
permette l'hashing del token del dispositivo prima dell'invio
Tracciamento
RFO1
RFO3
RFO7
Modulo Data Store
Il seguente modulo permette la memorizzazione locale degli allarmi scaricati dal server ed il
salvataggio dei filtri personalizzati creati dall'utente utilizzatore dell'applicazione.
Alberto Baggio
Tesi – iWWAlarms
26
Implementa le seguenti funzionalità:
•
salvataggio e lettura allarmi attivi, scaricati dall'oggetto remoto;
•
permette l'interrogazione e la modifica del database nel quale sono salvati i filtri
personalizzati creati dall'utente;
•
permette il salvataggio di filtri personalizzati;
•
fornisce accesso ad una lista di 100 colori utilizzati per disegnare i grafici
Tracciamento
RFO2
RFO4
RFO8
Modulo Controllo-Visualizzazione
Questo modulo implementa le componenti che costituiscono l'interfaccia dell'applicazione, e le
componenti che ne implementano la logica di controllo.
Implementa visualizzazione e controllo delle seguenti funzionalità:
•
visualizzazione allarmi attivi;
•
filtraggio allarmi attivi attraverso parametri decidibili;
•
salvataggio e applicazione filtri personalizzati;
•
visualizzazione di statistiche e grafici riguardanti gli allarmi;
•
impostazione dei parametri di connessione.
Tracciamento
RF02
RFO3
RFO4
RFO5
RFO6
RFO7
Alberto Baggio
Tesi – iWWAlarms
27
Definizione di prodotto
Alberto Baggio
Tesi – iWWAlarms
28
Illustrazione 18: Diagramma Classi - prima parte
Alberto Baggio
Tesi – iWWAlarms
29
Pattern
Illustrazione 19: Diagramma Classi - seconda parte
Nella progettazione del software è stato utilizzato il pattern MVC, nell'implementazione sono
stati adottati i pattern Observer e Singleton.
•
L'utilizzo del pattern Model View Controller è vincolato dalla struttura stessa
dell'ambiente di sviluppo, tool come Interface Builder impongono l'aderenza a questo
modello. Data la suddivisione dei componenti in conformità a MVC, verranno descritti
seguendo questa catalogazione.
•
Il pattern Observer è utilizzato implicitamente dal sistema di notifica fornito dalla classe
NSNotificationCenter (visibile in figura). Ricevuta una notifica NSNotificationCenter la
propaga a tutti gli oggetti registrati su questa (Observer Object), in questo modo
produce un aggiornamento dello stato di tali oggetti.
Illustrazione 20: NSNotificationCenter
Alberto Baggio
Tesi – iWWAlarms
30
•
E' stato adottato il pattern Singleton in modo da avere un'unica istanza per le classi che
lo necessitano. Le classi che si è scelto rendere Singleton sono: StoreAllarmiAttivi,
DownloadAllarmiAttivi, ServerConnection, DataBase e Filters.
L'invocazione [nomeClasse condivisa] ritorna il riferimento all'unica istanza della classe.
Illustrazione 21: Diagramma di sequenza - scaricamento allarmi
Alberto Baggio
Tesi – iWWAlarms
31
Model
DownloadAllarmiAttivi
DownloadAllarmiAttivi, classe Singleton che estende NSObject. Si occupa di effettuare lo
scaricamento ed il salvataggio (utilizzando StoreAllarmiAttivi) degli allarmi attivi.
Utilizza la classe classe Singleton ServerConnection, per comunicare con il Server e scaricare i
dati. ServerConnection attraverso le classi Json e Json-RPC invoca nel server remoto il metodo
getActiveAlarm. Dopo aver ricevuto il pacchetto di dati in risposta, ServerConnection effettua il
parsing e successivamente passa i dati al metodo delegato alla loro gestione, in questo caso (void) storeAllarmiAttivi della classe stessa.
Il pacchetto ritornato dal server in risposta alla richiesta di scaricamento degli allarmi attivi è
così strutturato:
Chiave
Informazione
acessName
Nome dell'oggetto che ha lanciato l'errore nel server remoto
ackComment
Se presente, commento inserito dall'operatore
effettuato il riconoscimento dell'allarme
ackOperatorName
Se presente, nome dell'operatore
riconoscimento dell'allarme
alarmClass
Tipologia di allarme
cookie
Indice incrementato ad ogni transizione di stato dell'allarme
description
Descrizione dell'allarme
dstBias
che
ha
che
effettuato
ha
il
–
fileTime
Ora in cui si è attivato l'allarme
GroupName
Area di provenienza
guid
Codice univoco che identifica l'allarme
limit
Soglia oltre la quale viene attivato l'allarme
localTimeBias
Fuso orario dell'impianto industriale nel quale è emerso
l'allarme
nodeName
Nome del nodo da cui è partito l'allarme
operatorName
Nome operatore delegato alla gestione/manutenzione
dell'impianto/macchinario dal quale è partito l'allarme
priority
Priorità dell'allarme
quality
-
selected
-
state
Stato dell'allarme (riconosciuto/non riconosciuto)
transition
Stato precedente
type
Livello di allerta dell'allarme, classificato secondo la scala:
Hi, HiHi, HiHiHi, Lo, LoLo, LoLoLo
user1
-
user2
-
Alberto Baggio
Tesi – iWWAlarms
32
Chiave
Informazione
user3
-
value
Indica il fatto che l'allarme è attivo (sempre true)
Campi dati:
•
NSDate* oraScaricamento: ora dell'ultimo scaricamento degli allarmi
Metodi:
•
+(DownloadAllarmiAttivi*) condivisa: ritorna il riferimento all'unica istanza della classe.
•
-(void) downloadAllarmi: effettua la richiesta di scaricamento degli allarmi al server
remoto. Associa il metodo -(void)storeAllarmi, della classe stessa, come delegato a
ricevere il pacchetto di dati inviato in risposta.
•
-(void) storeAllarmi: memorizza i dati ricevuti dal server remoto utilizzando la classe
Singleton StoreAllarmiAttivi.
•
-(NSDate*) getOraScaricamento: ritorna l'ora dell'ultimo scaricamento degli allarmi.
In modo più dettagliato i passaggi (visibili nel diagramma di sequenza soprastante) che
conducono allo scaricamento ed al salvataggio dei segnali sono i seguenti:
1. DownloadAllarmiAttivi invoca getActiveAlarms del Singlet ServerConnection
2. ServerConnection crea la richiesta conforme
createRequest(getActiveAlarms) di Json-RPC
al
protocollo
Json
invocando
3. DownloadAllarmiAttivi registra il metodo storeAllarmi, della classe stessa, come
responder associato alla richiesta. RequestResponder è la classe che gestisce la
selezione dei metodi in risposta all'arrivo dei pacchetti
4. ServerConnection
AsyncSocket.
invoca
il
metodo
writeData(richiesta)
della
classe
Singleton
5. WriteData invoca in remoto, sul canale socket, il metodo getActiveAlarms dell'oggetto
Server remoto
6. Ricevuto il pacchetto di risposta, Json-RPC ne effettua il parsing e lo invia a
RequestResponder che lo inoltra al metodo delegato alla sua gestione, nella fattispecie
storeAllarmi di DownloadAllaAttivi
7. StoreAllarmi memorizza i dati utilizzando la classe StoreAllarmiAttivi
StoreAllarmiAttivi
StoreAllarmiAttivi, classe Singleton che estende NSObject. Permette la memorizzazione degli
allarmi attivi. I dati relativi gli allarmi sono salvati in singoli array, contenuti all'interno del
vettore attributiAllarmi.
Tutte le classi che necessitano di informazioni sugli allarmi (per la visualizzazione o
l'elaborazione) utilizzano l'unica istanza di questa classe. DownloadAllarmiAttivi, dopo aver
scaricato gli allarmi, utilizza StoreAllarmiAttivi per memorizzare i dati.
Per completezza è presente una tabella che descrive l'ordinamento dei dati all'interno dei
Alberto Baggio
Tesi – iWWAlarms
33
vettori.
Informazione
Posizione
AccesName
0
attribute_id
1
Description
2
Priority
3
Value
4
GroupName (Area)
5
CheckValue (Soglia)
6
Provider
7
MilliSec (sempre 0)
8
fileTime (alarm Date)
9
Type
10
SubType (sempre 0)
11
guid
12
Campi Dati:
•
NSMutableArray* attributiAllarmi: memorizza i vettori contenenti le informazioni relative
gli allarmi
Metodi:
•
+(StoreAllarmiAttivi*) condivisa: ritorna il riferimento all'unica istanziazione della classe
•
-(void) svuotaArray: svuota l'array degli allarmi. E'invocato ogni volta che vengono
scaricati gli allarmi aggiornati, prima del salvataggio di questi
•
-(void) addArrayAttributi:(NSArray*)attributi: aggiunge al vettore degli allarmi l'allarme
passato
•
-(NSArray*) getArrayAttributi:(int) indiceAllarme:
informazioni relative l'allarme richiesto
•
-(NSDate*) getDateByAlarm:(int) indiceAllarme: ritorna l'ora per l'allarme richiesto come
oggetto [NSDate]
•
-(NSString*) getNomeByAlarm:(int) indiceAllarme: ritorna la descrizione per l'allarme
richiesto
•
-(NSString*) getAreaByAlarm:(int) indiceAllarme: ritorna il nome dell'area di provenienze
dell'allarme richiesto
•
-(NSString*) getPriorityByAlarm:(int) indiceAllarme: ritorna la priorità per l'allarme
richiesto
•
-(NSString*) getMillisecByAllarm:(int) indiceAllarme: ritorna il tempo di ack per l'allarme
ritorna
l'array
contenente
le
Alberto Baggio
Tesi – iWWAlarms
34
richiesto
•
-(NSString*) getValueByAlarm:(int) indiceAllarme: ritorna il valore dell'allarme richisto
•
-(NSString*) getTimeByAlarm:(int) indiceAllarme: ritorna l'ora per l'allarme richiesto in
formato stringa [giorno/mese/anno ore:minuti:secondi +fusoOrario]
•
-(NSString*) getProviderByAlarm:(int) indiceAllarme: ritorna il Provider dell'allarme
richiesto
•
-(NSString*) getCheckValueByAlarm:(int) indiceAllarme: ritorna il valore di soglia oltre il
quale si attiva l'allarme
•
-(NSString*) getFullNameByAlarm:(int) indiceAllarme: ritorna il nome intero dell'allarme
che lo identifica in modo univoco all'interno dello stabilimento
•
-(int) getNumeroAllarmi: ritorna il numero totale di allarmi attivi presenti
DataBase
DataBase, classe Singleton che estende NSObject. Attraverso il wrapper (sqllite3/Objective-C)
FmDb permette l'interrogazione e la modifica del database filtri.db, contenente i filtri
personalizzati dell'utente utilizzatore dell'applicazione.
Il database filtri.db è cosi strutturato:
Illustrazione 22: Database filtri.db
Campi dati:
•
FMDatabase* db: riferimento ad un oggetto del wrapper FmDb che permette
l'interfacciamento con il database
•
NSString* filterToDisplay: filtro selezionato
Metodi:
•
-(void) creazioneDatabase: apre il database filtri.db
•
-(FMResultSet*) queryDo:(NSString*) textQuery: effettua la query passata e ritorna il
risultato come un oggeto di tipo FMResultSet* (classe definita nel wrapper FmDb)
•
-(void) deleteDo:(NSString*) textQuery: effettua query che modificano lo stato del
Alberto Baggio
Tesi – iWWAlarms
35
database.
•
-(void) setDisplayFilter:(NSString*)filtro: imposta il nome del filtro che selezionato al
momento
•
-(NSString*) getDisplayFilter: ritorna il nome del filtro selezionato
•
-(void) open: apre il database
•
-(void) close: chiuede il database
RandomColor
RandomColor, estende NSObject. Rappresenta un array di 50 colori, utilizzati per disegnare i
grafici delle statistiche sugli allarmi. Presenta un unico metodo statico, +
(UIColor*)randomColor:(int)numeroAllarme, che ritorna un colore dato la sua posizione.
Filters
Filters, singleton che estende NSObject. Effettua il filtraggio degli allarmi attraverso i filtri
salvati nel database filtri.db o attraverso filtri i cui parametri sono stati impostati al momento.
Dopo aver letto i dati memorizzati in StoreAllarmiAttivi, ne effettua il filtraggio e memorizza i
dati su di un array temporaneo. Filters permette di catalogare gli allarmi in base all'area, alla
descrizione, alla priorità e all'ora.
Campi Dati:
•
int minPriority: rappresenta la priorità minima attualmente impostata per il filtraggio
•
int maxPriority: rappresenta la priorità massima attualmente impostata per il filtraggio
•
NSDate* minDate: rappresenta l'ora minima attualmente impostata per il filtraggio
•
NSDate* maxDate: rappresenta l'ora massima attualmente imposta per il filtraggio
•
NSMutableArray* afterFilter: array dinamico che contiene temporaneamente gli allarmi
che hanno superato i parametri impostati.
Metodi:
•
-(void) makeFiltering: (NSArray*)desc aree:(NSArray*)ar minPrio: (int)prioMin maxPrio:
(int)prioMax: salva nell'array afterFilter gli allarmi che soddisfano i parametri passati.
Desc, contiene i nome delle descrizioni, ar i nomi delle aree. MinPrio e maxPrio sono
rispettivamente la priorità massima e la priorità minima per le quali filtrare.
•
-(NSArray*) getAfterFilter: ritorna l'array contenente gli allarmi che soddisfano i
parametri impostati
•
-(NSMutableArray*) getElencoDescrizioni: ritorna un vettore contenente i valori di tutte
le descrizioni presenti fra gli allarmi attivi
•
-(NSMutableArray*) getElencoAree: ritorna un vettore contenente i valori di tutte le aree
presenti fra gli allarmi attivi.
Alberto Baggio
Tesi – iWWAlarms
36
View
Classi che disegno i grafici:
Le classi PieChart, Radar, BarGraph e Distribuition estendono UIView e permettono il disegno
rispettivamente dei grafici a torta, dei radar plot, dei grafici a barre e delle distribuzioni di
occorrenze degli allarmi.
Tutte definiscono i metodi:
•
-(void)drawRect:(CGRect)rect: disegna i grafici, utilizzando le funzioni definiti in
CoreGraphics, libreria di Cocoa.
•
-(void) touchesBegan:(NSSet*)touches withEvent:(UIEvent)event: identifica la porzione
di grafico. Se è un PieChart sposta all'esterno la fetta selezionata, se è un bar-plot
evidenzia la porzione selezionata, se è un radar-plot ruota il grafico affinché l'area
selezionata sia centrata sulla lancetta di identificazione.
Fatto questo, invoca il metodo della superView (PieTouch) delegato alla gestione del
tocco
Per identificare la porzione di grafico selezionata viene calcolato l'angolo formato fra la semiretta, limitata dal punto premuto e il centro del grafico, e la semi-retta limitata dal centro del
grafico e il punto (0,0).
Tutte le classi che ereditano da queste si limitano a disegnare il grafico a torta, a barre, radar o
distribuzioni di un particolare dato statistico.
Illustrazione 23: Area
selezionata
I grafici a torta e i grafici a barre danno una falsa illusione di tridimensionalità attraverso uno
schiacciamento dell'immagine; il rapporto ascisse/ordinate è di due a uno.
Alberto Baggio
Tesi – iWWAlarms
37
Gestori touch utente
I pie-chart, radar-plot
e bar-graph al tocco dell'utente visualizzano i dati relativi
all'area/descrizione selezionata. L'evento sollevato quando avviene il tocco è gestito dalla
classe PieTouch.
PieTouch che estende UIView, definisce il metodo:
•
-(void) touchesBegan:(NSSet*)touches withEvent:(UIEvent)event: identifica la porzione
di grafico selezionata dall'utente e ne visualizza le informazioni.
I restanti oggetti che costituiscono l'interfaccia grafica sono stati creati con l'interface Builder;
questi non verrano descritti. Ogni oggetto grafico è associato ad un corrispettivo controller.
Nell'immagine sottostante è visibile com'è strutturato uno degli oggetti grafici che permettono
la visualizzazione dei grafici.
Illustrazione 24: Grafici
Alberto Baggio
Tesi – iWWAlarms
38
Controller
Nella figura sottostante è visibile come è organizzata la navigazione e di conseguenza i
controller delle interfacce grafiche all'interno dell'applicazione.
All'avvio viene impostato come controller radice un oggetto rootController. L'oggetto grafico di
rootController presenta una scrollView contenente quattro pagine distribuite orizzontalmente;
ognuna di questa rappresenta una sezione differente ed ha associato un controller proprio.
Ogni sezione è accoppiata ad un'icona presente nella barra inferiore.
Nella sezione riguardante le statistiche sono visualizzabili i grafici, ognuno di questi è associato
Illustrazione 25: Gerarchia viste
ad un controller personalizzato.
Verrano documentate solamente le classi controller ritenute interessanti.
iAlarmsAppDelegate
iAlarmsAppDelegate è il delegato dell'applicazione, estende NSObject ed implementa
l'interfaccia UIApplicationDelegate.
Ridefinisce i seguenti metodi dell'interfaccia:
•
-(BOOL)application:(UIApplication*)application
didFinishLaunchingWith
Options:
(NSDictionary*) launchOptions: metodo invocato al lancio dell'applicazione. Effettua la
Alberto Baggio
Tesi – iWWAlarms
39
seguente sequenza di operazioni:
•
Alloca il rootController ed imposta la vista a questo associata come
dell'applicazione.
main View
•
Alloca la Singleton ServerConnection e procede alla connessione con il server
•
Se la connessione va a buon termine effettua lo scaricamento degli allarmi (questo
produce l'allocazione delle Singleton DownloadAllarmiAttivi e StoreAllarmiAttivi)
•
Infine procede alla visualizzazione.
RootController
RootController, che estente UIViewController, è il controller della schermata principale dell'app.
L'oggetto grafico accoppiato è RootController.xib, questo presenta una ScrolView e una serie di
icone oguna accoppiata ad una delle quattro sezioni presenti (allarmi attivi, filtri, statistiche,
settings). La scrollView contiene le quattro MainView dei quattro controller delle sezioni.
RootController definisce il delegato della ScrollView e ridefinisce il metodo -(void)ViewDidLoad
ereditato da UIViewController.
Metodi:
•
-(void)ViewDidLoad: inizializza i controller delle quattro sezioni e inserisci all'interno
della ScrollView le viste associate a questi controller.
•
-(IBAction) select:(id) sender: azione lanciato alla pressione di una delle icone, sposta
la scrollView nella vista relativa alla sezione selezionata
•
-(void)scrollViewDidEndDeclerating:(UIScrolView*)sender: invocato quando l'utente
scorre la ScrollView, effettua il traslamento di questa in modo discreto e non continuo,
in modo tale la visualizzazione passi da una sezione all'altra.
Page
Estende UIViewController. E' il controller della sezione che visualizza gli allarmi attivi. Presenta
un'unica ScrollView verticale all'interno della quale vengono visualizzati in pagine da 4 gli
allarmi.
Metodi:
•
-(void)viewDidLoad: inizializza la vista e registra l'oggetto nella lista che notifica
l'avvenuto scaricamento degli allarmi, associando come metodo delegato alla risposta (void)ricevutiAllarmi della classe stessa
•
-(void)ricevutiAllarmi: invocato in seguito alla notifica di scaricamento dei nuovi allarmi.
Alloca ed inserisce nella scrollView le pagine destinate alla visualizzazione degli allarmi
(oggetti di tipo ContPage). Il numero di pagine visualizzate è dato dal numero totale
degli allarmi diviso quattro ed arrotondato per eccesso. Ad ogni inserimento di una
pagina viene aggiornata la progressBar, eseguendo il metodo -(void)modifica in
background. Ad ogni nuovo scaricamento la ScrollView viene svuotata e riempita
nuovamente.
•
-(void)visualizzaDettaglio: visualizza il dettaglio del singolo allarme selezionato; fa
questo, allocando e visualizzando un oggetto di tipo DettaglioAllarme.
•
-(IBAction)aggiorna:(id)selector:
invocato
al
pressione
del
tasto
che
richiede
Alberto Baggio
Tesi – iWWAlarms
40
l'aggiornamento degli allarmi. Controlla che il dispositivo sia connesso al server ed
effettua
lo
scaricamento
invocando
downloadAllarmi
della
Singleton
DownloadAllarmiAttivi.
•
-(void) modifica: aggiorna l'avanzamento della progressBar
•
-(void)setLog: aggiorna lo stato della finestra che stampa il log delle operazioni di
connessione e scaricamento
ContPage
Estende UIViewController. Gestisce le pagine che visualizzano gli allarmi attivi in gruppi di
quattro. Preleva i dati dalla Singleton StoreAllarmiAttivi e li visualizza.
ControllerQuartaVista
Estende UIViewController e definisci il delegato della tabella che permette l'impostazione dei
parametri di filtraggio. Permette il filtraggio degli allarmi attivi utilizzando filtri creati al
momento o i filtri personalizzati salvati nel database filtri.db.
Campi dati:
•
NSMutableArray *areeSelezionate: elenco delle aree selezionata da includere nei
parametri per cui filtrare
•
NSMutableArray *descSelezionate: elenco delle descrizioni scelte da includere
parametri per cui filtrare
nei
Metodi:
•
- (IBAction) saveFilters: invocato quanto l'utente digita il pulsante save nella view
definita da controllerQuartaVista.xib. Permette il salvataggio delle impostazioni di
filtraggio selezionate attribuendo un nome al filtro appena creato. Dopo aver controllato
che il nome digitato non sia vuoto e non sia già presente, inserisce il nuovo filtro nel
database.
•
-(IBAction) showFilter: (id) selector: invocato quando l'utente preme il pulsante show,
visualizza gli allarmi che soddisfano i parametri impostati. Effettua le seguenti
operazioni:
•
Invoca il metodo [(void) makeFiltering: (NSArray*) desc aree: (NSArray*) ar minPrio: (int)
prioMin maxPrio: (int)prioMax ] della classe Singleton Filters. Questo effettua il filtraggio
e alloca l'array contenente gli allarmi filtrati.
•
Alloca un oggetto di tipo viewFilterResult che visualizza gli allarmi
•
-(void) showSaveFilter: (id) selector: alloca un oggetto saveFilters che visualizza i filtri
personalizzati salvati nel database
•
-(BOOL) descSel: (NSString *) desc: ritorna TRUE se la descrizione passata è fra quelle
selezionate nell'apposita tabella
•
-(BOOL) areaSel: (NSString *) area: ritorna TRUE se l'area passata è fra quelle
selezionate nell'apposita tabella
•
-(void) descSelRemove:(NSString *)desc: rimuove la descrizione passata dall'elenco
delle descrizioni selezionate dall'utente
Alberto Baggio
Tesi – iWWAlarms
41
•
-(void) areaSelRemove:(NSString *)desc: rimuove l'area passata dall'elenco delle aree
selezionate dall'utente
Delegato tabella, metodi rilevanti:
•
(void)tableView:(UITableView *) tableView didSelectRowAtIndexPath:(NSIndexPath *)
indexPath: invocato quando viene selezionata una riga della tabella che permette
l'impostazione dei parametri di filtraggio. L'azione effettuata dipende dalla sezione a cui
appartiene la riga selezionata [descrizioni, aree, priorità e data]. Se la sezione è la zero
(descrizioni), controlla lo stato della descrizione selezionata, se spuntata (graficamente
è visibile un checkmark), toglie la spunta e la rimuove dall'array delle discrezioni
selezionate, viceversa aggiunge il checkmark e l'aggiunge all'array. Nel caso in cui la
sezione sia la uno (aree), il comportamento è uguale alla sezione prima, con la modifica
dell'array delle aree al posto di quello delle descrizioni. Se la sezione è la due, la
gestione dell'evento è definita da setPriorityCell, essendo questa una cella
personalizzata. Infine quando la riga digitata appartiene alla quarta sezione (data) viene
aggiunto in coda al navigationViewController, e visualizzato, un viewController di tipo
DataSetFilter.
DettaglioAllarme
Estende UIViewController. Visualizza le informazioni dettagliate relative ad un singolo allarme. I
dati visualizzati vengono prelevati dalla Singleton StoreAllarmiAttivi.
ViewFilterResult
Estende UIViewController. Visualizza l'elenco degli allarmi dopo che è stato effettuato un
filtraggio. Ottieni i dati dalla classe Singleton Filters.
SaveFilters
Estende UIViewController. Visualizza l'elenco dei filtri personalizzati salvati nel database, inoltre
ne permette la modifica, l'aggiunta e la rimozione. Qui è definito il delegato della tabella che
visualizza i filtri.
Campi dati:
•
NSMutableArray* elencoFiltri: contiene l'elenco dei filtri salvati nel database
•
BOOL deleteMode: impostato a YES se si è in modalità di modifica, nella quale la
selezione di un filtro dall'elenco, comporta la sua eliminazione e rimozione dal database.
La modalità è abilitata/disabilitata dalla pressione del tasto [Delete] della view definita
da [SaveFilters.xib].
Metodi:
•
-(void) viewDidLoad: inizializza l'array elencoFiltri, interrogando il database riguardo i
filtri salvati ([“select nome from filter”).
•
-(IBAction)Delete: invocata alla pressione del tasto [Delete], imposta la variabile
Alberto Baggio
Tesi – iWWAlarms
42
[deleteMode] all'opposto dell'attuale valore e ricarica la tabella con l'elenco dei filtri.
•
-(IBAction)Add: (id) sender: invocato dopo la pressione del tasto [new]. Aggiunge un
nuovo filtro personalizzato al database. Prima di fare ciò, controlla che il nome inserito
nell'apposito spazio non sia vuoto. Per inserire il nuovo filtro utilizza la Singlton
DataBase, in particolare invoca il metodo -(void)deleteDo:(NSString*)query che
permette di applicare query che modificano lo stato del database. Infine ricarica la
tabella in modo che sia visualizzato anche il nuovo filtro inserito.
Delegato tabella:
•
(void)tableView: (UITableView *) tableView didSelectRowAtIndexPath: ( NSIndexPath * )
indexPath: invocato quando viene selezionato un filtro della tabella. Se [deleteMode] è
impostato a YES, elimina il filtro dalla tabella e dal database. Se impostato a NO
visualizza un oggetto di tipo MyFiltersDisplay, che permette la modifica e l'applicazione
del filtro selezionato.
MyFilterDisplay:
Estende UIViewController. Gestisce la visualizzazione la modifica e l'applicazione di un filtro
personalizzato salvato nel database filtri.db.
Le restanti classi che estendo UIViewController non presentano caratteristiche
interessante, perciò ne verra omessa la descrizione.
Elenco file:
CLASSE
DESCRIZIONE
MODEL
RandomColor
Lista 50 colori
DataBase
Interfacciamento con database filtri.db
Filters
Filtraggio allarmi
Json-RPC
(sviluppata
Piccolo)
Ing.
Andrea
Parsing/creazione richieste protocollo JSon-RPC
StoreAllarmiAttivi
Store allarmi attivi
DownloadAllaAttivi
Effettua lo scaricamento degli allarmi attivi
ServerConnection
Stabilisce, mantiene e gestisce la connessione con il server
(Sviluppata da Ing Andrea remoto
Piccolo)
RequestResponder
Lista degli oggetti in attesa di risposta remota
(Sviluppata da Ing Andrea
Piccolo)
AsyncSocket
Stabilisce la connessione socket, ed effettua l'invio/ricezione
(sviluppo
Dustion
Voss dell'informazione
code.google/p/cocoaasyncs
Alberto Baggio
Tesi – iWWAlarms
43
CLASSE
DESCRIZIONE
ocket)
VIEW
PieChart
Grafico a torta
Effetto3d
Grafico a torta della distribuzione di allarmi per aree
Effetto3dDesc
Grafico a torta della distribuzione di allarmi per descrizione
Radar
Grafico radar (TODO)
RadarArea
Grafico radar-plot della distribuzione di allarmi per area
RadarDesc
Grafico radar-plot della distribuzione di allarmi per descrizione
PieTouch
Gestore touch grafici (TODO)
GestoreTouch
Gestore touch vari grafici distribuzione aree
DescTouch
Gestore touch
rinominare)
BarGraph
Grafico a barre (TODO)
BarGraphArea
Grafico a barre distribuzione di allarmi per area
BarGraphDesc
Grafico a barre distribuzione di allarmi per descrizione
Distribuition
Grafico distribuzione occorrenze allarmi (TODO)
WeekOcc
Grafico distribuzione occorrenze allarmi ultima settimana
LastiSixHoursOcc
Grafico distribuzione occorrenze allarmi ultime 7 ore
vari
grafici
distribuzione
descrizioni
(da
CONTROL
Grafici
Controller grafici
ControllerBarArea
Controller grafico a barre distribuzione allarmi per area
ControllerBarDesc
Controller grafico a barre distribuzione allarmi per descrizione
ControllerWeekOcc
Controller
settimana
ControllerLastSixHours
Controller grafico distribuzione occorrenze allarmi ultime 7 ore
ControllerSecondaVista
Controller grafico a torta distribuzione allarmi per area
ControllerPieChartDesc
Controller grafico a torta distribuzione allarmi per descrizione
ControllerRadarAree
Controller radar-plot distribuzione allarmi per area
ControllerRadarDesc
Controller radar-plot distribuzione allarmi per descrizione
RootController
Controller vista principale applicazione
Page
Controller sezione allarmi attivi
ControllerQuartaVista
Controller sezione filtri
ControllerStats
Controller sezione statistiche
ControllerSettings
Controller sezione impostazione parametri connessione
ContPage
Controller pagine visualizzazione allarmi attivi
DettaglioAllarmi
Controller visualizzazione dettaglio singolo allarme
grafico
distribuzione
occorrenze
allarmi
ultima
Alberto Baggio
Tesi – iWWAlarms
44
CLASSE
DESCRIZIONE
SaveFilter
Controller visualizzazione/modifica/rimozione/
personalizzati
aggiunta
ViewFilterResult
Controller visualizzazione risultati filtraggio
MyFilterDisplay
Controller modifica/applicazione filtro personalizzato
SetDateFilterMax
Controller cella per impostazione data massima
DatSetFilter
Controller cella per impostazione data minima
MyFilterDisplayAdd
Controller aggiunta parametri filtro personalizzato
filtri
SLOC
http://cloc.sourceforge.net v 1.51 T=3.0 s (55.3 files/s, 6471.7 lines/s)
------------------------------------------------------------------------------Language
files
blank
comment
code
------------------------------------------------------------------------------Objective C
83
3068
2747
10312
C/C++ Header
83
713
1344
1231
------------------------------------------------------------------------------SUM:
166
3781
4091
11543
ToDo
Mancano da sviluppare la gestione del Push e la visualizzazione e connessione con lo storico
degli allarmi
Il push è già predisposto per essere implementato, basta abilitare il push nel delegato
dell'applicazione e nell'oggetto server remoto. Quando verrà ricevuto una notifica push
l'applicazione dovrà scaricare
Lo storico è previsto venga sviluppato come modulo se stante. Basterà aggiungere un
controller nella Scroll di rootController per accedere alla nuova sezione.
Alberto Baggio
Tesi – iWWAlarms
45
Conclusioni
Alberto Baggio
Tesi – iWWAlarms
46
Illustrazione 26: Pianificato
Illustrazione 27: Effettivo
Alberto Baggio
Tesi – iWWAlarms
47
Risultato
Gli obbiettivi iniziali sono stati soddisfatti. L'applicazione è in fasei di completamento, vi è
ancora da implementare la sezione che visualizza statistiche calcolate sullo storico. Per fare
questo è neccessario intervenire anche sull'oggetto serie, infatti non è ipotizzabile che il client
si scarichi tutti gli allarmi sollevati da una certa data e calcoli le statistiche su questi,
l'operazione sarebbe troppo onerosa; bensì è l'oggetto server che giornalmente deve fare dei
report contenenti le statistiche del giorno. In questo modo se si vogliono dati statistici su di un
lungo intervallo, ci si limita a calcolare prendento un dato al giorno, anziché tutti gli allarmi del
giorno. Sostenzialmente a differenza degli allarmi attivi, per le statistiche riguardanti lo storico
degli allarmi, la computazione è effettuata lato server.
Illustrazione 28: Computazione statistiche
Inoltre deve ancora essere attività la gestione del push, per questa vi sono da sistemare ancora
alcuni aspetti lato server per la gestione dei certificati; mentre il client è già predisposto per la
gestione.
Durante lo sviluppo dell'applicazione sono stati effettuati svariati test tesi a verificare il corretto
funzionamento dell'applicazione in casi limiti come: il sovraccarico del server, l'invio di
pacchetti vuoti o errati, la mancanza di connessione. Il testing finale e completo
dell'applicazione è ancora in fase di completamento. Non ho potuto occuparmene per la
mancanza di tempo e perchè l'applicazione non è completa.
Il prossimo mese (novembre) a Los Angeles verrà presentata una versione Beta
dell'applicazione. Entro due mesi l'applicazione verrà inviata ad Apple per l'iter di approvazione
e seguente distribuzione su Apple Store.
E' previsto il futuro rilascio dell'applicazione anche per sistema operativo Windows phone 7.
Chiaramente il client dovrà essere svilupppato nuovamente, non essendo portabile in ambiente
windows.
Scostamento rispetto a quanto pianificato
Come visibile dal confronto fra i due Gant soprastanti, vi sono stati diverse differenze fra ciò
che si è fatto e ciò che era pianificato.
I motivi sono i seguenti:
•
La progettazione del modulo che permette la comunicazione fra server e dispositivo non
è stata necessaria, è stata importata dal progetto iCem.
Alberto Baggio
Tesi – iWWAlarms
48
•
Le ferie sono state distribuite diversamente da quanto inizialmente pianificato, una sola
settimana a ferragosto invece di due
•
La fase di codifica ha richiesto una settimana in più del previsto
•
Non è stato possibile effettuare la fase di test conclusiva (comunque durante lo sviluppo
sono state effettuate svariati test). Questa verrà effettuata a partire da meta ottobre.
Riassuntivo ore
Attività
Ore
Studio
56
Analisi/Specifica/Progettazione
60
Codifica
180
Validazione/Revisione/Accettazione
40
Esperienza maturata
Sviluppare iWWAlarms è stato molto utile e costruttivo per svariati motivi: ho imparato un
nuovo linguaggio, ho dovuto affrontare diverse problematiche da solo, mi sono dovuto
integrare in un progetto già avviato.
La cosa che ritengo più utile è stato il fatto di dover pensare e sviluppare un'intera applicazione
dall'inizio alla fine da solo.
Lo sviluppo iPhone è stato piacevole, il kit di sviluppo è ben strutturato. L'unica cosa che non
mi ha pienamente soddisfatto è la gestione un po' contorta della memoria in Objective-C.
Miglioramenti
Il supporto che maggiormente mi è mancato nello sviluppo dell'applicazione è stato quello di
un grafico di professione. Trovarsi a pensare la grafica di un'applicazione, senza avere la
neccessaria esperienza, è risultato un po' frustrante a volte. Nonostante questo il risultato
estetico finale è gradevole, anche se potrebbe essere decisamente più accativante.
Una aspetto che difficilmente potrà essere migliorato è il fatto che i grafici tridimensionali su
iPhone 3g, con OS precedente al 3.2, hanno le animazioni leggermente rallentate; su iPhone 4g
funziona tutto perfettamente
Se avessi avuto più tempo sarebbe stato bello ampliare l'insieme delle statistiche visualizzabili
e migliore la precisione della barra che indica lo stato di scaricamento degli allarmi.
Alberto Baggio
Tesi – iWWAlarms
49
Appendice
Alberto Baggio
Tesi – iWWAlarms
50
Elenco Requisiti
REQUISITO
DESCRIZIONE
RFO1
Gestione push allarmi
RFO2
Visione allarmi attivi attraverso un sistema di paginazione che
evidenzi
RFO2.1
Date e ora attivazione
RFO2.2
Nome (Description) allarme
RFO2.3
Area sorgente allarme
RFO3
Possibilità di ricevere informazioni storiche riguardo gli allarmi
RFO4
Possibilità di effettuare il filtraggio degli allarmi secondo i
parametri:
RFO4.1
Descrizione allarme
RFO4.2
Area di provenienza allarme
RFO4.3
Priorità allarme
RFO4.4
Data
RFO5
Visualizzazione dettagliata del singolo allarme, con informazioni
riguardo:
RFO5.1
Data e ora attivazione allarme
RFO5.2
Provider di provenienza
RFO5.3
Area di provenienza
RFO5.4
Tipologia allarme
RFO5.5
Descrizione allarme
RFO5.6
Indicazione numerica priorità
RFO5.7
Valore allarme
RFO5.8
Eventuale commento dell'utente che ha effettuato l'ack
RFO5.9
Nome completo allarme
RFO6
Visualizzazione statistiche riguardanti gli allarmi
RFO6.1
Distribuzione occorrenze allarmi per area visualizzata con tre
differenti grafici:
RFO6.1.1 Pie-Chart
RFO6.1.2 Bar-Graph
RFO6.1.3 Radar-plot
RFO6.2
Distribuzione occorrenze allarmi per descrizione visualizzata con
tre differenti grafici:
RFO6.2.1 Pie-Chart
RFO6.2.2 Bar-Graph
RFO6.2.3 Radar-plot
RFO6.3
Distribuzione occorrenze allarmi ultima settimana
RFO6.4
Distribuzione occorrenze allarmi ultime 7 ore
Alberto Baggio
Tesi – iWWAlarms
51
RFO7
Impostazione parametri di connessione
RFO7.1
Indirizzo ip Oggetto server
RFO7.2
Porta a cui connettersi
RFO7.3
Nome utente per la login al server
RFO7.4
Password per la login al server
RFO8
Possibilità di salvare i filtri personalizzati
RFD1
Ulteriore statistiche riguardanti gli allarmi
RFD1.1
Gaussiana tempi riconoscimento degli allarmi salvati nello storico
remoto
RFQO1
E' garantito il funzionamento su iPhone iOS 3.1 o superiore
RFQO2
Il codice sorgente è corredato di documentazione
RFQO3
Saranno effettuate fasi di test corredate di documentazione
Tracciamento dei requisiti
Tracciamento: requisiti funzionali - Use Case
Requisito
Use Case
RF01
UC1, UC2
RF02
UC1, UC4
RFO2.1
UC4
RFO2.2
UC4
RFO2.3
UC4
RFO3
UC5
RFO4
UC1, UC7
RFO4.1
UC7.1
RFO4.2
UC7.2
RFO4.3
UC7.3
RFO4.4
UC7.4
RFO5
UC1, UC4, UC4.1
RFO5.1
UC4.1.5
RFO5.2
UC4.1.4
RFO5.3
UC4.1.3
RFO5.4
UC4.1.1
RFO5.5
UC4.1.1
RFO5.6
UC4.1.2
RFO5.7
UC4.1.7
Alberto Baggio
Tesi – iWWAlarms
52
Requisito
Use Case
RFO5.8
UC4.1
RFO5.9
UC4.1.6
RFO6
UC1, UC6
RFO6.1
UC6.1
RFO6.1.1
UC6.1
RFO6.1.2
UC6.1
RFO6.1.3
UC6.1
RFO6.2
UC6.2
RFO6.2.1
UC6.2
RFO6.2.2
UC6.2
RFO6.2.3
UC6.2
RFO6.3
UC6.3
RFO6.4
UC6.4
RFO7
UC1, UC3
RFO7.1
UC3.1
RFO7.2
UC3.2
RFO7.3
UC3.3
RFO7.4
UC3.4
RFO8
//
Tracciamento: Use Case – requisiti funzionali
Use Case
Requisito funzionale
UC1
RFO7, RFO1, RFO2, RFO4, RFO5, RFO6
UC3
RFO7, RFO7.1, RFO7.2, RFO7.3, RFO7.4
UC4
RFO2, RFO2.1, RFO2.2, RFO2.3, RFO5,
UC4.1
RFO5, RFO5.1, RFO5.2, RFO5.3, RFO5.4,
RFO5.5, RFO5.6, RFO5.7, RFO5.8, RFO5.9
UC6
RFO6, RFO6.1, RFO6.1.1, RFO6.1.2, RFO6.1.3,
RFO6.2,
RFO6.2.1,
RFO6.2.2,
RFO6.2.3,
RFO6.3, RFO6.4
UC7
RFO4, RFO4.1, RFO4.2, RFO4.3, RFO4.4
Tracciamento Classi – requisiti soddisfatti
CLASSE
Requisiti Soddisfatti
MODEL
RandomColor
RFO6, RFO6.1, RFO6.1.1, RFO6.1.2, RFO6.1.3
DataBase
RF08
Alberto Baggio
Tesi – iWWAlarms
53
CLASSE
Requisiti Soddisfatti
Filters
RFO4, RFO4.1, RFO4.2, RFO4.3, RFO4.4
Json-RPC
(sviluppata Ing. Andrea Piccolo)
RFO2, RFO5
StoreAllarmiAttivi
RFO2, RFO4, RFO5, RFO6
DownloadAllaAttivi
RFO2, RFO5
ServerConnection
(Sviluppata da Ing Andrea Piccolo)
RFO2, RFO5
RequestResponder
(Sviluppata da Ing Andrea Piccolo)
RFO2, RFO5
AsyncSocket
(sviluppo
Dustion
code.google/p/cocoaasyncsocket)
RFO2, RFO5
Voss
VIEW
PieChart
RFO6, RFO6.1, RFO6.1.1, RFO6.2, RFO6.2.1
Effetto3d
RFO6.1.1
Effetto3dDesc
RFO6.2.1
Radar
RFO6, RFO6.1, RFO6.1.2, RFO6.2, RFO6.2.2
RadarArea
RFO6.1.2
RadarDesc
RFO6.2.2
PieTouch
RFO6, RFO6.1, RFO6.2
GestoreTouch
RFO6, RFO6.1,
DescTouch
RFO6, RFO6.2
BarGraph
RFO6, RFO6.1, RFO6.1.3, RFO6.2, RFO6.2.3
BarGraphArea
RFO6.1.3
BarGraphDesc
RFO6.2.3
Distribuition
RFO6, RFO6.3, RFP6.4
WeekOcc
RFO6.3
LastiSixHoursOcc
RFO6.4
CONTROL
Grafici
RFO6, RFO6.1, RFO6.2, RFO6.3, RFO6.4
ControllerBarArea
RFO6.1.3
ControllerBarDesc
RFO6.2.3
ControllerWeekOcc
RFO6.3
ControllerLastSixHours
RFO6.4
ControllerSecondaVista
RFO6.1.1
ControllerPieChartDesc
RFO6.2.1
ControllerRadarAree
RFO6.1.2
Alberto Baggio
Tesi – iWWAlarms
54
CLASSE
Requisiti Soddisfatti
ControllerRadarDesc
RFO6.2.2
RootController
RFO2, RFO4, RFO5, RFO6, RFO7, RO8
Page
RFO2, RFO2.1, RFO2.2, RFO2.3
ControllerQuartaVista
RFO4, RFO4.1, RFO4.2, RFO4.3, RFO4.4
ControllerStats
RFO6
ControllerSettings
RF07, RF07.1, RF07.2, RF07.3, RF07.4
ContPage
RFO2, RFO2.1, RFO2.2, RFO2.3
DettaglioAllarmi
RF05, RFO5.1, RFO5.2, RFO5.3,
RFO5.6, RFO5.7, RFO5.8, RFO5.9
SaveFilter
RFO8
ViewFilterResult
RFO4
MyFilterDisplay
RF08
SetDateFilterMax
RFO4.4
DateSetFilter
RFO4.4
MyFilterDisplayAdd
RF08
RFO5.4,
Requisito – classi che partecipano al soddisfacimento
REQUISITO
CLASSI
RFO1
TODO, già predisposto
RFO2
DownloadAllaAttivi, StoreAllarmiAttivi, Json-RPC, RequestResponder,
ServerConnection, Page, ContPage, AsyncSocket
RFO2.1
Page, ContPage
RFO2.2
Page, ContPage
RFO2.3
Page, ContPage
RFO3
TODO
RFO4
Filters, StoreAllarmiAttivi, ControllerQuartaVista
RFO4.1
Filters, ControllerQuartaVista
RFO4.2
Filters, ControllerQuartaVista
RFO4.3
Filters, ControllerQuartaVista
RFO4.4
Filters, ControllerQuartaVista, SetDateFilterMax. DateSetFilter
RFO5
DownloadAllaAttivi, StoreAllarmiAttivi, Json-RPC, RequestResponder,
ServerConnection, AsyncSocket, DettaglioAllarme
RFO5.1
DettaglioAllarme
RFO5.2
DettaglioAllarme
RFO5.3
DettaglioAllarme
RFO5.4
DettaglioAllarme
RFO5.5
DettaglioAllarme
Alberto Baggio
Tesi – iWWAlarms
55
RFO5.6
DettaglioAllarme
RFO5.7
DettaglioAllarme
RFO5.8
DettaglioAllarme
RFO5.9
DettaglioAllarme
RFO6
ControllerStats
RFO6.1
RandomColor, StoreAllarmiAttivi
RFO6.1.1
PieChart, Effetto3d, ControllerSecondaVista
RFO6.1.2
Radar, RadarArea, ControllerRadarAree
RFO6.1.3
ControllerBarArea, BarGraph, BarGraphArea
RFO6.2
RandomColor, StoreAllarmiAttivi
RFO6.2.1
PieChart, Effetto3dDesc, ControllerPieChartDesc
RFO6.2.2
RandomColor, StoreAllarmiAttivi, ControllerStats
RFO6.2.3
ControllerBarDesc, BarGraph, BarGraphArea
RFO6.3
ControllerWeekOcc, Grafici, WeekOcc
RFO6.4
ControllerLastSixHours, Grafici, LastSixHourOcc
RFO7
ControllerSettings, options.plist
RFO7.1
ControllerSettings, options.plist
RFO7.2
ControllerSettings, options.plist
RFO7.3
ControllerSettings, options.plist
RFO7.4
ControllerSettings, options.plist
RFO8
MyFilterDisplay, MyFilterDisplayAdd, SaveFilter, DataBase, filtri.db
RFD1
TODO (vi è una possibile implementazione in Gauss.m)
RFD1.1
TODO
RFQO1
TODO
RFQO2
Definizione di prodotto v1.0
RFQO3
TODO
Alberto Baggio
Tesi – iWWAlarms
56
Glossario
•
Archestra IDE: ambiente di sviluppo integrato, creato per facilitare il design, la
creazione, lo sviluppo ed il mantenimento di applicazioni scalabili, sicure e
standardizzate atte a controllare le funzioni produttive di un'azienda (MES, Industriali
Automatation).
•
APNs: servizio messo a disposizione da Apple in grado di propagare informazione ad
iPhone, iPod, iPod Touch ed iPad. Questi dispositivi si registrano al servizio, stabilendo
una connessione IP protetta e ricevono le notifiche. Se una notifica arriva mentre
l'applicazione non è in esecuzione, il dispositivo avverte l'utente dei dati in attesa.
•
Cocoa: insieme di framework orientati agli oggetti che permettono lo sviluppo di
applicazioni eseguibili in MAC OS X e iPhone OS.
•
ERP: Enterprise Resource Planning, (pianificazione delle risorse di impresa) sistema
informatico che integra tutti i processi di business rilevanti di un'azienda.
•
Industrial Automatation: è l'utilizzo di sistemi di controllo automatizzati per il
monitoraggio di macchinari e processi industriali, senza l'ausilio dell'operatore umano.
•
Instrument: tool integrato in Xcode che permette il monitoraggio e l'analisi delle
prestazioni di un'applicazione eseguita su iPhone. In particolare è in grado di
visualizzare aspetti fondamentali quali: allocazione e rilascio della memoria, sequenza
degli eventi, attività della CPU, threads in esecuzione e risorse impiegate da questi,
traffico network e altro ancora.
•
Interface Builder: software che permette di disegnare interfacce grafiche per i
framework Cocoa e Carbon. Le interfacce vengono salvate in directory contenenti gli
oggetti grafici e le loro relazioni; il tutto è raggruppato in file XML o NeXT con estensione
.nib. Al lancio dell'applicazione i corrispondenti oggetti NIB vengono scompattati e
collegati al codice binario.
•
InTouch: software che permette la visualizzazione grafica dei dati monitorati, in tempo
reale, dagli oggetti eseguiti dall'ambiente runtime fornito da Archestra IDE.
•
Iphone SDK: kit di sviluppo che permette la creazione di applicazioni per ipPhone, iPod
Touch ed iPad.
•
Iphone Simulator: tool che permette di emulare l'iPhone su pc Mac.
•
Machine Vision Solutions:
informazioni da un'immagine.
•
MES: Manifacturing Execution System, di indica un sistema informatizzato che ha lo
principale funzione di gestire e controllare la funzione produttiva di un'azienda. La
gestione coinvolge il dispaccio degli ordini, gli avanzamenti in quantità e tempo, il
versamento a magazzino, nonché il collegamento diretto ai macchinari per dedurre
informazioni utili ad integrare l'esecuzione della produzione come a produrre
informazioni per il controllo della produzione stessa.
•
Objective-C: linguaggio orientato agli oggetti con a base il C.
•
SSL: protocollo crittografato che permette una comunicazione sicura e una integrità dei
dati su reti TCP/IP. SSL ed il suo predecessore TSL cifrano la comunicazione dalla
soluzioni
software-hardware
in
grado
di
estrarre
Alberto Baggio
Tesi – iWWAlarms
57
sorgente alla destinazione sul livello di trasporto. Il protocollo SSL consente alle
applicazioni client/server di comunicare attraverso una rete in modo tale da prevenire il
'tampering' (manomissione) dei dati, la falsificazione e l'intercettazione.
•
Token: blocco di testo categorizzato.
•
Xcode: ambiente di sviluppo integrato, sviluppato da Apple Inc. per agevolare la
creazione di software per Mac OSx e iOS.
Alberto Baggio
Tesi – iWWAlarms
58
Bibliografia
•
Cocoa Touch for iPhone OS3,
Java De Voe, Wiley
•
The iPhone Developer's Cookbook, building applications with the iPhone 3.0 SDK,
Second Edition
Erica Sadun, Addison Wesley
•
iPhone Advance Projects,
Appress
•
http://developer.apple.com/iphone
•
http://www.json.org
•
http://www.autoware.it
•
http://www.wonderware.com