Icem: Un’ Applicazione Per L’Iphone

massimo cocco icem: un’ applicazione per l’iphone

tesi di laurea

Relatore: Prof. Paolo Baldan

Università degli Studi di Padova Facoltà di Informatica Dipartimento di Scienze Matematiche Naturali MM FF NN Febbraio 2011

I’m never giving in On with the show - Queen - The Show Must Go On -

Dedicato a mio nonno.

INDICE

1 introduzione 1 1.1 ”Tutto cambia. Di nuovo” 1 1.2 Introduzione al progetto 2 1.2.1 Corporate Energy Mangement Application 2 1.2.2 L’azienda Autoware e iCEM 3 1.2.3 Settori sviluppati dallo studente 5

2 analisi del progetto 7 2.1 Studio di fattibilità 8

3 use case 9 3.1 Use case: Area ﬁlter 9 3.2 Use Case: Area risultati 10 3.3 Use case: Area Events 11 3.4 Use case: Dettagli Eventi 12 3.5 Ciclo di vita 13

4 il linguaggio object c 15 4.1 La struttura del linguaggio 15

5 strumenti utilizzati 19 5.1 Xcode 19 5.2 Xcode IDE 19 5.3 Interface Builder 20 5.3.1 Esempio di utilizzo di Interface Builder: Hello World 20 5.4 SQLite & SQLite Database Browser 21

6 progettazione e sviluppo dell’ icem 25 6.1 Connessione iPhone - Server 25 6.2 Database 26 6.3 Sezioni Allarmi ed Eventi 27 6.4 Tab Bar 27 6.5 Sezione Events 29 6.5.1 Area Events 29 6.5.2 Details Events 31 6.5.3 Meters of Events 32 6.6 Sezione Alarms 32 6.6.1 Area Filter 33 6.6.2 Area Set Alarm Order 36 6.6.3 Area Risultati 37 6.6.4 Area Dettagli 38

7 piano di qualifica 41 7.1 Tecniche di veriﬁca 41 7.1.1 Analisi statica 41 7.2 Tecniche di validazione 41

v 7.2.1 Analisi dinamica 41 7.2.2 Test di unità 42 7.2.3 Test di sistema 42

8 conclusioni 43

9 glossario 45

Bibliograﬁa 49 Lista delle Figure 51

vi 1 INTRODUZIONE

1.1 ”tutto cambia. di nuovo”

Con queste parole al MacWorld, Steve Jobs, cofondatore dell’Apple Inc., annuncia il nuovo modello di iPhone, chiamato iPhone4, suc- cessore del 3GS, riprendendo la frase ”Tutto cambia” usata per la presentazione del primo modello del melafonino. Presentato nel 2007, l’iPhone è diventato in soli 3 anni il dispositivo più venduto nella storia dei palmari con più di 20 milioni di dispositivi acquistati. Il telefonino, riduttivo chiamarlo così, ha da subito cambia- to e rinnovato il concetto di smartphones introducendo una serie di innovazioni tecnologiche straordinarie. Il dispositivo è composto da: un display da 3.5 pollici multitouch con una risoluzione vicina all’HD, solamente tre tasti ﬁsici per le funzioni di regolazione volume e home ed una fotocamera posta posteriormente (nell’ultimo modello ve ne è una anche anteriormente per le videochiamate).

Figura 1: Il nuovo iPhone4 presentato a Giugno 2010

Oltre a tutto questo, il telefonino incorpora un accelerometro, un dispositivo GPS oltre ad uno Wi-Fi e Bluetooth ed altoparlanti e la funzione di riproduttore di foto, video e musica. In definitiva l’iPho- ne incorpora le funzioni di un iPod con quelle di un palmare. “La rivoluzionaria interfaccia grafica”, continua ancora Steve Jobs nel suo keynote di presentazione [1], “è il risultato di anni di ricerca, sviluppo ed interazione tra hardware e software. [..] Utilizzeremo il miglior dispositivo di puntamento al mondo, le dita”. L’hard disk del primo iPhone aveva una capacità di 4 GB (2007), ora la capacità minima che si può avere è di 8 GB fino ad un massimo di 32 GB; lo spazio interno

1 2 introduzione

lo si può riempire oltre che con contenuti multimediali, da applicazione programmate solo per iPhone e che si possono acquistare presso l’AppStore.

Figura 2: Il logo dell’SDK di Apple

SDK ed XCode Apple ha messo a disposizione l’SDK dell’iPhone, strumento di sviluppo disponibile solo per Mac, che viene utilizzato dal programma di programmazione XCode, già disponibile nel DVD di installazione di Leopard (sistema operativo di MacOSx). Questa piattaforma ha a disposizione un simulatore di iPhone che permette al programmatore di poter veriﬁcare il corretto funzionamento della sua applicazione, come se lo avesse installato sul dispositivo vero e proprio. Usando il mouse e la tastiera, è possibile simulare il tocco (touch) oppure la funzione di ingrandimento/rimpicciolimento della schermata (multitouch). Sinossi della tesi La tesi descrive l’esperienza che ho fatto presso una ditta del vi- centino e la creazione di un applicazione per iPhone, successivamente inviata all’Apple per metterla in vendita. Nei prossimi capitoli, il lettore verrà a conoscenza dell’analisi dei requisiti studiati ad inizio lavoro (Capitolo 2), degli strumenti utilizzati, come XCode e l’SDK dell’iPhone oltre a programmi di gestione di database (Capitolo 5), della progettazione (Capitolo 6), per concludere con una valutazione complessiva dell’applicazione. Nel prossimo paragrafo invece verrà presentata la ditta ed il progetto afﬁdatomi: iCEM, applicazione per il campo industriale.

1.2 introduzione al progetto

1.2.1 Corporate Energy Mangement Application

iCEM è la versiona portatile dell’applicazione Wonderware Corpora- te Energy Mangement Application, CEM. L’applicazione consente alle aziende di implementare in modo semplice e veloce un programma di Energy Management per raggiungere gli obiettivi di sostenibilità energetica. Essa inoltre consente agli utenti di monitorare i consumi energetici, identiﬁcare e segnalare al personale addetto le relative inef- 1.2 introduzione al progetto 3

ﬁcienze. E’ in grado di rilevare le informazioni direttamente dai meters (contatori) presenti in rete, attraverso diversi protocolli di comunicazione (anche proprietari) e di ricevere informazioni. Grazie all’applicazione Wonderware, le aziende possono creare una vasta gamma di web report relativi ai consumi energetici sulla base di periodi temporali, re- parti, centri di costo ed eventi operativi. Inoltre si ha l’opportunità di essere forniti di visualizzazioni in tempo reale dei consumi energetici, avendo così un quadro complessivo del livello di utilizzo dell’energia.

1.2.2 L’azienda Autoware e iCEM

Lo stage, iniziato il 22/4/2010 e finito il 14/6/2010, si è tenuto presso l’azienda Autoware di Vicenza che fornisce soluzioni all’avanguardia per la gestione e l’automazione della produzione, per il controllo e la supervisione di impianti e processi, per la verifica della qualità attraverso innovative applicazioni di visione artificiale.

Figura 3: Schermata di avvio di iCEM

Nel Settembre del 2009, l’ Autoware è stata nominata “Endorsed Nasce l’idea System Integrator” da parte di Wonderware. Gli Endorsed System dell’iCEM Integrator costituiscono una cerchia estremamente ristretta di società, ad oggi 17 nel mondo (7 negli USA, 1 in Canada, 3 in America latina e altri 5 in Europa) che collaborano con Wonderware nell’affrontare i progetti più critici e nel supportare le nuove tecnologie ed i nuovi 4 introduzione

