Sviluppo dashboard per la gestione della programmazione di etichette NFC

Universita degli Studi di Padova

Dipartimento di Matematica

Corso di Laurea in Informatica

Sviluppo dashboard per la gestione della

programmazione di etichette NFC

Tesi di laurea triennale

Relatore

Prof.ssa Silvia Crafa

Laureando

Alberto Garbui

Anno Accademico 2014-2015

Alberto Garbui: Sviluppo dashboard per la gestione della programmazione di etichetteNFC, Tesi di laurea triennale, © Ottobre 2015.

Dedicato alla mia famiglia, in particolare ai miei genitori Mariarosa e Luciano.

Convenzioni tipografiche

Riguardo la stesura del testo, relativamente al documento sono state adottate leseguenti convenzioni tipografiche:

• gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio-nati vengono definiti nel glossario, situato alla fine del presente documento;

• i termini riportati nel glossario nella loro prima occorrenza vengono evidenziatidal simbolo g scritto a pedice;

• i termini in lingua straniera o facenti parte del gergo tecnico sono riportaticon il carattere corsivo.

v

Indice

1 Introduzione 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Introduzione alla tecnologia NFC . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Tag NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Progetto aziendale 52.1 Introduzione al problema . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Proposta di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Strumenti e tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . 6

2.3.1 MEAN stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.4 CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.5 Cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.6 Web Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Vincoli di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . 102.5.2 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . . 112.5.3 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.1 Piano di lavoro settimanale . . . . . . . . . . . . . . . . . . . 12

3 Attivita di stage 153.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . 153.1.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Design pattern utilizzati . . . . . . . . . . . . . . . . . . . . . 263.2.2 Websocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Gestione informazioni . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Gestione produzione . . . . . . . . . . . . . . . . . . . . . . . 323.3.4 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii

viii INDICE

3.4 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4.1 Analisi del codice . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Conclusioni 394.1 Conseguimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Obiettivi di progetto . . . . . . . . . . . . . . . . . . . . . . . 394.1.2 Soddisfacimento dei requisiti . . . . . . . . . . . . . . . . . . 39

4.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Valutazione delle conoscenze acquisite . . . . . . . . . . . . . . . . . 41

A MEAN stack 43A.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43A.2 Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.4 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

B Requisiti 49

C Architettura 53C.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . 53C.2 Architettura in dettaglio . . . . . . . . . . . . . . . . . . . . . . . . . 55

C.2.1 Client::views . . . . . . . . . . . . . . . . . . . . . . . . . . . 55C.2.2 Client::controllers . . . . . . . . . . . . . . . . . . . . . . . . . 58C.2.3 Client::services . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.2.4 Client::filters . . . . . . . . . . . . . . . . . . . . . . . . . . . 63C.2.5 Client::directives . . . . . . . . . . . . . . . . . . . . . . . . . 63C.2.6 Server::controller . . . . . . . . . . . . . . . . . . . . . . . . . 64C.2.7 Server::model . . . . . . . . . . . . . . . . . . . . . . . . . . . 65C.2.8 Server::schemas . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Glossario 69

Acronimi e abbreviazioni 71

Bibliografia 73

Elenco delle figure

1.1 Logo di MadeUp s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Comunicazione peer-to-peer fra dispositivi dotati di tecnologia NFC 2

1.3 Esempio di tag NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Zebra TC55 touch computer . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Protocollo websocket . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Teamwork - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Use Case - UC1: MadeUp Dashboard . . . . . . . . . . . . . . . . . 17

3.3 Use Case - UC1.1: Autenticazione . . . . . . . . . . . . . . . . . . . 18

3.4 Use Case - UC1.3: Gestione informazioni . . . . . . . . . . . . . . . 19

3.5 Use Case - UC1.3.1: Creazione informazione . . . . . . . . . . . . . . 20

3.6 Use Case - UC1.5: Gestione commesse . . . . . . . . . . . . . . . . . 22

3.7 Use Case - UC1.5.1: Creazione commessa . . . . . . . . . . . . . . . 23

3.8 Architettura client-server MadeUp . . . . . . . . . . . . . . . . . . . 25

3.9 Design pattern facade . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.10 Differenze tra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.11 Design pattern singleton . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.12 Autenticazione - login utente . . . . . . . . . . . . . . . . . . . . . . 29

3.13 Implementazione - Modifica informazioni . . . . . . . . . . . . . . . . 31

3.14 Implementazione - Visualizza informazioni . . . . . . . . . . . . . . . 32

3.15 Implementazione - Visualizzazione commesse . . . . . . . . . . . . . 33

3.16 Implementazione - Creazione commessa . . . . . . . . . . . . . . . . 33

3.17 Implementazione - Creazione task . . . . . . . . . . . . . . . . . . . . 34

3.18 Implementazione - Visualizzazione programmatori . . . . . . . . . . 35

3.19 SLOC - parte server . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.20 SLOC - parte client . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.1 MongoDB - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.2 Logo di Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A.3 AngularJS - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A.4 Two way data binding . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A.5 AngularJS injector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A.6 Node.js - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A.7 Java multi-threaded server . . . . . . . . . . . . . . . . . . . . . . . . 46

A.8 Node.js server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

C.1 Architettura generale del prodotto MadeUp - vista packages . . . . . 53C.2 Architettura client - vista classi . . . . . . . . . . . . . . . . . . . . . 54C.3 Architettura server - vista classi . . . . . . . . . . . . . . . . . . . . . 55C.4 Architettura client - componente views . . . . . . . . . . . . . . . . . 56C.5 Architettura client - componente controllers . . . . . . . . . . . . . . 59C.6 Architettura client - componente services . . . . . . . . . . . . . . . 62C.7 Architettura client - componente filters . . . . . . . . . . . . . . . . . 63C.8 Architettura client - componente directives . . . . . . . . . . . . . . 64C.9 Architettura server - componente controller . . . . . . . . . . . . . . 64C.10 Architettura server - componente model . . . . . . . . . . . . . . . . 66C.11 Architettura server - componente schemas . . . . . . . . . . . . . . . 67

Elenco delle tabelle

3.1 Tabella dei metodi WebSocket . . . . . . . . . . . . . . . . . . . . . . 35

B.1 Tabella dei requisti funzionali . . . . . . . . . . . . . . . . . . . . . . 50B.2 Tabella dei requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . 51

x

Capitolo 1

Introduzione

Il presente documento descrive il lavoro svolto durante il periodo di stage dal laureandoAlberto Garbui presso l’azienda MadeUp S.r.l. con sede in via Sile 41, Roncade (TV).Tale stage ha avuto una durata di circa 315 ore nel periodo compreso dal 18 novembre2014 al 26 gennaio 2015.In questo primo capitolo presento l’azienda ospitante descrivendone l’attivita principale.

1.1 L’azienda

MadeUp e una startup collocata all’interno dell’incubatore H-Farm. La principaleattivita e quella di offrire alle aziende prodotti software ed hardware. Lo scopoprincipale e quello di mettere a disposizione un canale comunicativo efficace einnovativo in grado di unire le aziende con i relativi clienti. Si occupa quindi disviluppare, produrre e commercializzare una piattaforma SAAS.SAAS, acronimo di Software As A Service, e un modello di distribuzione del softwareapplicativo dove un produttore di software sviluppa e gestisce un’applicazione webche mette a disposizione dei propri clienti via internet. I clienti, principalmenteaziende, non pagano per il possesso del software bensı per l’utilizzo dello stesso.MadeUp utilizza la tecnologia Near Field Communication (NFC) g per creare uncanale comunicativo tra i brand ed i consumatori. Nella sezione 1.2 descriverobrevemente la tecnologia NFC.

figura 1.1: Logo di MadeUp s.r.l.

1.2 Introduzione alla tecnologia NFC

NFC e l’acronimo di Near Field Communication e significa, letteralmente, comu-nicazione di prossimita. E un’evoluzione della tecnologia RFID (Radio FrequencyIdentification – Identificazione a radio frequenza) e consente una connettivita wireless

1

2 CAPITOLO 1. INTRODUZIONE

bidirezionale a corto raggio (fino ad un massimo di 10 cm). E stata sviluppatacongiuntamente da Philips, Sony e Nokia.La tecnologia NFC lavora ad una frequenza di 13,56 MHz e puo raggiungere unavelocita di picco di 424 kbit/s. Negli ultimi anni, molti produttori di smartphoneshanno iniziato ad integrare all’interno degli stessi questa tecnologia.

figura 1.2: Comunicazione peer-to-peer fra dispositivi dotati di tecnologia NFC

Esistono due scenari principali di funzionamento:

• comunicazione bidirezionale tra due dispositivi dotati di tecnologia NFC (en-trambi dispositivi attivi). In questo caso viene creata una rete peer-to-peer frai due dispositivi, che possono dunque scambiarsi dati a vicenda;

• comunicazione bidirezionale tra un dispositivo dotato di tecnologia NFC (attivo)ed un tag NFC (passivo). La sezione successiva (1.2.1) descrivera brevementei tag NFC.

1.2.1 Tag NFC

I tag NFC sono dei minuscoli chip di memoria solitamente integrati in supporti dicarta, di PVC o altri materiali in base all’applicazione finale. Sono dispositivi passivi,ovvero non hanno una fonte di energia propria ma vengono alimentati grazie al campomagnetico generato dal dispositivo NFC che li legge e scrive. Questa caratteristicapermette alle ditte produttrici di creare tag NFC di dimensioni veramente ridottecosı da poterli applicare ad un vasto numero di supporti, ampliando cosı il campoapplicativo.

1.3 L’idea

Il sistema MadeUp, in grado di mettere in contatto i brand e i consumatori, sfruttal’innovativa tecnologia NFC applicata ai piu svariati prodotti attualmente in com-mercio permettendo cosı a chiunque dotato di uno smartphone di accedere ad unaserie di servizi legati ai prodotti. Il sistema MadeUp comprende:

1.3. L’IDEA 3

figura 1.3: Esempio di tag NFC

• l’industrializzazione della scrittura dei tag NFC;

• il controllo remoto dei dispositivi di scrittura;

• la gestione dei dati raccolti e inseriti all’interno dei tag;

• la gestione delle informazioni che vengono associate al prodotto;

• l’implementazione di applicazioni mobile per captare i tag nei prodotti, reperireinformazioni del prodotto e verificarne l’autenticita.

Capitolo 2

Progetto aziendale

Questo capitolo descrivera la proposta di stage, gli strumenti e tecnologie utilizzate, gliobiettivi ed i vincoli che mi sono stati imposti nello svolgere la mia attivita di stage.

2.1 Introduzione al problema

Una dei punti di forza dei tag NFC e la loro univocita in quanto ogni tag NFCpossiede un proprio identificativo univoco imposto dal produttore stesso durante ilprocesso produttivo.Questa particolarita ben si coniuga con il progetto MadeUp in quanto permette diassociare delle informazioni univoche ad ogni prodotto commerciale che possiede alsuo interno un tag NFC programmato con il sistema MadeUp.Fin da subito quindi l’azienda si e resa conto della necessita di un sistema chepotesse gestire questa grande mole di informazioni nonche l’inserimento delle stesseall’interno dei tag NFC durante la fase di programmazione dei chip.

2.2 Proposta di stage

Il progetto di stage ha come obiettivo lo sviluppo di un pannello di amministrazioneweb che permetta all’utente utilizzatore di gestire le informazioni presenti nel sistemae creare delle commesse per i dispositivi di scrittura dei tag NFC.MadeUp utilizza i TC55 prodotti da Zebra [14] come dispositivi di scrittura deitag NFC. I TC55 sono dei computer tascabili per utilizzo lavorativo, sono dotatidi lettore di codice a barre ed NFC. Questi dispositivi utilizzando un’applicazionerealizzata ad hoc per restare connessi al sistema MadeUp tramite rete internet cosıda permettere la ricezione delle commesse da eseguire e l’invio dei dati relativi aitag NFC programmati. La figura 2.1 mostra il modello TC55 prodotto da Zebrautilizzato durante l’attivita di stage.L’applicazione da realizzare quindi puo essere suddivisa in due parti principali:

Gestione informazioni: l’utente puo gestire le informazioni presenti nel sistema,in particolare:

• visualizzare la lista di informazioni presenti;

5

6 CAPITOLO 2. PROGETTO AZIENDALE

figura 2.1: Zebra TC55 touch computer

• inserire una nuova informazione inserendo un titolo, una descrizione edeventualmente dei files multimediali;

• modificare un’informazione esistente.

Gestione produzione: l’utente puo gestire la produzione di etichette NFC creandodelle commesse che verranno inviate automaticamente ai dispositivi di scritturadei tag NFC, in particolare dovra essere in grado di:

• creare una commessa di lavoro selezionando un’informazione precedente-mente creata e fissando una quantita da produrre;

• creare eventuali tasks per una commessa esistente per suddividere il lavoroa piu dispositivi di scrittura;

• controllare lo stato dei dispositivi di scrittura.

Gestione dispositivi di scrittura: il sistema deve notificare in modo automaticola lista di tasks disponibili ai vari dispositivi di scrittura che sono connessitramite Web Socket.

2.3 Strumenti e tecnologie utilizzate

In questa sezione vengono descritte le tecnologie e gli strumenti principalmenteutilizzati dall’azienda e di conseguenza da me stesso durante il progetto di stage.

2.3. STRUMENTI E TECNOLOGIE UTILIZZATE 7

2.3.1 MEAN stack

L’azienda utilizza i vari frameworks g presenti nello stack MEAN (MongoDB Ex-press.js AngularJS Node.js), infatti per lo sviluppo del back-end delle varie appli-cazioni e per lo sviluppo di web-services g , viene utilizzato il framework Node.jsassieme a Express.js. Per lo sviluppo della parte front-end viene invece utilizzatoAngularJS. Per quanto riguarda invece la persistenza dei dati delle applicazioni vieneutilizzato MongoDB. MongoDB e i database non relazionali in generale offrono unamaggior efficienza in situazioni in cui le moli di dati tendono a crescere in manieravertiginosa, soluzione che ben si coniuga alle necessita di scalabilita di una startupcome MadeUp. Una descrizione di queste componenti e disponibile in Appendice A.Nella mia attivita di stage ho utilizzato questi frameworks per sviluppare la partefrontend e la parte backend del pannello di amministrazione web.

2.3.2 Bootstrap

Bootstrap e un piccolo framework per lo sviluppo di front-end web moderni ed efficaci,creato in Twitter da due sviluppatori interni e distribuito attraverso la licenza Apache2.0. Fornisce un CSS di base molto avanzato e una libreria JavaScript basata sujQuery per le animazioni e gli effetti visivi. Questi elementi permettono un uso quasiimmediato delle potenzialita di questo framework, demandando allo sviluppatoresolamente la pulizia del CSS di base di tutte le caratteristiche extra non utilizzate(solamente per diminuire la dimensione del file .css se desiderato) e piccole modifichea colori e stili. Nella mia attivita di stage ho utilizzato questo framework perfacilitare lo sviluppo dell’interfaccia utente frontend, in quanto Bootstrap presentamolti elementi grafici di uso comune gia pronti e di facile implementazione.

2.3.3 HTML5

HTML5 e un linguaggio di markup per la strutturazione delle pagine web. Le novitaintrodotte dall’HTML5 rispetto all’HTML4 sono finalizzate soprattutto a migliorareil disaccoppiamento tra struttura, definita dal markup, caratteristiche di resa (tipodi carattere, colori, eccetera), definite dalle direttive di stile, e contenuti di unapagina web, definiti dal testo vero e proprio. Inoltre l’HTML5 prevede il supportoper la memorizzazione locale di grosse quantita di dati scaricati dal web browser,per consentire l’utilizzo di applicazioni basate su web (come per esempio le caselle diposta di Google o altri servizi analoghi) anche in assenza di collegamento a Internet.

2.3.4 CSS3

Il CSS (Cascading Style Sheets, in italiano fogli di stile), in informatica, e unlinguaggio usato per definire la formattazione di documenti HTML, XHTML eXML ad esempio in siti web e relative pagine web. Le regole per comporre ilCSS sono contenute in un insieme di direttive emanate a partire dal 1996 dalW3C. L’introduzione del CSS si e resa necessaria per separare i contenuti dallaformattazione e permettere una programmazione piu chiara e facile da utilizzare, siaper gli autori delle pagine HTML che per gli utenti, garantendo contemporaneamenteanche il riuso di codice ed una sua piu facile manutenibilita.


2.3.5 Cloud computing

MadeUp utilizza diversi fornitori di servizi cloud tra cui Microsoft Azure e Parse.L’utilizzo di questi servizi di cloud computing mi e stato indicato a priori in quanto giautilizzati dall’azienda ancor prima dell’inizio del periodo di stage. Nella mia attivitadi stage ho utilizzato Microsoft Azure e Parse per eseguire il deploy dell’applicazioneweb e per usufruire di alcuni servizi accessori quali tracciamento degli errori e gestionedegli utenti.

2.3.5.1 Microsoft Azure

Microsoft Azure e una piattaforma di cloud computing IaaD (Infrastructure-as-a-Service) e PaaS (Platform-as-a-Service) aperta, flessibile e di fascia Enterprise.Permette l’utilizzo di una piattaforma software installata in un server remoto chepuo essere costituita da diversi servizi, programmi, librerie, etc.

2.3.5.2 Parse

Parse e una piattaforma di cloud computing BaaS ovvero un fornitore di backend diconsumo in grado di creare ponte tra il frontend di un’applicazione e vari cloud-basedbackends tramite una API unificata e un SDK che facilita il lavoro degli sviluppatori.

2.3.6 Web Socket

WebSocket e una tecnologia web che fornisce canali di comunicazione full-duplexattraverso una singola connessione TCP, e disegnato per essere implementato sialato browser che lato server, ma puo essere utilizzato anche da qualsiasi applicazioneclient-server. Il protocollo e un’implementazione basata sul protocollo TCP. Lasua unica correlazione con l’HTTP e nel modo in cui fa l’handshake durante unaUpgrade request tra server. Il protocollo WebSocket permette maggiore interazionetra un browser e un server, facilitando la realizzazione di applicazioni che fornisconocontenuti in tempo reale. Questo e reso possibile fornendo un modo standard peril server di mandare contenuti al browser senza dover essere sollecitato dal cliente permettendo ai messaggi di andare e venire tenendo la connessione aperta. Lafigura 2.2 visualizza le principali differenze tra una connessione HTTP normale eduna connessione WebSocket.

Nella mia attivita di stage ho utilizzato la tecnologia Web Socket per comunicarein tempo reale con i dispositivi di scrittura NFC e notificare la presenza di nuovecommesse/lavori da eseguire una volta che l’utente web termina la creazione di unacommessa.

2.4 Obiettivi

Di seguito sono indicati gli obiettivi dell’attivita di stage divisi tra funzionali,operativi, esplorativi e formativi:

funzionali: includono il soddisfacimento dei requisiti che riguardano le funzionalitaprincipali che l’applicazione web deve avere alla fine dello stage. Essi descrivono

2.4. OBIETTIVI 9

figura 2.2: Protocollo websocket

i servizi del pannello di amministrazione web che devono essere implementa-ti nell’applicazione e rappresentano il punto focale dello stage. L’obiettivominimo da raggiungere e la definizione e lo sviluppo delle tre sezioni (gestio-ne informazioni, gestione produzione e gestione dispositivi programmatori)precedentemente descritte nella sezione 2.2.

operativi: specificano le competenze che lo stagiaire deve acquisire per essere ingrado di lavorare all’interno di una realta aziendale come quella di MadeUp.Durante un primo periodo di stretto affiancamento ho avuto modo di osservarele regole e le procedure di lavoro del team e i servizi utilizzati a supportodell’esecuzione di tali procedure.In particolare l’obiettivo e farmi entrare quanto prima in contatto con:

• strumenti per la comunicazione aziendale, servizi di ticketing e di gestionedei progetti;

• sistema di controllo di versione del codice aziendale;

• stesura della documentazione e comunicazione con il tutor esterno.

esplorativi: delineano il livello di capacita di indagine dello stagiaire rispetto alproliferarsi delle nuove tecnologie che a distanza di brevissimi lassi di tempoevolvono, si rinnovano, migliorano o diventano obsolete. Pur avendo delineato


le tecnologie core dei propri prodotti, l’azienda si ritiene flessibile e inclineal cambiamento qualora fosse possibile ottenere risultati migliori con altristrumenti. Il progetto di stage e stato quindi occasione di studio e valutazionedi tali tecnologie, impiegate criticamente per evidenziarne pregi e difetti. Inparticolare una delle attivita svolte durante il periodo di stage e stata valutarese le tecnologie impiegate siano le migliori per raggiungere gli obiettivi fissati,in termini di prestazioni, compatibilita e facilita d’uso.

formativi: gli obiettivi sono stati discussi durante i colloqui conoscitivi primadell’inizio dello stage, delineando quelli che sarebbero dovuti essere gli aspettida valorizzare affinche il tirocinio potesse essere considerato completo inmaniera soddisfacente da ambo le parti.I principali aspetti formativi che ho preso in considerazione sono:

• entrare in contatto con alcune tecnologie che non ho avuto modo diutilizzare precedentemente come le comunicazioni dati tramite Web Socketed i servizi di cloud-computing, nel contempo approfondendo le mieconoscenze di Node.js e AngularJS. L’obiettivo in questo caso e in parteesplorativo e d’altra parte di consolidamento;

• dal punto di vista metodologico, l’obiettivo e l’inserimento in un teamdi lavoro vero e proprio in quanto e la mia prima esperienza in questosettore.

2.5 Vincoli di progetto

Il pannello amministrativo, e una parte di un sistema piu complesso ed articolatoquindi ho dovuto tener conto fin da subito dell’integrazione di tale componente.Il sistema esistente infatti comprendeva:

• la gestione del protocollo di comunicazione con l’applicazione mobile per laverifica di autenticita dei tag NFC;

• la gestione del protocollo di comunicazione con i dispositivi di scrittura deitag NFC tramite Web Socket.

Di seguito descrivero le varie tipologie di vincoli che sono stati imposti dall’azienda.

2.5.1 Vincoli tecnologici

Come anticipato in Sezione 2.3, le tecnologie core di MadeUp sono i quattro fra-meworks dello stack MEAN, che sono state quindi imposte come vincolo tecnologicoal progetto. Personalmente durante il corso di Ingegneria del Software1 ho avutomodo di sviluppare il progetto MaaP2 che utilizza anch’esso lo stack MEAN. Questetecnologie rappresentano uno standard de facto nei rispettivi settori, pertanto unamia scelta non sarebbe ricaduta su tecnologie diverse.L’utilizzo della comunicazione Web Socket con i dispositivi di scrittura dei tag NFC

1Ingegneria del Software mod. A [5]2MaaP - MongoDB as an Admin Platform [8]

2.6. PIANO DI LAVORO 11

era gia stata implementata per garantire una comunicazione continua ed in temporeale. Questo vincolo imposto fin da subito dall’azienda mi ha permesso di conoscerequesta nuova tecnologia e di valutarne pregi e difetti.Per quanto riguarda gli strumenti di sviluppo mi e stata lasciata totale liberta,quindi sia il sistema operativo che l’ambiente di sviluppo sono stati scelti da me.Questo aspetto mira a favorire l’operativita del singolo sviluppatore che si trovafin da subito con strumenti che conosce e con cui ha confidenza. Io ho adottatoMicrosoft Windows 8.1 come sistema operativo e Sublime Text come editor di codiceper la sua vasta disponibilita di plug-in per lo sviluppo di applicazioni in Node.js edAngularJS oltre al fatto che gia utilizzavo questi strumenti durante lo sviluppo deivari progetti universitari.

2.5.2 Vincoli metodologici

L’inserimento in un team di lavoro necessita di regole definite affinche la collabora-zione sia da subito produttiva e ogni componente sappia come svolgere ogni attivita.I vincoli posti dall’azienda riguardano:

Sistema di controllo di versione: integrazione nel flusso adottato dal team, quin-di git, regolato da norme interne;

Patrimonio documentale: documentazione di tutti i requisiti stabiliti in fase dianalisi, una breve specifica delle componenti individuate in fase di progettazioneed infine un resoconto dei risultati dei test eseguiti in fase di validazione;

Riunioni: pianificate in base alle necessita, al sorgere di nuovi problemi o comunquecon cadenza settimanale.

2.5.3 Vincoli temporali

La scansione temporale delle attivita e stata fissata nel piano di lavoro creatonelle due settimane precedenti all’inizio dello stage. Il completamento dell’attivitadi sviluppo, comprensiva di test e validazione e stato stimato in 315 ore, inferioredunque al limite massimo previsto per il tirocinio pari a 320 ore. E stato preventivatonel piano di lavoro un periodo di ambientazione attraverso lo studio delle nuovetecnologie e del dominio del progetto da parte mia, in modo che possa conoscere ilcontesto del progetto attuale e comprendere al meglio le tecnologie che andro adutilizzare. Il piano di lavoro previsto con il tutor aziendale e riportato nella sezionesuccessiva.

2.6 Piano di lavoro

Il progetto di stage prevedeva le seguenti fasi di lavoro:

Studio accurato del prodotto attuale (70h)

Acquisizione competenze specifiche per il progetto (35h)

Definizione ed analisi dei problemi (35h)


Raccolta delle informazioni e studio delle soluzioni (35h)

Implementazione pannello amministrativo, test pratici (105h)

Raccolta dei risultati e redazione del rapporto finale (35h)

2.6.1 Piano di lavoro settimanale

A seguire e riportato il piano settimanale di lavoro (35h a settimana) con indicazionedelle principali attivita e del carico di lavoro.

1. Studio del prodotto (35h)

• Familiarizzare con gli strumenti di sviluppo utilizzati (10h)

• Imparare ad utilizzare i dispositivi di scrittura NFC (25h)

2. Acquisizione competenze di ingegnerizzazione del prodotto (35h)

• Studio dei dispositivi tag NFC (10h)

• Studio del sistema di cifratura dei tag (10h)

• Studio del sistema di comunicazione tra dispositivi (10h)

• Studio dei componenti del sistema (5h)

3. Studio del attuale dashboard (35h)

• Studiare l’attuale soluzione (20h)

• Analisi dei requisiti (15h)

4. Studio del attuale dashboard (35h)

• Studiare l’attuale soluzione (10h)

• Analisi dei requisiti (25h)

5. Sviluppo dashboard (35h)

• Re-ingegnerizzazione (15h)

• Raccolta delle informazioni necessarie allo sviluppo (10h)

• Studio delle informazioni raccolte (10h)


• Valutazione soluzione proposta

• Codifica (20h)

• Verifica e validazione (10h)

• Stesura della documentazione necessaria (5h)


• Codifica (15h)

• Verifica e validazione (15h)

2.6. PIANO DI LAVORO 13


8. Sviluppo dashboard - Testing (35h)

• Testing (20h)

• Testing del sistema online (10h)


9. Sviluppo dashboard - Testing e Documentazione (35h)

• Testing del sistema online (25h)

• Stesura e riordino della documentazione (10h)

Riepilogo: 9 settimane per un totale di 315 ore

Capitolo 3

Attivita di stage

In questo capitolo descrivo i punti salienti del lavoro svolto, analizzando la gestione delprogetto e le attivita che hanno portato valore nello svolgimento dello stesso.

3.1 Analisi dei requisiti

3.1.1 Tracciamento dei requisiti

La gestione dell’insieme di vincoli e funzionalita da garantire e un’attivita complessa,soprattutto a seguito di riunioni che provocano variazioni nei requisiti. L’aziendaha da sempre utilizzato Teamwork - Projects1 come strumento per la gestione delprogetto e tracciamento dei requisiti, strumento che ho imparato ad usare anch’ioe che mi ha permesso di tenere traccia delle fonti dei requisiti, di classificare ognirequisito e di controllare il soddisfacimento degli stessi.

figura 3.1: Teamwork - Logo

1Teamwork - Projects [13]

15

16 CAPITOLO 3. ATTIVITA DI STAGE

3.1.2 Casi d’uso

Per lo studio dei casi di utilizzo del prodotto sono stati creati diversi diagrammi usecase in linguaggio Unified Modeling Language (UML) che ho descritto esaustivamentenel documento aziendale interno di Analisi dei Requisiti. Nella presente relazioneriporto solo i casi d’uso salienti, i piu significativi, che permettono di capire comel’utente puo interagire con il sistema per eseguire le attivita principali di inserimentodelle informazioni e creazione delle commesse/tasks. Ogni caso d’uso presente neldocumento segue il seguente formalismo.

Codice identificativo: codice univoco composto da:

UC: Use Case, caso d’uso;

Identificativo: un valore numerico gerarchico per permettere l’organizzazionedei casi d’uso.

Diagramma UML in figura corredata di una breve didascalia descrittiva;

Attori principali che possono essere uno o piu;

Attori Secondari che possono essere zero o piu;

Scopo e descrizione descrizione del caso d’uso;

Precondizione vera affinche lo use case si possa verificare;

Postcondizione vera e sempre verificata dopo lo svolgimento dello use case;

Scenario principale descrive il flusso di azioni principale;

Scenario alternativo descrive il flusso di azioni alternative.

UC1: MadeUp Dashboard

Attori principali: Utente, Utente autenticato.

Scope e descrizione: Questo caso d’uso definisce le funzionalita che vengonousufruite dall’utente al suo primo contatto con l’applicazione web. Un utente senon autenticato avra la possibilita di autenticarsi, mentre gli altri utenti possonoaccedere alla dashboard o terminare la sessione.

Precondizioni: l’Utente ha inserito e richiesto l’URL radice dell’applicazioneall’interno del proprio browser.

Postcondizioni: il sistema ha verificato l’autenticazione dell’utente e in caso siaautenticato ha permesso all’utente di interagire con le varie funzionalita.

Scenario principale:

1. l’Utente ha la possibilita di autenticarsi (UC1.1);

2. l’Utente autenticato puo visualizzare le informazioni presenti nel sistema(UC1.2);

3.1. ANALISI DEI REQUISITI 17

figura 3.2: Use Case - UC1: MadeUp Dashboard

3. l’Utente autenticato puo gestire le informazioni presenti nel sistema (UC1.3);

4. l’Utente autenticato puo visualizzare le commesse presenti nel sistema (UC1.4);

5. l’Utente autenticato puo gestire le commesse presenti nel sistema (UC1.5);

6. l’Utente autenticato puo disconnettersi dal sistema (UC1.6).

.

UC1.1: Autenticazione

Attori principali: Utente.

Scope e descrizione: Questo caso d’uso definisce le funzionalita che vengonousufruite dall’utente durante il processo di autenticazione.

Precondizioni: l’Utente ha inserito e richiesto l’URL radice dell’applicazione


figura 3.3: Use Case - UC1.1: Autenticazione

all’interno del proprio browser.

Postcondizioni: il sistema ha verificato l’autenticazione dell’utente, in caso d’errorenei dati inseriti e stato visualizzato un messaggio d’errore.


1. l’Utente puo inserire le sue credenziali (UC1.1.1).

.

Scenario alternativo: Se l’Utente inserisce delle credenziali errate per il login,appare un messaggio di errore (UC1.1.2).

UC1.1.1: Inserimento credenziali


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente per inserire le credenziali di autenticazione nel sistema.

Precondizioni: l’Utente ha inserito e richiesto l’URL radice dell’applicazioneall’interno del proprio browser.

Postcondizioni: il sistema ha rilevato le credenziali di autenticazione dell’Utente.

UC1.1.2: Visualizzazione messaggio d’errore


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente per visualizzare un messaggio d’errore in caso le credenziali d’accessofornite siano errate o incomplete.

Precondizioni: l’Utente ha inserito delle credenziali d’accesso errate o incomplete.


Postcondizioni: il sistema ha visualizzato un messaggio d’errore.

UC1.2: Visualizzazione informazioni

Attori principali: Utente autenticato.

Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per visualizzare le informazioni presenti nel sistema.

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla visualizzazionidelle informazioni.

Postcondizioni: il sistema ha permesso all’utente autenticato di visualizzare leinformazioni presenti.

UC1.3: Gestione informazioni

figura 3.4: Use Case - UC1.3: Gestione informazioni


Scope e descrizione: Questo caso d’uso definisce le funzionalita che vengonousufruite dall’utente autenticato per gestire le informazioni presenti nel sistema.

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla gestione delleinformazioni.

Postcondizioni: il sistema ha permesso all’utente autenticato di gestire le informa-zioni presenti.


1. l’Utente autenticato puo creare una nuova informazione (UC1.3.1);


2. l’Utente autenticato puo eliminare un’informazione esistente(UC1.3.2).

.

UC1.3.1: Creazione informazione

figura 3.5: Use Case - UC1.3.1: Creazione informazione


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per creare ed inserire una nuova informazione nel sistema.

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla creazione diuna nuova informazione.

Postcondizioni: il sistema ha salvato in modo permanente la nuova informazione.


1. l’Utente autenticato puo inserire il titolo dell’informazione (UC1.3.1.1);

2. l’Utente autenticato puo inserire la descrizione dell’informazione (UC1.3.1.2);

3. l’Utente autenticato puo inserire dei files multimediali da associare all’informa-zione (UC1.3.1.3);

.

UC1.3.1.1: Inserimento titolo



Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per inserire il titolo dell’informazione da creare.


Postcondizioni: il sistema ha identificato il titolo per la creazione della nuovainformazione.

UC1.3.1.2: Inserimento descrizione


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per inserire la descrizione dell’informazione da creare.


Postcondizioni: il sistema ha identificato la descrizione per la creazione della nuovainformazione.

UC1.3.1.3: Inserimento files multimediali


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per associare dei files multimediali all’informazione da creare.


Postcondizioni: il sistema ha identificato i files multimediali da associare allanuova informazione.

UC1.3.2: Eliminazione informazione


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per eliminare un’informazione dal sistema.

Precondizioni: l’Utente autenticato ha selezionato l’informazione da eliminare.

Postcondizioni: il sistema ha rimosso permanentemente l’informazione dal sistema.

UC1.4: Visualizzazione commesse


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per visualizzare le commesse presenti nel sistema.

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla visualizzazionidelle commesse.


Postcondizioni: il sistema ha permesso all’utente autenticato di visualizzare lecommesse presenti.

UC1.5: Gestione commesse

figura 3.6: Use Case - UC1.5: Gestione commesse


Scope e descrizione: Questo caso d’uso definisce le funzionalita che vengonousufruite dall’utente autenticato per gestire le commesse presenti nel sistema.

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla gestione dellecommesse.

Postcondizioni: il sistema ha permesso all’utente autenticato di gestire le commessepresenti.


1. l’Utente autenticato puo creare una nuova commessa (UC1.5.1);

2. l’Utente autenticato puo eliminare una commessa esistente(UC1.5.2).

.

UC1.5.1: Creazione commessa


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per creare una nuova commessa.


figura 3.7: Use Case - UC1.5.1: Creazione commessa

Precondizioni: l’Utente autenticato ha aperto la pagina relativa alla creazione diuna nuova commessa.

Postcondizioni: il sistema ha creato una nuova commessa.


1. l’Utente autenticato puo selezionare un’informazione presente nel sistema(UC1.5.1.1);

2. l’Utente autenticato puo inserire la quantita da produrre (UC1.5.1.2);

3. l’Utente autenticato puo suddividere in lavoro della commessa in piu task(UC1.5.1.3).

.

UC1.5.1.1: Selezione informazione


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per selezionare un’informazione presente nel sistema.


Postcondizioni: il sistema ha identificato l’informazione da associare alla commessa.

UC1.5.1.2: Inserimento quantita



Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per impostare la quantita da produrre per la nuova commessa.


