l u c a s o t ta n i
Sistema per il tracciamento, la gestione e la pianificazione d’uso di risorse reali e virtuali in ambito aziendale
Febbraio 2013
tracciamento, la gestione e la pianificazione d’uso di risorse reali e virtuali in ambito aziendale, Febbraio 2013
i i n t r o d u z i o n e 1
1 a m b i e n t e d’utilizzo 3 1.1 L’azienda 3
1.2 Bisogni aziendali 4 1.3 Ragioni di necessità 4 2 i l p r o g e t t o 7
2.1 Obiettivi dello stage 7 2.2 Strumenti a disposizione 7
2.2.1 Apache HTTP Server 7 2.2.2 MySQL 8
2.2.3 Eclipse Indigo 9
2.2.4 Android Honeycomb 9 2.2.5 Notepad++ 10
2.2.6 CakePHP 11
2.2.7 MySQL Workbench 12
2.2.8 SQLyog community edition 13 2.2.9 Git 14
2.2.10 Altri strumenti 14 2.3 Risultati ottenuti 18 ii s v i l u p p o 21
3 a na l i s i d e i r e q u i s i t i 23 3.1 Contesto d’uso 23 3.2 Requisiti funzionali 23
3.2.1 Elenco dei requisiti 24 3.3 Casi d’uso 28
3.3.1 UC1 - Homepage 28
3.3.2 UC2 - Report assegnazione 29 3.3.3 UC3 - Segnalazione guasto 30 3.3.4 UC4 - Stato del sistema 31 3.3.5 UC5 - Gestione delle risorse 31 3.3.6 UC6 - Gestione degli utenti 33 4 p r o g e t ta z i o n e 35
4.1 Il pattern MVC in CakePHP 36 4.2 Progettazione base di dati 37
4.2.1 Progettazione concettuale 37 4.2.2 Progettazione logica 39
4.2.3 Sicurezza delle password utente 41 4.3 Progettazione sito web 41
4.3.1 Struttura 42 4.3.2 Prima fase 43 4.3.3 Seconda fase 45
v
4.4 Progettazione applicazione Android 46 5 i m p l e m e n ta z i o n e e r e a l i z z a z i o n e 49
5.1 Funzionalità realizzate 49 5.1.1 Gestione delle risorse 49 5.1.2 Gestione degli utenti 50 5.1.3 Gestione dei software 51
5.1.4 Gestione dei pacchetti software 52 5.1.5 Gestione delle licenze 52
5.1.6 Gestione delle interfacce di rete 53 5.1.7 Gestione dei magazzini 53
5.1.8 Gestione dei report 54
5.2 Verifica e validazione dei prodotti finiti 54 iii c o n c l u s i o n e 59
6 r i e p i l o g o d e i r i s u ltat i 61 6.1 Riepilogo dei prodotti finiti 61 6.2 Uso dei prodotti in azienda 62 7 a na l i s i c r i t i c a 63
7.1 Analisi critica dello stage 63 7.1.1 Consuntivo delle ore 63
7.2 Analisi critiche agli strumenti utilizzati 66 7.3 Analisi critica del prodotto 67
7.4 Ulteriori aree di sviluppo 67 iv a p p e n d i c e 69
a g l o s s a r i o 75
Figura 1 Logo di Apache HTTP Server 8
Figura 2 Logo di MySQL 8
Figura 3 Logo di Eclipse Indigo 9
Figura 4 Logo di Android 3.1 Honeycomb 10 Figura 5 Logo di Notepad++ 10
Figura 6 Logo del framework CakePHP 11 Figura 7 Logo di MySQL Workbench 12 Figura 8 Logo di SQLyog 13
Figura 9 Logo di Git 14 Figura 10 Logo di Bootstrap 15 Figura 11 Logo di Slim 15 Figura 12 Logo di Smarty 16 Figura 13 Logo di Codeigniter 17 Figura 14 Logo di PostgreSQL 18 Figura 15 Use case UC1 28 Figura 16 Use case UC2 29 Figura 17 Use case UC3 30 Figura 18 Use case UC4 31 Figura 19 Use case UC5 32 Figura 20 Use case UC6 33
Figura 21 Schema concettuale del database 40
Figura 22 Schema logico del database, generato da My- SQL Workbench 42
Figura 23 Diagramma di attività per la creazione di una risorsa 45
Figura 24 Schermata di accesso alla gestione delle risor-
se 49
Figura 25 Schermata per la gestione delle risorse di tipo
“Computer” 50
Figura 26 Schermata per la gestione degli utenti 51 Figura 27 Schermata per la gestione del software 52 Figura 28 Schermata per la gestione della rete 53 Figura 29 Schermata per la gestione dei magazzini 54
E L E N C O D E L L E TA B E L L E
Tabella 1 Requisiti fondamentali 27 Tabella 2 Requisiti desiderabili 28
vii
Tabella 4 Test eseguiti sul sito web in modalità amministra- tore 57
Tabella 5 Test eseguiti sul sito web in modalità utente 58
L I S T I N G S
Listing 1 Esempio funzione magica di CakePHP 11 Listing 2 Configurazione della classe Router per la ge-
stione di JSON 45
viii
I N T R O D U Z I O N E
In questa parte verranno descritti l’ambiente di utilizzo del prodotto sviluppato, l’azienda Moretto S.p.A. e i biso- gni aziendali che questo progetto si pone come obiettivo di soddisfare, gli strumenti utilizzati per sviluppare il pro- dotto durante tutte le sue fasi e un breve riepilogo dei risultati che sono stati ottenuti.
1
A M B I E N T E D ’ U T I L I Z Z O
1.1 l’azienda
Moretto S.p.A. è un’azienda fondata nel 1980 che si occupa di auto- mazioni nel mondo della trasformazione delle materie plastiche. Ad oggi è composta da circa 200 persone distribuite in 5 filiali sparse nel mondo: Italia, Germania, Brasile, Turchia, Europa orientale. L’azien- da segue l’intero ciclo di vita dei prodotti, a partire dalla ricerca e sviluppo di nuove tecnologie e macchinari, fino alla distribuzione e all’assistenza tecnica post vendita.
L’evoluzione costante promossa dall’azienda ha portato tale realtà da un’impresa di stampo artigianale ad una multinazionale in compe- tizione nel mercato globale. Ciò ha richiesto una costante espansione sia della forza lavoro impegnata in azienda che di un continuo ag- giornamento ed espansione delle strumentazioni e risorse dedicate al controllo, coordinazione e gestione dei processi produttivi.
Di particolare interesse è l’evoluzione che ha seguito l’ufficio ICT della Moretto S.p.A., inizialmente denominato Centro Elaborazione Dati, ha avuto un ruolo di supporto ai reparti di ricerca e in segui- to all’intera rete aziendale. Con lo sviluppo di nuove tecnologie e la costante crescita dell’azienda, all’ufficio viene richiesto sempre più spesso di intraprendere un ruolo più attivo nelle operazioni azien- dali, automatizzando le procedure che in passato venivano svolte manualmente dai vari uffici.
Negli ultimi anni l’azienda ha intrapreso nuovi ed innovativi pro- getti di ricerca, che richiedono un utilizzo sempre maggiore di risorse informatiche. Nel mese di Novembre 2012 è stato installato un super calcolatore da 1088 CPU, racchiusi in 128 processori Intel, con lo sco- po di effettuare calcoli e simulazioni avanzate predisposte dal reparto di Ricerca e Sviluppo aziendale.
L’alto livello di informatizzazione raggiunto dall’azienda ha cau- sato un altrettanto alto livello di utilizzo di risorse informatiche sia hardware che software. In un mercato globale competitivo la qualità dei prodotti e servizi forniti dall’azienda è legata ad un utilizzo effica- ce di tutte le risorse interne anche non direttamente legate all’aspetto strettamente produttivo.
3
1.2 b i s o g n i a z i e n d a l i
I bisogni aziendali che questo progetto si propone di soddisfare sono raggruppabili nelle seguenti categorie:
1. Inventario delle risorse: tenere traccia di quanti e quali risorse sono disponibili e dove sono immagazzinate;
2. Registro delle consegne delle risorse: memorizzare a quali di- pendenti sono state assegnate le risorse, in modo da conoscere in ogni momento la posizione e lo stato delle risorse;
3. Resoconto manutenzione e segnalazioni di guasto: registrare lo storico di tutti gli interventi di manutenzione effettuati sulle risorse, per analizzare eventuali periodicità e valutare l’efficacia delle riparazioni piuttosto che di eventuali sostituzioni;
4. Gestione delle licenze: mantenere un registro delle licenze in possesso dell’azienda e dell’utilizzo attuale delle stesse, in mo- do da evitare sforamenti indesiderati e pianificare eventuali ac- quisti di nuove licenze se necessario;
5. Mobilità: vista l’estensione dell’azienda, è necessario che le so- luzioni realizzate ai bisogni sopracitati siano accessibili anche da dispositivi mobili.
In breve, deve essere sviluppato un sistema informatizzato per la gestione delle risorse, sia di tipo hardware che software, assegnate al- l’ufficio ICT e distribuite all’interno dell’azienda. Tale sistema deve es- sere accessibile anche da dispositivi mobili e visualizzare vari tipi di report relativi alla distribuzione, manutenzione e immagazzinamento di tali risorse.
Il sistema sviluppato dovrà essere assolutamente intuitivo e rapido nell’utilizzo, in modo da costituire un valido supporto nell’operativi- tà dell’ufficio e non un’ulteriore aggiunta al carico di lavoro che è attualmente sostenuto dai membri del reparto ICT.
1.3 r a g i o n i d i n e c e s s i tà
Prima dello sviluppo di questo progetto, la gestione delle risorse e delle informazioni ad esse collegate era effettuata tramite un sistema cartaceo o addirittura a memoria. Anche se tale sistema poteva esse- re sufficiente in una piccola azienda, con un numero di dipendenti limitato, ora è ingestibile all’interno di un’azienda con oltre duecen- to persone al suo interno. L’aumento esponenziale delle risorse da gestire a mano causa evidenti problemi, specialmente nel caso che il responsabile fosse assente o comunque non reperibile.
Inoltre, tale approccio è stressante per chi è costretto a gestirlo e si presta ad errori di dimenticanza specialmente in un ambiente dina- mico e in cui vi sono molti progetti da seguire contemporaneamente:
è sufficiente una telefonata o un’email urgente per interrompere il flusso dell’operazione corrente e ciò può facilmente far dimenticare di aggiornare l’elenco delle risorse distribuite.
Anche dal punto di vista dell’utilizzatore delle risorse, operare in un ambiente non automatizzato causa fastidi e ritardi nella gestione.
L’utilizzo delle ricevute cartacee richiede attenzione e occupa spazio, la richiesta di manutenzione, da effettuare via telefono, causa distur- bo ed interruzione nelle normali procedure lavorative con conseguen- te perdita di tempo per ritornare con concentrazione alle mansioni interrotte.
In queste condizioni è stato constatato che lo sviluppo di un siste- ma dedicato a questi bisogni avrebbe diminuito considerevolmente il peso di tutte quelle operazioni di routine relative alla gestione delle risorse, anche semplicemente per il fatto di poter godere di uno stru- mento in grado di fornire report sulla situazione in pochi secondi, sen- za dover consultare archivi cartacei o fare affidamento alla memoria personale.
Nell’insieme delle competenze e mansioni richieste correntemente all’ufficio, la gestione delle risorse copre un ruolo secondario ma co- munque fondamentale. Il fatto che non sia un compito eseguito tutti i giorni ma solamente su richiesta e all’occorrenza di eventi non pe- riodici e spesso imprevedibili, come l’arrivo di un nuovo dipendente, l’installazione di un nuovo software o la sostituzione di una risorsa guasta, rende lo sviluppo e l’utilizzo di uno strumento automatico un vantaggio considerevole in quanto andrà a sostituire l’attuale impian- to cartaceo che richiede tempi di consultazione e mantenimento con- siderevoli, senza contare il fatto che non offre la garanzia di contenere dati sempre aggiornati e coerenti con la realtà.
2
I L P R O G E T T O
2.1 o b i e t t i v i d e l l o s ta g e
L’obiettivo principale dello stage è la realizzazione dei componenti principali del sistema di gestione delle risorse dell’ufficio ICT, predi- sponendo tale impianto per espansioni ed aggiunte in un secondo momento.
Inoltre, lo sviluppo di questo progetto servirà all’azienda per indi- viduare possibili nuovi strumenti adeguati per lo sviluppo di ulterio- ri applicazioni web interne. Tali strumenti devono essere facilmente utilizzabili e garantire la possibilità di sviluppare applicazioni leg- gere, flessibili e facilmente utilizzabili da utenti privi di particolari conoscenze informatiche.
Gli obiettivi che devono essere soddisfatti dal progetto sono:
1. Definizione e creazione di un database adeguato per l’immagaz- zinamento delle informazioni relative alle risorse aziendali;
2. Sviluppo di un’interfaccia grafica (GUI) per la manipolazione dei dati memorizzati e per la visualizzazione dello stato degli stessi, basata su browser web;
3. Regolazione degli accessi e delle funzionalità disponibili a se- conda dell’utilizzatore corrente;
4. Possibilità di gestire i tipi di risorse monitorati dal sistema di- rettamente attraverso l’interfaccia grafica;
5. Realizzazione di un’applicazione mobile per l’accesso al sistema per Android.
2.2 s t r u m e n t i a d i s p o s i z i o n e
In questa sezione verranno illustrati gli strumenti e i framework utilizzati, indicando inoltre le motivazioni di tali scelte.
2.2.1 Apache HTTP Server
7
Figura 1: Logo di Apache HTTP Server
Apache HTTP Server è una piattaforma server Web open source.
Una tra le principali attrattive di questa piattaforma è la sua modu- larità che permette un’elevata flessibilità nella configurazione finale del web server. In questo progetto sono stati utilizzati principalmen- te i moduli mod_rewrite per la sostituzione degli url d’accesso alle pagine e il supporto per PHP.
La scelta di utilizzare questo server è dovuta al fatto che tutte le applicazioni web dedicate all’uso interno in azienda sono attualmente distribuite su questo tipo di server Web.
2.2.2 MySQL
Figura 2: Logo di MySQL
MySQL è un sistema per la gestione di basi di dati relazionali (RDBMS) tra i più diffusi al mondo. Nonostante alcune limitazioni, come la mancanze del supporto di chiavi esterne se le tabelle non utilizzano il motore standard “InnoDB” e la possibilità di definire un solo trigger legato ad un particolare evento (ad esempio, prima di una operazione di inserimento su una tabella), MySQL supporta una buona parte dello standard SQL definito nel 1996.
Nell’azienda ospitante le applicazioni non mission-critical che han- no bisogno di un database per le loro operazioni utilizzano uno o più database MySQL. Per questo la scelta è ricaduta su questo siste- ma piuttosto che altri DBMS. Inoltre, il framework PHP scelto per lo sviluppo, CakePHP, supporta MySQL senza necessità di particolari configurazioni.
2.2.3 Eclipse Indigo
Figura 3: Logo di Eclipse Indigo
Eclipse è un ambiente di sviluppo integrato (IDE) scritto in Java e pertanto multipiattaforma. Grazie alla sua modularità è possibile uti- lizzarlo per sviluppare codice in differenti linguaggi. In questo pro- getto è stato utilizzato per sviluppare codice Java e PHP, ma può esse- re utilizzata per qualunque linguaggio dopo aver scaricato il modulo apposito tramite il sito ufficiale di Eclipse.
La scelta di utilizzare Eclipse piuttosto che altri IDE è dovuta al fatto che possiedo già esperienze di utilizzo precedenti che mi per- mettono di utilizzare il prodotto efficacemente senza dover investire tempo nell’apprendimento dello stesso. Inoltre, è la piattaforma di sviluppo consigliata da Google per sviluppare applicazioni Android e permette, grazie ad uno dei suoi moduli, una semplice integrazione con il sistema di versionamento Git.
Android Developer Toolkit
Android Developer Toolkit (ADT) è un plugin sviluppato specificata- mente per Eclipse da Google per fornire gli strumenti adeguati per la- vorare su applicazioni Android. Fornisce strumenti quali editor XML specifici per i file di configurazione delle applicazioni mobili, pannel- li di debug, un designer grafico per lo sviluppo dell’interfaccia utente e uno strumento per esportare l’applicazione sui dispositivi mobili.
2.2.4 Android Honeycomb
Il Sistema Operativo Android è un sistema sviluppato specifica- tamente per i dispositivi mobili, basato su un kernel Linux e una Macchina Virtuale Dalvik. Sebbene questa macchina virtuale venga spesso confusa con una normale JVM (Macchina Virtuale Java), il by- tecode delle applicazioni che esegue non è bytecode Java ma una sua
Figura 4: Logo di Android 3.1 Honeycomb
elaborazione successiva. Il codice sorgente è scritto in Java, compilato normalmente in file compatibili con la JVM standard, successivamen- te convertiti in file .dex (Dalvik EXecutable) per l’installazione sul dispositivo
In questo progetto è stata scelta la versione 3.1 nota come Honey- comb poiché è la versione di Android compatibile con la maggior parte dei dispositivi mobili aziendali.
2.2.5 Notepad++
Figura 5: Logo di Notepad++
Notepad++ è un editor di testo avanzato che fornisce la possibilità di evidenziare la sintassi del codice sorgente per un elevato numero di linguaggi diversi. Questo editor è stato utilizzato per la scrittura
dei file misti HTML/PHP (le “viste” dell’applicazione web) perché è molto più leggero di un IDE completo come Eclipse.
2.2.6 CakePHP
Figura 6: Logo del framework CakePHP
La parte principale dell’applicazione, la logica di business lato server, è stata creata utilizzando il framework CakePHP. Questo fra- mework permette di sviluppare applicazioni web utilizzando il pat- tern MVC velocemente, sfruttando le funzionalità di scaffolding ed automazione integrate nel codice. CakePHP adotta un approccio del tipo “Convention over Configuration” ossia preferisce utilizzare un insieme rigido di convenzioni di scrittura del codice piuttosto che configurare esplicitamente i parametri di lavoro dell’applicazione.
Combinando tale approccio ad uno stile di programmazione ad oggetti, è possibile accedere alle informazioni collegate ad un ogget- to utilizzando delle speciali funzioni “magiche” (così definite dagli autori del framework) che, basandosi sulle convenzioni predefinite, sono in grado di estrarre dal database tutte le informazioni desidera- te senza dover definire metodi per l’accesso dedicati. Per esempio, in questo frammento di codice:
Listing 1: Esempio funzione magica di CakePHP
1 $this->User->findByEmailOrUsername(’mrossi ’);
//SQL equivalente:
// User.email = ’mrossi’ OR User.username = ’mrossi’;
la funzione findBy<...> permette di recuperare uno specifico sottoin- sieme di dati dal modello “User”, collegato per convenzione alla ta-
bella “users”, senza dover definire una funzione propria della classe ma semplicemente sfruttando le automazioni di CakePHP.
Non avendo mai sviluppato un’applicazione PHP che sfruttasse il pattern MVC, ho ritenuto che la potenza di queste automazioni potes- se essere un valido aiuto per raggiungere il risultato desiderato scri- vendo meno linee di codice. Inoltre, siccome è necessario seguire una stretta convenzione di scrittura del codice per poter sfruttare appieno le potenzialità del framework, questo fornisce di conseguenza uno stile di scrittura ben definito da utilizzare, così che non è necessario dover definire uno stile di scrittura proprio.
Un’ulteriore caratteristica interessante di questo framework è la possibilità data ai Controller di fornire risultati in diversi formati a seconda dell’estensione del file richiesto tramite URL. In questo progetto ho utilizzato il formato JSON per la comunicazione tra il server web e l’applicazione android: è sufficiente impostare l’opzio- ne apposita nel controller principale, l’attivazione del “gestore esten- sioni” per JSON, ed aggiungere una sola riga all’interno dei meto- di. Così facendo, è possibile servire due contenuti completamente diversi solamente richiamando l’url /servername/controller/action oppu- re /servername/controller/action.json senza grandi modifiche al codice sorgente.
2.2.7 MySQL Workbench
Figura 7: Logo di MySQL Workbench
MySQL Workbench è un tool per la gestione, lo sviluppo e il con- trollo di basi di dati MySQL. Oltre ad un’interfaccia grafica intuitiva per la creazione ed interrogazione di tabelle, offre un interessante
strumento automatico per la creazione dello schema grafico della ba- se di dati sviluppata. Grazie a questo strumento è stato possibile ge- nerare lo schema per la documentazione in pochi minuti piuttosto che le ore che sarebbero state necessarie per disegnarlo a mano.
Una critica che è possibile sollevare su MySQL Workbench è la grande pesantezza e lentezza d’uso. Richiede molte risorse hardware per funzionare e per tutte le operazioni di modifica ed inserimento dei dati richiede una doppia conferma. Anche se questa misura di sicurezza è potenzialmente utile, è spesso eccessiva specialmente per operazioni basilari come inserimento o cancellazione di poche righe.
2.2.8 SQLyog community edition
Figura 8: Logo di SQLyog
SQLyog è uno strumento analogo a MySQL workbench, più sem- plice e più leggero, già usato in azienda per la gestione delle basi di dati MySQL correntemente in uso. Nonostante la mancanza di fun- zionalità avanzate, disponibili nella versione a pagamento, compensa la lentezza e pesantezza di MySQL workbench con un minor uso di risorse e una maggior velocità nelle operazioni di gestione e controllo di maggiore frequenza.
Combinando MySQL Workbench nelle fasi di sviluppo e design con SQLyog durante le fasi di controllo e gestione si ottiene uno strumento completo, veloce, facile da usare e soprattutto, gratuito.
2.2.9 Git
Figura 9: Logo di Git
Git è uno tra i più famosi sistemi di controllo versione distribuiti.
Nell’azienda ospitante non era in uso nessun sistema di versionamen- to vero e proprio in quanto era previsto esclusivamente un backup giornaliero di tutti i server contenenti codice sorgente e altro materia- le di sviluppo. Ovviamente l’utilizzo di un sistema più organizzato è da preferirsi ai semplici backup periodici in quanto contiene al suo interno tutta una serie di informazioni relative all’andamento dello sviluppo come note, log e gestione automatica delle differenze e dei conflitti tra differenti versioni di file.
Git è stato preferito agli altri concorrenti esistenti in quanto non richiede un server centrale per la creazione dei repository ma può es- sere utilizzato direttamente in locale senza intervento dell’ammini- stratore della rete aziendale per eventuali configurazioni di server e permessi d’accesso. Inoltre ho già utilizzato Git con successo in pas- sato e l’esperienza accumulata mi ha permesso una rapida e semplice implementazione ed attivazione del sistema.
2.2.10 Altri strumenti
Durante il periodo di analisi sono stati analizzati altri framework e strumenti che non sono poi stati utilizzati, mentre altri sono stati scoperti in un momento avanzato della progettazione e nonostante avessero funzionalità anche interessanti, non è stato possibile inserirli in corso d’opera oppure si son rivelati di difficile integrazione con i restanti componenti già utilizzati Per completezza, vengono riportati qui di seguito.
2.2.10.1 Bootstrap
Figura 10: Logo di Bootstrap
Bootstrap è 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 Apache 2.0. Fornisce un CSS di base molto avanzato e una libreria JavaScript basata su jQuery per le ani- mazioni e gli effetti visivi. Questi elementi permettono un uso quasi immediato delle potenzialità di questo framework, demandando allo sviluppatore solamente la pulizia del CSS di base di tutte le caratteri- stiche extra non utilizzate (solamente per diminuire la dimensione del file .css se desiderato) e piccole modifiche a colori e stili. In ogni ca- so, queste operazioni possono essere automatizzate personalizzando il framework prima del download inserendo solamente i componenti desiderati e impostando i temi cromatici più appropriati per il sito desiderato.
Questo strumento non è stato utilizzato in questo progetto per la limitata quantità di tempo dedicata a curare il front-end del sistema rispetto al totale delle monte ore. In ogni caso la sua efficiacia è con- siderevole e dopo questo progetto, Bootstrap è stato impiegato con successo in due nuovi progetti e verrà incluso in tutti quelli successivi che verranno sviluppati
2.2.10.2 Slim
Figura 11: Logo di Slim
Slim è un framework PHP minimale che ho individuato durante le fasi finali del progetto, dopo aver rilevato che l’utilizzo di un fra- mework MVC completo e rigido è più spesso una limitazione che un aiuto nello sviluppo di applicazioni web.
Essenzialmente fornisce un potente motore di routing degli URL, metodi per sicurezza e crittografia e una semplice gestione dei mes- saggi flash (solitamente usati per notificare errori all’utente). Inoltre, ha una semplicissima procedura di configurazione per essere uti- lizzato e non impone allo sviluppatore nessun tipo di vincolo re- lativamente a convenzioni di scrittura o tipologia di base di dati supportata.
Non è stato utilizzato in questo progetto poiché non è possibile so- stituire il vecchio framework scelto in partenza senza dover riscrivere interamente il codice già prodotto. Slim verrà comunque considerato nello sviluppo di nuovi progetti all’interno dell’azienda.
2.2.10.3 Smarty template engine
Figura 12: Logo di Smarty
Smarty è un metodo molto efficace per separare nettamente la ge- stione della logica applicativa dalla sua rappresentazione a video. No- nostante sia basato interamente su PHP, i template utilizzano esclusi- vamente codice HTML con l’aggiunta di tag “Smarty”, scritti con una sintassi molto simile a quella di PHP. Tali tag sono principalmente controlli di flusso (if, cicli for, foreach e while) e comandi per l’inclusio- ne di ulteriori sotto-template, per facilitare uno sviluppo modulare dei vari componenti grafici utilizzati.
La principale critica nell’utilizzo di Smarty è il fatto di dover impa- rare un nuovo “linguaggio” per poterlo utilizzare effettivamente. In ogni caso, la sintassi di Smarty è talmente simile a PHP che in pratica la curva d’apprendimento è inesistente. Una volta presa confidenza con lo strumento, è possibile ottenere una vera e propria separazione tra logica e presentazione, ottenendo un codice HTML pulito e privo
del classico mix di parentesi angolari con PHP per la stampa a video del contenuto delle variabili.
Non è stato possibile utilizzare Smarty in questo progetto perchè l’integrazione con CakePHP è complessa. Inoltre, CakePHP fornisce metodi propri per la generazione parziale di elementi HTML che avrebbero reso l’utilizzo di Smarty decisamente poco utile, anche se il risultato finale è risultato meno pulito rispetto a quanto si sarebbe potuto ottenere con un motore di templating dedicato.
2.2.10.4 Codeigniter
Figura 13: Logo di Codeigniter
Codeigniter è un framework per PHP che permette lo sviluppo di applicazioni MVC. Differisce da CakePHP offrendo un approccio più libero allo sviluppo di applicazioni, senza imporre convenzioni specifiche o altre limitazioni. Ovviamente questo non permette l’esi- stenza di tutte quelle automazioni particolari che si possono trovare in CakePHP.
In ogni caso a posteriori posso affermare che l’utilizzo di un fra- mework particolare piuttosto che un altro suo concorrente non avreb- bero portato a sostanziali differenze nel prodotto finito e che la scelta va a cadere più che altro su preferenze personali piuttosto che su ana- lisi approfondite dei benefici che può portare l’utilizzo di un prodotto piuttosto che un altro.
2.2.10.5 PostgreSQL
Figura 14: Logo di PostgreSQL
PostgreSQL è un DataBase Management System relazionale ad ogget- ti. Implementa la maggior parte dello standard SQL:2008 e permette molte funzionalità più avanzate rispetto a MySQL. Lo sviluppatore può, tra le altre cose, definire tipi di dato propri, possono essere de- finiti più trigger per uno stesso evento (vengono poi attivati secondo ordine alfabetico) ed è possibile definire l’ereditarietà tra tabelle.
In questo progetto lo schema ad oggetti della base di dati, discus- so in seguito, prevede vari casi di ereditarietà, anche multipla, tra tabelle. Se avessi potuto utilizzare questo DBMS il lavoro sulla base di dati si sarebbe rivelato molto, molto più semplice da effettuare e contemporaneamente più efficace da utilizzare in quanto è il sistema stesso ad occuparsi degli automatismi necessari, invece di costringere lo sviluppatore a realizzare controlli e procedure a livello di applica- zione e di conseguenza aumentare la probabilità di generare errori nel codice.
2.3 r i s u ltat i o t t e n u t i
I prodotti sviluppati risultano soddisfare tutti i requisiti fondamen- tali richiesti dall’azienda, sono stati sviluppati sia la parte applica- zione web, sia l’applicazione Android richieste dal progetto. L’appli- cazione web consente un completo accesso alle funzionalità, sia per l’amministratore che per gli utenti: gli utenti possono visualizzare i dettagli di tutte le risorse che risultano assegnate a loro e posso- no segnalare eventuali guasti; l’amministratore ha accesso a tutte le funzionalità relative all’inserimento di nuove risorse nel sistema, ge- stione delle licenze e degli utenti e resoconti su tutti i dati inseriti nel sistema. L’applicazione mobile è dedicata esclusivamente all’am- ministratore e fornisce funzionalità ridotte rispetto all’applicazione web: vengono visualizzati solamente i resoconti relativi ai contenuti dei magazzini e le operazioni su di essi, la creazione e la distribuzio-
ne delle risorse, l’installazione o rimozione di software nelle risorse abilitate.
Il front-end dell’applicazione, seppur completo e funzionante, non è stato particolarmente curato sotto l’aspetto grafico e pertanto l’im- patto visivo dell’applicazione può risultare crudo e non rifinito. Visto l’ambito d’uso dell’applicazione, l’azienda non ha ritenuto rilevante questo difetto, che verrà risolto nelle successive versioni dell’applica- zione.
S V I L U P P O
In questa parte verranno descritte tutte le varie fasi relati- ve allo sviluppo del prodotto, esaminandone l’analisi dei requisiti richiesti dall’azienda, la progettazione della ba- se di dati e delle applicazioni, l’implementazione e rea- lizzazione di tali progetti indicando anche le principali problematiche rilevate e come sono state risolte.
3
A N A L I S I D E I R E Q U I S I T I
In questo capitolo verranno analizzati i requisiti individuati con l’azienda, approfondendo le funzionalità richieste nel piano di pro- getto. In questa fase è avvenuto un confronto con i rappresentanti dell’azienda per delineare al meglio la realtà da modellare e per ve- nire a conoscenza delle procedure attualmente impiegate relative alla gestione cartacea delle risorse in modo da rispecchiare al meglio il modus operandi corrente nel nuovo sistema.
3.1 c o n t e s t o d’uso
Nell’ambito di un’azienda in continua crescita, diviene sempre più difficoltoso tenere traccia di tutte le risorse assegnate ai dipendenti.
Tale difficoltà è composta da tre maggiori caratteristiche:
• La quantità di risorse da gestire, in costante aumento;
• La frequenza dei prestiti, dato che molte risorse non sono asse- gnate in “permanenza” ad un utente ma sono invece assegnate su una base di necessità contingenti. Un esempio potrebbe esse- re un navigatore GPS e un cellulare aziendale per una trasferta di pochi giorni;
• La distanza fisica tra le risorse. L’azienda possiede varie filiali nel mondo e non è facile tenere traccia delle risorse inviate e ritornate, insieme a tutte le altre.
Fino ad ora questo lavoro è stato delegato a supporti cartacei e alla memoria degli addetti, cosa che non può più essere accettabile nell’ambito di una multinazionale in crescita come la Moretto S.p.A..
Questo software si propone come rimpiazzo dell’attuale sistema, con lo scopo di snellire le pratiche utilizzate correntemente e alleggerire il lavoro degli addetti, fornendo una nuova piattaforma informatica di facile utilizzo e veloce consultazione.
3.2 r e q u i s i t i f u n z i o na l i
Questo software è un sistema che l’amministratore delle risorse potrà utilizzare per registrare e tenere traccia dello stato e dell’as- segnazione dei beni aziendali che deve gestire. Sono previste tutta una serie di risorse principali solitamente gestite attualmente dall’uf- ficio ICT, ma è previsto un meccanismo per l’inserimento arbitrario di nuovi tipi di risorse generiche per venire incontro a necessità future.
23
L’amministratore ha la possibilità di gestire anche gli utenti, che rappresentano tutto il personale dell’azienda a cui vengono assegna- te le risorse. Il sistema inoltre permette di gestire anche l’amministra- zione del software installato in azienda: è possibile creare pacchetti software per la facile installazione di profili di base sui vari compu- ter aziendali raggruppando i software più utilizzati. Contemporanea- mente viene tenuta traccia del consumo di licenze in modo da piani- ficare per tempo l’eventuale acquisto di ulteriori espansioni e nuovi investimenti.
Il prodotto sviluppato fornisce anche la possibilità di gestire la rete aziendale, tenendo traccia degli indirizzi IP e MAC di tutti i dispositivi connessi, in modo da facilitare le attività di sorveglianza e manutenzione dell’intera rete informatica.
Questo sistema fornisce la possibilità agli utenti di tenere traccia di tutte le risorse che sono state loro assegnate ed inoltre è prevista un’interfaccia per la segnalazione dei guasti e malfunzionamenti in modo da segnalare tempestivamente all’amministratore la necessità di un intervento. L’obiettivo principale di queste funzionalità è di ri- durre il carico di telefonate attualmente sulle spalle dell’amministra- tore, aumentando la produttività riducendo al minimo le interruzioni impreviste.
3.2.1 Elenco dei requisiti
Viene di seguito presentato l’elenco esaustivo di tutti i requisiti di sistema individuati. Ogni requisito è corredato dal seguente insieme di informazioni:
• Chiave: costituita da un carattere che identifica il tipo del requi- sito (“F” per fondamentale e “D” per desiderabile) seguito da un codice numerico. Un codice è costituito da numeri separati dal carattere ‘.’. Se esiste un insieme di codici a, b, ..., z che han- no per codice prefisso il codice x, x è soddisfatto se e solo se a, b, ..., z sono soddisfatti.
• Descrizione: la descrizione testuale del requisito
3.2.1.1 Requisiti fondamentali
Chiave Descrizione
F-1 L’utente deve poter accedere al sistema dopo che si è autenticato utilizzando username e password
F-2 L’utente deve poter visualizzare quali risorse sono state a lui assegnate
Chiave Descrizione
F-2.1 L’utente deve poter visualizzare l’eventuale scadenza dell’assegnazione di ogni risorsa
F-2.2 L’utente deve poter visualizzare lo stato delle risorse a lui assegnate
F-3 L’utente deve poter inserire un nuovo report di guasto su una risorsa funzionante
F-3.1 L’utente deve poter vedere lo stato di tutti i report che ha scritto
F-4 Una risorsa deve essere segnalata come guasta finché tutti i report di guasto non sono stati corretti
F-5 L’amministratore deve poter visualizzare un report globale delle risorse nel sistema
F-5.1 Il report deve contenere lo stato di tutte le risorse
F-5.2 Il report deve contenere l’eventuale assegnazione di tutte le risorse per cui è applicabile
F-6 L’amministratore deve avere la possibilità di gestire le risorse del sistema
F-6.1 L’amministratore deve avere la possibilità di creare ed inserire risorse nel sistema
F-6.1.1 L’amministratore può inserire risorse di tipo “Computer”
F-6.1.2 L’amministratore può inserire risorse di tipo “Telefono”
F-6.1.3 L’amministratore può inserire risorse di tipo “Mobile device”
F-6.1.4 L’amministratore può inserire risorse di tipo “Server”
F-6.1.5 L’amministratore può inserire risorse di tipo “Switch”
F-6.1.6 L’amministratore può inserire risorse di tipo “Stampante”
F-6.2 L’amministratore deve avere la possibilità di modificare i dettagli delle risorse presenti nel sistema
F-6.3 L’amministratore deve avere la possibilità di eliminare le risorse dal sistema
F-7 L’amministratore deve avere la possibilità di gestire gli utenti del sistema
F-7.1 L’amministratore deve avere la possibilità di creare ed inserire utenti nel sistema
F-7.2 L’amministratore deve avere la possibilità di modificare i dettagli degli utenti presenti nel sistema
F-7.3 L’amministratore deve avere la possibilità di eliminare gli utenti dal sistema
Chiave Descrizione
F-8 L’amministratore può vedere tutti i report sottoposti dagli utenti
F-8.1 L’amministratore può filtrare i report in base allo stato risolto / da risolvere
F-9 L’amministratore deve avere la possibilità di gestire il software registrato nel sistema
F-9.1 L’amministratore deve avere la possibilità di creare ed inserire dettagli del software nel sistema
F-9.2 L’amministratore deve avere la possibilità di modificare i dettagli del software registrato nel sistema
F-9.3 L’amministratore deve avere la possibilità di eliminare i dettagli del software registrato nel sistema
F-10 L’amministratore deve avere la possibilità di gestire i pacchetti di software registrati nel sistema
F-10.1 L’amministratore deve avere la possibilità di creare ed inserire pacchetti di software nel sistema
F-10.2 L’amministratore deve avere la possibilità di modificare i dettagli dei pacchetti di software nel sistema
F-10.3 L’amministratore deve avere la possibilità di eliminare i pacchetti di software dal sistema
F-11 L’amministratore può aggiungere software ad un pacchet- to di software esistente
F-11.1 L’amministratore può rimuovere software da un pacchetto di software esistente
F-12 L’amministratore deve avere la possibilità di gestire le licenze registrate nel sistema
F-12.1 L’amministratore deve avere la possibilità di creare ed inserire dettagli delle licenze registrate nel sistema
F-12.2 L’amministratore deve avere la possibilità di modificare i dettagli delle licenze registrate nel sistema
F-12.3 L’amministratore deve avere la possibilità di eliminare i dettagli delle licenze registrate nel sistema
F-12.4 L’amministratore può variare il numero di licenze disponibili per le risorse del sistema
F-12.5 L’amministratore può specificare il costo in licenze del software registrato nel sistema
F-12.6 L’amministratore può specificare il costo in licenze delle risorse registrate nel sistema
Chiave Descrizione
F-12.7 L’amministratore deve avere la possibilità di visualizza- re un report sulla distribuzione delle licenze, indicante il numero totale e quelle correntemente assegnate
F-13 L’amministratore deve avere la possibilità di gestire le interfacce di rete delle risorse registrate nel sistema
F-13.1 L’amministratore deve avere la possibilità di creare ed inse- rire dettagli delle interfacce di rete delle risorse registrate nel sistema
F-13.2 L’amministratore deve avere la possibilità di modificare i dettagli delle interfacce di rete delle risorse nel sistema F-13.3 L’amministratore deve avere la possibilità di eliminare i
dettagli delle interfacce di rete delle risorse registrate nel sistema
F-13.4 L’amministratore può impostare l’indirizzo MAC dell’in- terfaccia di rete
F-13.5 L’amministratore può impostare l’indirizzo IP dell’interfac- cia di rete
F-13.6 L’amministratore può aggiungere interfacce di rete alle risorse “Computer”, “Server”, “Stampante”
F-13.7 L’amministratore può rimuovere interfacce di rete alle risorse “Computer”, “Server”, “Stampante”
Tabella 1: Requisiti fondamentali
3.2.1.2 Requisiti desiderabili
Chiave Descrizione
D-1 L’utente deve poter accedere aggiungere nuovi report con informazioni aggiuntive relative ad un guasto su una risorsa già segnalata come guasta
D-1.1 Prima di aggiungere nuovi report, l’utente deve poter leg- gere tutti i vecchi report già presenti relativi al guasto della risorsa corrente
D-2 L’amministratore deve aver accesso all’area riservata attraverso la stessa area di login degli utenti base
D-3 L’amministratore deve poter definire nuovi tipi di risorse D-4 L’amministratore può scegliere se autenticare gli utenti
localmente o utilizzando un server Active Directory D-5 L’applicazione deve essere validata nel formato HTML5
Chiave Descrizione
D-6 L’applicazione deve poter esportare tutti i report in formato JSON
Tabella 2: Requisiti desiderabili
3.3 c a s i d’uso
In questa sezione verranno elencati i casi d’uso individuati in fase d’analisi, relativamente all’applicazione web. Si noti che per quanto riguarda l’applicazione Android, i casi d’uso sono un sottoinsieme di quelli già individuati e perciò non verranno ripetuti separatamente.
3.3.1 UC1 - Homepage
Figura 15: Use case UC1
• Attori: Utente, Amministratore;
• Precondizione: L’attore ha effettuato il login con successo utiliz- zando le proprie credenziali;
• Scenario: L’attore-utente può effettuare una delle seguenti ope- razioni:
– Visualizzare la pagina relativa all’assegnazione delle risor- se (UC 2);
– Visualizzare la pagina relativa ai guasti (UC 3).
L’attore-amministratore può effettuare una delle seguenti ope- razioni:
– Visualizzare la pagina relativa al resoconto delle risorse inserite nel sistema (UC 4);
– Visualizzare la pagina relativa alla gestione delle risorse (UC 5);
– Visualizzare la pagina relativa alla gestione degli utenti (UC 6);
• Postcondizione: Il sistema visualizza la pagina richiesta dall’at- tore
3.3.2 UC2 - Report assegnazione
Figura 16: Use case UC2
• Attori: Utente;
• Precondizione: L’utente ha richiesto la pagina relativa all’asse- gnazione delle risorse;
• Scenario: Il sistema presenta all’utente la pagina contenente il resoconto delle risorse a lui assegnate. Se lo desidera, può richie- dere di visualizzare tutte le informazioni accessibili agli utenti comuni relative ad una delle risorse a lui assegnate (UC 2.1);
• Postcondizione: La richiesta dell’utente è stata soddisfatta, op- pure viene visualizzata la pagina di dettagli richiesta dall’uten- te.
3.3.3 UC3 - Segnalazione guasto
Figura 17: Use case UC3
• Attori: Utente;
• Precondizione: L’utente ha richiesto la pagina relativa alle se- gnalazioni di guasto;
• Scenario: Il sistema presenta all’utente la pagina contenente l’e- lenco delle segnalazioni già effettuate. Se lo desidera, può richie- dere di visualizzare lo stato corrente di una segnalazione, com- prese le eventuali risposte dell’amministratore (UC 3.1) oppure creare una nuova segnalazione di guasto (UC 3.2);
• Postcondizione: La richiesta dell’utente è stata soddisfatta, op- pure vengono visualizzate le informazioni relative ad una se- gnalazione di guasto, oppure l’utente ha creato una nuova se- gnalazione di guasto.
3.3.4 UC4 - Stato del sistema
Figura 18: Use case UC4
• Attori: Amministratore;
• Precondizione: L’amministratore ha richiesto la pagina relativa al resoconto delle risorse inserite nel sistema;
• Scenario: Il sistema presenta all’amministratore la pagina conte- nente l’elenco tipologie di risorse attualmente gestibili dal siste- ma. L’amministratore può compiere una delle seguenti azioni:
– Accedere al pannello per la gestione delle risorse (UC 5);
– Visualizzare tutte le risorse inserite in una particolare cate- goria (UC 4.1) ed eventualmente visualizzare i dettagli di una risorsa specifica (UC 4.1.1);
• Postcondizione: L’amministratore ha avuto accesso al pannello per la gestione delle risorse, oppure ha ricevuto le informazioni desiderate sulle risorse presenti nel sistema.
3.3.5 UC5 - Gestione delle risorse
• Attori: Utente, Amministratore;
Figura 19: Use case UC5
• Precondizione: L’amministratore ha richiesto la pagina relativa alla gestione delle risorse;
• Scenario: L’amministratore può effettuare una delle seguenti operazioni:
– Definire un nuovo tipo di risorsa gestibile dal sistema (UC 5.1);
– Inserire una nuova risorsa nel sistema (UC 5.2);
– Eliminare una risorsa dal sistema (UC 5.3);
– Modificare le informazioni relative ad una risorsa già pre- sente nel sistema (UC 5.4);
– Visualizzare la pagina relativa alla gestione del software registrato nel sistema (UC 5.5);
– Visualizzare la pagina relativa alla gestione dei pacchetti di software definiti nel sistema (UC 5.6);
– Visualizzare la pagina relativa alla gestione delle licenze (UC 5.7);
– Visualizzare la pagina relativa alla gestione delle interfacce di rete (UC 5.8);
• Postcondizione: Il sistema visualizza la pagina richiesta dall’am- ministratore oppure avvia la procedura richiesta dallo stesso.
3.3.6 UC6 - Gestione degli utenti
Figura 20: Use case UC6
• Attori: Amministratore;
• Precondizione: L’amministratore ha richiesto la pagina relativa alla gestione degli utenti;
• Scenario: Il sistema presenta all’amministratore l’elenco degli utenti inseriti nel sistema. Se lo desidera, può richiedere di vi- sualizzare i dettagli di un utente (UC 6.1), ed eventualmente mo- dificarli o rimuoverlo dal sistema (UC 6.1.1 e UC 6.1.2) oppure creare un nuovo utente (UC 6.2);
• Postcondizione: La richiesta dell’amministratore è stata soddi- sfatta, oppure vengono visualizzate le informazioni relative ad uno specifico utente, oppure l’amministratore ha creato un nuo- vo utente.
4
P R O G E T TA Z I O N E
In questo capitolo verranno illustrati i risultati della fase di pro- gettazione, in modo da descrivere le scelte progettuali effettuate per soddisfare i requisiti identificati nelle fasi precedenti.
Il progetto è composto da due parti distinte. Nella prima parte viene progettato, sviluppato e realizzato il sito web con il relativo database mentre nella seconda parte viene sviluppata l’applicazione Android in modo che il server di riferimento resti solamente uno, il server web precedentemente sviluppato.
Per la prima parte è stato scelto di utilizzare un ciclo di tipo itera- tivo. Seppur inerentemente meno efficiente di un ciclo di tipo incre- mentale, sarebbe stato poco realistico utilizzare un ciclo del secondo tipo in quanto:
• Il progetto deve essere realizzato dal principio, senza potersi basare su software già utilizzato e testato. Questo causa una maggiore quantità di errori, sia di codifica che di progettazione in quanto manca una struttura solida preesistente;
• Gli strumenti utilizzati per lo sviluppo sono nuovi e mai uti- lizzati in precedenza, pertanto con l’avanzare della fase di co- difica verranno sicuramente scoperte nuove procedure o con- venzioni per risolvere un particolare problema, oppure emer- gerà un bisogno che si credeva soddisfatto da un’automazio- ne del framework che renderà necessarie modifiche nel codice precedentemente scritto.
Non è stato imposto un limite alle possibili iterazioni eseguibili nel ciclo di vita perché sarebbe stato un numero arbitrario privo di basi ragionevoli (per esempio, è impossibile predeterminare quanti meto- di in una classe sarà necessario codificare in quanto uno strumento del framework non fornisce il risultato adeguato, contrariamente a quanto previsto). Inoltre tali situazioni difficilmente saranno legate a questioni progettuali di alto livello ma piuttosto iterazioni triviali a livello di struttura delle classi e metodi interni quindi difficilmente reiterabili all’infinito.
Per la seconda parte, lo sviluppo dell’applicazione Android, è sta- to scelto un ciclo di vita incrementale. In questo caso, gli strumenti a disposizione mi erano già noti in maniera approfondita e pertanto non ci sarebbero stati i problemi indviduati per la prima parte del
35
progetto. Inoltre uno dei vincoli del progetto era di avere un unico server centrale, sia per la parte web che per la parte Android: per questo, una volta sviluppata e funzionante la parte web, non sareb- be più stato possibile rimuovere parti di codice già scritto, per non rischiare così di invalidare il lavoro già svolto.
4.1 i l pat t e r n m v c i n c a k e p h p
Il framework utilizzato per la realizzazione della parte web di que- sto progetto, CakePHP, si basa ampiamente sul pattern architetturale MVC. In questo pattern è presente una netta divisione fra le varie componenti dell’applicazione, separando i componenti a seconda se si occupano di gestire i dati, la logica propria dell’applicazione o la visualizzazione dei risultati ottenuti.
Gli oggetti di tipo Model rappresentano il collegamento con la base di dati sottostante al progetto. Essi si devono occupare di tutte quelle operazioni relative ai dati: ricerca, salvataggio e cancellazione, valida- zione ed in generale, la loro evoluzione nel tempo. Nell’implementa- zione data in CakePHP, essi solitamente rappresentano una singola tabella della base di dati. In un Model è possibile indicare quali sono le associazioni esistenti con gli altri modelli dell’applicazione, in mo- do da consentire al core del framework di navigare automaticamente la base di dati, estraendo tutte le informazioni collegate al modello cercato.
Gli oggetti di tipo View sono responsabili di generare l’output otte- nuto in seguito ad una particolare richiesta dell’utente. L’output gene- rato può essere di qualsiasi tipo, non solo XHTML: in questo progetto alcune viste forniscono output in formato JSON. Per convenzione, i fi- le di tipo vista sono scritti in linguaggio PHP e hanno estensione .ctp (CakePHP template), devono trovarsi all’interno della cartella nomi- nata allo stesso modo del controller al quale sono associate ed avere lo stesso nome dell’azione alla quale sono legate (per esempio, la vi- sta relativa all’azione print del controller UsersController sarà in
[...]/View/Users/print.ctp).
Gli oggetti di tipo Controller sono responsabili di interpretare le richieste dell’utente, utilizzando i modelli appropriati per la richiesta e di fornire in risposta la vista più appropriata. In CakePHP i control- ler utilizzano solitamente un solo modello, infatti per convenzione il controller prende il nome dal modello primario che utilizzano per elaborare le risposte. Ogni controller possiede uno o più metodi defi- niti azioni che rappresentano le varie funzionalità offerte dall’oggetto.
Di default tutte le azioni sono pubbliche ed accessibili attraverso un URL, gestito dal router dell’applicazione.
Siccome l’applicazione dovrà funzionare su un server web, che comunica utilizzando il protocollo HTTP, è necessario aggiungere al- l’applicazione un meccanismo apposito per individuare qual’è il con- troller da richiamare e qual’è l’azione da invocare utilizzando esclusi- vamente un URL. Questa funzionalità è chiamata Routing ed è fornita automaticamente da CakePHP.
Il meccanismo di routing di CakePHP è gestito dal Dispatcher inter- no che, sfruttando le convenzioni predefinite del framework, traduce l’URL ricevuto in una richiesta, attivando il controller corretto e pas- sandogli i parametri ricevuti. Per esempio, l’URL
http://example.com/users/search/param1/param2/param3
causerà l’attivazione del controllerUsersController, dal quale verrà richiamato il metodo search(param1, param2, param3)
L’aggiunta di questo Dispatcher all’interno dell’architettura causa una piccola variante al pattern standard, nel quale i comandi non ar- rivano più direttamente dalle View ma vengono rielaborati dal server web e dal Dispatcher stesso.
4.2 p r o g e t ta z i o n e b a s e d i d at i
4.2.1 Progettazione concettuale
La prima fase di progettazione di una base di dati è la progettazio- ne concettuale. In questa fase vengono raccolte tutte le informazioni della realtà da modellare relative a vari aspetti delle conoscenze a disposizione:
• Conoscenza concreta: i fatti, gli elementi reali che devono essere modellati;
• Conoscenza astratta: i vincoli e la struttura propria della cono- scenza concreta;
• Conoscenza procedurale: le operazioni svolte dagli utilizzatori dal sistema, le interazioni tra gli elementi modellati e il resto del sistema
• Comunicazioni: definire i metodi con cui si comunicherà con il sistema.
In seguito alla raccolta delle informazioni e all’intervista effettuata al responsabile aziendale, sono state indivuate le seguenti famiglie di entità da modellare ed inserire nel sistema informativo:
• Risorse: Le entità incluse in questa famiglia rappresentano tut- ti gli elementi concreti in possesso all’azienda. Una risorsa, in
questo contesto, rappresenta solamente un bene reale e non virtuale.
• Utenti: Gli utenti rappresentano tutti gli utilizzatori del sistema e, in maniera più ampia, tutti i possibili utilizzatori delle risorse.
Tra gli utenti sono inclusi anche gli amministratori del sistema.
In questa famiglia sono inclusi anche i rapporti sulle consegne effettuate e sulle segnalazioni di guasto.
• Software: Le entità appartenenti a questa famiglia modellano un’applicazione in uso nell’azienda o un’insieme di esse.
• Licenze: Le licenze possono essere di due tipologie diverse ossia licenze hardware, relative a risorse, o licenze software, relative a programmi. Le licenze sono intese come vincoli all’utilizzo simultaneo di più risorse o software di un determinato tipo.
• Networking: Le entità di tipo Networking rappresentano tutti quegli elementi in grado di connettersi alla rete aziendale e con- tengono tutte le informazioni relative ai loro parametri e al loro funzionamento.
Una volta delineate le famiglie di entità che comporranno il si- stema informativo, sono state definite tutte le entità proprie delle varie famiglie, esplicitando tutte le gerarchie tra classi presenti. Du- rante questa fase sono emerse numerosi casi di ereditarietà multi- ple che hanno richiesto una particolare attenzione durante la fase di progettazione logica.
Tutti i casi di ereditarietà multipla sono contenuti nella famiglia delle risorse. Su richiesta dell’azienda, sono stati individuati sei tipi di risorse distinti (telefoni, tablet, computer, stampanti, switch e server), ognuno dei quali ha diversi vincoli sulle relazioni con il resto del sistema. I vincoli individuati sono:
• Consegnabilità: Solamente telefoni, tablet e computer possono essere assegnati ad un utente;
• Connettività: Solamente computer, server, switch e stampanti possono connettersi alla rete cablata aziendale.
• Installazione di software: Solamente tablet, server e computer possono contenere installazioni di software.
Per realizzare questi vincoli in maniera affidabile all’interno del- la base di dati, tutte le relazioni tra un’entità esterna alla famiglia e una risorsa passano attraverso una delle tre superclassi elencate pre- cedentemente. Questa scelta permette una migliore coerenza dei dati inseriti anche se causa un’aumento considerevole della complessità
finale della base di dati. La scelta era tra rendere più complessa l’ap- plicazione, prevedendo meccanismi di controllo appositi in fase di creazione di nuove risorse oppure rendere più complessa la base di dati, senza però dover richiedere meccanismi di controllo particolari all’applicazione.
Siccome ho già visto di persona gli effetti che causa il presume- re che la base di dati verrà utilizzata solo ed esclusivamente dalla propria applicazione, ho preferito rendere la base di dati più solida, anche se più complessa e meno intuitiva, così da dipendere il meno possibile dall’applicazione che ne fa uso per garantirne la coerenza interna.
Figura 21: Schema concettuale del database
4.2.2 Progettazione logica
Durante la fase di progettazione logica della base di dati si trasfor- ma il modello concettuale ad oggetti sviluppato nella fase precedente nel modello logico della base di dati. Il modello logico contiene le definizioni delle tabelle, ottenute trasformando tutte le entità definite insieme alle loro relazioni in maniera opportuna.
A seconda delle tipologie di relazioni definite che coinvolgono una particolare entità, la trasformazione avviene come segue:
• Relazione 1-1 (univoca con inversa univoca): La chiave primaria di una delle due entità viene inclusa nell’insieme degli attri- buti dell’altra come chiave esterna, con vincolo di unicità. Se possibile, si fa in modo che la relazione così ottenuta risulti totale;
• Relazione 1-N (univoca): La chiave primaria della tabella prin- cipale (la tabella dal lato 1 della relazione) viene inclusa nell’in- sieme degli attributi dell’altra come chiave esterna.
• Relazione N-M (multivalore con inversa multivalore): Viene crea- ta una tabella con attributi contenenti gli eventuali attributi del- la relazione più le chiavi primarie di entrambe le tabelle, come chiavi esterne. La chiave primaria della nuova tabella contiene almeno entrambe le chiavi esterne.
Particolare attenzione deve essere posta durante la trasformazione delle gerarchie individuate durante la progettazione concettuale. A seconda del tipo di relazioni che coinvolgono la classe padre e le classi figlie, è possibile utilizzare un diverso tipo di trasformazione. In questo caso l’unica soluzione possibile è utilizzare il partizionamento verticale, distinguendo separatamente tutte le tabelle relative ad un tipo particolare di risorsa, perché sono presenti relazioni sia con le superclassi che con le classi figlie.
Questa scelta ha causato un notevole aumento del numero di ta- belle presenti nel database, e di conseguenza del numero di classi nell’applicazione web, però permette di modellare al meglio i vincoli individuati a livello concettuale. Le tabelle non hanno attributi pro- pri ma sono semplicemente un elenco di chiavi. Ogni risorsa appar- tenente a quel determinato tipo avrà tale chiave tra i propri attributi, come chiave esterna, e verrà usata come riferimento per tutte quelle relazioni che coinvolgevano la superclasse.
L’utilizzo di questa tecnica non traduce perfettamente il model- lo concettuale, in quanto sono necessari ulteriori meccanismi di con- trollo in fase di creazione e cancellazione dei record. Tutta questa
complessità si sarebbe potuta evitare se si fosse utilizzata una base di dati più evoluta rispetto a MySQL, come ad esempio PostgreSQL, che preveda strumenti più avanzati per la gestione dell’ereditarietà tra tabelle.
4.2.3 Sicurezza delle password utente
Le password d’accesso al sistema di tutti gli utenti sono memoriz- zate all’interno della tabellausers. Durante la creazione di un nuovo utente, prima dell’inserimento del record associato all’interno della tabella, viene generata una stringa completamente casuale di lunghez- za pari a 40 caratteri: questa stringa, chiamata sale, viene concatena- ta alla password dell’utente, memorizzata nel database, ed utilizzata come parametro per la funzione di hashing SHA-256.
In questo modo non viene memorizzata la password crittografata direttamente, rendendo più complessi eventuali attacchi a dizionario.
Per incrementare ulteriormente la sicurezza di questo approccio, è consigliato immagazzinare in un diverso database l’elenco dei sali utilizzati, in modo che anche nel caso di compromissione della ta- bella contenente l’hash delle password risulti difficoltoso ottenere le password originali.
4.3 p r o g e t ta z i o n e s i t o w e b
La progettazione del sito web è suddivisa in due iterazioni prin- cipali. Nella prima vengono delineate la maggior parte delle fun- zionalità, in modo che sia possibile utilizzare il prodotto ottenuto dalla realizzazione di questa parte in modo completo attraverso un browser web, anche mobile. Nella seconda parte vengono proget- tati i componenti necessari allo scambio di dati con l’applicazione Android.
4.3.1 Struttura
I componenti sviluppati per l’applicazione web sono suddivisi in tre package distinti secondo il pattern Model - View - Controller.
Model
Contiene tutti i file PHP contenenti le classe adibite alla gestione dei dati dell’applicazione. Le classi definite in questo package hanno una struttura interna comune: nella prima parte vengono definiti gli attributi propri della classe, indicando tutti gli altri Model collegati
Figura 22: Schema logico del database, generato da MySQL Workbench
ad essa, i criteri per la validazione dei dati e gli eventuali parame- tri propri che non seguono le convenzioni prescritte dal framework (come per esempio l’utilizzo di una chiave primaria diversa daid).
Nella seconda parte vengono definiti i metodi propri del model- lo, ossia eventuali funzioni per la gestione dei dati, nel caso che gli strumenti forniti dal framework si rivelino insufficienti. Solitamente questa parte è lasciata vuota, in quanto i meccanismi di automazione di CakePHP sono sufficienti per la maggior parte delle necessità di sviluppo.
Controller
Contiene tutti i file PHP che si occupano di gestire le richieste del- l’utente e di fornire le viste appropriate a seconda del tipo di richie- sta. Al loro interno sono inserite tutte le azioni messe a disposizione dell’utente. Il framework dà la possibilità di indicare quali Modelli vengono utilizzati da questo Controller, nel caso ve ne fosse più di uno, di quali helpers ha bisogno il controller per generare le viste (ad esempio la creazione di form HTML) e quali components vengono uti- lizzati per facilitare il lavoro (un component fornisce un servizio al controller, come per esempio la gestione della sessione e dei cookies) View
I file contenuti in questo package rappresentano tutte le viste mes- se a disposizione dell’utente. Solitamente sono scritte in PHP e HTML, utilizzando eventualmente le funzioni messe a disposizione dagli hel- pers appartenenti al controller che ha richiamato la vista in questione.
Le viste vanno suddivise in cartelle all’interno del package. Ogni cartella deve essere nominata esattamente come il controller che la utilizza ed il file deve essere nominato come l’azione dalla quale viene invocata.
4.3.2 Prima fase
I primi componenti progettati sono stati i Model, su cui si basa l’applicazione. Tutte le tabelle definite all’interno del database devo- no avere un oggetto Model che le rappresenta e ne determina le regole d’accesso. Sono state definite tutte le relazioni esistenti tra le tabelle e codificate secondo le convenzioni di CakePHP: hasOne per le rela- zioni 1-1, hasMany per le relazioni 1-N dal punto di vista della tabella senza la chiave esterna dell’associazione, belongsTo per le relazioni in cui la tabella ha la chiave esterna, ossia il viceversa delle due categorie precedenti. È presente anche una convenzione per le relazioni molti a molti e permette di non definire un Model proprio per quelle tabelle prive di attributi propri ottenute dalla traduzione dello schema con- cettuale, chiamata hasAndBelongsToMany (HABTM), che non è stata utilizzata in quanto anche le tabelle generate durante la traduzione dello schema al posto delle relazioni N-M hanno un Model proprio
e quindi utilizzano vari hasMany per realizzare la stessa funzionali- tà. Questa scelta è necessaria in quanto il meccanismo automatizzato per le relazioni HABTM è distruttivo e causa la perdita di eventuali informazioni aggiuntive relative alla relazione stessa, come eventuali altri campi oltre alle due chiavi esterne.
Sono stati definiti inoltre tutti i parametri di validità per l’inse- rimento dei dati all’interno delle tabelle controllate dai Model. È possibile utilizzare i numerosi parametri forniti dal framework oppu- re definirne di propri utilizzando combinazioni di quelli già forniti, operatori logici ed espressioni regolari.
Una volta determinati i Model, sono state definite le azioni che è possibile effettuare sui dati. Le varie azioni sono state poi raggrup- pate in base al Model cui si riferivano, in un singolo controller: per esempio, le azioni di view, create, edit, delete, index che opera- no sul Model User vengono raggruppate all’interno del controller
UsersController.
Per ogni azione definita è poi necessario progettare la vista as- sociata. Essenzialmente nel progetto sono utilizzati due tipologie di View: la vista per compilazione di form e la vista per l’output di dati a video. Il primo tipo richiede che il controller utilizzi l’helper Form- Helper mentre la seconda non ha necessità particolari oltre all’helper HtmlHelper, comune a tutte le viste che producono pagine web di base.
Creazione nuova risorsa
L’azione di creazione di una nuova risorsa si compone di 4 fasi distinte, ciascuna raggiungibile solamente se la risorsa in creazione è di un tipo che soddisfa tutti i requisiti lungo i vari passaggi. Esistono tre tipi distinti di risorse:
• risorse di base, ossia risorse di ognuno dei sei tipi predefiniti dal sistema, ad esempio “Telefono”. Ogni tipologia possiede delle informazioni specifiche legate al tipo;
• risorse di base con entità collegate, ossia quelle risorse di base che sono composte da più parti, come un dispositivo “Mobile”
che può utilizzare una scheda SIM;
• risorse definite dall’utente, ossia tipologie di risorse aggiunte nel sistema in un secondo momento. Non hanno informazioni spe- cifiche ma solamente quelle generiche, comuni a tutte le risorse.
La procedura di creazione di una risorsa è rappresentata dal se- guente diagramma di attività:
Figura 23: Diagramma di attività per la creazione di una risorsa
4.3.3 Seconda fase
La comunicazione tra il server web e l’applicazione android avvie- ne utilizzando i comandi GET e POST del protocollo HTTP per tutte le richieste provenienti dal dispositivo mobile, mentre le risposte ven- gono trasferite codificate nel formato JSON. Per abilitare la gestione dell’output nel formato JSON richiesto, in base al tipo di URL utiliz- zato, deve essere abilitata la gestione delle estensioni all’interno della classe Router, utilizzando la funzioneparseExtensions
Listing 2: Configurazione della classe Router per la gestione di JSON Router::parseExtensions(’ json ’);
Inoltre, all’interno di ogni controller che dovrà gestire le risposte in formato JSON, dovrà essere aggiunto all’elenco dei component uti- lizzati ancheRequestHandlerComponent. Questo componente permet- te di serializzare l’output nel formato corretto se la risposta non è generata in HTML standard.
4.4 p r o g e t ta z i o n e a p p l i c a z i o n e a n d r o i d
Un’applicazione Android è composta da due tipi di file. Il primo tipo è rappresentato dai file Java, che contengono la logica operativa dell’applicazione, mentre il secondo tipo contiene tutti i file XML di supporto. Tali file possono contenere risorse testuali, come ad esem- pio tutte le stringhe in una determinata lingua che verranno usate dal- l’applicazione, oppure definiscono il layout grafico utilizzabile da una o piùActivitydurante l’uso dell’applicazione da parte dell’utente.
L’applicazione sviluppata deve fornire un sottoinsieme delle fun- zionalità che fornisce il sito completo, ossia tutte quelle funzioni che plausibilmente vengono utilizzate durante spostamenti in azienda o comunque quando non si è presenti alla postazione di lavoro co- munemente utilizzata. Le funzioni inserite nell’applicazione mobile sono:
• Lettura delle segnalazioni di guasto, necessaria per leggere qua- li sono i guasti comunicati dagli utenti durante l’operazione di manutenzione;
• Visione del contenuto dei magazzini e spostamento delle ri- sorse tra magazzini, per mantenere sotto controllo eventuali spostamenti di risorse tra un luogo ed un altro;
• Installazione di software su una risorsa compatibile.
Inoltre è presente un collegamento al portale web nel caso siano necessarie altre funzionalità non presenti nella versione mobile.
L’uso dell’applicazione mobile è consentito solamente all’ammini- stratore. L’autenticazione non avviene tramite l’inserimento di nome utente e password ma è basata sull’identificazione del device fisico, tablet o telefono, sul quale viene eseguita l’applicazione. Combinan- do vari parametri costanti dello strumento, come l’indirizzo MAC o il numero seriale dell’installazione android viene generato un UUID che è confrontato con l’elenco dei dispositivi conosciuti ed autoriz- zati dall’azienda ad eseguire l’applicazione. In caso affermativo l’u- tente è automaticamente trasferito alla pagina principale altrimenti l’applicazione viene chiusa.
Vista la relativa semplicità dell’applicazione mobile, non è stato utilizzato nessun pattern architetturale particolare in quanto l’aumen- to di complessità generato dal pattern non sarebbe stato compatibile con l’effettivo vantaggio di utilizzo che avrebbe portato.
Sono stati sviluppati due categorie principali di Activity. La pri- ma, NavigationActivity, si occupa solamente di scaricare dati dal
server web e visualizzarli per l’utente, la secondaFormActivityinve- ce possiede funzionalità per l’invio di dati che verranno poi salvati nel database.
D’interesse è la gestione delle sessioni, in quanto è necessario te- nerne traccia per memorizzare l’autenticazione attraverso le varie Ac- tivity, analoghe a pagine web distinte. Se si effettuasse una nuova con- nessione ad ogni richiesta, sarebbe impossibile mantenere un’unica sessione con il server Apache. Per questo è necessario avere la garan- zia di riutilizzare ogni volta lo stesso oggetto usato nella connessione precedente: la garanzia viene preservata grazie all’utilizzo del pat- tern Singleton per ottenere sempre la stessa istanza della connessione, rendendo utilizzabile la sessione.