prodotti. Da un’indagine eseguita da dipendenti Wonderware e dai feedback rilasciati sull’applicazione CEM, è risultato che sarebbe stato molto conveniente avere sempre a disposizione ed a portata di mano, i dati dell’impianto preso in considerazione. iCEM Prendendo accordi con Wonderware, l’azienda si è proposta di idea- re un programma mobile da afﬁancare all’acquisto del CEM: iCEM. Per avere maggiore visibilità e proporre un prodotto all’avanguardia in fatto di funzioni e tecnologie è stata scelta come piattaforma di applicazione l’iPhone e, quindi, anche l’iPod Touch ,in quanto dispongono dello stesso sistema operativo. Come si vedrà più dettagliatamente nel capitolo Strumenti utilizzati, la scelta di programmare sull’ambiente di sviluppo offerto da Apple ha permesso l’utilizzo dell’SDK prodotto dalla casa di Cupertino. Questo pacchetto, usato insieme agli strumenti offerti delle macchine Mac con Leopard 10.6 e successivi, contiene un insieme di funzionalità molto potenti e permette la creazione di interfacce graﬁche tanto accattivanti quanto facili e divertenti nel loro utilizzo. Panoramica iCEM racchiude tutte le funzionalità del CEM; grazie ad un’interfac- dell’applicazione cia facile ed intuitiva, l’utente, collegandosi a web report creati, può accedere a:

• Gerarchie possibilità di navigare attraverso le gerarchie conﬁgurate nel- lapplicativo CEM e visualizzazione in tempo reale dei valori dei meter dislocati nell’ impianto.

• Eventi visualizzazione in tempo reale dei costi di produzioni legati allenergia. Si può monitorare lo stato degli eventi gestiti dallapplicazione CEM, il loro costo, la durata ed il valore dei loro attributi.

• Favoriti tutti i meter più importanti a portata di dito. Lutente può aggiungere i meter in una lista di favoriti che possono essere visualizzati semplicemente scorrendo la pagina con un dito.

• Allarmi tutti gli allarmi generati dallapplicazione Wonderware CEM anche quando iCEM non è in esecuzione grazie alle notiﬁche push.

Per consultare i dati, a livello software, viene collegato l’iPhone ai report web dell’industria o fabbrica munita del CEM, si accede al database interno e, mediante interrogazioni mirate, si visualizzeranno i risultati ottenuti attraverso ﬁltri di ricerca impostati dall’utente. Nei successivi capitoli verranno affrontati i seguenti argomenti:

• analisi dei requisiti studiati ad inizio stage

• ciclo di vita adottato

• strumenti utilizzati 1.2 introduzione al progetto 5

Verrà dedicato un capitolo alla conoscenza del linguaggio di programmazione usato dall’SDK dell’iPhone: l’Object-C. Per una più soddisfacente spiegazione degli strumenti utilizzati e del linguaggio di programmazione adottato, si rimanda il lettore ai capitoli successivi.

1.2.3 Settori sviluppati dallo studente

Lo sviluppo dell’applicazione iCEM è iniziata nel Marzo del 2009 da un altro stagista dell’azienda che aveva gia implementato la sezione inerente alle Gerarchie e Favoriti. Io ho sviluppato la parte logica e graﬁca degli Allarmi ed Eventi; tutti i successivi capitoli, dall’analisi dei requisiti alla progettazione in dettaglio, si riferiranno solamente a quelle sezioni dell’applicazione.

2 ANALISIDELPROGETTO

Il progetto ha per oggetto l’implementazione di due sezioni dell’applicazione iCEM che permettono di visionare e controllare eventuali allarmi o eventi inerenti alla fabbrica. Le parti che ho sviluppato permettono, grazie ad interfacce graﬁ- che, di interrogare un database e di visualizzare i relativi risultati; una volta ottenuti, grazie a Navigation Controller, ovvero un oggetto graﬁco che gestisce una struttura ad albero, è possibile osservare i dettagli di ciascun oggetto selezionato. Nei requisiti obbligatori da soddisfare, suddividendoli per sezione, troviamo:

• Allarmi

– Filtraggio dei risultati: l’utente potrà avere la possibilità di scegliere gli allarmi in base a conﬁgurazioni da lui personalizzate. Le voci che può modiﬁcare sono: Tempo,Tipo, Priorità, Area.

– Modiﬁca dell’ordine di visualizzazione: l’utente può scegliere di impostare la priorità di ricerca o su Tempo oppure su Tipo, Priorità, Area. Di default sarà Tempo.

– Visualizzazione dettagli: selezionando un allarme dall’elenco dei risultati, si possono visionare i dettagli di ogni voce legata all’elemento.

• Eventi

– Attiviti/Non attivi: grazie ad un elemento graﬁco, far coglie- re immediatamente quali eventi sono in funzione e quali invece sono inattivi.

– Dettagli evento: poter visualizzare i parametri principali che costituiscono un evento.

– Dettagli consumi: visualizzare quali sono i principali meter che consumano una particolare energia.

I requisiti opzionali si possono identificare soprattutto su elementi grafici, quali grafici, disegni ed interfacce, così da poter permettere all’utente una veloce e divertente navigazione. Ricordiamo che l’applicazione è da intendersi unicamente per iPho- ne: anche se l’utente possiede un Mac, il simulatore per device, de- scritto nel capitolo 5, è reso disponibile unicamente per lo sviluppo dell’applicazione e non per successivi usi a programma ultimato.

7 8 analisi del progetto

2.1 studio di fattibilità

Le conoscenze richieste per l’implementazione del progetto riguar- dano: • Buona conoscenza del linguaggio Object C. Essendo un linguaggio derivato dal C++, materia di studio universitaria, l’apprendimento è stato rapido e non molto difﬁcile.

• Conoscenza dell’SDK dell’iPhone e dell’ambiente di sviluppo XCode. Con i testi resi disponibili dall’azienda e tutorial pratici online, è stato possibile visionare le funzionalità che il pacchetto offre. Essendo in possesso di un portatile Mac, per il programma XCode non è stato dedicato tempo per studiarlo in quanto veniva giù usato per l’univeristà. • Conoscenza di basi di dati per la gestione di database Anche se il database non richiedeva una conoscenza appro- fondita di come gestire una base di dati, hanno contribuito molto gli insegnamenti universitari nell’ambito della SQL. 3 USECASE

3.1 use case: area filter

Figura 4: Use case area Filter

• Sommario: il sistema gestisce la schermata della ricerca degli allarmi tramite personalizzazione di ﬁltri. • Attore: utente • Precondizioni: l’utente ha selezionato l’icona Alarms sulla Tab Bar.

• Descrizione: all’utente si offorno 4 tipi di ﬁltraggio, ognuno atti- vabile tramite il pulsante ON-OFF. Tutte le impostazioni saranno inviate al database che successivamente visualizzerà in un’altra schermata i risultati. Nel caso in cui l’utente non modiﬁchi alcuna opzione, gli allarmi che risulteranno saranno quelli attivi da quel momento alle 24 ore in ordine cronologico. • Postcondizioni: l’utente ha immesso i dati che vuole analizzare.

9 10 use case

3.2 use case: area risultati

Figura 5: Use case area Risultati Allarmi

• Sommario: vengono visualizzati gli allarmi con le caratteristiche volute. • Attore: utente.

• Precondizione: l’utente ha impostato o meno i dati nell’area Filter ed ha avviato la ricerca. • Descrizione: il display che si presenta contiene la lista degli allarmi che risultano avere le caratteristiche impostate dall’utente. Oltre a scorrere la lista, se viene selezionato un allarme vengono mostrate le caratteristiche principali: nome, tipo, priorità, area. • Alternative: l’utente può selezionare le altre aree dell’applicazione cliccando sulle corrispettive icone poste sulla Tab Bar. • Postcondizione: l’utente ha visionato gli allarmi e le relative caratteristiche. 3.3 use case: area events 11

3.3 use case: area events

Figura 6: Use case area Eventi

• Sommario: vengono visualizzati tutti gli eventi attivi e non. • Attore: utente. • Precondizione: l’utente ha selezionato l’icona Events sulla Tab Bar.

• Descrizione: a display vengono visualizzati gli eventi attivi, rico- noscibili col led verde, e quelli non, rappresentabili col led rosso. Inoltre ogni evento è identiﬁcato col proprio nome. All’utente viene data la possibilità di visionare i dettagli degli eventi che selezionerà.

