Corso di Laurea in Informatica - Università degli studi ...

Università degli Studi di Padova

Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea in Informatica

Sviluppo di un Framework e servizi per lo scambio diinformazioni tramite tecnologia sms

Laureando Relatore

Alberto Rossato Prof. Alessandro Sperduti

Anno Accademico 2011/2012

2 di 97

Sommario

La presente tesi di laurea è la relazione finale relativa allo stage da me svolto nel corsodella Laurea Triennale in Informatica.Lo stage si è tenuto presso l’azienda Telerete Nordest che ha sede a Padova Via Salboro22/b. La scelta dell’azienda è avvenuta attraverso l’iniziativa Stage-IT, punto di incontrotra laureandi e aziende, sotto la supervisione dell’Università di Padova.Il lavoro in azienda ha avuto la durata di 8 settimane, dal 13 settembre 2011 al 04novembre 2011, per un totale di 302 ore lavorative, su un minimo di 300 ore ed unmassimo di 320 ore. I contenuti della tesi si svilupperanno in 9 capitoli.

Capitolo 1 Introduzione generale sull’azienda ospitante e sul progetto da essa offerto.

Capitolo 2 Elenco di tutte le tecnologie/strumenti utilizzati per il completamento delprogetto.

Capitolo 3 Pianificazione delle varie attività con divisione settimanale.

Capitolo 4 Descrizione della fase di analisi.

Capitolo 5 Descrizione della fase di progettazione.

Capitolo 6 Descrizione della fase di implementazione.

Capitolo 7 Descrizione dei test eseguiti sul prodotto e della fase di collaudo.

Capitolo 8 Sviluppi futuri che potrà avere il prodotto.

Capitolo 9 Alcune riflessioni personali sull’attività di stage e sul percorso universitario.

3

4 di 97

Indice

1 Introduzione 71.1 Riflessione generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Ideazione progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Collocazione all’interno dell’azienda . . . . . . . . . . . . . . . . . . . . . . 91.5 Evoluzione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Strumenti e linguaggi utilizzati 112.1 Linguaggi utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Strumenti per lo sviluppo software . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Eclipse IDE for Java Developers . . . . . . . . . . . . . . . . . . . 122.2.2 Joomla! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Librerie Esterne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1 Framework Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Server utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Tomcat 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Apache ActiveMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Software di controllo e sviluppo di progetto . . . . . . . . . . . . . . . . . 162.6 Strumenti per stesura documenti e diagrammi . . . . . . . . . . . . . . . . 17

2.6.1 Software Editore LATEXper documenti di testo . . . . . . . . . . . . 172.6.2 Software Diagrammi UML . . . . . . . . . . . . . . . . . . . . . . . 172.6.3 Software di pianificazione . . . . . . . . . . . . . . . . . . . . . . . 17

3 Piano di lavoro preventivo 193.1 Dettaglio ore preventivate . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Piano settimanale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Analisi 234.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Servizio campagne sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1 Contesto d’uso del prodotto . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Funzioni del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.3 Diagrammi Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.4 Tabelle dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Progettazione 335.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.1 Design Pattern Utilizzati . . . . . . . . . . . . . . . . . . . . . . . . 33

5

5.2.2 Identificazione dei componenti architetturali di alto livello . . . . . 355.2.3 Descrizione dei singoli componenti . . . . . . . . . . . . . . . . . . 355.2.4 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.5 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Modifiche al software esistente SMSTelerete . . . . . . . . . . . . . . . . 395.3.1 Panoramica generale software compravendita titoli di viaggi . . . . 395.3.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.3 Modifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Servizio Campagne Sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.1 Struttura portale e mockups . . . . . . . . . . . . . . . . . . . . . . 435.4.2 Struttura database . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 Implementazione 496.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Implementazione Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2.1 API Vodafone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2.2 API Aimon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.3 Implementazione in linguaggio Java . . . . . . . . . . . . . . . . . . 52

6.3 Dettaglio modifiche apportate al softwareSMSTelerete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3.1 Code JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3.2 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.3.3 Modifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4 Servizio Campagne Sms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4.1 Funzionalità prodotto . . . . . . . . . . . . . . . . . . . . . . . . . 666.4.2 Requisiti di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4.3 Joomla! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4.4 Operazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Test e collaudo finale 777.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1.1 Test di Unità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.1.2 Test di Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . 787.1.3 Test di Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.1.4 Collaudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 Sviluppi futuri 83

9 Conclusioni 859.1 Conseguimento degli obiettivi prefissati . . . . . . . . . . . . . . . . . . . . 859.2 Conoscenze acquisite tramite l’attività di stage . . . . . . . . . . . . . . . 859.3 Conoscenze acquisite tramite il percorso universitario . . . . . . . . . . . . 859.4 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.4.1 Attività realizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.4.2 Differenze con il preventivo . . . . . . . . . . . . . . . . . . . . . . 88

A Prodotti ottenuti 89

B Valutazione strumenti utilizzati 91

Glossario 91

Bibliografia 97

6 di 97

Capitolo 1

Introduzione

1.1 Riflessione generale

Esistono oggi diverse possibilità per poter comunicare a distanza.Tra queste, per importanza e per numero di utilizzi, troviamo al primo posto la tecnologiaSMS.Il termine SMS (acronimo dell’inglese Short Message Service, servizio messaggi brevi)

è comunemente usato per indicare un breve messaggio di testo inviato da un dispositivocellulare ad un altro. Il servizio è stato originariamente sviluppato sulla rete GSM,tuttavia è ora disponibile anche su altre reti, come la UMTS ed alcune reti fisse. Èpossibile inviare SMS ad un telefono cellulare anche da un computer, tramite Internet, edal telefono di rete fissa. Tra i principali vantaggi percepiti dell’SMS, che hanno condottoalla straordinaria diffusione di questo servizio come sistema di comunicazione, ci sono ilbasso costo rispetto ad una lunga telefonata e la possibilità di rendere la comunicazioneasincrona, cioè di leggere il messaggio in un qualsiasi momento successivo alla ricezione.

1.2 Ideazione progetto

In riferimento alle precedenti considerazioni si è deciso di sviluppare unFramework per l’invio,ricezione ed elaborazione di informazioni tramite tecnologia SMSe di utilizzarlo per implementare alcuni servizi dotandoli di tale tecnologia.

Un servizio già attivo nell’azienda ospitante è la compravendita di biglietti tramitel’invio di sms per usufruire dei mezzi di trasporto offerti dalla società dei trasporti pub-blici di Padova APS Holding. Tale servizio, in sintesi, permette all’utente registratodi inviare un sms ad un numero telefonico ben definito con il quale richiedere l’acquistodi un biglietto. Ricevuta la richiesta il sistema si occupa di inoltrarla alla società de-legata ad effettuare le varie transazioni bancarie per conto dell’utente. Essa in seguitoinvierà al sistema una notifica di pagamento effettuato. Infine l’utente riceverà un smscontenente il codice che identifica il biglietto appena acquistato. Il controllore di serviziodella società di trasporti potrà verificare tramite tale codice la validità del biglietto inquestione.L’azienda è in grado di effettuare le operazioni di invio e ricezione sms appoggiandosi,nella situazione attuale, solamente ad un unico operatore, Vodafone1. Questo peròimplica il non poter garantire il servizio di compravendita biglietti in caso di guasto daparte dell’operatore telefonico in questione. Inoltre, in caso di incremento delle tariffeofferte da esso, l’azienda non dispone di un’ alternativa piú conveniente.

1http://www.vodafone.it

http://www.vodafone.it

Con lo svolgimento dello stage offerto, l’azienda desidera raggiungere alcuni obiettiviben definiti. Il primo e piú importante consiste nell’aggiungere da subito la possibilitàmanuale di erogazione del servizio di compravendita biglietti utilizzando un providertelefonico sostitutivo a Vodafone. La scelta, da parte dell’azienda stessa per questioni difamiliarità con il servizio, è ricaduta sul provider Aimon2 il quale offre un servizio diinvio/ricezione sms a costi contenuti e delle Api per interfacciarsi ai propri server.Un secondo obiettivo consiste nella possibilità di affiancare nuovi servizi a quelli giàesistenti (compravendita biglietti), utilizzando le risorse disponibili (il software già svi-luppato dall’azienda).La scelta, anche in questo caso presa dall’azienda, su quale servizio sviluppare per primoè caduta sulla creazione tramite portale di campagne sms aziendali oppure di sempliciinvii singoli/multipli di messaggi, per poter contattare velocemente i propri dipendentio colleghi aziendali. Si tratta di apportare alcune modifiche al software già presente inazienda per renderlo in grado di gestire le richieste di invio sms anche da parte del nuovoservizio “Campagne Sms” e non solo quelle riguardanti la compravendita di titoli diviaggio.Negli sviluppi futuri l’obiettivo finale consiste dunque nel realizzare una vasta varietàdi servizi di cui l’azienda è proprietaria e che sfrutteranno la comunicazione sms offertadal Framework. Esso disporrà di un contratto con ogni gestore telefonico nazionale esarà in grado di riconoscere in modo automatico e non manuale il gestore telefonico diappartenenza dei destinatari dei messaggi, sms in modo da sfruttare le offerte tariffarieofferte da ognuno. Infatti, illustrando un esempio, il costo di comunicazione tra il serverVodafone ed un numero telefonico destinatario Vodafone, poiché comunicano utilizzandola stessa rete, è minore rispetto la comunicazione tra il server Vodafone e quello di undiverso gestore telefonico come ad esempio Tim3 che utilizzano reti diverse.

1.3 L’azienda

Ne-t by Telerete Nordest srl è una società di servizio nelle telecomunicazioni e nell’ICTche ha lo scopo di aiutare l’adozione e l’impiego delle nuove tecnologie per rendere lecittà sicure e a misura d’uomo. La sua azione si esplica in attività di progettazione,realizzazione ed esercizio di sistemi per la sicurezza e sorveglianza, la connettività el’accesso ai servizi pubblici e privati, con specifica attenzione al cittadino e agli entidedicati al suo servizio.I servizi offerti spaziano in diversi campi delle tecnologie per la città digitale:

• Gestione della MAN cittadina in fibra e wireless, pluriconnettività, satcom, ser-ver farm, security e disaster recovery, postazioni cellulari GSM, UMTS, DVHB,videosorveglianza

• Progettazione e integrazione di tecnologie per la mobilità (AVM tram, ZTL)

• Call center e Web Call Center, IVR e servizi di prenotazione monumenti e mani-festazioni

• Portali e applicazioni informatiche di supporto all’E-Government e per le aziende

• Fornitura hardware di supporto

2http://www.aimon.it/3http://www.tim.it/

8 di 97

http://www.aimon.it/

http://www.tim.it/

Telerete Nordest applica il principio del System Integration e ha quindi le competenzenella gestione di progetti complessi che sono indispensabili per realizzare sistemi completidi:

• Networking

• Connettività

• Servizi di web call/contact center

• E-service

• Info-mobilità

• Domotica

• E-government

• Integrazione di applicazioni.

Ne-t fornisce inoltre servizi di consulenza per ottimizzare i processi organizzativi eservizi a supporto dell’intero ciclo di vita della soluzione. Con una struttura di oltre 60collaboratori, è in grado di assicurare assistenza post-vendita e servizi di manutenzioneai clienti in modalità 24hx365.

1.4 Collocazione all’interno dell’azienda

Il progetto è stato collocato all’interno dell’area di sviluppo software dell’azienda deno-minandolo Net Sms Gateway.Al mio arrivo ho iniziato a collaborare direttamente con il tutor aziendale assegnatomi.Abbiamo concordato assieme gli obiettivi da raggiungere e le risorse di cui avrei avutobisogno. L’avanzamento del progetto è stato monitorato passo dopo passo da lui cheinoltre mi ha indicato nuove funzionalità da implementare.

1.5 Evoluzione del progetto

In azienda per poter svolgere le mie attività mi è stata assegnata un postazione dotatadi pc da utilizzare per tutta la durata della mia permanenza. Dopo aver riconfermatocon il tutor gli obiettivi da raggiungere ho iniziato a seguire il piano di lavoro redatto inprecedenza. La parte iniziale è consistita nell’analizzare i prodotto software già esistentein azienda. Questo ha comportato una mia formazione personale su molte tecnologieprima mai viste. Successivamente c’è stata una fase di analisi dei requisiti che avrebbeavuto avere il prodotto ultimato e quindi una sua progettazione iniziale. Con l’aiuto delmio responsabile, dopo aver affinato la parte di progettazione sono passato alla fase diimplementazione, aggiungendo anche funzionalità prima non ideate. La fase conclusivaè stata quella di test e di collaudo del prodotto.

9 di 97

10 di 97

Capitolo 2

Strumenti e linguaggi utilizzati

2.1 Linguaggi utilizzati

Per la scelta degli strumenti e dei linguaggi da utilizzare, là dove mi è stata data lapossibilità di scelta mi sono basato sulle esperienze positive già da me fatte; negli altricasi mi sono attenuto ai vincoli fissati dall’azienda. Per lo sviluppo del Framework di in-vio/ricezione sms si è scelto di utilizzare il linguaggio Java con l’ausilio del FrameworkSpring - Hibernate. Tale decisione è stata presa sotto consiglio dell’azienda poiché ilsoftware già esistente in essa per la compravendita di titoli di viaggio utilizzava questetecnologie ed inoltre per acquisire le competenze per poterlo modificare. Inoltre le fun-zionalità offerte dal linguaggio, nello specifico l’utilizzo in parallelo di flussi di esecuzionediversi, garantiscono una solida gestione delle operazioni di invio/ricezione sms. Nonsono state prese quindi in considerazione altre soluzioni.Per il suo impiego concreto in eventuali servizi futuri e per le modifiche da appor-tare al software per la compravendita di biglietti si sono utilizzate le Servlet e leJava Server Pages (JSP) offerte da specifici moduli del Framework. I motivi perpreferire tale tecnologia piuttosto di altre alternative come PHP oppure ASP sono:

• Efficienza: Il modello di esecuzione delle servlet è più efficiente rispetto a quello diuna applicazione CGI. Nel modello CGI viene infatti creato un nuovo processo perogni richiesta da esaudire mentre nel caso delle servlet ad ogni richiesta corrispondela creazione di un thread, operazione molto meno onerosa per il server.

• Robustezza: Un aspetto importante delle servlet è la robustezza. Il codice Javagira all’interno della Virtual Machine che è un elemento isolante rispetto al sistemaoperativo. Eventuali errori di programmazione non possono creare malfunziona-menti tali da danneggiare il corretto funzionamento del web server. Inoltre le servletsono immuni dagli attacchi dei pirati informatici in quanto la Virtual Machine e ilClass Loader si occupano di isolare e verificare il codice che viene eseguito.

• Scalabilità: L’architettura delle servlet consente in modo piuttosto naturale diintrodurre tecniche di bilanciamento del carico (load balancing) suddividendolotra più server.

• Potenza: La persistenza di una servlet su più richieste (una servlet rimane in me-moria fino a quando non viene terminata) consente di condividere facilmente infor-mazioni tra i thread corrispondenti e di sincronizzare le richieste; questo semplificanotevolmente, ad esempio, la realizzazione di applicazioni di tipo collaborativo.

• Accesso alle API standard: Basandosi sulla piattaforma Java, le servlet possonoaccedere ad un ampio ventaglio di API quali JDBC (Java Database Connectivity)

11

per l’accesso ai database relazionali, JAXP (Java API for XML Processing) chepermette di trattare con documenti XML, JCA (Java2EE Connection Architecture)che consente l’integrazione di applicazioni esistenti, ecc.

• Libreria di base: Il codice di implementazione delle servlet può fare affidamen-to su un ampia gamma di funzioni presenti nella libreria di base di Java e nellesue estensioni, che è estremamente completa (supera di diverse lunghezze quelledisponibili in PHP o ASP). Questo aspetto può comportare un netto risparmio deltempo di sviluppo, in quanto molte funzionalità non devono essere implementatema possono essere semplicemente riutilizzate.