Postcondizioni: il sistema ha identificato la quantita da produrre per la commessa.

UC1.5.1.3: Creazione task


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per suddividere la commessa in sottolavori chiamati tasks.


Postcondizioni: il sistema ha identificato con quanti e quali task la commessa saracomposta.

UC1.5.2: Eliminazione commessa


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato per eliminare una commessa dal sistema.

Precondizioni: l’Utente autenticato ha selezionato la commessa da eliminare.

Postcondizioni: il sistema ha rimosso permanentemente la commessa dal sistema.

UC1.6: Disconnessione


Scope e descrizione: Questo caso d’uso definisce la funzionalita che viene usufruitadall’utente autenticato disconnettersi dal sistema e terminare la sessione.

Precondizioni: l’Utente autenticato sceglie di terminare la sessione.

Postcondizioni: il sistema ha eliminato la sessione dell’Utente autenticato.

3.1.3 Requisiti

A partire dai casi d’uso ho fatto emergere i requisiti che l’applicazione web dasviluppare deve coprire affinche siano raggiunti gli obiettivi prefissati da MadeUp.Tali requisiti sono tuttavia un sottoinsieme della totalita. A tali requisiti di tipofunzionale infatti ne vengono aggiunti di altre categorie, come i requisiti di vincolosul progetto, i requisiti qualitativi del prodotto o dei processi, o i requisiti ditipo tecnologico. Completando i funzionali con le categorie appena citate si puo

3.2. PROGETTAZIONE 25

apprezzare la completezza finale dei requisiti. Ho riportato i requisiti di primo esecondo livello in Appendice B.

3.2 Progettazione

La fase di progettazione e stata influenzata notevolmente dalle tecnologie che misono state indicate dall’azienda e che ho descritto nella Sezione 2.3. In particolarel’utilizzo dello stack MEAN ha facilitato notevolmente la progettazione dell’architet-tura iniziale in quanto le varie componenti dello stack si integrano molto facilmentetra di loro.

figura 3.8: Architettura client-server MadeUp

AngularJS e ispirato al pattern architetturale MVC. Il suo punto forte e l’avanzatagestione dei dati client-side, che viene usata per mostrare informazioni all’utente.Offre infatti avanzati sistemi di gestione del dato e visualizzazione di grafici, pre-sentando all’utente l’applicazione sotto forma di single page application, ovveroun’applicazione in un unica pagina web contenente tutte le funzionalita necessariesenza alcun caricamento di pagina e attesa. Sono i controller di AngularJS cheattraverso dei appositi servizi riescono a generare le richieste http da inviare al server.

NodeJS viene invece impiegato per la sua implementazione server grazie anche almodulo Express che facilita la gestione delle richieste ed il successivo inoltro delle


stesse ai vari controller che potranno o meno interagire con il database MongoDB.

Back-end e front-end interagiscono dunque attraverso API di tipo RESTful. InFigura 3.8 mostro la situazione descritta.

Una descrizione dettagliata dell’architettura e disponibile in Appendice C.

3.2.1 Design pattern utilizzati

All’interno del progetto ho utilizzato diversi design pattern, di seguito descrivo iprincipali evidenziando la motivazione del loro utilizzo e conseguentemente i risultatiottenuti.

3.2.1.1 Facade

e un pattern che fornisce una semplice interfaccia ad un’ampia quantita di codice efunzionalita. Accentra le richieste e si occupa del loro smistamento verso l’esterno.

figura 3.9: Design pattern facade

ho usato questo pattern per accentrare in pochi servizi tutte le funzionalita che ri-chiedessero dati al back-end, quindi fornendo un’interfaccia semplice ad una strutturacomplessa come l’API definita. In questo modo intervenire in seguito a cambiamentidel back-end risulta immediato, garantendo manutenibilita ed estensibilita. Nellapratica l’utilizzo di questo pattern e stato facilitato grazie al router di Express ilquale raccoglie tutte le richieste ricevute dal server e le smista ai vari controller.

3.2.1.2 IoC

il pattern Inversion of Control serve ad accoppiare gli oggetti a runtime attraverso unIoC container. Le dipendenze possono quindi essere “iniettate” dall’esterno: non sisegue il normale flusso di controllo dei linguaggi imperativi, in cui, nel momento delbisogno, si richiamano funzioni di classi o librerie esterne. Gli oggetti non istanziano

3.2. PROGETTAZIONE 27

e richiamano gli oggetti dal quale il loro lavoro dipende, ma queste funzionalitavengono fornite da un ambiente esterno tramite dei contratti definiti da entrambe leentita.[4] Nella pratica questo pattern si implementa con la dependency injection,caratteristica spiccata di AngularJS.

figura 3.10: Differenze tra

ho usato questo pattern nella definizione dei moduli dell’applicazione web, ognunodei quali dichiara delle dipendenze che solo a runtime vengono soddisfatte. Inquesto modo ho potuto disaccoppiare completamente l’esecuzione dei task dallaloro implementazione, e prevenire i side effects che si possono creare sostituendo unmodulo.

3.2.1.3 Singleton

e un design pattern creazionale che ha lo scopo di garantire che di una determinataclasse venga creata una e una sola istanza, e di fornire un punto di accesso globale atale istanza.

figura 3.11: Design pattern singleton

ho usato questo pattern nella creazione dei servizi AngularJS, che sono singletonper costruzione. Questa caratteristica permette di creare oggetti capaci di mantenerelo stato di una risorsa, in modo da potervi accedere in lettura dalle varie componenticontroller. I controller dichiarano infatti dipendenze dai servizi e ne ottengonotutti la medesima istanza, garantendo consistenza del dato acceduto. D’altro cantoi servizi supportano la lazy initialization, vengono quindi istanziati solo quando


effettivamente richiesti da qualche altra componente, garantendo un efficiente usodelle risorse.

3.2.2 Websocket

Nel mio progetto la gestione delle connessioni websocket ha avuto una particolareimportanza in quanto come requisito era necessario permettere una comunicazionebidirezionale ed in tempo reale tra i vari client connessi ed il server.

3.3 Implementazione

Per lo sviluppo e la gestione del codice ho scelto degli strumenti che mi permettesserodi automatizzare quanto piu possibile le attivita che ad ogni progetto si ripropongono.Ho cercato qualcosa in grado di gestire in maniera efficace ed efficiente il ciclo divita del software, aderendo quanto possibile alle tendenze in termini di gestione deifile e attivita di build. Nell’ambiente JavaScript i tool che ho preferito sono:

NPM[10]: e il modulo di gestione dei pacchetti di NodeJS, grazie ad un file JSONdi configurazione e possibile dichiarare le componenti di terze parti che sivogliono utilizzare nel progetto;

Bower[1]: e uno strumento per gestire i pacchetti e le loro dipendenze. Attraversola definizione di un file JSON di configurazione, vengono esplicitate le librerienecessarie all’esecuzione dell’applicazione. Bower gestisce alberi di dipendenzacon livelli singoli, proprio perche, in ambito web, si ha bisogno di libreriecomplete che non dipendano da ulteriori pacchetti.

Il codice e stato scritto seguendo per quanto possibile la progettazione e documentan-do adeguatamente. La realizzazione dell’interfaccia web e delle relative API CRUDlato server si sono rivelate abbastanza semplici visto la mia recente esperienza con ilprogetto di Ingegneria del Software. L’implementazione lato server della gestionedella connessione websocket invece e stata piu impegnativa per diversi motivi:

• personalmente non avevo mai utilizzato questa tecnologia, infatti ho dovutodedicare diverse ore di studio per capire sia il funzionamento della connessionewebsocket sia l’utilizzo di alcune librerie di supporto;

• a livello di requisiti riguardanti la struttura dei messaggi websocket ci sonostate diverse iterazioni che hanno cambiato i requisiti iniziali e di conseguenzahanno portato a diverse iterazioni nello sviluppo del codice;

• alcuni servizi di Cloud Computing come ad esempio Parse non permettonol’utilizzo di una connessione websocket prolungata nel tempo in quanto latariffazione e basata sul numero di connessioni. Non conoscendo questalimitazione a priori, questo fatto ha avuto come conseguenza lo spostamentoobbligato di tutto il back-end su altri servizi di Cloud Computing che accettanoconnessioni websocket (nel mio caso Microsoft Azure) e quindi uno studioulteriore della nuova piattaforma da utilizzare.

3.3. IMPLEMENTAZIONE 29

3.3.1 Autenticazione

Uno dei requisiti dell’applicazione era permettere all’utente di autenticarsi al sistema.Tale funzionalita e stata implementata utilizzando un semplice form lato web cheinvia al server una richiesta POST HTTP contenente le credenziali dell’utenteutilizzando il servizio di AngularJS relativo alla gestione dell’autenticazione:

1 login: function(user , success , error) {

2 $http.post(API.login , user).success(function(user) {

3 changeUser(user);

4 success(user);

5 }).error(error);

6 }

La richiesta utilizza una specifica API adeguatamente implementata lato server chesi occupa di controllare la presenza dell’utente nel sistema eseguendo una query suldatabase e controllando se le credenziali sono corrette. In figura 3.12 e rappresentatoil form di immissione delle credenziali utente.

figura 3.12: Autenticazione - login utente

In questo caso l’utilizzo delle librerie lato server quali Passport e MongoStoreha facilitato l’implementazione in modo considerevole. Passport infatti permette didefinire una strategia per l’autenticazione utente in modo semplice e veloce:

1 passport.use('user', new LocalStrategy ({

2 usernameField: 'username ',

3 passwordField: 'password '

4 },

5 function(username , password , done) {

6 password = crypto.createHmac('sha1', app.config.app.cryptoKey)

.update(password).digest('hex');

7 return getUser ({

8 username: username.toLowerCase (),

9 password: password ,

10 enabled: true

11 }, done);

12 }));


Mentre la libreria MongoStore permette di salvare la sessione utente nel databaseuna volta l’autenticazione vada a buon fine cosı da permettere una riconnessioneautomatica senza dover re-inserire nuovamente le credenziali d’accesso.

3.3.2 Gestione informazioni

La gestione delle informazioni e una delle funzionalita principali della dashboardpermesse all’utente autenticato sviluppata durante il periodo di stage.L’implementazione e stata eseguita creando le varie API CRUD lato server per lagestione delle informazioni presenti nel sistema, in particolare:

GET - /api/v1/info richiesta della lista completa delle informazioni eventualmen-te paginate;

GET - /api/v1/info/:id richiesta di una singola informazione specificando l’iden-tificativo univoco della stessa;

POST - /api/v1/info creazione di una nuova informazione;

PUT - /api/v1/info/:id modifica di un’informazione esistente specificando l’i-dentificativo univoco della stessa;

DELETE - /api/v1/info/:id creazione di una nuova informazione specificandol’identificativo univoco della stessa;

Il framework Express grazie alla sua componente chiamata Router permette diimplementare in modo chiaro e sicuro il gestore delle richieste API, lo spezzone dicodice successivo e relativo alla gestione delle API CRUD per le informazioni:

1 router.get('/info', passport.auth , datamanager.getInfos);

2 router.get('/info/:id', passport.auth , datamanager.getInfo);

3 router.post('/info', passport.auth , datamanager.createInfo);

4 router.put('/info/:id', passport.auth , datamanager.updateInfo);

5 router.delete('/info/:id', passport.auth , datamanager.deleteInfo

);

Grazie all’implementazione lato server di queste API la relativa implementazionelato web e stata immediata. La creazione di un servizio ad hoc in AngularJS hapermesso di eseguire le varie richieste http in modo semplice permettendomi di rea-lizzare un’interfaccia web per la creazione/modifica/cancellazione delle informazionipresenti nel sistema.


figura 3.13: Implementazione - Modifica informazioni

La figura 3.13 rappresenta la pagina relativa alla gestione delle informazioni dove sipuo inserire un titolo, una descrizione, eventuali files multimediali ed eventualmentealtri campi informativi personalizzati.Utilizzando la richiesta http GET /api/v1/info precedentemente descritta il clientweb puo richiedere la lista completa delle informazioni presenti nel sistema. La figura3.14 mostra l’interfaccia web che permette di visualizzare le informazioni in modopaginato.