• Alternative: l’utente può selezionare le altre aree dell’applicazione cliccando sulle corrispettive icone poste sulla Tab Bar. • Postcondizione: l’utente ha visionato gli eventi. 12 use case

3.4 use case: dettagli eventi

Figura 7: Use case area dettagli Eventi

• Sommario: vengono elencati i parametri che costituiscono l’e- vento selezionato: meters associati, tipo di consumi energetici coinvolti, costi associati. • Attore: utente.

• Alternative: l’utente può tornare alla schermata precedente tramite un pulsate posto in alto. • Precondizione: l’utente ha selezionato un evento disponibile dalla lista. 3.5 ciclo di vita 13

3.5 ciclo di vita

Il ciclo di vita adottato è di tipo incrementale in modo da poter sostenere una contenuta fluttuazione dei requisiti in caso di ne- cessità. Ricordiamo che il ciclo di vita scelto identifica subito l’architettura che verrà successivamente utilizzata e non consente il ripetersi delle fasi di analisi e progettazione. Soltanto la progettazione di dettaglio e la realizzazione possono essere ripetute per un numero di iterazioni fisso fin dall’inizio. Questo modello di ciclo di vita ha permesso inoltre di realizzare prima i requisiti obbligatori e successivamente quelli opzionali, pianificazione che si è rivelata molto utile data la breve durata dello stage in relazione alla complessità dell’applicazione. La figura successiva illustra il diagramma di Gantt con la pianificazione del lavoro, organizzata e decisa dall’azienda Autoware; il periodo di stage, ricordo, è durato 8 settimane, dal lunedì al venerdì, tutto il giorno.

Figura 8: Piano di lavoro dal 22 Aprile 2010 al 19 Maggio 2010

Nella prima parte del diagramma si può notare come il periodo Conoscenza del dal 22/4 al 28/4 sia stato dedicato alla conoscenza del linguaggio, linguaggio l’SDK ed il Framework, con l’aggiunta della creazione di semplici esempi per familiarizzare con gli strumenti. La settimana successiva è stata dedicata allo studio e visionamen- Studio dell’iCEM to in maniera profonda dell’applicazione iCEM. In quel periodo erano già state implementate 3 funzioni dall’altro stagista che uti- lizzavano strumenti di cui avrei usufruito per l’implementazione dei servizi Allarmi ed Eventi. Dal 6/5 al 19/5 è iniziata la fase di implementazione della sezio- Allarmi ne Allarmi sia per quanto riguarda la fase grafica sia, soprattutto, per la parte logica/gestionale. Verso la fine della prima settimana, si sono iniziate a verificare le prime ricerche ed interazioni col database, creandone uno fittizio facendo delle interrogazioni di prova. Alla fine di queste due settimane, la nuova sezione è stata presentata al titolare dell’azienda che ha potuto testarne l’effettiva funzionalità ed efficacia. Successivamente è stata implementata la sezione Eventi che, ri- Eventi spetto agli allarmi, coinvolgeva maggiormente il databse e doveva fornire molte più informazioni. Per questo è stato deciso 14 use case

Figura 9: Piano di lavoro dal 19 Maggio 2010 al 14 Giugno 2010

di dedicarci 3 settimane; una parte relativamente impegnativa è stata quella di organizzare graficamente i dati in quanto le informazioni che dovevano essere date erano molte. Alla fine dello stage le due nuove parti dell’iCEM erano pronte e l’applicazione è stata inviata all’Apple per l’approvazione e pubblicazione nell’Apple Store. Verranno descritti ora gli strumenti utilizzati, soffermandosi in particolar modo sul linguaggio di programmazione utilizzato per la codifica, l’Objective-C, e sui software resi disponibili da Mac OS X per lo sviluppo di applicazioni per iPhone. 4 ILLINGUAGGIOOBJECTC

Il linguaggio Object C è un linguaggio di programmazione riﬂes- sivo orientato agli oggetti e compatibile con il C e C++. Venne creato nei primi anni ’80 da Brad Cox e Tom Love alla Stepstone, una compagnia software, per ovviare al problema della program- Problema della mazione procedurale. Con l’aumento dell’innovazione, i proble- programmazione mi che venivano proposti diventavano sempre più complicati ed procedurale il linguaggio di programmazione di allora non offriva il riuti- lizzo di codice. Nel 1988, NeXT, la compagnia fondata da Steve Jobs dopo Apple, ottenne la licenza dell’Objective C da Stepstone (allora proprietaria del marchio) e realizzò il proprio compilatore Objective C e le librerie sulle quali basò l’interfaccia utente di NeXTSTEP. Successivamente Apple, dopo aver acquistato nel 1996 la NeXT, iniziò ad includere nei sistemi operativi Mac OS X, l’Objective C ed il suo sistema di sviluppo Project Builder (in seguito rinominato Xcode).

4.1 la struttura del linguaggio

Esempi di utilizzo

Figura 10: Esempio di ﬁle header (.h)

Nella Figura 10 è rappresentato un file di intestazione. Ad inizio file abbiamo l’importazione del framework Foundation/NSObject che permette all’utente di dichiarare una nuova classe che deriva dalla superclasse NSObject, oggetto del framework Foundation da cui derivano tutte le altre classi definite.

15 16 il linguaggio object c

Figura 11: Esempio di ﬁle .m

Per dichiarare una classe si deve usare la sintassi @interface MNo- meClasse: SuperClasse { parametri } . Al di fuori della dichia- razione, devono essere dichiarate le funzioni che verranno poi implementate nel file .m. Per dichiararle si deve usare: – Visibilità: + metodo pubblico, - metodo privato – Tipo di ritorno: inserito all’interno di parentesi tonde – Nome del metodo – Parametro formale: dopo il nome del metodo vanno messi i : e poi il nome del parametro preceduto dal suo tipo tra parentesi tonde Il file .m inizia con l’importazione del file .h ed eventuali librerie che verranno usate; successivamente seguono le implementazioni dei metodi che dovranno avere la medesima sintassi che compare nel file di intestazione con anche il tipo di visibilità.

Figura 12: Esempio di ﬁle main

Il main è simile a quello che compare nel linguaggio Java: è una funzione che ritorna di norma un int e che prende in input due parametri, uno di tipo intero ed uno di tipo puntatore a carattere. 4.1 la struttura del linguaggio 17

All’inizio si deve allocare lo spazio necessario per l’istanza della classe X con il comando alloc ed ogni campo viene inizializzato a null col comando init.

5 STRUMENTIUTILIZZATI

5.1 xcode

Mac OSx mette a disposizione un potente ambiente di sviluppo di programmazione: Xcode, una SDK sviluppata da Apple che, oltre all’IDE, offre la possibilità di costruire interfacce in maniera semplice e senza effettuare implementazione del codice.

5.2 xcode ide

Xcode include un compilatore GCC, che è in grado di compilare codice C, C++, Objective C/C++ e Java, supporta il framework Cocoa che è l’ambiente di programmazione orientato agli oggetti sviluppato da Apple per il sistema operativo Mac OS X. La Figura 13 illustra la ﬁnestra standard di lavoro di XCode. Gra- zie ad un’interfaccia semplice ed intuitiva, l’utente può organizzare il proprio codice come meglio preferisce.

Figura 13: XCode: organizzazione della ﬁnestra principale

La finestra si suddivide in 3 sezioni principali: – Groups & Files: i file creati vengono suddivisi in cartelle personalizzabili successivamente dall’utente. – Targets, Executables, Nib Files: vengono gestite runtime dal- l’IDE, inserendovi file quali quelli inerenti alla gestione del- l’interfaccia e l’eseguibile dell’applicazione.

19 20 strumenti utilizzati