• Gestione delle sessioni: http è per sua natura un protocollo stateless. Per ilserver ciascuna richiesta è svincolata dalla precedente; con il solo http non si èquindi in grado di determinare se più richieste sono legate ad uno stesso utente.Le servlet, invece, offrono una gestione integrata delle sessioni utente in grado diindicare se una richiesta è stata inoltrata ad un utente già attivo.

Per quanto riguardo lo sviluppo del servizio di “Campagne Sms” si è deciso di utilizzareil linguaggio PHP e il CMS Joomla1. Tale utilizzo è stato vincolato dall’azienda inmodo che in futuro, nel caso il progetto venga sviluppato ulteriormente da terzi, siasemplice apportare nuove modifiche. La comunicazione tra il Framework sviluppato inlinguaggio Java ed il portale campagne sms sviluppato in linguaggio PHP avviene tramiteJMS (Java Message Service) poiché il software per la compravendita di titoli di viaggioimplementa già tale soluzione. In sostanza JMS è un insieme di API che consentono loscambio di messaggi tra applicazoni distribuite nella rete e fornisce un metodo standardtramite il quale le applicazioni possono creare, inviare e ricevere i messaggi.Tenendo conto di ciò non sono state prese in considerazione soluzioni di altro genere.Inoltre le motivazioni principali per utilizzare tale tecnologia sono:

• Asincronicità della comunicazione: il provider JMS consegna i messaggi al clientappena quest’ ultimo si è reso disponibile. Il provider li consegna senza che ilreceiver abbia effettuato una richiesta specifica.

• Affidabilità della comunicazione: JMS può assicurare che un messaggio sia con-segnato una ed una sola volta.

• Qualità del servizio configurabile: le API JMS prevedono differenti livelli diaffidabilità per considerare molteplici scenari applicativi.

• Robustezza ai cambiamenti: sono presenti tipologie differenti di messaggi e fea-tures personalizzabili.

2.2 Strumenti per lo sviluppo software

2.2.1 Eclipse IDE for Java Developers

L’utilizzo di tale strumento e dei relativi plugin è stato indicato dall’azienda. Inoltre talescelta è stata condivisa da parte mia a fronte di esperienze passate positive con esso.

1http://www.joomla.org/

12 di 97

http://www.joomla.org/

Figura 2.1

Eclipse2 è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma.Ideato da un consorzio di grandi società quali Ericsson, HP, IBM, Intel, MontaVistaSoftware, QNX, SAP e Serena Software, chiamato Eclipse Foundation, viene sviluppatoda una comunità strutturata sullo stile dell’open source. Eclipse può essere utilizzatoper la produzione di software di vario genere, si passa infatti da un completo IDE peril linguaggio Java (JDT, Java Development Tools) a un ambiente di sviluppo per il lin-guaggio C++ (CDT, C/C++ Development Tools) e a plug-in che permettono di gestireXML, Javascript, PHP e persino di progettare graficamente una GUI per un’applicazioneJAVA (Eclipse VE, Visual Editor), rendendo di fatto Eclipse un ambiente RAD.

Plugin Eclipse utilizzati:

Maven Plugin per Eclipse: Maven è un progetto open source, sviluppato dalla Apa-che, che permette di organizzare in modo molto efficiente un progetto java.Può essere paragonato all’altro progetto più conosciuto della Apache, Ant, ma for-nisce funzionalità più avanzate. I vantaggi principali di Maven sono i seguenti:standardizzazione della struttura di un progetto, test ed esportazione automatiz-zate, gestione e download automatico delle librerie necessarie al progetto, creazioneautomatica di un semplice sito di gestione del progetto contenente informazioni.

Subclipse: Offre le funzionalità sotto descritte di Subversion.

2.2.2 Joomla!

L’utilizzo di tale strumento è stato indicato dall’azienda.

Figura 2.2

Jooma!3 è un software di content management (CMS) per siti web, realizzato com-pletamente in linguaggio PHP e pubblicato con licenza open source GNU GPL v.2. Ènato nel settembre 2005 da una scissione (fork) dal codice del CMS (Content Manage-ment System) Mambo; attualmente è in rapido sviluppo, sotto la guida di un gruppodi programmatori (per buona parte ex-sviluppatori di Mambo) riuniti nell’associazioneno-profit Open Source Matters.

2http://www.eclipse.org/3http://www.joomla.org/

13 di 97

http://www.eclipse.org/

http://www.joomla.org/

Il CMS è distribuito sotto forma di pacchetto compresso: per poterlo utilizzare èsufficiente scompattare l’archivio in una cartella pubblica di un server Web dotato disupporto a PHP ed avere a disposizione un database MySQL per i dati del programma.Dopo un processo di installazione (più propriamente, di prima configurazione) di pochiminuti, il sito è operativo.

Tra le caratteristiche principali proposte ci sono:

• Alto grado di personalizzazione grazie alle numerose estensioni moduli, componentie plugin (vedi più sotto) disponibili sia come Software libero che con altre licenze.

• Caching delle pagine per incrementare le prestazioni.

• Funzioni di Search Engine Optimization, per facilitare l’indicizzazione dei contenutida parte dei motori di ricerca.

• Feeding RSS che permette ai visitatori di essere avvisati degli aggiornamenti deicontenuti mediante l’utilizzo di un feed reader.

• Versione stampabile delle pagine.

• Esportazione delle pagine in formato PDF.

• Pubblicazione tipo Blog.

• Sondaggi.

• Ricerca testuale su tutti i contenuti inseriti.

• Localizzazione internazionale, che permette la traduzione di ogni funzionalità delsoftware nella propria lingua.

2.3 Librerie Esterne

In base alle motivazioni descritte nel paragrafo precedente, come integrazione al linguag-gio Java sono state utilizzate le seguenti librerie:

2.3.1 Framework Spring

Figura 2.3: Logo Spring.

Spring4 è un framework open source nato con l’intento di gestire la complessità nellosviluppo di applicazioni Java enterprise. È leggero e grazie alla sua architettura estrema-mente modulare è possibile utilizzarlo nella sua interezza o solo in parte. L’adozione diSpring in un progetto è molto semplice, può avvenire in maniera incrementale e non nesconvolge l’architettura esistente. Questa sua peculiarità ne permette anche una facileintegrazione con altri framework esistenti, come ad esempio Struts. È un lightweight

4http://www.springsource.org/

14 di 97

http://www.springsource.org/

container e si propone come alternativa/complemento a J2EE e, a differenza di que-st’ultimo, Spring propone un modello più semplice e leggero (soprattutto rispetto adEJB) per lo sviluppo di entità di business. Tale semplicità è rafforzata dall’utilizzo ditecnologie come l’Inversion of Control e l’Aspect Oriented che danno maggiore spessoreal framework e favoriscono la focalizzazione dello sviluppatore sulla logica applicativaessenziale. Inoltre a differenza di molti framework che si concentrano maggiormente nelfornire soluzioni a problemi specifici, Spring mette a disposizione una serie completa distrumenti atti a gestire l’intera complessità di un progetto software. Spring è infine unframework nato con la concezione che il codice di qualità debba essere facilmente testatoe questa filosofia fa sì che, con esso, sia molto facile testare il codice. Grazie a questapeculiarità, il framework si è ritagliato uno spazio importante in quegli ambiti dove iltesting è considerato parte fondamentale del progetto software.

2.3.2 Hibernate

Figura 2.4: Logo Hibernate.

Hibernate5 è una piattaforma Middleware Open Source per lo sviluppo di applicazioniJava che fornisce un servizio di Object-Relational Mapping (ORM), ovvero chegestisce la rappresentazione e il mantenimento su database relazionali di un sistema dioggetti Java. Lo scopo principale di Hibernate è quello di fornire un mapping delleclassi Java in tabelle di un database relazionale. Sulla base di questo mapping Hibernategestisce il salvataggio degli oggetti di tali classi su database.

2.4 Server utilizzati

L’utilizzo di questa tipologia di server è stato indicato dall’azienda.

2.4.1 Tomcat 7.0

Figura 2.5: Logo Tomcat.

Apache Tomcat6 (o semplicemente Tomcat) è un contenitore servlet open source svi-luppato dalla Apache Software Foundation. Implementa le specifiche JavaServer Pages(JSP) e Servlet di Sun Microsystems, fornendo quindi una piattaforma per l’esecuzione di

5http://www.hibernate.org/6http://tomcat.apache.org/

15 di 97

http://www.hibernate.org/

http://tomcat.apache.org/

applicazioni Web sviluppate nel linguaggio Java. La sua distribuzione standard includeanche le funzionalità di web server tradizionale che corrispondono al prodotto Apache.

2.4.2 PostgreSQL


Figura 2.6: Logo PostgreSQL.

PostgreSQL7 è un Database relazionale ad oggetti rilasciato con licenza libera (stileLicenza BSD). Spesso viene abbreviato come Postgres, sebbene questo sia un nomevecchio dello stesso progetto.PostgreSQL è una reale alternativa sia rispetto ad altri prodotti liberi come MySQL,Firebird SQL e MaxDB che a quelli a codice chiuso come Oracle, Informix o DB2 ed offrecaratteristiche uniche nel suo genere che lo pongono per alcuni aspetti all’avanguardianel settore dei database.

2.4.3 Apache ActiveMQ


Figura 2.7: Logo ActiveMq.

Apache ActiveMq8 è un server per l’implementazione di code di messaggi attra-verso la tecnologia JMS (Java Message Service). Supporta vari tipi di linguaggio, tra cuiJava e Php e offre un rapido pannello di gestione.

2.5 Software di controllo e sviluppo di progetto

L’utilizzo di questo software è stata una scelta personale dovuta ad esperienze positiveprecedenti.

Subversion9 (abbreviato svn) è un sistema di controllo del versionamento. Si uti-lizza principalmente sul codice sorgente ma può funzionare con qualsiasi tipo di file.

7http://http://www.postgresql.org/8http://http://www.activemq.apache.org/9http://subversion.tigris.org/

16 di 97

http://http://www.postgresql.org/

http://http://www.activemq.apache.org/

http://subversion.tigris.org/

Caratteristiche principali:

• Mantiene un indice (un numero naturale) che viene incrementato ad ogni modificaeffettuata.

• Per ogni modifica mantiene autore, data, variazioni applicate, ecc.

• Permette di risalire alle versioni precedenti anche sui singoli file.

• Permette di controllare le modifiche effettuate, di annullarle, ecc.

• Mette in sicurezza l’eventuale modifica contemporanea da parte di più persone.

• Mette in sicurezza da cancellazioni accidentali, modifiche maldestre, ecc.

L’esistenza di un rapporto server client è necessaria al meccanismo di versionamentoche funziona essenzialmente controllando lo scambio tra i file sul server (repository) equelli sul client (copia di lavoro). I file versionati non sono direttamente accessibilineanche dal server; infatti nelle cartelle dei repository si trovano in forma di database eper accedervi, è necessario creare una copia di lavoro locale.

2.6 Strumenti per stesura documenti e diagrammi

L’utilizzo di questi software è stata una scelta presa in base a precedenti esperienzepersonali positive con essi.

2.6.1 Software Editore LATEXper documenti di testo

Per editare i file LATEXviene usato il programma gratuito Texmaker10 dotato di auto-completamento e di diversi strumenti per la compilazione come l’estensione di PDFLa-TeX che permette la creazione del file .pdf.

2.6.2 Software Diagrammi UML

StarUML è un progetto open source per lo sviluppo veloce di diagrammi UML. Ol-tre ad essere un prodotto liberamente scaricabile, StarUML risulta essere flessibile edestendibile, grazie alla sua architettura a plug-in ed alla disponibilità di apposite API.

2.6.3 Software di pianificazione

Lo strumento utilizzato come supporto alla gestione del progetto e quindi per la creazionedei diagrammi di Gantt, è Gantt Project11 per la sua semplicità di utilizzo e perchéè opensource.

10http://www.xm1math.net/texmaker/11www.ganttproject.biz

17 di 97

http://www.xm1math.net/texmaker/

www.ganttproject.biz

18 di 97

Capitolo 3

Piano di lavoro preventivo

Ecco riportata la pianificazione delle attività, su base settimanale, preventivate primadell’inizio dell’attività di stage presso la seguente azienda:

Azienda NE-T BY TELERETE NORDEST.ITSede Via Salboro 22/b - 35124 Padova (PD)

Telefono T. +39 049 2010011, F. +39 049 2010034Tutor Aziendale Ing. Francesco Mandelli

E-Mail Tutor [email protected] Web http://www.ne-t.it/

19

3.1 Dettaglio ore preventivate

La seguente tabella riporta le principali attività preventivate per il completamento delprogetto.

Figura 3.1: Tabella suddivisione ore.

20 di 97

3.2 Piano settimanale

Nel grafico successivo si ha una visione giornaliera delle attività da svolgere.

Figura 3.2: Grafico attività.

21 di 97

In particolare:

Settimana Periodo Attività Ore1 13/09/11 - 16/09/11 Stesura documenti di progetto

- Esplorazione/formazione sunuove tecnologie

40

2 19/09/11 - 24/09/11 Analisi requisti di sistema -Analisi requisiti software -Studio di alcuni use cases

40

3 26/09/11 - 03/10/11 Progettazione modulo provi-der - Progettazione moduloNet Sms Gateway - Progetta-zione modulo Database

40

4-5-6 04/10/11 - 22/10/11 Implementazione modulo pro-vider - Implementazione mo-dulo Net Sms Gateway - Im-plementazione modulo Data-base - Integrazione moduli -Sviluppo servizi con interfac-cia grafica

123

7 - 8 24/10/11 - 04/11/11 Verifica e validazione - Esecu-zione test

57

La fase di formazione si è svolta in contemporanea con la fase di analisi e ha riguardatosoprattutto la ricerca, lo studio e dei test sugli strumenti utilizzati per lo sviluppo. Nonsi può affermare che non vi sia stata formazione anche durante le altre fasi di lavoro,questo perché in ogni fase vi era qualcosa da imparare e nuove procedure da utilizzare.Il modello di ciclo di vita adottato è stato quello agile, ciò significa che le fasi di analisie progettazione sono state fatte ad alto livello, per non perdersi nella complessità deidettagli, mentre il grosso del lavoro è stato fatto in fase di sviluppo. Inoltre sono statesvolte numerose revisioni per verificare lo stato di avanzamento dei lavori e soprattuttoil lavoro finale è stato suddiviso in piccoli incrementi che sono stati sviluppati a seguitodi ogni revisione, per meglio soddisfare le richieste dei committenti. L’adozione di unmetodo agile implica una grande collaborazione e soprattutto disponibilità in terminidi tempo del committente che, in questo caso era il tutor aziendale, per lo sviluppo delprogetto.

22 di 97

Capitolo 4

Analisi

4.1 Premessa

La parte iniziale del progetto consiste nel creare non un tipo di servizio in particolarema un Framework per effettuare le varie operazioni con la tecnologia Sms. Questa èla parte piú delicata poiché tale Framework potrà essere utilizzato in una grande varietàdi prodotti per l’azienda. È quindi indispensabile dedicare ad essa il maggior tempoe risorse possibili. Di fondamentale importanza è poi il fatto di non dover dipendereda un solo provider telefonico, in modo da poter contare su un’ alternativa in caso dievenienza senza quindi impedire la fruizione del servizio. In seguito tra i vari serviziimplementabili verrà sviluppato quello riguardante la creazione di “Campagne Sms”.Esso sarà utilizzato solamente dai dipendenti dell’azienda per tenersi in stretto contattoe per essere il piú facilmente reperibili.In questo capitolo ci soffermiamo principalmente sul prodotto campagne sms poiché ilFramework non è un servizio e non offre in prima persona delle funzionalità agli utentiesterni. Non sarebbe possibile quindi stilare una lista di requisti con relativi diagrammidei casi d’uso.

4.2 Servizio campagne sms

4.2.1 Contesto d’uso del prodotto

Un vincolo indicato dall’azienda consiste nel fatto che il prodotto sarà fruibile solamentedai dipendenti dell’azienda. Ognuno di essi potrà creare un account personale con ilquale contattare gli altri colleghi. In futuro si potrebbe decidere di estendere il servizioanche al pubblico.