figura 3.14: Implementazione - Visualizza informazioni

3.3.3 Gestione produzione

La seconda funzionalita tra le piu importanti nella realizzazione della dashboarde permettere all’utente autenticato di gestire la produzione delle etichette NFCcreando nuove commesse ed eventualmente suddividendole in task.

L’implementazione ha comportato la realizzazione di API apposite per le richiesteCRUD relative alle commesse ed ai vari task seguendo lo schema descritto nellasezione 3.3.2 per permettere la lettura/creazione/modifica/cancellazione delle stesse.

L’interfaccia web e stata dunque aggiornata di conseguenza per permettere da unlato di visualizzare tutte le commesse presenti e dall’altro l’inserimento di una nuovacommessa come si puo vedere in figura 3.16 dov’e possibile inserire il destinatariodella commessa, l’informazione ed il relativo proprietario oltre che alla quantita eduna scadenza.

L’interfaccia di creazione dei task permette di suddividere una commessa in sottolavori, cosı da distribuire il carico di lavoro a piu programmatori di etichette NFCspecificando il numero di pezzi da assegnare ad un singolo programmatore come sipuo vedere in figura 3.17.

3.3.4 WebSocket

Una componente degna di nota di tutto il progetto e senza dubbio la parte relativaalla connessione WebSocket. Oltre all’utilizzo di semplici richieste http per effettuareoperazioni CRUD classiche, l’utilizzo di una connessione WebSocket ha permessodi creare un canale di comunicazione continuo ed in tempo reale tra la parte servered i client web che utilizzano il sistema MadeUp oltre che ai vari programmatori di


figura 3.15: Implementazione - Visualizzazione commesse

figura 3.16: Implementazione - Creazione commessa

etichette NFC che utilizzano proprio una connessione WebSocket per comunicarecon la parte server.Si e quindi deciso un protocollo di comunicazione per definire la struttura deimessaggi WebSocket cosı composti:

id: identificativo del messaggio;

sender: mittente del messaggio;

receiver: destinatario del messaggio;


figura 3.17: Implementazione - Creazione task

method: identificativo del metodo richiesto;

args: eventuali argomenti relativi al metodo richiesto.

La parte server in particolare e stata implementata sia per gestire in modo direttola comunicazione con i propri client, sia per gestire la comunicazione tra client diversivestendo il semplice ruolo di intermediario.Nel primo caso ad esempio la parte server tramite la connessione WebSocket con ivari client connessi tramite la dashboard puo notificare eventi di sistema e statistichein tempo reale quali la connessione di nuovi programmatori, il completamento diuna commessa, la creazione di un nuovo tag NFC, etc...Nel secondo caso la parte server e un semplice intermediario tra due client ed unavolta ricevuto un messaggio WebSocket utilizzando il campo receiver puo reindirizza-re il messaggio al client specificato. Quest’ultima casistica e molto frequente quandoun client web tramite dashboard vuole gestire e quindi comunicare direttamente conun client programmatore di tag NFC.

Un esempio di messaggio WebSocket e il seguente:

1 {

2 id: a47bC3e9dId83edj ,

3 receiver: "programmer01",

4 sender: "[email protected]",

5 method: "startTaskRequest",

6 args: [

7 25,

8 "NFCTag"

9 ]

10 }


Lato server i messaggi sono gestiti in formato JSON ed inviati tramite WebSocketin formato stringa, quindi ad ogni invio/ricezione di un messaggio WebSocket ilserver si preoccupa di effettuare la trasformazione dell’oggetto JSON in stringa oviceversa il parsing della stringa per generare l’oggetto JSON corrispondente.

Una connessione continua di questo tipo ha permesso quindi di poter monitorarein tempo reale i vari programmatori di etichette NFC attualmente connessi alsistema direttamente dall’interfaccia web riuscendo cosı a visualizzare lo stato delprogrammatore ed eventualmente la quantita di tag NFC prodotti in tempo reale.La figura 3.18 mostra la pagina di visualizzazione dei vari programmatori.

figura 3.18: Implementazione - Visualizzazione programmatori

Sono stati dunque definiti dei metodi da richiamare tramite messaggi WebSocketcosı da permettere agli utenti web di gestire la produzione di etichette NFC comoda-mente dalla dashboard inviando comandi ai vari programmatori connessi e ricevendoi rispettivi messaggi di conferma/notifica.Nella tabella 3.1 sono elencati i vari metodi che sono stati definiti ed utilizzati perimplementare corrattamente tutte le funzionalita del sistema MadeUp, in base alloro utilizzo sono stati suddivisi in tre categorie:

• Richieste;

• Risposte;

• Notifica.

tabella 3.1: Tabella dei metodi WebSocket

Metodo Descrizione Categoria

startTaskRequest Richiesta di avvio di un determinato task Richieste

pauseTaskRequest Richiesta di interruzione temporanea deltask attualmente in esecuzione

Richieste

stopTaskRequest Richiesta di interruzione del task attual-mente in esecuzione

Richieste

Continua nella prossima pagina


tabella 3.1 – continua dalla pagina precedente

Metodo Descrizione Categoria

stopTaskRequest Richiesta di interruzione del task attual-mente in esecuzione

Richieste

loginRequest Richiesta autenticazione tramite websocket Richieste

logoutRequest Richiesta deautenticazione tramite websoc-ket

Richieste

saveTagRequest Richiesta salvataggio tag NFC Richieste

associateTagRequest Richiesta associazione tag NFC Richieste

tagInfoRequest Richiesta di informazioni associate ad undeterminato tag NFC

Richieste

loginResponse Risposta alla richiesta di autenticazione Risposte

startTaskResponse Risposta alla richiesta di avvio task Risposte

pauseTaskResponse Risposta alla richiesta di interruzionetemporanea del task in esecuzione

Risposte

stopTaskResponse Risposta alla richiesta di interruzione deltask in esecuzione

Risposte

tagInfoResponse Risposta alla richiesta di informazioniassociate ad un determinato tag NFC

Risposte

saveTagResponse Risposta alla richiesta di salvataggio di untag NFC

Risposte

associateTagResponse Risposta alla richiesta di associazione diun tag NFC

Risposte

deleteTagNotify Notifica di cancellazione di un tag NFC Notifiche

taskListNotify Notifica che fornisce la lista completa ditask disponibili

Notifiche

statsNotify Notifica che fornisce statistiche generalisull’avanzamento della produzione

Notifiche

newTagNotify Notifica di creazione di un nuovo tag NFC Notifiche

startTaskNotify Notifica di avvio task Notifiche

pauseTaskNotify Notifica di interruzione temporanea di untask

Notifiche

stopTaskNotify Notifica di interruzione di un task Notifiche

completeTaskNotify Notifica di completamento di un task Notifiche

completeOrderNotify Notifica di completamento di una commes-sa

Notifiche

userLoginNotify Notifica di autenticazione utente Notifiche

3.4 Verifica e validazione

L’attivita di validazione e giunta alla fine del processo di sviluppo. Sono state testatele componenti ritenute critiche, senza un corretto funzionamento delle quali nonsarebbe stato possibile usufruire dell’applicazione. In particolare le funzionalita diautenticazione e tutte quelle funzionalita riguardanti la gestione delle commesse in

3.4. VERIFICA E VALIDAZIONE 37

quanto essendo di fronte a piu dispositivi di scrittura connessi nello stesso tempo sipotevano creare problemi di concorrenza.

Di seguito descrivo la metodologia di testing adottata e gli strumenti a supportodella stessa.

3.4.1 Analisi del codice

Ho eseguito analisi del codice durante tutto il processo di sviluppo, in modo daintervenire tempestivamente su eventuali incongruenze. L’attivita e stata supportatada due strumenti in parallelo, uno per l’analisi statica del codice ed uno per l’analisidinamica.

3.4.1.1 Analisi statica

L’analisi statica e il processo di valutazione di un sistema o di un suo componentebasato sulla sua forma, struttura, contenuto, documentazione senza che esso siaeseguito.[3] Negli ultimi anni sono stati sviluppati vari sistemi di misurazione staticadel software, anche noti come metrica del codice, con l’intento di aiutare gli svilup-patori ad individuare le parti di codice che necessitano di ulteriore attenzione o ditest piu estesi. I principali strumenti cui mi sono affidato sono:

JSHint[7]: e un tool opensource che rileva errori e potenziali problemi del codiceJavaScript. Forza l’adesione alle best practice del linguaggio, favorendo laleggibilita del codice e la sua correttezza. Personalmente ho utilizzato JSHintattraverso un plugin del mio ambiente di sviluppo cosı da avere un’analisistatica del codice scritto in tempo reale.

SLOC[12]: e invece un tool, installabile tramite NPM, che permette di calcolaremetriche del codice sorgente. Le piu rilevanti riguardano il numero di righe dicodice e la percentuale di righe di commenti. L’utilizzo di questo tool e statofatto manualmente su richiesta del tutor aziendale.

Grazie all’utilizzo di strumenti di analisi statica come l’applicativo SLOC[12] allafine dell’attivita di stage mi e stato possibile calcolare metriche relative al codicesorgente sviluppato in modo semplice e preciso.In totale sono state prodotte 13616 righe di codice suddivise in 9598 righe di codicesorgente e 4018 righe di commenti e/o righe vuote.Riporto qui di seguito i risultati in dettaglio di tale analisi suddivisa tra parte serverin figura 3.19 e parte client in figura 3.20:

3.4.1.2 Analisi dinamica

L’analisi dinamica del codice e il processo di valutazione di un sistema software o diun suo componente basato sull’osservazione del suo comportamento in esecuzione. Eparte essenziale del processo di verifica e produce una misura della qualita del sistema.Tipicamente con il termine testing ci si riferisce all’analisi dinamica.[3] L’analisidinamica viene eseguita mediante test di unita sul codice prodotto. L’obiettivoprimario del test di unita consiste nell’isolare la parte piu piccola di software testabilenell’applicazione dal resto del codice per stabilire se funziona esattamente come


figura 3.19: SLOC - parte server

figura 3.20: SLOC - parte client

previsto.Come strumento di analisi dinamica durante la fase finale della mia attivita di stageho utilizzato Jasmine[12].Jasmine e un framework per la definizione dei test di unita, consigliato dalla comunitache mantiene AngularJS. Esso offre tutte le primitive per studiare il comportamentodi funzioni JavaScript e fare asserzioni sul loro output.

Capitolo 4

Conclusioni

In questo capitolo conclusivo presento una visione d’insieme dei requisiti coperti e delleconoscenze apprese a titolo professionale. Esprimo infine una valutazione sul divario trale competenze acquisite durante il corso di studi e quelle richieste per lo svolgimentodello stage.

4.1 Conseguimento degli obiettivi

Gli obiettivi stabiliti per lo svolgimento dello stage sono stati descritti in Sezione2.4.Rispetto a quanto fissato preventivamente posso ora analizzarne il grado di raggiun-gimento, dando una valutazione a posteriori sulle aspettative personali e dell’aziendaospitante.

4.1.1 Obiettivi di progetto

Come previsto nel piano di lavoro preventivo, lo stage ha portato il pannello diamministrazione web ad un soddisfacente stadio di avanzamento. Il prodotto ottenutoa fine stage risponde a tutte le funzionalita minime identificate con l’analisi deirequisiti, tutte completamente testate. Gli obiettivi prefissati inizialmente sonoquindi stati soddisfatti rispettando i tempi previsti. Grazie alla progettazione delsistema nella sua interezza e stato possibile avanzare riducendo al minimo le modificheda apportare al lato back-end cosı da dedicare maggior tempo allo sviluppo delpannello di amministrazione web. A ridosso del termine dello stage, il prodotto estato pubblicato online e presentato a piu brand partner, che utilizzandolo hannoconfermato la validita del lavoro svolto.

4.1.2 Soddisfacimento dei requisiti

L’attivita di analisi dei requisiti svolta durante lo stage ha portato alla stesura diun documento che elenca nel dettaglio le funzionalita attese del prodotto. In totalesono stati identificati:

• 28 requisiti obbligatori;

39

40 CAPITOLO 4. CONCLUSIONI

• 9 requisiti desiderabili.

Lo studio approfondito dei requisiti iniziali e l’agile risposta alle variazioni in corsod’opera ha permesso di produrre, sin dai primi prototipi, un’applicazione conforme aquanto atteso. Tale conformita e stata ribadita durante l’utilizzo della piattaformada parte delle aziende utilizzatrici a ridosso della fine dello stage.Dei 37 requisiti individuati ne sono stati soddisfatti 35, per un totale del 95%.I requisiti desiderabili non soddisfatti sono relativi alla compatibilita con il browserInternet Explorer ed i dispositivi mobili in quanto a causa delle tempistiche ridottee stata data priorita al completamento dei restanti requisiti.Ritengo il risultato positivo alla luce dei continui cambiamenti introdotti in rispostaal mercato. Oltre che all’integrazione di nuovi requisiti infatti, si sono spesso applicaticambi di priorita nei requisiti esistenti, che quindi nel tempo sono diventati piu omeno importanti nell’idea di prodotto. La risposta a queste variazioni e stata velocesoprattutto grazie alla qualita della progettazione di alto livello.

4.2 Bilancio formativo

Dal punto di vista formativo l’attivita di stage in MadeUp e stata molto positiva.Durante questo periodo ho potuto consolidare alcune competenze tecniche ed entrarein contatto con tecnologie che non conoscevo. In particolare:

• Ho approfondito lo studio del framework AngularJS per lo sviluppo di sin-glepage application. Con la dashboard per il sistema MadeUp mi sono fattocarico di un progetto di medio-grande dimensione, che quindi richiede logichedi gestione e competenze diverse rispetto ai progetti che avevo intrapreso;

• Ho migliorato la mia personale conoscenza di NodeJS per lo sviluppo diapplicazioni back-end;

• Ho consolidato le mie conoscenze dei database non relazionali, nella fattispecieMongoDB, usato da MadeUp per la pesistenza dei dati;

• Ho avuto modo di provare con mano una nuova tecnologia a me sconosciutaquale le connessioni WebSocket scoprendo i grandi pregi se usate in determinateapplicazioni;

• Ho approfondito la mia conoscenza di REST come protocollo e architettura dicomunicazione.

Dal punto di vista metodologico invece sono entrato per la prima volta a far partedi un team di lavoro vero e proprio che mi ha permesso di toccare con mano unavera realta aziendale.Durante lo stage ho avuto inoltre la possibilita di applicare molte delle conoscenzeacquisite nella formazione universitaria e privata. I progetti universitari affrontati el’interesse personale per lo sviluppo di applicazioni software mi hanno permesso diconoscere tecniche di sviluppo, di progettazione e molti strumenti a supporto dellaprogrammazione.Tali conoscenze si sono dimostrate spendibili, apprezzate ed ascoltate in ambito

4.3. VALUTAZIONE DELLE CONOSCENZE ACQUISITE 41

aziendale. Questo ha fatto in modo che il trasferimento di nuove conoscenze avvenissenella direzione azienda-studente e studente-azienda.

4.3 Valutazione delle conoscenze acquisite

La preparazione offerta dal corso di studi non puo che essere teorica e ad ampiospettro, coprendo quanto piu possibile i numerosissimi aspetti dell’informatica eprovando a dare una valida educazione alla sperimentazione. Il valore che credodi aver acquisito dall’universita e la propensione allo studio delle tecnologie e dellesoluzioni inerenti ai progetti che intraprendo. Con questa premessa, il corso di studiassume valore in proporzione alla continuita che lo studente riesce a dare alle nozioniacquisite, sperimentando e prendendo parte a progetti extra universitari. Io hosempre avuto una forte spinta a mettere in pratica quanto studiato e grazie a questoho potuto avviare uno stage che aveva dei prerequisiti importanti, certamente noncoperti dal programma universitario.Molte delle conoscenze e best practice che ho utilizzato per lo svolgimento dellostage le ho imparate in modo indipendente, esplorando e realizzando dei progettiper approfondire il sapere acquisito. I corsi universitari, specie quelli di Informatica,mi sono serviti come prima importante infarinatura per costruire le basi del miobagaglio formativo.Ho trovato infine molto validi, per quanto concerne l’universita, i corsi che prevedonolavoro in team. Avere infatti esperienza di lavoro con altre persone, e degli strumentie delle tecnologie sufficienti a gestire un progetto, e un valore molto importanteche viene subito riconosciuto nel mondo del lavoro. In MadeUp mi sono trovatospesso a collaborare anche su temi non direttamente legati al mio progetto distage, per far fronte a problematiche che il team di sviluppo ha incontrato in miapresenza, problematiche che avevo gia affrontato proprio lavorando in team suprogetti universitari. Il livello di soddisfazione dell’azienda e stato alto rispettoall’esperienza svolta. A stage concluso l’azienda mi ha proposto una collaborazioneper la continuazione del progetto e l’integrazione di nuove funzionalita.

Appendice A

MEAN stack

Lo stack MEAN e un’insieme di software gratuiti ed open-source per la creazione disiti web dinamici ed applicazioni web. E’ una combinazione di MongoDB, Express.js,AngularJS e Node.js

A.1 MongoDB

MongoDB (da humongous, enorme) e un database non relazionale, orientato aidocumenti. Classificato come un database di tipo NoSQL, MongoDB si allontanadalla struttura tradizionale basata su tabelle dei database relazionali in favoredi documenti in stile JSON g con schema dinamico (MongoDB chiama il formatoBSON g ), rendendo l’integrazione di dati di alcuni tipi di applicazioni piu facile eveloce. MongoDB e un software libero e open-source, scritto in linguaggio C++.

figura A.1: MongoDB - Logo

[11]Per cominciare, ci sono sei semplici concetti da comprendere.

• MongoDB implementa lo stesso concetto di database al quale siamo abituati (oschema, se venite dal mondo Oracle). All’interno di una istanza MongoDB sipossono avere zero o piu database, ognuno dei quali agisce come un contenitoredi alto livello per tutto il resto;

• Un database puo avere zero o piu collezioni. Una collezione ha molto in comunecon le tabelle tradizionali, tanto possono essere considerate la stessa cosa;

• Le collezioni sono composte da zero o piu documenti. Di nuovo, si puo pensarea un documento come a una riga (record) di una tabella;

• Un documento e a sua volta composto da uno o piu campi, che assomiglianoalle colonne;

43

44 APPENDICE A. MEAN STACK

• Gli indici in MongoDB funzionano in modo molto simile alle loro contropartiRDBMS;

• I cursori, a cui spesso viene data poca importanza, sono qualcosa di diversodagli altri cinque concetti. E importante sapere che quando si richiedono dati aMongoDB questi restituisce un cursore col quale possiamo, per esempio, contarei documenti o spostarci avanti, senza che alcun dato venga effettivamente letto.

Riassumendo, MongoDB e fatto di database che contengono collezioni. Unacollezione e una raccolta di documenti. Ogni documento e composto da campi.Le collezioni possono essere indicizzate, il che migliora le prestazioni di ricerche eordinamenti. Infine, quando richiediamo dati a MongoDB otteniamo un cursore, lacui esecuzione e rinviata finche non si rendera necessaria.

A.2 Express

Express e un framework minimale e flessibile per la creazione di applicazioni webbasate su Node.js. Esso contiene una varieta di funzioni sia per la creazione diapplicazioni a singola pagina che multi-pagina oltre che applicazioni ibride.

figura A.2: Logo di Express

A.3 AngularJS

AngularJS e un framework g Javascript open-source g , mantenuto da Google, chepermette di creare siti web dinamici, front-end di web-service g , eseguibili comeSingle Page Application (SPA) g .

figura A.3: AngularJS - Logo

[2] Le principali componenti che caratterizzano il framework sono:

Moduli: rappresentano dei contenitori di alto livello di parti dell’applicazione.Hanno lo scopo di modularizzare il codice, rendendo queste parti riusabili;

Direttive: sono degli speciali attributi che permettono di estendere i tag HTML5definendone di nuovi, indipendenti dal resto dell’applicazione e riutilizzabili inaltri progetti in maniera dichiarativa;

A.4. NODE.JS 45

Servizi: permettono di incapsulare le classi comuni alle altre componenti, di testarlee riutilizzarle separatamente;

Filtri: permettono di filtrare gli oggetti del model in base a caratteristiche definitedal programmatore.

Le caratteristiche che hanno portato alla rapida diffusione di questa tecnologiasono:

Two-way data binding: un meccanismo che permette di tenere in sincronia modele view senza particolari sforzi di programmazione, in modo tale che ognicambiamento nel model venga automaticamente riflesso nella componente viewe viceversa;

figura A.4: Two way data binding

Dependency injection: permette di gestire le dipendenze tra i vari moduli inmodo molto efficiente. In particolare la definizione di un modulo prevede ladichiarazione delle componenti necessarie affinche il modulo possa essere creato.In figura A.5 e illustrato un controller che dichiara la proprie dipendenzeall’injector di AngularJS, sara quest’ultimo a fornirgli le istanze dei servizi cheaveva richiesto non appena ne avra bisogno.

figura A.5: AngularJS injector

A.4 Node.js

Node.js e un framework event-driven g per il motore JavaScript V8, su piattaformeUNIX like. Si tratta quindi di un framework relativo all’utilizzo server-side diJavascript.

46 APPENDICE A. MEAN STACK

figura A.6: Node.js - Logo

La sua caratteristica principale e l’efficienza. Il modello di networking su cui sibasa Node.js infatti non e quello dei processi concorrenti, ma I/O event-driven: ciovuol dire che Node.js richiede al sistema operativo di ricevere notifiche al verificarsidi determinati eventi, e rimane quindi in sleep fino alla notifica stessa: solo in talemomento torna attivo per eseguire le istruzioni previste in conseguenza del callback g .Tale modello di networking e ritenuto piu efficiente nelle situazioni critiche in cui siverifica un elevato traffico di rete.[9]

Linguaggi di programmazione definiti bloccanti (Java, Ruby, Python, PHP, ...)diventano concorrenti eseguendo piu threads mentre Node.js con JavaScript gestiscela concorrenza usando un gestore di eventi in un singolo thread com’e possibileosservare nelle figure successive:

figura A.7: Java multi-threaded server

A.4. NODE.JS 47

figura A.8: Node.js server

Appendice B

Requisiti

Per poter creare ordine nel processo di analisi dei requisiti risulta necessario imporreuna strutturazione ben definita e precisa sull’analisi effettuata, in particolar modosui casi d’uso e sui requisiti definiti. Ogni requisito individuato e stato classificatoin base alla fonte che ha permesso di individuarlo.Le fonti in cui sono stati suddivisi i requisiti sono:

Piano di lavoro: se il requisito e stato espresso all’interno del piano di lavoro stesoprima dell’inizio dello stage, sia come obbiettivo minimo che come obbiettivomassimo;

Interna: se il requisito e emerso durante le riunioni periodiche effettuate all’internodell’azienda o individuato su iniziativa dello stagiaire.

Al fine di raggruppare i requisiti in insiemi coesi e coerenti ho definito una segnaturaunivoca e gerarchica secondo il seguente formalismo:

[Tipologia di requisito][Priorita][Identificativo]

dove:

Tipologia di requisito: discrimina il tipo del requisito

F requisito funzionale;

V requisito di vincolo;

Q requisito di qualita;

P requisito prestazionale.

Priorita: fissa la priorita del requisito

O requisito obbligatorio, la cui implementazione e da ritenersi fondamentaleai fini del minimo soddisfacimento del progetto proposto;

D requisito desiderabile la cui implementazione non e da ritenersi fondamentalema se implementato darebbe valore aggiunto al sistema;

Z requisito opzionale la cui implementazione sara effettuata solo se le risorsea disposizione saranno sufficienti.

49

50 APPENDICE B. REQUISITI

Identificativo: rappresenta il valore numerico gerarchico del requisito.