– File Name: elenco di tutti i ﬁle del progetto: da quelli con formato .m e .h alle librerie coinvolte. La barra degli strumenti collocata nella parte superiore contiene i comandi principali per il settaggio della simulazione e l’avvio della compilazione del codice col tasto Build and Go. Una volta eseguita la compilazione compare il simulatore del- l’iPhone (a destra dell’immagine) che visualizza una possibile esecuzione del programma da noi appena creato. Con l’uso del mouse, è possible simulare il tocco (touch) delle dita e quindi interagire con l’applicazione; usando anche la tastiera invece, è possibile effettuare il gesto del tocco multiplo (multitouch) ed usare quindi le funzioni collegate. Nel prossimo capitolo verrà illustrato Interface Builder, un tool di XCode per realizzare interfacce graﬁche.

5.3 interface builder

Interface Builder mette a disposizione dello sviluppatore palette o collezioni. Questi elementi dell’interfaccia grafica comprendo- no caselle di testo, tabelle e menu a comparsa. Le palette di In- terface Builder sono completamente estensibili: questo significa che è possibile sviluppare nuovi oggetti e aggiungerli ad esse. Per costruire un’interfaccia lo sviluppatore deve semplicemente trascinare gli oggetti dalla palette in una finestra o in un menu senza aggiungere alcuna riga di codice. Interface Builder registra l’interfaccia di un’applicazione come se fosse una directory (bundle), che contiene gli oggetti dell’interfaccia e le relazioni tra di essi utilizzate nell’applicazione. Que- sti oggetti sono raggruppati in un file con estensione .nib; nelle nuove versioni di XCode, Interface Builder supporta file di formato recente del tipo .xib. Quando un’applicazione viene lancia- ta, i corrispondenti oggetti NIB vengono scompattati, collegati al codice binario della loro rispettiva applicazione e risvegliati.

5.3.1 Esempio di utilizzo di Interface Builder: Hello World

Per capire al meglio le potenzialità che IB (acronimo di Interface Builder) può offrire al programmatore, illustro brevemente ed in maniera semplice un suo utilizzo andando a sviluppare un’applicazione che dovrà visualizzare sullo schermo dell’iPhone la stringa Hello Wordl. Quando selezioniamo New File, scegliamo come tipo di progetto View-Based-Application che permette di lavorare su una View cioè su un oggetto grafico che offre la base per gli ulteriori widget che vorremo usare. Per creare l’interfaccia usiamo un file .xib come spiegato nel paragrafo precedente che successivamente verrà 5.4 sqlite & sqlite database browser 21 aperto da IB per effettuare le modifiche che vogliamo eseguire. Una volta aperto il file, la schermata che avremo è la seguente:

Figura 14: Finestre principali di Interface Builder

Abbiamo quattro finestre indipendenti; partendo da sinistra: – nella prima finestra vengono gestiti i legami tra metodi im- plementati nei file presenti nell’IDE di XCode e gli oggetti grafici – nella seconda è riprodotto il display dell’iPhone dove possiamo trascinare gli oggetti che prendiamo dalla Library (quar- ta finestra) e distribuirli nello spazio. Nel nostro caso avremo bisogno di una Label dove scriveremo la stringa Hello World. – nella terza abbiamo gli attributi dove possiamo impostare i parametri dell’oggetto selezionato (dal colore al tipo di testo al collegamento con un eventuale pulsante). Continuando l’esercizio, selezionando la Label inserita precedentemente, andremo a cambiare il suo parametro Title e scriveremo - Hello World. – l’ultima finestra contiene un elenco di tutti gli oggetti grafici che possiamo utilizzare per arricchire la nostra applicazione tra cui la Label che abbiamo usato. Successivamente premendo il tasto Build and Go, compare il simulatore dell’iPhone con l’anteprima dell’applicazione creata.

5.4 sqlite & sqlite database browser

Per la creazione e gestione dei dati scaricati, è stato utilizzato SQLite, una libreria interamente scritta in ANSI C che implementa al proprio interno un motore per database SQL, rilasciata al 22 strumenti utilizzati

Figura 15: Risultato ﬁnale dell’esempio Hello World

pubblico, e che quindi non richiede nessuna licenza d’uso. SQ- Lite non è una libreria client che si deve collegare ad un qualche grosso server database in quanto è lui stesso il server. La libreria SQLite legge e scrive direttamente sul file del database. La figura rappresenta la schermata di SQLite Database Browser con il quale è possible creare facilmente una tabella e popolarla, grazie alla grafica semplice ed intuitiva. L’esempio che si può vedere rappresenta un semplice database popolato da dati di tipo Allarmi, quindi strettamente legato al progetto che sto presen- tando. Per interagire con la tabella vengono usate le medesime interrogazioni che si usano per SQL; per esempio, se vogliamo i meter_id associati a ciascun allarme scriviamo: select meter_id from alarm Tutte le interazioni con la tabella vengono gestite a livello di codice, infatti SQLite Database Browser è servito solamente per gestire i dati scaricati. 5.4 sqlite & sqlite database browser 23

Figura 16: Schermata di SQLite Database Browser

6 PROGETTAZIONEESVILUP- PODELL’ICEM

6.1 connessione iphone - server

L’ iCEM è un’applicazione che permette di collegarsi tramite Wi- Fi o rete 3G, al computer della fabbrica (il server) e di scaricare i dati contenuti nel programma CEM. Il server è un oggetto Wonderware ArchestrA, un’ architettura Server completa per i software di automazione e gestione di informazioni. Oltre a questo, ArchestrA, utilizzando in ambiente industriale la tecnologia Microsoft.NET ed altre tecnologie Microsoft, costituisce un’architettura Service-Oriented (iSOA). Questa so- luzione presenta tutte le funzionalità necessarie nelle infrastrut- ture manifatturiere ed industraili, tra cui sicurezza industriale, connessione ai sistemi d’impianto e di business, interfaccia con i client, portale web e gestione sistemi.

Figura 17: Schermata per effettuare il login

Il sistema si mette in ascolto su una determinata porta TCP-IP in Connessione attesa di collegamenti da parte dei client. L’utente, per accedere via rete al server, deve effettuare un login immettendo le stesse username e password registrate nella macchina server: è logico

25 26 progettazione e sviluppo dell’ icem

che l’accesso lo possa avere solamente il personale. Una volta eseguito il login, avvengono le richieste da parte dell’iPhone di popolamento del suo database interno con i dati contenuti nel server. Le richieste si basano sul protocollo JSON-RPC.

6.2 database

Il database che viene riempito di dati nell’iPhone, è costituito da una serie di tabelle correlate con chiavi primarie. Come si può notare nella Figura 18, ogni campo dati interessante costituisce una tabella ed ogni tabella ha una relazione con almeno un’altra. Per l’interrogazione di queste, si usano le forme sintattiche di SQL, inserendo i comandi all’interno del codice Object-C come verrà spiegato nella Sezione Allarmi alla voce Area Filter.

Figura 18: Database dell’ iCEM

Usando la ﬁgura, vengono ora illustrate le tabelle che ho sviluppato: – Alarm: ogni allarme è costituito da: un attributo, un meter, un’ora precisa nel quale è/era attivo, dal tipo, dalla durata, dalla priorità e dall’area nel quale si è presentato.

Figura 19: Particolare della tabella Allarmi

– Event: ogni evento è costituito da: un id, un nome, l’area coinvolta e dal tipo di evento. Nelle successive sezioni, i concetti appena presentati verranno discussi e spiegati con maggior dettaglio, illustrando anche le scelte graﬁche adottate. 6.3 sezioni allarmi ed eventi 27

Figura 20: Particolare della tabella Eventi

6.3 sezioni allarmi ed eventi