4.2.2 Funzioni del prodotto

Come richiesto, il prodotto ultimato dovrà essere in grado di:

1. Interfacciarsi in maniera semplice con il servizio già esistente di compravenditabiglietti accodando ad esso i nuovi sms da inviare richiesti da parte degli utenti

2. Svolgere le operazioni di invio e salvataggio sms nel modo più efficiente e robustopossibile

3. Leggere il contenuto stesso degli sms inviati

Le funzioni in particolare per un utente che utilizza il prodotto sono:

1. Invio sms singolo

23

2. Invio sms multiplo

3. Report messaggi inviati

4. Creazione rubriche contatti personali

5. Creazione di campagne sms specificando destinatari e orario programmato

4.2.3 Diagrammi Casi d’uso

Occorre correlare ogni caso d’uso tramite:

• Attori principali

• Scopo e descrizione

• Precondizione e postcondizione

• Illustrazione dello scenario

Di seguito un elenco dei vari casi d’uso ideati.

Diagramma caso d’uso UC1.0: Net Sms Gateway

Figura 4.1: Diagramma dei casi d’uso che illustra le fasi iniziali obbligatorie per l’utilizzodel prodotto.

Use case: UC1.0: Net Sms Gateway.

Attori principali: Utente, utente autenticato.

Scopo e descrizione: permettere all’utente di inziare ad utilizzare il prodotto Net SmsGateway. L’utente è obbligato ad effettuare alcune operazioni iniziali. L’utente chesi accinge per la prima volta al suo utilizzo deve effettuare una registrazione mentreun utente già registrato deve immettere i propri dati.

Precondizione: l’utente è connesso alla rete Internet e si trova nella pagina principaledel servizio.

Postcondizione: dopo che l’utente si è registrato oppure autenticato, il sistema visua-lizza l’area di lavoro iniziale.

24 di 97

Illustrazione dello scenario: l’utente può:

• effettuare una registrazione al prodotto (UC1.1) inserendo i dati rischiesti percompletare l’operazione.

• se già registrato al sistema, effettuare la propria autenticazione (UC1.2) im-mettendo login e password corrette.

Diagramma caso d’uso UC1.1: Registrazione

Use case: UC1.1: Registrazione.

Attori principali: Utente.

Scopo e descrizione: Permettere all’utente di potersi registrare e ottenere di conse-guenza un account che gli consenta di usufruire del prodotto Net Sms Gateway.Senza di esso l’utente non può effettuare nessun altro tipo di operazione al di fuoridella registrazione.

Precondizione: l’utente è in possesso dei propri dati personali e conosce l’indirizzo peraccedere alla pagina di registrazione.

Postcondizione: dopo aver inoltrato la richiesta di registrazione l’utente deve attenderel’attivazione del proprio account dal parte dell’amministratore di sistema.

Illustrazione dello scenario: l’utente deve inserire:

• nome

• cognome

• email personale

• login

• password

25 di 97

Diagramma caso d’uso UC1.2: Autenticazione

Use case: UC1.2: Autenticazione.

Attori principali: Utente.

Scopo e descrizione: la procedura di autenticazione consiste nell’inserimento dell’in-dirizzo email e della password negli appositi spazi e nell’invio della richiesta diaccesso. Il sistema controlla la presenza delle credenziali nel registro degli utentiiscritti e fornisce esito positivo o negativo a seconda della correttezza dei dati.

Precondizione: l’utente ha scelto di autenticarsi, è connesso alla rete Internet, ed èposizionato nella pagina di accesso.

Postcondizione: se l’utente possiede un account registrato, è autenticato al servizio edil sistema è sbloccato in tutte le sue funzionalità. In caso contrario, viene restituitoun messaggio di errore.

Illustrazione dello scenario: L’utente inserisce i dati necessari per potersi autentica-re:

• nickname

• password personale

Ad autenticazione avvenuta l’utente viene reindirizzato alla pagina iniziale e puòutilizzare il prodotto.

Diagramma caso d’uso UC2.0: Operazioni generali

Figura 4.2: Diagramma dei casi d’uso che illustra le operazioni generali che un utenteautenticato può effettuare.

Use case: UC2.0: Operazioni generali.

26 di 97

Attori principali: Utente autenticato.

Scopo e descrizione: il diagramma illustra le operazioni generali che l’utente, dopoaver immesso le proprie credenziali, può decidere di eseguire. Le varie opzio-ni si presentano all’utente attraverso la pagina principale del prodotto. Esse siconcentrano sulle operazioni effettuabili via sms.

Postcondizione: i dati riconducibili all’utente vengono aggiornati.

Illustrazione dello scenario: l’utente può:

• (UC2.1) Inviare un singolo sms indicando testo del messaggio e destinatario• (UC2.2) Inviare sms multipli indicando i destinatari e il testo del messaggio• (UC2.3) Richiedere il report dei messaggi inviati dal proprio account• (UC2.4) Creare delle rubriche inserendo diversi contatti telefonici• (UC2.5) Creare delle campagne sms in in cui indicare destinatari, testo del

messaggio e data di invio

Diagramma caso d’uso UC2.1: Invio sms singolo

Figura 4.3: Diagramma dei casi d’uso che illustra la fase di invio di un sms singolo.

Use case: UC2.1: Invio sms singolo.


Scopo e descrizione: permettere all’utente di inviare del testo tramite sms verso unsingolo destinatario.

Precondizione: l’utente è in possesso del testo e del destinatario dell’sms.

Postcondizione: dopo che l’utente ha effettuato la richiesta di invio sms inserendo idati richiesti ed aver scelto il provider il sistema invia una ricevuta positiva oppurenegativa.

Illustrazione dello scenario: l’utente deve:

• inserire il contenuto dell’sms• inserire il mittente dell’sms• inserire il destinatario dell’sms• confermare l’operazione

27 di 97

Diagramma caso d’uso UC2.2: Invio sms multiplo

Figura 4.4: Diagramma dei casi d’uso che illustra la fase di invio di un sms multiplo.

Use case: UC2.2: Invio sms multiplo.


Scopo e descrizione: permettere all’utente di inviare del testo tramite sms verso de-stinatari multipli.

Precondizione: l’utente è in possesso del testo e dei destinatari dell’sms.

Postcondizione: dopo che l’utente ha effettuato la richiesta di invio sms inserendo idati richiesti ed aver scelto il provider il sistema invia una ricevuta positiva oppurenegativa.

Illustrazione dello scenario: l’utente deve:

• inserire il contenuto dell’sms

• inserire i destinatari dell’sms

• inserire il mittente dell’sms

• confermare l’operazione

Diagramma caso d’uso UC2.3: Report sms inviati

Figura 4.5: Diagramma dei casi d’uso che illustra la fase di ricezione del report smsinviati.

Use case: UC2.3: Report sms inviati.

28 di 97


Scopo e descrizione: permettere all’utente di ottenere un report degli sms inviati finoal momento della richiesta.

Precondizione: l’utente è loggato.

Postcondizione: l’utente ottiene il report richiesto in forma tabulare.

Illustrazione dello scenario: l’utente può richiedere di visualizzare un report rias-suntivo degli sms inviati associati in cui viene indicato il numero dei destinatari, iltesto, la data di invio.

Diagramma caso d’uso UC2.4: Creazione rubriche

Use case: UC2.4: Creazione rubriche.


Scopo e descrizione: permettere all’utente di salvare in modo persistente i propricontatti telefonici in alcune rubriche.

Precondizione: l’utente conosce i numeri di telefono dei vari contatti.

Postcondizione: l’utente ha creato delle rubriche telefoniche.

Illustrazione dello scenario: l’utente ha disponibile una sezione in cui creare rubrichetelefoniche. Questa funzionalità è molto utile poiché evita di inserire ad ogni accessogli stessi numeri di telefono.

Diagramma caso d’uso UC2.5: Creazione campagne sms

Use case: UC2.5: Creazione campagne sms.


Scopo e descrizione: permettere all’utente di creare delle campagne sms. Una cam-pagna sms consiste nell’inserire dei destinatari, il testo del messaggio da inviare ela data di invio.

Precondizione: l’utente conosce i numeri di telefono dei vari contatti, il testo delmessaggio e la data di invio.

Postcondizione: l’utente ha creato una campagna sms.

Illustrazione dello scenario: l’utente dopo aver inserito i dati richiesti crea una cam-pagna sms. In questo modo può inviare sms a piú destinatari contemporaneamenteprogrammando la data di invio.

29 di 97

4.2.4 Tabelle dei requisiti

I requisiti emersi dall’analisi effettuata sul capitolato sono stati qui di seguito raggruppatiin modo chiaro in una tabella riportante codice identificativo, descrizione e fonte. Nellacolonna provenienza sono evidenziati i tracciamenti dei requisiti con i rispettivi casid’uso. I requisiti dovranno essere semplici, chiari e privi di ogni ambiguità. Essi sarannoraccolti tabularmente specificando:

• il codice identificativo

• una breve descrizione esauriente

• la provenienza indicante l’use case corrispondente

Nel diagramma degli use case le funzioni e i servizi offerti dal sistema vanno indicaticon la sigla UCV.W.X.Y.Z , dove le lettere in italic rappresentano numeri interi. Ognirequisito deve essere segnato con un codice identificativo:

Tipo:

• F: requisito funzionale

• Q: requisito di qualità

• V: requisito di vincolo

• P: requisito prestazionale

Rilevanza:

• OB: requisito obbligatorio

• DE: requisito desiderabile

• OP: requisito opzionale

La nomenclatura di un requisito si basa sulla seguente sintassi: TipoRilevanza. Unrequisito funzionale e obbligatorio verrà quindi identificato con la sigla FOB.

30 di 97

Requisiti funzionali

Tabella 4.1: Tabella requisiti funzionali generali

Codice Descrizione Provenienza

FOB1 Invio sms UC1.0

FOB2 Invio sms multiplo UC2.0

FOB3 Report sms inviati sms UC3.0

FOB4 Creazione rubriche UC4.0

FOB5 Creazione campagne sms UC5.0

Requisiti di vincolo

Tabella 4.2: Tabella requisiti di vincolo


VOB1 Il prodotto deve essere sviluppatoutilizzando il CMS Joomla!

req. non fun-zionale

VOB2 Il prodotto deve comunicare conil servizio compravendita bigliettiattraverso il protocollo JMS


Requisiti prestazionali

Tabella 4.3: Tabella requisiti prestazionali


POB1 Il framework deve gestire l’invio disingoli/multipli sms nel sistema piùefficiente possibile


31 di 97

Requisiti di qualità

Tabella 4.4: Tabella requisiti di qualità


QOB1 Il prodotto deve essere di facileutilizzo

nessuna

32 di 97

Capitolo 5

Progettazione

5.1 Premessa

Il capitolo è suddiviso in tre parti: la prima descrive la fase di progettazione del Fra-mework, in seguito analizziamo le modifiche apportate al software che si occupa di gestirele operazioni di invio/ricezione sms per la compravendita di biglietti ed infine si parladella progettazione del servizio Campagne Sms.

5.2 Framework

5.2.1 Design Pattern Utilizzati

Di seguito vengono presentati i design pattern utilizzati per la progettazione del Fra-mework per l’invio e ricezione di sms.

Figura 5.1: MVC.

33

Figura 5.2: Schema esplicativo MVC.

Durante la fase di progettazione si è scelto di utilizzare il design pattern architet-turale MVC. La scelta è stata praticamente obbligata per poter sfruttare appienole funzionalità offerte dal Framework Spring, il quale implementa tale soluzione.Il design pattern Model-View-Controller (MVC) è un pattern architetturale chedefinisce la suddivisione del codice sorgente di un applicativo secondo le tre com-ponenti Model, View e Controller. La separazione porta ad una maggiore chiarezzadel codice, molto utile in fase di manutenzione, soprattutto quando a modificare isorgenti non sono le stesse persone che li hanno concepiti o scritti.Il significato di MVC è il seguente:

• Model: si compone dei metodi per l’accesso ai dati sensibili dell’applicazione,prelevati da una base di dati.• Controller: è il cuore dell’applicativo, contenente le classi ed i metodi che

implementano le funzionalità principali del software.• View: gestisce la parte grafica, in particolare la visualizzazione dei dati

recuperati attraverso l’interfaccia Model.

Nota: in questo caso specifico vengono implementati solo le componenti Modele Controller poiché la componente per la visualizzazione dei dati (View) verràimplementata dallo specifico servizio che utilizzerà tale Framework.

Figura 5.3: Struttura del design pattern Singleton.

Singleton La scelta di questo pattern è dovuta al fatto che assicura che nello stessoistante non esistano molteplici istanze delle classi che utilizzano i provider per

34 di 97

effettuare le operazioni sms. Vogliamo infatti che tutte le richieste vengano gestitesolamente da un’unica istanza per ogni specifico provider.Il Singleton è un design pattern creazionale che ha lo scopo di garantire da un latoche di una determinata classe venga creata una e una sola istanza e dall’altro difornire un punto di accesso globale a tale istanza.

L’implementazione più semplice di questo pattern prevede che la classe Singletonabbia un unico costruttore privato, in modo da impedire l’istanziazione direttadella classe. La classe fornisce inoltre un metodo “getter” statico che ritorna unaistanza della classe, creandola preventivamente o alla prima chiamata del metodo ememorizzandone il riferimento in un attributo privato anch’esso statico. Il secondoapproccio si può classificare come basato sul principio della lazy initialization inquanto la creazione dell’istanza della classe viene rimandata nel tempo e messa inatto solo quando ciò diventa strettamente necessario.

5.2.2 Identificazione dei componenti architetturali di alto livello

Componente Model

Il componente Model si occupa di gestire la memorizzazione e il reperimento dei datirelativi all’applicazione. Ogni classe del Model rappresenta lo stato di un oggetto lo-gico del sistema. Queste classi contengono solo le informazioni che sono necessarie permantenere lo stato dell’applicazione tra un utilizzo e l’altro e una serie di funzionalità direcupero e aggiornamento delle stesse, al fine di servire da archivio per l’intero sistema.

Memorizzazione dei dati: Come spazio di archiviazione verrà utilizzato con Java ilFramework Spring con Hibernate. Lo scopo principale di Hibernate è quello di fornireun mapping delle classi Java in tabelle di un database relazionale. Sulla base di questomapping, Hibernate gestisce il salvataggio degli oggetti di tali classi su database.

Componente Controller

Il componente controller ha il compito di intermediare tra il componente Model ed ilcomponente View. Si occupa di gestire le varie operazioni di invio/ricezione/lettura smsattraverso l’utilizzo dei provider disponibili. Inoltre deve aggiornare in modo corretto idati salvati nel Model rendendoli disponibili in seguito tramite View.

5.2.3 Descrizione dei singoli componenti

In questa sezione vengono descritte solo le classi piú significative delle componenti Modele Controller indicando le caratteristiche principali di ognuna.

35 di 97

5.2.4 Model

Figura 5.4: Diagramma delle classi UML che descrive il componente Model.

[ Connection_Properties ]

Tipo, obiettivo e funzione del componente : Descrivere le proprietà necessarieper poter stabilire la connessione con un dato provider.

Relazioni d’uso di altre componenti : Nessuna.

Interfacce e relazioni d’uso da altre componenti : Composizione dalla classeMAMController.

Attività svolte e dati trattati : memorizza tutti i dati che costituiscono la con-nessione ad un provider. I valori sono tutti inizializzati a valori di default, in modo daevitare situazioni di inconsistenza.

[ Sms ]

Tipo, obiettivo e funzione del componente : Rappresentare le caratteristiche checompongono un Sms.

Relazioni d’uso di altre componenti : Nessuna.

Interfacce e relazioni d’uso da altre componenti : Associazione semplice con laclasse MAMController e AIMONController.

36 di 97

Attività svolte e dati trattati : memorizza tutti i dati che compongono un’entitàsms. I valori sono tutti inizializzati a valori di default in modo da evitare situazioni diinconsistenza.

5.2.5 Controller

Figura 5.5: Diagramma delle classi UML che descrive il componente Controller.