Nelle tabelle B.1 e B.2 sono riassunti rispettivamente i requisiti funzionali e di vincolodelineati in fase di analisi.

tabella B.1: Tabella dei requisti funzionali

Requisito Descrizione Fonte

FO1 Il sistema permette all’utente di autenti-carsi

Piano di lavoro

FO1.1 Il sistema richiede l’username dell’utente Piano di lavoro

FO1.2 Il sistema richiede la password all’utente Piano di lavoro

FD1.3 Il sistema richiede all’utente se attivareuna sessione prolungata

Interna

FD1.4 Il sistema deve comunicare all’utente l’e-ventuale errore durante la procedura diautenticazione

Interna

FO2 Il sistema permette all’utente di disconnet-tersi e terminare la sessione

Piano di lavoro

FO3 Il sistema permette all’utente di visualiz-zare le informazioni presenti

Piano di lavoro

FO3.1 Il sistema permette all’utente di visualiz-zare in dettaglio una singola informazione

Piano di lavoro

FO4 Il sistema permette all’utente di gestire leinformazioni presenti

Piano di lavoro

FO4.1 Il sistema permette all’utente di creare unanuova informazione

Piano di lavoro

FO4.1.1 Il sistema permette all’utente di inserire iltitolo dell’informazione

Interna

FO4.1.2 Il sistema permette all’utente di inserire ladescrizione dell’informazione

Interna

FO4.1.3 Il sistema permette all’utente di inseriredei files multimediali per l’informazione

Interna

FD4.1.4 Il sistema conferma l’avvenuta creazionedell’informazione

Interna

FO4.2 Il sistema permette all’utente di eliminareun’informazione esistente

Piano di lavoro

FO5 Il sistema permette all’utente di gestire lecommesse presenti

Piano di lavoro

FO5.1 Il sistema permette all’utente di creare unanuova commessa

Piano di lavoro

FD5.1.1 Il sistema permette all’utente inserire uncodice commessa

Interna

FO5.1.2 Il sistema permette all’utente di selezionareun’informazione presente

Piano di lavoro


51

tabella B.1 – continua dalla pagina precedente


FO5.1.3 Il sistema permette all’utente di inserire laquantita da produrre

Piano di lavoro

FD5.1.4 Il sistema permette all’utente di inserirela quantita di tasks con cui suddividere lacommessa

Interna

FD5.1.5 Il sistema conferma l’avvenuta creazionedella commessa ed eventuali tasks

Interna

FO5.2 Il sistema permette all’utente di eliminareuna commessa esistente

Piano di lavoro

FO6 Il sistema permette all’utente di gestire idispositivi di scrittura

Piano di lavoro

FO6.1 Il sistema permette all’utente di visua-lizzare la lista di dispositivi attualmenteonline

Piano di lavoro

FO6.2 Il sistema permette all’utente di visualiz-zare lo stato dei dispositivi di scrittura(libero/occupato)

Piano di lavoro

FO6.3 Il sistema permette all’utente di visualiz-zare la commessa a cui sta lavorando undispositivo di scrittura in stato occupato

Interna

FD6.4 Il sistema permette all’utente di visualiz-zare il numero di commesse completate daun singolo dispositivo di scrittura

Interna

tabella B.2: Tabella dei requisiti di vincolo


VO1Sara utilizzato Node.js per la realizzazionedella parte backend

Piano di lavoro

VO2Sara utilizzato AngularJS per la realizza-zione della parte frontend

Piano di lavoro

VO3I dati saranno salvati in un database di tipodocumentale. Sara utilizzato MongoDB

Piano di lavoro

VO4L’applicativo dovra essere compatibile imoderni browser desktop

Piano di lavoro

VO4.1L’applicativo dovra essere compatibile conil browser Chrome (versione 42.x)

Interna

VO4.2L’applicativo dovra essere compatibile conil browser Firefox (versione 38.x)

Interna

VO4.3L’applicativo dovra essere compatibile conil browser Safari (versione 5)

Interna


52 APPENDICE B. REQUISITI

tabella B.2 – continua dalla pagina precedente


VD4.4L’applicativo dovra essere compatibile conil browser Internet Explorer (versione 9)

Interna

VD5L’applicativo dovra essere compatibile coni dispositivi mobili

Interna

Appendice C

Architettura

C.1 Architettura generale

Di seguito sono presenti i diagrammi dell’architettura generale vista packages infigura C.1 e dell’architettura generale vista classi per la parte client in figura C.2 eper la parte server in figura C.3.

figura C.1: Architettura generale del prodotto MadeUp - vista packages

53

54 APPENDICE C. ARCHITETTURA

figura C.2: Architettura client - vista classi

C.2. ARCHITETTURA IN DETTAGLIO 55

figura C.3: Architettura server - vista classi

C.2 Architettura in dettaglio

C.2.1 Client::views

Componente che contiene i template per la visualizzazione delle pagine web.

C.2.1.1 Client::views::dashboard

Descrizione: Classe che rappresenta il template per la pagina principale delladashboard;

Utilizzo: Viene utilizzata per renderizzare la pagina web principale;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto dashboardCtrlper gestire la creazione della pagina dashboard-home.

C.2.1.2 Client::views::404

Descrizione: Classe che rappresenta il template per la pagina d’errore;

Utilizzo: Viene utilizzata per renderizzare la pagina web d’errore 404;

Relazioni: -.


figura C.4: Architettura client - componente views

C.2.1.3 Client::views::login

Descrizione: Classe che rappresenta il template per la pagina di login;

Utilizzo: Viene utilizzata per renderizzare la pagina web di login utente;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto loginCtrl pergestire le operazioni di login e registrazione utente.

C.2.1.4 Client::views::menu up

Descrizione: Classe che rappresenta il template per la barra di navigazione supe-riore;

Utilizzo: Viene utilizzata per renderizzare la barra di navigazione superiore;


Relazioni: Relazione uscente, contiene un riferimento ad un oggetto navCtrl pergestire la navigazione tra le pagine web.

C.2.1.5 Client::views::menu sx

Descrizione: Classe che rappresenta il template per la barra di navigazione laterale;

Utilizzo: Viene utilizzata per renderizzare la barra di navigazione laterale a scom-parsa;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto navCtrl pergestire la navigazione tra le pagine web.

C.2.1.6 Client::views::products

Descrizione: Classe che rappresenta il template per la pagina di gestione deiprodotti;

Utilizzo: Viene utilizzata per renderizzare la pagina di visualizzazione dei prodotti;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto productsCtrlper gestire la visualizzazione/modifica di un prodotto.

C.2.1.7 Client::views::taskEdit

Descrizione: Classe che rappresenta il template per la pagina di modifica di unsingolo task;

Utilizzo: Viene utilizzata per renderizzare la pagina di modifica di un task;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto taskEditCtrlper gestire la modifica/cancellazione di un task.

C.2.1.8 Client::views::tasks

Descrizione: Classe che rappresenta il template per la pagina di visualizzazione diun singolo task;

Utilizzo: Viene utilizzata per renderizzare la pagina di visualizzazione di un task;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto taskCtrl perrecuperare i dati di un task e visualizzarli.

C.2.1.9 Client::views::orderEdit

Descrizione: Classe che rappresenta il template per la pagina di modifica di unasingola commessa;

Utilizzo: Viene utilizzata per renderizzare la pagina di modifica di una commessa;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto orderEditCtrlper gestire la modifica/cancellazione di una commessa.


C.2.1.10 Client::views::orders

Descrizione: Classe che rappresenta il template per la pagina di visualizzazione diuna singolo commessa;

Utilizzo: Viene utilizzata per renderizzare la pagina di visualizzazione di unacommessa;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto orderCtrl perrecuperare i dati di una commessa e visualizzarli.

C.2.1.11 Client::views::users

Descrizione: Classe che rappresenta il template per la pagina di visualizzazionedegli utenti;

Utilizzo: Viene utilizzata per renderizzare la pagina di visualizzazione della lista diutenti registrati nel sistema;

Relazioni: Relazione uscente, contiene un riferimento ad un oggetto usersCtrl perrecuperare i dati degli utenti.

C.2.2 Client::controllers

Componente contenente i vari controller lato client.

C.2.2.1 Client::controllers::dashboardCtrl

Descrizione: Classe che rappresenta il controller generico per comunicare con ilserver;

Utilizzo: Viene utilizzata per inviare richieste generiche al server quali statistichesulla produzione da visualizzare in prima pagina.

Relazioni: Relazione entrante: interazione con il template dashboard. Relazioneuscente debole: contiene un riferimento ad un oggetto statsService per utilizzareil relativo servizio.

C.2.2.2 Client::controllers::socketCtrl

Descrizione: Classe che rappresenta il controller per la gestione della connessionewebsocket;

Utilizzo: Viene utilizzata per gestire la connessione websocket lato client.

Relazioni: Relazione entrante: interazione con il template dashboard. Relazio-ne uscente debole: contiene un riferimento ad un oggetto socketService perutilizzare il relativo servizio.


figura C.5: Architettura client - componente controllers

C.2.2.3 Client::controllers::loginCtrl

Descrizione: Classe che rappresenta il controller per la gestione del login;

Utilizzo: Viene utilizzata per gestire registrazione e login dell’utente.

Relazioni: Relazione entrante: interazione con il template login. Relazione uscentedebole: contiene un riferimento ad un oggetto authService per utilizzare ilrelativo servizio.

C.2.2.4 Client::controllers::navCtrl

Descrizione: Classe che rappresenta il controller per la gestione dei menu delladashboard;


Utilizzo: Viene utilizzata per gestire la visualizzazione dei menu della dashboard ela navigazione tra le pagine oltre che all’operazione di logout utente.

Relazioni: Relazione entrante: interazione con i template menu up e menu sx.Relazione uscente debole: contiene un riferimento ad un oggetto authServiceper utilizzare il relativo servizio.

C.2.2.5 Client::controllers::productsCtrl

Descrizione: Classe che rappresenta il controller per la gestione dei prodotti;

Utilizzo: Viene utilizzata per gestire i prodotti inseriti nel sistema.

Relazioni: Relazione entrante: interazione con il template products. Relazioneuscente debole: contiene un riferimento ad un oggetto productsService perutilizzare il relativo servizio.

C.2.2.6 Client::controllers::taskEditCtrl

Descrizione: Classe che rappresenta il controller per la modifica dei task;

Utilizzo: Viene utilizzata per modificare un task esistente o crearne uno nuovo.

Relazioni: Relazione entrante: interazione con il template taskEdit. Relazioneuscente debole: contiene un riferimento ad un oggetto tasksService per utilizzareil relativo servizio.

C.2.2.7 Client::controllers::taskCtrl

Descrizione: Classe che rappresenta il controller per la visualizzazione dei task;

Utilizzo: Viene utilizzata per visualizzare la lista dei task o un singolo task indettaglio.

Relazioni: Relazione entrante: interazione con il template tasks. Relazione uscentedebole: contiene un riferimento ad un oggetto tasksService per utilizzare ilrelativo servizio.

C.2.2.8 Client::controllers::orderEditCtrl

Descrizione: Classe che rappresenta il controller per la modifica delle commesse;

Utilizzo: Viene utilizzata per modificare una commessa esistente o crearne unanuova.

Relazioni: Relazione entrante: interazione con il template orderEdit. Relazio-ne uscente debole: contiene un riferimento ad un oggetto ordersService perutilizzare il relativo servizio.


C.2.2.9 Client::controllers::orderCtrl

Descrizione: Classe che rappresenta il controller per la visualizzazione delle com-messe;

Utilizzo: Viene utilizzata per visualizzare la lista delle commesse o una singolocommessa in dettaglio.

Relazioni: Relazione entrante: interazione con il template orders. Relazione uscentedebole: contiene un riferimento ad un oggetto ordersService per utilizzare ilrelativo servizio.

C.2.2.10 Client::controllers::usersCtrl

Descrizione: Classe che rappresenta il controller per la visualizzazione degli utenti;

Utilizzo: Viene utilizzata per visualizzare la lista degli utenti o un singolo utentein dettaglio.