Quello che il lettore si sta accingendo a leggere, non è la descrizione completa dell’applicazione iCEM ma, come già spiegato nel paragrafo 1.2.3, la presentazione delle sezioni da me sviluppate: Allarms ed Events. La progettazione delle due sezioni è stata molto chiara ﬁn dal- l’inizio: l’utente doveva avere a disposizione un motore di ricerca che gli potesse fornire i dati relativi ad allarmi,attivi e non, e agli eventi relativi a quel momento preciso di utilizzo dell’applicazione. L’architettura è stata studiata e sviluppata con un approccio top- down, il problema principale è stato suddiviso in sottoproblemi esclusivi tra di loro cioè l’attività successiva dipendeva dal corret- to funzionamento di quella precedente. Questa strategia ha così permesso di correggere ed eventualmente ampliare determinate soluzioni per migliorare ed aumentare le funzionalità offerte e per avere un prodotto di qualità elevata. Per l’implementazione di entrambe le sezioni sono stati esegui- ti dei lavori graﬁci per rendere più piacevole ed intuitiva sia l’immissione di dati del cliente, sia dei risultati che venivano visualizzati a display.

6.4 tabbar

La graﬁca principale dell’applicazione si basa su un Navigation Navigation Controller cioè la possibilità di navigare in una struttura gerarchi- Controller ca con le funzionalità di passare dal livello attuale al successivo o al precedente in maniera facile ed intuitiva grazie a pulsanti posti in alto sul display.

Figura 21: Tab Bar nativa di Interface Builder

Per passare tra una sezione e l’altra dell’applicazione, è stata creata la Tab Bar, Figura 22, utilizzando un template diverso rispetto al Navigation Controller: il Window-Based-Application. Questo template, molto più semplice dell’altro, non include una Window-Based- Application 28 progettazione e sviluppo dell’ icem

View a disposizione dell’utente, ma semplicemente fornisce una Window sulla quale il programmatore deve costruire tutta l’interfaccia. In questo caso, è stato utilizzato il template Window- Based soltanto per costruire la Tab Bar, non si necessitava infatti di widget inutili.

Figura 22: Tab Bar

Tab Bar Per costruire con Interface Builder la Tab Bar, è stato necessario trascinare dalla finestra Library alla finestra Window un oggetto TabBarController. Di default, quando Interface Builder crea questo widget, gli item disponibili sono soltanto due, ma possono essere aumentati a piacere. In questo caso, sono stati necessari sei item (che sono Hierar- chies, Events, Alarms, Favorites, Options, Contacts). É possibile però visualizzare solamente cinque item, i successivi potranno essere visibili tramite il tasto More posto all’estrema destra (come mostrato in Figura 22). E’ stato possibile inoltre rinominare le etichette degli item ed inserire un’immagine personalizzata per ciascuno di essi, rispet- tando la misura di 24x24 pixel imposta da Interface Builder. Nel momento in cui uno di questi viene selezionato, l’immagine diventa di colore blu e tutte le altre restano in bianco e nero; è possibile infatti selezionarne soltanto una alla volta. All’interno del file grafico che controlla tutto questo in Interface Builder, MainWindow.xib, ciascuno di questi item è collegato ad uno specifico file che ne gestisce le funzionalità. Così Alarms è collegato al file AlarmFilterController.xib ed Events ad EventsView- Controller; la stessa organizzazione per le View dei sottolivelli delle sezioni che sono collegati ad altrettanti file di tipo .xib. Unico caso particolare è come sono state gestite le visualizzazioni degli allarmi e degli eventi che verranno spiegate nei sottocapitoli corrispondenti. 6.5 sezione events 29

6.5 sezione events

In ambito industriale, un evento può essere ad esempio un lot- to di produzione, un batch, un turno; grazie a questa sezione, l’utente ha sotto mano in ogni momento i costi reali delle varie forme di energia e può prendere tutte le iniziative necessarie al loro contenimento. In fase di studio, concordando con l’azienda, si è deciso di prendere in considerazione solamente gli eventi attivi anche se è già stato deciso che, nelle versioni successive, si potranno avere anche gli storici e quindi visionare eventi già passati e cioè inattivi.

6.5.1 Area Events

Una volta selezionata l’icona della Tab Bar Events, sul display compare un’interfaccia composta da 2 item: un Navigation Con- troller, che gestisce la struttra ad albero utilizzando una succes- sione diverse di View, ed una Table View, che permette la creazione di una tabella dove si può interagire con ogni elemento che contiene.

Figura 23: Schermata principale sezione Events; schermata dettagli evento

L’elenco che si presenta all’utente elenca tutti gli eventi attivi e non attivi con a ﬁanco un cerchio colorato che indica il loro stato. 30 progettazione e sviluppo dell’ icem

Nella ﬁgura sottostante, in questo caso, è visualizzato un elenco di 4 eventi attivi (colore verde) con il proprio nome. Dal punto di vista progettuale, la classe che gestisce questa componente, Even- tsTableViewController, è un’istanza di UITableViewController, classe per l’appunto di controllo che gestisce la struttura tabellare del- l’interfaccia. Ogni cella che contiene un evento è stata creata mediante un EventsCellView.xib: il sistema richiama la costruzione usando il ﬁle .xib per ogni elemento che trova nel database alla voce Events.

Figura 24: Costruzione mediante Interface Builder di una cella Events

Come mostrato in Figura 24, l’oggetto graﬁco è composto da una cella della Tabel View con al suo interno: – una label per visualizzare il nome – una UIImageView con un’immagine di tipo .png verde o ros- sa in base all’attività o meno dell’evento – un oggetto graﬁco contenuto nella Library dell’ Interface Buil- der chiamato Activity Indicator usato quando la sezione Even- ts viene selezionata ed il sistema sta cercando l’attività o meno dell’evento

Figura 25: Particolare di eventi in fase di caricamento con l’utilizzo di Activity Indicator

Table View Per ottenere informazioni su un evento, cliccandone uno attivo, si passa ad una successiva View. Se vengono selezionati eventi non attivi, identificanti col led rosso, non avviene alcuna azione in quanto sono eventi finiti e quindi non interessanti. La Table View per permettere di poter effettuare azioni sulle righe della tabella, mette a disposizione il metodo didSelectRowAtIndex- Path (Figura 26) dove è possibile a codice poter collegare la riga selezionata ad una determinata View di un file .xib, oppure ad un’altra azione. In questo caso ciascuna riga è collegata alla View di EventsView- Controller: nella figura questo si può notare nella riga dove si sta allocando memoria ad un puntatore di tipo EventsViewController e lo si collega al file .xib EventsViewController. 6.5 sezione events 31

Figura 26: Particolare del codice didSelectRowAtIndexPath

Da adesso si prenderà in considerazione l’evento EventPOman_BP1, il primo dell’elenco, per spiegare al meglio le schermate successive.

6.5.2 Details Events

Una volta selezionato l’evento, si presenta il display di Figura 27.

Figura 27: Schermata dettagli dell’evento

La ﬁnestra dei dettagli è costituita da una Table View con l’inserimento di una View selezionabile (la barra colorata) all’interno della cella centrale. L’idea di base è quella che il dipendente, una volta selezionato l’evento, deve avere a disposizione sulla schermata sia tutti i dettagli più importanti che i consumi energetici provocati con i relativi costi. Onde evitare di costruire un’unica 32 progettazione e sviluppo dell’ icem

ﬁnestra con tutti i dati che avrebbe potuto portare a rallentamenti dell’applicazione, si è deciso di mettere in prima pagina i dettagli e, con un aiuto graﬁco, una prima visione dei consumi, mentre i dettagli di questi potranno essere acceduti in un’altra maniera. Il disegno, in questo caso rosso, rappresenta i consumi energetici coinvolti, in particolare il numero di tipi. In generale, il disegno: – avrà tanti colori quanti sono i tipi energetici coinvolti – ogni parte colorata sarà più o meno grande rispetto le altre sezioni in base alla quantità di consumi che provoca. Se abbiamo 2 tipi energetici, uno costituisce il 30% e laltro il 70% dei consumi, il disegno avrà rispettivamente 2 parti di colore distinte di cui la prima sarà più piccola rispetto la seconda. In questo caso si ha un solo tipo di energia che quindi l’unico che contribuisce ai consumi (100%).