[ MAMController ]

Tipo, obiettivo e funzione del componente : Effettuare le operazioni di invio/ri-cezione/lettura sms attraverso il provider Vodafone.

Relazioni d’uso di altre componenti : Implementazione dell’interfacciaNet_Sms_Gateway_Controller. Aggregazione con la classe Connection_Properties. As-sociazione semplice con la classe Sms.

Interfacce e relazioni d’uso da altre componenti : Nessuna.

Attività svolte e dati trattati : Permette di collegarsi/scollegarsi al provider Voda-fone attraverso un router fornito dalla società denominato MAM. La comunicazione conesso avviene tramite linguaggio telnet.

37 di 97

[ AIMONController ]

Tipo, obiettivo e funzione del componente : Effettuare le operazioni di invio/ri-cezione/lettura sms attraverso il provider Aimon.

Relazioni d’uso di altre componenti : Implementazione dell’interfacciaNet_Sms_Gateway_Controller.Aggregazione con la classe Connection_Properties. Associazione semplice con la classeSms.


Attività svolte e dati trattati : Permette di collegarsi/scollegarsi al provider Aimonattraverso le API fornite dalla società utilizzando il protocollo Http.

[ ModelHibernateDaoSupport ]

Tipo, obiettivo e funzione del componente : Permette di eseguire le operazionidi lettura/scrittura su database tramite la tecnologia offerta da Hibernate.

Relazioni d’uso di altre componenti : Implementazione dell’interfaccia SmsDao.Estensione della classe HibernateDaoSupport. Associazione semplice con la classe MAM-Controller e AIMONController.


Attività svolte e dati trattati : Implementa la classe HibernateDaoSupport la qua-le traduce operazioni di aggiornamento, lettura, scrittura, interrogazione delle classimappate nel linguaggio specifico del database utilizzato.

38 di 97

5.3 Modifiche al software esistente SMSTelerete

In questa sezione vengono descritte le modifiche da apportare in modo tale che il softwaredell’azienda per la gestione dei titoli di viaggio gestisca anche le richieste di invio smsdal servizio Campagne Sms.

5.3.1 Panoramica generale software compravendita titoli di viaggi

Descriviamo velocemente senza entrare nello specifico il software dell’azienda.Analizziamo nel dettaglio il flusso completo per l’acquisto di un biglietto per un

singolo viaggio.

Figura 5.6: Schema che descrive il flusso esecutivo dell’acquisto di un biglietto.

• Il cliente invia un SMS opportunamente formattato ad un numero che fa capo adil server SMS Gateway. L’SMS viene quindi tradotto in una forma consultabile viaweb. Tale SMS conterrà al suo interno tra le varie informazioni la tipologia delbiglietto oggetto dell’acquisto con la relativa quantità.

• Le nuove richieste vengono passate dalla ne-t Application all’Hub MovinBox.

• La ne-t Application, tramite l’ Hub Movincom, effettua una richiesta di autoriz-zazione al pagamento all’operatore bancario presso cui il cliente ha fatto l’accop-piamento numero di cellulare/strumento di pagamento. Nel caso l’autorizzazio-ne abbia esito positivo la ne-t Application avvia il processo di contabilizzazio-ne che comporta l’invio da parte dell’operatore bancario di un SMS di avvenutopagamento.

• Viene comunicato l’esito del pagamento dall’ Hub Movinbox alla ne-t Application.

• Viene inviato dalla ne-t Application all’SMS Gateway una richiesta di inoltro SMSal cliente che ha eseguito l’acquisto. Tale SMS contiene un codice necessario allastampa delle ricevuta o per la richiesta di fattura.

• Viene contattato il gestionale dell’Azienda di Trasporti al fine di inserire i datirelativi all’oggetto acquistato. È quindi ritornato un codice identificativo che saràquello riportato nella ricevuta stampabile dal cliente.

39 di 97

In caso di avvenuto pagamento il cliente riceverà due SMS: uno dalla ne-t Applicatione uno dall’emittente dello strumento di pagamento.Il cliente riceverà un SMS dalla ne-t Application nei casi in cui si verifica un errorenella procedura e quindi anche nel caso l’autorizzazione abbia esito positivo ma non lacontabilizzazione.

Verifica dell’avvenuta validazione: Per la validazione da parte del personaleispettivo è sufficiente presentare l’SMS di ritorno dalla ne-t application riportante l’oradi acquisto del biglietto (che corrisponde a quella di invio da parte della ne-t Application).In alternativa il controllore può richiedere di contattare un servizio IVR in cui, una voltainserito il numero di cellulare del cliente vengono ritornati gli ultimi acquisti effettuati.A disposizione del personale ispettivo esiste anche un file di testo che viene caricato inun palmare tramite la connessione WiFi presente negli autobus e che riporta tutti gliacquisti effettuati durante la giornata.

40 di 97

5.3.2 Funzionamento

Tralasciamo le operazioni riguardanti il pagamento dei biglietti, poiché non utili ai fini delprogetto. Ci soffermiamo invece sulle operazioni di invio/ricezione sms. Tali operazionivengono eseguite da una servlet Java utilizzando code JMS (Java Message Service).

Figura 5.7: Schema che descrive l’utilizzo delle code JMS.

Come indicato nella figura ogni servizio invia in un’unica coda SmsOut i propri mes-saggi da essere inviati tramite sms dall’ SmsGateway dell’azienda. I messaggi vengonoinviati in formato Java Message Service. La servlet non fa altro che controllare perio-dicamente se in tale coda sono presenti ancora messaggi da inviare tramite il providerVodafone. In tal caso, dopo averli inviati, inoltra al servizio una notifica nella sua codaSMSOutStatus. Nella coda SMSIn invece la servlet inoltra i messaggi in arrivo diogni servizio.

41 di 97

5.3.3 Modifiche

Per permettere che tale servlet sia in grado di gestire anche l’invio di sms per nuoviservizi come Campagne Sms e utilizzare nuovi provider è sufficiente appoggiarsi ancorauna volta alla tecnologia delle code Java Message service. Questa è parsa la soluzionepiù semplice ed efficacie per il fatto che non si appesantisce il codice con nuovi elementi.

Figura 5.8: Schema che descrive l’aggiunta di nuovi provider e servizi.

Come si nota in figura, basta semplicemente dotare i nuovi servizi di proprie codeJMS e permettere a tutti i provider disponibili di accedervi. La servlet controlleràperiodicamente la coda in comune, verificando l’esistenza di nuovi messaggi da smistare.Di fondamentale importanza è la possibilità di far collaborare diversi linguaggi tra di loro,come nel nostro caso (Java e PHP), poiché tali code sono compatibili con la maggiorparte dei linguaggi di programmazione esistenti.

42 di 97

5.4 Servizio Campagne Sms

Di seguito vengono presentati: la struttura del portale, del database e alcuni mockupsideati in fase di progettazione.

5.4.1 Struttura portale e mockups

Figura 5.9: Sitemap del prodotto in fase di progettazione.

43 di 97

Il portale in base ai requisiti emersi nella fase di analisi deve essere suddiviso nelle seguentipagine:

Home: Pagina iniziale del prodotto. Contiene alcune informazioni sul servizio campagnesms, un form per il login utente ed uno per la registrazione. È visualizzabile daqualsiasi tipo di utente.

Figura 5.10: Mockup pagina home.

Contatti: Pagina contenente alcune informazioni riguardante l’azienda. Nello specificocontatti e posizione geografica. È visualizzabile da qualsiasi tipo di utente.

44 di 97

Sms Singolo: Visualizzabile solo dopo aver effettuato l’accesso al servizio. Contiene unform per l’invio di un singolo sms. L’utente deve inserire mittente, destinatario etesto del messaggio.

Figura 5.11: Mockup pagina invio singolo sms.

45 di 97

Sms Multiplo: Visualizzabile solo dopo aver effettuato l’accesso al servizio. Contieneun form per l’invio di sms multipli. L’utente deve inserire mittente, lista creataprecedentemente contenente i destinatari e testo del messaggio.

Figura 5.12: Mockup pagina invio multiplo sms.

Liste contatti: Visualizzabile solo dopo aver effettuato l’accesso al servizio. Trami-te questa pagina è possibile visualizzare tutti i contatti esistenti, crearne/modifi-carne oppure eliminarne, creare/visualizzare/modificare oppure eliminare liste dicontatti, associare contatti esistenti a liste.

Report sms inviati: Visualizzabile solo dopo aver effettuato l’accesso al servizio. Tra-mite questa pagina si possono visualizzare tutti gli sms inviati dal proprio accountcon il relativo stato.

46 di 97

Campagne: Visualizzabile solo dopo aver effettuato l’accesso al servizio. Tramite que-sta pagina è possibile visualizzare/creare/modificare oppure eliminare delle cam-pagne. Per ogni campagna si deve indicare mittente, lista di invio, data e ora diinvio e testo del messaggio.

Figura 5.13: Mockup pagina campagne.

47 di 97

5.4.2 Struttura database

Di seguito il diagramma della struttura del database ideato in fase di progettazione. Siè cercato, per quanto possibile, di renderla molto semplice.

Figura 5.14: Diagramma database.

48 di 97

Capitolo 6

Implementazione

6.1 Premessa

Il capitolo è suddiviso in tre parti: la prima descrive l’implementazione del Framework,in seguito le modifiche apportate al software di compravendita dei biglietti ed infinel’implementazione con Joomla! e le code JMS del servizio Campagne sms.

6.2 Implementazione Framework

L’implementazione è avvenuta utilizzando i due provider disponibili in azienda, Voda-fone ed Aimon. Inoltre la risoluzione delle dipendenze è stata eseguita con l’ausilio delframework Spring come richiesto.Per tenere traccia delle operazioni eseguite (sms inviati/ricevuti) vengono salvati dati inapposite tabelle corrispondenti alle classi del componente model utilizzando il FrameworkHibernate come voluto dal committente.

6.2.1 API Vodafone

Il protocollo MAM è un protocollo proprietario esposto dal servizio di MessaggisticaAziendale Mobile (MAM) di Vodafone. Esso regola la comunicazione tra MAM Server(Vodafone) e MAM Client (applicazione del Cliente MAM) per gestire l’invio e la ri-cezione di messaggi SMS. Il MAM Server garantisce l’invio e la ricezione dei messaggidi tutti i client MAM, invece il suo client è il mezzo utilizzato dalle varie aziende perusufruire del servizio SMS. Ad ogni MAM client quindi è associato un numero breve adisposizione dell’azienda il quale rappresenta:

• il mittente di tutti i messaggi originati dall’applicazione MAM Client connessaall’account.

• il destinatario a cui inviare i messaggi affinché giungano all’applicazione MAM-Client connessa all’account (se l’account stesso è abilitato a ricevere).

49

Figura 6.1: Architettura MAM Client-Server.

La comunicazione tra Server e Client avviene tramite protocollo tcp/ip mentre l’inviodei comandi al Client avviene tramite protocollo Telnet mediante la porta 8000.

Definizione protocollo

Il protocollo MAM è composto di primitive leggibili del tipo:

• Request/Confirm (comunicazione sincrona per iniziativa del client).

• Indication (notifiche asincrone provenienti dal server, per le quali non è previstarisposta esplicita da parte del client).

La comunicazione sincrona è quella piú affidabile ed efficiente in quanto il clientprende l’iniziativa della comunicazione e attende sempre e comunque l’emissione dellaConfirm da parte del server, prima di inviare una nuova Request.

Confirm: Il messaggio di conferma da parte del Server in riposta di una Request puòessere di due tipi.Reply: termina sempre con un OK preceduto da una riga vuota, il quale garanti-sce la corretta ricezione della Request da parte del Server.<param>=<value><param>=<value>..<blank line>OK

Error: ci restituisce il numero dell’errore seguito da una piccola descrizione. Inquesto caso la request non è andata a buon fine. Error #<errnum>: <descr>

Indication: È un messaggio asincrono spedito dal server al client. La sintassi dell’Indi-cation è molto simile ad una Confirm; si differenzia da essa per il fatto che iniziacon un punto esclamativo. Quando è in atto un messaggio Indication da partedel server, quest’ultimo non aspetta nessun tipo di risposta da parte del client alleIndication ricevute. Anche in questo caso l’Indication può essere di due varianti:Notification ed Error. Quando un indication è nella forma di tipo error provocala chiusura della connessione MAM verso il Client. Questo e uno dei motivi perscegliere una comunicazione di tipo sincrono con il server MAM.

50 di 97

Comandi base

Figura 6.2: Comandi MAM Vodafone.

Utilizzo MAM Vofafone

Per poter realizzare in maniera corretta il progetto è necessario delineare al meglio comeutilizzare la console MAM di Vodafone. Il problema da affrontare sono le limitate sessioniche il Server MAM dedica. L’utente infatti può stabilire verso il MAM Server una solasessione per volta (non sono ammesse sessioni contemporanee). Una sessione quindirimane attiva fino a quando il Client manda la Request Logout al Server o fino a quandonon scade il Timeout di inattività; in questo caso è il Server che imposta la sconnessione.Per ovviare a questo problema i casi possibili possono essere 2:

• Mantenere la connessione sempre attiva, evitando i continui Login/Logout da partedel client al Server. Ogni istruzione quindi utilizzerà la stessa connessione per poirilasciarla all’istruzione successiva.In questo caso si pone un problema di concorrenza in mutua esclusione: il socketdi connessione sarà la risorsa (unica) condivisa da ogni istruzione e tali istruzioninon potranno usufruire della risorsa contemporaneamente (mutua esclusione).

• Ogni istruzione, prima di eseguire la sua determinata Request al Server Vodafone,dovrà eseguire l’istruzione di Login e successivamente di Logout. In questo casosi evita l’utilizzo di una risorsa condivisibile. Le istruzioni, comunque, saranno lostesso in mutua esclusione in quanto non potranno effettuare il Login al ServerMAM contemporaneamente o prima del logout dell’istruzione che ha aperto laconnessione.La scelta è quindi ricaduta su questa seconda opzione in modo da stressare ilminimo indispensabile il server Vodafone.

6.2.2 API Aimon

Le funzionalità offerte da queste Api sono simili a quelle di Vodafone: invio/ricezione smse rispettivi report. La differenza sostanziale è il protocollo di comunicazione: in questocaso si utilizzano richieste HTTP/POST verso il server Aimon fornendo i parametririchiesti.Ecco i parametri fondamentali per ogni specifico comando:

Invio Sms: Lista dei parametri da passare alle al server Aimon tramite protocollo httppost:

51 di 97

Figura 6.3: Parametri post per invio sms con Aimon.

La chiamata restituirà una lista di struct contenente tante struct ordinate perquante richieste SMS sono state fatte. Se per esempio sono stati specificati dueSMS nella stessa richiesta, e il secondo contiene un errore, si avrà una struct diritorno simile a questa:’id_sms’ : ’18012549746465’# struct di ritorno relativo al primo SMS’error_code’ : 100, ’error_message’ : ’Invalid destination’# struct di ritorno relativo al secondo SMS

Report sms inviati: La richiesta di report sms inviati ha come scopo quello di scaricaretutti i report generati per gli SMS precedentemente inviati.

La richiesta ritorna una struct composta dai seguenti elementi:- id_sms : ID SMS, codice dell’sms rilasciato in fase di invio.- id_dlr : codice della parte del mesaggio: per l’invio via API sarà sempre valo-rizzato a 1.- destination: MSISDN del numero a cui è stato spedito l’SMS.- timestamp_report: timestamp del report nel formato GG/MM/AAAAHH:MM:SS.- status: stato del messaggio, (S → spedito, R → ricevuto, K → numero inesi-stente, rifiutato dalla rete o scaduto).

Report sms ricevuti: Per questo tipo di report si deve predisporre un’URL dove rice-vere, per ogni SMS ricevuto, una richiesta di tipo POST con i seguenti parametri:Sender : numero di telefono del cellulare che ha spedito l’SMS.Destination : numero di telefono del cellulare assegnato al servizio SMS Ricezio-ne.Timestamp : timestamp del messaggio nel formato GG/MM/AAAA HH:MM:SS.Body : testo dell’SMS ricevuto.