Relazioni: Relazione entrante: interazione con il template users. Relazione uscentedebole: contiene un riferimento ad un oggetto usersService per utilizzare ilrelativo servizio.

C.2.3 Client::services

Componente contenente i servizi per la comunicazione con il server.

C.2.3.1 Client::services::statsService

Descrizione: Classe che rappresenta il servizio per il recupero delle statistiche;

Utilizzo: Viene utilizzata per recuperare le statistiche di produzione.

Relazioni: Relazione entrante debole: interazione con il controller dashboardCtrl.

C.2.3.2 Client::services::socketService

Descrizione: Classe che rappresenta il servizio per la comunicazione con il servermediante websocket;

Utilizzo: Viene utilizzata per comunicare in tempo reale con il server mantenendouna connessione attiva in grado di inviare e ricevere dati in tempo reale.

Relazioni: Relazione entrante debole: interazione con il controller socketCtrl.

C.2.3.3 Client::services::authService

Descrizione: Classe che rappresenta il servizio la gestione della registrazione ed illogin utente;

Utilizzo: Viene utilizzata per registrare un nuovo utente, validare i dati di login diun utente o effettuare la disconnessione.


figura C.6: Architettura client - componente services

Relazioni: Relazione entrante debole: interazione con i controller loginCtrl enavCtrl.

C.2.3.4 Client::services::productsService

Descrizione: Classe che rappresenta il servizio per la gestione dei prodotti;

Utilizzo: Viene utilizzata per creare, modificare o eliminare un prodotto dal sistema.

Relazioni: Relazione entrante debole: interazione con il controller productsCtrl.

C.2.3.5 Client::services::tasksService

Descrizione: Classe che rappresenta il servizio per la gestione dei task;


Utilizzo: Viene utilizzata per creare, modificare o eliminare un task dal sistema.

Relazioni: Relazione entrante debole: interazione con i controller taskEditCtrl etaskCtrl.

C.2.3.6 Client::services::ordersService

Descrizione: Classe che rappresenta il servizio per la gestione delle commesse;

Utilizzo: Viene utilizzata per creare, modificare o eliminare una commessa dalsistema.

Relazioni: Relazione entrante debole: interazione con i controller orderEditCtrl eorderCtrl.

C.2.3.7 Client::services::usersService

Descrizione: Classe che rappresenta il servizio per la gestione degli utenti;

Utilizzo: Viene utilizzata per creare, modificare o eliminare un utente dal sistema.

Relazioni: Relazione entrante debole: interazione con il controller usersCtrl.

C.2.4 Client::filters

figura C.7: Architettura client - componente filters

Componente contenente i filtri propri di AngularJS.

C.2.4.1 Client::filters::URIfilters

Descrizione: Classe che rappresenta il filtro per la gestione delle URI;

Utilizzo: Viene utilizzata per codificare e decodificare una stringa URI.

Relazioni: -.

C.2.5 Client::directives

Componente contenente le direttive proprie di AngularJS.


figura C.8: Architettura client - componente directives

C.2.5.1 Client::directives::usersRolesDirective

Descrizione: Classe che rappresenta la direttiva per la gestione del ruolo utente;

Utilizzo: Viene utilizzata gestire la visualizzazione di determinati contenuti ai soliutenti con un determinato ruolo.

Relazioni: -.

C.2.6 Server::controller

figura C.9: Architettura server - componente controller

Componente contenente i controller nella parte server.

C.2.6.1 Server::controller::dispatcher

Descrizione: Classe che rappresenta il componente facade del relativo designpattern;


Utilizzo: Viene utilizzata per smistare le richieste del client ai vari gestori dei dati;

Relazioni: Relazione uscente: contiene riferimenti ad oggetti dataManager e pas-sport per richiedere azioni relative ai dati di analisi.

C.2.6.2 Server::controller::dataManager

Descrizione: Classe che rappresenta il gestore principali dei dati lato server;

Utilizzo: Viene utilizzata eseguire la maggior parte delle operazioni CRUD latoserver.

Relazioni: Relazione entrante: interazione con la componente dispatcher. Relazioneuscente: contiene un riferimento ad un oggetto db per eseguire query suldatabase.

C.2.6.3 Server::controller::passport

Descrizione: Classe che rappresenta il gestore di autenticazione utente lato server;

Utilizzo: Viene utilizzata validare i dati di sessione di un utente o i dati di logindurante la fase di autenticazione.

Relazioni: Relazione entrante: interazione con la componente dispatcher. Relazioneuscente: contiene un riferimento ad un oggetto db per eseguire query suldatabase.

C.2.6.4 Server::controller::ws

Descrizione: Classe che rappresenta il gestore della connessione websocket.

Utilizzo: Viene utilizzata per gestire in tempo reale la connessione ai vari client edinviare messaggi di notifica ai singoli client oppure in modalita broadcast.

Relazioni: Relazione uscente: contiene un riferimento ad un oggetto db per eseguirequery sul database.

C.2.7 Server::model

Componente contenente la parte di gestione dei dati permanenti nella parte server.

C.2.7.1 Server::model::db

Descrizione: Classe che rappresenta la connessione al database Mongo;

Utilizzo: Viene utilizzata per connettersi in modo remoto al database Mongo edinteragire con esso.

Relazioni: Relazione entrante: interazione con le componenti ws, dataManager epassport. Relazione uscente: utilizza un riferimento ad oggetti di tipo schemasper creare lo schema dei dati del database e per interagire con essi; Relazioneuscente: utilizza un riferimento ad oggetti di tipo parse per interagire con ildatabase Parse;


figura C.10: Architettura server - componente model

C.2.7.2 Server::model::parse

Descrizione: Classe che rappresenta la connessione al sistema Parse (2.3.5.2);

Utilizzo: Viene utilizzata per connettersi in modo remoto al sistema Parse (2.3.5.2)ed interagire con esso.

Relazioni: Relazione entrante: interazione con la componente db.

C.2.8 Server::schemas

Componente contenente gli schemi MongoDB.

C.2.8.1 Server::model::schemas::user

Descrizione: Classe che rappresenta lo schema dei dati della collection user;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscegli utenti.



figura C.11: Architettura server - componente schemas

C.2.8.2 Server::model::schemas::group

Descrizione: Classe che rappresenta lo schema dei dati della collection group;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscei gruppi di utenti.


C.2.8.3 Server::model::schemas::task

Descrizione: Classe che rappresenta lo schema dei dati della collection task;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscei task, sotto-strutture delle commesse.


C.2.8.4 Server::model::schemas::session

Descrizione: Classe che rappresenta lo schema dei dati della collection session;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscele sessioni utente.



C.2.8.5 Server::model::schemas::order

Descrizione: Classe che rappresenta lo schema dei dati della collection order;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscele commesse.


C.2.8.6 Server::model::schemas::NFCTag

Descrizione: Classe che rappresenta lo schema dei dati della collection NFCTag;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscele etichette NFC.


C.2.8.7 Server::model::schemas::products

Descrizione: Classe che rappresenta lo schema dei dati della collection products;

Utilizzo: Viene utilizzata modellare la struttura dei dati della collection che gestiscele informazioni presenti nel sistema.


Glossario

BSON Formato informatico di scambio dati utilizzato principalmente come magaz-zino dati e formato di trasferimento di rete nel database MongoDB. Si tratta diun formato binario per rappresentare strutture dati semplici e array associativi(chiamati oggetti o documenti in MongoDB).. 29

Callback In programmazione, un callback (o, in italiano, richiamo) e, in genere, unafunzione, o un ”blocco di codice” che viene passata come parametro ad un’altrafunzione. In particolare, quando ci si riferisce alla callback richiamata da unafunzione, la callback viene passata come parametro alla funzione chiamante.In questo modo la chiamante puo realizzare un compito specifico (quello svoltodalla callback) che non e, molto spesso, noto al momento della scrittura delcodice.. 22

Event-driven Event-driven (in italiano ”programmazione a eventi”) e un paradigmadi programmazione dell’informatica. Mentre in un programma tradizionalel’esecuzione delle istruzioni segue percorsi fissi, che si ramificano soltanto inpunti ben determinati predefiniti dal programmatore, nei programmi scrittiutilizzando la tecnica a eventi il flusso del programma e largamente determinatodal verificarsi di eventi esterni.. 21

Framework Nello sviluppo software, un framework e un’architettura logica disupporto (spesso un’implementazione logica di un particolare design pattern)su cui un software puo essere progettato e realizzato, spesso facilitandone losviluppo da parte del programmatore.. 2, 20

JSON JavaScript Object Notation (JSON), e un formato adatto per lo scambiodei dati in applicazioni client-server. E basato sul linguaggio JavaScript, mane e indipendente. Viene spesso usato nell’ambito della programmazione webper trasferire dati, in alternativa a XML. 29

NFC (in italiano letteralmente ”Comunicazione in prossimita”) e una tecnologiache fornisce connettivita wireless (RF) bidirezionale a corto raggio (fino a unmassimo di 10 cm) . 29

Open-source Software i cui autori permettono e favoriscono il libero studio el’apporto di modifiche da parte di altri programmatori indipendenti. Questo erealizzato mediante l’applicazione di apposite licenze d’uso.. 20

69

70 Glossario

SAAS Software as a service (SaaS) e un modello di distribuzione del softwareapplicativo dove un produttore di software sviluppa, opera (direttamente otramite terze parti) e gestisce un’applicazione web che mette a disposizionedei propri clienti via internet.. 29

SPA Applicazione che risiede completamente in una singola pagina, ma che tut-tavia da la possibilita di navigare fra le proprie viste come si farebbe conun’applicazione web tradizionale. 29

Web-service Sistema software progettato per supportare l’interoperabilita tradiversi elaboratori su di una medesima rete, ovvero in un contesto distribuito.2, 20

Acronimi e abbreviazioni

BSON Binary JSON. 19

JSON JavaScript Object Notation. 19

NFC Near Field Communication. 1

SAAS Software As A Service. 1

SPA Single Page Application. 20

UML Unified Modeling Language. 15

71

Bibliografia

Riferimenti bibliografici

[2] Pawel Kozlowski e Peter Bacon Darwin. Mastering Web Application Develop-ment with AngularJS. Packt Publishing, 2013.

[3] Anna Rita Fasolino. Verifica e Convalida del Software. Richiami e concetti dibase sul software testing. 2010.

[4] Martin Fowler. Inversion Of Control. 2005.

[11] Karl Seguin. The little MongoDB book. 2011.

Siti Web consultati

[1] Bower. url: http://bower.io.

[5] Ingegneria del Software mod. A. url: http://www.math.unipd.it/~tullio/IS-1/2013/.

[6] Jasmine. url: http://jasmine.github.io/2.0/introduction.html.

[7] JSHint. url: http://jshint.com.

[8] MaaP - MongoDB as an Admin Platform. url: https://www.npmjs.com/package/maaperture.

[9] Node.js - Wikipedia. url: http://it.wikipedia.org/wiki/Node.js.

[10] NPM. url: https://www.npmjs.org.

[12] SLOC. url: https://www.npmjs.org/package/sloc.

[13] TeamWork - Projects. url: https://www.teamwork.com/projects.

[14] Zebra TC55. url: https://www.zebra.com/us/en/products/mobile-

computers/handheld/tc55.html.

73

http://bower.io

http://www.math.unipd.it/~tullio/IS-1/2013/

http://www.math.unipd.it/~tullio/IS-1/2013/

http://jasmine.github.io/2.0/introduction.html

http://jshint.com

https://www.npmjs.com/package/maaperture

https://www.npmjs.com/package/maaperture

http://it.wikipedia.org/wiki/Node.js

https://www.npmjs.org

https://www.npmjs.org/package/sloc

https://www.teamwork.com/projects

https://www.zebra.com/us/en/products/mobile-computers/handheld/tc55.html

https://www.zebra.com/us/en/products/mobile-computers/handheld/tc55.html

Sviluppo dashboard per la gestione della programmazione di etichette NFC

Documents

Transcript of Sviluppo dashboard per la gestione della programmazione di etichette NFC