UIImageView A livello di implementazione, oltre ad inserire stringhe all’interno delle celle, per quanto riguarda l’inserimento del disegno di- namico, è stata creata una classe a parte, ViewVertical, che deriva da UIImageView: una classe che permette di disegnare sul UIButton display. Utilizzando successivamente Interface Builder è stato inserito dietro al disegno un pulsante di tipo UIButton; grazie ad IB, è stato possibile renderlo trasparente e decidere quale azione eseguire nel caso in cui venisse cliccato. Tra gli eventi a disposizione c’è Touch Up Inside che gestisce il tocco del dito dell’utente; collegando l’azione di tocco all’area riservata al graﬁco si crea il collegamento Tocco-Evento (signal-slot).

6.5.3 Meters of Events

Se l’utente tocca il disegno, verrà eseguito un ﬂip del display per passare all’ultimo sottolivello contenente una View con i dettagli dell’evento e cioè i meter che costituiscono l’elemento, suddivisi per il tipo e quantità di consumi energetici. Nell’ultima View del nostro esempio l’evento è costituito da energia di tipo POWER, costa 11.09eed è l’unico consumo: 100%. Per tornare alle schermate precedenti basta cliccare i bottoni in alto a sinistra e selezionare un altro evento attivo che si vuole studiare. La sezione Alarms è stata costruita usando le medesime strategie di progettazione: di base vi è un Navigation Controller e per ogni View è stata usata una Table View per la selezione ed interazione con gli oggetti a display.

6.6 sezione alarms

La funzionalità principale di questa sezione è quella di dare la possibilità all’utente di poter visualizzare gli allarmi con i parametri che desidera. Il primo problema è stato quello di organiz- 6.6 sezione alarms 33

Figura 28: Schermata dettagli consumi dell’evento zare il display principale della sezione e di inserire i campi dati principali. Difatti i parametri che si possono personalizzare sono molti e di vario tipo; per non appesantire la navigazione, è stata inserita la possibilità di rendere visibile o meno i parametri dello stesso tipo.

6.6.1 Area Filter

Una volta premuta l’icona Alarms posta sulla Tab Bar, all’utente viene visualizzata l’area Filter, raffigurata in Figura 29 e Figu- ra 30, dove si ha la possibilità di inserire un filtraggio per gli allarmi. La grafica si basa su una serie di label, inserite in celle della Table View, che grazie all’Interface Builder sono facili da modificare sia per quanto riguarda la dimensione sia per impostare azioni o titoli su di esse. Infatti, una volta selezionata dalla Library la label e posizionata sulla View, usando il mouse è possibile restringere, aumentare, ingrandire l’oggetto grafico ed è possibile modificare i parametri del titolo, colore o altro. Partendo dal primo elemento abbiamo le seguenti funzionalità: 34 progettazione e sviluppo dell’ icem

Figura 29: Schermata principale di Alarms: Time, Type, Priority

– Time: possono essere impostati qualsiasi dato temporale, dal giorno, ad un intervallo di tempo, dall’ora al minuto. – Type: gli allarmi sono suddivisi in 3 tipi, dal più pericoloso a quello meno. L’utente, grazie ad una rappresentazione grafica di un pallino colorato, può scegliere intuitivamente quali tipi di allarmi visualizzare. Quando verranno visualizzati i risultati, si potrà notare che la stessa rappresentazione grafica colorata viene riutilizzata per una identificazione rapida dei dati. – Priority: ogni allarme ha un valore di priorità che varia tra 1 e 999; l’utente può: inserire un valore esatto immettendo lo stesso numero nella casella min e max; fare una ricerca degli allarmi che risiedono tra un intervallo di priorità. – Area: ogni fabbrica è suddivisa in aree ed ogni area ha il suo tipo di allarme; grazie ad un box di ricerca stringa, l’utente può immettere l’area che preferisce.

Switch Come si può notare, in corrispondenza delle celle, è stato posi- zionato uno Switch che è costituito da 2 stati: ON e OFF. Quando l’utente accede per la prima volta a questa ﬁnestra di default ogni opzione è su OFF e quindi non si notano le personalizzazioni avanzate che si potranno modiﬁcare. Quando viene selezionato l’ON invece compaiono con animazione a tendina, 6.6 sezione alarms 35

Figura 30: Schermata principale di Alarms: Area tutti i campi settati con valori di default che l’utente può o meno cambiare. Quando invece si preme OFF, oltre alla chiusura a tendina della sezione, i dati immessi in quella opzione vengono tutti resettati a default. Questo comunque non pregiudica la perdita dei dati precedentemente immessi; infatti se si preme di nuovo ON, i valori visualizzati saranno quelli eventualmente modiﬁcati dall’utente.

Figura 31: Esempio di utilizzo dello Switch

La ricerca ﬁnale dunque prenderà in considerazione i dati inseriti per le opzioni settate ad ON e i valori di default per quelle in OFF. Ogni sezione dà la possiblità di ﬁltrare i parametri personalizzati 36 progettazione e sviluppo dell’ icem

sia in ordine decrescente che crescente. Se l’utente non esegue alcuna modiﬁca e preme direttamente il tasto in alto a sinistra Done, i risultati che si ottengono sono gli allarmi delle ultime 24 ore, dal più recente al più vecchio. Tutte queste immissioni di dati non fanno altro che costruire la query che andrà ad interrogare la tabella dei dati scaricati tramite connessione 3G/WiFi dell’iPhone; i risultati saranno ordinati prima per tempo poi per tipo, priorità ed area. Questa sarebbe l’interrogazione predeﬁnita che verrebbe fatta al database:

Figura 32: Query di default

dove possiamo notare: – l’interrogazione su tutti i dati degli allarmi * select attribute_id,meter_id ..... millisec from alarm – delle ultime 24 ore * where time between 1280406660 and 1280493060 – di tutte le priorità * priority between 1 and 999 limit 100 Se si volesse raggruppare i risultati in un certo ordine, ad esempio, all’utente interessa che i risultati vengano ordinati prima per priorità poi per tempo o per altri dati, si può premere il tasto Order in alto a destra e passare ad una successiva View.

6.6.2 Area Set Alarm Order

La nuova schermata è formata da quattro UITableViewCell costi- tuite da una label per identificare il nome e da una UITextField, un campo di testo modificabile dall’utente. Le celle hanno a fianco un numero che rappresenta l’ordine in cui Modifica l’attributo, identificabile dalla label, compare nella query di inter- dell’ORDER BY rogazione dopo la parola chiave ORDER BY; cambiando l’ordine, cambia la query e quindi cambia il raggruppamento dei risultati. Per inserire i valori basta cliccare sul numero che si vuole modificare e comparirà la tastiera numerica, come mostrato in figura. Se l’utente non modifica niente, la query rimane identica a quella spiegata nel paragrafo precedente. Se invece vogliamo che i risultati vengano ordinati prima per tipo e poi per tempo allora basta scambiare i 2 numeri: mettere ad 1 il campo Type e 2 quello Time ottenendo come query: select attribute_id,meter_id, .... priority between 1 and 999 limit 100 order by sub_type desc, time desc, priority desc, area desc; 6.6 sezione alarms 37

Figura 33: Schermata di ordine di raggruppamento dei risultati; modalità di modiﬁca

Eventuali errori come campi vuoti, numeri non compresi tra 1 e 4 oppure valori doppi, il sistema li autocorreggerà effettuando una ricerca sugli altri campi inseriti immettendo i numeri man- canti. Premendo il tasto Done si ritorna alla finestra Filter per eventuali correzioni dei dati inseriti precedentemente ed alla fine, se l’utente riterrà di aver finito, si preme il tasto Done per la visualizzazione dei risulati.

6.6.3 Area Risultati

L’area risultati racchiude l’elenco degli allarmi che rispondono delle preferenze personalizzate o standard immesse nell’area Fil- ter ed Order. Se il numero degli elementi è troppo alto, gli allarmi vengono suddivisi in pagine consultabili grazie a pulsanti posti alla ﬁne del display. Per la costruzione di ciascuna cella-risultato, si è usata una Table Organizzazione dei View Cell contenente: dati – una label in alto a sinistra col nome del meter che ha provo- cato l’allarme. – una UIImageView che richiama la graﬁca utilizzata per di- stinguere i vari tipi di allarmi nella schermata Alarms Filter. 38 progettazione e sviluppo dell’ icem