6.2.3 Implementazione in linguaggio Java

Descriviamo qui brevemente le classi piú importanti del Framework riferendoci aidiagrammi UML visualizzabili nela capitolo di progettazione.

Model:

[ Connection_Properties ]

Tipo, obiettivo e funzione del componente : descrivere le proprietà neces-sarie per poter stabilire la connessione con un dato provider.

52 di 97

Relazioni d’uso di altre componenti : nessuna.

Interfacce e relazioni d’uso da altre componenti : composizione dalla classeMAMController.

Attività svolte e dati trattati : memorizza tutti i dati che costituiscono laconnessione ad un provider. I valori sono tutti inizializzati a valori di default inmodo da evitare situazioni di inconsistenza.

Attributi

• host:String : indirizzo per effettuare la connessione con un certo provider.

• port:Int : numero della porta associata al servizio di un certo provider.

• user:String : nome utente per effettuare l’operazione di login al servizio.

• password:String : password utente per effettuare l’operazione di login al servi-zio.

Metodi

• Metodi setter/getter : metodi per modificare oppure ottenere i campi privatidella classe.

[ Sms ]

Tipo, obiettivo e funzione del componente : rappresentare le caratteristicheche compongono un Sms.

Relazioni d’uso di altre componenti : nessuna.

Interfacce e relazioni d’uso da altre componenti : associazione semplicecon la classe MAMController e AIMONController.

Attività svolte e dati trattati : memorizza tutti i dati che compongono un’en-tità sms. I valori sono tutti inizializzati a valori di default in modo da evitaresituazioni di inconsistenza.

Attributi

• receiver:String : numero telefonico del destinatario dell’sms.

• sender:String : numero telefonico del mittente che ha inviato l’sms.

• sms_body:String : contenuto testuale dell’sms.

• id:String : codice identificativo dell’sms. Solitamente viene rilasciato dal ser-ver del provider dopo che l’sms è stato inviato oppure ricevuto.

53 di 97

• timestamp: SimpleDateFormat : data correlata di orario corrispondete all’i-stante di richiesta di processione dell’sms al server del provider

• status:String : serve ad indicare lo stato attuale dell’sms. Per quanto riguardail provider Aimon la simbologia è: SMS INVIATI - S=spedito ;R=ricevuto ;K=numero inesistente,rifiutato dalla rete, scaduto. SMS RICEVUTI - F=nonletto T=letto. Per quanto riguarda Vodafone invece : queued=accodato nel-la coda di trasmissione dei messaggi ; rejected=rifiutato dalla rete GSM ;acccepted=accettato dalla rete GSM ; waitwakeup=in attesa di individuazio-ne del destinatario sulla rete GSM ; delivered=inviato al destinatario ; ex-pired=scaduto il periodo di validità ; cancelled=cancellato dalla rete GSM ;receivednew=ricevuto.

• priority:int : priorità di invio dell’sms.

• last_update: SimpleDateFormat : ultimo aggiornamento dello stato dell’sms.

• encoding:String : codifica dell’sms.

Metodi

• Metodi setter/getter : metodi per modificare oppure ottenere i campi privatidella classe.

54 di 97

Controller:

[ MAMController ]

Tipo, obiettivo e funzione del componente : effettuare le operazioni di in-vio/ricezione/lettura sms attraverso il provider Vodafone comunicando con il serverMAM attraverso il MAM client dell’azienda. Come giustificato in precedenza, si èdeciso di implementare la classe utilizzando una comunicazione sincrona.

Relazioni d’uso di altre componenti : implementazioneclasseNet_Sms_Gateway_Controller. Aggregazione con la classe Connection_Properties.Associazione semplice con la classe Sms.

Interfacce e relazioni d’uso da altre componenti : nessuna.

Attività svolte e dati trattati : tramite l’invio di comandi telnet interagiscecon la console del MAM client di propretà dell’azienda permettendo l’invio o laricezione di sms.

Attributi

• clientSocket:Socket : socket per la connessione con il router Vodafone MAM.

• properties:Connection_Properties: proprietà per poter effettuare in modocorretto la connessione.

Metodi

• Sms invioMSG(Sms x): serve ad inviare un sms passato come parametro. Inseguito viene ritornato con il campo id aggiornato.

• Vector<Sms> reportMsgRicevuti(): richiede al server Vodafone di ricevereun riassunto elencante la lista degli sms finora ricevuti. Gli sms vengonoinseriti in ordine temporale di ricezione all’interno del vettore ritornato comeparametro.

• Vector<Sms> reportMsgInviati(): richiede al server Vodafone di ricevere unriassunto elencante la lista degli sms finora inviati. Gli sms vengono inseritiin ordine temporale di invio all’interno del vettore ritornato come parametro.

[ AIMONController ]

Tipo, obiettivo e funzione del componente : effettuare le operazioni di invio/ri-cezione/lettura sms attraverso il provider Aimon.

Relazioni d’uso di altre componenti : implementazioneclasseNet_Sms_Gateway_Controller. Aggregazione con la classe Connection_Properties.Associazione semplice con la classe Sms.

55 di 97


Attività svolte e dati trattati : permette di collegarsi/scollegarsi al provider Aimonattraverso le API fornite dalla società utilizzando il protocollo Http.

Attributi

• properties:Connection_Properties: proprietà per poter effettuare in modo correttola connessione.

• send_url:String : indirizzo http per effettuare l’invio di sms.

• in_url:String : indirizzo http per ottenere il report degli sms ricevuti.

• credit_url:String : indirizzo http per controllare il credito residuo dell’accountAimon.

• report_url:String : indirizzo http per ottenere il report degli sms inviati.

Metodi

• Sms invioMSG(Sms x): serve ad inviare un sms passato come parametro. In seguitoviene ritornato con il campo id aggiornato.

• Vector<Sms> reportMsgRicevuti(): richiede al server Aimon di ricevere un riassun-to elencante la lista degli sms finora ricevuti tramite ricezione Http post. Gli smsvengono inseriti in ordine temporale di ricezione all’interno del vettore ritornatocome parametro.

• Vector<Sms> reportMsgInviati(): richiede al server Aimon di ricevere un riassun-to elencante la lista degli sms finora inviati. Gli sms vengono inseriti in ordinetemporale di invio all’interno del vettore ritornato come parametro.

• getCredit():float : richiede al server Aimon di visualizzare il credito residuo dell’ac-count utilizzato.

[ ModelHibernateDaoSupport ]

Tipo, obiettivo e funzione del componente : permette di eseguire le operazionidi lettura/scrittura su database tramite la tecnologia offerta da Hibernate.

Relazioni d’uso di altre componenti : implementazione dell’interfaccia SmsDao.Estensione della classe HibernateDaoSupport. Associazione semplice con la classe MAM-Controller e AIMONController.


56 di 97

Attività svolte e dati trattati : implementa la classe HibernateDaoSupport la qualequale traduce operazioni di aggiornamento, lettura, scrittura, interrogazione delle classimappate nel linguaggio specifico del database utilizzato.

Attributi Nessuno.

Metodi

• insertSms(Sms x): inserisce un nuovo sms all’interno del database.

• updateSms(Sms c): aggiorna lo stato di un certo sms all’interno del database.

• findIdSms(String id): cerca all’interno del database un sms tramite il suo id.

• findAllSms(): restituisce tutti gli sms all’interno del database.

• deleteSms(String id): elimina un sms all’interno del database tramite il suo id.

• SmsCount(): restituisce il numero di sms presenti nel database.

57 di 97

6.3 Dettaglio modifiche apportate al softwareSMSTelerete

Il software è stato sviluppato utilizzando il linguaggio Java con l’integrazione del fra-mework Spring, Hibernate e le code JMS.

6.3.1 Code JMS

Il progetto è stato realizzato utilizzando le API di Java Message Service (JMS) e sfrut-tando le funzionalità messe a disposizione dal Message Oriented Middleware (MOM)ActiveMQ, un middleware open source che supporta le specifiche 1.1 di JMS.Un middleware cooperativo è un componente software che si posiziona in un’architettu-ra di rete tra lo strato di trasporto e quello di applicazione per facilitare l’elaborazionecooperativa: viene richiamato dall’applicazione in fase esecutiva e sgrava l’applicazioneda pesanti compiti di gestione non strettamente legati alle sue funzionalità operativespecifiche. Questo strato software funge da intermediario tra le diverse applicazioni, for-nendo ad esse un’interfaccia standard per usufruire dei propri servizi. Ogni applicazioneche usufruisce di un middleware può dunque essere sviluppata senza preoccuparsi deidettagli della comunicazione.Un Message Oriented Middleware è una tecnologia di middleware che permette la comu-nicazione con scambio di messaggi tra due o più applicazioni.Le applicazioni non interagiscono direttamente tra di loro in quanto il mittente ed ildestinatario dell’informazione non devono necessariamente essere a conoscenza l’uno del-l’altro: è il MOM (Message Oriented Middleware) che riceve i messaggi dal produttoredell’informazione e li recapita ai relativi consumatori dopo opportune trasformazioni.La caratteristica più rilevante di un middleware orientato ai messaggi risiede dunquenella possibilità di asincronicità della comunicazione, permettendo il disaccoppiamentospaziale e temporale fra i comunicanti: mittente e ricevente per comunicare non devononecessariamente essere disponibili allo stesso tempo (comunicazione distribuita debol-mente accoppiata).I messagging system supportano due modelli di base per la gestione dei messaggi: Point-To-Point e Publish/Subscribe. Nel modello Point-To-Point il produttore invia messaggia una particolare coda (Queue) e un consumatore legge i messagi da questa coda. Inquesto modello il produttore conosce la destinazione dei messaggi e invia i messaggi di-rettamente alla coda del consumatore.Principali caratteristiche del modello Point-To-Point:

• Quando un mittente invia un messaggio a una Queue, essa lo consegna solo alprimo destinatario che cerca di ricevere un messaggio da quella Queue. Se nessundestinatario è attivo per la Queue nel momento in cui un mittente invia un mes-saggio, questo viene conservato dal Middleware finché non si attiva un destinatario(o finché non scade il time-to-live del messaggio, se questo è stato impostato).

• Ogni messaggio è ritenuto ricevuto (acknowledged) quando un consumatore lo harecuperato.

58 di 97

Figura 6.4: Modello Point-To-Point.

Il modello Publish/Subscribe supporta la pubblicazione di messaggi in un particolareTopic (discussione). In questo modello, nè il publisher nè il subscriber sono a conoscenzal’ uno dell’ altro.Principali caratteristiche del modello Publish/Subscribe :

• Più consumatori possono ricevere il messaggio. Il modello consente quindi unacomunicazione uno-a-molti e si adatta bene in tutte quelle situazioni in cui èimprecisato il numero delle entità che interagiscono nel sistema.

• C’è dipendenza temporale tra publisher e subscriber. Il publisher deve creareuna subscription affinché i subscribers possano registrarsi. Un subscriber che siè sottoscritto ad un topic potrà consumare solamente messaggi pubblicati dopola sua sottoscrizione. Il subscriber deve rimanere contemporaneamente attivo perricevere i messaggi, a meno che non abbia stabilito una durable subscription. Intal caso, i messaggi pubblicati mentre il subscriber non è connesso vengono ricevutiquando questo si riconnette.

Figura 6.5: Modello Publish/Subscribe.

JMS è un insieme di API che consentono lo scambio di messaggi tra applicazoni Javadistribuite nella rete. In sostanza JMS fornisce un metodo standard tramite il quale leapplicazioni possono creare, inviare e ricevere i messaggi usando un message orientedmiddleware.Un sistema architettato con JMS è costituito dai seguenti elementi:

• Client JMS: programma in linguaggio Java che invia o riceve messaggi JMS.

• Messaggio: raggruppamento di dati che viene inviato da un client a un altro.

59 di 97

• JMS Provider: sistema di messaggistica che implementa la specifica JMS e realizzafunzionalità aggiuntive per l’ amministrazione e il controllo della comunicazioneattraverso messaggi.

• Administered objects: sono oggetti preconfigurati da un amministratore ad uso deiclient. Incapsulano la logica specifica del JMS provider nascondendola ai client, ga-rantendo maggiore portabilita al sistema complessivo. Fanno parte del middlewarelato server e sono usati dai client per inizializzare la comunicazione.

• ConnectionFactory : è un administered object utilizzato da un client per realizzarela connessione con il provider.

• Destination (queue/topic): è un administered object che svolge il ruolo di “depo-sito” in cui i mittenti possono lasciare i messaggi che creano e da cui i destinataripossono recuperare i messaggi. Le destinazioni possono essere usate contempora-neamente da più mittenti e da più destinatari. A seconda del tipo di destinazioneusato (queue o topic), la consegna dei messaggi avviene secondo modalità diverse(point to point o publish/subscribe).

Le applicazioni JMS hanno qualità intrinseche che sono sintetizzabili in:

• Asincronicità della comunicazione : il provider JMS consegna i messaggi al clientappena quest’ ultimo si è reso disponibile. Il provider li consegna senza che ilreceiver abbia effettuato una richiesta specifica.

• Affidabilità della comunicazione: JMS può assicurare che un messaggio sia conse-gnato una ed una sola volta.

• Quality of Service configurabile: le API JMS prevedono differenti livelli di affida-bilità per considerare molteplici scenari applicativi.

• Robustezza ai cambiamenti: sono presenti tipologie differenti di messaggi e featurespersonalizzabili.

6.3.2 Struttura

All’avvio del software vengono create le code Jms appartenenti a due società venditricidi titoli di viaggio e un’ulteriore coda, SmsOut, in cui vengono inoltrati messaggi daessere inviati con protocollo sms.La parte principale del software è costituita da una servlet Java la quale controlla conti-nuamente se nella coda SmsOut sono presenti richieste di invio sms da parte delle società.In tal caso utilizza il MAM client per effettuare tali operazioni.In seguito viene attivato il report degli sms inviati e ricevuti collegati al MAM clientdell’azienda ed inviate delle notifiche di stato su gli sms inviati/ricevuti alle due societànelle rispettive code. Nello specifico:

1. Un utente invia un sms al numero della Mam Vodafone per la ricezione, riportandoall’inizio dell’sms la sigla corrispondente al servizio che richiede.

2. La servlet, dopo aver eseguito il report degli sms ricevuti, legge l’sms appena inviatodall’utente, e se ben formattato, lo inoltra alla società che offre il servizio descrittonell’sms stesso.

3. La società interessata riceve il messaggio e dopo aver effettuato le varie operazioni,come ad esempio il pagamento per conto del cliente, invia nella coda jms Sm-sOut un sms da inviare al cliente contenente la ricevuta del pagamento (codice delbiglietto da presentare al controllore).

60 di 97

4. La servlet gestisce la richiesta di invio sms da parte della società.

5. Il cliente riceve l’sms.

Figura 6.6: Code Jms iniziali software SMSTelerete.

Ecco il codice sorgente della servlet:

1 package i t . t e l e r e t e . sms t e l e r e t e . web . task ;

3 import i t . t e l e r e t e . sms t e l e r e t e . ap i . c o n t r o l l e r . AIMONController ;import i t . t e l e r e t e . sms t e l e r e t e . ap i . c o n t r o l l e r . MAMController ;

5 import i t . t e l e r e t e . sms t e l e r e t e . ap i . c o n t r o l l e r . S e r v i z i oCon t r o l l e r ;import i t . t e l e r e t e . sms t e l e r e t e . ap i . model . S e r v i z i o ;

7import java . t ex t . SimpleDateFormat ;

9 import java . u t i l . Calendar ;import java . u t i l . S t r ingToken ize r ;

11 import java . u t i l . TimerTask ;

13 import javax . annotat ion . Resource ;import javax . jms . Des t inat i on ;

15 import javax . jms . JMSException ;import javax . jms . MapMessage ;

17 import javax . jms . Message ;import javax . jms . MessageConsumer ;

19 import javax . jms . Se s s i on ;import javax . jms . TextMessage ;

21import org . apache . l o g 4 j . Logger ;

23 import org . quartz . JobExecutionContext ;import org . quartz . JobExecutionException ;

25 import org . springframework . beans . f a c t o r y . annotat ion . Autowired ;import org . springframework . jms . core . JmsTemplate ;

27 import org . springframework . s chedu l ing . quartz . QuartzJobBean ;

29 public class SMSTask extends TimerTask {

31 private Logger l o gg e r = Logger . getLogger ( this . g e tC la s s ( ) ) ;

61 di 97

33 //CONTROLLER VODAFONE@Autowired

35 private MAMController mamController ;

37 //CONTROLLER AIMON@Autowired

39 private AIMONController a imonContro l l e r ;

41 @Autowiredprivate S e r v i z i oCon t r o l l e r s e r v i z i oC on t r o l l e r ;

43@Resource (name = " jmsTemplateLocalhost " )

45 private JmsTemplate jmsTemplate ;

47 public void run ( ) {

49 try {

51 i f ( ! mamController . i sConnected ( ) ) {l o gg e r . i n f o ( "mamController Login" ) ;

53 mamController . l o g i n ( ) ;}

55 } catch ( Exception e ) {l o gg e r . e r r o r ( "Errore : " + e . getMessage ( ) ) ;

57 }

59 while (1 > 0) {

61 // l o g g e r . i n f o ("TASK mamController AVVIO repor tMsgRicevut i ") ;

63 try {

65 l ogg e r . i n f o ( "TASK mamController AVVIO reportMsgRicevut i " ) ;

67 //∗∗∗∗∗∗AVVIO IL REPORT DEGLI SMS RICEVUTI∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗mamController . reportMsgRicevut i ( ) ;

69 //OPPURE :// aimonContro l l er . repor tMsgRicevut i ( ) ;

71Thread . s l e e p (3000) ;

73l o gg e r . i n f o ( "TASK mamController FINE reportMsgRicevut i ( S leep ) " ) ;

75l o gg e r . i n f o ( "TASK mamController AVVIO repor tMsgInv ia t i " ) ;

77 System . out . p r i n t l n ( "comando repor t i n v i a t i " ) ;//∗∗∗∗∗∗∗AVVIO IL REPORT DEGLI SMS INVIATI∗∗∗∗∗∗∗∗∗∗∗∗∗

79 mamController . r epor tMsgInv ia t i ( ) ;//OPPURE:

81 // aimonContro l l er . r epor tMsg Inv i a t i ( ) ;l o gg e r . i n f o ( "TASK mamController FINE repor tMsgInv ia t i " ) ;

83Thread . s l e e p (3000) ;

85MapMessage message = null ;

87 l o gg e r . i n f o ( "INIZO CICLO INVIO MESSAGGI" ) ;

89

91 for ( int c i = 0 ; c i < 10 ; c i++) {jmsTemplate . setReceiveTimeout (100) ;

93 message = null ;try {

62 di 97

95 message = (MapMessage ) jmsTemplate. r e c e i v e ( "smsOut . queue" ) ;

97 // l o g g e r . i n f o (" Messaggio (" + c i + ") : " + message ) ;} catch ( Exception e ) {

99 l ogg e r . i n f o ( "Nessun messaggio da sp ed i r e " ) ;}

101 i f ( message != null ) {l o gg e r . i n f o ( "Messaggio r i c evu to " + message ) ;

103 St r ing dest = message . g e tS t r i ng ( " dest " ) ;S t r ing body = message . g e tS t r i ng ( "body" ) ;

105 St r ing cod i c e = message . g e tS t r i ng ( " cod i c e " ) ;Long i d S e r v i z i o = message . getLong ( " i d S e r v i z i o " ) ;

107S e r v i z i o s e r v i z i o = s e r v i z i oC on t r o l l e r . f indById ( i d S e r v i z i o ) ;

109l o gg e r . i n f o ( "Dest : " + dest ) ;

111 l o gg e r . i n f o ( "Body : " + body ) ;l o gg e r . i n f o ( "Codice : " + cod i c e ) ;

113 l o gg e r . i n f o ( " S e r v i z i o : " + i d S e r v i z i o ) ;

115 mamController . invioMsg ( dest , body , codice , s e r v i z i o ) ;}

117}

119

121 l ogg e r . i n f o ( "FINE CICLO INVIO MESSAGGI" ) ;

123Message message3 = null ;

125 // ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ c o n t r o l l o l a coda SMSInLowPriority ∗∗∗∗∗∗∗∗∗∗∗∗∗∗for ( int i = 0 ; i < 10 ; i++) {

127 jmsTemplate . setReceiveTimeout (100) ;message3 = null ;

129 try {message3 = jmsTemplate . r e c e i v e ( "SMSInLowPriority" ) ;

131 // l o g g e r . i n f o (" Messaggio (" + i + ") : " + message ) ;} catch ( Exception e ) {

133 l ogg e r . i n f o ( "Nessun messaggio da sp ed i r e " ) ;}

135 i f ( message3 != null ) {l o gg e r . i n f o ( "Messaggio r i c evu to " + message3 ) ;

137 i f ( message3 instanceof TextMessage ) {TextMessage message2 = ( TextMessage ) message3 ;

139 St r ing y=message2 . getText ( ) ;S t r ingToken ize r s t = new Str ingToken ize r (y , " , " ) ;

141 St r ing cf_id=s t . nextToken ( ) ;s t . nextToken ( ) ;

143 s t . nextToken ( ) ;s t . nextToken ( ) ;

145 St r ing d e s t i n a t a r i o=s t . nextToken ( ) ;S t r ing body=s t . nextToken ( ) ;

147 s t = new Str ingToken ize r ( cf_id , " : " ) ;s t . nextToken ( ) ;

149 cf_id=s t . nextToken ( ) ;s t = new Str ingToken ize r ( d e s t i n a t a r i o , " : " ) ;

151 s t . nextToken ( ) ;S t r ing x=s t . nextToken ( ) ;

153 d e s t i n a t a r i o=x . r ep l a c e ( "\"" , "" ) ;d e s t i n a t a r i o=d e s t i n a t a r i o . r ep l a c e ( "+" , "" ) ;

155 s t = new Str ingToken ize r ( body , " : " ) ;s t . nextToken ( ) ;

157 St r ing u=s t . nextToken ( ) ;

63 di 97

body=u . r ep l a c e ( "\"" , "" ) ;159

System . out . p r i n t l n ( cf_id ) ;161 System . out . p r i n t l n ( d e s t i n a t a r i o ) ;

System . out . p r i n t l n ( body ) ;163

165 S e r v i z i o s e r v i z i o = s e r v i z i oC on t r o l l e r . f indById (7 l ) ;

167l o gg e r . i n f o ( "Dest : " + d e s t i n a t a r i o ) ;

169 l o gg e r . i n f o ( "Body : " + body ) ;l o gg e r . i n f o ( "Codice : " + cf_id ) ;

171 l o gg e r . i n f o ( " S e r v i z i o : " + s e r v i z i o ) ;

173mamController . invioMsg ( d e s t i n a t a r i o , body , cf_id , s e r v i z i o ) ;

175 //OPPURE:// aimonContro l l er . invioMsg ( d e s t i n a t a r i o , body , cf_id , s e r v i z i o ) ;

177 }}

179} }catch ( Exception e ) {

181try {

183 mamController . l ogout ( ) ;Thread . s l e e p (3000) ;

185 mamController . l o g i n ( ) ;} catch ( Exception e3 ) {

187 l ogg e r . e r r o r ( "Errore SMSTASK Login/Logout : "+ e . getLoca l i zedMessage ( ) ) ;

189}

191 l ogg e r . e r r o r ( "Errore : " + e . getLoca l i zedMessage ( ) ) ;

193 }

195

197 }

199 }}

SMSTask.java

6.3.3 Modifiche

Le modifiche apportate per permettere al software “SMSTelerete” di interagire con il nuo-vo servizio “Campagne Sms” sono state ideate rispecchiando la stessa logica delle codegià utilizzata in precedenza e consistono nell’aggiungere tramite Spring due nuove codeJMS: SMSInLowPriority in cui il servizio campagne inoltrerà i propri messaggi daessere inviati tramite sms e la coda SMSOutLowPriorityStatus in cui l’applicativoJava invierà aggiornamenti sugli sms inviati per conto del servizio campagne.Inoltre è stato aggiunto un nuovo connettore per poter comunicare con le librerie Stomputilizzate per gestire le code JMS nel linguaggio php.Nel codice precedente si nota l’aggiunta nella servlet Java di un controllo nella nuovacoda di richieste di invio sms per quanto riguarda il servizio campagne.

64 di 97

Ecco il file xml con le modifiche alle code JMS:

<?xml version=" 1 .0 " encoding="UTF−8"?>2 <beans xmlns=" ht tp : //www. springframework . org /schema/beans"

xmlns :x s i=" ht tp : //www.w3 . org /2001/XMLSchema−i n s t anc e "4 xs i : s chemaLocat ion=" ht tp : //www. springframework . org /schema/beans

h t tp : //www. springframework . org /schema/beans/ spr ing−beans −3.0 . xsd6 h t tp : // activemq . apache . org /schema/ core h t tp : // activemq . apache . org /

schema/ core /activemq−core . xsd">

8

10 <!−− ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ SMSOUT ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ −−>

12 <bean id=" connect ionFactoryLoca lhos t " c l a s s="org . apache . activemq .ActiveMQConnectionFactory"><property name="brokerURL" value="${activeMQ . brokerURL}"/>

14 </bean>

16 <bean id=" jmsTemplateLocalhost "c l a s s="org . spr ingframework . jms . core . JmsTemplate">

18 <property name=" connect ionFactory " r e f=" connect ionFactoryLoca lhos t " /><property name=" rece iveTimeout " value="60000" />

20 </bean>

22 <bean id="destinationCodaSMSOut" c l a s s="org . apache . activemq . command .ActiveMQQueue">

<const ructor−arg value="smsOut . queue" />24 </bean>

26 <!−− //////////////////////// APS //////////////////////// −−>

28 <bean id="destinationCodaSMSInAPS" c l a s s="org . apache . activemq . command .ActiveMQQueue">

<const ructor−arg value="smsInAPS . queue" />30 </bean>

32 <bean id="destinationCodaSMSOutStatusAPS" c l a s s="org . apache . activemq .command . ActiveMQQueue">

<const ructor−arg value="smsOutStatusAPS . queue" />34 </bean>

36 <!−− //////////////////////// AIM //////////////////////// −−>

38 <bean id="destinationCodaSMSInAIM" c l a s s="org . apache . activemq . command .ActiveMQQueue">

<const ructor−arg value="smsInAIM . queue" />40 </bean>

42 <bean id="destinationCodaSMSOutStatusAIM" c l a s s="org . apache . activemq .command . ActiveMQQueue">

<const ructor−arg value="smsOutStatusAIM . queue" />44 </bean>

46 <!−− //////////////////////// CAMPAGNE //////////////////////// −−>

48

50 <bean id="destinationCodaSMSOutStatusCAMPAGNE" c l a s s="org . apache . activemq. command . ActiveMQQueue">

<const ructor−arg value="SMSOutLowPriorityStatus" />52 </bean>

65 di 97

54 <bean id="destinationCodaSMSInCAMPAGNE" c l a s s="org . apache . activemq .command . ActiveMQQueue">

<const ructor−arg value="SMSInLowPriority" />56 </bean>

58 </beans>

activemq.xml

6.4 Servizio Campagne Sms

Di seguito viene descritta l’implementazione del servizio, soffermandosi sulle singolefunzionalità sviluppate. Nello specifico tutti i requisiti di tipo obbligatorio sono statisoddisfatti.

6.4.1 Funzionalità prodotto

Tramite il prodotto Campagne Sms è possibile inviare sms singoli oppure sms multipliattraverso liste di contatti; creare campagne sms impostando la lista contatti e la datadi invio, visualizzare un report con relativo stato degli sms inviati.

6.4.2 Requisiti di sistema

Per avviare il progetto su una qualsiasi macchina si deve:

1. Prima di tutto installare sulla macchina un server Apache con Php.

2. Importare il database sql del progetto da file.

3. Importare sul server la cartella contenente il progetto e l’installazione di Joomla!.

6.4.3 Joomla!

Come richiesto dall’azienda, il prodotto è stato sviluppato in linguaggio php attraversol’uso della piattaforma Joomla!. In questo modo è possibile in futuro modificarlo moltofacilmente. Per il layout si è utilizzato il sistema di default di composizione per moduli.Il layout consiste di un semplice menú centrale costituito da una voce per ogni operazionepossibile.

Plugin

Unico plugin utilizzato in aggiunta a quelli di default è Chronoforms1 per la gestionedi forms lato backend. La sua adozione è stata decisa per dare la possibilità ad esternidi poter modificare con semplicità in futuro le forms esistenti. Verrà spiegato in seguitoil suo utilizzo nelle singole funzionalità.

Librerie esterne

In aggiunta a Joomla! si è utilizzata la libreria Stomp2 per la comunicazione in linguag-gio php con le code JMS, unica soluzione esistente per permettere tale comunicazione.Per la gestione dei contatti e delle liste è stato utilizzato lo script AddressBook3 poiché

1http://www.chronoengine.com//2http://stomp.fusesource.org/documentation/php/book.html3http://sourceforge.net/projects/php-addressbook/

66 di 97

http://www.chronoengine.com//

http://stomp.fusesource.org/documentation/php/book.html

http://sourceforge.net/projects/php-addressbook/

open source e di facile utilizzo. Esso è visualizzabile in Joomla! attraverso un IframeWrapper, passando come parametro alla pagina iniziale l’id dell’utente loggato in quel-l’istante.

6.4.4 Operazioni

Registrazione/Login/Logout

Le operazioni di gestione account utente sono state implementate attraverso le funzio-nalità offerte di default dalla piattaforma Joomla!.

Invio singolo sms

Dopo aver effettuato l’accesso è possibile inviare un singolo sms nella pagina apposita.

Figura 6.7: Pagina invio sms singolo.

Tale funzionalità è stata implementata tramite una semplice form creata con chrono-forms. Alla pressione del campo Submit ci si connette al server ActiveMq della servletJava e si invia un nuovo messaggio con i dati inviati in post dalla form alla coda JMSSMSInLowPriority. Viene inoltre aggiunto un nuovo sms nella tabella SmsInviati.

67 di 97

Figura 6.8: Form di invio sms singolo nel pannello Chronoforms.

Il seguente codice php si trova nel modulo Custom Code - aggiunta sms jmsdella form come si nota nella figura precedente.

<?php2

$nome = $_POST[ ’ mittente ’ ] ;4 $dest = $_POST[ ’ d e s t i n a t a r i o ’ ] ;

$corpo = $_POST[ ’ body ’ ] ;6

// inc l ude a l i b r a r y8 require_once ( JPATH_BASE .DS. ’ i n c l ud e s ’ .DS. ’ Stomp . php ’ ) ;

require_once ( JPATH_BASE .DS. ’ i n c l ud e s ’ .DS. ’Map. php ’ ) ;10

// make a connect ion12 try {

$con = new Stomp( ’ tcp :// l o c a l h o s t :61615 ’ ) ;14 } catch ( StompException $e ) {

echo " S e r v i z i o non d i s p o n i b i l e " ;16 die ( ’ Connection f a i l e d : ’ . $e−>getMessage ( ) ) ;

echo " S e r v i z i o non d i s p o n i b i l e " ;18 }

// connect20 $con−>connect ( ) ;

// send a message to the queue22

24$user =& JFactory : : getUser ( ) ;

26 $ui_id=$user−>id ;

28 $data = $_SERVER[ ’REQUEST_TIME’ ] ;$data= date ( ’Y−m−d H: i : s ’ , $data ) ;

30$db2 =& JFactory : : getDBO( ) ;

32 $query2 = "INSERT INTO SmsInv iat i ( c f_created , cf_modif ied , cf_user_id ,mittente , d e s t i n a t a r i o , body , s t a tu s )

68 di 97