Figura 34: Elenco dei risultati

– una label centrale col tipo di allarme – due label laterali a destra per identificare giorno ed ora dell’allarme Usando la funzionalità di IB, Push Notification, si è inserito un led con sfondo rosso sulla Tab Bar in corrispondenza del logo Alarms, per visualizzare il numero totale degli allarmi ottenuti così che, se l’utente volesse cambiare sezione dell’applicazione, quel led rimarrebbe fino alla successiva ricerca degli allarmi.

6.6.4 Area Dettagli

Grazie alla scelta progettuale di usare una Table View in un Na- vigation Controller, è stato possibile inserire maggiori dettagli per ciascun allarme semplicemente cliccando sopra un elemento della tabella. La View che si presenta visualizza tutti i parametri che identifi- cano quel particolare allarme scelto. Progettualmente la finestra contiene una serie di Label, alcune con il nome personalizzato (Provider, Area, ecc), ed altre con il contenuto di default che ver- rà modificato successivamente a codice. In questo esempio si può notare come sia utile l’utlizzo del Navigation Contoller; difatti 6.6 sezione alarms 39

Figura 35: Dettagli dell’allarme selezionato sulla barra del titolo in alto a sinistra, viene creato automatica- mento un tasto per tornare alla schermata del livello superiore col nome della View precedente, in questo caso Alarms. Per effettuare una nuova ricerca, dalla schermata Alarms si dovrà cliccare il tasto Filter e ripetere le azioni sopra descritte. Una scelta progettuale importante è stata quella di non resettare eventuali risultati e campi di ricerca personalizzati se si dovesse cambiare sezione dell’applicazione durante la sessione di lavoro. La mo- tivazione principale è stata la possibilità di avere i dati sempre disponibili all’ultima ricerca, ﬁno a quando non ne verrà effettua- ta una nuova, per poterli studiare con attenzione e per ricordarsi anche le conﬁgurazioni immesse.

7 PIANODIQUALIFICA

Per veriﬁcare il funzionamento dell’applicazione, sono state utilizzate sia l’analisi statica che quella dinamica, ad accertare la ripetibilità delle prove.

7.1 tecniche di verifica

7.1.1 Analisi statica

Le tecniche utilizzate per la verifica del codice e dei documen- ti sono stati: Inspection che Walkthrough. Nel dettaglio si sono eseguite le seguenti azioni: – Inspection * controllo degli input per ogni metodo usato; * controllo di giuste interazioni con l’interfaccia grafica * lettura mirata del codice per la ricerca di eventuali errori. – Walkthorugh lettura dell’intero codice con varie esecuzioni per controllare passo passo la presenza di eventuali errori. – Analisi del flusso di controllo accertamento di una corretta struttura del codice e delle chiamate dei metodi all’interno dell’applicazione – Analisi dei dati eliminazione di variabili inutilizzate e l’ini- zializzazione di quelle prive di valore

7.2 tecniche di validazione

7.2.1 Analisi dinamica

L’analisi dinamica si basa sull’esecuzione per più volte di parti del codice per veriﬁcare che da input conosciuti si ottengano risultati prevedibili in test facilmente ripetibili. Questo è rispettato se dagli stessi valori iniziali immessi nello stesso stato iniziale, l’esecuzione del programma porta agli stessi risultati. L’analisi dinamica ha permesso inoltre di rilevare incompatibi- lità sui tipi impostati per gli attributi sia degli eventi che degli allarmi; infatti, per i campi Price o Time presenti rispettivamente all’interno della View di Events e Alarms, inizialmente venivano

41 42 piano di qualifica

impostatati al tipo Integer, tipo uguale a quello utilizzato nel database SQLite. Questi campi però risultavano essere sempre “0” e quindi non venivano visualizzati a video, anche se, in moda- lità Debug le variabili avevano valori. Per questo si è dovuto impostare il tipo degli attributi a String.

7.2.2 Test di unità

Successivamente è stato possibile effettuare i test di unità su ciascun file, ovvero su ogni singola View che permette all’utente di interagire con l’applicazione. È stato verificato che tutti gli oggetti dell’interfaccia rispondessero in modo corretto alle interazioni con l’utente, e che i dati visualizzati fossero effettivamente quelli aspettati dalla query eseguita. Le prove sono state effettuate, sia attraverso white-box che black- box; in questo caso, per i test funzionali (black-box) è risultato di particolare aiuto il debugger, che ha permesso di evidenziare inconsistenze dovute ad una errata gestione del database all’interno dei file dell’applicazione.

7.2.3 Test di sistema

L’ultimo test effettuato è quello di sistema che verifica il corretto comportamento di tutta l’applicazione. Sia per quanto riguarda gli allarmi che per quanto riguarda gli eventi, è stato creato un database fittizio e, nel caso degli allarmi, delle personalizzazioni per verificare che i risultati visualizzati fossero idonei. 8 CONCLUSIONI

L’applicazione ottenuta sfrutta a pieno le potenzialità offerte dal- l’ambiente di sviluppo dell’iPhone e le implementazioni con programmi gestionali, quali SQLite. iCEM porta sull’iPhone dell’u- tente uno strumento efﬁcace quanto facile nel suo utilizzo grazie all’immediatezza del tocco offerto dal touchscreen del telefono e dalla semplicità dell’interfaccia graﬁca. L’obiettivo dello stage era quello di continuare l’implementazione dell’applicazione e di portarla a termine il prima possibile in quanto l’azienda, già durante il periodo di sviluppo, aveva avuto richieste di fornitura del prodotto sia in Europa che in America. Quando ho concluso il mio periodo in azienda, il primo step di sviluppo era stato completato con successo e l’iCEM era stato inviato all’Apple per essere poi immesso nel loro store. Le aspet- tative iniziali riguardo le funzionalità dell’applicazione sono state quindi pienamente soddisfatte, grazie anche al dialogo con il relatore aziendale che ha permesso di evidenziare al meglio i requisiti necessari per lo sviluppo del software. L’applicazione che fra poco si potrà scaricare, è solo alla versione 1.0 e sarà sogget- ta a miglioramenti ed upgrade; difatti tra le migliorie successive troveremo:

– storico sugli eventi – introduzione di un radar graﬁco per la questione allarmi – vari miglioramenti graﬁci

Il passo successivo sarà quello di portare l’applicazione funzio- nante sia sull’iPad che sull’iOS4, il nuovo ﬁrmware di Apple che permette il multitasking delle applicazioni, quindi sull’iPhone4. Le tempistiche e la suddivisione delle attività riportate nel modello di Gantt sono state rispettate; grazie all’interessamento personale precedente all’esperienza aziendale, il primo periodo dedicato allo studio dell’ambiente di sviluppo è stato dimezzato, così il tempo risparmiato è stato investito maggiormente nel te- sting alla ﬁne di ogni sezione sviluppata. Con l’aiuto di testi acquistati dall’azienda, dalle interazioni con l’altro stagista ed internet, lo studio ed apprendimento degli strumenti principali, quali soprattutto SQLite, è stato rapido così da non rallentare il lavoro e rispettare quindi i tempi stabiliti. Grazie all’Interface Builder, già spiegato nel capitolo 5.3, creare l’interfaccia utente e sfruttare tutti i widgets che l’SDK offre è stato molto semplice: senza scrivere alcuna riga di codice ed usando solo il mouse, ho potuto creare relazioni tra tasti e schermate, cosa che diventa complicata in altri ambienti di sviluppo. La valutazione dello

43 44 conclusioni