VALUES ( ’ $data ’ , ’ $data ’ , ’ $ui_id ’ , ’ $nome ’ , ’ $dest ’ , ’ $corpo ’ , ’ queued ’ )" ;

34 $db2−>setQuery ( $query2 ) ;$db2−>query ( ) ;

36

38 $body = array ( " cf_id "=>$db2−>i n s e r t i d ( ) , " c f_modi f ied "=>$data , " s t a tu s "=>"queued" , " mittente "=>$nome , " d e s t i n a t a r i o "=>$dest , "body"=>$corpo , "s e r v i z i o "=>"campagne" ) ;$header = array ( ) ;

40 $header [ ’ t rans fo rmat ion ’ ] = ’ jms−map−j s on ’ ;$mapMessage = new StompMessageMap( $body , $header ) ;

42 $con−>send ( "/queue/SMSInLowPriority" , $mapMessage ) ;echo " R i ch i e s t a d i i nv i o sms generata corret tamente " ;

44 // d i s connec t$con−>di sconnec t ( ) ;

46

48?>

invio–singolo.php

69 di 97

Invio sms multiplo

Dopo aver effettuato l’accesso è possibile inviare sms multipli nella pagina apposita.

Figura 6.9: Pagina invio sms multiplo.

Tale funzionalità è stata implementata tramite una semplice form creata con chrono-forms. Alla pressione del campo Submit ci si connette al server ActiveMq della servletJava e si invia un nuovo messaggio con i dati inviati in post dalla form alla coda JMSSMSInLowPriority per ogni contatto presente nella lista selezionata. Vengono inoltreaggiunti nuovi sms nella tabella SmsInviati.

70 di 97

Report sms inviati

Dopo aver effettuato l’accesso è possibile visualizzare il report degli sms inviati nellapagina apposita.

Figura 6.10: Pagina report sms inviati.

Tale funzionalità è stata implementata tramite una semplice form creata con chrono-forms. Al caricamento della pagina vengono visualizzati tutti gli sms inviati precedente-mente e verificato tramite la coda JMSSMSOutLowPriorityStatus se il loro stato è stato aggiornato. Infatti nel momento in cuii messaggi vengono inviati effettivamente dall’applicazione Java, essa inoltra una notificacon lo stato del messaggio in tale coda.

1 <?php// inc l ude a l i b r a r y

3 require_once ( JPATH_BASE .DS. ’ i n c l ud e s ’ .DS. ’ Stomp . php ’ ) ;require_once ( JPATH_BASE .DS. ’ i n c l ud e s ’ .DS. ’Map. php ’ ) ;

5 $db =& JFactory : : getDBO() ;

7 // make a connect iont ry {

9 $con = new Stomp( ’ tcp :// l o c a l h o s t :61615 ’ ) ;} catch ( StompException $e ) {

11 die ( ’ Connection f a i l e d : ’ . $e−>getMessage ( ) ) ;

71 di 97

echo " S e r v i z i o non d i s p o n i b i l e " ;13 }

$con−>connect ( ) ;15 $con−>setReadTimeout (2 ) ;

$con−>subs c r i b e ( "/queue/SMSOutLowPriorityStatus" , array ( ’t rans fo rmat ion ’ => ’ jms−map−j s on ’ ) ) ;

17while ( $msg = $con−>readFrame ( ) ) {

19$array=$msg−>map ;

21$aa=(array_pop(array_pop( $array ) ) ) ;

23 $modi f i ed=array_pop(array_pop(array_pop( $aa ) ) ) ;$ s ta tu s=array_pop(array_pop(array_pop( $aa ) ) ) ;

25 $d e s t i n a t a r i o=array_pop(array_pop(array_pop( $aa ) ) ) ;$ id=array_pop(array_pop(array_pop( $aa ) ) ) ;

27 $ t e s t o=array_pop(array_pop(array_pop( $aa ) ) ) ;$mittente=array_pop(array_pop(array_pop( $aa ) ) ) ;

29 $no_quotes=st r_rep lace ( ’ " ’ , ’ ’ , $modi f i ed ) ;$phpdate = strtotime ( $no_quotes ) ;

31 $mysqldate = date ( ’Y−m−d H: i : s ’ , $phpdate ) ;

33i f ( $ s ta tu s=="S" )

35 { $ s ta tu s=" de l i v e r e d " ; }$query="UPDATE SmsInv iat i SET cf_modif ied=’$mysqldate ’ , s t a tu s =’ $ s ta tu s ’

WHERE cf_id=’ $ id ’ " ;37 $db−>setQuery ( $query ) ;

$db−>query ( ) ;39

//mark the message as r e c e i v ed in the queue41 $con−>ack ($msg ) ;

43 }

45 $con−>di sconnec t ( ) ;

47

49 ?>

report–inviati.php

72 di 97

Liste contatti

Dopo aver effettuato l’accesso è possibile gestire i propri contatti e liste nella paginaapposita.

Figura 6.11: Pagina contatti.

Per la gestione dei contatti e liste si è utilizzato AddressBook4 visualizzabile inJoomla! attraverso un Iframe Wrapper, passando come parametro alla pagina inizialel’id dell’utente loggato in quell’istante.

4http://sourceforge.net/projects/php-addressbook/

73 di 97

http://sourceforge.net/projects/php-addressbook/

Figura 6.12: Iframe Wrapper.

Campagne Sms

Dopo aver effettuato l’accesso è possibile gestire campagne sms nella pagina apposita.

Figura 6.13: Pagina campagne sms.

Tale funzionalità è stata implementata tramite una semplice form creata con chro-noforms. Alla pressione del campo Submit viene aggiuna una nuova campagna nellatabella Campagne.

74 di 97

Figura 6.14: Form di creazione campagne nel pannello Chronoforms.

Per quanto riguarda la gestione delle campagne, una volta create viene utilizzatala funzionalità CronTab offerta dai sistemi Linux. Tramite esso, è infatti possibileeseguire ogni minuto un determinato script php. A differenza del linguaggio Java cheoffre diverse possibilità nelle pianificazioni programmate questa è stata l’unica soluzionetrovata. Nel nostro caso eseguiamo uno script che si occupa di controllare se esistonocampagne ancora da gestire con data di invio precedente a quella del controllo. In casopositivo vengono inviati i relativi sms ed impostata come eseguita.Ecco di seguito il codice:

1 <?php

3 include ( "Stomp . php" ) ;include ( "Map. php" ) ;

5// make a connect ion

7 try {$con = new Stomp( ’ tcp :// l o c a l h o s t :61615 ’ ) ;

9 } catch ( StompException $e ) {die ( ’ Connection f a i l e d : ’ . $e−>getMessage ( ) ) ;

11 echo " S e r v i z i o non d i s p o n i b i l e " ;}

13 // connect$con−>connect ( ) ;

15 // send a message to the queue

17 $dbhost = ’ l o c a l h o s t ’ ;$dbuser = ’ root ’ ;

19 $dbpass = ’ ’ ;

21 $conn = mysql_connect( $dbhost , $dbuser , $dbpass ) or die ( ’ Error connect ingto mysql ’ ) ;

23 $dbname = ’_DB_’ ;mysql_select_db ( $dbname) ;

25$data = $_SERVER[ ’REQUEST_TIME’ ] ;

75 di 97

27 $today= date ( ’Y−m−d H: i : s ’ , $data ) ;

29

31$ r e s u l t = mysql_query( "SELECT ∗ FROM Campagne WHERE data <’$today ’ AND

sta tu s =’queued ’ " ) ;33

while ( $row1 = mysql_fetch_array ( $ r e s u l t ) )35 {

$ l i s t a=$row1 [ ’ l i s t a ’ ] ;37 $cf_id=$row1 [ ’ c f_id ’ ] ;

$ d e s t i n a t a r i = mysql_query( "SELECT id FROM address_in_groups WHEREgroup_id=’ $ l i s t a ’ " ) ;

39while ( $row2 = mysql_fetch_array ( $ d e s t i n a t a r i ) )

41 {$ id=$row2 [ ’ id ’ ] ;

43 echo $ id ;$ r e s=mysql_query( "SELECT mobile FROM addressbook WHERE id=’ $ id ’ " ) ;

45 $nu=mysql_fetch_array ( $ r e s ) ;$numero_dest=$nu [ ’ mobile ’ ] ;

47 echo $numero_dest ;$user_id=$row1 [ ’ cf_user_id ’ ] ;

49 echo $user_id ;$mittente=$row1 [ ’ mittente ’ ] ;

51 $corpo=$row1 [ ’ body ’ ] ;$query=mysql_query( "INSERT INTO SmsInv iat i ( c f_created , cf_modif ied ,

cf_user_id , mittente , d e s t i n a t a r i o , body , s t a tu s )53 VALUES (NOW() , NOW() , ’ $user_id ’ , ’ $mittente ’ , ’ $numero_dest ’ , ’

$corpo ’ , ’ queued ’ ) " ) ;

55 $body=array ( " cf_id "=>mysql_insert_id ( ) , " cf_modi f ied "=>$today , " s t a tu s "=>"queued" , " mittente "=>$mittente , " d e s t i n a t a r i o "=>$numero_dest , "body"=>$corpo ) ;$header = array ( ) ;

57 $header [ ’ t rans fo rmat ion ’ ] = ’ jms−map−j s on ’ ;$mapMessage = new StompMessageMap( $body , $header ) ;

59 $con−>send ( "/queue/SMSInLowPriority" , $mapMessage ) ;mysql_query( "UPDATE Campagne SET s ta tu s =’ d e l i v e r e d ’

61 WHERE cf_id =’$cf_id ’ " ) ;}

63}

65 echo " R i ch i e s t a d i i nv i o sms generata corret tamente " ;// d i s connec t

67 $con−>di sconnec t ( ) ;

69

71?>

controlla_campagne.php

76 di 97

Capitolo 7

Test e collaudo finale

7.1 Test

In questa attività si eseguono prove pratiche sul software, così da evidenziare eventualibug. Tali attività hanno lo scopo di dimostrare che l’applicativo funziona senza generareerrori (Verifica) e di controllare (Validazione) che dato un input si ottenga un certooutput, secondo i requisiti a progetto.

Dato l’impiego di Maven per la risoluzione delle librerie Java, la fase di test è statacompletata con l’integrazione dei plugin da esso offerti i quali permettono l’utilizzo delFramework Junit1.Dopo aver ideato i vari test attraverso l’apposito comando Maven è possibile visualizzareil report di tali test.Descriveremo qui nel dettaglio solo i test di sistema, nonostante siano stati eseguiti an-che test di unità e di integrazione, in modo da evidenziare il tracciamento Requisiti-Test.

7.1.1 Test di Unità

L’obiettivo primario del test di unità consiste nell’isolare le unità software nell’applica-zione, per stabilire se funziona esattamente come previsto.Si dice unità la più piccola parte di software testabile nell’applicazione. Ogni singolaunità viene sottoposta a test prima di poter essere integrata in moduli per l’esecuzionedei test di integrazione. Sebbene sembri contradditorio, si può misurare la validità di untest di unità dalla quantità di errori che il test stesso riesce a rilevare.Generalmente l’implementazione di questi test viene eseguita in parallelo all’implemen-tazione di driver e stub utili allo sviluppo dei test di unità stessa.I driver e gli stub sono unità fittizie che simuleranno i primi le unità chiamanti, i secondiunità chiamate. Questi due elementi sono indispensabili in quanto la loro implementa-zione (che deve essere il più semplice possibile) va a sostituire unità reali che possonoquindi essere testate autonomamente.Sebbene l’utilizzo dei test di unità consumi molte risorse, tanto da portare alcune aziendea non prenderli in considerazione durante lo sviluppo dei propri prodotti, essi offrono van-taggi innegabili. Consentono, ad esempio, l’automazione del processo di test, riduconole difficoltà di rilevamento degli errori contenuti in parti più complesse dell’applicazionee spesso grazie ad essi viene ottenuta una maggiore copertura di tutti gli aspetti daverificare, poiché l’attenzione viene posta sulle singole unità.

1http://www.junit.org/

77

http://www.junit.org/

7.1.2 Test di Integrazione

I test di integrazione aiutano ad individuare i problemi che si verificano quando due opiù unità vengono combinate.Il test di integrazione può essere effettuato secondo diversi approcci ma le strategie piùdiffuse sono le seguenti:

* L’approccio top-down (dall’alto verso il basso) del test di integrazione richiedeche i moduli di livello più alto siano sottoposti a test e integrati per primi. Inquesto modo è possibile sottoporre a test la logica di alto livello e il flusso di datinelle prime fasi del processo. Inoltre risulta minimizzata la necessità di utilizzarei driver. Tuttavia, la necessità di stub complica la gestione dei test e le utilità dibasso livello vengono così sottoposte a test nelle ultime fasi del processo di sviluppo.

* L’approccio bottom-up (dal basso verso l’alto) richiede innanzitutto il test e l’in-tegrazione delle unità di livello più basso. Tali unità vengono comunemente definitemoduli di utilità. Questo approccio comporta l’esecuzione del test dei moduli diutilità nelle prime fasi del processo di sviluppo e una riduzione degli stub necessari.Lo svantaggio di tale approccio è che la necessità di driver complica la gestione deitest e ritarda il test della logica di alto livello e del flusso di dati.

* Il terzo approccio, definito umbrella (a ombrello), prevede l’esecuzione dei test se-condo i percorsi funzionali dei dati e del flusso di controllo. Il vantaggio principaledi questo approccio consiste nel grado di supporto fornito per il rilascio prelimi-nare di funzionalità limitate. Tuttavia, i punti deboli potenziali dell’approccio inquestione sono significativi, dal momento che è meno sistematico degli altri dueapprocci e richiede quindi un maggior numero di test di regressione.

7.1.3 Test di Sistema

Il test di sistema è un processo che, tramite test, controlla che il software sviluppatoraggiunga gli obbiettivi fissati e i requisiti determinati nella fase di Analisi dei Requisi-ti. Essi saranno oggetto di un collaudo interno. Se i test per un dato requisito desserorisultati negativi, si procederà ricontrollando e modificando i componenti tracciati perquel dato requisito.La maggior parte dei test di seguito descritti sono stati ideati attraverso il plugin di testofferto da Maven.

Ecco un esempio di test effettuato con il plugin Maven per i test:

package i t . t e l e r e t e . sms t e l e r e t e . ap i . c o n t r o l l e r ;2

import org . t e s tng . annotat ions . Test ;4 import i t . t e l e r e t e . sms t e l e r e t e . ap i . App l i ca t i onContext In i t e rTes t ;

import i t . t e l e r e t e . sms t e l e r e t e . ap i . model . S e r v i z i o ;6

public class MAMControllerTest {8

10 //@Test ( dependsOnGroups = { " i n i t " })public void invioMsgTest ( ) throws Exception {

12 MAMController mamController = (MAMController )App l i ca t i onContex t In i t e rTes t. getAppContext ( ) . getBean ( "MAMController" ) ;

14S e r v i z i oCon t r o l l e r s e r v i z i oC on t r o l l e r = ( S e r v i z i oCon t r o l l e r )

App l i ca t i onContex t In i t e rTes t

78 di 97

16 . getAppContext ( ) . getBean ( " s e r v i z i oC on t r o l l e r " ) ;

18 S e r v i z i o s e r v i z i o = s e r v i z i oC on t r o l l e r . f indById (new Long (1 ) ) ;

20 mamController . l o g i n ( ) ;

22 mamController . invioMsg ( "393479074683" , "Testo d i prova" , " r r1 " , s e r v i z i o) ;

mamController . invioMsg ( "393479074683" , "Testo d i prova2" , "yyy1" ,s e r v i z i o ) ;

24mamController . l ogout ( ) ;

26 }}

test.java

Figura 7.1: Esempio esecuzione test con Maven.

79 di 97

Lista dei test di sistema piú importanti effettuati:

Codice test Descrizione Output attesi EsitoMM01 Verifica del corretto invio di

un sms tramite il client MAMVodafone

Codice messaggio di rispostada parte del server

Positivo

MM02 Verifica della corretta ricezio-ne del report messaggi rice-vuti tramite il client MAMVodafone

Messaggio di esito positivo dalserver

Positivo

MM03 Verifica della corretta ricezio-ne del report messaggi in-viati tramite il client MAMVodafone


Positivo

AI01 Verifica del corretto invio diun sms tramite il client Aimon

Codice messaggio di rispostada parte del server

Positivo

AI02 Verifica della corretta ricezio-ne del report messaggi ricevutitramite il client Aimon


Positivo

AI03 Verifica della corretta ricezio-ne del report messaggi inviatitramite il client Aimon


Positivo

CP01 Verifica del corretto invio diun sms singolo

Aggiunta di un nuovo sms instato queued nel report smsinviati

Positivo

CP02 Verifica del corretto invio diun sms multiplo

Aggiunta di nuovi sms in statoqueued nel report sms inviati

Positivo

CP03 Verifica report sms inviati Visualizzazione elenco sms in-viati associati al proprio ac-count

Positivo

CP04 Verifica creazione campagnesms

Visualizzazione degli sms dainviare nel report sms invia-ti solo dopo la data di inviostabiliti

Positivo

80 di 97

Tracciamento test - requisito:

Test RequisitoCP01 FOB1CP02 FOB2CP03 FOB3CP04 FOB5

7.1.4 Collaudo

Il collaudo del prodotto è stato eseguito due volte distinte, la prima in presenza dell’ ing.Federico Filira addetto al reparto “Ricerca e sviluppo” dell’azienda mentre la seconda conil reparto commerciale composto dalle colleghe Braggion e Schillaci. La duplice prova èstata richiesta per evidenziare la comprensione del prodotto anche senza la padronanzadi conoscenze informatiche specifiche.Il risultato del collaudo è stato positivo in entrambi i casi e ha permesso di eviden-ziare la possibilità di implementare in futuro eventuali funzionalità come ad esempiol’importazione di rubriche di contatti all’interno della piattaforma.

81 di 97

82 di 97

Capitolo 8

Sviluppi futuri

Figura 8.1: Implementazioni future.

L’obiettivo futuro consiste nel dotare il software SMSTelerete di alcuni modem gsmcontenenti usim dei 4 provider italiani Vodafone, H3g,Tim e Wind.Per ognuno di questi quattro gestori telefonici esisterà un controller che comunicheràcon il relativo modem attraverso comandi AT. Ogni usim avrà attive delle promozionispecifiche per inviare a costo “zero” sms verso destinatari appartenenti allo stesso gestoretelefonico. Sarà possibile capire l’operatore di appartenenza di un certo destinatarioprima dell’invio dell’sms tramite l’HLR LOOKUP (home locator lookup).Il software nella versione finale funzionerà nel seguente modo. Una volta ricevute richiestedi invio sms verificherà se in esse sia specificato il provider con cui effettuare l’operazione.In caso contrario avvierà una ricerca sul miglior controller da utilizzare per l’invio in baseall’ operatore di appartenenza del destinatario.

HLR LOOKUP:L’HLR costituisce il database su cui un gestore di rete GSM memorizza, in modo per-manente, i dati relativi agli utenti che hanno sottoscritto un abbonamento presso di lui.Ogni azione di tipo amministrativo che il gestore di rete effettua sui dati di utente viene

83

svolta attraverso l’HLR.Esistono vari tipi di HLR, infatti può essere unico o stand-alone, per l’intero networkoppure distribuito nel sistema.

84 di 97

Capitolo 9

Conclusioni

Il capitolo a conclusione di questa tesi vuole esprimere una valutazione personale dellostudente in relazione alle settimane di stage.Tale valutazione si basa su i risultati ottenuti in riferimento agli obiettivi prefissati, intermini di funzionalità sviluppate, in relazione ai requisiti richiesti dal tutor interno e lenuove conoscenze acquisite dallo studente durante l’esperienza lavorativa.

9.1 Conseguimento degli obiettivi prefissati

A lavoro ultimato il prodotto richiesto inizialmente dall’azienda si presenta funzionantee fruibile fin da subito rispecchiando tutti i requisiti obbligatori richiesti. Tale prodottopermetterà ai dipendenti di comunicare tra di loro tramite tecnologia sms. Inoltre si èdato un esempio pratico della possibilità di aggiungere facilmente in azienda nuovi servizisms, accanto a quelli già presenti.

9.2 Conoscenze acquisite tramite l’attività di stage

Lo stage offerto dall’azienda ospitante mi ha dato la possibilità di esplorare nuove tec-nologie ed ampliare il mio bagaglio di conoscenze.Primo per importanza è stato l’approfondimento del linguaggio java con l’integrazionedel Framework Spring e nello specifico, la risoluzione delle dipendenze tra classi e librerieed inoltre, con il Framework Hibernate, la mappatura delle classi in database.Importante è stato poi l’utilizzo di servlet Java e delle pagine Jsp, di server web diversidal semplice Apache (come Tomcat e Jetty) per l’esecuzione delle servlet, le code Jms,utili in futuro in qualsiasi tipo di software che adotti la gestione di code.Prima dello stage consideravo una web application come un’applicazione generalmentescritta con linguaggi quali l’HTML, il Perl, PHP e Javascript. Fondamentale è stato poil’approfondimento sulll’utilizzo di un CMS come Joomla, ormai conoscenza obbligato-ria richiesta dalla maggior parte delle aziende produttrici di servizi web. Tutte questeconoscenze saranno utili in futuro nel mondo del lavoro permettendomi maggiori sbocchi.

9.3 Conoscenze acquisite tramite il percorso universitario

In questa sezione vorrei indicare la validità delle basi che offre il corso di studio in vista delmondo del lavoro, soprattutto per quanto riguarda l’esame di Ingegneria del Softwareil quale, nonostante la sua difficoltà e l’impegno a livello di ore richieste, offre tutte lenozioni e le pratiche sulle moderne tecniche di sviluppo software. Tecniche conosciuteed utilizzate ormai a livello mondiale e richieste fin da subito dalle aziende che offrono

85

posti di lavoro in tale ambito come ad esempio quella ospitante la mia attività di stage.Senza la padronanza di tali nozioni mi sarei certamente trovato in difficoltà.

86 di 97

9.4 Consuntivo finale

9.4.1 Attività realizzate

Vengono di seguito presentate le attività effettivamente svolte durante il periodo di stage.

Settimana Periodo Attività Ore1 13/09/11 - 16/09/11 Stesura documenti sulle nor-

me di progetto da tenere.Formazione sull’utilizzo delFramework Spring e Hiber-nate. Studio delle codeJMS. Studio del software pre-sente in azienda denominato“SMSTelerete”.

40

2 19/09/11 - 24/09/11 Stesura documento analisi deirequisiti. Individuazione re-quisiti obbligatori e creazionediagrammi UML dei casi d’usoassociati.

40

3 26/09/11 - 03/10/11 Progettazione del Frameworkper operazioni con tecnologiasms con relativi diagrammiUML delle classi. Progetta-zione database per il servizio“Campagne Sms”.

40

4 - 5 - 6 04/10/11 - 22/10/11 Implementazione del Fra-mework. Modifiche alsoftware SMSTelerete. For-mazione sul CMS Joomla!.Implementazione servizio“Campagne Sms”.

123

7 - 8 24/10/11 - 04/11/11 Verifica e validazione - Ese-cuzione test ideati. Elabo-razione di un manuale svi-luppatore. Collaudo finaleprodotto

57

87 di 97

9.4.2 Differenze con il preventivo

A lavoro ultimato si possono evidenziare delle differenze con le attività preventivateall’inizio. In ordine:

Formazione: Si pensava che fosse sufficiente una settimana per la formazione sullenuove tecnologie invece, con il vincolo di utilizzo del CMS Joomla! per lo svilup-po del servizio “Campagne Sms”, si sono dovute utilizzare altre ore a tale scopo,obbligandomi quindi a velocizzare la fase di sviluppo.

Implementazione: Alcune ore messe a disposizione per lo sviluppo dei Servizi utiliz-zanti il Framework sono state invece usate per apportare modifiche ad un softwaregià esistente in azienda.

Nonostante queste discrepanze, il preventivo combacia quasi del tutto con le attivitàeffettivamente svolte. Questo è sicuramente dovuto alla precedente esperienza acquisitaattraverso l’esame di “Ingegneria del Software” e “Sviluppo e gestione di progetto” laquale ha affinato le mie capacità di pianificazione di progetto.

88 di 97

Appendice A

Prodotti ottenuti

In questa appendice vengono riassunti in forma quantitativa tutti i prodotti ottenutidopo la conclusione di ogni attività svolta durante il progetto.

Ecco una tabella riportante attività svolta, prodotti ottenuti alla sua conclusione eloro tipologia.

Attività Prodotti in uscita Tipologia prodottiColloquio stage Capitolato prodotto Documento PdfAnalisi requisiti Documento analisi dei requisiti Documento PdfProgettazione Documento specifica tecnica Documento PdfProgettazione Diagrammi delle classi Diagrammi UmlProgettazione Diagrammi database Diagrammi Sql

Implementazione Documento definizione di prodotto Documento PdfImplementazione Codice sorgente Framework Codice sorgente JavaImplementazione Impostazioni Spring/Hibernate Codice XmlImplementazione Modifiche software SMSTelerete Codice sorgente JavaImplementazione Modifiche software SMSTelerete Codice XmlImplementazione Codice sorgente servizio Campagne Codice sorgente Php

Test Codice sorgente test Codice sorgente JavaStesura manuale Manuale sviluppatore Documento Pdf

Stesura presentazione Presentazione per il collaudo Presentazione Pdf

Qui invece vengono quantificati i prodotti ottenuti in base alla tipologia. Nel caso dicodice sorgente viene indicato il numero di linee di codice ottenuto.

Tipo prodotto Quantità/linee di codice prodottoDocumenti 6

Diagrammi Uml 2Diagrammi sql 1

Codice sorgente Java 2000File di configurazione Xml 300

Codice sorgente Php 700File di configurazione Php 100

89

90 di 97

Appendice B

Valutazione strumenti utilizzati

Seguono qui alcuni commenti riguardo gli strumenti utilizzati durante l’attività di stage.Per quanto riguardo gli strumenti per la stesura di documenti e diagrammi, di supportoper il codice Java e Php (Eclipse), la valutazione è positiva. Infatti la scelta è stata fattain base a esperienze personali.Per quanto riguarda i framework Spring e Hibernate, essi si sono rivelati impegnativiper quanto riguardo l’apprendimento, ma un’ottima soluzione per la risoluzione delledipendenze e della mappatura su database di classi.Il framework Joomla!, già dal suo primo utilizzo, si è rivelato semplice e ricco di docu-mentazione online. Inoltre permette di apportare facilmente modifiche in futuro.

91

92 di 97

Glossario

Api

In informatica con il termine Application Programming Interface API (Interfacciadi Programmazione di un’Applicazione) si indica ogni insieme di procedure disponi-bili al programmatore, di solito raggruppate a formare un set di strumenti specificiper l’espletamento di un determinato compito all’interno di un certo programma.9

Asp

Active Server Pages (Pagine Server Attive, in genere abbreviato in ASP) sono pa-gine web contenenti, oltre al puro codice HTML, degli script che verranno eseguitidal server per generare runtime il codice HTML da inviare al browser dell’utente(proprio per questo vengono in genere definite pagine web dinamiche). In questomodo è possibile mostrare contenuti dinamici (ad esempio estratti da database cherisiedono sul server web) e modificarne l’aspetto secondo le regole programmatenegli script, il tutto senza dover inviare il codice del programma all’utente finale(al quale va inviato solo il risultato), con un notevole risparmio di tempi e banda.13

Database

Significa archivio. È una raccolta di informazioni di vario tipo strutturate in mododa essere facilmente reperibili in base ad una chiave di ricerca determinata. Perestensione, questo termine viene anche usato per indicare un’applicazione destinataalla gestione di simili insiemi di informazioni. I database tradizionali sono suddivisiin campi, record e file. Un campo coincide con una determinata informazione, unrecord è composto da una serie completa di campi e un file è un insieme di record.19

Framework

Scheletro, intelaiatura, fondamenta. Termine normalmente riferito ad una strut-tura predisposta, tipo template, di un’applicazione. Nel linguaggio informatico,Framework viene usato per descrivere la struttura operativa nella quale viene ela-borato un determinato software. Di solito un framework include software di sup-porto, librerie, ecc. che aiutano ad assemblare le varie componenti di un progettosoftware. 9

Gsm

(Global System for Mobile communication) è lo standard per comunicazioni cellu-lari digitali adottato in Europa. 9

93

Ict

Le Tecnologie dell’informazione e della comunicazione sono l’insieme dei metodi edelle tecnologie che realizzano i sistemi di trasmissione, ricezione ed elaborazionedi informazioni (tecnologie digitali comprese). L’uso della tecnologia nella gestionee nel trattamento dell’informazione ha assunto una sempre maggiore importanzanella società odierna. 10

Ivr

Il sistema IVR (Interactive Voice Response) è un servizio informativo molto in-teressante per le aziende di piccole medie e grandi dimensioni per la capacità diottimizzare il flusso delle chiamate ed indirizzarlo direttamente verso specifici set-tori aziendali.Il chiamante ha la possibilità seguendo il menu vocale di digitare ilcodice e raggiungere velocemente il settore aziendale desiderato. 45

Java

linguaggio di programmazione orientato ad oggetti (realizzato dalla Sun Microsy-stems). 13

Jms

Java Message Service (o JMS) è l’insieme di API, appartenente a Java EE, checonsente ad applicazioni Java presenti in una rete di scambiarsi messaggi tra loro.14

Jsp

(Java Server Pages) sistema di scripting, simile alle ASP di Microsoft, in grado direalizzare pagine web interattive a contenuto dinamico. 13

Mockup

Per mock-up si intende comunemente la riproduzione di un oggetto originale ad usodidattico, dimostrativo, scenografico o di comunicazione visiva. In particolare, inpubblicità e nella comunicazione visiva in genere, i mock-up vengono solitamenteutilizzati come modelli o prototipi, per testare una nuova confezione, un espositore,uno stand fieristico, oppure ancora un gadget o una scenografia per uno spot. 47

PHP

Personal Home Page, home page personale. Linguaggio di scripting (open source)usato in documenti HTML che serve per effettuare funzioni interattive lato server.14

Servlet

programma scritto in Java appositamente per essere eseguito da un server WEB.Questi programmi hanno la stessa funzione dei CGI script. 13

Sms

(Short Message System) Sistema per invio di brevi messaggi, nella telefonia cellu-lare. 9

Telnet

In informatica e telecomunicazioni Telnet è un protocollo di rete utilizzato su Inter-net.L’obiettivo del protocollo TELNET è fornire un supporto per le comunicazioni

94 di 97

sufficientemente generalizzato, bidirezionale ed orientato ai byte (otto bit). È so-litamente utilizzato per fornire all’utente sessioni di login remoto di tipo riga dicomando tra host su internet. 56

Umts

(Universal Mobile Telecommunications System) è lo standard di comunicazionemobile per i telefoni cellulari che permette, mediante l’allargamento della banda ditrasmissione di 2 Mb/sec., un migliore utilizzo di Internet per i cellulari predisposti(WAP). 9

95 di 97

96 di 97

Bibliografia

[1] Cédric Beust, Hani Suleiman (2007) Pearson Education - “Next Generation JavaTesting”

[2] Craig Walls, Ryan Breidenbach (2007) Manning - “Spring in Action”

[3] Christian Bauer, Gavin King (2006) Manning - “Java Persistence with Hibernate”

[4] Wikipedia, l’enciclopedia libera: http://www.wikipedia.org/

[5] Documentazione Api Aimon : http://www.aimon.it/

[6] P. Canesi. MAM (2003) Vodafone - “Messaggistica aziendale Mobile, protocollo dicomunicazione”

[7] Robert J. Brunner (2003) Morgan Kaufmann. - “JSP pratical guide for programmers”

97

http://www.wikipedia.org/

http://www.aimon.it/

Corso di Laurea in Informatica - Università degli studi ...

Documents

Transcript of Corso di Laurea in Informatica - Università degli studi ...