stage è più che positiva; nei mesi di lavoro ho potuto vivere con- cretamente giornate di lavoro da 8 ore, interagire con un team di colleghi, provare esperienze che non avrei mai avuto se avessi deciso di intraprendere uno stage interno. La cosa che più mi dà soddisfazione è quella di vedere un programma, che ho aiutato a sviluppare, proprio nell’AppStore, uno degli store più grandi ed importanti del Mondo, a disposizione di milioni di clienti e che funziona sul dispositivo che ha cambiato la vita quotidiana di molte persone negli ultimi anni: l’iPhone. Come disse Steve Jobs sulla sua meraviglia tecnologica, It’s magi- cal. 9 GLOSSARIO

C Cocoa Ambiente di programmazione orientato agli oggetti sviluppato da Apple Inc. per il sistema operativo Mac OS X utilizzando il programma XCode. I linguaggi supportati da Xcode sono L’Objective C, l’AppleScript, il C++, l’Objective C++ e Java. Ma l’ambiente Cocoa è utilizzabile anche con altri programmi di sviluppo e utilizzando anche linguaggi come il Perl, il Python (grazie al bridge PyObjC) e Ruby (grazie a RubyCocoa). Compilatore GCC GCC (GNU Compiler Collection, in origine GNU C Compi- ler) è un Compilatore multi-target; nato inizialmente come un compilatore per il linguaggio C, dispone oggi di vari front end per altri linguaggi, tra cui Java, C++, Objective C. F Firmware Il ﬁrmware è un programma, inteso come sequenza di istru- zioni, integrato direttamente in un componente elettronico. Lo scopo del programma è quello di avviare il componente stesso e consentirgli di interagire con altri componenti tramite l’implementazione di protocolli di comunicazione o interfacce di programmazione. I iSOA Architettura software adatta a supportare l’uso di servizi Web per garantire l’interoperabilità tra diversi sistemi così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente. J JavaScript JavaScript è un linguaggio che consente alle pagine HTML di fare alcune cose a seguito di azioni del lettore. Può essere usato per spedire una form quando l’utente fa un click, per illuminare un bottone (o cambiargli forma) quando il mouse ci passa sopra. JSON-RPC JSON-RPC è l’unione di JSON, formato adatto per lo scam- bio dei dati in applicazioni client-server, e RPC, costituendo

45 46 glossario

un protocollo di chiamate a procedure remote codificate in JSON. JSON è basato sul linguaggio JavaScript e viene usa- to in AJAX come alternativa a XML/XSLT. Il suo uso tramite JavaScript, è semplice, infatti è in grado di eseguirne il parsing tramite una semplice chiamata alla funzione eval(). M Microsoft.NET un progetto all’interno del quale Microsoft ha creato una piattaforma di sviluppo software, .NET, la quale è una ver- satile tecnologia di programmazione ad oggetti. Multitasking Un sistema operativo con supporto per il multitasking (mul- tiprocessualità) permette di eseguire più programmi con- temporaneamente. Per quanto riguarda l’iPhone, premendo il pulsante Home è possibile passare da un’applicazione ad un’altra. Multitouch Tecnologia a schermo tattile, evoluzione di quella touchscreen, che differisce da quest’ultima per la rilevazione di interazioni con l’utente in più punti dello schermo. P Parsing (Parser) In generale un parser è un software in grado di effettuare l’analisi sintattica di un testo rispetto ad un determinato linguaggio. Nello specifico, un parser XML è un software in grado di effettuare l’analisi sintattica di un documento XML. Come minimo, un parser XML è in grado di verificare se un documento XML è ben formato. S SDK Software Development Kit (SDK) è un termine che si può tradurre come pacchetto di sviluppo per applicazioni, e sta a indicare un insieme di strumenti per lo sviluppo e la documentazione di software. Smartphone E’ un dispositivo portatile che abbina funzionalità di gestione di dati personal e di telefono. La caratteristica più interessante degli smartphone è la possibilità di installarvi ulteriori programmi applicativi, che aggiungono nuove funzionalità. Questi programmi possono essere sviluppati dal produttore dello smartphone, dallo stesso utilizzatore, o da terze parti. SQL SQL (Structured Query Language) è un linguaggio di interrogazione per database progettato per leggere, modificare e gestire dati memorizzati in un sistema basato sul modello relazionale, per creare e modificare schemi di database, per creare e gestire strumenti di controllo ed accesso ai dati. glossario 47

T Tab Bar oggetto grafico che permette di navigare all’interno di un’applicazione tramite l’apertura di schede indicate da un segna- libro. Nel nostro caso sta ad indicare una barra posizionata in basso nello schermo che ci permette di visitare le diverse funzionalità dell’applicazione. TCP-IP Suite di protocolli TCP/IP, o suite di protocolli Internet, è un insieme di protocolli di rete che implementa la pila di protocolli su cui funziona Internet. TCP/IP contengono i due più importanti protocolli: il Transmission Control Protocol (TCP) e l’Internet Protocol (IP). Touchscreen Un touchscreen, o schermo tattile, è un particolare dispositivo, frutto dell’unione di uno schermo e di un digitalizzato- re, che permette all’utente di interagire con una interfaccia grafica mediante le dita o particolari oggetti. Uno schermo tattile è allo stesso tempo un dispositivo di output e di input. V View oggetto grafico di Interface Builder che agisce da struttura base per l’applicazione e sul quale è possibile costruire gli altri oggetti grafici dell’applicazione.

BIBLIOGRAFIA

[1] MacWorld San Francisco 2010, Keynote Address, 2010 [online](Citato a pagina 1.) . Video, Apple Inc; [2] Apple Inc., iPhone OS Reference Library 2009. Your First iPhone Application [online]. Disponibile su: http://developer.apple.com/IPhone/library/documentation/iPhone/Conceptual/iPho ne101/Articles/00Introduction.html; [3] WIKIPEDIA, 2010. iPhone – Successo commerciale [online]. Disponibile su: http://it.wikipedia.org/wiki/IPhone [Data di accesso 2/08/2010]; [4] Sviluppare applicazioni con iPhone SDK, Bill Dudney, Chris Adamson, ed 2009.

ELENCODELLEFIGURE

Figura 1 Il nuovo iPhone4 presentato a Giugno 2010 1 Figura 2 Il logo dell’SDK di Apple 2 Figura 3 Schermata di avvio di iCEM 3 Figura 4 Use case area Filter 9 Figura 5 Use case area Risultati Allarmi 10 Figura 6 Use case area Eventi 11 Figura 7 Use case area dettagli Eventi 12 Figura 8 Piano di lavoro dal 22 Aprile 2010 al 19 Maggio 2010 13 Figura 9 Piano di lavoro dal 19 Maggio 2010 al 14 Giu- gno 2010 14 Figura 10 Esempio di file header (.h) 15 Figura 11 Esempio di file .m 16 Figura 12 Esempio di file main 16 Figura 13 XCode: organizzazione della finestra principale 19 Figura 14 Finestre principali di Interface Builder 21 Figura 15 Risultato finale dell’esempio Hello World 22 Figura 16 Schermata di SQLite Database Browser 23 Figura 17 Schermata per effettuare il login 25 Figura 18 Database dell’ iCEM 26 Figura 19 Particolare della tabella Allarmi 26 Figura 20 Particolare della tabella Eventi 27 Figura 21 Tab Bar nativa di Interface Builder 27 Figura 22 Tab Bar 28 Figura 23 Schermata principale sezione Events; schermata dettagli evento 29 Figura 24 Costruzione mediante Interface Builder di una cella Events 30 Figura 25 Particolare di eventi in fase di caricamento con l’utilizzo di Activity Indicator 30 Figura 26 Particolare del codice didSelectRowAtIndexPa- th 31 Figura 27 Schermata dettagli dell’evento 31 Figura 28 Schermata dettagli consumi dell’evento 33 Figura 29 Schermata principale di Alarms: Time, Type, Priority 34 Figura 30 Schermata principale di Alarms: Area 35 Figura 31 Esempio di utilizzo dello Switch 35 Figura 32 Query di default 36 Figura 33 Schermata di ordine di raggruppamento dei risultati; modalità di modifica 37 Figura 34 Elenco dei risultati 38 Figura 35 Dettagli dell’allarme selezionato 39